Renoki has been on the market for a while and I’ve gotten a lot of feedback on the game. Here are some of the improvements I’ve made so far.

Improving the Shop

People didn’t know what the items did. In particular, nobody had any idea what the wings did (which is pretty understandable). Anyway, I added a pop up box when you select the item and you have to press “BUY” in order to actually make the purchase. The pop up box has a short description of what the item does, hopefully eliminating all question.

Improving StartScreens

Having the informative picture on the start screen tended to be completely ignored. I’m not sure if it’s because the picture itself is unintuitive, or people don’t even realize that it has information on it. Anyway, I added some text to the start screens to make it painfully obvious what you are supposed to do. I really wanted to avoid using text but I couldn’t see any better way of doing it with the limited space I had.

Improving Number Monsters

Nobody understands the number monsters (correction, one person from work understood it). Anyway, I added text explaining what to do and also the first level with number monsters have the numbers painted on the door. This “should” make it painfully obvious what the point of this monster is.

Adding More Feedback
Someone brought up a good point that if sound is off, there is no feedback on good or bad hits. At first I thought of using the vibration feedback that Android already has built in for keypresses, but realized this might be too intrusive for users. Plus, it requires an explicit permission and I’m trying to keep my app permission free right now. So instead I have the entire gameboard briefly flash red when a bad press occurs. I think this worked out very well as it clearly stands out and indicates that something went wrong.

Enclyopedia
From an early stage of development, I wanted to add a Renoki Encyclopedia where I could list every Renoki along with funny descriptions/flavor text. I stumbled upon ViewPager, a brilliant little thing for Android that allows you to automatically do horizontal swiping of pages (similar to the current Android market). All you need to do is drop in some images to each page, and the user can easily swipe through each one. Now I just need to think up funny back stories for each Renoki.

Balance Tweaks
I think the game is too hard for people. I toned down the speeds for Normal and lowered shop prices. I realized that people actually mess up a lot so they have to buy hearts quite frequently. Someone mentioned that they got far in the game but were never able to save up enough to buy a hammer. I needed to amend this, as the later levels get really hard without the upgrades.

https://market.android.com/details?id=com.panda.Renoki

Or search “Renoki” on Android market. The Amazon Appstore dev fee is free for 1 year, so I’ll be uploading there as well soon.

I finally decide to just publish the app. I was going to go and balance test it some more, but I got lazy. Plus, publishing the app will motivate me a lot more to keep fixing it once bug reports and such start flowing in.

You can find in the Android Market by searching Renoki.

I discovered a very annoying thing recently that made me have to reconsider how I handled touch input.

Originally, my game consisted of a game loop that updates the state of all the sprites and then draws them onto the screen. Touch input was handled asynchronously, meaning I need a lock around my update section. The reason is that I don’t want touch input to affect the state of anything while I’m in the middle of updating, otherwise I could have a race condition where the update section is about to jump to state X, the user presses a button to go to state Y, and then the update section resumes and pulls it back to state X.

Now I understood the problems that could arise from this. Touch input needs to be processed relatively quickly or you get Android Not Responding errors. I felt that even if my touch input had to wait for 1 or 2 update loops to finish, that is still only fractions of a second. Unfortunately for me, sometimes the Android kernel will decide not to give the touch input priority to run. Instead, it will allow the update loop to keep acquiring the lock over and over, resulting in the dreaded ANR. And there wasn’t any sort of fair lock I could use, because I was just using Java’s “synchronized” command, which is supposed to handle locking for you.

I realized that I would have to make a queue of all touch events. When a user touches, it enqueues into a touchQueue. In each loop iteration, I dequeue 1 touch and process it. This way, you only have to lock around the touchQueue, which greatly reduces the chance of a touch event getting blocked.

It’s at this point that I realized something else stupid. When a touch occurs, it calls some onTouchEvent(MotionEvent event) and passes you a MotionEvent object which describes properties like the x, y coordinates, and whether it was a down or up press. Unfortunately, you need to make a copy of the MotionEvent it passes you, because after the onTouchEvent() is done, it will reuse that object. I sat around for a while, wondering why the MotionEvents in my queue were getting corrupted and it took me forever to realize this.

Now you need to consider having a pool of Events. It’s inefficient to recrete a new Event object every time a new touch is made. It’s better to have a pool of Event objects. When a new touch is made, you request an Event object from the pool. If the pool is empty, it creates a new one for you, otherwise it hands you a pre-existing one. When you are done with the Event object, you add it back to the pool for future touches to use. This saves on the overhead of dynamically allocating a new Event object every time there is touch input.

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.

Sound
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.

Shop
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
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.

Hearts
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).

Credits
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.