This is my first hub. A hub is basically a summary of a long series of posts covering a topic, in order, with links to the posts. There is a link to this hub on my Game Design Hubs page.
This is regarding my progress on my once and future company’s mech game in the making.
First, in Dozer, I noted that a side project of mine, Dozer 2, took far longer than I expected to get to its halfway point. I considered the financial viability of indie games in terms of a work/profit ratio, and proposed that our current plan, as it is, is a Bad Plan.
…my personality type is such that I cannot be effective unless I find a path I can define. So, harsh as the numbers are, the XBL Indie Market is a godsend for me. I just need to find that happy place where I can make a living at it and keep it growing.
I need to make this work. In the next year it has to function, in the next five or six it has to be outright successful, or else it will be stealing time and money from my peeps for no return.
Dozer 2, if I were a one-man operation, is in the aforementioned happy place, since I can build off of it in like manner to RadianGames. My financial needs are not as great as his at present, which gives me the potential to build a foundation upon which to grow.
So, how do I stay true to course, instead of wandering all over the map and spewing vaporware? Well, to answer the question, in Simplicity and Complexity, I try to turn the elements that make up the time of constructing a game into a mathematical formula, the better to perform a rough cost/profit analysis.
This is tricky, because our non-programmers (and often as not, programmers) don’t have a good idea of what is complicated and what is not. Greg once suggested a game where you just run by alternating the triggers on the game pad, and various super-hero battles take place around you and you can affect how they play out by how you run. The gameplay is simple. But … [w]e’d be spending a couple of years on a very “simple” game.
In So what now? I broke down my entry in the Code-Off, wherein we decided I would be head programmer for this project, and subjected it to my formula. My formula proved accurate — which in and of itself doesn’t mean much. Any theory can successfully predict the past. The real test is whether it can predict the future.
I then hypothesized a simple form of our mech game and predicted its length. I mistakenly assigned it a time factor of a year, but the proper calculation was about three months.
To stay on course for the mech game, we need to break it down.
… yeah, the quote is lame. Give me a break: most of the post is math.
In Organic Game Creation, I lay down the foundation for my proposed method for making the mech game: take an element from it. Turn that element into a game. Take another element. Turn those two elements into a different game. This is the formula that allowed Radiangames to take a place on the indie game scene.
[I]nstead of spending 3-4 months on a basic mech game, or 6-18 months on a more complex mech game, with no pre-existing experience except for ‘Dozer, a game I made more than a decade ago, why not release a game a month, with each game moving in that general direction?
In The Seed, I make a quick Space Invaders game design that can be our seed game.
My first day of working on Seed, I got an input manager, a model and physics manager, and most importantly, a fancy-pants particle system using an array of singletons with a common interface. That particle system is quite simply the foundation of the mech game, as it is the code that will allow us to have many different varieties of weapons. I also laid the foundation for a collision system that is full of awesome.