Who am I?

Like many others working in the gaming industry today, I started as a gamer. I spent years playing all kinds of games, but eventually I became interested in something more than just playing them. I wanted to understand how they were built, why certain mechanics worked so well, and what made some games far more engaging than others. I was particularly fascinated by the decisions behind the gameplay, the balance between different mechanics, and how seemingly small changes could completely transform the player's experience.

That curiosity eventually led me to World at War Tournament, a community built around one of my favorite games at the time. I joined as a volunteer, helping organize tournaments, creating mods, and collaborating with people who shared the same passion for games and game design. What I enjoyed most was that we weren't simply playing together. We were constantly discussing how things worked, what could be improved, and what we would do differently if we had the opportunity. Over time, those discussions became increasingly ambitious, moving from individual mechanics and balance changes to imagining entirely new gameplay experiences.

The more time we spent discussing mechanics, balance, maps, vehicles, and multiplayer gameplay, the more one question kept coming back: if we had to build a game ourselves, where would we even start? Instead of jumping directly into ideas, we decided to understand the problem first. We tried to identify the major systems that make up a multiplayer game and map how those systems connect to one another. It was a rather ambitious exercise considering our limited experience at the time, but we enjoyed trying to make sense of something that initially seemed overwhelmingly complex.

The result looked something like this:

Looking at it today, it's easy to see its limitations. There are missing systems, relationships that could have been described much better, and plenty of things I simply didn't know at the time. Still, I wouldn't change it, because the value of that exercise wasn't necessarily in the diagram itself, but in the process of creating it. Rather than starting with features we thought would be interesting, we tried to understand what the game actually needed, how its different systems depended on one another, and what might happen if we changed something. We certainly didn't have all the answers, but that was part of what made the experience enjoyable. Every discussion seemed to uncover another question, another dependency, or something we hadn't considered before.

Once we had a better understanding of those relationships, we naturally wanted to experiment with our own ideas. One of them became a fictional top-down multiplayer tank game inspired by World War II vehicles. We imagined how different tanks would behave, how their strengths and weaknesses could influence gameplay, and how players might interact with one another. It was an opportunity to explore our own design decisions rather than simply analyze those made by other developers.

The project was never intended to become a real game. It remained a concept, and that was perfectly fine with us, because what we enjoyed most was the process of imagining how everything could work together. We spent countless evenings discussing vehicle balance, progression, player interaction, objectives, and all the small decisions that together shape a player's experience. Sometimes we would spend hours exploring a particular mechanic, only to realize that changing it would create problems somewhere else. That usually led to another discussion, another possible solution, and eventually another set of questions. We didn't need to build the game to enjoy the experience, because the process of designing it was already rewarding in itself.

Looking back, I think those evenings gave me something much more valuable than technical knowledge. They taught me to approach problems with curiosity, to question assumptions, and to understand how different parts of a system influence one another before trying to improve them. At the time, I wasn't thinking about Product Management, game economies, or the different disciplines involved in building and managing a successful product. I simply enjoyed exploring ideas, understanding why certain mechanics worked, and imagining how things could be done differently. Somewhere along the way, however, that curiosity became more than a hobby. I realized that I didn't just want to play games or discuss how they worked. I wanted to be involved in creating them.

That interest eventually led me into professional game development, where I discovered just how much more there was to learn. Over the years, my responsibilities gradually expanded from Level Design and Game Design into Game Economy, monetization, and eventually Product Management. Each new role introduced different challenges and required me to look at products from a broader perspective, but the underlying approach remained surprisingly similar. Whether I was designing a game mechanic, balancing an economy, or making decisions about product strategy, I kept coming back to the same questions: how does this work, how does it connect to everything else, and what happens if we change it?

Looking back today, I can see that those early experiences influenced my professional development far more than I realized at the time. What started as a simple curiosity about games gradually evolved into an interest in understanding, designing, and improving complex systems. The tools changed, the problems became more challenging, and the responsibilities grew, but the curiosity that started it all never really disappeared. Even today, after years of working in Game Design, Game Economy, and Product Management, I still find myself approaching new challenges with the same questions we used to ask during those evenings: how does everything fit together, why does it work the way it does, and what could we do differently?