The Home Button

I decided my next step was to implement player state information (lives, items acquired, gold, points, etc). I realized that by adding these, I would also have to handle saving state between closing and opening of my app. This is where I ran into some annoying issues.

The lifetime of your Android app can be modeled by this:

What’s annoying is that pressing “Back” and pressing “Home” are completely different things. Pressing “Back” will cause the kernel to destroy your app, effectively closing it and freeing all the resources your app has allocated. Originally, I had planned that when a user resumes playing my app, they would always begin at the start of whatever level they were last at. This would save me the trouble of saving tons of game state variables, like what monsters are in the game board at the time they last exited. Instead, I just need to save the level. If the user exits my app with “Back”, then all of this works as planned.

The problem occurs when the user exits my app by pressing “Home”. The Home key will immediately return to the homescreen, but will NOT destroy your app. It will call the onStop() method and then your app will continue to run in the background. Interestingly enough, this is the exact same behavior that will occur if you receive a phone call while playing your app, or any other activity interrupts your app. This is where I have two choices, which are implemented very nicely by Plants vs Zombies and Angry Birds.

If Plants vs Zombies gets interrupted, either by Home Key or phone call, when you restart it you will see a loading bar. Once loading is complete, it will place you in the exact state you were in except the game is paused. This implies that they are manually freeing memory or something of the sort, and when you resume they have to spend the time to reload it. On the other hand, when Angry Birds gets interrupted, restarting it is instant. There is zero loading time and you immediately return to the exact moment but paused. This implies that the Angry Birds pause screen is still running at full capacity in the background of your phone.

So for my game, I’m probably going to take the Angry Birds approach and just have my game continue to run in the pause screen whenever users press Home. The game loop will continue to run, just each iteration will do nothing. All the graphics and music will remain in memory and resuming the game will be pretty much instant. Luckily, I can still use my original plan of starting the game at the beginning of the level when the user exits correctly with the “back” button. Since everything is always running in the background, I will not need to save any player state when the user exits with “Home”.

I worked a little bit today. Added hammer swing animation and logic to handle hitting monsters.

And yes, the hammer swings will queue up if you hit before the previous swing animation is done. It’s a simple queue that accepts up to 3 hits. After that, it just disregards future touches until the queue frees up a space. Hitting pause will always enter into the queue.

At first I thought I was going to need some synchronization because the hammer hits are independent of all the gameboard logic. Then I realized that instead of making the hammer swings asynchronous and needing locks, I can just make the hammers occur on the game clock.

Basically when you tap, you insert the location into the hit queue. On the update part of the game loop, you first check whether a swinging flag is true (animation already going). If not, then you remove from the queue and do a hit on that location and set swinging flag to 1. In the draw part of the game loop, you draw as long as the swinging flag is true. The only synchronization I need is around the queue.

My First Big Step

I worked on Renoki a lot this weekend. This was a combination of Allison being gone and the HoN servers being under attack from a DDOS making games unstable. Regardless, I managed to get a monster loaded and the door animations working. And yes you can faintly hear the radio station playing annoying Miku Hatsune in the background.

Anyway, I set up my framework exactly how I described it in one of the earlier parts. There is a loop that runs continuously that continually draws sprites to a screen and also updates their state. There is an array of sprites, with each index corresponding to one of the nine locations on the game board. For now, it just inserts sprites at constant rate, whereas in the future it will be random and dependent on the level speed.

The animations are done by using sprite sheets. This is where I take five frames of an animations and just paste them one after another onto one big image. After you load the combined image, you create a viewable rectangle that only shows one of the frames. Then, you just shift the rectangle over 1 frame at a time and that creates the moving animation.

The monster object is completely independent of the rest of the framework. By this, I mean that the monster controls the door open and close animation and how long it stays on the gameboard. Once the monster decides it is dead or retreats, it sets a flag and the loop will remove it from the array.

I’ve been somewhat busy recently with CMU graduation one weekend and apartment hunting the next. However, I did manage to do some learning.

I sat down and watched this long tutorial which gives a good background of Android graphics.

I’ve also begun to look at several tutorials on how to setup a game loop.
http://p-xr.com/android-tutorial-how-to-make-a-basic-game-loop-and-fps-counter/

Finally, I am taking a look at a tutorial on animating sprites
http://p-xr.com/android-tutorial-how-to-paint-animate-loop-and-remove-a-sprite/

The basic structure of the code will be simple. You have a loop running that continually updates the screen depending on a state. The state will follow the below Finite State Machine. Depending on the state, you will have various sprites or other actions appear on the screen.

I finally decided that I will man up and port Renoki to Android. For those who don’t know, Renoki is the iphone game that Mark and I released that failed phenomenally. You can see it here:

The iphone version is free now and may or may not still be available on the app store. Despite the fact that it didn’t sell at all and had some pretty large stability issues, I want to port it to Android. My hopes is it will be a side project to do in our spare time, as well as allow me to fix some of the shortcomings I found in the iPhone version that Mark never fixed. Once it’s complete I’ll probably buy an Android license and release it for free.

I started exploring some different Tutorials for Android. I first took a look at cocos2d, a graphics library that Mark used to program Renoki. Some developers are in the process of porting over cocos2d to android, and there is a basic version available. I looked it over and I don’t really want to commit to using it while it’s still in development. I’d rather go through the headache of controlling all my animations with the Android native graphics library. Also, considering Renoki is very simple in terms of animation, I think I can handle the load.

Right now I’m taking a look at the LunarLander sample game available on the Android Dev site. It seems to have pretty good documentation, so we’ll see where we get.