Force of Nature 2 Dev. Blog

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.

In the comments to the previous post I was told about a problem with asymmetrical gameplay – some players prefer to play only one role and don't want to play other roles, so sometimes it can be difficult to complete a team with a full complement. This is a very serious problem, and later I realized it. But I want to tell about the evolution of my gameplay in order, including all the mistakes I made. I can't say that I didn't see this problem at all, I just had what I thought was a simple solution – when a player queues up to play, he can specify whether he wants to be a hero or a builder (or no matter who). The matchmaking algorithm takes this into account when compiling teams. If suddenly there are so many people in the queue who want to play exclusively for the builder that it is impossible to put them into teams (remember, only one builder is needed for a team), the game offers such players to play 1-on-1 duels without heroes. Similarly if there are too many heroes, only in this case they can even be grouped into teams, just without a builder.

Another important point. Since I anticipated finding the right gameplay through trial and error, I didn't initially consider the current outcome as a finished game. I defined this stage as working on a game prototype. The goal was to ensure that the resulting gameplay would indeed be engaging. And only after finding such gameplay would I start creating the actual game. The prototype was made directly within Force of Nature 2. For this, I created a separate version of the game on Steam, which features a PvP game mode. I didn't focus much on the user-friendliness of this mode, as I planned to develop a separate game for the final version. This new game would only include the essential code from FoN. I intended to create entirely new character models and environments to give the game a distinct visual appearance. However, for now, it was just a separate mode in Force of Nature 2. Incidentally, the code architecture in FoN proved to be quite effective, allowing for easy and rapid addition of various new mechanics that were not originally planned.

Now, let's move on to the implementation of the MOBA + Building idea.

Here's the general plan:

1. Implement the MOBA in its pure form.
2. During testing, balance it to a state where it is enjoyable to play. (At this stage, I am simply replicating the successful experiences of other games.)
3. Add the builder hero.
4. Balance the builder so that his contribution to the team is proportionate to that of regular heroes, making the game even more engaging.

 To implement the MOBA itself, quite a lot needed to be done: 

1. Redesign the map. Place the foundations for bases and towers, and create a road between the bases.
2. Add a portal that periodically generates mobs.
3. Implement mob movement – they should follow the road and attack any enemy they encounter. If they stray from the road, they should return to it and continue their path.
4. Add towers.
5. Implement heroes. Heroes in MOBA differ somewhat in leveling up from what is present in FoN.
   • There should be an option to choose one hero from several at the start of the game.
   • The hero should not be able to gather resources, build, or work at the base.
   • The hero should have unique spells/abilities available from the beginning, which can be leveled up.
   • Upon death, the hero should enter a respawn timer and then reappear at the base.
6. Configure several different heroes.

Map Redesign

I decided to limit myself to just one road (lane) between the bases – for the prototype, this was sufficient. Additionally, initially I had only three testers besides myself, so we usually played 1v1 or 2v2. This lane divides the entire map into two halves, giving each team its own forest for resource gathering.

As you can see, besides metal and stones, there is also obsidian in each forest on the map. However, it is guarded by a neutral tower that automatically shoots at anyone it sees. This makes gathering obsidian dangerous – you either have to destroy the tower or use someone as a distraction to draw fire while the builder gathers obsidian.

Towers

Towers line the road and shoot at any enemies that come into their line of sight. Their behavior is fairly simple: if they don't have a priority target, they scan the area around them every 0.1 seconds for enemies, select one as their priority target, and start attacking. If they already have a priority target, they will continue attacking it until the target leaves the tower's attack range. As in other MOBAs, if the tower is attacking a minion but a hero enters its attack range, the tower will continue targeting the minion and not the hero. However, if a hero starts attacking another hero, the tower will immediately switch its priority target to the attacking hero. The models for the tower were hastily assembled from fragments of existing FoN constructions.

Portal and Mobs

For spawning mobs, I used a ready-made portal model from the tropical world. Implementing the logic to spawn several specific mobs every 30 seconds was not difficult at all. Implementing mob behavior also didn't take much time. The entire lane is divided into several checkpoints. Every second, the mob determines the nearest checkpoint. If it's close enough, it determines the next checkpoint along the path and moves towards it. If the nearest checkpoint is far away, it means the mob has deviated from the path, so it moves towards that checkpoint to return to the lane as quickly as possible. The mob periodically scans for enemies around it, and as soon as it detects them, it begins to attack.

I used monster models initially created for Force of Nature 2 but ultimately not included in it as models for the mobs (yes, I have about a dozen of those).

I'll stop here for now and continue next time.

Let's briefly summarize the main problem at hand: managing a complex entity like a "settlement" requires a significant flow of information, which is difficult to achieve in practice among players who are unfamiliar with each other.

To reduce this flow, we should resort to a time-honored practice: the division of responsibilities. Each player takes charge of one specific aspect of the overall team effort, fulfilling their role. To avoid conflicts, one person should handle resource management, while the others focus on their own character and the tasks assigned to them. In essence, one person on the team is essentially playing an RTS (Real-Time Strategy), managing all resource-related tasks, while the others play an RPG (Role-Playing Game), focusing on operational tasks. The most successful example of team-based combat among RPG heroes is the MOBA genre, which is why I decided to redesign my current gameplay as a blend of MOBA + Building.

I believe most players are familiar with the MOBA (Multiplayer Online Battle Arena) genre, but I'll briefly describe it just in case. In this genre, all players are divided into two teams. Each team has its own base where players can strengthen themselves and recover. Between the bases lies the battlefield where the main gameplay takes place. Each player controls their own hero. The goal is to destroy the opponent's base. Besides the heroes, the base itself actively contributes to achieving this goal. For defense, it uses towers that are present from the beginning and automatically shoot at any enemies within range. For offense, the base generates mobs that automatically march out to attack anything hostile. There are several predetermined paths (lanes) between the bases, along which the mobs travel and towers are placed.

In a MOBA, the base plays a significant role but operates automatically. Therefore, it makes sense to assign one player the role of managing the base. This player, whom I call the builder, should be the only one in each team with this role. The builder gathers resources, constructs and upgrades defensive towers, enhances mobs (and possibly controls them), and produces useful items for the heroes. Meanwhile, the heroes engage in battles, gain experience, level up, and enhance their abilities. Heroes also have different roles – some focus more on offense, some on defense, some on magic, and others on support. The only resource available to heroes is gold, which they earn in battles and can use to purchase upgrades. To avoid resource conflicts, each hero has their own individual wallet.

The gameplay for the builder and the heroes differs significantly. The builder focuses on resource collection and management, as well as overseeing the overall flow of the battle, while remaining relatively safe. The heroes engage in local skirmishes, concentrating on combat tactics. These roles are asymmetrical – is this good or bad? Initially, I saw only positives in this:

• Such asymmetry will distinguish the game from other MOBA titles, which are numerous and often very similar to each other.
• By blending genres, the game may attract a larger audience.
• The game features gameplay familiar to a large number of MOBA genre fans, making it accessible to them with a low entry barrier.

Imagining how the matches will unfold, another example of a custom map came to mind, this time from another cult classic game, Half-Life – the map was called Natural Selection. In this mod, a very similar idea with asymmetrical roles is implemented – one player on the team focuses on base development, while the rest engage in combat. The battles, however, didn't take place in an RPG genre but rather in a first-person shooter genre. This mod was so popular that it even got a sequel in the form of a standalone game, Natural Selection 2. Interestingly, the asymmetry in this game was even more pronounced – not only did different players within one team engage in gameplay from different genres, but the teams themselves also differed significantly from each other.

Well, there's a new idea, new references for other games. This idea does not have the shortcomings that the previous idea had. We can move on!

So, there is a ready idea. This idea was tested as a map for Warcraft 3. This map was interesting to play. Why then after testing it was decided to completely abandon such an idea?

Straight to the point - the main problem is that the game requires too much communication within the team. As I wrote earlier, the genre of this game is essentially real-time strategy. In strategies, our entire base is like one complex "character" that we develop and control. Each building or unit is just a part of one unified whole. And there should be no competition for resources between these parts. When we are going to invest resources in the development of the base, we evaluate the current strengths and weaknesses of this "character". Since resources are limited, we have to choose and consciously sacrifice some aspects in favor of others. The correctness of these choices largely determines the outcome of the battle.

In ordinary strategy games, all these choices take place in the mind of one person who tries to implement some clever idea and thus defeat the opponent. Meanwhile, the situation dynamically changes, and you have to constantly adapt to the circumstances. Let's say you planned a daring raid into the enemy's rear - sail to his base in boats and strike from behind. From the direction where he least expects it. With this strike, you plan to defeat the enemy completely, so you invest all the wood in building boats. But suddenly the opponent starts attacking you, trying to destroy the palisade that protects your base. Wood is also needed to repair the palisade, and now you are faced with a choice.

Perhaps the enemy's attack is not that dangerous, and you should not deviate from your plan to strike the enemy from behind. Or maybe this attack needs to be repelled first, and only then you can return to the boats. There's a lot of information rushing through your head.

But what if there are several players on the team? Who will make decisions and form the main strategy? What if you got the right amount of wood and were about to build a boat, but suddenly you discover that another player on your team has already used that wood to craft a cart because he didn't understand your plan? In regular strategy games, there are modes where you fight in teams, but each player controls their own separate base and collects their own resources, so there's no such problem - everyone implements their own plan.

But what about the Island Troll Tribe map? In it, players manage ONE base and SHARE resources, but at the same time it was interesting to play this map. So, the thing is that all the times we played this map, the whole team consisted of one group of friends. We were all in one audio chat, so we had the opportunity to quickly coordinate our actions. There was a lot of communication - every decision in the game required discussions. From choosing the location for the base to the tactics of conducting individual battles with opponents. Such cooperative work really gives a lot of positive emotions. The trouble is that not every player has a team of friends who are always ready to play. So players simply queue up and the game automatically forms teams from that queue. You can also enter as a group of players into the queue, if your friends currently are free and also want to play with you. As a result, in practice a team often consists of several separate groups of friends, or even single players. And every next match the composition of the team can change. Not all players are ready to communicate out loud with random strangers - some simply do not have such an opportunity (there is no microphone or headphones, or someone else is in the room), and there is often a language barrier. As a result, communication between separate groups of players within a team is reduced to brief messages in chat. But it won't be enough for my game. So, as I wrote at the beginning, the main problem is that the game requires too much communication within the team. Next time I'll talk about how I changed the core gameplay to deal with this problem.