My first idea was to implement the game engine core as a general subsystem so that the games that were built on top of it could use those susbsystems as general interfaces. So the core system was built as a DLL and the client (game) used that to assemble the game logic with needed components.
The first version of the engine will have the following susbsystems:
IDE Folder and Files Organization
The project structure is following other game engine projects organization where the core engine code base is separated as DLL project and the client game code is referencing the game engine source code as dependency and have their game logic calling all needed game engine systems to implement the game features.
Math: That will handle mostly by now 3D math calculations as vectors and matrix operations
Physics: That subsystem I integrated with a middleware physics engine once I was not planning to do myself from scratch
Renderer: The susbsystem responsible to prepare, process, and assemble vertices and pixels to render frames to the screen
System: This one will tackle the initialization of the main componentes of the engine (window system, resources, game logic, input, rendering, etc)
Resources: Responsible for loading resources of the engine as needed. For example, the render needs vertex and index buffers to hold vertex data, actors of the game mostly have a 3D mesh. When to load these resources and how to unload them is the main task of that subsystem
Game: Here all entities related to the game world will be represented. World tackles information about all actors that exist in the game, as actors represents all objects in the game, Camera tackles information about perspective field of view angle, position, aperture, ISO, etc.
The game client then is responsible first to setup the game, which rendering and physics api to use, specify the game data, start and shutdown the application.
The following snippet code is common to all games using the engine:
Engine Entry Point
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When doing the setup on the engine, rfConfig class stores this data coming from client (game) and visible to all susbsystems when they need access to.
Engine Configuration
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Regardless which API is being used for the subsystems they are abstraction functionality to process game engine data.
The renderer will be initiated as well as the physics susbsystem and the window subsystem not entering into implementation details.
Subsystem factory pattern initialization
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Each subsystem is an interface that derived classes will implement the Initialized function returning whether the subsystem initiated properly or not.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For instance, when starting the renderer subsystem the engine first create the renderer instance based on configuration and each initialized function is implemented differently depending on the subsystem features and commands.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters