Force of Nature 2 Dev. Blog

Last time, we experimented with a mechanic that allows builders to change turns. While it's still unbalanced and doesn't always work perfectly, the key takeaway is that it works! We can now see builders actively interacting with each other, with their actions heavily influenced by the opponent's moves. This is a positive shift, and it feels like we're heading in the right direction. Our next step is to continue developing this approach, identify any weak points, and improve them.

Bonus Gold Coin

Let's start with something that stood out right away. The second team's hero begins the game in the purchasing phase. In theory, this phase is for buying cards, but at the very start of the game, they don't yet have any resources to do so. If the hero doesn’t buy a card, they have to rush across the map to interfere with the enemy’s resource gathering. However, since both players start in opposite corners of the map, the second player ends up spending most of their time simply running to the other side of the forest. This makes them feel disadvantaged.

To balance this, we decided to give the second player a gold coin in their chest at the start of the game. While this won’t allow them to immediately buy a card, it at least compensates for the initial disadvantage and boosts morale.

Enhancing Combat Capabilities

Moving on to a more significant issue: the core interaction between builders revolves around the fact that during the purchasing phase, a builder has some free time to interfere with the opponent’s resource gathering and deal damage. However, they currently lack the proper tools to do so. Their only options are to hit the enemy with a pickaxe, place gnomes, or summon minions from the lane.

The problem is, you can't place too many gnomes because they require resources, and those resources are better spent on development. Minions also take time to leave the lane and reach the opposing builder, who can easily escape using a teleport. This leaves the pickaxe as the only reliable option, but it deals very little damage and is slow. By the time the builder swings the pickaxe, the enemy can run a considerable distance, making a second hit nearly impossible. That’s why we've decided to significantly expand the combat capabilities of the builders.

Sling Instead of a Pickaxe

First, the pickaxe has been replaced with a sling – a ranged weapon. In terms of resource collection, the sling functions just like the pickaxe: if it's the gathering phase, a hit with the sling collects the resource. The projectile flies fast but in a straight line, making it possible to dodge. To anticipate the enemy’s movements and launch a stone ahead of them, players can hold down the Shift key, allowing them to aim freely with the mouse instead of targeting a specific enemy.

Spells

Second, we've given builders spells to aid in combat. Initially, we introduced three abilities:

• Poison Cloud: The builder creates a large cloud of poison around them, gradually damaging anyone caught inside.
• Jump: The builder instantly teleports a short distance in the direction of the mouse cursor. This spell allows for quick escapes from the poison cloud, dodging attacks, or jumping over small obstacles like hills, making the builder much more mobile.
• Merchant: This ability generates a gold coin at regular intervals.

Like champions, builders' skills can be upgraded. The Poison Cloud’s area and damage increase with each upgrade, Jump gains more range and a shorter cooldown, and Merchant reduces the interval between coin generation. Since a builder's strength and progression come from resource gathering, we decided to tie spell upgrades to resources as well. To upgrade a spell, the builder must invest one of each type of resource at the card table.

Upgrades become available every 5 minutes, giving players plenty of time for other tasks while saving leftover resources for spell investment.

Ending Turns Early

Another issue we encountered was that sometimes players would run out of stamina early in the resource collection phase, either intentionally or accidentally. What should they do with the remaining time? They can’t collect resources (no stamina), and it’s not their turn to buy cards. Their only option is to fight, but what if their health is low, and the opponent has the upper hand? To solve this, we added the option to end the resource collection phase early. Players can click the pickaxe icon in the corner of the screen to trigger this, but the phase transition takes 5 seconds to give the opponent time to prepare for their own gathering phase.

Additional Improvements

Along with the changes mentioned earlier, we also addressed several other issues.

Increased Running Speed in the Purchasing Phase

During the purchasing phase, the builder needs to chase down and attack the opponent, but first, they have to catch up. The opponent usually runs directly from one resource to the next, only stopping briefly to hit each resource. If the chasing player spends time casting spells or attacking, they quickly fall behind. To counter this, we increased the builder's running speed by 10% during the purchasing phase. This also makes the option to end the gathering phase early even more valuable. If you run out of stamina but have an opportunity to fight, it's often better to end the phase early to gain a small movement speed advantage over your opponent.

Changes to Minion Lairs

We decided to remove the need to build special lairs for each race of minions to send them into battle. Previously, lairs had two functions: they required bricks to build, and minions were upgraded with souls. This system ensured that minions grew stronger over time and weren't all available from the start. However, we realized we could achieve the same goal without the lair-building mechanic. Now, all minions (except goblins) start at level 0 and are unavailable. The first soul invested upgrades a minion to level 1, making it available to summon in the wave. Simple as that.

This change doesn't significantly impact gameplay because players still need to gather resources, buy the corresponding card, and spend it to unlock new minions – just as before. Previously, players would buy bricks to build lairs; now they buy souls to upgrade minions. If there's no real difference, why complicate things? 

As a result, we removed lairs for Rats, Skeletons, Lizards, Spiders, and Mages. However, we brought back the Undead Lair. It originally existed when souls were used to send waves of minions, with the zombie wave serving as a penalty if the player failed to gather enough souls. The Undead Lair made zombies stronger, softening the penalty. When we abandoned the wave-for-souls system, zombies and the Undead Lair were also removed. Now that zombies are back, summoned via a special card, the Undead Lair is relevant again to make this penalty less harsh. 

Convenience Improvements

Along with gameplay improvements, we aimed to make the game simpler and more user-friendly. For example, now if you don’t have enough resources to buy a card but have enough gold coins to make up the difference, an indicator will appear on the card, letting you know it’s purchasable, but it will use a certain number of gold coins.

Another improvement is that players can now click on a card even if they can’t buy it at the moment (due to a lack of resources or it not being their turn). The card will be marked with a symbol and added to a wishlist. Once it becomes available, the card will be purchased automatically.

Our card table is completely open, and the information about which cards the opponent buys isn’t secret. Knowing their purchases can be quite useful for predicting their strategy. However, tracking which cards they buy can be tricky – there are 10 cards on the table at any given time, and it's hard to remember all of them to figure out which one has been taken. To make this easier, whenever the opponent buys a card, it will now fly across the screen and disappear into their side.

Well, once again, we have quite a few changes that need testing!

In my previous post, I discussed a number of problems we were facing at the time. Testing showed that the changes described successfully addressed the issues identified.

This time, I want to focus on a single change that wasn't prompted by any particular problem. It was simply an idea that seemed a little out of place for our genre but turned out to be surprisingly effective (and interestingly enough, it too came directly from card games).

I'm talking about Turn-Based gameplay. In probably 99% of card games, players take turns. The advantage of this is that while one player is making their move, the others have time to think about their next steps, which makes the game more strategic and less random. By structuring time in this way – where part of the time a player is thinking, part of the time they are actively making decisions, and part of the time they are observing and reflecting – you can keep the player engaged for much longer. Our brains love solving problems presented in the form of games, but they also tire quickly and need some time to rest or focus on something else. This concept is closely tied to a game design principle known as the "Difficulty Saw".

Let me briefly explain what that is. To give the player a sense of progress in the game, the difficulty level should gradually increase. But how fast should the difficulty ramp up? If it increases too slowly or too quickly, the player may either get bored or feel overwhelmed. One of the most successful approaches is to raise the difficulty continuously, but with occasional sharp drops, as shown in this type of graph:

The graph forms a shape resembling a saw blade, which is why it’s called the "difficulty saw". With this kind of pacing, the player constantly feels a sense of progression, but the game doesn't suddenly become overwhelmingly difficult. At the same time, it provides moments where the player can catch their breath and take a break from challenging trials. For more details, you can check out this article: The idea of a difficulty curve is all wrong

Since in competitive games, difficulty is directly influenced by the opponent, it’s more accurate to talk about tension and stress experienced by the player rather than difficulty. In this context, the stress curve takes the place of the difficulty curve. The "sawtooth" stress curve is also applicable to MOBA games. When a player is holding their position in the lane, they’re constantly clashing with their opponent, which keeps them on edge and increases stress. As health and mana gradually deplete for both players, the stress level rises. However, at some point, a hero can retreat to the base, heal, purchase new items, and then return to the battlefield. During this time, the stress level drops significantly because the hero is now stronger and healthier.

Turn-based mechanics in board games easily create these stress swings, which enhances player engagement. This led me to the idea that adding some form of alternating phases to my gameplay could be beneficial. So, here’s my solution.

The entire builder’s gameplay is divided into two phases: the resource collection phase and the purchasing phase. These phases alternate every 30 seconds. However, while one builder is in the resource collection phase, the other builder will be in the purchasing phase, and vice versa.

Resource Collection Phase

You can recognize this phase by the pickaxe icon in the bottom left corner of the screen (the number next to the icon shows how many seconds are left until the end of the phase).

At the start of this phase, the builder’s stamina fully regenerates, allowing them to collect up to three resources in the next 30 seconds. However, any unused stamina is lost at the end of the phase. Since there’s no stamina regeneration, players can only gather resources during their designated collection phase. Attacking gnomes, minions, or other players doesn’t consume stamina, so builders can fight at any time, regardless of their current phase or stamina level. But there’s one critical condition! If the builder attacks anything other than a resource, their entire stamina depletes to zero. This means that if they engage in combat during the resource collection phase, they’ll be unable to gather any more resources for the remainder of the phase.

Purchasing Phase

You can recognize this phase by the coin icon in the bottom left corner of the screen.

During this phase, the builder can buy no more than one card from each queue (as I mentioned in the previous post, there are two card queues). Cards cannot be purchased outside of this phase. Additionally, the pickaxe cannot be used to gather resources during this phase, but the “Stealing” spell can always be cast, even during the purchasing phase or when the player has no stamina. Not only does this spell allow you to gain an extra resource, but we’ve also added a small area-of-effect (AoE) damage component that affects both players and minions. Since the damage is AoE, the builder can deal significant damage to clustered minions. It can also be used to finish off an escaping enemy. You can even time it so that when an opposing builder rushes to collect a resource during their collection phase, you can cast “Stealing” to both steal the resource and damage the opponent.

What Does This Two-Phase Gameplay Offer?

First, it introduces the stress saw. The resource collection phase is more stressful because the player needs to run around the forest gathering resources without getting into fights. Engaging in combat would mean losing the chance to collect resources, and the next opportunity won’t come for another minute. On the other hand, the purchasing phase (especially at its start) allows the player to relax. The opponent is preoccupied with their own tasks, giving the player time to study the cards on the table, decide what to buy, or plan what resources to save for. Essentially, the player can map out their strategy for the next minute of gameplay. If all plans are set and the necessary cards are purchased, the player can use the remaining time to chase down their opponent.

Second, having two distinct phases provides players with a clear understanding of what they should focus on at any given moment to use their time efficiently. During the purchasing phase, the player buys cards and plans the next purchase while possibly hunting down their opponent. During the resource collection phase, the player focuses on gathering resources for the next purchase while avoiding danger. This system encourages players to make thoughtful decisions, something I’ve emphasized earlier, which ultimately makes the game more engaging.

Sounds promising – let’s put it to the test!

We have completely revamped the resource-gathering system. Let’s now take a closer look at what we have ended up with.

Usability Issues

In short, we had to learn how to play a brand-new game. Initially, it was difficult to remember where each resource was located, so we added their positions to the minimap.

We needed to come up with a reasonable penalty for a hero’s death to encourage more cautious play. The most logical punishment was the loss of resources, but taking away all resources upon death would set players back too far in their progression. So, we decided to give the builder two types of resource storage: a chest and a pocket slot. Everything the builder collects goes directly into their pocket. Upon death, the builder will lose everything from their pocket, however the resources in the chest will remain safe. There are also ways to transfer resources from the pocket slot to the chest, but I’ll discuss those later. When making purchases, resources will first be deducted from the pocket, and only when those run out would the game start using the resources from the chest. On the map, resources will only respawn when they are no longer in the hero’s pocket. Therefore, the resources in the two heroes' pockets, along with those on the map, always constitutes a fixed set – four units of each of the five resources (20 total). Resources in the chest are additional to these. In game replays, you can see the player’s resources displayed in the bottom-left corner of the screen: first, the chest resources, then the pocket resources.

We also felt that copper and iron were too simplistic, so we replaced them with more interesting resources – pearl and amber. To represent these new resources, we added a pirate chest and a crystal-studded stone from Force of Nature 2.

Since we aimed to create as much transparency in the gameplay as possible, we decided to add a display of the opponent's resources (both in their chest and pocket) on the card table, as well as show all the buildings they had constructed.

Complete Lack of Balance

This was to be expected, as we were just starting to experiment with this mode. We had no reference points, so the initial values – such as stamina regeneration rate, card costs, gnome damage, potion healing power, and so on – were chosen randomly. After the first few games, it became clear where we had overdone it, where we needed to scale back, and which aspects required adjustments.

The gnomes were by far the most unbalanced element. Their damage was too high for the builder to deal with directly. Ignoring them wasn't an option either; if you tried to rush in, grab a resource, and flee while a gnome was around, they would deal almost lethal damage. Recovering lost health was difficult, as the healing potion cost the same as a gnome but restored too little health. We naturally buffed the healing potion, but something also had to be done about the gnomes. Weakening them wasn't an option, as they'd then become too easy a target for champions and minions. The solution we found was to keep the gnomes' strength intact – champions and minions could still take them down with three hits – but builders only needed one hit to destroy a gnome.

The next issue that needed balancing was the cost of cards. Six resources per card proved to be too high, so we reduced the maximum cost to five resources, with most cards typically costing between two and four.

The stamina of the pickaxe used to regenerate very quickly, which often led to situations where the stamina was full and regeneration stalled, effectively wasting the hero's potential to gather more resources and buy additional cards. This undermined our concept of equally distributing resources between both players. Fortunately, fixing this was easy – we significantly slowed down the builder's stamina regeneration.

Lastly, we made the brick card more expensive, as bricks were previously too accessible and allowed players to construct all minion dens far too quickly.

Long-Distance Travel

Previously, the builder didn’t need to traverse the entire forest, as they spent most of their time at the base or controlling minions, and primarily gathered resources close to home. Now, it often happened that a necessary resource would run out on their side of the forest, requiring them to run all the way to the opposite end of the map. While this is generally a positive change, as it expanded the playable area of the forest significantly, we needed to introduce a mechanism for faster travel. We decided not to increase the builders' movement speed further, as they were already faster than the champions. Instead, we added teleporters to each half of the forest. These teleporters are connected and allow quick travel to the opposite side. Only builders can use these teleporters, they are not available to champions.

More Cards Needed

Collecting resources was quite engaging, but there were often moments when none of the available cards felt worth buying. Some cards played a minor role at certain points in the game, leading to both teams avoiding them. As a result, these cards would gradually accumulate, and eventually, the entire card table would consist only of these less desirable options. To prevent this, we implemented a system where the first card in the queue is automatically destroyed every minute, ensuring a constant rotation of available cards.

To give players even more options, we decided to introduce two separate card queues.

Here, we’re once again taking inspiration from Splendor, which also features multiple independent card queues. In Splendor, these queues differentiate cards based on their cost and significance: the first queue contains the cheapest cards with minimal victory points, the second queue holds more expensive cards with moderate points, and the third queue offers the most expensive cards with the highest points. We wanted to apply a similar logic to our two queues. However, we faced the issue of having a rather limited variety of cards at that point. So, we needed to introduce several new cards as well.

In the first queue, we placed cards that offered resource management abilities. The second queue was reserved for cards that strengthened the hero.

First Queue Cards:

• Brick: This card has already been described in the previous post.
• Resource Conversion Cards: These allow you to trade 2 different resources for 3 resources of the same type. Additionally, the 3 new resources go directly into the hero’s chest, keeping them safe even if the hero dies. While this is a valuable deal, using these cards often requires spending resources that were being saved for something else, and the resulting resource may not always be immediately needed. Therefore, this card serves more as an investment for the future.
• Gold Coin: Another mechanic borrowed from Splendor. The gold coin can be bought for 2 regular resources and is stored in the player’s chest. It can substitute any other resource when needed for a card purchase.
• Stealing: This card grants the ability to use the “Stealing” spell once during the game. You can steal any resource from the map, no matter how far away it is or whether you have enough energy. This spell can help you acquire a needed resource or prevent the opponent from obtaining one.

Second Queue Cards:

• Healing Potion, Zombie, Soul, Gnome: These cards remain from the previous iteration.
• Sandals: An equipment card that can be bought only once, providing a slight boost to the hero’s movement speed.
• Armor: Increases the hero’s maximum health.
• Vitamin Drink: Increases the hero’s maximum stamina.
• Stamina Amulet: Grants a small stamina regeneration boost.
• Orc Archer: If you purchase this card, one additional orc archer will join your next wave of minions, marching at the back of the column.
• Troll: Similar to the orc archer card, this one adds a large, tanky troll to your next minion wave. The troll will lead the column, soaking up damage.

Mines

In addition to new cards, we decided to introduce new structures that can be purchased using bricks – mines. There are five different mines, one for each resource: a pearl mine, an amber mine, a jade mine, an obsidian mine, and an ice mine. Each mine can be built only once and generates one resource every 30 seconds. However, it only produces a resource if the player has none of that type in their chest or pocket.

As you can see, there are quite a few changes, so we’ll be moving on to testing.

To briefly recap the conclusions from the previous post: the core problem at this stage is that the builder's resource-gathering mechanic not only requires speedrunning but is also completely closed off, preventing players from learning from one another. Let’s focus first on the speedrunning issue. It arises because players are initially given unlimited access to basic resources. Want to chop down trees? Go ahead. Collect branches? Sure. Quarry stones? No problem. There's plenty of everything, and the only limit is time. But why don’t champions face this problem? After all, they also gather resources – experience and gold.

Resource Limitation

The key difference is that champions' resources are limited and provided in equal amounts. Experience (considered a resource for progressing toward victory) is earned passively, simply by being present on the lane. Gold is gained by last-hitting minions, and even then, there’s a cap – it’s limited by the number of enemy minions in each wave. Essentially, the game offers both champions on the lane the same opportunities, and players must use their skills to claim a portion of these resources. As long as there’s no interference, collecting these resources isn’t particularly difficult. If players don’t engage in conflict, their growth will be equal, and only through their interactions does a difference in progress start to emerge.

This is the type of mechanic I needed to introduce in my game – resources should be distributed in equal portions for each team. Gathering them shouldn’t be too difficult, but opponents must have the opportunity to interfere with each other’s progress. When searching for the right mechanic, I remembered a card game – Splendor.

This game is entirely focused on resource collection and features much simpler rules compared to other card games. Essentially, it revolves around one core mechanic with a couple of additional features that help balance the game and prevent players from cheating. Here’s a brief overview of the main mechanic: there are five types of resources, which players use to buy mines that, in turn, generate more of the same resources. Players take turns, and during their turn, they can either collect three resources of their choice from the central bank for free or spend resources to buy a mine that produces a specific resource. There are many different mines, each producing one type of resource, with varying costs. All of them are available in a shared syore for all players. The goal of the game, in simple terms, is to build as many mines as possible and accumulate a lot of resources. The mechanic itself is very straightforward, but it has the feature I need – limited resource distribution.

The limitation comes from the fact that on each turn, a player can only take three resources from the bank or buy a single mine from the store. This creates conflict between players, as everyone interacts with the same resource bank and the same mine store. For example, a player might need certain resources to buy a specific mine, but those resources aren’t available in the bank at the moment because another player took them. Or, after saving up for a long time to buy a certain mine, another player might suddenly purchase it.

Another important aspect of Splendor is its complete openness – there are no hidden cards in the players' hands. Every move a player makes is visible to everyone at the table. This means that if someone begins using a new and unusual strategy, other players can quickly observe and adopt it. Overall, the game contains everything I need, and now I just have to figure out how to integrate this mechanic into our own game.

Major Gameplay Overhaul

To start, I decided to remove unnecessary mechanics that overcomplicated the gameplay, didn't solve any problems, and didn't make the game more interesting:

• The blast furnace was removed, and stones containing copper and iron now give ready-to-use ingots immediately. Building the furnace wasn’t a meaningful decision in the game. It was simply a necessity that had to be completed as quickly as possible, essentially another element of speedrunning. Smelting ore into ingots didn’t offer any tactical depth either – it was just another mechanical necessity that distracted the player from other tasks.
• The crafting table was also removed. Like the furnace, it didn’t offer any strategic flexibility. It simply needed to be built as soon as possible.
• Items produced at the crafting table were eliminated. The reinforced pickaxe had become the number one necessity and a speedrun element, while the backpack had fallen out of use ever since players no longer needed to return to the base for building materials. The sling had never been used since the beginning. On the other hand, gnomes remained tactically useful, but I’ll talk about them later.
• The mechanic for summoning minions with souls was also removed. Souls were initially introduced as a replacement for gold, a way to limit the player's ability to strengthen minion waves and break the "snowball effect". At the time, it worked, but the soul mechanic introduced a lot of unpredictability. It was hard to control when and how many souls players would collect, so often they wouldn’t have enough at critical moments to summon the next wave. To simplify things, we made minions completely free. The original problem that created the snowball effect was gold. Removing gold had already solved that issue, and there was no need to introduce a replacement mechanic. However, even though minions were free, players still needed to build the corresponding lair to summon them.

Next, I focused on reworking the resource system. The first step was making the entire forest non-interactable. All those trees, bushes, and stones in unlimited quantities were no longer necessary. Instead, we scattered resource spawn points across the map. Following Splendor's example, we chose five different resources – copper, iron, jade, ice, and obsidian. Each resource spawn point holds exactly one stone, which always breaks with a single hit from the pickaxe and always gives exactly one of the corresponding resources.

There are a total of four resource spawn points for each type of resource on the map, meaning the overall supply of resources is quite limited. This naturally creates conflict over resources, which is a positive outcome. However, similar to how in Splendor resources return to the bank after purchasing a mine, in our game, once resources are spent, they respawn on the map, allowing for continuous resource collection.

The player's inventory is also limited – each backpack slot can hold only one resource, and there are a total of seven slots. There are no chests in the game, so stockpiling resources is pointless.

To simulate the restriction in Splendor, where a player can only take three resources per turn from the bank, we designed it so that each swing of the pickaxe depletes exactly one-third of the character's total energy. The energy is set to regenerate fully in 30 seconds, meaning resource collection is quite limited – on average, players can gather one resource every 10 seconds.

To ensure that the core resource-gathering mechanic was transparent and allowed players to learn from each other, we temporarily disabled the fog of war.

Card Table

With the previously mentioned changes, we successfully created our version of the bank mechanic from Splendor. This alone could have been enough to solve the core issues: resource collection was now evenly limited, transparent, and introduced competition among players. However, we decided to take it a step further and adapt Splendor's mine shop mechanic, which also fostered player conflict.

Let's take a closer look at this mechanic. Even though each mine in Splendor grants only one resource, the prices vary between them. Even mines that provide the same resource can have different costs. Depending on the player's current resources and which other mines they own, the actual price they pay can vary greatly. Players can buy mines in a way that maximizes efficiency, allowing them to save resources and reduce the need to draw from the bank in future turns. Other players, seeing this, can interfere by purchasing a valuable mine first, forcing the player to either waste a turn gathering more resources from the bank or buy a less optimal mine at a higher price.

I decided to try adapting this logic into our game. Resource spending in our game mainly occurs when purchasing minion lairs or upgrading minions. So, I completely removed the old construction menu and introduced the card table. Five different cards were implemented to begin with: brick, soul, zombie, healing potion, and gnome.

Here’s a quick overview of the available cards:

• Bricks: Builders use these to construct minion lairs.
• Souls: Used for upgrading minions. Although we still call these cards "souls," they’re no longer the same souls that were previously used for summoning minions.
• Zombie: Purchasing this card forces the opponent's next wave to consist only of zombies. Since we abandoned the old system of summoning minions using souls, zombies – once an automatic penalty wave – lost their original function. However, this card now serves as a way to punish the opposing team.
• Gnome: Grants the builder a ranged gnome. These are the same gnomes that could previously be crafted using the crafting table.
• Health Potion: Simply heals the hero.

The card table is shared between both teams, meaning once one builder buys a card, it’s no longer available for the other team. A new card, generated randomly, replaces the purchased one. Both the card's effect and its price are randomized, making pre-planning virtually impossible. This mechanic completely eliminates the speedrun element, as players now have to react to current circumstances rather than follow a preset strategy.

With this intriguing and promising system in place, we moved on to testing:

And I’ll dive into the analysis of the results next time.

After the changes described in previous posts, the builder's gameplay started to form a clear and cohesive picture. The key adjustments were the radical simplification of construction mechanics and the introduction of a rock-paper-scissors dynamic among the minion races. Most of the time, the builder was busy gathering resources in the forest and immediately investing them in development. Occasionally, they had to shift focus from base building to either adjust a wave of minions or issue direct orders to a specific one. We fine-tuned the balance of this mode and made some minor adjustments to the storage system, and at that point, we could say the mode was more or less ready. It was time, once again, to take a critical look at the result.

Once we stopped making radical gameplay changes and started playing a stable version of the game, successful tactics and strategies quickly emerged. These strategies also highlighted the key player skills that had the most significant impact on victory. We soon discovered that the most crucial factor affecting the entire course of the game was the builder having a pre-planned action sequence for the first 5-10 minutes. During this period, the champions were still too weak to engage in ganks and were focused on farming minions. Builders were left to their own devices without any external threats, and the faster they developed during this phase, the stronger their foundation for victory would be.

As a result, from the very start of the game, the builder would rush to a specific tree to gather an exact number of logs, immediately construct a crafting table, then follow a pre-determined route to gather a specific amount of stones to build a furnace. And so on. It became clear that we had unintentionally introduced a new mechanic into the game – an element of speedrunning.

Speedrunning

In general, speedrunning isn’t inherently a bad thing – it’s a mechanic that has its own dedicated fan base. Some players even create speedrunning challenges for themselves in games that weren’t originally designed with that in mind. For an outside observer, it can be fascinating to watch a skilled player navigate through difficult sections of a game with precision and speed. However, I know for a fact that this style of play isn't for me.

In my games, particularly Force of Nature, there has never been any pressure on the player in terms of time constraints. I didn't even include standard survival mechanics like hunger or thirst, which often force players into a constant state of stress, preventing them from relaxing. Instead, health and stamina in my games regenerate gradually, signaling to the player that there’s no need to rush. Perhaps this reflects how my mind works – I enjoy solving complex problems, but I prefer to tackle them at my own pace. You might ask, "Artem, if you’re not into fast-paced gameplay and prefer a slower pace, why did you even decide to create a real-time, multiplayer battle game where speed inevitably plays a role?" Well, it’s true that in a MOBA, you can’t afford to be slow, but the required speed is of a different nature. In a MOBA, you need to carefully observe your opponent, assess the situation, spot opportunities, and strike at the right moment. You’re not in a rush; you simply need to be precise and attentive.

The fact that the resulting playstyle didn’t suit me personally created some challenges, as it’s difficult to balance something you don’t connect with. However, the experience of developing both parts of Force of Nature taught me that you can’t create a game solely for yourself. You need to tap into the preferences of the majority within your target audience. So, let’s take a closer look at the popularity of speedrunning among players of similar game genres.

Real-time strategy (RTS) games are quite similar to MOBAs, especially considering that the MOBA genre originated from Warcraft. In our case, it’s not just about the MOBA elements; we also have resource gathering and base development. If you closely observe multiplayer matches in RTS games, you'll notice the presence of speedrunning, especially in the early game. Optimal strategies are often calculated down to the second during the first few minutes. But how popular are strategy games these days? According to research, the number of players interested in strategy games has been steadily declining over the years. You can read more about this here: Gamers Have Become Less Interested in Strategic Thinking and Planning. The article analyzes the preferences of millions of players and reveals a consistent drop in their desire to plan their actions far ahead.

Now, let’s consider the MOBA genre itself. There is a class of heroes that doesn’t level up on the lane but instead roams through the jungle, killing neutral creeps. These heroes also follow a pre-planned route, and speed is crucial in executing that plan. Essentially, they are performing a speedrun. However, in a team of five professional players, only one hero usually takes on the jungler role. And in casual teams, it’s not uncommon for no one to want to play the jungler at all. This suggests that playing as the jungler in a MOBA is a role mostly preferred by experienced and hardcore players.

After analyzing all this information, I concluded that I should avoid including speedrunning elements in my game as much as possible. Speedrunning significantly raises the entry barrier and alienates a large portion of players. However, avoiding it is easier said than done. The success of the builder’s gameplay depends heavily on how efficiently they gather resources, and with proper planning, resource gathering can be far more effective than without any planning at all.

Closed Gameplay

But the issues don’t stop there. Another major problem that surfaced is the overly closed nature of the gameplay. Let’s assume a new player has somewhat figured out the game and devised a basic development strategy. However, they’re playing against a slightly more experienced opponent with a better strategy, leading to a loss for our new player. Now, the defeated player understands that they need to change their approach, but how will they figure out what exactly needs to be changed? How does a player actually learn to improve?

Let’s take a look at champions. Champions are constantly interacting with one another, allowing players to observe what their opponent is doing. If a less experienced player is up against a more skilled one, they can pick up on certain techniques and adopt successful strategies. This creates a constant exchange of knowledge between players. Even if a player doesn’t win, they’re still learning something new. While most MOBAs feature the Fog of War, which obscures a team’s overall actions, the most fundamental mechanics – farming on the lane and passive combat with the opponent – remain fully visible. This allows players to quickly grasp the essential skills of the game.

For the builder, however, the most fundamental skills are resource gathering, base construction, and minion wave selection. Of these, only the wave selection is visible, as the opponent can immediately see which minions are coming down the lane. Resource gathering and base development, on the other hand, are completely hidden behind the fog of war. This means that if the opponent is more efficient in these areas, the losing player has no way of learning from their tactics or improving their own gameplay.

Conclusion

Both of the issues discussed – speedrunning and closed gameplay – stem from the builder's core mechanic: resource gathering. This means that changes need to be made to the very foundation of the gameplay. It was a tough decision because altering the core mechanics would inevitably lead to a cascade of radical changes throughout the rest of the game, requiring almost everything to be rebuilt from the ground up. But the decision was made. In the end, we discovered an unconventional resource-gathering mechanic that addressed both of these problems, and I’ll dive into that solution next time.

In the previous post, I discussed the need to make controlling the lane more convenient and to simplify base development. We first tackled the base-building aspect, which immediately had a positive impact on the gameplay for the builder role. Now, the next step is to make lane control more user-friendly and intuitive.

To recap, the most crucial aspect of controlling minions is that each race of minions has a specific race they "hate," so to speak, against which they deal double damage. If players can accurately predict the race of the enemy minions, they can send counter-race minions that will easily defeat them. However, in actual gameplay, lane battles often devolved into chaos, making it difficult to predict anything. As a result, no one really bothered trying to guess which minions the opponent would send next. To address this issue, we previously introduced a history of the last two enemy waves, but this feature provided little help. Often, these waves consisted of minions from different races, making it challenging to quickly figure out the right sequence of counter-races to deploy.

Visual Cues

To begin with, we decided to reduce the number of races in the cycle of minions that "hate" each other from four to three. With a cycle of four races, each race has one they counter, one that counters them, and one neutral race diametrically opposed in the circle. This creates too many relationships to keep track of. By reducing the cycle to three, we simplify it into a classic “rock-paper-scissors” format, where there are only three relationships to remember, making it much easier to grasp.

As a result, we completely removed orcs from the game, as they were the least interesting of all the minions. Among the remaining races, spiders counter skeletons, skeletons counter lizards, and lizards counter spiders. To make this relationship even easier to remember, we decided to visualize it and always display it as a helpful hint in the minion wave selection window, represented by a relationship diagram. But that’s not all. To further simplify the selection of minions for the next wave, we decided to show the composition of the enemy's last wave directly in the minion selection window. Additionally, above the heads of minions in the rival races, a visual cue now indicates which race should be selected to effectively counter that specific minion.

Assassin Minions

I’ve previously mentioned that melee minions were the least useful, and to make them more desirable, we gave them the ability to carry beneficial spells for the champion fighting on the lane. However, lately, we’ve been playing 1v1 matches as builders, which made this feature of melee minions less useful, once again raising concerns about their effectiveness.

To increase their value, we decided to change their behavior model. While these minions couldn’t stand out with high defense like tanks or attack from a safe distance like ranged units, they made up for it with smarter behavior. Melee minions now prioritize attacking the minions they "hate" most – the ones against whom they perform best. They can even bypass tanks to go after ranged enemies, who are particularly vulnerable to their attacks.

Minion Battle Map

With the composition and order of minions in each wave now playing a crucial role, balancing them became much more challenging. As I mentioned earlier, we recorded all our games so I could review and analyze the footage, making necessary adjustments. However, the problem was that the minion battles rarely appeared in the builder's field of view, making it difficult to assess whether our new mechanics were working as intended. To solve this issue, I decided to implement a mini-map of the minion battle in the corner of the screen that would always remain in the foreground.

On this map, each minion on the lane is represented by a small circle. The color and icon encode the minion's race and type. An outer ring indicates the minion's health, while an arrow extending from the circle shows which enemy it's currently attacking. Despite my efforts to simplify this visual representation as much as possible, it was still nearly impossible to interpret in real-time during gameplay. However, this wasn’t a major issue; during post-game analysis, I could pause, rewind the footage frame by frame, and closely examine any questionable battles.

Accelerating Base Construction

In addition to what was shown in the previous video, we also realized that there was no real benefit to having construction take a significant amount of time. Previously, because the builder had to spend extra time moving between the forest and the base, they would try to bring back as many resources as possible in one trip. However, now that this movement isn't necessary, the builder rarely accumulates surplus resources. As soon as the resources for the next structure are gathered, they’re immediately put to use. Consequently, the builder seldom multitasks. If the builder starts constructing something, it's usually to use it right away, and the 10-20 second build time began to feel like an unnecessary distraction. To stay productive, players had to switch to another task and then remember to come back to finish the first one. To eliminate this disruption, we decided to make construction nearly instantaneous, reducing the build time to just 1 second.

All these changes are demonstrated in the following video:

As always, we'll dive into the analysis next time.

Let’s take a closer look at how the changes described in the previous post have impacted the overall gameplay experience.

The new fog of war mechanic hasn’t made much of a noticeable difference yet, but that’s not a big concern at this stage. Its primary purpose is to make interactions between builders and enemy champions more engaging, and so far, we’ve mainly been testing builders in 1v1 scenarios.

Now, regarding the new system of purchasing minions with souls: While this system was designed to prevent a snowball effect in terms of development disparity, it didn’t fully address the issue. As you can see in the video, for the entire second half of the game, enemy minions were relentlessly attacking my base, and I couldn’t turn the tide in my favor.

The main problem is that the new soul-based system demands too much attention. Players now need to constantly monitor the lane, keeping track of which minions the enemy builder is sending and ensuring they have enough souls to send out the next wave of minions. At the same time, they have to develop their base and gather resources. As a result, something would inevitably slip through the cracks. I would either lose control of the lane or fall behind in base development. Both situations led to the enemy minions gaining the upper hand, ultimately resulting in a total defeat. It became clear that both of these elements – lane control and base development – needed to be made more intuitive and manageable.

Lane Control

To simplify lane control, we added a panel that can be accessed by pressing the Tab key. This panel displays the last two waves deployed by both teams. Additionally, you can view the minion upgrades each team has researched.

This allows you to quickly check which minions your opponent is focusing on and deploying without having to divert all your attention to the lane.

Base Development

During testing, we identified several aspects of playing as the builder that require the player's attention but offer little to no enjoyment:

1. The builder wastes a significant amount of time running back and forth between the base and the forest. The journey from the base to the forest is time-consuming, even with the addition of a speed-boosting ability. During this time, the player cannot engage in anything productive.
2. The builder must manually place each structure they intend to build. However, in practice, the location of these structures has minimal impact, as enemies neither attack nor interact with them. At the same time, placing them randomly isn't an option either, as it could block important paths. This results in the placement of each new structure becoming a time-consuming task that shifts the player's focus to something trivial.
3. It's challenging to keep track of all the building recipes and ensure there are enough resources for each construction. To address this, we borrowed a feature from Force of Nature 2 that allows players to pin a recipe to the screen. However, this window only displays one recipe at a time, which often proved insufficient.
4. On the base, the builder constantly has to run between different structures, clicking on each one to interact. These unnecessary mouse clicks tend to confuse and frustrate the player.

To address all these issues at once, we introduced a single solution: the Base Management Panel.

With this panel, the builder can view all available structures in the game, including those they already have and those yet to be built. For structures that haven’t been built yet, the panel shows the required resources – how much is needed and how much is already available. Additionally, the builder can access any existing structure directly from this panel to interact with it – for example, crafting a new pickaxe, sending ore for smelting, or researching a minion upgrade. The player can open this panel at any time, even when they’re not at the base, eliminating the need to constantly run back and forth between the forest and the base for minor tasks.

Moreover, the panel removes the need to manually place each structure. The base comes with several pre-designated construction sites, and when a structure is selected in the management panel, it automatically begins building on the first available site.

Undead Minions and Testing

In addition to the quality-of-life improvements, we decided to introduce a new lair – the Undead Lair. When the builder constructs this lair, and they lack enough souls to send out the next wave of minions, a wave of demons is sent instead of zombies. These demons are significantly stronger than zombies, but building this lair requires obsidian – a resource that, as you know, is quite difficult to obtain.

Here are the recording from our tests:

At first we were still getting used to the new controls and often forgot that we no longer needed to approach a structure directly. However, everyone immediately loved the new base management system, and it made the gameplay much more enjoyable. I’ll share more about further improvements in the next update.

Even though we began adjusting the gameplay to ensure that every action taken by the builder produced predictable outcomes, the practical effect was not particularly noticeable. The champions on the lane had a significant impact on the minions, making it difficult to observe the results of choosing the correct or incorrect minion race to send in the next wave. Therefore, from this point on, we frequently arranged 1v1 builder duels. This allowed us to refine the gameplay without external interference.

Snowball Effect

One of the main issues that immediately caught our attention was the so-called "Snowball Effect". If a player managed to win an early battle and earn more money than their opponent, they could use those funds to summon stronger minions in the future, build new dens first, and research more upgrades than their rival. This significantly increased the chances of their minions winning subsequent battles, thereby earning even more money. Over time, the power gap between the opponents widened. This gap in money is similar to how a small snowball rolling down a hill starts growing slowly but eventually becomes larger and larger, quickly gathering more snow and expanding at an accelerating pace.

This effect is highly detrimental to computer games, as a small mistake or random event at the beginning of the game can render the rest of the match meaningless, even if the players' skills are roughly equal. As a result, players may feel frustrated and lose interest in the game.

We needed to devise a mechanism to prevent the "snowball effect" regarding the money for minions. After much deliberation, we decided to eliminate gold for the builder entirely. Previously, gold was one of the most important resources for the builder – it was used for constructing dens and hiring new minions, and it was earned by killing enemy minions. The new idea was to remove this resource completely. All constructions are now built using resources gathered from the forest. As for summoning minions, a new resource called souls is now used.

Souls

Initially, each team has 10 souls. To send a minion into battle, a soul must be invested. For example, sending an initial wave of 5 goblins costs 5 souls. Thus, each team has enough souls for 2 waves of minions from the start. When an enemy minion is killed, its soul transfers to the opposing team. If a tower kills the minion, its soul lingers in limbo for 30 seconds (the interval between minion waves) before returning to the team from which the minion originated. Therefore, it is crucial to prevent minions from reaching the towers and to kill them in open fields. As a result, minion souls constantly shift between teams.

If a team lacks enough souls to send the next wave of minions, a squad of 5 zombies (undead with no souls) is sent instead. They are relatively weak, so builders should avoid this situation. Killing zombies does not grant the opposing team any souls, as zombies have none. Some minions require more than one soul, costing 2 or even 3 souls depending on their strength. For these minions, the enemy team receives one soul upon their death, while the remainder returns to the team that sent them.

Thus, souls in the game neither appear out of nowhere nor disappear into nothingness. They can only transfer from one team to another, using minions as intermediaries. The initial total number of souls for both teams is 20 at the beginning of the game and remains constant until the end of the match. Throughout the game, small snowball effects may occur – one team might gain a temporary advantage in the number of souls they possess. They can use this advantage to create a stronger wave of minions that easily defeat enemy minions, thereby earning even more souls. However, this snowball effect cannot grow indefinitely, as no team can have more than 20 souls. Moreover, this advantage is automatically mitigated by the opponent’s tower, making it temporary.

Additionally, the builder can choose to send zombies for a few waves to save up souls, then attempt to create their own snowball effect with a wave of powerful minions that can sweep through the opposition.

I particularly liked the minion soul concept because it ties in well with the game's title – Force of Nature: Ghost Keeper.

New Fog of War

In addition to the soul concept, I decided to revamp the fog of war system. Previously, characters could see an area in a circle around them, regardless of whether there were trees, bushes, or mountains in the way. Now, all obstacles block their line of sight.

Traversing the forest has become more dangerous for the builder, as champions from the opposing team or other threats could be lurking behind every bush and around every corner.

Implementing this effect turned out to be quite an interesting optimization challenge. To create the fog of war map, I used a method reminiscent of the rendering techniques from early 3D games like Wolfenstein 3D (1992) - 1D Z-Buffer. First, I define the contours of all objects near the hero and render them into a one-dimensional depth buffer. This gives me information on how far the hero can see in each direction around them. Using this information, I form a "visibility star" centered on the hero, which is then rendered into the fog of war texture. After creating and rendering such a visibility star for each character on the allied team, I slightly blur the resulting fog of war texture. This process doesn't happen every frame but rather several times per second. On the frames in between, the data is interpolated between the last and second-to-last states of the fog of war. The interpolated texture is then used to render the final image. Much of this computation is accelerated by the GPU.

Here is a recording of the testing of these changes.

I will discuss the resulting gameplay, along with its pros and cons, in the next post.

In my last post, I concluded that the builder's gameplay needs to be filled with meaningful choices. This primarily concerns how they spend resources rather than how they gather them. The builder can invest resources in either minions or towers, leading to the first non-obvious choice: should resources be spent on towers or minions? In which situation is it more beneficial to develop towers, and in which is it better to enhance minions? Practice has shown that it almost always makes sense to invest in minions, while upgrading towers seems pointless. Let's try to understand why this is the case.

Tower Development

Broadly speaking, investing resources in minions boosts the team's offensive capabilities, while investing in towers enhances the team's defensive capabilities. During our testing, we found that focusing all efforts on offense was necessary, while defense could be neglected. This seems somewhat unnatural. Yes, developing an attack is essential for victory – no one disputes that. But everyone is also accustomed to the idea that good defense is a crucial factor in achieving victory in games. Consider any competitive games: whether strategies, soccer, or even boxing. Completely ignoring defense often leads to defeat. If a boxer only trains their punching power but leaves themselves open, they risk not having the chance to land their powerful punch and might get hit by the opponent's weaker, yet still effective, punch. In soccer, if the entire team rushes to attack the opponent's goal, just a couple of opponents need to bypass the attackers, receive a pass, and they'll have a good chance of scoring with a modest attack.

The situation is similar in strategy games. Suppose players A and B have an equal amount of resources. Player A decides to spend all their resources on building a large army and immediately sends it to attack player B. Player B, however, invests in strong defenses and can withstand player A's assault. Defense is usually cheaper than offense, so to successfully repel the attack, player B might not have to use all their resources, only a portion. After fending off the attack, player B still has resources left to create a small squad of warriors and send them to counterattack player A. This squad might not match the strength of player A's initial army, but it won't face any resistance, as player A's base has no defenses at all. Player B can then destroy the opponent's base and win the battle.

But why doesn't this same logic work in my game? The answer is quite simple – in my game, all battles occur on a single lane. The armies have no opportunity to bypass each other. To reach the opponent's tower, they first need to destroy all the minions in their path. If player A spends all resources on offense, while player B spends some resources on defense, then in each clash, player A's minions will prevail, and their remnants will attack player B's tower. Of course, I am simplifying things greatly. In practice, there are ways to bypass minions and strike the tower, for instance, with the help of champions or controlled minions. However, we were playing 2v2, meaning each team had only one champion, and attacking a tower with just one hero was highly inefficient. It's not that investing resources in towers was entirely pointless – the point of contact between minions doesn't stay in one place all the time. It oscillates throughout the game, sometimes closer to one team's base, sometimes closer to the other team's base. Even if all resources are invested in strengthening minions, there will still be moments when enemy minions approach the tower. So, with careful consideration, it is possible to balance the game so that strengthening towers plays a more significant and justified role. However, remember that we are currently trying to address the problem of meaningful choices regarding resource allocation. At that time, there was no real dilemma about whether to invest in defense or offense – the choice always favored developing the attack, i.e., the minions. While this is not good, it is a separate issue that can be resolved in the future. The truly pressing problem is making the choice of how to invest resources in minions more deliberate and meaningful.

Minion Development

The builder faces three main choices regarding minions:

1. Which den to build next?
2. What configuration of minions to send in the next wave?
3. Which upgrades to enhance?

Let's break down these points.

Which Den to Build Next?

What is the fundamental difference between different minion races? In Force of Nature 2, there were quite a few enemies, so I created many different dens, but the minions within them didn't differ much from each other. The principal differences were only between goblins, rats, mages, and the rest. Goblins are unique in that they are free and available from the start. Rats are also free but significantly stronger than goblins. Mages require obsidian – a resource that is tricky to collect for their development. All other races were very similar to each other. Yes, their dens required different resources, and the minions themselves had slightly different stats. However, they were balanced to be equal in strength, because if one race was stronger than the others, it would render the rest useless. We could remove some dens entirely, but then the builder would quickly finish all the constructions and have nothing left to do.

The first solution to this problem was quite simple: we imposed a limit of a maximum of two units of the same race per wave. This forced builders to use more variety and construct more different dens.

The second solution we came up with was as follows: goblins, rats, and mages remained unchanged, fulfilling their original roles. However, the other races – spiders, skeletons, orcs, and lizards – became rival clans, dealing increased damage to each other in a closed loop. This means: orcs deal double damage to skeletons, skeletons deal double damage to lizards, lizards deal double damage to spiders, and spiders deal double damage to orcs. This way, all races remain equal in strength, but the choice of which den to build next becomes crucial. This creates a unique “rock, paper, scissors” dynamic within the game.

What Configuration of Minions to Send in the Next Wave?

The idea of rival clans partially solves the problem of choosing the specific configuration of the wave. When you have several different races at your disposal, it makes sense to monitor which races the opponent is sending and try to counter with your own. However, we noticed another issue that needed addressing – the low usefulness of melee minions. Like tanks, they move to the front lines of the battle but almost immediately die because, unlike tanks, they have less defense.

Tanks, though dealing significantly less damage, can absorb damage for a while, allowing archers to inflict damage on the enemy. As a result, the common configuration was often 2 tanks + 3 archers instead of the default 1 tank + 2 melee + 2 archers. To make melee minions more useful, we decided to give them unique abilities that could be cast when needed. Both the builder, by possessing a minion and controlling it, and the champion on the lane could cast these abilities. When pressing the Control key, an icon of the spell would appear above the minion’s head. Clicking this icon would cast the minion's ability. It looked like this:

The abilities were as follows:

• Spider Melee Minion: Upon activation, it explodes and poisons all nearby enemies, dealing substantial damage over time but very slowly.
• Skeleton Melee Minion: Provides a significant magical defense boost to all nearby allies for a period of time.
• Orc Melee Minion: Greatly increases its running speed. This made it much more effective at distracting neutral towers and, if needed, catching and finishing off fleeing champions.
• Lizard Melee Minion: Heals all nearby allies.

To avoid making these minion abilities too powerful, each minion carried only a single charge. When a minion used its ability, the charge would be depleted from all nearby allied minions as well. Therefore, there was little benefit in sending a large number of melee minions into a wave just for their spells – only one minion per wave could cast the spell.

Mage abilities also now had charges. Each mage initially had 3 charges of their ability, and these charges were also consumed if any nearby allied minion cast a spell.

Which Upgrades to Enhance?

Previously, upgrades for minions were more significant, as there was less emphasis on which den to build next. It was quite beneficial to fully upgrade minions of one race and rely solely on them. Now, however, with the game requiring the construction of all dens to maintain a broad selection for the next wave, we used upgrades much less frequently. Therefore, at this stage, we decided to leave the upgrades as they were and not make any changes.

Here are the results from testing:

As a bonus, I will also include a demonstration of gameplay with the Warrior champion, as I haven’t showcased it yet:

Disclaimer: I would like to remind you that everything I show and describe here represents stages of development. Absolutely everything you see now has been changed, and not just once.

Now let's focus on the issues we see in the current gameplay (after several tests, one of which I described in my previous post). I'm not talking about minor issues like interface convenience, bugs, or balance flaws. Those things were quickly identified and fixed. I'm talking about more serious problems – there was no unique aspect in the builder gameplay that could captivate players and make them want to play the game repeatedly. From this point onward, my task as a game designer reached a new level. Previously, my job was simply to create a new game (by "game," I mean a set of rules that define the gameplay, not a finished product). Now, I had to make this game engaging. We are now delving into the psychology of the player.

During the tests, I always found myself more inclined to play as the champion rather than the builder. This posed a significant problem. There's no surprise in the fact that playing as a champion is exciting – the gameplay was inspired by DOTA and League of Legends, some of the most popular and successful games in history. This gameplay has been refined over two decades by various developers and millions of players. But why is playing as the builder less interesting? The builder has so many abilities and such diverse gameplay. In fact, when reviewing our test recordings, I always found the builder videos far more engaging to watch. Yet, I still preferred playing as the champion. So, what was wrong with the builder? Understanding this turned out to be quite challenging. Many of my conclusions might seem straightforward and logical now, but arriving at them required a lot of time and contemplation.

In the course of all these reflections, I discovered several key principles that influence the engagement of the game. Here is the first principle I arrived at:

• A player must clearly understand their contribution to the team and be able to assess how well they are fulfilling their role.

The Psychology of the Champion

Let's examine this principle from the perspective of the champion. The champion's value to the team lies in their combat prowess, which is reflected in their ability to kill opponents. The more they kill other heroes and destroy towers, the more valuable they are to the team. In practice, this is, of course, more complex, but for understanding player psychology, this simplification suffices. In addition to the primary measure of effectiveness, kills, there is a secondary measure: gold. The more gold a champion earns, the stronger they become, and the greater their potential to defeat the enemy. That’s it – kills and gold: two numerical metrics sufficient to determine a champion’s effectiveness.

If a player loses while playing as a champion, they can analyze their game to understand their mistakes and weaknesses. Perhaps the player struggles with last-hitting minions, earning less gold than their opponent, making them weaker. Or maybe they are buying the wrong items in the shop, hindering their chances of victory. They might also be taking too much damage from minions while attacking the enemy at inopportune times. By analyzing these aspects, the player can identify their errors and start believing they can fix them next time and improve their gameplay. This anticipation of applying new knowledge keeps the player engaged. If the player is already earning a lot of gold, winning battles, and destroying towers, they won't have issues with self-esteem. Their engagement comes from the sense of superiority over their opponent.

The Psychology of the Builder

Now, let's return to the builder. How does the builder contribute to the team's victory? They gather resources and invest them in minions and towers. Of course, they have other tasks – reconnaissance, direct participation in battles through minions, etc. However, these are not their primary responsibilities. The builder intuitively evaluates their contribution to the team through two metrics: how efficiently they gather resources and how effectively they spend those resources.

The efficiency of resource gathering can be measured by the quantity of resources collected. This is a bit more complex than gold for champions because there are many different resources, each with varying value. Will the builder be satisfied if they collect significantly more branches than the opponent, but the opponent gathers more copper, iron, and obsidian? Probably not. However, there is still some opportunity to quantify their work, compare these numbers, and monitor which strategies lead to increased resource numbers.

What about the spending of resources? This is where the main problem lies. Imagine a situation where the builder collects significantly more resources than the opponent, but their team still loses. How does the builder distribute the responsibility for the loss between their own efficiency in managing collected resources and the champion's performance in the lane? Did the team lose because the builder ordered the wrong minions, or were the minions good and correct, but the champion in the lane played poorly? It's unclear. And the builder themselves can't determine this – they can't evaluate their own gameplay, identify their weaknesses, or understand what to focus on in the next game to achieve victory. They can't even tell if they're playing correctly at all. As a result, after a few losses, interest in the game wanes, and the player is likely to switch to another game.

Let me emphasize the most important point: the builder must be able to see which of their actions yielded good results and which did not. Currently, this feedback is missing. The player has to make many decisions about where to allocate resources, but there is no way to evaluate the consequences of those decisions. Something needs to change in the builder's gameplay so that the decisions they make have clearer and more visible outcomes.

For now, let's pause on this thought. Additionally, I will briefly talk about another side project I was working on in parallel.

VR Shooting Range

The idea for a VR shooting range came from a 3D artist who worked with me on the second part of Force of Nature. I happened to have an old HTC VIVE VR headset, and the idea seemed intriguing, so I agreed to help him create a game prototype and test his concepts in practice. The game is set in a cowboy-themed environment. You play as a rowdy bar patron who starts seeing targets in every object around him. The game is time-limited, and your goal is to score as many points as possible. Different objects yield different point values, but the core concept is that the environment reacts to your shots in specific ways, creating new opportunities to earn even more points.

Developing a game for VR turned out to be a new and exciting experience for me. It was not as complicated as I had initially thought. Nevertheless, we soon decided to put this project on hold and focus more on our primary tasks. Perhaps we'll return to it in the future. Here’s how the prototype looked.

Of course, the prototype is filled with third-party assets, lacks animations, special effects, and sound. We didn’t aim for final-quality visuals; our goal was simply to familiarize ourselves with the new technology and test the viability of the idea.

To begin, let me briefly summarize the previous post. The builder had minimal interaction with others during the game, so the following changes were made to address this issue:

• The map was redesigned to include a shared forest for both teams, where builders can gather resources.
• A new leveling system for builders was introduced, encouraging them to visit the forest more frequently.
• The attack mechanics of the gnomes were adjusted so that they could be the same easily destroyed by both champions and builders.
• Builders now have adaptive running speeds: they run quickly when no enemies are nearby and switch to normal speed when enemies are present.

Now, let's move on to testing. We will examine the gameplay from the builder’s perspective. I apologize in advance for the video quality. We recorded these sessions for internal use – they were very helpful in analyzing the outcomes of matches. During gameplay, attention is often focused on one thing, and many issues go unnoticed. Watching the recordings, especially those of someone else's game, allows us to see the overall picture and quickly identify areas for improvement. As a result, after each game, we had several videos from the perspective of each player. To facilitate faster sharing and easier storage, we decided to record in lower quality to keep file sizes small.

I'd like to highlight some interesting moments from the game and comment on them. I'll refer to the timestamps using the YouTube timer.

The first notable moment occurs at 2:56. Here, the builder goes to collect iron, which is a crucial resource used in many recipes. We intentionally placed it on the map in such a way that the path to it is blocked by bushes from the base side and open from the lane side. Therefore, the builder has to choose between spending time and energy to clear a path through the bushes to the iron ore or taking the lane route, which carries the risk of being spotted by an enemy champion. In this scenario, the builder risks getting trapped with no way out. At 8:23, the builder goes for iron again using the already cleared path. However, you can notice that he decided to mine the ore closer to the enemy base rather than the one near his own base. This was because the current situation on the lane made it unlikely for him to be spotted by an enemy champion. Since iron is quite limited on the map and may become scarce towards the end of the game, the builder seized the opportunity to steal the enemy's ore.

At 13:44, we see the builder actively placing archer gnomes. He strategically places them among trees to prevent enemy melee minions from reaching them. Another gnome is placed at the enemy's iron ore (at 15:14), highlighting one of the most strategically important locations.

The next crucial stage is the extraction of obsidian. Our builder chose a method where the tower guarding the obsidian is distracted by a minion. First, the builder constructed an orc lair because orcs have a troll, the toughest minion, making it perfect for tanking. At 15:38, we see the builder send the troll to attack the tower, while he stands ready to collect as much obsidian as possible. He barely manages to break one stone, yielding three resources, which is just enough to build a shaman lair – the strongest minions.

At 22:24, we see the builder placing a gnome to monitor the enemy's obsidian. This was a very successful move, as two minutes later, at 23:05, he spotted the enemy builder heading to collect obsidian. Our builder immediately took advantage of the situation and went to interfere with the enemy’s resource gathering. However, upon arrival, he found that the enemy's defensive tower had already been destroyed, allowing him to freely collect obsidian. The enemy builder had opted for the strategy of upgrading to skeleton archers and using one to destroy the tower. As I mentioned in a previous post, this strategy might seem easier at first glance, but it is actually riskier. As a result, our builder managed to collect some obsidian without much effort but decided not to linger because the enemy champion was not visible on the map, posing a potential threat. As soon as the builder finished breaking the stone, he immediately returned to his base. Meanwhile, an allied champion headed towards him to be ready to defend if necessary.

Starting around the 25-minute mark, the builder sets a goal to mine all the iron on the map. Although he doesn’t have a shortage of iron, this strategy can deprive the enemy of a valuable resource. Strategically placed gnomes help spot the enemy champion in time when they attempt to ambush our hero in the forest. Ultimately, the goal of mining all the iron is achieved, leaving the enemy team limited in a resource crucial for upgrading many minions. Later, our builder applies the same strategy to copper.

At 30:35, the builder begins controlling a lightning mage minion to defend a tower from enemy attack. As I mentioned earlier, mages are the strongest minions. Additionally, each mage has a unique spell that the builder can activate with a button press. The lightning mage has an attack that targets all enemies within a large radius. The cold mage can slow down all nearby enemies, while the fire mage can launch a fireball that flies in a straight line, hitting and igniting a single target for a period of time.

At 32:20, using a gnome, the enemy builder was discovered mining the remaining copper near our base. The champion immediately went to gang up on them. They weren't able to kill the enemy, but at the very least, it forced them to retreat to base for health regeneration and disrupted their resource gathering. At 42:21, we see the reverse situation where the builder, controlling a mage minion, attempted to finish off a champion who had very little health left. They also couldn't secure the kill, but it was a tense moment for everyone involved!

In the final minutes of the game, the builder had nothing left to build or upgrade – it was all done. From this point onward, their focus shifted solely to assisting the champion by controlling minions. At 48:30, this assistance proved sufficient to eliminate an opponent. This marked the beginning of the most intense battles, but from the builder's perspective, there was no more material for analysis. One notable tactic occurred at 1:01:00 when the builder decided to barricade the portal with chests from which minions emerged, delaying waves at the base. After accumulating several waves in confinement, they destroyed the chests, unleashing a mega-wave! This unconventional move surprised all other players. Unfortunately, the mega-wave didn't yield much benefit as a mage champion utilized napalm to swiftly dispatch the entire wave with a single spell.

Next, we decided to end the game in a draw as it had already lasted over an hour. As a bonus, I'll upload the same game but from the perspective of the champion.

Let's summarize the gameplay at this point. Have we corrected previous mistakes? Absolutely! The builder now feels like a full member of the team and interacts much more actively with all other players, making the game much more engaging not only for them but also for the champions. Are there still issues in this gameplay? Certainly, and they are quite significant! I'll discuss them in detail in the next post.

For start, let's clarify some terminology: we'll refer to the combat heroes who stand on the lane and fight each other as champions, while the heroes who focus on gathering resources and building will be called builders.

Let's take a closer look at the main gameplay issues using the video from the previous post as an example. At first glance, everything seems quite decent. We see a rather intense and dynamic duel between two champions (an archer and a mage) throughout the game. Meanwhile, the background decorations for this duel, namely the minions and towers, become increasingly interesting, vibrant, and colorful. It looks great; however, the problem is that from the champion's perspective, the game remains a duel from start to finish. There is absolutely no sense of teamwork with the builder.

From the builder's perspective, things are even worse. Although the player is actively engaged in various tasks, and the effectiveness of their actions does impact the game's outcome, they barely feel the presence of other players on their own team, let alone notice the enemy team. For the builder, the game becomes less of a team battle and more of a competition against the opposing builder: who can earn more gold, hire stronger minions, and fortify towers faster. The one who contributes the most to their team wins.

This happens because the builder doesn't interact with anyone in the game. Let's delve into this further. What types of interactions could they theoretically have? Perhaps the following:

• builder to allied champion
• builder to enemy champion
• builder to builder
• builder to minions and towers
• builder to location.

Interaction: Builder – Location, Minions, Towers

First, let's examine the simpler connections. Regarding the "Builder – Location" interaction, there are no issues. The builder runs around the location, gathers resources, and interacts with neutral towers. The connection between the character and the location is strong and persists throughout the game. Now, let's look at the builder's interaction with allied minions and towers. Here, everything is also in order, as this was initially designed to be their primary area of responsibility. The interaction between the builder and enemy minions/towers is more complicated – it is practically nonexistent. The builder cannot personally attack them due to their low damage. To enable the builder to attack minions and towers personally, without turning them into a powerful fighter and rendering champions useless, we decided to give the builder the ability to craft a new weapon – a sling. The sling has a long attack animation, and the stone it launches travels very slowly. As a result, hitting a moving target with it is nearly impossible. However, its damage is quite substantial, making the sling an effective weapon against stationary objects such as enemy towers.

Interaction: Builder – Allied Champion

This is the primary interaction that ensures a sense of team play, and it currently has major issues. The champion has little to offer the builder. Even for gathering obsidian, it was much easier for the builder to enlist the help of a minion rather than distract the champion from the lane, as this could risk losing their own tower. The builder couldn't help the champion either. One might say the builder helps the champion by sending stronger minions to the lane, but in reality, this is more of an influence than direct assistance. Strong minions do help the lane overall, but they aren't flexible enough to adapt to specific situations. Imagine the situation where the opponent has developed faster, and their side has stronger minions than ours. In such a scenario, our champion would face a tough challenge because besides battling the enemy champion, they would also have to deal with the remnants of minions left after each wave. This critical situation prompts our champion to ask the builder for help. But what can the builder do? They cannot send support in the form of strong minions because they are lagging behind in development, and these minions simply do not exist yet. Essentially, all the champion can ask of the builder is to play better!

A more realistic approach seemed to be the builder's assistance through setting up gnome totems. For example, in a critical situation, the builder could come to the lane and place a bunch of archer gnomes who would shoot down enemy minions. Yes, it would require some of the builder's time and resources, but it could effectively help in specific situations. However, a problem arose here as well – the archer gnomes proved to be the most useful, but they were very difficult to balance. If we give them high damage and a lot of health, these gnome totems would become too imbalanced against the enemy builder – just a few of them strategically placed in key points of the enemy forest could make gathering resources practically impossible. On the other hand, with low damage and few health points, these gnome totems became ineffective on the lane – they could be destroyed by a champion in just one or two hits. To try to influence this situation, we decided to change the damage system for gnomes. Each gnome had 3 lives, and any attack against them, regardless of the amount of damage it dealt, would take away one life. This way, a gnome would be destroyed after three attacks, regardless of whether it was attacked by a minion, builder, or champion.

Interaction: Builder – Enemy Champion

It was assumed that champions, when they had some free time, could roam into the forest and try to kill the enemy builder. However, even this did not work out.

The first reason was that it was extremely difficult for the champion and the builder to meet in the forest. It turned out that the builder spent most of the time at the base – constructing dens, processing resources, and researching upgrades for minions. From the beginning of the game, the builder already had a strategy in place for early-game development, so he knew well which resources and how much of them he would need. To avoid wasting time on frequent visits to the forest, the builder would gather all the necessary resources in one trip and spend the rest of the time at the base. To encourage him to go to the forest more often, we significantly limited the size of his inventory, and the initial pickaxe collected resources very slowly. To allow for personal growth, the builder could craft a stronger pickaxe and a more capacious bag for himself. Fortunately, all the necessary mechanics for this were already available in FoN.

But there was a second reason why it was ineffective for the champion to attempt to chase down the builder – they had significantly different running speeds. Even if the champion encountered the builder in the forest, the builder could easily escape. Gathering resources required the builder to constantly cover large distances, so his running speed was much higher than that of the champion, who spent most of his time on the lane. To address this issue, we adjusted the builder's running speed to match the champion's, but we added a passive ability that needed to be upgraded through the skill window – Speed Boost. This skill provided a significant speed boost if no enemies were nearby the builder for the last few seconds. This meant that the builder could still run quickly through the forest to gather resources, but encountering an enemy champion (or even a minion) would instantly deactivate his speed boost ability, giving the champion a chance to catch up.

Since we started adding skills that needed to be leveled up for the builder, we also decided to introduce an ability that significantly sped up the resource gathering process for a few seconds. The ability to control minions was also made into a skill – the builder couldn't control minions right from the start; he needed to first upgrade the corresponding skill.

Interaction: Builder – Builder

Builders from opposing teams also did not intersect with each other. The reason was simple – they each had their own forest for gathering resources. Initially, we designed the location based on the standard MOBA genre map (like in DOTA and League of Legends), reducing the number of lanes from three to one. In MOBAs, each team has its own jungle, and there are heroes who level up not on the lane, but in the jungle – they are called junglers. They are somewhat similar to our builders. The idea of having two separate forests worked perfectly in DOTA and LoL because junglers had a specific role within the team – they leveled up in the jungle and provided assistance on lanes where needed, using the element of surprise. This is how they interacted with other players, and meeting the enemy jungler in the jungle was unnecessary. In our game, however, this division of forests resulted in the builder remaining isolated. Having separate forests made it less effective to influence another builder's strategy through gnomes – placing a gnome in the enemy's forest required spending a significant amount of time just to enter it.

As a result, the map was completely redesigned so that there was only one forest on it, shared by two builders.

That's all for now. In the next post, I'll detail how effective all our gameplay changes turned out to be.

At this stage, we had established a solid foundation for the MOBA+Builder concept. It was possible to play matches with a builder and a hero on one team against another team with a builder and a hero. Based on our impressions, we iteratively improved the game. To facilitate this, my testers and I would gather at a cozy café, order three large pizzas (thanks to a permanent deal – order two pizzas and get the third one for free), and discuss the matches we had played the previous day. We shared our emotions, talked about what we liked and what we didn't, and voiced our ideas and suggestions. We discussed these proposals, refined them, and compiled a list of fixes and new features we wanted to try in the next test. Once all the adjustments were made, we played several more matches and gathered at the café again. The whole process repeated itself.

Minimap

The first thing we changed was the minimap in the corner of the screen. In Force of Nature, the minimap was attached to the main hero, as only the events happening directly around him mattered. In a team game, important events occur in multiple locations simultaneously, so it's crucial to be able to quickly assess the situation. To address this, we had already implemented a free camera that was not tied to the main hero and could move freely across the entire map. However, this was still not enough – it was still quite easy to miss the beginning of an important battle on the main lane, as the builder was focused on a specific task rather than endlessly scanning the area for interesting events.

Therefore, the minimap was redesigned to display the entire location. This allowed players to understand what was happening at a glance. Besides being fixed and showing the whole area, the minimap also needed to integrate with the fog of war. Since fog of war wasn't initially present in Force of Nature, it wasn't shown on the minimap. In Force of Nature, there was no fog of war but rather a display of explored territory. This logic wasn't suitable for a MOBA, as players need to know the topology of the map from the beginning. Only the actions of opponents should be hidden, which is why the fog of war exists. Changing the minimap's logic might seem insignificant, but once it was adjusted, playing as the builder became significantly easier!

Gnome Totems

As another way for the builder to invest resources, we decided to give him the ability to place totems at various locations on the map. To avoid creating special models for them, we used existing gnome decoration models from Force of Nature. We had the Observer Gnome, Shooter Gnome, Defender Gnome, and Berserker Gnome:

The Observer Gnome simply revealed the map around him at a considerable distance. The Shooter Gnome attacked any targets within his line of sight. The Defender Gnome provided an aura to all nearby allies (including minions and heroes) that reduced incoming damage. The Berserker Gnome provided an aura that increased attack speed.

Rat Minions

New minion races were also added, which became available upon constructing special dens – rats and mages. To remind you, in order to summon particularly strong minion units for the next wave, you first need to build a den for that race. Dens are built using resources that the hero gathers in the forest or crafts himself. However, even after constructing a den, its units are not provided for free. For each summoning of a unit, it was necessary to pay with gold. Gold was obtained by killing any enemy minion. The initial minions, goblins, were completely free of charge. If the builder did not have enough gold to summon the next wave consisting of strong units, a wave of goblins was automatically sent instead. As an alternative to goblins, the rat race was added – these units were stronger than goblins and were also provided free of charge.

Here is how the rat den looks:

And here are the rats available for summoning. Like for all other races, there's a tank, melee, and ranged unit:

As you can see, for the ranged unit, we chose the porcupine from the second location of FoN. It shoots three quills simultaneously – one quill flies straight towards the target, while the other two veer slightly to the sides. This feature makes them quite interesting units because with proper positioning, they can collectively deal significantly more damage to the enemy team.

Mage Minions

Another den added to the game was the Mage den. Unlike other races, these units were not divided into tank/melee/ranged categories. All three mages had ranged attacks and differed in their elemental magic – fire mage, frost mage, and lightning mage. For their appearance, I used models of mages from the last location of FoN, but modified the appearance of their staffs to more vividly represent their respective elements.

Magic minions were the most powerful, but their den was not easy to build - it required obsidian. In each forest, there was only one obsidian deposit, guarded by a tower - similar to the towers on the lane, but belonging to neither team and firing indiscriminately at everyone. These towers inflicted less damage than those on the lane, but it was still significant enough to prevent peaceful obsidian mining. Destroying the tower was also difficult, as the builder was extremely weak in combat.

Despite this, there were three different strategies to obtain obsidian:

1. Distract the Tower: This was the simplest method. The builder could mine obsidian while the tower was attacking someone else. A hero ally could also be used as a tank. However, using a minion was more effective because the builder could command it to attack the tower. The best strategy was to develop quickly to the rats, snatch a tank rat from the wave of minions, and send it to attack the tower. Meanwhile, the builder would be prepared, ready to start collecting obsidian as soon as the tower began attacking the minion.
2. Destroy the Tower: Despite the tower being quite strong, it could still be destroyed. Again, the hero's assistance could be used, but using a minion proved more effective once more. The skeleton archer minion had a greater attack radius than the obsidian-defending tower, allowing it to be sent to attack the tower. Once the skeleton archer completely destroyed it, the builder could then safely begin harvesting the resources. However, the skeleton required quite a bit of time to single-handedly destroy the tower, and the builder could only control one minion at a time, unable to multitask. Therefore, this method took longer. Additionally, it allowed the enemy builder to potentially utilize the third method of obtaining obsidian.
3. Steal Obsidian from the Enemy: Using the observer gnome, it was possible to catch the moment when the enemy builder went to mine obsidian and take advantage of the situation – either by disrupting their efforts or using their distraction to gather obsidian oneself. If the enemy builder was busy destroying a tower, it provided a window to freely gather their resources.

Testing

All these new features seemed intriguing to us, but it was equally important to evaluate how the presence of a builder affects the gameplay of a regular hero holding the lane. Here, I will provide an example of an archer hero standing against a mage hero on the lane, while the builders on both teams are busy with their tasks.

Don't pay attention to the bugs and lags. Various issues frequently appeared during testing, but they were promptly fixed as soon as they were noticed. In the video, at the 15-minute and 18-second mark, you can see the allied builder sending a shielded rat to distract the tower while he mines obsidian. Unfortunately, this attempt was unsuccessful. Destroying an obsidian stone yields more resources than mining it, and the stone had very little health left. The builder thought he could destroy it in time, but this turned out to be a fatal mistake. Additionally, the builder lost all his resources in the process. At the end of the 20th minute, the builder made another attempt, this time successfully. Around the 6:45 mark, you can see the archer heading into the enemy forest in an attempt to gank the enemy builder, but this attempt also failed. Naturally, there were still many issues in the current gameplay, which I will discuss next time.

Playing as a builder is what will set my game apart from other MOBA games. Initially, the plan was for the builder to manage the processes that usually happen automatically in this genre. This means that minions and towers would fall under their control.

As with other heroes, selecting the builder was done through skill acquisition. However, unlike the others, the builder had no additional learnable abilities; instead, progress was made by investing various resources. All resources had to be gathered in the forest. For simplicity, I decided to eliminate resources that required crafting. Thus, only directly obtainable resources were used – such as sticks, logs, bamboo, palm leaves, stone, copper, iron, and obsidian. Gold was also a resource, but it wasn't gathered in the forest; instead, it was earned by killing enemy minions and heroes. Like other heroes, the builder had access to a shop where he could buy artifacts. His appearance was customized through invisible clothing slots, which, in addition to their aesthetic function, provided the builder with an extra 16 inventory slots.

Since the builder needs to move around the map a lot, his running speed was significantly higher than that of combat heroes. However, in direct combat, he doesn't pose a serious threat.

Towers

To influence the towers, I decided to limit the builder’s ability to upgrade the existing towers placed along the road from the start of the game. Eventually, I planned to add the ability to construct new towers and enable towers to use their own spells. However, at the outset, the starting tower could only be upgraded to one of three second-level tower variants: Lightning Tower, Machine Gun Tower, and Plasma Tower.

All three advanced towers have increased attack range, more health, and deal more damage compared to the original tower. Textures from Force of Nature were used for the appearance of these towers, but new models were created. The models were kept relatively simple and temporary since game elements were frequently added and removed. The Machine Gun Tower has a high rate of fire but low damage. Its attacks deal purely physical damage. The Lightning Tower fires more slowly but with greater power, dealing damage that is half physical and half magical. Additionally, the Lightning Tower has slightly more health than the other two. The Plasma Tower deals magical damage. It has the slowest attack speed, but its damage is the highest. I wouldn't say the towers are radically different from each other, but this was the initial setup. To upgrade the starting tower to an enhanced version, the builder needed to approach the tower with all the required resources and rebuild it. During this process, the tower would remain inactive for a few seconds.

Minions

From the start of the game, portals on both sides generate a wave of 5 goblins every 30 seconds. First come 2 defender goblins, then one melee goblin, and finally 2 archers. At any time, the builder can open a special minion management window and set a new wave configuration.

The builder can use gathered resources to construct dens for new minions, allowing players to hire mercenaries from other races using gold. Dens were made available for spiders, orcs, skeletons, and lizards. Despite goblins being available from the start of the game, players also had the option to construct a goblin den. In these dens, players could research upgrades for minions that increased various characteristics specific to each race. Like the towers, the models for these dens were assembled using existing textures. Here they are, in the following order: Goblin Den, Orc Den, Spider Den, Skeleton Den, Lizard Den:

Like goblins, each of the other races also had a defender minion, melee minion, and ranged minion. All units were taken from Force of Nature. Initially, defenders and melee units did not differ significantly from each other – they were both melee units with slightly different parameters. Some had higher attack speed, others more damage, some more health, and others armor. Different races also had different types of damage (physical, magical, poison) and varying defenses against these attacks (normal armor, magic resistance, poison resistance). There were more significant differences among ranged units. For lizards, their ranged unit was the kappa, which spewed a poisonous cloud that dealt area damage and poisoned enemies for a period of time. For skeletons, their ranged unit was the skeleton bomber, which also dealt area damage with bombs. Spiders had a ranged attack from the spider with webbing, whose attacks created webs that slowed down the attack and movement speed of enemies. Essentially, these features were directly adapted from Force of Nature since they were already developed.

In addition to constructing dens and upgrading minions, there was another way the builder could influence mobs. It was decided that the builder could "possess" any mob at any time and control it directly. This required some adjustments to the network code, as in Force of Nature each client connected to the server calculates their own hero and controls it. Calculating the physics of movement, hero actions, spell cooldowns, health, and the effects of various auras and spells – all of these computations are handled on the client's computer. I've already mentioned this in this post. However, the server (host player who started the game and invited friends) handles the calculation of all monsters. To allow builder-clients to control minions, a Star-based interaction system had to be implemented (this system was mentioned here).

Once everything was ready, we began testing the game from the builder's perspective. From that point on, we started recording all our matches to be able to analyze them later and identify any gameplay issues. So, from now on, I'll be documenting my posts with full gameplay videos.

Implementing Heroes

To prevent heroes from interacting with resources, their inventory size was reduced to zero. To allow for gold collection, gold coins were introduced. From the game's perspective, these coins are treated as ammo and automatically occupy the ammo slot. The primary weapon, even if it is something like a bow, does not consume this ammo. The character's clothing slots were hidden and replaced with six slots for amulets. All purchasable artifacts designed to enhance heroes are considered amulets. Even items like "Boots of Mega Speed" are treated as amulets in the game. I repurposed the crafting table to serve as the item shop. This table allows artifacts to be crafted instantly using a single resource: gold coins. The crafting table is automatically created at each base at the start of the game. I had to rework the logic of the crafting table so that after crafting an item (which, according to the new logic, means purchasing the item), it automatically moves to an available amulet slot on the character.

Different heroes should have different sets of skills. I implemented hero selection through a standard skills window from Force of Nature 2. I didn't have to change a single line of code for this. During the development of FoN, I had already implemented the ability to choose one skill from multiple options. I anticipated that at some point, players might face a decision on which development path to pursue. Once one option is selected, the remaining options automatically become unavailable for the rest of the game. Ultimately, this mechanic didn't make it into the final game, but it proved to be very useful in this case. Different heroes are implemented as skills in the development tree, linked by a choice – only one of these skills can be learned, effectively constituting the hero selection. Additionally, from the start of the game, the player is given an extra Skill Point, which they must spend on choosing a hero. The skills of each hero are designed as regular skills in the development tree, dependent on the main hero skill, and therefore available only to a specific hero. Yes, it may not look very elegant, but remember, this is just a prototype. When a hero's skills are learned, these skills are automatically placed into the hotkey slots for spells – there is no need to drag them there with the mouse, as was required in FoN.

When the main hero skill is learned (in essence, when the hero is chosen), this skill not only unlocks the other skills of that hero but also automatically equips the hero with pre-prepared clothing and weapons. The clothing is used to differentiate between heroes. Since the clothing and weapon slots are hidden from the inventory, they cannot be changed later, thereby fixing the hero's appearance for the entire game. As you know, in FoN, there is a wide variety of clothing to create many different looks. I simply added some color to certain parts of this clothing, giving some elements a bright red or green color to make it immediately clear which team the hero is from.

It was decided that for the prototype, three different heroes would be sufficient: a warrior-swordsman, an archer, and a mage.

Warrior

Among the trio, the warrior is the only melee hero. His key strengths are speed and durability. His skills include:

• Critical Strike: The next attack deals increased damage.
• Dash: A somersault towards the cursor. During the somersault, the hero is not affected by collision detection with other units, so this skill can be used to escape from surrounding enemies.
• Sprint: Temporarily increases movement speed. Since this is a melee hero, he needs skills that can quickly close the distance to the target for an attack and also quickly retreat to a safe distance.
• Block: The warrior gains a lot of armor and magic resistance for a short time, making him nearly impervious to enemy attacks. Additionally, during this time, the hero receives significant health regeneration.

Archer

The archer has the longest attack range with both his weapon and abilities. He is quite weak up close, but his skills allow him to harass enemies from a distance:

• Berserk: Temporarily increases attack speed.
• Fan of Arrows: The archer releases a fan of arrows that not only deal damage but also slow the target for a short time.
• Precision: Temporarily increases attack range. This skill allows the archer to stay even further from the enemy, continuing to deal irritating damage. At higher skill levels, the archer can even attack towers while remaining out of their range.
• Fire Arrow: The archer fires a flaming arrow that flies slowly but passes through any obstacles and enemies, dealing significant damage.

Mage

The mage has low base damage, but his main strength lies in his skills, with which he can deal a huge amount of damage:

• Meteor: The mage marks a point where a meteor strikes after a short interval, dealing area damage.
• Electric Discharge: Fires a lightning bolt in the specified direction, hitting only the closest target in its path.
• Flash: Stuns all enemies around the mage.
• Napalm: Throws a fireball that ignites the area for a short time, damaging all enemies in that area.

Testing

Testing showed that the heroes turned out quite successful. Each one's playstyle was significantly different, yet they were balanced well in terms of strength. Some of the heroes' skills were nearly identical copies from games like DOTA and League of Legends, but at this stage, it wasn't a concern, as the goal was to quickly build the MOBA foundation based on the experience of other games. Additionally, many skills were copied from Force of Nature 2, saving development time. In addition to hero skills, I relied on League of Legends and DOTA for many other balance aspects:

• Hero, minion, and tower health ratios and damage
• Attack timings
• Cooldown times and energy costs for spells
• Tower damage and range
• Experience and leveling up speed
• Unit movement speed
• Artifact prices
• Hero strength growth speed as they level up

I also had to tweak the AI of the monsters so that they, like towers, would switch to attacking a hero if the hero behaves aggressively and attacks another hero. In addition, homing arrows were implemented, which cannot be dodged and ignore all obstacles except the target they were fired at. These arrows are fired by heroes (archer and mage) and towers.

In the end, we (me and other testers) quickly managed to achieve the same emotions from the game as from League of Legends (which was the main reference). The hero felt good to control, farming in the lane was dynamic and intense. The price of mistakes was not too high to discourage players from taking risks and trying new things, but also not too low to maintain concentration throughout the game. We quickly started devising different battle tactics, and then counter-tactics against those tactics. Overall, the gameplay was exciting, and there was a sense that I was doing everything right.

I understand that at this stage, the game was simply another DOTA clone, and its value as a game itself was not great. However, it was an excellent foundation for further experiments with the builder.