Once we've established the high-level flow, the point designer will then create a simplified blockmesh layout of the area in Maya. The idea is to keep this as light and lean as possible using basic shapes so we can rapidly prototype spaces and gameplay. We want to get as much of the size, scale, and positioning of structures right before we hand the level off to the artists. This is because as finalized art comes into the level, making changes becomes much more difficult and time consuming.
As more of the level starts to take shape in blockmesh form, we start to go over the space with the artists to try and catch any potential major issues and address them at this stage. These issues might include visibility and polygon counts (or more specifically vertex set counts for the way our engine works), how much instanced geometry we will be able to use, texture memory count, how can we split the area for level streaming, etc. It's much better to tackle these now while the level is in a malleable state rather than once it's artified.
For exploration and puzzle sections of the game, aside from the puzzles themselves, we concentrate on making sure we meet our jump and grab height standards. Also, the flow of the level and how we lead the player through the environment is very important (i.e. how much do we wish to obfuscate the path from the player?)
We consider sight lines to areas beyond, looking at how we can use the environment to lead the player around by placing "weenies" -- this is a term borrowed from Disney theme park creators used to describe recognizable landmarks that can lure people.
Where combat spaces are concerned, we have more details we have to take into account when laying out the space. Some questions we have to ask ourselves:
We also want to try and find ways to widen the corridor of the playspace to give more options to the player in combat. This doesn't always mean just opening up the horizontal axes, but also the vertical. With Traversal Gunplay we want to let the player use their climbing skills to gain the advantage on the enemy.
Conversely, we want the enemy to be able to use these routes as well if the player decides to hunker down and sit still for too long. We try to encourage the player to move around the space and explore avenues that they normally wouldn't find in any other game. We want them to analyze and use the space differently to gain an advantage. All of this factors in to the layout of the space and how it can enhance the combat experience.
As the level starts to take shape and gameplay is put into the area, we start to iterate over the experience to get feedback, and see if we're heading in the direction of... funtasticville!
To help facilitate this, we've specifically designed our gameplay tools and pipeline to let us iterate through gameplay changes very quickly. The details of how we set up our tools and pipeline are unfortunately beyond the scope of this article, but I feel it's worth mentioning a few high-level points to demonstrate what I'm talking about as the quicker you can iterate on something, the better you can tweak and polish it.
Our pipeline is designed around the data being live on a set of servers rather than residing on our individual workstations. When we run the game this data gets streamed onto our devkits. This way we don't have to take time syncing up the game assets, as they're always available immediately.
There's a few types of data that we as designers deal with: the static background geometry, the foreground geometry (which is anything that can be interacted with, move, or animate), and the meta-game objects used to implement gameplay logic (position markers, trigger regions, splines, etc.) All geometry is built inside of Maya, but all gameplay metadata objects (including foreground geometry instances) are all placed and manipulated in our custom built level design tool called Charter, which is strictly designed for this purpose.
There's no cooking or pre-packaging of any data before hand; it just runs in the engine directly with minimal load times (on average about 45 to 50 seconds from game launch to main menu). When we build a level, we have the option to build just the gameplay data that's placed in Charter. It's a very fast process (usually under 30 seconds) which we can also dynamically reload into the running game to see our changes immediately. The same goes for our scripting language that we use create the gameplay logic.
When you have a very fast pipeline for getting your changes into the game, it frees up your workflow tremendously. Instead of lumping a bunch of changes together due to long load and build times, instead we can focus on specific elements of gameplay, even if it means iterating just one parameter at a time, and fine-tune any part of the experience (i.e. when tuning weapons, AI, puzzles, etc.)