41–50 of 257 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
This. When working on your own engine you also feel as if 90% of the time is spend on user interface creation if you actually want to have an visual editor. People don't realize that they will spend 95% of the time on the engine and 5% on the game. Which is ok if you don't want to make a commercial living out of it. But unless you are making a game with extremely specific needs (eg Factorio) using your own engine wil…
Even factorio started out on tried-and-tested libraries before moving away from them primarily because of optimization concerns (right?)
Keep it super simple. Or that game will never come out.
Many people often say that making an engine from scratch takes too long. But how long does it take to properly learn Unreal or Unity such that you can have an idea and turn it into a game without friction? Presumably, once your engine is finished, you are at that level of expertise instantly, which is a huge time saver. In my opinion, the more experienced of an engineer you are, the more the scales tip in the favor o…
Most likely never?
Obviously understanding what `GameObject.Instantiate(myPrefab, Vector3.zero)` takes several orders of magnitude less than implementing all that is required to properly perform that, even for such a basic operation.
Imagine when it comes to 2D/3D physics, shaders, platform support, etc.
If your goal is to build an engine, build an engine. If your goal is to actually deliver a game, build a game.
Thank you for writing this post, Noel!
> 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…
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.
That sounds obvious but it really isn't. One example: maybe you don't need any object culling at all. Nobody tells you this. Anything you look up will talk about octrees, portals, clusters, and so on - but you might be totally fine just throwing everything at the renderer and designing your game with transitions at certain points. When you know your constraints, you're not guessing, you can measure and know for a fact that it's fine.
Another example: shader programming is not like other programming. There's no subclassing or traits. You have to think carefully about what you parameterize. When you know the look you're going for, you can hardcode a bunch of values and, frankly, write a bunch of shit code that looks just right.
The list goes on and on... maybe you don't need fancy animation blending when you can just bake it in an external tool. Maybe you don't need 3d spatial audio because your game world isn't built that way.
Thing is - when you're writing an _engine_ you need all that. You don't get to tell people writing games that you don't really need shadows or that they need to limit the number of game objects to some number etc. But when you're writing a _game_ (and you can call part of that game the engine), suddenly you get to tweak things and exclude things in all these ways that are perfectly fine.
Same idea applies to anything of course.. maybe you don't need a whole SQL database when you know your data format, flat files can be fine. Maybe you don't need a whole web/dom framework when you're just spitting out simple html/css. etc. etc.
I think this headspace is pretty common among gamedevs (iiuc large projects often copy/paste dependencies and tweak between projects rather than import and support a generic api too)
After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious. Engines are the easy part. The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement: - importing data from various sources and formats, textu…
(and the same is becoming more and more true for shader compilers vs 3D APIs - all the interesting stuff is happening in the shader compiler, while the 3D API is just there to kick off shaders and feed them with input data)
Earlier quoted context omitted.
Even factorio started out on tried-and-tested libraries before moving away from them primarily because of optimization concerns (right?)
Yep, people forget one of the core notions of development which is not to prematurely optimise stuff. Especially something as complex as a game. Keep it super simple. Or that game will never come out.