> Our game, Celeste

I was really enjoying reading this piece until I read the above, then I realized I am reading for a big developer, the maker of, Celeste [1]. I am definitely adding this to my list of favorite articles about making games.

Also, you may want to check a previous discussion from nine months ago (573 points, 246 comments ): https://news.ycombinator.com/item?id=44038209

_____________

1. https://store.steampowered.com/app/504230/Celeste/

After I read the title, I fully expected this to be about writing games using AI. But no, actually there is no mention of AI to be found in the text, not even in the "Miscellaneous Thoughts" section, which seems to be mostly answers to "why don't you use X?" questions. Refreshing...

My experience with making your own engine vs using an off the shelf solution - the former can be viable and even superior on the condition that you know what you're doing. That is if you've built entire games or engines before, or have enough experience with the internals of one.

Otherwise it can be a dangerous fool's errand on which many projects go to die. My younger naive self can attest to this, he loved trying to build his own overly-ambitious engines. But he never finished any games.

Another thought if you do roll your own - keep it simple stupid. When your brain tells you that some amazing nested scene graph with integrated occlusion culling would be the coolest thing in the world, but you lack evidence that you'll actually need all that functionality, tell your brain that it's being stupid and just implement some kind of basic flat scene structure. You can always retrofit it later.

Also - study the code of the likes of Carmack. Consider that he produced the likes of the quake engines in only a couple of years. Reflect long and hard on the raw simplicity of a lot of that code.

Do not worship complexity.

These are the words of someone who has walked both roads!

This was a great read. I'm in my 40's and have mostly done web dev/devops type stuff throughout my career. Making video games has always eluded me even though I've always been interested in it. I think it's that everything feels like a brand new language I have to learn. Perhaps creating an engine is the move.

Very interesting article.

It's kinda sad SFML never got cited, It was my framework ( after ALLEGRO ) where i learned c++ and I think it dosen't get much love nowdays even if it is very light and strong

What's the best place to get some cool graphics assets, sound etc when making a love2d or sdl or {yourfavoritetech} game?

Nice article, engines are bloated and introduce so many overheads. If you don't intend to ship any AAA games, consider investing your times to learn code-first game frameworks like libGDX, MonoGame, love2d,... or even lower level stuffs like SDL, bgfx, opengl which are good enough for almost any cases. A bit higher learning curve is expected but it won't hide anything from you, or bury you under tons of bloated abstractions.

The primary thing I'm going for in a commercial engine is platform targeting and stability. Some of the defaults are certainly "bland", but that ensures I can actually ship this thing to a meaningful % of the available market. Unity's coverage is so consistent that I've been debating using it for non gaming applications. There aren't many cross platform ecosystems that work this well.

Discussed before: https://news.ycombinator.com/item?id=44038209

(246 comments)

Creating a game with an engine is like designing a character with a pixel dollbase. You can get something out quickly, skipping a few steps because they're done for you, but you have to live with whatever choices were made by the creator of the engine/dollbase. Those choices can constrain your execution and to some extent, your imagination.

>I often find the default feature implementations in large engines like Unity so lacking I end up writing my own anyway. Eventually, my projects end up being mostly my own tools and systems, and the engine becomes just a vehicle for a nice UI and some rendering...

I honestly don't see anything wrong with using the engine for its UI and "some rendering" kind of sweeps a lot of the complicated 3d light handling under the rug. I think the biggest mistake large engines have made is baking in features as first class citizens instead of those features being part of a standard plugin you could have written yourself from scratch once you reach that stage.

I've contemplated building my own editor UI, but after four weeks I realized that I'm just rebuilding the same UI structure you see in FreeCAD, Blender, Isaac Sim, Godot, etc. There's always a 3D viewport, there's a scene tree and there is an inspector panel for looking at the properties. So why not just use the Godot editor as a UI and provide my own custom nodes? By the time I've outgrown the training wheels, I've spent months working on the actually differentiating features.

Has he dealt with some of the more challenging problems in game dev that engines help a lot with? Like... multiplayer netcode.

Seems like if you're doing this for a hobby or solo/small team then maybe it's reasonable.

For most people where they want to be a game dev but they probably will just work in industry, it seems like learning the major engines to competency cannot be ignored.

i am making a text editor/ide in Go and i too switched from raylib to sdl. it's likely one of the best graphics layers out there.