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.