Developers diaries #27

City Car Driving 2.0

City Car Driving 2.0 is a driving simulator designed to help novice drivers master driving in a setting as close to reality as possible.

So we are sharing the work process through the example of such small mechanics as window opening and closing and windshield wiper operation. [previewyoutube=K0WyiwMkc6E;full][/previewyoutube] The first video shows preparations for creating the “window opening | closing” mechanics. First, we create a window controller component that belongs to the base class. This is done so that in the future, when the player adds new cars, this controller will automatically find them without additional modifications. Next, the controller logic itself is written. First, we get a link to the car. The purpose of this is to get the active car that the player is currently driving. Afterwards, you need to add window components to the car itself; they are assigned a tag so that the controller automatically finds windows using the specified tags. After the tags are added, the logic of automatic window search is implemented. We search for tags through cycles and note down a link to the windows. Further logic will use these links to access windows to open and close them. At this stage, the main thing is to determine at the very start the correct type of class to refer to when searching for windows. The video shows that it was determined incorrectly the first time. In the viewport (where the car model was), the developer selected transformation data that would participate in further logic. During this procedure, the problem of an incorrect class was discovered, and the class had to be changed in the automatic window search cycles, which is why errors appeared. We would like to specifically note that in some cases, you have to manually change the logic on Blueprint. When the class is changed, not all nodes can be rebooted.[previewyoutube=RYM_vWUtLKk;full][/previewyoutube] The second video is the longest and is where the main workflow takes place. After the initial logic has been written, we need to write an input filter: how the input system can understand and pass logical data when a button is pressed. When developing similar mechanics, our team always takes already implemented code as a basis. The reason is that the initial logic is most often the same and, to save work time, it is no use to write the same thing every time when developing a new mechanic. Therefore, at the beginning of the video, there is already a part of the previously written code. Next, we adapt the copied code to a different implementation. In this case, the logic is prescribed – what will happen when the player presses the button to open/close the windows. After that, we write a function that will access the window controller and trigger the “start window motor” event in it. The “window motor” works using layered mathematical functions within the input filter. Also, it is necessary to implement the following logic with the limitation, “There must be one button for one window.” How we did it: 1. When the button is pressed, if the window is completely closed, it starts to open. 2. If the button is released, the window will remain in its current position. 3. When the button is pressed again, the window should continue to go down if 3 seconds have not elapsed since the previous release of the button. This is done so that the player can choose the desired degree of window opening. 4. If more than 3 seconds have elapsed, the player most likely wants to close the window, so the window should begin to close. 5. If the player lowers the window completely, then, when the “window” button is pressed again, the window should begin to go up without waiting 3 seconds. This logic is implemented only on mathematical operations and window states. As a result, the filter sends only one value: in which position the window should be in the dimension from 0.0 to 1.0. [previewyoutube=uLWlJ-z2w7A;full][/previewyoutube] Now we need to implement a transformation of the window model based on what data comes from the input filter. First, at this stage, you need to decide how the window will move: along which axes; linearly or nonlinearly; whether a spline is needed to move the window. It was decided that the window would move linearly at the same speed along a spline, since we are working on passenger cars. Their windows don’t just open up/down. Real cars have window guides under the door trim; in our case, splines served as such guides. For each car, you can adjust the window movement for a specific model. You get the current window transformation on the spline. We convert the coordinate value to values from 0 to 1, and move the window to the new coordinates. We arrange all these transformation calculations into an optimization function, since these calculations are called every frame while the window is moving. [previewyoutube=jwYuovHpY_4;full][/previewyoutube] The “open | close windows” function is ready! In the last video, you can see what it looks like. [previewyoutube=4Sfd7mMGjgc;full][/previewyoutube]As a bonus, we attach a video of the creation of a windshield wiper controller. Basically, this is similar logic. We also obtain a link to the car and use automatic search for windshield wipers. Additionally, the presence of windshield wipers is checked because not all cars have a rear windshield wiper. The only obvious difference is the input filter, since here you just need to press a button and change the mode (speed) of the windshield wipers. In the windshield wiper controller, we obtain the required speed of movement of the windshield wipers, and set it in the animation, which was previously prepared by 3D artists.[previewyoutube=O6BQU_OyGFc;full][/previewyoutube]Now you can see the result. [img]{STEAM_CLAN_IMAGE}/44086444/e1587d01f1caf24e0bcc3396dce0d9b36a70038a.png[/img] You may notice obvious graphical artifacts in this log. We specifically note again that the work is still underway: the video does not show the final result. Developers’ logs are released every two weeks, don’t miss them!