Item Purchasing
We designed the item purchasing system – along with many other gameplay systems – to closely mirror how it works in games like Dota 2 and League of Legends. Our overall vision was to make every aspect of the game feel familiar to players. We want someone with MOBA experience to jump in for the first time and immediately understand, almost intuitively, how everything works.
Players earn gold passively throughout the match. Additional rewards are granted for securing kills and destroying towers. Items can be purchased either at the base or while dead. The items themselves follow a hierarchical structure: there are basic items that can be bought directly with gold, and composite items that are assembled from one or more components. Each player has six inventory slots available for items.
In the shop interface, the left side displays the full list of items along with a smaller selection of recommended items for the chosen hero. On the right, players can see the item build tree and a detailed description of its stats.
Purchased items enhance a character’s attributes. Here is a breakdown of those stats:
- Physical Damage. Primarily increases the damage of basic attacks, though it may also scale certain abilities.
- Magical Damage. Increases the effectiveness of spells.
- Armor. Reduces incoming physical damage according to the formula: final damage = damage * 100 / (100 + armor)
- Magic Resistance. Reduces incoming magical damage using a similar formula: final damage = damage * 100 / (100 + magic resistance)
- Attack Speed. Increases the rate of basic attacks.
- Cooldown Reduction. Decreases the cooldown time of abilities.
- Movement Speed. Reduces jump cooldowns and increases wall-climbing speed.
- Resource Gathering. Expands the radius at which the hero can collect resources (allowing them to pick up their own resources and destroy enemy ones from a greater distance).
- Backpack. Increases the number of resources a hero can carry. By default, a hero can only carry one resource, but items can expand this capacity by one or two additional slots.
- Jetpack. Improves aerial maneuverability, including control while flying and while riding a bomb.
Heroes
We also introduced three distinct heroes: Scout, Tank, and Judge. In addition, we decided to replace the simple spheres with fully fledged characters. To achieve this, I picked up a pack of stylized cartoon characters from the Unity Asset Store, created a set of simple animations for them, and integrated them into the game.
Scout
Scout is the fastest character, but also the most fragile (he has the lowest health pool). His abilities are:
- Kick. If Scout crashes into an opponent’s back while jumping, he deals damage and knocks the opponent off the platform. The damage increases for each resource the Scout is carrying.
- Dynamite. I described this ability in a previous post: the dynamite pulls nearby enemies toward itself and explodes on contact, dealing area damage.
- Poison Cloud. Scout creates a cloud of poison that damages all enemies inside it. If an enemy remains in the cloud for more than one second, they are knocked off the platform.
Tank
Tank is the slowest and most durable character. In a team, he serves not only as a tank but also as a support. His abilities are:
- Flame. A fiery aura surrounds Tank, dealing continuous damage to nearby enemies.
- Stop. Tank instantly freezes everything around him. He also collects all resources affected by this ability.
- Health Trail. Tank leaves behind a healing trail that restores health to him and his allies while slowing enemies.
Judge
Judge has the most complex abilities to master – a true mage archetype:
- Bomb. Judge fires a projectile. The longer it takes to hit an opponent, the more damage it deals. If the opponent is holding onto a platform, they take only half damage.
- Platform Hit. Judge delivers a powerful strike to the platform he is currently attached to. All nearby opponents take damage, and those on the same platform are knocked off.
- Brick. Judge throws a stone that passes through platforms, knocking enemies off them. The stone also collects resources carried by opponents.
We also introduced several additional gameplay elements to make the experience feel complete – giving players clear objectives to achieve victory. Rather than describing these systems individually, I’ll go straight to outlining the finalized version of the game rules.
Final Gameplay
Players begin the match at their base, and their ultimate objective is to destroy the enemy team’s base. Each base is protected by several towers. Players cannot attack towers or the base directly – instead, they must use mega bombs to deal damage.
Two lanes connect one base to the other. Along each lane, there are several towers and multiple control points. However, only one control point per lane is active at any given time; the others remain dormant. At the start of the game, the central control points on each lane are active.
Active control points periodically spawn resources in two colors, along with health packs and small bombs. Players must capture resources of their own color and deliver them to special resource receivers, typically three to four of which are located around each control point.
Each resource deposited grants the team +1 point on that lane. To gain the advantage, a team must accumulate more points than their opponents. Upon reaching a lead of five points, the team gains the ability to summon a mega bomb. Players from the summoning team can latch onto the bomb and tow it toward an enemy tower or base, where it explodes and deals damage.
Until the ten-minute mark, towers are protected by three shields, and all incoming damage is reduced by a factor of three. Each time a tower loses one-third of its health, one shield breaks, rewarding all team members with gold. After ten minutes, the shields disappear (along with the opportunity to earn bonus gold), making towers significantly easier to destroy. In addition to mega bombs, towers can also be damaged by delivering captured resources directly to them – while the damage is minimal, it can be enough to finish off a weakened tower.
A mega bomb can also be towed to an inactive control point and detonated there. This activates that control point (and simultaneously deactivates the currently active one on the lane). However, this is only possible after all towers along the path to the next control point have been destroyed. Initially, only the central points are active, and mega bombs have a limited lifetime. This creates a time constraint: reaching the enemy base directly is often not feasible. As a result, players must first activate a control point closer to the enemy base, and then assemble a bomb there – one that has enough lifetime to reach its target.
If a team activates a control point near the enemy base but fails to collect resources there for an extended period (more than one minute), the point automatically deactivates, and the central control point becomes active again (effectively resetting the lane to its initial state).
As mentioned earlier, creating a standard mega bomb requires investing between 5 and 10 resources. However, after the ten-minute mark, players gain access to a mini bomb, which costs only 3 resources. This bomb deals no damage and is useless for attacking towers or the base. However, it still activates control points, making it a valuable tool for quickly shifting the frontline closer to the enemy base.
Replay Recording
Balancing gameplay and fine-tuning the heroes took a significant amount of time, and we played a lot of matches in the process. Unfortunately, capturing gameplay footage wasn’t easy, so we didn’t really pursue it. Still, I wanted a way to review matches afterward, which led me to implement a replay recording and playback system. It turned out to be a much simpler task than I initially expected.
The client–server architecture of my game is built in such a way that absolutely everything is computed on the server. Clients merely send commands and render the state they receive from the server via network packets. In essence, the client is already a playback system – it simply interprets incoming data and visualizes it.
So the solution was straightforward: during a match, the server records every packet it sends, along with precise timestamps (relative to the start of the match). Once the match ends, all these packets – together with their timing data – are written into a single file, supplemented with information about all participating players.
To play back a replay, I launch the game client in almost the same way as for a normal match, but with command sending completely disabled. In parallel, a separate process reads the recorded packets from the file and replays them at the exact recorded times, emulating server communication. From the client’s perspective, it’s indistinguishable from a live match: it simply receives packets and processes them using the existing logic.
And it worked beautifully. With minimal additional effort, I extended the system to support time scaling (speeding up or slowing down), pausing, and even rewinding or fast-forwarding by a few seconds. Since the server records all packets sent to all players, the replay contains the full dataset, allowing the match to be viewed from any player’s perspective.
The only thing missing from the replay is mouse movement and aiming input, as this data is never sent to the server. However, as a small bonus, I added a feature where the client sends information about items a player inspects in the shop. As a result, even these interactions are captured in the replay.
And finally, I can show you a full match recording. To create this video, I used an older version of the game – the one that was current when the replay was recorded. The game looks quite different now, but I’m documenting its evolution step by step in this blog.
In this match, the teams were uneven – 2 versus 3. However, we invested considerable effort into balancing the gameplay so that differences in team size wouldn’t become a major issue. The game provides both teams with equal access to buffs: each control point emits experience, health regeneration, and energy equally for both sides. If only one hero is present at a control point, they receive the full benefit; if multiple heroes are present, the rewards are shared between them. The key requirement is simply to have at least one player on each active control point.
I consider this a crucial design aspect, since in real-world scenarios uneven teams are quite common. It might be a group of friends with an odd number of players wanting to play a private match, or a situation where someone disconnects mid-game.
Despite the imbalance in team sizes, the match turned out to be highly intense, with the tension lasting right up to the very end.
Write a comment