We are hard at work with new levels with shiny new tools! In today’s post I’ll tell you all about how we work, why it takes time to make a level and what we’ve been doing to remedy this.
You have to consider that for every new, unique environment we want to put in the game, there is a lot of man hours and coordination involved. The environments have been created first, that is, the textures and geological rules for how the terrain features should be generated. A new one of these is a big decision as it takes time to make and affects everything that will go in it. We stick with it for potentially many maps. Then level design and level building is done using one of the environments, and any special models can be planned alongside this. A new environment can also be planned and created alongside a level design. When planning new models, we aim for re-usability, not only to have the option to place it in other levels, but also in case anything should happen to that special level they were made for. If we decided to cut a hypothetical Paris-level, it would be a shame to have a beautiful hypothetical Eiffel-tower just sitting on our hard drives! These are just some of the considerations we need to take into account when we want new map content in the game.
With that being said, we recognize that it has taken a long time to get new maps out. That’s why we have been changing up some parts of how we work. There are two main approaches we have taken to improving our map creation process. One is crafting tools like the new terrain system. Automation of repetitious tasks is another of the solutions involved in our new workflow. This way we work smarter, not harder. Wait. AND harder. But no one works as hard as the Automotons! Automobots. Automotoicons (Automatons, Ed.)
New terrain system for XSI
Autodesk SoftImage (a.k.a. XSI) is our main editor for models, animation and – you guessed it – level design. Now we are moving even more of the tasks involved in building a new level to XSI, much thanks to XSI’s support for customization. We can code plugins, write small scripts (that we run in XSI’s script editor), or use XSI’s built-in visual scripting language ICE to write rules for how 3D-objects should behave in the level. Reto.RedBjarne has recently been busy writing some plugins and ICE-scripts for faster landscape building. The new system affords us to move our work back and forth between the software involved in making our maps (predominantly World Machine 2 and XSI). Previously we moved more from one to the other in a waterfall-like fashion. For more details and images on how we have built the level terrains until now, see Reto.Fleck’s blogpost on the topic here.
In our new system for making terrains, we can start with modelling a basic polygon mesh for the landscape and create a heightmap from that, which we then can bring into World Machine to get some nice natural effects on it, like erosion (see picture above), then bring it back into XSI and continue designing for game-play. We can also fine-sculpt the terrain mesh in MudBox or ZBrush. In other words, we bypass a lot of previous workload in World Machine where we created our heightmap by specifying rules that generate the terrain based off of top down drawn shapes (see picture below). This made it difficult to create accurate areas or quick tweaks as the heightmap would need to be re-built every time you made a change before inspecting it in the game. Now, we utilize the best from two worlds instead. Advanced 3D-modelling software like XSI for laying out the level elevations and crevices just as we like, and World Machine for the natural ageing process look. The new system also allows us to review our game-play earlier during the level building process, as we can take the level for a spin even before we have any heightmap at all. It lends itself well to iteration, as we can add more and more details to the landscape mesh alongside testing the level design.
Automation from outer space!
Reto.RedBjarne has also made tools for automating or speeding up some tasks we do often, like aligning and rotating objects like fences to follow the ground along a curve. There are definitely better things to spend time on than doing that by hand. As I’m ordained by Her Majesty to be one of those privy to level designer needs, I’ve also tried my hand at making some simple automation scripts:
Here is a screenshot of our level “MediumFrenchVillage” before and after you click my custom Adjust-Camera-button™. In the top image, our map gets cut at the camera’s far clipping plane. In the image in the bottom the “Adjust camera” script has been run. Now you can zoom very close or very far out and still see everything in your view-ports. The way it works is quite simple, but it removes workload and doesn’t make you run off looking in menus in the middle of a task, disrupting your flow. Previously you had to go into a view-port’s current camera’s properties menu and set the camera far or near clipping plane distance parameters to be bigger than the tiny default. Potentially, if you check your level in every camera (top, left, right, perspective) in all four view-ports, you would have to enter the camera settings 16 times. Every time you restart XSI. Every day. Phew! Instead we can set the script to run on startup, or you can just click a button once when you need it. This script is mostly useful for the level designers and our environment artist Reto.Dave, as we need to have the overview and move stuff around big distances a lot.
In World Machine we used to draw our roads in vector splines and export them. Another script imports the splines to XSI. It then scales and positions them to fit the terrain and replace the old ones. The scaling and fitting was previously done by hand… These splines are used to project our road textures on top of the terrain when we pack the map. Roads need to go where they are supposed to, and not through walls or into rivers, so it’s important to get these set up right. Again, we are looking at doing more of this from XSI from the get-go, but I still use the script regularly for previous levels.
I’m also working on a script that can be run on a group of spawnpoints and hover them just above the ground, so that you don’t risk spawning below the ground or having vehicles spawn on top of each other. Manual placing can be hasty before polish, which could lead to unfortunate results. Place your spawnpoint below the ground, and your soldiers will drop to their deaths in the endless abyss beneath the gameworld (see image below). Place the spawnpoints too high and you are similarly gonna have a bad time. The script saves time so that we can quickly set up an access point at a position without having to manually fine tune all of its spawnpoint’s positions until we are entirely happy with the accesspoint location itself.
With the new terrain system in place, I’ve already gotten some ideas for even more automation of the new “patterns” we are using in XSI. Maybe some of you guys have some suggestions or similar experiences? If not, I think it is time to get back to whipping out more maps!
[Ed: Secret intelligence informs us of amazing progress already in the level designer’s division after instating the new terrain system. Looking forward to serving you some freshly made maps in the near future!]