Mockup Week Day 2: Wet, Wet, Wet

Apparently someone dug into a huge underground water reserve! This place is wet, wet, wet, and it’s making my boots soaked. Down here its cold and chilly—Staying too long might catch you a cold. Brrrr!

Mockup Week Day 1: Dry and True

Dry and True! The dusty, dry, rocky cave that we’ve all seen before. The ground is sparse and rocky; and the walls seem to be red to very much the tone of red clay. The carving of the walls and floors suggest that this cave was not created by natural means; So who did this? Tomorrow we can go deeper to find out!

Mockup Week!

Starting tomorrow, every day I will be posting a mockup of a new "stage" in my game.

Stage of what, you may ask? As you descend the Cave you will traverse radically varying landscapes; each unique landscape is a stage.

I will be posting a picture along with a short teaser on what each stage will play like.

See you tomorrow!

Coming First: "Dry and True"

Protector Rush

As a sort of weekend project I decided I’d try out Flixel! With that, I began writing a small flash game which would be sort of a “prequel” to what goes on in Pocket.

It was fun!

Working with Flixel was kind of a pain at first since I had been working with FlashPunk for the past 8 months. That said, me and Flixel quickly warmed up together and became great friends.

For kicks, the game is up at FlashGameLicense. Let’s see if I can get a sponsor! I’ll post it here if it looks like my FGL venture isn’t getting anywhere.

The game was inspired by a certain game in dev over at TIGSource, as well as Final Fantasy XIII and the desire to make a game that’d work on Android phones.

Coming next: MOCKUP WEEK

Just a little piece of art!

Here’s a break from the recent Pocket updates!

A little bit of scribbling from me, this was pretty fun to do. It took about two hours—still need to work on that background if I decide to continue on it.

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.

Splash Splash

Image embedding is being a hater soooo:

Click this to see some epic puddle action