KronisLV
9 hours ago
I'm reminded of the story of Randy, that I watched unfold over quite a few months - he couldn't help himself but to work on new features, rewriting existing features, hacking to make his workflow better, but really struggled to release anything, like a form of bikeshedding where you are actually still productive, except what you produce doesn't seem to meaningfully get you closer to shipping at all.
The videos that document the journey probably haven't gone anywhere:
https://www.youtube.com/@randyprime/videos
https://www.youtube.com/@randyprime2/videos
If you want to make an engine and learn about making engines - make an engine.
If you want to ship a game - think long and hard about whether an off-the-shelf engine wouldn't be a better investment of your time (because you wouldn't invest hundreds or thousands of hours making something bespoke and could actually make the features you need within an existing engine).
I suspect that with the great FOSS and source available engines we have, like Godot, there will be plugins for msot things and folks will be able to make their own without having to start from scratch (unless they really want to), like the most competent terrain implementation for Godot so far is a plugin - https://tokisan.com/terrain3d/
Hell, maybe also contribute to lesser known engines if you feel like it: like jMonkeyEngine, Flax (it's great, like a lightweight and 3D oriented Unity / Unreal with a footprint closer to Godot and a nice C# integration), Stride and others.
bananaboy
8 hours ago
I’ve been working in the games industry as a programmer for 21 years and I’ve seen this so many times. I also used to see it on gamedev.net and flipcode.com. Very technical people, engine programmers, think they can make a game and seem to think that all it takes is an engine and don’t even think about the game part. They tinker endlessly with file formats, memory allocators, vector math libraries, pooled string classes, etc and never finish anything when they could have just used json and png files and actually shipped something. On PC for the scale of game most indie developers will make all of that stuff isn’t really necessary. And if you find it is necessary then you can refactor later.
LarsDu88
8 hours ago
This is the infamous "stack fallacy" https://techcrunch.com/2016/01/18/why-big-companies-keep-fai...
The idea that the layer above your own is trivial to build (e.g. biology is just chemistry, or chemistry is just applied physics)
At some point I built a little 2d game engine, but the same amount of time would have been better served actually building a game in Unity. Eventually I solo developed a full 3d VR app for the MetaQuest.
mabster
3 hours ago
I'm out of the industry now, but I kept doing this for a while. I would want to "scratch an itch" and build a game out of hours. After a few attempts I realised I don't actually want to build a game, I want to build an engine
andai
9 hours ago
A few months ago he posted a video where he realized his motivation behind the curse of the Eternal Enginedev: "I thought if I could just make a really good engine, making a game would be the easy part."
Edit: Found it!
https://www.youtube.com/watch?v=3kzNiMMnT4U
---
I had a related realization recently... I realized I had taken my "prototyping mindset" into a production project, and that was a very bad idea. (Wasted an enormous amount of time, could have finished way sooner.)
So, first of all, I need an outlet for creative and experimental stuff (R&D Division), to get it out of my system! And second, the production project isn't the right place for that. (At least, not on the level of tech and infra.)
I think that's basically what John Cleese was getting at with the Open/Closed Mode thing:
lowbloodsugar
7 hours ago
For many people sure. There is also the path of “just build a game” with no distinction between the game and the engine. Super Mario 64 doesn’t have a game engine. For the first few months it was just “catch the bunny”.