Renoki: Making An Android Game (part 11)

It’s been a long time since I made post about this. I’ve been kind of lazy about updating this and uploading a video to youtube.

Surprisingly, sound was relatively easy to implement and did not produce as much of a strain on my app as I expected. There are two types of sounds: short, quick sound effects that are played frequently and long background clips. To play background clips, I use the default Android MediaPlayer, which takes an mp3 file and streams it. This allows for lower memory usages as opposed to bringing the entire mp3 into memory. For sound effects, I created a SoundPool for quick retrievaly. You essentially pre-load all your clips into memory and can play them immediately. This is more efficient than having to create a new MediaPlayer object for the hundreds of little beeps and blips that play while smashing Renoki.

The only thing to take note of is that you have to kill your mediaplayer every time you stop the app. Otherwise it wastes resources and also keeps playing in the background. That and making sure you take into account pausing and resuming your app in every possible method. I ran into quite a few points where I would turn the app off in the middle of something and resume with no sound.

Victory Screen
The victory screen now gives you the option to Continue, enter the shop, or return to menu. Originally, the shop was a random monster that appeared and when you hit it, it opened the shop. Although neat, this confused the hell out of people (I still don’t understand how it isn’t painfully obvious that it’s a shop when it opens) and didn’t really add any value to the game. So now you can enter the shop in between levels no matter what and buy what you need.

The shop is the same as the normal gameboard. Each item is a monster that never retreats and only dies if you have enough money to kill it. Had to add some logic to make certain items disappear or not show up depending on what the user already had. For example, if a user owns the gold hammer, the bronze and silver hammer should disappear.

Bosses worked out incredibly well with my existing architecture. I merely had to add a boolean flag in the regular monster as to whether it’s a boss or not. In the event that it’s a boss, it draws an additional little health bar above it’s head that decreases in size as it’s health goes down. I have a special case in my levels at 5, 10, 15, 20 to insert the boss monster into the corresponding position and set the stay time to be huge. I then just had to change my level timer logic to make the player lose if the time ran out before they killed the boss, instead of winning.

Back Button
Unlike iPhone, Android has a back button that allows you to navigate between screens of the same app. I had to override the default action to prevent back from accidentally closing the game. Instead, if you are playing it pauses, if it’s paused you go to the menu, and if it is at the menu, it exits with a ghetto confirm box (art pending). The thing I need to decide on is whether pressing back in the confirm exit screen exits the app or just closes the confirm box. Some games (Angry Birds) pressing back twice will confirm and then exit. Other games (Cut the Rope) pressing back twice will open and close the confirm box.

Switching Number Monsters
I realized (quite late) that a Number Monster (the guy where you hit the corresponding number location and not the monster) didn’t need to have “health”. Instead, it would have a hit count, and each time it was hit the monster would rotate and switch to a new number. Once the hit count ran out, the monster would automatically be destroyed. Luckily, my architecture for monsters was flexible enough to allow this by just modifying the hit method in my NumberMonster class. I already had the spinning animation when the monster first appeared, so all I had to do was reset the monster so it would spin again, while subtracting the hit count. So now I have stronger number monsters that take 2 hits with 2 different numbers and also a boss that works the same way but with a lot more health.

One enormous nested if/else shitfest that draws hearts depending on the life of the player. I considered making an algorithm that could scale for any number of hearts, but I realized it wasn’t worth the effort because a player can’t have more than 6 hearts (24 life).

I actually have a ghetto scrolling credits page right now. It looks really terrible though, so I’m thinking about just making a victory graphic with all the Renoki or something and have a credits button on the main menu.

Loading Screen
I have to run a separate thread that loads all the images and sounds. Meanwhile, my main game thread has to just loop and wait until the loading is complete.

Share Your Thoughts

Leave a Reply