Magma Engine - 02/11/17

Its been a while since I updated this blog, due to school starting.

I've decided to make my new game engine open source on GitHub so if you want to check it out and contribute here is the repository.

Sol 2 - 13/09/17

So I've finished the Sol 2 prototype on Unity and I'm going to restart the work on my Engine.
Here is the link to the game.

I will probably do way less progress from now on since school is starting., but I will try to post here the problems I face while making the game engine.

Sol 2 - 25/08/17

Sorry for the lack of updates recently. I've found myself out of time and school is almost starting so I've decided to create a basic prototype of Sol 2 on Unity and then maybe port it to my engine.

I already made substantial progress and the game is already playable. By the end of August the prototype will be must probably finished.

Game Engine 16/08/17 - Graphics Module

I'm now readapting the GraphicsModule to the new Engine framework and also redesigning its skeleton. I have a VertexArray class & a Shader class, which have as child classes, for exemple,
OpenGLVertexArray and OpenGLShader. The GraphicsModule has two functions named GenerateVertexArray and GenerateShader which return a VertexArray handle and a Shader handle, respectively. This way I have a layer of abstraction between the Graphics API & the Engine.

I also have a OpenGLGraphicsModule, which overrides the functions so it creates the right VertexArray & Shader types and also handles all the OpenGL related stuff.

All the other classes use VertexArray and Shader as basis. For example, the Mesh class uses a VertexArray, avoiding direct OpenGL calls for flexibility.

Game Engine 16/08/17 - Component registration

While designing the new SceneModule (handles the creation and destruction of GameObjects & Components) I wanted to create a Component Factory that would allow me to create Components using their name string and register them.

So I created a static std::map containing the functions necessary to Component creation. Then I would register them using a static function named RegisterComponent. Sadly, I had to register the components at run-time and it wasn't really useful while creating new component types. So I created a static bool in my component types that when initialized would call the RegisterComponent function. This wasn't very clean still so I created two macros:

• ENGINE_REGISTER_COMPONENT_DECL: declares the static bool inside the class;
• ENGINE_REGISTER_COMPONENT_DEFN (type, typeName): defines the static bool, registering the Component of 'type' with the 'typeName' chosen.

Now, when I want to create a new Component, I call the SceneModule CreateComponent function, specifying the parent GameObject and the type string. This function calls the corresponding create function stored on the static std::map. This way I can even create new components using only the console.

Game Engine 14/08/17 - Console Module

One of the features that I wanted to enhance in the Engine overhaul was the Console.
In its previous version, the Console wasn't much at all, and the messages sent to it weren't readable, nor there was the ability to send commands from it.

This time, I've created the Serializable class, that implements serializing functions for the derived classes (such as the Message class). By doing this, I can now print to the console the contents of the messages in a human readable form. This also allows me to do the reverse process, converting text to a message. This allows me to input messages into the engine for debug purposes and other stuff like that.

I created a Windows Forms app for the console, which communicates with the Engine through a Named Pipe.

Here is a video of the console in action (the Engine window is still empty):

You can also see that I added a Filter numeric up down in the bottom right of the console. This way, I can filter the less important messages (such as MouseMoved) from the console. Each message type has a verbosity value describing how important it is (the higher the number, the higher the priority).

Game Engine 09/08/17 - Engine Services

While redesigning my Game Engine, I decided to separate different engine functions into different classes derived from a base class EngineModule. Modules can be located through the EngineLocator class, containing weak pointers to services provided.

At this point, I have the following modules & services:

• CoreModule - Manages Engine startup and termination;
• GlobalsModule - Manages Engine global variables (variant type variables, can be either strings, floats or booleans);
• LoggerModule - Logs the messages sent in the engine, depending on the implementation;
• CommandModule - Receives messages containing engine commands and executes them (such as sending messages & creating global variables, this class is primarly for debug purposes);
• ConsoleModule - Allows the user to execute engine commands and shows messages sent;
• FileSystem - Implements a layer of abstraction between OS calls to write and read from files and the engine;
• ResourcesModule - This one is where I'm working right now, manages engine resources, loading and unloading them as necessary.

All of these functions can be overriden without affecting the rest of the engine, making it way easier to implement crossplatform support.