This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Something you talked about in the presentation was that you built systems of gameplay that interacted in certain ways to allow for emergent gameplay but then, as you saw different strategies emerge, you sort of tweaked the design to take advantage of some of the scenarios you saw emerging.
It's a big question, but how does that work? Do you just let people run into the world, see what they can actually do, and then build design scenarios based on that? Or do you have an idea of the scenarios and the powers and how they're going to interact? It sounds like you were taken by surprise by some of those things. How much do you want to start deliberately designing toward the things that emerge that you see happening as you test the game?
RC: The way we do it is we work by layers, first of all. It's a very, very vague question because, at the end of the day, it's the heart of the nature of our game. It comes from some approaches at every level. It's true for the mechanics; it's true for the level design itself, and therefore the mission design; it's true for the architecture.
So, if we talk about the level design/architecture/mission design, we come up with a little story, and an objective, whatever the objective is -- reach this place or kill that guy. "Eliminate that guy" would be more accurate, because there are multiple ways to do it.
Then, we design the environment around it. We have a rough idea of the main path that we have in mind, and this main path might be based some of the powers that we have -- some of the mechanics. We know that there might be a double jump; we know that there's a blink [teleport]; we know that the player might have the tools to possess a rat and therefore go this way or that way.
That is the first draft, and then we let it organically evolve a little bit. We let the architects do their stuff, and they add some alternate paths. Of course, because nothing is scripted so much, we put the AI in there, and all the systems are simulated, so they interact with each other; they cross each other.
We let it live for awhile, and then we see naturally some stuff emerging. Even ourselves, before it goes to the players, in fact, the devs in-house will start finding some way to do things -- which are shortcuts, which are more fun. Then, if it's a problem, we fix it. If it's, in fact, something that we think has potential, then we encourage it and expand on it. Etcetera, etcetera, etcetera.
Then come the real testers, and they might find their own other stuff. Then we add some more mechanics later in the process, and not only this new mechanic offers new possibilities, but new bugs. At this point, you keep doing this; this is why it takes so long to make the game. Even though each level designer doesn't have that many areas to work on, they work on them for a long time -- for a long time -- and maintain them in every aspect.
So it's a highly iterative process, and you have to keep yourselves open to it; that seems to be the core of the actual way you approach the design of the game.
HS: Like Raf said, it's a vast question, and we could talk all day about it. Some percentage of those things, if you mess around with rules systems -- I don't know if you've ever tried to design a card game or anything like that, but as soon as you start tweaking rules, it's just like economics are law. This rule interacts with that rule to produce a second-order consequence that can be very damaging, or it can be very cool.
Sometimes they just go into the game with no problem, like "Hey, we had this and we have that other thing, and they interact in a way that we never thought of, and we like it!" Like double jump and, at the apex of the jump, using the blink, is a great example. We had to consider suddenly, "Well, the player does have longer distances that he can go," but we really didn't have to do anything to support that; it just worked.
Other things, somebody tried it, and it didn't quite work because the technology or the scripting just didn't let it, or whatever. We said, "People are going to think about that, and it does seem logical. We should actually make that work."
Today, we had an example where a guy stopped time at and some incendiary arrows were coming towards him, and he had the idea of plucking the arrows out of the air and using them as ammo, because he has no incendiary bolts for the crossbow. We wanted this to work; like a year and a half ago, we talked about this, snatch a bullet out of the air. It does work in most cases, but there was one ammo type where it did not; the reason are just because of the ways that those were technically implemented.
Of course we want to be consistent, and we want to say yes to the player. If the player is playing that way, creatively -- just ignore the fiction for a second. Ignore the setting and the characters and all of that. Just imagine you're in an abstract environment. I don't know if you've ever played a tower defense game called Neo Defense, but it's deliberately abstract, almost like the Tron universe.
If you just think about the world in that way, this guy has this tool to stop the simulation for a moment and some of the projectiles that are going to harm him are hanging in the air, and maybe he can go over and grab those. On the map, it creates a different strategic point: there's the point to take cover; there's the point to reach up and attack your enemy; and now there's the point over there to move over and grab this additional ammo resource out of the air. The player's using this creativity and creating his own gameplay; that is, by far, what Raf and I care about, I think, more than anything -- that sense of agency and expression.