Grid 2019 was my first professional video game project, I joined mid 2018 as junior tools programmer to improve the tooling of the Ego 3 (game engine) used for Grid 2019. My roles included general tooling improvements by adding new features and developing new tools as required by other teams on the project and tool maintenance (fixing bugs and crashes).
Level Editor - Automated Crowd Excitement Zone Placement
The audio team came to me asking if there was a way to automatically place excitement zone used to control the audio levels of different areas of a track because it was very time-consuming to do and maintain over the course of the project. One of the issues was that level design and environment art would periodically change the track layout or positions of crowd members which would trigger the audio team to go in and validate the zones to make sure in-game audio is correct.
My solution was to extend the level editor with specific functionality that would subdivide the track into segments and count the amount of people inside a segment, after going through the whole track the total can then be averaged and grouped according to specific criteria the Audio Designers determine. This process is repeated for each route on a given track and the final settings are saved in the same format as the hand edited versions (allowing for any changes to be done manually should the tool fail or specific one-time settings be required).
The final produce reduced 30 days of work per track (over the course of the whole game) to 30 minutes of fiddling with sliders and periodic re-generation as required. Generation settings would be saved into level files so once settings are dialed in they just need to be re-run in order to update the data as required.
Overall the Audio Team was delighted with a new tool to improve their effectiveness.
One of the issues that the environment team came across is that for some levels inside GRID the terrain would be extremely large with entire levels consisting of 3-8 pieces. This worked fine in game but when analysing the performance of some consoles an issue came as these large pieces where almost always on screen so the entire mesh had to be drawn instead of just the small piece that was on screen. This was quite late in the project with GRID shipping in a few months and the environment team didn't have the time to split the terrain into multiple pieces manually.
Source: Split Unity Terrain Script by Darrell Bircsak
The solution was to get the asset builder to convert the terrain meshes into tiles dynamically before converting the resulting mesh into the final binary package for the game. This task was given to me, and I spent a while time looking at triangles with intersecting lines (like a mad man). I found that 5 categories of triangle splits would be all that's needed to split any mesh into efficiently packed sub-meshes which the game can then selectively use as the occlusion system dictates.
5 split categories came from the amount of configurations that I deemed reasonable. 4 where configurations of simple triangles spanning 1-3 boarders, with the remaining one simply splitting along an axis and passing both resulting triangles back into the splitting mechanism recursively which would then match with one of the other triangle splitting configurations. As part of development I remember keeping track of the triangle split type and over 96% of the splits where very simple with a single tile boundary line going through the center of the triangle with the rest being at the intersection of tiles.
Once it all went into the asset builder a single config file would control the general size of tiles with specific settings being possible for each terrain segment as required by the artists. This saved a fair amount of time that was not otherwise available at that stage of the project and since it's an automated system all terrain segments were split into tiles from one Asset Builder version to another!
By the end of the project I had spent most of my time working in the asset builder which is not very visual and quite specific to the Ego engine and how it handles resources, so there is not a lot that I find interesting enough to share. The level editor also had a fair amount of work done on it but again, it's all either super specific to how it works or just boring to read/write about...
© 2019 The Codemasters Software Company Limited (“Codemasters”). All rights reserved. “Codemasters”® and the Codemasters logo® are registered trademarks owned by Codemasters. All Rights Reserved. All other trademarks or copyrights are the property of their respective owners and are used under license. Developed and published by Codemasters.