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:
Just hack around to get something working quickly.
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)
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!
Comments
Post a Comment