5th of April – Vectorblade VIII – Beware I live!

After some pondering – I decided I just keep going and see where coding leads me.

Thanks for all suggestions and kind words!

Following optimizations have been done:

– halfed the animation size of (most) bonus

– rotation of enemies are now only 8 directions (instead of 16)

– optimized bank switching

– optimized game loop

– implemented horizontal mirroring of patterns

– reduced enemy “level” information

– reduced a couple of macro based “coding” to subroutines – which cost quite a few cycles

– and probably more stuff I can’t remember

To get a “feeling” of the size and stuff that is missing I copy/pasted from Release the title music and highscore table/ editing / saving.

I plan to implement an “own” Game Over and Highscore screen at one time – but for now its usable and hopefully uses about as many bytes as the things I plan to do.

I decided on a theme for the next levels – which will be more “robotic” – and the new “Big Bug” will look a bit “sinistarish” – “Beware they live!”

I’ll probably reduce the vector count considerably from above image – but that was a first “start”.

Lets get a bit more into the game “mechanics”.

Enemies

Enemies are defined with an EnemyDefinition.

struct EnemyDefinition 
 ds ANGLE8_TABLE,2          ; if zero -> BigBug 
 ds BUG_ENEMY_HP, 0 
 ds ENEMY_STRENGTH,1        ; HP
 ds WAIT_ANIM_TABLE,2 
 ds ENEMY_BULLET_SPEED, 1   ; bug only (for now), lower nibble speed, uppernibble #xnnn, x= 1 can fire missiles
 ds ADDITIONAL_TYPE_INFO,1
end struct

As of now two different enemies exist
a) “normal” enemies
b) Big bugs

Normal enemies
– enter the game in patterns
– behavior of pattern and intro can be modified with “ADDITIONAL_TYPE”
– normal behavior:

• – intro via a pattern
  – after pattern a “delay” is done (enemy invisible)
  – enemy enters screen at a random position at the top of the screen
  – enemy goes to its waiting position

– waiting position:

• – 20 different positions, where enemies wait and “wobble”
  – waiting positions can be defined per level (pointer to waiting position table)
  – from waiting positions attack patterns are randomly initiated
  (count of attack pattern using enemies at the same time can be set via level information)
  – enemies can shoot (count of maximum shots per level can be set per level)
  – probability of shooting (and of bonus drop) can be set per level

The normal behaviour of an enemie can be modified by “ADDITIONAL TYPE” definitions, as of now:

• TYPE_NONE = 0
• TYPE_DIRECT_WAIT = %00000001
  – does not enter a “delay”, will not be invisible, from last “intro pattern” position, the enemy moves to waiting position
• TYPE_DONT_SHOOT = %00000010
  – this enemy can not shoot – never!
• TYPE_DONT_ATTACK = %00000100
  – this enemy will not initiate an attack pattern
  (all three combined can be used to define “blockers”)
• TYPE_DONT_WAIT = %00001000
  – this enemy behaves in a “normal” level like a “kamikaze” attacker
  (it does not enter a waiting position after intro pattern – it “vanishes” instead)
  this can be used to have larger intro waves – but still restrict the overall enemy count to 20 on screen!

Blocker example:

The above shown blockers “protect” the attacking enemies. Each blocker in the example has about 20 hitpoints.

Attack Pattern

Addition to attack patterns (more info on attack patterns: Vectorblade II) – attack pattern are really something one would nowadays call “scripted enemy behaviour”. Anyway attack sub-pattern definition can now also include “loops” – so the order of sub-patterns (in one attack pattern) is not necessarily linear anymore.

Thats all for today.

Malban