8 tips for a smooth launch to your indie game

It's time to finally launch your game... or is it? Have you done everything on this list?

In the game industry there is an oft-quoted rule of thumb that states "Creating 80% of the game only takes 20% of the time". It's a variation on the Pareto principle, and in my experience, it is fairly accurate.  Even once your game is finished, fully playable, and not to mention, fun, there is still a ton of work to do before you're ready to hit the trigger and let the rest of the world play it.

I've been a key developer on the launch of several major games, even more small ones, and of course the only developer for Tactic's first (and currently, only) game, Immortal Empire.  I've seen smooth launches, bumpy launches, and delicious lunches.  Let me make this next point abundantly clear by writing it in the largest, boldest font this website will allow:

Having a smooth launch for your indie game is extremely important.

Your dev-instincts have probably already alerted you to this, but let me just drive it home with a few important factoids and common misunderstandings.

• This rule does not really apply to major studios. If you want to point to Skyrim being buggy, or World of Warcraft's bumpy launch despite their respective successes, please understand that this doesn't apply to you. This is because:

• People will not wait for your game to work. You will get a big boost to traffic when your game launches. If your game is not working for a particular user, that user will very likely never ever play your game again. Boost to traffic wasted. And it's not just the users:

• Distribution platforms measure you based on a very brief period during your initial launch. Platforms like Steam or Kongregate will decide how much advertising your game will subsequently receive based on how it performs at launch. At launch. Not 2 weeks after launch, and certainly not 6 months later even if you significantly update or improve your game.  And finally:

• Game reviews will come at game launch. Even getting someone to review your game can be difficult. Getting them to re-review it after you've fixed all the bugs? Forget it. And expect a bad review.

If the above doesn't make it clear - don't don't don't launch a half-finished or even 90% finished product with the idea that you will "continually update it" as it grows into a massive success. Finish your game, then launch it. If it's a success, update it and grow your community.

One key clarification. When I say launch - I'm referring to your "big launch".  For example, when you go live on Steam to the general public. Closed betas, alpha funding, and other soft launch techniques are actually something I'm about to recommend.

So you're launching a massively multiplayer game and don't exactly have thousands of trained quality assurance testers to make sure it's working great. How do you make sure you have a smooth launch?  It's a mix of prevention and damage control.

Tip 1 - Have a fast build / deployment system  

Your bug-free game has lots of bugs. Sorry :(.  Don't believe me? The most recent patch for Starcraft 1 was released in 2009, over 10 years after its original release date. Fixing a typo? Nope - just little things like being able to nuke from anywhere on the map.

Sometimes your patch might even introduce bugs!

You're going to need to patch your game, so make sure that you have a fast, 1-touch build and deployment system ready so you can catch anything that slips through the cracks immediately.

I've seen people try to follow a complex 20-step process just to build and package up their game for deployment, and the whole time they are quadruple checking each step because they don't want to make a mistake.  Don't do this! Automate your build and deployment process. Write a program, a script, anything! Throw some (preferably lots of) automated testing in there too! It is much faster, safer, and gives you confidence that your game has been deployed properly.

Most importantly, it means you can very rapidly fix bugs as soon as they are discovered.  Which brings me to:


Tip 2 - Have an automated bug reporting system  

So we've established that your game will have bugs, despite your best efforts.  The vast majority of people will never tell you that they have encountered a bug. During the launch window, if it's a severe bug, or your server has crashed, they will most likely just silently quit your game and never play it again.

Use asserts, detect crashes, keep a useful running log of user actions on the client machine to aid debugging and upload reports to your web server.


Tip 3 - Implement real-time memory and performance profiling

Some bugs are simple and easy to reproduce.  Others are more insidious.  Your game might be slowly leaking memory or fragmenting. Your performance might be worsening over time or spiking in certain situations you hadn't previously encountered.  Not only is it useful to have in-engine real-time profiling tools for development reasons, it is very useful for catching these sorts of bugs and fixing them.

Keep track of poor performance or unusually high memory and report such cases using your automated bug reporting system.

It's also important to check these things during development. So you should:

Tip 4 - Run automated tests during development

"yo jsut hire a bonch of roobots to test ur game11`" - xXgamedevkilla16Xx

I know you're eager to build weapons and enemies, but you should spend a bit of time building some robot friends - an automated testing system. Do this early in development and it will save you mountains of headaches - and dissatisfied customers - in the future. 

You should be running the 3 main "S"'s of testing: Smoke, Soak, and Stress tests.

• The type of smoke tests that I recommend are basically a barrage of unit tests. Check to see if everything works at a basic level. 
• Everything from "Does the game run?" to "When I execute a trade with another player, do they end up with the expected item?"
• Usually a programmer will manually test the code they just wrote for its direct functionality. Smoke tests are excellent for catching situations where the code you wrote has inadvertently broken other areas of code. 
• (PS - proper code architecture can minimize this, but that's for a future blog post.)

• Soak tests will generally run the game for extended periods of time looking for memory bloats, leaks, performance leaks and such.
• Boot the game, and leave it running executing simple "normal" actions for long periods of time (say, 24 hours. Weeks if it is a game server.) For example, log a player in. Say some things in chat. Enter a game room. Kill a monster. Quit. Repeat!
• Boot the game and load all your levels in a loop over and over again. This might reveal leaks caused by level transitions.
• Boot a level and warp to various areas in the game, (in particular for 3d games) looking for performance leaks. Boot next level, and repeat.
• (PS - even garbage collected languages or engines can experience memory bloats. You're not safe! Run soak tests!)

• Stress tests attempt to maximize a particular element of your game. This will give you a good read on the capacity of your game and reveal problems that otherwise would remain hidden until an end user experiences it.
• Fill a level with highly intensive graphics to stress the GPU. Use realistic situations - the goal isn't just to overheat your video card. Spawn more enemies, have them all firing weapons and blasting particle systems, and so forth. 
• Fill a level with highly intensive computations to stress the CPU. Again, use real-world situations to test your game, we're not here to just eat up cpu cycles. Run complex physics simulations with thousands of entities. Execute huge numbers of costly pathing lookups for units in the game.
• Fire large numbers of database accesses, or login large numbers of users to your multiplayer game, flood bandwidth with large amounts of network traffic (or, better yet, limit your bandwidth to see how your game performs under poor network conditions).

You might think the cases you're developing will never happen and aren't worth testing. This is exactly the fallacy that causes bugs to slip through the cracks.  

Run these tests regularly. Daily, or with every build. Some companies will run this on every changelist that's submitted. Running tests frequently lets you isolate what changes you made that may have contributed to degradation of memory, performance, and most important, stability.

These tests also help identify bottlenecks. At one point when we were developing Bioshock 2 multiplayer, if every player equipped the incinerate plasmid and blasted each other, performance would grind to a halt. We found this case using a stress test and optimized that plasmid until it performed much better. 

When I first ran stress tests on Immortal Empire I saw very quickly how many concurrent users the server could potentially handle, and found that database accesses and unit pathing were bottlenecks. So, I optimized all the DB accesses and offloaded those calculations to a separate server. I also severely optimized the pathing to handle common failure cases (where no path was found) as they were the most costly operations.

Tip 5 - Soft launch your game. Repeatedly.

Houston, we have a pillow.

Other than QA and automated testing, your best defense against a bad "hard launch" is to soft launch your game as much as possible.  The idea is simple: launch your game to a select group of people who are aware your game is a work in progress.  People are going to do things your automated tests aren't.

Even with all the automated testing, Immortal Empire did the following and found bugs at every step of the way.

• Closed beta for friends and family (~50 people)
• Closed beta for select users (~300 people)
• Open beta with small press release (~2000 people)
• Soft launch Kongregate (~10000 people)
• "Hard launch" Kongregate (~100000 people)
• Steam (Still to come!)

In particular, you will begin to discover exploits.  Have a plan in mind for what you will do once someone figures out how to dupe items, farm huge amounts of gold in a short time frame, or hack your game to gain an edge over an opponent. Because it's going to happen!

Friends, family and select users will be vastly more forgiving than the average public. For us, the "open beta" and "soft launch Kongregate" included random users and let us gather game statistics too - what immortals were most popular? The most powerful? What spells seem to be dealing too much damage or too little? Which items are people choosing? Are they too strong? This type of data mining helps tremendously to balance your game and make it more fun and fair for everyone.

The remaining tips pertain only to multiplayer games. I have released many many real-time multiplayer games in my career and can confidently say they have their own set of unique, much more difficult problems than single player games.

Tip 6 - Schedule maintenance with a shutdown warning for connected users

Don't just tear down your server if you've found an exploit or crash.  Schedule maintenance, allow it to continue, and start fixing the problem.  When the maintenance window comes around, all you'll have to do is use your fast deployment system and boom! You're back in action.

Players don't like their game to be down for extended periods of time, but if there has to be a shutdown, they are far more forgiving when it's scheduled in advance. This gives them confidence that the shutdown was planned and that everything will be running again soon.

When it is time to shutdown your server, don't just disconnect players in the middle of a game. Give ample warning that the server is about to go down, and disable creation of new games. Wait until most of the games are finished and then tear it all down.

Tip 7 - Use separate staging and release game servers

This is the most optional tip in this list, but it's pretty handy as it will allow you to patch your game server with no perceptible downtime to your end user. 
For you programmery types this is double buffering for game servers.

Basically you have 2 sets of servers running concurrently, one for staging and one for release.  No one is logged onto your staging server, only the release server. It's time to patch! Update your staging server and leave your release server running. Take as much time as you need, because no one is logged on. Once it's ready to go, redirect all new traffic to the staging server.  

Then, as players finish up their games and log off the release server, the total number of users will eventually reach zero.  Now, switch them! Your staging server becomes the release, and the old release becomes staging. Voila! You just patched your game code and no one had to endure any downtime.

Tip 8 - Put a hard limit on the total number of concurrent users

Believe it or not, people actually will happily wait in line for something. But if you let them in and realize it's too full and ask them to leave, that's not going to go over well.

It's true that you want to have the capacity to support unlimited number of people. But you can't reasonably expect to estimate how popular your game will become, and server costs can be expensive, so overcompensating is unwise.  It's better to tell someone "sorry wait in line" than have them overwhelm the server causing it to screech to a halt.

Use your stress tests to get a sense of your server capacity for network bandwidth, CPU consumption, and memory. Then, cap the number of users to ~80% of that limit.  Finally, use your real-time memory and performance profiling to measure live users to get a sense of whether your estimated capacity is accurate.  Code in support to adjust that capacity real-time as needed.

Traffic for a new game is typically very spiky. On Immortal Empire we were running a small open beta and averaging ~20 concurrent users. Overnight, we had a favourable news article appear on Destructoid. I woke up to ~200 concurrent users and a slew of bugs.

Fortunately, I had prior experience launching multiplayer games and was ready! I followed the above tips and the server kept running despite the unexpected spike in traffic during our soft launch.  Then I scheduled some maintenance and released a patch a few days later.


Conclusion

So the million dollar question: Is it worth it?  I'll be the first to admit that if you're writing a small, single player Tetris-clone, you probably don't need to implement anything on this list. I've released many small scale games that didn't have these systems in place and they launched fine.

But as the complexity of your game increases, the above tips rapidly become requirements.  I've been to many major game studios, and these systems are commonplace. For any medium scale or greater game, or any multiplayer game with centralized servers, you're going to want this stuff.

You put so much effort into your game, you'd be throwing all that effort away if you aren't properly prepared.  

Thanks for reading, and I hope this helps you have a smooooooooooooth peanut butter lunch!  I mean launch.

Addendum

Immortal Empire was greenlit on Steam back in July 2014 and we're gearing up for another "hard launch". We're currently running a Kickstarter to help fund some significant improvements to the game before we go live on Steam. A stretch goal on that Kickstarter is to release our game engine and source code for free. 

So if you'd like to see how we implemented the above features, or simply want to use our game engine (for free!) to make your own game (and never have to build any of the above systems) then mosey on down to our Kickstarter and give it a look-see. Thanks!

How to get art in your game without being a professional

I'm not an artist, but I need art in my game.

This is part 3 in a series of articles describing how I approached each aspect of creating Immortal Empire as an independent developer. Read the whole backstory here.

Artwork is the area I relied most heavily on outsourcing to a number of individuals, most notably Mat Chambers (characters), David Baumgart (spell icons, fx), Zenobia Homan (tiles, environment objects), and Eric Vedder (illustrated characters). A few other artists (Sergei Churbanov, Cecilia Santos, Jasmin McGahan, David Scott) helped out as well to which I am eternally grateful.

Of course, trying to coordinate so many different people was difficult, and in some cases I needed to fill in some gaps with artwork myself.  In my previous article where I discussed the music to Immortal Empire, I pointed out that I have some formal experience with music, making that aspect of the game much easier to tackle.  When it comes to artwork however, I have literally no experience to draw upon. (moar puns!!1)

In the end, I deigned to create some affectionately termed coder art, much of which can be seen in the final product.  This article describes the process I went through and includes some tips I picked up which are hopefully useful to other artistically barren programmers like myself who need art in their indie games.

I'm very proud of many things in Immortal Empire, but let's face it, the artwork is not exactly cutting edge. At a fixed 800x600 resolution and consisting almost entirely of hand-drawn 2D pixel art, Immortal Empire's artwork lands somewhere between X-Com and Warcraft II, meaning it would feel right at home if it were released in 1995.  Alas, it was released in 2013.

Click for full-size

Many games have managed to be very successful in recent years despite not having advanced graphics, often employing a minimalist style to great effect.  Unfortunately I feel as though minimalism just wouldn't have worked for the game design of Immortal Empire, so instead I attempted to mimic a style that is very nostalgic for me: early 90s PC games.

Onto the artwork. I contributed in a number of areas, but I'm going to focus on a couple images I drew that will best describe the process.  Here is the animation for the entangle spell on the left, and the idle pose for the Elder character on the right.


For the pixel art, the process I eventually settled on went something like this.

0. Compare against a couple different neutral colour backgrounds, never change your opacity, and always work on a separate layer.  Accidentally using alpha or manually blending into a fixed colour background looks terrible in game, and it is a very easy mistake to make. Using separate layers for each step lets you restart when you make mistakes and do A/B comparisons easily.

1. Start with an outline.  When drawing lines (without alpha transparency), I found it almost always looked better to leave diagonals open rather than filled in like the image on the right. 


When creating rounded lines, decrease or increase the number of straight-line pixels consistently, rather than doing something arbitrarily. I'll often draw the line free-hand at first, delete the diagonals, then touch up the curve to keep line lengths consistent.

This might sound obvious but you really don't want to move onto the next step until you have finished this one.  At this stage, a silhouette can work as well, but I prefer an outline so you don't lose interior details.

2. Add shading to your outline. As with the lines widths, be consistent in how you gradient the colour.  By that I mean gradually increase or decrease the luminosity rather than flipping back and forth or skipping a shade.  I try to avoid adding detail in this step, instead I just shade uniformly. When creating rounded things like the tentacles below, I found it often looked best to put the brightest section near the center, not right on the edge. Keep a palette of distinct colours you have used on a separate layer for future use.

3. Add detail to the shading. This is where you can put creases in clothing, make things appear rough or shiny, or add dithering if that is your art style.   I try to avoid introducing new colours here, and instead would refer to the palette that I created in step #2.

Click for full-size

4. Add final touches.  Here I add little doodads like the buckle on the Elder's sash or the thorns on the tentacles. When doing this step, I found I often had to go back and adjust the shading.  For example, creating a little shadow underneath the buckle made it feel less flat.  Only when I am 100% happy with the look of this one frame will I start another frame of animation or attempt to draw more of the same element (such as the multiple tentacles in the entangle spell).

That's it!  My preferred setup is to use two windows, one zoomed in very close where I edit the pixels, and another zoomed out to 100% so I can actually look at the results. I check the actual zoom distance frequently, as I found that things sometimes look great zoomed in, but from afar look totally wrong. In fact, the opposite can also be true!

Like most things, art of course takes years of practice to improve. But here's hoping these few tips can help other artistically challenged independent developers like myself create some medicore but passable artwork for their games.  If you have anything to add about your adventures in this regard, or tips you can suggest, please comment below!

How to get music in your game without being a professional

I'm not a music composer, but I need music in my game.

This is part 2 in a series of articles describing how I approached each aspect of creating Immortal Empire as an independent developer. You can read the whole backstory here.

One of my favourite things about gaming, in particular when playing RPGs, is enjoying the musical score.  From Jeroen Tel, to Nobuo Uematsu, to Jeremy Soule, there are so many talented composers out there, and I just love listening to game music both in game and out.

So when I started working on Immortal Empire, I knew I wanted it to have a full orchestral score.  Somewhat surprisingly, I don't have an orchestra in my basement, so all the tracks had to be created digitally.  I wrote five of the twenty tracks in the game, the remainder came from a mix of outsourcing to Symphony of Specters (they worked on Castle Crashers, among other things), and a group of composers from the exceptionally talented Renoise community.  The Renoise composers contributed their songs effectively for free (I hosted a small competition with a few prizes), and I was blown away with the quality, community spirit, and overall generosity of this group.

Now while I'm not a professional, I should point out that I do have a background in music, which does make things much easier for me in this area.  I've had formal training in piano and classical guitar, and have been composing MOD music for years as an extremely remote, essentially non-existent member of the demoscene.  So naturally I write music in the excellent, tracker-style program, Renoise.

This article will be discussing how I approached writing music for the game, which you can learn about more in the following video! 

Obviously there's no right or wrong way to create a song, and truthfully the method I use changes depending on the style I'm working on.  But, this is the approach I took for this particular song, so maybe you will find it helpful.  To summarize the video, the steps I took are:

1. Establish the mood of what you're trying to create.  Have that in the forefront of your mind throughout all the next steps. Ask yourself, does this fit?
2. Create the rudimentary elements of the song. For the song in the video, I created a motif (in the video I call it the "theme") and a melody.  I generally just use octaves in the left hand and single notes in the right hand to keep things simple at this stage.
3. Add more complex musical elements, starting in the middle of the whole song.  Put together a single bar that has all the components and instruments you want.  If the bar never sounds right, go back a step and work on the basics again. Once that bar sounds correct, now write the beginning of the song and work up to that bar.  Then create variations on your original concept to finish off the song.
4. Finishing touches. Listen to the song front to back a few times.  Vary the percussion, fill in gaps that sound empty, and pull back areas that are too cluttered. If you've listened to it 10 times over the course of a few days and it still sounds pretty good, then you might just be done!

I'd also like to briefly touch on another important element of finishing up your song which is audio mastering.  The basic premise is just to take the music you have already written and make it sound better.  Again I am no professional here, but I can give you a few rookie tips to make your song sound more put together.

1. Panning. This is using stereo to make your song sound more full. Put some headphones on and start placing some instruments a little to the left and others a little to the right. Imagine an orchestra in your head. They're all in front of you for the most part, but the group of violins might be sitting off to one side, the cellos on the other. Emulate this in your song. Adjusting panning can sometimes disturb the instrument volumes you have carefully set, so you might want to keep an eye on them during this process.
2. Equalization. This is adjusting the low, mid, or high frequencies to fine-tune the tone of your song.  Depending on how much control you have over the samples, you might not need a lot of equalization. As a general rule, I try to use equalization to remove noisy and cluttered frequencies rather than boost areas that sound too thin.  If it still doesn't sound right after this step, I might go back and change out the instrument used.
3. Compression. This is taking the quiet parts of your song and making them louder, reducing the overall dynamic range of your song to make it sound loud.  My rule of thumb here is to not compress very much.  The reason being that you still want loud parts to sound big relative to the quiet parts.  I usually compress if I find myself wanting to adjust the volume while I'm listening to the song.
4. Limiting. This is preventing the occasional extra-loud bits in your song from causing distortion by clipping the amplitude peaks.  A limiter will also let you maximize the volume of your song by boosting the input before the clipping occurs.  My rule here is to try and minimize the amount of clipping. You only want a few anomalous blips and blops to be clipped, not a whole loud section.

So that's my process! Writing music is by no means easy and there are a lot of professionals out there who can produce simply amazing results.  But when you're on a budget and can manage with something simple, hopefully the above tips will help you out.

If you want to listen to the soundtrack, you can hear it all for free or download a full quality digital copy for only $7 at http://tacticstudios.bandcamp.com.  Since Immortal Empire is browser-based, the in-game music was significantly reduced in quality to keep the download size small. The soundtrack of course is mastered at full CD quality, and boy does it make a difference! 

Whether you're a professional composer or an amateur, I'd love to hear any stories you might have with writing music, so feel free to comment below!

How to get sound effects in your indie game without being a professional.

I'm not a sound designer, but I need sound in my game.

This is part 1 in a series of articles describing how I approached each aspect of creating Immortal Empire as an independent developer. You can read the whole backstory here.

When it came down to adding sound effects to the game, I started down what seemed like the most logical path for someone who is not a sound designer.

"I have the power of the internet. Everything is on the internet! I'll just snoop around and download royalty-free sounds," I thought. Sure enough after hours of searching, I found very few useful sounds even in paid catalogs.  The style and timbre of the sounds were inconsistent, sometimes too long, sometimes too short, sometimes just not the right type of effect at all, and it took forever to sort through miscellaneous bits of audio.

So what now? The internet has failed me. Well, I did what I must. Time to try making the sounds myself! I borrowed a Zoom H4N hand recorder from a friend, and was introduced to the fascinating world of foley art. Put simply, it is recording yourself banging stuff around until it sounds like you want.

It sounds (hoho - pun) like it would be more work, but for me, this was actually much easier and a lot more fun. I was astonished at how simple objects just lying around my house could be used to create the sound of equipping weapons, or throwing a dagger. Recording the audio myself, I had full control over everything. I could do as many takes as I wanted, get the right tone, length, volume, and keep the audio style consistent.  It actually worked out really well.

Of course, I filmed some of my adventures.

If you watched that video, I know what you're thinking. "You use Cool Edit Pro from the year 2000?" Why yes, yes I do.  If you didn't watch it, to summarize the video, here's a few things I found very useful when recording my own audio.

1. Keep trying stuff.  Sometimes what you pick up at first might not work. But, you'd be surprised how easy it is to just grab 20 objects, try them all, and find a great, useful sound you weren't even expecting. I picked up a stainless steel pot for armor sounds, but found it could very easily make sword sounds as well.
2. Do lots of takes. Hit the objects differently. Holding longer, scraping sideways, hitting harder, rattling it a bit, things like that. I did about 15-20 takes per type of sound. It's simple to just listen to them and pick the ones that turned out best.
3. Combine sounds. The bow equip sound is me dropping a wooden dowel, while plucking an elastic band, and ending with a thump from a wooden block. Blending sounds together, including directly overlapping them, is a great way to get a different overall sound. I can't tell you how often I blended in the sound of me punching a phone book into other sounds to give them more "oomph"

A note on the audio for spells. Some of the more physical-based spells were recorded using the above process, but the more magical ones often required tones I wasn't able to produce with household objects. In these cases, I called upon a gigantic library of samples I have been collecting over the last 20 years for the purposes of writing MODs (and their various successors). That includes a mixture of ripped stuff, some downloaded samples, and sounds I recorded from various synths I've been fortunate enough to use over the years (A Roland Juno-2, Yamaha PSR-300, PSR-730, and CS6X)

I mention in the video that I didn't create all the sounds myself, and that's true! So I want to give credit where it's due. My friend George Spanos is a professional sound designer and author at gamesounddesign.com. He's who I borrowed the hand recorder from (I have since bought my own) and he also contributed a lot of fantastic audio for the project, in particular for a bunch of the monsters.  So while this article is about doing things on your own, which is often necessary for an indie, it is of course incredibly helpful to have a few friends that can assist you with your project. Thanks George!

Hope you enjoyed the article! Myself and any readers I'm sure would love to hear your experiences with sound design, so go ahead an comment below!

To try out Immortal Empire, visit the website, or play on Kongregate.

I'm not a sound designer, but I need sound in my game

This is a recurring problem I encountered when developing Immortal Empire, a strategic role-playing game by my company Tactic Studios.  It required a lot of content to develop this game, and with few resources at my disposal, much of it had to be created by myself. The problem being of course, when it comes to certain fields like sound or art, I'm no professional. So I had to figure out something that would work.

This is no doubt a common situation among independent developers like myself, so I'm writing a series of articles sharing how I approached each facet of game development for Immortal Empire, and ended up with a finished game. Hopefully this will be useful for other indies who, like me, couldn't rely on professionals for everything.  The topics I will be covering are:

• Sound Effects
• Music
• Art
• Design
• Code
• Quality Assurance
• Business Development

It might be useful to know a bit of information about myself and the game I developed. Immortal Empire is a throwback to mid 90s PC games when 320x200 resolution and 256 colours was the gold standard. Inspired by games like X-Com, Diablo, and Dota, it is a multiplayer, strategy-based role-playing game.  All the in-game artwork is hand drawn 2d pixel art, displayed in an isometric view.  It has a fully digital original soundtrack, co-op, single player, versus mode, the whole bit.  Everything is crammed into a web-browser and it is playable across Windows, Mac, and Linux.

My primary background and education is in programming, having worked professionally as a programmer in video game development for the past 8 years on larger games and franchises such as BioShock.  In my spare time I wanted to develop games on a smaller scale, to keep up my coding chops and because it was fun to create the types of games I played when growing up. 

This series of articles is meant to shed some light on my experience with this process, with the aim being that hopefully other developers in the same situation can benefit from the lessons I learned and apply them to their own projects.  If you have any stories to share, professional or amateur, about your experiences with the topics I'm covering, please comment! I'm sure myself and other readers would love to hear your perspective. 

Now onto the articles...