Opinion: Unlocking our potential

[In this reprinted #altdevblogaday opinion piece, Sumo Digital's Alex Moore examines why the cost of creating AAA games has sky-rocketed, and possible ways to make content creation faster and cheaper.] In my last article, I looked at how content-driven games are made, concluding that any sense of control over the story is, ultimately, an illusion. With this article, I aim to open the door and look beyond our current limitations and ask instead: is it possible to make a content-driven game that isn't constrained by its creator, but instead crafted by the player? (Mini warning: this post turned from a simple idea to a fairly epic 2500 words. Get a cuppa and a chocolate biscuit before attempting to read.) To answer that, we need to look at what the current constrains actually are. There are lots of small issues, but they nearly all fall into one of two categories: cost or artistic desire. Cost It's a sad fact, but the cost of making AAA games has sky-rocketed. On average, on the original PlayStation, a team of about 10 people could make a 6$0 game in about a year. For the PS2, that went up to more like 30 – 50 people for two years. For this generation of console, there is no average – it's as many people as you can get for as long as you can get. 100 people taking three years is fairly normal, but it's also common for teams made up of many more. If the price of games reflected the increased man-year development time, they'd now cost about $1800 each. Why? As a very broad stroke: all those pretty images take a lot of developing. The quality of the art in games is far higher than ever before, and the code bases that drive everything are far larger and complex than we ever imagined they'd be. The biggest single factor slowing us down, and thus costing us money, is our tools and pipelines. Turnaround for an idea has slowed to an almost archaic crawl because of the time it takes to create content in a AAA game right now. The knock on of this is that it has a detrimental effect on the quality of the games we are making, and people don't want to pay $60 a pop anymore, let alone $1800. There are two ways of fixing this: as an industry, we need to invest in finding a different approach to creating content or we need to develop better tools. Or, preferably, both. Different approaches to creating content Once upon a time, coders creating everything in the game. Art was a means to an end. Nowadays we have teams of artists sat at desks across the globe, all beavering away on the small details. That nice crumbly wall in Uncharted 3 probably had three different artists working on it: one for the basic collision mesh, one for the render mesh, and one creating the texture and normal map in the first place. Throw in a lighting artist or two, and a particle effects guy to make the nice clouds of dust when it gets shot. Oh, and a guy to make the impact sound effects. Let alone the coders required to make all these systems work together. Back in 1993, a roleplaying game called Dungeon Hack came out. It wasn't unique by any stretch, but I mention it partly because of how movement systems used to work. The dungeon, as with most games of the time, existed on a grid. Each move you took moved you to the adjacent square, assuming there wasn't a wall there The world was rendered in first-person, but you had no freedom to look around at anything other than 90 degrees, and move one square at a time. (Completely unrelated to me writing this article, Legend of Grimrock, which uses this movement system in a modern game, has just been released.) From a top-down view, a dungeon looked a bit like this: The main reason I mention Dungeon Hack is because of how the dungeons were actually created. If you look again at the image above, you'll see that it's possible to create the layout by using just four files, rotated into position: By using a pre-defined set of tiles and an algorithm running a randomly generated number to lay them out, a unique dungeon was created every time you started a new game. Rules then layered on top to place items and enemies. In theory, there were limitless combinations and once the system for creating the content was up and running new levels could be generated almost instantly. If user control was desired, an editor allowed players to make their own layout. Tile based generation still exists in games like Civilization, but it has proved very difficult to create modern 3D games with such a system, partly because of the demands on artistic quality and partly because of the desire for unique locations to visit. Prefabs Prefabs are a more modern way of generating content, and in essence work in a similar way to tiles, except they are stand-alone units rather than part of an interconnected network. Humans are very good at spotting repetition though, which reduces the effectiveness of using this system. Houses fairly quickly get spotted as clones, and players tend to lose interest in discovering new places if they think they've already seen everything there is to offer. Procedural generation This is based heavily on maths and simple data structures. The best example of what can be achieved with this method is still the demo scene. As with the randomly generated dungeons, there is a set of rules controlling the overall scope of the images here. Similar methods can easily create large-scale environments. There are limitations, though, the main one being creating areas that flow well into one another. On their own then, none of these approaches really gives us the flexibility or quality that we desire. But by combining the three methods into a toolset, we could help open up new ways of creating large-scale content, rather than just relying on adding more artists into the equation. Character creation Every story needs characters, and in this regard there are already tools that allow us to create a lot of unique models quickly. I've used this video before because it's a great example of what can be created given the right motivation and time. We can also do very similar for animations: with a base set, we can quickly add variety by using additive animations, such as a limp, or letting physics code take control. The tools are the game Another way is to give players the ability to create content themselves. Creating levels for Doom was the reason I got into designing video games in the first place. More recently Minecraft created a game that was, initially, a tool where players could create their own content. There's a huge demand for this type of game, where the editor is effectively the game: FarmVille and DrawSomething are other examples. They are very different types of game from the Mass Effects of the world, but it feels like there should be a way of learning from their methodologies to enable us to improve our content driven games too. Clint Hocking has already done a very in-depth series of posts on convergence like this, and in far more detail than I am here. In his eight-part series he suggests that other gamers could provide the context for the story, a sentiment that I agree with but relies on playing online. EVE Online does this to a degree and some of the stories of conspiracy that come out of it are great reads. There's a flaw with this method though: even with relatively small player numbers (compared to World of Warcraft), each player feels like a very small fish in a very large pond. Your influence on world events is minimal. The reason people like playing the hero is because of the feeling of power and fantasy it gives them, and single-player games give you this ability. So, we can no doubt create worlds and characters much faster than we currently do, but that doesn't solve the main issue I'm trying to tackle with this post: is there a way to create a story this way? Story as a mechanic Glance back up the page at the diagram of the dungeon for a moment. There's another way of showing its layout, and that is to instead show each square that requires a change in direction as a node, and the route through as connections: If you read my previous article on content this should look familiar: this is, more or less, how we currently move through stories in content-driven games. In games today, we take freedom of movement for granted: if we want to go and spend time looking at a blade of grass, we can. This is because movement systems have developed from the very simple set of rules Dungeon Hack et al had, to a complex mechanic. An almighty array of things are happening in the background to grant you that freedom of movement, from how to respond to the amount you've moved the analog sticks through to how the scene behind that broken window renders. Can we take the same steps with story? Can we create sets of rules that allow the player to drive the available story events at their will? Possibly even the freedom to create their own stories? It's not going to be easy, and it's not going to happen overnight, but I think we can. How? Firstly, take the steps required to make content creation faster and cheaper. Then we need to understand what a story actually is. It's well documented that all stories fall into one of seven types, which seems like a good place to start:

(source: http://lenwilson.us/seven-stories/) The story outlines that most single player games use falls into ether Overcoming the Monster or The Quest which is something else that we ideally will address as the medium matures. Aside from that, though, these seven rules of thumb give us a great basis for the forming of a mechanic. How so? Well, a mechanic is really just a set of rules, and each of these seven categories has a very definable goal for each story category. This means that we can create a fairly simple set of IF statements to set the story goal based on the category chosen. Whether that category is chosen by the player or randomly doesn't matter. Of course, a good story requires much more than that: it also requires structure. Typically these are defined into sections called Acts. Act 1 introduces the audience to the characters and scenario, Act 2 fleshes everything out, and Act 3 has the conclusion. More rules, which means we can add another layer of complexity to our mechanic. The numbers of main characters, their traits and motivations: all these can be defined to some level either by the player or with weighted random selections (which is where you guarantee at least one of type X and so on). Would a story generated in this fashion be any good? Well… probably not. The missing touch is, of course, humanity. This, then, is where the player really comes in: their decisions and actions influence the actions and motivations of the computer-controlled characters alongside them. The game would adapt on the fly, so if the player decides to be friends with the bad guy for instance, a new enemy or threat would have to emerge. But the player could have the freedom to influence the story as they move through it. The thing we still can't do very well is to create dialogue: both in the writing of it and in the audible generation of it. Computer generated voices still sound horribly robotic, and that instantly ruins any sense of immersion or belief. (Unless, of course, you're doing a game about robots.) There's another problem as well, which is the second of the issues I mentioned at the start of this article. Artistic Desire This is the biggest problem really: what story do we want to tell? As shown above, the general structure of a good story is always the same, and Act 3 is the conclusion. Without closure you don't really have a story in the sense that literature and film define them. As humans, we like telling stories, we like crafting them, and we like the warm feeling inside that we get when we, the hero, reaches the end. Unless, instead, we turn our game into something more akin to a soap opera. They have moments of closure as story arcs come to an end, but the world in which those arcs exists continues to persist and expand. Can we do the same with a game? Do we want to? [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.]