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.