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

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

Constructions

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

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

Synchronization of audio and video effects

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

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

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

Interaction with the environment

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

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

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

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

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

Synchronization of heroes

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

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

2 Methods of client-server communication

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

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

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

Motion smoothing

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

Synchronization of settings

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

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

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

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

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

Lobby

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

Preparation

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

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

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

What is already done

 Completed tasks:

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

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

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

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

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

It listed the following items:

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

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

Third-person view 

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

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

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

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

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

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

Wildlife

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

Boomerang

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

Mannequin

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

WASD control and third-person view

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

Co-op

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

Suggestions from players

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

https://discord.gg/QSzdn3Mu2R

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

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

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

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

Store Page

The release is scheduled for May 27.

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

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

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

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

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

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

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

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

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

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

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

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

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

Constructions

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

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

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

48 buildings in total.

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

So, complete buildings list in the second part:

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

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

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

Sounds

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

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

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

Back to numbers:

FON 1

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

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

FON 2

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

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

It is about 4.6 times more than in FON1 !

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

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

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

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

Tables

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

Uhh.. There was no news for 2 months.

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

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

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

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

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

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

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

Force of Nature 1:

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

Total: 266

Force of Nature 2:

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

Total: 478

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

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

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

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

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

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

Total: 19 different enemy models

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

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

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

So, in total the first part contains:

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

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

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

If we compare domestic animals, then:

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

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

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

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

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

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

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

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

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

Character leveling system in the second part was completely redesigned.

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

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

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

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

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

Graphic style of item icons

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

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

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

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

6. Buildings

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

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

1. Programming

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

2. World and environment

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

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

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

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

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

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

• Cow
• Sheep
• Goose
• Chicken

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

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

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

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

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

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

This is how these characters look like during customization:

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

In one of the locations there is lava.

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

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

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

      float4 break967 = appendResult876;

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

As if someone specifically wanted to confuse me.

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

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

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

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

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

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

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

I still have to:

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

... and many more little things.

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

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

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

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

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

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

A* Pathfinding Pro

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

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

Screen Frost FX

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

Amplify FXAA

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

CTAA

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

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

MicroSplat

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

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

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

Unity

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

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

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

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

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

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

Unreal engine

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

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

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

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

Welcome to the Force of Nature 2 development blog!

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

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

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

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

In the second part of the game will be:

  - Caves and Dungeons

  - Bosses

  - NPC

  - Magic

  - A story with multiple endings

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