Entry 50 - New Map

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.


Read More 2 Comments

Entry 49 - Interaction Between Builder and Other Players

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.



Read More 0 Comments

Entry 48 - Evolution of Builder

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.



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:


Read More 0 Comments

Entry 47 - Implementation of Builder

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.



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.


Read More 0 Comments

Entry 46 - Implementation of MOBA. Part 2

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.


Read More 0 Comments

Entry 45 - Implementation of MOBA. Part 1

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.


Read More 0 Comments

Entry 44 - MOBA + Building

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.


Read More 4 Comments

Entry 43 - Communication

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.


Read More 0 Comments

Entry 42 - First Version of PvP Mode

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)

Read More 0 Comments

Entry 41 - Back to Blogging

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.

Read More 6 Comments

Entry 40 - Multiplayer. Synchronization of Base

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.



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.


Read More 6 Comments

Entry 39 - Multiplayer. Effects and Locations

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.


Read More 4 Comments

Entry 38 - Multiplayer. Environmental Interaction

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).

Read More 2 Comments

Entry 37 - Multiplayer. Main tasks. Part 2

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:

Read More 1 Comments

Entry 36 - Multiplayer. Main tasks. Part 1

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.



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.

Read More 2 Comments

Entry 35 - Multiplayer



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:

Read More 6 Comments

Entry 34 - Roadmap 2

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: 


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:

Read More 6 Comments

Entry 33 - Roadmap

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



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.



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.



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).



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.



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).


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:



Entry 32 - Store Page and Trailer

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.

Read More 21 Comments

Entry 31 - Progress Review 3

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.


Entry 30 - Magic Orb

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.

Read More 9 Comments

Entry 29 - Statistics. Part 3.

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



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.



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:



  • 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.



  • 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:

Read More 7 Comments

Entry 28 - Game Parameters Balancing

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.



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):

Read More 5 Comments

Entry 27 - Balancing Sounds

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:

Read More 11 Comments

Entry 26 - Statistics. Part 2. Items

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).

Read More 21 Comments

Entry 25 - Statistics. Part 1. Creatures

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.

Read More 5 Comments

Entry 24 - Ghosts

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.

Read More 9 Comments

Entry 23 - Progress Review 2

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. 

Read More 11 Comments

Entry 22 - Leveling System

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.

Read More 8 Comments

Entry 21 - House Constructor

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.

Read More 9 Comments

Entry 20 - Inventory

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.

Read More 7 Comments

Entry 19 - Animations

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.

Read More 7 Comments

Entry 18 - Dev. Progress Review. Part 2

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:

Read More 10 Comments

Entry 17 - Dev. Progress Review. Part 1

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:

Read More 5 Comments

Entry 16 - Sound Effects

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.

Read More 9 Comments

Entry 15 - Domesticated Animals

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
Read More 18 Comments

Entry 14 - Building

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.

Read More 9 Comments

Entry 13 - User Interface Changes

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:


Read More 7 Comments

Entry 12 - Character Customization

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:

Read More 4 Comments

Entry 11 - Creation of Swamp

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.

Read More 1 Comments

Entry 10 - Creation of Lava

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:

Read More 3 Comments

Entry 9 - Roadmap

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.


Entry 8 - My Team

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.

Read More 5 Comments

Entry 7 - Third Party Assets. Part 3

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.

Read More 2 Comments

Entry 6 - Third Party Assets. Part 2

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.



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.

Read More 3 Comments

Entry 5 - Third Party Assets. Part 1

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.



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. 

Read More 6 Comments

Entry 4 - Creating of Сanyon

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.

Read More 4 Comments

Entry 3 - Selection of Game Engine. Part 2


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.

Read More 2 Comments

Entry 2 - Selection of Game Engine. Part 1

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.


Entry 1 - Force of Nature 2 Dev. Blog

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.

Read More 27 Comments