In the last blog post we made an overview about the development of Autobahn Police Simulator 2. This time I want to tell you about our road creation tool, which we build and started to use for ABPS1.
Why did we develop a tool for road creation?
People who already created a game world would agree that it takes a lot of time to create a decent world map. Additionally every game has some specific requirements.
In our case we needed:
- Fast and easy designing roads. They look similar (highways look similar from geometry point of view), but have to be long enough to drive very fast.
- Possibilities to change directions (using bridges to cross the highway)
- Information for AI agents: the AI had to know how fast they could drive, how many lanes there are, where to leave the highway, where the player and the other AI agents are, etc.
- In Germany the highways are not just straight roads, they wind and curve like strings.
These points seem quite easy and fairly straight forward, but they aren’t. Different projects need different data from a tool. Some projects need only the geometry, some need more information. We needed more data about the road for the AI and for our map and navigation system. And after evaluating some tools we decided to write our own.
The first approach used some predesigned road parts for the whole autobahn and predeigned exits and entries, but this caused some problems in terms of the highway’s length. The lenght was always n*length_of_the_part and this was not flexible enough for us. That’s why we decided to use a mix of procedural generated parts and predesigned parts in ABPS1. We designed the exits and entries of the highways and the parts in between were completly procedural generated. The “simple” parts in between were on a spline, so a level designer could control how the highway looked like. We only had 2- and 3-lanes highways, so we couldn’t make it too complex for the first Autobahn Police game.
One issue was left. We couldn’t use Unity3D terrain due to some problems with streaming and memory. As a workaround we generated meshes with terrain texture on the side of the road geometry. This in turn caused a problem with geometry where the meshes might not fit (which created some other problems ), but for ABPS1 it was enough. At the time we simply didn’t need fancy terrain effects and with our geometry it was manageable even for older hardware. After the initial release of ABPS1’s PC version we used the same data for the mobile version, where we had to scale some things down a bit, but the road data is the same.
This approach worked well for the first ABPS installment, but we learned several things, which we had to fix in the next game:
- All exits and entries looked the same, this would have to be fixed in the sequel.
- Connections between the procedural and designed geometry were very complicated.
- During the development of ABPS1 we noticed that a realistic length for exits and entries and the whole world was not ideal, but reducing the length was not easy either because they were already set in the world. After our designers reworked them, we had to fix the connections to the procedural street parts in the world.
- Level design couldn’t do any editing by themselves, they always had to wait for artists, who had already too much work to do.
- The game map was relatively simple, but the players wanted more authentic and more complex highways.
So we decided to improve our road tool in order to build better and more varied highways. Our programmer decided to make a layer where we could define road parts. We named these objects “Road definitions”. This allowed us to make different road types (not only highways) and make parts for road exits, driveways, road extensions and reductions. We got a very powerful tool, but we underestimated the complexity to work with it, because someone had to create the road definitions and after that they had to be placed on a spline in the right direction to achieve their full functionality.
For example to achieve a realistic highway exit we needed to follow a couple of different road definitions. Here is sample from our internal documentation:
As you can see we needed six different road definitions and this was only for one exit. Different permutations of exits and entries for one or two lanes from two or three lanes highway etc. lead us to a big number of different road definitions. For ABPS2 we created them manually.
One on hand we now had this powerful tool, but on the other hand came a lot of work with it too. The creation of such an amount of road definitions (which even grew during development) was not very effective. We added all the road definitions manually to the road splines and we figured out that although we were very flexible with the length of each road definition part and their permutations, we also noticed that this was not very useful because the spline was way more important for actual variety.
During the development we faced a lot of issues we weren’t aware of when we started to make the game but we were able to fix a lot of them. While for others we were only able to solve for ABPS3. One of the problems was to connect the splines between the Unity scenes (because the size of our world we worked with a new scene for every level chunk) and especially to inherit data from the parent spline. The goal was that the child spline continues the direction of the parent spline.
So this was the second big iteration of our road tool. It saved us a lot of time creating the world again! Although it wasn’t perfect.
And here are some features that we changed and improved for the development of ABPS3.
Issue 1 – big number of road definitions:
We developed a generator which creates road definitions with a variable number of lanes and then automatically creates the permutation and transitions between these road definitions. This was possible because there are rules for the roads and we could use them. Additionally we had to create a feature to avoid holes in the game, so we needed some geometry on the border and to save polys on geometry, we made some variations. So now we have all together over 500 different road definitions. Some of them we will never use, but it was easier to calculate more road definitions with all kinds of permutations than exclude some from being generated. And who knows… perhaps they are needed in the future.
Issue 2: The problem with a big number of road definitions
We had to place a big number of road definitions in the right order to achieve special roads. For ABPS3 we decided to save time and improve our system. So from now on, some predefined groups of road definitions could be used for Level Designers. For example from our image above, now we simply needed one road definition group to set an exit. This makes the level and road design much faster with fewer bugs due to incorrect definitions.
Issue 3: Lanes for diferent directions
We started with the wrong approach for one feature during our development of ABPS2. We thought we could easily mirror the lanes for the opposite direction, but this was not possible because of the highway structure. So we had trouble making two splines fit in road curves. Especially because we also used a flexible height for roads so they are not completely flat. This problem was very complicated to hide in ABPS2 and we needed more geometry in the end, which didn’t look too good and needed more memory space as well.
So in ABPS3 we created the possibility to use one spline for different directions and different road definitions. From now on we can have a comfortable function which avoids a lot of problems in level design and make it possible to make better and faster roads.
Issue 4: static size of roads
In ABPS2 we noticed too late that our lanes were not always easy to drive on, but we couldn’t change the size of the roads that easily because we had to update all the road definitions first, then we had to update the level design in the whole world (around 50km of streets). And at the end we had a lot of trouble fixing bugs, so we couldn’t fix that problem anymore. This is one reason why it is very difficult to drive on some roads in ABPS2 and an even bigger issue is that the AI did not have enough space to react to the blue lights and police siren, so in the game the player got the impression, that the AI doesn’t react to them, but it does!
For ABPS3 we avoided this problem with the road definition generator which I already described above. Now we can regenerate the road definitions with different road sizes very fast.
Issue 5: border terrains, which worked in ABPS1 lead to problems
Our border terrain solution (as we called it) worked for ABPS1 and for mobile versions. In ABPS2 we had trouble with it because of the complexity of the roads which lead to clipping of the border terrains. This led to holes in the world and unused geometry which was covered by other geometry. Another problem was the features for vegetation and texture blending on terrain, which we had to implement manually. We optimized it, but it was still not flexible enough like actual terrain. But this time we could use the new terrain engine from Unity. It is not perfect, but the new terrain system fits our requirements much better than the other two options.
Conclusion
From over 12 years of game development we know the power of internal tools and the road creation tool was no exception. This tool gives us a possibility to make content that was not possible without. And from project to project we improve the tool. Of course our sequels set new requirements to the tool, so an improvement was inevitable.