Tummai Games

Took some time away from work and hobbies to spend some time with the family. Before I left I was working on adding some enemies into the game. I made three different monsters and added enemy-loading logic to the room-loading routines. The enemies display onscreen fine and die when you shoot their HP to 0. Tomorrow I’m going to work on some movement patterns.

I felt I should do some kind of update though, so here are the terrifying monsters I whipped up in GIMP. Turn on the lights before looking at them or you might die in your sleep:

1. Purple Tongue Head
   
   

   When you see it coming, the shit runs down your leg.

2. Eyeball
   
   

   It's looking for something to KILL!

3. Shuriken
   
   

   It's pointy.

I haven’t posted in a few days and that’s because I’ve been spending my time doing research. I’ve been peeking at other games and seeing how they handle sprite objects. By sprite object, I mean entities in a game that are represented on screen with sprites: enemies, projectiles, powerups, etc. When I was trying to code bullets, I didn’t really know how to go about it. Should I keep them separate from other sobjects (sprite objects) or are there enough similarities to lump them together?

If you think about it, a bullet isn’t much different from an enemy. It has an x and a y. It has a speed and a movement pattern. It has a palette. It has a hit box. The main difference is what you check for collision against. Enemies collide with the hero. Hero bullets don’t. They collide with enemies instead.

So some logic is different, but the data (or rather type of data stored) is the same! As far as turning the sobject data into actual sprites, bullets can be treated just the same as enemies (the hero too). Why do I care? If I am able to lump them all together, I can make all the sprites in a single loop. Here’s an example of what I mean:

Sobjects to Sprites

Let’s say I have a hero. That’s one sobject. He can shoot bullets. Let’s say I want to allow 3 bullets maximum on the screen at a time. That’s three more potential sobjects. Then enemies. Just pulling a number out of the air, lets say I want there to be 10 enemies on the screen at a time maximum. That’s ten more potential sobjects.

1 hero + 3 bullets + 10 enemies = 14.

So I have 14 sobjects that could be represented on the screen at any one time. If I treat them all the same, I can hold all of the data in arrays, like this:

sobj_id: .res 14
sobj_hp: .res 14
sobj_x: .res 14
sobj_y: .res 14
sobj_hitbox_top: .res 14
sobj_hitbox_bottom: .res 14
...etc

Then whenever I need to turn them into sprites, I can just loop through them all using an index register:

sobjects_to_sprites:
    ldx #$00
@loop:
    lda sobj_id, x
    ;do stuff
    ;calculate y, CHR#, attrib and x
    ;for each sprite of the sprite object
    ;and store in DMA sprite RAM

    inx
    cpx #.sizeof(sobj_id) ;loop through all 14
    bne @loop
    rts

And that will cover all my sobjects as far as turning their data into sprites. I don’t need to write more than one routine!

To differentiate between sobject types (bullet vs. enemy vs. hero), I can just have their index range set. For example, hero is always index 0. Bullets are always 1-3. And enemies are always 4-13. This way I always know what to test for collisions against: enemies will always test against index 0 (hero) and deal damage on a collision. Enemies will also test against index 1-3 (bullets) and receive damage on a collision.

With defined index ranges, limit testing is easy too: If the player presses the fire button, check sobjects 1-3. If they are full already, don’t create a new bullet. If there is an open space there, create a new bullet.

Conclusion

I think I finally figured out how I’m going to arrange sprite objects. Today I rewired all of my previous hero-moving code to fit into this new data model and I think I have it working. Tomorrow I’m going to try to add bullets for real!

I originally started working on this game as an entry for a coding competition. The genre was puzzle games and I thought a switch-throwing maze game would be fun to write. I missed the deadline for the contest long ago but I kept working on the game anyway. Now I’m thinking about taking the game in a new direction.

The decision to make a maze-only game was made because there was a deadline, and because the genre for the contest was “puzzle”. But now that I have as much time and freedom as I want, I think I’m going to expand the game beyond just finding your way through a maze. Specifically, here are some things I want to add that weren’t in the original plan:

1. Enemies and bosses
2. Weapons
3. A way to die (ie, health bar)
4. A way to improve (more weapons. powerups… level ups?)

In addition to these changes, I’m also going to change the setting and storyline completely. No more treasure hunting archaeologist. I haven’t worked out all the details but I think it’s going to be somewhat sci-fi, with the hero as a cyborg (ie, guns not swords). I think using the Guardian Legend girl as my test sprite has influenced me in some way. :).

Anyway, this comes at just the right time. I just got switches and doors working and the next thing I was going to write was a way to break the breakable blocks. In the original maze-game concept there was going to be an item (like a hammer) that the archaeologist hero would find to allow him to break blocks. Now I think it will be a powerup that makes your gun blast stronger.

Next objective: make the hero shoot a projectile when pressing A.