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.
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!
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:
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:
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.
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.
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:
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.
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.
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.
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").
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
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
(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.
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:
As you can see, most of this list is already ready. Only the third-person view and the co-op mode remained.
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 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:
The store page is finally ready! Now you can read the description, see screenshots and add the game to your wishlist!
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.
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:
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.
Magic orb (or simply Morbo) will not appear immediately, but as soon as you find it, it will become your faithful companion until the end of the game. In the game Morbo will perform several functions.
According to the game story, Morbo is an artefact that was created specifically for search and exploration. Players will be able to use this for their own purposes. Pay attention to it's behavior - if something valuable or interesting is hidden nearby, Morbo will attract your attention. It will also serve similar to a compass from Force of Nature 1 - mark all main objectives on the map.
As in FoN 1, day and night will follow each other. At night, of course, it will be much darker than during the day, and world exploration won't be very comfortable. Besides that, you will find caves and dungeons in which there will be no light at all. The torch will help you navigate in the dark, and you'll be able to hit enemies with it. But, nevertheless, it is much more convenient when both hands are free. Morbo emanates soft ghostly glow, which is enough to find the way in a dark cave. If necessary, the strength of this light can be upgraded.
Our hero won't have any magical skills, but he will be able to use magic. And the main assistant in this will again be Morbo. With the help of a special covering, Morbo will be able to accumulate mana, which can be spent on magic spells. Moreover, these spells will come from Morbo, not from the main character. Usually Morbo will follow you itself, but if you wish, you can detach it from the hero and control it directly. For example, it will be possible to send it into a crowd of enemies and use some spells to inflict damage on them, while remaining at a safe distance.
It's worth to remember that both abilities to accumulate mana and to cast spells will belong to Morbo, not to our hero. In singleplayer this won't be so noticeable, because Morbo will always be near you. But in co-op walkthrough, this feature will make using of magic a little uncommon. Only the player with Morbo will be able to use it's magic and give it commands. However, any player at any time will be able to call Morbo to him, no matter how far it is. Mana will also be shared for the entire team. I think this will make players act more coherently.
By the way, the idea of making a flying magic ball as a controllable companion went to me from the game Warlock, released in 1995 on the Sega Megadrive and SNES consoles. At that time, it was a rather unusual mechanic, that stuck in my mind.
While game balancing is in process, let's return to the comparison of the first and the second parts in numbers.
Counting constructions we have the same problem with variations as with enemies (as I wrote about in the second part of the statistics review). For example, fences have variations with different lengths - corner, 2 cells, 3 cells or 4 cells. I will not take into account such variations. Also, I will not take into account pathways and pavements, because there is no geometric models for them. I will also not take into account the pocket lamp, although it can be used as a decoration.
So, in total, in the first Force of Nature there are:
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:
Total: 94 buildings (almost twice the amount of the first part).
Game development is still in process, so this list is not complete. Maybe, there will be more of them.
It was quite difficult to count all the sounds, because there are sooo many of them. And yes, there are variations again. At the same time, large number of variations is very important for sounds. Many sounds such as footsteps,
or strikes sound very often and regularly. Without a sufficiently large number of variations, the repeatability of the same sounds will be too obvious. When calculating, I conditionally divided all sounds into the following categories:
Back to numbers:
In summ there are 19 loops, 25 individual sounds and 113 groups - total 423 separate 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.
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):
These tables turned out to be much more massive than in the first part. Over time I encountered one very significant drawback of this approach - the need to regularly manually synchronize values in these tables and in the game files. Working with parameters looked like this. First, I set the numbers in the table, focusing on my intuition and my idea of what should be stronger/better/more dangerous for interesting walkthrough. When doing so, I rely largely on the calculated values that the table provides me. Then I need to carefully move all these parameters from the table to the game, without making any mistakes. Then I launch the game itself and begin to walkthrough it, as players will then do. At the same time, I make sure that the weapon behaves exactly the way it was originally intended by me. Of course, there are lots of edits at once. One weapon needs to be made a little stronger, another - a little faster, etc. I immediately make all these changes to the table, so as not to forget about them later. When the edits accumulate quite a lot, I stop the game and start moving them from the table to the game project files. At this stage I have to carefully check all the parameters, not just those I have changed while playing. This is because during the game my attention was focused on the gameplay, and not on remembering which parameters I changed and which ones I didn't. Of course, it's not without mistakes. The head from such work begins to boil very quickly, mindfulness falls and the work turns into a nightmare.
My patience didn't last long. The mixer panel for balancing sounds showed itself very well, so I decided to make an analog of such a panel for game parameters.
Unfortunately, in Unity there is no simple ready-made solution "out of the box" to make a lot of parameters for various objects and conveniently arrange them in a table on the screen. But there are tools that allow you to create your own editor extensions. I had to spend some time to figure out how to do this. After all, this game is my first experience with Unity. However, in the end, I made a window in which all the weapons are collected. All the parameters that need to be adjusted are located side by side, and all the formulas are neatly transferred from the tables and work exactly the same. In fact, I've got a full analogue of Google tables. But this time all changes are made immediately directly to the project files. Setting up weapons with such a panel turned out to be much easier, so I spent a few more days and made similar panels for monsters, clothing and food. Over time I also set up relationships between different tables. For example, clothing can affect damage and attack speed of a weapon. At the same time, this influence can be different on a particular weapon. For example, if the sword deals 10 damage, and hits 2 times per second, and the mace does 20 damage, but hits 1 time per second, then both the sword and the mace will deal 20 damage per second. But if you wear gloves that add 5 to the damage, then the sword will deal 2 hits per second for 10+5=15 damage, i. e. 30 damage per second, and the mace for the same second only 20+5=25.
The ability to manage tables with both weapons and clothing in one window allowed me to set up more complex formulas that take into account both clothing, armor, amulets, and weapons at once. This way I can now balance not only the weapons between each other, but also the overall character build.
All this took a lot of time, but hopefully it will help me achieve a much better balance than in the first part of the game.
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:
The panel locates ALL the sounds available in the game. I can assign a horkey to any of the sounds, play these sounds quickly and easily in any combination, smoothly change the volume of individual sounds, thus quickly and easily determine the volume of each sound. It is also possible to play some sounds automatically to create some abstract background from them and be able to fully focus on one sound.
At first I thought creating of this panel would take me 2 days, but it took 5. But this time was not wasted. Thanks to the mixer, balancing sounds turned out to be a simple task, which I completed in just 2 days.
So out of the blue, I lost one more week of time.
Merry Christmas and Happy New Year to all! Stay healthy and let the new year be positive!
There are lots of different items in both parts. I will not describe in detail, just give the numbers:
Force of Nature 1:
Force of Nature 2:
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).
Now there are very few such color variations - all the elements of clothing are unique and the variety of weapons is also much wider.
By the way, because in the second part there is a new character - a girl, all the clothes had to be drawn in 2 versions!
Now to the question that worries everyone the most. When will the game be released?
At the beginning of September I planned I would have time to finish everything and release in November.
However, I slowed down a lot on a point that I didn't even take into account at that time - on the dialogs. I came up with the main idea of the story myself, but I specifically hired a screenwriter to design the elements through which the story will be presented to the players. Thinking through all these phrases, dialogues - all this actually takes a lot of time, so I needed such a person. By the end of the summer all the work was 95 percent complete, but the screenwriter suddenly disappeared. Just stopped communicating. I don't know what happened to him. I was mostly busy with other things and looked at his results superficially. Before adding all the dialogues and phrases to the game I read the story to my wife, and she found a lot of inconsistencies. Also, quite a few situations painfully resembled episodes from the Lord of the Rings. As a result, I made a hard decision to completely discard the results of the screenwriter and to do everything again from scratch. This time I was helped by my wife and a friend (who, by the way, also wrote all the music for the second part of the game).
As a result, we lost sooo much time - a month and a half. It seems strange to me - where was all this time spent? After all, the entire result eventually fits into 10 A4 pages. However, I am satisfied with the work done. The stories, in my opinion, have become much more interesting.
Perhaps you will say: "Why do we need a story at all in games of this genre? No one likes to read long texts anyway." However, it is important for me that everything that happens in the game makes sense. And I tried to make the texts not very long and complex, so that there was no great temptation to just scroll through them.
I won't specify new terms, because I'm afraid to make a mistake again. I will only say that I work from morning to night, seven days a week, to release the game as soon as possible. If you look at the list of tasks that I gave in September, then I'm about here now:
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:
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:
Total: 47 different enemies, although many of them are very similar to each other.
So, in total the first part contains:
I will not list all the enemies of the second part of the game, just give similar numbers. In total it will contain:
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 the following posts I will compare buildings, items and locations in a similar way.
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.
This way you will receive additional quests. These quests are quite complex and it will not always be clear immediately what to do. To complete some of them, you will have to think, for others - to travel a lot.
However, after completing the task, the ghost won't remain in debt, and will help you at the base.
Ghosts can do different things: craft, build, mine resources and repair. I already wrote earlier that in the new game, the work will not be performed by your own (as it was in the first part). Someone should stand by and do the job. Before the first ghost appears, you will have to do all the work by yourself, but then you will be able to assign tasks to ghosts by adding items to the crafting queue. By the way, queues at many tables have been increased to several slots. You can queue up a few items that interest you, and leave to do other things, and the ghosts will craft.
Usually, the ghosts will look for the job themselves, trying to disperse around the base. Different ghosts will have their own preferences in the work. Some will prefer crafting, others - construction.
You can also make a direct order to the ghost to do a specific task. Besides that you can equip several ghosts to do the same task simultaneously to speed up its execution (although their performance will then decrease).
The ghosts have another useful feature. Wherever you are, you can always summon a tamed ghost and ask it to teleport you home.
In my opinion, ghosts are a very serious change in the game, and I hope players will like it.
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.
What is still not ready and is delaying the release?
A few points that I didn't think would take a long time turned out to be quite capacious. We are currently working on the final cut scene. Yes, the thing, what was not in the first part at all. Since the second part of the game has a determined storyline, it also has a determined ending. Or more exactly, even 2 different endings. Creating final cut scenes takes quite a long time: again it's 3D and 2D animation, unique scenery and music. But this is necessary to give the story a complete look and not leave players in a state of frustration and uncertainty - "I did so much, but what for?!"
The next point, which turned out to be much more difficult than I thought, is the creation of production chains. What and from what resources we will craft, what research will be needed to build the next construction, what types of fertilizers will be available at different stages of the game, what resources will fall out of monsters, and so on. If you think these tasks are not so difficult, I assure you, they are. In the beginning, adding of various recipes is quite simple. However, later, when you have to bring it all together in one chain, a lot of difficulties and contradictions appear. A lot of items, resources, enemies, buildings and research, everything depends on each other, and to set up dependencies, you need to keep all this in mind. In the same mind, which already stores the architecture of the entire game and controls the creation of all content. I even tried to get an assistant for this task - a person who graduated from a game design course. I spent quite a lot of time explaining him in detail how game systems function, but in result he wasn't even able to structure what was already done at that moment. Now the task of creating production chains is almost ready. I would estimate about 90 percent. The remaining 10 percent are quite difficult - adding each new resource to the game requires a lot of effort from me.
The next thing is voice acting. The game's voice acting also takes longer than I planned. But it doesn't stand still. We have already finished voicing nature, weather and buildings. Unfortunately, the monsters are only voiced by 30 percent so far. In order for monsters' voicing not to become the main factor delaying the game release, I will most likely have to start testing the game when not all the monsters will be voiced yet.
It's hard to make accurate predictions. Almost all of my assistants are tired and go on vacation. I myself have not worked for the last week, because I got sick (it's okay, it's not covid and I'm already on the mend, I was even able to write this post). I'll try to describe an approximate plan for the remaining work:
As it is not difficult to calculate, if everything goes according to plan, the game should be released in November.
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.
Such a system will strengthen the RPG component of the game genre and will allow players to develop a character in accordance with their preferences.
Rising up through the chain of technological progress still has certain stages, but now it looks much more natural than in the first part. You don't need to complete quests to unblock new buildings and recipes. The limitation is very simple: you cannot smelt an iron ingot if you have never encountered iron ore before (obvious fact).
The game will have a special table for investigation new resources. If you find something new, take it to this table and explore. For example, researching ore will give you access to a blast furnace and metal recipes.
Quests are still present in the game, but their role is now completely optional, and only tells the player what to do in the early stages of the game.
P.S.: many people ask about the release dates. Previously I assumed that I would release the game by the end of the summer, but now I realize that I don't have time. In the next post I will give a new detailed review of the development progress and try to give new estimates about the release date.
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.
The floor of the house is always divided into blocks 4 by 4 cells each. If you place a new block next to an existing one, its height will be automatically adjusted. When you place the very first block, the construction grid will show you how far ground roughnesses will allow you to continue building the floor on the same height.
When I developed house foundations, I pondered how high the floor should rise above the ground. If it will be very high, this will allow players to build large houses even on quite scabrous surfaces. But then you can get large stairs on which players will have to "jump". Through trial and error I found a maximum value for one stair of 75 centimeters (30 inches).
House walls are also divided into blocks, 1 by 4 cells each. Wall length within this block will be automatically changed to adjust to nearby walls.
I had to do a lot of work with the roof. I wanted to keep roof building process management as simple as possible for players - just specify where roof blocks should be placed. And at the same time I wanted roof blocks to automatically fold into a single roof with a logical shape, but the roof shape not to be trivial.
To achieve this goal, I developed a system of 23 separate parts, which automatically form the final shape.
The result is something like this:
I would like to add more decorations to the walls and roof, but I have already spent a lot of time on this constructor. Therefore, even if my hands reach it, it will be after the game release.