Homebrew Programming

Sometimes I write code at home. Often its a sample, example or fragment. Sometimes I'm working from or writing to a tutorial. Maybe I'm sharpening my skills and every now and then its recreational. Homebrew for me tends to be a quite polarised affair - its either VERY close to my day job, solving the same problem a different way or just exploring the problem domain - or its that I've chosen to tackle something that I'll never get paid to do.

And this is one of those times, except I've let it run away with me. I stated glancing at the code I've got scattered around there are classes for a simple physics integrator, some camera code, an input tutorial I wrote for somebody, maths libraries that date back to the 90's, some file IO and resource management. Left over from a previous project I've got some network replication and RPC code I wrote, and last Autumn I wrote a streaming perlin-noise landscape.

So it wasn't long before I realised I'd accidentally written a game - or at least most of it - piecemeal over the past few years. In fact, just adding a message pump and sprinkling it liberally with Dependency Injection provided a mulitplayer first-person sandbox I can use to write a game.

What I can't get over is how similar foresight and hindsight are when you are writing code. Knowing the author and intentions of each system in a codebase really helps, but believe me - you don't want to live in this guys code - or his head. On the plus side, he wrote a lot of code and quite a bit of software. It all 'works' and is an entire working games codebase with an example game sitting on the top - but some of it feels like legacy code rather than a lean games API.

Oddly though, the project is coming together - so much so that I can't put it down. Every now and then I open up the project and tinker a little further. Adding something small, contained and complete.

Each of these steps has been reasonably self contained and a brief retrospective revealed that I'd fallen quite comfortably into agile habits as I've bounced from feature to feature. The discipline is getting each step "just working" with minimum effort, regulated by user-story based production.

At each step I've started with the Statement "I want feature X so I can get result Y" and attempted to follow the shortest stable path from here to there.

Agile does make programming games even more fun, and I've never had a satisfying goal further than arms-reach away. After sprint four, I realised I was cherry picking items from the backlog rather than taking the highest priority item so sprint five was a backlog-clearing exercise of assorted odds and ends that I had been avoiding. The few sprints since then have been quite clear sailing, and the empowerment of always doing something important combined with constant drip-feed satisfaction keeps momentum quite high. I'm now finishing Sprint thirteen, with a large product backlog to choose new features from and invaluable feedback from a couple of players.

By working in a free, almost goal-less manner, I've scored more goals than this metaphor makes sense. I've gone from a single rendered triangle through to a 3D world made of bricks where you can construct and shape the world in a first person perspective.

Watch this space. Its evolving.