Critical Missive

A World Without Reckoning

2012-02-08T01:41:00.001-05:00

I've had a copy of Kingdoms of Amalur: Reckoning in my hands for the last few days. The years-in-the-making project by Big Huge Games and 38 Studios, which went through both an IP switch and a name change over the course of its tumultuous development, has finally seen the light of day. As an open-world RPG, it's been positioned by Electronic Arts' marketing team as, more or less, a competitor to The Elder Scrolls V: Skyrim - though four months on, it's perhaps telling that Bethesda's title is still such fierce competition.

While I've enjoyed my time with Reckoning, the game is one of the strangest that I've played in a long time. While it does a lot of things right - fast and fluid combat, a deep and engaging progression system (at least next to most other contemporary RPGs), and a massive world to explore, there's also something decidedly vacant about the Faelands. As a game that draws much of its inspiration from MMORPGs, Reckoning serves as a case in point that bigger is not always better when it comes even to open-world games.

All World, No Content

The world of Reckoning is massive, even by modern open world standards. Though perhaps some players roll their eyes at the prospect of yet another sandbox experience, it's hard not to be impressed by just how much terrain is featured in Reckoning. That large game world is divided up into approximately 30 discrete zones; save for a few city areas and the interior levels (dungeons and buildings), all of them are sprawling, lush and gorgeous plains, forests and deserts that capture a certain limitlessness that few games do. Opening the world map and pulling back the camera can be an equally impressive experience, as well.

This illusion of size is slowly diminished the longer the game goes on - not due to growing familiarity with the world or a recognition that it just isn't quite as big as it looks, but instead, due to the general lack of actual content populating it. The towns and cities that players visit are soon revealed to only have two or three quests to complete, each of them providing about 5-30 minutes of gameplay (which is often just running from points A to B); moreover, once you've completed a task in a given location, it's time to move on to the next, never to return - in most cases, literally.

As imposing as the world of Amalur is, it's striking just how little of consequence actually exists within it.

While I can't say specifically how many locations Amalur has, it's got to number in the hundreds. Most towns have around three or four buildings to be explored (some of them more or less empty, others full of NPCs to talk to, shops and services, etc.), there's usually two dungeons in every wilderness zone (almost always quest-related), and when one takes into account the number of zones in total, it's clear that there is a ton of ground to cover. However, on a per-location basis, the amount of time spent is extremely low. Many of those buildings will be visited for about 10 seconds before players move on. Towns and cities only take a few minutes to see the entirety of. Unless one's goal is to inspect ever single nook and cranny of the world, these vast spaces will be exhausted of gameplay in a matter of minutes, not hours.

While I don't like to draw comparisons that are too direct, there are many other RPGs on the market that make far better use of their game worlds. Fallout 2, despite having about 20 major locations (each of them quite small to traverse), can potentially squeeze eighty hours out of a play-through based on sheer gameplay content alone - sure, you're not seeing a new area every few minutes, but that's not a big fault when there's always a new quest to embark on or character to talk to. After the fan backlash against Dragon Age II's content reuse last year, it's fair that developers should be afraid of offering "too little" to players, but the flip-side of that is a huge game world that just doesn't have enough to sustain itself. The fact is that Amalur's world could have easily been half its size, the filler trimmed away and the quests given greater focus, and it would have gained from it.

The Single-Player MMORPG

Aside from the sheer size of the world, Reckoning also does some curious things regarding the structure of that world - namely, it draws very heavy inspiration from MMORPGs. As mentioned above, the world is broke up into distinct zones, connected by convenient canyons and passes that are probably serve both technical and gameplay functions. The player's progress across the map is more or less west-to-east, with things opening up a little bit more at the midgame point as the player's objectives expand.

For gameplay purposes, MMOs typically split their worlds up into discrete zones. Not only does this make things easier for the developers to handle, but it also provides a level of certainty and structure for players that helps both understanding of the game world and the game balance. Zones can usually be classified as belonging to a particular level range, defined by the monsters and quests that exist in it - 1-5 is a starter zone, for instance, while a level 80 zone is for the players who have more or less reached the top of the food chain. Within each zone, there's usually a quest hub, such as a town or camp, which provides the player's tasks as long as he/she stays in that location, and provides essential services (healing, repairs, etc.).

Due to the sprawling nature of MMOs, and the fact that they offer more content than just about any player could ever hope to see without repeat play-throughs, there's almost never a reason to stay in a zone once it's been out-leveled, as the rewards for completing those old quests are likely to be outstripped by the ones in the new areas - and let's face it, chances are nobody's hunting down Smoked Rat Tails for the sake of the engaging narrative. It's a simple but effective method of compartmentalizing gameplay that works within a multiplayer setting, where the sheer amount of space is needed to house so many players.

The player spends almost all the game in Planescape: Torment's Sigil, which serves to deepen the player's understanding of and emotional bond to the location and its characters.

Most traditional single-player RPGs do follow a similar quest hub structure, but instead of running off to the next hub once one has been exhausted, instead players are asked to gradually familiarize themselves with the game world. This has a number of benefits and reasonings behind it:

Reuses existing game locations for more efficiency in content creation. Why make a new location when you can use the same one multiple times?
Helps build an emotional bond to the setting and characters, as the player will spend more time in the same places over the course of the game.
Gives a sense of consequence, as the world can be depicted to change based on the player's actions.
Objectives can span the world rather than just individual locations, and tasks as a result can often cover the length and breadth of a game - most RPGs have at least a few long-term quests.

Most lacking from Reckoning, I think, is that sense of emotional attachment. At one point in the game, the player is given the option of destroying the town of Canneroc, a small silk-harvesting village in the middle of a spider-infested wood. In a more traditional RPG, the decision to destroy this town would not be something taken lightly: chances are the player would have spent some time there, got to know its residents, its place in the world, been given some sort of investment into its well-being, etc. However, in Reckoning, it's just another quest hub to move on from, and whether it continues to exist or not has no impact on the game as a whole. What could have been an interesting moral decision is cheapened significantly by the lack of gameplay repercussions and the structure of the game itself.

I think it's very strange that Reckoning subscribes to this MMO-style world design. As a single-player game driven largely by its quests, story and exploration factor, there's very little reason for players not to want to complete every bit of content (at least in theory). Even if a zone's enemies are cannon fodder, or the loot is no good, players want to be able to tick those quests off one by one. By segregating the game world in this manner, there's a fundamental conflict of interest between the world design and the motivations of players in navigating it.

Too... Much... Loot!

I'll be the first to admit that I love loot in RPGs. Whether it's got random modifiers or you've just got a ton of unique items to experiment with, chances are loot drops are going to keep me occupied - and I'm not nearly as dedicated as some players out there. In giving players a large number of inviting zones to explore as one of their selling points, however, Big Huge Games put themselves into a bit of a bind - exactly how to justify all that space?

Much as I pointed out in my analysis of RAGE last week, the answer is loot. Lots of it. There are standard junk items, uncommon items, rare items, unique items and set items, items with sockets, crafting items... just about anything you can think of that's an RPG standard has found its way into Reckoning, albeit with a lot of the useless stuff stripped away (no more hoarding pots and pans, sadly). Chests, in their many whimsical permutations, dot the landscape as if they were plants, and masses of alchemical reagents fill the space in-between those chests. You can scarcely walk more than 30 or so paces without running into something to loot, whether that's a fungal pod or a Brownie's backside.

Unfortunately, this extreme emphasis on the loot factor also reveals a major issue: that aside from plundering chests, there really isn't all that much to do in Reckoning's huge world. There's plenty of stuff to find, yes, but 99% of it will be sold off as vendor trash. As if the developers already realized this problem, the ability to send items straight to the junk bag for immediate selling or destruction has been placed on just about every inventory-related UI element. If so much of this stuff is junk, even to crafters (who will likely only use a handful of pieces before finding gear they like), then it begs the question: why is there so much of it? The only answer, of course, is: to give players something to do.

The loot in Kingdoms of Amalur is so prevalent that the mechanism it follows is not unlike that of a quick-time event - cheap and easy, but empty and meaningless at once.

A lot of anger has been directed towards quick-time events, and perhaps rightly so. While they do have their advantages, a common over-reliance on them in order to produce effectively non-interactive sequences of gameplay can leave players feeling less involved, or even bored as they watch games rather than play them. I propose, however, that the looting that's done in Amalur isn't all that far off. After all, it still follows the exact same feedback loop of no-skill input resulting in disproportionately rewarding output... well, in Reckoning, that Awesome Button has a new name: Take All.

When provided as a reward for players after a tough battle, for completing a quest, or for exploring a far-off corner of the world, loot can be a fantastic way of motivating players and cultivating a feeling of accomplishment. To be frank, however, press button -> get reward is not a particularly engaging game mechanic, and placing a treasure chest around every corner, paradoxically, only cheapens the value of what should be one of the game's major selling points. Despite there being kilometers of game to explore, the loot system only emphasizes just how empty that space really is.

Closing Thoughts

For what it's worth, I do want to stress - Kingdoms of Amalur: Reckoning is a very fun game, beautiful, and has some excellent game mechanics. However, as much as I want to like it, the sheer size of the game has a number of pitfalls to it. The world, being as massive as it is, is necessarily empty and devoid of unique, interesting content, and the movement through the game from one zone to the next only serves to reinforce just how fleeting and inconsequential that unique content actually is.

Reckoning is more or less the prototype for an upcoming MMORPG, so it does make sense that the game follows at least some MMORPG-style design tenets. At the same time, it's also very clear that what works for an MMO simply does not work well for a single-player game. A story-driven experience demands that players are emotionally engaged with the game, and in focusing everything about the game world on the player, from movement through it to the transitory nature of the quests and objectives, it's harder to care about the larger picture.

Interestingly, I think one of the game's biggest failings isn't so much its size, but its portrayal of size. In trying to portray multiple nations and kingdoms, and even different continents, it inevitably falls victim to its own necessary abstraction. A game like Skyrim works because it is centered around a single province, and we are more ready to accept the compromises in scale needed to keep the game a reasonable size. Amalur tries to convince players that its cities of twenty are some of the most bustling, important places in the world, and under such strain, the illusion shatters.

In short: Kingdoms of Amalur would have been an excellent 40-hour game. Instead, it's merely a good 100+ hour one.

RAGE and the Circular Design Dilemma

2012-02-02T02:18:00.000-05:00

RAGE is a game I really wanted to love. From the get-go, it offered up an astonishingly beautiful, hand-crafted world and some of the best straight-up arcade-style shooting that I've played in years. On top of that, its advancements in artificial intelligence and animation produced a lot of interesting encounters and enemies who fought with a degree of unpredictability and spontaneity that is rarely seen in games. In many ways, it's a triumph and a fantastic experience.

As accomplished as the regular gameplay was in RAGE, however, the longer I played, the more there was something about it that seemed to get to me. It was extremely hard for me to pin down - here I was playing a beautiful, original and fantastically-produced shooter, something that I've felt we've had a bit of a glut the last few years beyond a few stand-out hits. And yet, there was something about it that kept nagging at me throughout the entire experience, right up until the end.

After a good deal of thought, I realized what it came down to wasn't anything about the core action and the gameplay, but rather, everything that surrounded it. RAGE is a game where the very mechanics and structure of the game exist not necessarily because they're fun, or because they make sense, but solely because they depend upon and reinforce each other. It's what I've taken to calling the circular design dilemma, and it's at the core of what makes RAGE feel less like a complete game and more a collection of smaller ones.

It Starts With Loot

The first thing that started to bug me about RAGE was its reliance on looting, inventory and other systems generally centered around the collecting, organizing and using of things. There are a lot of games where management of items is a key feature, of course, but shooters, beyond making sure your ammo and health are at acceptable levels, aren't really built on the same sorts of discrete hunting-and-pecking for doodads and trinkets in the environment.

I understand the rationalization for including loot in the game. As a post-apocalyptic title, the theme of scavenging for supplies is extremely fitting, and many other popular games, including Fallout 3 and Borderlands, already have a heavy focus on loot, so RAGE might look a little strange to be completely devoid of that element. It sounds great on paper - you scrounge up healing supplies, crafting items, ammo, and junk to sell, which you can use to purchase upgrades, exchange for more useful pieces of equipment, and so on. Plus, it lets you throw in a few quick and easy fetch quests. So far, so good.

Looting itself is not very interesting - it's what the act enables that gets players to care.

At the same time, however, RAGE is also a game that has absolutely nothing to do with looting or inventory management. It is broken up into discrete challenges - specific levels the player must conquer in more or less a set sequence, where the primary goal is almost always to get to the end and defeat a boss, or simply clear out all the baddies. There's regenerating health, so the only resource to manage is ammunition (and, arguably, time, if you count the defibrillator minigame). Loot is, for all intents and purposes, junk with no purpose in the game whatsoever.

Now, I don't want to devalue the idea of looting as a mechanic. The prospect of micro-rewards for small victories (kill enemy, get money) scratches a very deep-seated itch in players that many developers choose to exploit using either experience points, items, or some other progression system to reinforce. Defeating one enemy or solving one small challenge should in itself feel like it has consequence outside the individual combat encounter, and tying those into a larger game system by way of rewards is a great way to give the player a sense of forward movement. However, everything has its place - and in a game that is primarily about shooting enemies until they're all gone, so you can move to the next room and do it again, spending an additional ten minutes per level pressing the use button/key at flashing objects doesn't really add anything.

Rationalization

So, RAGE has loot. That's all well and good, but immediately the question reveals itself: what good is that loot? Most games that have some sort of collection mechanic tie that collection into the game itself. In Final Fantasy VIII, the (admittedly terrible) "Draw" mechanic ties into the magic system. In Super Mario Bros., collecting one hundred coins rewards a 1-Up, which enables the player to continue playing the game longer. In Fallout, the acquisition of new items is directly related to the player's ability to tackle more difficult situations, with more powerful equipment allowing forward progress and a palpable sense of improvement.

The problem is, RAGE doesn't really have any systems like that. It's staunchly devoted to being an arcade shooter, with a very fixed structure - despite featuring a slightly open-ended upgrade mechanic, getting those upgrades is a matter of time, story missions come one-by-one, and even new weapons are doled out with a very particular regularity. Despite all the open-world hype, RAGE is one of the most deceptively linear, point A-to-B games I've ever played. The lack of a proper world map and over-reliance on the GPS feature only serves to highlight that despite its huge levels, your path is fixed.

You'll spend more than your share of time navigating the crafting menu. However, one wonders exactly what this step accomplishes beyond taking up a few extra keystrokes and minutes.

So, what do we do? Well, the answer seems obvious - we invent reasons for that loot to exist! Again, this is one of those "good on paper" ideas. There are two primary solutions that RAGE provides to this problem. The first is a crafting system. Crafting, at least in theory, serves three major functions in the game: 1) It uses up all those items in the world, 2) it allows players to build cool special weapons, and 3) it allows a degree of choice in play-style. The second solution is money - RAGE more or less uses cash as experience, with dollar bills paving the way to upgrades for both vehicles and the player's weapons and armor.

Except, RAGE is a game that is about going from point A to B and shooting, blowing up or otherwise killing all the enemies in the way. The game's arsenal, which is more or less guaranteed as the player receives certain weapons for making progress in the story (Pistol, Shotgun, Assault Rifle, Sniper Rifle, Crossbow, etc.), is already more than capable of dealing with the onslaught of foes. While ammunition for a single weapon can occasionally get scarce, swapping to a new gun for a little bit rectifies any and all problems. All said and done, it really doesn't need all these cool gadgets and trinkets to craft and collect, and while a few, like the RC Bomb Cars, open up new tactical options, they're rarely more useful than a straight-up grenade toss or Shotgun blast to the face. Which means...

Is It Useful Yet?

RAGE does the next logical thing as it tries to justify all the new special items and crafted implements for the player to use: it gives the player very specific places to use them. Much like weapons, these items appear at set intervals and often tie into the themes of particular stages of the game. For instance, the RC Bomb Cars are used to take on the enemies in the Shrouded Bunker - in fact, they're positively littered all over the place, and enemies often start out with their backs turned to the player precisely to allow for the option of sneaking the RC Bomb Cars up behind them to detonate.

What's more, there are many sections of the Shrouded Bunker level where the player can only proceed by use of an RC Bomb Car. In most cases, it involves piloting the things into small ventilation ducts or other passages to reach the other side of a wall or barrier, then blowing up a convenient stack of explosives in order to knock down the wall or door into the next room. These serve as simple puzzles and admittedly help break up the action, but other than this particular level, this mechanic barely ever shows up in the game again save for a couple of optional extras and secrets. What's more, it even pales as a tactical option because other levels are designed specifically to take advantage of other items, such as EMP Grenades or the Shock Darts for the Crossbow. Chances are most players will never, ever touch the RC Bomb Cars again, despite having dozens of them available within levels, and the raw materials to craft even more.

RAGE's driving is fun, but has no connection to the shooting itself, and the game's open world really serves as an excuse to include the game's races rather than build upon the core action.

A more general example concerns the Lock Grinder, an implement that is, save for one or two places very early in the game, entirely optional. The Lock Grinder is effectively a method for opening specific doors, and must be crafted from a few fairly rare raw materials. However, RAGE is always extremely methodical about providing exactly the number of materials to make a Lock Grinder whenever you might need one, so instead of being a resource to manage and carefully weigh the advantages of using, instead the mechanic is boiled down to pressing a button in a menu and then another to open a door.

On top of this, the Lock Grinder itself almost never opens up anything interesting. In just about every case, the only thing players will ever find for using it is... yep, you guessed it, more junk items to sell for money, more ammo, and more crafting items. You never come across any special weapons by using the Lock Grinder, or upgrades, or quests, or characters, and save for the game's optional collectible card game, there's simultaneously no reason to open those doors, and no reason not to open those doors. We've now come full circle: RAGE's entire looting and crafting system has been boiled down entirely to "get stuff, use stuff, and get more stuff."

Racing and driving in RAGE also falls into this category, although considering it comes with its own built-in progression system and upgrade path, it resembles a full game in its own right. Despite it being a lot of fun to drive around the Wasteland and engage in those racing challenges, though, nothing about it ties into the shooting, or looting/crafting for that matter. Sure, driving helps you get from point A to B, but then, the only reason that A and B are so far apart is.. because there have to be cars in the game. I'd expect that the driving might factor into more boss battles, or let you blast through enemy fortifications, but the driving and shooting are literally divided up by invisible walls. I thought this was a shooter?

Parts of the Whole

Again, I want to stress that there is absolutely nothing wrong with looting, crafting, inventory management, and all that stuff. My favorite games utterly depend upon them. The key point that differentiates RAGE's systems, however, concerns a fundamental disconnect between the core shooting and the additional loot/craft/spend cycle. In other words, you could take these mechanics out of RAGE and lose absolutely nothing at all. The shooting will not get any worse if I can't loot crafting materials to make Wingsticks. The game's level design will not get worse by removing those lootable items. The guns aren't any less fun to use by making players pay money for the upgrades versus simply handing them over (especially as they're cheap, become available at particular points in the game and most players will be able to afford them as soon as they become available).

Games can usually be broken down into a series of smaller micro-games, individual modules of input and output whereby the player has a starting point, a processing state and an ending state. It is the interrelation of all these micro-games that form what we consider to be a full, proper game, with the distinct inputs and outputs of each forming the context and challenge. On its own, the act of pressing a button to fire a gun isn't too much fun, and certainly not a compelling mechanic - but when that event is contextualized by resources to manage, enemies to defeat, an environment to navigate, puzzles to solve, and so on, you have a system that is enjoyable. It's the way in which the different inputs and outputs of these systems link to each other that creates a complete game, not the sheer number of them.

RAGE, outside of its basic shooting gameplay, does not adhere to this understanding of game design. id Software are complete and utter masters of their craft, and I applaud them for that mastery, but everything around the shooting is completely ancillary to it. Instead of building systems that are interrelated, networks of mechanics which depend on and influence each other, RAGE has three games in one which, at best, intersect with one another only in ways which enable each other. Racing has little to do with shooting and only enables more shooting levels, and a faster mode of transport (which only is necessary because of the open-world structure, which only exists to facilitate driving, etc.), and looting/crafting/spending has little to do with shooting other than the fact that it is enabled by that shooting. The end result is that RAGE is a game where the design is not focused around building upon the core gameplay ideas, but on trying to rationalize and justify the existence of its side-mechanics.
Conclusion

After all this, I'm still not entirely convinced that RAGE is a poorly-designed game. I think it's much more accurate to call it two or three games in one than a single game, however. It's clear just by looking at the disparate elements that many of the features exist simply for the sake of them being there, rather than to enhanced and build on one another. Compared to a game like Borderlands, where looting enables new options for combat, the open world allows for more tactical options and open-ended structure, and the driving enhances the core shooting, it's clear that id Software struggled with trying to include all the things they wanted in a way that led to a coherent end result.

The most fascinating part of this analysis to me is how little a lot of this actually gets in the way of the core fun of RAGE. The loot acquisition does indeed scratch that "I'm getting better!" itch, the racing is a fun diversion, and the shooting itself, as I've mentioned, is the most enjoyable I've played in quite some time. However, that lack of consistency and coherence is exactly what prevents it from being the modern classic that many players waited five-plus years to get their hands on. In the end, the final game is a hodgepodge of ideas, and a case-in-point that a great idea in isolation isn't enough to make a great game.

Immersion: A Matter of Scale

2012-01-27T03:44:00.001-05:00

If there's a buzzword the triple-A videogames industry has been aspiring to achieve lately, then it's "immersion." It doesn't really matter what kind of game you're playing, or being sold - immersion is going to be at the forefront of the marketing campaign, as well as the developers' own design. Of course, the actual meaning of "immersion" is itself highly variable and prone to much interpretation. As a subjective quality different for every player, immersion can't really be pinned down in the same way "stunning graphics" or "impressive soundtrack" can, especially as it is often an amalgam of those same things (though that won't stop me from trying a little).

Above most other meanings, I've found that the immersion referred to by most of the games industry, as well as the press and fans, pertains to the illusion of virtual worlds - the idea that a game is taking place in a place and time that "feels real." Usually, this is the result of one thing - painstaking obsession with detail and spending huge amounts of time, effort and resources on building unique art assets, recording tons of dialogue, writing pages upon pages of supplementary text. While these certainly have their value, producing content of this nature is both more expensive - and, in the long run, often less effective than creating wider-scale universal game mechanics and infusing thematic consistency into the virtual world.

What is Immersion?

Talking about immersion by itself is a whole other article, but like most pieces I write, I think it's important that I first establish some common ground. To speak broadly, immersion is both the capacity for a game to draw players into its virtual world and system of rules (aesthetics and mechanics), as well as the nature of the process by which this is achieved. From a slightly different perspective, immersion can be understood as the degree to which a game is able to reinforce the player's own personal narrative - whether that's game mechanics that form circular patterns of play, or a game world that gives context for the player to operate within.

I make special mention of process, because immersion is not an either/or quality - it must be created by game developers with an acute understanding of the experience they intend to provide, and, from the player's perspective, it is built up over the course of playing that game. One does not simply switch a game on and become immersed - rather, it is a paradigm accumulated through exposure to and participation within a virtual world. As its rules, mechanics, characters, geography, conflicts, factions, and other unique qualities are slowly learned and understood, players become more and more drawn. Just as important is that, as immersion is earned over time, it can also be lost the longer a player inhabits a virtual space.

It is also important to note that while immersion can result directly from gameplay mechanics, game mechanics often aren't enough for us to label an experience as immersive. While a game of chess can be just as engrossing as the virtual vista of a digital world, rarely do we speak of games as being immersive on mechanical levels alone. Rather, it is the coherence between game mechanics, story, visuals, sound and so on that create that sense of immersion. For a far more detailed and adept discussion of this, I encourage you to check out Bart Stewart's recent article.

Macro and Micro

With that (admittedly tenuous) definition of immersion out of the way, it's time to turn towards the theme of this article: immersion on a macro scale vs. a micro scale. On the surface, the two terms are fairly self-explanatory, with micro-level details covering the smaller, individual bits and pieces of a game players will come into contact with, and macro-level elements defining the overall experience.

To use an couple of examples, a micro-element might be a graphical detail the player picks up on - Half-Life 2 does a fantastic job with this, by littering the homes and offices of its characters with little details that give insight into their histories and personalities. A macro-element, meanwhile, could include the overall structure of a game - the journey the player makes through the city streets of Grand Theft Auto IV, moving from mission to mission or simply exploring, learning the layout of the game world, does as much to create a feeling of a living, breathing city as any incidental details are able to on their own.

In StarCraft, the statistical differences in units create gameplay, as well as tie into the narrative context of the game.

Of course, both the micro and macro pieces have their strengths and weaknesses. The core strength of micro-level details tends to pertain to their ability to communicate individual pieces of information to the player. In ideal scenarios, this will have both narrative value as well as gameplay value. A Zergling in StarCraft has less health and does less damage than a Hydralisk, for instance, which allows the player to infer not only a simple mechanical relationship between the units (that A is stronger than B) but also their place within the hierarchy of the game's world. This can often form the centerpiece of scenarios the player experiences. Again in StarCraft, certain missions that revolve around the acquisition of new technology, or even resources, also have mechanical value - in these cases, unlocking a new unit to use, or learning how to manage resources.

Macro-level game elements are sometimes harder to pin down, but can usually be understood as that which gives meaning to the entire experience. That is to say, they serve less to highlight the individual facets of a game, and more to give context to situations, or provide weight to the narrative, or create a sense of consequence to actions. Deus Ex: Human Revolution, for example, uses the theme of transhumanism to inform the individual portions of the game, but it also serves as a thematic model for the entire game - its neo-Renaissance art style, the soundtrack's mix of electronic and organic instrumentation, the mechanics of the augmentation system and experience points, etc. Without that consistent theme augmenting the game, much of its character, consistency and context would be lost, and those micro-level elements wouldn't draw the player into the game experience with the same effectiveness.

One Without the Other

Game development, of course, is very much about prioritizing, trade-offs, and effectively getting "bang for buck" as far as all parts of a game are concerned - not just in terms of raw economics and management, but also in terms of design effectiveness (as many games are better off with dissonant elements removed), and in terms of asset and content creation (why spend months working on a level that will only be seen for five minutes, or a model that only shows up in the background?). The exact same logic applies to creating immersion.

Extreme details are all well and good...

Some readers will notice, above, that I made the implication that macro-level elements trump micro-level ones, and this was no accident: speaking bit-for-bit, those macro-elements, including the wide-scale rules of the game world, long-term persistent mechanics, etc. are far more effective, and cost-effective, in building that sense of immersion for players. Consider that while many games can do without the smaller bits and pieces of content or the individual pieces of mechanics, without any context to define an experience in the first place, or to give longitudinal meaning, the end result is a lack of direction, or a feeling of meaninglessness - the end result of which is a boring game that the player probably isn't going to be invested in.

... but it's also possible to accomplish as much with less.

To use an analogy, it's a bit like looking at an impressionist painting: while the overall level of detail in a work by Van Gogh might not necessarily rival that of the Baroque period's Rembrandt, the, well, impression one is left with when looking at the work as a whole is just as if not more coherent as the Rembrant piece. For fewer brushstrokes and comparatively less "work", the impressionist piece captures just as much; the ideal case of more with less. Mind, this isn't about one type of work being harder to produce - the emphasis, however, shifts between execution to conceptualizing as you go from one end of the spectrum to the other.

Tying it Together

Esoteric ramblings aside, how does this relate to immersion? Well, consider one game that's been receiving awards left and right and has had more discussion than just about any other game this year, The Elder Scrolls V: Skyrim. One foundation of Bethesda games, and made even more apparent than ever in Skyrim, is the degree to which the micro-level details of the game world serve to immerse the player. Walking through the virtual streets of Whiterun, one overhears conversations specific to characters (that often tie in with story events or quests), people attend their jobs and perform tasks during the appropriate hours (based not just on the time of day, but also days of the week), and so on. One is struck immediately by just how well-realized the game world is, how much care and effort went into it, how each conversation must have been written in advance, and painstakingly scripted and bug-tested...

... and therein lies the major problem. As impressive as a game like Skyrim is, especially upon initially starting it up and being staggered by the sheer amount of detail it achieves over such a huge scale, it's also woefully expensive to produce that amount of unique content. It might keep more developers working (something I certainly can't argue with!), but it also means that the production cycle is lengthened significantly. Skyrim, on its own, is huge, and even without all its personalized NPC schedules, contextual conversations, hand-placed props in every house that speak to the personalities of the owners, and so on, it'd be a massive undertaking to build... adding all that on top, while certainly helpful, doesn't really astound much beyond the intitial first impression. The first few hours might be absorbing, but even after that, the dialogue starts to repeat, the character behaviours are revealed to ultimately be pretty limited, and those individually-placed objects blend into the backdrop of the game world. What was once special, and which probably took so much of the game's development time, is in the long term no more persuasive or immersive than the content of any other Bethesda game.

Meanwhile, another problem rears its head: for all its detail, Skyrim is also extremely poor at implementing that macro-level consistency as far as game mechanics are concerned. The game initially reeks of political intrigue and drama, the expanded speech skill hints at benefits to winning over allies, and quest lines like the Dark Brotherhood allow the player to do some pretty drastic things... only, none of it ever really matters. Aside from being able to, occasionally, kill a few named quest NPCs, the player's impact on the game world is minimal at best. No matter how many Thieves Guild members the player finds (or kills), the city as a whole will always be plagued by thieves even of most of them lie dead. Likewise, no matter who wins the civil war, most NPCs fail to even acknowledge that it's ended in the first place. What could have become the crux of the game instead becomes only more noticeable and hurts immersion more and more the longer the player inhabits the game world.

A screen full of global statistics, and the emergent events that they can spawn, often make S.T.A.L.K.E.R. far more engaging than the thousands of static, scripted elements in Skyrim.

Compare the world of Skyrim to the one found in the S.T.A.L.K.E.R. series by GSC Game World. Despite the size of the Zone being miniscule next to the Nordic theme park in Bethesda's game, the interactions between the different factions forms a backdrop for the experience, with their different ideologies and goals creating a natural clash that has value in the story, as well as playing out in the game world itself. In Clear Sky, territories will actually shift as different factions gain control or lose it, rendering once-safe areas extremely dangerous, and vice-versa. Meanwhile, loners, animals, and other independents will often find themselves caught in the crossfire, and avoiding taking sides carries with it some very obvious penalties, namely in far more difficult exploration and less access to high-level equipment. Even the endings of Call of Pripyat change based on which factions (if any) the player has aligned with, and whether those factions were led to success or failure.

Despite S.T.A.L.K.E.R. having not even a percentage of the characters and dialogue Skyrim does, in focusing less on the individual details and much more on reinforcing aspects of gameplay and story on the macro level, the Zone is infinitely more immersive and realistic. While I'm not privy to the development details of either game, and it's always a bad idea to conflate the design and technical aspects of each game, it's also hard not to look at a game like S.T.A.L.K.E.R. and wonder just what a developer as big as Bethesda could do with more overarching mechanics beyond the character system.

Conclusion

If there is one thing I'd like to mention in finishing up, it's that I certainly value the smaller details as much as I do the big picture. I spent some time differentiating and defining the values of the two, and did so fully because I don't believe that one entirely supersedes the other. Just as those micro-level elements can seem arbitrary without common ground for them to sit on, the larger-scale ones can also be rendered as artificial, cold and lifeless without the small details to give them colour and personality.

As much as I love coherent game worlds governed by an overarching theme, logic or mechanic, the fact is that Kleiner's lab in Half-Life 2 would not be nearly as engaging to explore if not for all those smaller details, and I don't think expressing Alyx's story value in the form of a virtual pet-style game mechanic would be very appropriate either. There is a place for both, but it's in recognizing their relative values and producing games that take full advantage of that knowledge that defines good game design and project management. For all the talk those small details get, ultimately I don't think that's what sticks with players or makes for a better game, and it's certainly not making games any cheaper or easier to produce.

In Defense of Save-Scumming

2012-01-18T20:12:00.004-05:00

The last two articles I wrote discussed the issue of save-scumming, framing it as a design problem that needed to be solved, with the underlying assumption made that save-scumming was by nature was something that should be avoided at all costs, or mitigated as much as possible. Due to the tone of these pieces and the lack of recognition for the virtues of save-scumming (or a recognition that it is a non-issue in some players' eyes), I may have given the impression that I don't like save-scumming, or frown on those who save/load repeatedly.

In this piece I'd like to offer up a contrary opinion: that save-scumming isn't just important, but necessary. While I still believe it is worthwhile to spend effort in addressing save systems and the problem of save-scumming, I also want to make it abundantly clear that, from a player's perspective, save-scumming is often an ideal solution (or the only solution) when a game's design itself breaks down. Though my goal here is to present these points in a positive light, I also want to make sure that objections to them are heard in order to maintain a more balanced viewpoint.

Competition, and Lack Thereof

The first and most obvious point in defense of save-scumming is that, in non-competitive game environments (whether that's single-player or co-operative play), there is less motive for game designers to ensure balance, or to enforce players to follow an unfavorable outcome - after all, if there's nobody else interested in the outcome but the player itself, and the player's actions won't harm another player's experience of the game, is there really a good reason to prevent players from simply doing what they want?

To present this concern at face value, however, is to ignore the deeper discussion. Though we talk about player choice, and freedom, and how there should be no unreasonable restrictions on what players can and can't do, especially when it comes to such subjective and functional aspects of a game as the simple ability to save, in reality we're talking about something else entirely - the sorts of boundaries that we must accept when we experience a game's content. We are always going to be bound in some way when playing a game, whether that's by the laws of in-game physics, the explicit rules and goals of the game, the collision mesh in the environment, failure and success states, the time it takes to perform a given action, the controls, and so on. Playing a game is by nature to accept a set of limitations... otherwise there is no game to speak of.

Alpha Protocol may have combated save-scumming with its strict checkpoint saves, but it also locked players out of content, including both items and objectives... despite there being no competitive balance to maintain.

The question of save systems and save-scumming comes in largely where we draw the line - where are the boundaries of the experience, and how willing are we to accept them? Saving is such a critical issue not just because we like to exert a degree of control over our game experience (when and where we can stop playing, and how often we can retry or replay a game from a given state), but also because it fundamentally affects our relationship with a game. Our tactics, techniques, time investment, and rate and direction of progress through the game all change based on the limitations we have in saving. It's why roguelikes, with their strict no-saving rules, are so different to play than other games - not because they're necessarily more difficult, but because cautious and self-restrictive play wins out over all other forms.

Even though it's true that players have already been told and are conforming to the limits and rules of the game as soon as they actually start playing, that perspective ignores the fact that not all players have the same needs, the same goals, or the same desires - thus, while maintaining balance and integrity of gameplay may be a priority for some players, other simply don't care, or even take it as a triumph that they have broken a system. Moreover, that logic used above can be turned on its head - if it's a choice to follow the rules or not, even if the end result is failure, then isn't it a choice to abuse those same rules, even if the end result is success?

Completionism

Another point in defense of save-scumming concerns the matter of completionism. Though not all gamers are concerned with getting that "100%" value next to their save files, or simply the best outcomes to the story, the desire to see all a game has to offer (and then be able to brag about it or gain some recognition for the act) is one that many players share. Unfortunately, save systems often run contrary to the goal of 100% completion, especially in that they can force the player to stick with consequences that are not conducive to such an outcome. I can certainly say I've been trapped beyond a point of no return in a game before completing everything I wanted to, and that wasn't fun in the slightest.

Tying in with this concern about completionism is a general grievance that games should communicate outcomes to players in advance - that hiding information from players, or not providing enough data to make an important decision, can end up as frustrating rather than interesting. I personally can't say I agree with this in all situations, but there is merit to the argument. For example, in Mass Effect 2, players must complete a loyalty mission for each of their crew members in order to ensure their survival in the endgame. Instead of loyalty tying into the game in a logical way (such as, say, a mutiny), it determined which characters would be killed at the end of the game. These deaths were arbitrary, and represented a clear story/gameplay segregation that was neither rewarding nor remotely logical.

Mass Effect 2 hinged the fates of party members on loyalty, but the cause and effect weren't clear - a clear failure of design that save-scumming can help mitigate.

Denying information to a player can be a useful tool, admittedly - obviously a plot twist holds no weight if players see it coming a mile away, or are outright told about it in advance, and sometimes having to make a guess as to whether a final attack will defeat an enemy or only lead to your demise is rewardingly (or disappointingly) suspenseful. Likewise, that same plot twist also lacks impact if players can't look back on prior events and see hints of it in retrospect, and if an enemy has no guaranteed strategy that works against it, it isn't satisfying to finally pull out ahead. Success is an emotion felt when we feel we have conquered a challenge, not when we have been granted victory at random.

When we end up in a situation where our success feels arbitrary, or the ideal outcomes to the story are the result of extremely obscure actions near-impossible on a first play-through, or we miss out on a character's ultimate weapon, or pass a side-quest by unknowingly, we understandably end up feeling cheated by the game. I'm not going to even attempt discussing whether this is a problem or not, but there's no denying players have little recourse in such situations other than reloading saves until things work out for them. While it's always best to ensure this sort of situation never occurs, players should probably not be denied the option to reload in cases where it does happen.

Differing Player Motivations

Another concern with combating save-scumming is that it's effectively a gameplay measure that punishes all types of players for the perceived sins of a relative few - when in fact players have many different reasons for playing, and thus different motivations other than abuse or gaming the system to its fullest. A player dedicated to completing goals, for instance, might well be driven to save-scum for reasons entirely separate from a player driven by the desire to explore.

To take the example of The Elder Scrolls V: Skyrim, imagine a player has wandered into a dense forest out, and has come face-to-face with a powerful, high-level enemy. The player tries to fight, or run away, and is killed. Depending on the type of player, his or her next actions may be substantially different. For instance, he or she may:

Reload a save, and try to fight the enemy again using the same tactics.
Reload a save, and try to fight the enemy again using different tactics (i.e. ranged instead of melee).
Reload a save, and try to avoid the enemy.
Reload a save, and try to find an exploit to defeat the enemy (such as hoping the AI gets stuck).
Reload a save, travel around a bit or wait for the enemy to move on, then continue exploring.
Reload a save, and go in another direction, never to return.
Reload a save, make a note of the location, level up a bit, and return later to conquer the enemy
Reload a save, travel back to town, purchase some better equipment, and return to conquer the enemy.

Many players meet their match at the end of a Giant's club, so why should Skyrim assume that the motivations of players that led to that outcome are the same, or their actions afterwards?

The point is, there are a whole slew of different things that could be driving the player to reload, as well as dozens of outcomes possible once the player has actually reloaded. To term all of these as "exploits" or to say that they violate the spirit or nature of the intended experience is to be presumptuous about the motivations of all of these players in a way that may be extremely inaccurate. In such a situation, how is it even possible for developers to accurately anticipate what players want? Who are the developers to make a judgement and reward or punish accordingly

Once again, this ties in with the discussion about the rules and boundaries we accept when playing any game, but the key difference is that any sort of anti-save-scumming measures undertaken by a developer will inevitably seem unreasonable to certain players, especially those who don't fall into the category of "abusers." The "easy" answer to this problem is to have more intelligent ways of rewarding, punishing and limiting save-scumming, but of course, the measures taken are going to be completely different for any given game in the first place. Sure, it's easy to detect if the player has reloaded, say, five times in the span of 30 seconds of gameplay while inside the casino... but to create a robust anti-scumming system that is applied intelligently to all aspects of a game is a huge undertaking, and one which, frankly, probably isn't worthwhile. If you can't do it right, in a way effective and applicable for all players, why do it at all?

One's Reward Is Another's Punishment

Some people aren't so much opposed to the idea of save-scumming itself as they are opposed rewards and punishments granted in response to it. As I touched on in my article on incentivization, in order for a reward to be granted, there also has to be the capacity for a reward to not be granted... and the reverse is true of punishments. Whether or not it's an incentive or disincentive will depend on which side of the line you're standing; the question of who's a damn dirty cheater is almost irrelevant in such a case, because you're bound to upset some players no matter what.

In truth, it's hard to offer up a reasonable counter-argument to this, save for that one has to make certain a game's incentives and disincentives aren't too great so as to alienate players. When dealing with something so fragile as individual player preferences, which cannot be reasonably evaluated in objective terms, it's impossible to satisfy everyone, and to the same degree. Some players are going to love incentives and disincentives, others are going to hate them. Some players are going to be "okay" with them and won't mind much one way or the other. Some more players may not mind in practical terms, but will object to the principle of the matter. You really can't win.

Fallout: New Vegas makes players who try to break the hacking mechanic wait before trying again, but how can a developer anticipate a player's reasons or judge them effectively?

It'd be easy for me to say what I did before: that all players are going to have to accept boundaries in playing a game, and thus accept different outcomes for their own actions within the game, whether that's tactics or use of the save system. No matter what you do, nobody will be fully satisfied with how your game handles everything. However, what's different in this case with save-scumming is that game-saving is not just a mechanic, or a utility, but a hybrid of both, one aspect influencing the other, and further interacting with the rest of the game.

Just as a title's controls might be made theoretically "perfect" from a utility perspective, the actual rules governing them may be subject to debate for every individual player; a save system's utility may be "perfectly" executed, but the context for that save system and the mechanics it influences - and is influenced by - may also be open to myriad interpretations. Something like game balance can be expressed in objective terms, but there is no objective language that does justice to a save system, nor the measures governing its use. It's not a binary pass/fail condition, and can't be treated as such... otherwise, you're handing out those rewards and punishments based on a set of arbitrary conditions.

Conclusion

In closing this series, I think it's important to acknowledge that there is no right answer to any of this. As much as I might view save-scumming as a problem that needs to be remedied, I must also recognize the reason the practice exists in the first place. I save-scum myself; in fact, the first time I finished Fallout, I did so by saving and reloading in the middle of some particularly difficult battles. I'm also a fan of speed runs and other hyper-optimized forms of play, at least as an observer; such practices would not be possible without the sorts of meta-game manipulation that save-scumming is a part of.

As is often the answer with matters of game design, the problem can't be boiled down to one particular element, or one type of player, or one specific scenario, or mechanic - rather, it is holostic, influencing and influenced by the game as a whole. What I do hope, in light of this, is that this discussion got some people thinking, not just about save systems, but about the relationship between player and game, as well as the relationships between different game mechanics and systems, and all the "fuzzy" things that happen in between. I certainly didn't intend to follow up on the topic so long, but it was impossible not to when one question led to another so readily.

Thanks to all the readers and commenters, who were kind enough to interrogate my ideas and provide more food for thought than my own mind ever could. Many of them inspired the content of this article. As always, feedback of any kind is more than appreciated!

Save Scumming and Incentivization

2012-01-15T16:31:00.004-05:00

In my previous article, I examined different methods used by developers to combat save scumming. Among them were the use of checkpoint saves, limited save slots/numbers, and punishments for repeated saving/reloading. Although all of those systems have their strengths and weaknesses when it comes down to save scumming, I feel that usually the best choice is to work to design your game in a way where the motivation to save scum in the first place is diminished, or doesn't exist at all.

A few remaining thoughts were left on my mind, however, and there was a big topic that I skipped over in the original piece that I'd like to take some time to address. Specifically, it's incentivization, which I feel is related to punishments but deserves its own discussion due to the different ways it can be accomplished, and the way in which it can interact with punishments.

Incentives vs. Punishments

The first thing to consider is what differentiates an incentive from a punishment. This might sound obvious at first - punishments are bad, incentives are good - but the reality behind the situation is a little bit more complex. In many cases the difference between the two is a matter of perspective - is locking the player out of computer systems in Fallout: New Vegas an incentive to play the mini-game properly (and thus get an XP reward), or is it a punishment for not playing as the developer intended (you have to wait to try again)?

The reasonable answer is that the distinction between incentives and punishments is one of opinion, and that in almost every case you have to have a mix of an incentive and a punishment for either one to really make sense. It's definitely possible to express something as primarily positive or negative, especially to the player ("don't do this" vs. "do this"), but there's always going to be a downside to every upside. The job of a game designer (at least, one concerned with eliminating save scumming) is to frame the outcomes in a way that comes across as generally positive to the player, rather than punitive.

This can be easier said than done, especially because the ways in which players experience games can be very different from one another. Some players might love to get rewarded, while others think that missing out on rewards because they aren't as skilled as others isn't very much fun. Similarly, there are those who love a great challenge, and others who stop playing after losing no more than two or three times in a row; for them, the motivation to save scum is both situational and personal.

With that in mind, what are some of the ways in which developers can provide incentives to keep playing the game without resorting to save scumming or other forms of related abuse?

Understanding the Decline of Attrition

As I've written about before, if there is one trend covering just about all modern game design, it has been the reduction of attrition. This is something both enforced within gameplay and which often forms the entire basis of a game's mechanics (regenerating health), as well as something which stems less explicitly out of the structure of a game itself (the tendency towards shorter game levels or goals, with obvious break points). I'm not here to talk about whether I think this is a good or bad thing, but it's clear that it's defined many games released in the last console generation especially, and doesn't show any sign of disappearing as developers move towards the mobile market.

What tends to be lost with this reduction of attrition, however, is the incentive for players to keep playing a game for longer sessions. Whereas many past games were heavily focused on keeping the player in the action and moving forward at all times - strategy games like Command & Conquer with lengthy missions requiring long-term planning, or shooters like Half-Life refusing to break gameplay up into distinct levels - these days the challenges players face are immediate, the risks and rewards occurring within the same repeated 30-second cycle of gameplay rather than over the long term.

Many games used to emphasize long-term strategy more than they do now - making save scumming less viable then, and more essential now.

Instead of long-term goals being the default, now other types of goals have been superimposed upon this smaller cycle of short-term goals. Completing the level may now be a fairly trivial task, but can you get the achievement for completing the game in 5 hours? How about collecting all the hidden objects throughout the game? Gaining a high score on the leaderboards? Do you spend your superweapon's ammo now, or later on? Long-term goals exist nowadays primarily to satisfy the hardcore completionist players, and thus the motivations for save scumming tend towards meta-gaming and power-gaming.

Why do I go into this? It's important, I think, to understand how modern game design has changed and how and why save scumming now manifests. If developers are to create important incentives for players, they need to be able to know why players are save scumming in the first place, the sorts of functions it serves for them, and how those problems in gameplay can be remedied. Attrition, or rather, its decline, is at the heart of this problem.

Rewarding Consistent Play

While you can't really change the nature of players, you can reward them to keep them in the game, rather than reloading every five minutes to get ideal outcomes. One of the best ways to do this is by providing players a reward for avoiding reloads (specifically reloads done to avoid bad outcomes). Though this isn't going to be appropriate to every game for the reasons I've discussed above, I think it has a lot of potential in getting players to keep going.

The best recent example of this I can think of is in Jay Barnson's indie RPG Frayed Knights: The Skull of S'makh-Daon. In Frayed Knights, the player gains Drama Stars for opening doors, solving quests, defeating enemies, and so on. Drama Stars are obtained at a fairly fixed rate, with the distinction being that most of them are achieved for new accomplishments rather than old ones, so opening the same old door obviously won't reward the player like opening a new, unknown door will. When you save and quit the game, your Drama Stars are saved, but if you reload a save, they disappear and need to be re-earned.

Frayed Knights' Drama Stars reward players for sticking with it and surviving by the skin of their teeth, rather than loading up a previous save file.

Drama Stars can then be spent on special abilities used both in and out of combat. Some of these are pretty mundane and have small effects, like a temporary damage boost, but as the player accumulates more Drama Stars, the potential abilities become game-changing, up to and including a full party revive and restoration, turning a losing battle into a winning one instantly (provided the player has played consistently up until that point, of course). Although this doesn't eliminate save scumming entirely, it does a lot to encourage players to avoid reloading.

Another hypothetical example might be found in an action game, where the player gains a long-term bonus for killing enemies (i.e. 30 kills = +5% damage bonus), and which persists until the player either completes the current level or challenge, or reloads the game. Players aren't punished, per se, by reloading, but by continuing with the current challenge, they'll have an easier time in the long run for it. Admittedly, the nature of the game design would need to reflect this (avoiding instant death scenarios, giving the player a large supply of health rather than a small, regenerating one), but of course, these sorts of incentives are going to be different for every type of game. Frayed Knights' Drama Stars wouldn't work in a shooter, for example.

Additional Objectives & Bonuses

A related but different mechanic for encouraging the player to avoid save scumming involves providing the player with larger or extra rewards for completing tasks in an ideal manner, or for completing secondary tasks. This could be anything from bonus experience points and gold, to extra items, to a simple congratulations from a character in the game. Balancing these sorts of rewards is a challenge, as they'd have to be proportionate to the risks involved, as well as not being so significant that the player feels it's a good idea to reload the game if the demands aren't met.

Though I haven't seen this implemented on a universal level in recent games, the one that springs to mind the most for me is Fable: The Lost Chapters. In Fable, the player can take on different quests during the game, both required and optional, and choose to boast about them. Boasting effectively unlocks a set of secondary objectives for the player to complete during the mission, in exchange for a greater reward (usually money and experience), but also requires an investment cost, so it's not a sure-fire way to make tons of money easily.

Fable's boasting gave optional incentive for hardcore gamers to challenge themselves - indirectly encouraging them to avoid the save/reload cycle.

Combined with Fable's checkpoint saving system, it's more or less impossible (certainly inconvenient) to load up a previous save upon failing a boast, and the ability to take multiple boasts on any given quest also means that failing one still leaves the others open. This gives more options for the hardcore players to show off their skills or get the challenge they want, but still ensures that everyone will be able to move on in the game, without losing anything. While not specifically designed to prevent save scumming, this sort of mechanic once again encourages players to stick with the results they've got. Because of the investment required to boast in the first place, it's not a simple matter of "do it right and get a bigger bonus"; rather, it's directly tied to the player's own choice to undertake the additional challenge.

When talking about secondary or optional objectives, it's worth clarifying their importance in the game. If an optional task feels too important to the player - it has been given a lot of importance in the story, or the rewards for completing it are huge, or the player will miss game content by not completing it - then in my opinion it's hard to even really consider it optional at all, from a save scumming perspective. Since players who resort to save scumming are usually meta-gamers or power-gamers to begin with, they're going to want to complete just about every secondary task available before moving on in the game. Therefore, it's fair to say that rewarding an extra health potion or a 5% experience bonus for completing a secondary task incentivizes consistent play... but giving the player a whole new level to explore, or a new weapon or set of armour, only adds to the problem.

Meta-Game Incentives

Last, it'd be hard to talk about giving players incentives without talking about meta-game rewards. Though meta-game rewards aren't always available depending on a given game's platform, genre, etc., it does tie in quite nicely with the hardcore player mindset of "100%ing" a game that often fuels save scumming in the first place. Moreover, because so many games are geared towards long-term goals, and which are themselves often meta-game goals, it only makes sense to use those features to one's advantage.

The first and most obvious meta-game system to highlight is achievements. Most major gaming platforms have some sort of achievement system, regardless of the name, and a similar type of functionality can be added into a game even if it doesn't tie into any sort of meta-game system (the Mass Effect series does this on the PC). While an anti-scumming achievement might be a little too blatant for some players, the same sorts of problems can be solved by using achievements in conjunction with other goals - for instance, rewarding an achievement for saving all the peasants from an attack, which itself might only possible without save scumming. A more brute-force method of "no achievements for you, save-scummer!" can also be used, but again, being this blatant about it might turn some players away.

Rewarding achievements for fair and consistent play could encourage players to avoid exploits.

Another option is to cut save-scummers off from leaderboard rankings, or include some sort of high-score penalty for repeated reloads. Even games that don't have explicit scoring systems can have some sort of leaderboard compatibility, whether that's being able to track the progress and accomplishments of friends who are also playing, or listing completion speed, accuracy, and so on rather than high score. For single-player games this might be a little more out of place, but it's still certainly possible to integrate such functionality.

It's worth noting that these solutions start to border on punishments again. As I described above, I don't think the distinction between the two is quite as absolute as some might suggest, and when players aren't really missing out on any game features when save-scumming, I think it's a non-issue. Just as the Grand Theft Auto games disable achievements when players activate cheat codes, I think it's fair to do the same when players begin to abuse the save system - though care must be taken about the particulars. So long as a game isn't broken enough to actually require the use of save scumming to complete, I interpret achievements and leaderboards as rewards on top of the core game experience, rather than features all players should be privileged to.

Conclusion

Once again, I'm forced to admit that there is no sure-fire way to deal with save scumming. As many incentives as you throw at the problem, players are probably still going to continue to do so, and without outright restricting the player's ability to save and load the game in the first place (the hallmark of some genres, but not most), all a developer can do is push players in the right direction and hope they take the cues.

There are still some unanswered questions about save scumming that I'd like to get into at a later time. I realize that these articles can occasionally come across as very anti-player, punitive, and generally one-sided. I fully admit to this, but it's not a result of my personal opinion on save scumming, on the nature of the discussion's tone. There are plenty of arguments to be made for save scumming as well, as not all games are created equally and not all players are willing to subject themselves to the limitations imposed by developers. I'll be getting into that myself soon, but better yet, if you have a strong opinion about save scumming one way or the other, I'd love to hear it as well.

The Save Scumming Problem

2012-01-13T02:19:00.001-05:00

Save systems are tricky business. No matter what kinds of games you play, chances are you've run into at least a few that don't work quite the way you'd expect or prefer. Whether it's checkpoints and autosaves, quicksaves, the number of save slots, free saving versus limiting saving, or even limited save numbers, the ways in which a save system can influence how players navigate the challenges of a game is often given less attention than it deserves. There are a lot of conflicting beliefs about what differentiates a good save system from a bad one, especially as many players have very different standards; some like the tension that checkpoint saves provide, while others are adamant that saving should be as convenient as possible.

One thing that most developers and players do seem to agree on, though, is that save scumming can be a major problem, at the worst of times outright removing the challenge of a game entirely, and undermining the finely-tuned game rules and mechanics that the developers spend so long perfecting. There have been a number of different attempts at solving the save scumming issue, but few have been sure-fire solutions and fewer still haven't had drawbacks. In this article, I'd like to take a close look at what save scumming is, the different ways it can be combated, and to evaluate the relative successes and failures of each method.

Defining Save Scumming

Although most people probably have some idea of what save scumming is, for the record, I'd like to lay out a fairly basic definition that stands up under some degree of scrutiny and is relatively inclusive of players' motivations and goals. Like save systems themselves, save scumming and opinions on what it is, how much is fair and how much becomes an exploit, and so forth, tends to vary quite a bit from person to person.

Generally, save scumming is an action performed by the player which involves the deliberate manipulation of save game states for the purpose of obtaining an advantage during play that normally would not occur, or to achieve a desired outcome. This is usually done for three reasons:

Manipulation of story events and choices in order to obtain the player's ideal outcome, i.e. making sure the "best" resolution to an event occurs.
Saving and loading in occurrence with favorable outcomes in gameplay, i.e. reloading if a powerful attack misses the enemy.
Using prior knowledge to get past an existing challenge, i.e. completing a puzzle through trial and error and then reloading to remove any consequences of failure.

While there are undoubtedly a few special cases depending on the game, these are the three occurrences of save scumming that are most common and most prone to use (or abuse) by players. Of course, some also won't agree that all of these constitute save scumming, or that save scumming itself is a valid play-style in certain situations (such as to view all endings of a game), but I think this gives us a pretty comprehensive survey of the problem.

Checkpoints

One of the most effective, but also most restrictive way that developers can reduce or eliminate save scumming is by forcing the player to use checkpoints rather than providing free save options. Checkpoints are typically a bit more common on console and handheld games, but usually show up in just about all games in some form or other. For clarification, checkpoints here refer to the use of a single autosave slot, as opposed to traditional autosaves, which often work with multiple save slots or are combined with other types of saves, such as manual "hard" saves and quicksaves.

Typically, checkpoints and checkpoints can work to the player's advantage by making sure difficult stages of the game don't have to be completed multiple times over. Indeed, more than any other solution, checkpoints make it difficult or impossible for the player to manipulate outcomes, although they do allow for multiple attempts to be made prior to the next checkpoint down the road, meaning placement is extremely vital.

One strength of checkpoints is that they can often enforce story decisions in order to make sure players live with the consequences of their actions. While not important to every game, this can be extremely useful for helping players learn to appreciate their choices and their outcomes. Alpha Protocol, for instance, used checkpoints exclusively to regulate the player's movement through the open-ended story. With lots of personal relationships to manage, story-relevant decisions to make and even a few time-limited choices, the effects of the game's consequences, both in the short and long term, would have been dulled significantly.

Alpha Protocol got players to consider their actions by forcing them to live with their consequences.

Checkpoints also typically ensure that players don't manipulate the outcomes of combat encounters and other challenges, and more broadly make players consider the long haul rather than the short term. With checkpoints, overcoming single challenges becomes less relevant than making it to the end of a scenario in one piece. Attrition is a dying art in most games, especially those in the mainstream, and checkpoints make players work with what they have rather than rely on luck or other exploits to pull them through.

The one thing checkpoints can't really protect against is the use of prior knowledge. Unless a game saves at each and every junction where a choice is made, or an encounter or puzzle completed, it's very hard to prevent the player reloading to pick the right option from the beginning. Moreover, as most games tend to place checkpoints right before these scenarios, there's very little dissuasion for players actually doing so. This is a lesser concern than the other two motivations for save scumming, but still worth taking into consideration.

Finally, checkpoints, by their restrictive nature, have the unfortunate drawback of forcing the player to live with the consequences of his or her actions, no matter what they are. That means that sometimes, players will be stuck with decisions they made accidentally, or gameplay outcomes that weren't their fault. If a game includes a challenge, and the player is stuck with an unfavorable result because of a bug or an out-of-game distraction, then that does not feel particularly fair. Similarly, it's common for the dialogue choices in role-playing games to provide players with unintended results (especially in cases where dialogue wheels are employed, and the exact meaning of a player choice is ambiguous); in these situations, it's downright frustrating to end up with a story development that wasn't the result of a "bad" choice, but rather because the game was poor at communicating important information.

Limited Saves

The second major way games limit save scumming is by providing limited save slots (or save numbers). This is more common on consoles, and traditionally was as much the result of technical limitations as it was a design choice. In Chrono Trigger, for example, the player is limited to three save slots only, regardless of whether or not those save slots are from separate game sessions; if you have friends or family playing a separate session, then your number of save slots is actually reduced. Similarly, in the early Resident Evil games, the ability to save was limited by the number of ink cartridges the player collected around the game world.

Though generally a lot less common than it was in the past, it does crop up from time to time these days. IO Interactive's Hitman series rather famously provides the player a different number of saves depending on difficulty, with zero save slots at all on the highest difficulty level. The goal in such a game is to make sure the player has both effective planning skills as well as is able to execute on that plan; the other options are much more lenient and don't require the same devotion to planning and tactics, only on getting through the game's stages alive.

Limited saves in Hitman encouraged players to plan their actions carefully, and avoid unnecessary carnage.

Limiting save slots has a less drastic effect on gameplay than checkpoints do, but by making savegames effectively a resource to manage, players need to think about whether it's worth their time to save, and either overwrite earlier progress or use up a limited capability. The major upside of limited save slots is that it has a relatively equal effect on all motivations for save scumming - players aren't going to be nearly as tempted to reload an earlier save, or make a new save, if they know they may need that save option later in the game, regardless of whether it's a story event or gameplay scenario. It also mostly avoids the problem of the player being stuck with a mistake, or at the very least avoids the feeling that the game is punishing the player for a mistake the designers made.

However, limiting save slots also comes at a pretty big price: the core functionality of the game itself. The fact is that developers cannot, and probably should not, insist when and where players can save, because they are unable to anticipate the situations players will need to pick up and put down a game, or with what frequency, or the numbers of players who might be playing on a single device or copy. As much as we'd like to imagine players sitting down for hours to enjoy games, the fact is that with real life, including family members to manage, chores and tasks to complete, work to do, etc., it's simply not convenient for most players to do so. Limited save slots simply don't take the reality of gaming into account, and while it's possible for players to pause the game for hours on end, that's a pretty poor solution by any standard.

Last, in cases where there are limited slots for the player (as in the Chrono Trigger example), often the player will be left out of luck when a bug or glitch shows up at some later point in the game to hinder or ruin progress. Even if a player were to use all save slots in The Legend of Zelda: Skyward Sword, there's a pretty good chance the recent game-ruining bug uncovered could strike, and by the time the player encounters the fallout from the choice, it'd be too late. Losing progress is never fun, but losing five hours is still preferable to losing thirty hours.

Punishments

A less-common, but growing way of dissuading the player from save scumming, is through the use of various punishments for continuous reloads. These can vary radically from game to game, but all of them share the same basic idea of making repeated reloading unattractive, whether that's through respawning difficult enemies, reducing the player's effectiveness in combat, deleting savegames upon loading them, adding wait times to certain actions prone to abuse, artificially inflating load times, or providing greater challenges.

It's clear right from the start that punishments of different natures will be appropriate to different games. There's no reason to make die rolls or other random odds less favorable in a game where random odds aren't a major concern, for instance, while in a heavily rules-driven game, the idea of rubber-banding an enemy's abilities or challenge level is equally inappropriate. Moreover, punishments walk a very fine line - too drastic and they can be a turn-off from playing the game altogether (and effectively feel like "real" punishment), too subtle and they might as well not be there at all.

The time delay between hacking attempts punished players who abused quicksaves in Fallout: New Vegas, but the resulting wait periods were more an annoyance than a real deterrent.

One example of this I like to bring up appeared in Fallout: New Vegas. In Fallout 3, the game's predecessor, the hacking mini-game required the player to take time and use deductive reasoning to piece together a password using a limited number of guesses. Many players found that this mini-game quickly grew tedious and instead chose to simply guess at random, quitting the mini-game before the final choice was used and starting over - in the end it was still faster than playing the game "properly."

New Vegas added a lockout timer of about 30 seconds to each computer terminal, which persisted after reloading the game. Although this reduced the random guessing, the alternative of legitimate failure - being locked out of a terminal, and thus game content - was still far greater than waiting those painful seconds. Despite good intentions, the problem remained, and the tedium of the mini-game was only exaggerated for many players. Truth be told, removing the mini-game entirely would have solved the tedium and the save scumming in one fell swoop, but such drastic measures aren't always an option.

Punishments are hard to evaluate because of their case-by-case nature, but in general they can be effective means of making sure players don't perform exploits. The prospect of saving and reloading isn't so much fun if the odds of success get worse every time. However, it's also very important to consider the negative consequences punishment can have, and it's necessary to devote extensive play-testing in order to tweak those punishments just like a full-blown game mechanic would be tweaked. Moreover, as effectively a game feature, punishments can also introduce more bugs and may themselves be exploitable in some cases.

What Else Can be Done?

Though the techniques mentioned above, and more, can be used to reduce or eliminate save scumming, oftentimes the design of a save system is secondary to a game's mechanics, pacing and writing in preventing abuse. As much as you can force the player to play by the rules, it's often a far better choice to make them want to play by those rules in the first place, and the only way to do this is through smart design from the beginning in every aspect of gameplay.

Consider negative story outcomes. It's very common in role-playing games for players to replay scenarios in order to get the outcomes they approve of the most, whether the benefits are tangible or not. It doesn't make much sense from a development perspective to spend a lot of time and effort on different outcomes in a story if most players are going to manipulate events to get the "best" outcome over all others. Instead, taking care to make all story paths and outcomes feel valid and earned can reduce the desire to load up a prior save, as can focusing on long-term consequences rather than short-term consequences (if only because it's a lot less convenient to reload three hours after a choice has been made).

As far as gameplay goes, the tendency towards binary pass/fail or win/lose states can be just as great a temptation to save scum, as it's as undesirable an outcome as any. This temptation is made even greater in games where there is no way to repeat a mission, or where penalties are given for failure. This is a fundamental design consideration in all games, and thus it may not be possible to take this into account, but where possible it's usually better to make the player feel validated by an outcome, even if it isn't the most ideal. Just as life isn't simple, games don't have to be either, and a level of granularity to progression or victory (whether it's a new plot event, a score, a star rating, etc.) encourages players to improve rather than switch the game off.

Jeez, even the game insults me? Might as well stop playing right now, at this rate.

This isn't an argument for "no failure," make no mistake, but if players feel they're missing a significant amount of game content for a non-ideal outcome, they'll be far more likely to reload. Ideally, failure should have its own unique outcomes and rewards - new missions to resolve the consequences of the failure, or special items to give the player an added edge. Dragon Age II, for intance, made my failures feel less like failures and more like alternate, but acceptable, outcomes. Did I want a negotiation to end in a bloodbath? No, but the game didn't grind to a halt because of it, or make me feel like an idiot for screwing up, especially as the rest of the characters in the game world acknowledged the outcome as well as any other. Obviously, this isn't possible in all or even most cases due to the realities of development, but it's worth taking notes on all the same.

Presentation is also a huge factor in cutting back on save scumming. Consider the usual failure state: red text proclaiming "mission failed" while dreary or sad music plays in the background. That's a pretty big signal for players right there that they screwed up, and certainly doesn't encourage most of them to keep playing. Simply resetting the player back at the beginning of the challenge communicates the same failure, but also avoids adding insult to injury. Again, this isn't always possible, but it appreciably cuts down on frustration and also avoids wasting the player's time.

Conclusion

Though I've tried my best to break things down here and be as comprehensive as possible, there are always going to be exceptions, whether that's games that don't fit our normal understandings of success and failure, situations where save scumming can be helpful for players rather than an exploit, and so on. Dealing with save scumming is a challenge that's unique to every game, and more than any it's one worth considering, as it is, in a way, an embodiment of every unexpected variable that players bring to the gameplay equation.

If there is one lesson to be drawn from this discussion, it's that more than anything, the structure and mechanics of a game are just as important if not more important than the save system itself in mitigating abuse and exploitation. The most appropriate save system for a given game can still be broken and taken advantage of in unintended ways, and placing overly hard restrictions on the player is generally inferior to getting the player to accept what he or she has been given. Context in designing game and systems is everything, and taking care to understand how a given game mechanic, user interface element, or story event can affect the player's decision to save or reload the game can often make all the difference.

Can I Craft That For You?

2011-12-28T22:05:00.002-05:00

Though traditionally confined to RPGs and roguelikes, crafting has become a staple of modern gaming almost regardless of what genre you enjoy. Whether it's first-person shooters like RAGE, action-adventure titles like Dead Rising or Assassin's Creed, MMOs like World of Warcraft, or even rhythm games like Sequence, crafting is here to stay, for better or for worse. After all, games are all about choice, and just like RPG elements like experience points creeping into just about every facet of gaming, crafting is another solid way to provide that choice to players.

Even so, not all crafting systems are created equal - so much so that often reading "crafting system" amongst a list of a game's features is enough to set off alarm bells in my head, as it's as much a source of tedium and frustration as it is a genuine improvement. While there's always going to be some subjectivity involved as far as the value of crafting goes, there are still very clear wrong and right ways to go about implementing such mechanics. When done right, crafting can be a positive addition to a game... and when done wrong, sometimes it's enough to make players want to stop playing altogether.

Why Crafting?

The first question to ask before even going into the details of a crafting system at all is actually much more basic - namely, why crafting? What does crafting, mechanically, accomplish for a game? What sorts of problems does it solve, and introduce? Perhaps more to the point, does crafting fit into the overall vision of what a given game is about? Often when it comes to game mechanics, it's not so much a question of the how as it is the why that needs to be addressed before any design work or code is written down.

Namely, what exactly does crafting do for a game?

Provides a sense of player agency. Just like making a hot meal for yourself instead of getting take-out, crafting in games helps players feel that they own the things they create. Even if it's just following a recipe and there isn't anything creative involved, the simple process of choosing to make something can often be more satisfying than simply being given the same object or item.
Gives a secondary use for items. A common problem with loot-driven games, especially RPGs, is that the player will end up nearly drowning in excess amounts of equipment. Usually the solution is to either sell this equipment or simply throw it away, neither of which rarely have much use in the game. Crafting helps mitigate this problem.
Balances in-game economies. Another side-effect of giving the player lots of junk or "vendor trash" is that often a game's economy becomes woefully unbalanced or unstable, often to the point of completely undermining the value of money in the first place. I can't count the number of RPGs I've played where I simply stopped picking up items because I already had so much money to spend and nothing to spend it on. Implementing crafting doesn't just cut down on junk, it also helps reinforce the value of in-game money and keeps its role distinct.
Encourages exploration. Especially in open-world games, crafting is one of the ways in which designers can subtly get players to do and see more of the game worlds they spend so much time creating. Even if it's just picking flowers to use in a few potions, players will want to spend time doing things and going places if they can acquire items doing so - especially if they're useful or can't be found elsewhere.
Provides better rewards. How many times have you completed a game objective and received a reward that was completely and utterly useless to you, either because mages don't use longswords, or because the item was well below your character level? By rewarding the player with generic crafting ingredients and recipes (or unique, limited ones), players can actually receive something that's useful, without designers needing to come up with specific rewards for every possible play-style.
Adds to play-time. This, unfortunately, is one of the most malicious ways in which crafting is used. Though sometimes there can be benefits in requiring players spend more time to complete a task (if something is too easy, it isn't rewarding), the majority of games I see featuring crafting use it as a way to simply pad out the experience. More on this later.

With all that in mind, it's worth turning attention to exactly how all of those fit into the experience intended by a specific game. All of this sounds good on paper, granted, but when put in context, sometimes it's clear that crafting isn't always beneficial to a game's design. Would Super Mario 3D Land really be enhanced by the ability to craft power-ups? Does the cinematic, structured and highly scripted gameplay of Uncharted really need a system that encourages exploration? Grand Theft Auto IV is an open-world game, but does hunting down powder to make different types of bullets really fit with the vision of the designers or the immediacy of the experience?

This is all easier thought about than done, it goes without saying, and sometimes the only true test is experimentation. Even so, there are some games I've played where crafting feels bizarre, bolted-on and arbitrary to the experience, as if it was just thrown in there for the sake of it being included, and I think that's largely due to a lack of scrutiny paid not just to the individual game mechanics, but to their place in the larger picture as well. There's no "right" answers in this sort of exercise, but what it does do is highlight whether or not crafting is a good fit for a game, or if those resources would be better spent elsewhere - and in more cases than not, the answer is "yes."

Crafting Skills

More specific to RPGs is the inclusion of crafting skills in gameplay, which exist to limit the player's ability to craft in a way other than denial of resources. Much like the basic "why crafting?" question, the "why skills?" question is also of the utmost importance for ensuring whether or not a crafting system works in a given game. Even in cases where crafting fits in, the specifics, usually relating to skills, can often be over- or under-developed.

As above, when considering crafting skills it's important to ask these questions:

How does skill progression work? Does the player level up crafting separate from other skills in the game, or is the development of those skills integrated deeply into the standard gameplay?
How long does it take to level crafting? Is it something that requires a big time investment, such as gaining enough XP, or does the investment come from other parts of the game, like collecting money or crafting resources?
How are skill levels structured? Are there only a few skill levels with big benefits, or are the levels incremental with relatively small improvements each step?
Is crafting static or customizable? That is, is crafting a system that adheres to the same rules for all players, or do players customize their available options by, for instance, specializing in crafting certain types of items?
What sort of information about crafting skills is exposed to the player? Do they get to see all the minute details of the mechanics, or are they hidden in order to encourage experimentation and to create a more organic notion of improvement?
How many crafting skills does the player have? Are they mutually exclusive, i.e. only one crafting skill per player, or can the player become an expert at crafting anything in the game?
Do crafting skills compete for attention with other skills? Does the player have to, for instance, sacrifice combat ability to become a better blacksmith, or is every player guaranteed competence with at least one profession?

Some of these questions might seem a bit obvious, and admittedly they're the sort of thing that gets hammered out during development, but it is absolutely integral to answer them as early on as possible. These sorts of choices dictate the nature of a crafting system; leaving them to be figured out over time or through experimentation is setting up that system for imbalance, poor cohesion with the rest of the game, and eventually, outright failure. These questions are second only to the fundamental one of whether to have any crafting to begin with.

Crafting and Grinding

As I mentioned above, crafting is, much more often than I'd like, used in order to pad out a game and extend it beyond its worth. Much like in Japanese RPGs like Final Fantasy, where often the player has to take time out to perform repetitive battles in order to defeat a boss monster, crafting, in its lowest and most malicious implementation, can be used to restrict the player's way through the game by forcing the replay of the same game content over and over, and is even sometimes responsible for outright ruining a game's pacing and flow.

Talking about grinding is a hard thing, however. As I said above, sometimes a little bit of grinding can be to a game's benefit. Too much of it grows frustrating, but especially if it's optional content that isn't necessary to complete the game, grinding can give extra-dedicated players the sense of mastery over the game that they live for. Moreover, some players even enjoy the act of grinding itself - perhaps because it represents a sort of "safe zone" where the player doesn't have to contend with any new game mechanics or story elements, or even because it leads to a sort of "grinding zen." Quantifying exactly what the right amount is, both necessary and optional, is a very subjective thing.

Team Fortress 2's crafting system is extensive, but has begun to receive more emphasis than the core game itself.

Even so, it's fair to say that there is such a thing as too much grinding, and that extends to crafting as well as anywhere else. One game, I think, that perhaps takes the crafting grind to absolute extremes is Team Fortress 2, so much so that it has turned both myself and several friends of mine off from playing the game altogether. Even though it's a multiplayer-focused game intended to be played for years, with the crafting itself almost a metagame on top of it, the amount of emphasis given to crafting both by the developers and the community borders on absurd.

For the purposes of illustration, let me break down the process behind crafting a rare item, the Sharpened Volcano Fragment. This assumes that the player already knows how, of course.

To start, we need Scrap Metal. Scrap Metal is created by combining 2 weapons from the same character class.
Next, we need Reclaimed Metal. Reclaimed Metal is made up of 3 Scrap Metals, which means that we need to collect 6 weapons.
Now comes Refined Metal. Refined Metal requires, you guessed it, 3 Reclaimed Metals. We're up to a total of 18 weapons to hoard up.
The Sharpened Volcano Fragment needs 2 pieces of Refined Metal. That's 36 weapons in total so far.
Last, the Refined Metal needs to be combined with an Axtinguisher, another Pyro weapon... relatively rare, but considering we've burned through 36 items already, perhaps not too big a deal.

Of course, this is being optimistic and assuming that the player is a) going to keep all the weapons he/she finds for crafting purposes and b) going to find exactly the needed items. More realistically, the player is going to need two or three times the 36 weapons needed. Now, owing to some intrepid fans of the game, it's been estimated that most players will find a new item every two or three hours of gameplay, and that on average, players can only obtain about eight to ten new items per week. This means that, at minimum, you're looking at about 80 to 100 hours of gameplay just to craft this one weapon. Speaking realistically, however, it could easily take 250+ hours just to assemble the raw materials needed.

Granted, this particular item is an extreme example, and most in the game don't require quite that number. Still, it serves to highlight just how absurd a time investment is required just to obtain even a single one of Team Fortress 2's best items. Even for the more mundane items, 10 to 15 hours is not at all uncommon. Given that you'll need to give up your day job for the sake of crafting, it's no wonder that players are willing to simply shell out real money to get their hands on the items. Somewhere, Gabe Newell is rubbing his palms together and laughing manically.

Good Crafting: Case Study

After that rather depressing overview of Team Fortress 2, I'd like to take some time to gush over a game that actually gets crafting right. Risen, developed by Piranha Bytes, is effectively a reboot of the Gothic series, and shares many of the franchise's strengths, from an open world and punishing but fair difficulty curve. It also has one of the best crafting systems I've seen in a modern game, especially when compared to similar games in the genre, like The Elder Scrolls V: Skyrim.

The first thing Risen does right is that it shows incredible restraint in its crafting system: there are just four crafting skills - Alchemy, Smithing, Prospecting, and Gut Animals - and only two of those can be leveled up more than once. Leveling up crafting draws from the same pool of learning points all other skills require, and it must be done at the hands of a skill trainer. Skill trainers cost money to employ, and gold is rather rare in Risen, especially earlier on. Despite the limited number of skill levels, those skills provide large benefits for every new level gained, including new potions to brew and weapons to forge.

What?! I can't level my skills to 100? What kind of crafting system is this?

Due to the scarcity of items in the game, crafting takes on a different role than most others. Whereas in some it's just a cheaper way to get health packs, in Risen it's outright required for many of the best items in the game, from potions that permanently boost stats, to powerful swords. In order to craft, raw materials must be hunted down, and their numbers are finite. Many of the best ingredients can only be gained by defeating powerful enemies, or by exploring the darkest and most distant dungeons. Thus, crafting isn't just a matter of putting puts into a skill and hitting a button, it's about venturing into the game world and putting your in-game life in danger.

The risk-versus-reward element doesn't end there. Risen is a deviously difficult game, and early on, death is often swift and almost impossible to avoid when going against certain enemies. It's only through training, mastery of combat and acquisition of better gear that the player even stands a chance against the more challenging enemies. Because of the challenge, the player is presented with a very real dilemma: go for the combat skills and ensure survivability out in the wilds, or put points and money into crafting to gain access to powerful healing potions otherwise unavailable, or new equipment? Both health items and gear are hard to come by in Risen, and the trade-off between those two and the combat skills is a compelling one.

Last, what Risen's crafting system highlights most of all, both about crafting and more generally about mechanics, is that context is everything. All the levels, recipes, ingredients, perks and so on in the world mean absolutely nothing if the decision to pursue crafting isn't relevant, interesting, valid or rewarding to the player. Even though the system is just about as bare-bones as it gets, the crafting is compelling because of all the other elements of gameplay around it. It's often true in game design that less is more, and Risen's crafting is proof of that.

Conclusion

When implemented effectively, crafting can enhance a game in subtle ways, both deepening the gameplay experience and providing the player with options in overcoming challenges, customizing his or her character, and exporing the game world. However, it is worth reiterating that crafting, as trendy as it is these days, is not a guaranteed way to improve a game. There is such a thing as too much of a good thing, and that assumes that crafting is a fit for a particular game in the first place. Game design is often a process of throwing things at a wall and seeing what sticks, but I think crafting might be one of those cases where that mentality doesn't work.

I, for one, am hoping to see crafting fade from popularity, due to my own fatigue with the mechanics and because it's something that simply doesn't belong everywhere. I enjoy it when put in the right context, but the fact is that seeing it thrown into just about every genre of game imaginable really cheapens the mechanic, and ultimately ends up damaging many of the games it's shoehorned into. To be blunt, if it can't be done right, then don't do it at all - there are better things to spend time, money and labor on.

Sequels: Trying Too Hard?

2011-12-13T01:46:00.000-05:00

Bigger, better, more. Game developers are always expected to improve on previous titles, to move genres forward, to innovate, and to generally provide new experiences for players that they haven't seen before. Whether it's extremely high expectations for a long-awaited franchise revival, an internal desire for the developer to one-up previous games, or a publisher's want for the most impressive product on the market, you won't find many game developers who aren't interested in keeping a good thing going and improving on their prior work. There's a boundary, most will agree, and it needs to be pushed.

No more often is this attitude seen than in sequels. With every successful game that becomes a franchise, the desire, in all cases, is to provide players more of what they want, in a more refined manner, with more pleasing aesthetics, and a grander scale. Of course, this is only natural - developers want to make games that surpass their previous ones, publishers expect more sales than the original (or at least greater profit margins), and fans are ravenous for something that fulfills their desires (misguided as they can sometimes be).

However, in looking at a couple of up-and-coming games recently, a thought struck me. Though both of them are technically proficient, mechanically sound, and will no doubt sell millions of copies to their dedicated fanbases, I was left with a distinct impression that their developers were more focused on raising the bar with cinematic action sequences and appealing to the emotions of fans, to the detriment of the quality of the games in the first place. Put simply, it seemed to me that they were simply trying too hard to get my attention, to wow me, and to give me what I wanted. In an industry where often forward progress is held up above all else, it may seem strange to say, but I have to wonder that obsession is holding developers back.

Running Sim 2012

The Spike TV Video Game Awards, whatever you think of them, are one of the biggest media events for games in the mainstream today. With the VGAs, not only are the games of the past year put on pedestals for all to see, but often dozens of new games are premiered, with each publisher attempting to provide the most impressive trailers. Some of the work that shows up in these trailers is, to be blunt, nothing short of phenomenal, and shows that games are getting closer and closer to films as far as production values, writing, and direction go.

One of these trailer in particular struck me, and that was Mass Effect 3's. Though I enjoyed the first two games in the series, I wasn't a fan of the direction Mass Effect 2 took in placing action more at the forefront. Everything I've seen about the upcoming trilogy-ender has further emphasized the action, with full-scale open warfare and an invasion of Earth being the game's primary focus, if the trailers are to be believed. Mass Effect has long hinted at this sort of large-scale action and galaxy-shaping events, and Mass Effect 3 seems to capitalize on that potential.

Explore the entire city and win it back district-by-district? Don't be crazy, Shepard, there are corridors we need you to walk down and buttons that need pressing.

However, what struck me about the trailer wasn't so much the action, but how completely lacking in actual gameplay that supposed gameplay footage was. Despite the excellent graphics (no doubt making use of Unreal's newer atmosphere and lighting techniques), the focus on giving the player (or in this case, viewer) an intense and cinematic experience actually seemed to be getting in the way of the game itself. If the trailer of Mass Effect 3 is anything to judge it on, then it's a game about running in a straight line, while stuff happens in the skybox around you... and making Shepard press buttons to trigger more cutscenes.

Now, I certainly don't want to judge the game in its entirety based on less than a minute of footage, and I also don't want to suggest that there literally is nothing else to the game, because that's ludicrous. Still, it's very clear that BioWare's intent in showing off Mass Effect 3 is to wow prospective buyers with spectacle, explosions, and so on, a far cry from the first game's trailers espousing the game's dialogue system as expansive universe and fiction back in 2006. Yet this trailer had the opposite effect on me - all I can see is a sequence that dozens of developers worked on for what must have been months, and yet paradoxically, nothing is actually happening.

The original Mass Effect sold itself on its living, breathing characters and reactive dialogue. It's hard to believe that in 2012, we've devolved back to punching robots in the face.

Frankly, this is pretty upsetting to me. While I'm sure Mass Effect 3 will have plenty of redeeming qualities, showing off the game this way absolutely does not help to sell them. BioWare, no doubt, wanted to bring a level of excitement and cinematic scope to the game that they hadn't achieved in prior games, and EA no doubt want to have the hottest title of Q1 2012, and I can't fault them for that. It's extremely hard for me to look at such a sequence, though, and think of just how much effort has been expended for something of such tenuous interactivity and originality.

Of course, I'm hardly the first person to observe how the focus on spectacle and, to a wider degree, graphics, has encroached upon the ability to deliver good gameplay. It's a cruel irony that as graphics get better and better, actually building something that's fun to play around those visuals becomes increasingly complicated as the demands for realizing that vision grow exponentially. I love great game art as much as the next person, and I love to be wowed by immense graphics and lovingly-crafted worlds... but when the only thing a developer does with it is create a pretty backdrop for the player to walk a straight line through, I have to wonder exactly what the point is.

Nostalgia Trip

Sometimes, the ways in which developers try too hard to appeal to fans can have effects that are entirely separate from gameplay. Recently, I gained access to the Diablo III beta, and I've put about ten hours into it within the last week. Though I have my gripes with the game, it's hard to deny the level of detail, polish, and the sheer quality of the gameplay on offer. Where Diablo III begins to lose me, however, is in everything beyond its gameplay. Blizzard, no doubt, is under an immense amount of pressure to satisfy their fans and give them the "Diablo experience" that they all expect. How best to do that than to apply a liberal dose of nostalgia appeal to the game? It works for just about all old franchises, after all, so why not Diablo?

Let's play a little game. What sorts of things, outside of gameplay, do you associate with Diablo? I've got a few. Tristram. Deckard Cain and the Horadrim. The Cathedral. King Leoric, aka the Skeleton King. Wirt and his wooden leg. Adria the Witch. The Barbarian. The Wizard. Demons. The Den of Evil. Archbishop Lazarus. Waypoints. The Butcher. Dark wilderness interspersed with underground dungeons to plunder.

I can hear that twangy old guitar already...

If you pulled up many of the same ideas, then congratulations: Blizzard has already got you. Though I haven't played the entirety of Diablo III, of course, it's very clear from the opening of its beta that the entire experience has been systemically designed to include all of those memorable elements I mentioned above. Yes, there is Tristram. Yes, the Barbarian class makes a return, with all the favorite attacks from Diablo II. Yes, the Skeleton King is the first major boss monster you fight. Yes, there is a cave suspiciously similar to the Den of Evil, littered with the corpses of the Fallen enemies from the last game. Yes, Adria the Witch and Wirt get less-than-subtle shout-outs.

Just to be clear, I have nothing against callbacks, references, and appeals to nostalgia. I admit to getting a chuckle out of a couple of the references here and there, even though by all means Diablo III is a dark game. However, the nostalgia appeal goes beyond mere references - the entire structure of the game's early stages is based almost entirely around the original two games. It gets to the point where Diablo III stops feeling like a sequel, and more like a shallow attempt to include everything of popular recognition from the first two games; it certainly doesn't help that the reasons given for those locations and characters showing up border on nonsensical. It's as if Blizzard is less concerned with making a Diablo III than they are with making a modern, glossy amalgam of Diablo iconography.

Oh, so... we're... we're back here. Uh, again, I guess.

Beta players and members of the press have only been given a taste of the game so far, but it's fair to say exactly why - because those early stages of the game are so immediately familiar and recognizable to them. I fully admit that Diablo is not fine art; it's a game about killing monsters and taking the junk they drop on the ground. However, there's also something strangely manipulative about Diablo III's story setup and structure, like I can feel my heartstrings being tugged on, and snapping. And as I trundled through one repetitive-looking random dungeon after another, I had to wonder if all the time and effort spent on making the game so perfectly hit all those right notes was leaving the end product formulaic and derivative of its own legacy, when it should be fresh and exciting.

There's a fine line between giving fans a wink and a nod, and simple pandering, and developers need to make sure they don't step over it. Those references are good for a laugh here and there, but building much of your game on them is both limiting and tiresome. I've already played Diablo and Diablo II, and I want something new. Though I've used Diablo III as my case study here, this is one of the fundamental complaints I've had against recent Mario, Zelda, Metroid, and even Call of Duty games - all mechanically solid, and often extremely fun, but engineered to the point of exploitation.

Conclusion

I realize here that I've strayed from going into too many specifics, especially as this is a topic that deals so readily in feelings, emotions, and sensations, and not so much in cold hard facts. To some degree, I also have to acknowledge there may be an element of self-fulfilling prophecy here - I've developed certain expectations about where I'd like certain games to go, even if that's unlikely to happen, and so I'm inevitably disappointed.

Even so, I still feel it's worth saying to developers: yes, appeal to fans, and yes, improve upon the games that you love to make... but understand the risks involved in sticking too close to the beaten path. Players want to be thrilled, they want to be moved, and they want something original to experience, whether that's in gameplay or in story and characters. The more you try to capture, distill and refine that "magic" that so many players hold dear to themselves, and the more you try to impress, the more you also run the risk of looking like a child waving his or her hands about, begging for attention. A game has to stand on its own merits, and no amount of fan service or flashy cinematics will make up for that... and in the end, it may even cause more harm than good to try.

Making Game Levels Interesting

2011-12-04T01:04:00.001-05:00

Throughout the years I've spent in doing level design, one thing that's always remained largely the same for me is that it's a process of constant change and iteration. It doesn't matter what tools I'm using, or what idea I have going into level creation; when it comes right down to it, the only way to get truly great results is to keep refining and refining.

Usually the starting point is pretty similar as well: the player has to get from A to B, or fight enemy X, or has free reign to explore with several points of interest. Whatever the game genre, there's always going to be a starting point in designing a game level which is objective-driven, with the gameplay arising out of how the level facilitates and mediates the player's pursuit of those objectives.

However, while oftentimes you might have that clear start point and at least some idea of an end result in mind, usually getting to that end is a lengthy and sometimes painful process, as work is done, redone, moved about, and completely deleted as the needs of gameplay, story, and art direction change. While there is no surefire way to end up with a great game level right from the start, I've discovered a number of ideas to keep in mind that can greatly speed the level creation process and ensure that less work needs to be done in the long run.

Accentuate the Core Characteristics

Subtlety, though something to strive for, often doesn't work so well in level design, especially in action-oriented games. Similarly, realism is also great, but sometimes being too realistic can also lead to a feeling of blandness (just look out the window sometime). It's the high-impact, distinctive locations that stick with us even after we've turned the game off, and that take us away from the real world and into fantasy.

To that end, it's important, right off the bat, to identify exactly what sort of core traits and characteristics of a level are important, then play to them, and turn them into strengths. Is an environment sprawling and flat, with rolling plains and dusty roads? Are there towering cliffs and deep valleys? Is it a futuristic, alien space station with lots of curves and loops? Not all levels are going to be completely unique or interesting (a small shop in an RPG, for instance), but it's always good to have something to latch onto as a starting point.

Skyrim's vistas border on the geographically absurd, but they're what give the game so much character.

However, it's not enough to just identify those traits and build a level around them. You want the player to remember a location after he or she has left it behind, after all. I find that in almost every case, the mantra "turn it up to eleven" works best. If your level is a craggy mountain pass, make the rocks even more jagged and the path twistier than you normally would think to. If you're building a cluttered shanty town, place the shanties nearer to each other, pile up the trash higher, and stay away from providing obvious paths through the level. While this doesn't mean that you should always go for the absurd and ridiculous, taking advantage of those unique characteristics and pushing them forward just a little bit more than you would otherwise will make your levels feel like more than "just a town" or "just a factory."

Mood Through Design

Though music and sound, artistic direction and lighting can all have a big influence on the player's perception of a game level, the level design itself is often extremely important in nailing the intended mood and feel. This is one of those more subjective points, but I think it's worth bearing in mind that often the core geometry of a game level is just as important in establishing the mood of a given game level.

One of the best examples of this I've come across recently is Deus Ex: Human Revolution. The hub area of Lower Hengsha isn't just great-looking, it's also a phenomenally well-designed location. The intent is clear: a city area that feels bustling and crowded, as well as foreign and unfamiliar. By transforming what could otherwise be a fairly straightforward location into a multi-story urban jungle, complete with rooftops, streets and sewer canals, Eidos don't just make a more interesting level, they also make one that directly improves the atmosphere and feel of the location in such a way that is almost integral to it; doing the same for the game's Detroit hub just wouldn't have been right. The design is so successful that you could actually take out most of the distinctive artistic features, and you'd still be left with a level that stands out.

Human Revolution's busy, multi-level environments help establish mood beyond what the graphics themselves are able to provide.

Another, completely polar opposite example, is Fallout: New Vegas. Though there are portions of the game which take place in urban environments, most of the player's time will likely be traveling through the Mojave Wasteland, a largely flat and extensive desert stretching into the distance. Much of Fallout's appeal comes from its atmosphere, its crushing sense of desolation and bleak hopelessness. The dry, mostly barren landscape stretching out into the distance suggests not only new gameplay locations for the player to explore, but also accentuates those qualities that make Fallout what it is. Grand Theft Auto IV's comparatively dense city environment could have served the gameplay just as well, but would have killed that mood so important to the experience.

Always Keep the Player Engaged

There is nothing worse in level design to see the player running in a straight line from A to B, with little to no maneuvering required in between. Though it may be realistic to provide a path that's completely straightforward (real-life city streets rarely resemble mazes), from a gameplay standpoint, it's usually completely and utterly boring. Playing a game is all about being engaged and wrapped up in an experience, so the more you give the player to do, the better. In most games, the simple act of getting from one point to another isn't too interesting, but the more you can do to make that act fun, the better. The player needs to feel he or she is actually doing something, even if from a purely functional perspective, there's no difference.

To use an analogy, it's a bit like an animated loading screen, or the mouse cursor changing to an hourglass on a computer when you're opening a program: unless the user/player can see something is actually happening, and there is clear and obvious feedback for his or her own actions, then chances are he or she is simply going to think nothing much is happening at all. Your goal as a level designer is to avoid that feeling of nothing happening as much as you possibly can.

Left 4 Dead 2 never, ever gives the player a straight line to follow - even a few cars to jump on or climb over make a world of difference.

Though there are so many excellent examples to choose from, my favourite has to be Left 4 Dead. Rarely do the Survivors get from place to place without having to jump over something, take a side-passage around an obstacle, climb over a fence, scale a ladder, slide down a cliff, dive through a window, and more. Even without the zombie hordes attacking, just getting through a level is in itself engaging simply because of how the player is constantly called upon to do something other than walk forward.

Verticality

If there is one simple trick to making a level more interesting, it's this: stop thinking in two dimensions! Most game SDKs by default will start out with a completely flat plane to work with. Though it's easy to think "well, sure, have to start somewhere," it is surprising just how much of an impact these flat, featureless planes can have on your game levels. Flat, is, by definition, boring, and the closer your game level is to flat, chances are it's going to be less and less interesting to play. Once again, an appeal to realism is tempting (of course we don't have constant drastic changes in elevation, it's impractical), but even in "realistic" games, the hyperreal is what rules, not the real.

Creating a level with verticality in mind right from the start can be an interesting and entertaining approach. Usually, I don't do it, and those I've spoke to also tend not to think of it so much until after the fact. After all, that's kind of how we think about level design on a basic level, from a top-down perspective - especially those who have a background in isometric games, or even tabletop games. When we plan out a level, usually it's also in two dimensions rather than three, and without turning a conscious eye towards that, sometimes it's possible to build a game level and suddenly find, "hey, wait, this is a lot less interesting than it seemed on paper!"

Consider just how much more interesting Batman: Arkham Asylum becomes simply by placing enemies and objectives on multiple levels, or requiring traversal and gliding to get from place to place.

As an experiment, the next time you sit down to think out a level, try to imagine it in three dimensions, or better yet, open up your favourite SDK and drop key objective points not just at different spots along that basic 2D plane, but in 3D space, and then conceptualize different ways to go between them, even if it's just with CSG. Think about ramps, stairs, ladders, doors, windows, and all the sorts of things the player might interact with when playing the games, and how it'd be more interesting if the player entered a room by descending a staircase, or falling through a ceiling. The sooner you get stated on this, the sooner you'll have fun gameplay.

Composition & Artistic Principles

Though level design in and of itself isn't always directly connected to art, it's important enough to think about how a level will look from a compositional perspective even in the early stages when you're just sketching out a layout. You don't have to be an artist to do this, either - there's just a few basic rules to keep in mind that can make a huge difference in speeding along the level design process, and that will provide good-looking levels without waiting for detailing and lighting to get involved.

The most obvious and essential of these is, at least in my opinion, the rule of thirds. Though levels take place in 3D space, often it's easy to anticipate where the player is going to be looking at a given time - whether that's when exiting a commonly-visited location, walking a familiar road, or moving towards an objective in a linear fashion. As such, it's important to drop the camera to ground level and figure out what the player will be looking at. Building a level around the rule of thirds is an excellent way to provide visual interest and to make sure that each portion of the game world is adequately filled with something.

Always consider how compositional techniques like the rule of thirds can complement a level's aesthetic - BioShock in particular makes extensive use of it.

Though the principles of art are also a great starting point as well, some are more important than others in level design. I find that balance is most essential above all others, mostly because it can so easily be achieved early on, without relying on detailing and lighting in the same way. Whether that's providing one central point for the player to focus on, or weighing the scene equally on all sides, making sure that one part of the level doesn't completely overpower all the others is important in providing a sense of aesthetic wholeness and unity. Moreover, videogames, unlike the real world, are much more readily governed by the rules of fun rather than the rules of reality - usually a level design will actually be enhanced from a gameplay perspective as well as an aesthetic one by keeping balance in mind when building.

Of course, the most important thing to note about this section is that none of this is set in stone. The rule of thirds and other artistic principles are all well and good, but they shouldn't be used everywhere, especially where inappropriate to achieving a certain narrative goal. For instance, Half-Life 2's slow progression towards the Citadel wouldn't be nearly as effective if it wasn't literally looming over the player, and sometimes too much symmetry, or too many colours that fit together just right can become formulaic.

Conclusion

Level design is a slow and steady process, but it doesn't have to be extremely lengthy and difficult as well. Between teething pains working with tools, waiting for the right art assets to become available, and other production pipeline concerns, it can sometimes feel as if your work is never done. And while it's true that you can always tweak and play with something forever, by keeping in mind some of the points I've made above, you'll spend less time on redesigning and rebuilding your levels, and more time focusing on the details and particularities.

As usual, I've only scratched the surface of this topic, and would love to hear any more "quick tips" or fundamentals that anyone else has to share. Please feel free to comment and leave any others you might have picked up yourself!

Moral Ambiguity and Choices in Skyrim: All Setup, No Payoff

2011-11-23T11:32:00.001-05:00

While black and white morality systems have been a staple of RPGs for years now - though less because of the inherent systems and more because of poor implementation by developers - it seems that over the last year or two it's become increasingly popular for RPGs to present morally ambiguous situations for the player, in the hopes of providing more compelling and intellectually stimulating decisions. CD Projekt RED's The Witcher was perhaps the first game in this line, and shortly after, other RPG developers hopped on board, with Dragon Age, Fallout 3 and even Mass Effect 2 attempting to provide more difficult scenarios for the player that went beyond the question of "I want to be a bad guy/good guy."

With Skyrim, Bethesda have weaved a large and complex world, with rich lore that fits distinctly but unobtrusively into the existing Elder Scrolls fiction. As part of realizing this world, they have, more than their previous games, attempted to do away with the binary good and evil dichotomy, by instead presenting a number of factions for the player to interact with, both with their given political agendas and their own more human elements. However, while the setup plants the seeds for a game with interesting dilemmas with possible far-reaching consequences, due to either design limitations or oversights, instead Skyrim stumbles at providing interesting decision-making, even as it tries to provide a more realistic and morally ambiguous world.

Everyone's a Jerk but Me

The political landscape of Skyrim is defined largely by two factions, the Imperials (or more particularly, their military branch) and the Stormcloaks, a rebel army attempting to regain Skyrim's autonomy from the Empire due to perceived wrongdoings. On the surface, it's easy to see what Bethesda was going for here. While the Imperials are generally well-meaning and ensure equality for all under their laws, their philosophy also sees the individual concerns of smaller communities fall by the wayside in the name of the Empire, while the Stormcloaks, though fighting for a justifiable cause, do so often with cold-blooded murder, led by a man who seems more intent on proving his own superiority over others than truly saving his homeland.

In the mix of this are the Thalmor, a group of High Elves who control the Empire following the Empire's defeat in a prior war. This on its own presents a far more interesting situation than just the two groups, because the Empire is largely being manipulated by the Thalmor, and many of the things the Stormcloaks fight the Empire over, such as the now-illegal worship of the god Talos, are in turn dictated by the Thalmor instead of the Empire, not out of malevolence, but because the Empire will be wiped out if they don't adhere to the terms of their treaties. In many ways, the Empire is set up to take the brunt of aggression from the Nords of Skyrim, and they can do little about it without risking their own annihilation. It's a definite "between a rock and a hard place" scenario.

Is there a "make my own faction that isn't full of idiots" option?

The seeds here are sewn for interesting conflict and decision-making. Choosing to support one of the factions is a big part of the game, and determines the player's role in the game world. While both factions have good causes (the Thalmor are the only ones who are justifiably "bad guys"), their respective problems make the decision to join up a more difficult one. Much like in Fallout: New Vegas, the goal is fixated on one outcome between the two groups - providing Skyrim with peace, safety and prosperity - but they have significantly different means of handling that.

Unfortunately, in attempting to build a morally ambiguous world, Bethesda actually go overboard and by and large overshadow most of the redeeming qualities the different factions have. While the Stormcloaks are positioned as perhaps the "best" option due to their nature as freedom fighters, and the portrayal of their people as simple, hardy and well-meaning folk, it's clear that many are actually blatant racists and don't just want the Empire out of Skyrim, they want everyone who isn't a Nord to leave as well. With the Empire, it becomes clear that while they might mean well, being such obvious puppets for a larger group makes it hard to support them as well. Though many of their failings come more from what they don't do than what they do do, it's clear they have a lot of problems that simply defeating the Stormcloaks won't solve.

The human element isn't much better. Without going into significant plot details, some background revealed about the Stormcloak leader, Ulfric, casts serious doubt upon his competence as a leader and his loyalties. General Tullius on the Imperial side, on the other hand, is at least more immediately likeable, but doesn't really form any connection with the player; if I had one word to define his character, it would be "stern." When you end up questioning the faction leaders themselves, and don't have much faith in their ideals or capabilities either, what else do you have?

In the end, I find myself not really caring for any of the factions available, and I've found many others who feel the same way. While I made my choice, it felt like I was choosing the least incompetent party, not the one which best represented Skyrim and my character's beliefs. Though it's great to have choices and better still for them to be interesting, the way the Imperials and Stormcloaks are set up, it's clear Bethesda went too far in giving the groups negative traits to counteract the positives, without actually spending time to build up those positives in the first place. Good moral ambiguity in alliances makes for interesting choices, but in Skyrim, you're asked to choose between factions based not on which is better, but which one is least likely to screw things up.

You Want to do What?!

The second problem with Skyrim's moral decision-making has less to do with what it does and more to with what it doesn't do. While it's important to provide the player with factions and characters that he or she can care about and become emotionally invested in, without constantly questioning their every move and motive, good moral ambiguity doesn't stop there. A big part of that puzzle is giving the player logical and interesting choices to make that fit seamlessly into the situations the game presents, with the best decisions always being the most intuitive and clear-cut ones, rather than the most obscure.

Skyrim gets very close to this, but eventually trips over its own girth. In the city of Markarth, a massive place built on the back of a Dwarven ruin cut into the mountainside, there are two factions, though more loosely defined than the Imperials and Stormcloaks. The Forsworn are cultists (or at least religious extremists) who were pushed out of Markarth years ago by the Nords and placed under iron-fisted rule. Understandably, they now hate Nords and the corruption they represent. The Forsworn, despite being officially removed from the city, have many sleeper agents and other people on the inside working to gradually take the city back. After investigating for some time, the player is eventually framed and arrested, only to break out of prison and either kill the Forsworn leader, or help the Forsworn escape and/or help as they butcher the entire city.

Markarth is one of the game's most interesting locations, but doesn't have the quest design to to back up the art design.

On the surface, this looks like your classic situation, and admittedly, the deaths of all those people is a pretty significant outcome which has long-term repercussions. However, that's precisely what's wrong here. There are only two outcomes: kill everyone with the Forsworn and let a group of violent, dangerous cultists take over, or kill the cultists. It's pretty clear that these decisions are unreasonable and don't allow for much leeway. Pacifism isn't an option - it's impossible to persuade the Forsworn leader to give up his crusade, and it's impossible to oust the corruption of the Nords without siding with the cultists. In giving a radical binary decision to the player, Bethesda only draw even more attention to the fact that the options given are inadequate and, to be frank, highly unrealistic.

What's more, the player is rendered less an actor in the game world by such decisions, and more an observer. Much of the fun in RPGs is getting a sense of influence over the game world and storyline, and yet in Skyrim, too many quests, including the Forsworn conspiracy quest, are happy to let the player stand on by without providing any real function save for actually speaking the dialogue that sets the quest in motion. It's important not to build a game world that feels like it's just waiting for a hero to come along, but sometimes the lack of agency goes beyond the realm of plausibility and becomes irritating.

It's always easy to justify this sort of thing by saying that it'd be a lot of extra work to come up with so many different solutions and outcomes, but when your only options are "kill everyone" I really have to wonder what Bethesda's designers were thinking. Such decisions aren't morally ambiguous or difficult; they're just stupid, and their violence and bluntness is so jarring precisely because so many other options are denied. I'd be happy with those outcomes as options, but instead, senseless slaughter is mandatory, and ultimately the decision comes down to whether you want to kill cultists or civilians, not any sort of interesting battle of issues and ideals which can be reconciled without excessive bloodshed.

Status Quo is God

Skyrim loves to stick to the status quo. Though the world it provides is massive and interesting, with tons of small details to soak in, it isn't actually much of a fan of giving the player any real influence over the course of events. Despite the huge number of factions to join, quests to undertake and so on, there are almost never any long-term consequences for the decisions made. The racist Nords in Windhelm will always be racist, and you can't call them out on it or make them see the light, even if you yourself aren't playing a Nord. The feud between the two families in Whiterun can't be adequately resolved, despite it being such a strong theme of the location. This pattern keeps up for almost the entire game: interesting locations and situations are painstakingly set up by the designers, but they never actually go anywhere or provide the player with any sort of pay-off.

Nowhere is this more obviously exemplified than in the College of Winterhold. The College, located near the city of Winterhold, is rather notorious. Nords hate magic, and due to a disaster many suspect the College of causing, Winterhold was almost entirely destroyed. The people of Winterhold almost entirely hate the College as well as mages. The player is able to eventually arise to the position of Archmage of the College, and with it come a whole new set of benefits, like some neat equipment and a lavish part of the College to use as a home base. However, beyond this, very little about the gameplay or game world changes. As Archmage, you are never called upon to oversee issues at the College. You are never able to teach students, and indeed, it's possible to become Archmage with significantly less spell-casting ability than the other members there. You never have to deal with anything remotely resembling what an Archmage might actually do.

Wait... so, uh, I can't send one of my underlings to do it?

Instead, you get to a handful of new quests to undertake, including, astonishingly, menial fetch quests and the ever-popular "go here and kill a few enemies" task. As Archmage, I expect to see to administrative duties or academic ones which benefit the College and wider community, and yet everyone in the College still speaks as if my character is still a wet-behind-the-ears whelp. What's more, given the strained nature of the relationship between the College and Winterhold, it'd make perfect sense to be able to sit down and have a nice, long talk with Winterhold's leader, and try to repair relations between the two, perhaps helping to donate gold in rebuilding the city, or using magic for good purposes. Yet none of that is allowed either. In fact, despite being Archmage, the people of Winterhold are entirely at ease with my presence.

Obviously, Skyrim is a massive game, and it's hard to provide meaningful choice and consequence for every single quest line. I don't expect the game to devote the same resources to the main plot as it does to the side-stories taking place in the game world. At the same time, though, this isn't an exception - throughout the entire game you will be given interesting scenarios positively begging for your intervention, with obvious end points for their resolutions, yet it is a rare day when anything you do is reflected in the game world in even a subtle way.

Even so, this lack of impact to decisions, or lack of decisions to make at all, dulls and even destroys much of the emotional impact of these scenarios, and reduce the player's agency in the game world. It's often said that people need to see things in order to believe they're happening, whether that's the loading screen in a videogame ensuring the player that the game hasn't gone dead, or the progress bar during a program installation, and Skyrim suffers immensely from this, giving the player "implied consequence" rather than anything in the game world or gameplay itself. It is a sad irony to think that a significantly more limited game like Divinity II can give players more interesting choice and consequence.

Conclusion

Building interesting scenarios for players to enjoy is always a challenge, regardless of the game or the genre. RPGs typically have it even harder, as the amount of work required in building multiple outcomes to situations puts even more strain on a development team, and the higher standards for world design and writing inevitably invite more scrutiny. Even so, while Skyrim provides one of the best fantasy worlds I've witnessed in years, and corrects many flaws in prior Bethesda games, the sheer size of Skyrim and Bethesda's attempt at a darker and more "realistic" story and world ultimately exhaust the game before it can ever really get started at exploring the people, places, and scenarios it provides.

There are morally ambiguous situations in Skyrim, and I'll be the first to state that many of them are interesting and compelling, but rarely are players ever given the tools to explore or solve them in convincing and satisfactory ways. It's a common and integral point in fiction to never introduce concepts and problems that the setting itself can't sustain, but Skyrim does the opposite: it provides an extremely rich setting and then fails to do anything particularly interesting with it. For all the improved atmosphere, art direction, and some of the most interesting backstory and lore I've witnessed this year, it is a bitter irony that Skyrim undermines so many of its own strengths.

User Interface Analysis: Skyrim

2011-11-14T14:14:00.001-05:00

In my previous article, I took a pretty scathing and critical look at Skyrim's PC user interface, as well as some of the issues with the port in general, such as poor performance. Bethesda released a day-one 1.1 patch just after I had written the article, which fixed a number of the interface problems (such as inconsistent keyboard and mouse controls), but it's clear that the shipping version of the game still had some major problems, and likely that quality assurance fell by the wayside in order to hit that majestic "11/11/11" shipping date.

Though user interface is something that one can write books on, and indeed has been the subject of a number of my previous articles, Skyrim's user interface is something which I feel deserves specific scrutiny beyond the PC compatibility and usability complaints I voiced. Indeed, Skyrim has quite possibly one of the worst and most incompetently designed interfaces I have seen... well, to be frank, ever. Skyrim, the game, is one of Bethesda's best works and a substantial improvement over previous ones, I do want to stress... but actually interacting with the game is an exercise in frustration, and the interface itself violates so many fundamental design tenets that it's downright upsetting.

Oblivion and Fallout 3, it's fair to say, did not have the best user interfaces. Their layouts were a bit confusing and inconsistent, there were too many tabs, menus, nested menus, menus with multiple pages and sub-screens, etc. Moreover, in Fallout 3, close to two-thirds of the screen space was taken up by the Pip-boy 3000, a fancy model with lots of shaders which had precisely no gameplay function whatsoever (but it sure did look neat, huh?). One would think that after these two instances, Bethesda would go back to the drawing board and try to improve things for the better.

Initially, it looked that way. Bethesda's bold new iPod-esque design, with plenty of clean, futuristic fonts and scrolling "cover flow" menus was clean and seemingly efficient, removing a lot of the excess baggage of previous menus and more effectively organizing information. It's fair to say that this is one of the most radical redesigns of a user interface in a modern console game short of Fable III's interactive 3D Sanctuary. However, like Fable III, Skyrim completely forgets that conventions exist for a reason... and demonstrates that Bethesda really have not learned very much about designing interfaces at all.

Poor Use of Space

The first, and most glaring fault, and a problem shared with their previous games no less, is an almost criminal misuse of space. Though the heads-up-display is minimalistic and efficient actually getting into the menus demonstrates an almost complete ignorance of even the most basic design rules.

Upon opening up one of the game's menus (inventory or magic are the two most common), one is greeted with a single sidebar on the left or right side of the screen, containing a list of categories. While there are ten distinct entries on the inventory list (depending on what types of items the player has), the default position for the list is not at the top of the screen, but at the center of the screen. While this is immediately more readable, it quickly becomes apparent that not all entries can fit on-screen at once. On a gamepad, this means that sometimes you'll need to do additional scrolling to be able to read some of the additional items in the menu. On the PC, you'll need to actually scroll the list just to be able to click on the items that fall off-screen, even though there is more than enough real estate on screen to click each of them.

Despite all that extra space up top, the default list position makes no use of it whatsoever.

Actually selecting one of these categories will reveal a second menu which lists all items within that sub-category, i.e. potions or weapons. However, whereas a single column works for the smaller, ten-items-at-most list for inventory and magic categories, for the items underneath, it's a complete disaster. While only a few items won't put any stress on the format, when you have potentially dozens or even hundreds of items, as in the case of various potions, ingredients, food items, and so on, this misuse of screen space and fixation on adhering to a specific aesthetic means that sometimes it can take ten seconds or more to even reach the item you're looking for. Adding another column would have mitigated the problem almost entirely, and placing the default list position at the top of the screen rather than the center would have further reduced additional scrolling.

Finally, there's the item or spell display itself. Though it likely seemed a good idea at the time, over 50% of the screen space is taken over by a 3D model or particle effect of a given item, with attributes and a short description taking up close to 20% of the entire usable screen space. Why this is, I cannot fathom. Most of your time in the inventory will be taken up scrolling through items, not staring at 3D models. Furthermore, a separate option to examine the models in detail already exists - so why do they take up so much room by default? I imagine the goal was to show off those pretty models their artists no doubt worked very hard on, but to devote so much screen space to such a non-essential function is a major interface slip-up.

Text vs. Pictures

One immediately apparent characteristic of Skyrim's menus is that they almost entirely eschew pictures, instead replacing everything with text, sorted alphabetically in most cases. This is a trend I've seen in a lot of modern games lately, and is often sold as "getting rid of the Tetris inventory" or the more general "streamlining." Unfortunately, such a mode of thinking completely misses out on some of the many advantages that pictures and icons have over text.

While smart sorting options and using text aren't outright bad decisions, I want to stress, text, especially on a TV screen where real estate is more limited, takes up significantly more room than icons can, and have the immediate downside of being less easily identifiable. Those lengthy lists which define Skyrim's menu systems could take up half the space if more traditional and RPG-like inventory icons were used instead - and it would have further eliminated the need for a large 3D model to take up the majority of screen space.

One of the most defining features of RPGs, especially in the West, has been a paper doll feature, or a graphical representation of the in-game character. Traditionally, this was done (even in previous Elder Scrolls games) due to technical limitations, as highly-detailed and unique sprites were often beyond the graphical capabilities of many game engines. Over time, this practice has generally waned, mostly because modern games are able to display a high-detail 3D representation of the player character anyway, either during gameplay or in cutscenes.

Though clearly not optimized for a gamepad, Icewind Dale and other Infinity Engine games accomplish far more with pictures than with text.

Though the paper doll was initially included in games as a compromise, a way to have a customizable character without needing to create high-detail animated sprites for every possible combination of races, sexes, equipment, clothing, and so on, it also ended up serving a very important purpose as far as user interface goes. The paper doll, more than just a vanity, helped to instantly and immediately express exactly what items a player character had equipped - what suit of armor, what weapon, what magic amulet, and so on. When coupled with an "equipped" inventory sorter of some variety, it meant that players could quickly and easily figure out what items they had equipped at any given time, literally at a glance.

Skyrim removes the paper doll function entirely in favor of the aforementioned 3D models, and the result is that it's actually harder to figure out what one's character is using at a given time. Playing as a warrior, unless I have my weapon at the ready, I genuinely have no idea what I have equipped, potentially until it's too late and I meet the game over screen. Playing as a mage, unless I have my spells at the ready, I have no idea what I can cast at a given moment, leading to much mashing of hotkeys - and furthermore, as many spells share similar visual effects, often I find myself casting the wrong spell for a situation because I can't even tell them apart until I've fired them off.

Comparing the interface in Skyrim to the interface in Icewind Dale, it seems that the old Infinity Engine was capable of producing a more immediately usable, quicker, and more attractive interface than all the modern technology and theft from Apple in the world could. The pictures look good, it's easy to see what each item is, there are reams of more detailed information to be had at a single mouse click, quick-slots are easy to set up, and it's never a mystery what items I have equipped. Even Arena did some things better than Skyrim, and that was over fifteen years ago.

The Worst Screen in the History of UIs

The above title is not hyperbole. I think that Skyrim has genuinely managed to lay claim to the title of "worst interface element ever made." It comes in the form of the skills menu, used primarily for leveling up. It violates almost every single rule about designing user interfaces, and it does so for only one reason - to show off a pretty picture.

Among many other problems, the skills screen doesn't even give you an idea of how many skills there are to choose from.

The gimmick with the skill screen is that it resembles a number of constellations in a night sky, with each constellation representing a specific skill. I was under the impression that in previous Elder Scrolls lore, it was birthsigns that were the constellations, but I guess that idea was thrown out the window as birthsigns have been removed in Skyrim. But I digress. There are honestly so many issues with this screen that I am just going to list them one-by-one.

It's impossible to see all the skills at once. Want to know what your skill level in something is? Prepare to do some additional left and right scrolling. Depending on what skills you use, this could mean several seconds and close to a dozen discrete inputs to move the list along to where you want it.
It wastes a lot of extra screen space. By linking each of the headers to an image, instead of, say, displaying multiple rows or a vertical list with independent images, the numer of items on screen at once is further limited.
It needlessly violates conventions both in games and in the real world. From an early age, we are taught to read information left to right, and to list items top to bottom. This convention may not be the ultimate in organization, but it works and most players are going to be used to it. Instead, Skyrim presents a left-to-right list of items which is completely counter-intuitive to our existing understanding of how lists work.
The default point is the center, not the left side. Though it may seem more intuitive to place the currently-selected skill in the middle of the screen, in actuality it creates more work for the player, as the eyes have to travel both left and right to view other skills.
The list scrolls both left or right, meaning there is no "starting" point to go from. Usually in a game I want to know my information is organized in some sort of coherent way, but in Skyrim, the left and right scrolling ruins any spatial organization of information players might have. Furthermore, anything that's off-screen might as well not exist at all, so if it's not immediately visible, you probably won't have a clue of exactly where it is in relation to the other items.
On the PC, the controls are baffling and awkward. Mouse clicks only move the list one position left or right. Think you can click on one of those far-off items to select it? Too bad. I mean, really, what do you think that mouse even is, a cursor or something?
When it comes time to inspect the perks in the skill trees themselves, or level up, only one perk's details are visible at one time. This makes it impossible to view information at a glance, and furthermore means that it's harder to compare different perks to one another and weigh trade-offs.
You have to go back from the perk menu to change to a different skill. The way the controls are set up both on PC or gamepads, using the usual "back" button actually closes the entire skills screen, rather than going back to the main list. Why the needless break from convention? I certainly couldn't tell you.
Navigating through different perks is a tedious and difficult process. Rather than using a list, perks are represented by stars in each constellation, and must be "traveled" to using the analogue stick or mouse pointer. If you're imprecise with your movement, be prepared to waste time as you travel to the wrong perk selection. Furthermore, it takes around two seconds to move from one perk to the next, which itself can grow irritating if you want to find something at the opposite end of the perk tree.
UI elements and camera perspective can actually block out perks that should be visible. Instead of being able to see all the perks at once, the angle of the camera means that only a handful of them are even visible in the first place. In some cases, such as the "Perks to increase" counter visible in the screenshot, the titles of perks that should be visible are actually blocked out entirely, requiring additional scrolling.

I honestly do not know who designed this portion of the interface, but it has so many elementary problems that I have trouble understanding how it even made it into the game - surely, somewhere, someone must have said "you know, this doesn't really work well"? And yet it didn't - it's in the game, and players have to suffer through it.

As if scrolling everywhere wasn't bad enough, doing it in different directions presents its own share of issues.

I have a pretty good idea of what likely happened. Somewhere, a designer came up with the idea... "it'd be cool if there were constellations, with all these stars on it representing skills." Then, some artist whipped up a neat concept that looked really pretty, and everyone was on board. However, in not sitting back and asking exactly how it would work from a user interface perspective, what the trade-offs were, and so on, the result was something not at all enjoyable to use, or intuitive. Developers sometimes get married to an idea they really like, to the point where it can sometimes interfere with the rest of the game... in this case, Bethesda's designers were probably dead-set on this idea. As a result, one of the game's more important interface elements was utterly ruined... all for the sake of a pretty picture.

Conclusion

I again want to stress that I have been enjoying my time with Skyrim. The game is great, it's a lot of fun, and aside from my complaints with the interface and the PC version of the game, it really is a great experience compared to previous Bethesda titles.... and for what it's worth, there is one thing about the UI I do like - the mouse/stick gestures for selecting menus does work very well. I also don't want to point any fingers at anyone in particular; I don't work for Bethesda, I don't know their company culture, and I don't know who makes exactly what decisions, or how much freedom and back-and-forth there is.

Even so, I have trouble understanding how such a, frankly, amateurish user interface ever made its way into a supposed triple-A game. If Bethesda don't have a dedicated interface designer or engineer, then it's clear they need to get one as soon as possible. If they're willing to sacrifice so much functionality and usability for the sake of aesthetic gimmickry, on the other hand... well, then I think maybe there are deeper problems at Bethesda that the company needs to work out, and in a way which doesn't leave their players saddled with the soiled fruits of their experimentation.

k-e-r-soc-problems-errors-help/306862-show-your-fps-ingame-step-step-instructions.html

Skyrim, or How Not to Make a PC Game

2011-11-11T13:37:00.001-05:00

As with many, I have been looking forward to The Elder Scrolls V: Skyrim with both intrigue and trepidation. Bethesda Softworks have long been a developer who both baffle and amaze in the most extreme of ways, and usually one has to overlook a lot of problems and outright bad design choices when it comes to their games in order to have fun (or install a thousand mods). As a PC player, I generally expect Bethesda to deliver, if not the most polished and native PC games ever, at least a degree of quality that allows me to play their games without too many issues.

After spending a couple of hours with the game, there's no other way for me to say it: Skyrim is one of the worst PC ports I have ever had the displeasure of playing. Though many issues will likely be fixed and improved as time goes on, and undoubtedly mods by more enterprising gamers will help additional problems, the release state of Skyrim is, frankly, inexcusable. "Appalling" is not a word I use too lightly to describe a game, but it's the only one that fits here.

User Interface? What's That?

After Fallout 3's interface left me with a bad taste in my mouth, I wasn't expecting Skyrim's interface to astound - indeed, preview footage lead me to believe that it was a classic case of Bethesda once again trading in functionality for looks. Fair enough, that's nothing new. I can struggle through the UI, even if it's a bit wonky, until someone comes out with a replacement. Unfortunately, Skyrim's PC user interface is quite possibly the clunkiest and most difficult I have ever seen in a game made after the DOS era. I have played games from 1985 that were infinitely more usable than Skyrim; that a modern game makes so many elementary mistakes suggests a certain kind of malevolence, not simple laziness.

The first sign things aren't as good as they could be comes before the game even begins. The main menu is as sparse as can be, but is lacking features as basic as the ability to change settings before jumping into the game. Why is this the case? I can only speculate, but it probably would have required Bethesda to edit a couple of lines in an XML file somewhere, far too much effort to even bother considering. Things take a nosedive soon after, as one realizes that not only are there standard menu items missing, but that the mouse doesn't even seem to work. That's right, the first time you boot up Skyrim, you won't be afforded the luxury of using the mouse to start the game - you'll have to use the arrow keys like a schmuck.

Despite what it looks like, that "X to Delete" is not a button. Also: click the load button and decide you want to go back? Have fun figuring out how (hint: Alt+F4 is easier).

From there, things don't get much better. After the game's highly scripted, lengthy and almost entirely non-interactive introductory sequence, you're called upon to create your character... only once again, something as simple as "mouse controls" was apparently too difficult to implement, as the dozens of sliders that allow you to customize your character to your heart's content can only be manipulated with the keyboard. Bafflingly, turning between pages of customization options can be done with the mouse, but the settings underneath won't budge.

This inconsistency in where the game allows mouse controls extends to the main game even once you're past all the introductory stuff. Many critical game functions, such as manipulating the world map, or assigning favorites and hotkeys, can only be done on the keyboard, while other shortcuts work just fine. The game is also quite poor at communicating certain information in the interface itself (the first time I went to a shop, I accidentally bought a ton of equipment because it wasn't clear if I was buying or selling), but those are more general interface concerns I'll save for another time to pick on.

Other issues, like mouse acceleration being forced on and impossible to remove without an INI tweak, or the game defaulting to "Xbox 360 Controller - On" when started, even without a controller plugged in, or needless breaks from convention ("Tab" instead of "Esc" to exit menus) show just how little thought or care was put to the PC version's interface, and how little priority was given to this version in the game, or foresight given to what its players might want and expect.

"Customize" is a Four-Letter Word

Heavily tied to the horrendous UI design in Skyrim's PC port is the incredible lack of foresight demonstrated in the game's various customization options. Some of these things, such as the inability to change certain game settings in-game, are unfortunate, but predictable considering previous Bethesda games. There are, however, yet more problems which are clearly the result of extreme incompetence, ineptitude, or laziness, which extend to the most basic functions of the game.

Key remapping is something that you'd think would be a standard feature in a game, and that would work. Bethesda, it seems, have decided that getting such a feature working isn't critical to releasing a triple-A product. Though key remapping is in the game, whether or not it actually works properly is a crapshoot. Many functions in the game can't be remapped, whether that's certain hotkeys or interface elements. Fair enough - it's unfortunate, but not all games allow for player-customized hotkeys, so I can forgive Bethesda for that.

The "Favorites" menu is reserved for those who avoid the temptation to rebind their keys. No spell for you!

Less forgivable is that many key bindings outright conflict with other interface elements and can almost entirely break the user interface of the game. After setting up my standard "Bethesda game" control scheme that I've been using since Morrowind, I found almost immediately that those controls were incompatible with Skyrim. The first sign something was wrong was when I went to "loot all" from a container using the hotkey of "R" and found that my camera perspective swapped to third-person. Okay, whatever, rebind the third-person camera key, no big deal, right?

Unfortunately, things soon became worse. After rebinding the hotkey for the Favorites menu to "F" and the auto-walk key to "Q", I found that Favorites menu didn't want to open anymore. Curious, I pulled up my inventory and tried assigning some items to the Favorites - only it didn't work. I spent the first hour of the game assuming the Favorites menu was completely non-functional, maybe because I hadn't unlocked the ability to use it yet or something. Turns out, the "F" key is holy ground - because it controls the assigning of items to the Favorites menu, rebinding it to perform another function during regular gameplay, even a related function, makes it impossible to assign items and spells to it. The Favorites menu, I should note, is a critical component of the game and outright necessary for any sort of convenience when using a large number of weapons, items and spells - that this bug wasn't caught shows a severe lack of play-testing on Bethesda's part.

Console = Cheater

Using the console in games to manipulate quest variables, add items to the inventory, to noclip through walls, and so forth has been a standard practice of players for many years, and even more so for Bethesda games - not because Bethesda players are damn dirty cheaters, but because the number of bugs in Bethesda games almost necessitates the occasional use of the console in order to avoid running into problems, whether that's getting stuck on the terrain, a critical item being lost or disappearing, or a quest not functioning properly. Again, no hard feelings; it's an open-world game and sometimes things can go wrong.

Except it seems that Bethesda would rather not have its players making any changes using the console. While it is fortunately enabled by default (unlike many other games), even so much as hitting the tilde key ("~") is enough for the game to permanently lock the player out of the Steam achievements the game so readily boasts as one of its key features. That's right: get stuck in a Bethesda game due to a bug, and you have to choose between getting un-stuck, or losing out on your achievement. Granted, restarting the game and avoiding the tilde key will allow you to continue on to earn achievements, but this introduces an additional level of tedium, as you'll need to restart the game every twenty minutes because you explored just a little too much in an Elder Scrolls game.

Should you "accidentally" fry a quest-critical NPC, you'd better not try using the console to bring him back to life. Cheater.

This change was actually added in Fallout: New Vegas, because some players criticized Bethesda for their leniency regarding Fallout 3's achievements. In Fallout 3, the achievements were actually unlocked using a set of console commands, just like manipulating any other standard game variable, so players could simply type in a few commands and get their Gamerscore maxed out. Bethesda's response at the time was apathy, but apparently the outcry was great enough that they introduced the "console commands = cheater" measure in New Vegas.

However, what was a bad design choice then is still a bad design choice. I can understand maybe they had to put such a restriction in place due to technical limitations in the New Vegas engine, but when Skyrim's new "Creation" engine has been so hyped up, one would expect it'd be possible to introduce some sort of counter-measure to prevent cheating, without forcing players to avoid the console entirely. Apparently, expecting this was too much, and so now players who want to get around bugs in the game are being inconvenienced and punished for it, either by being denied their achievements, or by repeated game restarts.

There's another big problem with such a system. I'm a gamer who's fairly sensitive to field-of-view; as a long-time PC player I'm comfortable with a standard 4:3 field-of-view of 90 degrees, and occasionally can tolerate lower FOVs depending on the game (I'm much more comfortable with low FOVs in third-person games than first-person ones). In order to change the FOV to a usable setting in Skyrim, I have to use console commands... which in turn means that I have to choose between basic playability, and achievements plus motion sickness and disorientation. Thanks, Bethesda.

Bomb the QA Department

One final damning point about Skyrim's PC port - it's horribly, pathetically optimized, and has major compatibility issues. Right from the bat, I knew that something was wrong when my high-end system was getting framerates in the low 20s from time to time, and when performance did not improve upon lowering the graphics options. Things became even more suspicious when I realized that there was no rhyme or reason for any of the framerate drops - whether I was outside in the overworld, the terrain stretching into the distance, or inside a tiny shop the size of a prison cell, the game's framerate fluctuates all over the place. There's no question about this: Skyrim is badly optimized.

A second issue I immediately ran into was an intense audio distortion - crackling, skipping and popping most commonly heard in dialogue, but also in many of the game's environmental sounds. No in-game audio options helped and there seemed to be no relevant settings in the game's INI files to help. On a lark, I went to my Windows Sound Properties page and dropped my sound card's bit rate from 96,000 Hz to 44,100 Hz. Instantly, the problem was gone - and instantly, I was frustrated at the fact that once again, it was clear Bethesda had foregone so much as basic compatibility testing.

Dragons? Pfft. This bread is the most challenging scene Skyrim has to offer your video card.

While my problems from there on out were smaller, I've heard of a number of people have experienced severe graphical glitches, including corrupt textures, anti-aliasing incompatibilities, and strange flickering black marks across the screen while playing, all of which hint at a rushed and completely apathetic release with very little testing. This goes beyond basic optimization and into the realm of "did not even make an effort." If Bethesda think that this product is fit to sell, then Bethesda are clearly not fit to receive a single penny from me in the future.

All of the preview footage for Skyrim I'd seen was for the Xbox 360 version, with the PC version only featured in screenshots. Many PC-focused web sites were reportedly denied their own review copies from Bethesda, as well, and in all those glowing 9/10 and 10/10 reviews, the PC version was either downplayed or not mentioned at all. Now it's clear why - it's because it is at best a half-functional, poorly-performing wreck of a game.

Conclusion

"Mods will fix it" is a phrase commonly uttered when Bethesda games are mentioned, and it's certainly true that their often-buggy and occasionally-broken games have been substantially improved by their extremely dedicated fan community - I probably would not have got through Fallout: New Vegas or Oblivion if it wasn't for the countless hours fans spent overhauling the game's interface and fixing the bugs Bethesda refused to officially acknowledge. Even so, Skyrim's PC release is a new low for Bethesda - it's not that the PC version was a low priority for them, it's that it was no priority at all.

As a PC gamer, it's hard to get my hopes worked up these days. I've suffered through too many awful ports and broken games to expect every single title, especially one with strong console roots. Even so, Bethesda have a strong PC history and their biggest fans have always been on PC, making their occasionally-great games even better. But with Skyrim, it's clear Bethesda don't care too much about the fans that made them in the first place - not even enough to provide them a functional product. Considering recent comments made by Bethesda's publishing side, and the poor quality of Rage on release, I'm not sure which part of the company is to blame.

I wish I could say that this was an isolated incident, but in truth, it reflects on the sheer apathy the games industry has towards the PC platform, even as many publishers come out claiming that they care about the market and that it's a priority for them. If this is what things look like when developers and publishers supposedly put in an effort, I'm not even sure why I'm playing games anymore at all.

Opening Analysis: Morrowind

2011-11-09T15:07:00.003-05:00

Earlier this week I took some time to lament what I feel is the lack of strong design in sandbox games. In it, I used The Elder Scrolls III: Morrowind as an example of, effectively, a game that gets "sandbox design" right. Truth be told, however, there's more I'd like to say about Morrowind, especially in the lead-up to Skyrim's release, as not only do I think it's one of the best-designed sandbox games ever made, but it also serves as a fantastic example of how to build a game introduction and tutorial sequence which all designers can take something away from.

Show, Don't Tell

Morrowind starts out, as is rather customary for the Elder Scrolls games, with the player as a prisoner, this time aboard a ship on the way to Vvardenfell. The introduction, especially by modern standards, is surprisingly sparse: the player's view fades in as he/she comes to, watched over by a Dark Elf, who gives similarly sparse words on the present situation. From there, an Imperial guard approaches and commands the player to follow on deck, where he/she must select a race before proceeding on.

Immediately, Morrowind is smart enough to adhere to one of the most important tenets of good narrative and good game design: namely, show, don't tell. Most games would be content to begin with a lengthy backstory and cinematic opening setting the stage, a huge wall of text for the player to absorb as an orchestra swells in the background, or a completely non-interactive scene full of action, violence, destruction, death, and so on in some attempt to evoke an emotional response.

Morrowind's opening scene immediately establishes fundamental qualities of the game world and its characters.

Morrowind does none of that. Instead, it allows the player to slowly absorb the world and take in the situation. The Dark Elf at the very beginning implies that the world the player is entering is irregular, different from the standard Roman fantasy theme of the previous games in the series, or regular high fantasy for that matter, while also hinting at the location itself (largely populated by Dark Elves). The initial treatment by the Imperial guard and his strict, brief orders suggest the player is of a low caste or otherwise in a position of little power or authority, and the difference in appearance between the Imperial and the Dark Elf also implies a degree of race and class distinction which forms the undercurrents of Morrowind's game world.

Without directly saying anything, we are already able to learn a lot from the opening of the game... an opening which has gone on for less than two minutes, with minimal dialogue, no cinematic cutscenes, and no violence or ham-fisted attempt at drama.

Suggestion, Not Coercion

From the docks, the player is brought into a census office for the rest of the character creation process. While perhaps not the most clever character creation process ever, it does its job well and gives the player an overview of all the stats, character classes, and so on. Afterwards, the player is told to head on out, with scant tutorial messages going over the most fundamental of controls, like interacting with objects and equipping items. During this sequence, the player can search a conspicuous barrel to find a magic ring, and will likely equip it before moving on. After an exchange with another Imperial guard, who instructs the player to deliver a package to Caius Cosades in the nearby city of Balmora, with a suggestion given to take the nearby Stilt Strider, a massive insect-like creature used as transportation around Vvardenfell.

At this point, the game is completely open. The player can go anywhere, talk to anyone, and do anything, completely ignoring the main storyline if he or she chooses. The entire introductory sequence is over in about five minutes, with several of those minutes devoted to the necessary task of character creation. While the game does push the player in a certain direction, and the suddenness of the situation certainly encourages the player to follow the recommended path, the game does not force the player to do this, even though at this point the game has given only the barest of tutorial functions. Instead, Morrowind expertly crafts an opening scenario, using its first locations, the structure of its opening quests, and the tasks the player is given to do the rest of the teaching.

Fargoth is one of the first NPCs the player encounters, and interacting with him teaches more about the game mechanics than a dozen tutorial messages could.

This becomes abundantly clear in the opening town of Seyda Neen (whose name and details the player can learn from speaking to NPCs in the world). Going back to the magic ring found earlier, one of the first characters the player will spot is Fargoth, a Wood Elf lamenting his missing ring (who is conspicuous in being quite short and rather foppish, ensuring many players will speak with him). The player, had he or she found the ring earlier, is given the option to hand it back to its owner. If so, Fargoth is overjoyed and thanks the player profusely. Even this simple exchange teaches the player a number of things about the game and its world:

Morrowind is full of different races. Only a few minutes into the game and the player has already witnessed Imperials, Dark Elves, and Wood Elves, as well as potentially others in the area, such as Argonians and Khajiit.
Exploration can and will be rewarded, and the player should make it his or her business to talk to everyone and examine everything in the world closely, because it might be important.
Similarly, the player learns that prior actions can have consequences even if they are unforeseen.
Dialogue topics can grow, expand, and lead to one another as the player learns of new things to talk about in conversation - if the player goes on to talk to other NPCs, he or she will notice that those topics persist to those NPCs as well, representing a growing knowledge of the game world.
The player has choice in how to deal with various situations, and will receive different outcomes depending on this. In this particular case, the player must have a choice between a magic ring and a less tangible reward, which might also tie into the player's own role-playing fantasy of his or her character.
Doing good deeds will increase one's reputation on a character-by-character basis, while bad deeds will lower it. This is plainly demonstrated in Fargoth's disposition level drastically increasing or decreasing depending on whether the player gives Fargoth the ring or denies it.
Though not explicitly stated, the mere existence of a disposition mechanic, along with its change, with noticeable differences in Fargoth's dialogue and behavior toward the player, implies that disposition is an important part of the game and will have more significant effects later on.

All of this, the player has been taught with a single encounter with a completely insignificant and minor character, which may or may not even occur depending on prior decisions the player makes. No tutorial pop-ups, no hints, no quest compasses or big arrows pointing over the heads of NPCs to indicate they're "important." Morrowind presents a scenario and leaves the pace and way forward up to the player, trusts the player to make a series of decisions, and, should the player not follow the intended path, then it's no big deal, he or she will learn later down the road anyway.

This is the absolute best kind of tutorial - the kind that teaches the player something not just by incorporating it into gameplay, but in a way which feels natural to the player's own sense of discovery, rather than imposed upon him or her by a designer who assumes the player is too dumb to play the game the "right" way.

A World to Discover

Once the player has got his or her footing, one of the more significant choices presents itself: how to get to Balmora? The player is given the option of taking the Stilt Strider for a modest fee (which, by the way, has its own minor side-quest uncovered further use of the persuasion system, and also establishes the importance of currency in the world), which is the easy and faster route... but it's also the least appealing, especially because in order to actually get to the Stilt Strider, the player will likely travel down a path, and find him or herself at a crossroads - in one direction, the Stilt Strider, and in the other, the open world waiting to be explored (with a nearby sign pointing the player in the direction of Balmora, no less).

View of Seyda Neen from the docks, including the Stilt Strider. Reaching it requires the player travel just outside town, and in turn be tempted to explore the world. Why ride when you can walk?

Even something as fundamental as the placement of the buildings, the direction of the road and the implied decision between the two routes all serves to reinforce that Morrowind is a game about choice: in this case, the doubtlessly more dangerous, but also more interesting and potentially profitable route through the swamp, or the quick, safe, but uneventful route via Stilt Strider.

Indeed, the player will shortly be rewarded upon wandering out into the wilderness just outside of town, with easy combat against Mudcrabs (the game's most basic enemy), as well as an interesting encounter wherein a man falls out of the sky and promptly dies - searching him reveals a few "Icarian Flight" scrolls (giving a taste of the powers magic will provide the player later on, but also likely ending in a swift death if used carelessly), and some fancy clothing to put on. Almost immediately, the player sees the benefit in exploring versus taking the quick and easy route, but is also introduced to different types of danger in an entertaining and relatively consequence-free way. From there, the player comes across the first optional dungeon just off the beaten path, and plenty more, all while still being able to follow the straightforward road (signposted for convenience) and reach the main objective in Balmora.

Upon arriving in Balmora, the player will likely be taken aback by the size of the city, which is much larger than Seyda Neen, without necessarily being intimidating or hard to understand. The first buildings the player comes across upon arriving are likely shops, useful for offloading any unwanted equipment gained on the way over; if the player took the Stilt Strider, instead he or she will be treated to a nice view of the entire city from a high vantage point as something of a consolation prize. Finding Caius Cosades in such a large place is difficult, so the player, likely in recalling previous interactions with NPCs, will find that asking for directions to his house yields useful information (reinforcing the value of talking to characters in the game world without making it mandatory).

Balmora is just large enough to get lost in, and requires the player take some initiative and employ the lessons learned in the first town to move the story forward.

After meeting Caius, the initial quests will send the player off to buy better equipment (introducing the bartering mechanic if the player hasn't already figured it out), to sleep and rest (with a good chance the player will level up if he/she previously explored the outskirts of Seyda Neen), to the Fighters Guild (triggering the first quest-related dungeon-delving), the Mages Guild, and so on. Importantly, in exploring the Mages Guild and Fighters Guild, the player is introduces to two fundamental character archetypes and philosophies, given a goal to strive for (mastery over martial or magical arts), and is allowed to join them and take the first steps in more substantial side-quests, which provide their own substantial rewards, a taste of combat, and require the player to do more exploration and investigation, as a bit of a test in learning the game's mechanics.

Suffice to say, the end result is effectively the same each time: the opening quests, interactions, and locations of Morrowind are all set up in a masterful way with the sole purpose of teaching the player about the game world, the game mechanics, and, provided the player has a bit of ingenuity, will also lead to additional rewards for above-average perseverance and exploration. Everything you need to know about Morrowind is gradually doled out, not through endless tutorial messages, NPCs yelling orders at the player, or forcing the player down linear corridors, but simply by playing the game itself in the most natural and exploratory way possible... and it does so without ever actually forcing the player to do so. When contrasted with Oblivion's opening sequence, an hour-long dungeon full of exposition, following NPCs from door to door, a tutorial pop-up every minute, and a contrived, almost arbitrary introduction of the main plot, it's hard to believe that the same developer is responsible for both games.

Conclusion

I really could keep going on with this. Morrowind's early-game pacing is near-perfect and an amazing example of how to build not just a tutorial for any game, but also how to create a sandbox world with structure, cohesion, and which rewards the player in a way that doesn't feel like a dog being thrown a biscuit. I often see deep analysis of the introductions and designs of some of the most famous and historically important games - Super Mario Bros., The Legend of Zelda, Mega Man, Castlevania - and rightly so, but rarely do I see this sort of thought given to more modern games, which is a real shame in my eyes, because as games become larger and more complex, the need for intelligent design and direction only grows.

Hopefully with Skyrim, Bethesda will be able to recapture some of the design magic that makes the opening of Morrowind so great, and more generally, that other developers will be able to recognize and take away aspects to incorporate into their own games in the future. Building an open-world game is a massive undertaking, but as Morrowind demonstrates, putting it together and presenting it to the player doesn't have to be a task performed with an iron fist, or left a guessing game.

Sandboxes and the Rebirth of Grinding

2011-11-07T16:03:00.004-05:00

With the release of The Elder Scrolls V: Skyrim just a short week away, many gamers are stoked for what they feel is the return of the king of sandbox games. More so than being a competent RPG, Skyrim and other Elder Scrolls titles are concerned with providing players with huge, open-ended experiences where they can play as the characters they choose, and set their own goals for gameplay. I, for one, am looking forward to seeing what the end product actually looks like once it hits shelves and the hype dies down.

More generally, though, sandboxes are all the rage these days for a variety of reasons. The first is simple market trends - publishers are happy to adopt any characteristic they think might help enhance their games. Second, a lot of players appreciate the feeling of control they have over their experience by being able to play in the way they choose. Third, on a more esoteric, design-oriented level, sandbox games bring us closer to that nigh-unattainable ideal of a game which is able to provide us a truly interactive, responsive, and entertaining virtual world.

However, truth be told, I am not at all satisfied with the design of modern sandbox games, whether they're shooters, RPGs, or platform games. While many of them are still enjoyable to play through and provide a large degree of freedom in what tasks the player is able to perform at any given time, I find that the modern sandbox design falls victim to significant problems - chief among these concerns, and the one I will focus on in this article, that they almost exclusively revolve around the act of grinding. In addition to making for less interesting and compelling games which rarely lives up to that ideal, on a more basic level, it also makes me question whether such experiences even qualify as games to begin with.

Grinding for XP and Profit

Traditionally, when we think of grinding, we think of a game like Final Fantasy, or Dragon Quest. In such games, a lot of time is taken up by fighting the same repetitive monsters and enemies over and over, as random encounters on a world map and inside dungeons. Combat-heavy RPGs are nothing new, of course, and there's nothing wrong with this at its heart - attrition is one of the defining aspects of many RPGs, and being able to plan intelligently around the long haul rather than just the short term is a key distinction between players of different skill levels.

Castlevania II is infamous for revolving around grinding for currency, making up the majority of gameplay.

Where heavy combat begins to turn into grinding is when a game presents the player with an obstacle so difficult that it can only be defeated or surpassed through a drastic leap in the player character's ability. This can be manifest in a few ways. Experience level is the most common one, especially in RPGs - the game will throw a tough enemy at the player he or she can't possibly defeat until growing to a greater level, usually only possible through fighting lesser enemies over and over again. Another similar method is to bar the player from the next point until he or she has achieved certain arbitrary gameplay tasks (usually missions or side-quests), usually seen in several JRPGs and Western titles like Grand Theft Auto. The third form of grinding most common is to require the player amass some quantity of money in order to purchase a necessary item, buy off an NPC, and so on - Baldur's Gate II does this early on, as does Castlevania II: Simon's Quest.

Usually, grinding is regarded - rightly so - as being an artificial barrier to advancing the game, put there solely to pad things out and stop the player from completing it "too quickly." Sometimes, an alternate take sees it as a way to make sure the player is prepared for more advanced challenges, though I contend that this is just rephrasing the same problem in a more positive light. Either way, however, grinding, especially of a mandatory nature, is rarely looked upon positively. Some players enjoy the ability to grow in power and strength, but it's a fine line to walk between allowing upward mobility for the player, and forcing potentially hours of boring, completely insubstantive gameplay for the "privilege" of advancing the plot.

The Grindbox

As I mentioned above, usually sandbox games are well-regarded as a way of giving the player freedom to play the game in a way beyond what the designer explicitly set out, and ultimately to help reach that singularity point of a game whose mechanics and narrative are 100% reactive to the player's decisions. The truth of the matter, of course, is that most games fall perilously short of this lofty goal, and most games settle for providing a linear storyline with optional content on the side. The fact is that even the biggest games have only a fraction of the budget or time in development to ever capitalize on those sorts of promises, so they have to settle for something simpler.

The approach some developers take to get around this is to effectively create a large world with a ton of content in it, without linear restrictions on how the player can access this content. Though there are paths of progression, they are obscured by the fact that the player will often have many going at once, and that they frequently interact with one another. For example, in Morrowind, the player may be concerned with leveling up, with getting new equipment, with advancing his or her standing with one of the game's guilds, and with moving the main plot forward all at once. Progression in the guilds is linked in part to level progress, which in turn is made possible by better equipment, and in making progress in the guild, aspects of the main storyline can be uncovered and explored. This inter-relatedness of different progression elements, including both at a narrative and gameplay level, is extremely rare to see, but when it's pulled off, it works extremely well; as far as approaching the ideal, this is about as close as one can get.

Far Cry 2 is one of the few games that suffers from a "50 km2, and nothing to do" problem.

The problem is what happens when a game doesn't manage to nail this complex interplay between elements, or ignores it entirely. Most sandbox games are ambitious if nothing else - Far Cry 2 offers 50 square kilometers of land to explore both on foot and by vehicle, and Just Cause 2 has one of the largest game worlds to date - but usually they break down in actually giving the player anything interesting to do. Far Cry 2 makes almost no use of its open world - at best it's a way to provide multiple tactical approaches, at worst it's a collection quest for diamonds and full of tedious hikes from one map marker to the next. Just Cause 2 masks many of the same faults by draping them in a gown of explosions and 80s action movie cliches. Contrast with a game like Fallout 2, where the interconnected world is governed by (and governs) the player's own unique progression, and the outcomes of the stories and quests of that world consequently change as well.

When such a design begins to break down, or isn't expanded beyond basic incentivization (i.e. collect the trinkets), the game begins to resemble less a wide-open sandbox, and instead more of a checklist, a set of arbitrary goals to accomplish before the game is "finished." Just Cause 2, for example, houses thousands of collectable items and destructible buildings and objects for the player to hunt down. This task may offer hundreds of hours of gameplay, but none of that gameplay ties into the story, and has no real influence on the player's own growth and progression in the game - it makes up the bulk of the content and yet as far as the game is concerned, it is effectively meaningless. Indeed, at a certain point, the sandbox begins to resemble less a genuine player-driven game-narrative experience, and more a time-waster, an entire box full of filler content to grind through.

"Role-Playing" and Player Goals

It's possible to argue that player-driven goals should be able to trump designer-driven goals, and that if a player enjoys playing the game in a certain way, that's something a designer should play to. I really don't buy this argument, however. At a basic level, it's a designer's job to craft interesting interactive experiences for players, which includes interesting gameplay scenarios with meaningful stories, characters, and mechanics which drive the experience along - saying "we'll just put a bunch of stuff in the game and let the player figure out what's fun" feels like a cop-out to me, a way to wash hands of responsibility without actually designing a game at all.

Now, I'm definitely a fan of facilitating player customization and freedom in gameplay. Some players practically live for this, choosing to role-play as a character and adhere to certain rules even if there are no actual mechanics supporting it, such as the aforementioned "eat three meals a day" example. Certainly, if your game has room for it, give people the chance to do that. Similarly, if a player wants to go out and hunt down all the collectables, destroy all the convoys, whatever, then the player should be able to do it.

Where I begin to draw the line is when the game itself begins to be designed around these notions of completionism and "role-playing," where the end result is a collection quest, or built around achievement farming, or on creating a consequence-free "virtual world" for players. Frankly, I do not think that a set of scattered doodads to seek out and the ability to put on any single piece of clothing you like makes a particularly good game, and though it might approach the "sandbox ideal," it is a very sketchy resemblance at best. A sandbox, after all, is supposed to be about providing the player with a living, breathing, reactive world, where the rules of reality are there for the player to manipulate.

Morrowind offers up an open-ended world, but unlike most sandboxes, seamlessly integrates the main quest with side-quests and other aspects of player progression and exploration.

Morrowind, as I mentioned above, provides enough goals, interconnected mechanics and definite modes of interaction with the world that even at its most unfocused, it still resembles an actual game, and rarely if ever forces the player into performing a repetitive task - there's always something else to see and do, and chances are the player will be able to make progress in one part of the game by making progress in a separate one. I can certainly choose to play the game in ways not intended by the developers, and even use mods to create a more structured experience around that, but at the end of the day, there is still an actual game there to play. Contrast with others, including Oblivion, and the examples I've mentioned above, which tend to fall more into the "grind" category, and the difference becomes quite clear. Whereas one is an open-ended game which provides a huge number of options, and the extra stuff is merely there "on the side", the others resemble a series of arbitrary tasks the player is set loose to complete, and are devoid of any in-game meaning - goals without real context, influence, or finality.

Without any sort of reactivity by the game (narrative or mechanical, preferably both), or to any sort of interrelated progression mechanic, I have a lot of trouble calling the final product a videogame at all. A game is, by most definitions (and mine), a system of rules which facilitate structure and challenge, and usually includes a completion state and failure state, determined by completion or failure of a goal or series of goals; yet in most sandbox games, any "sandbox" elements are wholly separate from this definition. Instead, one ends up with a strange amalgam of a traditional game (missions, a story to follow, an end point, failure states), and a set of arbitrary tasks to perform merely for the sake of performing them, almost always entirely divorced from the actual game itself. When they do link up, it tends to be in awkward and similarly arbitrary ways, entirely in service of the "real" game - Just Cause 2 unlocking new missions, for instance.

Conclusion

Grinding is and always has been a cheap, if completely unfulfilling way of making games appear bigger than they are, and of providing a false sense of forward momentum that wouldn't exist if not for better game balancing and pacing to begin with. Now, it feels like those worst trends in gaming have become the central focus of so many other titles, whether that's because of an inability to properly rationalize trend-hopping, a lack of resources to actually flesh out a sandbox game in a substantive way, or simple lack of design forethought. There are exceptions, where a sandbox truly does make for good game mechanics (I have yet to mention Minecraft), but these are few and far between.

I realize that this is a bit of a controversial stance, especially when we consider the many different permutations that videogames can take on and the unexplored potential of the medium. For my part, I want to stress that I still can have a lot of fun with a sandbox if that sandbox is done well - I had plenty of fun with Just Cause 2 despite the fact that I will never, ever finish it (if it even can be "finished"). At the same time, in examining these games, it's hard to overlook the fact that many of them are, effectively, empty... and to be blunt, I am not satisfied with such experiences.

The Automation of Player Skill

2011-10-26T12:07:00.003-04:00

In a recent feature on Gamasutra, "The Abstraction of Skill in Game Design", Josh Bycer created a framework for understanding the degrees to which games abstract or "filter" the abilities of the player through the skills of an in-game avatar or the game mechanics themselves. Upon reading this piece, however, I found myself wanting to more deeply explore the nuances involved in the player-skill equation. Consequently, in this article, I'll be discussing some of the more specific ways in which developers automate or even apprehend player skill, much to what I believe is the detriment of the gameplay experience.

Let Me Get That For You

The most obvious way in which games automate player skill is quite literally by, well, automating things for the player. Whether this manifests as auto-aim in a first-person shooter, your squad automatically taking ideal positions and weapons in a strategy game, or your character automatically gaining skills in preset areas in a role-playing game, the end result is always the same: the player's direct control over the action and the game mechanics are suspended and superseded by the game designer's own will.

I'll take the most common example of this, the auto-aiming in a first-person shooter, most commonly seen in console games. Auto-aim is typically considered a necessity by shooter developers, whether or on console or PC, mostly in order to provide newer and less experienced players with the ability to get through the game without necessarily possessing a high skill level. As an accessibility tool, this is all well and good - after all, it makes little sense to deny a new player or a disabled gamer the "privilege" of finishing the game. However, on consoles, auto-aim is more or less a universal constant: finding a game without it is impossible, and finding one which lets you disable the feature in the first place is often quite difficult.

Shooters on consoles can still be fun and complex games, but taking out the aiming reduces skill involved and cheapens the play experience

Shooters on consoles have rarely worked well for me. Although I can enjoy the spectacle, the visceral thrill of firing at enemies (or friends in multiplayer mode), as well as the story and characters, rarely do I find myself enjoying the gameplay in particular, the fundamental "bread and butter" gameplay mechanics which all shooters revolve around. I think, at least in part, a lot of this comes down to the fact that so much of my play experience feels automated as a result of auto-aim, and, in more recent games, the snap-to feature when aiming down iron sights. Sitting down to play Call of Duty: Modern Warfare 2 with a friend in split-screen, it often feels as if there's a third presence in the room - an invisible game designer sitting between the controller and the television, who anticipates my own movements, says "oh, you want to shoot the guy on the left? I see, let me get that for you!" and pulls my crosshair in the right direction. Actually winning in such a scenario feels less about my skill in the fundamental act of shooting, and a lot more to do with my ability to simply select the right targets at the right time.

Now, don't get me wrong, shooter developers already know this. Bungie, pioneers of the modern console shooter themselves, were smart enough to anticipate this problem in the original Halo, and designed everything from the game environments to the enemy AI around auto-aim, the player's more limited degree of movement, and slower aiming speed. Furthermore, in downplaying the skill importance in shooting, they were required to compensate by emphasizing other areas of the game, such as more distinctive weaponry with strong balance, the addition of vehicle sections, AI comrades who fight capably alongside the player, etc. I don't mean to say that it's not possible to make a fun game with auto-aim, either, because clearly I'd be in the wrong, and I've enjoyed many shooters with degrees of auto-aim built into them over the years, both on consoles and PC. Despite all this, though, the movement of auto-aim from an accessibility and difficulty feature into a standard feature which games are designed around feels, to me, like the epitome of dumbing down the game experience for the player - rather than having to master the game mechanics in order to win, now I am made master by default, with a silent, invisible hand guiding my way all along.
The Reduction of Player Judgement

Another recent example of this I ran into, in a completely separate genre, was in Neverwinter Nights. I've always had a strained relationship the game, having played it since its release on and off but never really getting far into it or particularly enjoying it; I've always felt like I've been missing something, as if there's something about the game that everyone loves that has flown right over my head. Now, I believe I've cracked the code, and it lies in the removal of the player's judgement in utilizing the skills he or she might have.

Despite being a solid implementation of the Dungeons & Dragons 3rd Edition rules (a considerable step up from the "Advanced" D&D rules of earlier CRPGs), Neverwinter Nights is also extremely automated. Rather than building one's own party and then directly controlling each of them in order to overcome tactical combat encounters, instead the AI takes over everything from the inventory management, equipment, leveling up, and fighting in everyone but the "main" character. Supposedly to speed up the game pace and give the companions more personality, all it does is utterly sap the life out of the game by turning combat into a boring, repetitive slog where you spend 95% of your time watching your party auto-attack their way to victory. Even as a spell-caster with lots of active abilities, ultimately gameplay comes down to simply hitting a few hotkeys when necessary, and looting the occasional chest.

Neverwinter Nights loses much of the inherent depth in its ruleset by automating many aspects of play, from combat to feat and skill use.

Furthermore, when the AI breaks down, it often takes the player with it. I recall a recent attempt at a battle against a high-level spider enemy, wherein my AI companion, rather than taking the fight and absorbing some of the hits for me, instead decided to run off to a nearby trap and attempt to disarm it, while my player character was forced to take on the spider alone. As if that wasn't annoying enough, my companion apparently failed in disarming the trap, and the resulting fireball blew both himself and my own player character to kingdom come. I was not amused. At least I had a quicksave on hand.

Then there are the more subtle ways in which the game automates player actions. Going back to traps, rather than having to search the environment manually, either by using visual cues, logic and reasoning, or even just entering a "search mode", instead the function takes place automatically (at least when one has an AI companion capable of the feat), and almost never fails. This might seem like a small thing, but it makes all the difference. In a CRPG, the player's skill comes into play not in terms of twitch reflexes, but in terms of making the right decisions in succession, based on strong judgement and knowledge of the game mechanics. The Infinity Engine games such as Icewind Dale turned traps into a sort of resource management of their own. Usually it was good practice to scout an area with a stealthy rogue or character made invisible by way of a spell, both for enemies and for traps. However, often traps would be placed near enemy encampments, and disarming them would break stealth and expose your squishy mage or rogue.

Hence, trap disarming was an interesting risk and reward decision tree - one that a player could ignore entirely should he or she want to put up with the occasional inconvenience traps cause, or could handle intelligently. Indeed, much of the fun in playing a rogue or magic-user is in using those unique skills to one's advantage to tackle the game's obstacles in interesting and creative ways. In Neverwinter Nights, the entirety of the nuance of detecting and disarming traps has been completely and utterly removed, replaced with a skill-less automation which not only reduces the depth of the game considerably, but also makes all those complex feats and talents a player can invest in a lot less interesting as well. Rather than taking advantage of the inherent depth in the D&D rules to provide the player with interesting skill-based gameplay (reasoning, logic and risk-management), instead, Neverwinter Nights decides for the player how to play the game, and ends up actually being a less faithful implementation of the tabletop game - even without changing the rules themselves.

Cinematic Experiences

One of the most common points of praise for modern videogames is when they are compared favourably to movies. Many game franchises have made it their key selling point in order to provide the player with a "cinematic experience", to place the explosions, characters and dramatics all around the player as the universe's centre. I certainly won't deny that a cinematic game can be enjoyable - as I said, I love spectacle, and despite not being much more than an on-rails shooter, I can't help but be visually stunned by a game like Call of Duty, whose sole mandate appears to be to provide the player with a roller coaster ride of action and excitement.

However, rarely do we really see how this focus on cinematics can hamper the game experience itself - in fact, most players and developers alike tend to assume that those cinematic elements are good in and of themselves. Eurogamer's Simon Parkin recently posted a review of Uncharted 3: Drake's Deception in which he gave the game a solid score, but provided a strong critique of some of the game's limitations - most notably, as stemming from developer Naughty Dog's attempts to provide the player with an action movie's worth of excitement.

"But it also reveals another truth. Uncharted 3 is the most exciting game in the world, but only until you deviate from the script. Even in this chase the conflict between the developer's theatrical choreography and player-controlled interactions is clear. In order to ensure each set-piece is set off correctly, the game commits the cardinal sin of insinuating you have full control of your character, but in fact tugging you towards trigger points - making sure you're in the right spot to tumble over the bonnet of that braking car, for example."

The point of criticism is clear: while Uncharted 3 might be an incredible thrill-ride, it's also, in some senses, the worst game in the world: control is apprehended so that the choreography of the piece is maintained, and the game's pacing moves not out of the player's own actions, but out of the developer's want to adhere to an extremely (and exceedingly) specific flow of events.

Uncharted 3 provides enthralling visuals, but in automating much of the gameplay, it can feel as if the player is just getting in the way of the action.

There are two problems most notable with Uncharted 3 as I can gather (and apologies if I'm wrong, as I haven't played it myself). The first is that oftentimes the player doesn't feel in direct control of the experience. As Parkin states, often he found protagonist Drake running and jumping around in ways which clearly defied the (in-game) laws of physics, and his own expectations for the character, in order to make a cinematic leap forward or avoid the game over screen. Not only does this break immersion and the player's understanding of the game world's rules, it also takes control away and subtly tells the player "hey, you're doing it wrong, move over and let me handle it."

Second, oftentimes the game simply refuses to work in a way the player might anticipate or expect, especially in cases when the player defies the wishes of the designers. I've seen this plenty of times in the past, with absurd instant-death scenarios for stepping outside the dotted line, though much less common in modern games, and most developers have got pretty smart about providing realistic, natural, and coherent explanations for why the player can't do X or Y. Yet Parkin writes,

"Your freedom of choice risks ruining the shot. Indeed, throughout the game, if you jump into an area you are not supposed to visit, Drake will crumple on the floor dead, Naughty Dog switching role from movie director to vindictive god. That is not your predestined path: Game Over."

Uncharted 3, put simply, doesn't allow the player to experiment, to explore, or solve problems in creative ways. Instead, everything must adhere to the tightly controlled script that Naughty Dog has laid down, and deviating from that path is met with an instant failure and reload. The most absurd thing about such a limitation is that Uncharted has always, to a degree, presented itself as a game about adventure and exploration - the protagonist, Nathan Drake, is a modern-day Indiana Jones, who gets ahead by the skin of his teeth, jury-rigging one solution after another to just barely beat out his enemies. Yet when the player tries to behave as Drake, in a way not anticipated by the developer, the result is not a reward, but the most absolute of punishments. It's an inherent contradiction, and one developer Naughty Dog seems content to leave be, even if it ultimately harms their game in the long run.

Conclusion

There are, of course, plenty more ways in which one could observe or categorize the ways in which player skill is mediated by game mechanics, and plenty more examples out there to put under the microscope. I hope that in this article I've been able to both shed light on some interesting examples of what I think is a disturbing inclination, and also that I have made the case as to why they ultimately hinder the play experience rather than help it. Videogames should be all about providing the player with interesting mechanics, tools and scenarios, and, in my opinion, cutting into that via automation is contrary to the very foundations of the medium, and is something that deserves more consideration and scrutiny than it is given presently, by both developers and gamers.

Thanks for reading, and please share any thoughts in the comments!

Building Better Game Development Tools

2011-10-21T15:52:00.000-04:00

It's pretty incredible how far game development tools have come over the last generation of games. Even just 5 years ago, getting one's hands on game development tools was a difficult process, and learning those tools was even more difficult. Documentation was extremely scarce, and unless you were lucky enough to be tutored by an experienced team, or ended up in a game development job yourself, learning to use those tools effectively was even more difficult.

Today, in 2011, getting one's hands on game development tools and actually coming to grips with them is a much more friendly process. For one, there are dozens of freely-available commercial-quality game engines available, from CryEngine 3 to Unreal Development Kit, and even those few games that ship with official software development kits are extremely well-supported by comparison. What's more, the rise of online video now means that getting concise, visual demonstrations on how to use those tools is easier than ever, and with a human touch behind it, it's very easy to learn tools quickly, even if you're a complete novice.

In spite of this progress, however, I've found that modern software development kits still have a number of stumbling blocks they need to get over in order not only to make building games more intuitive, but also to make the process faster and require less fine-tuning, bug-fixing and other assorted issues. In this article, I'll be taking a look at a few SDKs I have experience with, examine where the problem areas lie, and provide comprehensive suggestions on how they can be improved.

A quick disclaimer: I'm a design mind, not a programming one, and it probably shows in this piece. I'm sure others will have all sorts of issues they can bring up, so bear with me here, as I'm talking about what I'm familiar with above all else.

Designer/Programmer Dichotomy

This is the all-time biggest stumbling block in my opinion. People who are trained in scripting, programming and other more "technical" tasks tend to not only have certain skill sets and degrees of familiarity, they also tend to process information and think in different ways from designers. Speaking broadly (and I do want to stress "broadly"), designers, artists and so on tend to understand the world in more visual terms - for them, what they can visualize is reality, and creating something that is pliable, "physical" and visible is far more intuitive. Programmers, on the other hand, tend to think in terms of data - visual organization is very important, but for them, speaking in very broad terms, it's possible to understand how something works and will impact a final product without necessarily seeing it first-hand.

Consequently, the organization of data tends to be different between these two general archetypes - artists like to keep things simple, uncluttered, and easy to understand, data-driven minds tend to be more focused with smaller details, on having information freely accessible at all times, and in general want to be able to consult any bit of information at any time regardless of what it might be relevant to. Again, I want to stress I'm speaking in very broad terms, and using stereotypes to do so - I don't want to suggest all people (or even most) think according to these, but rather only for the sake of conceptualizing the problem.

That problem of interests conflicting, of course, arises when you start to build a user interface that is able to accommodate both sensibilities. Designers tend to think in terms of visuals, so, for instance, level-building tools tend to present themselves in terms of end results - i.e. if I want to make a mountain, I use the terrain tool and sculpt one. However, programming, scripting, and even animation tend to exist more in terms of logical building blocks which inevitably require more functions - rather than hiding things behind the scenes and letting the visuals speak for themselves, and this may not be immediately intuitive for the visually-minded. When you try to combine both sides of the coin into the same toolset, you inevitably end up with something that, to an outsider or an inexperienced developer, can look positively intimidating, as the sheer number of functions required ends up going over the tipping point.

Far Cry 2 provides an excellent and intuitive level editor... but it's limited by nature of its reduced feature set, making for a friendly but incapable SDK.

One of the clearest examples of this I've seen is Far Cry 2's map editor. Running the Dunia engine, the home version available is stripped down to the essentials for those who want to build multiplayer maps. The basics of terrain manipulation and object placement are here, as well as texturing and vegetation, but beyond that, the interface is about as easy to figure out as any I've seen. For those who want to just get in and start building levels, frankly, it's great, and for rookies especially it's excellent in helping to teach the basics of level design.

However, for those who want any more advanced functions - basic scripting, AI characters, triggers and mission objectives, they're out of luck, and anything more advanced, like manipulation of local and world variables, cutscenes, animation and so on are also missing. If you included all those features in this toolset, it'd be far more intimidating, harder to learn (as more interface elements means more to sort through, more room for error, etc.), which would be inappropriate for a level editor aimed at general audiences.

More generally, however, these cluttered interfaces which arise from the dichotomy tend to cause greater problems - namely, they make the tools hard to learn and even harder to master, as the number of functions they must cater to ends up outstripping the talents of any single team member. What this ultimately means is that tools look cluttered and offer up, from an individual perspective, too much information to easily process and digest, and even for those familiar with the tools, can lead to a breakdown in workflow as more mental breathers are required to take everything in.

The Dragon Age Toolset offers up huge amounts of functionality, but keeps them quarantined in relevant areas to help keep content creation more intuitive.

One of the best solutions I've seen to this problem so far lies in the Dragon Age Toolset, BioWare's internal game editor for the Dragon Age series. While the updated version compatible with Dragon Age II is a no-show for now, the original version still has a logical way of organizing information for the end user, regardless of experience level. Effectively, game files, rather than stored within large level archives, are instead manipulated by an individual "mode" within the editor, and saved as individual files, i.e. *.dlg for dialogue. This means that, while level designers can easily create maps in the level editor, game designers can then hop in and create the actual gameplay via the area editor, by placing NPCs, triggers and so on. This extends to cutscenes, plots and quests, scripting, creature and NPC creation, and so on. The compartmentalized nature of the Toolset makes it easy to learn and easy to break up into small, intuitive pieces while still appealing to the more advanced sides of each discipline. I think that more game SDKs should take on this approach - if the tools need to be unified, they should still be small enough to learn the individual pieces of, rather than monolithic and intimidating.

Don't Waste Time

This might be a bit of a vague topic, but I think it's an extremely important one nonetheless. It's extremely common in game editors to have certain functions which take an extremely long time to perform, yet the function they provide is utterly essential.

The most common I personally run into, and the most aggravating as a level designer, is that generating lightmaps, more often than not, takes just about forever to accomplish. I realize that, at a basic level, this is something that is hard to control - lightmap generation is something essential to modern 3D games, there are certain underlying factors that can't be hurried or sped up, and the size, complexity and number of lights in A level very often contribute to rendering time. Even so, more often than not I find that, in many game editors, half my time is spent waiting for lightmaps to render rather than actually building more content.

UDK provides extremely high-quality in-editor rendering, which saves a huge amount of time in building levels.

There is an "easy" way around this lightmapping problem, and that is to have sophisticated and high-quality real-time previews of what in-game lighting will look like. Things in the editor are rarely identical in the game owing to optimization, in-game options, video drivers, and any number of things, but the faster I can conceptualize how a level is going to look in the game, the faster I can build it, and getting a sense for lighting and atmosphere is absolutely key - in fact, I'd say there is nothing more important in creating a level than knowing what the lighting is going to look like by the end of it. On top of it, lighting helps designers understand spatial relations, as without real depth perception, lighting and shadows help to give a sense of depth that is otherwise lacking when flat, static lighting is all you have to go on. If it's impossible, then at least provide me with fast, quick-and-dirty preview renders that take as little time as possible but still give a general idea of what the game is going to look like.

Another thing that tends to take a lot of time is testing out changes in-game. It's easy to build content, but most time is generally going to be taken tweaking it, and fixing all the little issues and bugs that crop up. In my experience, the more often you can test something in-game, the better. Unfortunately, some game SDKs still do not support this feature adequately. The Dragon Age Toolset as mentioned above is just one such example, as it requires a full export of project files and a full game restart in order to be able to see results - and that's not even counting how much time you might spend actually getting to the piece of content you want to spend.

CryEngine 3, through some arcane magicks, is able to allow you to drop into a game level at any time and place, and test exactly as it appears in the game itself. This. Is. Good.

Although I'm not certain whose editor the first was to do it, Crytek's CryEngine and CryEngine 2 really popularized the idea of being able to jump into the game world and test things out exactly as they would occur in the game itself. I'm not privy to the technical wizardry behind this, and don't presume to know what kind of a feat it is, but suffice is to say that it makes building content much, much quicker on a design end, and means that content creators get real, accurate feedback on what they've done even moments after it's been put into the game. From a level creation point of view, this is especially important, as most know that placing 3D objects accurately without clipping errors, floating bits etc. can be a real pain sometimes, as can ascertaining a sense of scale relative to the player. Moreover, being able to test out scripting in-game is extremely convenient, and allows bugs to be fixed in seconds instead of hours.

I'm sure there are dozens of other solutions that can save developers' time on the content creation front, everything from better standards between programs, to consistency in file formats, to removing or automating redundant and repetitive operations. These couple of examples are the two that stand out most for me, but depending on the field, I'm sure that there must be dozens of other issues - for example, I know audio designers would probably be happy to never again have to bother converting their *.wav files into some obscure and disused file format using a stand-alone compression tool that only works properly on Windows 2000, and batch actions when importing scores of diffuse, normal, specular, etc. maps would be a godsend for artists. Suffice is to say, any time-consuming tasks that could be made faster, should be made faster, end of story.

Standards, Standards, Standards

However, the fact is that oftentimes it's impossible to realize the demands for better tools, especially for developers which rely on their own technology. Whether it's because someone on a development team has a certain obsession with a proprietary format, because game technology is purpose-built for a specific product, or simply due to a lack of resources, a lot of these ideas I've presented get left on the cutting room floor for one reason or another.

The solution to this, I think, might be controversial, but in the end I feel would be best for the whole games industry and the development process. Standardization of tools has already begun, to a degree, with just about every developer out there needing experience in Photoshop, Pro Tools, Maya, etc. depending on the particular field, but even beyond asset creation, game tools have also begun to homogenize. Ten years ago, accomplishing anything more than what a game editor was explicitly designed to do was a complex task involving lots of jury-rigging and a good deal of luck, and transitioning from one SDK to another was a long, arduous process that required a lot of re-training. These days, the interfaces between SDKs are so similar, at least on a basic level, that most people should be able to jump in and create something useful within a week or two, and that is most certainly an improvement.

At the same time, much as we have those standards for the asset creation, we don't really have standards for development tools themselves, despite the similarities. I think, more than anything, what is necessary to cut down on development time and expenses, is the creation of a unified SDK front-end common to every game engine. The best analogue I can provide for this is Photoshop - while it can export a variety of image formats, compatible with just about any other program or device, the actual creation process is extremely standardized. Photoshop's interface has come to define modern image editing, and to a degree, even 3D modeling and texturing tools like Mudbox, to the point where any artist, photographer, etc. can use Photoshop and create something suitable for any job. The dream, for me, is to have a Photoshop for level editing, another for scripting, another for animation, another for audio work, and so on, so that skills would remain consistent and practical across just about any project, while the code underneath, the game engine itself, remains in the hands of the game developers.

Front-end SDKs similar to Photoshop could revolutionize and standardize game development... but potentially hurt it as well.

Adobe Photoshop is also a great examine in itself because in many ways it has been razor-refined for its intended purpose. It is well-organized and concise in presenting information and functionality, the tools are intuitive and self-explanatory, the software itself is supported by a huge range of hardware and runs extremely smoothly provided you have a system supporting GPU acceleration, it's highly customizable in terms of layout and keyboard shortcuts (something that can't be said for all SDKs), and it has defined the workflow for image editing across virtually all relevant fields. Tools like this, from a content creation perspective, would be incredible for game developers - ones which cater to the specific needs of different individuals, with sets of logical and intuitive functions which speed the creation process. Being able to envision my game levels layer-by-layer, painting level details with brushes and swatches, or adding fog and post-processing using simple brightness, level and hue controls would be excellent, and I'm sure those in other fields would find similar benefits in taking the best features from other professional tools.

There are a lot of pitfalls and problems to anticipate with such a solution. One is that of the monopoly - namely, whose standards are selected for the industry as a whole? While the colossal growth of Unreal Engine over the last ten years has come to define even the aesthetic of modern games and the workflow of game development, there are plenty of other equally capable alternatives. Two, the technology that powers one game might not be suitable for another, so any tools would have to be fully inclusive of just about any game design, would need to be cross-compatible with other tools, and would need to be routinely updated in a timely manner so that developers could take advantage of them. Three, videogames are a technology-driven medium, and innovation exists as much in tech as it does in design, unlike the film industry where the filming and editing processes are by and large already cemented and it's the creative side that reigns. Putting the development of some of that technology in the hands of a single company could stifle progress across the entire industry, even if it does lead to faster and easier development. Four, the one who actually ends up creating the tools would most likely have to be an uninvested third-party rather than an actually game developer - we already know that developers and publishers especially do not have much interest in using the competition's tools.

Conclusion

I have some confidence that, in the future, game development software will be able to naturally answer these questions in its own course, but I also can foresee the transition being bloody and fraught with problems and casualties along the way. Most importantly, however, is to recognize that all this is easier said than done - the real-world limitations of development, economics, copyrights, and everything in between represent a huge barrier, and that, what other fields like film have managed to do across the better part of a century, the games industry has only really been operating in such an organized and standardized fashion for the last decade or so. What I've covered here is only a fraction of potential interface and workflow improvements for game development tools, and I'd be intrigued and delighted to hear any other suggestions that might come up.

Ding! The Devaluing of the Level-Up

2011-10-17T19:40:00.001-04:00

Whether it's the swell of an orchestra, the thunder of a distant war drum, a chorus of angels, a guitar riff, or a simple, distinct "ding" sound, everyone loves to hear it: the chime that signifies a level-up. Although it has its roots in role-playing games, the notion of leveling up abilities, characters, items, and more has crept its way into just about every facet of gaming - so much so that it's nearly impossible to find a game which doesn't have some sort of leveling, experience points, or an equivalent progression system realized and presented in a numeric fashion.

You'd think that, as a fan of role-playing games, I'd love all this talk of levels, stats and attributes, and relish in the chance to up those numbers no matter what the context - after all, there's nothing I don't enjoy more than a good RPG. On the contrary, however - the more games I play which involve leveling and progression in such strict, metered and discrete ways, the more and more I tire of leveling. In this article, I'll first outline my own general conceptualization of what levels represent, and then I'll get into exactly why I feel the move towards leveling up in just about every game genre out there has contributed to the devaluing of the concept.

Conceptualizing Leveling

Role-playing games, having their roots firmly in the tabletop space, borrow many of their conventions from the mechanics necessitated by the limitations of the tabletop itself. To put it plainly, there is no "hood" to look under in the tabletop realm - all of the gears, the machinery, the underlying operations are exposed for all to see, and any pretense of fantasy, fiction, and aesthetic come solely out of the imaginings of the players involved in the game. Effectively, a role-playing game is a set of raw mechanics which interact with one another, in order to facilitate cooperation, interaction and competition within a fictionalized world outlined with a set of natural and physical rules, i.e. the ruleset. All the elves, dwarves, and magic that so many players love are ultimately secondary to the mechanics of the game itself, despite the fact that it's those aesthetic elements which are so iconic of Dungeons & Dragons.

Traditionally in RPGs, leveling has been about expressing a set of rules about the world - not about the Drow Ranger in the character portrait.

Within this framework, and the numbers exposed, a concept like "leveling up" makes a lot more sense. Everything in a tabletop game is expressed in a numeric fashion, governed in a consistent and mostly predictable way, and leveling up is just one way of understanding the progression of characters and abilities. Furthermore, although we tend to think of leveling up in terms of character level, most pen and paper games have plenty of other ways to level up - feats that need to be purchased, attributes that need to be raised, etc. Many systems will allow players to freely level up in different classes, as well, allowing for a significant amount of variety and control over progression. These tie in with the aesthetic and our understanding of the game - the "I'm a half-elf sorcerer!" fantasy - but at their lowest level, these are merely mechanics.

What this all means is that leveling up is not an end in itself, but rather a way of understanding the progression of a character's ability and proficiency, not just in a vague and general way as it's realized in most videogames, but in very particular, controlled and specified ways, often along multiple paths simultaneously. The "leveling up" is just one aspect of a much larger system, and while perhaps one of the most rewarding of those aspects, is still ultimately only a very small part of what makes up that complex set of interactions and rules. Leveling up may tie into that fantasy, our sense of empowerment and progress, but like my half-elf wizard, that's all something built on top to provide meaning to the experience, rather than something integral to those operations.

Defining Progress

Usually in videogames, progress can be expressed in some pretty intuitive and self-explanatory ways - completing a mission, gaining a new weapon, item or ability, killing a powerful boss, beginning another chapter in the story, moving from one environment to another, different one, and so on. All of these contribute to a feeling of movement through the game, an expansion of gameplay mechanics, and the overall sense of pacing that keeps the game interesting throughout its running time.

In The Legend of Zelda, we might emotionally respond to the acquisition of a new item, but what really matters is that we're able to move forward in the game - the Blue Candle, while snazzy and fun to think about, ultimately just grants us a new set of abilities that we can capitalize on. The same is largely true of getting a new weapon in Half-Life 2 - the SMG allows me to take on far more enemies than before, and the grenade launcher attached to the barrel is useful for clearing out rooms in one fell swoop, but those are functional things. The sound, the feel, the look of the weapon are all important, certainly, but again, it's what this new weapon allows us to do, what hole it fills in our repertoire, that really gives it its staying power and its gameplay function.

In Psychonauts, progression comes through acquisition of points and manifests as different abilities - is this all that different from the XP and levels that govern other games?

Of course, leveling up is just as much a form of measuring progress as acquiring a new weapon might be, so long as leveling up actually contributes to an increase in the player's abilities or provides new options in solving gameplay challenges. In fact, the difference between framing progress as "a new gun" or "boots that let me jump higher" and as a level up on a character sheet is actually much smaller than what might initially be apparent. In Psychonauts, for instance, I get new abilities by earning new merit badges via collecting arrowheads, imaginary figments and mental cobwebs, either via my own exploration or through story progress - if I called these "levels" and "experience points" instead, would I suddenly have a more compelling progression mechanic? I doubt it.

Some might argue that systems revolving around experience points and levels are inherently more open-ended, flexible and so on. It's true, certainly, that generally leveling up tends to be a bit more freeform than more traditional conceptualizations of progression - however, this is another case of aesthetics deceiving people. Rather, whether or not a game has a linear progression or an open-ended one is a structural concern, not anything that comes hand in hand with the system itself, even if we do tend to think about them in slightly different ways and conceptualize them accordingly. After all, there are plenty of linear RPGs with leveling mechanics built into them, just as there are plenty of non-linear action games without any real leveling to speak of - the difference is superficial no matter whether you're shooting gangsters or slaying bugbears, and earning gold or bullets.

The Degradation of Context

So, if leveling up is an expression of progress within a strict system of rules and mechanics, and if progress can be expressed in myriad ways without fundamentally changing the gameplay itself, exactly what's wrong with leveling? It's a bit of a complex answer, but generally it concerns the degradation of the context in which leveling up traditionally has taken place in - rather than existing within the bounds of a ruleset, instead, leveling has by and large been transformed into the sole measurement of progress within all games, regardless of genre, and the result is that leveling no longer feels significant to me in the same way it used to.

Largely as a result of games like Call of Duty 4: Modern Warfare and Gears of War, but also partially due to overarching online networks such as Xbox LIVE, over the last several years, is that the idea of leveling up and metagame progress has begun to supersede the focus on progress within the game itself. Now, just beating the game and getting a good record in the multiplayer component isn't enough - you've got to level up to 60, max out those weapon challenges, and have the biggest, baddest profile around. Is there a particular reason why leveling is in the game? I really don't think so - sure, it keeps players playing because the numbers keep going up, but the act of leveling feels completely divorced from and even contrary to the game itself.

Call of Duty has more ways to grind XP than Final Fantasy, but what relation does this progression system have to the gameplay itself?

Put simply, the leveling which has ended up in shooters, beat-em-ups, action games, and so on, almost never has any direct relationship with the game mechanics. In RPGs, leveling up is just one way in which the rules of the world are expressed - when I've become sufficiently experienced with something, I am able to gain new talents and improve my attributes, simulating the natural incline of ability over time that anyone in a given profession can attest to. In leveling up, I improve my character, and I do so in a way that makes sense within the game world - and in a way that the game world is able to summarily respond to. This is even more evident in more open RPGs, like Fallout, where improving, say, the stealth skill can open up an entirely new path to complete a task, which the game then acknowledges.

But what about a shooter - exactly how does getting 1,000 kills have anything to do with unlocking a new scope for a particular gun? Sure, you can try to justify this in some way that the player has now "earned the right" to use better equipment, but this is rarely if ever formalized in the game, except perhaps in some vague suggestions of rank along with those character levels. The fact is that these unlocks, these "levels" gained by the player, do not really have any direct correlation to any consistent simulation of the world - they are arbitrary in the extreme, existing only as a carrot to keep the player moving forward on the treadmill, with the only end either boredom, or the inevitable sequel.

What's more, these arbitrary and contextless mechanics tends to tie into the achievement and trophy systems found on persistent online networks like Xbox LIVE, PlayStation Network, and Steam. It's gotten to the point where challenges in games exist for their own sake and not necessarily because it's really fun for the player, because they add anything to the game mechanics, etc. Do the collection quests in Gears of War tie into the storyline much, if at all, or do they give the player new abilities or bonuses? No, not really, but... well, here's a little badge to tell the world you scrounged in the dirt like a moron for an extra ten hours! While achievements can sometimes be inspired, by slapping an experience mechanic onto a shooter, you also give yourself a lazy excuse to just turn those achievements into milestones - so now not only is experience divorced from the context of the game, it also exists to satisfy a system entirely outside of the game itself.

Leveling as an End in Itself

Worst, however, is that the new understand of leveling up as a treadmill, rather than a logical outcropping of the rules of the game world, has also begun to define modern RPGs as well, not just shooters and action titles which hold up leveling as a pretense of depth. One of the most telling quotes I've heard about RPGs in recent years, regardless of the original context, comes from a Torchlight developer: "RPGs are always best when the numbers are going up." I think, in a certain sense, I can agree with this - it's always good for the player to be making progress in the game and moving forward, and that's true in pretty much any game genre whatsoever. Giving strong feedback on that progress is also one of the bigger parts of the art - after all, the derogatory term "corridor crawler", if nothing else, implies a static experience.

Torchlight may have a million numbers, but that's all they are - there's no real justification or meaning behind them.

Where this mentality breaks down is that it begins to forget exactly what purpose leveling up serves in the first place. I've already touched on the appropriate context of leveling mechanics, so I won't go into that again, but suffice is to say that there needs to be a consistent and strong basis for including such a mechanic in your game. As a designer, one shouldn't be content to say things like "well, it's an RPG, therefore we've got to have leveling up." It's both practical and good design sense to look at those mechanics and question exactly what role they serve within the game, and adjust them accordingly. Sure, it's good to make progress in a game, but is doing so through discrete XP gain, leveling up, and new skill points always a good thing? I can't answer that question definitively, because it's inherently subjective, but the important thing is to ask in the first place, and genuinely try to provide an answer - otherwise, creatively, you are running on the very same treadmill you've given your player.

The sad truth of the matter is that, at this point, I don't think leveling up in games, and RPGs especially, really has much at all to do with leveling in the more traditional sense that I discussed above, where the goal is to understand and articulate character progression within a strict, organized framework. Rather, it's based on one thing: the desire to see those numbers keep going up, and up, and up... to where? Considering the constant demands by players to see level caps raised in expansions, patches and DLC (to the point where that is now a selling point in and of itself, i.e. World of Warcraft), the desire for more perks and skill and weapons which end up breaking the game balance even more beyond what a maxed-out player could previously pull off (another DLC fodder item), and the tie-in to persistent online personas, achievements, and multiplayer profiles, the only true answer I can give is "to nowhere... at least, until the sequel comes out."

Conclusion

Again, I like leveling up as much as the next person. The prospect of gaining a new ability to play with, of being able to wield a new weapon, or just knowing my character is even better in a fight, all of that appeals to me. At the same time, to me it feels as if leveling up has lost meaning - an abstracted, context-less ideal of progression without actually being situated logically within a game world or ruleset. Ultimately, the choirs of angels, war drums, and guitar leads are, in today's games, functionally equivalent to the "ding" of a Pavlovian dinner bell... and in reducing such a mechanic to a carrot on a stick, a stimulus-response algorithm, we in turn degrade not only the fabric of role-playing games, but the depth and breadth of which we understand progression in all games as well.

Understanding Difficulty

2011-10-11T18:23:00.002-04:00

Although we frequently have discussions about difficulty in games - is ittoo hard? which parts did you have trouble with? was it too easy andtherefore boring? - we rarely direct our attention to the different fundamentaltypes of difficulty which make up our experiences and colour ourperceptions of the challenge a game provides. In this article, I'd liketo go over a few of those most basic types of difficulty as well as theproblems associated with implementing them, as well as bring out that it'soften not just the sheer challenge of a game that matters, but the nature ofthose challenges that matter.

Trial and Error

The first, and most obviously identifiable type of difficulty that we findin games, and by far the most common, is trial and error. Put simply,trial and error revolves around getting the player to perform a task, eitherthrough experimentation (i.e. "I don't have anywhere to go, maybe I'll trythis") or outward suggestion (i.e. "these are your orders, soldier,now move out!"). At least theoretically, the main difficulty thispresents to the player is that the degree of challenge (types and numbers ofenemies, for instance) will always be slightly higher than what the player iscomfortable with, meaning that he or she will have to rise to the occasion inorder to come out on top, either by trying out new tactics, by taking greaterrisks, or through sheer force of will and dumb luck.

As many of us can attest, trial and error difficulty treads a very fineline. Typically, too many failures, and players will become frustrated,while too many successes and players will feel as if the game isn't going hardenough on them. The main issue with this, aside from basic balancing, isthat different players have different thresholds for difficulty. Whereasa more casual player who's just enjoying a game for its story will find thatmore than the occasional death is a turn-off, the hardcore player who plays onthe "insane" setting will want to be challenged at every turn andmade to work for every single victory. Ultimately a developer might runinto a situation where they're balancing not just one, but three or fourversions of the same game, due to the different needs of different players.

Of course, pacing is also a chief concern by and large governed by the ebband flow of difficulty, usually of the trial and error nature. The playerneeds to have portions of the game which fly by quickly and without too muchissue, breaks in combat to absorb the world and feel unchallenged, andnail-biting experiences that are tense and have a feeling of urgency tothese. Building these into a game when taking different gameplaypreferences into consideration is a difficult process; after all, while it canbe easy to balance a single encounter out to give the player the desiredexperience, doing so within the context of a full game is another thingentirely.

Adaptive difficulty settings are one way to get around this problem. On the most basic level, this will typically change the amount of resources(health, ammo, etc.) provided to the player, as well as the proportion ofpowerful versus weak items based on the player's performance (i.e. more"full heal" pickups if the player is struggling). This featureis actually extremely common in games, either because developers want to avoidproviding separate difficulty levels (a poor decision in my mind), or becauseplayers have a curious habit of selecting difficulty levels that aren'tappropriate for them (everyone has a different understanding of what"normal" should be).

Screw Alyx, these crates were my best friends in Half-Life 2. Turns out the reason was a bit more calculated than my platonic love of all things boxy.

Adaptive difficulty can be both explicit and hidden from plain sight. Prey,for example, has adaptive difficulty as a toggle option in the game's optionsscreen, and so it can be disabled based on the player's preferences. Half-Life2, on the other hand, while providing three difficulty settings (easy,normal and hard) also has a layer of code dedicated to analyzing the player'sprogress in the game, level of resources, the ease at which certain encountersare completed, and so on; the game will then adjust the items enemies drop, theamount of resources available in breakable crates, and so on in order to makesure the player is always kept on edge by having "just enough" healthand ammo to get through an encounter, but never quite enough to feel completelysafe or fully-loaded. Other games will implement it in still subtlerways, like allowing the player to finish off a tough boss monster just a littlebit more quickly than normal if the player's death is imminent, creating adynamic feeling of getting through by the skin of his or her teeth.

The biggest issue for me with adaptive difficulty is that, when left as abuilt-in feature that can't be disabled, it removes control from the player'shands. Although I'll usually take an entertaining and engaging experienceover one that's simply difficult for the sake of difficult, I also fullyunderstand that some players don't want hand-holding provided that theyexplicitly ask for it. Furthermore, adaptive difficulty can also lead toa feeling of predictability and sterility, without a hand-made feel toencounters (which was a major source of criticism for The Elder Scrolls IV:Oblivion). To this end, I feel that adaptive difficulty is best leftas it is in Prey - a toggle switch in the options menu - or specificto a difficulty level, with the hardest mode taking off all assists, whichmitigates the problem of too much challenge by allowing the player torationalize it as his or her own choice (i.e. "well, I picked hardest, Ishould have known it would be too much for me").

Endurance & Attrition

Another way to test the player focuses on the long term rather than theshort term. All forms of endurance, at their most base level, revolve aroundresource management, with the player given a limited quantity of a valuable orvital item, its distribution carefully controlled. Resources arecontrolled in three main ways in just about every game:

"Random" drops. It's quite common for enemies to partwith valuables when defeated, or for the player to uncover supplies in crates,chests and so on. By tinkering with the tables that control thosesupplies, based on difficulty, the player's progress, the amount of resourcesthe player already has, and the player's level of ability, character level,number of party members/companions, and so on, difficulty can be preciselycontrolled and monitored in order to provide a degree of challenge.
Attrition rate. Depending on the game, the rate at which a playerburns through supplies can be highly variable. For instance, in ashooter, going up against a tough boss monster might not consume too muchammunition, but may consume a huge amount of health. Conversely, going upagainst many smaller hordes of enemies will end up with a player ill-equippedto proceed, but chances are, a healthy one. Learning to anticipate whatthe player needs in order to continue in the game is important. If a gameuses an adaptive difficulty system, this might already be handled, but even so,careful consideration of how quickly the player goes through certain resourceswill lead to better encounter design and a game that feels more alive andresponsive to the player's needs. Strategically denying certain resourcescan be just as important as strategically providing them, too, in buildingtension and pacing the player's progress.
Player ingenuity. Most common to role-playing games, smart playerswill often stock up on useful items like potions and ammunition before headingout into a difficult encounter; the duration the player can stay out in thewild before returning to stock up on supplies again is by and large controlledby the player's prior action, as well as whatever the player might uncoverduring his or her outing. This is one thing that is hard to control in agame, and frankly, shouldn't be. Keeping aware of what players can andcan't do, and building challenges around that is a good thing, as are systems,such as encumbrance and fatigue, which can provide a soft limit on how much theplayer can carry. However, imposing unreasonable hard limits (i.e."you can only hold three health potions at once") rarely feels like afair way of managing this.

You don't need to be Arcanum to have compelling attrition and resource management (but it helps).

Long-term attrition may not be suitable for many games, but looking atattrition in different ways can actually reveal interesting opportunities formechanics that may go unnoticed with a casual glance. For example, apuzzle game like Tetris has a strong element of attrition in the sensethat the available space on the game board is continually shrinking based onthe player's performance, the difficulty level, and which puzzle pieces theplayer is provided with. On top of that, game speed is anothergradually-depleting resource the player must carefully manage as things movequicker and quicker over the course of the game. There is a veritableeconomy of space and time in Tetris, even though there is no healthbar, ammunition counter, etc. to speak of. Recognizing that attrition andendurance can exist as more than just basic physical resources will help fleshout and provide depth to existing mechanics.

"Fake" Difficulty

A subset of trial and error difficulty, what I'll term "fakedifficulty" here is something which is actually quite common in the gamesindustry, but depends a good deal on the genre in question. Fakedifficulty is a fairly broad spectrum of difficulty, but in common with all ofthe various permutations is the fact that they typically revolve aroundtricking the player or bending the rules of the game in order to provide theirchallenge - often causing significant frustration and annoyance for players,whether they're keen to those tricks or not.

One of the most common forms of fake difficulty actually fits within thecategory of adaptive difficulty - namely, it revolves around manipulating therules of a situation in order to provide the player with increased challenge,usually referred to as "rubber-banding". The key difference isthat while adaptive difficulty works in favour of the player (for example,you'll find 50% more health kits if you're low on health), fake difficultytends to work in favour of the enemies or opponents. However, sinceenemies rarely compete on fair terms with the player, and in fact tend to usean entirely different set of rules, this usually means that the bonuses givento the player's opposition fall into the realm of super-human - increased speedbeyond normal limits, temporary damage boosts, the ability to negate theplayer's own abilities when normally they can't, and so on.

A great (and persistent) example of this type of difficulty can be found in MarioKart - in fact, the series is somewhat infamous for it. While thegoal of the game's rubber-banding is to provide a tense and exciting experiencefor the player, making sure that each race is as close a finish as possible,and that enemies are able to always keep players on their toes, in the longrun, or for more experienced players, this form of difficulty tends to onlybreed contempt. While the illusion created is often enough to foolplayers who are of a lower skill level, as the effects are much more subtle andcan often work in the player's favour, when that same system is put up againstplayers who are able to make a mockery of even the high difficulty levels, thecomputer is forced to go to incredible levels to try and keep up with theplayer, to the point of blatant cheating, gaining items and abilities far inexcess of the player, and even defying the laws of physics (or whateveranalogue exists in the Mushroom Kingdom).

Another form of fake difficulty that rears its head is that of the falsechallenge (which I admit, sounds a little redundant). In the false challenge, the player is typically asked toperform a standard feat - defeat some enemies, race to the finish in the allottedtime, etc. However, what starts out as a relatively routine task quicklyturns out to be an extreme test of reflexes and ability, as the player is besetwith all manner of unpredictable obstacles, traps and powerful enemies. The key thing is that in all of these situations, the player is caught offguard, and unable to sufficiently prepare. Usually, this results in aquick and frustrating death, as the player likely felt he or she was successfulup until that point. Worst, usually, the only way to surmount this typeof challenge is to try it again, often from the very beginning of the sequence,armed with the foreknowledge of the hidden challenge ahead. When theseare compounded one after the other, it can lead to rage-inducing moments forthe player.

You can't see it here, but in 0.25 seconds, the driver in the blue car is going to develop a sudden case of sociopathy and swerve straight into the player's bike.

One game series which is notorious for this is Grand Theft Auto. While the game's mission-based structure suggests that the challenges faced arerelatively self-contained and straightforward, it's very common for the gamesto prey on the player's expectations in the worst way possible. Oneexample from Grand Theft Auto: Vice City I frequently cite is a racesequence where the player has to reach a number of checkpoints in a settime. No big deal, right? That would be the case, if itwasn't for the fact that other cars, trucks etc. are scripted to pull outaround difficult corners and immediately as the player passes by at full speed- the player is almost guaranteed to hit these cars and ruin his or her attemptoutright, unless he or she is able to slow down and let them passinstead. This just doesn't happen once, but close to five or six timesthroughout the race, meaning that even if the player does everything right,there's still a huge statistical probability that he or she will fail anyway,solely due to the designers pulling a fast one. A similar occurrence canbe found in Max Payne, where enemies are scripted to throw grenades atthe player at certain triggers, and these are literally impossible to avoidwithout prior knowledge.
Suffice is to say, fake difficulty, no matter the variety, isn't fun forplayers, even if it's built into the game with the best of intentions. Although often the goal is to provide an unpredictable or challengingexperience regardless of the player's skill level, more often than not it just comesacross as mean-spirited, and at worst, can completely turn a player away fromthe game by rendering attempts at competition null and void. Unlike mostforms of difficulty, this type is actually best avoided altogether, unless yourgoal is to make players hate your guts.

Random Number Gods

Although this is typically a type of difficulty reserved for strategy androle-playing games, random mechanics do exist in a wide variety of genres,whether they manifest in terms of how enemies behave in combat, the spread andaccuracy of weapons, or whether or not the player is able to sneak by a foesuccessfully.

I've occasionally seen mechanics based on random elements derided by people,claiming that it takes away from the skill of the player to hinge success uponunpredictable odds. The key thing to understand about building difficultyout of a random number generator is that challenge is not substituted for"luck", as some might claim. Rather, difficulty arises as theplayer is forced to respond intelligently to new developments that aren'tentirely predictable - it is the culmination of actions over a period of timethat are important, not the individual actions themselves. Unlike trialand error, which typically tests reflexes and coordination, systems built onrandom elements test the player's ability to respond to change and to cope withnew situations.

As mentioned above, it's also important to mention that random elements areoften a staple in all types of games, regardless of whether or not difficulty isprovided by trial and error, by manipulation of odds, or, ahem, fakedifficulty. Driving a car in a racing simulation, for instance, there'sbound to be some random effect in the vehicle's handling, or on varying typesof terrain, even if it's only a small piece of the overall picture. Thereis absolutely nothing wrong with this, because usually player skill is able toaccount for random elements anyway. More to the point, random doesn'tnecessarily mean unpredictable - it just means that there can be a certaindegree of noise or interference in playing the game, to prevent things fromplaying out exactly the same way every single time. Otherwise, whenplaying Tetris, we'd see the same blocks always become available inthe same order, and that wouldn't be nearly as fun to play, as the game itselfis based wholly around bringing a degree of order to that randomness.

Unfortunately, building systems out of random number generators,particularly in role-playing games and strategy games, it's easy to fall preyto a problem - not in the mechanics themselves, mind, but in the player'sperceptions and understandings of them. This usually manifests as what'scommonly called the gambler's fallacy. The simplest example is a coinflip. Even though a coin only ever has a 50/50 chance of landing heads ortails (assuming it's a fair toss), we tend to assume that the 50/50 probabilityapplies to all instances of the event in sequence, rather than the isolatedevent. In other words, we form a narrative as we flip that coin over andover again, perceiving each coin toss not as a single incident, but part of alarger whole - and as such, we also tend to assume that prior events have aninfluence on future events, or, put simply, that the more the coin lands heads,the greater the chances we think it has of landing tails.

Frayed Knights is about as fun as a game with spells like "Exploding Kneecaps" can be, but I often got the sense that the Random Number God was out for my blood.

In gaming terms, this can be described in the context of a turn-basedrole-playing game. A skill might have a 70% chance of success when used,yet we become frustrated when, turn after turn, the skill misses and we end upwasting both our time and resources trying to rectify the problem. Whatjust happened? Surely, the game is fudging the numbers! Well, no,not really. We assume that, because the skill has a 70% chance of working,it should (or will) succeed seven out of ten times, like clockwork. Thisis, of course, not at all the case, as each individual attempt has the sameodds as the last, and therefore, it's possible to chalk up a huge string oflosses despite what should be good odds.

There's no easy solution for this problem, because you aren't battling thenumbers, you're battling player expectations. Many developers actuallyget around this problem by instituting measures to make sure that random oddsare, in fact, more predictable. For instance, if I have that 70% chanceof success, I might program a clause into the game where it's impossible tomiss more than one time in a row - even if ultimately the math is completelyoff. That's right, often, the random odds most players feel they rely onaren't actually random at all, but instead manipulated to fulfill theexpectations players have. The irony of all this is that usually theplayer only ever notices that there's a "problem" if the math iscorrect in the first place. Obviously this is a controversial decision,and not everyone will agree with it one way or the other, but in the end it'sprobably better to fulfill player expectations than it is for those sameplayers to wind up frustrated over what they feel are unfair and incorrect odds.

Presentation is Everything

The header here might draw some flak, but I think that this is a lesson thatis very much unsaid when designing games, and yet at the same time one of themost important to learn. Difficulty, as I've outlined, comes in many flavoursand is highly subjective - however, it is also important to recognize that theway difficulty is presented to the player is also just as, if not moreimportant. Similar to the gambler's fallacy, sometimes it's not aparticular mechanic that's the problem, it's the way that players perceive itthat's at fault.

Let's take a recent example in Dead Money, the Fallout: NewVegas DLC add-on. The game came under attack from both players andpress alike for what they perceived as a steep difficulty curve. In DeadMoney, the normal endless freedom of Fallout gives way toslavery, as the player is thrust into a very specific and mostly linear paththrough the game by way of a bomb collar, which will instantly kill the playerif he or she strays too far for the beaten path. Many of the challengesin the game rely on destroying the radio transmitters that broadcast thedetonation frequency, which are often hidden underneath tables, inside closets,or are otherwise difficult to reach. The goal in this situation is tocreate tension for the player as he or she desperately rushes to find the radiotransmitter before his or her head is explosively removed.

It's pretty clear, from an outsider's perspective, to see why this mechanicwould be frustrating to players. The bomb collar produces a high-pitched,persistent beeping when under threat of detonation, which players quickly learnto avoid like the plague, for one. There's also something particularlydemeaning about being enslaved in such a way by the antagonist. Othergames that do this typically do so in such a way as so that the player regainshis or her freedom quickly - while it's a good way to breed contempt for thevillain, draw it out too long and that contempt falls onto the game developerinstead. Last, this kind of enforced limitation goes against what mostplayers take the newer Fallout games for, namely, open-endedrole-playing games with a variety of solutions for every situation; in DeadMoney, frequently there is only one solution, and it's often the oneplayers aren't happy with.

Bomb collars got you down? Don't worry, we've got a special offer on brain surgery to keep your spirits up!

However, the problem with Dead Money isn't the mechanicitself. Analyzed at a basic level, all it is a simple race against timeto remove an environmental threat - turn off the switch before you die. The bomb collar mechanic, while effective in terms of the storyline, could havebeen replaced with any number of similar mechanics and still would have beenjust as effective. More importantly, it wouldn't have been nearly asfrustrating to players. For example, radiation and toxic hazards areextremely common in the Fallout world - why, then, didn't Obsidianchoose to instead implement the same threat in the form of radiation and, say,vents to clear it up? Interestingly, this variation actually exists in DeadMoney, but is used to a much lesser degree. Had the bomb collar beenreplaced with a game mechanic which was functionally identical, but less atodds with Fallout's design tenets, I think there would have been farfewer complaints about the game's difficulty, because in that case, thechallenge would have been perceived by players as fitting far better intoFallout's world, and less limiting overall - after all, if it's justradiation or acid blocking your way, that's a much more incidental threat thanthe villain's scheming, which if anything comes across as deliberate griefing.

Looking around, I think you'll find more and more examples of perception ofdifficulty being a bigger problem than the difficulty itself. I canalready think of a few off the top of my head - the jarring and repetitivetaunts made by the bosses in Deus Ex: Human Revolution, for instance,are extremely grating on the nerves even if the boss fights themselves aren'toverly challenging with a little preparation. Usually, in fact,associating a character with a given type of difficulty (say, Boswer and hiscastles in Super Mario Bros.) can quickly cause players to becomefrustrated and annoyed in situations when that character is either alreadyrather annoying, or when the game mechanics themselves aren't enjoyable - itgives people a face to yell at.

Conclusion

This analysis, while far from complete, should have given a pretty goodoverview not only of a few different types of difficulty, but it should alsohave made understanding why people get upset at different types of games,different scenarios, and different sorts of difficulty a bit clearer. Creating and fine-tuning difficulty is always an ongoing process, and it's extremelydifficult to get it right for all players. Even so, hopefully this piecehas shed some light on exactly why that is, and what steps can be taken at amore fundamental design level, in order to ensure that your game is fun toplay, and challenging, without being frustrating as well.

Observations on User Interface Design

2011-10-11T18:12:00.000-04:00

The user interface is something that doesn't get much attention. Much like good sound design, when a user interface is done well, the player doesn't notice it - and when it's done poorly, it can be aggravating and damaging to the play experience, to the point of turning some players away from a game. Although we tend to talk about good and bad interface considerations, it's rare that I really see many people go into precise detail about just what makes a good interface. In this article, I'd like to take the time to go over what I consider to be the key tenets of good user interface design - while I don't want to suggest that this is the only approach to take, in general, just about every game with a good interface I've seen has adhered to most or all of these points, and ignoring them usually leads to poor results in the end.

Function Over Form

Although it's nice to have a good-looking interface, the absolute worst thing that a designer can do is build an interface that ends up encroaching on the functionality it's supposed to be providing the player. While this problem can manifest in some very obvious ways from time to time, it's worth considering the small ways in which placing visuals over functionality can hurt a game.

Wait... you mean all those dials and buttons don't do anything?

Take, for example, Fallout 3 - while the Pip-boy 3000 gives the game a significant dose of personality, helping to include what is usually a meta-game element within the game world, the Pip-boy is also generally poorly laid out precisely as a result of the designers prioritizing the look and feel of the interface over basic usability. Over a third of the entire game screen display is consumed by the Pip-boy, and many menus devote over half of the remaining screen space to large icons rather than providing more information to players. Combine this all with menus nested within other menus (and, in New Vegas, menus that toggle between different functions) and it's very clear that the desire to include the Pip-boy was so strong that it ended up sabotaging and hiding some of the game's most fundamental information. It's a classic case of prioritizing "cool stuff" over crucial information and usability, and it could have been completely avoided with a little forethought.

Compare the Pip-boy above to Diablo's health and mana orbs - they're distinct, and aesthetically interesting, even defining for the Diablo franchise, but they aren't obtrusive and remain easy to read and understand. Even the original Fallout, age and different standards aside, was more successful interface-wise than Fallout 3. All the technology and shaders thrown onto a menu can't change the fact that it's still cumbersome to use.

Interface is a Frame

Where many games treat the interface as just that, a tool, Fallout and Diablo treated it as more: a portal into the game which serves to reinforce the fiction, the tone and mood. A good comparison to draw is a picture frame - while a picture in itself can be beautiful, a good (or bad) frame will completely change one's perception of that picture, regardless of just how lovely it is on its own. This doesn't have to be completely literal: while the two games above do actually form a sort of frame around the game, and others, such as Ultima: Underworld literally treated the perspective view as only a single part of the gameplay experience, others, such as Half-Life, achieved the same effect by grounding the heads-up display in the narrative. The HEV Suit is one of the most iconic elements of Half-Life, and grounds us in the game's world... despite the fact that we barely even see it.

Not only is Diablo's interface functional, it also helps define the game world.

While I often see it said that heads-up displays and other aspects of game interfaces can draw players out of the game, remind them of the barrier between them and the virtual world, I've always felt this is a poor argument that, if anything, is refuted by play experience. Contrary to this opinion, I find that most often, a good interface will actually improve immersion, rather than detract from it, and by attaching certain game functions to in-universe objects, the player can feel as if he or she is operating an actual mechanism within that game world, rather than simply pressing buttons on a gamepad. Granted, this can be taken too far, as seen in Fallout 3, but when the balance between aesthetics and usability is struck, the user interface goes from being just a tool, to a legitimate and defining character within the game world itself.

Don't Hide Information

This is another tenet that I feel doesn't see much discussion, at least with regards to interface. Put simply, a designer should anticipate the information the player will need during gameplay, and put the most critical of it on-screen at all times. For a shooter, this is pretty easy to figure out - health, ammunition, armour, and so on are all safe bets, and unless removing these common HUD elements is part of the game's design, there's rarely a reason to consider much more as far as shooters go.

But what of more complex games, or those which require the player to juggle more information at once? Too often, I see games which simply model their interfaces after first-person shooters, without much of an attempt to actually consider just what things the player might want to see during gameplay. Instead, information that the player might well want (or need) at a glance ends up buried in menus and sub-menus, meaning that not only is the player inconvenienced, but he or she may completely ignore that information entirely. To be blunt, if this happens, then the user interface has failed: its one goal is to give the player the information necessary to gameplay.

250,00 gold and still unhappy? What must I do?!

Although otherwise a fantastic game, the 2004 remake of Sid Meier's Pirates! has one annoying flaw of this nature - though several critical aspects of gameplay are linked to the game's timer, often there is no precise information given on how much time the player might have to accomplish a task. The one that stands out the most for me is crew morale: although the interface displays a general indication of the crew's mood, and the player is able to respond to the crew's needs based on this, there's never a clear indication of just how much time the player has left to salvage his or her situation, or how much gold the player needs to find to improve their spirits. Where sometimes I'd be able to survive for months on end with a near-mutinous crew, other times my morale would plummet radically over the course of a single day, and suffice is to say, it really is no fun when you feel you have little control or understanding of why something in a game.

Give Me Details!

On a related note, it's a fairly common trend in gaming nowadays for the information available to players to be minimized or abstracted. Although generally considered an attempt to streamline gameplay, more often than not, this sort of approach ends up being confusing and detrimental to gameplay. Put simply, if there's no reason as to why information shouldn't be provided to the player, then there is no reason why that information should be withheld... and if you have the opportunity to be precise rather than vague, then precision should almost always win out.

Without a standard for what those bars indicate, these "stats" aren't particularly reliable.

A great example of this can be seen in Call of Duty: Modern Warfare 2. Although it features a deep and engaging multiplayer component, with strong RPG leanings in its equipment progression, perks and so on, the game hesitates to provide players with some of the precise information that they might want when playing the game. This ranges from the simple (how much damage, exactly, does a weapon do?), to a bit more crucial (what is the radius of a Frag Grenade versus C4?). Although the game does provide some statistics for players to review, interestingly, these aren't expressed as numbers, but rather, as simple bars... while this makes for a more approachable menu (no need to include a character sheet in your shooter), the data provided is vague at best and, according to fan feedback and testing, occasionally quite inaccurate as well. Yes, sometimes you want to just give the player the basics... but at the same time, there's no reason why players shouldn't be given the details either, because you can bet that there are plenty out there who want those details, no matter what the game is.

Minimize Required Input

Along the same lines, it's worth considering just how the player is going to get to that information. A mouse click? A hotkey? A nested list menu? A drop-down scroll box? A check box? A grid navigated with the thumbsticks? Pages flipped through with shoulder buttons? Game consoles especially have limited input functionality, and so additional prioritizing is necessary for console games, but regardless of the platform, all information should be quick and easy to get to, without fuss. Although I hesitate to provide a golden rule, if the player needs to perform more than two or three commands to find the information he or she is looking for, then chances are, it's harder to get to than it should be, and the more layers you have, the less likely the player is to ever refer to that information.

Civilization V gives you the information you need, but rarely in a way that's convenient.

Of course, this can be easier said than done. Sometimes, user interface can become necessarily cluttered, complex, or hidden - this is especially common in strategy games, where the player needs access to huge amounts of information, but only on occasion. There's nothing wrong with nesting information that you know players won't always need, but never put it deeper than it absolutely needs to be. Civilization V, for instance, despite being an excellent game, has major problems with this. While information on which players desire what resources can be easily found, for instance, the resources they themselves have available are only accessible on the trade screen, which requires a completely different set of steps to open up, and information on only a single player can be viewed at any given time. Additionally, the nested nature of many menus in the game and the use of large fonts and icons requires more scrolling than what would otherwise be necessary. While its predecessor's interface was hardly perfect, at the very least it was organized and grouped information together where it would logically be wanted - compared to Civ IV, Civ V can often require twice as many mouse clicks just to perform the same tasks.

Keep Controls Consistent

Have you ever played a game where pressing a certain button or hitting a certain key just didn't do what you expected? Although there's something to be said for challenging genre conventions, usually, deviating from standard key and controller layouts is a poor idea which only artificially increases the learning curve of a game. Unless you're genuinely able to improve on the interface, there should be absolutely no reason why your new game, Medal of Duty, maps the firing of weapons to the A button, reloading to the right trigger, crouching to the D-pad, throwing grenades to the analogue stick, and so forth. On the PC, this need only grows greater - with more buttons than ever available, and often necessary, it can be confusing for the player to have to re-learn all their familiar hotkeys again just for one game. Unless you can genuinely provide a good reason to not map J to the journal in your RPG, or the mouse wheel to switching weapons in your first-person shooter, then simply don't do it.

That said, that's no excuse to deny the player the option to customize and remap keys - even those hotkeys you tried so hard to make consistent. There is no technical reason why players should not be able to do so, especially on the PC, as unlike gamepads, mice and keyboards have far more equally valid button layout. Even so, as a basic usability feature, there is really no excuse not to allow players the option, even on consoles... that is, unless you don't mind telling disabled customers that they can't play your game because of your own oversight.

Convenience, Schmenience

Ah, a new item! Wonderful! I was getting sick and tired of my old Bodkin of the Weakling anyway, but... wait, what's this? The Scepter of Ill Tidings? Well, just how am I supposed to know which one's better? I mean, maybe one's good for bashing, and the other is good for stabbing, but how do I know how, why, and where? What about the damage they deal? Which one is better for me? What about my character class? Ah, screw it, I'll just sell it.

Even something as simple as comparing items can dramatically improve the user experience.

Alright, perhaps the scenario above is a bit of an exaggeration, but it's common to play a game and end up with a situation where you might want to perform a task, such as comparing two weapons, and the game does not make it particularly easy to do so. Whether that's something as simple as not being able to see the stats of both weapons at the same time, or not having a clear indication of which one is useful for what task, or what their requirements are, or how much money is valued at, there are times where the user interface, while not exactly failing, can still easily let the player down. As a designer, it's important not just to give the player what he or she needs, but anticipate what he or she might actually want given the nature of the gameplay. The interface is something that exists to service gameplay, and anything you can do to make that gameplay experience smoother and more manageable is a worthy addition.

Maps

Videogame maps do not have a very good reputation. Sometimes, they take the road of form other function, and end up looking cool without being particularly detailed or useful (The Witcher 2 has this problem from time to time, especially in outdoor areas). Other times, they end up trying to incorporate some sort of 3D gimmick, creating a map that has the rare distinction of being both hard to read and hard to manipulate (for a long time the Splinter Cell games were haunted by this). And sometimes, well, there's just no map at all, or it's stuffed into a tiny corner somewhere. Suffice is to say, if you're going to include maps in your game, they had better be easy to read, access and understand - if they aren't, then you've wasted your time.

Where am I? Why, let me just consult my handy... er... oh.

Of course, creating maps is an additional investment, requiring new artwork, programming, level design work, etc. At the same time, the incredible improvement to a game's usability that a good map can provide cannot be overstated. Even if you feel your game is simple, or small, or easy to understand, it doesn't matter: put a map in it, unless, of course, the player's perspective is such that the playing field might as well be a map to begin with (Supreme Commander and its strategic camera zoom feature). Chances are all players are going to use them at one point or another, and there are plenty more who use them to plan their approaches, devise more efficient strategies and plans, compare play-style with others. They're also extremely useful for writing guides, as well. No matter how much you might insist it's not necessary - trust me, it is.

Conclusion

Although this list is by no means completely exhaustive, I feel that these are the absolute most key points which an interface needs to hit in order for it to be considered good. Thankfully, most modern games have great interfaces, and some of the most basics problems are, in many cases, things of the past. That said, there are still many interface problems that continue to be prominent in the world of gaming, whether that's the withholding of important information from the player for no good reason, poorly-made and useless in-game maps, or the prioritizing of aesthetics over usability. As the metadata layer between the player and the game, the user interface is one of the most important things to get right... and one of the worst you can possibly mess up. Hopefully, this list has provided some food for thought on how to avoid falling into what are still in many cases common issues. Thanks for reading!

Belated Design Analysis: Portal 2

2011-10-06T03:23:00.002-04:00

I had a mixed relationship with the original Portal. Muchlike a number of games that came out during the rather memorable year of 2007, Ienjoyed it, but I felt that it had rather fully explored its gameplaypossibilities - by the end of it, there was little reason for me to continuewith it, or to replay it, and frankly, a sequel was the last thing on mymind. As a result, I ended up largely ignoring its sequel Portal 2during its initial release earlier this year - I love Valve games, generally,but even I was a little bit skeptical as to just how they were going to dustoff the old portal mechanic and give it new life.

This past week, however, Portal 2 hit that magical price point of$15 and so I, along with thousands of others I'm sure, decided to take theplunge and see what I'd been missing out on. Even though I’m now a fewmonths out of date, considering that a lot of people likely picked the game uprecently or decided to give it another go due to its new DLC add-on, I feellike it's a fitting time to visit (or re-visit) Portal 2. In this article,you’ll find a number of my thoughts on the game’s design, both as an individualexperience and as a sequel, with particular respect paid to understanding Portal 2 from a holistic perspective.

I won’t lie - there aren't too many things to complain about in thisgame. Still, however eager a critic I am, and however difficult it is forme to be nice, sometimes one can learn just as much from things that are donewell as from things which are done poorly.

Larger Than Life

One trait which particularly defined the original Portal was its simple and barebones approach to design: set in aseries of test chambers and, to a degree, the rest of the facility housingthem, the purpose-built environments worked extremely well in concert with thegameplay, by focusing attention solely on the mechanics at play. Inkeeping with this, its overall approach to story, pacing, level design andvariety, etc. was fairly minimalist - there were memorable moments, there washumour, and more memes spawned out of Portal than just about any gamein the last five years, but overall it was an understated experience, one whichcould be finished in an afternoon, but was quietly focused and constructed insuch a way as to emphasize strengths and all but eliminate weaknesses.

Portal 2 changes that to a degree. Although the game is stillable to retain much of its charm, and its limited (yet still expanded) cast ofcharacters generally results in a game that's easy to digest and fits wellwithin its frame, the rest of Portal 2 has taken on a decidedlygrander scale. Most obviously, this is apparent in its visual design: thebarren test chambers of the original game have been mostly stripped away infavour of a massive laboratory which builds itself out of panels, robotic armsand conveyors before the player's eyes, huge underground caverns containing theremnants of the older, abandoned Aperture Science labs, and other impressivevistas and settings. While Portal 2gets tremendous economy out of its available art assets by sticking to arelatively small selection, it's still a larger and more varied game, and thiscomes through strongest in the visual design.

Portal 2 doesn't just have new environments, it operates on a completely different scale as well.

However, even though it’s the difference in visual direction that’s firstapparent, it’s soon clear that Portal 2has, on the whole, taken everything about the original game and amplified itall. Portal, in addition tobeing efficient in its design, was also, for instance, quite deadpan and fairlysubtle with regards to humour, with small in-jokes, puns, anti-climacticsituations and dialogue, etc. providing the majority of laugh. Bycomparison, Portal 2 is a bombastic opera. The subtlety tothings is largely gone, instead replaced by more obvious jokes, bizarre references,sight gags, and irreverent banter or arbitrary interjections by various characters. There's still the occasional quiet, sardonic bit, but the majority of it stickslot a lot more and, interestingly reminds much more of the humour seen in (andaround) Valve's Team Fortress 2 and even Left 4 Dead 2.

Characters, similarly, are also cranked up to eleven, with the chatty newcompanion Wheatley taking the place of GLaDOS as a far more proactive guide(more on that later), though GLaDOS herself actually ends up undergoing arather significant character arc as well, her quiet and contemplativesociopathy exchanged for a more talkative and, dare I say, friendlynature. Meanwhile, more new characters, including Cave Johnson, founderof Aperture Science, flesh out the universe while injecting a far greatervariety of personalities into things... and much like Team Fortress 2'sSaxton Hale, Johnson is a boisterous individual whose entire premise seems tobe based entirely on a caricature. Allhe needs is to trade in his strict American accent for an Australian one.

Perhaps just as telling of how Valve chose to enhance Portal 2,however, is in where they decided not to make many changes. Althoughthere were new additions made to the game mechanics in the form of additionalpuzzle options (light bridges, tractor beams, surface-altering gels), some ofthe most obvious temptations were resisted. There are absolutely no newguns or, indeed, tools - everything new to the game can only be manipulatedwith the skill set the player started out with in Portal. Thegame still takes place in the Aperture Science Enrichment Center, even if we dosee much more of it - there aren't any drastically new environments, no tripsaround the world, no flashbacks, no water levels. There are no newvehicles to drive, the soundtrack is still understated in traditional Valvefashion, and the story resists the urge to stray from its simple frame. Thesechoices are not random: they were extremely well considered and calculated.

Generally, many developers are content to maintain the status quo with theircharacters, their game's scale, with their style and delivery, and with theirgame mechanics. However, just as often,they will also add on new features rather indiscriminately, regardless of howit might enhance (or take away from) the experience. BioShock 2'swholly unnecessary multiplayer mode; the nearly complete elimination of stealthfrom Splinter Cell: Conviction; Prince of Persia: Warrior Within'sfocus on combat, scowls, cleavage and nu-metal - we've all played games whereinappropriate changes or "improvements" have been made to thedetriment of the final product, even if they probably sounded good on paper.

Looked at casually, on a broad scale, Portal 2 offers much more ofthe same thing, but I think that the choice to really flesh out the charactersand world, to push the humour to the forefront, the more expansiveenvironments, and so on all, exist to complement not just the new gameplaymechanics, but the greater expectations that come with a full retail price tagand the lengthier story mode. Portal 2 feels different, but itdoes so in the most appropriate way possible. This was a very activedecision on Valve's part, as were all those smaller decisions made about thegame mechanics, direction and so on, and other developers should take note notjust of the fact that Valve decided to expand and improve upon what they had,but precisely how they did so, and in which areas of the game's design.

Visual Storytelling

One of the most common pieces of advice given regarding storytelling is"show, don't tell", which on a basic level simply means that plotpoints, character traits, and other story elements should be communicated, ifat all possible, using the world, the scenarios the characters find themselves in,how characters respond and behave in those scenarios, and so on. Theworst kind of exposition is almost always that which beats the reader over thehead, whether that's through active narration, constant reiteration, orconstrued conversations and dialogue to bring out the details. Likewise, we can learn just as much about acharacter based on how he or she decides to handle a stressful situation – doesshe panic, rise to the challenge, scheme and break the rules to get ahead,etc.? We don’t need to be told thingsthat we can already infer, and usually taking the time to do so is eitherredundant or just slows down the rest of the story.

In videogames, the focus of story and plot generally falls more on theenvironment and the player's interaction with it, rather than the charactersand what is explicitly said by them (though of course, there are alwaysexceptions). If there's a way to give the player information, it's almostalways best to do so through suggestion and discovery, rather than through alengthy block of text or introductory narration. Some developers, ofcourse, excel more at this than others, and the game in question is going tochange the criteria for storytelling as well. Still, it's always been a strong suit of Valve (the Citadel's sheerheight and bleak, alien design in Half-Life 2 is one of their highestpoints in my opinion), and Portal 2 does not disappoint in thisrespect. In fact, if anything it does much more with this than the first Portalever did, and the impact it has on the game’s storytelling, and overall pacing,cannot be understated.

At one point in Portal 2, the player makes his or her way down intothe bowels of Aperture Science, landing in the disused and abandoned cavernswhich housed the previous generations and incarnations of the organization. Although visually impressive and quite different from anything seen in Portalprior to its reveal, it'd be very easy to simply treat this as a pretty pictureand move on with the gameplay. Instead, this environment is used tocommunicate the evolution of Aperture Science throughout its years, itscorporate logo gradually evolving to match the aesthetics of the 1950s and 1960s,the furniture in the old offices matching contemporary fashions, and soon. Almost none of this is explicitly said outright - no character comeson screen and says "wow, so this is what Aperture Science looked like 50years ago!" It's clear to anyone playing exactly what is going onand what details are being presented about the story and the world, but not aword needs to be said.

Details such as Cave Johnson's subtle aging, depicted in his portraits, tell more than dialogue ever could.

There are other, smaller details throughout the game which help toflesh things out as well. At one point, the player comes across an oldwaiting room for test subjects - if one takes a closer look, it becomes clearthat there is a hidden observation room behind this waiting room, based on theprofile of the wall outside, which suggests all manner of things about ApertureScience. A number of climactic events in the game are built up not solelythrough narrative, but by visual suggestion as well; for instance, the shift toa wide-open, seemingly endless vista and a subtle change in colour palette helpto create a sense of foreboding before a confrontation with an enemy, and evenwithout the dialogue going on during this sequence, the importance of theimpending event would be clear. Micro-level details, such as posters andsigns on walls, with ever-so-slightly twisted "health warnings" and"safety recommendations", also help sell Aperture Science not just asa place, but as an organization, and further solidifies the characters withinthe game by providing a firmer understanding of their origins and philosophies.

Obviously, none of this is unique to Portal 2, and there are someamazing games which approach storytelling in much the same way. Still,the decision to communicate these background plot elements by literally makingthem part of the background was a very smart idea. Portal 2, though ultimately quite simple, is positively litteredwith near-constant banter and jokes, and new game mechanics are introduced at aquick pace, with the player's attention often occupied. By providing somedowntime in between these segments, during which exploration and quiet takeover, Valve not only improve pacing, but also provide an ideal opportunity forthe player to absorb information without voices chatting in her ear. Hadthe same attempt to tell a story using the environment been made during thesemore hectic and involved sequences, they would have almost certainly fallenflat - instead, by exercising some control and discipline over just where and howthese sorts of details are used, Valve ended up significantly enhancing whatwould otherwise be fairly dry stretches of gameplay.

Misdirection

There must be an entire team of leprechauns, pixies, and sentient gardengnomes employed at Valve, because Portal 2 completely and utterlyrevels in the misdirection of the player, without it even being entirely apparentwhile playing. One of the keys in designing a good puzzle isn't just tothrow together an end and then have the player figure out the cause - thatworks, but it will only get you so far. All the best puzzle games are theones which are able to toy with and constantly challenge the player'sexpectations, and make he or she look at the tools available in a new light.

In Portal 2, these moments are near-constant. One puzzle, forinstance, revolves around the redirection of three laser beams into threeseparate terminals - the player is given two blocks which are able to redirectthose lasers, but due to the way the environment is arranged, the player willalways be both one block short, and will run into problems redirecting thelasers as well. The environment, by subtly forcing the player to placeportals in certain locations, almost ensures the player will end up in asituation where two beams can reach their destinations, but a thirdcannot. In actuality, the player must place the entry portal in anentirely different spot as to what would seem obvious, but given that thepuzzle seems to be about redirecting lasers, chances are the playerwill spend a whole bunch of time trying to configure his or her redirectionblocks just so, even though it's impossible to solve the puzzle by doing so.

Yes, that's right, keep moving the box... mwahaha!

This also extends to the environments. Much of Portal 2'ssecond half revolves around exploration, but this exploration is performed byusing portals to jump from location to location, rather than hoofing it. At several points in the game, expectations are once against subverted. It's very common to throw the player into a wide-open location with what seemslike a clear way to the end, only for the player to shortly realize that it is,in fact, a dead end - sometimes even made less clear by using subtle visualcues to suggest it is, in fact, the right way. Instead, often the correctway to proceed is found in an entirely different part of the environment. Even so, this foolery is never consistent enough for the player to be genuinelysure of how to proceed, so the trick never wears out its welcome or growspredictable. However, Portal 2 then takes it one step further,by occasionally throwing the player in a huge open-ended area with what seemslike an obvious way forward using portals, only to reveal that the solution isactually as simple as continuing on foot, or opening a nearby door. The door?! Who would have thought?

Last, Portal 2 likes to employ a nasty trick in certain puzzles,particularly later in the game, where the player will be given a goal, but nomeans to readily access it. All the training done throughout the gameforms expectations of how to get across X and Y obstacles, and so whenpresented with a situation where those usual solutions aren't possible, it'svery easy to become lost, frustrated, and confused. However, in most ofthese situations, the solution to the puzzle ends up being as simple asbacktracking - going to a previous puzzle and using a portal or two to ferryover whatever item or tool might be needed to progress. Considering justhow used players are to being given what they need in order to proceed, exactlywhen they need it, but also how Portal 2 builds up these preciseexpectations throughout its entire length, this sort of trick is a lot moreeffective than one would otherwise expect - even at the end, Portal 2isn't afraid to humble you.

A Game of Two Halves

And here you thought you'd be getting away without a firm dose of criticismas well, hm? Portal 2, for all its strengths, can at times feellike two different games at once. The first is a simple, controlled, andcontained puzzle game, one which carefully follows in the footsteps of theoriginal Portal, and is decidedly linear and paced, almost to thepoint of being on rails. The second half is something much closer toValve's Half-Life 2, an adventure taking place in huge environmentswhich revel in the illusion of non-linearity and discovery, where the player isable to sit down and simply absorb the world, take in the atmosphere, and moveat his or her own pace.

This can, unfortunately, lead to Portal 2 feeling a bit schizophrenicat times, like it can't quite decide what it wants to be. As much as Ienjoyed the original game's contained nature, the return to the test chambers,elevators and corridors in Portal 2 feels almost like a mandatorytribute or callback to the original game, there simply because those are nowiconic to the series. When juxtaposed with the far larger, moreimpressive, atmospheric, and player-driven sections, which occur mostly in thesecond half of the game, it's hard not to feel as if, when you're drawn backinto those test chambers, you've had the wool pulled back over your eyes, or toalmost hear Valve saying "oh, right, this is Portal, not Episode3, sorry!"

It also doesn't help that the gameplay between these two sections can bequite different, and indeed, the first half of the game suffers significantly preciselyfrom this. After a very strong, hilarious, and cinematic opening, Portal2 relegates the player to following Wheatley around, who, appropriately,is fixed on a literal rail nearly the whole time. I'm not exaggeratingwhen I say there are entire stretches of the game where the player will donothing but walk forward and listen to Wheatley crack wise - sure, there mightbe the occasional use of a portal to get over an obstacle, but by and large it'sa case of "hold down W to win." The fact that many of theseenvironments are massive in size, have multiple paths which all converge meremoments later, and that the player is ushered through them by a companion charactermakes these parts feel like, frankly, a colossal waste of time. Even onesection involving navigating a pitch-dark area ends up amounting to following ahallway in a straight line. I'm not sure if there was more intended forthese parts of the game, but as they are, they're just mediocre and, to beblunt, feel like filler.

More tests? Come on, this is what, fifty so far?

Only in the second half do the training wheels come off and Portal 2trusts the player to walk from point A to B without the need for a companion toguide him or her down the straight corridor. It's in this second halfwhere Portal 2 truly shines - the puzzles are immediately made moreinteresting by the lack of obvious arrows pointing in the right direction, andwhile there's no gameplay benefit to exploration, the environments are openenough and contain enough little side-areas and red herrings to make gettingthrough them actually interesting. Generally, games driven by fast,intense action and quick pacing forego exploration as a necessary compromise tokeep the momentum up, but in a game like Portal 2, where the player isencouraged to take his or her own pace, and the prospect of portals allow forcreative ways to traverse the environment, there's no good reason why more timecouldn’t have been spent on that.

Granted, this isn't a failing of any of these individual sections of thegame. The puzzles are all excellent and well designed, even if some arereused from the first game for the sake of tutorials, and, when you're in thoselinear sections of the game, you're generally too busy listening to Wheatleymake his quips to pay much attention to just how short your leash reallyis. However, as mentioned above, when put up against the much larger,less guided sections of the game later on, it's hard not to feel short changed,as if you've been given a 4-hour tutorial to prepare for a 3-hour game. Ithink that, perhaps more than any other game I've seen in a long time, Portal2's juxtaposition of confined and highly directed puzzles, and more openenvironments, without any hand-holding, serves as a very good example of howindividual ideas within a game's design, when placed in concert with oneanother, can actually end up having adverse effects due to the way theycomplement one another (or don't) - regardless of how good those individualideas actually are.

Conclusion

While I wouldn't say Portal 2 is the same sort of happy accidentthat the first Portal was (and really, it has no right to be now thatit's been given its own sequel), it's clear that Valve have brought in a lot ofthe lessons they've learned from many of their other franchises in order tohelp make Portal 2 stand up as a retail product. It would havebeen easy to put together 30 new test chambers and some throwback gags aboutcake, but instead Portal 2 was carefully considered and constructed insuch a way as to craft a game that was both identifiably a sequel, while alsoimproving not so much in every way possible, but in the right ways toaccomplish the design goals Valve approached the game with.

The vast majority of the improvements made to Portal 2 aren't justgood in their own rights, they also possess a great deal of synergy between oneanother - the exploration stages both facilitate the use of visual storytellingto fill out the game world, which in turn satisfies the need for a morepronounced and defined story without actually cutting into Portal'strademark simplicity, which in turn helps to more effectively ground the largernumber of gameplay mechanics, as well as to pace their introduction. Gamedevelopment, and especially design, is always about knowing how individualgameplay, sound, story, and visual elements correlate to the project as awhole, as well as how they are able to influence one another, and Valve did atremendous job in making sure that Portal 2's disparate improvementsadded up to produce a sequel that was, quite literally, more than the sum ofits parts.

Thanks for reading, and I hope you enjoyed this piece, despite it being justa little bit behind the times! Please feel free to leave any thoughts youhave in the comments below!

Good and bad controls: "it's a feature, not poor design!"

2011-09-19T13:39:00.000-04:00

If there's one thing I hate about the survival horror genre of games, it's that so many of them seem to revel in an active contempt for the player. I admit that I'm not the biggest fan of horror games in general, but there has always been one thing that's kept me out aside from the fact that I'm generally not a fan of being frightened, and that's the fact that consistently, those games are limited by some of the clunkiest controls I've ever had the misfortune of attempting to use.

I'll set the stage. You're playing Resident Evil, what's supposed to be one of the premier survival horror classics. You've entered the mansion, you're into the atmosphere and the mood... and then, suddenly, you're under attack by a zombie! Your first instinct? Run away, of course... but as you try to move in the most obvious direction, your character instead chooses to turn, slowly and methodically, in a complete 180 degree arc over the course of about two seconds... and before you're even able to make a break for it, the zombie is gnawing on your head's gooey innards. Stupid game.

Although I like to use Resident Evil as an example, there are plenty more games that do this sort of thing... both in and outside of the survival horror genre. Another similar game I played lately is Dead Space, which, though enjoyable, was marred by the fact that the game's mouse controls were extremely sluggish, and his turning radius was such that fast maneuvering was an impossibility. Presumably, this was an attempt to simulate wearing Isaac's heavy mining suit... but when it comes to actually playing the game, it ends up hurting the overall experience. At best, it feels like an artificial barrier... and at worst, it can feel like the developer had no real understanding of how to design an intuitive control scheme in the first place.

Controls are a gateway

When I think about control schemes, the number one thing on my mind isn't "how can I cram all this functionality onto X number of buttons" or "what do we need to cut to get this setup to work", it's "how can we map parts of the input device in a way that is logical, consistent and functional?" It can be easy, especially with complex games, to lose sight of precisely what it is the controls are actually designed to do in the first place: give the player a way to effectively manipulate a character or set of abilities within a virtual environment. Above all else, controls need to be easy to understand, intuitive, and logical within the confines of that environment.

Let's take an example. In Fable III, the controls are set up in a simple, easy-to-grasp and highly consistent manner - the analogue stick manages character movement, and the various face buttons are relegated to interaction with the world (A), melee attacks (X), ranged attacks (Y) and magic attacks (B). The player is able to modify the sorts of functions these buttons perform by holding down the button for varying lengths, with a longer button press leading to a bigger and more impressive action in-game. Got a fireball spell? Hold down the button and now it provides an area-of-effect flame burst. Warhammer? Hold down its button and you'll perform a powerful sweep around you. These control functions change a bit based on the weapon or spell equipped, but they make perfect sense and are never inconsistent with what the player already understands.

Now, granted, obviously Fable III is a fairly simple game compared to some, and it doesn't require the same finesse of Street Fighter IV, but there is never any question while playing what button does what, how the player performs an action, etc. After a brief learning curve, the player can simply pick up the game and play it. The controls, effectively, serve as an extension of the player's will within the game world - they are not a barrier, but a conduit which allows for free expression within a game's ruleset. And due to the nature of those controls, the player never feels that he or she is denied options when playing the game, or artificially limited by the input available; if a mistake is made, it's due to the player's lack of ability, or reflexes, not the control scheme. It's this ideal, controls which serve as a gateway into the world, that I think games should strive for.

Controls are tactile

Another great advantage of controls, gamepads especially, that I tend to see ignored or overlooked by developers, is that there is a great tactile, kinetic feeling to using them. Have you ever got a new keyboard, or gamepad model, and found that your relationship towards the game felt completely different? As one of the few ways we're able to interface with virtual worlds, the physical nature and feeling of an input device is extremely important to immersion - and because we are so limited in the way we perceive those worlds, our minds naturally fill in the gaps while playing.

Pressing a button is never just "pressing a button". The process behind the action is far more complicated, even if we don't actively realize it. From our thoughts, come motion - we want to perform an action, and so we move to manipulate the controller in a way that we know will service the outcome we desire. From our movement, the controller actuates, and there is a time wherein the controller must operate on a mechanical level to transmit that motion to the game. Finally, we actually see the results of our thoughts, movements, and the controller's own mechanism appear on-screen. Even though we think of this as one step, there are several along the way, and they are all equally important to constructing the overall "feel" of operating with a game. Swinging that massive warhammer wouldn't be quite so satisfying if there wasn't a physical act associated with it, and when we charge up a larger attack, holding down the button gives us a feeling of anticipation for the outcome.

An easy example of how the tactile nature of controls has improved the feel of a game immensely has been in the racing genre. Prior to the introduction of analogue shoulder buttons, acceleration and braking was a matter of holding down a single face button or two - in order to vary speed and maintain precise control, one had to "feather" the accelerator. While still a matter of skill, this didn't make for a particularly convincing or realistic driving experience. Come the inclusion of analogue shoulder buttons, however, used for both gas and brake, suddenly the act of virtual driving was significantly improved: now, there was a direct 1:1 relationship between how distinctly one of those shoulder buttons was pressed. Effectively, driving went from 2D to 3D.

Another more direct example of the kinetic nature of controls comes from an older title, Goldeneye 007. Originally released for the Nintendo 64, one of Goldeneye's biggest claims to fame was that it was able to build an effective and fun first-person experience on a game console, with true 3D graphics and movement, precise controls within that 3D environment, and with gameplay which actually took advantage of those technical features. However, I place much of Goldeneye's success control-wise in the hands of the Nintendo 64 controller - while still considered an extremely unconventional gamepad, its single Z trigger, located at the bottom of the controller, was able to, more satisfyingly than just about any other conventional console controller, simulate the feeling of firing a weapon. Had shooting in Goldeneye been a matter of simply hitting the A button, it probably still would have been fun, but the feel of actually wielding a weapon and firing it would have been significantly diminished. Rare quite clearly realized the advantage of having a strong tactile feeling to their controls, and I think it contributed much to Goldeneye's success.

Controls are consistent with what we know

While much is made in the videogames industry of innovation, even around control schemes (see Splinter Cell's mousewheel-driven movement speed, or the low/high profile system in Assassin's Creed), often the best control setups are those which stick with what we know. While there's much to be said for reinventing the wheel, there's a pretty good reason why the wheel remains in use - it's damn good at what it does, and sometimes there's just no need to mess with it. Moreover, a new control scheme represents a risk in that players are going to need to learn how to use them before playing. While all games have a learning curve, of course, making the player try something unconventional input-wise when he or she would really just sit down and play the game can be a detriment to the user experience. There's a good reason so many strategy games stick to left-click -> select and right-click -> move, and why so many RPGs use keys like J for Journal, L for Log, or why WASD is now ubiquitous in PC games - not only do they make sense, but they're established methods for doing things in those genres, and players are familiar with them.

However, this point doesn't just extend to what users know from prior games - it also extends to what they know about reality. One of the reasons the controls in Resident Evil can feel so alien and so cumbersome to users isn't so much because the button mapping is all that wrong, but because the way the player interacts with the game world in Resident Evil feels completely divorced from any reality he or she may know. Put simply, we know how human beings can move, what speeds they can run at, how fast they can turn, how quickly they can react... yet Resident Evil chooses to ignore all of that intuitive knowledge about the real world that everyone knows, and decides to give the player a completely different set of limitations which can only be understood through repeated trial and error. While the zombies may have an excuse (we know zombies are slow, plodding, and clumsy, after all), Chris Redfield is supposed to be an elite S.T.A.R.S. operative - unless their standard equipment package comes complete with concrete shoes, that fundamental disconnect between what we know about the world and what is presented in the game is extremely unsettling, and can even be enough to turn someone off of a game for good.

That said, there are definite exceptions to this rule. One of my biggest pet peeves, as a shooter fan, is the inclusion of mouse smoothing, acceleration, and other related practices in first-person shooters, especially when it's implemented in a limited fashion. Battlefield: Bad Company 2, for example, features fairly precise mouse controls, but, when piloting a tank, or carrying a heavy machine gun, the sensitivity and acceleration of the mouse suddenly changes significantly. Presumably, this is done in order to more effectively establish the fact that the player is carrying a heavy object, or has taken control of a powerful machine, and so the developer has attempted both to impart that same kinetic advantage of gamepads, and to help balance the game. While a lot of this comes down to preference, I feel that in a completely skill-based setting, these sorts of artificial limitations on controls take the emphasis off of player skill and relegate the player's role to a component in a rock-paper-scissors equation. The sluggishness may be a bit more realistic, but when feeling the player is left with is "the controls screwed me over", I feel that realism can take a backseat, especially in what is otherwise a fairly arcadey game. Similarly, I don't think fighting game fans would be very impressed if you told them that suddenly there would be a 0.2 second delay between one input and the next.

Conclusion

The most important thing to keep in mind when conceptualizing control schemes is the question of "what is the most intuitive and natural way to perform a function, bearing in mind the physical capabilities and nature of our input devices". The fact is that, while there is no true "right answer" to building controls, keeping in mind some of the ideas expressed above can help build control schemes that get players into a game, rather than out of it. And perhaps, more importantly, it will help to avoid those artificial barriers that hurt immersion and defy existing player expectations in the worst of ways.