Dev process goals - knexer/twin-mouse-shooter GitHub Wiki

I want to do some things a certain way here, as an experiment / to learn from my past mistakes.

• Don't polish the turd: fixing bugs and polishing features ossifies them in their current state, making bigger changes harder, and can be used to procrastinate on the same bigger changes, which is a bad feedback loop to get into. Polish/bugfix only when:
  • some polish is needed to figure out if something is fun
  • the alternative is to work around the issue, and fixing it now is actually simpler
  • releasing something (e.g. to playtesters) and you don't want all the feedback to be about known issues
  • you need a momentum on-ramp or to feel better about the game (try to use this sparingly!)
• Don't procrastinate on cross-cutting structural things for too long. Otherwise adding gameplay and polish makes the structural things harder, which is the same bad feedback loop to get into. Examples of things that bit me previously include:
  • Saving/loading
  • Switching scenes (high level app states like a main menu, multiple levels, etc.)
  • Pausing/resuming
  • Making things look pretty and sound good (a big enough pile of programmer art gets daunting to tackle)
  • Establishing a workflow for designing scenes/composite objects outside of code and importing them; doing level design in code is convenient but not a good long term plan
• Keep track of tiny, short-lived tasks in comments at the top of the file, medium or longer-lived tasks in bugs, big multi-step projects in wiki
• https://www.youtube.com/watch?v=o5K0uqhxgsE