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.