Unigine engine
Let's start with the Unigine version. We are using version 2.11, released this spring, starting with which a free license appeared in the engine. At the moment 2.12 is out and 2.13 is expected soon.
What is generally worth knowing about Unigine is a Tomsk game engine often used for benchmarks and simulations. Over the years, it has released games such as Oil Rush, Cradle, and here, for example, the relatively recent mmo Dual Universe.
Quite a lot of interesting and promising solutions are used inside, it renders a rather beautiful picture and can be quite attractive to artists, especially if they model in a separate 3D package, and not by means of the engine itself.
Terrain is there out of the box, as well as water, clouds, volumetrics, projectors and other useful things. Various masks are applied on top of the terrain for detailing and other things - a very cool tool for creating landscapes, although in terms of usability there is room for improvement.
As a tool for a game developer - here, in principle, the experience of using C # in Unity can be applied, although Unigine does not have the same variety of ready-made component solutions. Nevertheless, some basic things are implemented, and the documentation will help you write the rest. C ++ hasn't gone anywhere either.
The engine is not yet suitable for a mobile platform, as well as for development without programming (although it is planned to develop it in these areas as well). Hardware requirements at the Unreal query level, the minimum application file size is quite large. But it's nice and well optimized.
But back to the game prototype. In the Unigine version, the main difficulties were associated with the visual design of physics for a typewriter, because the documentation suggests doing all this blindly, through code, besides, all sorts of physical settings are scattered in different places of the editor and the visual assembly pipeline itself is not described. That is, there was no banal ready-made example that could be modified without plunging into all the nuances. In 2.12, a demo appeared with a tractor digging the ground, but, perhaps, it is being assembled by code again, I did not watch this moment.
Be that as it may, I more or less assembled the machine, focusing on the documentation. About what I previously wrote the corresponding article: How I collected the physics of wheels in Unigine .
In terms of gameplay, in Unigine, unlike Unity and Godot, for example, it turned out to be quite easy to switch the physics of the car on the fly, not only the visual, but also the location / size of the wheels. Without coming up with additional tricks in order not to fall through the floor, and without rebuilding the model. Although, there is some chance of falling into the texture, but in completely different situations, and not at the time of changing cars.
The concept of a single vehicle that simply changes its forms, transforms, adapts, sees what is happening in other dimensions and so on fits well to all this. At least the main gameplay could be built around such switchings, although not necessarily.
What is sad about the engine is assembling the UI from the editor - somehow everything is cumbersome, with separate scripts hanging for each interactive element. Although here I only edited the implementation that was in the examples, I did not understand much, besides, I did not immediately figure out how to display the gui layer in order to see the visual representation in the editor.
On the other hand, if we mean a game that is more console oriented, about gameplay tied to a small number of buttons, with minimal use of the interface and with a minimum of interface elements, then this is no longer a noticeable problem.
Another depressing thing, simple animations recorded on an internal instrument - a tracker. Yes, it is powerful in its own way, but somehow too square-nested to use. Moreover, the animation recorded in this way can be played only using the outdated UnigineScript language. This is while in Unity or Godot you can animate literally everything around the perimeter. Yes, you can import animation of bones, but this is a little different (besides, I have not tried this method yet and I do not know how it is).
If, again, you look at it from the other side, then the engine is still more focused on physical simulations and interactions, so why not use this instead of baking some preset animations there - that is, to make some kind of emitters, switches, interacting structures, applying forces, using gravity, and so on. So you can do without an internal animator, but if it were properly implemented, then this is also a big deal, even if only in terms of direction - in a few clicks you can record a camera flight across the stage with all sorts of interactive elements, and here you have a finished film. Moreover, with such opportunities for a cinematic picture.
As for my project - at the moment, after several iterations, I have finally compiled and posted a more or less solid demo that can be tested.
The archive for Win64 can be downloaded here (weight 687Mb): DROPBOX
or on the itch.io page: NEWANGERS
unpacked takes 3Gb
What is there:
- The build has three main display modes - "day" and "night" (with presets of high graphic settings), and "a la comic" mode (with lower graphics settings).
- To switch between modes, press Esc so that the mouse cursor appears, and select the desired option in the menu on the top left.
- There are interactive objects on the levels - blue star-shaped portals, passing through which the car is transported to other worlds and you can return back by driving into the portal from that side.
- Many objects of the level are permeable, but some have colliders and the levels themselves are more or less surrounded by blocking walls.
- , , WASD. Q E. , , , R. Tab , , , .
- , .
- 1,2,3,4,5,6,7 — . .
- , «» .
- PgUp , . PgDown — .
- P — , L — .
An acquaintance posted the earlier sources of this prototype on his page along with some edits to the physics of the wheels of the original version: GITLAB .
Godot engine
Moving on to the next engine on our list. An open-source compact solution with huge capabilities (Blender from the world of game engines), but, again, is still inferior to Unity in terms of the variety of ready-made components. Although, quite a lot of various unofficial solutions, as well as examples with source codes for Godot, have already been written, and due to the relative simplicity / speed of implementation of the new functionality, I cannot say that this is some kind of problem at the moment.
Godot has a better reputation as a 2D engine, thanks to the variety of well-developed tools specifically for 2D, but they are an additional plus for 3D - it is much easier to make a game UI. Even easier than in Unity, as for me. At the moment, Godot in its development has reached the stable 3.2.3 version (but everyone is waiting for 4 because of the volcano, optimizations, and so on. Shaky assemblies of the four, by the way, you can already try - at least evaluate the picture).
The engine does not require powerful hardware for 3D graphics and produces a pretty decent picture. There are not a huge number of ready-made three-dimensional tools, but some of the most necessary, useful and universal ones have been implemented. The same goes for optimizations. For example, the engine implements the usual frustrum culling, which cuts geometry out of the camera's field of view. Occlusion culling (so as not to count the objects closed by walls), you will have to come up with the implementation yourself (which is not so difficult, especially in some point places, and not in every game you need it). Also out of the box in the engine there is no geometry batching (although there is partially for gles2) and terrain, but this is not such a problem, you just need to optimize something manually - stitch some meshes together, break the geometry into small parts or use chunks and so on Further.You can find some kind of implementation in a local small store, for example, add a ready-made terrain solution to your project.
The interface of the engine, by the way, is quite thoughtful and customizable (although there are some inflexible elements). It is generally convenient to use. There are enough supported languages for different levels of immersion. There is both C ++ and C # and a rather convenient internal GDScript that runs right inside the editor, without requiring a separate environment to be launched. Visual scripting is also present, so that without knowledge of programming in Godot it is also quite possible to live - to design some minimal logic, to animate something (Godot has a simple and cool tool for recording animations).
The low weight of the application, multiplatform nature, speed of development, ease of implementation of various third-party solutions are also important advantages of the engine. There are two rendering options - gles2 and gles3, both support 3D, but in the first it is simpler and in general it is more suitable for 2D and mobile phones. Gles3 provides a more advanced level of graphics, some part of mobile devices also support it.
Let's move on to a game prototype based on this engine. In Godot, a simple physical vehicle model comes almost out of the box, so bringing your cars here was pretty easy.
With what some problems arose - it is not so easy to intervene in a running physical object, for example, to teleport it from one point to another or to change the position of the wheel of the car on the fly. Therefore, here such a trick as in Unigine does not work and, as I understand it, in Godot it is easier to recreate an object than to change the physics configuration or something like that on the fly. But in fact, all this is not really necessary, and in this prototype I just returned to the standard idea of gameplay, when you ride for different cars, changing from one to another somewhere in special separate places.
Godot has some interesting tools like CGS objects and multi-meshes. I wrote in more detail about the features of their use in the article: Godot, 1000 little things
The prototype of the Nevanger on this engine received a separate name -Wild Engines . In general, I get like a family of similar projects, united by the concept of strange cars traveling through strange worlds. And as a working collective name, I used to call them Nevangers, until a more specific name comes up. The Godot prototype now has its own name, the version suspended on version 0.9 of Unity (which started it all) also has a different name, but it will come to that later, if there is time to return to it.
At first, I didn't have a special vision of what I would like to implement in the Wild Engines demo, I just made sketches of levels, trying to understand how to better implement the terrain and what opportunities I would like to see. Then I came to the idea of making the camera move behind the mouse and it became possible to realize more controlled aiming of the weapon than in other versions. Thus, this prototype will probably become more focused on the use of shooting.
Along the way, I began to assemble a level from platforms consisting of small blocks, trying various approaches to optimization and measuring performance. Optimizations by optimizations, but at some point I already filled the area visible to the camera with geometry so much that the editor stopped pulling the entire running scene, falling out with errors. Which was fixed by including more memory in the settings. Then I took the platform generation more into the code, leaving only simplified dimensional blocks with identifiers on the stage, which themselves loaded the necessary platform into themselves when the game was started. Then he rolled back the amount of used memory to a lower value and increased the level several times more without any problems. In addition, with such an implementation, there is always the option of reusing already loaded platforms, moving them to other places in the level,when the machine is heading in that direction in order to be able to draw the level space with them practically to infinity with the same resources and without transitions.
In a similar way, I later collected sketches of a similar level in Unigine, only there the editor immediately pulls the entire scene without the need to load platforms into blocks through code (but for Unigine, a much more powerful computer is used).
As a result, in the demo version of Wild Engines there are 4 cars, one of which must be selected to start, and two small levels (Level A and Level B). A couple of early maps also remained (Levels 0 and 1), but they are even more test and the landscape there is not optimized.
Full screen mode and shadows can be turned on / off in the menu.
Buttons 1, 2 and 3 change the position of the camera. The mouse aims and rotates the camera, the more the further the cursor is from the center.
WASD - move. PgDown - jump. Q - random impulse.
Left mouse button - shot.
By Enter, a hint about control appears and a button to return to the main menu, where you can change the machine / level.
Win64 version (42 Mb): DROPBOX wildengines_x64
Linux version (44 Mb): DROPBOX wildengines_linux
Bonus
And here is one of the newly emerging new mechas, the Necromancer:
You can ride it in the Unigine version.
Another new mechos, pink with blue backlighting, Debag, is both here and there.
There was also one old cartridge lying around ... what do you think, clones of which eight-bit games could be hidden under this name on a Chinese cartridge, if Vangers were a world famous franchise in those distant times?
