Tag: games

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!

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!

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.