Trending
Opinion: How will Project 2025 impact game developers?
The Heritage Foundation's manifesto for the possible next administration could do great harm to many, including large portions of the game development community.
The Portal designer shares lessons she's learned over her career -- the importance of playtesting, a collaborative, democratic development environment, and how basic human psychology can be exploited by game design, as applied to new game Quantum Conundrum.
Kim Swift made her name in the games industry with her first game. Portal became an instant classic, and launched her career. After working on the Left 4 Dead series, she left Valve and joined Airtight Games. Her first project for the Washington-based developer is downloadable title Quantum Conundrum. She's the creative director of the game, which will be published this summer by Square Enix on PC, Xbox Live Arcade, and PlayStation Network.
Of course, as a first person physics puzzler, it'll inevitably draw comparisons to Portal. "I took what I learned from Portal, and am trying to apply similar practices of things that I feel worked, for sure," Swift tells Gamasutra. "It's like, learning good lessons and then immediately throwing it out the window, because like, 'Oh no, I'm copying this other thing'? And it was just like, why?"
In this interview, she outlines precisely what she has learned: the importance of playtesting, a collaborative, democratic development environment, and how basic human psychology can be exploited by game design.
You use techniques from painting or other media in your level design.
KS: Just general artistic compositional design.
Is that something that came out of Valve, or is it something that came out of your personal experience? Because I know Valve is also very big on pointing people in the right direction or leading with art.
KS: It was a little bit of both. I had had an artistic background before I actually went to DigiPen, and so applying all of those principles made a lot of sense to me. A lot of it is just generally human psychology of how we actually are wired to look at things, and how we actually perceive things, as human beings.
So a real basic one is we are hardwired to detect movement. So if there is movement in something, our eyes just go straight to it. And so the fastest way to attract a player is movement.
And just in general, the artistic compositional basics just apply pretty much one to one, in terms of design, because it's all about manipulating the player to get them to look at something.
Players are going to want to go towards the light, as opposed to the dark. That's hardwired into us as human beings, because we don't want to get eaten by the bad thing in the dark, and so we're going to go where it's light out and we can see. And so just taking advantage of the fact that we're animals, basically (laughs) and manipulating that, kind of behind the scenes, to get players to go where you want them to. It's actually kind of a fun game to play.
It's like a meta-game for you?
KS: Kind of, yeah. Level design is like this in general. I mean, it's a meta-game for us as designers, to take a look at a space, and we as a designer have a particular mentality of how it's supposed to be solved, what we want the players to look at, what do we want, where do we want them to go.
And so in that way, it is a game for us to see if we have manipulated you the way we wanted to -- which sounds horrible (laughs) but it's so true. A good level, a player will go exactly where we want them to, and look at the exact things we want them to, and pick up the right things without them even knowing that we had set it up deliberately that way.
You use the word "solved". Your games are about finding solutions for the most part, especially the games you have the deepest involvement with, right? So you really have to do that.
KS: Yes. It's leading the player without making them feel like they're led, because you don't want to just hit them over the head with the solution -- because that's just like talking down to somebody.
But at the same time, you want to be able to steer them in the correct path, so that way, they're not just sitting there thrashing, trying to figure out where to go or what to do. And so it's a balance, for sure. You want to add as many environment hints as possible while at the same time not making it stupidly obvious.
If we talk about it analytically -- which we should be -- when we sit down to a game, we're there to be manipulated by the creators, right?
KS: It's a little bit of both. I think it's about, yeah, you're playing into the world the designer made for you, but at the same time you're also creating your own story within this world, as well, just by your actions. So once again, I think good games have a really good balance of this. That yeah, you're doing what the designer sort of told you to, but at the same time it has enough of a space where you feel like you're really, actually making your own choices, and you're making your own decisions, and impacting this world. So yeah, it's a give-and-take.
And how much of the game takes place on the screen, and how much of it takes place inside the player's brain?
KS: I would say it takes place more in the player's brain than it actually does on the screen, because people's interpretations of what actually happened are wildly different from everybody else. Like using Portal as a for instance, hearing one person's take on what the story of Portal versus somebody else's take can be extremely different -- versus what we actually had in mind. And I think that's a good thing. I think players should impress themselves onto the game world, and I think it makes it more immersive, and makes it more fun, and I know I do that.
Like in a kind of stupid way, when I play games, I'll make up little stories for just anything. It's almost the game of making up background stories for people you see on the street. You know what I mean? And so I do that for myself when I play games, just because I find it much more enriching, and I feel much more involved in the world. And like I've been playing both through Skyrim and Arkham City, and I find myself doing that all the time.
Do you feel that there's a need, or an impetus, towards putting ambiguity in games? Leaving spaces for the player to interpret?
KS: I think that's a good thing. I know I personally try to do that. I like leaving clues for a possible story, or a possible interpretation, but I want players to come up with their own impressions of the world, I think. I think it makes it much more personal.
Do you think that's just satisfying the player, in other words? Is that your main motivation?
KS: It satisfies the player, and I also just think it's interesting. I think it's the part of what makes games really unique as a medium -- that interactivity, and being able to kind of tell your own story by your actions and interpretations. Because books and movies don't do that. Books have a very clear story that it's telling you. Same with movies -- it's from one point of view, that of the director. And what's cool about games is you are the director, and I like that. I love that about this industry.
People will, as you said, bring themselves to games. And not only will they interpret what they see, but they will also subvert whatever they can, a lot of the time, through their own play and experimentation. Do you like to leave room for that as well?
KS: Oh, yeah. Yeah. It's why I like making physics games, because it pretty much has that built in. Players are going to try to beat a particular area the way they want to, and they're going to go where they want to, and I think that's interesting.
Do you think systems like physics that are procedural, or not dictated by something like scripting -- are they important to games, to allow this kind of interplay?
KS: Once again I think it's a balance. It's a give-and-take, right? So you need those scripted instances. For instance, if you are really trying to teach a player something and you need, need, need to have them look at something, have them experience something, have them pay attention. I think in that aspect, it's really important. But at the same time, it's good to give room, to have the player do what they want to when you can.
And so a lot of that comes down to playtesting, and watching players play, and making sure that they're learning the correct things that they need to. And kind of being hands-off as much as possible, but when needed, putting in that heavy hand to make sure that they look at something at the right time. Whether it be locking them in a room, or taking away camera control, or something like that. If they're not going to learn something, and be miserable for the next two hours, that's bad. That's bad design.
How do you know when you can, and how much you can, do that? The "heavy hand", as you put it.
KS: Testing. It all comes back to testing. You watch players play, and if they're doing what you want them to, then you've done a good job as a designer. You've manipulated them in the correct way. But if multiple people are experiencing the same confusion, not knowing what to do, then it's us.
It's our jobs to go in and add maybe a little hint here. And then test it again, run it through a bunch of people seeing if the same problem crops up again. If it still does, then add a little bit more, and a little bit more, and keep iterating and testing. And that's how our whole game was designed, essentially. It's just like... yeah, you have an idea of what you want, but you won't really know if that idea is successful until you actually test it.
Would you say you've done a similar kind of testing as you did with Portal?
KS: Yeah. Basically we run through somebody hasn't played before at the end of the week, and play them through new puzzles that we haven't seen playtested before, and see what worked and what didn't. And then immediately going back in and iterating on top of what we've learned.
How long is the cycle on this game?
KS: We're clocking in a little under a year. And we have a team of 16 people... No, we're 17 now. We're 17 now. And yeah, just, small team, small budget, small amount of time.
Do you like keeping it small and fast? Is that what appeals to you most?
KS: I like everything. I don't know. I don't have a particular preference, but in the case of [Quantum Conundrum] this is a new IP. It's good to test the market to see if this type of game is still viable, and if people want to play. So I think in this way it's a good way of hedging our bets. It's like, okay, we know that we can do this in under a year, put it out there, and see how it resonates. And whether or not you go big, stay the same, don't do anything at all... Who knows? So we're crossing our fingers that it'll do well.
The thing is that you hit much bigger with your first commercial project than you probably could have ever anticipated. Not even necessarily commercial success, which of course is one thing, but also it became the inescapable part of the gamer lexicon for the next more than a year. Everything from Still Alive, "the cake is a lie", the Companion Cube -- everything. A lot of people on Earth could, I'm sure, but I certainly couldn't have a conversation without some of that stuff coming up on a daily basis.
KS: Yeah, and I guess, from my perspective, I took what I learned from Portal, and am trying to apply similar practices of things that I feel worked, for sure. It's like, learning good lessons and then immediately throwing it out the window, because like, "Oh no, I'm copying this other thing"? And it was just like, why?
At the end of the day, I want to make products that people have a good time with. If players are having fun, then I've done my job, and I try to not get weighed down with the idea that I have to compete with myself. It just seems silly. I'm making games. It's not like I'm making like the cure for cancer or something. Like, I cured breast cancer, now I'm curing prostate cancer, right? It's a game. It's meant to be fun, and for players to have that moment of escape, and time out, in their lives -- to have a good time. And so I just take that for what it is.
This game is lighthearted, at least from what I've seen. Is that important to you, too? I know Left 4 Dead wasn't lighthearted, but I don't know how much oversight you had into the creative direction. How do you feel about that kind of thing? Because, obviously, so many games are so grim.
KS: I guess, for me, I wanted to do something different. I miss the days when it was okay to have a stylized game, and it wasn't immediately branded as, "Oh, this is a kids' game." No! What happened to the '90s? There were cartoony games, and it was okay! And so I miss that.
As well as, I think it fits the gameplay. I mean, there's a fluffy dimension! Can you really picture that in a realistic style setting that's grim? It's like, yeah... not so much. And we did do some iterations at the very beginning, trying to play around with different looks and feels for the game, and this is what we all ended on as a team, and really liked it.
What comes first -- the fluffy dimension, or the cartoon look and feel?
KS: Dimensions came first. So for me, my principle is gameplay should always come first, because, at the end of the day, it's a game, and it's all about that interactivity with this world. And so I don't care how awesome the art looks. If it doesn't play well and it's not fun, then, meh.
Yeah, we definitely prototyped it right off the bat -- and it was not a pretty looking game -- and got the dimensions, a couple of them, up and running right away, and started playing with them, and seeing if there was potential.
You say you got a few dimensions going, prototyped those, and then just looked and said, "this concept." Were you working with multiple concepts or was this the idea that was gestating?
KS: So when I first got together with my team, we were going to decide to do a project like this. We actually had a pitch process where anybody that wanted to submit a game idea could. And so we took a look at everybody's different projects. Everybody got to do a one sheet and talk about it. And at the end of the day, we voted on which ones that we wanted to do, based on the ability to quickly prototype and test the ability for it to be fun. And this had, at the base core, the simplest systems in order to prototype very quickly.
So within like a couple of weeks, we actually had an extremely rough prototype, obviously with no art or anything, but a fluffy dimension, and reverse gravity, and slow motion. And we were just playing around with the different permutations of them, and realized pretty much right away this had potential, this was a lot of fun to play with these different interactions, and just kept iterating and polishing.
What did you use to prototype originally?
KS: We are UE3, so we prototyped on UE3, and are still on UE3.
Have you ever used any other tools or any other methods? Have you always been direct to engine, and are you most comfortable with UE3?
KS: I've done both. I mean, I was at Valve, so I did Source Engine there, and so I actually had to relearn how to use all the editors and scripting and whatnot, so it was actually difficult for me! But easy for everybody else, because everyone else on the team was used to UE3.
I think if your team is capable to go straight to engine, it's nice to be able to test it out in the software that you're going to end up using. But obviously that doesn't work for everybody. So it's about finding what works best for your team.
Did you end up codifying or documenting at any point? It sounds like you went really straight to prototyping off of the pitch process.
KS: I have pictures of whiteboards. We have a game design document that I did at the very beginning of the project, but it hasn't seen much love since then. We're more of a rapid iteration-style team, so I have pictures of whiteboards -- actually, on my phone -- just kind of detailing out particular brainstorming sessions, or level design sessions. And we go kind of off of that. So we'll have a quick meeting, and we'll all get together in front of a whiteboard, and start drawing stuff out, and then go back to our desks and start building.
How did you recruit the people that you have? Was it all people that were already at the studio when you joined?
KS: Yeah. So it was all people at the studio that were interested in working on something different, and we ended up doing some prototypes on an initial game first, that I can't really talk about. But after that, we rolled onto this project, and started working on it right off the bat.
When it comes to using the human psyche, is that something you've done more research into as you've leveled up your design toolset? Or is it stuff that you knew from like your previous studies, as with art, for example?
KS: I think a lot of it was stuff that I kind of knew already. I wasn't exactly the popular kid in school growing up, so I found myself really observing people, and watching how they interact, and how they react to things. Also, watching an obscene amount of nature programs as a kid, as well, actually helped a lot.
I think this is kind of interesting: So at Valve -- I think this was for Half-Life 2, and I could be totally wrong -- they actually brought in an animal psychologist in to have her take a look at the game, and figure out if there was anything that they were missing in terms of cueing the player into doing something. So it's like yeah, we're smart monkeys, but base core, we're animals. And so we're having particular reactions to a stimulus that an animal might.
Do you think it's important, or beneficial, at least, to work with people in disciplines that are just totally outside of the games industry, and bring that kind of stuff in?
KS: I think so. It's interesting to get perspectives on things that you don't have. It's the same reason why I run a more democratic team, because yeah, I can make a decision, but I would like to have multiple disciplines looking at the same problem, because they might have a more efficient way of solving a problem than I would, or an artist would, or a programmer would. So I think having different disciplines taking a look at games to see if there's anything that we might be missing is definitely informative.
How has it been moving from a studio that can publish its own games to a studio that has to work with a publisher? Has that impacted your life?
KS: Honestly our partnership with Square has been amazing. So Mike Fischer is the CEO of Square Enix USA, and he's an awesome guy. And he was very clear with the team straight on -- that he trusts us as game designers, and he wants to give us the freedom to make the game that we want to make. And they've been really hands-off, in terms of letting us do what we need to do, give criticism that is positive, and actually really helpful for us, and at the same time just being incredibly supportive.
And super nice, actually. Like we'll have a deadline coming up, and we'll get emails from the people on our Square team being really excited for the next drop of Quantum Conundrum so they can play new puzzles, because they're addicted to playing. And so hearing that feedback from a publisher has been great because... I don't know. Working at Valve, I'd heard horror stories, and so far my experience has been really positive.
To talk about how they are addicted to playing the game, that made me think -- what is it about solving puzzles? If we were going to talk about psychology... Because I know, from playing Portal and Portal 2, and other games that have puzzles, you do get this indescribable positive feeling.
KS: You get a really good endorphin rush from the satisfaction of feeling smart. Like, "I had this problem and I am going to solve it." And I think that's almost with everything. You have a problem in front of you, and if you can solve it, and figure it out, it just makes you feel really smart, and really clever. After people play our game, I want them to feel clever.
How do you achieve that? Is it just by making clever puzzles?
KS: I think good puzzles, combined with -- once again, going back to playtesting! But playtesting, making sure that players are not getting overly frustrated, bashing their head against a problem without seeing the solution. Ideally, you want a player to come into a room, take a look, and within 30 seconds to a minute, know what they have to do, and then it's a matter of executing on it.
That's an interesting point, because that gap, sometimes, in games -- between "I think I know how to solve this" and "I actually can get the pieces into place" -- that can be a really frustrating place to be in, if the game has certain deficiencies in control, or readability. Or sometimes you have the wrong idea. Sometimes you have the right idea, but you just can't get the pieces into place.
KS: Playtesting, there were definitely instances for us as designers that were frustrating, because the player would actually figure out the correct solution, but there would be a bug or something like that that would punish them for that correct solution, so they would try to do the right thing but they would get punished.
And then realizing them thinking, "Oh, well this isn't the solution, so let me go try something else," and then reaching that thrashing point. And then them going back and saying like, "Oh, that was my initial idea in the first place, but I got punished for this one thing." So yeah, playtesting. It's something that you wouldn't catch otherwise; making sure those moments don't happen. Like where we are accidentally giving negative reinforcement for the right thing to do.
You were talking earlier about how the aesthetics are secondary to the gameplay, but you're bringing in things: you are bringing in some characters, you're bringing in arc. Do you have to build to that arc? How do you do that?
KS: I think it's all about having a rough outline to start with, and having flexibility in terms of what it will end up being at the very end, because sound and art and story should all be supporting the fun of the gameplay. And if it's getting in the way of the gameplay, then it's not doing its job properly. Art, or story, or sound should not be a hindrance to the game. It should just make for a more complete, better, immersive, fun experience.
If you had a discipline, are you a level designer? First of all, what's your stated role? But what is your real passion?
KS: I am a creative director, and I would say it fits me pretty well, because I am a little ADD. I like to do a little bit of everything, and I have a background in programming, and I have a background in art as well as design. And I like doing -- and for this game I actually did -- most of the writing. And so I like being able to do a little bit of everything, and I think, more than anything else, I like contributing to the project.
Even though, yeah, I'm in charge, quote unquote, of the project, I want to be able to point at things and say "I made that," or "I wrote that," or having an actual involvement in the game. Not only because it's satisfying to see something that you made come to life, but it keeps you realistic and grounded about everybody -- like your expectations about everybody else.
You know, not making unrealistic choices. Not knowing that it might cost the programmer 48 hours nonstop worth of work to be able to get that feature in. And just being grounded, and knowing what it actually takes to make a game, and put together a product, I think, is really important.
Do you think that's a specific skill? Having that vision of what actually is essential to this, to get it out the door?
KS: I think so, and as a creative director, making sure that everybody else is on the same page, and they're all seeing the same picture in their head. And getting people excited about working on the project. And like I said, we're a very democratic team, and so if someone has an awesome suggestion, I don't care if it came from me or not. Is it going to make the game better? Is it going to make the game more fun? Then do it.
And so like, level design, for instance: most of the people on our team have contributed a level to our game, and so it's not just one person doing all the design, it's lots of people. And I think it makes for a really fun and interesting design process, as well as product.
How do you balance people making levels? People have ideas. You also have a schedule. You also have this need to test things. It's a real balancing act.
KS: It is, but at the same time, using the testing as a driving goal. For instance, if you do want a level, you need to have it done soon enough that it can get through a few playtesting iterations, and so that becomes a driving factor for you to get it done.
At the same time, we're all in the same giant room, so talking to one another and having open communication about what we're all working on, and potential blocking factors. Like, I am working on something, but somebody is waiting for me to finish it so they can do their job. And just making sure that the communication lines are open, so we don't run into times where people are getting stuck waiting for somebody else. So yeah, more than anything else it's just about communication.
Do you really let people have autonomy on the team? I know you talk about democracy, but democracy and autonomy are kind of separate.
KS: Yeah. People work on what they want to work on. So, portraits in the game; you walk through and see different pictures on the wall... Scott and Chris, our two concept artists, they got to paint pretty much whatever they wanted. We would drop in suggestions every once in a while, and it was like, "Oh hey, could you do a painting of this?" So we actually have a painting of one of our teammate's dogs in the game, because he wanted a picture of his dog in the game. And we were like, "All right. That works."
So to me it's like, "Okay." It comes down to, what's the risk versus the reward for doing a particular anything? Whether it's a design concept, a piece of art, a piece of programming, will it take a long time for you to do? Will it block anything else that we already had planned? And can we test it as soon as possible? And if it works out, then it works out. If it doesn't, then -- because we are all communicating and doing the playtesting, too -- we can see when things are not working. Then we know, "Okay, it has to go," and we can basically extract emotion from the equation when making those decisions.
Read more about:
FeaturesYou May Also Like