For the eighth consecutive year, the Level Design Workshop will be hosted by GDC on Tuesday, Feb 28. Once again, we've assembled an exciting, diverse lineup of rockstar speakers from all walks of game development life.
A smiling @pabosher looks on. This photo is actually from the 2016 narrative summit, but I can personally assure you Philippe looks just as cheerful when attending the LD Workshops.
Whatever kind of games you make, level design is the lens through which players are most directly exposed to the underlying rhythms of your creation. And as the medium of video games has become increasingly broad and diverse, the techniques and ideas that go into level design have also broadened.
With that in mind, let’s introduce the roster of speakers for the 2017 LD Workshop, after which they’ll bat around some questions submitted by the LD community via social media.
- Joel B
Matt shares lessons and insights from his process in designing the 300+ interconnected levels for mountain-scaling platformer Celeste, his team's follow-up to TowerFall Ascension. It's a bit of a scattershot of topics, including inspirations from real-life rock climbing, designing for speedrunners, structuring rewards, and teaching players implicitly with level design. Celeste is still in development and this talk goes behind the scenes on the processes and problems we've faced since setting out to create a modern, unique, and memorable 2D platformer.
A Narrative Approach to Level Design details just that - approaching level design from the perspective of the story that the designer aims to tell with their level. This talk will give a glimpse into some of the design techniques that I've developed while designing on Telltale Games' narrative-focused adventure games, as well as on Ubisoft's upcoming RPG title South Park: The Fractured But Whole, presented in a way that can be applied to many different genres of games.
On South Park, all of our levels are derived from story scripts not unlike those used on the South Park show. It’s our designers' challenge to take these scripts and make them into enjoyable interactive experiences. I'll explain how we distill these scripts down to their core narrative elements, and use those elements as the backbone for our levels. We'll also apply this technique to an example script to drive home how to apply these techniques to any story.
Hi there - my talk, “An Approach to Holistic Level Design”, is about always thinking in terms of how gameplay, presentation and story is working together. It'll draw from my experience as an LD on games including 'Dishonored 2' and 'Bioshock Infinite', and the core design values of the genre known as immersive sims (as well as throwing a bit of Half Life 2 in there for good measure).
The topics I discuss emerge directly from the relationships between the output of different disciplines - namely "affordances", "intentionality", world building and my personal take on interactive storytelling, in the context of these kinds of games. My hope is that LDs of all types and experience levels can come away with clearer ideas about how to focus not just on gameplay, but the player experience as a whole - and how to make it richer and more engaging..
Greetings! I am a designer of many years, both in AAA and indie. My talk will cover my transition from doing level design in large 3D action games (Resistance 3, Sunset Overdrive) to a 2D overhead game (Hyper Light Drifter). When I first started on the project I was nervous as to whether my level design skills would translate formats, so I will talk about my fears of what wouldn’t carry over, and then the many processes and principles that did carry over. My goal is to show that even specific and specialized design skills are still quite transferable.
What is a “video game mixtape” and how can I use this format to tell stories in new ways? I don’t know if these are the questions that keep you up at night, but they are for me. In my talk we’ll go over how to create a good flow by mixing and matching a variety of simple game experiences. When the player goes through them in a specific (or out of) order, their minds start to make up their own narrative. See how we play with those expectations with examples from my debut, autobiographical video game mixtape FRKN WKND and with a couple of other recent mixtape games I’ve made.
My conference topic will focus on the design process we use to build an immersive and consistent exploration experience in the game's main City hub of Prague.
I'll describe how we started sketching our high levels needs and ideas regarding the general exploration navigation around the city, and how we could entice the player into constantly discovering new locations of interest, offering both interesting challenges and satisfying rewards.
I'll also describe our approach to creating compelling mini stories through analysing the greater Cyberpunk genre as well as our own particular conspiracy driven, deep and brutal main narrative, in order to breathe life into the "ordinary with a twist" citizens of Prague, who all contribute to making the game world consistent, meaningful and relatable.
Last year I gave a talk at GDC about how to improve your tools & level editors. It was well received, and many commented how they liked the solutions, but one question kept coming up: How do you make all these improvements without hiring 10 more tool programmers? And that is a fair question.
Over the last year since GDC 2016 I have gone around the game industry asking experienced developers from AAA companies around the world: What do you do to make sure the right features get worked on? How do you triage the hundreds if not thousands of requests into what you will and will not improve on in your tools & level editor?
In this talk I am going to go over the many production methods and approaches game developers around the world have used, and are using, to make sure time is correctly spent on improving tools & level editors, so you can see what methods have been tried, and what you could do for your studio to improve your tools through improved triage.
What are the real differences when going about designing a singleplayer level vs a multiplayer level? How do you tackle layouts with different objectives, narratives, and combat needs that differ between SP and MP? There's a paradigm shift of thought that occurs when swapping between designing between SP and MP and I'll be drawing from my own experiences in designing narrative-driven SP levels along with my transition to designing MP levels. This talk will tackle the differences and similarities when swapping between designing for each, lessons learned about what you shouldn't waste as much time on, and how to go about planning playtests of SP vs MP levels.
(Robin-Yann Storm) I personally love designing around a mechanic or setpiece. Introducing a mechanic, playing with it on a micro level, and then swinging it in and out on a macro level can work well. A good video on that subject is this: https://www.youtube.com/watch?v=dBmIkEvEBtA.
(Lisa Brown) Yeah, having some kind of centerpiece mechanic can help link spaces together in the player’s mind in a non-visual way. For example, having a series of rooms based on some kind of trap or hazard that ramp up over time. I think it’s important to have pacing in mind both within the level, but also how that fits in the overall pacing arc of the game. For example, if you playtest a level and it feels kind of slow, but it happens right after BIG ACTION EXPLOSIONS LEVEL, you have to keep in mind its context in the overall pacing when you make adjustments.
(Jolie Menzel) Since I’m often working from the narrative space, I’m often coming from a macro perspective and working inward. I start by analyzing what I need the level to do from a story perspective and a gameplay perspective, looking for any moments where a player need to learn how to do something. Those things form a skeleton of critical beats. From there, I add in supplemental beats that will augment those critical beats and help to nail the overall feeling that I need the level to capture.
(Clemence Maurer) In a game like Deus Ex, that needs to support many types of players and proposes quite a big array of tools, we usually start from a defined, high level story beat and start working on our layout immediately, thinking mostly about how we can make something that can support stealth (multi-path, occlusion, verticality, vantage points…) and combat (cover, escape, flanking, open vs tighter spaces…). Our level needs to support every pillar, including the narrative driven ones such as branching conversations with “persuade” gameplay opportunities, so we spend more time designing it directly in the engine instead of spending too much time on 2D drawing for example. That way we immediately get a sense of scale and gameplay potential, easier to iterate upon. When we’re happy with the base layout we work inwards, making the level architecturally “alright” with our artists and defining the micro gameplay :what augmentation(s) would be need to get through that area? How do we convey this need in the environment? How do we spread them out to support a maximum of players with a heterogenous loadout?
(Matt Thorson) For Celeste we’re making the game holistically, which is a fancy-sounding word for figuring it out as we go. We have a lot of story, but we’re developing it alongside the gameplay for each area and we change both to fit each other. So sometimes our conception of an area’s story arc and pacing will change based on some cool levels we make, or a great story moment idea. Sometimes we’ll realize that a great level moment just doesn’t fit in the context of the area. We’re always zooming in and out from level to area to full game perspectives to re-evaluate our work, and a lot gets cut or repurposed.
(Aquma) For video game mixtapes, the focus is on the micro. I just build simple gameplay experiences/levels that percolate in my head over a period of time. After I make enough of them, I start looking at how to piece them together in a way that conveys are general story and vibe. The macro. The process is very iterative and not like passive media where you plan it all out in advance.
(RYS) You can use so many things: Lights, audio, geometry, etc, but playtesting is the biggest one for me. Build it, let players play it without telling them anything, and then see if they understood it clearly enough, by seeing them play and asking them.
(JM) Something I think is a really important to develop a sense for is allowing players some wiggle room in their interpretation of the narrative. It’s of course of utmost importance to make sure that the player is interpreting a narrative as you intend them to if that narrative is driving their goal. However, if they’re interpreting some world or character lore in their own way, as long as that doesn’t subvert the goals, it's a good thing. It prompts discussions among your players and will let them feel ownership of their personal interpretation. Inside is a recent example of a game that does this really well, where goals are clear but story is up for discussion. Braid is another that comes to mind.
(Steve) I second Robin on the crucial importance of playtesting as a fundamental part of your process - it’s really the only way you could know whether things are working as intended. Don’t be afraid to playtest early, and once you start, try to keep it regular, if you can. Try to do what you can to make the playtests representative of how players would actually play the game (e.g. don’t interfere unless it’s really necessary), and whether you’re in the room watching, watching remotely and / or recording them, ask them to vocalise their thoughts as they play.
Finally, when it comes to asking them questions, I find that one of the most useful things to ask about is what their intentions are at various parts of the playthrough. More than “was this fun or not”, a question like “what were you trying to do here, and why?” can reveal a lot about their intuitive understanding of gameplay goals and narrative engagement, in sometimes surprising ways.
(CM) Playtesting if great but it’s a double edge sword if designers are not confident in their own designs. What I mean by that is that it’s easy to “over-interpret” bad signals sent by some playtesters and take dramatic actions so that this one player who got stuck in a level, will never get stuck anywhere anymore. I’ve seen this type of reasoning a lot of times and although I think it was essentially caused by an inadequate playtest management, it was also due to a certain uncontrollable will to...control the experience.
This urge to control can be what you want depending on the type of game you play, but in other games where emphasis is put on exploration and / or multi-approaches layout, it’s really alright if people just don’t see everything and don’t experience the level like you would have liked them to. And instead of changing and cutting as soon as a playtester has a problem, you need to wonder if there really is an actual issue or if it’s just a part of your design that maybe some people with struggle with a little bit more that others. And that’s ok. In big companies it can get harder to keep trusting the design and succumb to panic, which can be dangerous because it risks compromising what makes your mechanics interesting and organics. It can also ruin the mood of a level because now suddenly we have lights and sparkling enticers everywhere we want you to see something ! I see that too much these days.
(Beth) The others already touched on much of it, especially in terms of *how* to verify objectives + narrative beats are being communicated well while you run playtests of your level. One thing I would note is that although you can try to subtly guide/manipulate players towards looking at their next objective, combat options, a narrative scene, etc, it is very difficult to guarantee anything. Thus, taking advantage of the few moments you know exactly where the player will be + what their camera view will be staring at is critical. Examples: when players go through a door frame, exit/enter a staircase or an elevator, exit a building, etc. Make sure you take advantage of those moments to make sure the environment frames critical gameplay or narrative elements.
In addition, sidekicks and secondary characters are a great active way to draw attention to critical elements. For example, on Bioshock: Infinite we scripted a lot of dynamic moments where Elizabeth would gaze, point, run over to, or stand by certain elements that we wanted to draw the player’s attention to. Psychologically, people are much more drawn to movement, especially when the movement is attached to a person. People will instinctively look at whatever another person is gazing or pointing at.
(Aquma) I believe the key is to ask, “what is my experience goal for the player?” From there, every question about theme, environmental story telling, even gameplay, is checked against this north star. If you follow it, play test, and iterate a lot you’ll get there.
For gameplay goals, I emphasize play and exploration and try to distill the gameplay down to those essential elements. I assume the player knows nothing and design around that. This way, even if they’re just poking around, the player can figure it out and enjoy the experience for what it is.
(RYS) My personal preferred way is to not choose, and instead randomly combine them, play them, and find out what works. A shotgun approach, of sorts.
(JM) I use the “shotgun approach” Robin described as well while in a brainstorming mode. In addition, it’s important to consider if you’ve taught the player that they can combine certain mechanics. I’ve been in situations where there may be synergy between two mechanics, but didn’t have bandwidth in the game to teach the player how to utilize this synergy in a satisfactory manner. It may have felt like a clever combo of mechanics to me, but that’s no good if the player can’t figure out what to do and feel clever themselves!
(RYS) I really dig it when players find their own style to play a level, so long as the chosen style for the level still fits and has an audience.
(LB) It sort of depends on the game, but I do like trying to provide many options to approach, say, a combat setup (especially if your game already gives players a number of tools, for example many weapons).
(JM) My precious level must be experienced exactly how I want it to be! No exceptions! Personal style be damned!
I’m not sure if that sarcasm came across in text, but, it's definitely a good idea to analyse different kinds of play styles. It's great to bring in folks with those styles to test as much as you can. A good way to analyze a level played in a specific style is to think, “in what ways am I telling this kind of player ‘No’?”. For instance, an open-world player is going to always be bumping into your invisible walls, i.e being told “No, you cannot run off into the forest”. Depending on your game, this may be an acceptable limitation (maybe the player going off track will distract from the story/goal), or it may be something you want to rectify (you want the player to feel lost and are ok with them coming back to their goal later).
(Steve) Regarding adjusting to “expected” playstyles, one question that might be worth asking is, why is this expected? Is it because of the genre the game seems to belong to, or because of specific expectations that this game or level has established on its own?
I’d say that supporting different playstyles is generally a good thing, so long as they are in-line with the tone and style of the game. If players feel inclined to play in a way that is out of tone with what you intend, then it might not be a matter of whether you support it or not, but more about what you can do to iterate on whatever aspects of the game / level might be giving the player those motivations and expectations.
(if you can support a range of playstyles, definitely do it. If at some point you are obliged to block a path or “force” the player to do something that might go against a certain playstyle, it needs to be as justified and coherent as possible, narratively as well as environmentally. You really want to avoid giving the illusion that people can play however they want, just to throw in some cutsene and forcing them to, for example, slaughter anyone in the room when you’ve always tried to avoid conflict before. Example : the last of us. It killed the experience for me.
(Beth) I agree with Steve, I would much rather design a space that supports multiple different play styles than limit players by forcing them into only playing a certain way. Although it is important to have a clear understanding of the most common play styles for the type of game you’re making, it is very limiting (and boring!) to only design a map for that one specific play style. This is especially relevant in multiplayer level design, where a level should support numerous different play styles and also serves as a way to define roles/split up teams throughout the map in multiplayer. Defining appealing areas for a specific play style can also be a tool, especially in MP, to draw players to a certain location or provide intentional combat choke points.
(Aquma) Hmm…that sounds like a lot of work! I like puzzles, but don’t want to get too wrapped up in making them. So for video game mixtapes, I try to make the core puzzle mechanic and core puzzle relatively simple. That way, when the player would normally expect a ramp-up in difficulty or complexity, we just end that part of the game and move on to something new. Maybe a vignette later in the mix will revisit that puzzle with a twist, but it’s still more of a throw back than a “sub mechanic.”
(RYS) I think it depends on where you want to work, and on what. Some companies want level designers to model, others just want them to whitebox, but scripting/programming is useful for anyone in the game industry.
And: Quality over quantity. Show the good stuff, get the interview, then talk about all the other minor skills you may have that can help.
(LB) Also if you have a specific type of game or studio that you’d like to ultimately work on, keep that in mind when you choose what to focus on in your portfolio. Remember that your portfolio is a tool that hiring devs can use to determine if your skillset is applicable to their needs.
(JM) Robin and Lisa’s points are all spot-on. Research the studio that you’re applying to: I don’t mean just browse their Wikipedia page, I mean look for who works there and find talks they’ve given or articles they’ve written about game development. Short of talking to someone who works at the company directly, this is your best window into a process that has been used at that studio that you should be ready to prove that you can be integrated into.
(Steve) Regarding the levels of scripting, programming and 3d modelling skills required to get LD jobs, it definitely does depend on what kind of team and project you’d be applying for. For example, I don’t really have any hard 3D modelling skills, and it has never been a part of my job as an LD, working mostly on first-person games in big teams, where I would collaborate with environment artists / architects. Programming has also never been a requirement of my job, due to the use of visual scripting systems like Kismet / Blueprint in the Unreal Engine - but this can vary.
For your portfolio I would always focus on LD specific work (i.e. not building entire games, etc), making levels for kinds of games you’d be interested in working on, and keeping the scope small enough that you finish things with time to iterate towards high quality.
(Beth) For a portfolio, I would use whatever tools you are familiar with + can easily create content with to make levels. It is also an added bonus to think about the companies you want to apply for and specifically create levels in software similar (or exactly) to what they use. Personally, I’m a proponent of Unreal.
In terms of the scripting/programming or 3D modeling skills, as others mentioned it is highly dependent on both the size of the team and what kind of project you’re working on. It also depends on whether you’ll be working on designing levels for a singleplayer game or multiplayer. When I’ve worked on multiplayer levels, I focus almost exclusively on layout and flow. However, when I’ve worked on singleplayer levels, I’ve also scripted combat + minor narrative scenes as well as incorporating more environmental art skillsets (not 3D modeling). I would suggest understanding basic programming/scripting logic (even if you can’t write it) as at the very least you’ll often need to slightly modify existing scripts. And any artistic background (especially architecture, cinematography, etc) will definitely help you stand out and make much more intentionally designed levels in your portfolio. For example: if you created a level for your portfolio that’s just box shapes, that’s okay. But it would stand out and communicate your vision much better if you’ve already thought about the definition of the boxes/cover shapes and what the level environment is, in addition to utilizing artistic aesthetic to guide and direct players intentionally.
At the end of the day, a level designer’s focus is on the player experience and making sure players are guided and relevant information is communicated to them. Level design is the glue that flows in between everything and holds it all together. So if you have other skills that slightly bleed into other disciplines, it is highly valuable as you can help get more stuff done!
(Aquma) Learn some basics with a game engine and make a ton of little complete experiences based on what you know how to do. Go for quantity first. But always challenge yourself to add something new to each game piece you make. If you’re intentional about completing them and improving, the quality will come and you won’t have anything to fear having just made a ton of shitty games/levels. Pick your best work and you’ve got a portfolio!
If you don’t have the patience for that, just find a tool (whether it’s an in-game level editor or something pre-made) that has the shortest learning curve and make a bunch of levels with that. Play test with your friends, and improve your designs based on how you see them play.
Hey there, Joel again. Thanks to all the speakers for sharing. Hopefully you enjoyed this little teaser and mini-roundtable.
Next week, in addition to their full presentations, we’ll also be hosting a portfolio review during the lunch hour on Tuesday. If you’d like to get direct feedback from our panel of devs, be sure to bring your work on a thumb drive, laptop, or tablet. (Try not to rely on wifi - it can be pretty spotty!)
In San Francisco, but not able to join us at the Workshop itself? Meet up with speakers and attendees for a happy hour right after the show (~6-7pm) at the Bin 55 lobby bar of the Courtyard Marriot, just around the corner.
That’s it for now. We hope to see you on February 28th at GDC - come say hello! Keep an eye out for the organizers, too - Claire Hosking, Nels Anderson, and myself! If you can’t be there, you can follow along online with the #LDWorkshop hashtag on twitter.