Sinister Soups Serving Musings On Game Development and Play


Mousing in Diablo 2: An Analysis

Having played some Diablo 2 again a bit ago (as evidenced by my last post, wherein I describe the process I had to go through to get the game running), I started thinking carefully about the design in that game with regard to targeting and attacking.

Since it's a 10-year-old game, I was reminded of some of the many issues I have with the way the interface works in general, and some of the highly questionable decisions they made, in my opinion, just to try to make sure that the game was vaguely playable with nothing more than a two-button mouse, even though every computer has a keyboard.

Still, this post isn't really about that, and rather than complain about questionable UI, I'm going to quickly discuss the way the two mouse buttons target enemies, and activate the skills mapped to them, because I think there are some interesting decisions there.

The left and right mouse buttons are the only method of activating abilities in Diablo 2, and the appropriate LMB or RMB hotkeys must be changed to the skill you want to use, before clicking that button to cast it.

The left mouse button is limited to melee and ranged projectile skills, and passive abilities or abilities that target a specific location or area of the screen are not allowed.

The left mouse button is also intended as the primary method of navigating the world, and clicking on empty space with the LMB results in the player character moving in the direction of the cursor. The character continues to move as long as the button is held, and will navigate around objects or enemies in its way without interacting with them.

It's important to note that this is the functionality of the LMB regardless of the skill that has been bound to that button, and even if a projectile skill (such as Ice Bolt) is bound to the left button, it will not be fired if the player clicks on empty space. In order to actually use a skill bound to the LMB, the player must click directly on an enemy, at which point he may hold the button down to stay locked onto that target and repeatedly use the LMB-bound skill on it.

The other way to use the skill bound to the LMB is by holding the Shift key, which forces the character to stand in place and attack. In the case of a projectile attack, holding shift causes the character to shoot projectiles in the direction of the cursor without moving; while in the case of a melee attack, the character will swing its weapon in place without moving, and will lock onto any target that moves within range of that attack, but will not pursue the enemy if it moves away as long as Shift is held.

The right mouse button is both more complicated and more interesting. For one thing, it is the only way to cast passive spells on the player character, such as buffs or auras, and it's the only way to cast spells onto specific areas of the screen, such as Fire Wall, or even Teleport.

Furthermore, since the right mouse button is not intended to be the primary method of moving around, it treats projectile skills as though Shift were held down. In other words, projectile skills bound to the RMB will cause the character to stand still and cast whenever the RMB is clicked, even if Shift is not being held.

Melee skills have an even more interesting functionality when bound to the RMB.

If an enemy is clicked directly with a melee skill bound to RMB, it becomes a locked target as long as the button is held, and the character chases it around, performing the melee move repeatedly until the target is dead, which is identical to the LMB in functionality. If, however, a melee attack is bound to th RMB but the player clicks and holds in empty space, rather than directly on an enemy, the character will navigate in the direction of the cursor, just like with the LMB, but instead of avoiding enemies, it will lock on to the first one it runs into, and perform the bound melee attack onto this new target until it is dead.

The variable ways in which these two mouse clicks are treated is interesting, especially because at first glance the two buttons seen interchangeable if one has not played Diablo 2 before. These subtleties of design reveal that the left mouse button is meant to be treated more as the "moving around" button, while the right mouse button becomes the "utility and attack" button.

The design also makes clear that Diablo 2 has a concrete implementation of a player's current target, at least as long as the mouse button is held down, which is what make it possible for the "move and lock on" functionality of melee skills on the RMB to work, and for players to simply hold the mouse button down to keep attacking, rather than having to click for every attack on the same enemy.

I think the way the game utilizes the right mouse button in particular is quite clever, especially because I think the "move and lock on" functionality could be adapted quite well to a console controller. Basically, different face buttons would be bound to different skills, and if one of these buttons was held while the player moved with the left stick, the character would lock on to any nearby enemy and start repeating the bound skill.

Action RPGs, and indeed, action games in general tend to emphasize button mashing on the console. However, even a game as old as Diablo figured out that having to constantly click while fighting off waves of enemies is annoying, and instead made it so that mouse inputs were held, and clicks were merely used to select new targets. I could see going this route for a console action RPG, trying to draw the focus of gameplay to strategic skill use, instead of making the player spam a button just to accomplish anything.

Filed under: Game Design No Comments

Direct vs. Derived Statistics in RPGs

In the RPG space, there are generally two ways to handle character attributes or statistics.

Each stat is used and modified directly.

The first, simpler solution defines a set of stats that a character needs for the mechanics of the game to work, and then exposes them directly, allowing items, spells, level gains, and other modifiers to explicitly raise and lower these stats as necessary. Japanese RPGs tend to go this route, with simple stats like Attack and Magic, which are then directly modified by improved weapons or accessories. I will refer to this method of managing character stats as a Direct Stats system in this post.

Damage is derived from Power which is derived from Strength and Agility.

The second common solution, and more popular in western RPGs, is a system of primary attributes like Strength and Dexterity, which are often directly customizable as a part of the leveling process, but which generally do not affect game mechanics directly. Instead, these primary attributes control derived stats like Attack Power or Critical Chance, which are used directly in game mechanics, and which are calculated from the primary attributes according to some formula, which can vary depending on the character class. For example, in WoW, the Attack Power derived stat raises damage from physical attacks and is derived entirely from the Strength attribute for most classes, while Rogues instead use both Strength and Dexterity to compute it. I will refer to this method of managing character stats as a Derived Stats system in this post.

The benefits of a Direct Stats system are simplicity and understandability. As long as a player understands a stat's basic function, it is fairly easy for him to figure out how important it is to his character, and consequently, what items and abilities to concentrate on. If he wants to make a character that is exceptional at killing things by hitting them with a hammer, and knows that the Attack stat directly affects weapon damage, he knows to prioritize Attack over other stats.

A Derived Stats system, on the other and, can be a lot less understandable, since it tends to be cluttered with a large number of stats, some of which seem to represent similar concepts (Strength vs. Power?) and explaining the relationships between them is no small challenge. This is exacerbated when primary attributes are treated differently by different classes, meaning that even if a player learns how a stat works for one class, they may be in trouble when they try another.

The downside of a Direct Stats system is that with such clearly defined stats being the only defining characteristics of a character, it can be harder to differentiate characters. For instance, it is likely that all physically oriented characters will need the Attack stat, despite the fact that they are meant to have different flavors and different powers. With such a clear-cut set of stats, it's hard to put the stats to use in creative ways that still makes sense. Sure you could make a class that loses Attack instead of HP when it is hurt, for instance, but a lot of people are going to complain that such a weird mechanic ruins their immersion.

This is where a Derived Stats system can really shine, you can add a lot of variety to the mechanics governing your classes when you choose to derive stats differently for Rogues than Warriors, for instance. Furthermore, having both derived and primary stats available means that you can bind certain abilities or class features in unexpected ways, sometimes using a primary attribute for an attack, for instance, and primary attributes also work well for role-playing scenarios outside of combat.

The Right Tool For The Job

As is often the case with this kind of thing, neither of these two approaches to character development is necessarily better than the other, instead, there are specific situations where one may be more useful than the other.

The Direct Stats system most commonly shows up in Japanese RPGs which have simplified and distilled the systems they learned from early western computer RPGs like Wizardry and Ultima. Those games, on the other hand, adapted their mechanics from pen and paper RPGs, specifically Dungeons & Dragons, which through four editions has kept and refined the quintessential Derived Stats system of Strength, Dexterity, Constitution, Wisdom, Intelligence, and Charisma.

The origins of these two systems are not a coincidence, and considering them, we can quickly come up with some conclusions about the types of games best served by each system.

Derived Stats are often the best fit for games that share a lot of similarities with pen and paper RPGs. Games where the player only controls one character, for instance, can have complicated derived stat arrangements because the player will only have to master that one character's class to be effective, without having to worry how another class works. Such a system is especially important in a multiplayer game like WoW, where players often have to work together and share the loot they find. Since even classes with similar functions, like Rogues and Warriors again, need different primary attributes to grow their derived stats, you can easily create loot that is more useful to one than the other, reducing conflict over who should get an item.

A Derived Stats system is also a great fit for games which, like pen and paper RPGs, offer a lot of gameplay outside of pure combat scenarios, since the variety of available stats, all important to different types of characters, and all with specific flavors (my character is very Wise!) can be used in conversations with NPCs, in quests, or generally to advance the plot.

The Direct Stats system can be equally valuable, however, and it is often the best choice in games where the player must control or manage a large number of characters. Imagine that you have a roster of 20 characters, each has a slightly different class, and each class derives its relevant stats slightly differently. Do you want to have to remember exactly how each one of those classes uses the Strength attribute every time you need to decide who to give a sword with +Strength on it?

Similarly, a game with a heavy focus on combat, where battle is the primary gameplay mechanic and 90% of your time is spent fighting something is probably better served by a Direct Stats system. This is particularly true if the combat in question is highly strategic, and requires a lot of meaningful choices from the player at every turn. In a game like this, information is one of the most important resources at the player's disposal, and being able to clearly present information about the player's characters, so that it is always clear exactly what a stat does, and how the character will be affected if that stat is buffed or debuffed, can make the game a lot more satisfying and enjoyable.

So there you have it, each of these two systems has their uses, and the key is to consider what kind of game you want to make, and what you want the player's experience with the game to be like.

The next time you are playing an RPG, gentle reader, consider how the designers chose to represent your characters' attributes. Chances are there are good reasons they chose the system they did, and you can learn quite a bit by considering what those reasons might be.

Filed under: Game Design No Comments

Star-Crafting A Fun Online Experience

You realize that this is nowhere near enough pylons, right?

It should come as no surprise that Starcraft 2 will include a matchmaking system as its default method of starting multiplayer games. Blizzard went that route with Warcraft 3, to ensure that players could find good challenges for their teams and be ranked on fair matchups, as is necessary when you have a ladder system to support.

While the system in Warcraft 3 was good for its time, it could also be said that it had its flaws, chief among them its propensity for matching you with people who would proceed to curb stomp you.

At least, as a rather mediocre RTS player, that was my experience with the thing, and judging by the Penny Arcade strip linked above, I wasn't alone.

Luckily, Blizzard seems to be working to ensure that Starcraft 2 doesn't have the same problems. I had already heard that it would have different ladders for different skill levels, so that the more casual fans of RTS, like myself, might actually have a chance to compete with others on their level. Now, a recent article at the Escapist reveals some other steps they are taking to address problems with skill mismatches.

Their first major improvement is limiting each copy of the game to creating a single account, rather than allowing unlimited accounts like their former games. The reason this is important is because there is a certain breed of griefer who likes nothing more than to stomp on newbie players, a practice apparently called "smurfing," which they can only do by creating new accounts with no win history. If they tried this with an experienced account, the game's matchmaking would never match them with the a newbie player, since it tries to match very closely based on skill.

Handily, by limiting you to a single account, you can't go around creating what are essentially griefer or troll accounts, whose sole purpose is to ruin other peoples' experience. It also integrates nicely with Blizzard's recent update to a single-account Battle.netsystem, which now integrates WoW accounts as well, and will definitely be required for future Blizzard products.

The other thing mentioned in the above article, is that they are considering adding some slack to their matchmaking. Apparently, right now, the matchmaking in Starcraft 2 is too accurate, to the point that players are pretty much always matched on an even level. While this is fair, it leads to poor pacing for someone playing a night of Starcraft 2. Every game they play is a breathless, tooth and nail fight, and it doesn't allow the more relaxed play one might get playing a more novice opponent, nor the extreme challenge of facing a better player, which many people swear by as a means of improvement.

Ultimately, I think Blizzard is on the right track here. Exceptional matchmaking, combined with limited accounts to ensure honest skill levels means that both great players, and the really terrible ones (like, again, myself) can have good, exciting games without undue frustration, and I can definitely see the benefits of a slight random component to ensure a more interesting gaming session.

If I were them, I would actually consider going a step further than pure randomness, and think about how they can craft the sort of pacing they want. Since they seem to already be thinking in terms of a series of consecutive games, a session if you will, it wouldn't be too hard to start coming up with heuristic rules to give players the sort of experience that they desire, or alternately, that Blizzard wants them to have.

For example, if a player loses a couple of games in a row, maybe the system adapts to give them a few easier matchups, to give them some breathing space and a chance to try to apply what they might have learned from their defeats against a less demanding opponent. If they are willing to give players this kind of control, they could even allow you to choose from a preset difficulty, or "experience" that they'd like to have that night. Maybe I choose the Relaxed experience, and am only matched with opponents who are my level or lower, while another player wants a Meat Grinder, to hone his skills or just wrack his brains, and is therefore matched only with people of significantly higher level.

Of course, I'm sure Blizzard is already thinking about these sorts of things, and there are challenges there, such as making sure that someone who wants an easy experience is only matched with players who want a hard one, or you just get the same sort of griefing play this whole thing tries to avoid. Still, it'll be interesting to see what lessons Blizzard pulls from the current closed beta, and how the online RTS landscape will change when Starcraft 2 is released.

Filed under: Game Design, Games 2 Comments

Re-RPGing Mass Effect 2

This should be my last post about ME2, I feel like I've said most of what I have to say about it at this point, but I did want to share my thoughts on some aspects of the game that I feel Bioware simplified too much.

The one thing I would bring back from the original Mass Effect is the inventory system. Mass Effect 2 essentially doesn't have an inventory, and instead periodically awards you pieces of armor for different body parts, and a very limited number of new weapons that are pretty much just obvious replacements for your starting guns.

While customizing your armor is neat, it takes away the unique aspects of different suits of armor, instead having each little piece give a small bonus to HP, or Shields, or Biotic Damage. It also takes away armor classes, which means that no matter what character class you play, you'll always have pretty similar protection, rather than the light, medium, or heavy protection afforded by different armors in the first game.

Loot is an important part of the character improvement you expect in an RPG, and if done right, it doesn't have to be the mess it was in the original game.

Less Is More

A revised inventory system should avoid duplicates. In the original game, you would end up with 10 Phoenix IV armors, for instance, or 20 Toxic Rounds VI weapons mods. I would bring back armor, weapons, and weapon mods as items, but I would only let you get one of each type.

If you acquired, say, the Phoenix Light Armor Mark I, you would never find another such suit, nor would you find Phoenix Light Armor Mark II or any other upgrades. Instead, these would literally be upgrades, so that if you really liked the sort of stats that the Phoenix Light Armor emphasized, you would find schematics to upgrade it to Mark II, Mark III, etc.

In this way, you wouldn't end up with a crowded inventory, because each type of item would only take up one slot, but each item could also have cool unique properties that would make you want to upgrade it if it was your tool of choice. Maybe the Phoenix Light Armor can bring you back from the brink of death one time in a firefight (via magical biotic adrenaline or whatever), and has an especially good biotic defense. If that appeals to you, you would devote your resources to upgrading that model, and maybe let other models you have access to fall behind, at least until you get more resources or more upgrade schematics for those items.

The same would be true of weapons and weapon mods, you would only have one such item in your inventory, but that would just represent the fact that you can outfit your team with those items, not that you only have one instance of it. This way, you could still outfit multiple weapons with the same (upgraded) weapon mod, and give your team members upgraded weapons and armor (though more on this in a minute).

The key to this, of course, is that the game must have a wide variety of interesting armors, weapons, and mods for you to find. Bioware completely ignored this aspect in Mass Effect 2, maybe giving you one piece of mediocre "loot" per story mission, and not having enough variety in weapons that you would ever want to use the starting shotgun once you got the tier 2 version.

Instead, give us unique shotguns with stats that matter, whether that's firing rate, accuracy, knockback... look at Borderlands, there is a game that randomly generates weapons that feel fresh and unique without just being obvious linear upgrades.

Mass Effect 2 already allows you to upgrade things like overall shotgun damage, so instead, let us upgrade individual weapons and armor, so that we can customize our offense and defense how we choose, using whatever unique items we prefer.

The Party Problem

There is one aspect to this design that I am ambivalent about: whether you should be able to equip your teammates, like you could in the original game, or if you should only be able to impact it a little, like in the sequel.

On the one hand, equipping your party in the cool items you have found can be satisfying, and it lets you customize their performance. On the other, it also makes for a lot of unfun micromanagement.

In Mass Effect, I only used one team after a certain point, I never swapped out Liara or Wrex simply because unequipping the great stuff they were wearing and equipping it on someone else was too much of a hassle. Because you could only choose weapons for your companions in Mass Effect 2, however, and their armor never changed, I ended up using all sorts of different team makeups in the sequel, and I feel that this definitely added to my enjoyment of the game.

Being able to take whatever party members you like without having to worry about their equipment lets you have a lot more role-playing fun: bringing along characters you might want to learn about, or whose reactions you'd like to see to specific events.

I think that having the sort of inventory I described above, where you would only see one instance of a piece of armor, but could equip it to as many party members as you like, would make it so that you could still keep your whole roster's equipment up to date pretty easily, and so it wouldn't hurt to let you equip them.

Ultimately, though, I think this is the sort of thing that should come out in testing, and if it turned out to still stifle the ability to take any team you want, I wouldn't be opposed to just limiting the armor switching to your main character like Mass Effect 2 does.

Filed under: Game Design, Games No Comments

All I Have To Say Is… Civilization 5!


Civilization 5 exists! And it looks pretty!

I'm excited! So excited! Civilization 5 was announced today, with a release date of Fall 2010. I wasn't expecting to see a new Civilization game this year, since there haven't really been any rumors to that effect, so I guess they did a good job keeping it quiet.

I make no secret of the fact that Civilization 4 is one of my favorite games ever; in my opinion it took everything that the series had done up to that point and really distilled and refined the hell out of it:

  • It solidified the concepts of borders and culture, which had been added in Alpha Centauri and Civ 3, but hadn't been as fully integrated into the design as they should have been in those games.
  • It adopted and adapted Alpha Centauri's civic system, allowing greater and more satisfying customization of your society.
  • It even worked to resolve the problem of city spam in earlier games, where building tons of cities right next to each other was the optimal strategy, by making a smaller number of specialized cities the way to go, which is the way I had always wanted to play.
  • It had extensive modding support built in, which led to excellent fan modifications like the critically acclaimed Fall From Heaven II.
  • The design centered on a functional multiplayer from the very beginning, which ensured that it wasn't buggy and useless like it had been in some of the previous games.

Civilization 4 really is a gem, I still play it to this day, and play it online all the time with an old friend of mine.

With that in mind, I am really excited to hear about a new Civ game... but I'm also a little bit worried.

My primary concern is that the design of Civ 4 was spearheaded by Soren Johnson, whose blog you can see prominently linked to on the right there and whom I mention as a sort of inspiration of mine on my "about me" page. Soren Johnson no longer works for Firaxis however, he joined EA to work on Spore a few years back, and while I'm sure Firaxis has plenty of talented people, I would feel much more at ease about this new entry in the series if he were the mastermind behind it.

The only entry in the series since Civ 4, the console Civilization: Revolution, had some interesting ideas, but was also a much more simplified version of the game, and that was a game designed by Sid Meier himself! As far as I understand, Sid is now working on the Facebook "social networking" version of Civilization, so I assume some other promising designer is in charge of Civ 5. Whoever that is, I wish them luck, and hope they can pull off a really great followup to one of the greatest games ever.

Wild Speculation!

We don't really know much about the game at this point, the official site linked above doesn't really have any meaty details, and there are only three screenshots, though they look very pretty. However, I'm going to take the time to do some speculating on how the game will differ from Civ 4, based on those screenshots.

The biggest takeaway from the shots is definitely the fact that the game uses hexes instead of a square grid, a first for the Civ series! This may seem like a drastic change, but it really isn't; the previous game used a square grid, but since you could move freely on diagonals, it was really more of an octagonal grid in disguise.

From the screenshots, it looks like cities will still have a radius of two tiles that they can work, though now that will mean two hexes out, instead of the old "fat cross" setup of the previous games. I infer that that's how it will work from the city in the screenshot above, which seems to be working a forest hex south-east of the city center and one hex away from it.

Units look like they have a lot more soldiers in them, which might just be a stylistic decision to make them look more realistic, or they may be adapting the army mechanic from Civilization: Revolution, where you could merge several units of the same type to create a single army unit, combining all their strength together. If they did adapt the army mechanic, that would be a major change to how the PC game plays, and I'm not averse to it, since I thought that was one of the more interesting additions to the console version.

My last major takeaway from the screenshots is that there are still resources on the map (like horses and cows), and it looks like you can still claim them with an improvement like you could in Civ 4, so I'm hoping that goes largely unchanged from the last game. One thing I'm not clear on though is if you even can still build improvements, or if they've gone with the system from Revolution, where a square worked by a city looks like it's improved, but you can't actually build a farm on a hex, or a mine, or a windmill.

I really hope they haven't done away with improvements like they did in the console game. It may sound silly, but having a ton of improvements at my disposal, letting me modify my empire's territory as I see fit, was a key feature of earlier games for me. I loved developing my land and optimizing my cities to be as efficient as possible, more than even the diplomacy or war aspects. I was very pleased with the number of terrain improvements they added in Civ 4, somewhat reflecting the crazy terraforming possibilities in Alpha Centauri, like the borehole: a giant strip mine drilled down into the planet's crust.

So yes, it's really too early to tell exactly where they're going with this game, but we can see how wrong my speculation turns out to be in the months to come.

I really do hope they're not going the "massive simplification" route to make it more accessible, though. We PC gamers like our strategy titles to have plenty of juicy complexity, and it would be a shame if they failed to take the computer's strengths into account when making this game, and made it too much like the last console title.

Filed under: Game Design, Games 1 Comment

Anecdotal Interface Fail

The original Mass Effect had massive interface issues. Pretty much every screen in that game had at least one glaring fatal flaw, something that these fantastic articles go into in-depth.

Mass Effect 2 fares better in this regard, though its complete lack of an inventory mitigates the need for UI significantly, which in turn makes it harder to screw up as royally as the first game.

Nonetheless, the game still managed at least one epic interface fail, and it's enough of a head scratcher that I felt obligated to share it here.

Mission Incomprehensible

One of Mass Effect 2's (mostly excellent) side missions involves stopping a couple of missiles from being launched, in order to save a colony.

Unfortunately, it turns out that you will only be able to stop one missile, and you must choose between saving the living area or the industrial area. If you save the living area, you will save thousands of lives, but they will need to be evacuated since the colony will no longer be able to sustain itself. If you save the industrial area, the colonists will die, but the colony will remain viable and can be resettled in no time.

Clearly, one of these is the "Renegade" choice and the other the "Paragon," and you can safely assume that the choice you make will have some sort of impact in Mass Effect 3 (though if the "impact" of the first game's choices on Mass Effect 2 is any indication, then all you'll get is a strongly worded e-mail).

Regardless, it's a fun mission, and having to make a big decision at the end is cool; what's not cool is the UI they cooked up to let you make that decision.

Here's how it works: you're presented with a typical list of two different choices Save the Colony or Save the Factories. It's a typical list, where you can use the D-pad to highlight one choice or the other. When you highlight a choice, the text on the right changes to explain the choice more closely, just in case you're not sure which one to highlight in order to get your desired result.

So that's pretty easy right? What could go wrong?

So, I highlighted the Save the Colony option, and hit A to confirm it.

Imagine my surprise when the mission summary told me that I had chosen to save the factories, sacrificing thousands of colonists.

Since that hadn't been my intention, I replayed the mission just so I could look at that screen again and try to figure out what I'd done wrong. I beat the mission, got to the choice, and everything was exactly as I'd thought, I'd even highlighted the correct choice in the list.

And then I glanced down at the context-sensitive buttons at the bottom of the screen, which you would expect to say something like:

A. Confirm
B. Cancel

Instead, the button prompt says this:

A. Save the Factories
B. Save the Colony

In other words, that list, the one where you can highlight either Save the Factories or Save the Colony? Yeah, it serves no purpose, and in fact, if you highlight a choice and then hit A to confirm it, like you would anywhere else in the game, you will choose to kill the colonists every time.

Wow. Just... wow.

Clearly they had no idea how they wanted to present this choice, and someone probably decided to change it at the last minute, instead bungling the whole thing. This is why it pays to have someone actually design the UI, Bioware.

I'm just saying.

Filed under: Game Design, Games 2 Comments

Learning and the Art of Time Travel

Consider Achron: the world's first meta-time strategy game. It's a pretty crazy idea.

Many games these days implement time-rewind mechanics. It started with Prince of Persia: The Sands of Time, and the most recent examples are probably indie favorite Braid and racing behemoth Forza 3. But Achron is different, Achron doesn't just let you rewind time, it gives you a proper timeline, like a movie editor or music sequencer, and lets you skip around in time freely.

If an attack goes poorly, you can go back in time and change how it played out, or cancel it completely. You can also go into the future, build units and teleport them back into the past, which means you can use your army... and then build it.

Oh, did I mention the game has multiplayer? And that your enemy can do all these things as well?

But it would take too long for me to try to cover all the cool stuff going on in this game; instead, I'll let the developer do it in one of their awesome demo videos:

I think this kind of mechanic is really compelling, and I wouldn't be surprised to see a lot of games start embracing time travel as a true game mechanic. It offers so many gameplay possibilities, it's easy to grasp but hard to master, and it's an experience that only a video game can give you.

Where else in life can you experience what it'd be like to change the past? Or travel through time?

There's a lot of interest in Achron's engine too, the army would like to use it to teach causality and long-term effects, which brings me to the second half of this post.

Learning Through Failure

I've been reading a lot about difficulty and challenge in games lately, and one subject that comes up a lot is the idea of failure vs. punishment.

Failure, whether in a video game or in some task in the real world, has an awful lot of value. We learn through failure, or more accurately, we learn by analyzing our failure, making changes, and trying again. A key point to make is that the sooner we can try again after failing, the more quickly we learn, which shouldn't really surprise anyone. Are you more likely to learn from a failed attempt if you immediately try again, while your past methodology is fresh in your mind, or if you wait a week before your next attempt?

This is where punishment comes in. Punishment is where a game essentially piles extra baggage onto your failure, usually by making you lose progress, and forcing you to redo something you had already accomplished in order to try again.

The problem with punishment is that it makes it hard or impossible to learn from your mistakes, and quickly breeds frustration, which will make some people lose interest or give up entirely. If you have to run through 5 minutes of level every time you miss a specific tricky jump, you're not really learning very much from your failure. It takes too long for you to try again, and by the time you do, you no longer have a good idea of what you did wrong in the first place, making it harder to compensate.

I'm not the first to make this argument of course, and rather than rehash what others have said, I'm going to focus this post on the above in the context of Achron. If you'd like a more in-depth view on the subject of challenge vs. punishment, I definitely recommend you check out this wonderful post, as well Shamus Young's original take on the subject, which has spurred a lot of the conversation on this topic on other blogs I've read.

Real-time Failure Correction

So what makes Achron so exciting, besides a wholly new and original gameplay mechanic, which might actually become a lasting innovation to the genre, unlike more "innovations" thrown around these days?

Games that let you rewind time without punishing your failures already do a better job of teaching you how to improve, and preventing frustration, than traditional games where failure is a chore. Achron takes this to another level however, because not only can you rewind a single action, or a single mistake, but you can continually go back and tweak your strategy, learning from your mistakes in real time, and seeing how your corrections impact the ultimate outcome.

Not only that, but Achron is multiplayer, or at the very least, it has an AI opponent capable of impacting the timeline the same way you can. This means that you can not only learn from your mistakes, but from your enemy's mistakes as well. You can watch how your opponent modifies his past actions to account for changing situations, and you can continually respond in kind, in a sort of see-saw on enlightenment.

The potential for learning in a game like Achron is tremendous, and it should make for great gameplay as well, because not only does the time travel mechanic provide a completely unique experience and allow the development of insane strategies, but learning how to do something interesting is also fundamentally fun for most people.

Just consider how exhilarating a new game can be, when you're still bumbling along, learning the mechanics for the first time.

Of course, maybe it's too early to declare Achron a harbinger of the future of games. A lot depends on the execution, and the game won't officially be out until next year. However, preordering gets you access to beta builds, and since this game intrigues me so much, that is exactly what I have done.

I haven't had a chance to try it yet, but once I do, rest assured that I will let you know how their ambitious work is looking.

Filed under: Game Design, Games No Comments

But You Must!

The title of this post is a quote from a very famous and very popular game. It's also somewhat of an inside joke between myself and a friend of mine, and the why of it will become clear in a moment.

There are plenty of linear games out there, where you are shepherded from point A to point B without any choice of where to go next. I'm not going to say that this is unacceptable, something that should never be done, because there's room for all sorts of games out there, and sometimes keeping a game linear serves the maker's vision well. If you have an exciting, interesting game, and you want me to see it in a specific way, I won't begrudge you that opportunity, and hopefully it will turn out to have been the correct choice.

However, there is always danger in removing or constraining a player's agency; a game is meant to be played after all, and not all people will go along with you willingly. Whether its superfluous or excruciatingly long cutscenes, linear levels, or open areas that are too small and with too little to interact with, many people will not be pleased with arbitrary limits on their freedom to play their way.

But, as I say, I can accept that sometime a game must send you along a particular path. What I can't understand, is why some games insist on pointing out that you have no choice, by giving you a choice without any meaning.

The Zelda games are pretty bad at this, or maybe it's Nintendo games in general. This brings us back to this post's titular quote, which comes from Ocarina of Time, a game considered by many to be the best Zelda game, or even the best game of all time.

In the interest of full disclosure I'll note that I don't agree with either of those sentiments.

In Ocarina of Time, there is a point where you, as Link, the Hero of Time, speak to Princess Zelda, and she gives you what is essentially a quest. I believe it is a quest to retrieve the Spiritual Stones and unlock the Temple of Time, but I could be wrong, it's been a while. In any case, she tells you the task she want you to do, and then asks if you will do it. You are given two clear choices, one to accept, and one to decline.

Most people who played the game, probably just hit Yes and moved on with their lives, but what happens if you hit No?

But you must!

So, will you do it?
- Yes
- No

If you keep saying no, she will keep telling you that you must, until you give in and accept your wretched fate. At that point, it just feels like the game is toying with you, or possibly trying to break your will: "You will accept my quest, dammit, struggle all you want."

Since this is obviously a key point in the game, and it wouldn't make sense for Link to turn around and become a pig farmer or something, why in the world do they pretend to offer you a choice? It would be easier to just walk you through that part of the game, make it a plot point like any of the others. I may not feel like I have a choice if you do that, but I don't have a choice now either, and at least that way you can move on with the game without this weird little intrusion into your epic adventure:

And so it was, that the Princess told the Hero of his task, and lo she did plead with him to take the world's fate upon his shoulders. But the Hero, fickle and cowardly as he was, refused the Princess her request.

And so it was that the Princess plead again: "But you must!" She told him. And again did the Hero deny her.

86 times she asked, and 85 times he refused, until at last, tired, hungry, and annoyed, he relented, and so the adventure began...

So yes, I think it silly to give the player a choice only to then refuse to accept that choice. The moral of the story is that if you're going to take the player's agency away, do it quickly and seamlessly, and don't taunt or confuse him with it.

On the other hand, if the designers of Ocarina of Time had done that, then my friend and I would be denied a hilarious line to overuse in everyday situations.

So I guess there's that.

Filed under: Game Design, Games No Comments