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.

Game Engine 08/08/17 - Messaging System Overhaul Part 2

My MessagePool class works the following way when allocating a message:

1. Search for a free memory slot;
2. Allocate on the slot found and mark the slot as occupied;
3. Create a MessageHandle pointing to the slot location;
4. Return the MessageHandle.

The MessageHandle class manages the amount of references its Message has. In the MessagePool's Clean() function, the MessagePool searches for messages with 0 references to them, and deallocates them, marking their slot as unoccupied. 

When passing around messages between EngineModules, the moment there are no more MessageHandles the message is deallocated.

In the next post I will write about the ConsoleModule & CommandModule classes.

Game Engine 07/08/17 - Messaging System Overhaul Part 1

While working on enemy movement I found myself stuck with this engine's limitations. I have found lots of problems with my current design regarding game objects receiving info from other game objects, searching game objects and the physics wrapper, that is a mess.

For the reasons I've mentioned above, I've started remaking the skeleton of the engine.
I've already made some significant progress,  such as a Messaging system overhaul.

I remade the entirety of the messaging system. In my original engine the messages were classes with an enum identifying their type and a smart void pointer.I honestly didn't like this design really much as it was quite hard to show messages and create messages on the console, for example.

Now the Message class is derived of the class Serializable, containing two virtual functions (Serialize and Deserialize), so I can convert messages to strings and vice versa. The different types of messages are now derived classes of the base class Message, implementing different versions of the serialize functions.

Last but not least, I have created a MessagePool class, where messages are created without allocating new memory (way faster than before and prevents memory fragmentation). Now, instead of passing messages around with smart pointers, I use a MessageHandle class that destroys the message automatically when it was already processed by everyone.

(taken from the Game Programming Patterns book by Robert Nystrom)

Tomorrow I will make a new post going more into detail regarding the MessagePool class

Sol 2 03/08/17

Sorry for the lack of updates recently as I've been away from my computer for a while.

I've now finished the resource system and structures (drills & storages) and also added a cost when we try to build new structures. I'm now starting the work on enemy entities (you can also see a new turret) but there isn't anything yet to show.

Last but not least I've implemented an Audio system so now I can play the game soundtrack my friend Joana made.

I'm hoping to have something to show in a week or two, maybe even finally an objective.

Here is a video showing the new update: