Comment by gyomu
9 months ago
> “boy, am I glad I didn't spend several weeks trying to code that up from scratch".
If your goal is several decades of a career as an independent developer (like OP), what is an investment of a few weeks for a) understanding a topic deeply and b) having source code that you deeply understand, 100% own, and can reuse across future projects?
It's worth remembering when deciding on rolling out your own engine that this is a multi-layer trade-off as well, I have an anecdote on this.
I have decided a couple years back that my setup will have a hand-rolled physics engine, specifically for the reasons you outlined - having complete understanding over what the code does, how it's structured and how it manages data - but after starting actually-not-so-arduous process of getting it together, it quickly became rather clear that whatever I could implement would pale in comparison to solutions that are robust, field-tested and generally created by professionals.
Physics development in particular is known for wonky nonsense, but there are better and worse heuristics and ways to deal with their shortcomings; a handful of books and Youtube presentations still couldn't prepare me for the actual depth of the problems ahead. What I have now works, is relatively stable in initial demos and I am proud of it, I'm going to tweak and use it in the game I'm working on. It is however pretty obvious already that a lot of time is yet to be spent on massaging jank out of the equations.
I wholeheartedly recommend spending more than several weeks on implementing various subsystems if one either is generally interested in how these things work or silently wishes for that badge of honour (it shines brightly). However, as they say, if you want to make games, do NOT make an engine. Not just because of the time it takes - it doesn't have to take that much (even though it usually does) - but also because along with total control over the medium for expressing your creative vision, it gives you total responsibility for it as well. Sometimes it's better to work in the confines of rules set out by actual engine developers.
There's levels to that though. For example it took me all of a week to write the 2D rigidbody physics system that runs this game:
https://www.youtube.com/watch?v=zVmd2vmZrVA
But it's tightly scoped, there is only really one thing that needs to be dynamic, although it worked admirably with more. We wanted big impulses so could get away from questionable cases easily and could deal with crushing cases simply by exploding the ship.
Likewise the players on the ship running around and the players when they're jetpacking about are all different sub-sets of code implementing that specific behavior.
A lot of "make a game, not an engine" is working out what the minimal thing you need to build is rather than making everything extremely generalized.
I'm in the same demographic (less successful than Noel, but I have made my living from game dev for the last 15 years, a lot if from my own indie games). I've used multiple engines throughout that time as they seem to have a lifespan before either tech or business reasons obsolete them (e.g. my first commercial release was made with Flash).
My only regret were the times I tried to roll my own, I would have saved a lot of time and effort focusing on picking the best tool for the job that saved me as much work as possible.
At the end I want to make games and not engines, and only do as much programming as I have to. All those person-millennia spent at epic/unity/etc actually spent doing a lot of stuff (even if you don't need 90% of it, 10% 1000s of people working for decades is still a lot).
Face it, you just don't know how to do it and are trying to convince yourself that you don't need to learn how to
Lots of things I don’t know how to do and can spend time learning, many will be better use of that time and effort than reimplementing a game engine from scratch vs using middleware.
I get the argument, and sure, it's viable in certain circumstances. But it's a few weeks _per area / topic_. In my opinion there are enough areas in a typical engine that you could study them for a year and not get through the material. There's graphics, audio, networking, physics, etc. I think the sweetspot is to understand each well enough that you have some insight into what the engine is doing for you, not necessarily to be able to (re-)implement it.