Tarvos

Status report

A few tweaks here, mostly to get things done faster when creating levels. Since I don't want to pursue the 'store level data in a text/xml file and read it at run time path' (too many security requirements when I last looked into it), things need to get hardcoded. In order to lighten the load, I'm shipping anything that gets repeated a few times off to procedures, etc. This will also help, as it will force me to standardise the names of the files I pull (as this will be done automatically).

It's a bit unfortunate, but each level currently takes me quite a lot of work - Reclamation has only had 2.5 levels made for it so far. This isn't just due to the requirements of making sprites, backgrounds, etc. It's got some overhead as far as putting things into the game itself.

What I fixed (fixed Bugs)

What I broke (new Bugs)

Bugs (old & new Bugs combined)

• Collision detection algorithm - may need more investigation. This could actually be less 'bug', and more 'not sticking to the rules I forgot to write down' - This actually seems pretty solid lately
• If player attempts to use weapon immediately on load, exceptions occur. If player tries later, they will work - images not fully loading in time may be the cause

Improvements list aka To-Do

• Implement new concept for collision detection
• Spawners
• More items, weapons
• Code so that Fireballs are created after player animation is done, not at the start
• Code to ensure that when an item is on top of another item that is moving, it also moves - ie: relative motion
• Action Items should have a list of affected objects, rather than a single object for greater flexibility

New features/Improvements implemented

• New procedures for allowing easier entry of level information
• Projectile throwing enemies now have a timer before they can throw again

Summary

Different styles of AI attacking are good to implement, as they allow the engine to present different options. The code implemented actually allows the projectile to be given an X & Y acceleration, which means that arcing projectiles can be made, or if gravity for that sprite is switched off, horizontal 'zaps' can be done as well. Additionally, the projectile is only formed at the end of the animation.

Looking to the future, I'm considering a new strategy for maps, etc. I think that I'll rewrite the engine to also keep a list of Rectangle objects, which the engine will treat as simple 'Foreground' objects. This way, I won't have to make the level map, then break it into smaller pieces, and insert those as sprites. Instead, I can simply draw the (static) platforms onto the background, and use the new Rectangle list to account for the Foreground objects. This will make the games significantly more lightweight - less sprites will be required (use of Rectangle rather than Sprite will free up a lot of processing), less PNG files to download, etc. I imagine that level development time will be faster too (again, less time to enter the data). Could indeed be interesting.