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.

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:

Game Prototype 25/07/17

We have chosen "Sol 2" as the name for this game, so from now on the posts will be named as "Sol 2" + current day.

I'm now in the process of implementing an Audio system in the Game Engine. I have never done such thing before but I'm not expecting it to be really difficult because I'm using the SFML library for handling windows, input, audio and networking.

Game Prototype 23/07/17

Help us chose a name for the game!
Here is the Strawpoll.

Game Prototype 22/07/17

New update! Well, I didn't actually add anything new but, my friend Joana just finished one of the soundtracks in the game. Feel free to check out the soundtrack on her Soundcloud page!

This weekend I'm not at home so there will be no updates with new stuff added to the game for a while.

Game Prototype 20/07/17

I've finished the in-game GUI & HUD and added a Debug GUI! I've also added the ability to place buildings (even though I only have one enabled now). 

Here is a screenshot:

In the top right you can see the Debug GUI with some profiling info. It still isn't finished but it will contain some cheats in the future.

In the bottom of the screen there is the building selection menu, but you can see that I only have the AA (Anti-Air) turret in the menu for now.

(Recap) In the top left and center you can see some info used in the game such as HP (health points) and the resource amounts (for both Energium, the pink one, and Materium, the blue one).

Here is a video showing the building placement in action:

In the next update you should expect to see something related to gameplay (probably resource extraction and storage).

Game Prototype 17/07/17

I'm now back home and I've almost finished the in-game GUI.
Here is a pic:

Now I only need the turret selection menu.

I've already added the HP, Energium and Materium bars as seen in the image.

Some time soon you will see the turret selection menu working.

Game Prototype 11/07/17

While I'm away from the computer where my project files are, I'm taking advantage to plan some stuff ahead that I will do once I arrive such as the game GUI (Graphical User Interface).

Here is an image I made on paint.net showing how I'm thinking it should be:

(this is not already implemented, it is just a preview)

In the top left you can see the two resource bars, the Energium bar (the yellow one) and the Materium bar (the blue one). They show how full is our resource storage and how much resources we have.

In the top center there is the HP bar, showing how full is our HP.

At the bottom center there is a menu where we select what type of building we want to build (drills, turrets, resource storages, etc).

It is based on the tower construction menu on Savage Moon (PS3 game I played some years ago):

As you can see I'm trying to make the GUI as simple as possible to use, and as small as possible too, as I dont want to have the screen filled with buttons and other stuff.

I will also implement a debug menu with cheats so I can test gameplay mechanics without having to spend 10 minutes every time just to wait for the enemies to arrive.

When the GUI is implemented I will post a video on YouTube showing how it works.
If you have any suggestions or questions don't hesitate to contact me by posting a comment on this blog.

Game Prototype 10/07/17

Sorry for the lack of updates recently, I had been studying for the final exams and now I am in holidays. One more week and you should expect to see some new stuff on the Game Engine such as:

• Lua scripting capabilities (only needs some polishing now);
• GUI system (partially implemented);
• Font loading using FreeType library and rendering text to GUI (currently working on this);

Meanwhile a friend of mine is working on the HUD design for the game. Maybe in two weeks I will have the HUD finished.

Game Prototype 18/06/17 - Gource

This is just a quick update, I just recorded a video of the progress on the Prototype using Gource and I would like to show you:

Game Prototype 18/06/17

Sorry for the lack of updates recently, I've been busy studying for the final exams.
This time I've given up on making my on physics system because it is really hard to do something good enough, and it will probably end up really slow. So, instead, I opted by using Bullet Physics. So basically what I've been doing is creating a wrapper for Bullet on my Game Engine. Here is the result:

As show in the video, integrating Bullet on my Game Engine means that I have now collisions working between the player and the terrain (will also be used for projectiles, such as missiles).

You can also see I made some models for the terrain (temporary).
In the next post I will probably have already added a Resource (game resources, not models, textures, etc) system, where I store data about how many Materium, (further explained in the game document) for example, the player has.
This will be essential for the functioning of the Prototype.

Game Prototype 14/06/17

I have been having some problems lately with the FPS. In a frame, it took 16 ms to render, in the next one, it took 300 ms to render. This was weird because sometimes it didn't even happen. I started commenting every piece of code until it stopped doing that and I ended up finding that glGetUniformLocation was the culprit.

I also created a class structure for the game. For example, I have a BaseUnit class (base class), which MovingUnit and StaticUnit inherit of, and for now, I only have another class, the Player class (inherits from MovingUnit).

So, now we have a player which we can move with smooth camera following and other stuff.

Warning! Programmer Art bellow, viewer discretion is advised.

(I know the model is horrible, but it will have to do for now)

I might add some decorations to the terrain in the next update.

Game Prototype 09/06/17

I have moved to work on the Game Logic part, so the new posts will be titled as "Game Prototype <date>". But that doesn't mean I'm not adding more features to the Game Engine, as when I need a new feature I will just add it.

As to what I've been doing lately, I started creating a terrain system. It isn't anything too complicated, the terrain will be just a giant plane with a texture and some rocks and other deco placed on it. The ground will be moon-like, and should look very alien.

Here is the Google Drive document containing info about the game. If you refresh the page you maybe lucky to see new content being added as it isn't finished yet :P.
BTW thanks to my friend Tiago Neves for the amazing formatting XD.

Game Engine 08/06/17

After a week of trying to get CSM (Cascaded Shadow Mapping) working I finally did it. :P

I had a lot of problems finding info about it on Internet because most websites didn't have everything I needed so I had to scavenge a little.

Here is a video of the new shadows:

Now I'll finally start working on the Game Logic. Me and a friend of mine are creating a document containing basically everything the game will have and how it will be. It's a kind of a mix between Supreme Commander and Tower Defence genre but it's played in 3rd person (we have a character).
More info will be released with the document.

Game Engine 31/05/17

I've finished implementing shadows + deferred rendering and I had some frustrating errors relating to shadow acne and transforming camera view space to light space, but I managed to go fix it all.

Here is a video showing the new looks of the graphics:

For shader loading I wrote a "compiler" from a customised version of GLSL to normal GLSL.
For example, I can write this:

$$VERTEX
// This becomes the vertex shader

$Position$ in vec3 vertPosition; // Automatically assigns this attribute to the vertex position

void main() {
    [...]
}

$$FRAGMENT
// This becomes the fragment shader

out vec4 fragColor;

void main() {
    [...]
}

All of this makes it easier to write and store shaders (single file, instead of multiple).
I'm might add CSM (cascaded shadow mapping) as it is better for large terrains and spaces.

Game Engine 30/05/17

Okay I just finished implementing SSAO (Screen Space Ambient Occlusion) with OpenGL and GLSL on my Game Engine and it's working pretty fine.

Now there is a feel of depth that wasn't before. Here are some images to compare before and after SSAO.

Before

 After

As you can see it's way better now but I think it still looks strange. I'm planning to add shadows to make it look nicer.

Game Engine 29/05/17 - Part 2

Here goes the part 2 of my Game Engine showcase.

More systems and functionalities I have in my engine:

• Framework: Basically this is the engine core, everything depends on this chunk of code to work, here we have things I already wrote about such as the FileSystem.
• Locator: Maintains pointers to services, for example, the moment I startup the Graphics system, it provides itself to the Locator and the Locator stores a pointer to the system. Now when I call Locator::GetService<Graphics>(), I get the Graphics system in return.
• Service: Used by Locator as described above.

• Physics:
• Physics: Manages Rigidbody's  and updates them.
• Rigidbody -> Component: Applies basic physics to GameObject, for now its only used to apply forces to a GameObject, such as gravity and drag. I didn't add collisions because i wont need it for the game I'm making.

• Collisions:
• Collisions: Manages Collider's and updates them.
• Collider -> Component: Tests collisions between other colliders, if there is a collision, notifies other components of the GameObject of it.
• Derivatives of Collider: Tests for multiple shapes of collisions (BoxCollider).

Here is what I'm already able to do:

As you can see I can now load models (with skeletons, meshes, materials, textures and animations) and render them unto screen. In this case I'm not loading an animation, this animation is done on the fly.

It took me a week to only get skeletons up and running because there is little documentation on the internet about it.  What really helped me the most was this website I found after some digging. I had already done some stuff with skeletal animation a year ago and I had the same problems.

I'm planning to add deferred rendering which I will talk about in the next post.

If you have any questions or suggestions post them in the comments or contact me through email: riscado.antunes@gmail.com

Game Engine 28/05/17 - Part 1

I didn't upload messages to this blog for a long time because what i was making wasn't really visible.

Now I have made a lot of progress and I'm planning to start working on game logic in a week or two.

Here is what i've already done:

• Messaging System:
• MessageBus - Handles messages and sends them to the message listeners
• MessageListener - Receives messages to MessageBus. Can also send messages to other listeners through MessageBus.
• Message - Has a void smart pointer pointing to its data and also has a type. MessageListener's can subscribe to certain types of messages.

• Resource System:
• ResourceManager -> MessageListener - Stores resources and sends them as needed. A resource can be requested through messages.
• Resource - Used to store data about many things such as Model's, ShaderProgram's, etc. Also used as an interface to load the data.
• Multiple derivatives of Resource (ModelResource, ShaderResource, etc.).
• ResourceRequest - Serves as an interface to sending messages and requesting resources, making it much easier.
• FileManager - Platform independent class to read resource file tree and load files.

• Graphics System:
• Graphics - Handles Renderer's and everything relatable to graphics
• Renderable - Anything that can be rendered unto screen (pure virtual class).
• Renderer -> Component - Used to draw a Renderable (BTW Renderer's have layers, such as the Transparent layer, the Default layer, etc.).
• Window - I'm using the SFML library for handling windows, UI, networking and other utils. If you haven't checked it out, you should, it's really useful for small projects.
• I also have derivatives of Renderer (ModelRenderer, etc.).
• That's it for now. I'm planning to add AO (Ambient Occlusion) in some time.

• Scene System:
• Scene - Handles GameObject's and Component's. Also updates Behaviour's.
• GameObject - A bunch of Component's tied together with a Transform and a parent GameObject. Also serves as a mini MessageBus for components.
• Transform - Specifies a transform for anything (Translation + Rotation + Scale).
• Component - Basically every functionality of the Engine uses this. Basically, it's just a piece of code to be executed by some System (for example, Renderer -> Graphics).
• Behaviour -> Component - Everything that is related to game logic derives from these. They are updated by Scene.

I also have made a basic Physics and Collisions systems, which I will write about in the next part.

Feel free to write suggestions in the comments or ask questions. You can also send an email to riscado.antunes@gmail.com if you want to ask anything.

Game Engine 23/04/17

So i've restarted the work on my game engine and i'm taking as basis the following books:

• Game Engine Architecture (2nd edition)
• Game Programming Paterns

My engine is message based and will use game objects/component architecture. I already have the basis for the system, such as the MessageManager class (sends messages to the target systems) and System class (receives and sends message from/to MessageManager).

I also created the following systems (classes that derive from System):

• Console: receives input from the player and allows me to fake other systems by sending messages and receiving them;
• Graphics: handles window creation and destruction, handles OpenGL calls and Renderer components (a component that can be put on GameObjects to draw them);
• Resource Manager: handles resource loading and destruction, manages file tree and prevents resources from being loaded twice.

I will continue posting here the changes i make.