You can help CodeWalrus stay online by donating here. | New CodeWalrus | Old (dark mode) | Old (light) | Discord server
0
b/Calculator Development publicado por u/DarkestEx January 29, 2015, 12:48:00 PM


About the game:
The game is a challenging and addictive making puzzle game.
The goal of the game is it, to reach a platform, but you only have two steps, so choose wise, in which direction you go!
You will even be able to make your own textures and levels for it and have highscore tables.

Project status:
We're in beta now, the game mechanics are pretty much fully implemented, BUT right now highscores, texturepacks, leveleditor, settings, etc. aren't made yet. The project is real big, we started it back in 2014, working every day at home and at school, have big real physical, and digital folders full of source code, assembly and axe listings, drafts, textures. One of my friends (Fabian Sölch) is helping me with the ideas, textures, levels and how the gameplay is going to be.

Programming:
Everything is written in Axe (with some assembly parts)
I'm using C / SFML style rendering code and the whole engine is built C styled like I would do in a modern environment, but everything is maxed out in speed and efficency. I'm using a main loop, dynamic callbacks, compression and decompression and more advanced stuff.

Current Version: z80-160210-a (download)

Last Screenshot (of version z80-b150404-a):


Keys, UI and explanation:
(Enter) = Select during menu
(Clear) = Exit
(Up)/(Down)/(Left)/(Right) = Move Cursor
The goal is to collect all black tiles with the least amount of overall steps.
But you have to reach any portal or black tile within two steps. The screen wraps. If you can't reach a safe place after the 2nd step, you will loose one live and the level will restart. If you loose all lives, you have to restart from level 1.

Blocks:
Below is a list and explanation of the blocks in the game:
- This is just plain void. Don't land on it with your 2nd step or you'll die!
- This is a tile. You have to land on each of them with your 2nd step (and all checkpoints) to solve a level. Once you stepped on one, it will disappear afterwards and turn into void.
- This is a solid wall. You can't step on or interact with it.
- This is a checkpoint. You have to land on all of them with your 2nd step (and all tiles) to solve a level. Once you stepped on one of them, it will turn into a platform.
- This is a platform. You can safely land on it. It won't disappear.
- This is a portal entrance. As soon as you land on it with your 2nd step, you will be teleported to a random one of its outputs. There are two portal channels, which look the same, but only teleport you to one of its child outputs.
- This is a portal output. You can step on it, but nothing will happen. It will just behave like a platform.
- This is a door. There can be multiple doors in one level, but when you step on a switch, only one random door will open and turn into void.
- This is a key. There can be multiple keys in one level; if you step on one, a random door will be opened.

- And finally, this is you!

Testing:
If anybody wants to be a tester, just download the latest beta version and if you encounter any errors or feature requests, just write them down here.

Completed:
- Portals
- Checkpoints (done in b050215)
- Platforms (done in b050215)
- Level decompression and compressed write (fixed in b050215)
- BCD level and data reading routines (fixed in b050215)
- Step limit
- Screen wrapping
- Level rendering
- Level changing (fixed in b050215)
- Basic program structure (redone in b050215)
- Doors (added in b090215, fixed in b300315x)
- Buttons (added in b090215)
- Toggleable tiles (added in b090215)
- Normal Platforms (added in b090215)
- Konami code (fixed in b300315x)

In Progress:
- Textures (pretty done with 'em actually)
- Keybindings (a few tweaks needed)
- UI (started in b110215, redone until b150404-a)
- Dialogs (redone in b300315x); some UI elements still missing (input box, etc.)
- Settings Menu (started in b110215)
- Levelpack structure (v3 in progress)
- Levelpack scripting language
- More levels! (last ones added in b300315x)
- Highscore table (started in b150404-a)
- Time limit (started in b150404-a)

Todo:
- Synchronize high score tables over I/O, stats, and hs tables, new file format v3
- Pause menu

Ideas:
- Customizable keybindings
- Option to add a walkthorugh to every level

Feel free to visit my project page.
Last Edit: August 26, 2018, 03:24:38 PM by DarkestEx
Inicia sesión o crea una cuenta para dejar un comentario
u/Dream of Omnimaga January 29, 2015, 12:58:20 PM
Heya and welcome to the forums. :D By the way, is this also your account? http://codewalr.us/index.php?action=profile;u=105 Because it seemed like you registered two forum accounts, so if it's not a friend or member of a programming group, I will remove the duplicate account if you don't mind.

Anyway this game looks nice and it seems pretty interesting. I'll definitively need to play it in order to fully understand the gameplay mechanics. Keep us posted for updates :)
u/Snektron January 29, 2015, 02:50:12 PM
Looks promesing :) i'll defenitely test the beta soon. I'm glad to see more projects emerging from CodeWalrus.
u/DarkestEx February 06, 2015, 01:37:24 AM
UPDATE [beta050215]:

Change Log:
- Added checkpoints
- Added platforms
- Fixed level decompression and compressed write routines
- Fixed BCD level and data reading routines
- Fixed level changing
- Redone game structure
u/Dream of Omnimaga February 06, 2015, 03:57:15 AM
Cool to see new progress. Will checkpoints be in the middle of longer levels or will they be between each level so you can continue where you left off? Also what kind of compression do you use? I am curious about what is the size of each level before and after compression? :)
u/DarkestEx February 06, 2015, 01:55:00 PM
Quote from: DJ Omnimaga on February 06, 2015, 03:57:15 AM
Will checkpoints be in the middle of longer levels or will they be between each level so you can continue where you left off?
Level authors can choose if, and how many lives will be added at the beginning of a level. If you quit, you will be able to continiue, where you left (same level, same score, same lives, but if you're in the middle of a level, you will have to restart that level). But that goes onto my todo list, as right now, no saving is implemented at all. (You cold actually implement state save, as my engine's state and level data is completly in SaveSScreen, so you could just copy the contents of that into a file, and the engine would just continue executing where it left, when you restart the game and copy the contents back to SaveSScreen and jump directly to LOOP (like Hibernate function on PC)). But that is just a possbility and it would cost you about 700 bytes of Flash. It would easier than making a own file format for saving, but however, its on you to decide whats the best option.

Quote from: DJ Omnimaga on February 06, 2015, 03:57:15 AM
Also what kind of compression do you use? I am curious about what is the size of each level before and after compression? :)
I pack my data as small as possible by using every bit of any byte and only using the smallest required data size. This saves a lot of flash but makes uncompressing harder (many bitwise commands in my decompressing algorythm). I made many functions to directly manipulate the compressed content and some to decompress data into ram. The size of one uncompressed level (including its own header) is about 80 bytes. But with my compression its reduced to 40 bytes per level (50% compression rate). An important element of the compressing is using binary coded decimal and splitting bytes in halves. To prevent any problems, the levels will each have its own checksum byte, which must match the checksum of the uncompressed level. There will be a level editor, so its very easy to make levels.

Levels are made out of a 10 bytes header which contains an unique id, setting such as if there is a time and or a step limit, (if any) the actual time and or step limits, the average time needed to complete a level, the average steps needed to complete a level (theyre both for calculating the score), the start x and y position (as one byte, bcd; e.g. write 0x34 (EE34 on calc) for a starting position of X:3, Y:4), and the difficulty of the level (beetween 0 and 15, where 0 is easy and 15 hard) and some reserved bytes, that might get used in later versions). If you're unsure about one field, just fill it with 0.
The second part of every level is it's actual map. It is 30 bytes in size. The data is allocated as a matrix, with a width of 10 blocks (5 bytes) and a height of 6. You can use two portal classes, which might have any amount of inputs and each one can have up to 8 outputs. If one class has more than one output, the output will be choosen randomly. The both portal classes are seperate and don't link to each other. You can place doors and buttons too. But there's only one class. So its the same as with the portals: You can have unlimited buttons, but they can control up to 8 randomly selected doors. You can have platforms, that you have to step on (checkpoints; they turn to platforms after stepping on them) and stay there, you have sole platforms, that you don't have to step onto, you can have solid blocks, that you can't step onto (good for making levels, where you can't acces an area, before solving a puzzle; portals can help by providing a single direction way), you can have empty blocks and finally tiles, that you have to step on, but then disappear when you leave them.

I'm sorry for writing that much, but I'm sure it will make it easier to understand.
u/Dream of Omnimaga February 06, 2015, 11:26:17 PM
Ooh, I like the level customization and editor idea :)

Also nice to see how small levels are. I thought that they would be close to 200 bytes each before compression because of the data and stuff.


Also no problem about long posts every once in a while, especially to explain stuff. ;) The only downside is that since people are busy they might not necessarily reply to them, so I usually keep them for such explanations :P
u/DarkestEx February 09, 2015, 12:40:44 PM
UPDATE b090215:

- added doors
- added buttons
- added checkpoints that you have to reach
- added platforms
- added 4 new levels
- a few bugfixes
- compiled and uploaded new binary (download)

Screenshot:
Last Edit: February 09, 2015, 02:02:10 PM by DarkestEx
u/tr1p1ea February 09, 2015, 12:42:27 PM
Wow looking nice! I can see this game becoming very addictive :).
u/DarkestEx February 09, 2015, 12:43:55 PM
Quote from: tr1p1ea on February 09, 2015, 12:42:27 PM
Wow looking nice! I can see this game becoming very addictive :).
Thanks, tr1p1ea!  :). I hope it makes as much fun playing it as it makes making it.
u/Dream of Omnimaga February 09, 2015, 04:16:10 PM
Looks nice, but you should make the Level complete thing so it's a box that appears in-game so it looks more professional and stuff. Also which sprite are the doors?
u/Snektron February 09, 2015, 06:00:02 PM
Looks good! Maybe like DJO said, some more animations/eye candy. Animations for moving the "player" maybe?
u/DarkestEx February 09, 2015, 08:05:05 PM
Well yes of course will I improve visuals (player animation, gameover screen, etc.) but now as I'm mainly done with the actual gameplay I can focus on the visual things :).
u/Dream of Omnimaga February 10, 2015, 12:24:31 AM
Good move I guess. Some people start with visuals first then the gameplay, without realizing that the latter can be much harder to implement. I generally try to make sure the project is not beyond my skills before spending too much time on anything else.

That said, certain people in the TI community often used very simple graphics in the past (some even stuck with menu-based gameplay) and since many games use similar graphics, it's good to ask newer programmers if in the future they plan to spice things up.  :P
u/DarkestEx February 11, 2015, 06:24:23 PM
UPDATE b110215:

- Fixed glitch, that allowed to cheat (You could have gone one step and then pressed Enter to trigger it, as if you landed on it with your 2nd step; No worries, Konami Code will be added instead ;))
- Added dialog messages using dynamic assembly callbacks
- Fixed last level's portal positions
- Changed texture of door and button (now key)
- Started with the config menu (for you, it just displays "Comming soon!" - Don't notice the typo :P)
- Changed in-game footer status text for readability
- Bugfix in level loading routine (removed wrong return statement in the middle of the levelrc block; how did that came there?)
- Added block explanations to the main post

Download the binary here while it's fresh.

Screenshot is here:
Start a Discussion

b/Calculator Development

Showcase your newest TI, Casio, HP, Numworks or Sharp calculator projects here, discuss programming and share or browse user tutorials!

320
Topics
Explore Board
Website statistics


MyCalcs | Ticalc.org | Cemetech | Omnimaga | TI-Basic Developer | MaxCoderz | TI-Story | Casiocalc.org | Casiopeia | The Museum of HP Calculators | HPCalc.org | CnCalc.org | Music 2000 Community | TI Education | Casio Education | HP Calcs | NumWorks | SwissMicros | Sharp Calculators
Powered by EzPortal