
When it became clear to us that the original City Car Driving engine was very outdated, we began to look for a new solution that would be:
- Actually developing and interesting for specialists.
- Scalable, which would be suitable not only for a new game, but also could be used in the future for our simulators.
- Optimized for modern computers.
Our search stopped at the Unreal Engine, first of all because of its flexibility in operation and the variability of tools that allow artists and designers to perform many tasks independently. 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 UE4, used internally, after which we transferred all our developments to UE5 in CCD 2.0

Let’s start by creating a landscape. The main part of the landscape and roads are created by a generator specially developed by us, which is not part of the UE. Using the same generator, the main AI of urban traffic is created, as well as the logic of pedestrians. As a mandatory feature, traffic control is attached to this. A side part of the landscape is completed by artists as 3D models. With this approach, we can ensure for ourselves a high speed of creating locations with an extensive network of roads and a realistic landscape.

The screenshot shows how the location is filled: objects without textures and detailing are a blockout (a blank for an object). Level designers, when filling the location, work in parallel with viewing the physical properties of the location so that there are no holes or invisible walls. After filling the location, the objects are checked for a collision with the player’s car.
IWhen filling the location with objects, we use internal developments for automatic placement and generation. In the development process, designers and artists use industry-standard optimization methods:
- Levels of Detail (both manual and automatic).
- Geometry Instancing.
- Material Instancing.
- Combining textures into atlases (both manual combination and automatic when creating HLOD groups).
PBR (Physically Based Rendering) materials are used on the objects with the possibility of their customization by level designers.

Reflections in the game work on the basis of PBR materials (Roughness-metalness). Thus, materials without roughness have a reflectivity. At the same time, the reflections themselves are generated using SSR (screenspace reflections) technology.

To make the above reflections more realistic, we have added reflections based on HDR (High Dynamic Range) on the car. The reflection capture mode is displayed on the right side of the screenshot. The mode displays the calculation of reflections in real time, this is the main technology that draws reflections on textures.
At the very beginning of development and at every stage, from the first polygon to the last pixel, we were focused on maximizing the optimization of the game. At the same time, we try to achieve graphics quality that meets the industry standards, adjusted for the chosen style.
UE allowed us to choose one of two types of shading – Forward Rendering or Deferred Rendering. Forward is faster in some cases but makes it impossible to use many effects, reduces the overall performance and quality of dynamic lighting. Thus, in order to maintain the balance of the availability of modern graphic technologies, the speed of work and the capabilities for optimizing the final image, we settled on the Deferred Shading.
Having decided on the type of shading, we moved on to the basic lighting settings.

It was decided to make the change of the time of day dynamic, so the intensity of the color of the sun and the filling light will be changing. Further, when determining the presence of dynamic light sources (lampposts, illuminated signs, interiors), performance measurement tests were carried out. The measurement results showed that it is necessary to combine different lighting methods – realtime (from light sources in the engine) and baked (glow within the texture).

Shadows iare implemented using various UE lights functions and baked shadows at the model level. For example, “cascade shadows” work near the player. The shadow processing mode is shown on the right side of the screenshot.

At a distance, cascading shadows disappear and DistanceField Shadows, much lighter for the performance, turn on.

Will there be different regions, countries, etc. in CCD 2.0?
In early access, we plan to release only one region: a southern city near the sea, in the future we plan to expand and add game locations.
In CCD 2.0. will there be an imitation of damages to the car, after which it loses its functionality?
It will be, in future diaries we will definitely tell you how we want to implement this functionality.
Will there be cars from the original CCD in 2.0?
No, we want to preserve the uniqueness of the products and will not mix vehicles. There will only be new cars in CCD 2.0.
Will there be TrackIR support?
At the moment, support is not being considered.
Will there be VR support?
There will be no support in early access.
Will there be an expansion of social interaction with the audience? For example, a discord server, for the opportunity to discuss the game, or to communicate directly with the developers?
Yes, it will. At the moment, we are preparing a discord server, and as soon as we are ready to launch it, we will immediately inform everyone.

For now we have touched only a part of the technologies used. In the following diaries we will tell you more about the graphics.
In the next issue, we will talk about the methodological component in the game and show exercises in the car-racing track. Dev diaries are released every two weeks, where we talk in detail about the development of the game. Don’t miss them!
