it’s all about the tools you have

There comes a time in any man’s life where they have only one goal and one priority: making tools for videogames. My whole life I’ve been dreaming about making tools for videogames. When my second grade teacher asked: “Billy, what do you want to be when you grow up?” I said I wanted to make tools for videogames.

So when I got my cutscene system up and running, I asked myself: How can I make a tool to help me with this? I refactored the system to read cutscenes from a .json file, and the answer was staring right at me: I need to create a tool to *create* those .json files.

This is actually a good project. This is not an engineer over-engineering something or creating convoluted solutions for something that is barely a problem.

A game that is heavily dependent on storytelling, and that has a lot of cutscenes, needs something to make it so the process of creating cutscenes is a fast as possible. You want it so creating those .json files is not a bottleneck, you want to iterate fast, you want to visually see things faster. There is just a lot of benefits into having a tool that creates cutscenes.

What is a Cutscene Editor?

this is a cutscene editor

The first step of every old fashioned software is to figure it out in paper and paper. I decided to name the software “the wanderson film maker” – Named after my favorite movie director: Wes Anderson. It doesn’t make much sense, but who cares about the tool’s name anyway?

The requirements were simple enough: It has to read cutscenes from a .json file, and save cutscenes to a .json file. Of course, to do that, we have to settle on a .json format.

The .JSON file format

When I first wrote the first cutscene, this is what it looked like.

[
{ "action": "DIALOGUE", "actor": "thief", "value": "Scene 1: An Orc Dungeon" },
	{ "action": "MOVE_X",   "actor": "thief", "value": 3 },
	{ "action": "DIALOGUE", "actor": "thief", "value": "A Thief enters the room (that's you)" },
	{ "action": "WAIT", "value": 0.5 },
	{ "action": "MOVE_X",   "actor": "thief", "value": 6 },
	{ "action": "MOVE_Y",   "actor": "thief", "value": 2 },
	{ "action": "WAIT", "value": 0.5 },
	{ "action": "TURN", "actor": "thief", "value": true},
	{ "action": "WAIT", "value": 0.5 },
	{ "action": "TURN", "actor": "thief", "value": false},
	{ "action": "WAIT", "value": 0.5 },
	{ "action": "MOVE_X",   "actor": "thief", "value": 9 },
	{ "action": "MOVE_Y",   "actor": "thief", "value": -4 },
	{ "action": "WAIT", "value": 0.5 },
	{ "action": "PLAY_SOUND", "value": "cash_sfx" },
	{ "action": "EMOTE_WAIT_HIDE", "actor":"thief", "emote":"money", "wait":1.0}
    ...
  ]

That ended up working pretty well. Every entry, or action, will have an “action” saying… Well, what is the action, and what follows after are the parameters needed to execute the action. So, when the cutscene manager in Godot is reading the json, it will look at the action, and will look at different parameters to create the cutscene.

Of course, everything evolves and changes, but this structure mostly stayed the same through the development of the tool. The only thing that was added were fields for a cutscene name, description, and the starting position of different actors.

"description": "Passport Control Scene",
"name": "cutscene_3",
"start_positions": {
  "burub": {"x": 9,"y": 3},
  "gashnakh": {"x": 14,"y": 3},
  "thief": {"x": 3,"y": 13}
}

The Features

“Creating Cutscenes” is not specific enough, so how to break that down into something that we can actually code to create cutscenes?

Turns out we need *a lot* of things. Here is an incomplete list:

  1. We need the good old New/Open/Save/Save As… menu
  2. An Action List – A panel that shows us all the actions in a cutscene, and allows us to add new actions to a cutscene.
  3. An Inspector – A panel that will allow us to configure every action. Inputting its different parameters.
  4. A Playback Preview. This one is not a must, but it’s pretty nice to be able to see things and it helps to catch issues early, before actually getting the cutscene into Godot.

At the bulk, that’s it. But of course, things grew a little bit out of hand.

The Action Inspector

Actions can get pretty complicated and sophisticated, this is an example of the action where multiple actors can move at the same time. Not that bad, but it is the most complicated thing that can happen in a cutscene.

The Character Manager

I have created a “Character Manager.” All that the cutscene system really needs is a name. That name will be used in Godot to map to an existing actor with all the sprites, animations, and set up. But I wanted it to be a bit nice, and added sprites so we can visualize the cutscenes in the tool 🙂

Everything is just nicer when you have pretty pictures to go along with it.

The Log

Honestly, for me, this is a must on any application. I just need to see what is happening, I want to know what is happening. And I want to be able to clearly differentiate between a log, a warning, and an error. And I would like that to be in the tool itself, not on a windows console in a separate window.

The star of the show – The Cutscene Preview

Sure, I said it’s not a must. And it isn’t. But it is, by far, the shiniest piece of the tool. It all just hits different when you can visualize the cutscene while building it.

On this cutscene preview you are able to:

  • Paint the map with movable/blocked tiles. It’s purely visual as the cutscene will ignore all that, it’s there just so I can better depict the godot scene into the tool. I just need to know where actors can and can’t move.
  • Resize the map to any size. Currently useless, as I do every map so that they are the size of the viewport, but I’m sure one day I will want maps to be bigger and have more things.
  • Play the cutscene.
  • Move to previous and next action. It can also start playing from a specific action. Being able to jump around the events are life saving as I don’t have to go through all of them every single time when creating or editing a cutscene.

Boring Programming Parts

Open, Save, and Save As…

It seemed that the best library out there to show file dialogs in C++ is this one called “nativefiledialog-extended.”

And it was surprisingly easy to setup and get it up and running. After including it on my CMake build, this is how the function to open a cutscene looks like.

void CutsceneEditorLayer::OpenCutscene() {
    NFD::Guard nfdGuard; // NFD_Init() is called, and NFD_Quit() is called when it goes out of scope. Neat!
    NFD::UniquePath outPath;
    nfdfilteritem_t filters[] = { {"Cutscene JSON", "json"} };
    if (NFD::OpenDialog(outPath, filters, 1) == NFD_OKAY) {
        Cutscene loaded;
        if (WANDERSON::SERIALIZER::LoadCutscene(outPath.get(), loaded)) {
            m_cutscene = loaded;
            m_currentFilePath = outPath.get();
            m_selectedAction = -1;
            m_isDirty = false;
        }
    }
}

The LoadCutscene() function above is what is going to do the heavy work of opening the file that, thanks to this library, is guaranteed to be a valid file, and parse the json to load it into the internal data structures.

Now what

Welp, that’s the gist of everything I wanted to talk about in terms of this tool to create cutscenes!

I am, for real, and for some weird reason, a bit passionate when it comes to making *tools* for videogames. Maybe it’s the idea of solving a problem really well that does it. Creating cutscenes by writing json files would be unbearable. And, at the same time, cutscenes have to be data-driven, otherwise it would be even more unbearable. A tool to make a cutscene solves that problem, it can spit out those files for us and it has a pretty interface to let us do it.

Maybe it’s the fact that now I don’t have to worry about creating those files, and creating a cutscene is easy, and as least time consuming as it can be. So, I can focus my time on other things. And I know that if I rewrite a cutscene it won’t be a pain to edit it or redo it.

This created an interesting problem. I can create, edit, and tweak cutscenes really fast, so now I have to actually do all of the writing, and rewriting of cutscenes. That is actually the time consuming part that there aren’t shortcuts for. But I guess I did it to myself when I said: “You don’t want creating .json files to be a bottleneck.” Because creating those .json files are certainly not the bottleneck.

vibe coding a videogame

https://gueepo.itch.io/machinist-story

The word about AI has been on the streets for quite a while now. As a professional skeptical person, and, not only that, as a professional “I hate and don’t trust technology” type of person, I had no interest on it. Until one day I get a message at work saying we have enterprise licenses to use AI Coding tools and asking who was interested in having access to it. In a few minutes over half of my team manifested interest.

So I did what any secure person would do: Give in to societal pressure and also say I’m interested. And once I have access to it, might as well try it and see what the fuzz is about, right?

I haven’t been really coding much on my free time, so didn’t really care for the productivity gains there. And I couldn’t use non-enterprise coding tools at work, so I never really got into “the perfect storm” for me to try coding with the help of AI.

I’ve seen the wonderful tales of vibe coding, and also the tales of woes, even the more experienced people in the industry seemed to all have the same thought and opinion: “It’s just a tool, and can improve your productivity if you know what you are doing.”

I have been using AI for a good amount of days now to help me, and what’s my take? You might ask. My take is that it’s just a tool, and can improve your productivity if you know what you are doing. I could sit here and sing the praises to it, but the truth is that I have been coding *almost* daily for over 10 years now, and, whether I like it or not, I have to say that I am pretty much an expert on this, and I know what I’m doing so this tool helps me greatly because I have experience on thinking exactly what I need, and planning how to do it.

I can easily detect when the AI is making things up or just using things that don’t exist, and I can easily fill in the gaps where AI doesn’t go to. Would it be the same with a Junior Developer? I’m not sure. Probably not. I’m not a Junior Developer so I can’t really be talking much about that experience, and honestly, I don’t really care much. I’m just trying to make a video game on my free time, I’m not trying to push the entire industry of programming tools forward.

All that is to say that, yes, coding with AI helped to reduce the boring parts of it, and allowed me to overcome pain points faster and easier. I feel like it’s important to say that I have one important rule: I don’t let AI edit my files, hell, I don’t even let it read it. I copy it and paste whole files and code snippets like an animal and ask questions about it. So I guess that, by definition, I’m not really vibe coding after all ):

TL:DR; I hate AI. But eventually caved in to the idea of coding with AI assistance. Yes, the productivity gains were substantial.

Anyway, what did I do?

My original goal was to work on monthly iterations and milestones. But I didn’t work on this videogame for almost 2 months. Life happens, people get busy, demotivated, travel do France, runs a marathon, things like that.

But when I got back into this, I had a laundry list of things I wanted to do:

  • Rework the cutscene system (vague)
  • Improve the enemy behavior (vague)
  • Rewrite script for the first scene and add the changes into the game.

I decided to start with the cutscenes.

Cutscenes

I was, at first, just trying to see what these AI coding tools would say and do. And it was very efficient at suggesting helper functions to create, and ways to simplify the code. Until it eventually called me out on my bullshit.

Wow! It even reads my comments and points out at things I’m unhappy with!

I had already considered doing this move, but seeing this just made me think that I *had* to do this refactor, and so I got into it. It was really just a matter of creating a function that would read a .json and calling the proper functions to queue actions based on it.

So, in 2 days or so I was able to fully do this refactor that I have been holding off for so long, and now everything is better. wow.

The best thing is that now that cutscenes are data files, I can create a separate tool to create cutscenes. Everything in game dev always boils down to having cool tools, so I would like to make a cool tool to create cutscenes for this videogame.

So, you know what next update is going to be about 🙂

On a side note, I reworked the entire first cutscene.

Enemy Behavior

There were a number of small adjustments on how the enemy behaves in this videogame. Let me just list it out.

  • When moving, it will look for a tile around the enemy, not the enemy itself. A small adjustment, but one that makes a lot of sense.
  • The enemy will look one turn into the future to decide what it should do this turn! A significant adjustment. So, if the enemy doesn’t see a good move for this turn it can think about it a little, instead of just being like “Welp, guess that’s it!”
  • Did a small tweak so now characters won’t walk on top of each other when moving. I had support for this already, just had to flip a boolean variable. Oops.
  • Added a coward behavior to the enemies. If an enemy is flagged as “Coward” it will run away from you when their health is low. Here’s some code snippets!
func IsActorInDanger(_actor) -> bool:
	if _actor.actor_stats.will_retreat:
		var health_ratio = float(_actor.CurrentHealth) /  _actor.actor_stats.health
		return health_ratio < _actor.actor_stats.health_ratio_to_retreat
	return false # an actor that wont retreat is NEVER in danger.
  • I introduced the idea of speed and charge time on the game (just like in Final Fantasy Tactics) so now turns are more dynamic based on actor’s speed and it’s something that I can play around with.

What’s Next?

I think it’s time.

The ultimate goal for this part of this project is to have the first Act of the story. I want the first Act to be very good, cool, polished, beautiful, and all the nice words that I can think of. So adding the other two Acts is just a matter of writing a script, and designing cool and interesting battles.

I also want the next game to be just a matter of writing a cool story and designing cool and interesting battles. Or at least that I have very polished game system so that I can work on adding complexity and making a good videogame.

So it’s time to add the content for the entire first act of the videogame. As of today, that means adding 2 more battles, and 4 more cutscenes. Adding some music, sound effects, and possibly working on some pixel art as well.

We’ll see how it goes next time!

machinist story: a milestone

There is a new update to the machinist project! Check it out !! https://gueepo.itch.io/machinist-story

Upon “releasing” my little game project idea out in the wild, my goal shifted to having semi-frequent updates. I’m calling the first update the “iteration milestone” because the goal is to work only on quality of life improvements.

A lot of things about this videogame still suck, and I would like to address as many of those things I can before moving into actually designing more battles, writing more chapters, and making more music.

I like to think of this game in three different areas: Cutscenes, Battles, and Dialogue.

Cutscenes

Most of the work on cutscenes happens on a sheet of paper where I need to write, rewrite, and add notes on top of the game script. Translating all this into a cutscene isn’t that difficult, honestly. It just looks very ugly.

Can you believe I’m paid to code professionally?

I like to think that… This is a cutscene. A cutscene is just a bunch of scripted commands, but I hate this so much, but it works. So I probably won’t be overthinking this too much until it stops working! When that happens, I will be mad at myself for not thinking about this earlier.

Battles

The big question here, beyond quality of life, is how to make combat interesting.

Maybe if “Machinist Story” (Working Title) ever make it across the finish line, I can add traditional RPG elements to the game, like items, skills, party members, or any form of customization that changes how the battles play out. But these things are definitely not making it into this one. So, how *do* I make battles more interesting?

The first step was improving quality of life. The new update feature things such as:

  • Being able to see how far your character can move/attack while navigating through the UI;
  • Graying out options that you are not able to use anymore in this turn;
  • Showing how much damage was dealt; and
  • Being able to navigate the map when it’s your turn so you can see how far the enemies can move and attack.

A big challenge here is the AI. There’s just so many variables to account for. What’s the shortest path to the enemy? Which of the four positions around them I want to be at? How can I not obstruct my mates and let them kill the enemy too? What is the best path to get to the enemy if I can’t get to it this turn?

The good thing is that I don’t need to worry about none of that right now. So I won’t. Moving on.

Dialogue

My biggest issue with how dialogues are portrayed is that it isn’t clear who is speaking, and the dialogue boxes are ugly and always in the same place. I wanted to add names, portraits, and make the dialogues come out of the character.

I would like something more like this.

But unfortunately, I have spent way too much time on making the battle a little bit prettier, and making the cutscene code a little less ugly.

What’s Next?

Working on monthly iterations has been an interesting idea. And although I really want to add more stuff into this game, so the game has more battles, more cutscenes, more, more, more! I am faced with a sad reality: That intro cutscenes *SUCKS.*

So, the next iteration is simply working on the script, incorporating the pages of notes I have into the actual script, and, who knows, if time allows, I can start writing the script for the rest of the game, and not just Act I.

I will probably tackle some quality of life and small improvements here and there as well. And I expect to do *A LOT* of work on the cutscene system to improve it, but the overall goal here is simply to tell a better story in a better way. (:

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.