Building Huge Open Worlds: Modularity, Kits & Art Fatigue
Events
Subscribe:  iCal  |  Google Calendar
Cologne DE   22, Aug — 26, Aug
Seattle US   28, Aug — 30, Aug
Atlanta US   30, Aug — 4, Sep
SEATTLE US   31, Aug — 4, Sep
Vancouver CA   5, Sep — 9, Sep
Latest comments
by Arran Dunn
3 hours ago

Awesome

by Mohsin Majeed Siham
6 hours ago

Very nice advice for Beginners....Really Helpful...Thanks....

The link under texturing is broken, here is the correct link. http://docs.cryengine.com/display/SDKDOC2/Ambient+Occlusion+and+Normal+map+bake+using+Xnormal

Building Huge Open Worlds: Modularity, Kits & Art Fatigue
7 August, 2018
Interview
Level Design

Joel Burgess, a true master of open-world games and a level designer who has contributed to the creation of Oblivion, Fallout, Skyrim, and other beloved games, gave a talk on the basic things you should know in order to construct a rich game world, using modularity and avoiding the art fatigue. 

Introduction

I actually began college as a music major but switched to the Digital Media major at the University of Central Florida, which was a new program at the time. (They now offer a game dev-focused graduate degree w/FIEA) I took a broad mix of classes at UCF; a few that were game development oriented, but also classes in topics like cognitive psychology, traditional art, computer science, web development, and film history.

I did some freelance work in college but got my first on-site games job at a studio called Terminal Reality (TRI).  There I worked as a level designer on Bloodrayne 2 and Aeon Flux, as well as a little help on other projects. I was only at TRI for about a year and got the chance to join Bethesda Game Studios (BGS) during work on Oblivion. I’d stay there for eleven years, going on to also ship Fallout 3, Skyrim, Fallout 4, and was co-running Fallout 76 when I left the studio in 2016. Since then I’ve been with Ubisoft Toronto as what’s called a World Director. My work up here has so far been a secret!

Level Design

I started level design as a hobbyist way back in the BUILD engine, making levels for Duke Nukem 3D.  I’d dabble in modding for a few QE Radiant-based games, as well as Hammer and a good bit with Unreal.  I was lucky to work with a great proprietary engine (Infernal) at TRI, and also lucky to be a founding member of the level design team at BGS.  The toolset at BGS was nothing like what I was used to working with as a modder, and it would be gradually improved to empower a good level design process as we iterated over the years.  Now I’d be happy to recommend the Creation Kit to almost any beginning level designer.

I think a great attribute in an LD is the ability to balance sometimes-conflicting needs in a space.  I’ve often referred to LDs as the ringmasters of the game; they have great power to direct the attention of the player towards certain features, content, and experiences.  It’s a huge responsibility, really – when you’re working with a strong team, their efforts are often only seen by players if the levels of the game showcase that work.

In order to do that well, you have to balance a lot of complex needs.  What’s the emotional state the player is likely in? How much range is there between players, based on their playstyle, skill, etc?  What can the engine handle here? What features are going to sing really well? What are the artistic ambitions for the area, and can those coexist with the gameplay requirements?

Learning to balance all those factors can be extraordinarily difficult, and frankly many level designers cannot do it.  This is why it’s important to talk to your collaborators, so they can help you understand the impact of their speciality (whether it’s artistic presentation, technical constraints, or whatever) and help you make the best decisions of when to compromise in one area to showcase another.

Modularity

I had some major influences in my early career, and all I’ve done is learn from amazing people, and share those lessons.  

Lee Perry, then of Epic Games, wrote a terrific article in 2002 for Game Developer Magazine which was the first time I was really exposed to the concept of working modular. Prior to that, I had built everything from scratch, usually with brushes – like basically everyone had been doing at that time.

When I arrived at TRI, Shannon Dees (environment art) and Jake Keating (level design) were working modular, and I learned a great deal from their process.  This is where I also met Cory Edwards and Nathan Purkeypile, both fantastic modular kit creators who would later join me at BGS and champion a modular workflow there.

Photo courtesy of Techvibes

The massively talented Istvan Pely had already implemented a modular approach at BGS when I arrived in 2005, and I fully embraced this with the help of artists like Robert Wisnewski, Clara Struthers, and Rafael Vargas, as well as level designers like Jeff Browne, and others who would join us over the following years.

In all this time learning about modular level design, I think one thing really rang true through the years; you need to embrace and respect some core rules and break them very deliberately, for very specific reasons.  One of the reasons a lot of projects struggle with a modular approach is a failure to really understand or embrace limitations.

Everyone knows that a kit-based level can look bland, and “show the grid” in ways that make it obvious the environment is modular.  When building modular, you have to suffer through this phase of learning the process – It’s kind of like the “ugly” phase of growing a longer hairstyle.  It’s important to avoid the temptation of shortcuts, and develop a deep understanding and respect of why those limitations are in place.   Things like “patch pieces” are often workarounds that subvert the core logic of the kit, and can have a massive impact on the long-term functionality of the kit.

Photo courtesy of Techvibes

But once you’re fully committed to working with a kit, you eventually can start working around the limitations and make enhancements that work with the kit.  

Nate and myself share a couple of examples of this in our GDC talks, such as creating a grid-based cave kit, but using a “floating” sub-kit of floors and walls to create organic shapes that hide the kit, or being able to use “swinging” pieces in a kit which made sacrifices in other areas, such as not being able to tile along two horizontal axes.

The biggest change I’ve seen over the years is a much broader interest in taking a kit-based approach to building games.  While there is still plenty of “purist” games which repurpose very little art, I’ve seen more and more interest in modularity.  I think this is thanks to both the skyrocketing expectations of scope and detail in games, which a well-used kit system can help with, as well as the increased interest in procedural systems, which benefit greatly from rules-based assets like an environment kit for level design.

Kits

I’ve seen a lot of different interpretations of what a level-building kit may be, across many types of games and tools.  Kits can apply to 3D games or 2D, they can be used to generate environments procedurally, or to empower LDs building environments by hand.

So I think the most important thing to keep in mind when considering a kit-based approach is that one size does not fit all.  The rules of a kit for a 2D isometric game with procedural maps will be very different from the rules of a kit for a 3D platformer, and that’s okay.  So begin by thinking about what you hope to accomplish by building a kit first, both in terms of how it helps in the creation of the game, and what impact you want for players.

When you have this in mind, it’s good to start by thinking about tiling rules.  Will your kit tile in all directions? Just the horizontal plane? Does it only need to tile in one main direction?  When you know this, then think about the volumetric footprint of the kit. Equilateral kits are very versatile but will tend to look the most repetitive.  What are your priorities? What kind of scale and proportion of the environment is in your game?

Photo courtesy of Techvibes

Another good tip is to think about whether your game will have multiple kits in it.  This is often the case, whether it’s connecting different areas of one environment type (eg: sewer pipes and sewer shafts) or totally different types of environments (eg: ice floes, castle walls, dungeon chambers).  There’s a catch 22 here: using the same logic across kits will make the much more compatible, but also can make repetition more obvious to players.

A good rule of thumb in this situation is to use similar kit logic for locations that are either total replacements for one another (eg: the rooms of temples and the rooms of a dungeon may be logically identical kits, but with totally unique cosmetics) or kits that will benefit from extensive combination between themselves (eg: the pristine and destroyed rooms of a space station may often need to be used together).  But when you have environments that are more isolated, embracing unique types of kit logic can help the game areas have more variety. (eg: Castles with high ceilings versus caves with wide tunnels and claustrophobic ceilings)

One big saving grace in these kinds of games with many logically-distinct kits is to use a standard doorway system to connect them.  If all kits use the same logic for their doors, windows, and other portal types, then it will save a lot of effort when you want to easily move from one to another.  This allows a lot of creative combination of kits, which also helps fight the great enemy: repetition.

Art Fatigue

I suppose I’ve touched on some of this already; you can do a lot with kits to break up the grid and generally delay the player noticing the repetitive parts of a kit system. Interoperable kit variants and props can go a long way here.  Generally speaking, the better you can mix and match pieces within a kit and other kits in the game, the more combinations you can come up with to break up the monotony and create interesting variety for players to look at.

This is why I generally stay away from hard associations between kits and certain gameplay or artistic decision.  For example, you may decide to make a rule that only kobolds live in your mossy cavern kit, or that your posh castles always have bright, heavenly lighting.  While this may make sense, it’s actually quite limiting. When you free yourself up to use kobold enemies and props in any kit, there’s a big increase in the variety you get to mix and match cultures with kits.  Seeing a posh castle kit covered up with grimy kobold assets and moody lighting will shake up player expectations and fight back against repetition.

Best of all, this isn’t the kind of thing that’s really tools-limited.  It’s more about your team philosophy toward the kind of world you can craft, and choosing ways to give your assets maximum versatility through mix-and-match.

Polishing

It’s generally bad news to change certain aspects of a kit once levels are built with it.  Things like pivot point location, base footprint size, and transition metrics can be a disaster if they need changes that will break hundreds or thousands of layouts when they propagate out.

For this reason, I always think it’s most critical to focus on functional polish early, and then allow for visual polish in the later stages of development.  This allows levels to be built ASAP in development, as well as allowing artistic polish to be executed in a “real” context after many levels have been built and provide actual use cases for visual polish.

The biggest hurdle to this process, I find, is a combination of two things. First, everyone working within this process needs to understand the difference between functional and visual polish.  An artist may not realize, for example, why it’s a big deal to change the tiling edge of a kit piece. This requires some mentoring and education for those new to the kit process.  The second is getting artists comfortable with the notion that they’re committing to certain aspects of their visuals early, such as the proportions of space that will be roughly defined by kit dimensions.  Again; it requires a shift in thinking that not everyone will come to naturally.

 

Team Work

It’s been a fascinating challenge to transition from my previous team to a whole new studio and team setting here at Ubisoft Toronto.  I’ve found that certain concepts and techniques that worked great at Bethesda are challenging to implement here, while there are a lot of things that BGS struggled with, but the team here is very well-equipped for.

So it really comes down to paying attention to your specific technical, creative, and production realities, then trying to make the best decisions within those circumstances.  No one-size-fits-all wisdom, unfortunately – at least none that I’ve found!

Modern Tools

I think Houdini and similar tools have incredible potential, and there’s a path there towards exciting frontiers that are hard to imagine right now. I think that today’s procgen tools can be an incredible help, especially when building big areas – but these tools still require a lot of careful rules-crafting and input.

In the future, I think procgen tools enhanced with AI will generate offer great support for games. As today, this may take the form of runtime procedurality, or streamlining and automating aspects of level creation on the dev side, such as establishing first-pass layouts and adding finishing touches (neither of which is uncommon now) – but what’s really exciting is wondering at how an AI-powered toolkit can learn from how users interact with output and improve the generation step.

Advice

There are two pieces of advice that I find myself frequently offering to aspiring designers.  One is to prioritize becoming a competent novice in a few game engines over becoming an expert in one.  The process of learning a few tools will help you better understand the kinds of problems and workflows that are universal, and recognize the different ways in which one editor handles it versus another.  This often helps you understand the underlying tech better, and also helps you adapt to new engines more quickly. If you’re looking to work in the game industry, there’s a good chance you’ll use a proprietary and/or heavily-modified editor, and learning tools quickly will really help you be more adaptable and helpful to your team.

The other is to be avidly curious about the world outside of games.  Game developers tend to – understandably – be passionate about games.  This can lead us towards a lot of self-referentialism and monoculture, however.  Try to learn about fields that interest you outside of games, and you may be surprised at what you’ll be able to bring back to your digital work.  A lot of level designers will dabble in studying architecture, which of course can help give you crucial familiarity with concepts and terms that will help you build more rational spaces.  But you may find surprisingly useful ideas in less-obvious places, too. Pick up hobbies, watch films and documentaries outside of your comfort zone, read books and talk to people! Balancing outside interests with the discipline to your core craft will help make you a more three-dimensional thinker and creator, as well as help avoid burnout.

Joel Burgess, Level Designer at Ubisoft Toronto

Interview conducted by Artyom Sergeev

Comments

Leave a Reply

1 Comment on "Building Huge Open Worlds: Modularity, Kits & Art Fatigue"

avatar
RockCliff01
Guest
RockCliff01

I’ve been designing levels for a Skyrim mod project for the past 5 years. I’ve pretty much worked with every kit in Bethesda’s CK (Ice Caves, Moss Caves, Mines, Nordic, Imperial, Apocrypha, Snow Elf, etc), and just about every concept he spoke about here applies in abundance to the way they built the game. You get to iterate very quickly to see what works and what doesn’t, leveraging kit-bash asset kits to create unique combinations, or sometimes reskinning certain assets to fit another, effectively extending that kits variations. It’s a treat to design levels in this workflow.

wpDiscuz
Related articles
Partners’ project
Partners’ project
Interview
Level Design
Report