The engine itself is divided into 4 main modules : SDK, editor, player, and plugins.
- SDK: The main codebase of the engine. Most general-purpose and core code goes here, like the renderer, gui, entity/component, visual scripting, etc... . Below a screenshot of my first project made with this SDK, that time around still creating a dedicated exe for the project:
- Plugins: After my first project, I wanted the engine to become multi-purpose. I had multiple different games in mind, which would all require different functionality. Best example is being able to create 2D as well as 3D games. I didn't want to rely on hackarounds for this, and didn't want to expose functionality that isn't needed for a certain kind of game as part of the SDK, so I came up with plugin-support. Everything game-specific now goes into a plugin. For example, there is a camera class in the SDK, but there is no explicity camera handling, this is part of the plugins. Also the editor "game view" is something that must be programmed by a plugin, to support 2d and 3d games, without the unity-approach of having to view your 2d scene via a 3d camera in editor mode (wtf...). Also stuff like lighting, shadows etc... goes all into plugins. The SDK has a highly abstracted rendering framework, and the plugins use those to implement the actual rendering. This makes the SDK itself independand of certain technologies, more expandable and flexible for the future.
- Editor: For making anything but trivial (and limited in content) games an editor is absolutely necessary. I started to creating a fully-functional editor when I got tired of editing config-files via hand, and started to polish it up once I started to port my 10-hours gameplay Terranigma 2 project to the engine. So the editor basically is built of the SDK. I don't like the approach of developing everything editor-centric, so the SDK is independant of the editor, minus some minor features that just have to exist in there because it is needed i.e. for modifiying some component-value with an UI-element. Below a screenshot of the editor how it currently looks like.
- Player: The players main purpose is to be able to create games without an ounce of programming. I don't want to create a new visual studio project for each new project - while I learned that there where shortcuts (like auto-creating and setting up such a project), it really isn't necessary eighter. The plugins are good enough to customize the games as I pleased, so there is no point in having control of how the runtime-exe is setup. Currently the player is very primitive, just running from whethever plain-text config/xml-files/data a project is made out of. In the near future (read: once I get close to releasing a complete project with it) I will implement specific packed file formats for faster loading times and smaller storage size.
_________________________________________________________________________________________________________________
So thats the basic architecture of the engine. My design philosphy was simple: Do most general purpose in the SDK, build editor and player on top of that, make plugins for everything specific using the SDK and being used by editor and player. For that reason, SDK is mostly clean and developed very carefully, while I don't mind a few shortcuts and hacks here and there in the editor and/or plugins. The SDK also takes up most of the code -. 120k LoC vs. 28k Editor and 2k player. For that reason, it is furthermore devided into several submodules, which I'll end the article with briefly adressing:
- Audio: Loads and plays audio-files
- Core: A module for putting stuff together - state machine, scene/generic resource management and the plugin-interfaces all goes here
- Entity: The entity/component/system-module, with support for prefabs, system messaging etc...
- Event: The visual scripting module, minus all the vital GUI stuff (this is in the editor)
- File: Wrapper and helper-functions for file operations
- Gfx: The main graphics framework with classes for textures, meshes, etc...
- Gui: All basic gui stuff - widgets, rendering, handling...
- Input: This module transforms raw input into user registered actions, states, and so on.
- Math: Basic math classes like vectors, matrices, and a bunch of helper functions
- Network: A small networking libary (I only did on small-scale network game yet)
- Physics: Well, its physics. Rigid & soft-bodies are supported, and its designed for 3d (I'm uncertain whether making it 2d-capable is better to be build in here our just make a different physics module)
- System: Basic stuff like assertion-macros, logging, string-conversion and a ton of helper-functions for the STL, etc...
- XML: My own primitive XML-parser. I told you I don't use 3rd-party libaries, stop shaking your head
_______________________________________________________________________________________________________________
So thats about it for this time. Next up, I'll be discussing the developement of those sub-modules in more detail, starting with the GUI (since this was the first thing I actually designed). Thanks for reading, and until next time!
PS: here is one final screenshot of the most-recent project we made in a team of 4 with my engine:
