Category: Game Development Page 2 of 5

I strained my back last weekend (I’m getting old), so I’m spending a lot of time sitting down these days, recuperating. On the bright side, I’ve had time to start prototyping the Bouncing Babies clone I’m building for iOS. You can see my progress below:

If you want to check out my code, you can clone the GIT repo. Here are a few notes about the prototype:

I don't have any "levels" in the game yet. So far, it just feeds you one "baby" (yellow ball) after another until you get bored. I was just trying to test out the bouncing and the controls. I will add escalating difficulty in the next week or two.

Since this is a prototype, the code has almost no comments and the structure is a bit of a mess. Prototyping is meant to be quick and dirty. The idea is to get a working demo as fast as possible and not worry about the architecture. This helps define what's involved in building the real game. Ideally, you should throw out the prototype when you're done with it.

You'll need a copy of the Flash CS5 IDE to compile the demo. I'm comfortable coding in Actionscript, so I can build faster in Flash than any other method. I decided to sacrifice open-sourciness for speed in this case. I put all of the code in Actionscript class files, so you can dig through the code without Flash CS5 if you wish.

Realism and simulation are often unnecessary. In this game, I want the bounces to be equal distances apart. If the bounces were realistic, they wouldn't be equally spaced. But, I can make it feel right just by carefully adjusting the height and speed of each bounce. The game won't actually model reality, but a user won't notice because it feels right.

Along those lines, I wanted the bouncing on screen to look good. I know that the path of a ball flying through the air is given by a second-order (parabolic) equation:

y = Ax² + Bx + CSo, I used this basic equation to specify each bounce. From linear algebra, I knew that I needed 3 equations to solve for my 3 unknowns (A, B, and C), which meant that I needed 3 points on each bounce. These were easily measured directly from the original game, but it takes about 5 minutes to do the algebra for each curve. There are 4 curves. What if I decided later that I wanted to tweak the height or width of the curves? So, I spent a little longer solving the equations with a set of hypothetical points: (a,b), (c,d), (e,f) and used them to create a helper file in Flash. It's in the GIT repo as arcmaker.fla. I can input any 3 points and it will calculate A, B, and C for me. It also draws the graph on top of a screenshot of the original game so I can see it. Last, it spits out some text that I can copy-paste into my game actionscript files. I probably spent a little over an hour on this. I used to resist coding helper scripts and level editors, thinking that it would be a waste of time, but it almost always pays off. If you think a helper script might be useful, go ahead and make it.

Another way of making the game feel right is to speed up the ball a bit on each bounce. When the ball moves at a constant horizontal speed, it actually feels like it's slowing down (because my bounce paths are too wide). I use a multiplier to speed up the ball a bit on each bounce. I created another helper for fine-tuning this. If you right-click on the Flash demo above and choose "Show Testing Console", you can change this multiplier. I have it set at a value that feels okay to me. a value of 1 will not change the speed at all - try it and you'll observe the "slowing down" effect. a value of 2 will double the speed on each bounce, 3 will triple it, etc. After updating the multiplier, right-click on the screen again and choose "Hide Testing Console" to play the game with the new speed settings. Tweak the multiplier value until the game feels right. It's amazing how such a small thing can make a huge difference in how the game feels. Again, this is another one of those helpers that is worth the time to code because I can quickly try different values and see what feels right.

The prototype is coming along nicely. I just have to code in my levels to ramp up the difficulty. Then, I can start figuring out how to port the game to iOS.

In case you missed it, the GIT repo is here. Clone it and you can follow my progress as I continue working.

...And you thought you'd never use algebra in "real life":

game design - who says you'll never need algebra

Yes, smarty pants, I know I could have solved the equations more easily with matrices, but my matrix algebra is super rusty, so I did it old-school.

Entity Component Systems – A Practical Example

By Andy

On April 25, 2013

In Actionscript/AS3, Game Development, Uncategorized

I have been reading up on entity component game engine architecture a lot lately. Essentially, an entity component system uses composition to create objects and throws away old-school inheritance style programming. This is because game objects feature a lot of complex functionality that can create inheritance chain problems. I understand the concept and it makes a lot of sense, but there are very few nuts-and-bolts breakdowns of how to implement an entity component system.

Luckily, Richard Lord has come to the rescue with Ash. It’s an Actionscript3 entity component game engine. He also wrote an extremely detailed blog post outlining the difference between an inheritance-based design and an entity component design, with a ton of code snippets so you can see the implementation details.

Please note that Ash is just one variation of an entity component system. There are other ways to do it, but this is the best explanation of entity component systems that I’ve found.

Creating Bouncing Babies for iOS – Game Design Analysis

By Andy

On April 15, 2013

In Game Development, iOS Game Dev, Uncategorized

Another post in my iOS game development series…

Before I try to recreate Bouncing Babies for iOS, I thought I should take the time to do an analysis of the gameplay. This could prevent some wasted time during development.

First, I want to point out that the original game fits the definition of a Classic Arcade Game:

Single Screen Play
Infinite Play
Multiple Lives
Scoring and High scores
Easy-to-learn, simple gameplay
No story

The original game was shareware back in the DOS days (pre-Windows). I knew that the game didn’t use a physics engine (not even remotely possible with the computing power back then), but I wanted to get a good look at how it worked, so I pinched a gameplay video from YouTube and combined all of the possible frames into a single image:

bouncing babies game design analysis

The image shows all of the possible positions for the babies and the player firefighters. Note how the babies can actually occupy only a handful of positions. Even when you have multiple babies on screen at the same time, they can only be in these distinct positions. The speed of the babies can be slowed down by simply repeating frames.

The gameplay is simple. You control a pair of firefighters who must bounce the babies to safety. As you can see in the image above, the firefighters have only 3 distinct positions. There are 2 control schemes:

the left and right arrow keys.
the 1, 2, and 3 keys.

Either way, I thought it would be an ideal game for converting to touchscreen control. The firefighters respond to the controls with no latency – as soon as you hit the key control, your players jump to the corresponding position. This seems obvious, but note that it is unlike breakout or pong, where the player can place their paddle in almost any position and the challenge is getting to the correct spot in time. Bouncing Babies is much simpler. The challenge is simply to hit the correct key at the correct time.

Here is another image showing the positions of the babies when they hit the ground:

bouncing babies game design analysis 2

There is no collision detection system in the game. As you can see from the second image, when a baby reached the low point of it’s bounce, the player firefighters had to be in place to bounce it. If not, the baby went splat. Again, the game is all about timing. When the baby was just about to hit the ground, the game checked if the player was in place to bounce it. If yes, bounce the baby. If no, the baby hits the ground.

One interesting thing I noted when I created the images above – the third bounce arc is smaller than the second. It doesn’t just look smaller – there are fewer baby positions in the third arc than the second. This means that it takes less time for the baby to fly through the third arc. This makes the timing more complex than it would be if the second and third arc were identical.

I’ll be making some tweaks to the game design, but I don’t plan to make any changes to the actual gameplay – just the way that the code works. Stay tuned for more.

Don’t forget, you can follow my agonizingly slow progress on the github repo:
https://github.com/wastedpotential/bouncing-babies
I’ve added the images from this post to the SOURCE folder in the repository.

Game Time: Spelunky

By Andy

On April 8, 2013

In Game Development, Game Time, Game you should be playing, Uncategorized

If you spend any time on XBox Live Arcade, you probably already know about Spelunky. What you may not know is that it has actually been around as a free-to-play PC game for several years. I’ve only played the Windows version, so that’s the one I’ll talk about.

Spelunky is hard to describe. It’s a 2-D platformer that looks like an NES-era 8-bit game. Like a true NES game, dying means that you start back at the beginning. But there are two things that make Spelunky brutally difficult. First, it’s a rogue-like, meaning that you don’t have multiple lives or even a health bar. A single hit from any enemy kills you and you start back at the beginning.

To make matters worse, all of the levels are procedurally generated. That means that when you die and start over, a new level is randomly generated. This means that you never play the same level twice, so you can’t just memorize patterns like in most classic games. You need to actually hone your game playing skills to get anywhere in this game. On the bright side, Spelunky is really well balanced, so you won’t get stuck on a level that’s impossible to complete (unless you foolishly waste all of your ropes).

If it sounds sadistic, it is. Spelunky is the sort of game that will have you yelling at your computer screen. It’s also a hell of a lot of fun. I spent many hours playing it back when it was first released as a free PC game and I’ve heard that the XBox version is even better and more polished. I have no XBox, so I can’t say.

One of the interesting things about the original Spelunky is that it was built using GameMaker. GameMaker isn’t usually considered a “real” game developers platform, so I think it’s cool that an exceptional indie game was made with GameMaker. It’s a good reminder that a great idea will get noticed, regardless of the technology.

If you want to play the free PC version, you can get it here.

It's not worth doing unless it's worth overdoing

Category: Game Development Page 2 of 5

iOS Game Development – Prototyping Part 1

Entity Component Systems – A Practical Example

Creating Bouncing Babies for iOS – Game Design Analysis

Game Time: Spelunky