FirstQuest Development Methodology Crisis

I am shedding another development skin.

My first solo game (working title: FirstQuest) is bogged down in 'engine development'.

Until now, I have been using 'enjoying coding' as a motivation tool to keep up momentum on the project.

This, coupled with the fact I enjoy systems engineering, has led me into the clichéd problem of over-engineering the game engine.

Looking forward to working part-time from September (having one day a week to work on games) has made me re-assess how I develop code.

I now intend to split 'play coding' and 'work coding'.

Work coding:
Stick to agile principles:
  • Develop only what is required to move the game forward.  
  • Keep code as modular as possible, but DO NOT engineer systems.  
  • Stick RIGOROUSLY to test-driven development - EVERY bug needs a unit test before fixing it.
  • During the one day part-time, ONLY do work coding.  Keep play coding for evenings/weekends.  (This should allow use of work velocities)
Play coding:
Just hack around to get something working quickly. 
  • I can explore, learn stuff, and produce interesting things.
  • DO NOT BOTHER with unit testing - it is not worth pretending this is work-quality code.
  • Have fun!  It doesn't matter if it all goes wrong!
 That is the plan.

Comments

Popular posts from this blog

Micro:Bit and SPI display

DCS World with TrackIR under Ubuntu

Cardboard Mock-up of USB Joystick