I've set myself a personal challenge; to turn around a game inside of 2 months, while also working full time. I've decided that over the next year (starting a month ago) I'm going to work towards being able to turn around a game inside of 2 months.

What has spurred this somewhat bold idea?

So far, I've always worked on one pie in the sky idea or another, and this has usually resulted in a fun, but fruitless, process and very little playable material. I spent no less than 3 years trying to produce something resembling GTA3 with zombies (grand theft zombie or similar), but while I was doing this, the industry was moving around me. If I can reliably turn around a game inside of 2 months, then i will be able to turn around a commercial game product given externally set deadlines. Or so goes the theory.

I've set myself challenges before, but these challenges have had far-future ending dates and uncertain goals. I know based on things I've done in the past that if I focus on something I can churn out a vast amount of not-terrible code in a short amount of time, even with a few arbitrary requirements. I've spent years studying how games are put together and can quite successfully teach others to do it, so why not do it myself?


The reward:

If I succeed within this dev cycle (allowing for things such as moving house at the beginning of july, ludumdare, hopefully visiting some family early next month) I will buy myself a 360 and pay the subscription for publishing XNA games. I've set my deadline for a playable prototype at August 19th, which is approximately 8 weeks after my start date on June, ignoring the week I moved house.

The litmus test:

My game has to have the following features:

Maintainable
The code has to be maintainable; not necessarily perfect, but I want to avoid my usual "object orgy" approach to programming; to this end I'm using a component based architecture. Although some would say that component based architecture is Object Orgy writ large. Rapid prototyping does mean that you can throw away a lot of code but i dont want to throw away ALL my code as this is very wasteful.

Playable
This is critical. the player has to be able to drive around the level, in pursuit of some goal, while being attacked by enemies. I've started implementing a very very basic system of seperation between semantically "engine" code and semantically "game" code. I'll do some cleanup once my goal is achieved.

Performance
I'm using c# and this produces some performance challenges which are outside of my usual comfort zone. I've given myself a slightly challenging goal - no allocations at runtime in normal circumstances (i.e. with basic level planning, I need to be able to avoid too many run time allocations). This is important on the 360 because the GC is not so sophisticated, having various performance issues not experienced on the PC platform. (every 1mb allocated triggers a full recursive mark and sweep). So far, I've used a limited amount of object reuse / pooling to overcome this problem. The ability to use structs (a value type in c#) for math and logic is critical here also and has helped considerably. On modern hardware, it seems that a copy of a small to medium sized value type is cheaper than dynamic allocation.

3D: Yes, the game is 3d. believe it or not, provided I have a reasonable bit of physics middleware, I'm just as happy working in 3d as I am in 2d. I've picked up the physics engine BEPU which so far, appears to be very well engineered, and most operations with it don't allocate huge amounts of shit to be collected by the GC.

Sound, music
Just the basics; placeholder artwork which is integrated properly with the rest of the world, thus demonstrating that I am actually capable of turning around such a system quickly enough.

Scripted events
A storyline is impossible without this. The initial prototype will consist of a scripted demo level, with hopefully about 10 minutes of gameplay.

I have a blog on tumblr documenting my progress here;


http://newoldstuff.tumblr.com/

I began my challenge in its current form on the 21st of June, the same day I wrote my basic lighting functionality for 3 directional lights. I'll be taking a few days out because of ludumdare on the 19th-22nd and so my final prototype should be arriving on the 26th.

Tonight I will implement my damage modelling system to accompany my projectile system (which took a few days but which I'm quite proud of because it works and its damn fast to boot).

[Edit] Oops, I actually started on the 21st

I wont be trying to sell the prototype - the whole point of the 2 month dev cycle is to eliminate my tendency to over-engineer everything. I need to be able to turn around a product in 2 months.

I'll no doubt keep a lot of what I do for the next phase (again, 2 months) and that product should be saleable. Bear in mind that I'm starting from scratch in a new language and dev framework. I cant go for a 6 month dev cycle and release something polished because there is a danger that I will fall back into my old routine of working for 18 months on nothing.

I think 2 months for a complete prototype/concept with fully fleshed out features is a good goal. But, along the lines of ChurchSkiz's thoughts, I think it needs to be followed up by another month or two of good polish and finish work.


Good luck.