I don't know what it is about game development that really brings out the yak shaving in people.
One time, about 8 years ago, I backed a game called Nowhere[1] by a very talented programmer. The original premise was an alien life simulator.
Well, it's been eight years, and development is still going strong!
The developer is currently working on the String implementation for the programming language he invented[2], which he's using to write the other programming language he invented[3], which is eventually going to be used to write the game.
>I don't know what it is about game development that really brings out the yak shaving in people.
People get into game development because they want to have fun programming. Getting projects done involves a lot of things that are not fun, so it usually goes nowhere because the incentives are misaligned.
I've noticed this in many hobby professions - eg. hobby woodworkers spending more time on creating workbenches/tools/jigs/sleds than actually building some projects, hobby guitar players spending more time on gear than playing, etc. and I'm 100% guilty of it as well.
Sometimes all you have to do is shave the yak and give the wool away, and a nice yak-wool coat will come back to you. :)
Which is to say: sometimes, if you build a low-level library/infrastructure service and release it, someone else will take advantage of it to write the high-level thing you were originally aiming to create.
I'm speaking from experience — my company's DBaaS is built on the premise of just building a really good database domain-model to hold a certain type of large, public-available datasets, for efficient, flexible querying of them; loading those datasets into it; and then giving people access to it (through SQL or various use-case-shaped APIs.) It's a really thorough yak-shave of the DB+ETL layer of what was originally planned to be a higher-level B2C product.
But it turns out I have a pretty unique view of what should be considered "fun", because my yak-shave was everyone else's schlep. Everyone turned out to be dying to get their hands on this thing, because they wanted to spend all their time on a product, rather than getting good data to feed their product. Once we realized that, we stopped trying to build a B2C product at all, and just started selling the yak wool directly.
I never thought about the implication that shaving a yak is the most fun thing you want to do all day. It's so great you would rather shun all your other responsibilities to shave some yaks. I guess I'd better try it.
I really depends on the species of yak. Shave your matted, smelly yak? No thank you! But my silky black yak, absolutely!
I guess the trick is to fall in love with a species of yak that everyone else needs but wants to avoid, so they'll pay you to shave your favorite yaks.
> People get into game development because they want to have fun programming
Totally agree. I think the only real issue here is expectations. If the project mentioned was crowdfunded specifically and only with the goal to deliver a game, then I think people would be right to be a little bit irked that the developer is instead tinkering with their own programming language rather than the game, after eight full years. However if the project was funded with the understanding that the developer was just going to explore and share the process of game development and everyone is on board with them going off-piste to develop something interesting, then I guess that's fine.
That said, the amount of money in question is $67k spread over 1660 backers (~$40 each) so it's not like this person has grifted millions then done a rug-pull :)
I don't know about other backers, but I'm happy with how this has turned out myself. I think backing anything comes with a level of risk, and the fact that they're working on something publicly, eight years later, is more than a lot of campaigns manage.
Thank you. It's not a grift (or is that what a grifter would say - oh god I hope it isn't). I didn't want us to overpromise and become the next No Man's Sky (which has by now fully redeemed itself) so I never spent much time on advertising and trailers. As a result, we didn't get much money. People were skeptical from the beginning, which was expected. What we got in support largely came from a handful of friends who wanted to see it done, and most of their names are going to end up in the credit roll. 99% of our present funding comes out of our own pockets and from Sylvia's illustration business.
> I've noticed this in many hobby professions - eg. hobby woodworkers spending more time on creating workbenches/tools/jigs/sleds than actually building some projects
As a hobby woodworker, I was saved from this by circumstances: I couldn't build a workbench in the old shed, I couldn't build a new shed at the time, but I needed a new nighstand ASAP because my son needed a larger bed, so I had to make it on an old kitchen table in the old shed.
That is absolutely fine, and you can learn a lot with that sort of approach. It really depends on your objective.
The only thing to keep in mind is that writing software for business (e.g. SaaS) requires the exact opposite approach. You go lean, write what other people want, and go for an MVP first.
In my first year of 3D printing, I printed mostly parts about upgrading and modding my 3D printer.
But the good thing is it also made me get used to the whole process of refining a 3D print and after a year I barely started to print functional&useful things.
So yeah, I don't see a problem with this approach :)
I'm somewhat guilty of this when working on a desktop app. I made a state management library, though I realized I cannot possibly finish it in full so I spent only 100h on it to get it minimally working. I don't consider it a waste though. The waste was trying to come up with some kind of strict error handling ala Rust in TypeScript, I went far with this and got an idea to do it with minimal development, thankfully I pulled the plug on this after a month and went back to work.
As a solo bootstrapper founder it's really hard to do development and business / marketing in the early stages. Focusing purely on development is preferable when time limited, however, I think it's sometimes helpful to stop development and take a break to spend on business / marketing - i.e. some education, or preparing marketing content for the future. This tends to put in perspective how much time sometimes is wasted on meaningless things and gives clarity on what is really important - shipping a quality product.
This is a lot like what a YouTuber by the name of Randy has been doing: he decided to create his own game engine instead of using something like Godot/Unity/Unreal and it's been quite the adventure.
Of course, he still has nothing close to an actual game and the progress he's made in a year is visually similar to what i threw together in a month in Unity for a freelance client once. Though admittedly, he's probably learnt a bit more about how game engines work by creating his own and it's been quite the educational experience, as well as something that actually has gained him a nice following of people who support him towards more videos.
But that's still not very conductive to shipping finished games. It's very much the same as people whose games tend to balloon in scope, another thing that's as damaging to finishing a product in a reasonable amount of time as writing your own engine is.
I do suspect that not everyone has the utilitarian approach to game development that i or other people like me have: who just pick Godot/Unity/Unreal for every single project of theirs without ever caring much about the inner workings of everything. Then again, i'm the kind of person for whom, for example, adding graphical effects to their game consists of utilizing pre-made shaders instead of learning to use the shader language properly and all that.
Not that there's anything wrong with that, but those are wildly different mindsets.
In case you missed it, some further context, his website now reads:
I’ve decided to shelve Arcane (a video game I’ve been “working on” for 7 years) so I can practice shipping smaller games first
I’ve been sending out a personal changelog every Sunday
I’ve started using Unity so I can hone my design & prototyping abilities
I scrapped my old custom website with this WordPress one
I’ve transitioned to having writing (this site) be my main communication medium since I’m not the biggest fan of chasing the YouTube algorithm
Yep, that is actually the eventual outcome for many of these grandiose projects.
Nonetheless, i hope that his further pursuits are more successful or at least fulfilling for himself!
Who knows, maybe he'll be able to create interesting content about Unity some time in the future, like Sebastian Lague and others make: https://www.youtube.com/c/SebastianLague/videos (if he ever feels like doing more YouTube content)
> as well as something that actually has gained him a nice following of people who support him towards more videos.
A following which has recently turned against him after they funded 6k a month on his patreon, and he flatout told them that he would stop communicating, doing YouTube videos and he would also stop working on the game they were giving funding for.
If he was making that much money for a while, lives somewhere affordable, and saved a lot of that, he’s got a decent runway to start making money by actually making games instead of getting lost in his own engine.
I did the same thing 10 years ago. I probably spent about 9 months full time building a game on a custom OpenGL engine, but at that point I realized how many systems I was still missing (for example animation, more advanced effects and shaders, etc).
But as of recently I'm now doing game development again, but this time using Unity. I've learned that game development is really hard, geometrically more so than a random business application or tool, and you have to use all/any tools that are available to you.
Game development is a weird place. You want to be low level to get the most performance, but you also want to be expressive to be able to write an ambitious game. Really does invite the notion that there ought to be a better way, you get a sort of itch you can't quite reach to scratch.
I'm having a lot of the same struggles working on my search engine. What I want to do with files is often somewhere between what the operating system provides (too low level), and what a DBMS provides (too high level). So I'm having to build all these weird bespoke disk-based data structures myself. It's clear these things can be done and there is a lot to gain from doing it, but the language support for non-trivial disk based data structures is a bigger pain in the ass than sitting on a burning cactus covered in tabasco sauce.
> Game development is a weird place. You want to be low level to get the most performance, but you also want to be expressive to be able to write an ambitious game.
The vast majority of games don't need to be low level for performance. Practically nobody outside of massive AAA studios is writing architecture specific assembly for modern PCs or consoles (and even in those studios, there are very few people doing so). The majority of gameplay programmers are writing bog standard C++ that would be just as performant in C#, or in many cases a lot of the logic is written in a higher level scripting language that is orders of magnitude slower than the native C++, or even just writing all of the game code in something like C#.
> Really does invite the notion that there ought to be a better way, you get a sort of itch you can't quite reach to scratch.
Oh for sure, and there often are better ways to solve these problems. In my experience, one of the most common reasons for not doing things better is because the codebase is based on an engine from 20+ years ago when they _did_ have to avoid interfaces and virtual function calls for game performance, and you have "modern" systems that are built on top of those abstractions (in the same way that lots of modern networking libraries still leak details about concerns from the 80s/90s)
Depends entirely on what you want to do. Use a bog standard engine, and you get Satisfactory. If you build your own, you can have Factorio. The former will never reach the sort of simulation complexity the latter can even on modest hardware.
> The former will never reach the sort of simulation complexity the latter can even on modest hardware.
You're comparing games rather than engines here. There is no reason at all that you can't write your simulation logic in vanilla bare bones C++ as factorio has done, and still get the benefit of using an existing engine. You get all the neat (and hard) things like serialisation, multiplatform support, networking, asset management, patching, and a bunch of other things. Sure, factorio may not need a 3d renderer, but it definitely needs and uses the rest of what I listed above.
But you'll always be fighting the engine, because these kinds of "one size fits all" engines are complex enough to be essentially another operating system above the one you'd otherwise be dealing with. As long as your desires are well aligned with the abstractions it presents it will probably save you time, but the more you drift from that the less time it will save you and eventually there's a point where dealing with it costs more time than it saves.
For the level of performance the Factorio devs want it makes sense they'd opt for maximum control over everything rather than fighting someone else's implementations.
The problem is you can't deal with the number of entities factorio regularly does on a stock engine. They just aren't made to deal with hundreds of millions of stateful and non-trivially interacting entities. That's not what game engines are built optimized for.
I think you're underestimating what can be done with the industry standard engines. From a rendering perspective modern game engines can handle so much stuff that it will fill your screen entirely. Just look at UE5's Nanite which supports ridiculously massive scenes and splits the frame into roughly pixel-sized triangles to render at interactive frame rates.
If you do end up in a situations where you have more objects than is suitable for even these systems to simulate you don't need to throw the baby out with the bath water. Create your own managers running whatever simulation you wish without tying the units directly to the most obvious game engine entities, with whatever scheduling you need to make the updates work with the compute budget you have. Use the engine entities to represent whatever higher level object makes the code manageable and easy to work with.
Then you can surely leverage the game engine for input handling, rendering, and a lot of your logic, just writing your own code for whatever challenges are unique to your game and where the standard approach for that engine is unsuitable.
Just because you're using unreal doesn't mean you need to have one actor per entity (for example). Using [0] as an example, there's no reason you can't implement a cache optimized simulation algorithm in C++ and pass the results out to UE4 instead of whatever layer factorio is using.
To be fair, factorio is a pretty good example of when the existing options offer limited value (lock step networking, _very_ simplistic rendering, very little in the vein of "gameplay" features), but it's one of very very few. For every factorio, there's 100 2d side scrollin platforms that are written in a custom C++ engine rather than using unity.
Reimplementing all of the features that unity provides for you is time spent on "just" adding a level editor, asset loading, character animations, scalable UI, collision detection, networking, state management, serialization,gamepad support, multiplatform support, store/platform integrations, when you could have been building a game. I can spend a month building a bare bones C++ engine that gives me all of the above and start into my game, or I can download unity, start with all of those features and spend a month working on my game.
Sure, and then deal with leaky abstractions and fighting the engine wherever its abstractions don't give you what you want.
> adding a level editor, asset loading, character animations, scalable UI, collision detection, networking, state management, serialization,gamepad support, multiplatform support, store/platform integrations
None of these are nearly as hard as cult-of-always-use-an-engine makes them out to be. And there's value in having complete control over your product and understanding how every part of it works. You don't have to wait for Unity to support a new platform, or fix a bug that's blocking you, or implement a feature you want, you just do that yourself.
I'm not saying it's the wrong choice to use a bespoke engine, indeed many games that are made with bespoke engines would not have been made otherwise and I'm grateful that such things exist and enable those games to be made, I'm just saying it's not necessarily a bad idea to make your own engine. Hell, Jonathan Blow is a successful game developer who made his own engines for Braid and The Witness, and now he's gone as far as making his own language and compiler to make games with going forward because he feels C++'s eccentricities get in the way too much.
> None of these are nearly as hard as cult-of-always-use-an-engine makes them out to be.
I never said they were _hard_, but they take time. Time that can be spent on your game.
> You don't have to wait for Unity to support a new platform, or fix a bug that's blocking you, or implement a feature you want, you just do that yourself.
Every system has bugs. You're always going to have to make tradeoffs when building projects, and building an entire framework from scratch to avoid those bugs is throwing the baby out with the bathwater. You're trading the possibility of at some point in the future being blocked from developing a very specific part of your game for the guarantee of spending time up front yak shaving.
> Hell, Jonathan Blow is a successful game developer who made his own engines for Braid and The Witness, and now he's gone as far as making his own language and compiler to make games with going forward because he feels C++'s eccentricities get in the way too much.
Blow has shipped two games in 20 years, and one of those (braid) predates _any_ of the existing engines being free and easily accessible. Another of the "build it from the ground up" camp is Casey Muratori, who started handmade hero almost 8 years ago, and is nowhere even close to a game. The post we're commenting on here is entitled "Accidentally Making a Language, for an Engine, for a Game". If your take away from those things is that "you'll spend more time fighting the engine" then I don't really know what else to say.
You say that like it is a bad thing. By (nearly) all accounts Braid and The Witness are lovingly and expertly crafted, unconventional, and brilliant games. He's not making the annual Madden or Call of Battlefield here.
> Casey Muratori, who started handmade hero almost 8 years ago, and is nowhere even close to a game
Be fair to Casey, Handmade Hero is primarily an educational project and he only devotes a few hours to it each week. Though admittedly he has allowed the scope to creep quite a bit from the original goals.
> The post we're commenting on here is entitled "Accidentally Making a Language, for an Engine, for a Game". If your take away from those things is that "you'll spend more time fighting the engine" then I don't really know what else to say.
My point is more that I'm kind of sick of people being so down on the concept of building your own engine even for relatively simple 2D games. Yes, I agree that it takes time, but so does learning the ins and outs of an existing engine and the time you invest in the latter nets you less generalizable skills than the former and leaves you with less control over the end product. It is a tradeoff, and like all tradeoffs there are good reasons to go one way or another.
Is that really true though? Aside from graphics and physics, which seems to be highly reusable, where's the performance critical stuff? Lots of engines seem to be mostly using scripting languages for everything a game developer needs to do.
I wonder if there's a DBMS out there somewhere that already does what you need? Seems like by the time you got to a scale where you would need custom stuff, you'd have money to redo it(Unless it's a foss thing meant to be big but not commercial, or to run on a server you're paying for yourself)
I work specifically with video game performance, mainly as a graphics programmer, and often focusing on getting things to work well across multiple platforms. In my experience the performance issues are almost always a combination of how much is being simulated and rendered, how it's being rendered, and how much stuff is kept in memory at any given time.
If you can improve culling before rendering and physics, minimize the surroundings streamed in to your immediate vicinity, and optimize some of the heaviest materials and post effects, that goes a really long way.
Of course, there's an endless list of caveats depending on what your game specifically is, but even in an open world game where things happen off screen the above applies. You just have very simply LODs/imposters for faraway visuals and simplified logic running at lower frame rate for characters in other parts of the world.
Sure. What about simulation? Like I mentioned Factorio in your neighboring comment. It does things with a custom engine that you simply can't do using "highly reusable" systems.
Existing engines are great as long as you want your game to look and behave like every other game written in the same engine. It's gotten to a point where a careful observer can tell which engine a game is written in just by looking at it and feeling how much input lag and framerate variance it has.
I think a lot of people get into game development to go back in time to their early experiences of computing. Before all the enterprise projects, before all the tools and frameworks, before all the tiring interactions with people and teams and managers and customers. Just an empty BASIC prompt, just a blank C file. It’s a search for a blank slate, open to infinite creative possibilities, before the world put everything in boxes within boxes within boxes and drained much of the joy from these magical machines. Finishing a game is coming back up for air, who’d want that?
Game development methodology has fascinated me recently. With the Battlefield 2042 debacle, its interesting to compare it to what I know (financial trading platforms).
With trading platforms, they last for years, decades maybe. They're created with some ideas around how to manage performance and to support evolving requirements. Developers know this thing is going to be around for a long time, so its treated as such. Years down the line, you start creating a new platform and look to do a long migration to keep clients happy because you can't just turn off their favourite functionality.
Modern AAA FPS games seem to be the complete opposite. Reinvent significant amounts every release. Dump the old game as the new one is released. Much seems to be from scratch. The BF2042 scoreboard issue seems like it should be almost off the shelf. There also seems to be this big shift towards short release cycles which pushes even more churn and reinventing the wheel. Look and feel must be updated to keep things "fresh". Although most of the popular games on Steam[1] are older games that have been around for years.
So many places to shave a yak, I'm surprised games get shipped at all.
Of course take all of this comment as an outsider who just yearns for the old days of cool mods and custom servers.
The days where AAA games dumped the engine between releases are long gone (like Playstation 1 long gone).
For franchise games there will be incremental improvements to engine systems; some to support new gameplay features, some to help with development tooling/pain-points, and some to improve visual fidelity. The trick is choosing the correct number of upgrades/refactors that fit the release schedule while remaining relevant and not dooming your next franchise release with insurmountable feature debt.
In my experience the biggest engine changes come with new hardware platform support, typically a console generation jump. More power requires a toolchain that can handle more complex assets (and more of them), new graphical features and expectations, different optimizations, new API, different storage types or capabilities etc. Bigger franchises may use a new console generation as an opportunity to gut an existing engine and rework to the strengths of the new hardware generation (and remove the support for older hardware, such as removing 32bit pointer support, DirectX9, Windows7 etc).
Historically where game engines get in trouble is when a codebase is written to one franchise and then forced on to a team making a fundamentally different game with fundamentally different requirements (open world vs compact maps, physics heavy vs platformer, single player vs MMO). At the executive level it makes total sense, they spent x million$ on a game engine and are told by everyone how great an investment it was... why not spin up a new game using that amazing (and paid for) technology?
The flip-side has also sunk numerous game engine efforts, which are often buried without ever becoming public. Doing everything all at once is impossible, you can either do many things generically but with restricted performance and capabilities. Or you can do 'everything' required by a specific game and slowly introduce features that support other games and make things more generic.
> Modern AAA FPS games seem to be the complete opposite. Reinvent significant amounts every release. Much seems to be from scratch.
I think this should be qualified. The audience and creative workers demand new assets for new titles, but gameplay concepts and codebase seem to move at a slower pace, though live services seem to be distinct systems and not expected to live long, of course.
On one extreme, you have EA's sports titles, where new releases have just incremental updates.
If you don’t mind a digression for someone who needs help…
What is the architecture pattern of a trading platform?
I am looking to build a system that is able to:
- receive 1000s incoming streams of data
- save the data
- make data available to live subscribers
The closest analogous system I can think of is bond/stock/commodity/etc price subscriptions for traders.
I feel like this many in - many out data stream architecture should be solved by now and I rather not start from scratch in architecture and technology choices.
I can’t find the right phrase to even google to get started.
I assume your live subscribers are external people over the internet?
The trading platforms I've worked on tend to order things into a single stream that you can act upon. This helps with testing, race conditions, auditability. You will want to be able to replay an exact series of events to recreate conditions.
LMAX Disruptor[1] and Aeron[2] are two open source examples of something widely used, either using the libraries themselves or as concepts.
Some things that trading systems (generally?) need which you may not, which might simplify your architecture:
- Every message must be delivered and in order. UDP is usually used over TCP, as the platform will likely want more control over handling missed messages.
- It will be common to have read/write applications that need to add a message as a response. Writing is difficult as you need to be quick, otherwise a subsequent message from another application might invalidate your message.
Do subscribers need older data? How do dropped packets impact the system? Can they just be forgotten? What latency requirements do you have? Do subscribers also write to the same stream?
I think sometimes the followers find out that being engaged in the process of creating something brings more value than the game they're waiting for anyway.
I have been in a couple of communities involved with developers as they built games and it was almost disappointing when the game was released because the 'journey' was finished and so time to disband.
It can certainly be a curse though if the developer isn't or stops enjoying it.
Wait, that's the game by Leonard Ritter, aka paniq!
I loved his (demoscene) demo Masagin[1] way back when, and have the SVGs of the geometric shapes somewhere, with a vague idea of bleaching them onto t-shirts (speaking of old projects that never come to fruition...)
Frankly, I can't say I'm surprised that's where he's at with Nowhere. Well, I'm glad he's having fun.
Truth is developing the engines is a lot more fun than developing finished products. Game engines are like virtual machines purpose built for interactive audiovisual program execution. The games themselves aren't that interesting. Operating systems are fun, the applications running on them are boring. Browsers are fun, the web sites are boring.
Well, it's been eight years, and development is still going strong!
The developer is currently working on the String implementation for the programming language he invented[2], which he's using to write the other programming language he invented[3], which is eventually going to be used to write the game.
Haha, sorry but was that intentionally snarky or just happened to be?
Implementing and refining game tech is not easy, but it's fun, is mostly a science, and gives you rewarding feelings regularly. Game design/production is a mystical dark art (or at least can feel like one) that can be incredibly discouraging, so people avoid it, and avoid the point at which the end is in sight and the game will be judged as a game, by gamers. Modern games leave such a potent impression on our psyche that trying to design one of your own without excessive imitation or feelings of inferiority asks a lot of us. There's also the phenomenon of "devlogs," whose quantity is proportional to development time, and which are useful to show backers that you're making progress (in good faith or otherwise.) And in many cases, somehow they are always long enough to maximize ad placement!!
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.
Since I've crossed over from game dev to doing illustration myself, I've realized something about how one ends up in this place, because I've been there. Not as deeply or for as long, but I've seen it and still get tempted by it. It's not actually unique to game dev - it applies to any creative work(e.g. the 30-year novel) - but games demand a higher degree of engagement with their technology than static works, and that creates the ground conditions for scope to explode far more frequently.
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 ;)
It's not game development that brings out the yak shaving, it's programming language development. Game development is just a gateway drug because it provides so many opportunities for good abstractions to make things easier. The mistake everyone makes is thinking that they can create a programming language while also doing X, where X is whatever they had doing when they got the itch to do a PL. Really, if you want to do a PL right, you have to do it full time.
Actually I'm not sure it's really a mistake, it's just that doing PL development is so much fun that there's no reason to go back to the original project, if original the impetus for it was to have fun.
Yeah. After wasting two years working on a programming language I realized nobody was ever going to use, I made an oath to just stick to hacking on top of language that already exist
Honestly, my problem is: I don't want to write low-level code, I want a game engine where I can focus the majority of my time on implementing the actual game mechanics. I don't want to have to deal with manually redrawing the screen every time, I want a sprite graph.
I also don't want to have to use slow and clunky UIs like Unity, I just want to spend the majority of my time writing code in text files, and making assets in other tools like Tiled or photoshop or whatever.
It really surprises me how few engines there are in that category. Only ones I've found were: PhaserJS and HaxeFlixel, and unfortunately no 3D ones.
Thank you for backing his work, his posts and twitter feed are a gold mine for some pretty unique ideas in signed distance field and other rendering research.
I read an amazing quote online about any satelite company trying to create their own custom rocket to launch its satellite instead of using existing infrastructure.
The day they decide to get into that is the day they stop being a satelite company and become a rocket company instead. The person put in much more eloquent words so wish i could find that comment but its sounds similar to that.
Wow these are just excellent and even though it says spacecraft design most of them ring just as true for software design.. or maybe just true in general!
This one really made me laugh :D
> At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it.
What an excellent link, thanks for sharing. Definitely bookmarking this.
Working on languages and runtimes is just fun on its own. It ends up pulling in many facets of CS: graphs, perf, grammars, automata, resource allocation, etc.
One time, about 8 years ago, I backed a game called Nowhere[1] by a very talented programmer. The original premise was an alien life simulator.
Well, it's been eight years, and development is still going strong!
The developer is currently working on the String implementation for the programming language he invented[2], which he's using to write the other programming language he invented[3], which is eventually going to be used to write the game.
[1] https://duangle.com/nowhere
[2] https://hg.sr.ht/~duangle/scopes
[3] https://hg.sr.ht/~duangle/tukan