March #1GAM Entry: The New Worlds

I did it.

I thought I had a design that was a bit too ambitious, but I somehow managed to finish my March entry for One Game a Month.

“The New Worlds” is a space exploration game. Your homeworld’s star is known to go nova eventually. Evacuating everyone is the only option, and evacuation is expensive. Explore the universe, set up bases on suitable planets, and increase the wealth of your homeworld before time runs out.

Download The New Worlds for Linux 64-bit (547 KB tar.gz file)
UPDATE: A 32-bit Linux version is available now. Download The New Worlds for Linux (543 KB tar.gz file)

I’ll have to write up how it all happened later, as I’m rushing off to see family this weekend. I had to cut back on features, such as setting up trade with alien civilizations.

There’s still at least one major issue with the game play. It’s entirely possible to run out of fuel and supplies and have the game continue to run even though you can’t do anything. You can’t go anywhere. You can’t wait to die. You can’t scrounge for supplies as it was a feature I didn’t have time to add even though I really wanted it.

I want to come back and address this issue, although the next time I touch this code I’m sure I’m in for a shock. It’s horrible and ugly and I hate myself for writing it. B-)

Still, it’s playable, and it’s possible to lose and win. And it is fun exploring and trying to survive in the universe.



Jumping Into The March #1GAM Project

Last month, I finished my One Game a Month February project on the last day, just in time to submit it and get credit for it. Whew!

February’s project was made in almost 12 hours of actual work throughout the month. That is, for about 3 hours per week, I was able to hack a game together. What surprised me was that I didn’t need a huge block of time to get something substantial accomplished. I thought that 45 minutes was the minimum amount of time I needed to concentrate and get my bearings before writing or changing code, but some of my more productive game development sessions weren’t more than 15 minutes in length.

For March, I know I am capable of throwing something together quite quickly. I’ve spent a little over four hours so far on game development this month, and while I’m worried that my game design might be a bit too ambitious, I’m pleased with the results so far.

March’s game is “The New Worlds”, a space exploration game. You’re tasked with discovering interstellar resources to bring back to your homeworld to get everyone off of the planet before the sun goes nova. Hopefully you can find a new home for everyone as well.

Along the way you might discover planets that are already inhabited, and you can setup trade. As you increase the wealth of your homeworld, your ship can be upgraded to allow you to travel farther and faster with more passengers.

Here’s some in-progress screenshots over the last ~4 hours of development:

A random star field.

March #1GAM

Some random solar system. I changed the background from black to a purple-ish hue as I found it was a bit easier on the eyes.

March #1GAM

More planet variety, and clicking on a planet sends your ship there.

March #1GAM

February #1GAM Entry: Electomagnetic Play

I managed to put my February entry for One Game a Month together mostly in the last couple of weeks, sometimes with only 15 minutes at a time to dedicate to working on it. It’s amazing how much comes together in 15 minutes.

Electromagnetic Play is currently only available for 64-bit Linux as I wanted to get it in under the deadline. I’ll work on ports later when I have some time.

Download Electromagnetic Play for Linux 64-bit (1.5MB tar.gz file)

A quick description of the evolution of the game.

I thought of having magnets that you use to move metal balls around an arena.

February 1GAM

Eventually I decided on a simple game in which you have to catch the balls in a metal bucket, and you can only move the bucket by charging magnets on either end.

February 1GAM

Once I had balls dropping and magnets charging when you clicked on the green buttons, I had something that was basically finished.

February 1GAM

Add some scoring and lose conditions…

February 1GAM

…and tweak the challenge a bit by level, and we have a game.

February 1GAM

I Have a Day Job Again

“You don’t know what it’s like out there! I’ve worked in the private sector. They expect results!” – Dr. Ray Stanz

I’ve been meaning to write about this topic for some time. Back in May of 2010, I put in my two weeks’ notice at my day job.

At the time, I wrote:

So why walk away from that? Because I’m also cutting myself off from an obligation to be anywhere for 40-60 hours a week. Those hours are mine now. I have the freedom to use them however I want. Instead of being a cog in an otherwise pretty great wheel, I’m making my own wheel.

Of course, with that freedom comes great responsibility. I’m solely responsible for the success or failure of my business. My future income depends more on my marketing, sales, creativity, and productive output than the time I spend sitting at a desk. It’s going to be hard work, and I’ll encounter challenges the likes of which I’ve never seen.

My burn rate said that I’d have enough savings for one year. Thanks to living in a city with a lower cost of living, the stipend I get as President of the Association of Software Professionals, and the support of my girlfriend-now-wife, I was able to last until 2012 before I needed to seriously look to supplement my income.

My income was near non-existent, though, and I should have been focused on supplementing it way earlier. You can do a lot of things wrong, but so long as you have sales/cash flow, you can live to tell the tale. If you don’t have cash flow, you can’t survive. I waited too long, unfortunately, so after having some contract PHP work disappear out from under me and realizing that I didn’t really have the network of support to find game development work easily, I once again took a full-time job.

I should do a full post mortem on my full-time indie attempt, but for now, here’s the highlights.

When I started out full-time indie, I probably spent too long figuring out what to do with my time. Eventually, I got into a structured daily routine of work. Things were going to be fine so long as I spent my days being productive. Get up, exercise, get some game development done, write a little, repeat the next day.

Unfortunately, I didn’t ship fast enough. My flagship game, Stop That Hero!, wasn’t officially released until a year after development, even though I thought it would be a one-month project at first. Even though I knew not to focus on technology and to focus on the game, even though I knew I should focus on getting to a positive cash flow as quickly as possible, even though I knew better, I still did the exact wrong things. While I had a good flurry of support from the pre-order, the sales are very low and aren’t going to be covering a regular meal, let alone mortgage payments.

Clearly what I’ve been doing isn’t working, but what was I supposed to do next? How was I supposed to turn things around?

Anything I spent my time on that didn’t bring in money felt like the wrong thing. I was feeling a lot of stress. Towards the end, I found myself somewhat paralyzed. Planning was important, but planning wasn’t action, but action for action’s sake wasn’t working. I could spend time learning a new development platform, but that would still mean no published games right away, but if I took time to plan I could figure out a way forward but who has time to plan? I know one hour of planning saves three hours of work, but if you only have mere hours left, you want to make them count. But that brings me back to trying to move forward while also trying to figure out which direction forward is. Gah!

I was disappointed, but I also felt like I was letting a lot of other people down. I’ve had a number of aspiring game developers tell me that I was an inspiration to them. My wife reminds me that I had a good couple of years worth of trying which is more than most people give themselves since they never make the attempt. She’s right, but it’s still hard to think I had an opportunity and lost it.

These days, it’s a lot less stressful not to worry about how to spend my day, wondering and second-guessing if I’m making the right choices in order to make a living. I’ve reintroduced that 40-60 hour week obligation, which means everything else in my life takes a backseat, but for the last few months, I’ve been able to breathe a bit more. I could take some time to reassess.

When I was hired, I made it clear that I fully intend to continue work on my business. It would have been a deal-breaker for me if I they were going to insist that I couldn’t as a condition of employment.

Now the trick is making time for my business outside of the day job hours while balancing the rest of my life. But I’ve been here before, and being on the other side of having a full-time business, I have new insights. I understand more fully the lessons I thought I pre-learned. I understand the game development industry just a little more.

So I’m not done. I’m going to live on. I’m going to survive.

And while there’s plenty of advice on how I should go about doing it, while there’s no shortage of people who can say that I should have focused on Facebook or mobile or free-to-play or Flash or HTML5 or Unity or Windows or any number of business models, platforms, and tools, I know I’ll find my own way. I’ll make my own rules.

In some cases, the consequences are heartache and failure that could have been avoided had I listened to someone else.

But I didn’t go into this to follow someone else’s lead. I’m not doing this to be like everyone else or make games like them.

I’m an independent game developer. I define my own success.

January #1GAM Entry: Walls and Armies

I’m in crunch at the day job, and so I didn’t have weekends like I had hoped to work on a game project. Luckily, I had finished the design of this two-player card game, and it counts. I call it “Walls and Armies”, and the rules are below.


Take a standard 52 card deck of cards. Remove the jokers from the deck and leave them out of the game.
Shuffle all cards into a main deck.

For each player:

  • Determine how many “walls” and “army” cards you get. For each type,
  • Flip the top card from the main deck to determine the number of cards to deal
  • If it is a face card (Jack, Queen, King, Ace), then place that card down in front of the player face-up and sideways to indicate that it is a “shield”.
  • If it is a number card, discard the card and deal the indicated number of cards face-down in front of the player. For example, if the top card was a 3, then discard the 3 and deal three cards.
  • The wall cards and shield cards are laid out individually in front of the player. The army cards are placed in a deck, and the player should not look at them.

The first player is the one who has the fewest wall cards, or if tied, the one with fewest shields, or if tied again, the one with the fewest army cards. In case of a tie across all three sets of cards, flip a coin.

For each player:

  • Pick one of the opponent’s wall or shield cards to attack, then flip the top card from your army deck. If the target card is face-down, flip it over to reveal it. You cannot attack wall cards until your opponent’s shield cards are eliminated.
  • If your card is higher, then discard both the target card and the army card.
  • Otherwise, your opponent can choose to leave it alone or counter-attack:
  • If left alone, you may stack your next army card on top of any of your in-play army cards, adding the number of the armies together to attempt to eliminate the target card.
  • Your opponent may choose to counter-attack by playing one of his/her own army cards.
  • If the counter-attack is higher than your army card, then the counter-attack is discarded, and each of the stacked armies are added to the opponent’s wall cards.
  • Otherwise, both the counter-attack and the stacked armies are discarded.
  • Repeat until you run out of army cards.
  • Replace all face-up shield and wall cards with face-down cards.
  • Replenish your army deck by flipping the top card from the main deck. If it is a face card, add it to your shields. Otherwise, deal yourself the number of cards indicated into your army deck.
  • Play continues until either player has run out of wall cards. The other player is declared the winner.

12 Games in 12 Months #OneGameAMonth


It’s mid-December, which means people are remembering their New Year’s resolutions and rushing to accomplish them before 2013 rolls around.

Last year, I managed to release the Stop That Hero! alpha after many months of delay. This year, I similarly managed to get the next update out a few months ago after many months of delay, and it still hasn’t been ported to the Mac. Otherwise, I have a couple of Ludum Dare games under my belt. One of my aspirations is to be a prolific game developer, and this is not a good track record.

Ludum Dare has three main compos during the year (one is this weekend!), but each month in between features a miniLD with custom rules by whoever is hosting. I have been considering making it a goal to participate in each of these miniLDs if only to get 12 games in any given year.

Chris Kaitila, aka McFunkypants, wrote 12 games in 12 months about his experience in the last year attempting to make at least one game a month, so it seems I’m not the only one with such aspirations.

I set out this year to prove to myself that not all game projects need to stretch on for months or years. It was a battle against the featurecreep and code bloat that I’d suffered from for years as an indie gamedev. I’ve started so many more games than I’ve finished in the last 20 years.

From assembly language “hello worlds” to BASIC choose-your-own-adventures without an ending. From to Turbo Pascal Tron lightycles games, to Visual Basic prototypes so woefully buggy and half baked they weren’t even worth backing up. From unpolished (but complete!) C++ openGL shooters with only one level to Adobe Director (shockwave) horse-racers with no finish line. From php sports simulators with broken AI to html4 multiplayer chat worlds with server problems.

Looking in my Projects directory, I see that my unfinished 0h Game Jam about a horse race with no finish line. Hmm.

Now, Kaitila has a broader range of experience with tools and engines than I do. I could probably stand to get outside of my C++/SDL comfort zone, but the risk is taking the time to learn something new versus using what I know to work on games.

But he found that it’s easy to get sucked into a never-ending project, one that quickly stops being fun to develop, and so becomes one that never gets finished. I’m sure we’ve all been there. There’s a lot of discipline involved in game development, which isn’t obvious to anyone who hasn’t done it before.

So what can you do? Reduce scope! But feature creep is always a problem. Set short deadlines! But projects always have a way of taking more time than you planned.

Kaitila’s answer to both: game jams.

Instead of getting involved in a long marathon of game development which might force you to choose between your health/family/friends and your project, you run little sprints. Ludum Dare’s 48 hour compos and miniLDs are perfect. There are also other game jams throughout the year, such as Meaningful Game Play Game Jam and 0h Game Jam held during a missing hour due to Daylight Savings, so there are plenty of options.

Like daily workouts, each game project made me stronger. Faster. Better.

You can do this too. Challenge yourself to make a game a month this next year. Let this be your new year’s resolution. I’m going to do it all again in 2013. One game per month, on average, and a dozen finished products by the end of the year.

I’m issuing a challenge to all my gamedev friends: join me in the epic quest. It CAN be done. You don’t have to be hardcore, insane, or obsessed. Join me in the gameamonth challenge. We can help encourage each other.

If you have a Twitter account, you can sign up for the One Game A Month challenge. It’s like a game for game development. You get XP for each new game you post, and people who sign up before January 1st get 100 early adopter bonus points.

I’m in. Are you?

LD24: Evolution Game Post Mortem #LD48

My last few Ludum Dare entries have missed the main compo deadline and had to be submitted to the Jam, but my entry for Ludum Dare #24 was finished in time to get judged along with the other 1,000+ entries. That was a big win for me, since my game development in general has felt quite slow.

The theme for LD24 was Evolution, which always makes it to the final round and has never won as a theme until now. I ended up creating a simplistic side-scrolling shooter. It definitely wasn’t my best entry, but health problems made it difficult to do better in the 48 hours.

What Went Right

  1. Leveraging existing tech

    Since LD#18 (“Enemies as Weapons”), I’ve been slowly building up a game engine for Stop That Hero!, my casual strategy game that lets you summon minions to fight heroes who want to put a stop to your evil empire. As I am using test-driven development to work on that game, I ended up with code that is relatively loosely coupled and cohesive. It was quite simple to gut out the STH! parts and leave behind a way for me to immediately create a menu, game play screen, and ending. Instead of spending the first six or twelve hours trying to get an SDL window to shut down properly, I could concentrate on more important things.

    My engine isn’t super powerful. People using Unity or Flash had a huge advantage since so many components are fully-formed and well-designed. Still, I had code that I was able to use in multiple games, and I knew how to use it. I was able to put together my game fairly rapidly.

  2. Better familiarity with tools

    My art program of choice is GIMP. While I’ve been known to doodle on paper since I was a child, I haven’t been very practiced with pixel art or image manipulation. I don’t know how to do 3D modeling very well, but if I did, I would use Blender.

    Over the years, I’ve learned how to use GIMP to create some decently functional art and ads. Selecting shapes, making use of layers, and knowing how to manipulate color goes a long way. What I create is not production-quality, but it works for an LD48.

    Evolution Game Play

    Sound effects were made using DrPetter’s sfxr. Even though it is really easy to use if you just want to generate random sound effects, knowing how the various parameters can be tweaked helps a lot in getting an effect to sound just right.

  3. Iterating fairly well

    My biggest victory came from iterating, even if I could have approached it more intelligently.

    After working out some ideas on paper, I had a basic design for a shooter.

    Initial Design of Evolution game for LD#24

    I wanted the controls to be simple. I came up with some different ways for how enemies would evolve, as well as ways the player’s tank might evolve.

    I wanted different kinds of enemies that came in different sizes, used different movement patterns, and attacked the player in different ways. I even had an idea for a boss character.

    Design Notes of Evolution game for LD#24

    I also thought of Evolutionary Upgrades, aka Power-ups, for the player. Some impacted the tank’s weaponry, such as a spread gun or homing missiles, while others affected the tank’s size or armor.

    Design Notes of Evolution game for LD#24

    Once I had an idea of the kind of game I wanted, I set to work. My initial list of tasks:

    – get the player’s character in the game
    – make it controllable
    – add obstacles (most likely boulders)
    – make collisions between the player and obstacles deadly
    – add an enemy
    – create a wave of enemies
    – create a way to modify the wave of enemies so each enemy evolves in some way

    First, I got a scrolling background. In hindsight, maybe this part could have been left until later. My next goal was to get a controllable tank on the screen, complete with the ability to fire bullets. Having something controllable that early meant that throughout the development of the rest of the game, I could get a feel for the controls. As the game came together, the tank’s controls were updated a few times. I originally had the tank’s movement a bit slow to accelerate, as switching a tank’s directions is probably really hard, but I found it was more annoying than fun. It felt too sluggish. I made it more responsive in the end, and it was better for it.

    Next, I added boulders, followed up with collision detection between the tank and boulders. Now tanks have to avoid obstacles, making the side-scrolling environment a bit more maze-like. In terms of the theme, however, perhaps these obstacles were not the best thing to add earlier, although I did have plans for enemies to interact with boulders by pushing them toward the player if they collided with them.

    Finally, I added killable enemies. The enemy was pretty basic. It moved in a straight line toward the player, didn’t attack, and moved through boulders.

    I realized that I was not going to get all of the enemy types and upgrades in, so I focused on making sure what I had was as finished as I could make it. I added enemy waves, which added more enemies and made them harder to kill as the player progressed. I added a score so you could see how well you’re doing, and I even had time to make some points visibly pop up when you kill an enemy. That last bit was a small aesthetic change, but I think it polished the game up quite nicely. Great bang for buck.

    Now, there are some things I spent time on that I could probably have left until later. The scrolling background wasn’t really necessary, was it? And the enemies were supposed to be the main focus of the design, so why did I work on boulders first? I definitely could have prioritized much better.

    Still, what’s key here is what I didn’t spend time on. I didn’t spend time making tank upgrades, which is good because I didn’t have a need to upgrade the tank. I didn’t spend time making lots of enemy types, which is good because I didn’t have the time to intelligently figure out how they should be introduced. I didn’t spend time to figure out boulder/entity interaction, which is good because who knows if it would have added anything?

    By getting something playable and iterating, I was in a position to reduce scope to finish the game by deadline. Along the way, I almost always had something playable that I could submit by the deadline.

What Went Wrong

  1. Dealing with Back Pain
  2. Shortly before the theme was announced, I was working to get the next release of my casual strategy game Stop That Hero! out the door. Between that project and my responsibilities as President of the Association of Software Professionals, I was sitting at my desk a lot, and it was taking its toll on me. I could feel some tightness in my hip, and so I decided to try to setup my environment so I was standing more.

    I placed a container under my keyboard, and it was raised to the perfect height to let me stand while I work. Everything was great, until I had to use the mouse for some reason, which was still on the desk. I leaned to the right to reach for it, and I didn’t realize I was going to be mousing like that for long. Standing in such an awkward way, coupled with the tightness I was experiencing from sitting for so long for days on end, I ended up with some very, very annoying back pain.

    The Friday before the compo, I went to a massage therapist since I figured it was just tightness that needed to be massaged away. After the compo, I went to a chiropractor because it clearly wasn’t getting better and in fact felt worse.

    But during the compo, I was taking a lot of breaks. I could sit or stand for a period of time, but when the pain started getting distracting, I’d go lie down on my back for a time before I could start working again.

    I lost a lot of productivity to that pain, and I’m still recovering from whatever happened to cause it.

  3. Being Uncool

    My entry didn’t get a rating. It seems that in the time since my last LD, there was a change that if you don’t have a high enough cool rating, you don’t get a listed rating. As I was a bit busy and couldn’t dedicate the time to reviewing other games post-compo, I didn’t get many reviews done. Reviews translate into coolness. With over 1,000 entries, people aren’t expected to review everyone’s games, but there is an expected minimum you should rate. I rated a few immediately after the competition, but between not being able to play Unity-based games and having other priorities, I didn’t get back to it. My only listed rating is Coolness, and I was ranked #986 with a rating of 22% cool.

    There were quite a few 100% Coolness ratings, and those people are awesome. Or they just have a lot of time. Either way, I’m glad they exist.

  4. Doing a poor job of including the theme

    Evolution is always a contender for the finals of theme selection, and I was caught off-guard when it actually won.

    I could have tried to design something involving random genetic changes in entities and seeing which one adapts better to changing circumstances, but it sounded too obvious and also too open-ended. I wanted to try to keep my entry simple and straight-forward since I wanted to submit an entry to the compo instead of the Jam.

    While I had some design notes that I called “evolution,” such as tweaking variables to create new enemy behaviors and types, it really wasn’t evolving so much as creating variations, the kind of thing you’d see in any shooter and most games in general.

    Perhaps I should have thrown a few more ideas at the wall before settling on this side-scrolling shooter. My wife suggested the idea of an “evolving door” which has the benefit of being pun-tastic, but I couldn’t find a good way to incorporate it into my existing design. Judging by the variety of entries, I could have been a bit more creative.

What I Learned

  1. Iterate like you mean it. This is where Agile software development experience really comes into play. If you can create the simplest bit of value, and then build on it, you’re going to ship. If instead you build up scaffolding code to prepare to provide some unknown, vague value, you’re probably going to get mired in delays.

    In previous competitions, I’ve found that I didn’t introduce basic interactivity until a bunch of other things were ready, and I’ve suffered as a result. By getting something player-controllable right away, I was able to not only get a game around it much more quickly, but I was also able to make small changes to the controls until it felt right.

  2. Having good tools and knowing how to use them is great for productivity. To iterate quickly, you need to be able to produce functionality quickly.

    I used to try to create decent art, but between not having much practice and not being familiar with GIMP, I would spend way too much time on art, and in the end, it still looked really bad. I wasn’t getting the return on investment.

    Now, my art skills are still not production-quality, but they are passable, and I am able to create decent programmer art in minutes when it used to take me hours.

    Also, experience counts in general. I write way better code today than I did just a few years ago, and I do so much faster. I terrify myself when I look back on earlier Ludum Dare compos and read through my code.

  3. I need to take care of myself. Up until the compo, I had been doing yoga and taking regular walks. However, poor posture in front of the computer and sitting for way too many hours at a time in those postures did me in. It’s over a month later, and I’m just now feeling fine enough to start stretching and taking walks again. Maybe I need to seriously investigate the standing desk option and even look into a much better office chair.


If I could do LD#24 over again, what would I do differently? I’d spend more time upfront trying to create a design better suited for the theme that is also simple enough for me to make. I’d make sure my list of tasks was prioritized so that at all times I was working on implementing something that served the core design. And I’d make sure that I had set aside time after the compo and Jam to rate other games. People worked hard on their entries, and with over a thousand of them submitted, it’s unfortunately easy to get buried. I think the coolness rating does a great job of making things fair, and the name is perfect. I want to be cooler next time.

Being able to get a game submitted is still a great feeling, though. In 48 hours, I created a game where there once wasn’t one. Next time, I should hopefully be healthier and able to focus more on game development, and my next entry should be not only minimally complete, but actually enjoyable to play. I’m still aiming for getting #1 in the Overall category, and while it feels like I’m a long way away from challenging other entrants for that position, I’m definitely way closer than I was when I was participating in LD#11 four years ago.

How did your LD#24 go?

Join Me in the Weekly GBGames Game Dev Co-op Hour

Last week, I decided to try something new. Every week, I’ll do an hour of game development in a Google Hangout, and you’re invited to come along.

Synchronize Your Watches

What: Weekly GBGames Game Dev Co-Op Hour, an hour of game development with you, me, and anyone else who shows up.
When: Every Wednesday morning at 6:00 AM (Central Time) for an hour.
Where: In a Google Hangout. The link will be posted on Twitter and on my Google+ profile a few minutes before the hour starts.

It’s a bit early here, and depending on where you are in the world and your schedule, it may or may not be convenient for you, but I hope you’ll join me. We can discuss game design, talk about what you’re working on, or simply work silently together. I see this weekly hour of public-facing work to be an opportunity to connect with other indie game developers. We’ll laugh. We’ll cry. We’ll become better game developers.

Do you plan to attend the Co-Op Hour?

The Third Ludum Dare October Challenge

Ludum Dare was originally a 48-hour game development competition. Given a theme, you have 48 hours to create an entire game using no pre-existing assets. In recent years it has grown into a huge phenomenon, expanding into a dual-event that occurs three times annually. There are also Mini LDs each month between the major events. And of course, there’s the awesome community that drives it that seems to get bigger and bigger.

Two years ago, PoV launched The October Challenge, which pushed developers to do more than simply create a game. Your task for this challenge was to take your game project, finish it, and put it on the market before the end of the month. Then, when you’ve earned your first dollar, you’ve completed the challenge.

The third October Challenge is here, and it’s a good opportunity for you to learn what it takes to “go pro” in game development.

When the first October Challenge was announced, it came at a perfect time for me. I had recently quit my day job to go full-time, but I had no real plan for how to proceed. I was thinking about how much time I should spend on any one game. Do I try to release lots of small games over the next year, or should I concentrate on making one or two really great games? I didn’t want to churn out crap, but I also didn’t want to put all of my eggs in one basket. After all, I only had so much savings, and the larger the game, the more time I would have to spend on it, which meant the more money I’d burn through. Where’s the optimal balance?

It was also immediately after August’s Ludum Dare #18. The theme was “Enemies as Weapons” and I had created my most ambitious LD48 game, “Stop That Hero!”

I really liked what I had come up with, even though it took me 72 hours to finish so I had to submit it to the LD Jam instead of the main compo, which meant less people played it. Still, the feedback was pretty good, and I was already thinking about polishing the game up and selling it as my first major commercial project. The question was how long I should spend on the updated/better version?

The October Challenge helped answer the question for me. I had a month to finish the game and get it out there.

Unfortunately, I made some major mistakes. I completely rewrote the game from scratch, attempting to learn how to create component-based game objects. I had never written a full-fledged game architecture before, and I was using up a big part of my month building an engine rather than a game. I was trying to make it as data-driven as possible, which made it difficult to settle on a solid vision for the game. And due to my lack of progress, I hit a real funk that I couldn’t shake for awhile. You can read more about what went right and wrong in the Stop That Hero! October Challenge post mortem.

I was determined to sell my first copy, but it clearly wasn’t happening that October. That month, 20 people submitted entries in which they earned their first dollar through pre-orders, ads, or sales. Over the next year, I continued to work on the game, and I sold my first pre-order and earned my first $1 on September 30th, 2011, one day before the next October. I’m still working on it, and you can try out (and purchase!) the current version of Stop That Hero! today.

It took a lot longer than I originally expected, but without this challenge, I don’t know how long I would have gone before figuring out my real strengths and weaknesses as a game developer. I clearly had a lot to learn, and I still do.

So if you’re interested in running your own indie game development business, I would highly recommend participating in this year’s October Challenge. There’s more to running a game development business than developing games, and this challenge is an excuse to find out what’s involved.

Are you participating?