In my Game Engine Architecture class we looked at several open source engines. My team looked at Godot ( https://godotengine.org/ ) with each of use examining one or two aspects of it. Here’s the complete list:
Bootstrapping by Nik Bair
Memory Management by Alex Hubble
Node Architecture & Physics by
I looked at the Input system and the Server Architecture
Input
GodotArchitectureUML.drawioThe Input Event class is inherited from Resource which handles memory management and is inherited from Reference which is similar to a smart pointer implementation. This is inherited from Object which is a general base class to just about everything in the scene.
Input Events are a generic form of input event that can be handled in script by overriding a base function. It has sub-classes for handling all the standard input including MIDI, but you can also generate custom events representing an action instead of just a key-press.
One thing I found interesting about this is the depth of the inheritance tree. After already inheriting three layers deep there is another class to deal with modifiers like shit and alt, and inheriting from that we finally get to the classes to handle key presses and the mouse. The mouse has two child classes to handle button presses and motion.
Server Architecture
When first looking into the Godot source code I notices a servers/ folder and ignored it because I assumed that it had to do with networking or hosting the game. Later when looking for the rendering pipeline I couldn’t find it until I stumbled upon an article by one of the lead programmers: https://godotengine.org/article/godot-3-renderer-design-explained. It turns out the servers are actually important parts of the game engine handling things like physics, audio, camera, and rasterization.
This server structure creates a clear divide between these systems and the end user as well as abstraction between them and the engine. The choice to use this system points towards a focus on making it simpler to make games while limiting end user modification (without getting into the source code). It also is a choice of maintainability and ease of modification over speed.
The architecture makes it easier for users by providing a clear API, and it makes the engine easier to maintain by separating the systems from the core of the engine. However, because of this separation it is slower to send data between the systems. Please check out the article linked above for a more detailed explanation on the rendering system and design choices. It’s an interesting read by Juan Linietsky who is one of the original creators.