Allright, got the first alpha-version done finally! Here's how things are looking now:
The game can be downloaded from indieDB: http://www.indiedb.com/games/magiduck
I've tested the game on DosBox with CGA, EGA, VGA and SVGA_S3 configs. Seems to be working alright, but maybe it's good to mention that the display-initialization has been completely written in Assembly now (in case anyone thinks this might be risky). The EGA-version doesn't seem to be able to disable blink in Dosbox but PakuPaku has the same issue, so I'm blaming that on Dosbox for now. The keyboard routine is now included in the Assembly-library too.
Just to confess my horrible sins: the previous pre-alpha release was actually dangerous. The keyboard initialization was haphazard and could cause a situation where it would jump to a wrong segment of memory. The Assembly-routines didn't preserve registers correctly either. All these should be corrected now. I've tested the game for long periods of time and have had no issues in Dosbox. Deathshadow's timer-routine probably had nothing to do with my previous memory issues, it simply made my old mistakes manifest themselves.
Most of the work lately has been about creating new content; levels, graphics and tweaking behavior code. Also spent a lot of time on tiny tech-tweaks, code-cleanup and some tools to improve my content pipeline.
There are still many things to optimize in the Assembly routines, so I think the next version will run slightly faster.
I added a new menu system, which allows for HTML-like layouts with text and sprites. It can easily be used for text-pages or pop-up windows too. It uses the game's normal actors to save menu elements so only 32 bytes of extra memory spent on that. The menu text elements are streamed from a file when needed and simply printed into video memory. Just to reduce disk-access, I also decided to spend ~1K of memory to precache some of the most often used menus. I can only guess how fast or slow the file-streamed menus will be from a floppy :|
The animation system is revised too, decided to KISS multi-part animations goodbye. The sprite atlas now uses more memory and it simply uses some bigger sprites, instead of sprites consisting of multiple parts. Every animation frame stores all the information needed to store a sprite, memory offsets, size, etc... With all this, the new system still uses less memory than the old one and has much less overhead, when adding sprite-data to the draw-list and clipping sprites against the screen bounds.
The actors in the game now form a linked list, so parenting is quite a bit easier and that can be used to create some multi-part entities instead of the animation system.
Levels are packed into one big file now and there's less file clutter in the game folder otherwise too. I'm hoping to create some kind of package format that would include both levels and tile-graphics at some point too.
Anyways, I'd be happy to hear any critiques or bug reports about this if anyone has the time
I'm sure the game will remain a tower-climber thing with very similar mechanics though, but any ideas for enemies or new
game-mechanics are very welcome too. Right now, the experience is admittedly a bit flat. Perhaps partly because of some lame level design, but I think it could use some more dynamic elements to create more interesting chains of events.
The game can be downloaded from indieDB: http://www.indiedb.com/games/magiduck
I've tested the game on DosBox with CGA, EGA, VGA and SVGA_S3 configs. Seems to be working alright, but maybe it's good to mention that the display-initialization has been completely written in Assembly now (in case anyone thinks this might be risky). The EGA-version doesn't seem to be able to disable blink in Dosbox but PakuPaku has the same issue, so I'm blaming that on Dosbox for now. The keyboard routine is now included in the Assembly-library too.
Just to confess my horrible sins: the previous pre-alpha release was actually dangerous. The keyboard initialization was haphazard and could cause a situation where it would jump to a wrong segment of memory. The Assembly-routines didn't preserve registers correctly either. All these should be corrected now. I've tested the game for long periods of time and have had no issues in Dosbox. Deathshadow's timer-routine probably had nothing to do with my previous memory issues, it simply made my old mistakes manifest themselves.
Most of the work lately has been about creating new content; levels, graphics and tweaking behavior code. Also spent a lot of time on tiny tech-tweaks, code-cleanup and some tools to improve my content pipeline.
There are still many things to optimize in the Assembly routines, so I think the next version will run slightly faster.
I added a new menu system, which allows for HTML-like layouts with text and sprites. It can easily be used for text-pages or pop-up windows too. It uses the game's normal actors to save menu elements so only 32 bytes of extra memory spent on that. The menu text elements are streamed from a file when needed and simply printed into video memory. Just to reduce disk-access, I also decided to spend ~1K of memory to precache some of the most often used menus. I can only guess how fast or slow the file-streamed menus will be from a floppy :|
The animation system is revised too, decided to KISS multi-part animations goodbye. The sprite atlas now uses more memory and it simply uses some bigger sprites, instead of sprites consisting of multiple parts. Every animation frame stores all the information needed to store a sprite, memory offsets, size, etc... With all this, the new system still uses less memory than the old one and has much less overhead, when adding sprite-data to the draw-list and clipping sprites against the screen bounds.
The actors in the game now form a linked list, so parenting is quite a bit easier and that can be used to create some multi-part entities instead of the animation system.
Levels are packed into one big file now and there's less file clutter in the game folder otherwise too. I'm hoping to create some kind of package format that would include both levels and tile-graphics at some point too.
Anyways, I'd be happy to hear any critiques or bug reports about this if anyone has the time
I'm sure the game will remain a tower-climber thing with very similar mechanics though, but any ideas for enemies or new
game-mechanics are very welcome too. Right now, the experience is admittedly a bit flat. Perhaps partly because of some lame level design, but I think it could use some more dynamic elements to create more interesting chains of events.