Making of Tiny RPG Studio

This is the story of how I created Tiny RPG Studio: a small engine for simple RPGs, built to help people make their first games without needing to program.

At its core, it came from an idea that took me years to understand clearly: sometimes the best tool is not the one that lets you do everything, but the one that gives you just enough limits to finally finish something.

Childhood, RPG Maker, and the Static World

When I was a child, my aunt gave me a PC with Windows XP. I still did not have internet access, but I explored that computer as if it were the most interesting and exciting thing I could possibly have.

I used to ask people to download games for me. Once, I bought a rewritable CD and went to a friend's house because he had internet. He opened Baixaki, and we started looking for programs he could download so I could burn them to the CD and install them on my computer later.

I remember once telling my cousin: "the internet is magic, I can download anything, learn about anything, and one day, when I have it, no one will stop me."

While browsing Baixaki, a Brazilian download site, I saw a category that caught my attention: "game creators." At the time, I was already addicted to PlayStation 1, playing Resident Evil and Silent Hill, so the idea that I could create my own games felt insane.

I downloaded things like Engine 001 and RPG Maker.

RPG Maker was incredible because it already came with ready-made sprites, an RTP package with characters, maps, objects, and amazing pixel art. I did not know pixel art, so that whole visual side was already partly solved for me.

I quickly learned how to build visually interesting maps with sprites, place NPCs in the world, and write dialogue for them. At that point, I really had my first game, and that felt like an unprecedented idea.

I remember telling a cousin: "I found a different kind of game, where you create games inside it." In other words, I did not really understand the concept of a game engine yet.

Eventually, I reached a point where I had created that world, but everything was static: the scenery, the NPCs, the monsters, even the story. Everything existed, but nothing could change.

I wanted to do something simple and even a bit cliche: a king in his castle would ask me to kill a dragon that was terrorizing the village. So I would go there, defeat the dragon, and come back to talk to the king.

But the king did not know I had done it.

And I asked myself: how could I solve this?

Searching through forums and tutorials on Google, I found something called "Switches." They could have two states: ON and OFF.

So when I defeated the dragon, I would turn the Switch ON. When I returned to the king, he had his default dialogue, but he also had an alternate dialogue if the Switch was ON. Something like: "You killed the dragon and saved the village."

I did not know exactly what I was doing, but it worked. So I started creating switches for all kinds of things, even to check whether it was day or night in the game world.

Discovering Programming

Much later, I started a technical IT program, a two-year course I took alongside high school. I wanted to learn programming.

That had a big impact on me because, at that point, the computer meant everything to me, but I was still just a passive user, using things created by other people. The idea that I could become a programmer and create things from my own ideas, for other people to use, felt surreal.

In the first programming logic classes, the teacher explained what a conditional is, what an IF is: if yes, do this; otherwise, do that.

Before that, instructions felt like a fixed sequence, like a recipe. But then something new appeared: a branch in the flow. A condition.

And I had a huge epiphany.

That Switch from RPG Maker was exactly the conditional I had been using to change the king's dialogue. So, in a weird way, I already knew programming long before I knew that I knew programming.

I even remember writing some code and asking the teacher what he thought. He said: "Everyone, this is interesting. He did it differently from how I taught it, but it will also work. This shows that there are many ways to write code."

Aside from art class in elementary school, that was the second time in my life I started getting praised in class. It happened in programming class, not because I was great at math or logic, but because I had already learned all of that from RPG Maker.

Bitsy and the Value of Limitations

Then came a big time jump. I had already graduated in computer science, was working my first job as a programmer, and was creating small game projects with plain code, now in JavaScript. I also knew how to make games in Unity with C#.

Through those projects, I discovered itch.io, which is huge, and found tools like Twine, for creating text games with choices; PICO-8, a fantasy console for making retro minigames; and Bitsy, a tiny engine for creating narrative games with three colors and simple pixel art.

Bitsy gave me another epiphany.

I used to think that creating a game engine like Unity or Unreal was an absurd idea. My role was to be a high-level application developer. I do not consider myself a programming genius like Linus Torvalds with the Linux kernel, so learning low-level GPU programming just to consider creating an engine felt way too distant.

But I had never stopped to think about creating a high-level engine in JavaScript, using Canvas, where all the low-level details could be ignored. The focus could be something else: creating an accessible tool, easy to use, and capable of running even on a phone.

An engine that is simpler to build and also simpler for people to make games with. No need to know programming. No need to take courses or watch tutorials just to build something basic.

I immediately thought: "I wish I were the person who created Bitsy, because that idea is absurdly brilliant."

Instead of competing with RPG Maker, Godot, or Unity by trying to offer more features, more performance, and more tutorials, Bitsy goes in the opposite direction. It serves the needs those tools do not serve as well: accessibility, simplicity, and a very low barrier to entry.

One of the best games I ever created was Zero to One, made in Bitsy for a game jam called One Room.

It was the best game I had created precisely because I never managed to finish my more ambitious games, the ones with long scripts, lore, worlds, systems, and brilliant ideas.

I am very bad at creating something with a limited scope. I define a scope and immediately want to expand it with incredible ideas that appear all the time. I take a shower and come back with five more ideas for the game. That makes the game impossible to finish. After a few months, I give up and already want to make another game that feels even more brilliant.

But Bitsy does not let that happen so easily. It is limited by default. You are forced to reduce the scope and tell a direct story there.

So I wrote a simple script, created three scenes, finished the game, and released it within the limited time of the game jam.

In other words, all my problems were solved there: I finally had a solid little game released online.

Bitsy stands alongside major engines in terms of the number of games created precisely because it is easy and fast to make something and release it. Without a doubt, it helped people who had never thought about creating games actually create games.

Taking a Break from Game Dev

After years of making games, after creating paid games and taking Godot courses, after deciding that my biggest life goal was to release a game on Steam, I gave up on game dev.

Imagine spending every night for a year creating a game, putting effort and work into it, and in the end, after a year and a half, having only the beginning of a game. The art was not ready, the gameplay was not smooth enough, and the puzzles were not good.

Once again, I had been too ambitious and could not finish my game.

After that, I thought: how many games are released on Steam? On itch.io, how many brilliant games appear every day? Does the world need more games? Or does it specifically need my games?

The work, bureaucracy, and frustration you need to go through just to make a simple game are heavy. That is why I completely gave up on it for a while.

Returning with AI

The arrival of AI had a major impact on programming. I started using ChatGPT to help me create C# classes, write SQL queries for work, and solve project errors.

You know that annoying error you have no idea how to solve? Before, I would go to Google, read several forums and posts, then go to Stack Overflow, find nothing, think about asking a question, and already imagine getting torn apart in the replies.

That summed up my experience as a programmer pretty well: moments of joy and moments of frustration.

Then I started copying the entire error message and sending it to ChatGPT. It gave specific and useful solutions. I would go back, apply them, and solve the issue. It was rudimentary, but it worked.

Over time, I began to realize that many errors could be solved in record time. When a coworker asked me for help, I would send their error to ChatGPT and solve it in minutes. Sometimes they had spent the entire day stuck on it.

They would say: "wow, you solved my error that fast? I lost the whole day on this, you really are a programming genius." I would laugh and say: "I sent it to the chat."

After a while, everyone started doing the same thing and no one asked me for help anymore.

I became excited about the potential of AI to remove the frustrating part I never liked and let me focus on the part where I could be better: being creative, having ideas, and giving direction.

When GPT-5 came out, I started creating small web games with HTML, JS, and CSS directly through chat. This was in 2025. I found it fascinating and applied the same philosophy of small projects: creating minigames and short stories.

I had the idea of creating a mini-RPG using Canvas, based on my previous projects. It quickly created something playable, and then I thought: now we need a small editor for this, so I can actually create this game properly.

And it did.

It was a small MVP, made with a one-shot prompt, but it turned out well and, surprisingly, it worked.

I left the project aside for a while, until I realized that, for it to become something real, I needed to take it out of the chat, put it in an editor like VS Code, and start working on it properly.

At the time, everyone was talking about Cursor, a fork of VS Code focused on working with AI. I downloaded it, got the free version with some credits, and put the project there. It started evolving brutally fast.

I showed the project to Diego and he doubted it: "I want to see if this is really working." It looked magical and had been made too quickly.

But when I tried to add something new, the project broke badly. I kept asking the AI to fix it, tried several prompts, and nothing worked. Since the code had been generated by AI, I also did not understand everything, and fixing it alone would take a lot of time.

At the time, I thought: "I hit the limit of AI here."

Then tools like Claude Code and Codex arrived, with agents better prepared to work on code projects. When I saw that Codex was available for ChatGPT subscribers, I came back to the project.

Codex solved the fatal bug, improved a few things, and got the tool ready to launch in just a few days.

We have to consider that I had already given up on game dev. My routine had become that of an adult with no time for unpaid personal projects. Spending nights fixing bugs and debugging was no longer realistic.

So I saw that the most tedious manual work could be handled by AI, while I focused on being creative, having good ideas, expressing myself as an artist, and applying software engineering. That is the reason I came back to game dev and to the community, and why I felt it was worth creating a small game engine.

This project would not exist without the beginning with GPT-5 and the maintenance with Codex.

Launch, Community, and Engineering

Since the engine was an MVP, a prototype, there was still a lot to polish, improve, and fix.

Diego, who has always played my games and projects, started collaborating a lot. He helped the tool become good enough to launch, not only by testing and finding bugs, but also by helping solve code problems, giving constant feedback, and promoting it through game jams.

I think that made the difference between the engine being seen by someone and being completely forgotten among millions of projects out there.

In the end, promotion is one of the most important parts of a project. As the saying goes, "marketing is the soul of the business." If you create an incredible tool and no one knows it exists, what is the point?

By the end of 2025, the engine had already launched. People were creating games with it, game jams were happening, the community was growing, and I even posted about it on LinkedIn.

Then came the part I value most in the project: applying my knowledge of programming, software engineering, and best practices to turn it into something beyond a prototype.

Until that point, I had mostly been deciding the creative direction and how the features would work. I had not yet thought that much about code and architecture, because it was a simple project made for people who do not have much time.

But with the success of the tool, I decided to apply everything I knew about code. It was fascinating, because I learned things that I took to work, presented in a talk, and used to help other developers: how to build something high-quality with the help of AI agents.

I decided to try Claude Code, paying for it instead of using a free version, because there is no such thing as a free lunch. I made the biggest migration in the history of the project, moving the entire codebase to TypeScript, with aggressive linting, unit tests, functional tests, and a code quality pipeline.

I created an architecture, organized folders and structure, applied SOLID, and started using best practices I had learned from college and from every company I had worked at.

That was when the project became much more robust. If I change something that breaks something else and creates a bug, I find out immediately, because there are tests covering many scenarios.

In that second phase, the engine became a serious project, something people could use and trust. With the game jams hosted by Diego, promotion gained strength, and today we have a very active community using the engine every day.

The Philosophy of Tiny RPG Studio

The philosophy of Tiny RPG Studio is the same one from the beginning of this post: creating an accessible tool for people who are just starting out.

I created a game in RPG Maker, used boolean variables, used Switches, and it was so easy that I did not even know it could already be considered programming.

The sprites already existed. I did not need to know pixel art or programming. Even so, I was able to create stories and adventures.

Now I have reached a point in life where I can create my own engine for other people to use. Maybe it will be their RPG Maker. Maybe it will be the first engine of their lives. Maybe it will be where they create the first game they actually finish.

I would never try to create an RPG Maker competitor, the same thing but better. That would be impossible. But I could take the minimalist philosophy of Bitsy and create something in that direction.

In the end, creativity is also about building on solid and brilliant things other people made before you, standing on the shoulders of giants, and then adding your own special touch.

I feel that Tiny RPG Studio is something new because it is absurdly simple to use.

You do not need even the bare minimum of pixel art, programming, or knowledge of how to create a scene with a teleport event from one place to another.

The game world is fixed, limited, and already interconnected, like a tiny open world. Even that comes built in.

The interface is simple and intuitive even on a phone, because the project was born mobile-first. And because I still think generating an HTML build, downloading it, and hosting it is too much work, the engine focuses more on generating a URL.

You create your game, generate a URL, and send it to your friends. The URL already contains the entire game. There is nothing else to download.

I cannot imagine a simpler way to create a mini-RPG, and I feel very proud of this project.

In the end, Tiny RPG Studio was born from this cycle: discovering games, discovering programming, giving up on projects that were too big, and coming back with a tool small enough to actually exist.

If it helps someone create the first game of their life, then it was already worth it.