Renoki: Making An Android Game (part 9)

I coded a good amount this past week and managed to complete a good chunk of work.

Re-organizing Bitmaps – Originally I just initialized bitmaps in the main view. I decided that was a bit too limiting and moved them into the global application context. I grouped bitmaps into arrays depending on the game state (menu, help pages, gameboard, monsters, items, etc). I realized when making monsters that I needed access to multiple bitmaps (different stages of the animation) and so having all the bitmaps be globally accessible makes things a lot simpler. This way, I can declare multiple NumberMonsters and they all share the same bitmap, without having to pass in 4-5 bitmaps per object.

Number Monsters – Number monsters are of course the monster that has a number on it which forces you to hit the corresponding number location instead of the monster itself. In the code, we refer to this as owning a spot. The problem we’ve always had with these guys is when you go to hit a normal monster and a number monster appears in another spot and takes ownership of the spot you’re about to hit. Then you tap down and the hammer is redirected to hit the number monster, instead of your intended target. Unless the user has fast reactions or is aware of this case, they become confused. Where did my hit go? Why is this monster still here? Why did another door open and immediately close with no monster in it?

To prevent this problem from happening, you have the number monster appear, but be un-hittable until the door has fully opened. At this point, it is blank and has no ownership. Once it is fully in view does it then take ownership. This eliminates the problem of doors opening and immediately closing with no monster (that looks like a bug). It also makes it much more obvious where the hammer is being redirected to, as you can see the full number. Of course, you are still going to have people not noticing that a number monster appeared but there’s only so much I can do without sacrificing the entire game mechanic.

Shield and Sword Monster – These were very similar. In certain states they play one animation and cannot be hit. In other states they act like normal monsters. Interestingly enough, once I had figured out how to do the spinning animation for the new NumberMonsters, I just leveraged this code for Shield and Sword. It was a simple state diagram where one state loaded a different bitmap sheet and reacted to hits differently.

So now the core set of monsters are done. The only things to add are higher levels (trivial, I just adjust the health/damage they do), money monster (trivial, I just make hitting it steal money), and bosses (somewhat trivial, just modify the stay time, health, and force the location). The next step is work on the framework for levels.

One Comment

  1. Allison

    August 10, 2011

    What Shield and Sword monster are you talking about??? The helmet dude?

Share Your Thoughts

Leave a Reply