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.
We even made a table where we experimented with detailing, textures and shapes realism for a single object.
Finally we came to use a realistic shape, simplified details and stylized textures. I like the result. Icons look neither like cartoons, nor realistic or rendered. A close look will reveal the work of artist in each icon.
The capacity of your backpack will be quite small at the beginning of the game - only 16 cells. However, with time it can be increased by creating different bags.
We've also added a few small changes that I hope will make life easier for players. For example, inventory compaction not only transfers all items to the upper-left corner now, but also groups them by class (food, weapons, resources, etc.). Sending items from the inventory to the chest (and vice versa) can be done now via mouse click with pressed Shift key.
Important scenario items will now not fall into the backpack, but into a purse, from where they cannot be lost if you die.
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.
On iPi developers' website I found recommendations for installing the sensors. There are 2 basic configurations - to point the sensors opposite each other, and to point them at 90 degree angle to each other.
First, I decided to test the position of the sensors opposite each other. But it turned out that the quality of the result is no better than recording with a single sensor. The second sensor works well avoiding overlapping hands with the body, but in fact hands' movements are visible either by one sensor or by another, so we still get tracking with one sensor.
Configuring the sensors using the second scheme allowed to slightly improve tracking quality. Most of the movements were detected by both sensors simultaneously, which increased the accuracy.
However, animation quality still didn't reach the level I wanted to see in the second part.
So I started looking for an experienced animator. After more than a month of searching I finally found a person, whose animation quality suited me. Now we make up to 3-4 animations a day, and in about a week or a little more, the main character's animations will be ready. But there are also monsters and bosses, so animation is still one of the key factors determining the release date of the game. I hope I'll find a solution to speed up the animation of minor characters.
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:
This table will produce amulets and various parts of complex shapes. According to my estimates, it will take about a month to finish main buildings and another month for decorative ones.
Enemies are also half ready. There will be quite a lot of different ones: wild animals, various fantasy creatures, magicians and knights. And we'll try to find time to add many new ones before release. Artificial intelligence algorithms have been significantly refined. I haven't done any fine-tuning of AI yet, but I hope that with the help of new algorithms I will be able to make battles more dynamic and interesting than in the first part.
There will be 5 bosses in the game. Concepts are ready for all of them, but 3D models have been made only for three for now. Creating one model takes about a week, so it won't take much time to finish the rest of them. The worst thing is to give them unique abilities, because it requires writing program code. I think it'll take me another 2-3 weeks to script the behavior of all the bosses. This is what one of them looks like. Meet the Lord of metal:
Drawing models for monsters and bosses is only half the job. They also need to be forced to move. Character animation is quite a painstaking labor: it turns out to make only 2-3 separate movements a day. On average, one enemy takes a week of time. At this moment, it's the main factor that postpones game release, because many characters with ready 3D-models are not animated yet. In the next post I'll tell you more about various difficulties I had to face while animating of the main character.
We fill the game with content intensely. Yes, there is still a lot that I want to add to the game. However, some of this work is being done in parallel, and I hope that in 2 months we'll be able to start beta testing. As a result, the game should be ready for release sometime in August. Yes, I know that the deadline has moved forward. Previously, I estimated to complete the development by the end of spring. But at that time, many aspects were not even started. Now all the main parts of the game are already affected and we are steadily moving towards completion. Therefore, I hope that the current forecast will not be far from the truth.
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.
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:
The sound part of the game is nearly half completed. Sounds of user interface, footsteps and bumps on different surfaces are fully finished. Crafting, building sounds and surrounding noises are half completed. It remains to record weather sounds, birds singing, unique sounds for different constructions, magic spells and all the monsters. So, there is still quite a lot of work. According to my estimates, it will take about 2 more months.
At the beginning of the first part of the game, it is indicated that all music for it was made by "Storm Warning!" band. It's a music band my classmate and I founded when we were students. I used some tracks from our tracklist which I composed and mixed by myself. This time music is technically from the same band again. But now our guitarist works on it. He composes tracks specifically for the game. The music is very pleasant and fits well into the game environment. There are already more than a dozen tracks ready, and we hope to produce as many more.
The game will have a fairly wide variety of clothing and weapons. There are already more than 50 items of clothing (and there will be 20 more). For example, how do you like this outfit?
Many weapons are not ready yet - about a third of the estimated number is done. However, all the scripts are finished, and I only need to make models and draw icons. It won't take for long.
I’ll post the second part of the post with the rest of the points and summing up a little later, but no later than this weekend.
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.
On the high frequency ranges Sony is actually a bit quieter, but in the main audible range of 100-5000 Hz it has even a slightly higher noise level. In addition, it has a parasitic exceeding in the region of 7000 Hz. I decided that maybe I got a defective one, so I returned the recorder and bought a new one in another store. But the situation was the same. I also returned a new recorder.
Then I decided to find an experienced professional who will not only have good equipment, but will also be a sounds processing specialist. After quite a long search I met Eugene. Now we are actively recording sounds for the second part of the game. We try to make a maximum of live sound and a minimum of synthesized.
The situation with COVID-19 makes life a bit more difficult for us, as we can’t fully use the services of voice actors. But we're doing our best.
Here is a short video on which you can see the process of recording sounds for Force of Nature 2.
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:
It was decided to completely remove the pig from the game. The purpose of a pig for a farmer is obvious - they are bred for meat. But I didn't want the game to encourage players to be cruel to peaceful and harmless animals. Want some meat? Eat the boar. He is not peaceful at all and generally he is the first who gets into a fight. And I don't want to use a pig for such far-fetched purposes as finding worms.
In order to tame an animal, you will still need to make a trap and throw it on the animal several times. But now you will not be able to tame it until you provide it with a place to live. There are two types of animal houses:
Universal barn will need to be built first, because you don't know which animal you will meet first. Then it will be more profitable to build specific sheds for certain animals.
Feeders appeared in the game. They can be put on the ground and filled with food. Animals themselves will eat if the feeder is close enough to reach it. After installing such a feeder, you will only need to collect resources from the animals and replenish food supplies in feeder from time to time. Resources collection has also been simplified compared to the first part. Now you don't need to open the GUI window and click the button to collect resources. When the animal has finished creating the product, a special icon appears above it. You can click on it and the hero will run up to the animal and take the product.
Unlike the first part, now animals will not accumulate produced products and will not be able to continue working until you take finished resources from them. But don't be afraid. Like many other buildings, animal houses can be upgraded. At higher levels, these houses will be able to accept food from the animals that live in them. You will only need to add food in the feeders from time to time and take finished products from houses at once.
I hope you'll like these changes!
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.
All buildings were redrawn from scratch and now have a more detailed design.
Also there will be a lot of new and interesting buildings that were not present in the first game. In fact, the whole progress line is new. This will not just be a repeat of the first part with improved graphics.
The building process doesn't go by itself anymore. As for all the work in the second part, to proceed the building you need to be close to the construction. The hero starts working with his hands to increase the percentage of done work. But don't worry, you won't have to work with your own hands for long. Soon enough you'll have an assistant who will work on the base while you travel the world, fight enemies and gather resources.
The building progress can be viewed by gradually appearing parts of the construction.
Also some buildings can be upgraded to the higher level. They will work faster and give the access to new recipes. For example, here is the first and the second level of tailor table.
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:
Also, the current character characteristics were moved to this window. It seems to me this should simplify the comparison of different equipment, making it possible to immediately observe how armor, running speed, damage per second and other parameters change. In addition, there will be much more different clothes and weapons in the game than in the first part.
To quickly move items between your inventory and an open chest, you can now click on objects with the Shift key held down - this will instantly send the item from inventory to the chest or vice versa.
Building and craft windows have also changed significantly. I tried to get rid of excessive windows and fit all the necessary information into one window. This is how the building window now looks like:
The list of all buildings is placed to it's left part. It is also possible to select a category (crafter, storage, farming, decoration, etc.). The description of the building is now in it's right part, with the ability to choose from several variants (for example, the length of the fence).
I hope the new user interface will allow less distraction from the main gameplay and it will become more fun to play.
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:
And this is how they look like in the game:
As before, character's skin and hair color can be customized. Also you can choose one of several hairstyles.
I didn't embed an underwear color customization (as it was in the first part), because there will be much more various clothes in the second part, and the character will always have something to wear.
The gender of the character can only be selected in the beginning of the walkthrough. During the walkthrough, only colors and hairstyle can be changed.
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.
Clearly something is missing. I know! Duckweed!
Yes, it’s better now, but I came across a new problem - the sharp edges of duckweed on the border between water and ground. I tried to mask this edge with the texture on the terrain, but that didn't help much. Then I decided to hide the border using swamp debris. For this, I prepared several models of individual strips.
I can find out the exact border between water and ground using the Marching Squares algorithm, knowing the height of the landscape at each point and the water level.
I went through all the borders, placed points with an equal interval, and paved the resulting segments with elements of swamp debris.
Seems fine, but sometimes sections of the border quite far get out beyond the boundaries of one debris element. Therefore, as a final refinement, I select all the points on the boundary for each element and define the line that best approximates these points. Then I move the selected item to this line.
Now the result is quite fine with me.
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:
However, when I gave the lava a flow animation, I ran into a problem - the lava flowed through the stones, creating a feeling that the stones hang over the lava:
To solve this problem I generated a texture of the distance to the nearest land. Using this texture, I can make the lava near the stones colder and reduce the speed of its flow. I also decided to change the textures from the purchased asset to my own.
Here is the result:
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:
... 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.
I am still doing the coding part alone. I also took on the drawing of all the vegetation in the game. In the future, I most likely have yet to find a composer. I composed and recorded all music for the first part by myself, but now I no longer have the strength to create a new tracklist for the second part.
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.
Hidroform Ocean System
Hidroform Ocean System is an ocean surface modeling system. I used this effect to create a menu screen. One of the few effects that I used "out of the box". That's what the main menu of the game looks like at the moment. This is a working version, the logo I took from the first part and will change it in the future.
Antialiasing is a software technique for diminishing jaggies - stairstep-like lines that should be smooth. There are a lot of different assets in the Unity Store that provides this filter. I started from Amplify FXAA (Fast approXimate Anti-Aliasing) because it is free and is high rated. I was totally satisfied by the result for a long time.
I read about the CTAA (Cinematic Temporal Anti-Aliasing) from one article that compared differet antialiasing techniques. It is a preaty expensive asset, but it was on a 50% off sale so I decided to check it. It took some time to adjust the parameters, but the result exceeded my expectations. The smallest details are now distinguishable.
Indirect lighting (redflected lighting) is very important for getting a realistic image. But computation of correct indirect lighting is very time-consuming task even for a modern computer. Most of games pregenerate it and store in textures that are used futher for rendering. But the games, that generates locations proceduraly cannot precompute the lighting and shouls use other techniques. On of such technique is ambient occlusion. There are a lot of approaches for this techniques that differ in quality and performance. Compared several of them I stopped on Amplify Occlusion.
However, this filter produces small-scale shading and does not work well at the edge of the screen. Therefore, I also wrote my own ambient occlusion filter, which is focused on large-scale shading. Together with Amplify Occlusion, these filters significantly increase the quality of the picture, which is especially noticeable when the weather in game is cloudy and there is no light from the sun.
Using ready solutions (assets) in Unity helps to save a lot of time. In the Asset Store you can buy models, sounds, animations, scripts and much more. There are tons of assets, but basically it is all a product of extremely low quality. Today I want to talk about which third-party assets I happened to encounter, which ones I ended up leaving in the game, and which ones I had to rework.
Standard terrain material in Unity uses the simplest way to blend textures. There are solutions for blending textures using heightmaps, which makes the transitions between textures more natural.
For my game, I chose between CTS and MicroSplat, read reviews and performance comparisons, and chose the seccond one. This is a completely free solution for better display of landscape. It has many settings, is well optimized, its developer answers all questions very quickly. It is also possible to expand the possibilities of the material with paid add-ons, such as snow, the illusion of wind, water / lava, triplanar overlay and others. However, I have not yet encountered the need for any such addition.
As in the first part of the game, I am still very concerned about the performance, so I looked for a good and lightweight shader to display water. In the end, I chose AQUAS. For quite some time I was completely satisfied with how the water looked like, but when I started doing the day-night cycle, I noticed that water does not always respond correctly to a smooth change of illumination. Sometimes sharp jumps in brightness occur. For a long time I had to figure out what was going on. It turned out that unity sorts light sources by importance - it selects 1 main and several additional lights. The processing of these lights in the shader is slightly different. Usually the main light is the sun. However, during the change of day and night, this source gradually goes out to 0, thus the main source becomes the sky, moon or torch. The developer of AQUAS obviously made a mistake in shader, because when the main light source changed that the brightness of the water changed discontinuously. I tried to fix this bug myself, but the shader code was completely unreadable. Obviously, the shader was automatically generated by some system of visual editing of materials. As a result, I refused to use AQUAS. By this time, I had been using Unity for more than a year, so it wasn’t too difficult for me to write my own shader, which correctly processes all light sources. I also added the ability to display shore waves to my shader. I am satisfied with the result.
Ez Define Symbols
Ez Define Symbols is a small free utility that allows you to make build parameters. With it, you can easily turn on and off sections of code. For example, you can make an assembly for testing, in which the game control panel will be included. Eith this panel I can spawn resources, teleport the hero to any point on the map, control the weather, spawn animals and much more.
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.
At the next step I scanned the resulting model using photogrammetry. For this, I took 88 photos of the canyon from different angles. The resulting model has 3,000,000 polygons.
Then, from a 3D model, a height map was formed, which I cut into many small sections. When the game generates a canyon, it takes these sections, mixes them in random order and lays out them along the previously generated spline to form a height map of a cliff.
Unfortunately, the map in the game has a resolution of 0.5 meters per cell and cannot represent all the details of the original model, however, the result still looks good, and the creation process was very fun.
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.
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
- 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.
That's all for now! More details and screenshots in the following posts.