At GDC, I heard a lot of conflicting advice.
Dan Cook suggested a broad portfolio to reduce risk, for instance, while other developers talked about focusing your energies on a single project or genre.
Whatever any one indie said, the one thing everyone seemed to agree upon was the importance of speed.
Dan Cook has written about the importance of quick iterations to “find the fun” as quick as possible.
Andy Schatz talked about the development of Monaco when he was almost about to throw in the towel on being an indie, and he advocated working on something exciting every day.
Use two hour game jams to explore game mechanics or designs.
Play-test early and often.
Create an MMO every day.
With Stop That Hero!, I already knew that things were going much more slowly than I would have liked, but the importance of speed really hit home during the Ludum Dare Jam at the Noisebridge hacker space on the last day of GDC.
My goal: create one simple, quick game every hour during the jam. I knew it was ambitious, but I wanted to try out this focus on speed.
In the end, I spent hours just trying to cobble together some decent code to use as a base for my first project, and I didn’t manage to finish it.
That’s not agile. That’s not speed. And that’s not good.
I struggle with my major project partly because I don’t have a base of code to leverage. Every time I need technology to support game play, I have to figure out how to implement it and fit it into my existing code. I never spent any time working with something like Game Maker or a game engine such as Quake or Torque, and since I do my development on GNU/Linux and want to be able to port to multiple platforms, there aren’t really any 2D engines available for me to work with. If I need some tech, I more often than not have to figure out the best way to architect it myself. My current pathfinding and navigation code is difficult to work with, for example, and I’m sure there is a better way.
Stop That Hero! might just be too much for me right now, and I might be better served by stepping back to work on smaller projects that don’t require AI, UI, or any other technology I don’t currently have. Also, I could probably do well to dedicate time to studying existing source code.
While part of me wants to muscle through and not leave my first major project unfinished, another part of me thinks I would do better building up my tech by creating smaller games around individual pieces. For instance, if I created an entire game around clicking buttons, I would have created my UI code AND have a finished game to show for it. On the other hand, I’d probably run into a lot of the same issues trying to finish a smaller game anyway, so why not continue working on the same project?
I really want to see Stop That Hero! get finished, but the ship date keeps getting pushed back, and the problem isn’t necessarily a matter of features that can be cut. The basic game requires a lot of moving parts which still aren’t created, so it’s not as if I have scope to reduce.
If I want to work and ship faster, I need to change something about what I’m doing. Either I need a improved technology base, which I obviously haven’t been able to create quickly, or I need to temporarily switch to a smaller, simpler set of projects.
How would you approach this problem? Would you try to use smaller projects as stepping stones to the larger project, or would you continue to work on the larger project, figuring that you would end up hitting the same obstacles and solving the same problems anyway?
This post was scheduled to be published at a time when I will not be able to access the computer. I’ll respond to comments when I return at the end of the month.