2025 – machinist lives

ok, here we go.

I don’t even remember how to write anymore! Most of the times when I think about wanting to make videogames on the side and writing about it, I think that a good measure of progress is to evaluate myself monthly, that is, a monthly blog post. Lately, these are closer to one single blog post a year. I have reflected on the why that is enough times, publicly, and in private, and it doesn’t really matter. What matters is that I want to make a videogame, and I want to write about making a videogame.

The issue here is that I’m not really making a videogame. I like to think of this as working on what I call “the machinist project” where a videogame is one of its public apparitions. “The Machinist Project” resides mostly on a soft cover red moleskine that I have in my apartment where I write long handed short stories. Up to this day there are twenty six little stories in there, and the “videogame” I have been working on is story number thirteen. That means that when I work on a videogame, I am thinking of the possibility of making twenty five others.

As a living and breathing world, the world contained on that soft cover red moleskine goes through a bunch of shit. Ranging from Board Games Tuesdays on your local tavern, musicians getting upset because they aren’t getting the busiest spot on a friday evening on said local tavern, to a swordsman getting into combat with a demon from an alternate reality and ending up in a parallel universe, train heists and political intrigue.

The point I’m trying to make here is that this is, in a way, a real world.

What I’m trying to get at is that there are bands and musicians in this world, and I quite enjoy my time sitting down on my computer, chugging down a pack of Sapporo and staring down at MIDI tracks on garage band, reading on music theory and questioning my ability of coming up with good melodies while playing pentatonic scales on a guitar tuned to Standard C. What I’m trying to say here is that I’m trying to make music, and music is another facet of this project.

the videogame

Check it out on itch.io: https://gueepo.itch.io/machinist-story

Setting goals for yourself and failing to achieve them is a tale as old as time. Here is the first iteration of what I wanted to achieve this year.

I really like The Machinist Project and I wrote a few good chapters for it, and I’m tired of not having anything to show from it. So I want to have a demo. The demo should be the first act of the first story, and that means 2 cutscenes and 2 battles.

I do really like The Machinist Project. And those few good chapters are so good that they made it through my randomly conducted script reviews mostly intact. And I am still tired of not having anything to show from it.

I haven’t made any significant progress by November, so the idea shifted towards having anything by the end 2025. Literally anything.

That means scuffing things out, cutting this “minimum viable product” into something even more minimum, and trying to keep the “viable” part in there.

This project only needs to be a thing that can be executed, and then you watch a little cutscene, play through a little battle, and then watch another cutscene that resolves the conflict. Things can roll from there. I can upload it to itch.io, keep updating it, and making devlogs.

More importantly, I can show it to people.

“Show it to people” being such a high priority might come off as “impure,” like, what? Am I working on a project just for the sake of other people? Ew! But it’s just that it’s annoying to talk about this thing that doesn’t exist, especially when it’s been over a year. How about YOU try telling your friends you have been doing this thing for a year and then show nothing from it to anyone.

With all that in mind, I started making use of all the 30min breaks I could find throughout my day to add or fix something on the game. And I managed to get the cutscene, dialogue, and battle system into a decent state in less than 2 months. The wonders of consistently showing up to work on a project!

What I’m saying in way too many words is that I finally have a “minimum viable product,” or “proof of concept.” Just something that I am going to show a few people and ask: “Is this anything?”

It can be found on itch.io: https://gueepo.itch.io/machinist-story

What’s Next?

It has been less than 24 hours and I already have a laundry list of things to improve on it. The videogame idea seemed to be received positively, and the fact that it now exists gives a lot of mental clarity.

So, what’s next? Iterating on the script so the characters and the world are a bit more fleshed out. Tweaking the gameplay, and adding quality of life stuff before even moving into adding more content.

After that, adding more content and finishing the whole first Act of the game! That’s three more scenes, which means three more cutscenes and three more battles! (Subject to change)

And, of course, making music for the game, as well as a soundtrack EP. YES. These two are different.

Who knows how long all that will take!

reboot (aka “Just Use Godot”)

I started the year of twenty twenty four with a positive attitude and the mindset of working on my own little story-based turn-based top-down pixel art videogames. It is currently the eleventh eighteenth twenty-sixth twenty-seventh of november 31st of January, 2025! and no story-based turn-based top-down pixel art videogame has been finished.

I also told myself I would write twelve entries on this blog, but I have done only one. So I should speedrun things and do a videogame and eleven blog posts in 2 months, right? Lmao, no.

Well, this is awkward. Let’s hope something comes out of this in 2025.

The Rise and Fall of The Machinist Game Engine

There was a time in life where I had aspirations and goals, and I wanted to be a Video Game Programmer and work in the Video Game Industry – Being in suburban Brazil makes it a bit harder, mind you – I had finished a lot of small, silly, little games already, but when asking myself: “What is the next step?” or “How do I get Good? TM” I arrived at the conclusion that I have been avoiding for years at that point: I have to make my own game engine.

Many dead engines later I stumbled upon the dynamic duo of gueepo2D and The Machinist Game Engine. The first being a little game library to abstract graphics, input, window, and an application framework. And the second one being an actual game engine dedicated for tactics games.

The reason why I stubbornly insisted on working on The Machinist Game Engine is very simple, actually. To fulfill my lifelong goal of building my empire of Tactics Games, I have come to the conclusion that the best path would be to build a game engine tailored to make these types of games. I would have to code a bunch of those systems anyway if I were using Godot or Unity, might as well own the whole tech stack, right?

But I forgot to take in consideration a thing: What if I simply don’t want to code?

I mean, have you ever tried coding a renderer? a system to read and render fonts? an UI System?

Turns out coding is boring, no one cares about it, I don’t care about it, and the less I code the better. And this is just a very convoluted way of saying “maybe I should just use the Godot Game Engine.”

the machinist project, godot, you, and me

So I have downloaded and installed Godot and started remaking my game. Because that’s the path I’ve chosen apparently. And it’s actually a nice breath of fresh air to be able to work on a videogame without having to open Microsoft Visual Studio, not having to write C++ code, deal with CMake and compile times. Who would have thought !!

Above is the current state of “The Machinist Project” on Godot after a couple months of work. It’s not a lot but when I say “a couple months” it means that maybe I sat down to work on it four or five times in a given month, so I will take any progress !!

the royal army symphony, george (the orc musician) and things that really matter in game development

People think that what’s really important about game development is game design and coding. I’d say: “Nah, mate.” The real important thing is the music for your videogame.

Because apparently I have a really hard time not thinking about the music my video game should have. Not only that, this video game is very much story-driven and I can’t help myself but to add in-universe bands and musicians into the story. And if there are bands and musicians in the world, they have to have songs, albums and EPs, right? RIGHT?

So after writing a scene where the main character is in jail, I thought: “Hey, what if one of the guards was actually a musician, and they just play the guitar all day instead of working? That would be cool.” That would be cool. So that’s how George, The Orc Musician was born, he is a guard but also an aspiring musician, so I have to make a whole EP of songs that are just guitar and voice. I have to.

The “George, The Orc Musician EP” has to exist in-universe and has to be part of the soundtrack of this video game.

Anyway, here is a demo for the intro song of the EP. I wanted to try having a guitar and some form of 8-bit melody. Mixing up 8-bit sounds and “real” instruments is something that has been on the back of my mind for a while now, and I don’t hate it.

When they tell you about scope creep (or was it feature creep? idk) they don’t tell you it can come in the form of conceptualizing a number of bands, EPs, and a soundtrack in a range of different styles.

Take, for example, The Royal Army Symphony. The story is set in an Orc Kingdom, and it’s just common sense that every Monarch will have its own government subsidized official band. Don’t let the name “The Royal Army Symphony” fool you, it’s a Stoner Rock band. Anyway, here’s a demo piece by them.

I think it’s also hilarious that I spent time drawing this cover art. It’s just a poorly done trace over a picture of The 1975 but I made everyone green (because they are Orcs.)

Truly a multimedia project!

current year

current year

I have been on a journey of creating a User Interface system on my game engine, and I think it’s finally at a point where I can do *something* with it – So I thought, why not do some menus? Three menus are going to be extensively used on the videogame that I am working on, an “Action Selection” menu, an “Actor Stats” menu, and, of course, a “Dialogue” menu. I want to take a deeper look at the Actor Stats menu.

As is *always* the case, let’s just copy Final Fantasy Tactics – Because that’s the starting point of absolutely everything on this thing that I am making. So if you look at the image above, you will see that we have this little thing showing the current character’s portrait, level, exp, hp, mp, etc., etc. And that’s what I want to replicate, probably not with all that information, but something along those lines

I decided to put a music video in the middle of the blog post because why not

There are two sides to creating this. The visual structure, and the logic. Let’s first look at the visual structure.

You don’t need to think too hard about this, this menu is just a portrait texture, a bunch of text labels, and three meters, and I decided to add a panel in the background. Each of these has its own respective class on the Machinist UI, as they are frequently used and serve as a “building block” for menu functionality. I won’t bore you with the positioning/sizing details, but in code, this ends up looking something like this.

So visually it looks like the screenshot below. There are still some ways to go, like, for example, coding the meters and, you know, designing a whole RPG system with components such as leveling, stats, and combat. But I think it looks kinda neat. I ended up with a version that has a panel as a background, but I might experiment with some variations later on.

Now, it wouldn’t be very programmer-y of me if I didn’t talk about everything that is wrong with this current approach and how we could improve it. So… *sighs* I guess I have to talk about that now.

The biggest issue I have here is the way I am creating a menu for this game (engine?) – The menu is entirely created on code. See, there is a static class to create the menu, and once that function is called it allocates the menu as well as all the components needed. This can be fine, and this can be not fine, so I will just go on about the reasons why I, personally, don’t like it this way.

I don’t like having to recompile the game/engine every time I have to tweak the menu, those 2~3 seconds of recompiling easily distract me, it’s not so much a waste of time as it more so that it just gets annoying and throws you off of any momentum or concentration that you have going.

Another issue is having to position/size things *in code* which is also really annoying. I said previously I would not bore you with the details of positioning and sizing things, but now I *will* bore you with the details of positioning and sizing things.

As you can imagine, getting to all these magic numbers is a matter of trial and error, and add that on top of the 2~3 seconds to compile and it all just gets really annoying.

The solution to all my annoyances here comes in two different steps.

Step 1: Make it Data-Oriented

Imagine a world where all that information was in a .json file. It could look something like the JSON below, and then all we need is some form of generic Factory method that gets a Menu JSON path as input and can create the menu with all its elements.

Delightful.

This totally eliminates the need to recompile every time you change something about the UI – because all the relevant information is now in a file that is going to be read in real-time. WOW! This almost feels like a real game engine all of a sudden. You just feed it a JSON file and it will create the UI for you, magical.

But this doesn’t eliminate all the guesswork and magic numbers from it, does it? So how could I possibly get rid of that?

Step 2: UI Editor

Yes. That’s Right. I got you. It was all an elaborate plan to bring you right here at this moment in time, the moment where we have a 1-on-1 conversation about my favorite subject of game development, TOOLS PROGRAMMING.

The engine takes a JSON file with all the data and creates the UI menu for you. We totally could leave it at that, even if I’m just writing and tweaking these files by hand it is already a big win compared to what we had before, but what if we create something to generate these JSON files for us?! We could create a tool!

An editor creates the JSON, and the engine reads the JSON, that’s what game development is all about. Game Engines are all about creating and reading files and the better you create the files and the better you read the files the better your engine is, and, in the future, there are going to be better ways to create and read files. But, at the moment, we should take it one step at a time.

What I’m trying to say here using way too many words is that I will be working on making the creation of menus on the Machinist Game Engine a data-oriented thing.

A detour to Like a Dragon: Infinite Wealth

You know, I really wish people could *see* into my head the *vision* for “The Machinist” – I think it’s a neat idea and I like it and I’m trying to make it work but, you know, juggling a huge number of things is not an easy task but progress is (very) slow and steady.

I usually describe it as “Playable Short Stories” – One engine to make games that share 80% of features, the engine keeps improving, and I come up with some sort of system and a bunch of tools that make it as easy as possible to create dialogues, cutscenes, characters, things like that. Basically, creating a new video game would be all about creating a new story, and I thought this was a good idea and that no one was doing it.

But I proved to be wrong (as is often the case) because that’s exactly what Like a Dragon is doing. But Like a Dragon is more like full-blown playable novels, not short stories.

This rapidfire schedule is possible, Yokoyama explained, because Ryu ga Gotoku Studio works on several projects in parallel, with staff, game mechanics and systems shared between productions. One developer handles the same physics-driven minigame for several games at once, for instance.

https://www.rockpapershotgun.com/its-frightening-how-fast-we-have-to-release-like-a-dragon-games-to-stay-relevant-says-yakuza-writer

The wonders of shared tech.

With regard to Infinite Wealth (aka Like A Dragon 8) and Like A Dragon Gaiden specifically, “there isn’t a huge difference” between them, Yokoyama added. “By this I mean that, in a sense, Like a Dragon Gaiden was derived from Like a Dragon 8. We could have just told of Kiryu’s past through a thirty-minute interlude as part of Like a Dragon 8, but we decided it would be a lot more interesting as a game of its own, which is how the project came to be.

https://www.rockpapershotgun.com/its-frightening-how-fast-we-have-to-release-like-a-dragon-games-to-stay-relevant-says-yakuza-writer

You see. Basically the same game, completely different stories, cutscenes, characters, dialogues, etc., etc., You get it. That’s what I’ve been trying to do. If you think of it, it’s not really a groundbreaking concept and there’s probably a bunch of series with that concept around there, but it’s just that somehow, somewhere, it seems to be the case that all these games/studios/concepts get lost in Business Related grievances or end up having to remake the whole engine because of *GRAPHICS* – Now, I don’t have the graphics problem because it’s just pixel art. Even though I’m sure I WILL be refactoring and remaking my game engine renderer multiple times.

I was going to make a whole detour about making music and all the struggles that I’m dealing with on *that* side of things, and, more importantly, my adventures in testing and acquiring guitar pedals !! Because making cool music is clearly not about your guitar skills, it’s about how many pedals you have.

But this is close to (or maybe even it surpassed at this point !) 1,000 words, which is sort of the limit I impose myself on these blog posts, so maybe… next time.

(hi, this is me post finishing writing and revising this post, spoiler alert, I went *way* beyond 1,000 words)

I know “everyone” is here just for the music videos.

what goes into UI

what goes into UI

If you are familiar with this image and know what it refers to, then you are probably too deep into internet and twitter discourse and I feel sorry for you. But not all hope is lost, and even though you can only watch and you are powerless, things might just get a little bit better!

(you can only watch)

Good thing I don’t have to worry about any of that, I have *my own* game engine! (and kids, that’s how I spend three months trying to get a sequence of characters showing up on the screen without breaking everything)

but anyway, what goes into making a UI?

On the gif above that I posted on X (formerly Twitter) you can see a simple tactics-style movement and combat! And I’m very proud of that. But I absolutely hate the sequence of characters “o to wait i to attack u to move” that you can see on the top left corner of said gif, and, of course, the final video game shouldn’t be like that, that would be absurd. So what is the solution?

The solution, of course, is User Interface. We don’t want “o to wait i to attack u to move” – We want a list of options that you can navigate through, and these options happen to be “Move, Attack, Wait” – But not only that, what if we want to change the option “Attack” to “Act”? What if we want to add more options? We need a flexible User Interface!

So that’s the story of how I started working on the User Interface of my game engine, machinist.

So I started doing some research, and by doing research I mean opening Godot and taking notes on their UI structure, as well as opening the book “User Interface Programming for Games.” and copying their UI structure. With that, I had a few classes on my engine:

  • A Control class – This is the base for all UI elements, a control is basically a *thing* that will exist within the UI.
  • Some specializations in Control, like a Container class (holds a list of controls), a Label class (a control that has text), and a Panel class (renders a beautiful 9-slice panel that can be resized)
  • And of course, a UI Manager, and a broad Menu class.

Things started getting a bit more complicated when I wanted to make a list of elements in the UI. The idea is simple.

Let’s say I have 3 labels. I want to add these three labels into a List class, and I want the list to handle repositioning them and rendering them. That is achieved through having a ListItem and a List class, which basically just holds a gueepo::vector<ListItem>

That’s not exactly where it gets complicated, since a list really just keeps track of a number (its position), and then just adds the width/height of the items into that to reposition the items, just basic math, really. The rendering is passed on to the control itself, so the ListItem/List don’t have to worry about it, so it’s pretty much like not having to do any work at all!

It gets complicated when you ask the following questions: When selecting an option in the list, how do I execute a function? How do I make it so a machinist::Menu talks to machinist::BattleSystem? – Solving this specific case is doable, machinist::BattleSystem can be a Singleton, or we can have static functions. We can add a callback on machinist::ListItem and there we have it, but how do we solve the broader problem? What even *is* the broader problem?

The broader problem is: “How do we separate menu structure/visual and menu logic?” Not only that, but the problem is also “How do we separate engine-side menu and game-side menu?” Things can get a bit cumbersome here if you want to keep a data-oriented approach, what exactly is menu data? Just a description of elements and position? Where do you store the logic? Every menu is its owns .cpp file? Do you want to add a scripting language just for the UI? How would you do that?

Well, I don’t have the answer for any of these.

But my current approach will be to work on creating a better separation between engine and game, not just for UI, but for *everything,* which basically means that I’ll put a pause on the UI work for the moment and work on some restructuring and refactoring. Fun !!

Since we are talking about restructuring and refactoring, maybe it’s time to revisit gueepo2D and do some needed work there as well, it needs some tweaks and a GUID generator system, so we can set up better data-oriented approaches on machinist. Fun !!

If you have followed everything that’s going on here, you will notice that we started up with “How do we make a UI system for an engine?” and ended up with “Welp, I have to refactor and work on the structure/architecture of the engine.” Which is a recurring thing in game engine development !! Fun !!

So that’s what I will be doing for the next few weeks. Maybe I can have a videogame finished by 2027.

banger

Tiny Tactics powered by The Machinist

peak game engine

At some point over three years ago maybe I have spent way too much time working on video games and video game adjacent technologies. A tale of burnout in the games industry is not uncommon, but what happens when you are already burned out on day 1? Turns out the plan to address all those things *later* was, in fact, not a good plan. But I made it to the other side (I think?)

At one point you just get tired of everything and wonder what are you even doing. During our lifetime we will see the collapse of Capitalism, we will be thrown into barbarism, and we will be in The Good Timeline if we don’t see nuclear weapons being used. That is to say that some days you just look at your video-game-making day job and can’t help but have no other reaction besides feeling stupid and wondering what the hell are you doing with your life.

Well, I’m trying to make video games, that’s what.

Tiny Tactics powered by The Machinist is a videogame project that I have been cooking in my head for way too long. I know that the name “Tiny Tactics powered by The Machinist” is a silly name, dare I even say it’s goofy. But every single word is here for a purpose, including *these* ones.

Tiny Tactics powered by The Machinist is a storytelling project. I like to think of it as “playable short stories”, because making video games is stupid, and silly, and video games are for babies and man child. Short Stories are for Cool People.

Tiny Tactics powered by The Machinist has multiple steps and multiple faces, and every now and then I want to make slices of this project public. Those are going to be what people call “video games.” But ultimately, it’s about creating stories, and a game engine capable of telling these stories to an audience, a game is a mere byproduct of the process.

Now, I could spend a long time here using words to describe aesthetics, gameplay, intentions, player goals, or player interactions. None of that matters. Every good project needs a humble beginning, and the humble beginning of “Tiny Tactics powered by The Machinist” is simply trying to copy Final Fantasy Tactics.

It’s obviously incredibly facetious (and dumb) to say that “I’ll just copy Final Fantasy Tactics” is a “humble beginning.” What I really mean here is a subset of the functionality and gameplay, whatever I manage to put in on the first iteration of this project.

A complicated aspect of Final Fantasy Tactics is its isometric art. I both love it and hate it. The isometric perspective allows for incredible cutscenes and it achieves a diorama-like feel that is Very Beautiful and I love it (In this house, we stan Sakaguchi-san.) But on the other hand, it does make gameplay harder to read.

To top it all off, I’m not really passionate or very excited about making pixel art, but I will try my best to learn it and, who knows, eventually, I can find someone I can pay to make beautiful art for these little projects.

Now, I would be lying if I said I knew where this was going. Or if I said I knew when something playable would be out, but hopefully, in a few months, maybe!

As to the question “But what is it about?” – The answer is that I also don’t know. I have some starting points for the first thing I’m working on and let’s see where this will go. The process is basically writing scenes and short stories within the constraints I have. For example, for the first game, I am working with an asset pack, so I have constraints on characters and environments.

So, every day I will sit down, look at the characters, look at the environments, look at what I have, write down some ideas, and proceed to write some scenes, a short story, or both! Whatever comes to mind. It’s all about experimenting with different ideas until one tells me that they are the chosen one.

I guess what I’m really trying to say here, by using a lot of words, is that I’m trying to make a video game.

the rise and fall of the goblin game engine (and glappy2D)

the rise and fall of the goblin game engine (and glappy2D)

the rise and fall of the goblin game engine.

I have written before about making a game jam on my game library (gueepo2D) and having a bad experience with it, and how that led me to experiment with building something on top of gueepo2D and how I experimented with different architectures, structures, and how I, ultimately, had to ask myself: What am I doing? And *why* am I doing it?

These questions led me to a number of different answers, the first one being that gueepo2D should *really* be just an intermediate layer used to build engines and/or games. The second one was that I *should* make more specialized engines for the types of games I want to make, which made me think about The Machinist, an engine built for turn-based tile-based games, and The Goblin Game Engine, a general-purpose engine with ECS and Scripting, and, in the future, a full-blown editor.

This whole journey had its ups and downs and made me solve a number of problems I was having when trying to make my own video games, a big one being that now I am able to export whatever I make on these engines into an HTML5 playable. And that process left me wanting to make *something* and publish it as an HTML5 playable. And that’s how the journey of creating a videogame with The Goblin Game Engine started.

It didn’t take long for me to realize that The Goblin Game Engine shouldn’t really be a thing – It was just a side quest, just something that was cool, just something that I wanted to experiment with, and I did, and I learned a lot with it and it got me unstuck. The issue here is me insisting on making something with it when I shouldn’t have.

I don’t want to get into a Godot Game Engine tangent here, but here we go. I think Godot is a Good And Cool Engine. And I want to make little prototypes, game jams, and maybe eventually contribute to its codebase, and on a fundamental level, Godot and Goblin try to solve the same problems, so it just didn’t make sense for me to want to work on both. Let’s not forget that My Actual Thing is The Machinist – These are all little side quests!!

Anyway – The *thing* I was working on was this Ski Game using Kenney Assets.

It would essentially be a lite clone of “Subway Surfers.” There would be a main lane where coins and obstacles spawn and you move left and right to collect/avoid the things – Easy, straightforward, and boring.

There were two problems: The Gameplay and The UX.

The Gameplay Loop is just boring, it’s always the same, and there’s nothing to it. If you think about it, what makes Subway Surfers interesting? Compared to this poor Ski Game – Subway Surfers has an extra dimension you can jump/slide into, and you have enough powerups to create some form of gameplay variation. Ski Game wouldn’t have any of this, because I’m not really trying to create an *actual* video game, I’m just trying to create a simple thing that is playable, a little bit fun, so I can put it out there in HTML5. That’s the whole deal.

As for UX issues, this is a bit more complicated. User Experience problems are the bread and butter of making a game engine, it’s all about creating and optimizing workflows and making things fast, it’s not about creating video games, duh. Video Games are just the product of a workflow.

With the development of the goblin game engine, I came to dread the whole “entities composed by components” system that was standardized by Unity, there’s an extra step to absolutely everything that you are trying to do, and maintaining a scripting language can be very annoying, and when creating a general-purpose engine an editor is a *MUST* which just makes everything worse.

Well, you live, you try things out, and you learn.

So, there are two options here: Make the Ski Game into an actual video game or scratch it.

So, after scratching the Ski Game (and The Goblin Game entirely) I decided to work on my original goal: Having a simple game developed and “shipped” in HTML5, and I would use the base library, gueepo2D, no fancy abstraction layers this time.

All this was a long way to say: RIP Goblin Game Engine 😦

glappy2D

Fast-forward 12 hours and the world got to know the absolute masterpiece that is glappy2D.

I know that it sounds a bit cartoonish, but right after I finished writing the section above I was dead set on developing this stupid, silly, little game, so I searched for free assets, free fonts, and easy ways to make simple sound effects, and got to work.

Making a “flappy bird” type of game is probably the most beginner-friendly task there is, and I have made it a bunch of times before, so I just created a GitHub repository, put the assets there, and started writing some poorly performant code.

The final result is a horrific main.cpp that contains five hundred and thirty-five lines.

But it is a silly cute (mostly thanks to Pixel Frog who put some amazing and cute free assets out there on itch) little game that you can play by clicking the link below.

glappy2D by gueepo

And with that, I have crossed two big things out of my list, getting rid of the goblin game engine 🙂 and making *something* silly with my game library and “publishing” on itch and playable on a browser.

Now, it’s back to writing and working on The Machinist with occasional breaks for game jams on Godot and, who knows, also on gueepo2D.

Outro

bro we waited like 14 years for this

This is where I would have my Twitter profile, but that website is naught but a shadow of its former self (and it was never great), or to YouTube, but I haven’t posted anything there for almost a year, and it doesn’t help that the script I was currently working on was about making a game on The Goblin Game Engine and I just scratched that game and the engine and, as a consequence, the script, so…

maybe a movie recommendation will do

gdc2023 and godot 4

peak drawing

gdc2023

proof

In 2019 I went to GDC for the first time and I had free beer and coffee and cookies at the Unreal Engine booth and I had a great time (proof on the left).

In 2023 I went to GDC for the second time and I had free beer and coffee and cookies at the Unreal Engine booth and I had an OK time, I forgot to take a picture of myself drinking a free beer at the Unreal Engine Booth so you will have to trust me on this one.

A big piece of this is because in 2019 I was a few months into the game industry, and I had to fly from Brazil to Canada and then San Francisco for GDC, that’s a whole fun adventure. In 2023 I live in San Francisco. Well, not quite, but close enough. So going to GDC is just going *there.* Another part of it is that the first time I went to this conference I was very excited and looking forward to the future and all the possibilities, but now that the future is here, the only thing I look forward to is going to the gym and sleeping.

There’s not a lot of exciting things happening, engines are trying to top each other on how many triangles they can show on screen or how much smoke effects they can throw at your face without dropping (too many) frames.

Right next to them you have speculative assets that didn’t exist 6 months ago and with not a lot of visitors. Where all that money is coming from?

There’s plenty of indie games but you already saw all of them on twitter, but it’s nice to see it, and hey, maybe you can talk a little bit with the developer that might be just there nervously watching you play their game.

GDC is an interesting experience because you can suddenly get insights and find your true intentions about being in this industry, mine is that I don’t really care about working on games, but I do care about working on tech to enable people to make theirs.

godot game engine

I’ve always wanted to be more comfortable with Godot. I like the engine, I like the community, and I like the fact that it is open-source.

But after months and months of not using it, and add to that the fact that they had a major new release, made it so I don’t feel comfortable anymore into just jumping into it and doing something. I feel like I needed to relearn it.

So I started searching for tutorials and courses. And I found this one: “Create a Complete 2D Survivors Style Game in Godot 4”

https://www.udemy.com/course/create-a-complete-2d-arena-survival-roguelike-game-in-godot-4

Now, I have played some Vampire Survivors, and I like its proposals and its simplicity, it’s an interesting game that appeals to your Lizard Brain, and when meditating on all these thoughts I had the idea of “Vampire Survivors, but make it Hades.” – What does that mean? I don’t know.

But what I knew is that this course would take me one step towards “Vampire Survivors, but make it Hades” so I wishlisted the course, waited for Udemy to have a sale (it took a total of two days), and then acquired the course.

And let me tell you, the Godot Game Engine is great, perfect, and I love it.

Obviously, it’s not perfect, it has its own weird things, I had this weird bug where mouse clicks wouldn’t register on the proper elements, and some things are weird and convoluted (looking at you, Tilemaps) and hard to setup, but once you wrap your head around it they all work great, and they all look great. I guess it’s just a normal thing about open-source software, it’s great for the most part, but with some weird UX problems and it has some inconsistencies here and there.

Maybe someday I will be able to get into the source code and improve some of those things myself, someday.

“But weren’t you writing your own game?! What happened with that? ” – No one

I am still working on a mess of projects that I nicknamed “my own game engine” – the overview is that I have gueepo2D, a simple 2D game framework. It’s code that you use to build a game engine, it’s not an engine itself. Then I have the Goblin Game Engine, which is a multi-purpose game engine with Lua and ECS, and then, The Machinist Game Engine, which is designed to be a game engine really good at making tactics games.

I’m not gonna sugarcoat it: The Goblin Game Engine is dying

I always wanted to be more of a Godot Guy, even though I work on my own game engine and I still want to keep working on it, but it just doesn’t make sense to build my own general-purpose game engine and want to use Godot, these two thoughts are competitive.

So I reevaluated if I really wanted to have my own general-purpose game engine and the truth is that no, I don’t. So I’ve decided to go away with the Goblin Game Engine. And I will be writing more about that in the future because I want to give it an honourable ending by making a simple game with it.

The Goblin Game Engine was really important because it got me unstuck on the problem I was facing on this whole game framework/engine development thing. Ultimately, Machinist only exists as a consequence of that, and I’m really happy with that, I’m really content with the structure of a “tactics game engine” and gueepo2D – a more general graphics framework.

So that begs the question: If I’m doing a tactics engine, what if I want to do something that is not a tactics game?

If gueepo2D is not designed for making games, and Goblin is no longer a thing, then the only answer really is Godot. Even when I am using Godot I wish things were different and how I could do better on my own game engine, and how I could be building tools to make the specific things I want to do on the specific game that I want to make, but these things take time, and what if I just want to do a quick game jam? It’s really hard to game jam on a custom engine, and I just can’t write and maintain two full-blown game engines.

Still on the topic of using Godot or my own game engine, I always knew that my own game engine is something that pays off in the long term, so I sort of made up this rule of thumb:

  1. If I want to work on a project for less than 3 months, I should use Godot – There’s no reason not to.
  2. If I want to work on a project for more than 3 months, then I can use Machinist, or spin up my own systems and tools on gueepo2D – But here’s the truth, here’s what took me a long time to recognize: I don’t want to make a game that is not a tactics and that will take more than 3 months.

I want to make a bunch of small games and try things out, sure, but when making full-blown games that I think are interesting, and that I think can ACTUALLY be good – These games always take the shape of an RPG/Tactics videogame – and that’s what Machinist is for.

ANYWAY.

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!

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.

anyway

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!

I will take you on a game engine journey

Remember last post when I said “I’m back mostly because looking back at your progress for the past weeks is just a very good thing to do?! And now I am just going back to the roots™ of this devlog – I will do whatever I feel like and then I will come here and write about what I’ve done, problems I’ve faced, what I’ve learned and, of course, add some Michael Scott gifs.”? – and then I proceeded to not writing anything for 153 days?

at least one thing on all that was true

I have very important news: remember I was doing a 2D game engine called realiti2D? Yeah, good times, I decided to stop doing realiti2D and start doing another engine, which I decided to call visions2D.

But for what reason someone might decide to stop doing something just to start doing it all over again? You might ask.

Well, there were some things I didn’t really like about realiti2D.

First, I didn’t really like the entrypoint. You have to create a class that extended the “Application” class, and then implement a function pre-defined in the engine, and that would be where your Application would start.

It just feels a bit confusing and unnecessary for me, I changed to a “you do the main function” approach. visions2D will have auxiliary classes to create games and tools, but at the end of the day, you can do whatever you want if you know well the engine architecture.

With that, within visions2D I can create a standalone renderer so I can test things and create tools.

And that was the second big reason, as I learned more about rendering, I noticed that realiti2D’s renderer was pretty bad, and I felt like restarting it would be the better thing to do. But I promised myself that’s the last time I restart an engine, if I face any major issues, which I’m sure I will, I will refactor!

With visions2D I want to not only create a good environment to make games, but to also make tools, and for that I need a well written renderer that can work as a standalone. I also need really good UI code, but that is a future me problem.

visions2D

How does the current process on visions2D look like? You may ask.

A big thing is that I started with Dear ImGui from the start, and it has been really helpful with debugging and making simple tools!

And recently I have made a simple flappy bird clone on it!

I will do a short youtube video on it so stay tuned.

Random Prototype of the Month

I like working on some occasional prototypes, so recently I picked a course on how to make a simple match-3 game, and you can see the result of it above! There’s not much to it really, it’s a match-3, everyone knows how a match-3 is supposed to work!

My intentions would be to expand it in the future and make something more interesting to it, but for now I just laid down some basic foundations.

That’s the course it was based on, I highly recommend it! I actually recommend all other courses by Wilmer Lin, he’s a very skilled programmer.

What’s next?

I intend to make frequents blog posts! I know I always say that, and it might take 1 week to do another post, or it might take 3 months, but I want to be frequently writing about the process of making this game engine, and also making some occasional game prototypes.

With some time I might think about doing vlogs instead of blog posts like this, but I’m still trying to figure out how to YouTube.

Speaking of how to YouTube.

This is the fourth video I’ve ever made! and It’s about making a roguelike in 72 hours for Ludum Dare 48! Spoiler Alert: It didn’t go too well.

I want to make an YouTube video every 2 weeks. I feel like that’s how much time I need to actually plan what I’m going to do, actually do something for the video, and then record/edit it. If I get the hang of it and it turns out that it’s easy to do that, I might think of doing one video per week, I might do these game engine vlogs, maybe a “monthly coffee time” where I talk about recent game industry news?!

I don’t know, I still have to get the hang of this YouTube thing and figure out to get good lighting, how to get the camera to focus on my face and how to get the microphone to properly capture my voice…