Optimizing

Lately in Pocket's development I've been focusing on some of the things I outlined in my "Pocket's Future" article, along with some other usability and deep code improvements. But, one outward-standing thing I've done since the past update is add a lighting system and some puddles.

These operations are very transparency-heavy, as are many of the effects in my game. And guess what? Flash seems to suck with transparencies.

Some statistics taken on my computer:

When my game is idle in The Pocket it reaches a fairly constant FPS of 125. When I disable the HUD, which is quite liberal with transparencies, the FPS actually doubled. Yes, that's right, up to 250 frames per second when idle.

On average my game took less than a millisecond to update, when in action it would usually take a single millisecond, and in heavy action it can reach 2 milliseconds, with a rare 3. Whereas, the render update constantly takes between 4 and 20 milliseconds. Most of the rendering burden seems to fall on the transparency operations. When disabling all transparencies, my game will stick to the lower side of the spectrum, and with all transparencies turned on in a effect-heavy Cave room the update time will nearly reach 20 milliseconds and above.

With those clock rates, at about 25 ms to update, my game gets about 40 frames per second.. Ehhh~ The ideal rate in my game is 60.

So this brings me to my important point today: Optimization!

It is so very very very important to do clocking tests like these when making games, you have no idea. I'm glad I discovered this now. THIS is why you make a graphic options menu-- Just saying. On a lower-end computer than mine, a player might run at only 10 fps with all effects on! But if I allowed them to be turned off, that same computer could run the game at the desired 60 frames.

Since I'm going to try to support flash devices like Android with this game, optimization tweaks like this becomes even more imperative, I think. Even if update speeds aren't a problem for the phone, battery power most definitely is for every device user, and with that it's important to give them options to lower the CPU usage of my game.

Another very important method I've found in reducing battery usage is allowing the player to adjust the maximum frame rate of your game. Estimating, a game capped at 30 fps only takes half as much battery power as one running at 60 fps. That could mean A LOT for a device user, who manages every task process to conserve their battery. Making my game more power-efficient and easier to run on devices is obviously necessary if I want to make my game at all viable to play.