Narrative "modes" in video games

As a follow-up to my last post about differences between Japanese and Western-style RPGs, I thought I would point to another article from Gamasutra (what can I say, they publish great articles) that I saw today. It's an interview with two of the people behind Portal, on which, if you haven't been reading lately, I have a bit of a fanboy crush.

It's a great interview (if a smidge rambly in spots), but the part that's relevant here is the bit about, well, narrative. Here's a quote from Eric Wolpaw, Portal's lead writer:

We had this theory that games tell two stories. There's the "story story" which is the cutscenes and the dialogue, and the "gameplay story" which is the story that's described by the actions you take in the game world. The theory was that the closer you could bring those two stories together, the more satisfying the game would be.

I spent years and years reviewing games, and that's something that always bothered me in games, where the delta between the two stories was real high. I promised myself someday that if I ever got the chance, I'd try to make a game where that delta was almost zero. It was a conscious decision that we wanted to try and keep that world.

This to me is a really important insight and helps explain the special sense of immersion and, for me, empowerment that comes from playing a game where your own actions in the game world are tightly aligned with the narrative being "told" in the game.

I've only played a few games that gave me this feeling. Portal is one; Myst is another. Both are first-person perspective games (where that perspective is never broken), and both are puzzle games. Both present a profoundly coherent sense of place. Seems like the start of a promising recipe. Even Myst, though, doesn't completely close the gap between "story story" and "gameplay story." As the player you wander around creating the "gameplay story." The "story story" has, for the most part, already happened and is revealed as you play through pages you find on the various islands.

In other words, your goal as the player in Myst is just to supply an ending to the "story story." In Portal you supply the whole thing, which is pretty special.

Seems like the same idea could be applied to RPGs in their various incarnations. In Japanese-style games a la Final Fantasy, the gap can be pretty wide. The story might be compelling and the characters unforgettable, but the gameplay mode and the story mode are totally distinct. Gameplay stops when narrative starts and vice versa. Western-style games maybe close the gap a bit, but there's still the sense that your total experience in the game world is much different than the story being told through the main quest line. Sure, I could convert my gameplay experience with Oblivion into a story, but, man, would it be boring.

Japanese vs. Western RPGs; story vs. gameplay

Gamasutra posted an article a few days ago about the 20 essential Japanese RPGs. It's pretty long but worth a skim. I've spent most of my gaming life (until recently) fairly insulated from reviews and online chatter about the quality of games I played. As a result, I knew what I liked, but I didn't know if anyone else agreed. It was fun to read someone else's take on those games.

Turns out I have played quite a few of the ones listed, including:

• Final Fantasy IV
• Final Fantasy VI
• Final Fantasy VII
• Final Fantasy VIII
• Final Fantasy X
• Final Fantasy XII
• Chrono Trigger
• Chrono Cross

Lots of Square games on that list, obviously, but they were only one of two or three outfits creating US-bound RPGs in the 80s and 90s. Plus, I liked all their games, so I tended to go out and buy them.

I've never played Xenogears, but I did play the first installment of Xenosaga, and I definitely agree with this article's take on that game:

Still, once again, the plot [of Xenosaga] was simply far too ambitious for its own good, and the number of planned installments was cut down from six to three, compressing the plot even more. It didn't help that the first two games were saddled with terrible pacing issues, plodding cutscenes, and boring battle systems.

Japanese vs. "Western" RPGs
This article also intrigued me because I'm still working on Oblivion (which will no doubt be a looong process), and I've only just begun to understand the differences between Japanese and Western-style RPGs. This is yet another way in which I'm a little slow, but I have never really spent much time with any Western RPGs before Oblivion.

I tend to like story-based games with interesting characters, and Western RPGs have leaned away from story and more toward gameplay, with their open-ended worlds and emphasis on first-person role-playing.

To avoid launching into a rant about the state of stories in games (which you can find here at Blog of War, and also here and here), I'll just say that so far I still prefer the Japanese model. Most definitions of narrative require an some act of telling (by an author and/or narrator). It's this author who interprets events and helps shape their meaning.

Japanese-style RPGs tend to acknowledge the existence of an author/narrator and adopt a more cinematic style -- they tell a story. Western RPGs tend to drop you in a world and let you, in a sense, create your own story. The trouble with this model is two-fold for me:

1. Most of us aren't good story tellers. The things we do in these spaces probably isn't very interesting. If I choose to spend my time in Oblivion on alchemy, I'll just run around collecting seeds and roots all the time. Nothing riveting there. Sure, I could play the thief or the wizened wizard, but these are just types; they're not characters with flaws and emotions. I want characters.
   
2. There's no one to tell the story to. If a story needs a teller, it also, out of necessity, needs an audience. If a man tells a story in a forest and no one is there to listen, is it still a story? Sorry... The point is that I can certainly entertain myself in a sandbox-type game -- where I'm the story-teller with no audience -- but I find it far more compelling to be an active audience member, using the available gameplay to move a story along.
   

That's my two cents. What's your preference?

The big city

First of all, I apologize for the brief lapse in new posts. Work was hectic last week and involved a trip to New York. It was my first time in New York, and I wasn't quite prepared for the scale of things or the sense of awe that a city so big commands. Upon leaving, I was struck by the urge to play SimCity, probably because the trip ended with a flight over the city on a clear night.

Where does the urge to build a city come from? Not sure, but I think it has something to do with the way cities seem to behave like organisms -- constant while constantly changing. It's not a new metaphor, but it is a brilliant dynamic to try to capture in a game.

Reflections like this leave me wondering about the relationship between story-based and open-ended games. SimCity doesn't have a pre-ordained story. Indeed, Will Wright (the creator of SimCity) and others would tell you that the narrative value of open-ended games like SimCity is in the communication of events after the fact, rather than in gameplay itself. Even more, he would likely say that the best games are ones that possess the most narrative potential without dealing with a specific narrative (in other words, games that encourage storytelling among players).

The Grand Theft Auto series, though, is a nice example of games that accommodate sandbox play along with a directed (though branching) storyline. Some might call the story optional, but really it's not. The size of your sandbox in GTA depends directly on completing at least some of the story.

Since I'm working on a story-based game, I feel compelled to address somehow the possibility of open-ended play in my game world. How I'll do that remains to be seen. A lot of games resort to side quests, the search for hidden items and hidden bosses, etc. These are good options, but they are once-and-done activities. At a certain point, you can accomplish everything. Maybe that's desirable, though. Stories always have a beginning and an end, so to some extent they can't coexist with purely open-ended gameplay. Maybe the best answer is something like GTA or Will Wright's upcoming game Spore, which I've heard him describe as goal-oriented gameplay designed to prepare you for the ultimate sandbox experience.

I can envision adaptive story-based games where the player's decisions truly affect the world and the characters, but they are still some years away (D&D-based games like Knights of the Old Republic don't quite cut it, in my opinion). In the meantime, I'll continue mulling the issue while I build a virtual city to rival Manhattan.

Real-time battles, part 3: party AI

My last post about real-time battle systems looked at requirements for enemy AI. This third (and final) installment will deal with party AI.

To me one of the most significant differences between a turn- or time-based battle system and a real-time system is how the other members of your party behave. Old-fashioned time-based systems like Final Fantasy VII usually have random battles that take place in a temporary battle area. The advantage here is that the player can easily give orders to every member of the party during the battle, since only one party member or enemy can execute a move at any given time.

In a real-time system, things happen too fast to give explicit orders to each party member throughout an entire encounter. One obvious solution to this problem is not to have a party. But if you don't take the easy way out, you have to prevent the rest of the party from being a liability.

The common approach to party AI is, first, to give the player a way to switch control between active party members at any time during a battle and, second, to provide a short list of general behaviors for AI-controlled party members. These often give you three choices along the lines of aggressive, defensive, and support (healing and ranged attacks).

Unfortunately, these limited options usually result in party members that seem to get themselves killed (but only after using up all your items), and there is no way to customize their behavior any further.

Final Fantasy XII's gambit system finally offered a better and more fun option for party AI. By giving the player access to the if-then structure (e.g., if an ally's health drops below 50%, cast cure on that ally) of the party AI system (and by making it a part of the character leveling scheme), party AI became not only useful, but fun. Creating just the right combination of gambits became almost a game in itself.

One criticism of FFXII's gambit system, of course, is that the more gambit combinations are available, the less you have to pay attention during battles. You can literally run up to a group of enemies and go get a snack while your party defeats them. In some ways this is quite nice, but could be quite annoying for players who like finer control. Turning gambits off is always an option, though.

I haven't yet designed the party AI system for my game, and I don't know how I'll approach it. Some amount of control over party members' decisions is essential, but a more robust system would need to be carefully integrated into the gameplay and could distract from the primary character leveling system (which is going to be very cool, but I don't want to give it away just yet).

But until it's time to program party AI, I will turn my attention back to modeling buildings and other inanimate objects.

Real-time battles, part 2: enemy AI

My first post about real-time battles dealt with timing -- how to pace a battle so it's fast-paced but leaves just enough time to make decisions. Part 2 deals with a considerably more complicated topic: enemy artificial intelligence (AI).

Before I begin, a disclaimer. I don't know anything about AI -- at least not about programming it (yet). These thoughts are just that: reflections on what's required to simulate an intelligent adversary. The way I see it, the problem of enemy AI can be divided into two parts (at least in terms of RPG games like the one I'm making):

Basic movement
In a real-time battle system, enemies exist in a world filled with obstacles -- rocks, trees, buildings, other creepy monsters -- so enemies need the ability to move around the world without doing silly things like trying to walk through a wall or wandering into the ocean.

Basic movement, then, requires that enemies have the ability to move around in a normal fashion (when nothing is in the way), and to avoid obstacles when they arise. Normal movement, of course, can take several forms. One enemy might patrol between a series of fixed points while another might wander aimlessly in a particular area.

Neither of these possibilities is very convincing, however. It would make much more sense for enemies to move about the world with a purpose. Not only would they lead happier and more fulfilling lives, they would seem more realistic. An evil imperial soldier might indeed patrol between fixed points, but a giant cave bat wouldn't spend all its time wandering within five meters of the place it was born.

Higher brain function (deciding what to do)
Wandering is fine, but what if a player (or group of players) invades the cave bat's cave? It would protect its turf by attacking the intruders. The first order of business is to decide who to attack. This decision is easy enough when there is one player-controlled character, but in a party-based or multiplayer game it obviously becomes more difficult.

Many games solve this issue with the concept of aggro. An enemy might attack the first player it sees, but if another player comes in and deals twice as much damage, he will draw the enemy's attention. Aggro, then, can be thought of as a function of damage or healing. Whichever player in range has offended the enemy the most becomes the object of its raging cave bat wrath.

Once the enemy has decided who to attack, it must then choose the manner of attacking. The conventional way to approach this problem is to build a decision tree. Given its set of possible moves, the enemy will survey its situation and choose a move, often with a healthy dose of randomness built in. For example, a monster with access to a healing spell and a basic attack might go through this sort of thought process:

• If my health is less than 60%, heal myself.
• Otherwise, attack the player with the most aggro.

The options in the decision tree get priority based on their order. As you might imagine, these trees can get pretty complicated. It's not the most sophisticated way for enemies to make decisions (they can't learn), but it is the most straightforward.

A similar approach is also useful for party AI, which I'll discuss in part 3. I know you can't wait.

My camera, vanquished

After three days of wrangling with my code and muttering to myself, I have managed to get my camera system to a place where it mostly behaves. Having accomplished this, I feel a new sense of admiration for games with cameras that gracefully avoid passing through floors and walls. It's still possible to make it pop through a wall occasionally or to find just the right spot where it will completely freak out, but it'll do for now.

Here's the gist of how it works:

• Just before every frame is drawn on screen, the camera casts a series of rays to detect objects around it. The primary ray starts at the camera's target (the player) and casts back toward the camera, ending a short distance behind the camera. A group of secondary rays are also cast pointing outward from the camera itself, like spines sticking out in several directions.
  
• In normal circumstances (when no offending objects are near the camera), the camera can be moved around by clicking and dragging the left mouse button.
• If an object interrupts the primary ray (i.e., passes between the camera and its target), the camera jumps to a point in front of the object. Once the object is clear, the camera slides back to its preferred distance from the player.
  
• If the camera detects an object below it (like the ground), it will begin sliding toward its target. In this mode, the camera's distance to the target is proportional to its own distance from the ground.
• If an object gets too close on the left or right side of the camera, the camera will slide along this object toward the target until it slides clear and can move along unobstructed.

So why was I having so much trouble? My camera didn't have enough feelers sticking out of it. My initial setup only cast rays backward, left, right, and down. With so few, it was easy to make the camera think it should be moving forward and backward at the same time. Once I added a few more feelers--essentially increasing the resolution of my collision detection--the camera started behaving more like I planned.

Then the muttering diminished, and I cracked open a beer.

The virtual web, and how to avoid hitting the ground

The other day I stumbled on an intriguing new project called Metaplace that's aiming to provide an easy-to-use, web-standards-based way to create virtual worlds. The possibilities for creating games are obvious, but this seems an interesting step for the Internet in general.

If Metaplace works like they say it will, it would be possible to turn your web site into a virtual world--meaning that your site wouldn't just deliver content, it would provide a place where people could gather and discuss that content. Imagine being able to chat in real time with anyone else who's currently visiting a site. It could be an incredibly powerful way to make connections. This is a big step beyond our current social networking setup, where people just leave messages amounting to little more than, "I wuz here."

--------------------

On a game-related note, I spent most of my time today working on camera collisions. There's nothing worse than a game with bad camera controls. I'm trying to build a camera that's smart enough to keep the player always in sight. This means recognizing when it can't see the player and moving to a place where it can.

I've gotten to the point where my camera can handle direct obstacles well enough. Things get tricky when it needs to avoid objects like the ground. It doesn't make much sense to look at the player-character through the ground, so the camera needs to recognize when its getting too close to the ground (or something like a wall) and move to a safe spot along the vector between the camera and the player. This involves a lot of math for an English major, so I'll just have to take it slow.

Real-time battles, part 1: timing

Ok, so my last post wasn't exactly about real-time battle systems like I said it would be. This one is.

As I mentioned previously, there are advantages to a real-time battle system (like World of Warcraft or most other MMOs). For one, you don't need to whisk the player off to a "battle mode" that exists in some parallel universe. Another big advantage is that battles can be more realistic. Enemies and party members can attack and be attacked at any time, and there doesn't need to be any god-of-the-battle AI that dictates when each character or enemy is allowed to execute a move.

As you might expect, these advantages come with their share of tricky design decisions. This is the first in a series of posts that will discuss some of the common ones. Where to start?

Timing

Attack speed -- At first glance, timing seems easy. Each character or enemy has an attack speed, probably determined by some stat or the awesomeness of your weapon.

Cooldown -- Ok, that might be enough if all you do is flail about, but what if you want to give your player a special "extended flail" skill? You wouldn't want him to be able to string these together endlessly (it just wouldn't be fair), so you need a cooldown time for each ability or skill.

Charge time -- So now you can't eliminate your target with an endless string of "extened flail," but couldn't you just string together every skill in your arsenal and gank your unsuspecting target that way? (Indeed, this is the method used by every god-forsaken rogue in World of Warcraft.) This wouldn't be too challenging, either (yes, I played a mage), so you also need to implement some system where abilities require time to execute. Then you need to decide whether the charging process can be slowed or interrupted.

Down time -- This is similar to cooldown, but instead of affecting a single ability, down time affects your ability to do anything at all. After executing your supremely powerful "nuclear meltdown" ability, there might be a period of time when you can't execute any new moves, which leaves you vulnerable to the giant cockroach monster that survived the meltdown. Final Fantasy XII used down time instead of cooldown; WoW imposes a uniform down time of about a second after each move, in addition to skill-specific cooldown.

Easy enough, right? Part 2 will cover the intricacies of enemy AI.

In Blizzard's shadow

Hello, my name is Ben. It has been one year, five months since I last played World of Warcraft. I am proud of my resistance to the temptations that keep tugging at me, like The Burning Crusade, the fact that all my friends and family still play, and the peer pressure brought on by the Scroll of Resurrection.

Despite my resilience heretofore, I find it hard to escape the shadow of WoW that looms over my game. This is particularly obvious in my control scheme. Left click to look around your character. Right click to turn him. Scroll wheel to zoom in and out. Some of these are standard features of PC RPG controls, but I find that as I refine the controls, almost all my decisions are made by furrowing my brow and trying to conjure memories of how they did it in WoW.

As you might imagine, this is cause for concern. The easy thing would be to grab The Burning Crusade free trial from my bookshelf and fire up my old account. (I stood over the trash can for a minute after receiving said free trial but could not bring myself to toss it. Now it just watches me work.)

No, the right thing to do is mimic the intuitive parts of the WoW control scheme then try to improve on the frustrating bits. I don't want my game to look or feel like WoW, but genre is a useful thing and must be acknowledged, even as it relates to keyboard input.

Now if I could just remember those frustrating bits...

Oh, for a space helmet

I played Metroid Prime 3: Corruption for the first time tonight. Aside from the usual "wow, this is really cool" effect of playing Wii games, two main things about the user interface struck me as very well done.

• First, the controls (of course). The running, aiming and shooting action all take some getting used to, but there are some very nice touches, like moving the wiimote toward and away from the screen to activate a door lock.
• The heads up display (HUD) is also really nice. Samus Aran of course wears a nifty space helmet, and the HUD actually looks like a visual overlay from inside her helmet. So instead of information sitting on the screen in some sort of omniscient way, it really looks like you're seeing only what she would see. It's also possible to make out the faintest reflection of Samus' eyes in the HUD, which is a brilliant detail.
  

Ok, so the controls and HUD basically make up the whole user interface, but the sense of immersion is almost immediate and breaks rarely (most notably when she rolls into that little ball).

This of course leaves me wondering how to improve immersion in an RPG-type game. Standard RPG controls and HUDs hardly make sense at all, actually. How do you know how many health and magic points your target has? What do menus and hotkey bars have to do with making decisions in a real battle?

One answer is that the objective is different in FPS games than RPGs. FPS's rely on first-person perspective and a direct connection between player and avatar. Often the in-game character's face is never visible. RPG UI tends to be much more akin to omnicient third-person perspective in a novel, where the player assumes a god-like control of characters' actions. Maybe these two kinds of perspective are just there for different reasons, to facilitate a different kind of immersion.

This to me seems like an easy out for RPG developers. I think most of the time the quality of immersion (and story telling) takes a back seat to the goal-oriented "game" aspect of things (why else would you need to see a number flash on screen every time you deal damage?). Some would say that's the way it should be, but I'm not so sure.

So how do you combine the best of both worlds? I'm not sure yet, but my best idea so far is to have all my characters wear space helmets.