Force of Nature 2 Dev. Blog

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.



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



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


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



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

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



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

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



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

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



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

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

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


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


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


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.



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



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




Portal and Mobs

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


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



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


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.



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


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

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

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



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


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.



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


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


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


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)


Overall the description is very similar to survival games where you build your base. Therefore, this is exactly how I imagined a team battle mode that I could implement on the basis of FoN2. All the necessary mechanics have already been implemented, many resources, buildings, weapons, clothing, food are already available, the network code that allows multiple players to play the same game is also ready. Then what's left to do?

  1. Divide the players into 2 teams. Players must be able to attack players from the other team. Players should also be able to attack the other team's buildings and not be able to use them. Research conducted on the science tables should not be revealed to the enemy team.
  2. Rework the camera. When several people are playing, a lot of things can happen at the same time. To make it easier to control what is happening, the camera should not always be attached to the hero and the player should be able to look around the base and the surrounding area.
  3. Implement fog of war. If you implement a free camera, you also need to make sure that teams can hide their actions from each other.
  4. Prepare the map. The location where the events take place should be compact enough so that the teams can interact with each other. At the same time, the map should contain all the resources necessary for crafting and building.
  5. Rebalance crafting and building. Each match should take 20-30 minutes. During this time, players should have time to develop their settlement from scratch. For this purpose, many crafting chains and recipes should be significantly simplified, and the time intervals for production and resource mining should be reduced by an order of magnitude. Some mechanics should probably be abandoned altogether (such as taming animals and growing crops).

Although the list looks quite impressive, it took me about a month to implement it. The technical part (the first three points) was the easiest and was completed in just a couple of weeks. The whole map at that time consisted of one small island, similar to the first location from FoN2. However, this island also contained small patches of a tropical biome with ferns and bamboos. All available metal was limited to copper. Growing crops, taming animals, changing day and night, temperature and weather changes were completely removed. The pick and axe were combined into a single weapon. Experience was given for destroying rocks and trees.


Next, the testing began. Unfortunately, at that time I had not yet recorded full battles, so I only have small fragments that show the free camera and the fog of war.


Almost immediately it became clear that this kind of gameplay has a lot of drawbacks, and if you want to make a really interesting game, you will have to change a lot of things. I'll tell you about this next time.


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.


Yes, you probably guessed that things didn't go according to plan. The challenge was to come up with an interesting gameplay that would allow matches to be played again and again without loss of interest, even for the losing team. I think many might laugh at my words. Is it really that hard to come up with interesting gameplay? After all, almost everyone has a picture of a super game in their head that would be very interesting to play. I had such a picture in my head too. In addition, this picture was even supported by real positive gaming experience. But as this picture came to life, I was faced with a cruel reality and realized that most interesting ideas in practice are broken by many pitfalls.


In future posts, I will describe in more detail about the entire path I have overcome. For now, I'll just summarize that after many iterations, I've arrived at a completely unexpected gameplay that has almost nothing to do with the original idea. Moreover, the game I'm currently working on has nothing in common with FoN2 - neither in terms of lore and setting, nor in terms of reusing code, models or animations. This is a completely new game. In three words it can be described as “MOBA without gravity”.


Now I have a finished prototype that is really fun to play. However, for full implementation, I still have a lot of work to do - setting up databases of player accounts, configuring servers, working on network code security, protection against cheating, implementing a large number of heroes and their abilities, balancing parameters and much more. For this I have to reassemble the team, because most of the people who worked on FoN2 have already left for other projects. At the moment me and a couple of other people are working on a trailer to get on Kickstarter and raise more funds for further development. I will tell you more details in the following posts. I have quite a lot of stuff that I would like to share, so I will try to post once a week.


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.



Therefore, data on everything built by the player (i.e. position, state, items inside, etc.) is constantly stored in the computer's memory within virtual copies of all constructions. This data storage architecture turned out to be very useful when implementing multiplayer. Because the image of each building is already in memory (even if the location itself with this construction is not loaded now), and each construction has an unique ID, this greatly facilitates synchronization; everything works exactly the same way as with the objects of the environment (bushes, stones, and items on the ground). The only difference is that, instead of virtual worlds made specifically for synchronizing environmental objects, I use virtual worlds made for ghosts. Therefore, the opening/closing of windows and doors, changing the mannequin's poses, and the inscriptions on signs and portals were all implemented quite quickly.


Chests and other storage units caused far more trouble. I had to significantly refine the system of resolving collisions between players' actions to avoid, for example, such situations: several players simultaneously click on an apple in the chest and it goes into everyone's inventory. Now, this system can also resolve conflicts of territories. For example, if two players want to build a construct on the same piece of land at the same time.


Crafting and building

All crafting takes place on the server computer. Clients process only their own manual crafting. Everything that happens on the tables, building of new constructions, growth of plants on seedbeds, etc. is processed by the server. I had to completely redo the way of measuring time intervals for crafting. In singleplayer, when we teleport between worlds, the whole game is paused; time stops and all crafting freezes. In multiplayer, this behavior is unacceptable because if the server player teleports to another world and is currently loading another location, other players should still see that crafting on the table continues. There was also a lot of work with resolution of conflicts. Conflict resolution was especially difficult when using tables with built-in storages and when planting on seedbeds with the use of fertilizers that lie in a fertilizer storage. The difficulty here is that one player can start crafting from items that are on the table and, at this moment, another player can take some resources from this table into their own inventory. Additionally, if one player plants flora with fertilizers then the other player takes these fertilizers from the storage. These tasks are not very difficult, but I had to think a lot on taking these possible scenarios into account.



These two videos demonstrate the synchronization of using constructions, crafting, and building:


Feeding animals and controlling ghosts

Synchronization of feeding animals was even more difficult, especially automatic feeding when the animal itself eats from the trough. In addition to resolving all possible conflicts with the animal itself and the trough's inventory, I had to take into account the ability of the animal to reach the trough. Troughs are designed in such a way that if animals don't have direct access to them, they will not be able to take food from there. And again, this becomes a problem if the server player is in another location. In singleplayer this was not a problem; the availability of the trough could not change while the player was in another location. Therefore, when the player changed the location, each animal simply remembered the list of troughs to which it has access. In multiplayer, availability can change. While the server is fighting monsters somewhere in the swamps, the client can open some gates and make the trough available. All such moments require additional synchronization.


Ghosts had the apotheosis of various mechanics interweaving; their synchronization was the most difficult moment in the whole game. Ghosts are characters, so their animations and position need to be synchronized. They also participate in crafting, they can be controlled, you can talk to them, they have their own settings (priority of work), they can interact with the story and progress, have scenario items in the pouch, etc. Ghosts are the only characters in the game, besides the main character, who can move around locations. Individually, these tasks would not be difficult, but here they all occur in one character. Therefore, when synchronizing each individual ability of the ghost, I had to keep all of their other abilities in mind so that everything worked smoothly. All of this took about two weeks and a lot of my nerves.



Now, the good news. The list of tasks I gave earlier has already been fully implemented. The last thing added to it was the synchronization of monsters, bosses, scenario events, and the magic sphere. There is still one point I forgot to include in the list initially: synchronization of the minimap. In addition, I'm going to record a new trailer that demonstrates multiplayer capabilities. The game will need to be thoroughly tested and perhaps its balance will be slightly changed for several players.


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.



To synchronize the flight of an arrow, stone, needle, dart, fireball, etc., I don't transmit the position of these items for every frame. I calculate the parameters of the equation of the parabola along which these items will fly, and transmit only these parameters. Other players, having received them, can easily launch the ammunition along the same trajectory. However, the other players’ client doesn't try to determine the collision of the item with anything. It simply moves the arrow along the parabola until it receives a signal from the first player that the movement should be stopped and the item itself removed. The boomerang is synchronized in a similar way, but the trajectory there, of course, is more complex and the number of parameters is greater.


Synchronizing sounds, sparks, explosions, and other one-time effects is the easiest. You just need to tell other players at which point to play certain effects. To be able to transmit a link to the effect, I made a script that automatically scans all game files, gives each file a unique number and places these numbers into the dictionary, which allows it to quickly identify each file by its code.


Synchronization of effects and sounds was one of the most pleasant tasks - there were no difficult moments, and the result was very noticeable! We can already see how other players are running around the map, interacting with the environment, cutting down trees, shooting arrows, using magic, etc. At this stage, I posted the second demo video. You have already seen it, but I will duplicate it here:


Jumping between locations

The world in the game is divided into several locations. Moving players around these locations is not a problem. Going to another location, the player simply sends a signal to the server, the server redirects it to the other clients, after which they hide the corresponding character. The difficulty lies in the fact that locations are randomly generated when entering for the first time. If one of the clients goes to a location where no one has ever been before, that location must be created. This is what happens in a single-player game. 


So what's the problem? In programming, it’s called RAM fragmentation. When the program works, it often allocates some pieces of memory, then releases, then allocates again, and so on. Then, over time, RAM becomes like a colander - small pieces of allocated and currently used memory are distributed throughout all available space. When we need to allocate memory for a new and very large chunk, the system understands that this chunk cannot be taken and the program crashes with the error "not enough memory." Although, there would be enough free memory in total for this piece.

This problem exists only in 32-bit operating systems. For 64-bit systems, the address space is so large that we will not be able to fill it with garbage. In the first part of the game, I encountered this problem because - in the early stages of development - I did not think about memory fragmentation. To generate a world, you need to allocate several fairly large chunks of RAM for the geometry of the level, its textures, grass, etc. If a player played for a long time in a ready-made game, then exited the menu and tried to start a new game, there is a high probability that the game would crash. To avoid this, I had to do a trick that - when trying to start a new game - the game asks the player to restart the application. As a result, RAM for the application was renewed and the game had a large chunk of memory without garbage. 


In the second part of the game (as I mentioned above), each location is generated when you first enter it, so I needed to protect myself from the fragmentation problem. To do this, when I start the game I immediately allocate several large memory buffers for future map generation and then use these buffers, if necessary. To prevent these pieces of memory from being idle during the main game, the game uses them to store some information about the currently loaded level - height map, textures, and grass. Subsequently, it turned out that there was no sense in supporting 32-bit systems anyway and, as there is no problem for 64-bit systems, this approach turned out to be unnecessary. 


In the online game, it became a significant problem. If the client goes to a new location, then the server needs to generate this location, meaning it needs to free up memory buffers for this. But it uses them for the location that was currently loaded. Therefore, I had to significantly redo the memory management.


That's it, see you in the next post!


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

What happens next? An apple is added to player A's inventory and information is sent to the server (this was already mentioned in the previous post). However, the apple must be removed from the ground so that no one else can pick it up. Therefore, player A forms a data packet, places the apple in it, and writes the operation "update quantity" (equal to zero). Player B, having received this packet, will understand that the apple just needs to be removed, and will do it. Everything is quite simple, but this scheme does have its difficulties.


Regarding simplicity, there are not many objects in the environment and include a tree (in the game a bush is also considered a tree), a stone, a plant, an item, and a decoration (which includes barrels, boxes, fences in the first location, and so on). There are not many actions that can be done with these simple objects.


The second item listed above has one difficulty - you need to be able to point other players to a certain object (a particular tree or a specific bush of wheat). The need to point to specific objects will be useful later in synchronizing other game elements like effects, attacks, and animals. This means that we require a universal mechanism and so, each object or other element in the game must have a unique ID. 


During the initial map loading, the server assigns these identifiers to all objects and - when the client connects and requests a map save - the server sends these IDs along with other data. Clients should also be able to assign IDs to new objects and the events they generate themselves. At the same time, IDs must not be duplicated, otherwise there will be confusion. To generate unique, unrepeatable identifiers, there is a ready-made, simple, and secure solution - GUID (Globally Unique Identifier)


With just one line of code I can generate such identifiers, but their size is 16 bytes. Since the links to the objects will have to be sent constantly, I decided to go a more complicated route by using unsigned integers of 8 bytes as identifiers. Session number is always stored in the first 4 bytes, and the ID itself is stored in the remaining 4 bytes. Every time someone connects to the game, the server gives them a session number which will increase by one each time. Even if the same client connects to the game, exits, and connects again, they will receive a different session number. 4 bytes for identifiers within one session is enough even if you generate events and items 100 times every second continuously for a year.


In order to send a data packet to other clients (point three of the list), each such packet is sent to the server where it is copied and sent to all other clients. I wrote about the ways of sending packets in my previous post. Afterwards, one of the Factorio developers wrote to me. If you’re reading this, hey! And hello to all other developers who have been brought to my blog!

So, he told me that the network communication schemes I wrote about are called Star (when all messages pass through the servers) and Mesh (when each client sends messages directly to other clients). Based on experience, he also advised me to use the Star model instead of Mesh. Additionally, he told me about some of the subtleties of the Internet and the specifics of sending messages via Steam API. Thank you very much, kind man! Now, what was I talking about? Oh yes! The Star scheme is used to send the package to all clients for environment packets.


There are no difficulties in receiving the packet, resolving the object by ID, determining the operation, and performing this operation. However, there is another significant point, which (I think) is a big problem for almost all online games: What happens if two players simultaneously click on an apple to pick it up?

If you leave everything as it is, the apple will slide into the inventory of both players, leading to a simultaneous message sent to the server that the apple should be hidden. The apple will be removed, but a total of 2 apples will be added to the players' collective inventory. To resolve such conflicts, we have to make an object locking system. Before picking up an apple, each player sends a request to the server to allow the operation with the object. The server sends a positive response, while noting that the apple is currently in use. If someone else asks the server for permission to do something with this apple, the server will deny them. After the player (the one who had received initial permission to work with the apple) picks it up, they immediately send a message to the server that the work with the apple is finished.


After all this was implemented, players could already see the interactions of other players with the environment. At this stage, I posted the first video demonstrating these capabilities. I will post it again since it corresponds well to what I’ve described. Keep in mind that it is an old video which you may have already seen.


Now let's check the task list:

  • Lobby - Done!
  • Starting the game and setting up the connection - Done!
  • Auxiliary tools - Done!
  • Synchronization of heroes - Done!
  • Interaction with the environment - Done!
  • Synchronization of audio and video effects - Done!
  • Jumping between worlds - Done!
  • Synchronization of constructions - Done!
  • Synchronization of crafting and building - Done!
  • Synchronization of monsters - Half done
  • Synchronization of quests and scenario events - Not ready
  • Testing and balancing - Not ready

Since I first wrote this list, I realized that there are 2 more tasks that should be implemented - synchronization of the minimap and the weather. However, these are not very large tasks and, in total, will take no more than a week. All together, it should take about a month of work. However, for greater reliability, I’m estimating it will take around 2 months. In total, the expected release date of the multiplayer at the moment is mid-March.


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:


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.


Game launching

After the game is selected and all players are ready, you need to start loading the world. But first you need to create and run the core of the network code - the server for the player who created the game and the client for the rest of the players. I decided not to make a big difference between the server and the client, since I wanted the roles to be changed and clients could sometimes take on some of the server's tasks. This is necessary in order to loosen the strict affection between players to make easier for them travelling the worlds independently of each other. Therefore, the game does not have a server as such. There is only a client, although for the player who created the game, this client still performs slightly more functions than others - it controls game saving, generates new locations, resolves access conflicts and monitors data streams to be consistent. Despite the fact that there is no server as such, I will still use this word for the player who created the game.


When the client is running and configured, the world starts loading. And there is also one important difference from the first part of the game. Previously, clients received all the necessary information about the world over the network from the server every time. Now the client receives the world files only on the first launch. It saves them to itself and in subsequent connections it requests from the server only the changes that have occurred to the world. This allows to reduce the amount of transmitted data several times and significantly speed up the loading of the game.


Auxiliary tools

Initially, I started designing network code so that it would run in a separate thread in parallel with main game. This would avoid delays in the data messages exchange at the moments when the computer is very busy, for example, by loading resources when changing locations. However, I quickly realized this approach would be difficult to implement, since Unity doesn't allow working with resources in parallel threads. You can bypass these limitations, but the complexity of the code will increase significantly. Therefore, I decided to try launching the client in the main thread of the game and break those moments in the download, when the game is freezing, into smaller parts. A rather painstaking work was done, but in the end I managed to make sure that during loading the game does not freeze for more than 0.1 seconds, which is quite an acceptable delay for multiplayer.


In addition to this problem, there were a number of auxiliary tasks needed to be implemented before starting to make the main network code: packets grouping, delayed dispatch, allocating areas for generating unique IDs between clients, organizing different data streams for auxiliary and main packages. This is a very large number of small tasks, but their design and implementation took a very long time. Perhaps also because these tasks are purely technical and difficult to visualize in your imagination. There were times when I didn't write a single line of code for several days, but just walked from corner to corner or laid on the couch, forming in my head a picture of how the interaction of game objects should be built. But finally this stage was successfully passed and it was possible to move on.


That's all for now.

The item "Synchronization of buildings" from the list of tasks (from the previous post) has moved to the finished tasks. This includes the instant addition, removal and relocation of buildings, as well as their use (except for time-consuming processes, as these tasks relate to the item "Synchronization of crafting and building").


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:

What I still have to do

  • Synchronization of constructions (2 weeks)
  • Synchronization of crafting and building (1 week)
  • Synchronization of monsters (2 weeks)
  • Synchronization of quests and scenario events (2 weeks)
  • Testing (2 weeks)

(Time estimates are approximate)


I will tell you more about these tasks in the future posts. Also I'll write about all the difficulties I faced and how I solved them. You may notice that more than half of the tasks are already done. In addition, there are many purely technical tasks among the ready ones. Such tasks are more difficult, because there is a lot of work, which remains behind the scenes and does not lead to any visible changes. When you write code for 2 weeks, and nothing changes visually in the game - it starts to depress, motivation decreases, and work begins to go slower. But almost all such tasks are already behind. 


What do we have now? As you can see, there is still about 9 weeks of work left. In each new post I'll indicate at what stage the development is at the moment. If everything goes smoothly, there is a chance that multiplayer will be released before the end of this year. However, the more realistic prospect is that it will be released in January.


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:

Also, the game world has no sky and no reflections for water. This is not very noticeable when viewed from above, but when viewed from a third person it becomes a problem.

The third reason is the design of locations. The game was originally designed for a top view, so all locations are quite flat - they have almost no height differences. When viewed from above, terrain slopes are difficult to notice, but they become a big problem when building a base. For example, notice this slope to the shore:

Also, all trees are limited in height by the level at which the camera is located. All these features become too noticeable when viewed from a third person - locations start to look very flat, boring and tasteless.


Finally I decided that I would have to change too much, and in the end I would get a completely different game altogether.



The last thing from the list that remains to be implemented is the cooperative mode. This is exactly what I am currently working on. There is a lot of work here, as there are many difficulties - in the next blog posts I will talk more about them. I gave up using ready-made networking solutions and I write all the networking code myself (which is something I will elaborate on in another update). But the work is moving. The most difficult and boring part of it has been already done - the implementation of all the auxiliary systems: lobbies, transferring files over the network, setting up connections between players, different methods of transferring packets, the ability to reconnect (which, by the way, was absent in the first part of the game), the ability for all players to independently jump across locations (which was also impossible in the first part of the game). All movements of characters and their interaction with locations are synchronized.


Unfortunately, the post has already turned out to be quite long, so I'll tell you more about all this in further ones, and for now I'll list only main features:

  • as in the first part, up to 4 people can play at the same time
  • as in the first part, Steam servers will be used to transfer packets between players
  • as in the first part, it will be possible to play only with friends from Steam
  • unlike the first part, players will have complete freedom of movement
  • unlike the first part, the server and clients will have absolutely equal opportunities in the gameplay

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.


Now I can also tell you about the system requirements.

The game does not require a very powerful computer to work. At the ultra settings, it will run on configurations with 8 GB RAM and a video card of the level of NVIDIA GeForce GTX 960 / AMD Radeon HD 7970. If you set the minimum settings, then it will go well on much weaker configurations. The only serious limitation is that the game will only run on 64-bit systems. However, according to Steam statistics, now almost all players have 64-bit operating systems. At first, only Windows OS will be supported, but in the future I will try to add support for Mac and Linux.


I have a lot of work related to the release of the game now, so the next post will most likely be after the release. In it I'll talk about further plans for the development of the game.