So the algorithm wasn’t great and the map was slow. Rome wasn’t built in a day. I get it, you have a vision in your head for how you want it to work and it wasn’t there yet. But this is actually a psychology problem and not a project problem.
So the algorithm wasn’t great and the map was slow. Rome wasn’t built in a day. I get it, you have a vision in your head for how you want it to work and it wasn’t there yet. But this is actually a psychology problem and not a project problem.
I agree with your perfectionism point; but how to test the hypothesis that it would be "fun"? A rough prototype can easily not be fun, even if the hypothesis is true! User experience seems hard...
Perhaps this is the reason for Mark Cerny's Method in game dev: to complete a slice of a AAA game to shippable standard, to tell if it's worth completing. Because players can't evaluate the experience of a game without the finished game. It's a hell of a lot of work, like $3 million; but doing just a slice makes it less than the $30 million for the whole game.
Whereas, for some reason, for Zelda: Breath of the Wild, they developed a cheap 2D prototype to test out their "physics" and "chemistry" ideas. How were they able to test their hypothesis so cheaply?
What makes a hypothesis cheap to test? Is it a bit like unit tests versus functional tests?
The author identified all the things they needed to do, and described the process of doing everything but those things despite seemingly knowing exactly what was needed contemporaneously.
Obviously it’s no fun to try and force a non-fun project through to the end, and I agree with the author’s analysis that they should have stopped sooner.
I’m guessing it wasn’t fun which is why the author did what I often do when I sit down at my computer to work and want to blow it off: I spend a bunch of irrelevant time physically close to where work happens, but I don’t do any work.