Just some numbers that are currently used:
- At maximum at the moment I configured to have 35 “objects”
(object is everything that “moves” – shield, base and score are no objects) - Displaying all objects including sound, base and score takes about 26000 cycles
- Displaying the same with a “full expanded” shield take about 5000 cycles more – except in cheat mode, I don’t think that is possible
- Collision detection uses many cycles, but only those that are “near” the shield are exactly checked. Destroying all 35 objects with max shield and max shield width (whole screen) – the collision detection takes an additional 30000 cycles – but just for that one instance of checking – again, in real life without cheating such a thing does not happen.
- “Explosions” take slightly more time than the objects – showing 35 explosions takes about 31000 cycles (again – not possible).
- Object generation is happening “on the fly” – if the object list is full, the object that should have been built is discarded (can be seen e.g. with to many explosions – than no floating scores are generated (but scores for the player are awarded nonetheless)
Each object uses as of now 20 bytes of memory (RAM) – but optimizing – that could be reduced to at least 16. Probably won’t do that, since as of now that is not necessary.
The ingame RAM handling is nearly complete and I still have over 100 byte RAM left.
Scoring (since we are at numbers), high score can be up to 999 999 points, although to achieve that I have to balance the game a bit more :-).
The bonus “stars” can give bonus up to 254 points.
The game right now gets more difficult “automatically” – the spawning of enemies gets faster the more objects are spawned.
The final game will be a mixture of automatic difficulty adjustment and programmed adjustment.
Internally the game will have “phases” – which will be switched by certain enemy spawn counts.
Each phase will set a hole bunch of game behaviour variables as seen here:
(this is actually all implemented, for testing 4 phases exist)
phase1: db DEFAULT_ALL_SPAWN ;spawn types allowed db SHIELD_WIDTH_GROWTH_DEFAULT ;4 2 up , ec -> bpl than width grow db SHIELD_DEFAULT_SPEED ;2 shield major speed ; update every tick, must be in sum greater than minor increase db SHIELD_MINOR_DELAY_COUNTER_DEFAULT ;2 shield minor counter delay; test for dec -> bpl db SHIELD_MINOR_INCREASE_DEFAULT;0 shield minor speed increase db INITIAL_SHIELD_WIDTH_ADDER ;1 1-4 shield width adder db INITIAL_SHOT_MOVE_DELAY ;0 shot move delay ; test for dec -> bpl db INITIAL_SHOT_MOVE_STRENGTH ;0 shot move strength db INITIAL_X_MOVE_DELAY ;1 x move delay ; test for dec -> bpl db INITIAL_X_MOVE_STRENGTH ;1 x move strength db INITIAL_HUNTER_MOVE_DELAY ;0 hunter move delay ; test for dec -> bpl db INITIAL_HUNTER_MOVE_STRENGTH ;1 hunter move strength db INITIAL_BOMBER_MOVE_DELAY ;1 bomber move delay ; test for dec -> bpl db INITIAL_BOMBER_MOVE_STRENGTH ;1 bomber move strength db INITIAL_BOMBER_SHOT_DELAY ;200 bomber shot delay ; test for dec -> bpl, decreased by 25 every shot down to 50 (50 = 1 s) db INITIAL_DRAGON_MOVE_DELAY ;5 dragon inner move delay; test for dec -> bpl db DRAGON_CHILD_FREE_SPEED ;2 dragonchild (free) speed; update per tick db DEFAULT_MINIMUM_BOMB_RELOAD_DELAY; 50 db INITIAL_BONUS_MOVE_DELAY ;3 x move delay ; test for dec -> bpl db INITIAL_BONUS_MOVE_STRENGTH ;1 x move strength db DEFAULT_BONUS_ACTIVE_TIME ;9 in seconds dw 20 ;next phase after 20 spawnes
With the use of automatic difficulty adjustment AND the phases I am quite confident, that a finetuning of release is pretty much possible.
Changes since beta:
- again optimization of vector routines – for now I deem them fast enough, doing it faster will use much more memory
- some sounds added
- adjustment of base/shield – should be centered now
- added “phases” but not configured…
- scores get multiplied by the number of objects destroyed with the same shield (max x 3)
- implemented bonus (display, catch, countdown) – but not the bonus effect yet
Malban