3 months in 3 days (game engine dev)

3 months in 3 days (game engine dev)

the intro

Some weeks ago I found myself having a migraine. On that same day, I found out that migraine medicine is composed of basically two things. First, your average pain relief medicine. Second, *caffeine*. So, is that the secret? Is that the deal? That’s how you deal with migraines! Pain Relief Medicine with a side of coffee. I will keep that in mind.

Anyway, turns out that having a side of coffee at 9PM will keep you awake for some time. So I decided to, on a Friday night, do what every normal person does on a Friday night, write some game engine code.

Here are a few tasks that were cooking in my head.

I wanted to remove a bunch of things of my game library. The concept of layers, a debug memory tracker, precompiled headers, and dear imgui.

Having DearImGui on your C++ graphical project is pretty much a must in our Holy Year of Twenty Twenty Three. But it goes against my design philosophy that gueepo2D should only contain the bare bones to make a game. It can always be added into the game, or in a separate project alongside the game using the SDL2 and glad as dependencies, as those two are already included in the library.

DearImGui is very useful when creating tools, but I believe that tools should exist alongside games, not engines (Take that Unity Users!).

Oh well.

game jams, wintermute, and ECS

wntrmt by gueepo

On February 26th, 2023 the world has changed. I participated in a game jam and the experience and the result were so terrible that it made me reconsider my game library, the tactics game engine that I wanted to make with it, and the games I wanted to make.

A big win I had during this game jam was adding an entire API to my json file wrapper that was able to handle arrays, this was a big step towards being able to make games that are more data-oriented. But making a game on this piece of tech was a nightmare!

Human issues aside, there were a bunch of problems in the game engine that made it harder for me to able to do something with it. The first one is that gueepo2D is, by design, a bare-bones game library. It provides you with an application interface, it is capable of handling input and drawing textured squares to the screen, sure, but making a game requires a lot more abstraction, it requires a lot more tools.

In a sense, gueepo2D is something you use to make game engines, it is not something that you use to make games, although it can be used to make games.

The biggest thing that it lacks is some sort of Entity Component System. I have probably written a dozen times that “I don’t *need* an entity-component-system”, and it’s true, when making an engine that is tailored for tactics games I am confident I can come up with my own data structures that will work better for what I want to make, but what happens when I’m not really certain of what I want to make, and I need to make it fast?

Because that’s what a game jam is!

When you want more general-purpose functionality, ECS is a pretty good solution to go to, and not having it on the engine hurt my productivity and ability to partake in a game jam.

So here’s the question: If I need ECS to make simple games quicker, but ECS is against gueepo2D’s very own core philosophy, what is the answer? What is the solution? What should I do?

the goblin game engine

the goblin game engine

The Goblin Game Engine is the answer!

If “gueepo2D” is a piece of technology that you should use to build game engines, then why not build a general-purpose game engine on top of it? The Goblin Game Engine is born.

But what does this game engine have that gueepo2D doesn’t?

  1. A Resource Manager – A central way to store references to all types of resources that you would need in the game, and they all can be retrieved with a function call that asks for an ID. Not only that, the Resource Manager is data-oriented, so all the resources can be loaded from a json file, so no need to create pointers to create dozens of textures in the game.
  2. ECS and a Game World. You create entities, and the entities have components, all this is added to the Game World, a centralized place where you can see and consult all entities. The GameWorld, the entities, and the components will also take care of updating and rendering. And, of course, entities can be loaded from a file so you don’t have to spend hundreds of lines of code creating components.
  3. LUA scripting. Finally. Typing C++ is too much work, we need an easier way to add functionality to our entities without typing *too* much and without having to recompile the game, LUA is the perfect solution for that.
  4. Finally, an editor. If we can load configurations, resources, and entities from files, how do we create those files? Creating them by hand would be less work than creating it on code already, but the ideal workflow is to have an editor capable of creating, editing, and saving those files. Hence, The Goblin Editor! (currently under development)

Obviously, the final goal is to be able to create an entire game without having to touch C++ – That is a very ambitious goal, and I’m not even sure if I want to achieve that. Having Lua as auxiliary scripting is one thing, having it do the heavy lift on systems work is a whole other thing. But who knows! There’s a long road ahead for the game engine, and soon I plan on putting it to the test by making a small game and maybe partaking in another game jam.

But that is not all.

I forgot to mention that The Goblin Game Engine has a twin brother.

the machinist game engine

joder, esto si es motor de videojuegos

I talk a lot about making a “game engine really good at making the types of games that I want to make (tactics games)”, and I finally kicked that off. Well, this actually has existed for a while under the temporary name of gpg-1. But the goblin game engine and the whole experience with the game jam made me have a breakthrough and realize how this game engine should be done, and what it should look like.

So as I started making the goblin game engine, I also started “sketching” the machinist game engine.

This engine is called “machinist” because I desperately wanted a name that was related to Final Fantasy Tactics, and after looking at all characters’ names and jobs, I stumbled upon Mustadio’s special job, a Machinist. And I think it is a suitable name for the engine.

There’s a lot of work to be done on machinist.

Just like the goblin game engine, its focus is to be data-oriented, but this game engine can make way more assumptions about the final product than goblin.

And just like goblin, machinist will also have an editor tailored for creating the adventure maps of RPGs, and creating battle maps for tactical turn-based battles.

Whatever come out of this is still months away.

emscripten builds

Lastly, the final game engine adventure that happened on the last week or two after months of not doing game engine work was the one of adding the ability to export the games made with gueepo2D to the web.

This is very important for me because unless you are on Steam you don’t really want to download a game and click on a .exe file. Specially if we are talking about gamejams. Let’s be real, you are going to play a game jam game for 5 minutes at most, so being able to run all this on the web is very important.

Running emscripten through the engine took some work, but it is surprisingly easy considering the end result. You would imagine compiling a graphical application written in C++ into web assembly would be something extremely difficult. But it actually only took me a day. Well, whoever is behind emscripten is probably doing tons of work, and I appreciate that.

Changes to the engine include:

  1. Initializing OpenGL ES 3.0 instead of the default OpenGL Core 3.3 when building through emscripten
  2. Compiling an entirely different fragment shader and changing the OpenGL version on the header of the vertex shader
  3. Setting everything up on CMake so it can generate the proper makefiles to build the code where it outputs a playable version on HTML5
  4. An annoying thing that took me a while longer to notice and fix was that on OpenGL ES GL_RED is not a valid internal format, instead I have to use GL_R8, but when changing that my fonts worked just fine on the web, hooray!

So with all that, I’m looking to put my next little game on the web and not having people need to download it!

You can check the Goblin Game Engine HTML Demo Here:

goblin game engine by gueepo

why no one ever told me boy genius was a thing?

banger movie

the year of the gamer

I’ve decided to dust out this blog and start using it again.

The long story is that I’m always in an eternal state of either blogging or thinking “I should blog” – and every time that I think about it I ask myself: “But should I use WordPress? Medium? My own Website? or Cohost?”

The reason I like WordPress and why I am here is that this WordPress blog already has some stories. I used to write monthly here since January 24th, 2017. Wow! That’s a long time ago!

This website saw me going from my first weird game idea called “Zelda Souls”, trying pixel art, game music composition, making a weird tic-tac-toe-like thing prototype, making a weird puzzle-platformer prototype called simply “ghost game”, prototyping a bunch of other weird things, migrating from Unity to GameMaker, making my first few game jams, releasing two mobile games, migrating from GameMaker to Unity, making more weird prototypes, going to GDC for the first (and only!) time, moving to the United States, starting Peanut Butter Engine, realiti2D, visions2D, and killing all of them!

And it all pretty much ended when I got a job in the games industry, that’s it, right? That’s what it was all for! Grinding until I get a job and can sustain myself by working on video games!

Anyway, the TL;DR is that there was a lot of chaotic weirdness and experimentation going on here, and I want to add more to that pile! When I look back at all those things I think: “Wow! I used to do things!” – I remember when I used to be excited about doing things and experimenting with game development, good times! Now I am just an old guy burned out who wants to spend all of his free time writing and playing the piano. And watching movies. Watching movies is great!

Yesterday I rewatched this movie called “RRR”, right. It stands for “Rise, Roar, Revolt” and it’s an Indian movie made in Telugu language, right.

This is one of those movies that make you go: “Joder, Esto es cine!” while holding your cigarette.

The short is that it is a movie about two Indian revolutionaries – And what they supposedly did in times when there isn’t a lot of historical information about them.

It’s just a great movie and – Wait a minute. This is *not* what this is all about.

Oh boy, I wanted this to be a short post but turns out it’s going to be a long post.

The gist is that I want to use this WordPress blog again for time-based stuff that might not be relevant in a month or two, I used to do that on my website gueepo.me – but the reason I don’t want to do it there anymore is that when I post a link to the website on Twitter or on CoHost it looks weird. Yep. That’s the whole reason. Looks weird when linking to the post. So I’m here.

but what is this about, mate?

2023 RESOLUTIONS, what else would *this* be about?

When I first landed Home I had two things with me. A CyberPunk 2020 RPG book, and the thought that this book would be the key to an amazing year of game development.

The idea was really simple, yet very ambitious and very hard to execute: Create 12 Turn-Based Tactical RPGs based on the Cyberpunk universe using my game engine temporarily named GPG-1 that is built on top of my game library, temporarily named gueepo2D.

It can be done. I even flashed out the entire narrative for the first little game (in a single day!), it has 1,000 words and it’s about two Corporates being ambushed in a random alleyway. The flow would be simple, the game would start with some cutscenes, you would be thrown into a turn-based tactical battle and then there would be a cutscene to end it all. I would do that 12 times. The goal at the end was not only to have 12 small games but to have a robust game engine tailored to create games in that style so that I could use it to create an *actual* video game.

It sounds good in theory, but when I think about it, you know what’s better than creating 12 little games and building a game engine at the same time? Not doing that. I felt better by deciding to not do that.

I want to do *LESS* projects over a *BIGGER* period of time, with more *quality*, less *stress*, and more *passion* (the secret ingredient!) – And I want to make YouTube videos about them. I feel like 3 videos is a good amount to strive for.

The Tactics Project

The first project is the logical conclusion of the whole “1 game per month” thing I have designed and given up on – Just make one little game instead of making twelve. And make the engine at the same time.

The goal here is to have an engine capable of creating Tactics games, the goal is not the Tactics game itself. And I will be doing everything on the game, writing, programming, music, and pixel art. Fun Times Ahead!

It will probably still be based on the CyberPunk 2020 RPG and universe because I like it. I want to write stories about real life, I mean, ha, ha-ha. I want to write stories about dystopic capitalistic societies.

look at that dumb kid playing Nh3 lmao

The Chess Project

The other project that I want to tackle is making an AI for chess. That would mean making a simple chess implementation (obviously using my own game library temporarily named gueepo2D), making a headless version of the game, and then working on writing an AI for it.

Do I know how to play chess? No.

Do I know how to write a chess AI? Nah.

Do I know how to write AIs? Well, I’ve done that a few times in the past. You see, when I was more optimistic about computer science (and life) I used to be very passionate about AI and even worked on some AI-related research projects for 3 years or so on my bachelor’s degree. That’s almost the entire degree!

Is this project just an excuse for me to spend a huge amount of time learning how to play chess, get decent at it, and experiment with AI algorithms which were something that I was really passionate about when I had perspectives in life? Yes!

That’s *two* programming projects in a year! That’s enough already. That’s *more* than enough already.

Something that I want to explore and make a video about is DevOps, Automated Builds, etc., etc. – Especially in the context of game development, I feel like this is a weird thing to be *passionate* about, but I enjoy it and I think there’s a severe lack of knowledge about these things on game development, and it’s so important for running smooth processes. We will see!

me after watching Bullet Train for the third time

now what?

Now I hope I don’t give these projects up, which is a real possibility since I’m not really scheduling a consistent day or time to work on them. If you’ve read a few productivity books, first of all, read some actual books, and second of all, you know that’s the first mistake! But I am a burned-out dude after all, and I’m trying to figure out how to *enjoy* something that I have been doing *almost daily* for about ten years now (programming, I’ve been programming *almost daily* for about ten years now *sighs*)

But then we come to the bread-and-butter of my existence, my game library, gueepo2D!


My goal for gueepo2D in the holy year of twenty twenty-two was very simple and ambitious: Don’t deprecate it and start working on another engine, and I achieved it! Success!

The goal for this year is to Don’t deprecate it and start working on another engine. And change its name. I *hate* the name “gueepo2D” – It’s not even a “game engine” anymore! It’s a “game library” now! (What even is the difference?!) – That’s also something that happened in 2022.

But I’m here to talk about renderer backends.

Windows has DirectX, MacOS has Metal, and they both, together with Linux, have OpenGL and Vulkan – That’s a lot of different ways to create windows, something that is abstracted with SDL2, which is a good thing. But that means that individual graphics implementations are still in my hand. And I’m fine with that, I don’t *hate* doing graphics programming until suddenly I do start *hating* graphics programming.

It’s too much work, there are a lot of things going on, and it is very difficult to do graphics programming correctly and efficiently while also doing a whole engine around the graphics, even if the graphics are simple 2D pixel art graphics. So it comes a time when I just have to decide if I want to really have the graphics APIs on my hands or if I should use something like SDL2 Renderer, BGFX, or Sokol.

And that was a big struggle I had in my mind until today I realized that… Why not both? I mean, the engine already abstracts the renderer in a way that it doesn’t know and it doesn’t care whether it’s OpenGL, DirectX, Metal, or Vulkan. I did that pretty much on purpose, thank you.

So I can just use that abstraction layer to use SDL2 Renderer, BGFX, and/or Sokol – That’s probably not the most efficient thing, and it will be a bit of a headache to write a Sprite Batcher that works on all of these (I’m assuming!) – But ultimately, that’s better.

But I just listed three options, which one am I going to do? SDL2 Renderer is the easiest, BGFX is probably the most robust, Sokol is probably the one with the least amount of dependencies, so the answer to “which” one am I going to implement is: “I don’t know!”. That was helpful.

I will be experimenting with them all in isolation, doing the hard work of drawing textured squares and then I will think about it.


follow me on twitter because I will be there until the website dies

or follow me on cohost even though I think this website will die because people are going to other weird twitter alternatives, even though cohost is clearly the Better Twitter Alternative

obligatory end-of-the-post music recommendation

make it double!