Leaderboard

It's been a while - aside from Obsidian work, I've been doing quite a bit of talks here at Dragon*Con and across the sea in Spain at Gamelab on a variety of subjects, from advice to getting into the industry, to Kickstarter, and even our approach to designing characters for video games. Even better, I'll be doing the same coming up here in October at Austin GDC's narrative track concerning Obsidian's narrative approach - and going through our design process at the end of the month overseas concerning design as well (more on this as it happens). Still, it's nice to be home and back into the thick of things here. Speaking of which, for those of you who've come to visit the page, you may have noticed our countdown. Our countdown to what? It should become clear in 4 days or so -- stay vigilant.

Something that seems to frequently come up when discussing the design of a game system is whether or not some aspect of that system adheres to reality. Or, more precisely, whether the outcomes of that system accurately simulate the results that the person making the argument expects, based on their particular interpretation of reality. Generally, these arguments come from players, or from non-designers, or less experienced designers, and will take the form of, "But XXXX isn't realistic!" or "Realistically, YYYY should happen instead". And, frequently, experienced game designers will turn around and say "Who cares?" and merrily go on their way designing an "unrealistic" system. I wanted to give a quick explanation of why this is, explain what role I see realism as having in game design, and then provide a bit of a defense of "realism" as it relates to something I call the "responsibility of expectations" that is placed on any game design. First - game designers primarily ignore or devalue realism because their primary goal is rarely to construct an accurate simulation of a real world. At their core, game systems are sets of rules that encourage and discourage, or reward and punish, certain choices within the game versus others. In establishing both what choices players can take, as well as the rules effects of those choices, designers are generally attempting to create a system which a) avoids "dominance" b) provides opportunities for players to differentiate their strategies based on the decisions they take, and c) give players opportunities to make "good plays" in response to opponents (be they computer or human controlled). As a very basic example, take armor in Fallout: New Vegas. Wearing Light Armor has strengths (you move faster) and weaknesses (you absorb less damage). Wearing heavy armor has the opposite effects. Heavy armor does not dominate Light Armor, even though it performs better at its core functionality, because there are cases in which moving faster is more important than absorbing damage. For a more complex example, because the game uses subtractive DT, low DAM weapons are disproportionately affected by DT. So, for instance, if a creature has 5 DT, going from a 6 DAM weapon to a 7 DAM weapon doubles your damage (your actual damage goes from 1 to 2). Whereas, if that same creature had 0 DT, going from a 6 to a 7 DAM weapon is only a 1/6 increase. This is an example of how you can encourage the player to make "smart plays" - when fighting an enemy in light or no armor, you are encouraged to use your highest DPS weapon regardless of its DAM. Whereas, when fighting an enemy in heavy armor, you want to select a weapon with enough DAM to significantly overcome its DT while still having enough DPS to deal substantial damage over time. When combined with the other properties of weapons (range, rate of fire, spread, etc.) you end up with an interesting matrix of choices in which players are encouraged to find the optimal weapon for any given situation. No weapon is dominant, players can select from a group of weapons they like based on their own personal playstyle, and there are opportunities for players to maximize their effectiveness through smart play. These are the core goals of most game designs. Many games have other additional goals, and simulating reality is sometimes one of those goals. But when you evaluate a system from the perspective of someone trying to create as good a game as possible, these goals are paramount. The problem with realism is that, in reality, there are strongly dominant options. Catch 22's exist. I can't imagine ever wanting to bring a knife to a gunfight. If I was going to be venturing into the Mojave wasteland, you bet your ass I'd want to only wear the heaviest power armor I could find and only use the biggest gun I had... plus I wouldn't have an invisible backpack full of other weapons I get to choose to optimize my damage in other situations. So, often, the goals of realism and the goals of quality game design conflict, and in almost all cases realism is cast aside. That explains why realism is so often ignored. However, there are two cases where realism is important - first, in creating a sense of "verisimilitude", and second, in dealing with the responsibility of expectations. Verisimilitude is a term that, like "truthiness", I'll use to mean the extent to which something "feels realistic", even if it is not. For instance, again, I'll use eating, drinking and sleep deprivation, in F:NV's Hardcore Mode (if Hardcore mode is off, these features are not present). These may not actually realistically simulate the mechanics by which a person becomes starved, dehydrated or sleep deprived. The rates, and effects, are almost certainly not identical to what you'd encounter in real-life. However, the fact that I am thinking about food and water in the wasteland, and the fact that I am happy whenever I find a delicious, delicious fresh barrel cactus fruit, gives my journey through the wasteland a taste of reality. Not realism, but "truthiness", or vertisimilitude. Note that these aren't really mechanics that work as I described above. It is a strongly dominant option to have water, and to drink it when you get thirsty. It's not really a valid playstyle to be "the guy that never drinks water". But, in this case, it is a small enough part of the system and has enough of a positive effect on verisimilitude that it's worth having the system, IMO. Finally, when players approach a game, they come both with their own personal baggage/knowledge, and they form opinions on things in your game before they ever interact with the actual gameplay of those things. As two examples, I'll use Civilization and Power Armor. First - in Civilization, one of the most common complaints has been the situation where 1000 spearman defeats a tank. It seems ridiculous that something like that would even be possible. Yet, in the game rules, it is clearly an outcome that is possible, and tailoring the rules to avoid that outcome could have deleterious effects on the actual gameplay, in which case it may not be worth it. In fact, allowing lower-tech units beat higher-tech units helps avoid over-rewarding players that fast-tech and start off isolated - if tech was as dominating in Civ as it is in the real world, the game would not be much fun, even though it would be more realistic. However, players do come with that expectation, and that is something you have to deal with - so the ideal solution would be one in which the balance of the game isn't ruined but spearmen can't, in fact, beat tanks, because players come into the game with expectations and preconceived notions, and it's generally a bad idea to violate them (unless you're trying to make a point in violating them, which is maybe a bit too post-modern for a video game). Next, let's take the example of Power Armor in F3. None of us knows how Power Armor works in "reality". So, our preconceived notions aren't about the actual function of the armor, but instead the weight that it's given in the art and lore of the world. When, in the intro movie to F3, the camera trucks out to reveal the fully power-armored soldier, you can't help but think "Wow, that guy is a badass. I bet that armor is awesome!" If, in the game, you then found that armor, and it was barely better than leather armor, you would be disappointed because your expectations had been violated - the game art wrote a check that the mechanics couldn't cash - and that's a drawback even if the game works perfectly well as a game that way! This is something that Rob Pardo talked about at the last GDC - it's important that you respect the fantasy in your game and not violate it through the game mechanics.

At work, we have a lot of rules for how to write. These range from punctuation (single-spacing after terminal punctuation) to spelling ("all right" vs. "alright") to structural (where a "goodbye" response should be relative to a "start combat" response and where that should be relative to a "friendly" response). Every project has a document (or documents) on the specific guidelines for that project. In spite of all the details, there are certain high-level principles that tend to be common. Okay, maybe it's just in my mind, but here are principles that I believe are important for writing player-driven dialogue in choice-heavy RPGs. * Dialogue should inform and entertain players -- inform them about the world and quests, entertain them with interesting characters and prose. If you aren't informing or entertaining, think hard about what you're trying to accomplish. * Write an outline. Really. Just do it. You should have an idea of where you are going before you set out. If you don't know where you're going when you write your conversation, chances are the player is going to get lost at some point. * Always give at least two options. At a bare minimum, you should always have an option that says, "Let's talk about something else," that leads back to a node where you can say, "Goodbye." You may think that your dialogue is riveting and no one could possibly want to stop reading/hearing it, but believe me -- someone out there does. * Never give false options. Do not create multiple options that lead to the same result. It insults players' intelligence and does not reward them for the choices they make. * Don't put words in the player's mouth. With the exception of conditional replies (gender, skills, stats, etc.), phrase things in a straightforward manner that does not mix a request for information with an emotionally loaded bias ("I'd like to know what's going on here, jackass."). * Keep skills, stats, gender, and previous story resolutions in mind and reward the player's choices. If it doesn't feel like a reward, it isn't; it's just a false option with a tag in front of it. Note: entertainment value can be a valid reward. * The writing style and structure are the project's; the character belongs to you and the world. As long as the dialogue follows project standards and feels like it is grounded in the world, it is your challenge and responsibility to make the character enjoyable and distinct. All of these principles exist to support this basic idea: your audience is playing a game and they want to be rewarded for spending time involving themselves with conversation. If it is a chore, is non-reactive, is confusing, or is downright boring, it is the author's failing, not the player's.