---

Following article was written and contributed by Sylvain Douce 'Channie'

TOOLS OF THE TRADE: MAKING A BETTER GAME THROUGH THE TOOLS

Jim Brown begins the first afternoon talk. His lecture is about level design tools and how they can save your life, called "Tools of the trade : Making a better game through the tools".

Jim starts with a little story about a senior designer asked to test drive new technology. He used the exact same tools for years. The new tool allows him to gain 2.4 minutes a day. He doesn't see it as a major breakthrough. But he's wrong.

If a hundred people are using this tool, they'll gain 2.4x100= 2400 minutes = 4 hours a day. 4 hours is half a working day, so the team will gain 20hrs per week....2 weeks per month....1 month every two months... So 6 man-months is equal to a complete year on the project. What could you do in one year on the project ? Lots of things, obviously!

At Epic Games, each time a project is completed, just before being shipped, a focus group (comprised of team leads and key players) sits down and does some bug triage etc... The group is about 12 people, so one man become one month. What the entire team is capable of doing in one month will definitely make the difference in polish. It will make the difference between good and great.

Time for a practical application.

"Every designer, even without Max or Maya knowledge, could quickly block in some volumes and get a playable demo literally in minutes! The idea is to build very basic shapes, put together whitebox of the level. It allows fast iterations: you can test the gameplay until it's fun."

Jim uses Unreal Engine for 10 years now. He knows the benefits of great tools, and he knows the many unreal licensees need great tools too. Using the level design process behind the making of the "Assault" map for Gears of War 2, he shows us what Unreal tool served purpose during the crafting of the game. Jim starts with the BSP, which is often overlooked as a deprecated tool since it's not adapted to the current generation hardware (it was adapted to the 3dfx voodoos and nvidia tnts). BUT it its incredibly useful for prototyping!

Every designer, even without Max or Maya knowledge, could quickly block in some volumes and get a playable demo literally in minutes! The idea is to build very basic shapes, put together whitebox of the level. It allows fast iterations: you can test the gameplay until it's fun. You can then add some layers (upper floors, lifts,...) without harming the level, instead of doing this at the end of production where a tiny modification can have huge repercussions over the art team! Once this phase is done, the gameplay is already rock-solid and ready to be sent to the art department.

Jim takes a second example with pictures of DM-Deck16, a famous map for Unreal Tournament '99. He took the BSP and then converted it into collision with a few clicks, then passed it to the art team. The collision was the gameplay reference the artist must keep in mind, and they did their 3D models in respect of these constraints.

The Deck16 example proved a point: once you've established a solid foundation to one of your level, you don't have to change it when doing a remake. You just have to find a balance between a big blank whitebox and a more evolved version.

Back to the assault level (the map is the exact same from a talk Andrew Bain has done a year ago, and is still watchable here -right click save as, 300MB-). Using BSP he quickly made the vehicles, the bridge and the environment.

The Deck16 example proved a point: once you've established a solid foundation to one of your level, you don't have to change it when doing a remake. You just have to find a balance between a big blank whitebox and a more evolved version.

Lessons learned:

• it forces a design mindset
• it's fast, quick and easy
• it allows quick collision creation
• it's tried & true.

As a conclusion, Jim says BSP is not shiny, but it has been here for years.

The second tool Jim is showcasing is the new Unreal Generic Browser. In my opinion the same principles apply on most of the moddable engines out there. The generic browser lists all the assets a game is using. When creating an AAA, hundred of thousands assets are created! (textures, sounds, localization, ...). So a browser helps you to stay organized. But it won't help you if you aren't rigorous. You'll have to set up naming conventions, because you don't want to spend time on searching for assets. Every minute you search for an asset is a minute you don't actually spend on making the game. So they added a filter browser (type part of the name of an asset and you'll get it instantly), a tag browser (every door model can be found using the corresponding tag) and a shared collection browser (useful to share models and sounds with your co-workers).

The third tool is the ability to work in realtime. OK it's not really a tool but a feature of the editor. Every thing you do will automatically update the viewports. You can see the results of dropping a light or scaling a model. Jim shows a Matinee script (the Unreal cinematic tool) and tell us how easy it was to iterate on a cinematic in realtime without having it wait to render in a traditional offline CGI process.

The fourth tool is Lightmass, a recent addition allowing radiosity and an overall improvement on lighting quality for unreal games. Jim says it makes the light guy gain time by freeing him up from painstakingly placing counter-lights to do hand-radiosity.

Time to showcase Kismet, a visual scripting tool. To Jim Kismet is easy to pickup since it does not involve writing lines of Perl or Python code. Here, all you have to do is connect boxes together and watch the result. So any designer can pick it up very easily, with no programming background required. At Epic, they do the guns prototyping with Kismet. No programmer is involved. Someone even did a golf game only with Kismet! As a conclusion, Jim admit Unreal can be a bit intimidating at first, but after a while, it starts to rock.

Jim invites us to take a step back; Unreal is just one toolset among many others, but still, you have to take the responsibility to know your tool and what you can do with it.

At the end of the day, your game is good or not. It's not about the tools, but the game. Keep always that in mind. Efficiency wins out over artistic capability.

Don't be afraid to watch someone who KNOWS what he's doing. Don't be afraid to ask for help. Network with all the guys in your team. But you can be more than that: you can be the champion.

How?

• Read the technical documentation
• Read monthly build release notes to stay on top
• Don't be insular: your game can't be good if you keep it to yourself
• Do some proofs of concept, present them, share knowledge.

POCs or Proofs of Concept are faster to do than going through the traditional heavyweight pipeline (documentation, paper design, feature requests and so on...). POCs are more compelling than paper design, it helps selling ideas to your leads. At Epic, the big fat enemy guy with a shield was not present in the initial design, they POC'ed it during a Free Friday using the standard grunt, scaling it up, attaching a door knob on the head and a trashcan as a shield to one of his hands...and voila! It convinced the team and it was added into the game. The Free Fridays is an initiative at Epic allowing the team to work on other things every other friday, after a milestone.

You're welcome to ignore the schedule, ignore your current tasks and do something else that will benefit the game or the company. That's how the big fat enemy guy was born. Designers usually do technical documentation and prototypes in kismet. If it's compelling, it might end up in the game. Challenge yourself! This is not only about the tools, but about making you a better designer!

Be the first to understand the tools, the honor will be on you. At Epic, they have an open policy about the tools: if you feel some of the tools are badly designed, you can tell your leads and your bosses about it: they'll welcome the feedback! Your goal is also theirs: eliminate bad tools and replace with better ones. You will perform better, and your team as well!

Stay open minded, avoid tunnel vision (schedules, processes...) even when things are going well! Small changes can lead to big impact. As a final word for this lecture "You have to be the screwdriver, and not the screw".

GDC 2010 Level Design Notes Part 1 by Sylvain Douce

GDC 2010 Level Design Notes Part 2 by Sylvain Douce

GDC 2010 Level Design Notes Part 3 by Sylvain Douce

GDC 2010 Level Design Notes Part 4 by Sylvain Douce

GDC 2010 Level Design Notes Part 5 by Sylvain Douce

Get the Book »