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

Bonus Gold Coin

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

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

Enhancing Combat Capabilities

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

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

Sling Instead of a Pickaxe

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

Spells

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

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

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

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

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

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

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

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

Usability Issues

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

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.

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.

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.

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.

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:

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.

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.

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.

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:

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.

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.

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.

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.

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.

In the next few posts I want to talk about how the gameplay of the new game evolved, what problems I encountered, how I solved them, and why several times I had to make difficult decisions and start development from the very beginning.

Simpsons Warcraft 3 Custom Maps already did it!

From the very beginning of the development, I had a pretty good idea of the gameplay I wanted, because I had already played a similar game. I'm talking about the map for Warcraft 3, which was called Island Troll Tribes. In short, here is the idea of this map. Two teams start in different corners of the island. In each game, all players initially have the first level and a completely empty inventory. First of all, they begin to collect basic resources, such as logs, stones, and choose a place where to set up a base. Then they begin to hunt, chop trees, mine more complex resources, construct buildings that allow them to cook food and produce weapons and other power-ups. By performing certain actions players earn experience and gain levels (in a game that lasts 20-30 minutes players can earn a dozen levels and become much stronger at the end of the game than they were at the beginning). The team needs to become as strong as possible and destroy the opponents' base. In fact, it is a strategy game, except that not a single player manages the entire settlement, but several players. And each player controls one unit.

(an example taken from open access)

More than two years have passed since my previous post. The events that are taking place in the world right now have affected me directly, but I will not speak out on this topic in detail, because not every freedom of speech is possible today. However, I really hope that good will eventually triumph over evil. Good luck to all and a peaceful sky above your heads!

Even though I stopped blogging, game development didn't stop for me. As you can see, the multiplayer for Force of Nature 2 has been successfully released. After that, I had a choice in which direction to develop further. The first, rather obvious direction is the third part of the game. I have a huge amount of ideas for it (also thanks to all those who wrote to me by email and on Discord). In addition to the development of the third part, there was also an idea to implement a team battle with the construction of a base based on FoN2. In each match, two tribes start at different ends of the island, build their settlements and try to defeat each other. The idea was to release this as a separate free to play game and monetize it through in-game purchases, which will not affect the gameplay in any way and will be purely cosmetic. Since I already have a working network code for FoN2, have the opportunity to build a base, fight, level up a character, it seemed to me that implementing such a network battle would not be so difficult. I just need to come up with interesting match rules, and assemble the game from ready-made bricks. The rapid development of such a mode could give me additional funds to better implement all the ideas of the third part of the Force of Nature. Therefore, it was decided to focus specifically on developing a network battle based on the FoN2 code and resources.

In this post, I'll talk about the most difficult task I had to implement: synchronization of the base. This synchronization included building/moving constructions, crafting items with bare hands and on tables, growing and gathering plants, feeding and controlling animals, and interactions with ghosts.

The difficulty here was in a wide variety of closely intertwined mechanics. Synchronization of all these processes had to be done very carefully so as not to break anything. There were significant changes of code and - in order to make sure everything works correctly - I gradually uploaded these changes to Steam (I combined such changes of the mechanic with small updates and with new decorations). Because these changes can potentially break the game, I always try to update in the morning and regularly check the mail/Discord/forum in Steam during the day to see if there are bug reports. On several occasions, there were some bugs indeed, but they were quickly detected and fixed.

Constructions

As I wrote earlier, for multiplayer I had to make virtual images of all locations in order to be able to synchronize environmental objects between players if the players are in different locations. But I didn't have to do this for buildings, because such a scheme has already been implemented for them. Even in singleplayer, ghosts can work with some constructions while the player is traveling around the world, so I needed these buildings to be in memory all the time.

In the last post, I left out one kind of interaction with the environment - damaging objects! I decided to describe it in this post instead because attacks revolve heavily around audio and video effects.

Synchronization of audio and video effects

Let's start with the attacks. The concept of an "attack" in the game is quite complex. Each attack has a lot of parameters - preferred target (what we click on), host of the attack, damage (physical / magical / poison), weapon material, effects (poisoning, slowing, burning, pushing, stunning, etc.). If it's an arrow, then we have to factor in its appearance and flight path; same with a boomerang or fireball. All of these effects do not have a save/load code, because they are not saved when you exit the game. Instead of creating code for writing/reading all possible effects (there are lots of them), I use a simple and logical step - I send only a link to the weapon as an inventory item. 

I've already implemented the sending of inventory items. The attacks of each monster are also already implemented through weapon items (i.e. each monster does not just store the damage it deals, but a link to a full-fledged item which is the same as the sword or spear that our main hero uses). The only exceptions to separate weapons include swamp water, a volcano's vent in the bowels of the mountains, and cannons that guard the pirate boss. For multiplayer, I had to rewrite their code a bit and create a "weapon" for each of them to fix it.

In the past, I’ve described the process of launching the game in Co-op mode and improving the synchronization of players' positioning and animations. Read on to learn more. 

Interaction with the environment

I decided to synchronize environmental objects (i.e. trees, bushes, items lying on the ground, plants that can be gathered, and so on). In general, the synchronization of these objects occurs according to the same scheme:

1. Firstly, we define the entire set of events that can occur with the object. For example, for an item on the ground, this is picking it up and dropping out, for a tree - dealing damage to it and cutting it down, for a plant - gathering it.
2. For each event, it's necessary to create a data packet which includes the indication of the object and the operation on it.
3. Send this packet to all other players.
4. When receiving a packet, resolve an object, an operation, and perform this operation with the object.

For example, since the map is initially synchronized for all players, players A and B both see an apple lying on the ground in the same place. Player A gets closer to that apple and wants to pick it up (clicks on its label or presses LCtrl).

Multiplayer implementation is somewhat similar to the work of a surgeon. I have 2 computers running the game. I need to synchronize each event that occurs on any of them - form a package for it and send it to the other computer, so that this event is displayed there as well. As a result, it's like I'm stitching 2 games together, painstakingly connecting each event. 

Save and load functions play an important role while syncing. I can save the game on the server, and save it not to a file, but to an array of bytes. Then I can send this array to another computer, and load the game from it, as if it was a save file. In such a simple way, I quickly achieved that after starting the game on two computers we see the same world. Even if player on the server managed to cut down a couple of trees before the client connected to it, the client will see that trees have already been cut down, because when connected, the server will send to it a save of the world's current state. However, after both players have loaded the same world, nothing connects them anymore - everyone plays his own game. That's why it's necessary to synchronize all game events further.

Synchronization of heroes

The first thing I synchronized was main heroes of all players themselves. By this I mean not only their position and movements, but also their customization, inventory, weapons in their hands, and so on.

When saving the game, the server began to save all characters' settings, sending them to the rest of the players along with the world files. Also, the server assigns a unique ID to each connected player, by which the players then distinguish each other. Hurray! As a result, all connected players can be seen after the game start. But for now they just stand still and do nothing.

2 Methods of client-server communication

First you need to decide which way to send packages. There are 2 ways: 1) each client sends data packets to everyone else directly and 2) each client sends it's state to server, and then server forwards it to other clients. When there are only two players, there is no difference - in both variants each client simply sends a package with it's condition to the second one. However, when there are lots of players, the situation begins to change. Suppose we have 10 players. In the first method everyone has to send a packet to the others, i. e. 9 packets. Totally, to synchronize the state of all characters on all computers, we need to send 90 packets. In the second method, each of 9 clients will send 1 packet to the server, and the server will send 1 packet with the state of all players to each client, i. e. a total of 18 packets (5 times less than in the first method). But also the delivery time of a package from one client to another is doubled. For the first part of the game I chose the second method as more versatile. However, for the second part I reevaluated both of these methods and came to the conclusion that the first one is better. The maximum number of players is 4, and in this case 12 packages will be sent against 6. However, we'll need to send many other packages - with the states of monsters, buildings, environments, special effects, and so on. So 6 extra packages won't make much difference. In addition, these extra packages completely fall on the clients, not on the server, which in this case is the bottleneck of the system. But the delay in the game will be halved.

By the way, I managed to significantly optimize characters' state packages themselves compared to the first part of the game. If in the first part the full state of the character sent over the network took 166 bytes, now it takes only 26 bytes, i. e. 6 times less. Which is very useful, because in the future I still have to synchronize monsters, which in the second part we have several times more.

The method of communication of each with each is implemented only to synchronize characters' position and animation, where the minimum delay is most important. For most other packages, a centralized scheme was chosen, when all packages pass through the server. This allows to ensure that the order of packages processing is the same on all clients (in which order packets arrive at the server, in the same order it redirects them to clients, and in the same order clients process them). If clients send packets to each other, then their order may be violated. And this can create problems.

Motion smoothing

Just sending a character's position regularly will not be enough. Packets arrive from one computer to another with different delays, even if both are in the same room. As a result, movements of the remote characters are intermittent, discontinuous, not smooth. To get rid of this, I need to smooth out the received data. In the second part I significantly improved the algorithm from the first part - it not only smooths characters' position, but also foresees their movement in advance, based on previous data. As a result, I can get smooth and natural movements even when sending only 10 packets per second (in the first part 30 packets were sent per second).

Synchronization of settings

In addition to the characters' position I had to tinker a little more with the synchronization of their animations. The task is not very difficult - you just need to track the change in your animation and send a new animation to the rest of the players. However, the difficulty was to figure out how to get such control over the animations in Unity. 

After synchronizing heroes I implemented the change of weapons, equipment, inventory, hot slots and all client settings (such as the position of interface windows on the screen, the selected preferred ingredients in recipes where there is a choice, the skill tree, the state of hot slots and much more). There were quite a lot of tasks and they took a decent amount of time, but it doesn't make sense to describe them in detail - they were all implemented according to the same scheme:

1. we monitor changes in something, save these changes to the stream, send it to the server
2. the server stores this state (so that in further game sessions with the same player to send him all his settings)
3. the server redirects to other clients only the part of data that directly affect character's appearance

Ugh! A lot of text. I'll try to describe other tasks in less detail. In the meantime, let's check our ToDo list - since the previous post, the "Synchronization of crafting and building" item has moved to ready tasks:

In the previous post, I wrote a list of the main tasks that have already been done and that still have to be completed. Now I will go through them in more detail.

Lobby

This is where you start a multiplayer game and wait for other players. In general, lobby in the second part is structurally the same as in the first part. Of course, interface design has been changed for the new style. But there is one significant difference. In the first part, you could only run a multiplayer game for an already created world. Therefore, to start playing with a friend, you first had to create a world in a singleplayer mode, exit it and reconnect to it with a friend. At the same time, the friend did not have the opportunity to customize his character specifically for this game. Now you can choose the option to play a new game with a friend, and the friend will be able to set the appearance of his character. This part of the work turned out to be the easiest, since all the code for the lobby is a separate small structure, not connected in any way with the network code of the main game. It was not difficult to think through its architecture at all.

Preparation

The first thing to do when planning multiplayer was to formulate the basic requirements for the result. To transfer packets between players, I again (as in the first part of the game) wanted to operate with the tools provided by Steam. This would allow me not to use dedicated servers or white IP from one of the players. Also, as I wrote earlier, I want to give players complete freedom regardless from each other to move around the game world. This possibility was absent in the first part - it was done for reasons of saving time on development, but negatively affected on gameplay. The main difficulty here is that the world is divided into several locations, which are loaded separately. When exiting a location, the game saves to disk all the changes that occurred in that location while the hero was there, and then unloads the location from memory to free up resources for a new one.

But imagine such situation: there is player 1 (server) and player 2. Player 2 goes to another location and starts to cut down trees there. But suddenly his Internet connection breaks, and he disconnects. Player 1 himself goes to that location, and he should see that trees have been cut down. But who and when will send him information that there are no more trees? The connection with player 2 has already been lost, and at the moment when he was chopping down these trees, the entire location was unloaded from player 1's memory and he didn't know anything about what kind of trees there are at all. 

It turns out that in a network game, the server (player who started the game) must continue to receive changes about the unloaded locations if other players are there. To solve this problem, the server stores simplified virtual representations of all locations, and in real time synchronizes them with real objects that other players see on their screen. Such implicit interaction between players makes it impossible to use third-party ready-made solutions that are available in Unity store, so I decided to write all the network code myself. But it's OK, I already have enough experience! In addition, the code written specifically for the game can be significantly optimized, unlike universal ready-made solutions.

What is already done

 Completed tasks:

• Lobby (the place where players gather in a team to play together)
• Starting the game and setting up the connection between the players
• Auxiliary tools
• Synchronization of heroes (equipment, position, animations)
• Interaction with the environment
• Jumping between worlds
• Synchronization of audio and video effects

The last point is what has been done since I posted the previous post, so here is a new video that demonstrates these possibilities:

I've been busy developing multiplayer lately. There is a huge amount of work to be done for this task, which makes it difficult for me to switch on to other tasks. So, as you may have noticed, this resulted in the frequency of the updates having decreased over time. To dispel any doubts you could possibly have related to the progress and future development of the game, I decided to continue writing updates in this blog. (Seeing as some players had already made claims that the developer had abandoned the game, which is far from the truth.)

After the game released, I published a roadmap for the near future: 

https://steamcommunity.com/app/1316230/discussions/0/3105775765936755410/

It listed the following items:

• Wildlife (done)
• Boomerang (done)
• Mannequin (done)
• WASD control (done)
• Third-person view
• Cooperative mode

As you can see, most of this list is already ready. Only the third-person view and the co-op mode remained.

Third-person view 

This is the only item from the list that was eventually canceled. In fact, a lot of work has been done on this task. A special version of the game was prepared, in which you could tilt the camera and look forward. In the first moments it even seemed that something could come of it. However, the further we tested the game in this mode, the more we became convinced that this view simply does not fit this game.

The first reason is battles. The radius in which monsters begin to "see" the main character is configured in such a way that when enemies appear on the screen (when viewed from above), they can see you and run up to fight, but when they are outside the screen, they cannot. When viewed from a third person, you will notice them at a much greater distance, so you will be able to take your bow and shoot them from a distance while they run towards you.

The second reason is optimization of models and environment. Many models do not have polygons that are not visible from above. For example, the barn model does not have an underside of the roof:

As you may already know, the game is released! Just in case, here is another link to it:

https://store.steampowered.com/app/1316230/Force_of_Nature_2_Ghost_Keeper/

The game was released in a finished state, not in early access. However, this is only because it can be passed from the beginning to the end and is quite stable. The status of "final release" does not mean I will not continue it's further development. The first 2 weeks after release I was busy mainly by following reviews, watching streams on Twitch and YouTube, monitoring the stability, balance, and looking for the weakest points. Now everything has become calmer and I can begin to implement my future plans, which I want to share with you.

Wildlife

To begin with, I want to add one small thing that I planned for a long time, but didn't have time to make it for release - decorative small animals. All sorts of butterflies, mice, small crabs and spiders - they will not affect the gameplay in any way, but will make the world more alive.

Boomerang

The next thing I want to add to the game is a new weapon, the boomerang. It won't have much damage, but it will fly through enemies and damage anyone it hits. As many may have already noticed, the game often has fights with crowds of opponents, so you want to have more diverse weapons that deal AOE damage (area of effect).

Mannequin

Next, I plan to add the mannequin decoration. It will look like a wooden man, on which you can put clothes. In addition, other decorations will gradually be added to the game, without any functionality, but to garnish the base.

WASD control and third-person view

This is one of the most frequently requested features. The task is not easy at all. And not even in terms of implementation, but in terms of design. Firstly, on the later stages of the game, many buttons will be used to control all skills, spells, and the sphere. Placing them all around the WASD buttons will be problematic, but there are a lot of keys on the keyboard, so the optimal solution can be found. Secondly, the ability to look into the longer distance can greatly affect the balance in battles - players will be able to start shooting targets with arrows much earlier than it is possible now, and will be able to hit opponents before they approach the hero. I'll be experimenting with the controls and the camera, maybe making some different control prototypes and testing them. In general, I can't promise that the game will really get a third-person view and WASD control, but I promise I'll work in this direction.

Co-op

This is probably the most popular feature that players are asking for. The cooperative mode will be implemented. A game of this genre simply must have this option. However, I can't specify the time frame for the implementation of the network game yet. I did Force of Nature 1 on my own engine, and the second part on Unity. I haven't yet begun to find out how to work with network in Unity, so I can't tell you about exact time terms. I'll start doing it pretty soon, in a week or two.

Suggestions from players

You can send your suggestions to the Discord server of the game (there is a special section for this).

https://discord.gg/QSzdn3Mu2R

However, as you can see, I already have a lot of tasks, so I will filter the suggestions and implement only the best and easiest to implement.

You can discuss this post on game's Steam forum:

https://steamcommunity.com/app/1316230/discussions/0/3105775765936755410/

The store page is finally ready! Now you can read the description, see screenshots and add the game to your wishlist!

Store Page

The release is scheduled for May 27.

The trailer is also ready. It can be viewed on the store page. However, Steam accepts only FullHD video for the trailer. You can find the trailer in higher resolution (QHD, 60fps) on YouTube.

Lately I tried not to make plans on the game release date, because all my latest estimates were incorrect. 

However, I've already overcome many difficulties, and now I can make forecasts again. 

Let's look at the plan I made in early Autumn:

• finish production chains - done
• put all the content together - done
• walkthrough the game by myself from the beginning to the end and adjust the balance (this point was the longest and took the whole winter + March) - done!
• beta testing - already launched
• final preparation (making game trailer, Steam store page design, etc.) - in process

I already wrote that game balance setup was much more difficult than I thought, and took a very long time. In the process I discovered many tricks that made balance setup easier. If I knew these tricks initially, then, perhaps, this work would have taken much less time. 

At the very beginning of January I decided to launch alpha testing, although initially I didn't intend to conduct this stage of testing at all. At that time the game was set to only 20 percent, and testers had to wait for the next game level setup finished. However, the launch of alpha was justified - bugs were found and fixed, and there were also many ideas that I tried to implement.

At the moment game balance setup is finished. The game is completely ready and can be played from the beginning to the end. The level of readiness now corresponds to the level at which many indie developers usually put the game in early access. Now main tasks for me are: to identify obvious errors in game balance and make all the mechanics as clear as possible for the players. Instead of early access I decided to begin beta testing stage. This stage was launched a week ago. For testing I took players who speak my native language, Russian, as we have to communicate a lot with each other, discuss suggestions, vote for edits, etc. Testing is very productive - I get a lot of good and useful suggestions, most of them I implement, thereby making the game better. 

I'll start making a trailer this week. The biggest problem here is that the music track is not ready yet. However, the trailer should be ready by the end of April. Just after that, the game will appear in Steam store in the "coming soon" section. Steam requires the game to stay in this state for at least 2 weeks. During this time, I will keep making final improvements.

Thus, the game should be expected in the second half of May. 

I think that in the next post I will already be able to show the finished trailer and share a link to the page in Steam store, and you (I really hope so) will add the game to the wishlist :) Also most likely in the next post I'll specify the final release date.

You've probably already noticed that in some screenshots posted earlier, there is a little ghost ball flying next to the hero. In this post I'll tell you more about it.

While game balancing is in process, let's return to the comparison of the first and the second parts in numbers. 

Constructions

Counting constructions we have the same problem with variations as with enemies (as I wrote about in the second part of the statistics review). For example, fences have variations with different lengths - corner, 2 cells, 3 cells or 4 cells. I will not take into account such variations. Also, I will not take into account pathways and pavements, because there is no geometric models for them. I will also not take into account the pocket lamp, although it can be used as a decoration. 

So, in total, in the first Force of Nature there are:

• 4 houses
• 17 buildings for items production (garden beds are also here)
• 8 storages
• 14 fences and decorations
• 5 misc (2 beds, nameplate, teleport, urn)

48 buildings in total.

In Force of Nature 2 many constructions have several upgrade levels. However, different levels of the same table are essentially different tables: they have different recipes and look different. Therefore I will consider such levels as unique buildings. Ready-made dwelling houses (as it was in the first part) will no longer be available. As I wrote in one of the previous posts, houses will now be built from pre-designed elements: a floor, walls, doors, windows and a roof. But I will count all such a set for 1 building. Among the innovations of the second part there will be animal barns, feeders and so on. 

So, complete buildings list in the second part:

• 15 constructions for animals
• 2 houses
• 41 constructions for crafting/mining items
• 6 storages
• 19 fences and decorations
• 11 misc

Total: 94 buildings (almost twice the amount of the first part).

Game development is still in process, so this list is not complete. Maybe, there will be more of them.

Sounds

It was quite difficult to count all the sounds, because there are sooo many of them. And yes, there are variations again. At the same time, large number of variations is very important for sounds. Many sounds such as footsteps, 

or strikes sound very often and regularly. Without a sufficiently large number of variations, the repeatability of the same sounds will be too obvious. When calculating, I conditionally divided all sounds into the following categories:

• steps - steps of different strength on different surfaces
• hits - hits with different weapons on different surfaces
• ambient - all sounds that create location atmosphere. These are sounds of rain, wind, lightning, birds, grasshoppers, creaking of old beams, etc.
• characters - sounds made by different monsters and animals
• constructions - sounds that constructions make while working or when opening their interface window
• interface - buttons clicks, switches, etc.
• misc

Back to numbers:

FON 1

• steps - 8 groups, 40 sounds in total
• hits - 15 groups, 39 sounds in total
• ambient - 19 cyclic tracks (loops) + 5 sounds for thunderstorms. 24 sounds in total
• characters - 20 uniquely voiced characters, 57 groups of sounds. Considering variations - 223 sounds in total
• constructions - 23 groups, total of 35 sounds
• interface - 25 individual sounds
• other - 9 groups, total of 37 sounds

In summ there are 19 loops, 25 individual sounds and 113 groups - total 423 separate sounds.

FON 2

• steps - 23 groups, 208 sounds in total
• hits - 24 groups, 69 sounds in total
• ambient - 40 cyclic tracks + 56 groups of other sounds. Total - 315 sounds
• characters - 35 uniquely voiced characters, 180 groups of sounds. Considering variations - 788 sounds
• constructions - 34 groups, total 171 sounds
• interface - 72 separate sounds
• other - 86 groups, 318 sounds

In sum 40 loops, 72 individual sounds and 403 groups. 1941 separate sounds in total.

It is about 4.6 times more than in FON1 !

P.S. The post turned out to be about numbers, so to decorate it I'll add a screenshot of the battle against spiders:

Upcoming game has thousands of different parameters - crafting recipes, enemy health, the amount of experience required for each level, energy spent when using each weapon, and so on. All these parameters must be specified. But if you set them lightly - just put them down at random, game walkthrough may not be interesting: sometimes too hard, sometimes too easy, sometimes boring and slow. All these parameters should be configured wisely. It was this task that turned out to be the most unpredictable for me in terms of time. At the end of Autumn, when I was just starting to balance the parameters, I was sure that I would be able to do everything in a couple of weeks. So I was confident that the game would be released before the end of the year. But since then, more than 3 months have passed, and the work has been done only by about 60%.

Why so long? I'll explain on the example of weapons setup. 

At some point, player gets access to 3 types of copper melee weapons - a copper sword, a copper spear, and a copper mace. I wanted to adjust their balance so that none of them was noticeably stronger than the others. So that each has its own pros and cons and players are equally profitable to fight using each of them. Melee weapons have the following parameters: animation duration, idle time after impact until next strike, damage, energy spent, probability of stunning the enemy, number of seconds of stun. The same situation as with sounds - you can't set them individually, only as a group at once. And to do this, you need to be able to look at all these parameters for each weapon at the same time.

Tables

In the first part of the game I already faced this problem, and found a fairly simple solution - Google Sheets. In them I entered all the necessary parameters, and also made columns with formulas that helped to instantly calculate such characteristics as damage per second, energy spent per 1 unit of damage, energy spent per second during a continuous attack, and so on. With the help of such a table you can change weapon's main parameters and immediately see how calculated values change. Thus, it's quite easy to achieve that the average damage per second for all weapons is approximately equal. This is how I set up parameters in Force of Nature 1, so the first thing I did was setting up such tables for all objects in the current game: for weapons, clothing, trees, enemies, etc. Setting up these tables is a much more time-consuming task than it might seem. After all the formulas are thought out and set up, you still need to enter all the objects in these tables. And that's hundreds of lines. Very long, monotonous and boring work. Here, for example, is what a table with enemies looks like (and this is only a small part of all monsters):

Uhh.. There was no news for 2 months.

But don't worry. It doesn't mean I'm relaxed and do nothing. Conversely. All I do is work, so it's hard to find the strength even for the next post.

The main thing I've been doing all this time is playing my own game. Along the way, adjusting each parameter - the speed of each enemy, the cooldown of each skill, the volume of each branch crunching, and so on.

It was the volume of the branch crunching that caught my attention the most at the very beginning of my walkthrough - I noticed the lack of sound volume balance. There are thousands of different sounds in the game - hits, crunches, steps, animals, magic, weather, inventory etc. All of them were recorded separately and their volume is random. Therefore, some sounds scream very loudly, creating an unpleasant sensation in the ears, and some are barely audible. The fix is simple - you just need to set each sound to the correct volume. Each... Of several thousands... By the way, it's impossible to consider each sound separately - it must be combined with several other sounds in order to srt up the volume of these sounds relative to each other.

In Unity it's not easy to balance sounds' volume. To change each source's volume you need to pause the game, change the volume value, and then continue the game. Sometimes it is not so easy to detect which certain sound is out of the mix. As a result, setting up each sound takes several minutes. If you estimate roughly the total required time for this, you'll get 5 minutes * 2000 sounds = 10000 minutes = 166 hours = 20 days of 8 hours (if you work without interruptions). Not very good prospect...

To make it easier for myself, I decided to spend a few days and make a mixer panel, which will allow me to adjust each sound directly during the game, without stopping it. 

In the end, that's what I've got:

There are lots of different items in both parts. I will not describe in detail, just give the numbers:

Force of Nature 1:

• resources - 102
• tools - 21
• weapons - 34
• ammo - 12
• clothes - 42
• amulets - 18
• food and potions - 31
• other (maracas, fishing rod, magic chests, pocket lamp) - 6

Total: 266

Force of Nature 2:

• resources - 153
• tools - 39
• weapons - 68
• ammo - 12
• clothes - 92
• amulets - 21
• shields and bags - 17
• food and potions - 39
• fertilizers - 5
• other - 32

Total: 478

I will note that earlier there were many repeating elements among clothes and weapons. For example, there were many similar armor coats, differing only in the color of metal. Swords made of different metals also differed only in color (similarly, many other types of weapons).

In the next posts I will try to compare the first and second parts in numbers. Let's start with enemies.

There is one difficulty in calculating the total number of enemies. Should I take into account all shape and color variations of the same monsters? Or count only unique monster classes? The easiest way is just to give all the numbers.

Let's start with the first part of the game.

So, in total it has 12 enemy classes: Goblins, Golems, Sappers (goblins with bombs), Devils (from the desert), Rippers (ghosts with scythes), Scorpions, Skeletons, Yeti, Bears, Elks, Boars, Foxes. Some of the monsters in the same class have different models. For example, a brown bear and a polar bear have different body shapes, there are several types of Skeletons, and so on. If you count the number of different models, you will get more:

• Skeletons - 5 models
• Goblins - 3 models
• Bears - 2 models
• Golems, Sappers, Devils, Reapers, Scorpions, Yeti, Elks, Boars, Foxes - all of 1 model

Total: 19 different enemy models

Almost all monsters also have color variations, for example, goblins inhabit different locations and have different colors. If we take into account all such variations (i. e., all different enemies that are generally in the game), then it will come out like this:

• Skeletons - 5 models * 2 colors = 10 variations
• Scorpions - 5 colors * 2 types (melee/range) = 10 variations
• Goblins - 3 models * 3 colors = 9 variations
• Golems - 4 variations
• Rippers - 3 variations
• Bears - 3 variations
• Devils - 2 variations
• Yeti - 2 variations
• Sappers, Elks, Boars, Foxes - 1 variation each

Total: 47 different enemies, although many of them are very similar to each other.

So, in total the first part contains:

• 12 enemy classes
• 19 different models
• 47 different variations

I will not list all the enemies of the second part of the game, just give similar numbers. In total it will contain:

• 27 enemy classes
• 50 different models
• 102 different variations

If we compare domestic animals, then:

There are 6 animals in the first part (each represented by a single variation)

In the second part - only 4 animals, but 2-3 color variations each - 10 unique variations total

Yes, there are fewer types of domestic animals. But, in fact, the goat and the cow in the first part brought the same resource (so I decided that the goat could not be included), and the pig had a little more benefit than zero (as I wrote earlier, I did not want to force players to kill peaceful pigs).

Besides that, in the first part there were rabbits and penguins. But in the second part there will also be some peaceful characters. And it will have bosses as well!

Another important feature worth mentioning. In the first part all enemies were purchased. By the way, it is the only thing in the game that was bought - everything else (buildings, trees, stones, resources, weapons, clothes and the main character) I drew myself. In the second part there is almost no purchased content. All monsters are unique and were made specifically for this game - you will not find them anywhere else in other games. Even the ones that were in the first part were redrawn to have a unique look.

In this post I will talk about one of the biggest game innovations - ghosts.

I already mentioned earlier that there will be bosses in the game. By killing them, you will release their souls, which will then exist in the form of ghosts. You can talk to ghosts. Some of them have unfinished business, which they will either tell you directly about, or hint at, if you ask them carefully.

So, the summer is over and the game isn't ready yet. Although in the spring I supposed everything would be different. Let's figure it out.

Almost everything that was supposed to be done by the end of the summer has indeed been completed. Absolutely all monsters and bosses are drawn and, most importantly, animated. I had the most doubts about the animation of monsters and bosses, but we did it. Quests and storyline are also ready. Some dialogs are still going through the final editing stage, but it doesn't take much time. Weapons, equipment, clothing - everything is ready for battle. All main buildings are also ready. 

Character leveling system in the second part was completely redesigned.

Previously, levels were not a player's achievement, but simply stages of game walkthrough. Many players didn't like that getting new levels required completing quests (which limited players' freedom) and that the availability of buildings and recipes depended on it. Now character leveling up and rising through stages of technological progress don't depend on each other.

Fighting monsters, the player gains experience. Having accumulated a certain amount of experience, the player gets a new level. With each level obtained, the player also receives several skill points. He can spend these points to increase his health, stamina, accuracy and other attributes. Also for these points you can learn several active skills, such as sprints, dash, block pose, etc., and some magic techniques. There are 19 attributes and skills in total.

As in the first part of the game, some constructions can only be placed inside the house. However, the way of house building is now completely different. Now there will no longer be ready-made houses, such as a hut or a dugout.

The house will now need to be assembled from parts - floor, walls and roof. You can decide for yourself what size the house will be, what rooms will be inside.

In this post I'll tell about some details of character's inventory development.

Graphic style of item icons

We've done a huge work to create our own style for item icons. Firstly, I wanted icons not to look soulless, as it often happens when using screenshots of 3D models of items. Secondly, I didn't want a high level of realism, as it was in the first part of the game (I took photos of real items for icons there). Thirdly, I didn't want to go to another extreme - cartoon-like images. Also, icons should be easily recognized in small size - you can draw a beautiful detailed object image, but when you reduce its size to fit into the inventory cell, all its details turn into an illegible chaos of pixels. In search of the needed style we tried many different ways of drawing the same objects.

Character animation is quite a difficult task. There are many minor movements in the shoulders, pelvis, torso turns, etc. We don't pay attention to them, but if they are absent, the character starts to move like a robot.

Not having a lot of experience in character animation, but having the need for a large number of them for the first part of the game, I resorted to homemade motion capture technology. For this I used  Microsoft Kinect sensor, which was designed for XBox 360, but can also be connected to a computer. This sensor uses infrared scanning to obtain a depth map and is essentially a low-resolution 3D scanner. On XBox, the sensor can detect player’s positions very approximately, but in real time. For PCs, there are special programs (I used iPi Mocap Studio) that allow you to record video, and then to extract human movements more accurately. All animations of the main character in the first part of the game were made in this way, and it took me only a couple of days. Main time was spent on manual cleaning of captured animations. Since the sensor can capture only from one side, sometimes when the body turns, hands can be hidden from the sensor by the body itself or by the head, so their position is not detected and has to be set manually. In general, I was very happy with the result. Although the quality of animations is not at a high level, I would have done much worse with my hands and spent much more time.

Since the quality bar for the second part of the game has risen, I wanted to make animations better. To do this, I decided to use two sensors to record animations. In addition, I decided to buy new, more modern ones - Microsoft Kinect 2.0.

6. Buildings

Most of the buildings are already finished. But here I proceed from the principle of the more is the better. I plan to add lots of more decorative buildings. It takes quite a long time to create them, but we put our heart and soul into them. We try to think through the mechanism of their functioning and work out all details. Here, for example, is a jeweler's table:

In this and in the next posts I will tell you point by point about the current progress of game development. I will describe what is ready, what remains to be done, and give my estimates for the remaining work.

1. Programming

The game code is almost completely ready. It remains to script all bosses and a couple of minor quests. The rest of the game is already fully playable.

2. World and environment

All game locations are already finished. The game has 5 main biomes plus some additional locations and 4 types of dungeons. Map generation algorithms have been significantly improved since the first part of the game. Now the way to the goal won't be as straightforward as before. You'll have to explore locations to find the right way. Here is a screenshot of swamps - one of biomes I wrote about earlier:

I try to make all game aspects at the highest possible level. This also applies to the game sound design.

In the first part of the game I recorded sounds on a fairly inexpensive condenser recorder Zoom H4n. This recorder has its own low level noise, inappreciable when recording loud sounds. However, if you record quiet sounds - clicking seeds, taking an object from inventory, bones tinkling, etc., this noise becomes noticeable. I had to process recordings with a noise reduction filter, and this notedly decreased the final sound quality. Despite this, sounds recording is a very exciting process. I looked for sticks and stones on the street, broke and threw them, recorded individual sounds, and then assembled from them the sounds of different breaking structures.

To improve the sound quality in the second part I decided to improve my equipment. I did not want to buy separate microphones, stands, a recorder (a complete set for professional sound recording). I just decided to replace my rather cheap voice recorder with the recently released Sony PCM-D10 - an updated version of the Sony PCM-D100. This recorder was called the best in quality on many forums. I had to wait half a year for this recorder to appear in my region. However, the recording quality upset me greatly. It was no better than my old Zoom H4n. I made a test recording and compared signal spectrum.

Animal breeding has been slightly changed compared to the first part of the game.

The full list of domestic animals at the moment is as follows:

• Cow
• Sheep
• Goose
• Chicken

Building system has undergone some changes compared to the first part of the game.

As before, building can be done only within markup grid. A special window in the corner of the screen shows how many resources you have for the selected construction. This is useful if you build a lot of repetitive elements, such as fences.

In the first part of the game user interface was not very convenient. Many windows replaced each other, which distracted attention.

Now I tried to fix this problem. To begin with, the design itself has changed. The asset RPG & MMO UI 6 from Unity Asset Store was taken as the basis, but after it was significantly redone to fit my own needs. Windows can now be moved around the screen. Windows' header has an interesting animation. For example, this is how the main character’s inventory window looks like:

Many times I've been asked to add a female character to the first part of the game. But adding a new character means not only to draw it, but also to fit all the clothes to it. This is quite a bit of work. Therefore, I never added a female character to the Force of Nature 1. But now I collaborate with artists, so I can afford to realize every element of clothing in two versions - for male and for female.

So raise your thumbs up! Force of Nature 2 will allow you to choose the gender of the character.

This is how these characters look like during customization:

The swamp is another biome that I had to implement. The difficulty here, as always, is to generate its procedurally using algorithms, rather than drawing by hand. There were no problems with generating the landscape and placing the vegetation - the algorithms that I used before to create other biomes worked fine here. But I couldn’t make the surface of the water look like a swamp.

In one of the locations there is lava.

First I bought the ready material of lava in the Unity Asset Store. However, the situation was similar to the situation with the purchased water material. The purchased shader was not optimized and it was very difficult to improve it, because its code is completely unreadable and full of such lines as

      float4 break770 = ( i.vertexColor / float4( 1,1,1,1 ) );

      float4 lerpResult904 = lerp( lerpResult903 , appendResult898 , temp_output_1000_0);

      float4 break967 = appendResult876;

      float4 appendResult965 = (half4(break967.x , break967.y , 0.0 , break967.w));

As if someone specifically wanted to confuse me.

So I decided to write a similar shader from scratch. Armed with textures from the purchased asset, I quickly managed to make a pretty good lava:

In this post I will tell about what has already been done and what is to be done.

The "coding" part of the game is almost complete. All basic systems are ready - the movement system, physics, interaction with objects, building, crafting, repairing, clothing, weapons, AI, fights, saving and loading, game settings.

Compared to the first part of the game, the user interface has been completely redesigned - it has become much more convenient and I will tell about it separately in the future.

Now I'm mostly busy filling the game with content.

The game will have 5 main locations. As in the first part of the game locations will be very different from each other, some will be hot, other - cold. At the moment 4 locations are ready. By the end of the year I hope to finish the last location.

I add buildings and resources in parallel. Now only about 15% of them are ready, but thanks to new artists, they are added quite quickly.

I still have to:

• add enemies - now they are only in the first locations, and I have not yet begun to make bosses
• customize storyline and dialogues
• make cut-scenes
• add magic
• add sounds
• add music

... and many more little things.

As you can see, there is still plenty of work to do. But I hope I can handle it pretty fast.

Like the first part, the game will first be released only for single player. For the first couple of months after the release, I'll be busy mostly just supporting and adding some small new features. Then I plan to implement a co-op walkthrough. Since the second part of the game is much more difficult in technical terms, then I think it will take not less than half a year. After the co-op, I plan to make a big DLC that adds new locations, monsters, resources and buildings to the game. After that I want add the PvP mode and VR version of the game.

I created the first part of the game completely by myself. I was engaged in programming, drawing, modeling, animation, voice acting, music. My friends helped me with the testing, and the fans helped me translate the game into different languages.

Most of the second game I also developed alone. However, I realized that I want to add a lot of different content to the game and I can’t do it alone. Plus, the first part of the game brought me some money that I could spend on several assistants.

I have already worked in large companies before and have experience working with other people. However, until that time, I had not yet had occasion to manage the project or to engage in staff recruitment. I admit, the process of searching people turned out to be much more complicated than I thought. It took a lot of time and effort. As it turned out, each artist has his own strengths and weaknesses. And to understand his features, it is not enough to give the artist one test task - you need to work a little with him. And you should to figure it out if you want to form a balanced team of a small number of people.

Now I am collaborating with three 3D modelers, one 2D artist and one other person helps me with the documentation and design of the progress tree. At first, I had absolutely no strength and time for programming, all my attention was spent on putting artists in the course and agreeing on the style. However, now I can implement a full-fledged content creation process - from sketch to final model.

A* Pathfinding Pro

Path finding is an important component of artificial intelligence, which allows monsters to run from one point to another bypassing obstacles. There are 2 main approaches to finding a path - mesh-based and grid-based. Unity has its own pretty good mesh-based algorithm. However, such algorithms have several disadvantages. Mesh-based approach is universal and well suited for complex maps, with overlapping layers and bridges, but it is more difficult to adapt to a frequently changing world. In addition, the data structure in this approach is able to operate only the monsters of the same size. If the game has creatures of different sizes, then you need to generate and maintain a data structure for each size. Grid-base algorithms are more predictable and are easier to control. They easily adapt to changes in the map, but handle only one layer (it is difficult to use them for multi-level maps). For these reasons, RPG and strategy games commonly use grid-based algorithms. Therefore, this is exactly the algorithm I wanted for my game, which means that the built in path-finding did not work for me.

The most reted algorithm in the Unity store is A * Pathfinding Pro. Having purchased it, I first studied its code. It turned out that this algorithm does not use memory very efficiently and is poorly suited for large locations. Having contacted the author, I got more accurate data - in order to store a grid for a map of size 1000 by 1000 (the approximate size of locations in my game), the algorithm will need about 400 megabytes of memory. In the end, I developed my own solution for pathfinding. I took the algorithm from the first part and rework it significantly. I am very happy with the result - the data structure is very compact and supports monsters of any size. And it is several times faster than A * Pathfinding Pro. I can’t say that A * Pathfinding Pro is bad. It was simply designed to be as universal and easy to use. My algorithm, although it turned out to be quite optimized, is not very easy to use. However, it allows me to process hundreds of enemies at the same time, and I also have complete freedom in it, since this is my own code.

Screen Frost FX

For the effect of cold, I used the Screen Frost FX asset. This asset offers a nice animated effect of covering the screen with frost and also contains a good sound effect. However, the animation is implemented by simple frame-by-frame playback of individual generated images. To play this effect, it is necessary to keep 64 textures of 512 by 512 pixels each in video memory. Specially for this effect I wrote a small program that analyzed all the frames, and for each pixel determined the graph of its animation and approximated this graph with a function with 4 parameters. To play the animation of this effect, I also needed to write a small shader, which is able to restore the color of each pixel using the 4 function parameters and frame number. However, this allowed me to reduce the number of required textures of size 512 by 512 to 2 - the final color of the effect in one texture and the function parameters for each pixel in another.

Amplify FXAA

Antialiasing is a software technique for diminishing jaggies - stairstep-like lines that should be smooth. There are a lot of different assets in the Unity Store that provides this filter. I started from Amplify FXAA (Fast approXimate Anti-Aliasing) because it is free and is high rated. I was totally satisfied by the result for a long time.

CTAA

I read about the CTAA (Cinematic Temporal Anti-Aliasing) from one article that compared differet antialiasing techniques. It is a preaty expensive asset, but it was on a 50% off sale so I decided to check it. It took some time to adjust the parameters, but the result exceeded my expectations. The smallest details are now distinguishable.

Using ready solutions (assets) in Unity helps to save a lot of time. In the Asset Store you can buy models, sounds, animations, scripts and much more. There are tons of assets, but basically it is all a product of extremely low quality. Today I want to talk about which third-party assets I happened to encounter, which ones I ended up leaving in the game, and which ones I had to rework.

MicroSplat

Standard terrain material in Unity uses the simplest way to blend textures. There are solutions for blending textures using heightmaps, which makes the transitions between textures more natural. 

At one point in the game, the hero travels through the canyon. Creating procedural generation of cliffs of the canyon turned out to be quite an interesting task.

First, I sculpted a shape from clay. It took more than 10 kilograms of sculptural clay. I tried to convey the layered structure of the Grand Canyon. It was decided to make only three layers. I looked a lot of photos of the canyon and highlighted some interesting references.

Unity

It turned out that the C# language is very well suited for interacting with the external development environment. Unity uses pure C#, without any changes, and supports all its features, including the most modern. Native lambda expressions, events, and enumerators can save a lot of time. But how Unity adapted the embedded enumerator mechanism to create coroutines — emulation of the parallel code in one thread, at first seemed like some kind of magic for me. As a result, a person who knows C# needs exactly 1 day to start writing code for Unity. Also, the terrain system supports any changes in real time. In a month and a half I managed to do much more than in Unreal. Therefore I decided to stay on Unity. And since the first part of the game was written in C#, I could use pieces of code from it without any changes.

After two years of using the engine, I better understood how the engines work in principle. To form a picture, all the engines have a chain of methods - Rendering Pipeline. Both Unity and Unreal provide the opportunity to customize this chain. Only the default settings differ. For Unreal these default settings are designed for powerful hardware and for Unity - for mobile devices. However, you can always reconfigure Unreal for mobile devices or Unity for maximum graphics. Yes, for Unity this reconfiguration is not quite simple - it is not just a set of sliders and toggles. Some filters you should install separately and some you should buy or write your own. The initial feeling I had that games on Unity have worse graphics was caused by the reason that Unity has a much lower passing threshold, which has led many inexperienced users who are not able to adjust the graphics and use the default settings. However, there are also experienced teams that make beautiful games on Unity.

So I can officially declare that if the graphics in Force of Nature 2 is bad, then this is not because of Unity, but because of my crooked hands.

Since this is a development blog, I will talk quite a bit about technical issues.

Game development began from the choice of a game engine. I didn’t use any engines before and I had no idea how they work. After reading several overviews of game engines, I realized that now the most popular are Unity and Unreal Engine.The main difference between these engines is that Unreal is completely based on the C++ programming language, and Unity, although written in C++ itself, uses the C# language for user code and scripts. I programmed in both languages before, but much more in C#. The first part of the game is 95% implemented in C# and only 5% in C++. I also looked the list of games developed on these engines and noticed that games created with the Unreal Engine look more beautiful and modern. Also in the list of Unreal games there are many really big and high-quality AAA projects, such as ARK, Fortnite, PUBG, Batman, Gears of War, Street Fighter, Tekken, Warhammer and other.

Therefore, initially I chose Unreal Engine for Force of Nature 2. It seemed to me that Unreal is for good and high-quality games, and Unity is for beginners.

Unreal engine

It is very good that modern engines use such a financial model that you can start using them absolutely for free.

I spent a month and a half learning the basics of the engine and creating a test project. It is really easy to achieve beautiful graphics in it. The just created project has by default good settings for graphics, lighting and high-quality screen effects. It makes almost any scene look good. In addition, the engine by default offers a number of beautiful particle effects, such as fire, smoke, sparks and explosions. A good shader is also included for grass and plants, giving the vegetation nice wind animation.

Then I went into programming script and map generation. It turned out that writing your own code for Unreal is very inconvenient. C++ is a very powerful language, but the mechanisms it uses for integrating with external development environment are outdated. But it is precisely the interaction of user code with the engine that takes up the bulk of programming. You have to constantly decorate your code with macros, which greatly reduces its readability. Unreal Engine uses its own garbage collection, which is not provided by the C++ language itself. This requires the developer to use special arrays and lists. As the result you are not using pure C++, but a modification of the language - Unreal C++, which has lots of features and nuances that you need to know and understand.

I was also surprised that the standard terrain tool does not support real-time creation and modification from code. It was a big problem for me, because my game uses procedural level generation. Of course, Unreal provides complete freedom to create your own tools, and you can make your own terrain with blackjack and ho with all the necessary functions. And you can also get used to the language. But I decided to spend another month and a half and figure out the Unity engine.

Welcome to the Force of Nature 2 development blog!

My name is Artem. I've been developing the second part of the game since August 2017 - i.e. already 2 years. Now a lot of work has been done, so I can make predictions about the date of release. I think it will be in the spring of 2020.

In this post I'll tell you why I decided to make the second part, and not update the first game. Yes, the first part of the game really has many drawbacks - balance, control, user interface, outdated graphics. I'd like to fix all of this.

A little history of the creation of the first part of the game.

To begin with, I made a big mistake by deciding to make the game from beginning to end by myself, without using game engines. Initially I did not even think that I will sell this game. I was interested in diving into the study of the mechanisms of the game engine and creating everything with my own hands. I started development in August 2011, exactly 8 years ago. Then it seemed to me that I would finish everything in 1 year. The game was released in December 2016. It took a lot of time to develop physics, animation, sound processing, resource management, artificial intelligence of monsters, user interface and more. In addition, the level of all these systems did not reach modern standards. The render distance is very small, the sounds lack reverb and other effects, the user interface has few tools for aligning elements, and so on. Finally, I completed the game. And I would like to add tons of new content to it. But adding each new feature took too much time, because every time I had to edit my engine, add new functions to it. In addition, I watched a lot of streams on my game and realized that I made some mistakes in the game design. In the end, I decided to take the popular game engine and create a new game from scratch.

In the second part of the game will be:

  - Caves and Dungeons

  - Bosses

  - NPC

  - Magic

  - A story with multiple endings

For 2 years of development, I made everything that was in the first part, and even more. The game has changed a lot. Probably the most noticeable of the changes is the camera. The game now has an RPG game format. The player is always in the middle of the screen, and the movement and attack are controlled with the mouse. Since the game is a mixture of RPG, strategy and farm genres, this format justifies itself.