City Car Driving 2.0 – Developer Diaries #11

City Car Driving 2.0 – Developer Diaries #11

The dynamic weather system and the change in the change of day and night are key elements for creating an atmospheric and plausible world.

Such systems should generate not only interesting gameplay moments, but also aesthetic.

Before proceeding with such a large task, it is necessary to answer the question – “What do we want to get?”.
First of all, the time of day and the weather should affect pedestrians, traffic, turning on lamps on the street, light in the windows of the houses and handling of the player’s car.

This means that changes in states should be stored in a place to which it will be easy to connect from the outside, and at any time you can get the necessary data.
Secondly, all this should be visually displayed, and as close as possible to reality. For example, surfaces get wet during rain, and after some time after the rain they remain wet.

Clouds smoothly tighten the sky, with which shadows disappear from more scattered light. And all this should look great at any time of the day.
Thirdly, it should be easily customous, controlled and expanded. We should have the opportunity to add new weather for the future development of the project.

The weather may also be required in certain game situations, it means that it should be possible to change it from other classes. Also, artists should have access to all necessary parameters in one place, for point setting of graphics.

Ok, the goal is set that next?
To begin with, having looked at the points, you can exhale and calmly throw out all thoughts about the system of calculating the weather change relative to temperature, humidity, magnetic storms and the fact that the player washed the machine.
And, having looked at the practice of other companies, take ideas with a predetermined weather forecast. So we solve two problems at once: the need to make a bulky system with weather generation and the fact that in random generation we may have conditions when the weather will not look attractive enough.
Then you need to think over the architecture of this system. Here blocks of the circuit block come to the rescue.

To observe the cleanliness of the code and the distribution of logic, the entire system is divided into four Blueprint class.

  • Bp_Planettime – is responsible for the course within the game time
  • BP_BIOME – sets basic level settings, its geographical coordinates and possible weather
  • BP_WeathereSystem – calculates the current weather and the transitions between its conditions
  • Bp_levelvisualization – accepts data from all three previous classes and on the basis of these data, sets visualization


This is a class whose responsibilities go far beyond the boundaries of the weather system. Traffic, pedestrians and even hours on the phone, should receive the exact time, know about the past minutes, and some elements should be able to rewind time.
For the implementation of such functionality, interfaces are well suited. The time class at the start is searching for interfaces, reports to everyone who found a link to himself, and at the time of the game causes an event to which those elements are signed that needs it.

Thus, each element will decide whether it needs to do something after the event or not. And if it is necessary to stop the movement of time, we will have one entry point for this.

The passage of time itself is implemented through the timer in Blueprints, where the set time is added for each call, after which the seconds are rounded, minutes and hours. The obtained values ​​are stored in the structure and can be obtained by everyone who has a link to BP_PLANETTIME

Additionally displayed parameters for setting up playing time, how many seconds/minutes/hours pass in the game in a real second. Plus, the functions for stopping, rewinding and receiving time in text format for intra -game watches are introduced to this.


This class is easiest to implement, it sets the values ​​of latitude, longitude and mixing of the North at the level. Filters of possible weather in this location can also be set.

In terms of architecture, he also transfers a link to himself along with the data we set.


This class should receive information from BP_PLANTTIME and BP_BIOME, determine the condition of the weather, and most importantly, implement the transitions between them.

But where to keep all the information about the weather at every moment of time of each day? So that all this is not fun in memory. Plus, the system should be convenient to fill out in order to quickly make a monthly forecast, because we need to achieve visual diversity.
To solve these problems, a weather forecast was introduced in which a list of days is stored, and in each day a set of temporary segments with its weather values ​​is already stored. Each segment has a time of its beginning and end. There is also a standard condition that the weather will go to, if for some time, weather forecast will not be found.
Store weather forecast was decided in Data Assets format. This is a way of storing data in Unreal Engine, which includes not only values, but also functions.
The first thing is Primary Data Assets, in which all the necessary variables and functions are announced. And then, on the basis of this, Data Assets are created to fill them with unique data.

Here is a function from Primary Data Assets to search for the weather on the day and hours

But how many parameters will be in the weather? But rather, even how long it will be to set them every time for all intervals for each day? Obviously more than one that will already take a lot of time. So the idea came to introduce weather presets, which will contain information about rain, cloudy, getting wet, fog, etc. And here Data Assets were also used here.

It remains only to resolve the issue with the transitions between the weather conditions. The instant transition is definitely not suitable, which means that we introduce for each time period the duration of the transition to a new state. But the linear transition will look boring, so add the transition curve.
The curve should go from 0 to 1 to 1 and software, which will allow it to count for any values, multiplying by the duration and the delta between the initial and targeted value.

Only now the transition from sunny weather in the rain will consist of the simultaneous appearance of clouds and rain, which means that we add by the curve to each parameter inside the preset. This will allow us to configure the rapid appearance of clouds with the slow appearance of rain.


At the same time the easiest and most complex class. From the point of view of architecture – he only receives data from all three previous classes and transmits them to visual components. The only thing is to compare the issued weather conditions and the settings of clouds, particles, sky and everything else. It is so simple that a separate diary will be written about it.
Thus, we have implemented dynamic weather, with the possibility of flexible setting up all the parameters, which allows you to receive completely different combinations and allowing a quick amendment and settings.

Development diaries come out every two weeks. Do not miss!