Engine Architecture Overview news

SugarBombEngine architecture is designed the way to make it easy for developers to work with the engine and to keep it simple for players

The engine is modular like Gamebryo, but unlike Gamebryo, which uses ABI incompatible approach (direct export of C++ classes), SugarBombEngine API design turned towards id Tech engine family approach, which is using C API, though, SBE actually uses C++ virtual interfaces with all potential issues removed from the interfaces so they're mostly can be viewed the same as C structs filled with func pointers. What this decision allows is to be ABI compatible between different compilers and different versions of the same compiler (hi MSVC)

Gamebryo actually allows to build all its modules as dlls, but they all will be dependent on a specific version of a specific compiler they were built with. In addition, Bethesda develops its games for game consoles first, and only then ports them to PC. Because of that, they compile all the engine modules into a set of static libraries and then link them all into a single executable. The same goes for PC for the ease of maintainability. id Software did the same for "BFG Edition" so unmodified Doom 3 BFG version actually can't support the game dll, despite having the supporting code (which is left from DOOM 3 and broken) and also built as a single executable. This is completely fine for players, because they will only use the app to launch the game. For developers, though, it is easier to have all, or most of, modules built as separate dynamically-linked libraries that potentially can be plugged-in (loaded/unloaded on-the-fly) and hot-swapped during the application execution time. So SBE will be designed this way to keep both sides happy

The actual architecture will partially mimic the Gamebryo (2.3). Some of the modules will be structured the same way, but a couple of things will be done differently to make the codebase potentially reusable by other projects (aiming to reimplement other Bethesda games). One of such things is the game framework module, which will be the mediator between the application and the actual game module. The framework actually shouldn't necessarily load the game module, all the game-specific code can be located inside the framework as well, it's separate because of convenience. The framework module can be implemented to support games of RPG genre. This will allow to reuse it for all the Bethesda games reimplementations (to some degree), for example. At the same time, it will be possible to swap the framework to another one, which is oriented on, let's say, racing games. And it will work just fine

Some of you might notice some similarities to CryEngine, and I should agree that there are some similarities, though, funny enough, they're not intentional. The SugarBombEngine architecture as it is now was designed to make it easier for developers to work with the engine and make it easier to adapt the engine for any game genre if there will be need

Speaking about F3BFG and its multiplayer-oriented nature I should also mention that the architecture was planned to be multiplayer-aware from the beginning. What that means is that there will be two separate modes supported without any recompilation required. One is the "listenserver" (or host) - a client that could potentially run a local server, to play singleplayer or connect to remote servers. Another one is the "dedicated server", which just runs the game logic without the local client support, required for multiplayer games and best performance. The game framework module contains logic to load the game module and provide access to engine APIs. It will also load the networking module in case we need multiplayer support. The game module contains logic for both client and server (that's not the best solution, and even Carmack himself admitted that), but it's fine for our purposes, because we're not trying to create a competitive game, so we don't need to care about cheating. The dedicated server will receive null pointers/objects for sound/rendering/other client-side functionality, so the game module will remain usable by the server even having client-side logic inside (without any client-side game logic dlls or custom dedicated-only builds required). There will be two types of application - for client-side and for the server. They both derived from the simple application which provides an app framework to allow it to easily manage the app lifecycle (init, shutdown and run it). Both client and server app types will load the game framework module and interact with it and the only difference between them is that the client app will additionally load other client-side modules (like sound, input and renderer, and this is actually what Gamebryo app does) and provide their APIs to the game module while the server app will pass in null pointers/objects instead

So, without going any deeper into details, this is the brief explanation of the planned architecture for the SugarBombEngine. Of course, it's not the best possible, but it perfectly fits this project. Hope you find this article interesting and informative. If you have some questions you can leave them in the comments section