Opinion: The perception of interactivity

[In this reprinted #altdevblogaday opinion piece, Sumo Digital senior designer Alex Moore looks at how content-driven games are made, tying his analysis into the uproar over Mass Effect 3's ending.] The conclusion of the Mass Effect trilogy has spawned a great deal of chatter on forums and news sites alike, based initially on the online petition requesting extra endings and the growing responses from Bioware and others alike. Kyle's post here covers one perspective, and with this post I aim to cover something slightly different one. It is not directly about Mass Effect, but instead about how content-driven games are made. Understanding It seems to me, from the way the petition is worded, that despite investing hundreds of hours in the trilogy, many gamers don't understand the logistics involved in creating a video game. It could be argued that they shouldn't need to – we watch films without knowing all the intricacies involved in getting the image and sound to the screen, so why should gamers need to know about the blood, sweat and tears that go into making games? While some films do spark huge reactions toward the director from fans, those fans often find other outlets for their reaction, with alternative endings turning up on Youtube or comic strips or even novels. There are rarely the tools made available for alternative endings to be made for video games, which in turn leads to fans putting pressure on developers. Funding issues aside, there's a big reason why a game driven by content cannot have infinite endings: it's simply not possible to create and test that much content. To expand on that statement, the way the Mass Effect trilogy melds the experience to the player's actions puts a phenomenal sense of power and creation into their hands, and this naturally gives the impression that the game is crafted specifically to them. Unfortunately, it's not. Exhibit A To give an example of how a content-driven game is designed, I'm going to have a quick look at Dragon's Lair. If you haven't played it, the premise is very simple: a beautiful animation plays out and, at a pre-defined point, something happens which the player needs to react to with a button press. This is a video of the full game being played all the way through. The playthrough doesn't show many of the player deaths because the player knows what they're doing. But behind the smooth flowing animation is a system that's waiting for a player input. If the player misses the window of opportunity, the game branches and the player dies. If they hit the window, they progress. Different companies refer to these as different things – nodes, branches, gates. They're effectively all the same and, for this post, I'll stick with the latter. This example is the simplest gate required to create player choice. Each and every sequence has been hand crafted, and the game planned out in intimate detail. To design Dragon's Lair and sketch out the flow, it probably took a few weeks, though actually creating the content took seven months and 1 million dollars (source). That was in 1983, so in today's money that's a lot more. And all this for a game that can be completed in just over 10 minutes, as shown in the above video. Testing As well as creating the content and code, it all needs to be tested. Test plans come later down the development line, when the framework of the game and the main mechanics are close to being locked. Once that happens, it's possible to create a list of tests and expected results. From here the test team can do regular checks to ensure the game is behaving as intended. A test plan for the the diagram above might look something like this: One sequence with a single gate therefore might lead to eight tests. Possibly even more. For now, though, that's enough to highlight why testing is one of the most difficult parts of making games. It stands to reason therefore that in a game more complicated than Dragon's Lair there's going to be far more possible outcomes. At any one point the player could have done one of a hundred things, let alone the thousands of small inputs they've made to get to where they are. If a bug surfaces, the developer then needs to find a way to recreate it so that they can understand what's going wrong and then, hopefully, fix it. I should note at this point that something like a shooting mechanic is very different from gated content, because that's a system that has a set of defined rules. When the player does certain things (such as presses the fire button), the rules determine what happens, not the content. So the test plan doesn't have to account for pressing the fire button at every possible position the player can get themselves into. The sort of gates I'm describing here really only come into play at big story points, such as the 'choose route' type option presented to the player in Gears of War for instance. Scaling up Now we know the level of detail required for a single gate, we should now look at how we cope with multiple gates. In Mass Effect, each conversation often has a few possible outcomes, especially when they're with key characters. The interaction required by the player is very different from the reaction-heavy animation window system employed by Dragon's Lair, but the underlying system is very similar: Suddenly we're facing a bit of a crisis – one conversation with three possible outcomes, each with just two more attached to them has led to six unique paths. And the game design wants over a hundred conversations… There's no real way that we can create that many unique gates. So, instead, we create paths that feed back into themselves further down the line: You'll notice that by using this system it's entirely possible that the player won't have to go through every gate to get to the end – in fact it's desirably to do this to try and encourage replays. Choke Points You can keep even more control over the number of possible outcomes by creating larger, single, gates that the player has to go through to complete the game, but where they're free to choose whatever route they desire in between: The orange boxes in this case are choke points. With a game like Mass Effect, there are multiple choke points, but the entire game is constructed of so many that the player doesn't have to go through every one to get to the end of the game. In fact, there's very purposefully a great deal of routes through the game. But every single route has been planned, designed and has had content created for it. This type of design method isn't just limited to stories, but can be used for level design or ability trees too. A good example of a game that uses this method for all of these systems is BioShock. Several levels give you objectives that you must complete to ultimately move forward, but you can do those objectives in whatever order you desire. Equally the story feels to develop around you, the player. It's up to you whether or not you delve deeper into the myth and seek out the audio diaries, and of course there's the choice of how to deal with the little sisters. Layered on top of that are you abilities and upgrades, all at your choice. It works really well, all the way up until the point where you meet Ryan. At that point, all players must go through a single choke point with only one outcome. Thus their choice is removed. My protest with BioShock was simply to stop playing – I still have no idea how it actually ends. Mass Effect 3 has obviously created a similar reaction, though a much stronger one than my silent protest. Throughout the trilogy, players have been making what they believed were unique decisions, and the games responded accordingly. The achievement by Bioware is staggering, and from an external perspective very inspirational. Logistically, though, there could never be enough endings to satisfy every possible outcome, and hopefully this post has gone some way to showing why not. Disclaimer: I don't work for EA or Bioware, and wasn't involved in the creation of Mass Effect at any point. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]