It’s the year 2600, and you have embarked on a voyage to find new alien artifacts in order to advance your civilization. The only problem is, the planet you are excavating on is still inhabited, and its natives aren’t too happy that you’re trying to take their stuff!

This is the premise of Alien Blitzer, the product of an afternoon of game jamming. It was built from concept to prototype in a 6 hour period with the theme of “Evolution”. In this post I just want to explore the game itself, and influences. I will be going over takeaways separately.

The Game

Here’s a slightly cleaned up version of the game. This is what we finished up with, with the exception of bugs,  a couple minor visual things, and the intro screen. While incomplete, it was a nice prototype for the given time with two people . I coded the game in ActionScript while Josh Flash created the HUD and sprite graphics. I’ve included the demo and source below, although I warn, the source isn’t pretty.

Demo | Source

Mechanics

Core mechanics are pretty simple, you have your arrow key movement (up, down, left right), and projectile attack. Ammo is expendable, so the player must collect ammo as they make their way through the stage. And there are also aliens the player must dodge or destroy.

One of the inspirations was the old NES title Legendary Wings. It looks as though I borrowed a few ideas, although not necessarily intentional. These include player controls, enemies, and weapon power ups. It may not look as much in the prototype, but that’s where things were going.  The weapon system is intended to share the same weapon “evolution”,  giving the player a more powerful weapon as they collect items. In addition, the baddies are intended to have a more elaborate  movement, opposed to the straight lines.

Getting Technical

Alien Blitzer is built using Flixel, and a small set of other tools. Here’s a quick break out of what was used.

Controls – Player movement and attacking is handled by Flixel Power Tools’ FlxControl. For prototyping, this library makes things super simple as long as you’re looking for basic controls.

Tile Mapping – The tile map was put together with Dame Editor, and is made up of a few layers for the ground map, water, and mobs. The mobs needed some extra processing with ActionScript so they weren’t all part of one entity, and are activated by distance from the player. I was looking for something built into Flixel or Flixel Power Tools to more eloquently detect and trigger an event for when the object was on screen, but wasn’t able to locate anything in time.

Hud & Sprites – Graphics were created in Photoshop. They snapped in really nicely, replacing a bunch of  ugly colored blocks that acted as placeholders.

Intro Screen – The intro screen uses Flixel Power Tools’ special FX, and Greensock’s TweenMax for the animation loop.

Future Tasks

I’ll be using what I learned from this game towards future games, including an upcoming prototype. Here are some points of focus in the near future:

Polish – The player controls and mob speed really needs to be tweaked so that thought can be put behind shooting the baddies. Maybe even some reworking of sprite proportions. As it is now, by the time a mob comes into view, you don’t have enough time to move into position to kill it. The level itself also need to be extended, it’s pretty short.

Sprite Management – I’m playing around with managing mob sprites in Dame so that there is little need for extra coding. This will make the polishing mentioned above much easier. Dame gives the option of creating several ActionScript classes that cover the tilemap/level, sprites, and interaction between these objects and the rest of the game. I intend on playing with paths and “trigger” tiles, which can effectively guide or alter sprite behavior, but I’m not sure if I can fit those into this game.

Music – Adding music has been a struggle. At first I was running into bitrate issues, but now it fails silently. I’ll want to add sound effects, and soundtracks in the future. Overcome I must.

Conclusion

There you have it. A review of my latest prototype. It has opened up a few more avenues to explore, which I’ll be writing up posts for as I go on.

I’m curious what technologies here others are using, or maybe want to learn. Input is welcome.

At the end of April I had my first Game Jam with our local Sac Game Jam meetup. It was loads of fun, and a valuable experience. For this jam series, all teams start from the ground up, beginning by deciding on a game concept, mechanics, and then building out the prototype. This is all done within a relatively small period of time (around  6 hours), and at the end we all demo our creations, for better or worse.

My team went with a tug-of-war concept, and we used ActionScript using the Flixel framework.  We consisted of two ActionScript programmers, and a graphic designer. Let me just say, graphic designers are awesome. We were lacking some key equipment, so we restored to taking photos of the hand drawn images using a cellphone. Low tech, but it worked out. The paper cut-outs had a neat look too! In the end we made a mad dash to make things presentable, and while we had something to show, there was more we had wanted to include that didn’t make the cut.

There are many pitfalls that can be encountered throughout the prototyping process which can snare both newbie, and experienced jammer. These traps can be enticing,  often giving the facade of being critically important (“the game will be nothing without this!”), and in some cases of no importance (“we can figure this out later”, “this will be a snap!”). These can be avoided through preparation, planning, and restraint. Here are some tips I’ve gathered from this experience that I found noteworthy and will apply in future jams.

1.) Come prepared, don’t learn the framework at the game jam

There should be a basic understanding of how to use the framework,  not mastery, but some familiarity. The key issue is you don’t want to be spending chunks of time struggling with a mechanic or feature. This will eat up what little time you have like Pacman.

2.) Prototype, quick and dirty

Don’t worry too much about what it looks like, in code or graphically. You’re strapped for time, no one is going to care if it’s all nightmarish spaghetti code (*shudder*). Ya, it would be awesome if you could OOPify things with Player->doSomeAction(enemy), but you may be complicating things, which results in bottlenecks further down the line.  Make everything public, keep it in a single file unless absolutely necessarily.  In addition, don’t worry about animating sprites, or anything like that. This is just a prototype to give the idea of what you’re game will be like. Resort to using colored blocks and shapes if need be. Prototype like the wind!

3.) Start with simple game mechanics

Decide on core mechanics within the first moments of the jam, and keep those mechanics simple. It’s really easy to get carried away with game mechanics and lose sight on your main objective. Mechanics that require conditions and checking (ex. buff/debuff system) should be boiled down to something more manageable so that it doesn’t become a hold up. Even if the mechanics sound too simple, stick with them until it’s been implemented. If they really are that simple, you will have time to expand and add.

4.) Divide up features when working in groups

Working with another programmer adds a layer of trickiness. You now have to be careful of not stepping on the other fellow’s toes. Avoid overlap, and give ownership to features. Break things out logically like movement, item collection, and enemy collision. This is a practice that should be started at the very beginning so that there is a minimal amount of duplication.

5.) Be ready to share your stuff

When working with a group, be sure you have a way to efficiently share code at any time. There are many services out there, such as DropBox, but it doesn’t have to be that fancy. E-mail will work just as well. If you don’t have something setup in advance, resort to what ever is the most effective that doesn’t take long to setup. Advanced forms of code sharing, such as version control (Subversion, Github) may be tempting, but should most likely be avoided due to complications that can arise, such automated merging, and conflicts. From a coders perspective, you should know what is being removed or added.

Conclusion

Well there you go, a handful of pitfalls to watch out for from a great learning experience that was Game Jam #4.  There will be more that I will be sharing as I journal more past and future jams.  The important thing is to keep looking how to improve yourself, and most of all to have fun.

Thanks go out to GameDevRadio.net for their podcast on prototyping (and others).