To build the engine, you can download it or browse the source on Github. Inside the Source directory, you will find a number of directories:
- Engine: source files for the engine itself, broken out by module type (base, scripting, rendering, etc.).
- Game: source files for the “stub” game executable which loads the files saved by the editor into a playable copy of the game.
- Meta: the metadata generator used in building our game engine’s scripting and serialization modules
- Server: source files for the server in a client-server networked game.
- ThirdParty: source files for all of our third-party libraries.
- Workspace: workspace and solution files for Xcode and Visual studio respectively.
You’ll also find executables, resources the editor uses, and tools.
In the Source/Engine folder, you’ll find the main giga-engine.h. This contains the most basic includes we’ll need for our engine. While I have tried to keep the number of #ifdef WIN32 preprocessor statements to near zero, it’s not quite there yet so you’ll see one of those at the top of this file:
1 2 3 4 5 6 7
#ifdef WIN32 // Windows definitions - NOMINMAX defaults to STL; WIN32_LEAN_AND_MEAN minimizes Windows' includes #define NOMINMAX #define WIN32_LEAN_AND_MEAN 1 #include #endif
If you’ve ever worked with Windows much before, you’ll probably be familiar with WIN32_LEAN_AND_MEAN. This makes the Window’s header files slightly smaller. Also, defining NOMINMAX on Windows tosses the Windows definitions and leaves them to STL.
Another oddity you will see throughout the engine that you’ll be familiar with if you’ve worked with Windows is the definition of GIGA_API:
1 2 3 4 5 6 7 8 9 10
// Windows DLL export definition #ifndef GIGA_API #ifdef GIGA_EXPORTS // We are building this library #define GIGA_API __declspec(dllexport) #else // We are using this library #define GIGA_API __declspec(dllimport) #endif #endif
On macOS, this is defined as blank in our project files “GIGA_API=”. On Windows, this tells the compiler whether to export or import the symbols from the files for dynamically loaded libraries. Since we build our engine as a DLL on Windows, these are required. If you build the engine as a static library, these definitions can also be blanked out on Windows.
Next, you’ll find a number of standard system includes available on both platforms and the STL library headers:
1 2 3 4 5 6 7 8 9
// STL #include <vector> #include <map> #include <string> #include <algorithm> #include <thread> #include <mutex> #include <typeinfo> #include <memory>
We make fairly extensive use of STL throughout the engine. In the olden days, this would have been frowned upon, since the Standard Template Library was at least considered to be (if not actually) slower than rolling a more optimized version of basic containers. As a result, you’ll see many engines like Unreal have their own containers. However, if there is a performance hit now, it is negligible compared to the effort expended writing and maintaining your own code for these pieces.
And that’s it. Each module will also have it’s own basic header which will include relevant third-party libraries.