Self Motivation

I do apologize for immediately posting nothing at all. I have 3 or 4 draft posts which start with nice small snappy ideas, but then seem to simply spiral out of control and try to solve world hunger (though not very well).

My next post was going to be about self motivation, but it's really hot here, so I just went to bed instead. No AC kinda sucks. Eventually AC in europe may become rather standard, but only when the north sea is lapping at my feet... in the brendan hills.

So, despite suffering from heat exhaustion most of the day, and getting food poisoning yesterday, we're doing alright.

Tommy Refenes is the coder who works with me on our game. He was one of the engine coders at Streamline before we all decided to leave. He's just recieved all the hardware he needs, and is starting up a Subversion server so that we can code remotely. He's already got a basic DX9 environment going, along with a console and various input interfaces. The engine is also being built with multithreading in mind from the start. Some of the techniques we use could be called "brute force", relying on the nature of the target hardware. In many 360 games, there's a lot of processor power going untapped, so we're trying to be smart about how we process and pipeline everything from game play to sound to graphics.

I'm trying to get my head around some of the shader tech we'll be using and planning game code architecture. We use a wiki to document everything we work on, listing everything from game mechanics and algorithms to business plans and marketing ideas. I personally like to try to document everything I can about a game well before coding anything because it forces me to be intentional. It means that I can't just say "yeah, let's have kick ass feature #131516" without seeing what affect it will have on the rest of the game. It means that I won't code anything half heartedly, or without proper respect to the rest of the architecture (unless the name of the game IS experimentation and prototyping, in which case, anything goes).

Design documents change all the time, naturally, so we try not to look at the document as something that's set in stone. It's more like a repository of knowledge about the project, changing day to day, but helping us to maintain a united vision of the game (even if that vision alters over the development). Since it's a wiki, it's very easy to track each other's changes, and share ideas, text, images etc. It can also rather naturally guide the design of the code architecture (which is both good and bad, but basically comes down to how well you design software) and via "needed pages" can show you what areas need more elaboration before the design can be called "well formed". Damn I love my wiki!

One interesting thing I've encountered with wikis in the past is that although they can give a very detailed (albeit sprawling) specification for a design, it's very hard to communicate a higher level idea of what the hell the game is about. In other words, you can understand each individual component of the game, but it's hard to see how they bind together to make something interesting. As a result, I make pages which explain lots of emergent strategies made possible with the core rules. This gives a newcomer to the wiki lots of practical possibilities in the game, and explains how the core rules give rise to them.

At some point we'll open up the wiki for public scrutiny incase anyone is interested.

Pretty soon I should be able to start actual game play coding - I've been preparing all my favourite physics equations in anticipation, but most of the work will be in game play element management.