Today we will talk a little about technical solutions at City Car Driving 2.0: About the engine used when creating the game, let’s talk about the schedule, show several working materials.
When it became clear to us that the initial City Car Driving engine was very outdated, we began to look for a new solution that would be:
- Relevant and interesting for specialists.
- Scalable, which would suit not only for a new game, but in the future could be used for our simulators.
- Optimized for modern computers.
Comparative testing of four game engines was carried out. As a result, our searches dwelled on Unreal Engine, first of all, because of its flexibility during work and variability of tools, which allows artists and designers to perform many tasks on their own. In addition to these reasons, the undoubted advantage of UE is its compatibility with our internal editors: landscape, traffic, and so on.
About a year ago, we created a pilot project on the UE4 used inside the company, after which it was decided on a smooth start of work on CCD 2.0, in the future, we transferred all our achievements to UE5.
It all starts with the creation of the landscape. The main part of the landscape and roads are created by a specially developed generator, which is not part of UE. The same generator sets the main parameters of the AI of city automobile and pedestrian traffic, as well as the logic of their work. Mandatory control of traffic rules is attached to this. The secondary parts of the landscape that did not fall into the generated area are completed by artists as 3D models. With the help of this approach, we can provide for ourselves a rather high speed of creating a realistic basic landscape of locations with an extensive network of roads.
The screenshot shows how the location is filled: objects without textures and details are BLOCKOUT (workpiece for the object). Level designers, when filling the location, also use the mode of display of the location physics, tracking the “holes” or invisible walls. After filling the location, objects are checked for the possibility of conflict with a player machine.
When filling the location, we use our own development tools to automate the arrangement and generation of some types of objects. During the development process, designers and artists use standard optimization methods for the industry:
- Levels of Detail (both by hand and automatically generated)
- Geometry Instancing
- Material Instanceing
- Combining textures in atlases (both manual combination and automatic when creating HLODS groups)
All objects use PBR (Physically Based Rendering) Materials with the possibility of flexible tuning them with levets designers.
Reflections in the game work on the basis of PBR materials. Materials without roughness (ropehness) have a pronounced reflective ability. Reflections themselves are generated using SSR (Screenspace Reflections) technology.
To give greater realism to the above reflections, we added reflections based on HDR (High Dynamic Range) by car. On the right side of the screenshot – an image obtained in Reflection Capture display mode. This regime demonstrates the miscalculation of reflections in real time, it is the main technology that draws on reflection textures.
At the very beginning of the development and at each stage, from the first landfill to the last pixel, we were aimed at the maximum optimization of the game. At the same time, we try to achieve the quality of graphics corresponding to the standards of the industry with the adjustment for the selected style.
UE allowed us to choose one of the two methods of Shading – Forward Rendering or Deferred Rendering. Forward Rendering in some conditions "faster", but deprives the possibility of using many effects, complicates the miscalculation and reduces the overall quality of dynamic lighting. To comply with the balance of modern graphic technologies, the speed of work and the possibilities of optimizing the final picture, taking into account the use of dynamic lighting, stopped at Deferred Rendering.
Having decided on the type of shading, we moved to the basic lighting settings.
The change of time of day was decided to make dynamic, so the intensity of the color of the sun and filling light will change. Further, when determining the presence of dynamic light sources (lampposts, luminous signs, interiors), tests and measurements of performance were carried out. The results of the measurements showed that it is necessary to combine various methods of lighting – dynamic (from certain sources of light in real time) and static (imitation of illumination within the texture).
Shadows in the game are implemented using various UE functions and baking shadows at the models level. For example, near the player they work "Cascaded shadows". On the right side of the screenshot – the mode of processing shadows.
In the distance, cascading shadows disappear and turn on Distancefield Shadows, much easier for a computer.
In CCD 2.0. There will be different regions, countries, etc.D.?
In early access, we plan to release only one region: the southern city near the sea, in the future we plan to expand and add game locations.
In CCD 2.0. there will be an imitation of damage to the car, after which it loses its functionality?
It will be, in future diaries we will definitely tell you how we want to realize this functionality.
There will be cars from the original CCD to 2.0.?
No, we want to maintain the uniqueness of products and will not mix transport. In CCD 2.0 will only be new cars.
There will be support for Trackir?
When the project is released in the early access of support.
There will be VR support?
When the project is released in the early access of support.
Will there be an expansion of social interaction with the audience? For example, a discord server, for the opportunity to discuss the game, or directly communicate with the developers?
Yes, it will be. At the moment, we are preparing a discord, and as soon as we are ready to launch the server, we will immediately inform everyone.
We touched only part of the technologies used. In subsequent diaries, we will tell you about the schedule.
In the next issue, we will talk about the methodological component in the game and show the exercises on the Avtodrome. Development diaries come out every two weeks, where we talk in detail about the development of the game. Do not miss!