[DominikD]

That's not the point. You've got code responsible for audio, asset loading and streaming (which tends to be ad-hoc in "engines" that focus on rendering), UI, state loading and saving, visibility query DB, nav meshes, and a lot of system and gameplay logic further divided into unique modules (character management, damage management, etc.) Yes, editor is a must these days (and has been for over 20 years) but that's not the point DeathArrow was making.

[flohofwoe]

What if your game embeds all assets in the executable as runtime structures instead of loading files? What if savegames are just checkpoints instead of serialized game state? What if you render so little data that you don't need complex visibility checks, etc etc etc...

Simple 2D games don't need all the runtime components that a triple-A game needs, yet a game engine for 2D games is just as much a game engine as an engine used for triple-A games.

[Buttons840]

Does every game have an engine?

This is a good time to point out we're really arguing over the definition of a word here, and can probably agree on a lot of facts and observations, even if we don't agree on what the definition of "game engine" should be.

[flohofwoe]

Exactly, the deeper you dig, the more the "engine" just disolves into lines of code. Where does the engine HAL end and where do operating system services begin? Is libcurl considered part of the engine? Maybe if it's linked to the engine code? But what if the curl libs are part of the OS installation?

And on the opposite end, if the Unity editor is considered part of the engine, why not Visual Studio, Photoshop and Maya/3dsMax/Blender too?

In the end, the engine is just that fuzzy layer between the high level gameplay code and the operating system (going with my own preference that "engine" should only be used for the runtime parts).

[matheusmoreira]

> Does every game have an engine?

Yes.

Engines are essentially loops. There are many examples of engines in software and hardware. Processors, virtual machines, emulators: they are execution engines looping over instructions that they decode and execute. Game engines are the same: they loop over user input, logic and audivisual output. Every game will have this loop deep inside, no matter how it was programmed. It is essential to their operation.

Modern game engines are generalizations of that loop. People took the common functionality from successful games and separated it from the game-specific code.

[kevingadd]

Even the mainstream 2d engines like game maker provide a lot more than just physics and graphics.

[skohan]

It really depends on the games you are making. Not every game needs nav meshes for example.

For things like audio and asset loading, you can get really far building on top of a library like SDL2 or GLFW as a cross-platform system interface, and using some single-header libraries for things like loading models or playing audio samples. There are also great physics libraries out there like Chipmunk or Bullet which neatly encapsulate most of the "hard stuff" in building a game engine.

For something like a 2D platformer for example, it's perfectly reasonable and easier than ever for a solo developer to take on building a small custom engine.

[NicoJuicy]

Play("sound.wav");

Load("Asset.png");

That wasn't so hard