| Oh no, we are on Hacker News. ;-) Hi, this is the yak shaving developer in question speaking. I was worried we'd get grilled hard over our slow progress, but I'm relieved to read that most of you understand how perilous and long-winded gamedev can be. Our backers are also very patient with us, and I don't want to destroy this relationship, but keep being as open and forthright as I can with our progress. I don't mind the jokes (after all, yes, the whole undertaking is a bit ridiculous), but just want to make sure the facts are understood as they really are: * Yes, the premise of Nowhere continues to be that it's an alien life simulator (as in: simulating the everyday life of an alien). * The game is being developed by not just one, but two people: My wife Sylvia Ritter[1] is responsible for the concept art that drives the procedural design (she has given me a lot of work), and I am responsible for programming and direction. We both have a hand in the game design. * Yes, development is still going strong, and will continue to do so, until the game is done or I keel over, whichever comes first ;-) * Yes, I am absolutely yak shaving, and there's definitely some sunken cost thing going on here, but there is still no project I'd rather work on than this one. When we launched the crowdfunding, I had a hunch that this would end up taking us 10 years. Now we are on the far side of it and I had to start cutting features and workflow improvement ideas in order to have a chance at making it in time. * Yes, I developed a programming language for the game, because the art is procedurally driven, and that requires both fast turnaround in prototyping (close to Scheme or Python) while providing C level performance at the same time. There simply was at the time that I started, and still is, no adequate solution available. Originally, I didn't want to do it, but we rationalized that innovation of technique requires innovation of tooling, and hence worth the effort, provided we'd open source everything we made in pursuit of our goal. * No, Scopes' string implementation is complete for several years already, the recent commits are all touch-ups, augmentations and small fixes for the userbase that has grown around the language, which were quick to do and cost me no significant time. We have in fact other, much larger, support problems that I can not adequately cover because the game is main priority, and the language exists to service the game. * Yes, I developed a pure functional reactive language on top of Scopes for our game engine that I wrote a few examples with, in the intent of finally merging the CPU and GPU models so we save 90% of pointless and repetitive boilerplate code for CPU/GPU resource management. It's a fantastic idea that is going to go places, but after realizing how much more I'd have to write to get it all the way to its final, visual programming oriented form, I aborted the prototype and focused back on the game. * What else have I spent my time on? I spent most of those years writing a bunch of prototype shadertoys to explore possible technology used for the game and also teach mathematical concepts to other developers, and they're all released here[2] * What's going on right now? After streamlining package management[3] for both Scopes and Nowhere, I am presently working on our sculptable terrain engine. There is a by now somewhat outdated video demo[4] of one of its earliest incarnations. The LOD stitching has been fixed, and we have occlusion culling now, but I still have to rewrite parts of it to get a rock solid sub 10ms per frame performance. It would have been more fun to do all that with FRP instead, but tooling is never quite where you want it. Thanks for reading all that, Leonard [1] http://sylvia-ritter.art/ [2] https://www.shadertoy.com/user/paniq [3] http://majoreo.rocks [4] https://www.youtube.com/watch?v=5JOzqsJZmCo |
What actually happens when scope explodes is that a coherent view of the project has been lost. This is not problematic in a creative sense, just in a "finished product" sense: every time you introduce a contradiction into the work you have to either eliminate it(which creates a negative attachment response, and therefore really requires project managers to step in and cut off some heads) or you work very hard to create some kind of technical rationale, e.g. "we'll do both ideas, so now we have a new type of asset and the entire game must be populated with it and the features will be a little more complicated by it". Which you can proceed to start doing without difficulty, and only feel the downside of later.
Game devs are particularly susceptible to this because games sit in an intersection of dynamic/synthetic/interactive that allows infinite numbers of assets and features to be added, but at a gradually increasing cost, even if you drop fidelity(see every roguelike that has been in development for more than a few years.) And it lets the dev sit in a space of perpetual escape from coherence, because "it'll be great as soon as I add this next thing - after all, nobody has ever done this before". It's a little hype cycle that can be reinflated over and over.
But if you paint a picture, it's one-and-done: there's only so much room on the canvas, so you have to deal with your folly immediately to finish. You can, of course, go the route of burning it and starting over, making the same mistake repeatedly, but this provides much less of an illusion of progress than hitting the compile button on your ever-growing codebase. And you can do a lot of preparatory studies and meander without committing to the image you're making, but the act of doing the studies still propels you into a space where you can hurry up and finish whenever you want.
So the usual advice given to game devs to manage scope is to introduce a technical restriction that "limits the canvas," but if you're technically inclined I think the proper advice would actually be to limit dynamism and make more static works with simple design scope so that more of your technology can be one-off, and not required to be integrated into the large, fully-automated framing of a game engine. E.g. a magnificent rendering system that creates static images for a visual novel. "Simulator" type projects are mostly eliminated by this except where they can take a direct reference, like a vehicle sim. All of my least coherent designs started embracing the simulation concept - and doing that was itself a way of getting away from a clear statement of belief within the game, of trying to accommodate multiple sets of beliefs without directly engaging them.
Not that anyone is going to listen, of course. Sometimes one has to lose a few years of living to this stuff ;)