> “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?

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.

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 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.

My graduation thesis was porting a particles visualization engine from NeXTSTEP/Objective-C into Windows 95/Visual C++, based on OpenGL, with samples like marching cubes.

This is a single bullet point on modern engines feature list.

And now that you’ve done it, you could probably reimplement it better in a fraction of the time.

Except that I wouldn't, because most of that stuff would be a shader nowdays, and depending on the API version, not the same kind of shader.

This kind of stuff is fun, if the end goal is to become a game engine or tools engineer, if the goal is to make a game, it is mostly yak shaving.

I was like this in the past. Making my first 3D game: After weeks of implementing all input, object management, culling, model loading, math lib, gfx, normal mapping, SSAA,... I had 0% progress on my game.

However, for my fun hobby 2D projects, I still self roll without dependency in the web canvas. You could call the browser an engine though.

Also using an engine allows us to make progress on the project itself, rather than sinking major time into building infrastructure.

Reinventing the wheel isn't that fun for most people.

On the contrary, lots of people enjoy the reinventing the wheel part as a means of avoiding all the tricky creative choices and risk of actually shipping a completed game.

Me, too many times.

I think this is also true beyond games, e.g. for all the different UI libraries.

This happens absolutely everywhere. Many B2B SaaS products could have been a single T-SQL script in MSSQL or some other paid/non-OSS/evil capitalist equivalent.

I think a lot of developers lean on ideological angles to deflect rational criticism of their lack of progress and direction.

Unity and Unreal are absolute powerhouses if you have an actual idea and a burning desire to express it as quickly as possible to as many customers as possible.

> Unity and Unreal are absolute powerhouses if you have an actual idea and a burning desire to express it as quickly as possible to as many customers as possible.

If your game idea fits well into the structure of these engines: perhaps.

But I can tell you that lot of ideas that I have for games ("games" is to be understood in a somewhat more broader sense) don't fit these structures well. So I am very certain that for the game ideas that I have in mind, writing an own game engine would very likely be the better choice.

I’m not doubting you, but the vast majority of ideas people have for games are largely derivative and could quite easily be implemented in Unity.

It does feel like for many people, it's a form of procrastination and escapism. I'm still working on the game, I just need to do this and this and this first.

Of course - sometimes you just need to learn how it works below, but if your goal is to ship, and you don't have a lot of time, then what I said strikes true to me.

animation blending isn't that bad. If you have a two poses represented as lists of quaternions and positions, all you have to do slerp between the quaternions and lerp between the positions.

FABRIK IK algo is a ~100 loc function.

Agreed, though getting to that point of understanding is what takes time. Also, there are literally dozens of similar topics where a solo dev should be happy to take any help they can get, IMHO. I'm sure audio is similarly easy, as is input, pathfinding, AI decision trees, physics, etc, etc.

physics is not easy. its pretty challenging and has unending scope.

audio can also have unending scope if you want to do physically simulated Spatial Audio.

Im not sure if AI/pathfinding are worth developing as part of an engine. I feel like their implementation is heavily dependant on the game type, engine implementations often get in the way, rather than helping.

rendering is a beast, especially if you need a long draw distance and have a world that doesnt fit into gpu memory.

The whole task of putting all the pieces together into a cohesive package is a huge undertaking as well.

> inverse kinematics and animation blending

Either this is a central feature of your game, and writing it is worth it. Or it’s a technical boondoggle, and you don’t need it.

It's just so wrong. These things are very standardized, and you often just want the common implementation that everyone is using. Writing these in most cases is like writing your own SHA256.

Is your indie game more complex than quake 3?

This is table stakes for any 3D animation, these days. Anim pop is embarrassing and almost certainly you'll want look IK let alone any of the more complex usage.

> This is table stakes for any 3D animation

You’re doing 3d skeletal animation for your indie game? How many skeletons and animations are you going to make?

And you don’t consider it a central feature?

If you have any animations you're going to want to blend them. If you don't want to make a lot of animations you're probably going to want to use IK for procedural animation.

If you use an engine, you won't be forced to spend time and make it a defacto central feature (because you wont have time for other features). You'll just have access to it.

Evan a 2.5D platformer, a common indie genre, would want animation blending and foot IK without innovating on it.

> If you have any animations you're going to want to blend them.

Yes, if 3d skeletal animation is a central feature of your game it’s not a big deal to spend time making a good system that works for you.

> you're probably going to want to use IK

Plenty of 3D games with 3d animation don’t have IK

> for procedural animation.

Wow your game has 3d procedural animation! That better be the main feature right?

The reason I’m so skeptical is a feature has cost whether it’s written in the engine you use or not. You have to do work to make your content look good for IK, and for an indie games that’s critical resources to invest in that.

For most games, spending time tweaking rigs for IK is not going to make your product better.

> You have to do work to make your content look good for IK, and for an indie games that’s critical resources to invest in that.

This is the entire point of using an engine. You can spend time on the content instead of coding features that aren't unique. Suddenly many types of content are far less costly.

I’m saying the real cost is the content.

It’s not hard to implement any of these features, you just don’t have time to do them all.

I agree an engine can be a good prototyping tool.

Blatantly false dichotomy.

Or You simply aren’t ruthless enough about how much time you have on an indie project.

Or those features can be nice-to-haves that are worth it if they're not too much effort, such as if, say, I don't know, an engine handles them for you. Come on, real life rarely justifies such easy, simple decisions. And polish can matter a lot for games.

Sure I’m expressing a value judgment, a design preference - not an eternal truth. And the principle is I want to spent the effort on the most important features in which case it’s not a big deal to write them. Your best features become better than if they were cobbled together in Unity.

That is, to be generous, a rather extreme and niche value judgement that corresponds to no utility I can think of. Real life has a spectrum of "important features" and a corresponding spectrum of justified effort. If that's your idea of artistic integrity, then you do you, but for anyone else it's probably nonsense.

> to be generous, a rather extreme and niche value judgement that corresponds to no utility I can think of

Ok, well I look forward to seeing your games then, as I’m sure you’re skilled at shipping.

Heh, I contribute to a FOSS social vr project called https://github.com/v-sekai and the majority of the multi year effort was asset pipeline, ik and animation blending. Yes we donated the code to Godot Engine but we choose working on the tooling problem rather than the game… The V-Sekai game is in limbo / not a game. We made godot-vrm which does 3d avatars, with basic animations, look at, jiggle and copy constraints. Since we’re unable to use the unity ecosystem’s finalik or unreal engine’s control rig we have to code to the same level of professional quality with no budget. Features like stable multi-joint y-branching rotation and position constraints are hard. Feel free to chat in V-Sekai discord. I’m iFire.

Using Godot for my big project, thank you for donating the IK stuff to godot!