I've been taking The Cherno game engine tutorials and enjoying them so far. However, I do have a question:

I notice he puts the main while loop in the engine library dll. The game executable only create an object from a class with the Render(), Update(), etc functions which are called from the engine library dll's main loop.

I'm wondering if this is what people usually do when creating their own engines. I know there's no one single way of doing things, but I would have imagined normally the main loop is on the game client and the Engine library just provides everything I need to run a game (renderer, loaders, etc)

First it depends on the scope and type of “engine”. If you go for something large-scale with an “automatic” front/backend like unity or unreal then you pretty much have to supply the whole game-loop yourself.

On the other hand, if you have something that is more along the line of a framework that other people can use, then you could also have people implement all the game-loop etc… itself.

I prefer the first approach, but mostly because I go for the Unreal/Unity-approach with my game-engine. Also I find that game-loops and initialization-code can get quite large, and I also wouldn't want users having to spend a day to just get started and having to think about how to put very basic things together.

I'm on the opposite site of the table. My code is granting as much freedom as one needs to build a good game and so I don't have an “Engine Object" one would instantiate. Anything I do is providing a macro that is implemented in any class and not just covers the usual “main” function for different platforms but also runs the setup/cleanup code needed and finalizes for example my Allocator instances to assert if memory leacks have been detected. The game loop runs in a user defined function the code is just calling after setup and before finalize in the implicit main function.

I don't know of any other engine handling it this way, however I saw this first in Urho3D on GitHub.

Anyways, as we tend to reach a full asynchronous approach and so need to handle also setting up and running the thread pool/task scheduler, we might change or expand that to another macro which loads the initial task instead but that's subject of the future and it won't change the principle of granting highest possible freedom to the user

Thank you all for the replies, interesting seeing different opinions on the topic. Granted, this is a lot of fun. Thanks again!

EBZ said:
Thank you all for the replies, interesting seeing different opinions on the topic. Granted, this is a lot of fun. Thanks again!

Yeah, indeed. Keep in mind that as with most things in programming, there is usally a tradeoff. At a certain point, you cannot maximize both freedom and convenience for the user. Its certainly possible to eigther go into any of the two extremes, or alternatively seek to strike a certain balance. But at certain points you'll have to ask yourself: Do you prefer to be able to give maximum control to the users and accept that it makes the application more complicated/unsafe to use; or do you prefer the convenient solution that disallows certain customization?

On the extreme side of things you have unity which makes it very hard to customize certain aspects (and their attempts to give you back control comes across like somebody locking your front door and then making a tunnel just to get back out). But its also possible to give users a plugin-based approach which still doesn't force them to be a 3rd-class citicen (which I try to do with my engine); just as there can be approaches with libraries that you have to integrate all yourself that might be easy to use. My point towards Unity is that I'd actually rather prefer if the “professional" workfield was a little bit more filled with solutions that give more control towards users; as it is with Unity dominating the indie-scene, makes me not very happy.

On the other hand, I have concerns about plugin performance and being able to debug a plugin based environment is hard to achieve. Havent seen your system yet but from experience, it is a pain in the a most the time.

Our approach is to offer certain modules via NPM you can integrate into your project. Those modules stand asside in their own directories and are part of the project only when referenced somewhere in your code (our build tool manages this). So you always have full control over how your code looks like and behaves

Shaarigan said:
On the other hand, I have concerns about plugin performance and being able to debug a plugin based environment is hard to achieve. Havent seen your system yet but from experience, it is a pain in the a most the time.

Hm, I don't really see how those concerns apply to plugin-based approaches. Maybe my own solution is just so good, but there are really no performance-concerns or problems debugging at all that come from using plugins specifically. What problems did you exactly encounter with debugging plugin-based systems in the past?

Shaarigan said:
Our approach is to offer certain modules via NPM you can integrate into your project. Those modules stand asside in their own directories and are part of the project only when referenced somewhere in your code (our build tool manages this). So you always have full control over how your code looks like and behaves

Note that I'm not really talking about plugins in the sense of necessarily having DLLs that are dynamically loaded into the engine; but more about users writing custom code for the engine via means of extension instead of setting up your own compiled game/editor-exe(s). That could still mean that you statically compile the users “plugin”-code or whatever, it just means that the engine supplies the binaries itself w/o requiring the user to do so themselves.