tag:blogger.com,1999:blog-305796602024-02-18T22:17:34.698-05:00Joel BurgessJoelhttp://www.blogger.com/profile/09816332769743524346noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-30579660.post-1151906727978616122018-06-03T01:13:00.002-04:002023-03-21T13:26:27.873-04:00Resume<div style="text-align: right;">
<div style="text-align: left;">
<h2>
Joel Burgess</h2>
<h2>
<div style="font-size: medium; font-weight: 400; text-align: right;">
<div style="text-align: left;">
</div>
</div>
<div style="font-size: medium; font-weight: 400; text-align: right;">
<div style="text-align: left;">
<a href="mailto:joel@joelburgess.com">joel-at-joelburgess.com</a><br />
<br />
<div style="border-radius: 15px; border: 5px solid rgb(187, 187, 187); margin: 0px; padding: 10px; text-align: justify;">
<b><i><u><a href="http://www.softRains.games">Soft Rains</a>, Studio Head</u></i></b><br />current<br />
<ul>
<li>Co-founded a team of veteran developers from major AAA and indie studios</li><li>Responsible for overall company + project direction</li>
</ul>
</div>
<br />
<div style="border-radius: 15px; border: 5px solid rgb(187, 187, 187); margin: 0px; padding: 10px; text-align: justify;">
<b><i><u><a href="https://www.capybaragames.com/games/">Capybara Games</a>, Studio Director</u></i></b><br />
11/2019 - 2023<br />
<ul>
<li>Help define + implement internal studio vision, roadmap</li><li>Pivoted Grindstone's live plan to achieve excellent retention and multi-year growth</li><li>General Business Development with external partners</li><li>Management of existing back catalog of CAPY games</li>
<li>Provide creative leadership and collaboration with game teams</li><li>Direct contributions when possible, eg: Grindstone level design</li>
<li>Maintained a happy and healthy creative environment for cool devs!</li>
</ul>
</div>
<br />
<div style="border-radius: 15px; border: 5px solid rgb(187, 187, 187); margin: 0px; padding: 10px; text-align: justify;">
<b><i><u>Ubisoft Toronto, World Director</u></i></b><br />
6/2016 - 11/2019<br />
<br />
<b><i><a href="https://watchdogs.ubisoft.com/game/en-ca/">Watch Dogs Legion</a></i></b><br />
<ul>
<li>Direction for core setting fiction + narrative context</li>
<li>Collaborate across multiple teams/studios on all aspects of world</li>
<li>High-level planning for locations, gameplay distribution</li>
<li>Responsible for presentation and collaboration with internal/external partners</li>
</ul>
</div>
<br />
<div style="border-radius: 15px; border: 5px solid rgb(187, 187, 187); margin: 0px; padding: 10px; text-align: justify;">
<b><i><u>Bethesda Game Studios, Senior Designer</u></i></b><br />
6/2005 - 5/2016<br />
<br />
<b><a href="https://fallout.bethesda.net/games/fallout-76" target="_blank">Fallout 76</a></b><br />
<ul>
<li>Established world tone, setting, and overall goals</li>
<li>Initial design of major gameplay systems, factions, locations</li>
<li>Coordinate and align all dev teams on early vision</li>
</ul>
<b><a href="http://www.fallout4.com/" target="_blank">Fallout 4</a></b><br />
<ul>
<li>Organized and led level design team</li>
<li>Various Systems and balance contribution</li>
</ul>
<div style="text-align: left;">
<b><span class="Apple-style-span" style="font-family: inherit;"><a href="http://elderscrolls.com/">The Elder Scrolls V: Skyrim</a></span></b><br />
<div style="text-align: left;">
<ul>
<li>Systems and Combat Design Contributions </li>
<li>Dialogue, Book, and Quest Writing </li>
<li>Level design and gameplay scripting </li>
<li>Gameplay Design: Dragon, Spriggan, Wispmother </li>
<li>Tools and Workflow Design </li>
<li>Organized <a href="http://www.creationkit.com/">Documentation </a>and Release of Creation Kit modding tool </li>
<li>Collaborated w/Valve on <a href="http://steamcommunity.com/workshop/browse?appid=72850&browsesort=toprated&browsefilter=toprated&p=1">Steam Workshop Integration</a></li>
</ul>
</div>
<div style="text-align: left;">
<span class="Apple-style-span" style="font-family: inherit;"><span style="font-weight: bold;"><a href="http://fallout.bethsoft.com/">Fallout 3: A Post-Apocalyptic Role-Playing Game</a></span></span></div>
<ul>
<li style="text-align: left;">Established & guided creative vision for level design </li>
<li style="text-align: left;">Collaborated on world & quest design/implementation</li>
<li style="text-align: left;">Hired & managed team of five level designers w/producers </li>
<li style="text-align: left;">Shared systems & tools design duties w/design leads </li>
<li style="text-align: left;">Co-Editor of Strategy Guide for base game & expansions </li>
<li style="text-align: left;">Hands-on level design layout, scripting, writing</li>
</ul>
<div style="text-align: left;">
<span style="font-family: inherit;"><span style="font-weight: bold;"><a href="http://fallout.wikia.com/wiki/Point_Lookout_(add-on)" target="_blank">Fallout 3 DLC -Point Lookout</a></span></span></div>
<div style="text-align: left;">
<ul>
<li>Project co-lead from concept to ship </li>
<li>Managed team of ~20 artists & designers on tight schedule</li>
<li>Hands-on w/project. Implemented free-form quests, world design/building, scripting, directed/performed voice acting, etc.</li>
</ul>
</div>
<ul></ul>
<div style="text-align: left;">
<span style="font-family: inherit;"><a href="http://www.gamesforwindows.com/en-GB/Live/Pages/f3operationanchorage.aspx" style="font-weight: bold;">Fallout 3 DLC - Operation: Anchorage</a></span></div>
<ul>
<li style="text-align: left;">Collaborated on High-level design of military scenario </li>
<li style="text-align: left;">Design of general space/gameplay flow and mechanics </li>
<li style="text-align: left;">Flavor text and holotape writing</li>
</ul>
<div style="text-align: left;">
<span style="font-family: inherit; font-weight: bold;"><a href="http://elderscrolls.com/home/home.htm">The Elder Scrolls IV: Oblivion</a></span></div>
<ul>
<li style="text-align: left;">Responsible for many of the game's 200+ dungeons </li>
<li style="text-align: left;">Spear-headed effort to formalize level design process </li>
<li style="text-align: left;">Contributed to story hooks and points of interest for random gameplay</li>
</ul>
<div style="text-align: left;">
<span style="font-family: inherit; font-weight: bold;"><a href="http://obliviondownloads.com/StoreCatalog_ProductView.aspx?ProductId=6">Oblivion DLC: Mehrunes Razor - (Knights of the Nine compilation</a><span style="font-weight: bold;"><span style="font-weight: bold;"><span style="font-weight: bold;">)</span></span></span></span></div>
<ul>
<li style="text-align: left;">Co-Collaborator Design, writing, and scripting </li>
<li style="text-align: left;">Shared level design duties with one other Level Designer </li>
<li style="text-align: left;">Created entire DLC as a team of two</li>
</ul>
<div style="text-align: left;">
<span class="Apple-style-span" style="font-family: inherit;"><a href="http://www.blogger.com/post-edit.g?blogID=30579660&postID=115190672797861612" style="font-weight: bold;"></a><a href="http://obliviondownloads.com/StoreCatalog_ProductView.aspx?ProductId=7" style="font-weight: bold;">Oblivion DLC: The Vile Lair</a></span></div>
<ul>
<li style="text-align: left;">Established lair layout and theme </li>
<li style="text-align: left;">Shared in Level design and writing duties.</li>
</ul>
<div style="text-align: left;">
<span style="font-family: inherit; font-style: italic;"><a href="http://bethsoft.com/games/games_obliv_shivisles.html" style="font-weight: bold;">Oblivion: The Shivering Isles (expansion)</a></span></div>
<ul>
<li style="text-align: left;">Collaborated with designers on Quest Dungeons </li>
<li style="text-align: left;">Design, writing, and implementation of freeform gameplay areas</li>
</ul>
</div>
</div>
<div style="text-align: left;"><br /></div><div style="border-radius: 15px; border: 5px solid rgb(187, 187, 187); margin: 0px; padding: 10px; text-align: justify;"><b><u><i>Other Projects & Industry Advocacy</i></u></b><br />Ongoing, personal projects and commitments<br /><br />Co-Founder & Organizer, <a href="https://gdconf.com/">GDC Level Design Summit</a><br /><ul><li>2010 - Present</li></ul><br />Board of Directors, Interactive Ontario<br /><ul><li>2021 - Present</li></ul><br />Industry Advisory Committee Member, Ontario Creates<br /><ul><li>2021 - Present</li></ul><br /><b><a href="https://theheartset.com/" target="_blank">The Heart Set: A Card Game</a></b><br /><ul><li>Designed original concept for tabletop game</li><li>Prototype, Design & Iteration </li><li>Organized artists & illustrators</li></ul><a href="http://adventure.game/">QUEST: A role-playing game for everyone.</a><br /><ul><li>Supplemental writing for early stages of TTRPG</li></ul><ul></ul></div><br />
<div style="border-radius: 15px; border: 5px solid rgb(187, 187, 187); margin: 0px; padding: 10px; text-align: justify;">
<span style="font-style: italic; font-weight: bold; text-align: left;">Level Designer, Terminal Reality</span><span style="font-style: italic;"></span><br />
<span style="font-style: italic;"></span><br />
<div style="text-align: left;">
4/2004 - 5/2005</div>
<div style="text-align: left;">
<span style="font-family: inherit; font-weight: bold;"><a href="http://www.aeonflux.com/">Aeon Flux</a></span></div>
<ul>
<li style="text-align: left;">Contributed to overall Game Design during pre-production </li>
<li style="text-align: left;">Wrote and began production on two "episodes", or levels</li>
</ul>
<div style="text-align: left;">
<span style="font-family: inherit; font-weight: bold;"><a href="http://bloodrayne2.com/">Bloodrayne 2</a></span></div>
<ul>
<li style="text-align: left;">Designed and produced two levels of final game </li>
<li style="text-align: left;">Handled dialogue and cinematic scripting</li>
</ul>
<div style="text-align: left;">
<span class="Apple-style-span" style="font-family: inherit;"><span style="font-weight: bold;">Demonik </span><span style="font-style: italic;">(unreleased)</span></span></div>
<ul>
<li style="text-align: left;">Contributed Art Assets</li>
</ul>
</div>
<br />
<div style="border-radius: 15px; border: 5px solid rgb(187, 187, 187); margin: 0px; padding: 10px; text-align: justify;">
<div style="text-align: left;">
<span style="font-style: italic;"><span style="font-weight: bold;">Art Director & Designer</span></span><span style="font-weight: bold;"><span style="font-style: italic;">, Dezign Corp.</span></span></div>
<div style="text-align: left;">
2/2003 - 11/2003</div>
<br />
<div style="text-align: left;">
Rob Williams - Project Lead</div>
<div style="text-align: left;">
<span style="font-weight: bold;">PlanetQuest </span><span style="font-style: italic;">(unreleased - cancelled)</span><span style="font-weight: bold;"><br /></span></div>
<ul>
<li style="text-align: left;"><span style="font-style: italic;">Managed tasks and budget for freelance artists</span></li>
<li style="text-align: left;"><span style="font-style: italic;">Wrote extensive design documentation for original RPG concept</span></li>
<li style="text-align: left;"><i>Early systems prototyping w/proprietary tools</i></li>
</ul>
</div>
<br />
<div style="border-radius: 15px; border: 5px solid rgb(187, 187, 187); margin: 0px; padding: 10px; text-align: justify;">
<div style="text-align: left;">
<span style="font-style: italic; font-weight: bold;">3D Artist, UCF GAMES Lab</span></div>
<div style="text-align: left;">
2001 - 2004<br />
Dr. John Weishampel - Project Supervisor</div>
<div style="text-align: left;">
<a href="http://games.bio.ucf.edu/"><span style="font-weight: bold;">The VR Forest</span> </a>(location-based educational exhibit)</div>
<ul>
<li style="text-align: left;"><span style="font-style: italic;">Created and imported content into Torque Game Engine</span></li>
<li style="text-align: left;"><span style="font-style: italic;">Collaborated on overall experience design</span></li>
<li style="text-align: left;"><span style="font-style: italic;">Project was unveiled at Orlando Science Center in 2005</span></li>
</ul>
</div>
<br /></div>
</div>
</h2>
<h2>
Education: </h2>
<h2>
<div style="font-size: medium; font-weight: 400; text-align: right;">
<div style="text-align: left;">
<div style="border-radius: 15px; border: 5px solid rgb(187, 187, 187); margin: 0px; padding: 10px; text-align: justify;">
<div style="text-align: left;">
<span style="font-style: italic;"><span style="font-weight: bold;">B.A. Digital Media: Interactive Media</span><br />University of Central Florida</span></div>
<div style="text-align: left;">
Dr. Robert Kenny - advisor</div>
<div style="text-align: left;">
Graduated 2004<br />
<span style="font-weight: bold;">A.A. Music Theory & Performance</span><br />
Indian River Community College</div>
<div style="text-align: left;">
Casey Lunceford, Department Head</div>
<div style="text-align: left;">
Graduated 2001</div>
<div style="text-align: left;">
</div>
</div>
<div style="text-align: left;">
<span style="font-weight: bold;"><br /></span></div>
</div>
</div>
</h2>
<h2>
<span style="font-weight: bold;">Miscellaneous:</span></h2>
<h2>
<div style="font-size: medium; font-weight: 400; text-align: right;">
<div style="text-align: left;">
<div style="text-align: left;">
</div>
<div style="border-radius: 15px; border: 5px solid rgb(187, 187, 187); margin: 0px; padding: 10px; text-align: justify;">
<div style="text-align: left;">
<span style="font-style: italic;">Organizer/Presenter: GDC 2010-2020: </span><i>Level Designer's Workshop</i><br />
<div style="text-align: left;">
<span style="font-style: italic;">Instructor: GDC China 2012, 2014<i>: Level Design Workshop/Tutorial</i></span><br />
<span style="font-style: italic;">Panelist: SHUX 2018, QuakeCon 2010, 2012</span><br />
<span style="font-style: italic;">Speaker: Pixelatl Festival, 2016</span><br />
<span style="font-style: italic;"><br /></span><span style="font-style: italic;">Chapter Author: <a href="https://www.crcpress.com/Level-Design-Processes-and-Experiences/Totten/p/book/9781498745055" target="_blank">Level Design: Processes & Experiences</a> (edited by Chris Totten)</span><br />
<span style="font-style: italic;"><i>Co-Author: Level Design Book via Focal Press </i><i>(Title & Release Date TBD) </i></span></div>
<div style="text-align: left;">
<span style="font-style: italic;"><br /></span><span style="font-style: italic;">2012 IGF Design Jury Member </span></div>
<div style="text-align: left;">
<span style="font-style: italic;">2011-2019 IGF Judge</span></div>
<div style="text-align: left;">
<span style="font-style: italic;"><br /></span><span style="font-style: italic;">On-Campus presentations:</span><br />
- Harvard Graduate School of Design<br />
- Linköping University, Sweden<br />
- FIEA (graduate school at University of Central Florida)<br />
- George Mason University<br />
- University of Baltimore, Shady Grove Campus<br />
- The Guildhall at Southern Methodist University (SMU)<br />
- GlitchCon at the University of Minnesota</div>
<div style="text-align: left;">
<span style="font-style: italic;"><br /></span><span style="font-style: italic;">The UCF Virtual Rainforest Team was:</span></div>
<div style="text-align: left;">
- Featured at ESA conference, Savannah, GA 2003</div>
<div style="text-align: left;">
- Featured at Institute for Simulation and Training, Orlando</div>
<div style="text-align: left;">
- Featured at IAAPA convention 2002<br />
<span style="font-style: italic;"><br /></span></div>
<div style="text-align: left;">
<span style="font-style: italic;">Co-Organizer "Rock vs. Cancer" ACS benefit concert</span></div>
<div style="text-align: left;">
</div>
</div>
</div>
<br />
<div style="text-align: left;">
<span style="font-weight: bold;">References:</span></div>
<div style="text-align: left;">
Reference Contacts are Available Upon Request</div>
<br />
<div style="text-align: left;">
<a href="https://www.linkedin.com/in/joelburgess/">View my Profile and Endorsements on LinkedIn</a></div>
<div style="text-align: left;">
<a href="http://www.mobygames.com/developer/sheet/view/developerId,211101/">View my Profile at Moby Games</a></div>
</div>
</div>
</h2>
</div>
</div>
Joelhttp://www.blogger.com/profile/09816332769743524346noreply@blogger.com0tag:blogger.com,1999:blog-30579660.post-14665616400538314342014-07-07T22:14:00.000-04:002018-10-27T07:15:48.353-04:00GDC 2014 Transcript: The Iterative Level Design Process Used to Ship Fallout 3 and Skyrim<br />
<i>Originally presented at GDC 2014 as part of Level Design in a Day</i><br />
<i><br />
</i> <i>Slides available on <a href="http://www.slideshare.net/JoelBurgess/3-10gdc2014-iterativeleveldesignprocess" target="_blank">Slideshare</a></i><br />
<i>Full audio/video available on the <a href="http://gdcvault.com/search.php#&category=free&firstfocus=&keyword=joel+burgess&conference_id=" target="_blank">GDC Vault</a> (requires subscription)</i><br />
<i><br />
</i> <i>A note about author voice in this article: As per the usual disclaimers, the views and opinions expressed within are my own, and may not necessarily reflect the views and opinions of Bethesda or Zenimax. Those views and opinions are intertwined with the interests, history and objectives of Bethesda Game Studios, however. While I am reporting on the practices of the studio, some of the particular reasons behind these practices are my own opinions, which only have partial impact on the actual adoption and implementation thereof. For this reason, I will try to use “I” to express my opinions, where “we” will usually express a fact about the studio.</i><br />
<i><br />
</i> Iteration, as it’s generally known within game development, is the progressive process of planning, creating and testing content. This is typically expressed as a cycle, where process is repeated, with each repetition applying lessons learned from the prior. This cycle is progressive, with each iteration building upon and refining the last. This concept is widely embraced: many game developers have espoused iteration when discussing the design process. <br />
<br />
<a name='more'></a><br />
<br />
There's good reason for this. Iteration works. Studies such as <a href="http://www.nngroup.com/articles/iterative-design/" target="_blank">this one </a>from J. Nielsen show that when developing interfaces for software such as a banking application, polling users on the UI experience can provide designers with findings which then inform their next UI iteration. The result is that early iterations see major gains in usability. These finding are echoed in other studies, as well as being supported by observing everything from how an artist develops a painting to the scientific process.<br />
<br />
Like any broadly-referenced term, there are many interpretations, scopes, and applications of iteration. An annual game franchise such as Madden, for example, can be seen as a very long-form iteration, where each game sees entire features added, removed, and improved upon. Spelunky, which originally came into existence as a fairly low-fidelity Gamemaker game would later be released as a commercial title with entirely new art and codebase which largely mimicked and refined that seen in the original release.<br />
<br />
Individual assets within a game are frequently iterated upon, too. The look of the original Team Fortress Spy is a far cry from his modern TF2 appearance. The gameplay design of the Spy has also been iterated upon over the years, even though the core class role has remained fairly consistent. The visual design of the spy also demonstrates that elements, such as his balaclava, can stand the test of time over many iterations, while other aspects change radically. TF2 is also a game which has seen a great deal of publicly-observable iteration over the years, as Valve introduced many new gameplay-altering items and game types.<br />
<br />
Non-developers rarely get an opportunity to appreciate pre-release iteration, however. In one notable exception, however, anyone can retroactively follow the path of <a href="http://www.gunpointgame.com/" target="_blank">Tom Francis' Gunpoint.</a> This game was well-documented online, from early experiments with character movement and environmental gameplay all the way to the final, commercial version, in which the evidence of those early iterations can be seen and felt. A premium version of Gunpoint even includes a number of prototype builds from various stages of development, allowing players to directly experience the game at different iterative points.<br />
<br />
When talking about level design specifically, it’s typical to think of iteration as the workflow steps required to conceive of and create an individual level. For example, it's necessary to plan a level, then go through the process of implementing that plan in an editing environment, and finally polish to level to a state of completion. Each of these steps is an iteration the level must go through to exist as playable content.<br />
We can think of this as "<b>Structural Iteration</b>", or the progressive set of steps required of us to actually create the level. Without each iterative step, the content cannot exist.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_L1sKLQCobTrwClx08HJD-9bxsuDkInPJTaALPAYz76aEU5W8WMd2j8gv-8p_o7EU6jdc-npkX8fdYY73LtcifjECvGtel6lwb4v0caozoivuTcnkVhg847ZAOZ92h7oLBCUp/s1600/image008.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_L1sKLQCobTrwClx08HJD-9bxsuDkInPJTaALPAYz76aEU5W8WMd2j8gv-8p_o7EU6jdc-npkX8fdYY73LtcifjECvGtel6lwb4v0caozoivuTcnkVhg847ZAOZ92h7oLBCUp/s1600/image008.png" height="176" width="400" /></a></div><br />
There's a crucial step missing from this simple “plan/create/polish” breakdown, however: playtesting. Before considering any level complete, most level designers will make an effort to solicit feedback from peers and players, or at least play their own level through the eyes of a player. That feedback is then applied by revisiting aspects of the level which are shown to be broken, of poor quality, or exhibit some unrealized potential.<br />
<br />
This we can think of as "<b>Qualitative Iteration", </b>or a step with which we can iterate over our content to not just make it complete, but make it good.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZmmWgQA7aCX6stBRg_EB18N2kXxC93eA0Y5rGN_lPe5jD4EojPGOPXVjV9vjqbXmtZyW3IzNBszfKVcB2_TW6Up4yQzC-O_xLP1yy8BRUdkpPYAGxLl0MfFNeJ2JS9lY_fXmA/s1600/image010.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZmmWgQA7aCX6stBRg_EB18N2kXxC93eA0Y5rGN_lPe5jD4EojPGOPXVjV9vjqbXmtZyW3IzNBszfKVcB2_TW6Up4yQzC-O_xLP1yy8BRUdkpPYAGxLl0MfFNeJ2JS9lY_fXmA/s1600/image010.png" height="181" width="400" /></a></div><br />
<br />
This is typically cyclical; few level designers can nail execution on the first try. Qualitative iteration cycles can go on for an unknown amount of time before the designer is comfortable calling a level final. This contributes to the "It's done when it's done" mentality sometimes prevalent among game developers. Game developers can never really sure how many iteration cycles it may take for a piece of content to feel complete. Many of us would iterate eternally, if we could, but this of course means the level would never reach its final structural iteration.<br />
<b><br />
</b> <b>PROCESS</b><br />
<b><br />
</b>This article is, at its core, an exploration of workflow process. I think process is worth discussing, because it's through process – even intuitive, unconscious process - that we're actually able to make games. The processes we choose don't only enable us to make games, but to make them in a way we consider efficient, enjoyable, and sane. Iteration is really just a process choice, and one that, as mentioned, many already embrace.<br />
<br />
It's worth realizing, also, that processes iterate and evolve over time. Consider any task you have performed repeatedly in your life, whether it's creating a level, getting from home to work, or cooking your favorite meal. The way you accomplish the task has probably not changed drastically very much, but gradually evolved over the years as you organically learned from experience and applied that knowledge.<br />
<br />
The same is true of our process as a studio. The iterative process to be discussed in this article was conceived of for Fallout 3, then kept around improved upon for Skyrim. We still use it for our current project, albeit with changes based on lessons learned from Skyrim. I'm sure we haven't got it right yet, and will change more going into the future beyond now. We’re unlikely to radically change our process overnight, abandoning accrued skill and institutional knowledge, and instead grow it naturally over time.<br />
<br />
As mentioned, our level design process was created for Fallout 3. That’s because Fallout 3 was the first BGS title to make use of a dedicated level design team from day one. Older games such as Morrowind and Oblivion featured level design, of course, meaning that we had the existing infrastructure necessary to build levels. The studio was just choosing to invest more deeply in the moment-to-moment experience by forming a level design team. Those of us founding that group knew that iteration was a core value we intended to embrace as we considered our workflow process.<br />
<br />
There are a number of factors that influence any process, and I'll try to list several of ours here. Allow me to point out that this article is more historical than prescriptive. One size will not fit all. Unless you’re working within parameters very similar to ours, on titles very similar to our own, it’s unlikely that you can directly lift our technique. If you're interested in applying any lessons gleaned from this article to your own process, pay attention to the similarities and differences here between our circumstances and yours.<br />
<br />
One obvious requirement of a level design team at Bethesda is the ability to generate a massive amount of content. Skyrim, for example, contains over two hundred locations which involve level designer effort, from tiny camps and roadside encounters all the way to extensive dungeon experiences. We knew our process had to empower us to output a lot of stuff.<br />
We also knew that we wanted to increase the overall quality of the moment-to-moment level design experience. We'll always want to improve this, of course. When it comes to quality, it's a good rule of thumb to never be satisfied. We held the belief that instituting an iterative process was key to attaining quality.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9mf-mAEKY_H8n1t8j8OoH4G2TzuRMnEWOfrigaSkfoxXN9NH8ZotjG-pBjVz0076a3fVUc6RuyL2LlOTOZTi12g9hzJExayXbL6LxnCV6XhadBvsIlYuU4d6AoS5ee5n7fYXI/s1600/image012.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9mf-mAEKY_H8n1t8j8OoH4G2TzuRMnEWOfrigaSkfoxXN9NH8ZotjG-pBjVz0076a3fVUc6RuyL2LlOTOZTi12g9hzJExayXbL6LxnCV6XhadBvsIlYuU4d6AoS5ee5n7fYXI/s1600/image012.png" height="225" width="400" /></a></div><br />
It's also true that Bethesda is a very process-oriented studio, and that we generally have a strong sense of our schedule. At any given time we can get a sense of our near and long-term goals, and the time in which we want to complete them. Some people may think of this as a negative. It's not uncommon to see producers and schedules vilified in game development, and the idea of being shackled to a schedule can seem like a death knell for creativity and quality.<br />
<br />
I find the absence of a schedule somewhat like being adrift in deep, blue ocean. You can swim in any direction you wish, and you may end up somewhere wonderful - or only be exhausted, and further from land then when you began. I've found that having a schedule can provide you with a point of reference on the horizon. By knowing what you're aiming for, you have the ability to plan how to expend your energy and pace yourself. This knowledge is a boon for our level design process.<br />
<br />
As previously mentioned, Bethesda was already a well-established studio when the level design group was formed. This gave us an advantage, because we already knew how art was created and put into the editor, had an existing toolset, understood the code pipeline, and so on. In a start-up situation, for example, things may be more chaotic because everyone is trying to find their place. When we were a new group, we had the support of a professional, supportive group of peers within the studio. This luxury allowed us to focus primarily on ourselves, without too much risk of tumult from outside upheaval.<br />
<br />
<a href="https://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="https://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="https://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="https://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="https://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="https://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="https://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a>Another fact of life at Bethesda is that we're a very low-turnover studio. This means that our level design group stays at a relatively uniform size through all stages of a project. This is in contrast to some other dev teams. Content creators such as level designers can be difficult to use effectively in the early stages of a project (more on this later) but are desperately needed in the late stages. This can result in a ballooning of staff to finish a game, with those individuals then ending up reassigned or laid off at the end. Because we don't do this, we had to be sure our process would make productive use of level designers in the early going, but neither leave the team short-staffed at the end. This absence of staff churn is also key to maintaining team chemistry, to which I attribute much of our ability to be successful as a team.<br />
<br />
Finally, we knew that we wanted to maintain a healthy quality of life. I abhor crunch. This isn’t a difficult or controversial opinion to hold; I imagine very few game developers will flock to defend crunch. I believe, however, that we tend to associate crunch with exploitative cases of institutionally enforced overtime which are commonly heard of, and which many of us have lived through. But crunch is not always the result of irresponsible managers who will knowingly demand unreasonable hours. Just as often, I speculate, it's the result of our own willingness to crunch, coupled with an inability or unwillingness to plan ahead realistically or at all. We believe that through informed planning, we could create a level design workflow that would minimize the likelihood that we'd end up asking too much of ourselves, either directly or implicitly.<br />
<br />
<b>APPLYING ITERATION TO WORKFLOW</b><br />
<b><br />
</b>Let's take a few steps back and talk about how iteration can be applied to a simple workflow. Imagine (or recall, depending on your experiences) that you are an aspiring level designer. You've got a great idea for a level, and you want to mod it into an existing game. You’re a complete novice; you've never done this before. You start by downloading mod tools and reading some tutorials. You probably tweak the tutorials so that you're creating your level as you learn, and bit by bit you inch closer to finishing. Sooner or later, you finish the level, and perhaps share it online or with friends.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVdk5Lhb8VGRiILAK-yE0co2MTeFnjFuIZ31eRJ9dBWkQIO9ud8EoFF0Nj2Ck4ul2inFt4anPwufZ2RG9VTR7aVcvoni4RRgwosSiQtyvl9C1TTB_Kj0J9lZ0NinUGWS4JzjhB/s1600/image014.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVdk5Lhb8VGRiILAK-yE0co2MTeFnjFuIZ31eRJ9dBWkQIO9ud8EoFF0Nj2Ck4ul2inFt4anPwufZ2RG9VTR7aVcvoni4RRgwosSiQtyvl9C1TTB_Kj0J9lZ0NinUGWS4JzjhB/s1600/image014.png" height="180" width="400" /></a></div><br />
The trouble with this black box approach is that you can easily make nonobvious mistakes. Early on you may have made a poor design decision or technical misstep, for example. You can build on that unsound foundation for quite a while and not fully understand or realize what you've done wrong. You may eventually sense the issue, and end up spending a lot of time meandering back on yourself to straighten out such problems, or just end up releasing a sub-par level. (That’s okay, of course! Stumbling through is part of the learning process. Most masterpieces can only be reached by creating a mountain of crap to climb on.)<br />
<br />
Let's say you come back for more abuse, and set about to create a second level. This time you understand more about the steps that go into creating a level, and you're likely to break the work up into stages based on what you now know. From here, you're able to compartmentalize the work, and understand that you need to plan certain things before creating a graybox, test aspects of your layout before adding detailed art trim, when to spend time lighting, and so on.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqkupq17wX3VrPfiXGUJ_3q3qorrThGqeahlTmqXITgdoNqiiOsGuopgrisQ5nY56pMmy2OeNuPGqGwkCz33UfzPzM_ljr033HS7aABg5a12MtNr76ljbOpIv8nL6cIDO1WSTs/s1600/image016.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqkupq17wX3VrPfiXGUJ_3q3qorrThGqeahlTmqXITgdoNqiiOsGuopgrisQ5nY56pMmy2OeNuPGqGwkCz33UfzPzM_ljr033HS7aABg5a12MtNr76ljbOpIv8nL6cIDO1WSTs/s1600/image016.png" height="140" width="320" /></a></div><br />
This is the beginning of establishing an iterative process. If you're making a specific level - "Level A", for our purposes - start by breaking the task up into chunks. To keep things simple, let's imagine four chunks: "Concept", "Layout", "Gameplay", and "Polish".<br />
<br />
Once we break up workflow in this way, we can continuously iterate through the level by focusing on each stage in sequence. It also allows us to analyze our work at the end of each phase and make sure we're working from a sound foundation before moving on. This helps us avoid creating a fundamental layout problem, for example, before moving on to detailed encounter or visual work that would be wasted when doing major layout revisions.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZ7z59HwKkP61F2b5tLPf1wqy_PI7V3eA2cruup0Tb2DOD2FssEQhsiFJkE2Eos-_OQVk0zIc9o6r6C-2oIQ9VAblrLh60gcD4gRN7W4pJLxJIgb-5OR_jseE5rf_eVKyYMiQz/s1600/image018.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZ7z59HwKkP61F2b5tLPf1wqy_PI7V3eA2cruup0Tb2DOD2FssEQhsiFJkE2Eos-_OQVk0zIc9o6r6C-2oIQ9VAblrLh60gcD4gRN7W4pJLxJIgb-5OR_jseE5rf_eVKyYMiQz/s1600/image018.png" height="91" width="400" /></a></div><br />
From here, it's easy to extrapolate from making a single level to making the various levels you might create for an entire game. If we imagine a simple, three-level game, you would simply iterate level A until completion, then move on to level B, repeat, and wrap things up with level C. Let’s call this process one of "<b>Continuous Iteration</b>".<br />
<br />
Now that we’re considering a multi-part project, let’s frame this in terms of scheduling your time. If we assume that each pass takes roughly a week to complete, and each level is broken up into four passes, then we’re allowing ourselves about a month per level. This means you'll spend a month focused on level A, another on level B, and finishing the game with level C in the third month.<br />
<br />
That's not quite how we approach it at Bethesda, however.<br />
<br />
We start the same way, by breaking work into focused chunks. Once we've made our first pass at level A, however, we don't move on to the second pass of level A. Instead, we'll complete that same first pass iteration of every other level in the game. Only then will we return to level A and go through our second iteration of it. Then, likewise, we iterate every level in the game up to second pass, and go on in this fashion until the game is complete.<br />
<br />
The key difference here is time. We've got a lot of content, so once you complete a pass on any particular level, it's typically weeks before you'll revisit that level to complete the next pass.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjzqN1QZX6cApg0216efp4LN2XHzZ37jQSPkwZ7scTpAd_SJ6nMt8-4lWmev1JftpzoJ9s0Cs4WrNRPgYWxw54xOFEFoa7RlMEm8_uUiCgga9pbVwxaFOlqjVr1OqKRGu1SpuHW/s1600/image020.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjzqN1QZX6cApg0216efp4LN2XHzZ37jQSPkwZ7scTpAd_SJ6nMt8-4lWmev1JftpzoJ9s0Cs4WrNRPgYWxw54xOFEFoa7RlMEm8_uUiCgga9pbVwxaFOlqjVr1OqKRGu1SpuHW/s1600/image020.png" height="172" width="400" /></a></div><br />
There are a number of benefits behind this approach.<br />
<br />
First, and easy to overlook, is the fact that it keeps you fresh. Anyone who has worked on anything for weeks at a time probably appreciates that you can lose perspective if you don't come up for air once in a while. By taking time off between passes, we can avoid becoming lost in nuance, and come back to the content with fresh eyes later.<br />
<br />
This approach also allows us to incrementally build on a strong foundation. Each pass depends on the strength of the one that came prior, and for reasons I’ll soon explain in detail, taking our time allows us to make sure we're establishing a high level of confidence in each pass before moving on. This confidence reduces the likelihood of wasted work compared to a linear, continuous iteration process.<br />
<br />
A major contributor to this confidence is that we've got more time between passes to gather feedback. If you're iterating continuously and rely on outside feedback, that feedback can become a bottleneck. Imagine the difference between giving feedback that a designer needs immediately versus feedback they won't actually need to respond to for weeks. In the latter case you’re able to play the content naturally and organize your thoughts, as well as allowing the level designer ample time to digest your feedback before needing to react to it.<br />
<br />
Let's think in terms of a schedule again. If we still assume four one-week passes per level, and three levels named A/B/C, we'll now get a two week break from any given level between one pass and its next.<br />
This leads us to another benefit. Now, rather than thinking of January as "level A" month, we think in terms of what pass of the game we're focused on. We'll spend a few weeks on first pass, a few on second, and so on. While you are more frequently focusing on different content and problems, you’re not switching contexts. The layout problems solved in Level A are fresh in your memory when dealing with the layout problems of level B. The real benefit comes at the end: we aren't thinking in terms of completing the final level, but polishing all the levels. This gives the level designer the ability to focus each iteration along the guidelines of the project's progress.<br />
<br />
That's the final benefit; this workflow allows us to cope with the growth of a project which is being developed as we work. This last point is absolutely crucial, and the lynchpin of our approach.<br />
Accept for a moment that game development is chaos. Everything is connected, and inter-dependencies are numerous and complex. Whether working with a small group, as part of a team of hundreds, or even alone, changes to one component of a game can have unexpected impact on any number of other aspects of the game.<br />
<br />
This means that the timing of what we do matters. So does the context in which we choose to do these things. This is especially important for a level designer. That is, informed level design requires code and art, to say nothing of proven ideas. The trouble is that great code and art both take time. This is one of the big problems with conventional level design methodology that our approach aims to resolve: what can a level designer do productively at the beginning of a project, before there's much code and art to work with?<br />
<br />
A quick aside - let's establish what a Bethesda level designer does. The core skillset expected of us involves creating good layouts within a modular kit system, having a sense of how to eke out good gameplay from our systems, including knowledge of our scripting, quest logic, and gameplay markup tools, and putting this all together in a technically-competent level which performs well.<br />
<br />
We wear more hats than these, however. There are a number of other, ancillary tasks which level designers may take on. These may include writing books or dialogue, contributing to systems design such as crafting, combat or balance, prototyping features with our scripting language, collaborating with programmers on internal tools, or just about any other odd job that may come up.<br />
<br />
There's a dual benefit to this split focus between core level design work and miscellaneous other tasks.<br />
One, which is only tangentially relevant to our topic: it allows us to broaden ourselves as game developers. It's increasingly easy for a developer to become highly specialized, especially on larger teams. We deliberately avoid this, and in fact will intentionally put level designers on ancillary tasks which cater to their weaknesses. For example, if a need arises for a script prototype, we'll often select a level designer who needs improvement in that area for the task, assuming it's not asking far more than is reasonable. This enriches the level designer professionally, adds variety to day-to-day work, and their broadened skillset will make them more useful to the studio in the long run.<br />
<br />
Second, and more to the point, is that the split focus allows us to make sure, from a management perspective, that our level designers are altogether more productive. To people from certain schools of thought, this may seem counter-intuitive. To understand, it's necessary to consider the timing and context of our work.<br />
<br />
In the early stages of development, there's very little for an LD to work with. Code and art are just starting, too. Further, the project is at a conceptually nebulous stage. Even if you're developing a sequel, things tend to be pretty blue-sky at the onset. Every idea is a good idea, and anything is possible. This makes it very difficult, even if we had the tools to make content, to focus on the concepts that will translate into good gameplay down the road.<br />
<br />
This is directly inverse to the later stages of development. By then, we'll have plenty of art and code to work with, making the practical side of creating content very achievable. The conceptual space of the game is more narrow and well-defined at this point, too, making it much easier for us to focus on good gameplay without being distracted by those ideas which seemed wonderful at the start, but have since been attempted and cut.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidfUK3lACZX_dNafPeKnBYWrR7Xtq90lNJuf8tXQ9MaOszklsb86b8cMBA_ILkTpB2-bbeLAfWbBhTybXFjYTKx23Ff7jx8-MKx2_ZK0o0n6jnpOMTMCmyrVx-AbkelablHpab/s1600/image022.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidfUK3lACZX_dNafPeKnBYWrR7Xtq90lNJuf8tXQ9MaOszklsb86b8cMBA_ILkTpB2-bbeLAfWbBhTybXFjYTKx23Ff7jx8-MKx2_ZK0o0n6jnpOMTMCmyrVx-AbkelablHpab/s1600/image022.png" height="173" width="400" /></a></div><br />
So, how does this translate into making the level designer more productive? If we are looking through the contextual lenses of early development versus late, we see that doing good level design work is difficult in the early going. However - there are many other tasks to which a level designer can be applied. Collaborating with programmers on internal tools, working with artists to establish kits, prototyping with scripting tools - these are all among the ancillary jobs that we seek out. This means we aren't spending as much of our time doing core level design, and that's okay; we aren't very well equipped to do that work yet.<br />
<br />
Later in development, however, many of those early problems are solved. Tools have been nailed down, kits are done, and systems work may only require maintenance. This frees us up to spend vastly more of our time and attention on core level design, and that's okay, too; we're better equipped to be effective at that now.<br />
<br />
Now is a good point at which to introduce the concept of "Opportunity Time". We use this term broadly within BGS to describe when we're able to actually look at an idea in the game on-screen and identify those things which show especially great promise. These become key opportunities for us to capitalize on by focusing our efforts. This is especially true of level design, for the reasons mentioned so far. The thing about opportunity time is that you often do not know what opportunities will arise until you've actually gotten there.<br />
<br />
Maybe we’re just bad guessers, but we've proven to ourselves over the years that no amount of theorizing can reliably substitute for reacting to something playable in-game. So that's one of our mantras at the studio, and something our level design process hopes to solve: How do we maximize our opportunity time, and get there faster?<br />
<br />
<b>THE PASSES</b><br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYXU3lNayLRdy51pakrRme9havUGCKjSIRv1FP0jG7pnwsTf7ve8enVPUq45vb18kPhvbsD8UuyFdq8iS0JaNa4HTT3LJsYcNuXkSHUhqQtLnUgCFCAIWJE4koGJpbrg2tulBf/s1600/image024.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYXU3lNayLRdy51pakrRme9havUGCKjSIRv1FP0jG7pnwsTf7ve8enVPUq45vb18kPhvbsD8UuyFdq8iS0JaNa4HTT3LJsYcNuXkSHUhqQtLnUgCFCAIWJE4koGJpbrg2tulBf/s1600/image024.png" height="140" width="200" /></a><br />
Next I will start describing the specifics of our process. Our work is broken down into a series of passes, much like the level “A” example earlier. Each pass has a specific focus, and is intended to create a strong foundation for the passes that will come after. Iteration is built directly into our schedule in this way.<br />
<br />
Permit me to remind you that timing and context are of the utmost important when it comes to deciding how we spend our time and attention. Because of this, I won't just describe what we do on each pass, but also what the state of the project happens to be at each.<br />
<br />
<b>PASS ZERO</b><br />
<b><br />
</b>Our first pass is actually called Pass Zero. This pass is focused on conceptually planning the level. There's not a lot for us to work with at this point. The game may not even run yet, and there's certainly no real art to work with. What we do have, however, is a list. This list contains all of the spaces and events we plan to tackle with level design. It's essentially a slot machine of the various architectural kits, encounter types, map locations, names and scopes of each space.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijgl40ojQpYFs1ipI43bZslS87lUtC8e_q09C-CjNNp3QBACs7u8ceot-398SGgd5zuX4QZjbMG6sEm1C4orNG9gh8vxGgO634lXvRI1Lncc2J9wH8F96V0g-RlRTpJ8Qb1knl/s1600/image026.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEijgl40ojQpYFs1ipI43bZslS87lUtC8e_q09C-CjNNp3QBACs7u8ceot-398SGgd5zuX4QZjbMG6sEm1C4orNG9gh8vxGgO634lXvRI1Lncc2J9wH8F96V0g-RlRTpJ8Qb1knl/s1600/image026.png" height="143" width="200" /></a></div><br />
As a level designer, a pass zero assignment might read as such: "You'll be working on Bleak Falls Barrow, a large. It's built with Nordic Ruins, and inhabited by Draugr." Some spaces will have planned ties to a quest or other dependencies, but often these few pieces of information and map coordinates are all the information provided.<br />
<br />
Your job? Pitch what you'd like to do. This takes the form of a short wiki entry, usually no more than 1-3 paragraphs. We emphasize the need to keep this short, and generally try to focus on one unique thing about this particular level that will make it stand out. We've learned from experience that trying to do too much in a single space can muddy our focus, and sometimes detract from our ability to also concentrate on other spaces.<br />
<br />
We also spend some time at pass zero thinking about story. This isn't necessarily player-facing story which will manifest in the game as dialogue or written text. Instead we are concerned about basic story of the space. Why it was built, for what purpose, and by whom? What happened here in the past? What has happened here more recently, in the time just before the player arrives? Even though we don't intend to communicate this information to the player in any concrete way, it can inform hundreds of seemingly-inconsequential decisions we make about how we build the space, and what we choose to put in it. If this space was an ancient tomb which fell into disuse, but has recently been used to dispose of political heretics, then how might that manifest as environmental storytelling? This internal consistency hopefully translates into a sense of authenticity which itself is detectable by the player, even if the observable result is subtle.<br />
<br />
Pass zero is also when we start making asset requests. We aren't worried about requesting every wall, ceiling and chair required. Those things get taken care of in other ways. Pass zero LD requests will be those things which are unique to the space, or unprecedented. There are two main reasons we deal with this now.<br />
The first is obvious - we're interested in building a reliable art schedule, and this information helps producers quantify the work ahead of the art team. The second reason is more subtle, however, and entirely more important.<br />
<br />
Let's imagine that you'd like to include a puzzle in which the player must ring a series of bells in the correct order to open a passage. It's not enough to simply request "Bell Puzzle" and be done with it. It’s necessary to break the request down into specifics. How many bells? How large? Do they animate? What sounds do you need, and do you have the necessary script hooks to use? Coming up with good asset requests forces the level designer to mentally implement the content. It's easy at this phase to think too abstractly, but this process forces us to consider details which may be otherwise easy to miss and result in vague or wasteful art requests.<br />
<br />
As this article steps through each pass, I won't only focus on what we do, but also what we avoid doing on each pass. This is vital. Level designers aren't naturally restrained people, I've found. We love seeing our ideas come to life on screen (this is what hooked us, isn't it?) and will sometimes overextend ourselves too soon. There's a real hazard here, however. If you're tempted to clutter and light a space, for example, when only a handful of lighting tools and clutter objects exist, you'll rely too heavily on those few things too much now, and all of that work will likely be deleted later when more robust assets exist.<br />
So we try to think about what's optimal to do right now, and eschew the things which are better handled at later stages. Remember: timing and context are paramount.<br />
<br />
During pass zero, for example, we don't even bother booting up the editor. Even if there are assets to work with, they are far too few to be practical. Anything we do now will be busywork.<br />
<br />
We don't spend our time drawing up detailed maps, either. The nature of our toolset means that we depend heavily on our kits to establish layout and flow. Getting out the graph paper and creating detailed, proportionally-accurate maps is a poor use of time, and can lead to frustration when we have difficulty working from such a blueprint later. Better to avoid this now and sketch in the editor later.<br />
<br />
This doesn't mean we avoid maps completely, however. We just keep them abstract. A typical dungeon map is more likely to focus on loose connectivity and pacing, rather than determining fine spatial details. This kind of map is more of a tool for the level designer, and not a way to communicate ideas to others.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiecpWLVHlPNFacCYBelDxYxsatUAsux2RyKeEUaUa7BVCSv46cm01deqDuuU-gUkx0vly6tM0PRhnxej788F4Ljk5VyktsbgnC0HoemuQQlaMajZHhUKFwP_2FPA9Wk6jtXfuz/s1600/image028.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiecpWLVHlPNFacCYBelDxYxsatUAsux2RyKeEUaUa7BVCSv46cm01deqDuuU-gUkx0vly6tM0PRhnxej788F4Ljk5VyktsbgnC0HoemuQQlaMajZHhUKFwP_2FPA9Wk6jtXfuz/s1600/image028.jpg" height="240" width="320" /></a></div>We also stay away from “fluffy” documentation. I've seen level design documents that spend ten or twenty pages focusing on less than half an hour of gameplay. Some of these have wandered into tiny backstory details such as the feud between brothers who manufacture the fuel used in hovercraft which the player only sees momentarily when enemies appear during a specific scene. This stuff might be good flavor, but it’s part of the task of pass zero to distill ideas. If you can't boil your conept down to the essentials, then you're missing the point of the pass. It's okay if you think and express yourself through lengthy documentation, of course. But that stuff is for you - not the team, and not the player.<br />
<br />
As mentioned before, you'll move on to another pass zero after this, and another after that. It takes us a while to work through all of our content, and weeks will pass while we do this. The rest of the team is busy, too, meaning that the state of the game has changed by the time we're done.<br />
<br />
<b>PASS ONE</b><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1y4jPsXEtZXvBz9Ao0fnWwOO9eIwD-raOX05AjRYvAmazFM7ikvzrgwZmNSqLIE1o7-9fBx4VgtaKvmgSe7X4HnbxnsogSskTae-0Ct00k-KqrNNpAhoh-VbiBl2zETsRq_eS/s1600/image030.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1y4jPsXEtZXvBz9Ao0fnWwOO9eIwD-raOX05AjRYvAmazFM7ikvzrgwZmNSqLIE1o7-9fBx4VgtaKvmgSe7X4HnbxnsogSskTae-0Ct00k-KqrNNpAhoh-VbiBl2zETsRq_eS/s1600/image030.png" height="143" width="200" /></a></div><b><br />
</b> This brings us to First Pass. This pass is all about layout. While going through our pass zeroes, level designers were also working alongside environment artists to establish the kits which we use to construct our spaces. Thanks to this early collaboration, we've got enough art to actually make meaningful layouts, even at this early stage.<br />
<br />
The core mission here is no surprise; we're focused on making as complete a layout as possible. It won't look fabulous yet, but we can be confident that the kits will evolve visually, and that the functional details - pivot points and such - will remain the same, meaning that the work we do now won't be undermined by later changes. This allows us to focus on the basic rhythm and flow as we move through the space, even though it will be empty and unlit.<br />
<br />
We also spend a little bit of extra time making sure that we understand the kits well, and provide feedback to the kit artists to make sure we're getting maximum function out of the limited set of pieces they'll be able to create and polish. This is worth the extra time, because any kit pieces that come online very late will be difficult to retroactively integrate into existing spaces. The fact that this slows us down a bit is fine, of course, because we're generally more available at this stage of the project than we will be later.<br />
<br />
First pass is also a good time to start working on incidental writing such as books or notes that may be found within the space. By this point we've gotten feedback on our pass zero, so we can be confident that the underlying ideas are worth spending time on. This kind of writing can really be done at any point, but because it's an optional detail for players who dig a bit deeper it's also easy to not do if you're under the gun later.<br />
<br />
There's also some housekeeping that can be done at this early stage, such as making sure our locations have appropriate names, location data, map markers, and so forth. This information is relatively unlikely to change, so it's good to get it out of the way now.<br />
<br />
During first pass, we avoid a handful of things. Among them is optimization. Our toolset relies on level designer-created volumes and tagging to help control performance costs. Because of the spatial nature of these volumes, we wait until after first pass, because it won't be until after we've received feedback that we can be confident our layout work is solid and won't change dramatically.<br />
<br />
We also avoid doing any encounters, or the navmesh they require. While we may have a few encounters to work with at this point, they'll be rough. Further, as with optimization, navmesh is intrinsically tied to layout, meaning work spent here is too subject to change based on feedback we won't receive just yet.<br />
<br />
We also stay away from lighting and cluttering, for basically the same reasons.<br />
Finally, we discourage any kitbashing or arthacks. For the uninitiated, these are the terms generally applied when using art in a way it wasn't intended for. For example, you may not have a bridge piece in a kit, and choose to turn a wall sideways as a temporary stand-in. Or, as seen in this example found on Reddit, abuse a piece of furniture to create the illusion of a piece you don't have at your disposal.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgv8u9d7nna9yu8p_QanjM3okZfQ7o3aUaUY9_zNs9L5UtHZ931UcdgTp-LD_igi1jLXrPyAfDbbw3P112k17PlXqP3S90TOHQvgUre2wJWRyUewQ27VZg0i7yFDJm0-mXQdxMe/s1600/image033.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgv8u9d7nna9yu8p_QanjM3okZfQ7o3aUaUY9_zNs9L5UtHZ931UcdgTp-LD_igi1jLXrPyAfDbbw3P112k17PlXqP3S90TOHQvgUre2wJWRyUewQ27VZg0i7yFDJm0-mXQdxMe/s1600/image033.jpg" height="640" width="489" /></a></div>Because we work on huge games with limited art resources we will end up shipping with lots of arthacks like this. Done well, they help us stretch maximum value out of limited art. But it's not a good idea to do them this early. They mask problems and shortcomings that are better left in the open and addressed. Any kitbash this early runs the risk of masking an issue that ought to be given attention. This risk outweighs the short-term gain afforded by the arthack.<br />
<br />
More time passes as we work through our first pass spaces, and the game has again evolved as we enter second pass.<br />
<br />
<b>PASS TWO</b><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOGGwE9SPLO1ckcqYwg4lgeivLJ_OhAs0LKLAKtOX3qK9wDjAnzXeFRpdMhO921DGzViZs8VRLdj10TxMaVSGNAQt-5qZLpvEHCkVkQbB5gVN7nQEl8D5uJ6_CuLrWHFcws_3f/s1600/image034.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOGGwE9SPLO1ckcqYwg4lgeivLJ_OhAs0LKLAKtOX3qK9wDjAnzXeFRpdMhO921DGzViZs8VRLdj10TxMaVSGNAQt-5qZLpvEHCkVkQbB5gVN7nQEl8D5uJ6_CuLrWHFcws_3f/s1600/image034.png" height="143" width="200" /></a></div><br />
Second pass is about gameplay. At this point, we've probably been working on a Vertical Slice, meaning that in the right set of circumstances, the game can look pretty complete. The Vertical Slice has accelerated progress on core mechanics as well as a specific subset of location, encounter and weapon types. This means that we can begin focusing on gameplay in levels that have similarities to the VS, and we can have faith that the lessons learned in the VS will permit the team to make accelerated forward progress on the rest of the game beyond the slice.<br />
<br />
The main objective when tackling a second pass is typically focused on setting up enemy encounters. We'd like to get a sense of pacing. How many enemies, of what type, in what numbers, how often? It's also a good time to start thinking about loot. Where does the player find healing items, pick a lock to access some hidden goodies, or come across the jackpot stash guarded by a boss enemy?<br />
<br />
We can also start working on scenes at second pass, whether this is a conversation upon which the sneaky player can eavesdrop, or forcing an enemy to run down a particular hallway when the player approaches.<br />
<br />
Working on encounters also requires that we work on the navmesh for the particular space. This is a good use of time, because the navmesh will be maintained throughout later stages of development, and a good foundation now will save time later.<br />
<br />
As mentioned earlier, the gap between passes affords us ample opportunity to generate and share feedback. This means that you may have feedback on your first pass that requires attention now. Layout adjustments, in particular, can be taken care of at the onset of a second pass, meaning that you'll have good confidence that your layout-dependent work (such as navmesh) won't be undermined later.<br />
<br />
While we're working on the gameplay pass, it's worth remembering that our games aren't entirely about sticking people with the pointy end of a weapon. If you plan to include non-combat beats, particularly one-off content such as a puzzle or dialogue, it's something we want to stub in now, even though that stub should just be placeholder. Again; this helps establish pacing, and serves as a playable pitch for your gameplay ideas.<br />
<br />
One more thing that we spend time on during second pass is optimization. This may seem counterintuitive. We aren't likely to be struggling with performance problems yet; the level is still unlit and basically empty. Even if we are running at a poor frame rate, this is most likely an issue with unoptimized, work-in-progress code work at the rendering level.<br />
<br />
So... why spend the time now, if we're so concerned about doing things when they make the most sense?<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7BJpefbVgW3_GLweHzh03qH76-j09xNGlsH3BdqK7IWdNmt-BrgQHiNm1fI_29TeNIDngY3JOqyUYRkbCRImHPp5sebaKFBTVrmolcLXwhhFlhsHBcvybi9CtV2f117c_05Cg/s1600/image037.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi7BJpefbVgW3_GLweHzh03qH76-j09xNGlsH3BdqK7IWdNmt-BrgQHiNm1fI_29TeNIDngY3JOqyUYRkbCRImHPp5sebaKFBTVrmolcLXwhhFlhsHBcvybi9CtV2f117c_05Cg/s1600/image037.jpg" height="76" width="400" /></a></div><br />
This comes down to eating your vegetables. Because we're confident in our layout, and layout is the only real barrier to creating our optimization bounds, there's no real reason *not* to do it now. This work if fairly tedious and will be mandatory later, so doing it now will free us up down the line to focus on things that make the game better, rather than scrambling to make the game run at our target frame rate.<br />
<br />
There are a couple of things to avoid at this pass. The primary one is not to blow the level up and start over. This is a common reflex when revisiting any level, particularly at second pass. The temptation makes sense - you've got newer art, better ideas, and sometimes it seems easier and more enjoyable to build something from scratch than to work on something that already exists.<br />
<br />
We try to avoid giving into this reflex, however, because it's often just that: a knee-jerk reaction. We've made this mistake often enough to realize that restarting a level can often result in setting ourselves back only to create something which is different from what we had, but not necessarily any better. Scrapping old work out of boredom isn't useful iteration; it's just busywork, and can be avoided.<br />
<br />
We also avoid doing any in-depth script handling to support our gameplay. Just as with layout in first pass, our gameplay is subject to feedback and revision once the second pass gets completed. This feedback can result in significant changes. If you spent a lot of time handling edge cases scripting a puzzle, or writing side topics in a conversation, that detail work is often wasted when revising. It's okay to leave things very rough for now as a result.<br />
<br />
From second pass onward, feedback will be coming in more frequently. There are many avenues for feedback on a level. There's anecdotal feedback, such as you might get from a co-worker you quickly grab to run through the space, or an email you receive from someone who randomly tried your level out while testing a feature. There are also group critiques held, where artists and other level designers will view your content on a projector and make verbal comments. Peer reviews are more formal, and involve a roundtable of peers playing your content and meeting to present prepared notes to you and each other. Levels will also be reviewed by the lead level designer and artists whose work is used in the level, resulting in more notes.<br />
<br />
The key with the majority of feedback is to not react to it. Not immediately. We prefer to catalogue this feedback instead. It's very easy to be distracted by a good suggestion, but these can also lead to “different-not-better” revisions. It's better to compile feedback and decide how to react based on observable trends, and only after having sufficient time to digest the feedback and consider its impact.<br />
<br />
<b>PASS THREE</b><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5cat2hV4wu9biIhrEyspXDlkEHbkH_Vw8BBieIQjWZnW9OuPn5_U5iKlgYw2gmjw7dbtHSNhaooiQfh3yEFaGKPdHl9p0mmGSblu4L6td981AQmBwikZNy0ReJ7qNrxTXSTaE/s1600/image038.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5cat2hV4wu9biIhrEyspXDlkEHbkH_Vw8BBieIQjWZnW9OuPn5_U5iKlgYw2gmjw7dbtHSNhaooiQfh3yEFaGKPdHl9p0mmGSblu4L6td981AQmBwikZNy0ReJ7qNrxTXSTaE/s1600/image038.png" height="143" width="200" /></a></div><b><br />
</b>More time passes, and it's onward to pass three.<br />
<br />
Pass three is called the "Content Complete" pass. By now, the core gameplay systems are all in place.<br />
<br />
We're well beyond the Vertical Slice, and while the game is still largely unpolished and some features are still missing, we've got at least the beginnings of everything we need to move on. This is often the first time that the home stretch is within sight, although it's just barely on the horizon.<br />
<br />
The primary goal of the level designer at third pass is to ensure that nothing in the level remains which is missing, temp, broken, or otherwise unaccounted for. This doesn't mean that we'll actually complete every third pass with literally nothing missing, however, as things like missing art or features will be beyond the control of the level designer. The responsibility of the LD, in this case, is to make sure that the missing content is accounted for. A missing piece of custom art, for example, should be checked on to verify that it's on the schedule, and we know roughly when it'll be completed so that it'll be possible to implement once it's available. More importantly, it allows us to catch scheduling oversights sooner than later. If that piece of art never got scheduled or was cut, we can take the opportunity now to make alternate plans. Otherwise we could end up with a nasty surprise and a hasty solution later.<br />
<br />
Beyond this, there's a general focus on refining the gameplay established during second pass. This could mean implementing new encounters that were unavailable before, adding more handling for things that were only placeholder before, or generally reacting to pertinent feedback received since second pass.<br />
<br />
Third pass is also good time to generally reconcile the expectations of systems design with the reality of the content in the game. Remember that systems design, like any other part of the game, is really just an assemblage of ideas at the beginning of the process. By now, many of those ideas have been put through the crucible of implementation, and we have a better idea now than before of what we actually want to see in the levels. It's possible, for example, that a type of crafting station may have been cut, while we generally would like to work more lock picking opportunities into the spaces. By keeping abreast of this, we can organically work systems into and out of levels now, rather than retroactively at a later date.<br />
<br />
One of the tools available to a level designer on third pass is a feedback buddy. The nature of a third pass makes it easy to misstep, so we pair up to make sure a specific counterpart is available to gut-check the third pass while it’s in progress. This might mean using the feedback buddy for a technical opinion, to play a piece of content, or otherwise offer perspective.<br />
<br />
It's worth mentioning that every third pass is a little bit different. The passes so far have been focused; concept, layout, gameplay. By third pass, each level has started to develop its own personality, meaning that the level you work on this week may require a lot of attention dedicated to scripting a complex setpiece, whereas the one next week is spent fixing a layout problem that wasn't caught until now. This places more responsibility on the individual level designer to self-manage his or her time - another reason that due dates are useful.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpDxS0TdRJd-2myQr_zCkFjREwLW-tH7lYXo_zuXH0ozXIrlVpsgGnA4xRhK0M4v_dUbslMcgADISlvWVTcLEyVre5XSN2VNw0A9b_UHHbP2Oj-49eupXqf7YstUTVKgkqqP3a/s1600/image040.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjpDxS0TdRJd-2myQr_zCkFjREwLW-tH7lYXo_zuXH0ozXIrlVpsgGnA4xRhK0M4v_dUbslMcgADISlvWVTcLEyVre5XSN2VNw0A9b_UHHbP2Oj-49eupXqf7YstUTVKgkqqP3a/s1600/image040.png" height="182" width="400" /></a></div><br />
We avoid doing further optimization at third pass. This may seem incongruous with the emphasis on optimizing at second pass, but remember that it was preventative at that point. Not enough has meaningfully changed to revisit this work.<br />
<br />
So... a small confession. We don't actually call third pass "content complete" at the studio. I made that up for the purposes of this article. What I colloquially call it around the office is the "ship with shame" pass. This is because a third pass complete level, if you put a gun to my head, could be shipped. Nothing should be missing or broken; it's all technically there.<br />
<br />
But there's an important distinction to be made here. Completion does not assure quality. Third pass is not as much about quality as it is about confidence. The process of taking a level through third pass should give us confidence that we'll be able to complete the level according to plan. More importantly, it's going to give us the confidence that we can execute on this level to a high standard of quality between now and ship.<br />
<br />
Third pass is meant to be our springboard to opportunity time.<br />
<br />
With that in mind, third pass also marks when it's time to admit that certain ideas just aren't working. I've mentioned already that we don't like to idly demolish existing work. If something has failed to click by now, however, there's a good chance that it's not going to, and a discussion should be had about how to proceed.<br />
<br />
When possible, we try to deflect the blow. It's sometimes possible to course-correct with relatively minor tweaks or re-working. Sometimes scope is the problem, and trying to pare back on overly-ambitious ideas allows us to attain greater focus. We also have some time set aside in the schedule for "mulligan passes", which are basically a do-over on a prior pass.<br />
<br />
Sometimes it's necessary to consider cutting the level. Nobody likes having their content cut, and these can be difficult conversations. Well-placed cuts can be liberating, though, and allow us to flush difficult problems that would otherwise have required a great deal of time and attention. That time and attention is better spent on levels with greater potential in the long run. Given the choice, it's better to spend effort elevating a good level to great than spend that same effort elevating a bad level to mediocrity.<br />
<br />
Another tool at our disposal is a strike team. Strike teams are similar to pods or cabals you may have heard of at other studios, and are really just a multi-disciplinary group of developers who come together to focus on a particular feature or piece of content. We use strike teams in a number of ways at BGS. Often a strike team can focus on a feature that hasn't gotten much attention yet, and rapidly get it into a usable, testable state. We also use them to fully exploit opportunities or polish content with high visibility. We can also use a strike team to assemble a team around a designer who has been struggling, however, and make a push so solve difficult or ambitious problems.<br />
<br />
Occasionally, however, the most direct solution is putting in hours. Crunch. I pointed out early on that I hate crunch, however, so why would I ever point to it as a problem-solving tool? It's because we only think of crunch as an absolute last resort. Imagine that you're a level designer with content on the cutting block. You may go to your lead and offer to crunch if you're confident that's going to solve the problem. If you're already working six days a week, however, or regularly staying late into the evening - or both - how is that lead supposed to believe you? What additional hours are left to put in? Even if you could put them in, the chances are high that the physical and mental strain will result in lower overall productivity, and there's a risk that you'll actually introduce bigger problems in the form of bugs and poor judgment.<br />
<br />
The same situation plays out differently if you're working reasonable hours, however. Short-term, self-directed crunch can work as a stop-gap solution. When you've got no other options, it’s an effective blunt instrument. It isn't pretty, and putting in hours won’t impress anybody, but the option exists if you aren’t already overextending yourself.<br />
<br />
<b>THE BEAUTY PASSES</b><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiC3aVy250E6tuK5rD7hb2MTmYzqz1or6wipLevfKKSFCWUjMRiggXdUx6K3xVyL0aBkN7Wot6L5TqFe4n2RXQq3jco65zN9G-XW787mLr1ijg_zMzKEga6u5QyxnivVqoFSLEu/s1600/image042.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiC3aVy250E6tuK5rD7hb2MTmYzqz1or6wipLevfKKSFCWUjMRiggXdUx6K3xVyL0aBkN7Wot6L5TqFe4n2RXQq3jco65zN9G-XW787mLr1ijg_zMzKEga6u5QyxnivVqoFSLEu/s1600/image042.png" height="160" width="200" /></a></div><br />
Once third pass is complete, we get a bonus pass of sorts: the beauty pass.<br />
<br />
Beauty passes generally happen as the art team begins to gradually transition away from generating new content and towards polish and optimization. This shift is important for optimization because programming needs a reliable baseline to test from. That is, if an area ceases to load, programmers would like to be reasonably sure that it's because of a code change, and not because new content checked in the evening prior.<br />
<br />
This frees some artist time up to help with things such as lighting, detailed clutter, atmospheric effects, and our sound engineers even pitch in with an audio pass. The level designer is generally hands-off during these passes. The artists will do this work better and more quickly, and it frees the level designer up to focus elsewhere.<br />
<br />
The main thing to avoid on this pass is to be *too* hands-off. It's up to the level designer to communicate the intentions behind the level, and any particular needs or problems the artist may be able to solve. These artists shouldn't be thought of as janitorial staff, brought in to clean up after the level designers, but as collaborators who are taking an ownership stake in the level.<br />
<br />
While the beauty passes are going on, level designers will be turning their attention towards final pass.<br />
<br />
<b>FINAL PASS</b><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEinRWh3FabQWsbascCAC51opvA1zwCv8O5Fp-DThk05BzznrhcdwWLBxJKmRi07ULmuyfeLHa1Cz9UIkKZVQmAnPmse02xVmRxnmX6vsqknwNWGRLd7oSFwP4tR1cPITK5AM_k0/s1600/image044.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEinRWh3FabQWsbascCAC51opvA1zwCv8O5Fp-DThk05BzznrhcdwWLBxJKmRi07ULmuyfeLHa1Cz9UIkKZVQmAnPmse02xVmRxnmX6vsqknwNWGRLd7oSFwP4tR1cPITK5AM_k0/s1600/image044.png" height="143" width="200" /></a></div><br />
Final passes arrive as the game begins the march towards release. This is it: go time. Final pass is our chance to make sure we're shipping the best content we possibly can. Because after this, that's it. The core of the game is pretty much all accounted for, and the focus will be on quality until the point at which we need to pivot towards release.<br />
<br />
During final pass, the goal is clear - polish everything. This pass is often about accentuating the positives of your level, while removing, fixing, or otherwise de-emphasizing anything negative. There are often late-game realizations that we can capitalize on now. Say that some particular enemy and weapon combination is a lot of fun, but never really presented - these things can sometimes be easily worked into a level you're polishing.<br />
<br />
Team feedback also comes in tidal waves throughout this pass, giving level design a great deal of insight about what in the game could stand to be showcased or improved upon.<br />
<br />
Beyond that, final pass demands that we do any housekeeping that remains. This may mean taking measures to optimize for performance, ensure level data is correct, fine-tune navmesh, or otherwise make sure the level is fully functional. The hope, however, is that most of this work is taken care of by now, allowing us to focus the majority of our attention on polish.<br />
<br />
One more little confession to make. You may have noticed that I haven't called this "Fourth Pass". That's because fourth pass isn't always the final pass. Every space receives a fourth pass. Upon Playtesting, however, we may decide that a particular level should undergo another pass and receive further polish.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6BMbAA3KxytLPHo4KndktA8Q2IdvBuZLqZ4gmLDkyqJIOtcceBAykzFZReC6fxv5LCBaRLQk1LOSgQvhW-2lmymG3dqQzAeACqeOBA99yTe4fBbMhehGgbKt5Udl8mIQiHgYx/s1600/image046.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6BMbAA3KxytLPHo4KndktA8Q2IdvBuZLqZ4gmLDkyqJIOtcceBAykzFZReC6fxv5LCBaRLQk1LOSgQvhW-2lmymG3dqQzAeACqeOBA99yTe4fBbMhehGgbKt5Udl8mIQiHgYx/s1600/image046.png" height="151" width="320" /></a></div>Some spaces won't require this and ship in their fourth pass state, but others might get five, six, or more passes. This is sometimes because the content isn't meeting expectations, but more often it's because we see potential that we'd like to further capitalize on.<br />
<br />
It's only because of the foundation laid by our earlier passes that we're able to do this. Those first passes, concept, layout, gameplay and completion, are primarily a form of Structural Iteration. That is, each is focused on steps we know are necessary for us to create a level. Laying and testing that foundation throughout the early stages of development doesn't just occupy otherwise-idle hands. Process empowers us to spend the latter half of our development focused on making a game that's meeting our standards for quality, rather than scrambling just to get it done. Put another way; everything beyond third pass is focused on Qualitative Iteration.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCaBh_e2F-4coVDqDIzoDwIHZGEBtMuh0UGRxYvw6DrnhAdX5ArJiIZSl1o0ZrkUw20iEncnE3uG4pjenK50XwV5AS9PzV2NkcB7yghe7iamLiyxnkC2Nhj1epikKHdEdXP3KU/s1600/image048.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCaBh_e2F-4coVDqDIzoDwIHZGEBtMuh0UGRxYvw6DrnhAdX5ArJiIZSl1o0ZrkUw20iEncnE3uG4pjenK50XwV5AS9PzV2NkcB7yghe7iamLiyxnkC2Nhj1epikKHdEdXP3KU/s1600/image048.png" height="201" width="400" /></a></div><br />
That's the core goal of the whole process - meaningful, qualitative iteration happens in opportunity time, which inherently occurs in the latter stages of development - and so we try to maximize the amount of opportunity time available to us.<br />
<br />
<b>PERSPECTIVE</b><br />
<br />
Allow me to close this with a few thoughts on perspective. I briefly mentioned at the beginning of the article how easy it can be to lack perspective when working on any creative endeavor. Our process aims to grant perspective where it is otherwise so easy to lose track of it. Level designers are responsible for a lot of content at BGS, and it can be very easy to wheedle away at some nuance or detail in one area, to the detriment of other areas which we'll have to neglect as a result. By continually moving forward in step with the progress of the game, we're able to keep the big picture in mind. <br />
<br />
Every game developer should keep in mind that there's no such thing as a truly finished game. I don't know a developer who can't tell you at least one thing they wish they could have improved upon or fixed in a game he or she has shipped. When you work on games, especially big games that take three or four years to create, it isn't long before you do the math and realize that you only get so many shots at this. Perspective helps us make the most of the time we have, and a healthy choice of process can help guide us to make sure that we don't just put everything we have into one game or two, but that we can continue to make games long into our lifetimes.<br />
<div><br />
</div>Joelhttp://www.blogger.com/profile/09816332769743524346noreply@blogger.com2tag:blogger.com,1999:blog-30579660.post-29402703063626592682013-04-19T13:44:00.000-04:002018-10-27T07:15:48.420-04:00Skyrim's Modular Level Design - GDC 2013 Transcript<br />
<h2>
<u><span style="font-size: x-large;">Skyrim’s Modular Approach to Level Design</span></u></h2>
<b><i> Originally presented @ Level Design in a Day, GDC 2013<br />
Co-Authored and Co-Presented w/Nate Purkeypile<br />
<a href="http://www.slideshare.net/JoelBurgess/gdc2013-kit-buildingfinal" target="_blank">Slides available here.</a></i></b><br />
<h4>
<span style="font-weight: normal;"><br />
</span></h4>
<h4>
<span style="font-weight: normal;">While many developers understand the basic concepts behind a modular system, and some have dabbled in it for a project or two, very few have made a career out of it. That’s exactly what Nate and I have done, however. Our current project will be our fifth together in the near-decade we have known and worked with each other. Every one of these projects has taken this kit-based approach, including those we worked on before joining Bethesda.</span></h4>
<div>
<span style="font-weight: normal;"><br />
</span></div>
We recently realized that there are many unspoken understandings we and our colleagues share; expectations and assumptions taken for granted as part of our process. We've struggled to explain ourselves in detail for new artists and designers who had joined our team. This talk was a way for us to explore and articulate this accumulated knowledge.<br />
<br />
To understand our approach, it’s useful to know where we’re coming from as developers, and where Bethesda Game Studios is coming from as a whole. <br />
<a name='more'></a><br />
Let's begin with a pretty simple observation: our games are big. If you've played or read about Skyrim, Fallout 3 or any of our other open-world games, scope is a big part of them. It’s an <i>integral</i> part of our games and our DNA as a studio. You couldn't boil Skyrim down to a six-hour game and expect to provide the same experience. Scope isn't a random attribute of our games; it’s a major feature. <br />
<br />
When you play a Bethesda game (or when you work on one) you know this going in. The games are big! This influences everything we do at the studio. Production methodologies, tech and tools, workflow, pipeline - it’s all informed by a need for efficiency. We need high bang-for-buck on everything we do. Games like Skyrim take a few years to make, even moving as efficiently as possible. With a game that big, missteps aren’t measured in hours or days, but scale to weeks and months. <br />
<br />
These core values, along with the circumstances of team size, and our collective experience making games together all adds up to what you’d commonly refer to as studio culture. Even if your team or your game isn’t driven by the same forces as ours, chances are you could take a lesson from us, just as we could probably take a lesson from you.<br />
<br />
With that in mind, consider this a case study. The modular approach to level design we’re analyzing here is just one manifestation of the BGS studio culture.<br />
<br />
Before getting too far into things, let's me define what a “kit” is. Kits, first and foremost, are systems. A basic pipe kit, like the one from Fallout 3, may only be four simple pieces of art which can be used together. This kit, as most, snaps together using a grid system. The most important attribute of a kit is that it adds up to far more than the sum of its parts. This artist hasn't just given us four pieces, but a system with which we can create infinite configurations of pipes, all on the editor side.<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
<div style="text-align: left;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMbA_DNOg_yP6_9fTHsed0-lQL7VEtvS94Y42FQ1veAa4pvM4zm9xdvum3UPOIa7J6IVEjwBvTu9I1otMe65iHUesFfy-27xxcNIQs-DfCS9rWYn6hczhrED-D0GlTdOkUZrFZ/s1600/gdc2013pipes.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiMbA_DNOg_yP6_9fTHsed0-lQL7VEtvS94Y42FQ1veAa4pvM4zm9xdvum3UPOIa7J6IVEjwBvTu9I1otMe65iHUesFfy-27xxcNIQs-DfCS9rWYn6hczhrED-D0GlTdOkUZrFZ/s320/gdc2013pipes.png" width="320" /></a></div>
While the pipe kit is a good example of a simple art kit, our primary topic here is architectural kit creation. Examples of architectural kits would include the Nord Crypts in Skyrim, or the Vaults from Fallout 3. This is important to topic for gameplay, because kits are the primary building blocks of level design at Bethesda Game Studios.<br />
<br />
Kits aren't a new idea. They aren’t unique to Bethesda or to the types of games we make. Consider the board game <a href="http://en.wikipedia.org/wiki/Carcassonne_(board_game)" target="_blank">Carcassone</a>. Unlike Monopoly or Scrabble, the board changes every time you play Carcassone. The tiles are arranged so that roads meet roads, rivers meet rivers, and so on, creating an effectively randomized yet visually cohesive whole. It’s easy to see the grid when looking at a Carcassone table, and how this system of art works together to make a unique play field. The board tiles are themselves an excellent example of an environmental art kit.</div>
<br />
Many sprite-based, 2D games make heavy use of similar ideas and techniques to those we’ll be discussing today. Sprite sheet or texture atlas technology lies at the heart of many 2D game systems, so it’s easy to see how those games lend themselves to repeatable tiles of a uniform size. Thanks to this, it’s not necessary to paint the entire world by hand. Designers and artists can use art systems of repeated tiles to draw out the map quickly and with less of memory footprint.<br />
<br />
Back in November of 2002, Lee Perry (then of Epic, now <a href="http://bitmonstergames.com/" target="_blank">BitMonster</a>) authored an<a href="http://udn.epicgames.com/Three/rsrc/Three/ModularLevelDesign/ModularLevelDesign.pdf" target="_blank"> article in Game Developer magazine</a> which explored a modular approach to level design and world building, specifically as a way to help cope with the increased fidelity of games at that time. <br />
<br />
Bethesda has been at this for quite some time - 18 year as of this writing. Terminator: Future Shock and the Elder Scrolls 2: Daggerfall, both games which far pre-date our<span style="font-size: x-small;"> (<i>Nate and Joel's</i>)</span> tenure at the studio, embraced a modular approach to world-building, which would become the foundation upon which much of our current thinking and technology are built.<br />
<br />
So remember - the concepts discussed today are far more than the product of our work together over the past decade. Many influences and ideas have contributed to our current workflow, and there are many lessons yet to be learned.<br />
<br />
<h3>
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0b51o9hNLvXiT9jgdvjJuoe1-Igyl9brkxkKNaonpJheMFjF-4OIOjxrqa9pm0Cn0jvtddEvv_mcpzqodjBLL2tTG1yBweHSPpmSse57JbaeLbcGzcwRWIFqQq4sMpEix-ymg/s1600/webVaultAntFarm.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="158" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi0b51o9hNLvXiT9jgdvjJuoe1-Igyl9brkxkKNaonpJheMFjF-4OIOjxrqa9pm0Cn0jvtddEvv_mcpzqodjBLL2tTG1yBweHSPpmSse57JbaeLbcGzcwRWIFqQq4sMpEix-ymg/s640/webVaultAntFarm.png" width="640" /></a><u><h3>
<u><br /></u></h3>
<h3>
<u><br /></u></h3>
<h3>
<u><br /></u></h3>
<h3>
<u><br /></u></h3>
<h3>
<u>Going Modular: Pros and Cons</u></h3>
</u></h3>
As mentioned earlier, many developers understand the principles behind modular level design, but we hope to offer insights gained from our extensive exploration of this topic. To do this, we’ll go over the various benefits and drawbacks we've found over the years, with an emphasis on how to get the most out of the workflow.<br />
<br />
The first, most self-evident benefit of working with modular art is that it’s reusable. Reusing art helps us mitigate the huge scope of our games. There’s a massive amount of world-building to be done in Skyrim, and not having to specifically create and export every fence post and doorway becomes very important to us. We try to be smart about where we spend our time and attention, reusing art where it makes sense, and investing time where we want something more unique.<br />
<br />
Consider this list of features, which together make up the rough measure of Skyrim’s world-building needs:<br />
<br />
<ul>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>16 sq. mile Overworld</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>5 Major Cities</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>2 Hidden Worldspaces</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>300+ Dungeons</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>140+ Points of Interest</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>37 Towns, Farms & Villages</li>
</ul>
<br />
Now consider that alongside this photograph of the Skyrim development team. There are 90 people in the photograph below. With the exception of a small number of outsourced assets, you’re looking at the entirety of the dev team across all disciplines. We've resisted the temptation to grow into a multi-studio team of hundreds, such as you often find behind games of similar scope to those we make.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHyxmCHwaRQLTsuifgQezuaiHed_qFxal57pwioReaYNVXYk1LsHKvXFmN4CFaX-ukF0zXRf2aVSBZ3Dipo4qDsf5tNsnDDyeusq4Q2MBKzbi54ymj4xjengrovFh2OUi45Qc8/s1600/SkyrimTeamPhoto.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="402" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHyxmCHwaRQLTsuifgQezuaiHed_qFxal57pwioReaYNVXYk1LsHKvXFmN4CFaX-ukF0zXRf2aVSBZ3Dipo4qDsf5tNsnDDyeusq4Q2MBKzbi54ymj4xjengrovFh2OUi45Qc8/s640/SkyrimTeamPhoto.png" width="640" /></a></div>
<br />
Today we're focused on what you’d most typically associate with traditional level design at Bethesda; the dungeons component of that world-building work. Only ten people out of the 90 in that photograph are directly responsible for those dungeons. The rest of the team is focused on the myriad other features, content, systems and support needed to build a game like Skyrim. You can begin to appreciate how small our dev team really is when you consider how much responsibility each person needs to shoulder.<br />
<br />
Sooner or later while reading this, you may think that the scope of the game is a restriction that limits our ability in some way, that it’s a burden we wish we could shrug off. The thing is - even if our circumstances were different, and we had infinite time, resources, or talent - I don’t think the way we make games would look all that different We've found a way that works for us.<br />
<br />
Consider the Dutch artist Piet Mondrian, famous in particular for his work in Paris during the 1920’s. You may not know Mondrian by name, but you’re likely to recognize his work, such as the piece seen below. Mondrian had access to more than four colors of paint, and was certainly capable of more technically complex work. Yet he chose to self-impose restrictions which led him to pioneer a style he may not have otherwise discovered. The influence of that style is still felt today in art and fashion.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgnUuJ8M2ADFO5R1PvkXe872SpTHBYXbrfxkVMMvPOubGezMmvQrmaPlNXR4S9Ifox_cO3hphWPMqsdU5h4uroIuV8vuEdOP3bX1pP-segiHnER-BwjPwjGE28hBdK-Fx17fBiu/s1600/Mondria.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="317" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgnUuJ8M2ADFO5R1PvkXe872SpTHBYXbrfxkVMMvPOubGezMmvQrmaPlNXR4S9Ifox_cO3hphWPMqsdU5h4uroIuV8vuEdOP3bX1pP-segiHnER-BwjPwjGE28hBdK-Fx17fBiu/s320/Mondria.png" width="320" /></a></div>
<br />
Look throughout the history of science, technology, music, anywhere people are creating, and you’ll find examples of restrictions not limiting creativity, but focusing it and leading people toward new discoveries and innovations. I think our workflow is like that. To change it because of a shift in circumstance would be ignoring the belief systems and experience that led us to that conclusion.<br />
<br />
Getting back to the topic at hand, we should also acknowledge the most self-evident drawback of using modular art: the fact that resused art can become repetitive. This leads to what we commonly refer to as “art fatigue”. The median play time of Skyrim on Steam has peaked at well over 100 hours, which is a huge compliment . With that kind of time spent, however, players are bound to notice the same rock or farmhouse or tapestry used again and again. And another two dozen times after. Art fatigue sets in where this repetition becomes obvious and erodes the authenticity of the world.<br />
<br />
We've found some ways to delay the onset of Art Fatigue. One of the big ones is simply doing away with copy and paste design as much as possible. When I first joined Bethesda, Oblivion was poised for the home stretch of its development cycle. Oblivion was of similar scope to Skyrim, yet built by a team of about half the size. One of the ways the dungeon art team coped with this disparity was to create a number of “warehouse” cells in the editor. These warehouses contained fully lit and cluttered rooms to copy, paste, and then arrange to create "new" dungeons. While efficient, this method left much to be desired, and many players rightfully called Oblivion dungeons out as being “cookie-cutter”.<br />
<br />
One thing we noticed was that players were quicker to react negatively to repeated detail elements, as opposed to broad architectural repetition. Consider the following three screenshots, each taken from a separate Oblivion Dungeon.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvQvqOo7Dzb7K5epZjgBXVg4QDZJyDQDIqzRMSnoDg7wyKcMXcA5VFlXDkL7yI0QBYjeKu_XPE1HDEiedtxxcS-Rl1gPA9lKbnGCRdnKmjWC4gb2Ytg49OOB-b91HaHT4aHe6b/s1600/Obliv02.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="363" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvQvqOo7Dzb7K5epZjgBXVg4QDZJyDQDIqzRMSnoDg7wyKcMXcA5VFlXDkL7yI0QBYjeKu_XPE1HDEiedtxxcS-Rl1gPA9lKbnGCRdnKmjWC4gb2Ytg49OOB-b91HaHT4aHe6b/s640/Obliv02.png" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTfD8fjeLlqV6h6iFKfk4EIIXxMhCuMvrYybWrtbFsrr7g0PNLXdFrHX7Fm7YrHXgVchEde0OjnuDK15epeUUDCZwsgSHLWdmDkhUJQZYDvOBTM0jTmSPhCEYwwOe0ge9pkP1M/s1600/Obliv01.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="363" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTfD8fjeLlqV6h6iFKfk4EIIXxMhCuMvrYybWrtbFsrr7g0PNLXdFrHX7Fm7YrHXgVchEde0OjnuDK15epeUUDCZwsgSHLWdmDkhUJQZYDvOBTM0jTmSPhCEYwwOe0ge9pkP1M/s640/Obliv01.png" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0FBAN4lvHPoeEqx_O0yynt4k6BiBGhu_W424Vn4QyJZuqCTvwdptf30utmwZboTXnqgjsk8XOuJxb1aGXvhGfEJB52DYlJdRCevFeXScHphEkvfmM0wlxDU_MyWKxbQRJGzNa/s1600/Obliv03.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="363" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0FBAN4lvHPoeEqx_O0yynt4k6BiBGhu_W424Vn4QyJZuqCTvwdptf30utmwZboTXnqgjsk8XOuJxb1aGXvhGfEJB52DYlJdRCevFeXScHphEkvfmM0wlxDU_MyWKxbQRJGzNa/s640/Obliv03.png" width="640" /></a></div>
<br />
In each, you’re more likely to pick up on repeated clutter first, then the repeated architecture. This is especially true in actual gameplay from a first-person perspective. To minimize needless repetition, we abolished the use of warehouse cells as they existed in Oblivion. Beginning with Fallout 3, we staffed up a group of level designers and got tool support to make sure we were able to build spaces more quickly, and with the most granular art available, reducing the amount of repetition as much as we possibly could.<br />
<br />
You can also fight art fatigue at a more fundamental level. It’s common at the start of a project to strongly associate a particular setting with specific types of inhabitants or gameplay. You may want to only see soldiers in military bases, and zombies in crypts, for example. Resist this. Think of your kits as the architectural identity of the space, and allow other elements to establish the specific identity of any given space in which it’s used. The more you’re able to divorce these things, the more you’ll be able to mix elements up and keep the settings fresh.<br />
<br />
This also applies to the kits themselves - try to actively encourage the notion of mix-and-matching your kits. This is sometimes called <a href="http://en.wikipedia.org/wiki/Kitbashing" target="_blank">kit-bashing</a>, kit-jamming, or a kit mashup.<br />
<br />
Look the following examples of Dwarven dungeons from Skyrim. The first delivers on the expectation of any Dwemer dungeon in an Elder Scrolls game. There’s a chunkiness of proportion, an emphasis on brass highlights and clockwork elements which are all hallmarks of that style. Skyrim features around ten of these dungeons, however, and they’re all pretty big. If they were all the same, it’d be a dull, one-note experience, and take the thrill out of discovering one.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidfYtIOpmzol1yG-a5VNtaDpcbqlrwhfg_ZZZhRzTekb0dt-6TVfMqQhKDpUzajM36sdXdBD4A9DImNNayk12MWFwoQTSA3yPMrdkuDwPw4iRt1rRam2aSn_nrqKBRGW8nv0iG/s1600/Dwem01.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEidfYtIOpmzol1yG-a5VNtaDpcbqlrwhfg_ZZZhRzTekb0dt-6TVfMqQhKDpUzajM36sdXdBD4A9DImNNayk12MWFwoQTSA3yPMrdkuDwPw4iRt1rRam2aSn_nrqKBRGW8nv0iG/s400/Dwem01.png" width="400" /></a></div>
To try and mix things up, we started playing around with ideas like combining exterior elements. In the second example we've introduced some lightweight unique assets and enemies you’ll only encounter in this particular Dwarven dungeon. This twist on visual and gameplay expectation helps keep the setting fresh and combats art fatigue.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNjRGFSE6RtdBVSyzrRs_THoaprOd2X_gyaco3v21y9fbMWBvAZJPqrOfBbFLgN9__Kz6uATBKdLp3Zirg5MksI_xSHYVJbdrlRyw46PbQp33c5Th0ob26h7lyXO2tQ3ftYQop/s1600/Dwem02.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNjRGFSE6RtdBVSyzrRs_THoaprOd2X_gyaco3v21y9fbMWBvAZJPqrOfBbFLgN9__Kz6uATBKdLp3Zirg5MksI_xSHYVJbdrlRyw46PbQp33c5Th0ob26h7lyXO2tQ3ftYQop/s400/Dwem02.png" width="400" /></a></div>
In the third example, the level designer simply tried bashing Dwarven hallways with ice caves. What he achieved was an instant shift in tone and atmosphere. Some artists will be uncomfortable with this idea. The notion of your art being used in unforeseen ways could lead to bad intersections or lighting issues, for example. To work on this kind of game, however, you need to take a couple of steps back and be open to this. Allow for this kind of experimentation and have it in mind when you’re creating the art to begin with. Not every combination will look good or make sense, but you can be part of a conversation about what works, what doesn't - and most importantly, what <i>almost </i>works, but could work great - with a little tweak from you.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicvM6xWydDeucjcQReHexCLDF942RGF4XwG4HxwzpsgzBXwR6im0lUAWTBbFuO81Fy7isauJX0cpYF66gsXm-JVE8Jn_i4n-ehsZiHkLWYoPvxmBm91s9jHD_aECAhqBeWpfiA/s1600/Dwem03.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicvM6xWydDeucjcQReHexCLDF942RGF4XwG4HxwzpsgzBXwR6im0lUAWTBbFuO81Fy7isauJX0cpYF66gsXm-JVE8Jn_i4n-ehsZiHkLWYoPvxmBm91s9jHD_aECAhqBeWpfiA/s400/Dwem03.png" width="400" /></a></div>
<br />
Looking again towards the benefits of working modular, one of the big bonuses (<i>especially from a production viewpoint)</i> is that a modular approach helps if your team has a low ratio of artists to designers. Remember the ten people responsible for the dungeon content in Skyrim? Eight of them are the level designers, and only two represent the entirety of our full-time kit art team. They generated seven kits, which the level design team used to create well over 400 cells, or unique loaded interiors, of dungeon content. And those dungeons were built in about two and a half years, from start to finish.<br />
<br />
To put this into proportion, the infographic shown here represents the kit art team as yellow, level design as orange, and the blue-gray area as a conservative estimate of the dungeon content created by that collective group.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjENqrgoEqv1QyaSgY9U9udCTPKiv-ZlE7MEiKXkwFPyQ_bVelhqt7ifYJLu7tmPPAo8dPCtjk3lYmZB6viEi6B5S_1PLE1YBGnNsSrTI3tawSjE9fZ-hBYzYzsHBIuggpTJ2Db/s1600/GDC2013Infographic.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="304" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjENqrgoEqv1QyaSgY9U9udCTPKiv-ZlE7MEiKXkwFPyQ_bVelhqt7ifYJLu7tmPPAo8dPCtjk3lYmZB6viEi6B5S_1PLE1YBGnNsSrTI3tawSjE9fZ-hBYzYzsHBIuggpTJ2Db/s320/GDC2013Infographic.png" width="320" /></a></div>
<br />
There are two points to make here. The first and most obvious: this approach allows a small number of artists to support a much larger team of designers, who can in turn generate a lot more content than those two artists otherwise could. The example provided by Skyrim shows just how effective this approach can be, when only two artists were required to provide the core art behind so much content.<br />
<br />
The second, less-obvious point is the more important one, however. Think of the other 80 people in that team photograph. Because such a relatively small group was able to handle the dungeon component of the game, it allowed the rest to focus on the myriad other needs of the game, whether it was landscaping the massive world, writing and scripting the many quests, contributing to character art and animation, working in the guts of our game code.<br />
<br />
Of course, there’s another reason that Skyrim had only two full-time kit artists; kits are really complicated things to work on. Kits require not only the artistic ability to produce high quality visuals, but also a technical competency in their art tool, a deep understanding of the editor and design workflow, and so on. This unique blend of left and right brain is somewhat at odds with what many art professionals value. I've worked with great artists who make excellent kits but hate working on them - so they don't.<br />
<br />
So when you’re trying to identify somebody with the the aptitude and interest to be a great kit artist, you’re basically looking for a unicorn. They're rare.<br />
<br />
Another example of the problematic complexity of kits is the process of identifying and fixing bugs with them. Kits aren't like other art assets, for which you might be asked to fix a bad pivot point or texture seam, but are otherwise fire-and-forget. It’s important and necessary that a kit artist can keep the entire system of rules in her head throughout the entire project. Kit pieces are instantiated dozens or even hundreds of times throughout the game. Making an obvious fix to something like a bad pivot point may address a specific bug but create new problems in those hundreds of instances elsewhere that you may not have thought to check.<br />
<br />
This does bring us to one of the other benefits or our approach, however, which is the very fact that kit pieces are heavily instantiated. When a change goes into a kit, those changes are instantly viewable across the whole game. As an artist, performing an export is like a fly-by deployment of new art, whether the level designers were waiting with bated breath or don’t really care.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirh5ETZwfFzMJkSevwlv04aUfXX1eIR0C-nkZA3vJbSFm6Vz6dpmUDtZSpsL8ES0BtdfEy9I-5Edu_w_dLvqqZzisSxUPdh1NuBJ4l59joqLPhCqFOFxxhGc6tIMs4CElUU-ep/s1600/gdc2013Airdrop.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="265" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirh5ETZwfFzMJkSevwlv04aUfXX1eIR0C-nkZA3vJbSFm6Vz6dpmUDtZSpsL8ES0BtdfEy9I-5Edu_w_dLvqqZzisSxUPdh1NuBJ4l59joqLPhCqFOFxxhGc6tIMs4CElUU-ep/s400/gdc2013Airdrop.png" width="400" /></a></div>
For artists this allows you to see your art in real-world use cases right away. There's no need to construct a test area. Just load up any level making use of your art and check it out. See how it really appears in game instantly. <br />
<br />
This deployment process also has minimal impact on the design workflow, which is not free, but something we work very hard towards. We’ll go into more detail later, but consider this. It’s often been the case that early in a project, art is trying to answer a lot of questions about how the game should look, and kits are no exception. This aesthetic process can be unstructured and time-consuming. The trouble is - design is often twiddling their thumbs at this stage, waiting for something to work with. This can result in art rushing through their process too quickly, sometimes making decisions they’ll change later, in ways that can drastically effect level design and force work to be thrown out or heavily revised.<br />
<br />
To avoid this, we get our kits to a "functional-but-ugly" state as soon as possible. This is discussed in more detail later, but the high-level idea is that we figure out as much as we can about how kits work first, which allows design to get working while art then can focus on their visual direction without being rushed.<br />
<br />
This is one of the contributing factors to another perk we enjoy; Bethesda level designers are quite fast. Because we’re working editor-side with pre-established kits, our level designers are able to iterate on layout extremely quickly. We can sketch with kits right in the editor and push those to the game, playing the results immediately.<br />
<br />
In fact, we’d go so far as to suggest that a level designer working with a good kit that she understands is able to iterate faster and truer to final gameplay than any other designer with any other editor or workflow in the industry. This is because she's using the actual, final art and playing it almost as fast as she can work. We don’t have turnaround with art, we don’t have to bake textures or compile geometry, and our markup is fairly minimal.<br />
<a href="http://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="http://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="http://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="http://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="http://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="http://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="http://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><a href="http://www.blogger.com/blogger.g?blogID=30579660" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"></a><br />
Ah, but there’s a catch, and it’s one of the major downsides of our approach. When we say that a Bethesda level designer is the fastest, it’s with a big caveat. We specify that she’s working with a good kit. Without that, she’s not just the slowest LD in the industry - she’s a non-starter. We’re totally dependent on the art we work with, which is why the relationship between art and design is so important.<br />
<br />
Consider an all-too-common tale from throughout the game industry. There are many variations of this story, but it’s typical that early in a project, designers are figuring out how their levels should play out. They may do this with editor BSP, external art and previs tools, or through paper maps and documentation. Whatever the method, design works on this until they’re happy enough with it to hand it off to art.<br />
<br />
Hopefully this process has been well communicated - but in practice it often isn't and the art team ends up in the difficult position of trying to polish something they weren't very involved with. They’ll do an art pass, though, and make the level visually appealing Once they’re at a place they’re happy with, they send it back to design for final markup and scripting. Once design has done that, the level should theoretically be done - right?<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiG6MBVTd0oPdXET3FpOGyZ3im4m3KQlj4vnLrRD3-TIZTl48qQEsvhEnCrKaK9uFCvx2mPilWpMV-metvK4cKyOwNnvLbkdHwIQe7E4WWWYOPAlMipv6AhAJj9k1stZR-riIgy/s1600/webHandoff.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="212" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiG6MBVTd0oPdXET3FpOGyZ3im4m3KQlj4vnLrRD3-TIZTl48qQEsvhEnCrKaK9uFCvx2mPilWpMV-metvK4cKyOwNnvLbkdHwIQe7E4WWWYOPAlMipv6AhAJj9k1stZR-riIgy/s640/webHandoff.png" width="640" /></a></div>
<br />
Not usually. Level designers often inherit a litany of unforeseen problems when receiving final art for their levels. Cover along a street has been converted into poles too thin to take cover behind. A wall intended as a visual blocker is now a see-though chain-link fence. A bridge now has support beams which occlude sight lines in a major gunfight you had planned.<br />
<br />
When work is handed off like this, it's often one of the main fault-lines of communication This story plays out again and again across all manner of games and teams. At best it’s non-optimal. At worst it can be downright toxic and create an atmosphere of hostility between art and design.<br />
<br />
We’re no strangers to this. We've had our share of communication problems and finger-pointing, and have sought out ways to avoid the whole mess. This has come largely from seeking more open communication and collaboration. <br />
<br />
Some users who download our Creation Kit comment that kits seem impersonal. To these people, our kit-based approach probably seems like anything except collaborative. Kits can seem restrictive when you’re an end-user - and in many ways they are. But this is one area in which the experience of a Bethesda developer differs greatly from that of a Bethesda modder.<br />
<br />
Kits don’t simply appear in the editor one day, fully formed from the mind of the artist and complete, with no further pieces coming along. There’s a process we've worked out to establish any kit, and it takes place over a period of time during which a level designer and artist are in full collaboration.<br />
<br />
<h3>
<u>Things To Know Before Beginning</u></h3>
This begins the technical portion, and it's worth establishing a few items. We’ll be referring to abstract units on occasion. If you’re familiar with Unreal units, for example, these are much the same. All you really need to know is that a character is usually about 128 units, or six feet, tall. We are also accustomed to a Z-up environment. If you’re used to Y as the vertical axis, keep this in mind.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY441pHDKRmPsyIZR6OCklq-W97aoYKdJ9-ITZmlP5snV_bsFzGwCjCTuy1dmM8shIHdpmdw_MGO1h0p3WsYAtXIyL1c4AUh0EDByaKytHQPTkLgqgRxlFE72WWaVqVOBEqu9T/s1600/webDovahScale.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY441pHDKRmPsyIZR6OCklq-W97aoYKdJ9-ITZmlP5snV_bsFzGwCjCTuy1dmM8shIHdpmdw_MGO1h0p3WsYAtXIyL1c4AUh0EDByaKytHQPTkLgqgRxlFE72WWaVqVOBEqu9T/s200/webDovahScale.png" width="185" /></a>There are a number of things you want to establish at a game-wide level before you begin on kits. As mentioned - you want to do this as early as possible. One thing we've found very useful is to determine a uniform dimension for door frames. This has a few benefits. It allows us to transition from kit to kit without unique pieces, as well as allowing easy re-use of doors between kits. More importantly, it gives AI and animation a fixed standard to work from, which can be reinforced throughout the game.<br />
<br />
It’s also worth figuring out the most narrow traversable space in the game. We usually stick to a minimum of two character widths. This allows us to avoid pathing problems by ensuring there’s at least enough space for two AI characters to path around each other in any given space. You should also know how steep of an incline your AI can navigate. In our case this has usually been 60 degrees, but you should also know what looks <i>good</i>. The full incline often looks bad for animation, and you may want to embrace 30-45 degree slopes in your kits.<br />
<br />
Finally, if you’re making a game with environmentally contextual gameplay, like a cover shooter or platformer, figure out some important gameplay measurements early on. If you’re making a platformer, figure out how far the player can jump. How far can the player fall before dying or taking damage? If a cover shooter, know what height of cover I can shoot out from. <br />
<br />
Keeping this kind of information in mind early will allow you to build kits that make the game look and play its best throughout.<br />
<br />
With that, we’re ready to get into what happens once we’re ready to actually start building a kit.<br />
<br />
<h3>
<u>Where Kits Come From - Our Process</u></h3>
<div>
When we're ready to begin any kit at Bethesda, a kit artist and a level designer are both assigned to that kit. There are several stages they'll go through in the initial establishment of that kit.</div>
<div>
<u><br />
</u></div>
<u><b>1) The Concept Phase</b></u><br />
<u><b><br />
</b></u> The first stage of building a kit is what we call the <b>concept phase</b>. This doesn't literally mean "concept art", although that is often involved. Rather, this is the stage at which we're first deciding upon the main ideas that will drive the kit. <br />
<br />
The main goal of this phase is to figure out the big picture ideas of the kit and how it fits in with the rest of the game. This usually takes a relatively short period of time because it doesn't involve any actual content creation. Instead, you're mainly answering questions. What is the visual theme of the kit? How is it different from other areas in the game? What kinds of spaces do you want to build with it? How will be it be used? How often will it be used? Some of these answers will be driven by design, others by art - it's important that both voices are being represented from the very beginning.<br />
<br />
Much of the visual process at this stage consists of gathering reference, working with concept art when applicable, and making sure we're all on the same page with the art direction for this kit. There are workflow and logistical questions we start asking at this stage as well, however.<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_ori0ENMk5OqaOYZkB1MkOIdbpmFhLs2TkIUtdbTbrvI-8JwikbRtea5AaccA7ag0otCFHvwo8XHZN1YNpp4ouv7oD29fVX_G_PXZTCThVkWVm-3U7w-1dpI2AmmSF3_BRc-y/s1600/webKitUsageBreakdown.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_ori0ENMk5OqaOYZkB1MkOIdbpmFhLs2TkIUtdbTbrvI-8JwikbRtea5AaccA7ag0otCFHvwo8XHZN1YNpp4ouv7oD29fVX_G_PXZTCThVkWVm-3U7w-1dpI2AmmSF3_BRc-y/s400/webKitUsageBreakdown.png" width="400" /></a></div>
<br />
Probably the most important question to answer is this: How widely-used will the kit be? This drives almost every decision when it comes to kit creation. For instance, the Cave Kit in Skyrim is used over 200 times, but the Ratway kit is only used twice. Consequently, the scopes of these two kits are very different.<br />
<br />
This also influences the number of "Sub-Kits" that each kit has. A sub-kit is what we call each part of the kit that works with the rest of it. Common examples include a "small room" sub-kit, or a "large hallway" sub-kit. The cave kit has seven sub-kits, while the Ratway has only three. The number of pieces in each of these sub-kits also varies between kits. The "small hallway" cave sub-kit has around 50 pieces. The Ratway hall sub-kit has only seven pieces. Knowing the scope of a kit will help you make good decisions about how robust the kit will need to be, and how much time should be spent building it.<br />
<br />
<b><u>2) The Proof Phase</u></b><br />
<br />
Once we're satisfied that we understand the big ideas driving the kit, we need to prove those ideas out. This is called the "<b>Proof Phase</b>".<br />
<br />
The point of this phase is to start to test out the major concepts of the kit, and it's the first point at which we'll begin building actual assets to bring into the editor.<br />
<br />
We're still keeping everything fairly high-level and not getting too deeply involved with building the art, however. Proof pieces have almost no mesh detail and usually no textures at all. Instead, we'll be playing with proportions, kit logic, naming conventions, and other basic needs. Because of that, this stage of the process is also relatively quick, often only 1-3 weeks, depending on the scope of the kit, and how many failed iterations of the proof pieces end up being created and disposed of.<br />
<br />
Before we can create the first mesh, however, there are several important details you have to know about kit-building.<br />
<br />
First, we have to agree upon one of the most important details for any kit - its <b>footprint</b>. The footprint is the foundation of the entire kit. The most common footprints for kits are equilateral, but other proportions can lead to kits with their own distinct feel. These fundamental decisions are very important, as it will influence the visual identity of the final kit. In this image, the green grid represents the footprint of several pieces used to build a simple room from Skyrim's completed cave kit.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjdlqj_v-kBJZVKjweWTxZVy5hvSYKg9B92sBJStf42uoDhIsknu3TLH7s1szeEbeHmCvJrx_7lnV4n6i-fV2X2AJu5PocfZ76fGCDg-DY0WulPsGwqu8UVG_UvOsRvSLWAbSzQ/s1600/GridChop.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="182" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjdlqj_v-kBJZVKjweWTxZVy5hvSYKg9B92sBJStf42uoDhIsknu3TLH7s1szeEbeHmCvJrx_7lnV4n6i-fV2X2AJu5PocfZ76fGCDg-DY0WulPsGwqu8UVG_UvOsRvSLWAbSzQ/s320/GridChop.jpg" width="320" /></a></div>
<br />
It's important to note that although the various sub-kits of one kit do not have to share the same footprint, those footprints should be multiples of each other. Otherwise, even if the kit pieces initially snap together, as a kit loops back around on itself, it will no longer line up. For example, a 512x512x512 room will always tile nicely with a 256x256x256 hallway, but a 384x384x384 room will eventually create gaps and/or overlaps.<br />
<br />
It is also very important to have your grid snap sizes as large as possible. Level designers tend to build on a grid snap setting of one-half the size of the footprint. If the default snap size is large, it is very easy to work with a kit. Pieces line up quickly and easily, and large gaps make it obvious to spot where pieces aren't lined up.<br />
<br />
Avoid attempting to create a kit which tiles on all axes. Hallways kits tend to tile on only one axis, while rooms typically tile on two. An all-axis tiling kit is able to create spaces which stretch out not only horizontally, but also vertically stack and tile on themselves. This kind of kit allows a great deal of building freedom, but is very complex to build and use. When vertical tiling is desired, it's generally wiser to build a separate sub-kit with a fixed horizontal plane size. <i>(See Skyrim's cave and Nordic "shaft" sub-kits for examples)</i><br />
<br />
It's extremely important to note that the footprint is the <i>full </i>bounds of the piece, and not the traversable space of the piece. It is the imaginary grid that things line up on. Pieces always exist within the footprint. The only time a piece is at the edge of the footprint is when it is actually snapping together with another kit piece. Avoid the temptation to build to the edge of the footprint, or even worse, outside of it.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgitxYDbYR71akW4W4evwka0QezuVHbtVxsSuGbDE4AiertzYo5CovXXUnjbS4XKHT3zcgL2gP1mSKLlFkjQ4_n5CeE0egV7ucPSE0365aeeYDCFZvQXxNxKVZI4km3upY8ePHT/s1600/GDC2013footprintoverlap.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="298" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgitxYDbYR71akW4W4evwka0QezuVHbtVxsSuGbDE4AiertzYo5CovXXUnjbS4XKHT3zcgL2gP1mSKLlFkjQ4_n5CeE0egV7ucPSE0365aeeYDCFZvQXxNxKVZI4km3upY8ePHT/s640/GDC2013footprintoverlap.png" width="640" /></a></div>
<br />
This is most evident in something like a hallway kit. If the walls of the hallway are along the edge of the footprint, there is no room for the walls themselves to exist; they will be co-planar. In the example pieces shown here, a hallway is built using the full extents of the footprint. The alcoves set into each wall extend outside the footprint area, creating an overlap which prohibits hallways running adjacent to each other.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9QXCCsOury8qVvXPcX2Z0uKVNAuE8WBzdtDnQJcRK1V2IwaETyFjGlCrFTIY2ckvopeaQDhfBYFvi8mHL4OHRJaUlXIwwProallUEH8d-R0hzZCJWp3K9b76nwB_eIMDoT41A/s1600/webFootprintAlcovesCorrected.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="254" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9QXCCsOury8qVvXPcX2Z0uKVNAuE8WBzdtDnQJcRK1V2IwaETyFjGlCrFTIY2ckvopeaQDhfBYFvi8mHL4OHRJaUlXIwwProallUEH8d-R0hzZCJWp3K9b76nwB_eIMDoT41A/s320/webFootprintAlcovesCorrected.png" width="320" /></a></div>
<br />
The second diagram shows a revised version of the same piece in which the hallway alcoves are planned and accounted for - they now exist within the footprint, allowing the hallways to run adjacent without incident. Note that level designers could have worked around the overlapping version, but doing so would be placing arbitrary and sometimes-awkward restrictions on layout.<br />
<br />
The proof process will help you identify and solve these problems early - save art and design untold hours of work, bugs and frustration that may have come later if we dived too quickly into building visually-complete pieces.<br />
<br />
<b><u>Sidebar: The role of the Level Designer</u></b><br />
<br />
Let's step away for a moment before continuing to the next phase of kit development. With all this emphasis on art, you may wonder what the role of the level designer is through these phases. <br />
<br />
Remember that this isn't something the artist does in isolation and hands off to design later. The process is best when the kit artist and level designer are interfacing on a daily basis. Each is an ambassador of a sort, representing different sets of needs and interests - the shared goal is to preemptively identify these differences and make them topics of conversation. They can otherwise become points of confusion and contention later.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQ5iIY9eAKnbNGjKUlzApQvJCNugV8tDALuj_iP2lZxtu_HptT514uk8JHWdzp__cLl6G2DklxoRDBTlXSH9ma_GpXC7nlX8dIsWEOW-OuRAv-fs7ezyRNWbtLpN7KQ7R_Ren6/s1600/webFriendlyDebate.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="139" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQ5iIY9eAKnbNGjKUlzApQvJCNugV8tDALuj_iP2lZxtu_HptT514uk8JHWdzp__cLl6G2DklxoRDBTlXSH9ma_GpXC7nlX8dIsWEOW-OuRAv-fs7ezyRNWbtLpN7KQ7R_Ren6/s640/webFriendlyDebate.jpg" width="640" /></a></div>
<br />
The level designer should be constantly stress testing throughout these stages. The artist should deliver pieces as soon as they are even rudimentarily functional, and the level designer should use them in non-ideal conditions. Only testing a kit as it was intended won’t teach us anything useful. The level designer should anticipate likely (and unlikely) use cases and attempt them, being sure to discuss the ramifications with the kit artist as these expose gaps in kit functionality.<br />
<br />
Ultimately, the kit will not be able to support every use case and eventuality. The level designer must choose what the kit does and doesn't support in concert with the kit artist. The idea here is that other designers will eventually discover these limitations first-hand, and the original designer and artist should have answers whenever possible.<br />
<br />
Here are a few specific things that the level designer can look for while stress-testing a kit.<br />
<br />
One of the big things to do is loop the kit back on itself, usually through various sub-kits. In this example, we’re testing a room and hallway sub-kit. Small hallways tile from the west end of the room and looped around to the south wall. Notice that the southern door fails to line up. It looks like it’s about a half-footprint away from where it should be. A common reaction to this may be to request a half-length hallway. This would fix the <i>specific </i>instance, but it’s what we call a “patch-up” piece, which is really just a band-aid over a deeper problem.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibZ0Ri2ob2rPVhfS6vVTn-2TBSPgxX1gjLBrDgMlLP14spvV44AukWWBA0Egb7oJrdqfXQ0Mc6IxANN5XdELNyfevmgRUqKHd6feFGkr2lCRdy6pzt2FS18tD51mIdm0ipPRnT/s1600/webLoopbackStressTest.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="184" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibZ0Ri2ob2rPVhfS6vVTn-2TBSPgxX1gjLBrDgMlLP14spvV44AukWWBA0Egb7oJrdqfXQ0Mc6IxANN5XdELNyfevmgRUqKHd6feFGkr2lCRdy6pzt2FS18tD51mIdm0ipPRnT/s640/webLoopbackStressTest.jpg" width="640" /></a></div>
<br />
We don’t really care about fixing this specific case; we want to prevent this problem from recurring during normal workflow. So if we look harder, it becomes apparent that we've got a footprint issue with the “2-way”, or hallway corner piece. Notice how it’s longer on one side than the other? That stub is what’s creating the problem. The correct way to fix this problem is to rework that piece so it fits within the intended footprint. It’s good to resist adding patch-up pieces, as they can bloat your kit, add arbitrary and non-obvious usage rules, are usually just symptoms of problems with your core kit.<br />
<br />
Something else to try is stacking kits on top of each other. In this example we've placed to hallways right on top of each other. Nate spoke earlier about footprint bounds, and it applies vertically as well as horizontally. This kit uses the entire vertical footprint, creating a co-planar ceiling/floor. This is problematic for a number of reasons: The lack of thickness will be a visual issue if you can ever see it, say from a stairwell or if there’s a hole. It can also cause z-fighting flicker, make optimization and trigger placement very difficult, and generally create a confusing editor view for you.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj5qv8fDPMAqfja-UlnlP183x1SN6KedvaLqyB-xaWsmtQCVzFVPv2DOTotRRBpbY0IoXjWIf4IVuOYpqgr5RGbeBQC9Rq0kGTpAOQnTZx820c28zmOiP7XVr1ndmbJfr1-B_jP/s1600/webVerticalFootprint.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="148" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj5qv8fDPMAqfja-UlnlP183x1SN6KedvaLqyB-xaWsmtQCVzFVPv2DOTotRRBpbY0IoXjWIf4IVuOYpqgr5RGbeBQC9Rq0kGTpAOQnTZx820c28zmOiP7XVr1ndmbJfr1-B_jP/s640/webVerticalFootprint.jpg" width="640" /></a></div>
<br />
Instead, predetermine how thick floors should be. This is especially useful with highly architectural kits - something we especially appreciated building the highly architectural, destroyed environments in Fallout 3.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKcnUN0JCK3AOsX_swSnxvpKaQljGSZBmgWNLKbhz1dylVPBSPB949A2ZwMrPe3aonEBmWoIaSszGdTJS1gHcryRM3qlFiQSax5SIa_c2xhrBNggPdm37gYLwDkYeNjVBiGvAm/s1600/webHallRoomPillars.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="182" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKcnUN0JCK3AOsX_swSnxvpKaQljGSZBmgWNLKbhz1dylVPBSPB949A2ZwMrPe3aonEBmWoIaSszGdTJS1gHcryRM3qlFiQSax5SIa_c2xhrBNggPdm37gYLwDkYeNjVBiGvAm/s320/webHallRoomPillars.png" width="320" /></a></div>
One more common test is to create a pillared room from hall pieces. If you’re a level designer with experience using kits, you probably know were this is going. In this example we've placed a few hallway corners along with several 3-way intersections. In doing so, we've created three "pillars", highlighted in green. This is a classic example of level design using a kit in a way that wasn't intended. These unintended pillars often look bad, but that doesn't mean somebody won’t try it. Somebody always does. This underscores the role of a level designer in the kit development process - the LD should raise these conversations early on and work with the artist to determine what the kit can and cannot support.<br />
<br />
The stress-testing process can at times seem combative, it’s important that parties both remember that the end goal is creating a great kit that will produce levels which look great and play great.<br />
<br />
<b><u>3) The Graybox Phase</u></b><br />
<br />
The next stage is "Graybox". By now, we've figured out the big ideas of the kit and proven that the kit will function. The goal of the graybox phase is to flesh out a kit and to figure out what the most common pieces will be.<br />
<br />
Just like the proof phase, the artist is not doing final texture work, keeping piece iteration a relatively quick process. This typically takes 1-4 weeks, depending on the complexity of the kit.<br />
<br />
The first graybox should be of the primary sub-kit, or whichever sub-kit we expect to be used most frequently. This helps to figure out the problems early on and enables the kit's level designer to start stress-testing with "real" layout.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgw8QWxJQFC7sEgvwHSeoJ1K7ZZdi7dP32bKkrn5MRu0dbYwf1CUF1jRKHz_frVol_FEveB41BvquhDirpxNDoUruLLeFSliu83K4EsQ5wJqRhF31yMAX6v3Sc9ScvbQvRIAPcg/s1600/webGrayboxSet.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="192" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgw8QWxJQFC7sEgvwHSeoJ1K7ZZdi7dP32bKkrn5MRu0dbYwf1CUF1jRKHz_frVol_FEveB41BvquhDirpxNDoUruLLeFSliu83K4EsQ5wJqRhF31yMAX6v3Sc9ScvbQvRIAPcg/s320/webGrayboxSet.png" width="320" /></a></div>
<br />
Remember to focus on how the kit functions, not how it looks. However; certain visual elements will have an impact and should be roughed in at this stage - usually any visual component that needs to tile across multiple footprints. Each kit has different needs, and you'll have to rely upon your collective vision (<i>established during the concept phase</i>) to figure out which elements these are. If you are making a room kit that has a pipe running down the center, put that in. If you want to build an asymmetrical cave kit, start building obvious asymmetry into the graybox pieces. If you make your graybox too generic, you do not actually solve any problems.<br />
<br />
At this point, the level designer and the artist work together to figure out the naming convention. This can be a tedious exercise, but it's important to sort out early.<br />
<br />
The key to good naming is balancing brevity with readability.Try to choose naming conventions that will make sense to someone who has never seen it before. If you over-abbreviate, things can quickly become an encoded mess that require a decoder ring to decipher. This can put stumbling blocks in creative process later, as level designers can stumble over looking for the piece they need.<br />
<br />
When you have naming conventions that you're happy with, be sure to consistently use them across all kits. This builds a common studio language and makes it easier for level designers to learn and transition to new kits, even across multiple projects.<br />
<br />
As an example, let's analyze a piece from Fallout 3, named "UtlBayCorInMidPRTT01L01". If we break the naming convention down, it consists of the following components:<br />
<br />
<ul>
<li><b>Utl </b>- This indicates that it's a piece of the Utility Kit.</li>
<li><b>Bay </b>- Indicates it's a member of the Bay sub-kit.</li>
<li><b>Cor </b>- Cor is our shorthand for "Corner", usually followed by "In" or "Out"</li>
<li><b>In </b>- This tells us it's an "Inside" corner. "Outside" corners bend the opposite way.</li>
<li><b>Mid </b>- This is common shorthand for a tiling piece, usually a floor. In this case the bay sub-kit tiles vertically.</li>
<li><b>PRTT01 </b>- No clue.</li>
<li><b>L </b>- "Left" We often use L/R at the end of a name to indicate mirrored versions of a piece.</li>
<li><b>01 </b>- Indicates that this may have visual variants. Discussed in detail later.</li>
</ul>
<br />
Most of the name is easily decoded and consistent with other kits. The "PRTT01" component is indecipherable, however. It was intended to help indicate what the piece will tile with above, below, and on each side - but because it was so difficult to internalize, the kit was underutilized. Which is a real shame, because this kit had a great deal of potential that wasn't tapped for the core game, making some of the effort put into it a waste.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRbLGxNz5Rofntk7_HgRFHwLQobpsnLGWabvk7h8c60z7YRMP2FyJFsi6ddSq1eZ0zNanOhySm9mDHhpe2ypRSCDzn4GM0bPjL4rqWBt7C2tSGKOVtIVaiV1x_UoJXkoxXxHS1/s1600/webNameBreakdown.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="256" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRbLGxNz5Rofntk7_HgRFHwLQobpsnLGWabvk7h8c60z7YRMP2FyJFsi6ddSq1eZ0zNanOhySm9mDHhpe2ypRSCDzn4GM0bPjL4rqWBt7C2tSGKOVtIVaiV1x_UoJXkoxXxHS1/s640/webNameBreakdown.jpg" width="640" /></a></div>
<br />
The extreme case of UtlBayCorInMidPRTT01L01 is a useful cautionary tale, but some naming conventions won't fulfill the obvious-to-an-outsider rule. For example, we call a straight hallway piece a "1Way", and a hallway turn/corner is usually called a "2way". More obvious are "3way" and "4way" junctions. We chose this convention because it groups these functionally-similar pieces together in the list, making them easy to get to. Once you understand this name, you'll understand it across all hallway sub-kits because we use it consistently. This is just one case where a slightly obtuse naming convention is justified by the iteration speed benefits and offset by consistent usage.<br />
<br />
As briefly mentioned above, It's wise to add 01 as a suffix to any piece which will feature visual variants but otherwise fill an identical role and occupy the same footprint. Even if you are only starting with one of each piece in the beginning, the 01/02/03 suffix format will become useful later, because those pieces will sort together in the list and be easy to find and swap for.<br />
<br />
At this point, pivot placement should also be decided upon. Generally, the pivots of our kit pieces are at the ground plane of the kit and in the center. Exceptions do exist however. For instance a pipe kit might have a pivot at the edge of the pipe so that it can hinge like an arm, which makes it easier to line up. A platform kit might have its pivot at the base of the platform instead of the "ground plane" so that it can snap to other areas easier. Changing pivots later can be a huge problem, requiring manual updates to hundreds of instances, especially if the pivot has changed before.<br />
<br />
<b><u>4) The Build-Out Phase</u></b><br />
<br />
Next up is the "Build-Out" phase. This is when the kit starts to become real art, and can be introduced to the team at large.<br />
<br />
With the core pieces proven out and functionally capable of laying out basic levels, the artist can begin developing those pieces visually and adding less-critical pieces and variants in response to usage cases as they present themselves.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqU0MDA5J2K9USfc0GbapyyktPnCT19Cg9fFwC8jJRw8noG9c45oNyCkIt7_m4ZnKAowm0_phfoBzljkamYu55avVCnstOy1K9XLGLXlAqQo3KDBP8NupsafEOtvfqj0GzCGUI/s1600/DwarvenKitShot.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="274" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgqU0MDA5J2K9USfc0GbapyyktPnCT19Cg9fFwC8jJRw8noG9c45oNyCkIt7_m4ZnKAowm0_phfoBzljkamYu55avVCnstOy1K9XLGLXlAqQo3KDBP8NupsafEOtvfqj0GzCGUI/s640/DwarvenKitShot.png" width="640" /></a></div>
<br />
This is also a good time for the level designer who has been working on the kit so far to introduce the kit to the rest of the level design team, and give an overview of the thinking behind the kit, its current status and future plans. This is the first stage at which it's a good idea to have other level designers start using the kit for their own layouts, which will generate a lot of useful feedback.<br />
<br />
This stage can take much longer because actual textures and geometry are being made. This can take a few months, especially if there are a lot of sub-kits. If the graybox phase was successful, however, level design shouldn't be held up very much: the art can be swapped out seamlessly once the final art exists. This isn't always the case though, so be aware that unforeseen problems can undermine layout being done during build-out.<br />
<br />
Even though this article won't go into this in much depth, one very important thing to note is to build out one visually-complete piece before beginning the variants. If adjustments must be made based on art direction feedback, it is much easier to adjust one piece (<i>or a small number of pieces</i>) instead of an entire kit. This can be a massive time savings. Kits will get a lot of polish over time - you're primarily trying to anticipate and avoid changes which will impact functional factors such as footprint, snap rules and pivot point.<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDRiKgQPD7Ruw0jTG7xoFoCQdTeaqoHkTYe7BmX6QXMsmPMQmz4-S9-cGQtfzqINhbHiJcnaXRkTGMXQvhBpnK3_2Oz8UrtCGCHPPZBnVUeUiK_qvpzjOClBRTkM5J-UCIPb5w/s1600/webHeroPiecesAreLame.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="162" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDRiKgQPD7Ruw0jTG7xoFoCQdTeaqoHkTYe7BmX6QXMsmPMQmz4-S9-cGQtfzqINhbHiJcnaXRkTGMXQvhBpnK3_2Oz8UrtCGCHPPZBnVUeUiK_qvpzjOClBRTkM5J-UCIPb5w/s320/webHeroPiecesAreLame.jpg" width="320" /></a></div>
<br />
Something to watch out for is the temptation to start working on "Hero Pieces". This is a piece that has a lot of fancy unique art, such as a hallway piece with an embedded statue, or a one-off setpiece for a specific event. Even though these pieces seem important, can look really nice and impress everyone on the team, they are ultimately not what is important early on. The hero piece is only used a few times, your normal piece is used hundreds if not thousands of times. Focus on what is actually important; the standard pieces. The hero piece can always come later, and will only be a bottleneck for the handful of specific instances in which they are needed.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDc6jZuzirBglAn6ahBsf61Z1MHkijzUfawUAsy6mGyYt9-jByrwa25svCd9XSwth_7FcJ1Cy5EkHnbGoxnoTBSGISeXD_b7zt3PxDZHSlSoV2xmtTuBy6LnZs5DxWJbNzvXEg/s1600/web_Helpermarkers.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="237" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDc6jZuzirBglAn6ahBsf61Z1MHkijzUfawUAsy6mGyYt9-jByrwa25svCd9XSwth_7FcJ1Cy5EkHnbGoxnoTBSGISeXD_b7zt3PxDZHSlSoV2xmtTuBy6LnZs5DxWJbNzvXEg/s320/web_Helpermarkers.jpg" width="320" /></a></div>
<br />
Something we've only discovered on our current, unannounced work are what we call "Helper Markers". This is editor-only markup that can help convey meaningful information about the kit. Some examples of this are markers to show how a kit should snap together, where the doorways are or markers for the ceiling so that you don't have to flip the camera upside down to select those pieces. It's good to think about these markers as the level design team starts using the kit, as they can help make usage more intuitive and straightforward.<br />
<br />
<b><u>5) The Polish Phase</u></b><br />
<br />
Finally we are ready for the polish phase, which is really an ongoing process and that exists <i>(to some extent)</i> throughout the rest of the project. Over the coming months, the kit artist can respond to real usage cases, fix bugs, and additional functionality. Additional art polish will go in as needed, and due to the way that kit art is deployed, this should be a seamless process.<br />
<br />
It is important for the level designer and the artist to talk critically about all the requests that come up throughout the process. It is very easy for an artist to say "yes" to every request that comes up. This can quickly lead to a kit that is bloated and unmanageable. Remember the reasons decisions were made while establishing the kit, and make sure that each additional piece is worth it. When adding pieces for a specific use case, see if there is a reasonable alternative, if something else exists already, if the use case is actually worth expanding the kit. The answer won't always be "no", but it can't always be "yes", either. Choose your battles.<br />
<br />
During the initial process the artist usually worked with one level designer on a limited set of areas. Throughout the course of the game lots of different level designers will make lots of different levels. No matter how thorough the initial phases were, this always brings up unexpected issues. Assume that this will be the case and plan for additional kit polish time for course-corrections down the road.<br />
<br />
<h3>
<u>Going off the Grid: Advanced Techniques</u></h3>
<div>
At this point you know how to make a rules-based kit on the grid which works as a system. Things snap together, there are corner pieces, straight pieces, doorways, rooms, etc. </div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiS3ue1NayKhJThbZ-psc5ylgGK4d6jCwj2FZ1qKq1nSE2MXX-xrdn4QQ_S5VL8CV3GoO-zDpNV-WnuUmMx8S53vGVZ9IBKG9QHX8bGvySzbWv7pTMLaAg0gKqb5vQVsnDCmoso/s1600/webBR2kit.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="310" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiS3ue1NayKhJThbZ-psc5ylgGK4d6jCwj2FZ1qKq1nSE2MXX-xrdn4QQ_S5VL8CV3GoO-zDpNV-WnuUmMx8S53vGVZ9IBKG9QHX8bGvySzbWv7pTMLaAg0gKqb5vQVsnDCmoso/s320/webBR2kit.jpg" width="320" /></a></div>
<div>
The problem with this kind of kit is that it will always feel like a kit. Things are always at 90 degree angles, the player will sense the system and art fatigue can set in. Modular levels often <i>feel </i>like modular levels.</div>
<div>
<br /></div>
<div>
Starting with Fallout 3 we started to push kits beyond this to see how we could make a kit <i>not </i>feel like a kit. We had spent our careers thus far learning the rules; now we needed to break them.</div>
<div>
<br /></div>
When you start to bend the rules, always keep in mind the reason they were rules in the first place. These ideas exist for a reason, and it can be hard to appreciate why until you've made certain mistakes firsthand.<br />
<br />
If you find a way to bend kit logic, you shouldn't necessarily apply that to all kits you make in the future. It is best if you embrace one particular logic quirk for each kit, otherwise things will quickly spiral out of control. It is also extremely important to remember the cost of bending the rules. Art has to spend more time making more pieces and the art is a lot more complicated. The level design process is also usually more complicated and its easier to make mistakes. Make sure these trade-offs are worth it on a case-by-case basis.<br />
<br />
One of the key technologies that let us start building more complicated kits was something called "Snap to Reference". With snap to reference the editor can treat any object as the origin for things to snap for. This way, things don't have to be aligned to rigid 90 degree angles. You can rotate a piece and then use that as the new grid, so new pieces will snap together with this rotated piece. This obviously creates gaps between pieces rotated at different angles, but we bridge those gaps in a lot of ways.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_u-tiH0WuuSan1I7o5Tyj23fJMzUOT9tTcaehyphenhyphenzKE-W-un6DOaNs7qgk7XDqK_NKow0vupBTtT1DZxZ40Qi9Opqy0gwpy3twwQpqop12OWIBQNSGZcFZ5L8N2PY5ecCsXBaiC/s1600/webSnapRefDiagram.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="194" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_u-tiH0WuuSan1I7o5Tyj23fJMzUOT9tTcaehyphenhyphenzKE-W-un6DOaNs7qgk7XDqK_NKow0vupBTtT1DZxZ40Qi9Opqy0gwpy3twwQpqop12OWIBQNSGZcFZ5L8N2PY5ecCsXBaiC/s640/webSnapRefDiagram.jpg" width="640" /></a></div>
<br />
One of the new kit types introduced in Skyrim was the "Pivot and Flange" system used for the Ratway. This is a hallway kit that acts almost like a pipe kit. All of the hallway pieces can be rotated at unique angles, allowing for a much more organic flow. Because these hallway pieces are all rotated at arbitrary angles, there is a gap created between each hallway piece.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhunNN-P4LczDJcgDOnl9UMd-X2FtyiBprgTG8GtlZLxqWlvTJukTXdT5pNalq7vurBiDo4fDAQ6SGXIW-u0Fuu7uAFKiZKP0V3hId-8Ir0nYzRjrtc65V6RQWEM3s8-1HMWkZQ/s1600/webPivotFlange.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="324" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhunNN-P4LczDJcgDOnl9UMd-X2FtyiBprgTG8GtlZLxqWlvTJukTXdT5pNalq7vurBiDo4fDAQ6SGXIW-u0Fuu7uAFKiZKP0V3hId-8Ir0nYzRjrtc65V6RQWEM3s8-1HMWkZQ/s640/webPivotFlange.jpg" width="640" /></a></div>
<br />
We covered up this gap using an archway that follows the full curvature of the walls, ceiling and floor. There are a few issues with that you should be aware of. For starters, the level design process is more linear. Instead of knowing exactly how many pieces would be between a set of rooms, since things are rotated at strange angles, all of the numbers/angles are thrown off, which can make it harder to make adjustments.<br />
<br />
It's also easy to create non-obvious errors. Because these archways can't snap to both halls, level designers may accidentally fail to align the gap-covering archway exactly right, which can lead to tiny holes that you might only see at just the right angle. (<i>This underscores the importance of playing your work frequently, rather than staying editor-side for too long) </i>It is also a bad system for highly specific architecture. Since it is inherently organic and relies on jamming things together, the visuals break down if you want clean, specific intersections. If you want organic naturally curving hallways however, this system is fantastic and does not require many kit pieces. Because the Ratway is supposed to feel like an ancient, decaying subterranean tunnel system, it's perfect.<br />
<br />
We also found ourselves experimenting with our own rules when it came time to build the caves of Skyrim. Caves have always been problematic for modular building, as modular kits are highly rules-based and orthogonal but caves are highly freeform and organic. Another system that we started using in Skyrim is the Shell-Based Building system.<br />
<br />
This is a system where we build all of the standard kit pieces in the traditional way, but then layer in freely placed walls, pillars and balconies to break up the play space in an organic way. The diagram below shows a simple example where shell pieces are used to establish a room, and free walls and pillars are used to quickly create a more organic shape than the corner allowed by the strictly grid-snapped shell.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiE7u3Cc9-OimimVij4Q2aHeBicWNMzRh7yFB1WNcuFcLXFdFEYDP05Sr2btUSB9reCDcAPvfmhWIS5Si6984v_RTAkXV8x9M0ZKu9ZxO0bcsX2QeR5XxAn7bxXriHG2x30daKT/s1600/webCaveShellStages.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="490" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiE7u3Cc9-OimimVij4Q2aHeBicWNMzRh7yFB1WNcuFcLXFdFEYDP05Sr2btUSB9reCDcAPvfmhWIS5Si6984v_RTAkXV8x9M0ZKu9ZxO0bcsX2QeR5XxAn7bxXriHG2x30daKT/s640/webCaveShellStages.jpg" width="640" /></a></div>
<br />
This allows level designers to build seamless levels with the exact shapes and flow that they want. Visually, it is very easy for things to never look the same. The amount of art that need is surprisingly minimal, due to the random, chaotic way the art can be combined. Some artists might worry about things like specific intersections not looking great. Try using an art-review process to monitor specific usage and provide constructive feedback when things aren't working. Good lighting and rendering features like ambient occlusion also work out very well and go a long way to hide any awkward intersections. The flexibility you can get from doing a level this way is astronomical. (<i>Plus, no one really notices those little intersections.)</i><br />
<br />
Delving further into our history, Directionally restricted kits are a technique we began in Fallout 3. Traditional kits can be rotated in any direction and still snap together. Directional kits do not allow this, as they require certain pieces be used in relationship to each other. This allows art to do things like asymmetrical halls, specific width rooms (<i>such as a room spanned by a large arch</i>) or room kits that have unique pieces for all of the cardinal directions.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEisoLZNEyQ_TcMAYJquQrXLYkVxYyXez9UUgE2CeJdG_zUbCQE1PhPR7yTs1AFeolDck64AiSDL1AhLOo4KfPhAhTY2pj5SSUocuuGxj87CRioaZc0rbFMXIq0W-UpDOmyO6PBR/s1600/webAsymmHall.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="184" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEisoLZNEyQ_TcMAYJquQrXLYkVxYyXez9UUgE2CeJdG_zUbCQE1PhPR7yTs1AFeolDck64AiSDL1AhLOo4KfPhAhTY2pj5SSUocuuGxj87CRioaZc0rbFMXIq0W-UpDOmyO6PBR/s320/webAsymmHall.png" style="cursor: move;" width="320" /></a>This is a lot more work for both art and design, but it is extremely useful for organic kits, as it removes the need for surfaces and textures to tile in every direction. This can be a lot of extra work, and it changes some of the core logic of a kit. While extremely useful for creating natural kits, directional restrictions usually aren't worth the extra effort for something highly architectural. It can make the kit easier to understand if you start thinking of each unique surface differently, such as the A/B sides of the hallway pictured here.<br />
<br />
One thing to watch out for when doing this is the need for what we call a "De-Twist" piece in the hallway kits. When an asymmetrical hallway flows in just one direction, it tiles just fine. Sometimes, however, another hallway will meet up that happens to be flipped the other way. A de-twist piece bridges this gap over the course of a single piece by flipping which side meets up with the other. Hence the "de-twist". The following diagram shows an example of an asymmetrical hallway looping back on itself, where it then requires a de-twist.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmaPxfRdzXvpxpIwBrkneJBNiP49kxI_B-xkG6hIANSMvZrbRRGtghLv1HRZCtkFUBALSwQir1SWX0CJrigd4lyrvkqnxs3qmE0D-jnt6FJBvcDyjhHPphMwGxY2BNK4UNjAD4/s1600/webDetwist.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="302" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmaPxfRdzXvpxpIwBrkneJBNiP49kxI_B-xkG6hIANSMvZrbRRGtghLv1HRZCtkFUBALSwQir1SWX0CJrigd4lyrvkqnxs3qmE0D-jnt6FJBvcDyjhHPphMwGxY2BNK4UNjAD4/s320/webDetwist.jpg" width="320" /></a></div>
<br />
Another simple kit concept that can add a lot of flexibility is a "platform" kit. Platform kits are any that sit on <i>top </i>of other surfaces, and allow level design to cut up the horizontal planes of play. They can be very large or small, and both examples can be seen in Skyrim. These empower level designers to create interesting playspaces without needing to add a great deal of complex vertical logic to the kits. The number of pieces needed to create a platform kit is minimal, and they tend to work with almost any other sub-kit with the same visuall theme. These platform kits were even used independently in the exterior as points of interest.<br />
<br />
Platform kits are a specific example of what we've started to call "Glue" kits. Beginning with our current project, we are now creating a number of small-scope kits which exist primarily to create transitions between multiple kinds of kits and sub-kits. Glue kits are essentially made with kit-bashing in mind, and could be just about anything from platforms to tunnels to ledges. They are so far giving us a good deal of mileage, and show how discoveries and innovations made along the way can begin to influence your formal workflow. Which is good, because an evolving workflow is proof that you're still learning.<br />
<br />
<h3>
<u><b>Conclusion</b></u></h3>
There’s an awful lot more that we could cover if we were to get into the deeper details of kit-building, and you’re encouraged to reach out to us with any questions you may have. For now, however, let's wrap up.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiekDhYM26bRSR8xRK9pWo6xMweFKrdhbLK46kyTe6v1cexnhX25LXtCD9diBT8h6K39z4SXy2rI1oUvGcwibf8_JXWmUQHcgYhBAHMqVls2eOQ6FC0McBnYtAqJ4pOWZFspyXi/s1600/webSkyrimFanShot.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiekDhYM26bRSR8xRK9pWo6xMweFKrdhbLK46kyTe6v1cexnhX25LXtCD9diBT8h6K39z4SXy2rI1oUvGcwibf8_JXWmUQHcgYhBAHMqVls2eOQ6FC0McBnYtAqJ4pOWZFspyXi/s640/webSkyrimFanShot.jpg" width="640" /></a></div>
<br />
When you get down to it, I do not believe our team could have built Skyrim except through our decision to explore and embrace workflows like the ones discussed here. We’re driven by a desire to explore our worlds via their creation, always aware that the time we spend polishing every edge off one idea takes away from what we could be doing with another, and the thing after that. We've said before that the worlds of our games are their own main characters. Those worlds come to life before our very eyes during development.<br />
<br />
Don’t mistake these workflows for a compromise into which we have been forced. Rather, these are choices we have made in order to make the scope of our games possible while maintaining a working culture which keeps us happy and harmonious.<br />
<br />
Because while I don’t believe our team could have built Skyrim any other way, I also believe that no other team could have made Skyrim. Other teams could have made a game <i>like </i>Skyrim, and perhaps have spent more time or money, or worked with more people, or embraced different ideologies. But any of those games would have been a different one than what we created, and we're proud of the games we've made.<br />
<br />
At the end of the day, the games you create - the art you put out into the world - is an expression of yourself. If you’re working as part of a team, however, that art isn't just an expression of your own self, or even many individual selves. It’s an outward expression of your relationships, and who you are as a <i>group</i> of people. And these relationships are perhaps the most rewarding thing you’ll develop in your lifetimes. It's worth finding techniques that help grow those relationships and in turn improve the games you can make together.<br />
<br />
<i><span style="font-size: x-small;">Joel Burgess is a senior designer at Bethesda Game Studios, and Nathan Purkeypile is a senior environment artist. Their shared gameography includes Skyrim, Fallout 3, Aeon Flux, Bloodrayne 2, and an unannounced project currently in development. Nate and Joel were also co-leads on the Point Lookout DLC for Fallout 3. They can be reached on twitter via <a href="https://twitter.com/JoelBurgess" target="_blank">@JoelBurgess</a> and <a href="https://twitter.com/NPurkeypile" target="_blank">@NPurkeypile</a>, respectively.</span></i><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiGUXhMPuYktkFa2nUvFqaW11kHRnSYkL0PKW47yM1GIjWN0-64U6tah0ZpGnfZ0jsf_AGmeJr1txZ1kzjbW0DDTr26SoMMMhwYUTRGff5QnKQdjniWXQVgDFBJYpCValK8tS5Z/s1600/webhugginItout.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiGUXhMPuYktkFa2nUvFqaW11kHRnSYkL0PKW47yM1GIjWN0-64U6tah0ZpGnfZ0jsf_AGmeJr1txZ1kzjbW0DDTr26SoMMMhwYUTRGff5QnKQdjniWXQVgDFBJYpCValK8tS5Z/s320/webhugginItout.jpg" width="146" /></a></div>
<br />Joelhttp://www.blogger.com/profile/09816332769743524346noreply@blogger.com33tag:blogger.com,1999:blog-30579660.post-62413743766293705142013-03-19T17:07:00.001-04:002018-10-27T07:15:48.480-04:00Gamasutra Feature - LDiaD RoundtableMyself and a few of the other gents involved with the 2013 <a href="http://schedule2013.gdconf.com/session-id/822397" target="_blank">Level Design in a Day Bootcamp</a> were recently asked to answer a few questions from members of the public. We happily obliged.<br />
<br />
You can check out the full, roundtable-style feature <a href="http://www.gamasutra.com/view/feature/188740/level_design_in_a_day_your_.php" target="_blank">over at Gamasutra</a>. Topics discussed include designer workflow, player guidance, and the role of the level designer on past and future teams. Got more questions for the group? Hit us up on twitter and we'll see what we can do.<br />
<br />
Speaking of which - we're just a week out from GDC! Hope to see you there - but if you can't make it, stay tuned to this space. I'll be posting the slides for my session this year, which is focused on the modular, kit-based approach to level design we have embrace for many years at Bethesda.Joelhttp://www.blogger.com/profile/09816332769743524346noreply@blogger.com0tag:blogger.com,1999:blog-30579660.post-62245669395551267912012-10-04T20:05:00.000-04:002018-10-27T07:15:48.461-04:00Motivating Players - FIEA RemixI was recently invited to speak at <a href="http://www.fiea.ucf.edu/" target="_blank">FIEA</a>, a graduate-level game development school in Orlando.<br />
<br />
The talk I gave was an update of my 2011 contribution to GDC's <a href="https://www.facebook.com/groups/308354239212854/" target="_blank">Level Design in a Day</a>, "Motivating Players in Open Games". Skyrim has come out since that talk was originally given, so I was able to add some examples taken directly from the game.<br />
<br />
Here's the video and slides - enjoy!<br />
<div style="text-align: center;">
<br /></div>
<div style="text-align: center;">
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="480" src="http://www.youtube.com/embed/jOK0Bb58dEk" width="500"></iframe>
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="356" marginheight="0" marginwidth="0" scrolling="no" src="http://www.slideshare.net/slideshow/embed_code/14595434" style="border-width: 1px 1px 0; border: 1px solid #CCC; margin-bottom: 5px;" width="427"> </iframe> </div>
<div style="margin-bottom: 5px;">
<br /></div>
Joelhttp://www.blogger.com/profile/09816332769743524346noreply@blogger.com1tag:blogger.com,1999:blog-30579660.post-25987924635282692322012-03-22T21:24:00.005-04:002018-10-27T07:15:48.383-04:00GDC 2012 Transcript: Pursuing Elegance - Simplicity, Complexity, and Finding your Creative Process.<div class="MsoNormal">
As with last year, I jotted down a transcript of my talk on the flight to San Francisco for GDC. The conference doesn't record video of tutorials - which our session technically is - so I like posting these for those would want to refer to the talk.<br />
<br />
Slides are available at <a href="http://www.slideshare.net/JoelBurgess/pursuing-elegance">slideshare</a> if you'd like the raw powerpoint - but there are no speaker notes, so I recommend reading this transcript if you'd like to get a more complete impression of the topic.<br />
<br />
Thanks for reading, and let me know if you have any comments of questions.<br />
<a name='more'></a><br />
<blockquote class="tr_bq">
<i>"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction." </i>E.F.Schumacher, 1973</blockquote>
When I was asked what I’d like to talk about at GDC 2012, I mentioned simplicity. Throughout my career, I've noticed a tendency in developers to over-complicate things. Whether we’re adding steps to a puzzle, branches to a layout, failsafes to a script, or topics to a conversation, designers always seem to be adding layers of complexity – often before there’s really any demonstrated need to do so. I'm as guilty as anybody else, and I've found that what’s made me better throughout my career is not having more or better ideas, but being more selective about which ones I choose to pursue.<br />
<blockquote class="tr_bq">
"<i>The poor architect succumbs to every temptation and the good one resists it."</i> Ludwig Wittgenstein</blockquote>
</div>
<div class="MsoNormal">
If there’s a common reason I’ve observed this among game developers, I think it’s that we are, at heart, problem solvers. Those of us who stay in the industry past that five-year burnout stage do so because we relish the fact that our jobs change constantly. We appreciate that there is always a new technical or creative hurdle to overcome. But this can become a self-indulgence. I think that most designers, if we’re honest with ourselves, can recall toiling away at something because we enjoyed the work - not necessarily because it's contributing to the overall quality of the player experience. Developers are classically hard workers, and intelligent. But the number of hours we put in and how clever we are is irrelevant if it doesn’t impact the game in a positive way.<br />
<br /></div>
<div class="MsoNormal">
Since I began work on this talk, Skyrim came out. If it seems ironic to you that someone who worked on Skyrim wants to discuss simplicity, that’s not lost on me. Still, I think an embrace of simplicity lies at the core of our success. Response to the game has been truly beyond our expectations. The most flattering attention we’ve received, of course, is from other developers. When other game devs talk to me about Skyrim, they often want to know how we go about making games of such large scope. There’s no easy answer to that, however, and this talk became, in a way, an attempt.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8NF1EwaRVY1cBe1BsPXRIyDjkirKNEb6XftYsY28ok2ysTgNHAIkjD8jLIQSdpr67eSWIkRvzBGl1N4NF_ms_72SM3JEMIsUW80i4M4-lLuTbL_Q5f4iosaV9YhTjLkX6Yv-P/s1600/SkyrimLogo.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="68" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8NF1EwaRVY1cBe1BsPXRIyDjkirKNEb6XftYsY28ok2ysTgNHAIkjD8jLIQSdpr67eSWIkRvzBGl1N4NF_ms_72SM3JEMIsUW80i4M4-lLuTbL_Q5f4iosaV9YhTjLkX6Yv-P/s320/SkyrimLogo.png" width="320" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
With that in mind, I'll share some basic stats from the production of Skyrim. While the game existed in some conceptual form for a number of years, full-scale production didn’t begin until Fallout 3 was finished. We are a one-project team at Bethesda Game Studios, so most of the content team was still on Fallout 3 DLC throughout 2009. This means that Skyrim was only in full production for around three years. We are a large team at just under 100 developers, but we aren't massive, either. Some other games with similar scope involve literally hundreds of developers spread out across multiple studios worldwide. Everyone at BGS is based in Maryland and we have tried to espouse an environment where everyone knows and can approach everyone else on the team. We do use some outsourcing, but it is quite limited. Mostly we outsourced armor and weapons, which we still did our own concepts and game-specific implementation for. Speaking to level design specifically, we had a team of eight LDs on Skyrim. Between us, we were responsible for over 300 locations and events in the game. These include very large, multi-hour dungeon crawls, smaller experiences, all the way down to one-room affairs and exterior locations. Level designers also were responsible for areas of the game you may not expect, such as the traps system and combat design for certain creature encounters.</div>
<div class="MsoNormal">
<br />
The last data point I’ll share is one I’m especially proud of. In an industry plagued by delays, where you expect a big game like Skyrim to slip once or twice, we hit our ship date. We didn’t just hit our date, but we called it to the day over a year in advance, and of course we knew that date internally for months ahead of the announcement. Furthermore, we didn’t just ship in North America, but finished the game in enough time to cert, localize, print and ship to nearly every territory where the game is available on the same date worldwide. </div>
<div class="MsoNormal">
<br />
The point of all of this is to highlight that while we are a well-backed studio, we aren’t extravagant in our resources. While we have steadily grown over the past ten years, we’ve avoided explosive growth. How we are able to do that while continuing to make games known for their massive scale is in large part thanks to our studio culture.<br />
<br /></div>
<div class="MsoNormal">
My boss, Todd Howard, has several mottos for the studio. One of these is:<br />
<blockquote class="tr_bq">
“<i>We can do anything, but we can’t do everything.</i>” </blockquote>
Taken skin-deep, this is simply a statement about having to choose your battles. But looking a little deeper, there are some further implications. First, it implies a high level of ambition. Every developer at Bethesda has pet features they’d like to see appear in game, or we wouldn't have to be selective about where we pool our resources. To that end, we’re very good about seeking compromise. I think we’re good about recognizing when something isn't quite working and re-thinking if we need to scale back or cut the feature. The most important thing about this is that it doesn't live in some mission statement or is only held by an inner circle of highly-placed leads. Every developer in the studio ends up embracing this approach to development.<br />
<br /></div>
<div class="MsoNormal">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8izYBdghhQKZVpMcDjWXuHbPaCA2mFoiCVl_qZtOQ5-vCMvWKIR7P5R4G4dqLfEN8d_-BtR2pwgK_Kb8xPfuE35EVIBUZxtZ9DPCPTBLHeL9CQgo4AXehEOkUE9y3o0hIN1Xm/s1600/IdealistRealist.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="223" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8izYBdghhQKZVpMcDjWXuHbPaCA2mFoiCVl_qZtOQ5-vCMvWKIR7P5R4G4dqLfEN8d_-BtR2pwgK_Kb8xPfuE35EVIBUZxtZ9DPCPTBLHeL9CQgo4AXehEOkUE9y3o0hIN1Xm/s320/IdealistRealist.jpg" width="320" /></a>That’s important because it affects how we approach our work internally, before we ever approach or collaborate with a colleague. We must be of two minds. One side of ourselves is the idealist; that inner persona with ambitious, far-reaching ideas, and a strong opinion about the Right Way do to things – whether it’s the best thing for the task at hand or the art form at large. The Idealist doesn’t worry about how difficult something may be or how long it might take. Those aren't reasons to kill a good idea in the cradle. Likewise, our other self is the Realist – that awareness that an end date must be in sight if we ever want anybody outside ourselves to enjoy our work. We get perspective from our inner Realist. This is how we can see the big picture and realize that the time we spend grinding away every corner on the feature in front of us is taking away from time available to the next thing down the line, and the thing after that. We also seek out expedient solutions as the Realist, looking to cut to the heart of things so we can move on.<br />
<br /></div>
<div class="MsoNormal">
It would be easy for me to cheerlead the idealist, by the way – but I don’t think many designer need help with that. I have to emphasize that we must be Idealist and Realist in equal parts. Some may be tempted into thinking they ought to be an uninhibited auteur at all times, or that your producer is your built-in realist. I think that attitude is a little irresponsible, and stymies your growth as a creative person, however. If we have no discipline within ourselves, we will never progress past the infancy of aimless creativity. Besides, I’m sure your producer would rather fulfill his or her proper role as a facilitator rather than your babysitter.</div>
<div class="MsoNormal">
This is all a bit theoretical, however. The benefit of having just shipped a game is that I can talk freely about it, however. So let’s look at some examples from Skyrim.<br />
<br />
<div style="text-align: center;">
<u>Example I: Loopback Layouts & Asking "So What?"</u></div>
</div>
<div class="MsoNormal">
Layout is one of those things that universally is the purview of the level designer, anywhere you may go. While the specifics of the job will vary greatly based on the studio and project, pacing and the sequence are always the concern of a level designer. When we first approached Skyrim, we knew that there was one big layout problem we hoped to fix. In our earlier games, players often progressed through a dungeon, only to end up back-tracking through empty space when the boss was killed and the loot all looted. This was a dead space in the experience that we realized we could mostly banish. We did this with loopback layouts, which you see a lot in Skyrim. The basic idea of a loopback is that the player enters a dungeon, goes through whatever progression sequence and climax the level designer has set up, and is deposited quickly near the entrance of the dungeon via a one-way device – usually a physical drop.<br />
<br /></div>
<div class="MsoNormal">
Because Skyrim is a mountainous game, we were also able to apply this layout concept in an upwards fashion from time to time. The player may progress upwards, which is a nice change of pace, and exits somewhere high in the mountain peaks, getting a nice vista of the landscape. This provides a natural one-way blocker.</div>
<div class="MsoNormal">
Production was marching along, and we were feeling good about this decision – when something unexpected came up. This really shouldn’t have been a surprise to us, and I suspect nobody who has played one of our games will be shocked, either. Turns out that players can pretty much get anywhere they want to get, including going up nearly-vertical mountain slopes. <br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguc_wBo9J0_CMc11eH9RJI6Chwv1oxZ3aquNt8YBQNDYvueEjdfdmpWZJ83apAMS_4sxQLcjtsGv5RFrG81fG70PIVvzD9mAFFnU5pGlyRoMfhL7QIS7kyNl-ZfDQHKWXCB0GJ/s1600/JerkHorse.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="175" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguc_wBo9J0_CMc11eH9RJI6Chwv1oxZ3aquNt8YBQNDYvueEjdfdmpWZJ83apAMS_4sxQLcjtsGv5RFrG81fG70PIVvzD9mAFFnU5pGlyRoMfhL7QIS7kyNl-ZfDQHKWXCB0GJ/s320/JerkHorse.png" width="320" /></a></div>
</div>
<div class="MsoNormal">
This wasn’t a problem with a one-size-fits-all solution, and we had to consider each loopback dungeon individually. The first reaction, of course, was usually to lock the back door to prevent wrong-way access. We didn’t do this instantly, however. If you were to come to me and say “The player can get into the back door of my dungeon, take ten steps to kill the boss, and walk right out.”, I am not going to assume this is a problem.<br />
<br /></div>
<div class="MsoNormal">
I’ll ask:<b> “So What?” </b>There are several reasons we might assume this is a problem, but upon further analysis they often don’t matter. When there is no great answer to the question, we’ll tend to leave the back door unlocked.<br />
<br /></div>
<div class="MsoNormal">
We prefer to do nothing in these situations for a couple of different reasons. First, it’s usually the best Idealist solution, because it allows the greatest range of player expression. Unpickable locked doors are often a contrived, designer-imposed restriction and feel like such to the player. A door which is unlocked, or can otherwise be bypassed, more naturally fits the rules of the world. That matters in a simulation-feel game like Skyrim. Second, and this is hopefully the most painfully obvious point I’ll make – doing nothing is a highly efficient in terms of time usage. It doesn’t matter how trivial the fix may have been. If we can determine that no problem exists, we’ve saved time. <br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiRPizGgq12LqS-77MOza_PNmEXPG0a-NJhOn7O8u1Pdx4oadokP8AerlGKE-9ngQJE2IbX16mfOZMMaN8tgihyphenhyphenJwAxKR_5cwQ869sDSst6Vn70Bd61KnoBXPEO_E27P-i6chYd/s1600/LessWorkMoreFilling.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="163" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiRPizGgq12LqS-77MOza_PNmEXPG0a-NJhOn7O8u1Pdx4oadokP8AerlGKE-9ngQJE2IbX16mfOZMMaN8tgihyphenhyphenJwAxKR_5cwQ869sDSst6Vn70Bd61KnoBXPEO_E27P-i6chYd/s320/LessWorkMoreFilling.jpg" width="320" /></a></div>
<br /></div>
<div class="MsoNormal">
So: while it maybe easy to think of the Idealist and Realist as strictly opposing forces, they are not. Solutions exist that can satisfy the needs of both. In the case of leaving a loopback door unlocked, the Idealist is happy because we’ve arguably given the player a better experience, and the Realist is obviously pleased that we saved ourselves the time of administering a fix.<br />
<br />
<div style="text-align: center;">
<u>Example II: The Radiant Assassin & Possibility Space</u></div>
</div>
<div class="MsoNormal">
<div style="text-align: left;">
Radiant Story is one of the big features we knew we wanted to pursue right at the beginning with Skyrim. Radiant Story uses a feature called the Story Manager to feed quests and events into the world based on the player’s experience. The Story Manager is capable of tracking almost any data you can imagine – it knows everything about the player, how he or she has affected characters in the world, the state of current events, various information about locations, and so on. The point of this is, of course, to deliver semi-procedural experiences to players. We may not be able to achieve high-order procedurality in games with the fidelity of Skyrim just yet, but with Radiant Story we’ve begun to scratch the surface.</div>
<div style="text-align: left;">
<br /></div>
</div>
<div class="MsoNormal">
One application of Radiant Story are what we call Wilderness Encounters. Late in development we were able to identify areas of the world where not much was going on, and use the Story Manager to send events towards the player based on this. One of these encounters is the “radiant assassin.” The event is pretty straightforward: the player is walking along when an assassin from the Dark Brotherhood attacks. If the player kills and loots the assassin, she may discover an assassination contract with her name on it.<br />
<br /></div>
<div class="MsoNormal">
We consider this to be a pretty effective use of Radiant Story, if only because it proved to be thought-provoking for players. In the weeks following Skyrim’s release, we saw a lot of commentary about this event online. People would relay what had happened and had various different stories about why this assassin would come after them. This was especially interesting because the Story Manager is only looking for two conditions in order to be triggered. The player must have reached level ten, and not begun the Dark Brotherhood quests. For all the data Story Manager is capable of tracking, that’s all we care about in this case.<br />
<br /></div>
<div class="MsoNormal">
Looking a bit deeper, the design implementation of this particular event is pretty small. We created an assassin NPC, a note that dynamically fills in the player name, and set up the Story Manager event. That’s not much authored story, but any assassination attempt is a loaded question, rife with inherent mystery. Players were comparing this blip of authored story we provided against their personal history, and drawing their own conclusions. Perhaps they had married an NPC another character was interested in, or it was a case of mistaken identity. Maybe their criminal record or meddling in regional politics had caught up with them – or maybe it was a clear cut case of revenge for somebody the player had wronged.<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVXode1hvUoyIzbRZVmLgmJlOMmAd5RKcPVmhAR_E_48TnKIEnEDflZAhRIEFGvQwlGjihEGPpvXa4RGkOUWYDlaXVfeRw0z76wTcKoQ-MwA4CxPq6A4Dpv8d2IdDz3UP4NmIK/s1600/PossibilitySpace01.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="210" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVXode1hvUoyIzbRZVmLgmJlOMmAd5RKcPVmhAR_E_48TnKIEnEDflZAhRIEFGvQwlGjihEGPpvXa4RGkOUWYDlaXVfeRw0z76wTcKoQ-MwA4CxPq6A4Dpv8d2IdDz3UP4NmIK/s400/PossibilitySpace01.png" width="400" /></a></div>
<br /></div>
<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
</div>
These and dozens of other possible conclusions make up what we’ll call the “possibility space”. This is the ripple created by the bit of authored story we created. As small as it was, the possibility space resulting from this story was quite large. I mentioned at the beginning of this discussion, however, that tendency of developers to add additional complexity. And indeed, it would be very common for a designer to see this story, feel encouraged by it and want to add on. So let’s suppose we provide information that traces the assassination contract back to a Jarl – one of the governers of Skyrim. There are a few issues that can come up if we do this.<br />
<br /></div>
<div class="MsoNormal">
First, and by far the least important – is the fact that we’ll need to add additional conditions to the story manager event, so it only triggers if the player annoys a Jarl. This will reduce the number of players for whom the event will trigger. We’re comfortable with players missing content in our games, however, so while we’ll take this sort of thing into consideration, it isn’t a big concern.<br />
<br /></div>
<div class="MsoNormal">
More troublesome however, is the fact that by validating one member of the possibility space – we’ve now established the idea that this is a politically-motivated assassination attempt, not romantic, revenge, or otherwise – we instantly invalidate every other member of the original possibility space. We haven’t necessarily increased the possibility space in a new or more interesting direction, either. So we’ve arguably put more effort into making a less effective or interesting story. Further, we’ve started down a slippery slope of implementation. The moment I attribute the contract to a Jarl, I have to consider reasonable reactions on the part of the player. Can the player confront the Jarl? What will be said? What if the player takes revenge? When we tack on story for its own sake, without an idea of where we are going, it can be difficult to know where to draw the line and move on.</div>
<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhogO3m4wn08r9B55jlm0emHIKGgpyf1vgZG06yyPhbrwMV3VNMSWIXN_TZqHAEbL23PCcaDfcW25JZSLKCulVCYF_YIGNr8hfSJ1yIhbL5yVpJrgcqWA-kR2fczoee-3FwNUHZ/s1600/LydiaPNG.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhogO3m4wn08r9B55jlm0emHIKGgpyf1vgZG06yyPhbrwMV3VNMSWIXN_TZqHAEbL23PCcaDfcW25JZSLKCulVCYF_YIGNr8hfSJ1yIhbL5yVpJrgcqWA-kR2fczoee-3FwNUHZ/s320/LydiaPNG.png" width="239" /></a></div>
<br />
One interesting sidebar for those who have played Skyrim – many players will be familiar with an NPC named Lydia. Lydia is assigned to follow the player at a relatively early stage of the game’s Main Quest, and will dutifully tag along on whatever adventures the player undertakes. Lydia became a surprise hit with players – not long after launch, we began hearing stories about Lydia and the <a href="http://www.rockpapershotgun.com/2011/11/21/skyrim-lydia-death/" target="_blank">emotions </a>and <a href="http://youtu.be/ns8jsiQZEgw" target="_blank">personality</a> that were projected upon her. The bittersweet fact about Lydia is that she’s a stock NPC with no unique attributes or dialogue of her own, save her name and face. She’s just one member of a small group of standardized “housecarl” characters - one per city in the game - who will follow the player as a reward for attaining status with that city.<br />
<br /></div>
<div class="MsoNormal">
This simply goes to show that we must never underestimate the power of player imagination. The fact that the stories and personality players project onto Lydia doesn’t technically exist in the game data is irrelevant. In fact, it makes those stories all the more important.<br />
<br />
<div style="text-align: center;">
<u>Example III: The Headless Horseman & 15-Minute Proofs.</u></div>
</div>
<div class="MsoNormal">
Another Wilderness encounter that can trigger is the Headless Horseman event. At night, there’s a chance a ghostly figure on horseback will ride past the player. Should the player pursue the Horseman – not a directed activity – he will ride to a cemetery and de-materialize. The cemetery has an simple, independent event set up, and some skeletons and loot will be waiting for the player there. Part of what makes this event interesting is the fact that it very nearly wasn’t in the game at all.<br />
<br /></div>
<div class="MsoNormal">
As mentioned earlier, Wilderness encounters are triggered based on where content <i>isn’t</i> in the world. We couldn’t effectively determine where content gaps existed until fairly late in development because we couldn’t know earlier where all the major roads, dungeons, cities, and Points of Interest would happen to be. As a result, many of these events went into the game at a late stage, and we were very interested in ideas which were easy to implement but provided a big bang for the buck.<br />
<br /></div>
<div class="MsoNormal">
A few of us were standing around the office, chatting about ideas for a level designer involved with this effort. The idea of a headless horseman came up, but we knew there would be no way to get unique art at this stage, and collectively gave the idea up. A thought struck me, however, and I told the designer who would be doing the work to give me a few minutes to try something at my desk. Here’s what I did.<br />
<br /></div>
<div class="MsoNormal">
I had dabbled with our outfit system not much earlier, and started looking at an existing set of armor. Armor in Skyrim uses a slot system. In the case of the cuirass I was using, it was tagged with the body slot. This tells the game not to render the character skin below the neck or above the elbows/knees, since the cuirass will cover the body up in those areas anyway. I simply duplicated the armor and told the game a few lies by tagging the same piece of cuirass art with several other slots related to the head and face. The result of this is that equipping the armor causes the head to stop rendering, since the game thinks you’re wearing a full-face helmet.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJJPDaSthX5j-X1sh5Bl31qJ48lR1WpGJFZ7PZI3fkQ7a-efsVIFqvsXIRngJdl2E5fd_WQC0tNWj_IYz4tDoJruirwL13UKweHA6A8iLAreQjCL-WZ2yb1xevAZQ14DPcLj4w/s1600/Headless02.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="248" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhJJPDaSthX5j-X1sh5Bl31qJ48lR1WpGJFZ7PZI3fkQ7a-efsVIFqvsXIRngJdl2E5fd_WQC0tNWj_IYz4tDoJruirwL13UKweHA6A8iLAreQjCL-WZ2yb1xevAZQ14DPcLj4w/s640/Headless02.png" width="640" /></a></div>
<br /></div>
<div class="MsoNormal">
Armed with the results of this experiment, I was able to tell the level designer who implemented the event exactly how to get the desired results, as well as a few warnings and caveats I expect he may run into. </div>
<div class="MsoNormal">
The moral of this story isn’t to hack, of course. That can be trouble for a number of reasons, even though it worked out in this case. The important idea here is the concept of a fifteen minute proof.<br />
<br /></div>
<div class="MsoNormal">
When I sat down to prototype the headless NPC, I wasn’t sure what would be possible. So I gave myself short period of time to experiment. For most level design problems, I find that fifteen minutes is a good limitation. It’s not enough time to solve a problem, and that’s the point. You only want to explore the reality of the idea enough to determine whether it’s tenable and gauge what will be involved. <br />
<br />
This exercise is what I call a <b>15-minute proof.</b><br />
<br /></div>
<div class="MsoNormal">
I love using 15-minute proofs, because I think we tend to react to spur-of-the-moment ideas in two ways as designers. We either jump in with both feet, or dismiss it out of hand. By permitting yourself a 15-minute proof, you can make more informed decisions. This appeals to our inner idealist, because it gives a risky idea a chance at life, rather than seeing it ignored as an unknown quantity. They please the realist as well, because we’re saving time in the long run. Many 15-minute proofs will end with the idea being too difficult or time-consuming to pursue. It’s far better to have only lost fifteen minutes finding that out, rather than to have allowed ourselves to simply start working on it and only find that out after a week or work.<br />
<br /></div>
<div class="MsoNormal">
The 15-minute proof is especially useful when multiple solutions are competing. If your tools are anything like ours, there’s always more than one way to skin a cat. With the Creation Kit, in fact, there are often a half dozen ways to approach any given problem. Thanks to this, it’s a common scene in our office to see one designer who is grappling with an idea or problem, and have two or three other colleagues each proposing very different routes. When this happens, the designer typically runs with whichever idea was represented the most convincingly. That designer may only find out a week or a month – or more – down the road that there’s some issue with the resolution that renders it ineffective. When this happens, you’re at an impasse. You can cut your losses and move on, or try to recall or re-construct the alternatives that were presented, and choose one of those – potentially repeating the same process again.<br />
<br /></div>
<div class="MsoNormal">
By permitting yourself a proof for each solution, you’re still only gambling with an hour or so of your life, and you’re going to make a much more educated decision about how to proceed, without having to try and remember every alternative if one doesn’t pan out.<br />
<br />
<div style="text-align: center;">
<u>Example IV: Special Pickaxes & Avoiding Extraneous Nesting</u></div>
</div>
<div class="MsoNormal">
When we want to discuss simplicity and the workflow of a designer, it seems inevitable that we should discuss scripting. This is one area where simple solutions are almost universally preferable, and especially difficult for designers to identify and implement.<br />
<br /></div>
<div class="MsoNormal">
One of the many activities available to players in Skyrim is the ability to gather minerals by mining. The way it works is straightforward. Nodes in the environment can be activated by the player, who will play an appropriate animation if in possession of a pickaxe. After a few seconds the animation completes and the player has gathered some minerals to use in crafting. Sometime in the later stages of alpha , however, I receive a bug.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEioaZ0ikfYC9xr33ptxlCs-QedJh0tW1EvcMvwuSXPgfOPRFKkDqA9fO0q4NRxUlx-CKI3Ewx3Oe7A5WIRUcu_HUBJYfBUCqeKMoPTsR75UX4T0VCjHFO_RftMlhKEbwO2xw6/s1600/MinerAtWork.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEioaZ0ikfYC9xr33ptxlCs-QedJh0tW1EvcMvwuSXPgfOPRFKkDqA9fO0q4NRxUlx-CKI3Ewx3Oe7A5WIRUcu_HUBJYfBUCqeKMoPTsR75UX4T0VCjHFO_RftMlhKEbwO2xw6/s400/MinerAtWork.png" width="400" /></a></div>
<br /></div>
<div class="MsoNormal">
One of our QA testers has identified that she cannot mine ore when in possession of a unique pickaxe that I had created. I asked the designer responsible for the system which scripts to check out and I found this function:<br />
<br />
<span style="background-color: #444444; font-size: x-small;"><span style="color: #ffcc00; font-family: Verdana;"> bool</span><span style="color: white; font-family: Verdana;"> </span><span style="color: yellow; font-family: Verdana;">function</span><span style="color: white; font-family: Verdana;"> </span><span style="color: white; font-family: Verdana;">playerHasTools</span><span style="color: #ffcc00; font-family: Verdana;">()</span></span><br />
<span style="background-color: #444444; font-size: x-small;"><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;"> </span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">if</span><span style="color: white; font-family: Verdana; text-indent: 0in;"> </span><span style="color: white; font-family: Verdana; text-indent: 0in;">Game.</span><span style="color: yellow; font-family: Verdana; text-indent: 0in;">GetPlayer</span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">()</span><span style="color: white; font-family: Verdana; text-indent: 0in;">.</span><span style="color: yellow; font-family: Verdana; text-indent: 0in;">GetItemCount</span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">(</span><span style="color: white; font-family: Verdana; text-indent: 0in;">pickaxe01</span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">) </span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">> 0</span></span><br />
<span style="background-color: #444444; font-size: x-small;"><span style="font-family: Verdana; text-indent: 0in;"><span style="color: #ffcc00;"> </span></span><span style="color: #a3a3a3; font-family: Verdana; font-style: italic; text-indent: 0in;">; player has a pickaxe.</span><span style="color: #a3a3a3; font-family: Verdana; font-style: italic; text-indent: 0in;"> </span><span style="color: #a3a3a3; font-family: Verdana; font-style: italic; text-indent: 0in;">Return true.</span></span><br />
<span style="background-color: #444444; font-size: x-small;"><span style="font-family: Verdana; text-indent: 0in;"><span style="color: #a3a3a3;"><i> </i></span></span><span style="color: yellow; font-family: Verdana; text-indent: 0in;">return</span><span style="color: white; font-family: Verdana; text-indent: 0in;"> </span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">TRUE</span></span><br />
<span style="font-size: x-small;"><span style="background-color: #444444; color: #ffcc00; font-family: Verdana; text-indent: 0in;"> Else</span></span><br />
<span style="background-color: #444444; font-size: x-small;"><span style="font-family: Verdana; text-indent: 0in;"><span style="color: #ffcc00;"> </span></span><span style="color: #a3a3a3; font-family: Verdana; font-style: italic; text-indent: 0in;">; </span><span style="color: #a3a3a3; font-family: Verdana; font-style: italic; text-indent: 0in;">player has no </span><span style="color: #a3a3a3; font-family: Verdana; font-style: italic; text-indent: 0in;">pickaxe. </span><span style="color: #a3a3a3; font-family: Verdana; font-style: italic; text-indent: 0in;">Return false.</span></span><br />
<span style="background-color: #444444; font-size: x-small;"><span style="font-family: Verdana; text-indent: 0in;"><span style="color: #a3a3a3;"><i> </i></span></span><span style="color: yellow; font-family: Verdana; text-indent: 0in;">return</span><span style="color: white; font-family: Verdana; text-indent: 0in;"> </span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">FALSE</span></span><br />
<span style="font-size: x-small;"><span style="background-color: #444444; color: #ffcc00; font-family: Verdana; text-indent: 0in;"> endIf</span></span><br />
<span style="font-size: x-small;"><span style="background-color: #444444; color: yellow; font-family: Verdana; text-indent: 0in;"> endFunction</span></span><br />
<span style="font-size: x-small;"><span style="color: yellow; font-family: Verdana; text-indent: 0in;"><br />
</span></span></div>
<div class="MsoNormal">
<snippet></snippet></div>
<div class="MsoNormal">
This is reasonable stuff – the designer wrote a function to check for the pickaxe in the player inventory, and returns true if it’s found. Looking for “the” pickaxe was an entirely appropriate thing to do. He had no way to know I’d have an idea for a one-off variant at a later date. So my first reaction is simply to add an OR statement to the script. If the player has “the” pickaxe OR “my” pickaxe, then proceed.<br />
<br />
<span style="font-size: x-small;"><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;"> <span style="background-color: #444444;"> </span></span><span style="background-color: #444444;"><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">if</span><span style="color: white; font-family: Verdana; text-indent: 0in;"> </span><span style="color: white; font-family: Verdana; text-indent: 0in;">Game.</span><span style="color: yellow; font-family: Verdana; text-indent: 0in;">GetPlayer</span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">()</span><span style="color: white; font-family: Verdana; text-indent: 0in;">.</span><span style="color: yellow; font-family: Verdana; text-indent: 0in;">GetItemCount</span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">(</span><span style="color: white; font-family: Verdana; text-indent: 0in;">pickaxe01</span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">) </span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">> 0 ||</span></span></span><br />
<span style="background-color: #444444;"><span style="color: #ffcc00; font-family: Verdana; font-size: x-small; text-indent: 0in;"> </span><span style="color: white; font-family: Verdana; font-size: x-small; text-indent: 0in;">Game.</span><span style="color: yellow; font-family: Verdana; font-size: x-small; text-indent: 0in;">GetPlayer</span><span style="color: #ffcc00; font-family: Verdana; font-size: x-small; text-indent: 0in;">()</span><span style="color: white; font-family: Verdana; font-size: x-small; text-indent: 0in;">.</span><span style="color: yellow; font-family: Verdana; font-size: x-small; text-indent: 0in;">GetItemCount</span><span style="color: #ffcc00; font-family: Verdana; font-size: x-small; text-indent: 0in;">(</span><span style="color: white; font-family: Verdana; font-size: x-small; text-indent: 0in;">pickaxe02</span><span style="color: #ffcc00; font-family: Verdana; font-size: x-small; text-indent: 0in;">) </span><span style="color: #ffcc00; font-family: Verdana; font-size: x-small; text-indent: 0in;">> 0</span></span><br />
I checked, however, and found <i>another</i> unique pickaxe in the game. My first reaction was still to add an OR check to the script, but it made the script visually ugly on the screen, and I wanted to find a better approach. What I ended up doing was creating a piece of data which, in our tool, is called a <i>FormList</i>. This is just a collection of objects, and can be passed into getItemCount just like an explicit object. Not only did this make my script more readable, and therefore less error-prone, but I just happened to know that a formList is more tolerant of updates than scripts, which is important for future mods, patches or DLC that may wish to also modify things.</div>
<div class="MsoNormal">
<br />
<div style="text-align: center;">
<u>Example V: Barred Doors & Deceptively Simple Checks</u></div>
</div>
<div class="MsoNormal">
In the first example I mentioned that we did occasionally need to prevent the player from progressing through a space in the wrong direction. The quickest and easiest way to do this in our editor is to simply mark the door as locked, requiring a key. This is easy and effective, but it sends a mixed message. The door cannot be lockpicked open, and players sometimes assume a key must exist when there often is none. As a result, we’ve had reports of players searching the area for a key, and sometimes even going all the way back to town to see if they missed a quest step.<br />
<br /></div>
<div class="MsoNormal">
To improve upon this, we wanted to have the option of including barred doors. We felt this was something people would understand – if a door is barred from the other side, you don’t bother looking for a key or hidden lever. You understand that you must navigate space to get around to the other side. So we requested a simple piece of art to couple with our standardized door shape.<br />
<br /></div>
<div class="MsoNormal">
I sat down to script this all up. The lockbar was easy – animate up when clicked, animate down when clicked again. Likewise, the door wasn't too challenging. If the player tries to open the door while the corresponding bar is engaged, provide a “<i>This door is barred from the other side</i>” feedback message.<br />
<br />
Everything compiled, so I hopped in game to test – and found something I didn’t expect.<br />
<br /></div>
<div class="MsoNormal">
When players approached the door from the side with the bar, they could still click on the door itself and receive the “barred from the other side” message, which of course is just as mixed a message as what we were trying to fix in the first place. I think of a few ways to potentially solve the issue, such as scripting triggers in the area to inform the door about whre the player has come from, or working with an artist to come up with tricky art that splits the door up into multiple parts, or includes a fake collision volume in the bar. The trouble is that none of these are particularly graceful, and are arguably more trouble than they’re worth for the problem I want to solve.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxVD8M4HMrOTF0IIMtDFZAQfPDVRiuA9V-QYBrsNF5LwQePQA2Us8rOEeU3qratO74z7SwOTtCpezGeZf3Lv8-6bSM-Z2jpF-_u1DhpbP3ux6yiBhvbURvOrLGpVDY9a5IkTPX/s1600/BarredDoor.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="225" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxVD8M4HMrOTF0IIMtDFZAQfPDVRiuA9V-QYBrsNF5LwQePQA2Us8rOEeU3qratO74z7SwOTtCpezGeZf3Lv8-6bSM-Z2jpF-_u1DhpbP3ux6yiBhvbURvOrLGpVDY9a5IkTPX/s400/BarredDoor.png" width="400" /></a></div>
That’s when I happened to notice something – the pivot point (represented by a small, yellow + in the image above) of the doors are always at the bottom/center of the object, and the lockbar art pivot point is directly below the bar. Because of this, I realize that there will always be a fixed distance between the pivots – so I added a new check to my script - note the second if statement below:<br />
<br />
<span style="background-color: #444444; font-size: x-small;"><span style="color: #ffc000; font-family: Verdana;">if </span><span style="color: #d9d9d9; font-family: Verdana;">barred </span><span style="color: yellow; font-family: Verdana;">==</span><span style="color: #d9d9d9; font-family: Verdana;"> </span><span style="color: #ffcc00; font-family: Verdana;">true</span><span style="color: #d9d9d9; font-family: Verdana;"> </span><span style="color: yellow; font-family: Verdana;">&&</span><span style="color: #d9d9d9; font-family: Verdana;"> </span><span style="color: #d9d9d9; font-family: Verdana;">actor </span><span style="color: yellow; font-family: Verdana;">==</span><span style="color: #d9d9d9; font-family: Verdana;"> </span><span style="color: #d9d9d9; font-family: Verdana;">game.</span><span style="color: yellow; font-family: Verdana;">getPlayer</span><span style="color: #ffcc00; font-family: Verdana;">()</span></span><br />
<span style="background-color: #444444; font-size: x-small;"><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;"> if</span><span style="color: #d9d9d9; font-family: Verdana; text-indent: 0in;"> </span><span style="color: #d9d9d9; font-family: Verdana; text-indent: 0in;">actor.</span><span style="color: yellow; font-family: Verdana; text-indent: 0in;">getDistance</span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">(Door) </span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">< </span><span style="color: #d9d9d9; font-family: Verdana; text-indent: 0in;">actor.</span><span style="color: yellow; font-family: Verdana; text-indent: 0in;">getDistance</span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">(</span><span style="color: #d9d9d9; font-family: Verdana; text-indent: 0in;">LockBar</span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">)</span></span><br />
<span style="background-color: #444444; font-size: x-small;"><span style="font-family: Verdana; text-indent: 0in;"><span style="color: #ffcc00;"> </span></span><span style="color: #a3a3a3; font-family: Verdana; font-style: italic; text-indent: 0in;">; I cannot be opened from this side!</span></span><br />
<span style="background-color: #444444; font-size: x-small;"><span style="font-family: Verdana; text-indent: 0in;"><span style="color: #a3a3a3;"><i> </i></span></span><span style="color: #d9d9d9; font-family: Verdana; text-indent: 0in;">barredMSG.</span><span style="color: yellow; font-family: Verdana; text-indent: 0in;">show</span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">()</span></span><br />
<span style="background-color: #444444; font-size: x-small;"><span style="font-family: Verdana; text-indent: 0in;"><span style="color: #d9d9d9;"> </span></span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">else</span></span><br />
<span style="background-color: #444444; font-size: x-small;"><span style="font-family: Verdana; text-indent: 0in;"><span style="color: #ffcc00;"> </span></span><span style="color: #a3a3a3; font-family: Verdana; font-style: italic; text-indent: 0in;">; player must be on the "right" side</span></span><br />
<span style="background-color: #444444; font-size: x-small;"><span style="font-family: Verdana; text-indent: 0in;"><span style="color: #a3a3a3;"><i> </i></span></span><span style="color: #d9d9d9; font-family: Verdana; text-indent: 0in;">UnlockMeMSG.</span><span style="color: yellow; font-family: Verdana; text-indent: 0in;">show</span><span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;">()</span></span><br />
<span style="color: #ffcc00; font-family: Verdana; text-indent: 0in;"><span style="background-color: #444444; font-size: x-small;"> endif</span></span><br />
<span style="color: #ffcc00; font-family: Verdana;"><span style="background-color: #444444; font-size: x-small;">endif</span></span><br />
<div style="direction: ltr; language: en-US; margin-bottom: 0pt; margin-left: 0in; margin-top: 4.8pt; mso-line-break-override: none; punctuation-wrap: hanging; text-align: left; text-indent: 0in; unicode-bidi: embed; vertical-align: baseline;">
<span style="color: #ffcc00; font-family: Verdana;"><span style="font-size: x-small;"><br />
</span></span></div>
</div>
<div class="MsoNormal">
<snippet></snippet></div>
<div class="MsoNormal">
This ended up working out fine, and it’s how the game shipped. Something I found funny, however – in preparing for GDC, I relayed this story to one of our programmers, and explained that while I thought it was a neat example of a simple fix, but I didn’t know if I should use such a hack as an example at GDC. The fix seemed too simple, and I had spent the project waiting for bugs to show up, although they never surfaced. He literally laughed in my face. He told me that it was just good code I had written. He’d have done the same if I had requested a code fix.<br />
<br /></div>
<div class="MsoNormal">
This underscores the importance of script literacy for designers. Anybody with programming experience has probably rolled his or her eyes at these examples, because they seem so elementary. But many designers have learned to script on the job, and we tend to script in a very purpose-driven way. Most designers script to solve a very specific problem, and can be guilty of a kind of tunnel-vision. We don’t have the shared knowledge base programmers benefit from. We aren't always aware of things like code etiquette and best practices.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHqQKQ0nJEvPmL4Hfty5su3IPXSYxUbuGo_09BtZsiUUmZlwOJrhjQcGd2RRyMUXDhQrNr71Q48gWpj1jd7OW3M37zh_uOm7VPPFrGlT68KIq0ps4AEXW7YQdwJ50cEF96vy2j/s1600/vaultboycoding.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiHqQKQ0nJEvPmL4Hfty5su3IPXSYxUbuGo_09BtZsiUUmZlwOJrhjQcGd2RRyMUXDhQrNr71Q48gWpj1jd7OW3M37zh_uOm7VPPFrGlT68KIq0ps4AEXW7YQdwJ50cEF96vy2j/s1600/vaultboycoding.png" /></a></div>
<br /></div>
<div class="MsoNormal">
There’s also a common misconception among non-programmers that code is complicated. It can be, especially if you’re talking about something like 3D rendering or memory allocation. Much of the coding involved with games has more to do with logic control, however. I encourage any designer to learn more about this kind of programming. Even if you don’t script frequently – or at all – you’ll not only be better equipped to communicate with programmers, but also be able to apply the abstract principles of logical design in ways you may not expect, whether it’s mapping out the flow of conversation, wiring up entities in the editor, or approaching puzzle design.<br />
<br /></div>
<div class="MsoNormal">
The real message here is: talk to programmers. Not just about your scripting issues – though that is wise – but also about the problems they tackle in their work. Designers may often miss simple solutions simply because it doesn’t occur to us that they can exist in scripting.<br />
<br />
<div style="text-align: center;">
<u>Example VI: Disputing Occam & Justifying Butterflies</u></div>
</div>
<div class="MsoNormal">
Hopefully I’ve shown enough simple solutions to convey their merit, but what about complex ones?</div>
<div class="MsoNormal">
When I first pitched this talk, it was really just the germ of an idea – that original observation about designers layering uncalled-for complexity, and the need to resist that temptation. Because of this, it was quite reasonably suggested to me that I frame the talk around Occam’s Razor.<br />
<br /></div>
<div class="MsoNormal">
For those who don’t know, Occam’s Razor is a concept generally summarized thusly: When comparing two theories, if all other things can be taken as equal, the one which can be expressed in the simplest terms tends to be the better of the two. While I like Occam’s as a rule of thumb, I found that I was increasingly uncomfortable using it as the basis of this talk. I was coming to conclusions I didn’t necessarily agree with, and seeking out very specific kinds of examples to reinforce them. <br />
<br /></div>
<div class="MsoNormal">
What I realized was that Occam’s Razor is very often applied – and mis-applied – as a debate tactic. When debating two opposing ideas, it’s often useful to create a black/white scenario. If you can classify your argument as simple and the opposite as complex, then it’s just a matter of applying the Razor to cut away the complex one and win the debate.<br />
<br /></div>
<div class="MsoNormal">
The language isn’t quite that plain for us. First of all, simplicity and complexity are really just attributes of the solutions we’ve looked at today. Better terms may be “Direct” and “Robust” – and those aren’t mutually exclusive, but opposite ends of a spectrum. When we look at things this way, our examples may bias towards the direct side of the scale, but they aren’t all in the same point. Some are more robust than others – and that doesn’t make them inherently worse. The point here is that a complex solution isn’t an incorrect one.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmUtsyHCU6VW7oe-dxuH1p8CTgNKLIZUOeTxtqNs2uMonfug17bVVHpFCA1CuWOXj158TNIg95MSj4FnWsutCZ5Nq5AbEqGyIPjxdzfoH1UEUiGg9-buMlvsPTVdgobXDCMJCb/s1600/PursuingElegance.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="150" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmUtsyHCU6VW7oe-dxuH1p8CTgNKLIZUOeTxtqNs2uMonfug17bVVHpFCA1CuWOXj158TNIg95MSj4FnWsutCZ5Nq5AbEqGyIPjxdzfoH1UEUiGg9-buMlvsPTVdgobXDCMJCb/s320/PursuingElegance.png" width="320" /></a></div>
<br />
You just have to know what you’re getting into.<br />
<br /></div>
<div class="MsoNormal">
With that in mind, I want to discuss critters. In Skyrim, critters are any form of small life such as insects and fish. They also happen to be a fully scripted system, as it wouldn't make much sense to impelement these with the full suite of AI an animations given to a human or dragon, for example. <br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRnHpI_QMK6IyVlBdSwGVwb7E-pLJkHYAkooQqngEYy-5m4gEtnFsXwrI0Oq_hC7BQONVU-JNxbj38LuGg5I_qEBoWSgi3aNxrzUsRQrYQhiVdl0wGIX-V2wkxiTYcNAu9ke7e/s1600/critters.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="120" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRnHpI_QMK6IyVlBdSwGVwb7E-pLJkHYAkooQqngEYy-5m4gEtnFsXwrI0Oq_hC7BQONVU-JNxbj38LuGg5I_qEBoWSgi3aNxrzUsRQrYQhiVdl0wGIX-V2wkxiTYcNAu9ke7e/s320/critters.png" width="320" /></a></div>
The features of critters are as follows. They have a limited awareness of their environment. Butterflies prefer certain types of flowers. Dragonflies will dart away from the player. Fireflies know to come out at night, and fish are aware of each other and will form schools. Because they know a little bit about the world, we are able to move them procedurally. There are no traversal animations for critters; we move them completely through script-generated splines. Critters are also interactive – players can catch them as well as do damage to and "kill" them.</div>
<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgD2fvQDtDpz1EIGhlE-McHVUzNCNT3QuV0GborpUPCOAteDetl36DpXZDdfPT5tpLyyBkFWatLOInE40N7HRo6xBB51TqB3so7cZ-_ZV1i8ppRUM3DCIRQm2aUEXvANlr3g4eK/s1600/Daedra.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgD2fvQDtDpz1EIGhlE-McHVUzNCNT3QuV0GborpUPCOAteDetl36DpXZDdfPT5tpLyyBkFWatLOInE40N7HRo6xBB51TqB3so7cZ-_ZV1i8ppRUM3DCIRQm2aUEXvANlr3g4eK/s400/Daedra.png" width="210" /></a></div>
<br /></div>
<div class="MsoNormal">
You may think that this seems like a lot of effort for insects. You wouldn’t be alone in that assessment. Colleagues within the studio saw what we were doing and wondered why we didn’t consider simpler alternatives. It’s not as though a feature sheet ever existed for Skyrim that declared the game would feature Dragons, Radiant Story, a Civil War, Shouts and… butterflies. This was a direct reaction to something we felt was missing in the game – a layer of small life and motion in the environment.<br />
<br />
We certainly could have requested art of what would essentially be particle clouds of butterflies moving in a looping path. Many critters began this way, in fact. There are a number of reasons that I believe the complexity of critters was justified, however, and why we persisted.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
First of all – we introduced a brand new scripting system called Papyrus for Skyrim. This happened to be the second time in my career where I was working for a studio that threw out one language for a new, better one. What I had observed was that designers will suddenly have vastly more power at their diposal – and no clue what to do with it. The trouble is that six months later, you’ll see the designers simply doing the same things, in the same way, with a new syntax that they’ve had to learn. We wanted a complex scripted system, not just to stress test Papyrus, but also to culturally show the studio what wonderful things were possible now that we could never have done before. Critters fit that bill perfectly.<br />
<br /></div>
<div class="MsoNormal">
Second – and completely subjective – we felt that we were giving players a better value proposition with interactive, dynamic critters. This is the kind of point you can’t effectively argue, however. Sometimes you just have to stand behind a belief that something is “worth it”.<br />
<br /></div>
<div class="MsoNormal">
The third reason is twofold – critters are a highly repeptive system. The first layer here is repetition to the player. As of March 2012, the median playtime of Skyrim among Steam users is around 80 hours. 27% of those players spent upwards of 100 hours with the game. This is a massive compliment, and we knew that players tend to spend a lot of time in our games. By taking the extra effort to make this sytem dynamic, we felt that critters would stand a better chance of capturing the imaginations of our players, rather than becoming simple window dressing early on.<br />
<br /></div>
<div class="MsoNormal">
The second, and probably more important consideration, is the repetition of workflow. We knew that we wanted there to be a lot of critters placed in the game. Because of this, it was important to us that they were dynamic, procedural, and above all – easy to put in. When you observed the time we spent from the outside looking in, you’d see a programmer, of whom the critters were his brainchild, spending a lot of time prototyping critter features and making sure allt he appropriate scripting hooks were in place, as well as myself putting a lot of time into writing the scripts and making sure everything was hooked up as we wanted in the editor. This doesn’t’ even mention the four artists who lended us their time actually creating the critters and responding to our evolving needs for how they were built, animated and exported.<br />
<br /></div>
<div class="MsoNormal">
The groundwork for critters consumed as much time as it did in large part because the system was dynamic. But thanks to this we were able to make a system which was very flexibile, making the addition of new critters relatively simple, but also allowed for drag-and-drop implementation in the game. This last part was very important because we knew we needed every artist and designer contributing to world-building to be adding critters where possible. If every critter spawner required technical set-up, then we wouldn’t have seen nearly as many put into the world at all. It’s important to note here that any given artist or designer on the team is smart enough to tweak the script or perform manual setup if that was required – but when designing a tool or system to be used by creative people, it’s important to stay out of their way as much as possible and permit them to be creative. While they’re smart enough to be technical, you don’t want them wasting brain cycles on it when creating. So if we can build more robust systems to permit this in their workflow – all the better.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6Irxd1tL7y1AAvLwTgEr6-qVVXPM3cw5nGHCIaXgAs_BfcKQ7Ad7IhLuteKHuWfNQgCZHcju3uyq8GMV2iC0kpKvQXuo_mwq63j4sBHKdd016ktslehXcWkxVzRV12XNvaRS0/s1600/CostTradeoff.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="216" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6Irxd1tL7y1AAvLwTgEr6-qVVXPM3cw5nGHCIaXgAs_BfcKQ7Ad7IhLuteKHuWfNQgCZHcju3uyq8GMV2iC0kpKvQXuo_mwq63j4sBHKdd016ktslehXcWkxVzRV12XNvaRS0/s400/CostTradeoff.png" width="400" /></a></div>
So – simple solutions are good, and complex ones can be good, too. Where does it come together? How do we know when to go in which direction? That’s where process comes into it.<br />
<br /></div>
<div class="MsoNormal">
You see – in this spectrum of direct and robust solutions, all answers are good ones. An infinite constellation of bad solutions exist outside, but let’s assume everything within is good for now. There’s still a best place to be – in the center. This is where elegant solutions live.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGou5-PF8l7_Rze280zIh3bVvzggsq7koK7oL-LG2HBaBBA0YB12w0GKf7dhHKvWLaqMRPQ9yWgvFhpfgaiTkdIrJ7RtOz2e7yo-sLiL9xf7yQt3fo9iGfIuJ82VuOYkk0LM7D/s1600/PursuingElegance.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGou5-PF8l7_Rze280zIh3bVvzggsq7koK7oL-LG2HBaBBA0YB12w0GKf7dhHKvWLaqMRPQ9yWgvFhpfgaiTkdIrJ7RtOz2e7yo-sLiL9xf7yQt3fo9iGfIuJ82VuOYkk0LM7D/s320/PursuingElegance.png" width="320" /></a></div>
<br /></div>
<div class="MsoNormal">
Elegance is a term most people who work with computers will know – these are solutions that have the ease of understanding that come with direct solutions, but also have the broad focus of a more robust solution, without the tendency for bugs. Put another way – elegant solutions are always optimal. You’ll never favor a highly simple or complex solution when an elegant one is on the table. That’s the trouble with elegance, though – it usually isn’t available. You almost never find it out in the open.<br />
<br /></div>
<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIDGcP1O0DOW9oiC5Dy2TLIPFSy4rZ6NX0pgeBZw322SZiTmx4IKGNVJr0YTyufxSUbq9qi-pyZ4x0giTlzoxt4zXAvT3CNqtpPMIbFINJqKb9NKO12o4FwCLkoogA743KLZ1q/s1600/Quixote.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIDGcP1O0DOW9oiC5Dy2TLIPFSy4rZ6NX0pgeBZw322SZiTmx4IKGNVJr0YTyufxSUbq9qi-pyZ4x0giTlzoxt4zXAvT3CNqtpPMIbFINJqKb9NKO12o4FwCLkoogA743KLZ1q/s200/Quixote.png" width="168" /></a></div>
So – how do we pursue elegance, if it won’t come to us? Unfortunately, there is no roadmap I can provide. I won’t lie to you and pretend to share my top ten tips for finding elegance in every situation. What I can tell you is that it’s often found within a compromise – and compromise is only found as part of the internal discussion we call the creative process.<br />
<br /></div>
<div class="MsoNormal">
Writers often talk about sitting down to a draft and writing expansively. You have an idea of your characters, their goals and where a scene may go, but you aren’t worried about grammar or sentence structure at this phase. The goal is to get whatever is in your head out onto the page. If an idea takes you in the moment, you should follow it. Keep writing. Get words on the page. Hold nothing back.<br />
<br />
<div style="text-align: center;">
“<i>Write with the door closed, rewrite with the door open.</i>” - Stephen King, 'On Writing'</div>
<div style="text-align: center;">
<br /></div>
</div>
<div class="MsoNormal">
Then you walk away, and come back later. When you come back to that draft, you do so with a different mindset – when you rewrite, you’re sifting through the previous ramblings, panning for gold. This phase is the lens which identifies and amplifies the best your creativity has to offer.<br />
<br /></div>
<div class="MsoNormal">
I think it’s much the same for us. I think we begin as Idealists, and end in more of a focused, Realist state of mind. Consider this with the development cycle at large. In pre-production, it’s important that we leave the doors off and embrace every idea. You want to build the best possible foundation for your game, so rule nothing out. But anybody who has been at this phase knows that very quickly you need to begin abandoning ideas – maybe excellent ideas – or you’ll never achieve focus and define a vision for your game. Likewise, as production marches along, you’ll do this more and more as you polish and refine your game. When it comes down to shipping and dealing with content lock, the Realist will win many times, as you often don’t have the time to take the risks associated with robust ideas.<br />
<br /></div>
<div class="MsoNormal">
This doesn’t just apply to a mutli-year development cycle, however. Iterating on any given level design, you’ll begin with a blue sky attitude. Every idea is an option, but you’ll need to do less and less of this as you iterate. Level designers are often distracted by new ideas while iterating, but this can muddy the waters. It’s often better to be selective and stick to your original plan, so you can polish your work as you approach your final iteration.<br />
<br /></div>
<div class="MsoNormal">
The concept can scale even further, even down to a 15-minute proof. By definition, we begin a proof with a vague idea, and in the course of that time we begin cutting away to find the best path to take.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirLa3GUHDn_bW7Zk6kD_qyJtdd0TOdZfkbbz9a5T38bmcdoU1TdqHGeCBj42VnqqZzCgZVNSU9K1a-TGoejRyq-IeARj-qXE2qqE19nO8QpCydc5x7VCohUZa0ZeyYwwBn_648/s1600/PursuingElegance.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="186" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirLa3GUHDn_bW7Zk6kD_qyJtdd0TOdZfkbbz9a5T38bmcdoU1TdqHGeCBj42VnqqZzCgZVNSU9K1a-TGoejRyq-IeARj-qXE2qqE19nO8QpCydc5x7VCohUZa0ZeyYwwBn_648/s320/PursuingElegance.png" width="320" /></a></div>
<br /></div>
<div class="MsoNormal">
This isn’t a linear progression, either. We can oscillate back and forth between idealist and realist all day long. It’s through this cycle that we can really hear both sides of our internal conversation. And that’s how you arrive at compromise. You’ll never do that unless you’ve heard both sides of an argument – and only when considering both sides will you find those elegant solutions that can make both sides happy.<br />
<br /></div>
<div class="MsoNormal">
Consider the improvised Jazz solo. Young musicians often think that jazz is easy. The beats are looser, it’s more relatable to modern music, and the idea of a sixteen bar solo where you get to make anything up? After spending a year or two playing scales and etudes, the idea of an improv solo sounds like a vacation.<br />
<br />
Playing jazz sounds like a lot of fun – and it is – but a middle school jazz recital is typically awful.<br />
<br />
Swinging the beat as a band is extremely difficult, and an improv solo <i>isn’t </i>just making anything up at all. This is because great improv artists are masters of their instrument. They’ve internalized the fundamentals, to the point that their horn is almost literally an extension of their mind and body. Great jazz soloists aren't just creative geniuses – they’re dedicated technicians, and have played hundreds of jazz standards. They've heard other soloists and their ideas, and tried a million riffs and licks on stage and in rehearsal over the years. The great soloists often have a recognizable style, built on those sparks of genius that they keep and refine year after year. They develop, refine and present their ideas to an audience. Put another way: they iterate.<br />
<br /></div>
<div class="MsoNormal">
We aren’t so unlke them, really. Game development is still an emerging medium. We face new challenges every day, and that’s exciting. There is so much untapped potential in us – so many elegant solutions to find, whether we’re talking about scripting, layout, or more fundamental design problems. I believe it’s through our personal creative processes that we’ll grow within ourselves and make each other better. By discovering and refning your own process, you’re going to find elegant solutions - not just for the game you're working on right now, but for every this and every one to follow. And by finding those, you’ll see the opportunity for them when they arise again – and you’ll get better and better and better as you keep this up.</div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<br /></div>Joelhttp://www.blogger.com/profile/09816332769743524346noreply@blogger.com6tag:blogger.com,1999:blog-30579660.post-83741872674946739142011-03-23T02:43:00.000-04:002018-10-27T07:15:48.520-04:00GDC 2011 Transcript: Motivating Players in Open World Games<div class="MsoNormal"><a href="http://www.poweredbygamespy.com/wp/wp-content/uploads/2011/02/gdc25.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="199" src="http://www.poweredbygamespy.com/wp/wp-content/uploads/2011/02/gdc25.jpg" width="320" /></a>Since I don't use speaker notes, <a href="http://www.slideshare.net/JoelBurgess/gdc2011-motivating-players-in-open-worlds">my slides from GDC 2011</a> are basically useless on their own. Because of this, I wanted to post this transcript of my talk online. I typed the majority of this out on the plane to San Francisco, mostly as a way to practice the talk quietly, so it follows what I had planned to say pretty closely. In fact, I realized through the week that I had forgotten to make several minor points which are captured here.<br />
<br />
Fair warning - this is long. Turns out I speak about 7,000 words per hour. Transcript after the jump.<br />
<br />
<div class="MsoNormal"><a name='more'></a></div><div class="MsoNormal"><br />
<div style="margin-bottom: 0in;"><a href="http://www.blogger.com/post-edit.g?blogID=30579660&postID=8374187267494673914" name="more"></a>During the Level Design in a Day tutorial at GDC 2010, we took a lot of questions from the audience. One question directed at myself was: “How do you go about making levels for open world games?” Should be an easy one, right? The vast preponderance of my experience at this point in my career has been doing just that, after all.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">I was stumped. I gave some answer that I felt was kind of a lame cop-out, and it bothered me for the rest of the conference. By the time I left San Francisco last year, I knew that this would be where to begin if we were invited back in 2011.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">We did get invited back, and I found that the question had not gotten any easier to grab hold of. It was just too broad. There was an implication, too, that conventional level design wisdom didn’t apply, and this wasn’t true – although many tricks that served me well in more traditional games had to be tweaked for Open World efficacy. In fact, I realized that building for an Open World required some small, but fundamental shifts in how I viewed my role as a creator. Much of this was something that had happened gradually, subconsciously over years at Bethesda. So I started thinking about this notion of building for player experience in open games specifically.</div><div style="margin-bottom: 0in;"><br />
</div></div><div class="MsoNormal"><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsSCxXFLnBqsfpbj6v4Q1i8X13MTX32DKRjEuwnYJ7JY_AdhTu-OOh2U17agpfXuJU5t027RdkX1CUnzsfTm4XYWNrcnhCuQLwdYuw9Nz-XsClrsdfMQ-DI4Alwfp9zERRCLkz/s1600/Freelancer.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjsSCxXFLnBqsfpbj6v4Q1i8X13MTX32DKRjEuwnYJ7JY_AdhTu-OOh2U17agpfXuJU5t027RdkX1CUnzsfTm4XYWNrcnhCuQLwdYuw9Nz-XsClrsdfMQ-DI4Alwfp9zERRCLkz/s200/Freelancer.jpg" width="144" /></a></div><div class="MsoNormal" style="line-height: normal;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjt9iXgeC-L2uPAa-pnq2fHivd66FO-Nt_F0gEEszskpGoemREZbiKi_RpNqRd1_XVJO0LP5Gsnr821B7SVHhgIxCF40_cQErGepHPeoX32w5Swqafs-jMyX5gwSAHh2lSnkqtQ/s1600/RedDeadRedemption.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjt9iXgeC-L2uPAa-pnq2fHivd66FO-Nt_F0gEEszskpGoemREZbiKi_RpNqRd1_XVJO0LP5Gsnr821B7SVHhgIxCF40_cQErGepHPeoX32w5Swqafs-jMyX5gwSAHh2lSnkqtQ/s200/RedDeadRedemption.jpg" width="166" /></a><br />
<div style="margin-bottom: 0in;">The first thing I wanted to do was consider what we mean when we talk about an “Open” game. I didn’t want to attempt some one-size-fits-all definition, though. I don’t think of “Open World” as a genre, for one -- just a descriptor you can apply to many types of game. Shelves are lined with dozens of titles we might apply this label to – and certainly there’s been an explosion of Open Worlds since GTA III got the world’s attention with big sales and genuinely captivating gameplay. The notion of an Open World game isn’t new, though. Look further back and there are many classic titles you can apply the moniker to. Freelancer is a personal favorite, and many RPGs like Arcanum had expansive, non-linear overworld maps before GTA III brought the concept to the mainstream. Even the early consoles had them – Toe Jam & Earl, Final Fantasy, the original Zelda. Speaking of which, it’s not an entirely Western or American idea, which is sometimes the misconception. Games from Asia – Ico, Ocarina of Time, Symphony of the Night – as well as other parts of the world – Risen, Mount & Blade, Minecraft – have explored this territory.</div></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggLGsQbfVfLa5o2z6N_66vZWrpbFYF6VbrKMTDKu8MGokUIRgIO1fzVx53IBw4SjbvhFx7Z9pe-OS5t7nxYC2GLSzeOvJP9NO0UrpLKPgbD0nxJj5gDWL8lZf-KI-Ud8CFeIwu/s1600/DeusEx_1566.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggLGsQbfVfLa5o2z6N_66vZWrpbFYF6VbrKMTDKu8MGokUIRgIO1fzVx53IBw4SjbvhFx7Z9pe-OS5t7nxYC2GLSzeOvJP9NO0UrpLKPgbD0nxJj5gDWL8lZf-KI-Ud8CFeIwu/s200/DeusEx_1566.jpg" width="160" /></a></div><div class="MsoNormal" style="line-height: normal;"><br />
<div style="margin-bottom: 0in;">Further, another term that often gets thrown around when we talk about Open World games is “Sandbox.” Whereas “Open World” is just a statement about the physical space, “Sandbox” is often used in a way that could be interpreted as “Open Mechanics” or “Open Simulation Boundaries.” I don’t think many people would argue that Deus Ex is an Open World game, for example, but it has this same feeling about it; you can choose to approach the setups in the game in many different ways. </div><div style="margin-bottom: 0in;"><br />
</div>This, for me, boiled down to one common aspect -- a deliberate choice to focus on Player Agency.<br />
<br />
<div style="margin-bottom: 0in;">So why is player agency attracting so much attention? Why bother talking about it? What are the roots of our fascination with it? For me, the answer would end up being personal. I have a memory from my early childhood. The details are vague – I don’t know if it was an Atari, a computer or an arcade cabinet – but the emotion is clear. I remember feeling awe when I first saw something on screen manipulated directly by an external controller. This flew in the face of everything my young mind knew about how a TV worked and how you interacted with it. Suddenly the TV offered playtime, not passive consumption. This same draw is what has spurred a generation – and, increasingly, our global culture – towards interactivity. Even in today’s world, where we’re surrounded by interfaces and interactivity constantly, I still find myself occasionally inspired when I see something on-screen happen when I press a button, if just for a passing moment.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">I won’t be the first person to point out the obvious fact that Interactivity is the primary, and perhaps only, attribute of games that other mass media hasn’t got. It bears repeating, though. We may lag behind film, for example, in story-telling, but I believe we can catch up one day, and that’s a noble pursuit we need to focus on. But Interactivity – the fundamental core of our form – they will never have. This is why I believe in games the way I do. If I didn’t, I wouldn’t be in this industry – and I believe I have gravitated towards Open games for the same reason. Games that choose to focus on interactivity are the path to unlocking the full potential of our medium. </div></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiH3wKe7fRWLLh_kjMNPhHs0EuQyVrfGYqqg3b_yJ_sUW5xE32FTR3UoCvk0HqHmrVZ3BxFv7bpSDBAiqGd928jB-11KaeOfN9ypbT_euQRwtG3fRUjh54p4lDKb25PwOdAZ3bx/s1600/TandemBikeAdvert.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="114" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiH3wKe7fRWLLh_kjMNPhHs0EuQyVrfGYqqg3b_yJ_sUW5xE32FTR3UoCvk0HqHmrVZ3BxFv7bpSDBAiqGd928jB-11KaeOfN9ypbT_euQRwtG3fRUjh54p4lDKb25PwOdAZ3bx/s200/TandemBikeAdvert.jpg" width="200" /></a><br />
<div style="margin-bottom: 0in;">It presents problems for us as creators, though. We have a new collaborator whom we’re inviting into the creative process. The player may not directly inform creation, but games, like any storytelling medium, come alive in their audience. Games, especially, have to trust the audience with a lot of the quality of that experience. You can put a book or a film down, but you can’t usually influence the directing or script. And with Open games we’re choosing to give the player even more autonomy than usual. The control we give the player is inversely proportional to the amount of authorial control we are able to exert. This is just a reality, however. We simply need to acknowledge this partner and accept the relationship.</div></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFY3nKcEZUzWbEA6HIeOLvUg5BtdRZz3wfmVX7faKR_qYHVW2yT9CNtEPO3VsJ2KeEYvtNx5QkZ-F_HT4yrqow42HAqLkZnnFefZaTxmbkbymZoHXiAB5R56WMqgFB7Lr3vihA/s1600/MysteriousStranger.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiFY3nKcEZUzWbEA6HIeOLvUg5BtdRZz3wfmVX7faKR_qYHVW2yT9CNtEPO3VsJ2KeEYvtNx5QkZ-F_HT4yrqow42HAqLkZnnFefZaTxmbkbymZoHXiAB5R56WMqgFB7Lr3vihA/s200/MysteriousStranger.png" width="125" /></a></div><div class="MsoNormal" style="line-height: normal;"><br />
<div style="margin-bottom: 0in;">Let’s pause for a second to consider a specific type of player: the type that gravitates towards Open games. These are players who love to prod and explore. They want to experiment with cause and effect, to see how the game reacts when they do this or that. These are players who pick up on design cues – go left here – and do the opposite. Other games have trained this behavior in part. Lots of games have trigger events that advance a story, after which you can no longer go back and explore the space you’re currently in. These explorer types may be avoiding that, or just be trying to be sure they’ve fully explored an area before moving on.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">This type of player can be trouble, and designers tend to build a lot of fences around their content. Invisible walls, contingencies in scripts, locked doors – usually with a well-intentioned goal of protecting the player from ruining her own experience. The problem is that players will always find a way around these band-aids. In my experience, if you’re simply reacting to issues like this as they come up in the form of bugs, then your content is going to become bloated and difficult to edit – and you’ll inevitably miss something, especially when your player pool goes from 50 QA testers to however many thousands or millions of people play the game. Simply accepting this will often inform your process to use simple, open handling – and increase the chance that when the player breaks your handling, she doesn’t also break the game.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">The most important thing to remember is that this player isn’t a jerk. Every designer will have this reaction from time to time. “The player who does X is trying to break the game, I’m not handling this edge case!” Well, maybe. Probably not, though. These players are our people. You probably play games the same way they do. We aren’t building delicate model airplanes; we’re making Tonka trucks. Our games are meant to be banged on, played with, and not break too easily if we can help it.</div><br />
So – back to this player/designer dynamic. Like any relationship, things are going to go more smoothly if there are some ground rules.</div><div class="MsoNormal" style="line-height: normal;"></div><ul><li><span class="Apple-style-span" style="font-size: large;">Player-Designer Ground Rules</span></li>
</ul><div class="MsoNormal" style="line-height: normal;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbPMU7mMFkgueLYrozBCiBt22hyCvXFnR3oVavopaIjy9LmUEy9fyKtHWc5oldcjMuRy_MDo1F-cVxx-vx2wfJ_7kkgpWruIFWqGOZJuh5OPik_x-PScF0XepuGzI5D72blZA_/s1600/sleepisDeath.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="155" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbPMU7mMFkgueLYrozBCiBt22hyCvXFnR3oVavopaIjy9LmUEy9fyKtHWc5oldcjMuRy_MDo1F-cVxx-vx2wfJ_7kkgpWruIFWqGOZJuh5OPik_x-PScF0XepuGzI5D72blZA_/s200/sleepisDeath.png" width="200" /></a><br />
<div style="margin-bottom: 0in;">The first rule to remember is that the player is ultimately the one in control. This may seem obvious out of context. After all, we aren’t on the couch with the player, and all of our responses to player activity are preconditioned in some way. Yet we still have this illusion as creators that we have ultimate deterministic control over gameplay, when this just isn’t the case. </div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Consider Jason Rohrer’s “Sleep is Death,” a turn-based storytelling game for two players. One player is the storyteller, the other simply the player. Each turn, the player is able to move around a simple 2D area and interact or speak via simple text boxes. The Storyteller then has a window of time in which to react to the player. The storyteller presumably has an existing story in mind, and has various prepared bits of writing, background sets and other assets. The dynamic inevitably ends up with the player really driving the experience, while the storyteller scrambles to keep up – frantically, if the player isn’t being cooperative. In fact, when a SiD storyteller tries too overtly to funnel the player, the experience becomes less enjoyable – the spell is broken. It’s a lot like D&D; the Dungeon Master does a lot of prep work, but at game time the players are really the ones in the driver’s seat. At the end of the day, a common complaint for an unsatisfactory game is a heavy-handed DM or SiD storyteller trying to constrain players to follow a preordained story path.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Which brings us to our second rule: Stay backstage. Strive to be unseen. We like to keep a 4<sup>th</sup> wall between ourselves in the player. If we think of the player as an equal partner when we are creating, that’s great. The player, however, shouldn’t have the sensation of our constant presence. Your best work will go unseen – the game will just feel like it’s doing what it should, reacting to the player naturally. Remember: Tonka trucks. Try to build for open play from the start.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Third is fulfilling expectations. This is one that absolutely applies to all games, not just Open ones. This comes down to consistency and trust. The player should have a reasonable expectation of what to expect from various scenarios. For instance: these quests give armor rewards; this tactic is effective against that enemy; breaking a ? box gives me some kind of power-up, or if I follow this path I’ll find something fun. It also applies to simulation rules of the world. If the player can kick down a door in one level, it’s going to feel bad that a dozen other, similar doors in another level cannot be. This game-wide consistency builds a foundation of trust, and when reasonable player expectations are not met, it can often be disappointing and damage that valuable sense of trust. I should offer the caveat that playing with expectations can sometimes be refreshing, but it’s something to be careful with.</div><div style="margin-bottom: 0in;"><br />
</div>Fourth, and most important, is to accept that the story in the player’s head is always more important than the story you thought you were telling. Check your ego at the door. There’s a lot of talk about player-driven experience and emergent narrative. Whether or not you personally buy into it, this is important to many people who will play an Open game. This might come off as an anti-story comment, but it isn’t. The storytelling potential of games is exciting and far beyond what we’re doing right now. What I am saying, however, is that when we are trying to tell story, the player must feel like it’s occurring naturally around, or in response, to her. We shouldn’t just be telling our story at the player.</div><div class="MsoNormal" style="line-height: normal;"></div><ul><li><span class="Apple-style-span" style="font-size: large;">Directing the Player to the Fun Stuff</span></li>
</ul><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhM2VsvKkgH3noMfm4XULb7mNv70wthPgAGZ_RIYVlfFQ9nHuR4hpiu-LQxNT9TZ_ITjpsvmlIDaTvL5eOLd0Rr0gRxcAUBq11lg-WGhoRAwb29y3ZX9Xgv9ZIWbPQ0iwL005-Q/s1600/DisneyMainStreet.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="111" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhM2VsvKkgH3noMfm4XULb7mNv70wthPgAGZ_RIYVlfFQ9nHuR4hpiu-LQxNT9TZ_ITjpsvmlIDaTvL5eOLd0Rr0gRxcAUBq11lg-WGhoRAwb29y3ZX9Xgv9ZIWbPQ0iwL005-Q/s320/DisneyMainStreet.jpg" width="320" /></a></div><div class="MsoNormal" style="line-height: normal;"><br />
<div style="margin-bottom: 0in;">With these ground rules in mind, let’s confront one of the first, fundamental problems they present a level designer. My broadest definition of a level designer’s job is to ensure that the player is entertained. The definition of “entertainment” might shift to reflect the game, but that’s the basic responsibility. However, if we just got finished saying that the player shouldn’t feel our presence, how do we make sure she is entertained? Well, imagine giving somebody $50 and dropping them off in a rough part of town, versus dropping that person off at the State Fair. Now, the person downtown might have fun – more fun than you’d ever have at the fair, even – but they might also wander aimlessly or get stabbed. The person at the fair will almost certainly have a good time, because it’s an environment set up for fun.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Fun in our games is usually concentrated as some kind of POI – point of interest. These are the places in the world where we’ve put effort into setting up interest, and the primary tools in the box for any level designer or world builder to draw players naturally to them are simple environmental techniques.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">First, and most obvious, are distant visual landmarks. The classic example here is Cinderella’s castle, now a standard feature copied by themeparks everywhere. It’s one of the first things anybody sees arriving at the park and guests naturally head towards it. The interesting part about Cinderella’s castle in particular is that it’s not a ride or show. Primarily it’s a landmark to help you orient yourself in the park. It’s also a planning hub, because from the area in front of it you can see many other landmarks you might have missed before, sprinkled throughout the park.</div></div><div class="MsoNormal"><br />
</div><div class="MsoNormal" style="line-height: normal;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgdkcE2vqAf14aSgzXqQ-GOiAjn9_ZbMH53chxkaBPJfJgW1rDNWhFEE3tFvg1BFh8QjP22pd9S5b_5NRNrNtt-3WB697kKK_sDEzmAMsjcXCTub1BloWa5ZUJTIf4hdJzTK0JI/s1600/Fallout3_MiddleDistant.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="130" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgdkcE2vqAf14aSgzXqQ-GOiAjn9_ZbMH53chxkaBPJfJgW1rDNWhFEE3tFvg1BFh8QjP22pd9S5b_5NRNrNtt-3WB697kKK_sDEzmAMsjcXCTub1BloWa5ZUJTIf4hdJzTK0JI/s200/Fallout3_MiddleDistant.jpg" width="200" /></a><br />
<div style="margin-bottom: 0in;">These other landmarks are basically doing the same thing as the castle, but on a local scale. Consider the screenshot from Fallout 3. These satellite towers are the main distant landmarks in this part of the Capital Wasteland, but check out the little landmarks nearby. There's a small factory, and also a water tower will become visible as the player nears that initial landmark. We’ll talk about this kind of distraction and its utility later.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">We also use these kinds of landmarks in the Point Lookout DLC to set up several landmarks to draw the player into the new region right away, as you can see in the video below. The lighthouse and the ferris wheel are just cool weenies to draw interest.</div></div><div class="MsoNormal" style="line-height: normal; margin: 0px;"><br />
</div><div class="MsoNormal" style="margin: 0px;"><iframe allowfullscreen="" frameborder="0" height="293" src="http://www.youtube.com/embed/0Avi9bUCh9s?hd=1&start=31" title="YouTube video player" width="480"></iframe></div><br />
<div class="MsoNormal" style="line-height: normal;"><br />
<div style="margin-bottom: 0in;">The smoke rising from the mansion and the enemy silhouetted at the start of the shot both provide some movement to draw the eye, too. You can get a lot of use out of motion in the environment. Movement always creates more visual interest in your space, but it also tends to have a direction. Streams flow this way, a flag in the breeze flaps that way. These directional cues can guide the player along, some more powerfully than others. When we build POIs for Skyrim we can keep these cues in mind. For example, we’ll tend to put something interesting at the pond where a creek ends, because we consider it likely that players will follow the stream to see where it goes.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Another tool at our disposal is prior knowledge of the world. Put another way – use common sense. Games have a lot of conventions – exploding barrels, the need to break open crates – that don’t have a strong counterpart in the real world. These are fine, but remember that even hardcore gamers were unaware of them before they started playing a lot of games. Whenever we can use knowledge which is common to the human experience, we increase the efficacy of our efforts to guide the player along. Roads and signposts are a good example of this, as are signs of life, like the smoke of a distant campfire or the sounds of civilization.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">It's also important that we remember the power of sound. When we play games, we typically only have two of our senses at our disposal. Vision is already doing the heavy lifting. Probably the best use of sound to draw players in Fallout 3, as it happens, was an accident. As the player explores the world in that game, we’re constantly streaming in new area ahead of them. This means AI that was running in the background will start processing in realtime, and random encounters will spawn. This also meant that combat breaking out on the edge of the loaded area was quite common. This was the same as it was in Oblivion, except that Fallout combat is loud. What we observed was that players would be walking along in the wasteland and hear muffled, distant gunshots and explosions, and almost always turn on a dime to investigate. Lucky for us, this usually brought the player to something interesting we had set up. We’ve taken that insight with us into Skyrim, a world more visually dense than the Capital Wasteland, where players can easily walk right past a POI we set up without seeing it. Now we’re cognizant that the crackle of a campfire, the crash of a waterfall, or the ringing of an anvil might draw you to what you can’t yet see.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">None of this is revolutionary stuff, though. Most level designers and world builders are doing this, even if at an intuitive level without realizing it. What’s really going on, though? Why does it work when it works?</div></div><div class="MsoNormal" style="line-height: normal;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh42yLgl7LCVJ4Tflql5VOVNQO1DE5cnEDYxD0wT7yNTFywpTw69AGsUtrl4U34Fb28q3bPSOHv1uNXnwnE0tBTcdSow2urx0Y0JtqklrREv4eOIYs6cghclMMMBLwPzqp5z9PO/s1600/I-want-to-go-to-there.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh42yLgl7LCVJ4Tflql5VOVNQO1DE5cnEDYxD0wT7yNTFywpTw69AGsUtrl4U34Fb28q3bPSOHv1uNXnwnE0tBTcdSow2urx0Y0JtqklrREv4eOIYs6cghclMMMBLwPzqp5z9PO/s200/I-want-to-go-to-there.jpg" width="200" /></a></div><div class="MsoNormal" style="line-height: normal;"><br />
</div>Well, we’re trying to elicit a specific emotional response. We want to motivate the player to go somewhere. We’re trying to create goals in the player’s mind.<br />
<div class="MsoNormal" style="line-height: normal;"></div><ul><li><span class="Apple-style-span" style="font-size: large;">Goals and Player Motivation</span></li>
</ul><div class="MsoNormal" style="line-height: normal;">And this is interesting, because I think it’s the building block of sustained interest in any given game. I think that the player should always have a goal. This isn’t something I’ve always believed, either. I play a lot of games without focusing on the goals presented by it. Far Cry 2, for example. Sometimes I just want to be in that game. I’m not doing missions when I play, though. I’m roaming around the hills, swerving to avoid zebras with my jeep, or torching a hostile campsite.</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9Np4xmjKgYg0x2U9LC0dt3wyJBbyzrE6eovQi1UzWWWHPmeQ0OgIz0MGiEeRDZImyjIYPXoaCDOX90siI12miXLGIFwUjEpqSK2GlKva4SYGwowkTSzpkPo8uBl5CW2TtEhPq/s1600/FarCry2.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9Np4xmjKgYg0x2U9LC0dt3wyJBbyzrE6eovQi1UzWWWHPmeQ0OgIz0MGiEeRDZImyjIYPXoaCDOX90siI12miXLGIFwUjEpqSK2GlKva4SYGwowkTSzpkPo8uBl5CW2TtEhPq/s200/FarCry2.jpg" width="171" /></a></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><br />
<div style="margin-bottom: 0in;">But I also drift away from most games that I play. I don’t fail to finish games because I throw them down in a rage, or even get sick of them. I just realize one day that I haven’t touched the game – maybe a game I really enjoy – for a week or two, and I’m kind of done with it.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">What I realized in hindsight was that, in every case, I had ceased to feel compelled to do anything in the game. I had no goals, whether my own or those of the designer.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Goals can take many forms, then. The most obvious are the stated goals. When you start Fallout 3, for instance, you have an explicit quest goal to find your Dad. Now we know, because we’re comfortable with the fact that our story goals may not align with the goals or interests of the player, that the player probably isn’t going to off and find Dad right away. These stated goals are useful, though, because they provide some direction to the player. Especially for players who have become bored with the game and need something to do, or players that have put the game down for some time and don't immediately recall what they were doing with it. </div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">There are also player-determined goals. Really, any goal can be player-determined. That is, if you really want to find dad, then fine. That stated goal is also the goal of the player – great. There are also goals which may not be stated, but exist because a designer constructed them. For instance, I don’t think anybody ever tells you in Crackdown to collect all the agility orbs. But they’re there, in interesting places to go, and many of us will do nothing but hunt them down for big chunks of time. Then there are goals that are entirely unscripted. Some of them we may still kind of create – we know that stealth players will gravitate towards certain setups for an easy kill, for instance – but some are completely out of left field. Somebody playing an MMO may roleplay a blue knight and do unusual things to acquire the coolest blue armor pieces in the game. We know full well that somebody will play Skyrim and try to kill every elf they see, too. The important thing is the player choice to focus on a goal the player cares about.</div></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1mWXOJMs8mqPKhQqWG4JciQxRWtHLPlPgWdAlM5t3l4ON58ywoeZW3I-uAQUJT1XXrahX6cJ2jv9e_2XMzcHsv1agDLtDccx4Qst7DICclV8rFsRXrU-dl7iEPNM9m_HmjkOs/s1600/minecraft.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="131" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1mWXOJMs8mqPKhQqWG4JciQxRWtHLPlPgWdAlM5t3l4ON58ywoeZW3I-uAQUJT1XXrahX6cJ2jv9e_2XMzcHsv1agDLtDccx4Qst7DICclV8rFsRXrU-dl7iEPNM9m_HmjkOs/s200/minecraft.jpg" width="200" /></a><br />
<div style="margin-bottom: 0in;">There are also emergent goals to consider. The term “emergent” gets thrown around a bunch in different contexts, but what I mean here are goals that occur out of the simulation rules of the game, in pursuit of some higher goal. The best example I can give here is Minecraft. Minecraft is an interesting game to bring up, too, as it’s a game that currently has no stated goals or authored narrative whatsoever. Let’s say a few Minecraft players tell us their goal in the game. One wants to build a portal to the nether. Another just wants to explore a cool environmental feature. Maybe you want to build a cool rollercoaster like you saw on YouTube. Take the rollercoaster example. If you’ve played any Minecraft, you know that this is going to require a ton of iron. You can’t get that kind of iron without a mining operation, though. You need tools to mine, so you start clearing a forest, and you need to build a little house to keep you safe from monsters at night, too. Then you find this underwater river and end up finding a monster spawner and…. You’ve been playing every night for a week, and haven’t laid the first piece of track for your rollercoaster. You don’t throw the game down in frustration at this point, though. You’ve been highly entertained by all these little emergent goals that bubbled up, and may not even care about the rollercoaster anymore. This has everything to do with why Minecraft is so good. The simulation rules are just very well done, and create a nice pace of experience.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Somewhat similar are Goals of Opportunity. These are goals that pop up and tempt the player for a moment. Say you’re playing WoW, and you notice something on your mini-map. There’s a mineral deposit nearby – something you could really use, not far away. You check it out and sure enough, it’s in the middle of a camp of monsters just a bit too high level for you. The player makes a value judgment on the fly. Do you try to carefully pull each mob, expending resources, old school style? Maybe you call on a guild member or try to stealth in and hope you get the ore before they aggro you? Perhaps you’re feeling sneaky and wait for another player to come by and draw aggro, allowing you to ninja-loot the ore. Or, maybe, you keep riding on by. These are great little decision events that keep players interested. </div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Finally, and a little bit less relevant, but still interesting, are out-of-game goals. Trophies and achievements have given us useful way to communicate very “gamey” goals to the player. Pretend that we think there’s something really fun about getting 100 headshots, or killing ten enemies with a single explosion. That’s difficult for us to do in the narrative context of the game without breaking the fourth wall. This external layer, however, is a chance to speak, designer directly to player, and offer these goals without breaking immersion.</div><div style="margin-bottom: 0in;"><br />
</div>Given two players of the same game who happen to have the same goals, however, it’s unlikely those goals are prioritized in the same way. Different goals appeal to different players and different circumstances. We can begin to understand this judgment by breaking down that goes into it a bit.</div><div class="MsoNormal" style="line-height: normal;"></div><ul><li><span class="Apple-style-span" style="font-size: large;">Goals & Priority</span></li>
</ul><div class="MsoNormal" style="line-height: normal;"><div style="margin-bottom: 0in;">The component of prioritizing goals that any designer will know about is the risk:reward ratio. Recalling that we want to fulfill the player’s expectations, we are hopefully able to telegraph the difficulty of a given scenario to the player, so she can surmise the reward. A player might see that a platforming puzzle is difficult, or notice evidence of a challenging enemy outside the mouth of a cave. Maybe your game has a direct way of conveying both risk and reward, like WoW’s quest journal. Players will gravitate towards rewards they want and risks they feel they can handle. This is a subjective value judgment.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Somewhat less obvious is the notion of commitment – time commitment, specifically. I would hypothesize – I have no data to support this one way or another – that players tend to gravitate towards a goal they think matches the time they have to play. For instance, if Joe Gamer sits down on a busy Wednesday night, he may only have 15-30 min to play; he’ll probably choose something he thinks he can finish in the time frame. Likewise, if he’s playing Fallout 3 on the weekend and has a few hours to devote, he may decide this is the day he finally finds Dad.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">The real monkey wrench is inherent interest. There’s truly no accounting for taste. We probably have a good idea that certain things attract certain player archetypes, of course. The player who is into dialogue and bartering will gravitate towards towns, while Conan is going to grab a broadsword and go dungeon-diving. Sometimes there are player goals we can’t know a thing about, however.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">When we announced Skyrim a few months back, I was lurking on the forums and saw a speculation thread about spiders. The poster, it turned out, was curious if we’d have spiders as an enemy type in some dungeons, and if we’d include an option to disable them. I thought this was silly at first, but then I skimmed the thread and saw that other people chimed in with the same sentiment. Then it dawned on me – I know one of these people. </div></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><a href="http://www.lqgaming.com/wow/gallery/albums/deathknell/mob_young_night_web_spider.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="168" src="http://www.lqgaming.com/wow/gallery/albums/deathknell/mob_young_night_web_spider.jpg" width="200" /></a><br />
<div style="margin-bottom: 0in;">Last year I got back into WoW for a bit, and convinced my friend Casey to try it. Casey plays some games, but she isn’t the biggest gamer in the world by a long shot. I remembered that when I was helping her level her character, she would always avoid spiders. I know Casey, and she doesn’t have crippling arachnophobia. She just thinks they’re creepy and would rather not deal with them. As a lifelong gamer, this was enormously frustrating to me – if spiders give me the best XP, or if I have a quest for them, or even if they have a 1% chance to drop something I want, then I’m killin’ spiders. I don’t care if they’re unicorns and teddy bears, I’m going to get genocidal on that monster. What I realized, though, was that I was playing WoW like I was balancing spreadsheet. I’m pretty conditioned in a game like that to do whatever is the most efficient thing possible. Casey wasn’t enjoying WoW any less for her preference. That game has a broad enough scope that we could easily go around the spiders and do other stuff – and sometimes that actually made the experience more interesting.</div><div style="margin-bottom: 0in;"><br />
</div>Of course, it isn’t as though we sit around at Bethesda and chart out this kind of stuff for every quest and POI in the game. What’s the point of discussing it, then? If player choice is so chaotic that we can’t accurately predict behavior, why bother? Well, it isn’t about building a perfect metric. It’s more about awareness of this fact, and being able to cope with it as well as possible.</div><div class="MsoNormal" style="line-height: normal;"></div><ul><li><span class="Apple-style-span" style="font-size: large;">Deliberate Distraction</span></li>
</ul><div class="MsoNormal" style="line-height: normal;"><br />
<div style="margin-bottom: 0in;">In preparation for this talk, I spoke with Rob Davis, who worked on The Saboteur. He said that the golden rule for him in Open world games was to provide the player with as many interesting things to do whilst doing from point A to point B as possible. That’s spot-on.</div></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-iI6oZeNtwbBmfqkUQ4VPmyewZFBomxbq7g_P2PLrcZhNvy_r0e53xhI9uTjrNSz9LXcxw7XJFH0lsRTXTBR4ackPEet5UUBR8M61L5oVGFOzihTU0F3NcOuTix5P-_YsDRBK/s1600/GDC2011_YAWN.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="112" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-iI6oZeNtwbBmfqkUQ4VPmyewZFBomxbq7g_P2PLrcZhNvy_r0e53xhI9uTjrNSz9LXcxw7XJFH0lsRTXTBR4ackPEet5UUBR8M61L5oVGFOzihTU0F3NcOuTix5P-_YsDRBK/s200/GDC2011_YAWN.jpg" width="200" /></a>It’s something I call deliberate distraction. Let’s take that A to B example for a moment. It’s a Common setup in any RPG and most open world games. Let’s imagine that as a graph for a moment though, where the vertical axis is how entertained the player is, and the horizontal is the time spent playing the game. We’ll go ahead and assume that what happens at both A and B are pretty interesting things, but that doesn’t mean the player interest level is static between them. In fact it almost certainly wanes leaving A and falls into this valley of boredom.</div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;">So let’s revisit that scenario. We still have A and B, but we sprinkle some points of interest between them – X, Y and Z. We actually do this with quest paths at Bethesda. We’ll draw lines along quest routes and use that to inform where we place POIs. Some designers will be uncomfortable with this. You might worry that the pacing of your story will fall apart. Remember, though, that the player story comes first. If your story has a player fully compelled, chances are they’ll bee-line. Be comfortable with the fact that they may not, though. Don’t shun that player.</div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0cmWDcVaQrKn4HwxOOcJN6nTd7SvB6PcUmjqzeiVxKs1dm-72ZLDi2wmi_3n-TBI_sDu8rJJ3MYgS8esboUuWpOVQ7h-TkFNjJwbF7kyu7XrxZKHCKRpX0ipITF_nEJEzBQZM/s1600/GDC2011_Curvy.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="112" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0cmWDcVaQrKn4HwxOOcJN6nTd7SvB6PcUmjqzeiVxKs1dm-72ZLDi2wmi_3n-TBI_sDu8rJJ3MYgS8esboUuWpOVQ7h-TkFNjJwbF7kyu7XrxZKHCKRpX0ipITF_nEJEzBQZM/s200/GDC2011_Curvy.jpg" width="200" /></a><br />
<div style="margin-bottom: 0in;">Let’s just say the player checks out X and Y, but not Z. She didn’t notice Z, was in range of B and wanted to bee-line, or maybe just missed it. No big deal, it happens all the time. Perhaps there were spiders involved. When we take that journey and plot it along this imaginary graph, notice too that X and Y are a little lower on the vertical axis. Let’s just say they were less interesting than A and B. That’s fine, too. Not everything will be a big set piece. When you chart the player interest, you see that we have less sustained time spent in the valley of boredom. It doesn’t matter that X and Y weren’t mind-blowingly awesome; they still contributed some entertainment and improved the overall pace of the player story. </div><div style="margin-bottom: 0in;"><br />
</div>Deliberate distraction is just one way we cope with the next problem we want to confront – empty space. Proper use of physical space in any game, but especially an open one, is critically important, and a big part of the level designer’s responsibility.</div><div class="MsoNormal" style="line-height: normal;"></div><ul><li><span class="Apple-style-span" style="font-size: large;">Dealing With Empty Space</span></li>
</ul><br />
<div class="MsoNormal" style="line-height: normal;">Let’s pretend we have a job – remake God of War. Not a sequel, not a reboot – we’re remaking the first game, but this time it’s going to be an Open world game. Well, that game has a lot of these dramatic backgrounds, like polygonal matte paintings. So that’s what we’ll focus on. Bang that out, make all the space playable. You see it, you can go to it. Cool, right?</div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;">Well, no. If we add nothing to those areas, except that now the player can run off and explore them, we haven’t added anything of value to the game. In fact, we’ve just made the game worse. Because if the player wants to check something out – maybe some temple reminds him of a vacation spot from childhood – and there’s nothing there. What was the point? Poseidon is still wrecking things back there. That’s still where the fun is.</div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;">This is another point where some developers will become uncomfortable. There’s an attitude you might encounter in yourself or others when confronted with this. “That’s just for looks. The player isn’t really meant to get there.” That isn’t good enough. You can’t just abandon those areas. You made it playable, and remember that a good chunk of players will go explore that kind of stuff, hoping to find something neat. What they’re doing is totally valid.</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7d4mZ6JTUPY486rINWFEv_73w_DhZTFeQ1NEQHy26gfkYm69es_FB4i-kly8ezEzxlyQPObyNcPE6XUj1kz1lwowgD74gAKzo2nYcDtWmseG2-0mkj0GQp4xrG1LMLiHCNytZ/s1600/RopeBridge.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="136" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7d4mZ6JTUPY486rINWFEv_73w_DhZTFeQ1NEQHy26gfkYm69es_FB4i-kly8ezEzxlyQPObyNcPE6XUj1kz1lwowgD74gAKzo2nYcDtWmseG2-0mkj0GQp4xrG1LMLiHCNytZ/s320/RopeBridge.jpg" width="320" /></a></div><div class="MsoNormal" style="line-height: normal;"><br />
<div style="margin-bottom: 0in;">Take another example. The Rope Bridge is a classic adventure story setup. There’s always the tension – will they make it or will they fall? In the Temple of Doom – spoiler alert – Indiana Jones and friends make it across just fine. And if we were to make a Temple of Doom game with the goal of recreating the story beats from the movie, that would be all we have to handle. But we’re making an Open world game in that setting. Now we have to handle something – namely, the fall into that river full of American Alligators posing as crocodiles.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">For the linear game we didn’t really have to worry about them. Indy either couldn’t fall, or we would play a cinematic of the gators thrashing about and reload the scenario. That won’t do in an Open world game, though. So what to do? First we have to actually build the area to make it playable. No smoke & mirror tricks, we’ll have to physically connect it to the world. But what if the player falls?</div></div><div class="MsoNormal" style="line-height: normal;"><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_cJIjdLyd-gkw1CyVAK7O6M3I4-nA9Vy5u0fymYLOO99KlKed-Z5TK9ctXnzJJEqwjmrPfEjJSMvZbe3wXLAh4W38aNIO6crNIY-1VBV7f4N8qF1OusHPjq5Umixz_FwWGsyu/s1600/Temple+of+Doom+croc+%25281%2529.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="158" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_cJIjdLyd-gkw1CyVAK7O6M3I4-nA9Vy5u0fymYLOO99KlKed-Z5TK9ctXnzJJEqwjmrPfEjJSMvZbe3wXLAh4W38aNIO6crNIY-1VBV7f4N8qF1OusHPjq5Umixz_FwWGsyu/s320/Temple+of+Doom+croc+%25281%2529.jpg" width="320" /></a></div><br />
<div style="margin-bottom: 0in;">Your instinct may be to place a killbox in the canyon. Which you can do, but that sucks. That’s something we really try to stay away from. People don’t come to open world games for that. “Okay,” you say, “it’s a really long fall. The player’s probably going to die anyway.” That might be true, but remember that the player will always find a way around your little blockers and barriers. Somebody will slide down the edge safely, or have enough health buffs to survive it. So that’s not really valid – and it’s functionally the same as putting a killbox in there anyway. You may try another trick: “Those crocs are beasts. They’re going to rip the player to shreds, and the player’s going to get it. You shouldn’t be here. Go back and cross the bridge,” and at this point you’ve laid down the gauntlet. You’ve just issued a challenge to the player, and the player is going to have the skill, items, or old-fashioned patience to get through the fight and wipe out every croc down there, one way or another. And there’s no worse kick in the teeth than the fact that you’ve got nothing down there for the player but a middle finger.</div><div style="margin-bottom: 0in;"><br />
</div>What do we do with that river, then? Well, it’s the reality of building such big games that we can’t have something incredibly interesting in every nook and cranny of the world. It’s fair to point out that we spent a lot of time on whatever was across that bridge. Which makes sense -- it’s something we expect the majority of players to see or do. </div><div class="MsoNormal" style="line-height: normal;"></div><ul><li><span class="Apple-style-span" style="font-size: large;">Consolation Loot</span></li>
</ul><div class="MsoNormal" style="line-height: normal;"><br />
<div style="margin-bottom: 0in;">One thing we can use here is what we at Bethesda call “Consolation Loot.” Basically, we’ll put something – anything – in these kinds of areas. Consolation loot can be many things. We might use a freeform quest hook, some optional story bits like a journal, or the most straightforward solution – some minor loot. Some designers may suggest that we’re rewarding failure, but remember that many players will deliberately investigate these nooks and crannies, and for those people you’re rewarding exploration. Having something in these corners will make the game feel much more handcrafted and polished. We don’t want to put anything critical to progressing through the game in a dead end, but even if the loot we put in that dead end is inconsequential, it still takes a moment of zero interest – or frustration if the player went through duress to get here – and turns it into a positive moment, however minor.</div></div><div class="MsoNormal" style="line-height: normal;"><br />
</div><div class="MsoNormal" style="line-height: normal;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhIlg934keG5g8ElOpH-zcmIZUD9DQgUpK2putIXGCji7qfyHDjY0sn-Eo4Woj4iqyuZdj505Mxm962qQNoHQgahXoivQelb8VuBR1wlWtoggnuPqbHiNy3wl2FlK4Bw-EaRObP/s1600/PhoenixDown.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="153" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhIlg934keG5g8ElOpH-zcmIZUD9DQgUpK2putIXGCji7qfyHDjY0sn-Eo4Woj4iqyuZdj505Mxm962qQNoHQgahXoivQelb8VuBR1wlWtoggnuPqbHiNy3wl2FlK4Bw-EaRObP/s200/PhoenixDown.jpg" width="200" /></a><br />
<div style="margin-bottom: 0in;">It’s not just a Bethesda thing, either. If you’ve played any Final Fantasy to completion in the past 15 years, you may have ended the game with Hi-Potions or Phoenix Downs maxed out. Even though some of those games are fairly linear, they’re filled with dozens of little dead-ends where you’ll find these loot items. They may be inconsequential in the grand scheme of things, but that doesn’t matter. What matters is the minor joy of finding them.</div><div style="margin-bottom: 0in;"><br />
</div>Let’s take a step back and look at this problem of empty space on the global scale. Read reviews or forums of any big, Open world game, and a common theme will come up again and again: the game feels vast for the sake of being vast. “This is a walking simulator. There’s no reason for this game to have such a big world if it’s empty.” I believe there’s only one way to overcome this hurdle, and that’s by paying attention to your POI density.</div><div class="MsoNormal" style="line-height: normal;"></div><ul><li><span class="Apple-style-span" style="font-size: large;">POI Density</span></li>
</ul><br />
<div class="MsoNormal" style="line-height: normal;"><div style="margin-bottom: 0in;">POI density, simply put, is the notion that if we choose a point in the world at random, we have an expectation of the number and variety of Points of Interest in the general vicinity of the player. I can’t give you a perfect formula for POI density, but I can give some basic ideas on how to determine and use it.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">First, figure out what POIs your game should have. They can be tiny campsites, outdoor ruins, dungeons to explore, whole cities and towns, or non-physical things like randomized, roving encounters. </div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Next, decide how long each type of POI should take to create. One good level designer may knock out a half dozen minor landmarks in a day, whereas a fully-fledged town could take multiple people the span of a project to implement.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">From this point, you should be able to develop an idea of your desired POI density. This will be influenced by many factors, such as draw distance, travel options, visual blockers in the world, and tone.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Imagine a hypothetical area of your game. Let’s say we’ve decided that a square quarter mile is a good feel for the immediate area surrounding the player in your game. Now begin to theoretically populate that area with the correct number and variety of POIs to achieve your desired POI density. We can think of this as a sort of “Vertical Chunk” of the game. By reconciling those chosen POIs and the time it takes to build them (and the world they occupy) we can theorize how long that Vertical Chunk would take to build.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">This is the part that none of us are doing when we approach our Open Worlds. Most games have a relatively known timeframe in which to be built. With our vertical chunk estimate, we can extrapolate to figure out how much world we can build in the time we have for development. Yet most Open World games begin with a fixed world size, and the teams are simply doing their best to fill them up with fun. It’s a trap we fell into with Fallout 3.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">One of the first and most valuable pieces of documentation we had for Fallout 3 was a map of the Capital Wasteland. This was an invaluable planning tool. This got everyone on the same page about the general size of the map, what locations needed to be built, and gave us a rough idea of quest flow; it provided a foundation for almost every decision made at the high level.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">Fast forward nearly two years. We’re in alpha, and for the first time, we’re meeting Fallout 3. Up until this point, the game has been a collection of assets, tasks, code and lots of teamwork. The game is beginning to feel complete as everything comes together. We realized, however, that wandering the wasteland didn’t feel right. Something was off about that experience. What we realized was that the world felt pushed together. We simply had too much stuff, too close together.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">This is because we were using the same POI density that had served us well for Oblivion. There’s no secret playbook at Bethesda that tells us what to do. We simply learn from what we’ve done before. POI density wasn’t something we really had a name for back then.<br />
<br />
</div></div><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDSvq1wgKLBjM7crFhhnAyihl3rp2dmdIoU3CGknJapfzxrSnNF0oZ9979k2fJs7Gh6JSpt_xCvOuHWZFyPsssZnWwBxcmrRNHJsjdDFosxzfobTIXE0Qoo5RdJeHdP3jTBjHa/s1600/F3worldMapExpansionDiagram.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDSvq1wgKLBjM7crFhhnAyihl3rp2dmdIoU3CGknJapfzxrSnNF0oZ9979k2fJs7Gh6JSpt_xCvOuHWZFyPsssZnWwBxcmrRNHJsjdDFosxzfobTIXE0Qoo5RdJeHdP3jTBjHa/s320/F3worldMapExpansionDiagram.jpg" width="320" /></a></div><div class="MsoNormal" style="line-height: normal;"><div style="margin-bottom: 0in;">The trouble was that Oblivion and Fallout 3 are very different games. The sightlines in Fallout 3 are much larger, and you don’t have the major visual blockers of Oblivion’s forests and hilly terrain. Aside from all that, it’s a game where you’re supposed to occasionally feel lonely, and we weren’t achieving the tone we wanted.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">So we made a decision. We could have pared back, but we decided to add a significant amount of new area to the North and West ends of the map. Remember that we were in alpha, and a lot of this work was supposed to be done. If you’re a producer, you should be squirming in your seat right now. This took our entire environment art and level design teams offline for the better part of two months. It was a painful decision, but we felt it was the best option to make the game what we wanted it to be.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">The core lesson here is that you need to respond to your game as its being developed. Our process is deeply iterative, but at the end of the cycle we put a stamp on it and ship. The player will never see any iteration but the state in which the game is at ship. We might update a game through patches or DLC, but nothing on the scale of what I’ve just described. We think of our world as the main character of the game, and like the player it can be a fickle, evolving creature that we don’t always understand.</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">And that’s another important relationship the player has. Players who talk about an Open World game they care about tend to have strong, almost emotional ties to the location where the game takes place. There’s a real emotional resonance there, like I mentioned with myself and Far Cry 2 earlier. You just like being there. Being there has become its own, far-reaching goal. Powerful stuff, really</div><div style="margin-bottom: 0in;"><br />
</div><div style="margin-bottom: 0in;">And we're a part of that as designers. By seeding the world with well-made locations, and thinking seriously about their distribution, the player enjoys a consistent, entertaining pace of activity and interest in the world. The world should feel at once believable, but more exciting than the mundane world. This is a place where adventures big and small are likely to happen; where you can trust that you’ll be entertained at some level. You aren’t stepping into the streets of your home town – you’re going somewhere more. Someplace that has spoken to you in a deep, compelling way that, as the player – even as the designer – you may not always understand.</div></div><br />
</div></div>Joelhttp://www.blogger.com/profile/09816332769743524346noreply@blogger.com3tag:blogger.com,1999:blog-30579660.post-68724189931966784092011-03-02T10:40:00.002-05:002018-10-27T07:15:48.499-04:00GDC Slides: Motivating Players in Open Games<a href="http://www.joelburgess.com/GDC2011Crowd03.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="150" src="http://www.joelburgess.com/GDC2011Crowd03.jpg" width="200" /></a>GDC has been an amazing time so far, and the main conference hasn't even started yet. I've hardly had time to sleep so far, but I did want to get my slides posted online for anybody who wanted them.<br />
<br />
<a href="http://www.joelburgess.com/GDC2011Crowd02.jpg" imageanchor="1" style="clear: right; display: inline !important; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="150" src="http://www.joelburgess.com/GDC2011Crowd02.jpg" width="200" /></a>Here they are on slideshare: <a href="http://www.slideshare.net/JoelBurgess/gdc2011-motivating-players-in-open-worlds">"I Want To Go To There: Motivating Players in Open Games"</a><br />
<br />
I should caveat, however, that my slides aren't going to be very useful except as a reminder for folks who were at the talk and are looking for a rough refresher. I was able to avoid using too much text on my slides and don't really use speaker notes, so for most it will just be a bunch of loosely connected images. Audio will be released on the <a href="http://www.gdcvault.com/">GDC Vault</a>, though, and I did write out a rough transcript of the talk on the plane ride into San Francisco Sunday, so I may clean that text up <i>(it's around 6,000 words and I didn't get through the whole talk!)</i> and post it here for more general use.<br />
<br />
<a href="http://www.joelburgess.com/GDC2011Crowd01.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="150" src="http://www.joelburgess.com/GDC2011Crowd01.jpg" width="200" /></a>I also had a cutting-room floor talk about non-linear level design that I hastily composed from a portion of the talk that we didnt' have time for. I'm still deciding what to do with that, though. It's obviously much less polished than what I presented on Monday.<br />
<br />
Thanks again to everybody who attended, all who asked questions and anybody who<a href="http://twitter.com/#!/search/%23LDinaDay"> #LDinaDay hash tag</a> to sound off during the day. It was a ton of fun for us, and I hope you enjoyed it too!Joelhttp://www.blogger.com/profile/09816332769743524346noreply@blogger.com2tag:blogger.com,1999:blog-30579660.post-39870582350364783452010-03-16T19:22:00.010-04:002018-10-27T07:15:48.441-04:00GDC Slides: Level Designer, StorytellerI was hesitant to release my slides as-is, but I decided to go ahead and make them available. I'm not sure how much use they are by themselves, but they should at least be handy as a refresher for folks who were able to attend. Speaking of those who were able to attend, here's where every one of them was awesome and went along with my prodding to do the wave before the talk began:<br />
<div><br />
<object height="300" width="400"><param name="allowfullscreen" value="true"><param name="allowscriptaccess" value="always"><param name="movie" value="http://vimeo.com/moogaloop.swf?clip_id=10220628&server=vimeo.com&show_title=1&show_byline=0&show_portrait=0&color=ffffff&fullscreen=1"><embed src="http://vimeo.com/moogaloop.swf?clip_id=10220628&server=vimeo.com&show_title=1&show_byline=0&show_portrait=0&color=ffffff&fullscreen=1" type="application/x-shockwave-flash" allowfullscreen="true" allowscriptaccess="always" height="300" width="400"></embed></object><br />
<br />
<a name='more'></a><br />
</div><div>We actually had such a great turnout that GDC didn't have space for group tables, so I had to cut my exercises. Instead, the wave was a last-minute idea to get people off their feet at the end of the day, since I was sort of relying upon the exercises to keep everyone engaged for an hour. Thanks to this cut, I ended up showing a video example of some LD storytelling techniques in Fallout 3, which I had removed from earlier versions of the talk.</div><div><object height="250" width="400"><param name="allowfullscreen" value="true"><param name="allowscriptaccess" value="always"><param name="movie" value="http://vimeo.com/moogaloop.swf?clip_id=10220498&server=vimeo.com&show_title=1&show_byline=0&show_portrait=0&color=ffffff&fullscreen=1"><embed src="http://vimeo.com/moogaloop.swf?clip_id=10220498&server=vimeo.com&show_title=1&show_byline=0&show_portrait=0&color=ffffff&fullscreen=1" type="application/x-shockwave-flash" allowfullscreen="true" allowscriptaccess="always" height="250" width="400"></embed></object><br />
Thanks again to everyone who came out! The Level Design sessions were a huge success, and I hope everyone enjoyed attending as much as we did putting them together. Who knows, maybe we'll be back next year! <a href="http://joelburgess.com/GDC_LDstorytelling_Public.pptx"> Here's the file for your downloading pleasure.</a><br />
</div><div>P.S. - If anybody knows a good way to embed a powerpoint with slide animations intact, let me know! Lots of my slides are unreadable without these, and I'd like for folks without Office 2007 to be able to benefit from them, too.</div>Joelhttp://www.blogger.com/profile/09816332769743524346noreply@blogger.com5