Powered by dead dinosaurs

Month: April 2013

Entity Component Systems – A Practical Example

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.

Sega Nomad Battery Mod

A little over a year ago, I picked up a Sega Nomad on craigslist for $10. In case you’ve never heard of it, the Sega Nomad is a handheld system that plays full-size Genesis cartridges. They are semi-rare and I was lucky to find one so cheap. Next, I bought an NOS battery pack for it on ebay. I couldn’t wait to play Genesis games on the go.

Unfortunately, the battery pack was DOA. After doing a little research on the world wide interwebs, I found that all of the battery packs for this system are DOA because the Ni-Cd rechargable batteries inside just don’t hold up for over 15 years.

During my research, I came across a YouTube video that suggested a battery pack mod which would bring it back to life. I am the proud owner of a soldering iron and a foolish level of self-confidence, so I figured I might as well give it a try. After all, I took an Electronics class in high school. What could go wrong? Here’s a video of the result:

As you can see, it actually works like a charm! I used the same battery pack as the original youtube modder, a Sony NP-F550 and a cheapo charger, both of which can be purchased on Amazon for very little money. A fairly simple mod for anyone willing to risk $25.

Creating Bouncing Babies for iOS – Game Design Analysis

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

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.

 

 

Powered by WordPress & Theme by Anders Norén