Force of Nature 2 Dev. Blog

At this point, the core gameplay was essentially complete. Matches felt like a full-fledged experience: they were fun, engaging, and easy to follow even for someone watching from the sidelines. It was time to show the game to the publisher.

As before, I planned to prepare a proper gameplay trailer for them, but things turned out to be much simpler. During one of our discussions, I casually showed what we had built, and the project was approved almost immediately. There was only one piece of feedback: the visuals needed improvement. Without strong visuals, we would be trying to sell nothing more than a game concept on Kickstarter. With appealing graphics, attracting people's attention would be significantly easier.

From that moment on, I put gameplay development aside and shifted my focus to content production. While gameplay experimentation required little more than playtesters, creating actual content demanded at least a small team.

Fortunately, a few people I already knew stepped in to help. A 2D artist and a 3D modeler who had previously worked on Force of Nature 2 joined the project. In addition, one of our playtesters turned out to be a remarkably talented artist and was eager to contribute as well.

Our first task was to decide on the game's setting.

Players leap from platform to platform, freely traversing a world without gravity. We came up with three different ways to explain this behavior and began creating concept sketches for each of them. To make the comparison easier, we chose a small section of a map and reimagined it in several different settings. As a result, the sketches below all depict the same area, interpreted through different thematic lenses.

Space

The first setting that comes to mind whenever someone hears the phrase "zero gravity" is, of course, space.

The action could take place in open space or in orbit around a planet. Characters wearing spacesuits push off from fragments of a space station and drift freely through the void, using jetpacks to adjust their trajectory and maneuver between platforms.

The visual style could lean toward a more realistic depiction of space:

Or embrace a more sci-fi aesthetic:

The heroes themselves could wear a variety of different spacesuits:

Another option would be to use robots as playable characters. This would greatly expand the range of possible silhouettes and designs, since robots can take virtually any form.

This setting is intuitive and fits the core gameplay mechanics exceptionally well. However, let's explore some other possibilities before making a final decision.

Underwater World

The second way to explain the characters' ability to move freely through space was to place them underwater.

In this version, the game would take place on the ocean floor, surrounded by coral reefs, seaweed, schools of fish, and the ruins of a long-abandoned underwater facility.

The characters could still wear suits, though not spacesuits this time. Instead, they would use diving gear and deep-sea exploration equipment.

Floating Islands

Our third option was a world of floating islands, similar to those seen in the movie Avatar. The action would take place high above a planet's surface, in a region where gravity somehow does not apply, allowing characters to fly freely between islands.

Since this is a fantasy setting, our heroes would not require any specialized equipment. This gave us complete freedom when it came to character design. Virtually any type of hero would fit naturally into the world, much like the diverse casts of League of Legends or Dota 2. Because of that, we did not create any dedicated character sketches for this setting – there are already countless examples of suitable fantasy archetypes available online.

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.

I often watch game reviews, and at one point I came across Dome Keeper. What caught my attention was the way the hero collects resources: they tether them with elastic bands, causing the resources to trail behind the character. The player must then physically haul them back to base.

The way these resources respond to changes in the hero’s movement creates a powerful sense of physical presence – precisely the kind of tactile feeling I value so highly in my project. So I decided to adopt a similar mechanic.

From that point on, simply touching a resource was no longer enough. Upon contact, the resource enters an active state and begins trailing the player who captured it, colliding with other resources and with the level’s walls along the way. The player must bring the resource to one of the collection points to score.

Interaction with enemy resources was also expanded. Previously, touching them would merely push them away. Now, contact with an enemy resource destroys it entirely. This allows players to actively interfere with each other’s deliveries – disrupting attempts to score and earning points by denying the opponent’s efforts.

Mega Bombs

The combat changes created the feeling of a brawl between heroes – but that alone wasn’t enough. To truly engage players, the game needed to feel like a battle, a struggle over a meaningful, overarching objective. Simply collecting resources for points wasn’t compelling enough.

That’s when we introduced Mega Bombs.

By collecting resources, players earn points that can be spent to create a Mega Bomb and launch it toward the enemy base, damaging it upon detonation. The scoring system follows a tug-of-war principle. The “rope” starts in a neutral position. Each resource collected by one team shifts it one unit in their direction, while each resource collected by the opposing team shifts it one unit the other way.

To create a Mega Bomb, a team must gain a five-point advantage – in other words, pull the rope five units to their side. Once they do, a player must fly to one of the resource receivers and press a large red button.

The Mega Bomb has a limited lifetime before it detonates automatically. During that time, the team that created it must push it toward the enemy base, while the opposing team tries to stop them.

To control the bomb, a hero grabs onto it as if it were a wall and physically pushes it toward the opponent’s base, where it must explode to deal damage.

Controlling the Mega Bomb is far from easy. It has significant inertia and is difficult to turn sharply. The level is also designed so that it’s impossible to move it straight from the resource spawn point to the enemy base without maneuvering.

Meanwhile, the opposing team can interfere. The Mega Bomb has its own health pool, and the less health it has at the moment of detonation, the less damage it deals. Its health gradually decreases over time, so the faster a team delivers it, the more damage it will ultimately cause.

Opponents cannot damage the Mega Bomb directly, but they can collide with it using their bodies, physically obstructing its movement. They can try to knock the controlling player away with a brick. And if an enemy player is dragging resources behind them, one of those resources will immediately peel off and attack the Mega Bomb, dealing a small amount of damage.

Mega Bomb Levels

A team needs at least 5 points to summon a Mega Bomb. However, they are not required to trigger it immediately – they can continue accumulating points. The more points invested into the bomb (up to a maximum of 10), the stronger it becomes.

Higher-level bombs have more health and a longer detonation timer, giving the team more time to push them to the enemy base (although once the bomb reaches the base, it explodes instantly, without waiting for the timer).

Importantly, the base damage potential of the Mega Bomb does not scale with its level. However, since higher-level bombs start with more health, they are more likely to retain more health upon arrival – and therefore deal greater effective damage.

But that’s not all.

At higher investment thresholds, the bomb gains additional properties. If 7 or more resources are invested, the bomb generates a repulsion field that pushes opponents away, making it much harder for them to block it or interfere using resources.

If the full 10 points are invested, the bomb leaves behind a poisonous trail that damages and poisons enemies caught within it. At the same time, the player who controls the bomb will receive healing as long as he touches the bomb.

When a Mega Bomb appears, resources stop spawning, forcing all players to shift their focus entirely to it.

This method of attacking the enemy base through the Mega Bomb also produced another valuable effect I mentioned in one of my earlier posts – a sawtooth-shaped stress curve. The gameplay naturally breaks into alternating phases with distinct dynamics. First, both teams concentrate on gathering as many resources as possible while preventing their opponents from doing the same, all the while looking for an opportunity to deal meaningful damage. Then, once a Mega Bomb is summoned, one team attempts to escort and protect it, while the other does everything it can to destroy or disrupt it. After that, the cycle begins again.

Resource collection is more methodical and controlled, whereas pushing the bomb is aggressive, risky, and far more intense. It’s during these moments that the real breakthrough potential emerges – the opportunity to significantly advance toward victory in the match.

Unfortunately, at that time we weren’t yet recording full matches, so I can’t showcase complete gameplay footage. Still, with all these additions, the game had already become dramatically more exciting to play.

As I mentioned in the previous post, jumping from wall to wall already felt quite fun, but the game itself lacked purpose. Simply collecting resources quickly became repetitive, and player interaction was weak. Trying to knock away your opponent’s resources was pointless – it was always more efficient to spend a jump collecting your own. So we began implementing combat.

Location Hazards

The first thing we did was give the heroes health. Now, when a player collided with a bomb, they wouldn’t just be knocked back and temporarily lose control – they would also lose a portion of their health. Losing all health would send them back to their base, costing a significant amount of time.

This single change dramatically altered the pace of the game. Players immediately became more cautious. Previously, hitting a bomb carried roughly the same penalty as miscalculating a jump angle. Now bombs were far more dangerous, and players had to think in terms of priorities.

A common dilemma emerged: by jumping in one direction, a player could collect two resources at once – but that same direction might also contain a bomb, turning the jump into a risky move. And where there is risk, there is excitement. Perhaps the risk could be reduced by carefully edging along the wall and jumping from a slightly different position – and that’s where experimentation and creative problem-solving began to flourish.

Once we introduced the ability to lose health, it became necessary to provide a way to restore it. From time to time, alongside its standard set of spawns (two types of resources and bombs), the resource spawner would also generate a medkit. This immediately intensified player interaction: the medkit was valuable to both players, and therefore naturally became a source of conflict.

Auto-Attack

Players could now shoot at each other. I deliberately chose not to overcomplicate the basic attack and made it as accessible as possible: when the player presses the button, the hero automatically attacks the nearest opponent (provided they are within range). The projectile also auto-targets.

This behavior closely resembles combat in MOBA games, where it’s enough to click on an enemy within range – once fired, the projectile is guaranteed to hit, and dodging is impossible. I decided, however, to allow for at least some possibility of evasion. The projectile travels quickly, but at a finite speed and with a limited lifetime, meaning the opponent has a chance to outrun it.

To prevent every close encounter from devolving into the same predictable exchange of shots, the attack needed a cost – some element of risk. Here again, I drew inspiration from MOBA design and implemented a similar anti-spam penalty. When a player attacks their opponent, nearby resources of the opposing color begin attacking the aggressor. Much like in Dota 2 or League of Legends, where minions aggro onto a champion who initiates an attack, the aggressor risks taking significantly more damage than they deal. The projectiles fired by resources can also be dodged — at least in theory.

As a result, every player encounter becomes unique, since the positioning of nearby resources now plays a crucial role. Moreover, situations are often asymmetrical. With certain resource layouts, it may be advantageous for Player A to attack Player B – A will take minimal retaliation from nearby resources – while for Player B, attacking back might be disadvantageous. This opens the door to anticipation and timing: choosing to engage when the situation favors you more than your opponent.

Another distinctive feature of the auto-attack is its variable cooldown. The delay between consecutive shots depends on specific circumstances – namely, how long the projectile takes to reach its target. If the projectile hits almost immediately, the cooldown is short, allowing the next shot to follow quickly. But if the projectile travels for a longer time, the delay before the next attack increases accordingly.

The difference between the minimum and maximum cooldown isn’t dramatic, but it’s enough to achieve the desired effect. Imagine Hero A chasing Hero B while firing, and Hero B retreating while returning fire. Hero A’s projectiles will be chasing their target, taking longer to connect – which reduces A’s rate of fire. Meanwhile, Hero B’s shots travel directly toward the pursuer and land much faster, allowing B to fire more frequently. As a result, Hero A deals less damage than Hero B during the exchange.

This creates an important dynamic: the attacker is in a riskier position than the defender. In other words, aggression costs more than defense. I consider this a fundamental principle of competitive game design – attacking should always be more difficult and more dangerous than defending. It establishes the right combat rhythm. Players shouldn’t attack recklessly; instead, they should carefully alternate between offense and defense, looking for mistakes and capitalizing on them when the opportunity arises.

Abilities

In addition to the basic attack, we introduced abilities that players could cast from time to time. The initial set looked like this:

• Dynamite. The player throws a stick of dynamite that begins pulling everything nearby toward itself. Upon contact with an enemy hero, it explodes, dealing heavy damage both to the target and to anyone caught in the blast radius.

• Brick. The player throws a brick that passes through walls and reacts only to enemy heroes. It deals no direct damage, but it knocks opponents off walls or strongly pushes them while they are airborne. The brick can also shove resources and bombs, making it a powerful tool for controlling the battlefield.

• Wall Strike. The hero strikes the wall they are currently holding onto, damaging all opponents who are attached to the same wall or standing very close to it. The hit also knocks players off the wall.

Unlike many MOBA games, where projectiles typically interact only with heroes, our projectiles exist within the same physical world as all other objects and characters. As mentioned earlier, the brick isn’t just a way to push an opponent – it can also manipulate resources and bombs, helping you (and potentially your allies) control the situation. You can plant dynamite and then nudge it with your body or a brick, making it even more dangerous.

We always intended to further expand this kind of projectile interaction. It allows abilities to combine with one another, unlocking new properties and emergent use cases through systemic design rather than scripted outcomes.

Dash

Another addition was the dash. After performing a jump – and before regaining the ability to execute the next full jump – the hero can perform one short lateral burst of movement.

Originally, the dash was meant purely as a defensive maneuver. It didn’t alter the hero’s movement vector, but simply shifted them slightly to the side. However, this severely undermined the sense of physicality – it felt as if characters were zigzagging mid-air in an unnatural way.

We eventually revised its behavior and turned it into a weaker secondary jump instead. In many ways, it now resembles a double jump – a mechanic beloved by many players for the freedom and expressiveness it provides.

And so, with this post, I am officially beginning the devlog for my new project.

Having become thoroughly familiar with the Unity engine during the development of Force of Nature 2, I decided to stick with it for this project as well. At this early stage, implementing fancy graphics, animations, visual effects, or sound design wasn't a priority. To test whether the wall-to-wall movement mechanics actually worked, simple 2D abstractions were more than enough: a circle representing the character and polygons acting as obstacles.

Map Editor

To create the maps, I utilized my own custom vector editor, originally developed for FoN2. This tool allows me to draw and edit various shapes, assign tags and metadata to them, and even load raster images to serve as masks. I previously used it to create templates for procedural location generation in Force of Nature 2.

Later, while working on a MOBA prototype, I expanded the toolkit to handle the diagonal symmetry often found in that genre. The editor saves data in a custom file format, which is then imported into Unity via specific scripts, converting it into a structure that is easy to work with. I designed the code handling this format to be completely decoupled from the main game logic, so porting it to the new project was effortless.

Physics Implementation

As I mentioned in the previous post, the core concept of this project relies heavily on physics – an area of Unity I hadn't actually touched yet. The reason is simple: Force of Nature 2 didn't use it.

In that game, all projectiles followed simple parabolic arcs controlled by scripts. Even character collisions – whether with each other or the environment – were handled by custom logic. These systems were ported from the first game, which was built on a custom engine where I wrote everything from scratch. That legacy physics engine was quite rudimentary; it lacked surface friction and couldn't handle interactions between complex shapes, making it unsuitable for this new project.

Unity's 2D physics engine turned out to be quite intuitive. The basic setup is quick: assign polygon colliders to the level geometry, circle colliders to the characters, tweak some physics materials, and disable gravity. Since we are working in a top-down 2D plane where height isn't a factor, gravity is unnecessary. Movement works via mouse clicks: clicking applies a single impulse to the character (a ball), launching it toward the cursor. However, getting the character to actually stick to the environment proved to be a significant challenge.

In a typical platformer, gravity and friction keep a character grounded. But without gravity, I needed a different mechanism to anchor the character to a platform's edge; otherwise, even the slightest force would send them drifting away. Unity offers a way to link objects called "Joints" (Fixed, Spring, Wheel, etc.). Unfortunately, none of the built-in options allow one object to slide along the surface of another. This was exactly the behavior I required: once the character grabs a wall, they need to be able to move along it.

To achieve this, I had to bypass Unity's standard physics and implement a custom solution. When the character touches a wall, they attach to it using a Fixed Joint, but from that point on, I manually control their position via script. I calculate a contour around the wall, offset by a distance equal to the character's radius. The character can then slide freely along this calculated path in response to control inputs.

When a jump command is issued, the Joint breaks, and the character is handed back to Unity's physics engine. To ensure the transition between physics-based movement and script-based attachment is seamless, I also calculate the character's movement vector just before impact. I project this vector onto the platform's surface and apply a small, decaying impulse in that direction. This simulates friction, creating the sensation of gradually skidding to a halt against the surface.

The "Public IP" Problem

The next hurdle I faced was implementing player-to-player networking. On the surface, multiplayer looks simple: one player sends data to another, and the characters on both screens move in sync. In reality, however, computers on the internet can’t just "reach out and touch" one another. Almost all home devices sit behind so-called private addresses – they are invisible to the outside internet. To be reachable from the outside, a computer needs a Public IP address and an open entry point into the network.

Simply put: your computer is hiding behind a router, and other players can't send you anything directly unless you open the "door" yourself.

In major titles, specialized network services handle these issues. For example, when I released my previous games on Steam, I relied on Steam's ability to automatically relay data between players through their own servers. Players could connect to each other seamlessly, with Steam handling all the complexity behind the scenes.

However, this approach had a downside. During the holidays, when millions of users flooded Steam, their relay servers would get overloaded, and multiplayer performance suffered. Connections would appear and disappear randomly, purely due to the heavy load.

For this new game, I don't have access to that Steam "magic" yet, and the test server needs to function on its own. So, for this development phase, I had to set everything up manually:

• Configure DDNS: This service assigns a constant hostname to my home server, ensuring it can be found even if my ISP changes my IP address.
• Set up Port Forwarding: This involves configuring the router to open that specific "door," allowing external connections to reach my test server.

Only after doing this was I able to host a server at home that other people could actually connect to. For the actual transmission of data packets, I utilized Unity's built-in networking mechanisms.

Resource Gathering

Movement alone – no matter how unique – doesn't make a game. I needed to implement at least a minimal goal for players to compete over. To serve this purpose, I hastily threw together a basic resource collection mechanic:

A "spawner" floats lazily across the map, periodically ejecting clusters of resources. These resources come in two colors, corresponding to the opposing teams: the green team must collect green resources, and the red team collects red ones. Collecting a resource nets the team a point. While you can't collect enemy resources, you can knock them away to make the opponent's life more difficult. In addition to resources, the spawner also spits out small bombs; colliding with one sends the player flying and disables their controls for a few seconds.

Players primarily move by jumping, which applies an instant velocity vector in the chosen direction. While clinging to a wall allows for slow sliding, jumping remains the fastest way to traverse the map. While airborne, players can also apply a slight force to fine-tune their trajectory – essentially, limited air control.

This simple rule set was the first to be implemented. Here is the result – the very first gameplay test of the new project:

Unfortunately, the recording frame rate turned out quite low, though the game itself ran smoothly during the session.

After playing for a few minutes, we realized that the movement mechanics are actually quite easy to get used to and don't cause any motion sickness or discomfort. However, player interaction felt almost non-existent. To fix this, we decided to deepen the gameplay and introduce combat elements.

So, I faced a tough challenge – to come up with a fresh idea that would make the gameplay engaging yet easy to understand. Not an easy task, as you can imagine – Steam is full of dull, uninspired games. Many game designers struggle with this problem, and I’ve spent a lot of time chasing that “fun” gameplay idea myself, but so far, I’ve come up empty-handed.

If I put together everything I want to see in my game, I end up with quite a long list of requirements! Let’s start by fixing one thing: it should be a team-based game, where one team fights another. What else do we know about the gameplay?

• Although it’s a team game, it shouldn’t require constant communication between teammates – each player should have a clear, fixed role and understand how their individual actions contribute to the team’s victory.
• Players from opposing teams should constantly interact. Interactions within the team and with the environment are also beneficial for gameplay.
• The game should offer meaningful choices as it progresses – decisions that genuinely impact the team’s success. Whenever possible, players should be spared from making meaningless choices that have no effect on the match.
• Players should be able to evaluate the effectiveness of their choices. They will experiment in various situations, and they need to understand which of their outcomes were beneficial and which were not – ideally, in measurable terms.
• Player progression should be handled carefully to avoid a “snowball effect”, where one team pulls too far ahead and the other has no chance to recover. It’s better to reward successful actions with one-time progress toward victory rather than with permanent power boosts.
• The game should avoid adding dull, repetitive tasks just for the sake of variety – artificial complexity is worse than simplicity.
• Rewards should be distributed to both teams evenly, at a steady pace, preventing players from speedrunning their way to victory.
• The core mechanics – the routine actions that make up the bulk of the gameplay – should be visible to the enemy team. What you’re doing most of the time should be observable by your opponents, and vice versa. This visibility allows players to learn from stronger opponents, even after losing.
• The game as a whole should have its own rhythm. Intense moments should alternate with calmer ones, giving players time to both focus and relax.
• Above all, the gameplay should remain simple and intuitive.

All these points are essentially a distilled summary of my previous posts. They grew out of analyzing the mistakes I made while building earlier versions of the game. There are quite a few of them, and getting all these principles to coexist peacefully is no easy task. For example, gameplay should be varied – yet compact, free of unnecessary clutter, and simple enough to grasp quickly. How do you even begin to balance all that?

In search of answers, I started reading tons of articles on gameplay design – and that’s when collections of game mechanics came to my rescue. In such articles, authors catalog mechanics and compile them into lists. There are many like these out there, featuring dozens or even hundreds of mechanics – 50 (Monkey’s Lunch), 100 (GMTK), or even 300! (Squidi.net)

I can’t recall exactly which list I was looking at, but two mechanics really caught my attention: Physics and Parkour.

Physics

Physics in games is one of those things that makes virtual worlds feel truly alive. It relies on familiar, intuitive rules – objects fall, collide, swing, bounce off each other. The player doesn’t need to study a tutorial to understand how a ball rolls or why a bridge collapses under weight – it just feels right. Because of that, physics becomes a natural way to draw the player in, to build trust in the world, and to make the controls feel more tangible.

But physics is valuable not just because it’s familiar. It’s also a powerful generator of emergent situations and unexpected solutions. The developer only sets the rules – mass, friction, elasticity – and from there, the system begins to live its own life. One player might stack crates to make a ladder, another might hurl them at enemies, and a third might block a doorway with them. That freedom makes every session unique: wherever there’s physics, there’s room for improvisation and for stories that can’t be scripted. Many of the most memorable gaming moments are born not from storylines, but from the unplanned collision of physical systems.

Parkour

Parkour is perhaps one of the most expressive and emotionally charged mechanics in games – and it’s closely tied to physics, the physics of movement. It evokes that same sense of freedom we feel when running, jumping, or climbing in real life. Even if the controls are simplified to just a few buttons, the player still feels it’s them overcoming obstacles, catching that ledge, or leaping away at the last possible moment.

However, parkour isn’t always about realism. Often, it goes beyond the limits of the real world: characters run along walls, push off ceilings, swing from ropes, or use jetpacks and magical impulses. The goal isn’t strict adherence to physics, but rather the feeling of movement – the mix of lightness, control, and risk.

From a historical perspective, parkour was almost a revolution in how games handled movement. Once upon a time, characters could only jump along preset arcs – like in old platformers. But when developers introduced mechanics like grabbing onto ledges and pulling up, game worlds suddenly felt deeper. There was a new sense that the player was truly interacting with the environment rather than just moving through a predesigned path. Think of the first Prince of Persia or Tomb Raider – those moments when the hero barely catches the edge of a cliff became a symbol of living, dynamic gameplay.

Sports Games

Physics and parkour are essentially two sides of the same phenomenon – the interaction between humans, movement, and space. In real-world sports, this connection is everywhere. Football, hockey, basketball, tennis, boxing, racing – all revolve around how a person learns to master both their own body and the laws of physics. The ball bounces, the ice is slippery, the power of a strike must be precise, the angle of a jump calculated perfectly. It’s always a balance between inner control and external forces. And that’s exactly why sports are fascinating even to those who’ve never held a hockey stick or sat behind a racing wheel: the physics are intuitive, but the execution demands skill.

In team-based video games, the same formula works just as well. When characters slide, leap, pull off risky maneuvers, or use momentum, players are engaging with the same principles – controlling motion, feeling weight and inertia, and treating the environment as an ally. This makes the gameplay both exciting and readable even to spectators. Physics and parkour create a shared language of interaction, one that communicates without words. We see how precisely a jump is timed, how perfectly a dash is executed, or how fragile the balance is in a collision. All of this generates tension, thrill, and respect for mastery – whether it happens on a field or on a screen.

Wall-to-Wall Sliding

Physics is, at its core, about inertia and collisions, while parkour is about using not just your legs, but your entire body to move through space. Combined, they create a unique sense of physical presence within the game world. That’s when I imagined a mechanic blending the two: players move not by running on the ground, but by pushing off walls with their hands. The floor is so slippery that walking is nearly impossible – you can only slightly steer your trajectory. The movement flow comes from a sequence of pushes, impacts, and impulses, as players use the environment itself as a means of locomotion.

In such a setting, physics becomes a full-fledged battleground. Players can collide, knock each other off course, and interfere with each other’s objectives. Movement turns into a skill-based challenge, full of risk and precision. While sliding, a character isn’t entirely in control – and that lack of control creates tension, where every mistake costs momentum or leads to a dangerous crash.

Of course, such a mechanic demands incredibly fine-tuned implementation. Tiny details make all the difference – friction coefficients, push force, jump timing. A single imbalance can turn smooth, exhilarating motion into something clumsy or frustrating. This is especially true in platformers: thousands of games feature jumping from one platform to another, yet only a few feel right. In successful ones, the timing of a jump, landing, and impulse is tuned to milliseconds, creating that flow state where the controls feel like an extension of the player’s body.

So the next step was to test the idea in practice – to see whether the movement would actually feel as fun and unusual as it did in my imagination. On paper, everything looked great, but I quickly discovered that implementing such a mechanic in Force of Nature 2 was impossible. The entire world there is structured as a grid of cells, each either passable or not. Mountains and obstacles can be rendered at an angle, but from the physics standpoint, their edges are just neatly stacked steps of square tiles. All borders run only in two perpendicular directions, which means I can’t use arbitrary angles when building a level – and those are essential for the mechanic to work.

Still, that’s not a big deal. All I needed was to test the theory in practice. So I decided to leave Force of Nature 2 behind and continue the development as a completely new project.

We sent the publishers a gameplay video – the same one I shared in that earlier post. Before watching it for the first time, they specifically asked me not to provide any explanations about the rules. They wanted to see the game exactly as a potential backer on Kickstarter might, without any guidance. Later, of course, I gave them a thorough breakdown of the gameplay.

Their feedback was this:

1. “The gameplay is too complex for an outside viewer to easily grasp what’s happening on screen.”
2. “The game blends too many different mechanics, which risks making some roles feel much more desirable than others.”

Their conclusion: “You could try going to Kickstarter, but there’s a high chance the game won’t be understood.”

That was essentially it. They didn’t give me a flat “No.” Instead, they said, “We can try to work with this, but the odds of success are low.” The final decision was mine to make.

I tried looking at my creation from the outside, and it didn’t take long to realize they were absolutely right. The game had become a mix of several genres – hero combat, resource gathering, and card-table mechanics. Even someone familiar with the MOBA genre would have to absorb a huge amount of new information just to start playing. And for someone who isn’t familiar with MOBAs, understanding the game would be even more daunting.

The roles themselves weren’t truly balanced either. While a team can have any number of champions, the forester must be exactly one – no more, no less. If the forester leaves mid-match, their team is almost guaranteed to lose. Yet playing a forester in a one-on-one duel without champions is far less fun than playing as part of a full team.

In my effort to make the gameplay cohesive, logical, and complete, I had stitched together something like a Frankenstein’s monster of game mechanics. Could it work? I think so – at least for us, the testers, it felt exciting and engaging. But we’d been immersed in it for a long time, gradually learning its systems and strategies. Would a new player find it just as compelling to dive in and master all its intricacies? I honestly didn’t know.

And let’s not forget: for a game like this to succeed, it needs hundreds of active players at all times. It has to hit critical mass right from the start, or it will quickly fade. Sure, it might find a niche audience – but would that niche be large enough to consistently fill two balanced teams from the matchmaking queue?

All of these questions terrified me because I had no clear answers. The risks were undeniably huge. So, I decided I wasn’t ready to take it to Kickstarter – not yet. But I also knew I couldn’t keep pushing the project forward at the same pace. Something radical had to change.

A Team of Foresters Only

The first idea was to remove the champions entirely and leave only the foresters – teams of foresters battling each other. By cutting out the “half” of the game tied to champions, we could make things much clearer for players. The barrier to entry would be much lower, since mastering just a single role would be enough to start playing.

But without champions, the entire current gameplay begins to fall apart. The whole system is built around foresters acting as support. They’re highly dynamic and crucial, yes, but ultimately not the frontline fighters. If you imagine a team as a living organism, the champions are its arms and legs, while the forester is the head. To win, you must defeat your opponent physically – the main work is done by the arms and legs, while the head coordinates everything. It’s the same in our game: victory comes from dealing physical damage to the enemy base, primarily through the champions, while foresters create the right conditions for their teammates to grow stronger. If you remove the arms and legs but add more heads, there’s no one left to fight. That means the very goal of victory and the way to achieve it would have to change.

In other words, cutting out the champion-related half of the game also removes its foundation – its core identity of destroying the opponent’s base through combat skill. A new foundation would need to be built from scratch. But doing that beneath an already-finished “house” seems like a terrible plan.

There was another problem: I had no clear idea how multiple foresters on the same team could even interact with one another. Beyond resource gathering, the game relies heavily on a turn-based rhythm – the “gathering” phase and the “purchasing” phase – which is deeply intertwined with the forester’s actions. If there are multiple foresters, how should turn order work?

Would each player have their own phase that switches independently over time? That would turn the game into chaos. Previously, the alternating phases created a special dynamic between the two opposing foresters – a kind of tag game where first one chases the other, then the roles reverse. But with multiple players, each on their own phase, that interaction breaks down. Some players on Team A would be chasing part of Team B, while others on Team A would be fleeing from the rest of Team B – and the roles would keep swapping unpredictably. It would become a confusing mess.

What if the “purchasing” and “resource gathering” phases switched for the entire team at once? That’s slightly more plausible, but it still raises plenty of issues. To keep gameplay satisfying, we had added various ways to influence turn changes depending on immediate needs. Sometimes, changing turns even served as a punishment (for example, entering combat would cost you your resource-gathering phase). In a team setting, all of these systems would break, and entirely new mechanics would be needed.

I spent some time trying to solve these problems but quickly realized I wasn’t likely to produce anything worthwhile this way.

Hero Defence

The next idea actually came from the publishers themselves. They suggested completely changing the genre and turning the game into a team-based Hero Defence. This is a variation of Tower Defence where waves of monsters periodically march toward your base along fixed paths – but instead of relying on towers you’ve built, you personally control a hero with unique spells and abilities, leveling them up over time.

Up to this point, all my gameplay had been built around the MOBA genre, which itself traces back to a Warcraft III custom map – Dota. If you look at the most popular Warcraft III custom maps of all time (for example here), Dota naturally holds the top spot, but right behind it is Legion TD. So yes, this genre has a proven audience, and there are plenty of similar games on Steam.

Since I was in a creative slump, I decided to take some time and build a small prototype in this genre. My first attempt wasn’t team-based: a single hero had to fend off waves of monsters. But the idea was that it could be expanded into team battles, where each hero defends against their own wave of monsters while all heroes share the same core objective and can assist each other. Players would also be able to send various obstacles and disruptions to the opposing team.

I implemented the basic mechanics, using my existing champions as heroes. But I quickly realized I couldn’t commit to developing a full game in this genre – I was simply too unfamiliar with it and couldn’t get a good feel for it. It’s not enough to just copy an existing game; you need to add unique elements that set your version apart from the competition. And I didn’t know these games well enough to understand the emotions players experience when playing them. So, I decided to abandon the idea. Still, here’s what I managed to put together:

As you can see, things weren’t looking great. Continuing in the original direction was far too risky, and I didn’t have any fresh ideas yet. It sounded like a dead end. But don’t worry – this story has a happy ending. A solution was found, and my team and I have been working on it for quite a while now. In fact, this entire blog series about developing a network-based battle game – starting from that very first post – was written after I had already built a fully playable prototype of the next idea, shown it to the publishers, and received their approval.

So, everything up to this point has just been the backstory. I’ll talk about the new stage of the game’s development in the upcoming posts.

P.S. As for the version with foresters and resource gathering – I won’t throw it away. When I have some free time, I plan to polish it into a full-fledged mod for Force of Nature 2 and release it publicly.

While we were waiting to hear back from the publisher, we continued developing our game.

New Spell Cards

The more spell cards we add, the more variety each match can offer — so we decided to introduce a few new ones:

• Spy. This spell makes the player invisible for 5 seconds. However, the effect immediately ends if the player performs any attack or casts another spell. It's perfect for escaping a chase, or for sneaking up on a target unnoticed.
• Cage. This card lets you place an invisible trap on the map. If an enemy steps on it, the trap turns into a small cage area that lasts for 5 seconds before disappearing. Any enemies caught inside are trapped and can't leave the area, though they can still move freely within it, attack, and use spells.
• Interception. Since the game now features quite a few invisible elements — traps, cages, spider eggs, and spy heroes — we decided to add a counterspell: the Interception. This area-based spell reveals all invisible enemy objects within its radius. It instantly exposes spies and interrupts their teleportation home. Additionally, any enemy structures placed by the Forester — even if invisible — are captured. For example, if a Forester sets an invisible trap cage and the opposing player correctly guesses its location and casts Interception there, the cage will switch ownership to the second Forester and become invisible to the original one.

We also gave Gnome-archers a new ability: they can now see all invisible objects around them — traps, cages, spider eggs, and spies. Gnomes now work well in tandem with the Radar spell: they can detect hidden traps, while Interception allows them to take control of them.

Here’s a recording of a game session where we tested the Spy and Interception cards:

New Hero: Shaman

We also got tired of playing Foresters with the same old matchups — Poison Warlock vs. Bomber — so we decided to introduce a new Forester: the Shaman.

Here are his abilities:

• Q – Dart. At regular intervals, the Shaman gains a dart, up to a maximum of three. He can throw a dart in a chosen direction at any time — even while stunned. Darts can be fired one after another with no cooldown between throws.
• W – Spikes. The Shaman unleashes a wave of spikes from the ground. These spikes deal physical damage and travel through terrain, including buildings and mountains. The damage increases the longer the wave travels. If you hit an enemy at close range, the damage will be minor. But if you manage to hit them after the wave has traveled some distance, the damage ramps up significantly. However, this also gives enemies more time to react and dodge.
• E – Control. The Shaman pushes all nearby enemies in a chosen direction, covering a fairly wide area. This spell can be used both defensively — to push enemies away — or offensively, to pull them closer. You can also use it to shove enemies into traps, under towers, or toward a Gnome.
• R – Stupor. The Shaman summons thorny vines from the ground that grab and immobilize all nearby enemies. While affected enemies can still attack and cast spells, they’re unable to move.

New Death Mechanic for Foresters

When one champion kills another, they’re faced with a clear choice on how to use the time while their opponent is off the map. They can either return to base to heal and buy items, or push the lane while uncontested. It’s a conscious decision with well-understood consequences — a deliberate gameplay choice.

For Foresters, the situation is a bit different. When one Forester kills the other, they also get a window of opportunity while their opponent is dead. They can return to base to recover and shop. But what if they don’t need healing and have no desire to go back to base? How should they celebrate their victory?

If it’s currently their gathering phase, they can freely collect their three resources. But that doesn’t offer the same impactful reward as, say, a champion pushing a lane and damaging the enemy tower. And if it’s their purchasing phase, they have nothing useful to do — and they can’t end the phase early either.

Sure, they could attempt a gank on a lane, but that takes time and usually has limited impact — after all, a Forester isn’t really meant to be a fighter.

To make killing an enemy Forester more meaningful — and to add an element of deliberate choice — we decided to rework the reward system. Now, defeating a Forester grants much less gold than before. However, five treasure chests appear randomly on the map. Destroying these chests yields bonus gold, with the amount increasing for each successive chest: 2, 4, 6, 8, and 20 coins. The chests disappear the moment the defeated Forester returns to the forest.

Teammate champions of the fallen Forester can also destroy the chests — but they won’t receive any gold. Instead, doing so denies the enemy team the extra reward.

These chests give the victorious Forester a choice. Going after them is risky — the enemy champions know where the chests are and will likely intercept you. But if you succeed, you can turn a modest reward into a significant payoff.

This also adds new dynamics for the champions: they know it’s worth destroying as many chests as possible to deny the enemy Forester their reward. However, the chests are located in the forest — and without their own Forester alive, the forest is shrouded in fog of war. They’ll only see a small area around themselves. Meanwhile, the enemy team’s Forester is still alive and provides full vision of the forest for their allies.

Scenario Events

Like in other MOBA games, we wanted to introduce global events that occur independently of the players' actions — similar to dragon spawns in League of Legends or Roshan in Dota. These events act as focal points, drawing both teams together and often triggering large team fights.

We decided to add a similar mechanic to our game. At the 20th and 30th minute marks, a crystal appears in the center of the map, at the location of the central teleport. Initially, the crystal belongs to no one. Any player near it begins to pull a “tug-of-war” bar of ownership toward their team. If both teams have the same number of players nearby, the bar remains still. But if one team outnumbers the other, it slowly shifts in their favor.

Once a team fully captures the crystal, all its members receive powerful aura buffs. However, when the crystal first appears, it releases a burst of energy that instantly kills all nearby heroes. So teams should avoid standing directly on the spawn point — it’s safer to wait a little farther away.

Unfortunately, I didn’t manage to save any footage showcasing the most recent changes — the new hero, treasure chests, and the crystal event — so in this post I’m only sharing gameplay featuring the two new cards: Spy and Interception.

Let me briefly recap the previous post to set the stage. My main goal is to launch a Kickstarter campaign, and for that, I need to showcase gameplay that is both clear and visually impressive.

By this point, the core gameplay of our game had already solidified – no major changes were being made anymore. We were mostly focused on balancing and adding new spell cards. Since each match features no more than four cards, and balance nuances can’t really be conveyed through a video, we decided it was time to present our creation to a publisher. Their feedback would help us assess the risks of going to Kickstarter with the current state of the game.

We split into two teams: the first team had a champion Archer and a forester Bomber; the second team included a champion Mage (played by me) and a Poisonous Warlock as the forester. By now, we were all very familiar with the game’s rules, had developed our own tactics and strategies, and knew the key timings – so the match turned out intense and exciting.

Each match usually features four randomly selected spell cards. However, for the demo reel, we decided to lock in the following cards:

• Dynamite, which lets you rig all deposits of a certain resource to explode when an enemy forester tries to harvest it;
• Grenade, which follows an arcing trajectory and can be thrown over obstacles;
• Mud Grenade, which creates a swampy area that slows down all enemies moving through it;
• Silence, which disables the use of spells and abilities for all nearby enemies for a short time.

Each player recorded their own screen, and we later stitched the footage into one seamless video. Unfortunately, one tester’s PC struggled while screen recording, so we had to set their graphics settings to minimum. But that wasn’t a big deal – they were playing the champion Archer from the first team, and the focus of the demo was mainly on the forester heroes anyway.

Another issue we ran into was that each player recorded gameplay from their own point of view. As a result, in the final video, switching between characters made it a bit disorienting – it was hard to tell who was on screen and where on the map they were. One moment, you're following a hero in the center of the screen, and then – suddenly – it's a completely different character in a different location.

To make the game more intuitive during playtests, we had implemented a system where each player's own character and their allies are always highlighted in green, while enemies are shown in red. This way, players don’t have to mentally remap the color scheme when switching teams – your side is always green, the enemy always red. This approach, similar to what you see in DoTA or League of Legends, worked well during playtesting.

However, this created a new challenge for the video. Since the main character on screen is always green regardless of which team they’re on, it becomes unclear to the viewer which team they’re actually watching. To address this, I added colored corner highlights during editing: green corners for one team, red for the other.

Unfortunately, that wasn’t quite enough. Viewers naturally focus on the center of the screen, and the corners are only perceived through peripheral vision. There simply wasn't enough time during the video for the viewer’s peripheral vision to reliably pick up on these cues.

To make team identification more intuitive, I decided to add background music as an additional layer of feedback. For the green team, I used a melodic, relaxing track infused with nature sounds. For the red team, I picked an upbeat, rhythmic electronic track. I believe this made it much easier to follow which team is which throughout the video.

Just to clarify: this video wasn’t meant for Kickstarter yet – it was created specifically for a publisher. While the publisher already had a rough idea of the game we were working on, they weren’t familiar with the gameplay in detail. Still, they specifically asked us not to provide any explanatory commentary with the video. They wanted to evaluate the gameplay with a completely fresh perspective – just like a potential Kickstarter backer might, watching the video without any prior context.

So here it is – the demo reel we submitted to the publisher for review.

Today, I found myself once again pondering a familiar question: why did I decide to create a game in an entirely new genre? Why not just make Force of Nature 3? After all, I had already achieved some success in that genre and built a small but engaged community.

Anyone who played both parts of Force of Nature likely noticed how different they are from a technical standpoint. I developed the first game with virtually no experience in game development, which meant I made every possible mistake along the way. In fact, when I started working on it, I had no intention of ever selling it.

Medical Visualization

At one of my previous jobs, I worked in computer graphics – specifically, volume visualization for medical equipment. Devices like CT, MRI, and ultrasound scanners can capture data from beneath the skin. This data is stored in volumetric cubes, where each voxel encodes a specific material property – such as X-ray density or magnetic susceptibility. Naturally, this creates a need to visualize the data in a clear and useful way: to explore the inside of the human body, isolate what the doctor needs to see, remove unnecessary details, and take measurements.

Standard 3D rendering techniques are great for visualizing surfaces – but these machines don’t give us surfaces, only density values. Of course, there are algorithms that can reconstruct surfaces from volumetric data, and we worked on those too. However, they’re not entirely reliable and often fail to provide accurate or consistent surface definitions. In medical devices, such uncertainty is unacceptable, which is why voxel-based rendering – without explicit surface reconstruction – is typically preferred. The resulting visualization doesn’t have sharply defined boundaries but instead faithfully presents the raw data as captured by the scanner.

I found this work fascinating. Programming for GPUs is very different from programming for CPUs. The GPU’s architecture is unique, with a limited and specialized set of capabilities, meaning that common programming patterns often don’t apply. Even traditional polygon rasterization techniques were of little use here – volume rendering relies on ray tracing methods, and at the time, GPUs didn’t yet have dedicated instructions for that. Each new task felt like a puzzle, and solving it brought genuine satisfaction. Over time, I became deeply knowledgeable in this area. I began developing my own techniques and even managed to implement some features that our competitors didn’t have.

A Hobby Project

One day, while playing Terraria, I suddenly realized that I had all the skills necessary to make a similar game – perhaps even in 3D. The idea excited me, and I decided to try building my own polygon-based renderer. Just a day later, I already had a basic prototype: I could fly over a simple landscape made up of different types of soil. Within a week, the world had water, grass, and trees. It was incredibly exciting to keep adding more and more elements to this world. I named the project The Island.

At the time, accessible and free game engines like we have today simply didn’t exist. Both Unreal Engine and Unity required paid licenses. But I wasn’t aiming to make a full-fledged game anyway – I had no idea how I would even distribute it. Steam didn’t have its Greenlight program yet and mostly featured big-budget titles. I just wanted to challenge myself – to build something from scratch, entirely with my own hands. It was a hobby project, and progress was slow, since I was working two jobs and writing my PhD thesis at the same time.

Greenlight

In July 2012, Steam launched Greenlight – a system that allowed developers to get their games onto the platform through community voting. I didn’t hear about it right away, but when I did, I immediately set a new goal: to turn my hobby project into something complete. By then, I already had procedural world generation with a variety of biomes, but there was still a long road ahead – skeletal animation, AI, UI, sound design, construction mechanics, special effects, and countless other small systems. Since I wasn’t using any game engine, I had to build every single part myself. There were plenty of complex challenges, but overcoming them was always rewarding.

My two jobs were taking up a huge amount of time and energy. Eventually, I realized I might never finish the game unless I made a bold move – so I left my well-paid job at a large American medical company. My coworkers were surprised; landing that position hadn’t been easy. And it’s not like I was leaving for a better opportunity elsewhere – I was leaving for a self-made hobby project, cobbled together on my own.

But the decision was made, and after that, development kicked into high gear. In the end, the game was ready and submitted to the Greenlight community. Two weeks later, it was approved – those were some of the most nerve-wracking weeks of my life.

Three more months of intense work later, the game was officially released on Steam.

Force of Nature

I’m not sure how successful my project would be considered. There are solo-developed games that have achieved far greater popularity. Since I built my own engine, the graphics were already a bit outdated by the time the game was released. Still, for me personally, the sales were a clear success. I realized that I could now make a decent living from my hobby – working with joy instead of pressure. And without a boss hovering above me. That was an amazing feeling.

But it also came with responsibility – now I had to make every decision myself, and there were no guarantees of stable income. So I got straight back to work, adding new items, buildings, and implementing a co-op mode.

However, I started running into a major issue – any new feature I wanted to implement had to be developed entirely by me. Around that time, free engines like Unity 5 and Unreal Engine 4 were becoming mainstream, giving indie developers access to modern tools and effects and allowing them to work much faster. If I continued with my custom engine, I’d quickly fall behind. So it became clear: I had to switch to one of the modern engines. Porting Force of Nature to a new engine would have meant rewriting everything from scratch. So instead, I decided it was more efficient to begin work on a full sequel.

Force of Nature 2

After spending some time evaluating both Unreal and Unity, I decided to go with Unity. (I’ve written more about my engine choice here and here.) I had to learn how to use Unity’s assets, shaders, animation system, and UI tools – but before long, development was in full swing. Now I didn’t have to spend most of my time on technical challenges. I could focus on the game itself – on better controls, a clearer interface, helpful hints, and an actual storyline. I could implement smarter enemy behavior and a deeper combat system. All of this received far more attention in the sequel than in the original.

Thanks to the steady income from the first game’s sales, I was also able to hire a few helpers – artists, 3D modelers, animators, and a sound designer. In the first game, I had to constantly decide whether to spend time creating a new monster myself or use a ready-made (often flawed) asset from an online store – and I usually chose the latter. But now, I could create exactly what I wanted for each specific biome. Whereas before I had to piece the game together from whatever I had lying around, now I could build it the way I had always envisioned.

In the end, I feel that Force of Nature 2 is far more polished than the original. To me, it’s a game that genuinely looks at home on the Steam store, without the amateur feel of the first one.

Some players might disagree – I’ve seen reviews saying I should’ve continued developing the original game instead. But judging by the ratings, the sequel resonated more with players: 80% positive reviews compared to 75% for the first.

And yet, here’s what really surprised me: Force of Nature 2 had deeper mechanics, more content, higher quality, better reviews… and still made less money at launch than the original.

The reason? In 2016, when the first game came out, about 11 games were released on Steam each day. By 2021, that number had risen to 33. Competition had tripled – and if you narrow it down to open-world survival games, it had grown more than fourfold. Sure, many of those games are low quality, but there are plenty of solid ones too. Which means today, a fan of survival games has to choose between mine and three other titles of similar quality.

Crytivo

After Steam ended the Greenlight system, the indie game market began to grow rapidly. That meant I now had to think about how to make my game stand out among the flood of new titles. I considered two options: marketing companies, which simply take your money and build a promotional strategy; and publishers, who also promote the game but consistently take a cut of your revenue. I didn’t know much about marketing, so the choice was tough. But in the end, I decided that a publisher would be more motivated to promote the game effectively, since their income would grow along with mine.

Still, picking a publisher requires caution – it's easy to end up with one that does absolutely nothing yet still takes half your revenue. And that’s not just a problem with small companies that don’t know what they’re doing. Even large firms can be guilty of this.

It’s pretty hard to find honest, up-to-date information about game publishers, but I came across quite a few positive reviews about one company and decided to reach out. They were interested in my game too, and that’s how I ended up signing a contract with Crytivo.

As it turned out, working with a publisher wasn’t scary at all. I didn’t lose an ounce of creative independence – I was still free to decide what to work on and which direction to take. Yes, they did suggest a few things right away. But all their suggestions were just that – recommendations. They were also well-reasoned and very convincing, so I agreed to all the changes immediately.

In addition to promotion, Crytivo also handled registration of the game on several platforms besides Steam. Of course, those platforms don’t bring in nearly as much revenue as Steam, but I did the math, and combined, their sales just about cover the portion of income I share with the publisher.

Plus, sales on Steam noticeably increased too, so overall, I definitely came out ahead.

Beyond the marketing, I also gained access to a network of experienced people – folks who had faced many situations, worked with various teams, and were always ready to answer my questions and offer advice. It became much easier for me to make tough decisions about the game’s development. I can’t say all publishers operate this way, but my experience was definitely a positive one.

Future Plans

And so I came to the most important question: what should I do next?

The obvious idea was to start working on Force of Nature 3. But something was bothering me.

Even though partnering with a publisher had boosted the sales of the second game, the total revenue only just caught up to what the first game had earned. That trend really worried me. I realized that with modern game engines becoming more accessible, the barrier to entry in game development had dropped significantly. That means more and more great games are going to be released by small indie studios.

I think I managed to make a pretty big quality leap from FoN1 to FoN2, but that was just enough to maintain my position in the market. If I want to stay in game development, I’ll need to make another leap between FoN2 and FoN3 – reaching an entirely new level of quality. But my financial situation hasn’t changed, and I could only afford to spend as much on FoN3 as I did on FoN2. So it was unlikely I’d be able to make that leap on the same budget.

I needed a way to quickly, and preferably with minimal investment, create a game that could generate significant income. Sounds like a perfect plan, right? But you know how it is – "easy money" always comes with high risk. And I decided to take that risk.

Luckily, the architecture of Force of Nature 2 turned out to be flexible and easy to adapt to different genres, so I could modify it for a new kind of gameplay. I thought a networked team-based battle game could be a great direction. From the start, I also knew I wanted to try a free-to-play model with in-game purchases. If things went well, a game in that genre and with that monetization could fulfill my plans and provide the funding I’d need for FoN3.

Even though I was willing to take a risk, I still wanted to minimize it. While development costs would be relatively low by my estimates, I’d still need to invest something. I didn’t want to reuse the exact same assets from FoN2 – I wanted to adapt the setting, create unique heroes, and offer different skins. I’d also need server infrastructure.

So while I wasn’t risking all my money, I was still putting a significant amount on the line – and I didn’t want to end up with nothing and no way to move forward with FoN3.

That’s where my publisher came in – they had already helped several partners raise funding on Kickstarter, and most of their campaigns were successful. They know exactly how to package a project so that it reaches its funding goal.

Kickstarter

I really liked the idea of launching a Kickstarter campaign. Not just because it could bring in funds for development, but also because a successful campaign would prove that there’s demand for this kind of game and give it some initial visibility. Just like going through Greenlight did for me back in the day.

But if the primary goal is to pass Kickstarter, then the development process shifts slightly: all effort has to go into making the most impressive trailer possible. That’s what influences people’s decision to back a project more than anything else. Since I’ll be saving money up until the Kickstarter launch, I won’t be able to show off updated graphics. Maybe just some detailed 2D art of the environment, characters, and “fake screenshots” – artwork that simulates in-game visuals.

The main draw has to be the gameplay. I need to clearly show the gameplay elements that will excite potential players. It has to look fresh, team-based, and varied – and that all needs to come across in the trailer.

And the rest… well, you already know what happened. That’s what all my recent posts have been about.

Let’s start by analyzing our previous video. The biggest impact on gameplay came from the introduction of bushes, which allow players to hide from the enemy team. However, they don’t obscure the core mechanic of the forester – resource gathering – so players can still observe their opponents and adapt to their strategies and routes. At the same time, bushes add an element of surprise, making it much harder to predict enemy movements and opening up countless opportunities for outplaying opponents.

Movement across the map has taken on an emotional “rollercoaster” effect:

• Players frequently have to cross bushes.
• Approaching a bush builds tension because of the unknown lurking inside.
• Entering an empty bush brings both relief and excitement – now it’s our turn to set up an ambush.

Bushes, especially those extending beyond the forest, also allow champions to sneak up on foresters undetected, making ganks far more viable. This has strengthened the interaction between foresters and champions, which has been a great improvement for the game.

As a result, we’ve gradually moved away from pure forest duels and shifted our focus to team-based testing. Most of our matches are now 2v2, with each team consisting of one forester and one champion. Some of the most exciting moments occur when champions leave their lanes to gank the forest, leading to large-scale team fights. Bushes enhance these situations, but to encourage even more forest skirmishes, we decided to add two linked teleporters to the map – one in the middle of the lane and another in the middle of the forest. This teleport system gives champions the ability to instantly appear in the heart of the forest, creating even more dynamic and unpredictable engagements.

At this point, we can say that the core gameplay of our game is fully formed, and no major changes are planned. Moving forward, our focus will be on balancing existing mechanics, refining heroes and their abilities, and adding new cards.

Game Overview & Rules

1. Each match features two teams, each with a base where players spawn, respawn after death, and make purchases.
2. Every base contains a portal that periodically spawns creeps, which march toward the enemy base. The objective of the game is to destroy the opponent’s portal.
3. Heroes are divided into two classes: Champions and Foresters. Each team can have only one Forester, but there is no limit on the number of Champions.
4. Champions play similarly to those in Dota or League of Legends – they earn gold and experience by killing creeps, level up, and upgrade unique abilities.
5. Foresters spend most of their time in the forest, gathering resources and purchasing spell and ability cards.
6. Foresters cycle between two alternating phases:
7. Resource Gathering Phase (30 seconds): The forester can collect up to three resources. However, if they engage in combat, they immediately lose the ability to gather resources for the rest of the phase.
8. Purchasing Phase (30 seconds): The Forester can use gathered resources to buy one card from two available decks.
9. As they gather resources and purchase cards, Foresters gain experience and level up. With each level, they unlock one of their unique personal spells.
10. There is a large pool of spell cards available for purchase, but only a randomly selected subset is used in each match, ensuring variety and unpredictability.

Choosing the Setting

Though it was a bit early in development, we decided to explore potential settings for the game and sketched out a few concepts.

Pirate Island

The game could take place on a pirate island, where adventurers arrive in search of treasure. Resources could be represented as chests filled with massive, colorful gemstones.

Distant Planet

This setting takes place on a faraway planet in the distant future, evoking a Starcraft-like atmosphere – alien deserts, futuristic technology, spacesuits, and bizarre extraterrestrial creatures. The battles revolve around harvesting rare and valuable minerals.

Battlefield

Here, we attempted to blend the aesthetics of World War I with steampunk elements. Instead of traditional bushes, cover could be represented by tattered tents scattered across the battlefield.

Magic University

In this setting, the game takes the form of a grand wizard tournament. This theme naturally complements the heroes' various abilities and the unique card-buying mechanics. While deep storytelling isn’t crucial for a game like this, a well-thought-out logical framework helps us, as developers, immerse ourselves in the world we're creating. This, in turn, makes it richer, more engaging, and better designed.

After reviewing our options, we decided that Magic University is the strongest candidate for the game's setting.

Continuing the development of our MOBA with Foresters! Last time, we introduced quite a few changes, and this time, there will be just as many.

New Cards

The Forester’s primary role is to gather resources and use them to purchase cards with various useful effects. Naturally, we want to increase the variety of these effects. The card table should be filled with enticing options so that players see a direct benefit from collecting resources.

Broadly, cards can be divided into three categories:

• Resource cards – help gather more resources.
• Minion cards – summon minions to the lane or enhance existing ones.
• Spell cards – provide situational advantages and allow players to hinder their opponents.

Spell cards, in particular, are among the most desirable – Traps, Gnomes, and Dynamite (resource sabotage) have always been popular choices. That’s why we decided to add even more spell cards. Here are the newest additions:

• Spider Egg – The Forester can place a spider egg somewhere on the map. This egg is invisible to the enemy team, but if an opponent passes nearby, it instantly hatches, releasing a spider that rushes toward them. The opponent has a few seconds to react and dodge – otherwise, the spider will explode upon reaching them, severely slowing and poisoning them.
• Grenade – Thrown to a designated point, dealing damage in a small area upon explosion. It also stuns enemies for one second. The grenade follows an arcing trajectory, making it useful for hitting targets behind obstacles like trees, bushes, or elevated terrain.
• Mud Grenade – Similar to the regular grenade, but instead of an explosion, it creates a muddy swamp upon impact. Any enemy passing through this area is significantly slowed.
• Silence – Creates a burst of energy around the caster, disorienting nearby enemies and preventing them from casting spells for the next five seconds. This works against both Foresters and Champions.
• Interception – Cast on an area, allowing the Forester to seize all enemy objects placed by the opposing Forester – this includes traps, spider eggs, and dwarves. Dwarves are easy to capture, but since traps and spider eggs are invisible, the player has to estimate where the enemy might have placed them. This mechanic adds a lot of strategic depth, as players quickly learn the optimal resource-gathering routes, and invisible traps are often placed at key intersections.
• Harpoon – The Forester throws a harpoon in a straight line. If it hits an enemy Forester, it steals a random resource from their inventory.

In addition to introducing new cards, we’ve also made some adjustments to existing ones.

For example, Gnomes no longer just attack enemies – they can now reveal invisible objects around them. Since we already have two invisible elements in the game (Traps and Spider eggs), and there’s a card that interacts with them, we also needed a tool for detecting hidden threats.

Traps have been improved as well. Instead of simply slowing an enemy who steps on them, they now completely stun the target for a short duration.

We’ve also reworked the Healing Potion card. It is now simply called Potion and allows the player to choose between either a single health vial or two stamina vials. Since Foresters are now actively involved in combat and rely heavily on their own spells, they consume stamina much more frequently. We wanted to provide a way to replenish it without forcing players to take long trips back to base, but at the same time, we didn’t want to clutter the second deck with multiple different vials. The solution was a single, versatile potion.

Stealing has also been slightly adjusted. If a player attempts to steal a resource that has been rigged with explosives, the dynamite will detonate, consume itself, and explode – but the hero will take no damage from it.

Currently, there are seven spell cards in the game: The five introduced earlier (Spider Egg, Grenade, Mud Grenade, Silence, and Hijack), Gnomes, and Dynamite. However, Trap, Stealing, and Harpoon are not classified as spell cards. Instead, they belong to the resource card category (since they help players acquire resources) and are found in the first deck rather than the second.

More spell cards will be added in the future, but for now, we’ve introduced a limit per match – only four random spell cards will be selected at the start of each game and included in the second deck. This means that every match will feel different, as players will have to adapt their hero’s skills to the four available spells, which change every time.

At the start of a match, Foresters can check which four spell cards are available. This information is displayed on the card table – spell cards included in the match appear in the lower-right corner.

Forester Abilities

We've decided to replace the third ability of the Bomber forester since it previously boosted the damage of resource mining traps – a card that may not always be available in the deck. Instead, we've given this hero a new ability called Burning. When activated, a ring of fire appears around the Bomber, dealing damage to all enemies inside and slowing them down, making it harder for them to escape the flames.

This change further reinforces the Bomber’s need to close the distance with enemies. First, he is a melee hero whose basic attack uses a pickaxe. Second, his Explosion ability deals more damage the closer the enemy is. Third, his new Burning ability only affects a relatively small area around him. Finally, his Gravity ability, which pulls enemies toward him, synergizes well with this setup.

We’ve also made small tweaks to other forester abilities. The third ability, Summon Mage, is now passive for both heroes. Previously, players had to actively cast it, consuming stamina each time. However, since this ability didn’t directly impact the events happening around the player, it was often forgotten or felt more like a background task rather than an engaging mechanic. Now, as a passive skill, it works much more smoothly – players simply upgrade it, and from then on, a mage will automatically spawn with every minion wave. Further upgrades make the mage stronger.

Even though Foresters now have a wide variety of abilities (their personal skills plus purchased spell cards), they are still weaker in direct combat compared to Champions. And that’s how it should be – otherwise, Champions would become obsolete. However, we didn’t want Foresters to feel completely useless on the lane either. To address this, we made an adjustment: all damage taken by Foresters from enemy minions is now halved. Additionally, Foresters have multiple area-of-effect abilities, while minions tend to stand close together, making Foresters more viable in lane fights. This means they can help push towers if the enemy Champion is absent – but if a Champion is present, the Forester will still be an easy target.

As I’ve described before, Foresters are vulnerable during the resource collection phase because they are discouraged from engaging in fights. If they do enter combat, they immediately lose the ability to collect resources for the remainder of their turn. This mechanic aligns with the game’s turn-based logic – each turn, one player is in a vulnerable position while the other hunts them down, and on the next turn, the roles reverse.

However, the "No combat during resource collection" restriction was a bit too severe. With Foresters now having more offensive tools than in earlier versions, avoiding fights has become significantly harder. To balance this, we’ve adjusted the rule: Now, Foresters only lose their resource collection phase if they deal damage to an enemy hero (either an enemy Forester or a Champion). They can still attack enemy minions and gnomes, set traps, and use non-damaging spells like the Poison Warlock’s jump, the Bomber’s gravity, or the Mud Grenade without penalty.

This change gives Foresters more room for tactical play while preserving the core risk-reward dynamic of the resource collection phase.

Bushes

In a previous post, I talked about how the openness of our game allows players to learn from each other, making competition more engaging. Even if a team loses to stronger opponents, they can still pick up new strategies and apply them in future matches.

I also mentioned that for Foresters, the entire resource area functions as a single shared point of interaction, which should be open. However, making the forest completely open has a downside – it significantly hinders interactions between Foresters and Champions. There needs to be some level of openness, but not total transparency. The core mechanics – like minion farming for Champions and resource gathering for Foresters – should be fully visible, but there should also be some room for secrecy in terms of strategic plays and ambushes.

Invisible traps and spider eggs were our first step toward introducing more hidden mechanics, and they’ve worked well. So, we decided to expand the use of invisibility even further.

Completely closing off the resource forest isn’t a great idea, but we wanted to experiment with Bushes, similar to how they work in League of Legends. The concept is simple: there are small areas of bushes scattered across the map. Bushes don’t affect movement – players can freely enter and exit them. However, when a player enters a bush, they become invisible to the enemy team – as if they are hiding inside it. If an enemy player enters the same bush, they immediately reveal all hidden opponents inside.

We implemented this mechanic with tall grass zones, where players can set up ambushes while remaining unseen – unless an opponent steps into the same grass.

We’ve also made an additional change – the resource forest is now covered by the Fog of War, just like the area outside the forest. However, visibility inside the forest depends on who enters it:

1. If no allies are inside, the forest remains completely dark, and everything happening there is a mystery.
2. If a Champion enters, they (and their team) can only see the area immediately around them.
3. If a Forester enters, the entire forest becomes visible to the whole team – except for bushes, which always remain hidden unless visited.

This system preserves the element of secrecy while ensuring that Foresters still have good control over the resource zone, without making it too easy for opponents to track their movements.

Previously, the Fog of War completely blacked out covered areas, hiding both the characters and the terrain. This was the simplest way to implement it – I only needed a map of fog-covered regions and, after rendering each frame, I would go over it and black out everything inside the fog. Essentially, the game first rendered everything (including things the team shouldn’t see) and then masked the hidden areas.

However, this approach had a downside: it hid the environment as well, even though the terrain never changes and there’s no real reason to obscure it. A completely blacked-out location made navigation unnecessarily difficult.

In the new implementation, fog-covered areas are no longer entirely blacked out, but rather dimmed, allowing the environment to remain partially visible. However, I had to ensure that enemy players in the fog are completely hidden, along with all special effects and sounds coming from those areas.

Other Improvements

Flexible Card Purchases. Until now, players were limited to buying only one card per row per purchasing phase. After purchasing, the row was marked with a green checkmark, indicating that no more cards could be bought from it. We've now relaxed this rule slightly. Players can remove the green checkmark by spending one diamond, allowing them to buy another card from the same row. Diamonds are rare and valuable, so the restriction still remains meaningful, but this change adds flexibility and makes resource management more strategic.

Enemy Card Tracking. Since the card table is shared between both Foresters, all purchases instantly become visible to both players. Knowing what spells your opponent is acquiring is crucial for predicting their next moves. However, keeping track of purchases while multitasking can be difficult. To help with this, we've added a log of the opponent’s last few purchases, displayed in the bottom-right corner of the screen, alongside their resource count.

Teleport Adjustments. Previously, teleports worked instantly – as soon as a player clicked on a teleportation point, they were immediately transferred. While the character still appeared to stand on the teleport for a moment, from a gameplay perspective, they were completely untargetable. This made it too easy to escape fights, so we decided to make teleportation slightly more challenging. Now, players must stand inside the teleport zone for 2 seconds before they are transported. If they move out of the teleport area before the timer completes, the teleport is canceled, and they remain in place. If they feel unsafe during these 2 seconds, they can freely run away – the teleport doesn’t hold them in place. This tweak adds counterplay, making teleports a strategic decision rather than an instant escape option.

Testing

The changes described above are quite significant. Thanks to new spell cards, battles between Foresters should now feel more dynamic, while the bush mechanic should make Forester-Champion interactions more engaging.

This time, I'm sharing a recording of a 2v2 test match, where each team had one Champion and one Forester. Champion-led ganks didn’t happen too frequently yet – mostly because we were still learning the new mechanics and hadn’t fully figured out the right timing for them. However, when they did happen, they led to some interesting outcomes.

Welcome to a new post about the development of our MOBA game, inspired by Force of Nature 2. Lately, the changes we've introduced have consistently yielded positive results, reinforcing our belief that we're on the right way. With that confidence, we're ready to keep pushing forward. Let's dive into the latest updates!

Stamina and Charges

We've been working to make the combat system as intuitive as possible for MOBA players. The next logical step was to reintroduce stamina to its traditional role. Previously, we used stamina only to limit the number of resource-gathering actions. At the start of each gathering phase, foresters received just enough stamina for three resource hits, with any unused stamina burning out at the end of the phase.

However, now that foresters can cast spells, we wanted stamina to serve as a standard resource for spellcasting, as is common in the genre. As a result, we restored stamina's original purpose and introduced a new mechanic – charges – to control resource-gathering actions. These charges are displayed directly above the hero's head.

This change not only freed up stamina for spell usage but also made it significantly easier to visually track the current phase.

Previously, players sometimes struggled to stay aware of the phase they were in, particularly after engaging in intense battles. In such situations, players would shift their focus from managing resources to monitoring health – both their own and their opponent’s. After a fight, it could be confusing to determine whether it was time to gather resources (avoiding further battles) or to buy cards and aggressively confront the enemy.

To address this, we had already added two indicators: a corner icon (a coin or pickaxe) and a screen border glow (yellow or blue). However, these indicators were placed on the edges of the screen, relying on peripheral vision, while the player’s main attention was on their character. The charge indicator, positioned directly above the hero's head, is always within the player's line of sight, making it much easier to identify the current phase.

Resources as Towers

In traditional MOBA games, towers serve as a stress-relief mechanic for players who may struggle during matches. Towers provide a safe haven, allowing players to avoid unnecessary fights if their opponent proves more skilled. Players can opt to stop aiding their minions in killing the enemy's minions, letting their own minions perish and luring the enemy closer to their tower. While this creates a risk of damage to the tower, it also provides a relatively safe area for the player to regroup. For beginners, this mechanic is particularly valuable – it lets them reduce their personal stress by redistributing it across the team, as the now-damaged tower requires the team to play more cautiously.

We wanted to introduce a similar concept to our game, creating "safe zones" where players can catch their breath during high-stress moments, even at the cost of some overall progress toward victory.

In our game, these safe zones are represented by the resources that foresters gather. Resources act as protective "towers" for players. However, only active resources – those that haven’t been harvested – offer protection, and they protect only the forester in the resource-gathering phase who has charges available. This means a resource will only defend a forester who is currently able to gather it.

Protection works as follows: if a hero attacks a forester near an active resource, the resource retaliates by attacking the aggressor. However, if no one initiates combat, any hero or forester in any phase can safely move near resources without triggering an attack.

We were cautious about introducing these "resource towers" into the forest, as a large number of them could significantly disrupt the gameplay balance. To mitigate this, we started with a low damage output for these protective resources. Additionally, their projectiles do not deal instant damage – they travel slowly toward the target and self-destruct after two seconds if they don’t hit. This gives players an opportunity to evade the attacks.

This system creates a fair and forgiving mechanic that adds an extra layer of strategy without overwhelming players or drastically altering the game’s flow.

New Hero: Forester - Bomber

Combat between foresters has become engaging but still feels somewhat repetitive. Until now, we’ve only had one forester hero, meaning both players used the same set of base abilities. While additional ability cards introduced some variation, most battles boiled down to trading identical spells. It’s time to change that by introducing a new hero!

Meet the Bomber. To distinguish the original hero, we’ve named them Poison Warlock, as their signature spell is a poison cloud.

Abilities of the Bomber

• Gravity: Pulls all nearby enemies toward the Bomber.
• Explosion: Deals instant magic damage to all nearby enemies. The closer the target is to the epicenter (the Bomber), the higher the damage.
• Pyrotechnics: Enhances the damage dealt by mining resources.

The Gravity ability synergizes with Explosion, allowing the Bomber to pull enemies closer to maximize damage. Unlike the Poison Warlock, who uses a sling for ranged combat, the Bomber wields a pickaxe, making them a melee-focused hero. Close combat is critical for their playstyle, both for dealing damage and utilizing their abilities effectively.

Other Improvements

Since foresters no longer need to closely monitor minion battles on the lane, we’ve decided to remove the lane battle diagram that previously occupied a large portion of the top-left corner of the screen. This diagram was originally introduced back when builders engaged in a “rock-paper-scissors” mechanic with different minion races, requiring players to track these skirmishes. However, this feature has become obsolete with the removal of that mechanic.

Instead, we’ve repurposed that space to display a second card queue along the edge of the screen. Now, both card queues are visible at all times, eliminating the need to open a separate window to view the card table.

All resources belonging to the opposing forester, which were previously visible on the card table, have been moved to the main screen and are now displayed in the bottom-right corner. Additionally, interface buttons from Force of Nature that were irrelevant to this mode have been completely removed.

At the top of the screen, next to the game timer, there’s now a progress bar displaying each team's overall advancement toward victory. At the start of the match, both teams begin with 300% base health – 100% for the portal and 100% for each of the two lane towers. As towers are destroyed, this number decreases. A score of 0% indicates that all towers and the portal have been destroyed, resulting in a loss. This feature provides an immediate overview of how well or poorly your team is performing.

New Minion Cards

Several new cards have been added, summoning additional minions in the next wave:

• Orc Archer: A ranged unit with a healing aura that restores health for nearby allies.
• Orc Swordsman: A melee unit with an aura that boosts the attack power of nearby allies, including other minions.
• Troll Tank: This unit already existed in the game, but now its aura grants bonus armor to nearby allies.

Removal of Pearls as a Resource

The Pearl resource has been entirely removed from the game. We found little difference in gameplay between gathering five resources versus four. However, eliminating one resource also allowed us to remove four of its respawn points, significantly compacting the forest resource area. This has made forester combat more frequent and intense while also increasing the strategic value of the card that allows players to mine resources. With fewer resources available, predicting the mined location becomes easier, raising the stakes.

Base Healing for Foresters

Since foresters now frequently engage in combat and lose health and stamina, we wanted to give them a way to recover at their base, similar to champions. However, this healing comes with a drawback. In addition to the time lost returning to the base, there’s now a penalty: while the forester is at the base, their portal generates minions at one level lower than usual.

This creates another layer of connection between foresters and their minions. The strength of a forester lies in the forest, and their actions in the forest are reflected in the performance of their minions on the lane.

Refining Mechanics: A Familiar Approach

Throughout development, we’ve repeatedly opted to replace our custom mechanics with familiar, time-tested ones. The same principle now applies to forester artifacts. Previously, artifacts were purchased at the card table using resources. Now, we’ve moved artifact purchases to the base shop, where regular champions also buy their items. However, foresters have access to a completely separate set of artifacts tailored specifically to their needs.

These "new takes" on old mechanics – like the unique method for purchasing items – were intended to make the game stand out from other MOBAs. However, the resource-gathering and spell card system already provide enough innovation. Adding unfamiliar approaches to common mechanics risks overwhelming players unnecessarily.

Foresters now purchase artifacts in the shop using gold, earned by: сollecting resources, killing other heroes, passive income throughout the game.

From Gold Coin to Diamond

To avoid confusion between the gold used by foresters to purchase artifacts and the Gold Coin available at the card table (which substitutes for any resource), we’ve replaced the Gold Coin with a Diamond.

Let’s see how it al plays out!

Previously, I discussed our decision to remove building mechanics and minion management from the game. At first glance, it might seem like we’ve stripped away features and made the game less dynamic. However, this change has had a surprisingly positive impact on gameplay. Players are no longer distracted by auxiliary tasks. Instead, their primary focus is clear: defeating the enemy forester. This clarity enhances the overall enjoyment of the game, as players can fully understand their actions and predict their opponent's moves. Moreover, it significantly improves skill development. Since the results of your decisions are immediately apparent, it’s easier to identify mistakes and learn to avoid them in future matches.

One minor distraction from battles remained: the hero progression system. Previously, players had to manually sacrifice one unit of each resource every five minutes to unlock the ability to upgrade one of three skills. While this approach added value to resources, it also forced players to constantly track spell upgrades. After unlocking a skill, they had to mentally set a five-minute timer to upgrade the next one and repeat the process.

To streamline this, we made hero progression automatic. Like in many other games, our foresters now gain experience during play, leveling up when they reach certain thresholds. Each new level unlocks an additional skill upgrade. Players earn 1 experience point for every resource gathered, and cards taken from the table also grant experience – equal to their resource cost.

The forester's level now also determines the level of their minions. For instance, if the forester is level 1, their minions are level 1; if the forester reaches level 5, the minions summoned from the portal will also be level 5. This adjustment maintains the importance of resource collection for progression but eliminates the need for players to juggle additional tasks mentally.

New Teleports

At the start of the game, players often spend considerable time running to the forest. This is especially challenging for the second team, as they must traverse the entire map to disrupt their opponent’s resource gathering. To address this, we added teleporters to each base, leading directly into the forest. The teleportation exit point for each base is located near the opponent's base exit. This means that a second-team forester can immediately teleport to the first team’s base and ambush their forester.

Notably, champions cannot use these teleporters, preventing the entire team from ambushing the enemy forester at the start of the match. However, the first-team forester can avoid confrontation by using their teleporter. If they do, the second-team forester can simply run from their base without using the teleporter, still creating the possibility of an early-game encounter. As you can see, this creates a variety of strategic options right from the beginning!

Fog of War

However, to prevent the second player from gaining a guaranteed advantage, the first player needs some degree of privacy. I’ve previously explained why game transparency is beneficial – it allows players to learn from each other. This led us to remove the fog of war entirely, which has been a good decision so far. However, we now see a need to reintroduce it. That said, the core forester mechanic – resource gathering – should remain visible to preserve the advantages of open gameplay. Therefore, the forest area where resources are located will stay visible to both teams at all times.

Teleport Restrictions

Another issue we noticed involved the forest teleporters, which provided little room for positional play. If one player realized they were losing a fight, the teleporter offered no reliable escape route – the opponent could simply follow them through the same portal. To address this, we added a short cooldown between uses for each teleporter. Once a player uses a teleporter, it becomes inactive for the next 4 seconds, preventing anyone else from following immediately. Additionally, heroes now have a personal cooldown of 6 seconds after using a teleporter, meaning they can’t instantly jump back and forth. This change prevents players from exploiting teleporters to escape and immediately return to the same spot.

Timeouts for Gnomes and Traps

We’ve also updated mechanics for gnomes and traps – anything players can place on the ground. These now have timeouts, disappearing automatically after a certain duration. Let me explain why we made this change. The idea behind gnomes is to give players a choice: either destroy the gnome, taking significant damage, or avoid it by navigating around the forest to reach the resources they need. However, as the game progresses, gnomes tend to accumulate, making it increasingly difficult to avoid them. Eventually, players have no choice but to confront them, often needing to destroy multiple gnomes in quick succession.

This created a situation where the strategic choice was effectively removed – players had to destroy gnomes, and the sooner, the better. By introducing a lifespan for gnomes, the original intent of providing meaningful choices comes back into play. Players can now decide whether to deal with a gnome immediately, incurring some losses, or wait it out, temporarily complicating their path through the forest. This change restores balance and ensures that gnome placement works as intended, enhancing the strategic depth of gameplay.

With traps, the situation is slightly different. Without a timeout, any trap will almost inevitably trigger sooner or later, as forester spend a lot of time running through the forest. Adding a timeout forces players to think more carefully about trap placement, making their choices more strategic.

Let me also highlight a seemingly minor change that doesn’t directly impact gameplay but adds a lot of positive emotion to the experience: we’ve added visual feedback for when traps are triggered. Now, whenever a forester accidentally steps into a trap and loses a resource, or tries to gather a booby-trapped resource and gets blown up, the opposing forester receives a notification in the form of flying cards on their screen. This small detail strengthens the connection between a player’s actions and their results, encouraging them to use traps more often and making their impact feel more rewarding.

So, let’s see how all these changes play out in action!

Last time, we allowed builders to fight each other directly using weapons and spells. It worked! Naturally, we had to rebalance the numbers for each spell, and that was the first priority. The Merchant skill, in particular, needed a major overhaul since it regularly granted free coins. When fully upgraded, it could produce so much money that gathering resources became unnecessary – you could buy any card without them.

The stats for the primary weapon, the sling, also required fine-tuning. The critical parameters included those affecting hit probability, such as the speed of the stone and the throw animation duration (i.e., shot delay). If the projectile flies too quickly and the throw happens almost immediately after a click, hitting an opponent becomes too easy. Since the opponent can’t retaliate during the resource collection phase, this could make their experience less enjoyable. But if the stone speed is too slow and the throw animation is too long, it becomes easy to dodge, rendering the weapon ineffective.

Moving Away from Construction

Now, let’s address more significant gameplay drawbacks. I’ve previously mentioned the “Snowball Effect”, where advantages compound to the point that it’s no longer fun to play on the losing team. My aim is to create gameplay where, no matter how bad things look, the team always has a chance to pull together and turn the tide. This keeps the losing team engaged and prevents the winning team from relaxing too much. Building mines, which (like the Merchant skill) provided regular free resources, was a prime example of accumulating advantage. So, we decided to eliminate mine construction. Previously, we had also removed minion lairs, and now… we have no buildings left. The “builder” no longer builds anything, so it’s time for a new name. From now on, we’re calling him the Forester, since he spends most of his time roaming the forest and gathering resources. We’ve chosen Forester rather than Jungler, as in MOBAs, because the gameplay here is quite different.

Moving Away from Minion Management

Let’s move on. Besides buildings, another major source of the snowball effect was the ability to upgrade minions. This makes sense, given that minions were essential for victory – they destroyed towers and the enemy portal. Upgrading minions was so advantageous that the Soul card, which enabled this, was always prioritized. However, since this card appeared randomly, it could fall into the hands of one player at the right moment, leaving the other player feeling unfairly disadvantaged.

In a difficult decision, we decided to completely remove the ability to build up strength through minion upgrades. Since players could no longer upgrade minions, they also lost the ability to unlock new minion types. After a long journey experimenting with minion management, lairs, soul-based summoning, and a “rock-paper-scissors” dynamic among rival races, we returned to a standard setup – each side now has the same set of minions in every wave, similar to a typical MOBA. It's a bit bittersweet, considering the time and effort invested in these unique mechanics. But is this bad for gameplay? Not at all. While fresh, unusual mechanics are valuable, it’s better to focus on one well-crafted mechanic rather than many underdeveloped ones. This approach also makes it easier for players to understand the game. In our case, the standout mechanic became the unique resource gathering and the competition over it, while minion management took a back seat. Managing waves of minions was less engaging and distracted players from resource gathering, yet it couldn’t be ignored, as minions were still the key to victory.

By removing minion management, we greatly simplified the player’s mental load, but a new problem emerged: how do players now contribute to their team’s victory? Previously, builders could strengthen minions, giving them a chance to overwhelm weaker enemy minions, destroy towers, and eventually reach the portal. But now, all minions are identical. So how can the Forester’s actions translate into a team victory? Should we have Foresters move to the lanes and use their new spells to help their minions and champions defeat the enemy’s and break down towers? No – that would distract players from the core mechanic, and we don’t want that.

The solution we found was this: all damage taken by the Forester is also shared with his team’s minions. The damage is distributed proportionally. Since each wave has five minions, every 20% of the Forester’s health corresponds to one minion’s health. For example, if the Forester takes damage equal to 10% of his maximum health, the first minion in his wave instantly loses half its health. If the Forester loses 20% of his health, that minion dies, and subsequent damage is passed on to the next minion. If the enemy Forester is caught and completely drained of health, his entire minion wave will also fall. Furthermore, if the Forester is killed, the next wave on the enemy side will spawn zombies instead of a set of minions.

This mechanic incentivizes Foresters to engage in combat, as dealing even small amounts of damage to the opponent directly affects their minions on the lane, giving the Forester’s own minions a better chance to reach and damage the enemy’s towers. It also clarifies the path to victory – players simply need to deal more damage to the opponent and, ideally, defeat them as often as possible.

New Cards

Since we’ve removed several cards from the game, it made sense to replace them with something useful. These new cards, however, are designed to offer only temporary advantages or opportunities to damage the opponent.

As a result, we decided to keep the Soul card, which still affects minion levels. However, its effect is now single-use and applies to all of your minions at once – the entire next wave of minions (and only that wave) will be at an elevated level. Meanwhile, the base level of all minions gradually increases over time for both teams equally.

Another major category for new cards involves various temporary spells, such as a Stealing card. These cards are single-use, providing only a brief advantage and giving heroes more ways to fight each other. Additionally, these spells appear randomly, allowing players to combine them with their skill sets, making battles more varied and situational – a definite plus.

At this stage, we’ve introduced only two spell cards, with plans to add more in the future. 

• Trap Card: This card lets the player set a trap on the map, invisible to the enemy team. Any enemy unit that runs over the trap will activate it, causing a significant slow effect for a period of time. If the enemy Forester triggers the trap, they not only get slowed down but also lose a random resource from their inventory, which is transferred to the Forester who set the trap.
• Dynamite Card: Usable only during resource gathering, this card allows players to “mine” a specific resource – jade, obsidian, ice, amber, or pearl – meaning all deposits of that resource become rigged. For example, if you choose to mine jade, it applies to the entire jade resource, not just one deposit. When the opponent collects jade on their next gathering phase, the deposit will unexpectedly explode, dealing damage to the enemy Forester. The mining effect lasts for only one turn, so if the opponent doesn’t collect jade that turn, the effect will disappear by the end of their turn.

Other Updates

As always, alongside the major gameplay changes, we made a few adjustments to improve user experience and address some frustrating aspects of the game.

Previously, for instance, players could place a Gnome-Shooter right under an enemy’s feet. The Gnome would attack immediately, leaving the Forester no chance to dodge the damage. Gnomes could also be set up near portals, so when the Forester teleported to such a portal, multiple Gnomes would instantly start shooting, dealing excessive damage. Now, Gnomes remain inactive for the first 3 seconds after being placed, giving the enemy a chance to either back away to a safe distance or destroy the Gnome right away. Additionally, Gnomes can no longer be placed close to teleporters.

It was also challenging to keep track of which phase of the turn you were in – gathering or purchasing. A small icon displayed the phase in the corner of the screen, but players weren’t used to constantly glancing there. This often led to confusion, with players accidentally attacking the opponent at the start of the gathering phase, only to lose all their energy as a result. To make the phase more noticeable, we added color-coded edges to the screen in addition to the icon. Now, the screen edges glow yellow during the purchase phase and blue during the gathering phase.

So, there we have it – another round of significant changes. Let’s see them in action!