Hello! For this project me and three of my peers did a deep dive into the GoDot game engine, with each of us focusing on a different aspect of the project. Below are the links to the blogs of my peers, read them to do a dive into the other aspects of the GoDot engine!

Bootstrapping: https://www.niklausbair.com/blog/developing-a-game-engine-looking-at-godot
Input and Server Architecture: https://jacobb.me/blog/2019/10/12/godot/

Scene structure: https://www.austinlaimos.com/post/game-engine-development-godot

So for this I decided to focus on how GoDot handles memory management. To start I’d like to go over the princaples that they listed in their documentation here: https://docs.godotengine.org/en/3.1/development/cpp/core_types.html#memory-model. Here they talk about the issues with using heap and paged memory build into the language, with heap it talks about how memory can lead to being segmented memory. With paged memory it’s good for temporary memory but falls flat when working with permanent memory. So their solution to this is to use a memory pool model for managing their memory. This allows the programmer to allocate memory as without wasting space. However the issue with this is that you have to do a get function every time you want to access that memory, making it slower than using the heap. So the solution is to use a mix of the three, for small / temporary management they use paged memory, for memory that needs to be accessed quickly they use the heap, and for the rest they use the memory pool!

With that established, lets talk about how they use and implement the memory pool. For this they have three classes that work together. Memory, PoolAllocator, and VectorPool. Lets start with Memory, here is where the engine actually allocates it’s memory. Located in this class is the memNew and memDelete functions, these are used as the main ways to allocate and delete memory within the engine. It is also important to note that they use primarily static memory in this function.

The next part of this equation is the PoolAllocator class, this is exactly what it sounds like it’s the memory pool. This is the slower part of the memory management, however it’s much more space efficient due to it’s ability to defrag itself when allocating memory. This works by allocating a set amount of memory (from the Memory class) on initialization, then it is free to ma mange that memory as it sees fit.

Here we can see the memory pointer tr being given it’s static memory, as well as some other pieces being put together. Next up is how they actually allocate memory, this is done in a few steps. Firstly it checks to see if there is any entries available. By checking this will allow the pool to exit early if needed, saving on time. The next check is done by seeing if there is appropriate sized memory space in the pool, if this fails the first time it’ll run a defrag on the memory chunk then check again. This helps a lot with the best case scenario of this check by doing a quick check, however extends the worst case scenario by checking the pool twice.

Finally if both of these succeed, the pool will place the memory into one of the entries pre defined by the pool. The rest of this class is general memory pool stuff, there’s a resize function, a getter for entries, and the normal deconstructions.

Next is the VectorPool, I’m a bit torn about the exact function of this. It appears to be an abstraction of the memory pool, being where the user actually calls the memory pool. However why the memory pool is abstracted is beyond me as it all seems straight forward.

In conclusion, the memory management in GoDot is extremely streamlined, giving the user a lot of control but abstracts it enough to maintain itself.

Hello and welcome to my newest blog! With this series I will be documenting my journey on creating my own game engine. So with this being said there are a few fundamental questions I’ll be asking and answering in this blog post. Firstly, what is the purpose of the engine? I plan to create a game engine that specifically focuses on turn based strategy games. I’m aiming at being focused enough that people using the engine will have a streamlined experience making what they need, but be flexible enough to cover various types of strategy games. So if someone just wanted to make checkers they could, or make a jrpg they could as well.

There are a few features that I would like to be a part of this engine. Firstly a unit creator / manager would be key. Allowing users to make a unit quickly is vital for any strategy game engine to work. Secondly is a build in turn system, being able to decide when turns happen, when they swap, and what turn order is made will be vital for any turn based strategy game. Thirdly is an instancing system for scenes, many strategy games (particularly rpg and adventure games) will have an instance for combat, dialog, and just exploring the world, and having an easy way to support this will help greatly. There are other features that come to mind that will help such as AI tools, scene management, ect, however these are all questions that I’ll ask down the road once I have more of an idea of the footing I’ll have.

The next question is, what IDE and language will I be using to make this engine? For this I plan on using C++ in the eclipse IDE. There are several reasons for this, firstly I’d like this engine to be cross platform between windows, mac, and linux. To do this I need to pick an IDE that can compile

C++ in these platforms, witch eclipse fits the bill. Secondly, eclipse is very well documented and well used so finding help on any questions I may have down the line will be simplified. Thirdly, I have some experience in using eclipse so, not as much as with Visual Studio but it still helps. Put simply, I’m using eclipse due to the well documentation, cross platform capabilities, and my familiarity with the platform.

With all of that, I’m wrapping this blog post to a close. I’ll be posting updates on my journey into creating an engine so stay tuned!

So we are just about finished with this project, and while I’m very proud of the final result there were definitely some major hiccups along the way. The first major one I want to talk about was the scope of the project itself, said simply it was way to high. We decided that in 3 months we were going to have 5 levels in a seamless level, leading out design team to be spread super thinly. But not being in design this didn’t affect me as directly as it did them, what did however was the fact that we were unprepared for the pipeline issues that would inevitably come with this decision. What we finalized on was having different “work in progress” scenes for each level, then when things were ready or needed to be tested we would shove them all into the master level scene. This caused generally more issues than it was worth, with this we needed to have one programmer focusing on making sure the build wouldn’t collapse after the merge.

The second difficulty we ran into was with the art pipeline, none of us on the team had any experience with how Unity handled it’s 3D art pipeline which made learning it a task upon itself. The problem was, we didn’t fully understand what we were doing until after the project was nearly done, so the issues that were started near the beginning of the project were affecting us later into it as well.

All that being said, I feel like I’ve learned alot about how to set up pipelines and about developing in unity generally. There’s a lot that went bad, in the experience of it going bad I learned about the limitations of the engine, how to work around said limitations, as well as the strengths. This project being completed I feel like I have a new understanding of how Unity runs and how to properly develop for it.