For the last two and a half years, I’ve been working as an IT project manager in the fields of government and medicine. While I do enjoy organizing things and bringing people together around a project, I slowly realized that the job wasn’t quite right for me.

Large institutional projects come with a lot of structure. Processes are well defined, roles are clearly separated, and many people have already paved the path before you. In many ways that’s reassuring: you’re supported, you’re guided, and things are predictable.

But it also means you rarely get to touch the creative parts of the work.

As a project manager, you often depend on many other people to make progress. You coordinate, you plan, you follow up. And while I enjoy working with others, I found myself missing the feeling of actually building something myself.

I’ve always been drawn to games. As a kid I played countless board games, invented my own with my brothers, or spent afternoons recreating imaginary worlds together. Later, I almost ended up working in the esports industry just before COVID happened. Instead, life took me toward IT and I hadn’t touched the world of games since.

Until recently.

This project came partly from curiosity, partly from stubbornness, and maybe also from a bit of a quarter-life crisis. I wanted to try creating something on my own terms: something creative, something playful, something where I could experiment freely.

And if I was going to do it, I wanted to do the whole thing myself: programming, art, music, testing, documentation… everything.

I’m still not sure whether game development will be the path I follow in the future. But I knew one thing: I wanted to try.

Before starting the project, I knew I needed the right tool.

Modern game engines are incredibly powerful, but they also come with a huge amount of complexity. Since this was my first complete game, I was looking for something simpler, something with constraints that would help keep the scope under control.

That’s when I discovered Pico-8.

Pico-8 is often described as a “fantasy console.” It recreates the feeling of programming on old hardware with strong limitations: a fixed resolution, a small color palette, limited memory, and built-in tools for everything.

And that’s exactly what made it appealing.

Everything is included in one environment:

• a code editor

• a sprite editor

• a map editor

• a music tracker

• a sound effects editor

You can open it, start creating immediately, and share your games easily with others through the Lexaloffle community.

The limitations turned out to be incredibly helpful. Instead of worrying about endless possibilities, I had clear boundaries. That made it much easier to actually finish something.

My first instinct was to create something entirely original.

I started experimenting with different mechanics and ideas, but I quickly ran into a common problem in creative projects: scope creep. Every idea led to another idea, which led to more features, more complexity, and eventually… a project that felt impossible to finish.

At some point I tried building a small shooter inspired by Enter the Gungeon. It was fun to prototype, but it quickly became obvious that it would require far more work than I could realistically handle in evenings and weekends.

So I changed strategy.

Instead of inventing everything from scratch, I decided to adapt something that already worked.

My girlfriend and I had been playing the board game Botanik quite a lot. It’s a clever tile-placement game where players build steam-powered machines by assembling pipes, flowers, and mechanisms while competing for the best pieces.

It felt like a perfect candidate.

The rules were already there. The core gameplay was solid. All I had to do was translate it into a digital version.

Of course, adapting a board game to a small fantasy console comes with its own constraints. I had to simplify a few things:

• I removed one category of tiles (the scientists).

• I reduced the number of available board tiles.

• I adjusted the scoring system slightly.

• I tweaked a few rules so they would work smoothly in a digital interface.

The result is BotaPic:

a local 1v1 turn-based strategy game where players compete to build the most efficient steam machine by placing tiles on a shared board and managing the available pieces.

A typical match lasts around 20 minutes, making it perfect for playing with a friend on the same couch.

I started working on the game at the end of November, mostly during evenings, weekends, and whenever I had enough energy after work.

My process was fairly straightforward:

1. Build the mechanics first.

   I started by implementing the core rules and basic gameplay logic.

2. Create temporary visuals.

   The first graphics were extremely simple — just enough to understand what was happening on screen.

3. Iterate on visuals after feedback.

   Once people started testing the game, it became clear the visuals needed serious improvement.

4. Test and refine.

   I invited friends to try the game, gathered feedback, and adjusted the design.

5. Add sound and polish.

   Finally, I worked on sound effects, music, documentation, and the overall presentation before releasing the game.

It wasn’t always a linear process, but this rough structure helped keep the project manageable.

Programming is probably the part I was most comfortable with going into this project.

I’ve been building websites since around 2017, though my professional work as a project manager hasn’t involved much coding recently. My last real programming project before this one was a small initiative called La Pépite.

I had experimented with small game prototypes before, but I had never actually finished a complete game.

Even though the technical side was my strength, there were still plenty of challenges. Pico-8’s limitations force you to think carefully about how you structure your code and how you manage memory.

Looking back, there are definitely things I would do differently today. But for a first complete project, I’m quite happy with how the technical side turned out.

The first version of the game… looked terrible.

The sprites were dull, not very colorful, and sometimes it was difficult to even understand what you were looking at.

The feedback from early testers was clear: the visuals needed work.

So I went back to the drawing board.

Literally.

The more I drew, the better I became at working within Pico-8’s limitations. Adding stronger colors, improving contrast, and experimenting with simple shading techniques made a huge difference.

I’m definitely not an artist today, but this project showed me something important: you get better simply by doing the work.

To be honest, a few of the sprites, especially flowers and fruit tiles, were heavily inspired by other artists’ work. But most of the remaining tiles and elements were designed from scratch, and I’m proud of how they turned out.

Testing turned out to be my favorite part of the whole process.

In total, seven people helped test the game. They played both the digital version and the physical board game, which made it easier to compare how the two experiences differed.

Most of the feedback revolved around clarity:

• Whose turn is it?

• Where can I place tiles?

• What just happened on the board?

These are things that are often obvious in a physical game because players naturally interact with the pieces and each other. In a digital game, you need to communicate everything through the interface.

Testing sessions also reminded me how much I enjoy playing games with other people in the same room. That’s always been my favorite way to experience games; sitting together, talking, reacting, and sharing the moment.

Another unexpected benefit of testing was motivation. Sharing the game regularly helped maintain momentum and made the project feel real.

The most difficult part of the project turned out to be something I had completely underestimated: the music.

Drawing was challenging, but I had some experience to fall back on. Music, on the other hand, even after playing piano for a decade, felt like entirely new territory.

My initial goal was ambitious: to create a full soundtrack for the game. That meant learning Pico-8’s music tracker from scratch, which quickly proved more complex than expected.

Several challenges emerged:

• The music needed to stay engaging without becoming repetitive or distracting.

• There was limited inspiration to draw from within the Pico-8 community.

• While creating individual sound effects was manageable, turning them into cohesive musical patterns was much harder.

• My music theory knowledge was rusty, which didn’t help.

At first, I approached it in a very academic way, overthinking the theory instead of experimenting.

Eventually, I stepped back and made a pragmatic decision: for a first game, sound effects were enough. Adding constant background music risked overwhelming the experience rather than improving it.

After spending a couple of months stuck on this problem, I accepted that it was okay for my first game not to have music, and that moving forward was more important than getting everything perfect.

Looking back at the project, there are still many things I would improve.

If I continue creating games, I know I’ll eventually need help, especially with music and final visuals. Game design itself is also something I’d like to explore more collaboratively.

Ironically, I’ve realized that my real strength might still be what I was doing as a project manager: bringing people together to build things. The difference is that this time I want to participate directly in the creative process as well.

One thing I also want to acknowledge is the role AI tools played in this project. Without them, finishing the game alongside a full-time job would have been much harder. I used them for programming assistance, visual inspiration, music ideas, and writing.

Maybe I didn’t learn as deeply as I would have without them, but they allowed me to build much more in a limited amount of time.

There are still known bugs and improvements I’d like to make. For example, there is a small issue when both players place tiles in the machine at the same time where the interface briefly allows extra placements; the animation of the tile placement is wonky to say the least; the board design is artsy if we can call it that; if I had more space available, I would probably add a proper introduction menu; etc…

But at some point you have to draw a line.

A game, like any creative project, is never truly finished. It’s simply released.

And this is where I’ve decided to stop and share it.

Looking ahead, I want to continue making games that people can play together in the same room. Couch co-op and party-style games feel like the most natural direction for me.

I’m also planning to learn Godot next. Just like with this project, the goal will be to start small and focus on finishing something.

Maybe even join a game jam, who knows, maybe that would be a good way to meet similar-minded people.

For now though, I’m just happy that after years of thinking about it, I finally finished my first game.

And of course, thank you to everyone who has supported me by testing, giving feedback or just listening to me talk about what I like :)