Introduction

Hello everyone, I will start this post by presenting myself (I promise it will be short). I am Simon, a C++ developper for more or less 15 years (8years professionally) and a life long RTS fan. I also always loved writing short stories. I am also an avid badminton player and competitor but that is less relevant.

I have played and loved many RTS games : Age of Empires 2 & 4, Cossacks, Warcraft 2 and 3, Starcraft BW and Starcraft 2 to name just a few.

I have always wanted to build games when I was younger. Then life goes by and the idea kinda felt of my mind. It went back in early 2023, inspired by some frostgiants interview when I realised that the skills I got in my professional career transfered pretty well to game development and since I like crafting complex programing systems (that's what my job is basically) and writing stories it makes a lot of sense to me to start my own adventure in my spare time.

The genre RTS was a no brainer for me. While it is a very complex I felt like building a solid RTS engine could be doable and if it was flexible enough that would allow for RTS to be easier to build.

I started in january 2023 a C++ engine that I called the Octopus Engine.

Octopus Engine

language

C++ as a language felt natural to me since it is by far the language I am the most proficient with, plus it is know the very efficient and RTS are mostly CPU bound. Not much thoughts on my part here.

High level concepts

Since I was new to game dev and rts engine in general I looked into different resources on the best ways to build one. Of course I do not pretend that my approach is the best but it feels solid enough for what I want to build : A robust RTS Engine.

Fully deterministic simulation

As I said before I build complex programs in C++ at my day job. And one of the most dreadful thing is a bug that occurs in a non deterministic way for whatever reason.

What does one need to do to achieve this?

Several point of attention are required to allow for fully deterministic behaviours

- Always seed random number generation

- be wary of multi threading (you need to ensure that thread output are always in the same order regardless of thread seed)

- Use Fixed point computing : this one is required to allow determinism between different computers

- Use regularly analyzers such as  valgrind (memcheck and helgrind mostly)

What do you gain from it?

As said before having a completelty deterministic engine allow for easier debugging.

It also enable must have RTS features such as : Loading and replay

Architecture

When I start the project I already had in mind that the first RTS game made with the engine will probably more of a tech demo that a fully made game. knowing that what was very important to me was to build an engine that would more of a plugin in another game engine or any display you want.

The idea came from a frost giant interview where they stated that they build their engin 'snowflake' on top (or under I dont know) of Unreal Engine.

Building Octopus outside of any Game engine allowed me to easily build it on many systems since it had almost no dependencies, easily set up unitary tests and efficent profiling thanks to callgrind (valgrind again).

However I needed a way to synchronized efficiently a display loop with the engine loop. To do so I took inspirated to well rounded display loop between graphic cars and screen : triple buffering.

The engine updates a state while doing expensive computations. then swap with the middle step if available. The display render the state and occasionnaly swap with the middle step.

Each system can work on a state (only the engine modifies it) without having to worry about data races.

But... The engine does three times the work!

Well yes... but actually not the heavy work.

The way it works here is that State are modified by applying a step to it. A step is an array of small delta that can be applied in the shortest amount of time because it is very simple operation. The expensive work is creating the step from a state and this is only done once.

Hidden benefit of this approach

With this approach there is a nice benefit coming : by making delta reverisble you now get a simulation that is able to rollback very fast! When time comes this can be used in multiplayer to improve lag compensation. You can simulate the game by assuming no commands came but if a command come then you can rollback and apply it. This has yet to be proven effective (in term of workload) but is an idea from Stormgate so I am pretty confident.

It also enables interesting gameplay ideas such as rewinding time in a RTS!

Fair and square

Fair and square is the tech demo for the engine. it is going to be a simple RTS wave survival game where you also need to get out on the map to survive and get unit upgrades.

Squares, triangles and circle live "here", "here" is composed only of simple shapes.

They all aspire to reach "there", where all shapes and forms exists. However gatekeepers prevent shapes from "here" to access it to avoid mayhem "there".

Display

As you could see in the previous image I started to use SDL2 to handle display. Why? Because that is what I used in the past and it was usable in C++.

It took me a bit more than one month to achieve this kind of display

Forgive the quite bad art.

It worked well the time it lasted but it quickly felt cumbersome to work with and the visual ceiling was pretty low.

Making the switch to Godot

When I realized that SDL2 was not only hampering the potential visuals but also heavily slowing me down I started to look at the alternatives. Pluging Octopus in a game engine felt like the best idea. I first looked at Unreal Engine for its C++ compatibilty and its potential but it quickly felt way too much for what I wanted to do. I then kinda overlooked Unity and went to try Godot when I found out it also have very nice C++ compatibility. The open sourceness was also a plus.

I hoped on some tutorials and everything went smoothly. In a week i got to this :

Not only it look a lot better but it also has a lot more potential for improvements (art did not get any better tho).

Performance are bit worst but nicer look come at a price plus there are still improvment potential.

State of the project

All that is all nice and well but at that point what is Octopus able to achieve?

Harvesting routine

Path finding

Attack modifier : AoE

Target acquiring when idle

many other thing are implemented in the engine  :

- producing buildings

- producing units

- resource spending

- pause/resume

- attack move

- command queue (shift clic) (not yet plugged in with Godot)

Whats is next?

Fair and square is going to be the first game built with the Octopus engine. It is going to be release with very simple art and a simple gameplay loop (the one that will be available in the demo).

Now my main goal is to produce a small playable demo to get feedback on the feels of the engine. I hope to have something available by the end of June hopefully.

The idea will be to get maximum feedback and proceed from there to a more complete RTS and add multiplayer support (that would probably be handled by Godot actually).

The Octopus Engine needs to stabilize and will require some documentation and polishing. Once Fair and square is released I will focus back on Octopus to wrap it up nicely.

Hopefully one day I would be able to make it available for everyone to use, right now putting it in the hand of people would only cause headaches...

Changelogs

v0.5

- Added 4 new units

- Added tier, technologies and requirements handling

- Improved demo level for better difficulty ramp up

- Added visual feedback for group control

- improved rally point visuals

- prepared multiplayer toolbox (not available yet)

v0.4b

- Fixed Maze level causing a crash

- Fixed line of sight check for path finding failing

v0.4

- Improved path finding when line of sight on target

- Added challenges to the arena menu

Known bugs : units can sometimes go through walls

v0.3

- Added french translation and locale selection

v0.2

- Added all english menus

- Added one page briefly describing units

Videos

Tech demo v0.3 (Godot)

Soon(tm)

Tech demo v0.2 (SDL2)

Tech demo v0.1 (SDL2)