Comment by danielbarla
9 months ago
> I genuinely believe making games without a big "do everything" engine can be easier, more fun, and often less overhead. I am not making a "do everything" game and I do not need 90% of the features these engines provide.
At that point, of course, you don't need the engine. Having said that, every time I've really deep-dived into some particular feature of an engine - such as inverse kinematics and animation blending in Unreal - I've come away thinking "boy, am I glad I didn't spend several weeks trying to code that up from scratch".
There's definitely an argument to be made for minimalism and anti-bloat, but the reason engines are popular is that they really do some heavy lifting for you.
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.
> “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
1 reply →
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.
[dead]
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.
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.
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.
2 replies →
> 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.
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!
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?
4 replies →
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?
Blatantly false dichotomy.
Or You simply aren’t ruthless enough about how much time you have on an indie project.
4 replies →
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.