January 8th, 2018
Collision is that bit of code where one thing runs into another thing and both things have to decide what to do (or not do) about it. My collision code I cobbled together last week clearly has bugs. But this week, I did something very foreign to my previous experience as a programmer: I did not work on these problems and I moved on.
From Derek Yu's autobiography:
... for a project to progress as a whole, the individual parts have to progress at relatively equal speeds. You have to know when what you're working on is good enough to put on hold and it's time to move on to something else.
He goes on to explain that being a problem solver makes it "hard to leave a problem not fully solved." Similarly - while brushing up on procedural generation last week, I read something from Tom Francis that slowly took root:
I don't polish or improve things until all the other systems are in.
It turns out that this is terrific advice to a fledgling game designer. As a person who wants good systems, I often overcompensate by trying to create "perfect" systems. In programming, perfect systems are rarely perfect and trying to create one is generally a black hole for progress: time and energy go in, but success rarely comes out.
Adding arrows and death
Instead of focusing on my terrible collision code for what was quickly becoming some kind of twisted crate simulator, I decided to give my world some actual gameplay in the form of monsters, workable AI, some arrows, and death. As week two of development came to a close, I was finally able to enjoy several minutes of a thrilling, brutal world. With monsters swarming me from obscure angles, I could not make it to the castle's exit - not even once...
... and trying to protect the Monarch (currently represented by a gold circle) was almost impossible:
Stopping my work on collision and moving on has paid off. I now have a game (even if it has miles to go). Again from Tom:
It is easy to stop polishing the silverware when you realize how much of the house is on fire.