Ariel Albano Soares
Game designer, game programmer & pixel artist
Combo Overload
  Combo Overload is a game developed in about 4 months, released on Steam in 2025. I was the one who made the entire game except for its soundtrack. It follows the recent genre of short incremental games.
​
  Its gameplay loop is centered around short and simple runs of fighting a wave of enemies, and back to the shop, which is a huge skill tree.
​
  An interesting design choice present in Combo Overload is that in the shop most of the time you have some different directions you can go in how to spend your limited currency. To explain it better, the way it normally goes in the genre is that, although the skill trees are big, the progression still feels linear due to the way that the prices scale, often times when you unlock a new upgrade node its price is on a scale above what was present, so the player ends up having to buy everything prior to that, so then he can move on to new nodes. This applies to both common currency, and limited currency.
Â
  In Combo Overload the idea to avoid the linearity was to make sure that there were always multiple options of upgrades spread out that the player can use their limited currency. The result of this design choice is that it adds a significant choice for the player to ponder in how to spend in the shop, while also adding customization to his build, since now the order in which you upgrade will shape a new build.
​
  Here's a clip of the youtuber Wanderbots take on this design.
​
  Talking about lessons learned from Combo Overload, on release there were many negative reviews on Steam, mostly due to the early game progression being slow and grindy. After addressing that the reviews started improving, but it was already too late for the Steam page itself, the sales quickly dropped. This taught me a big lesson in game design in the hard-way, to always playtest. I had only playtested the game myself, and the early progression felt good, but in retrospect that was my own personal bias, since as the creator, implementing and simply seeing it work already felt good, it didn't feel like a grind to me. If I had others playtest the game before release that could have been easily avoided, but I failed due to my own inexperience. That was a big lesson in knowing when to trust my own point of view when making games.
​
Rogamol
  Rogamol is a title that began in 2025, and is currently under development. I'm the developer of the entire project, except for the soundtrack and the sound effects.
​
  It is a whac-a-mole meets roguelite, inspired and following the design philosophy of Balatro. The main loop consists of beating the level, which is about reaching the score requirement by hitting the moles, then onto the shop to upgrade your build, for which there are multiple item types, and also upgrade your own mole army.
​
  The design philosophy of Rogamol is for it to be a systemic game, with a huge variety of content in the form of items, moles, bosses, weapons and difficulties, which interact with the systems to allow for emergent gameplay to manifest. And with there being no meta progression, the game requires the player himself to improve, which incentivizes the player to learn the game inner workings by forming its own internal model of it, thus coming up with strategies in real time to adapt each run to what is randomly offered.
​
  This type of game normally offers the possibility of some very broken builds that break the game, and Rogamol is no exception, there are setups and synergies in which the player becomes unstoppable. But the existence of broken builds is not to be trivialized, for if it is easy to reach them, it becomes a dominant strategy, compromising the entire design and balance of the game. It creates a strategy sink that draws the player to always go for them, making him feel forced to replicate the powerful and winning strategy every time, thus ruining the whole experience.
​
  To avoid dominant strategies the solution is simple, but not easy. The solution being mainly balancing the game, balancing with the goal of allowing the powerful builds to exist, but making them hard to reach, such that when the player reaches it, it feels special because it is rare, and rewarding because he had to learn the game, while also validating his knowledge through the feedback that is reaching the build itself. When this balance is reached, the player experience becomes a blissful power fantasy.
​
  Putting all of this design philosophy in the context of Rogamol, balancing the game is an iterative process, learning what in the game is strong or weak takes a lot of playtesting. Earlier versions of the game had so many things that were unbalanced, that playing the game, although initially fun, quickly became boring because it was a struggle to struggle, the game was simply too easy. It was trivial to reach extremely high scores while also acquiring more economy than was ever needed. To address all of that, again, it was through iteration, the biggest offenders to the balance were the toppings, some of them were too strong, the mole multipliers, where it was easy to reach high multipliers way beyond X10, and the score requirement growth was also increased. There is also the matter of the economy, balancing the economy is akin to balancing the game, since having economy enables the player to do whatever he wants, and there was one specific topping, the dough that, with the right setup which was trivial, starts printing money in an unhealthy way. The dough is still present in the game, and still allows for the same ceiling as before, it has been addressed not by removing or reworking it, but by balancing its numbers, finding it in the shop is not an instant win anymore. And as the economy itself got more controlled through iterations, the entire game itself felt progressively more balanced to play.
​
  I said there is no trivial way to balance the game, but there is one approach which helps with not letting over-powered items become dominant strategies, which is adding more variety. This design is at the core of the roguelite genre, adding more variety of content to the game not only creates more variety of runs, which gives longevity, but also dilutes the item pool, which makes it so that the overpowered items are simply harder to find in a given run. This doesn't replace the need to balance the game though, rather, it works well when pairing them together, achieving balance and variety.
​
ArrowMongers
  ArrowMongers was a project that started in 2022, where I was the solo developer.
​
The game is a top-down shooter roguelite, where you are a young boy who dreams of becoming the best archer in his village. Starting on his birthday, he can now become an official archer by competing in the colosseum, and braving the dungeon.
​
  The game has meta-progression in the form of leveling up the character and its stats, and mainly by unlocking unique arrows that also level up.
​
  Inspired by Ratchet & Clank, the vision for ArrowMongers was to have different arrows, which work like having different weapons in a shooter game, each one with a unique skill and its own level. And as the player progressed through the game the arrows he acquired get progressively more complex and intricate.
​
  In roguelites the core loop is about repetition, but they shouldn't feel repetitive, so that's always a problem for the game designer to solve. The standard solution is to have random power-ups during each run, thus making each run feel unique when done right. ArrowMongers takes a different approach, it employs two distinct core loops, one is the dungeon, which is a more traditional roguelite experience where it has a procedurally generated dungeon, and the other one is the colosseum, which isn't run-based, rather it offers pre-determined levels, 100 of them, where the player advances through them throughout the game. By having these two avenues that the player can tackle at any time at his own pace, this reduces the repetitiveness of the run-based format of roguelites. That together with the meta-progression is the design idea behind ArrowMongers to solve the intrinsic problem of the roguelite genre.
​
  Having both the colosseum and the dungeon made the game feel more dynamic to play, having both options in itself did feel fun, but it ultimately didn't solve the problem it was intended to solve, playing the dungeon still felt repetitive simply because the runs weren't randomized like they are in most roguelites. By trying to innovate in the solution to the genre, I underestimated the tried and tested design of roguelites, which, again, is randomizing the runs. Which is a lesson I took to heart later when developing Rogamol. I want to say though that I believe the design I tried of having two gameplay experiences could be a good one if I hadn't used it as a replacement, and instead used it to complement random runs.
​
  ArrowMongers was ultimately a project left unfinished. The goal was to secure a publisher after getting it to a polished and playable state, but after reaching out to dozens of publishers that didn't work out, and the project had to go into an indefinite hiatus.
​
  Getting rejected by publishers made me reflect a lot on the shortcomings of the game, which are my own shortcomings as a designer. With it being my first big project, I learned a lot of what goes into project management, I realized during development how severely overscoped the game was from the start given my current abilities and experience at the time. At every step I underestimated how much time each element added to the game was going to take. Something that fortunately doesn't happen as often nowadays. Combo Overload for example was a project I planned to finish in less than half a year, and it went as planned.
Closing thoughts
  I wanted to finish this game design section by talking about what I feel is the biggest design lesson I learned by making games throughout the years.
​
  You see, there were several times when I was developing and something in the game started bothering me, meaning I found an issue in the game, but an issue that seemed small. The issue being small made me want to dismiss it, believing that even though I found it, that a player wasn't going to notice it, you see, I'm a game designer, of course I'm way better at noticing problems than an average gamer, so I just let it go by unsolved. But after all, it never was true that the problem would go by unnoticed, whoever played the games always noticed exactly the issues I had been dismissive about. So the lesson was to respect others, to respect the player.
​
  What I'm trying to get to here is that I had these arrogant moments when designing games, which when they backfired, and they always did, made me feel like I was underestimating people. Thinking on a personal level, it made me notice the arrogance I had inside of me as a person, since after all, game design is art, and art is about understanding the self.