What Went Right:
1) The idea.†I was given the random variables of “Construction” and “Seeds”. In the first couple hours, I started out by going in some very different directions (including, somehow, space combat and zombie themes, both of which I rejected on principle). Once I started thinking about cellular automata and GM plants, though, the game finally started taking definitive shape. A primarily procedural system with room for complexity and natural dynamism was perfect for a game jam, I figured. Now that it’s done, I’m pleased that I went with a more original theme and system, and the basic resource-management dynamics work.
2) The technology.†I had started using Unity and 2D Toolkit two weeks before I began the project, yet I never felt like I was being slowed down by my tools. Plus, I could publish for the web, which was a major priority for a game jam.
3) The sheer effort.†It came down to the last few minutes, but I was able to finish in time. I slept a total of 7 hours over the entire 2 days, and there were several moments when I seriously considered just giving up on the competition and finishing the game later. Actually making the deadline was a triumph. I felt like the last person to finish a marathon: a little bummed, but mostly proud of having gotten there at all.
What Went Wrong:
1) The idea.†Picking a complex procedural system ensured that I could have some complexity, but it was like a wild beast that I was constantly struggling to tame. There were a lot of positive feedback loops that wanted to ruin the game’s balance (e.g. plants that would immediately kill everything on the screen, or immediately die off en masse, or be obviously optimal or suboptimal strategies), and I didn’t have the time to carefully adjust all the variables. In most cases, the various mechanics were either far too influential or had little influence at all. I had to cut several systems entirely due to…
2) The schedule.†I started out with a scope that was far too ambitious, which I understand to be a common mistake in a first game jam. I was constantly cutting and simplifying as I built the game, and despite that effort, everything I worked on took 2-3 times longer than I estimated. Worse still, the game required a fairly large amount of UI work, which is usually my slowest to produce. Out of desperation, I ended up re-using the art style and music from one of my previous games. In the end, I had almost no time to flesh out or balance the final product. The version I submitted to the competition was terribly unbalanced and featured a game-breaking bug after a few minutes of play.
3) The format.†I prefer working solo on small projects, but combined with the time pressure of this game jam and the “random variable” constraints, I think it worked against me. Without the camaraderie and teamwork that’s usually associated with in-person game jams, the extra pressures did more to limit my output than to squeeze it out of me. I don’t think this would have been such a problem if I had picked a much simpler game to make, but I didn’t, and it was.
I’m proud that I finished the game, but I’m not so proud of the game itself. I think my instincts were in the right place; the core of the game is successful and has a lot of potential, some of which was realized. But I know I could have done something better if I had started with something smaller and saved the bigger idea for some other day. If I want to do some rapid prototyping in the future, I’ll just call it prototyping, give myself a full week, and not worry about extrinsic constraints.