where should the main function and game loop live in a game engine?

Should both live in the engine or game? or should the main function belong to the game while the engine contains the game loop (or vice versa)?

The question suggests you're not ready to make an engine and should focus on making a game or two first.

Engines manage their own lifetime, including the life of game loops. Engines provide hooks for the game to attach to at startup, and hooks for parts of the game at most key events.

There are plenty of game development libraries, development kits, frameworks, and toolkits that provide game functionality for games that don't use engines. In those cases, the game itself typically manages the game execution because there is no engine doing that job.

have organized my Visual Studio solution so that the engine is built as a static library, while my editor (or game) is an executable.

Then you're likely not making an engine, you're making a library or middleware.

Is there a rationale or trade-off to consider here?

Yes.

The words have meanings. “Game engine” has meant something for the past three decades.

The bigger purpose of an engine is to pull the gameplay parts away from all the infrastructure such as the game loop, game world/scene processing, physics processing, graphics processing, animation processing, math processing, audio processing, input processing, file management, network processing, and more. When a good game engine matches the type of game being made there is relatively little software development to do.

For example, people can make no-code games with Unreal that are multiplayer matches on Steam and EGS. Out-of-the-box there are example multiplayer game projects that require no source code. Developers can tie together engines, middleware, and external libraries with their own assets using nothing more than data to the engine.

People can (and do) develop games using their own game development libraries, development kits, frameworks, and toolkits and leverage them for the various systems, but that's not an engine.

From a design standpoint, main() should definitely be with the game. Otherwise your engine isn't really an engine, it's an application. The loop is a little more flexible, some people like it in the engine, others like controlling it in the game.

The loop could be in the engine, but only if you want every game/editor to use the same loop. If you think you'll need custom timing/flow later, leave it in the game too.

Write a game or two, or three or four, see what code they have in common, extract that into a game engine. That is what a real game engine is. Car engines aren't built in isolation, they are built for cars, and these cars have specific common properties that the engine targets. If it doesn't fit at least one game well, it's a waste of time, besides the experience itself of doing some rendering, audio, input handling and file management etc.

Everyone (including me) just starting to write a “game engine” is perfectly analogous to people writing compilers by writing a parser and then an abstract syntax tree and then doing stuff on that, without ever having written a code generator and having no clue what constraints a code generator imposes on the ideal compiler design. They do eventually finish writing a “compiler”, but it's usually completely inefficient, mallocing and freeing all over the place, missing caches everywhere, and mostly just shuffling trees around, instead of being streamlined and focused on the actual bare minimum essential and useful work it needs to do, at all times.

@d34dl0ck3d

Lets see…where to start?

What do you imagine an “game engine” is?????

Because all options are valid, context is much more important, what do you want to build exactly? Why are you even considering spending years of your life doing something as foolish as a game engine?

If main() is in the “engine”, you are sandboxing your games, you are building a “console” that start games. The order of operations change and your games will only see hooks to be informed when to do things (besides all the lower level APIs it may have access to….)

If main() is in the game side and it controls the game loop, I must say your “engine” is actually just a collection of APIs that offer low level abstractions to complex operations, a framework if you will. There are plenty of those around for you to try and see how they manage things around (may I suggest you start with Raylib?!).

That said, by definition, any game engine IS just a collection of APIs and a framework, but it needs some little extra features to be called an engine.

(if you are making a collage of many external libraries, that is something different and you are wasting everybody's time by calling it an engine, including your own).

(no, a GUI level designer is not an engine either)

(or a high level OpenGL renderer for the matter…..no matter how fancy are your shaders :P)

frob said:

The words have meanings. “Game engine” has meant something for the past three decades.

Not trying to pick a fight, just quite curious of how the therm “game engine” has definitive and well defined meaning outside of vibes?

It's quite literally the part of the project that accelerates the game production, it could be considered anything.

We could also argue that, like engines, you can reuse it and build the vehicle around it… it makes the game go vrummmm…. but that is a later point of view.

To me, the engine is the workhorse. It takes care of the bulk of rendering, audio, maybe physics, etc. Everything that's not really specific to the game you're building, and could also be reused for another game. An engine usually also comes with tooling, but the tooling is not the engine. There are graphics engines, sound engines, etc. A game engine would probably have a graphics & sound engine, but also some other parts that are specific to game development. But at that point, “specific to game development” means you already have a specific type of game in mind whose workflow you want to lift into the engine. For example a chunk-based, tile-based game could have all the chunk memory management / swapping etc. in the engine, and the game only needs to fill the world with content and add behaviour to that content.

But the flagship engines are massive, bloated tool suites, sound and rendering engines, with all kinds of asset format management and probably also networking, and GUI functionality, maybe persistence, etc. But a lightweight game engine could also not have any tooling and expect you to just interact with it through code. Like there could be a pokemon game engine or something, that doesn't really need fancy tooling, and you just supply the sprites, animations, tilemaps, sounds, and the stats for each monster, and the levels. And it does the rendering and input handling and all that, and you just need to do stuff like dialogues and other custom triggers in the world, and that's mostly it.

That's why I recommend making a few games and then seeing what parts can be generalised in which way without losing the required level of specificity to stay performant. If you make racing games, you are under very different audio, video, physics, etc. constraints than when you're making a shooter or a pokemon game. General-purpose engines are a dumb meme. You can't solve any problem particularly well if you try to solve it for all possible situations. Choose your constraints, and own up to that, and make the best thing you can make for exactly that set of constraints. Then, you're actually creating something of value for those who are working under the same constraints.

Just like you wouldn't use a big number library with FFT to speed up multiplications for stuff that also fits in a register.

TooOld2rock-nRoll said:
It's quite literally the part of the project that accelerates the game production, it could be considered anything.

I doubt it, but possible.

I'd imagine if you took a poll of professional game developers and asked what an engine was, I'm guessing you'd find near-universal consensus with examples like Unreal and Unity leading the pack, possibly others like GameMaker:Studio, Godot, Construct, Source Engine, or id tech. People could probably throw other engines like Frostbite, CryEngine, Coretech, or even MonoGame in there, but the pattern remains with those too.

Next I'd take a look over at the Wikipedia article, which while it isn't authoritative it does represent the common viewpoints. It takes a bit before they mention specific engines, down in the history section, and they start with Unreal Engine and id tech, as those were the first two modern engines. When they get into game engines in the industry, Unity and Unreal are listed again as the main engines typically used.

Back in the late 1990s when the term originated people knew what it was because in part we knew what it wasn't. We already had terms for libraries and development kits and game construction kits. It wasn't those because they already had names. The new term of a game engine was how studios were taking existing games that had typically grown to include a sequel or two or three, or related games developed in a studio, and rather than starting from scratch with each game they abstracted their systems into a single program that managed all the core stuff, and allowed the game to load up as a module or library, along with editors and other elements as modules or libraries. Most that came after followed that pattern, where the game engine itself did it's own thing and almost treated the game as data to the engine rather than as the main program itself.

While each of those mentioned is different for implementation, they're all similar in regard to how the game fits in with the engine. Development with ANY of the engines over the past 30 years is about game logic, game objects, component/behaviors, and similar. They're all oriented around a game simulation / world that gets initialized, content loaded in, then the main update loop. Most games on the engines have the first level as a simulation / world that is nothing more than UI elements for the front end, then transition into a different simulation / world. Developers aren't doing the low-level stuff around program entry point, memory management, and hardware manipulation, instead developers focus on in individual game objects / actors / sprites / entities, their associated logic, and their hooks on various elements like update, tick, physics event handlers, network event handlers, UI and mouse event handlers, and eventual shutdown handlers. It is the engine itself that handles all the interaction with the system, including the function int main() or int WinMain() or similar, as well as the main game loop that runs the simulation or world. The game engine directs active objects / actors / components / behaviors / etc with their tick() or update() or similar functions rather than the game managing the loop that iterates over them.

@TooOld2rock-nRoll If I'm understanding your message right a key difference between something being a framework and engine lies in how they control the flow/the order of operations?

@frob @tooold2rock-nroll (sorry, the editor doesn't let me capitalise the name… No idea how @d34dl0ck3d did that — oh wait, that's just a link…) I think you're both arguing past each other. Everyone would agree that Unity and Unreal etc. are game engines, and that all the big engines are like that, where you basically point and click yourself through your game's development. But if you look at all the titles that ship their own in-house engine, you might be looking at something quite different. Yeah, it will have a level editor, probably, and other stuff.

But I think most engines that are built for a specific game, or for a series that a studio produces, are not like that at all. They contain all systems the game has, such as the specific NPC AI in an RTS, which while it is part of the specific game, would still be considered engine territory, and would be reshipped (with some improvements) in the sequel. Additionally, all the tooling the studio wrote (asset managers and all that) are also counted into the engine, even if they are separate programs. I think most engines just start out as a studio building a single game from scratch, more or less, and then reusing parts of it. In that case, you start out with a monolithic game, and the question of where the main loop is, doesn't exist. Because everything is the same project at first. And then for the sequel, you split it up, probably doing a big cleanup of the engine code, applying all the learnings you had during development of the game, and then you can decide what you want to do with the main loop. I think almost never does an engine start out as an engine, and almost always as part of a game that's written from scratch.

Even “the” Unreal engine, it was built specifically for the game called Unreal, and refined for its sequels. Although nowadays it's built for Fortnite and TV cinematics. And for example the CoD4 engine and its level editor were not at all like the monolithic Unity or Unreal. You had a level editor program, you had a level compiler/baker program, etc., lots of small tools. And to bake the reflection maps, it actually started the main executable of the game, loaded the level, and rendered all the perspectives of each reflection node. But if you wanted to add dynamic behaviour, you were expected to write your own script files in a somewhat C-like language, which then got compiled during level baking. No blueprints or anything weird like that.

The point of all this: just because all big “generic” engines nowadays are the same, does not mean that all engines have to be like that in order to be proper engines. And whether an engine owns the main loop and calls the game from a trampoline, or whether the game owns the main loop and calls the engine like an API, does not really matter. For some types of games, one design may be preferrable over the other. It's really just an implementation detail, and with all implementation details, its merit needs to be discussed on a case-by-case basis, because implementation details don't live in isolation, they live in the context of the rest of the whole program.

@d34dl0ck3d like I am arguing with @frob, it is not a well defined therm…. it's like porn, we know when we see it :P

But yes, your understanding is correct, although it's a very blurry line we are talking about.