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

Getting Diablo 2 Working Under Dual-Core Vista x64

Getting a game as old as Diablo 2 to behave on a modern PC can be quite the chore; something I rediscovered today when my buddy and I got a hankering to play it again. Fortunately, I managed to get it working, so I figured I'd document my steps in case someone else runs into the problem and happens to find this, or, more likely, I forget how I got it working and need a place to look the next time the desire to play this game manifests itself.

The problem I encountered was one of massive framerate drops on a pretty regular basis. Not only was the framerate pretty poor to begin with, but it seemed to periodically encounter particularly long frames, drop to near nothing, and then quickly catch back up again, causing everything to zoom by at a stupid-high speed.

Ultimately I found that the only thing that fixed the problem was setting the game to run using DirectDraw rather than Direct3D in the Video Test application that installs itself with Diablo 2.

Diablo 2 Shortcut Compatibility Settings

Unfortunately, changing to DirectDraw caused the game to fail to load; it would just sit there after running the executable, without the game actually even opening a window, though I could see its process in Task Manager.

Ultimately, I was able to get the game to launch and run just fine using DirectDraw by setting the compatibility settings shown to the right on its shortcut.

I'm not sure if they're all necessary, and it may not even be necessary to run the game as Administrator, but since these settings worked out for me without any problems, they're what I'm sticking with for the time being.

I'm not sure why Diablo 2 chokes so stupendously when you try to run it in Direct3D mode. Perhaps the game tries to use some features of old Direct3D drivers so archaic and deprecated that modern hardware chokes and dies on it.

Alternately, it's possible that modern GPU optimizations for multi-core computers like mine cause synchronization issues on these old games that cause the kind of craziness I was seeing. I know my nVidia driver control panel has an option for "Threaded Optimization" that might not be playing nice with Diablo 2's expectations.

In any case, DirectDraw worked for me, and if you're having trouble getting Diablo 2 to run on a modern PC, I hope this helped you out in some way.

Filed under: Games No Comments

Objects, Components, and Entities, Oh My!

A new post at last, and it’s that rarest of rare beasts, a programming post!

I’ve been reading and thinking about game system architecture lately. What I mean, specifically, is how objects and actors that take part in a game are represented in code, and what the relationships (in code) between them are like.

The traditional approach follows the Object Oriented programming model of a class hierarchy, where everything is represented by an object containing both data and functions, so that an Orc has both a Size value and an EatPeasant() function bundled up inside it. Furthermore, rather than writing each object from scratch, inheritance is used so that a tree of objects emerges, where specific actors like Orcs inherit much of their data and functionality from object higher up in the tree.

For example, an Orc may inherit its Size from a Monster class, as well as Position, which Monster in turn inherits from MovableObject, which inherits it from GameObject.

This is the naïve OOP approach to managing the actors in a game, and it is almost certainly the wrong approach, at least for a game of any appreciable size or complexity. Don’t get me wrong, it’s an intuitive way to set things up, especially for programmers with experience in other fields, and it can work very well for a small game where the hierarchy can be kept under control and doesn’t grow to massive, unmanageable proportions.

But there are better ways to do things, ways that are much cleaner once you have hundreds of different types of objects in your game, ways that are ultimately just as intuitive once you get used to them.

This is what I’ve been reading about, and pondering, in recent days: component-based architectures and entity systems for representing and managing the actors in your game. While I explain the concepts involved below, if you're really interested in the subject I recommend Mick West's article on the subject, which is very well written and goes into considerable detail.

At its most basic, a component-based architecture eschews a complex object hierarchy in favor of every actor in the game being a collection of components that define what that actor is, and what that actor does. Each actor then, apart from perhaps having some extremely common data such as an identifier, holds a list of components like PhysicsComponent, InputControllable, IsMonster, or whatever else is necessary to define all the operations that the actor can undergo.

These components then hold the relevant data and functions that define the actor, while centralized game systems either iterate over the actors, or even hold their own references to the individual actors’ components, and are able to do whatever updating or rendering the component requires every frame.

The benefits to this kind of setup are many. For one thing, instead of having perhaps hundreds of separate inherited objects, each necessitating its own class with all the upkeep that this entails, actors are simply the sum of their components, and any time a new component is written by a programmer, it can not only very easily be used to create new actors, but can also be trivially added to actors that already exist, giving them new functionality.

This means that with the proper tools, designers can easily redefine behavior on any actor simply by changing what components make up that actor, or tweaking the data that component manages; the only limitation is what components are available. Writing an individual component is also simpler and easier to test than modifying a fully realized, complex, working object that is being passed around throughout the game.

As an example, our Orc from before would be defined by the components that give it a size, and that allow it to eat peasants. If we then decide that Orcs should fly, we can give it a flying component, one which we might already be using for birds, or that we can subsequently use for whatever other actors we think should fly.

It also becomes trivially easy to make other Orc-like monsters, by simply swapping out a couple of components, or simply initializing the new monsters components with different data. For instance, a Goblin monster may be functionally identical to the Orc, but its SpriteComponent loads Goblin.jpg instead of Orc.jpg.

A component system within the confines of an object-oriented language like C++ or C# is all well and good, but what I found particularly interesting while reading on this subject was a method used by Adam Martin, to do away with the pesky and ill-fitting OOP paradigm entirely while designing this sort of component-based architecture.

Essentially, Adam proposes that the actors in a game (which he call entities, a common term that I have not used up until now specifically because he calls his method an Entity System) and their components should be approached using a database model.

Instead of even having an actor class which holds a list of component objects, he advocates divorcing the data and functionality of entities entirely from the traditional OOP model. An entity then becomes nothing more than a unique identifier, a number or a string, and components become packets of data needed by that entity.

Separate systems operate on the data in a component, for instance, a PhysicsSystem might take the data in a PhysicsComponent and use it modify the data in the entity’s PositionComponent, but components themselves merely hold data, not functionality.

The cool thing about this, though it took me a while to make sense of it, is that instead of passing around complex class-based objects in your code, you can simply hold onto an ID for the entity you want, and then essentially perform database-style queries to obtain any data you currently need from the components bound to that ID.

Not only do you get all the benefits of the popular and powerful component architecture, but you also keep your data separate from functionality which comes with a number of benefits; for example, it allows you to perform parallel operations easily on different entities (which are just sets of data) without breaking anything.

I feel like my thoughts about this database-like view of a component system are not yet fully formed, but I definitely feel like there is a powerful elegance to doing things this way. I will need to let the thoughts simmer some more before I have more to say about it, I think.

I recommend checking out Adam’s series of articles on the subject, linked above. It really is quite eye-opening.


Red Dead Dastardliness

Red Dead Redemption wasn't really on my radar, and then, for some reason, people started telling me it should be. My only thoughts on the game were that I'd heard the original, Red Dead Revolver, was a pretty uninspired shooter.

Then today I saw this.

Note: I had originally tried embedding the video, but it would refuse to load when you hit play, and there is no YouTube version of the video because it was taken down by the publisher on copyright claim. That's a pretty rotten decision, this is the kind of awesomeness that helps sell a game.

Okay, so now I'm definitely going to have to get this game. Besides, a new Western-themed open-world game sounds like a good time, the only other such game I've played was Gun, and while that was fun, it was also a long time ago.

Filed under: Games No Comments

The Silence Is Deafening

I know my update schedule has become erratic, and I haven't been posting on a regular basis, as I would like.

Some upheaval and turmoil at my job has led much of my free time to be consumed by job search related activity, updating my resume and the like, and I haven't been able to devote much time to the blog in recent weeks.

Rest assured that once things settle down a little, I plan to remedy this situation, and I do have a number of half-finished posts ready to go, as soon as I have the time to polish them up to standards.

Filed under: Notices No Comments

Embedded Gaming

That's a game up there. I mean an actual, playable version of the Secret of Monkey Island, embedded directly into the blog.

You can click on the Play Demo button and start playing this classic point and click adventure right now, no need to download anything, no need to install anything, and no need to interrupt your browsing.

Apparently this company, InstantAction, is going to allow you to embed games in HTML just as easily you can currently embed YouTube videos.

Of course, I don't know how practical this sort of thing will really be. I imagine you won't see hardware-intensive games being embedded any time soon, but in the meantime, it's a neat little look into one possible future of online distribution.

So give it a whirl, see what you think. It's Monkey Island after all, you really can't go wrong with Monkey Island.

Filed under: Games No Comments


What is X-Com? Until last week, X-Com was a fantastic little PC turn-based tactical game. A game which let you build up a fancy base, while researching cool technology, and recruiting soldiers. A game where, with your base fully operational, you could send out squads of guys to shoot down UFOs, investigate crash sites, and fight the alien menace.

X-COM: UFO Defense

X-Com is dear to many PC gamers and turn-based game fans, and seeing as I happen to be both of those, it’s a game dear to me, as well. The great mix of genres, the chance to do so many cool things in a single game, and the deep and satisfying turn-based combat are what define X-Com, what make it such a special game.

So hearing, last week, that the X-Com license is being used to make a First Person Shooter did not exactly elicit an enthusiastic response from most X-Com fans, myself included.

Don’t get me wrong, I’m sure it’ll be a decent game. It’s being made by the same people who made Bioshock 2, after all. But do we really need another First Person Shooter on the market? Do we really need to convert a property near and dear to many a gamer’s heart into a genre as far removed from its roots as is physically possible?

The most disheartening thing about all this is probably how eager the online games press is to play this off as a good thing. I realize it’s not in their interest to be skeptical about new game announcements, that it’s better for them to be optimistic about everything the publishers toss their way, but it’s doesn’t make it any less depressing to see them fail to question these sorts of decisions on behalf of the longtime fans, who do not have as public a voice.

The Kotaku article on the subject is a perfect example. They quote the new game’s press release, filled with appropriate buzzwords like “high-stake odds” and “strategic gambits” and then proceed to conclude that “the strategic stuff is still in” and therefore “it’s the first-person stuff that has people angry.”

It’s silliness, old-school X-Com fans aren’t going to be appeased by promises of “strategic depth” from PR material for a game that switched genre from a strategy game to a shooter, and the author shows a profound intellectual dishonesty in proclaiming that the first person perspective is the biggest problem fans will have with the game, rather than, you know, the fact that it’s now a shooter.

Unfortunately, this sort of coverage is pretty much par for the course, though there is some more balanced coverage out there. A PC-focused site like Rock, Paper, Shotgun, for instance, took this opportunity to write a couple of insightful and personal pieces about what X-Com meant to them, and what it means to the many fans of the old games.

Further silver lining comes in the form of extra exposure for indie projects that are apparently trying to fill the X-Com shaped hole in our hearts. Since little hope remains of another turn-based tactical game bearing the X-Com name, these indie efforts have the potential to define the future of the hybrid-semi-genre.

The first such promising project is Xenonauts, currently in development by a small indie studio. It looks like it will be released commercially, and their site shows some very polished concept art as well as design ideas about different aspects of the game. Since it's still in fairly early stages, I recommend keeping an eye on their site if you are interested.

The Geoscape in Xenonauts. Looking good!

The other major project I’ve seen come out of the woodwork with the FPS announcement is UFO: Alien Invasion, an open source X-Com clone or remake based on the Quake 2 engine. Though I just found out about this project, it’s been in the works for quite a while now, is still updating on a regular basis, and looks to be quite mature, not to mention free!

A UFO crashsite in the open source UFO: Alien Invasion

I haven’t tried it out myself yet, but I plan to give UFO: AI a whirl soon. It even supports multiplayer, including cooperative control of one team, or two teams facing off! Maybe I can con a friend into trying it with me, after all, a multiplayer, cooperative X-Com sounds about as close to heaven as I dare imagine.

Filed under: Games No Comments

Designing S3: Stats

A while back, I wrote a post explaining that Setting Sun Saga (or S3) is a game I plan to make based on the model of Final Fantasy Tactics. This will be the first in a series of posts discussing various mechanics of S3, and attempting to outline an initial design for all these relevant mechanics.

Present thinking has led me to conclude that I want the unit stats in S3 to closely match those of FFT, and consequently, I will begin by describing the stats in that game, and then explain how I am planning to change aspects of these stats to better suit my game.

For reference, I recommend the excellent FFT Battle Mechanics Guide written by one Aerostar. This fantastic document provides a great deal of invaluable insight into the mechanics behind FFT, and some of the rationale for the way those mechanics were designed.

The Stats of Final Fantasy Tactics

Final Fantasy Tactics uses a Direct Stats system for its character development, and if you give the linked article a read, you will see that I agree with this approach for a tactical RPG where the player is tasked with managing a large roster of characters. So what stats does FFT use?

  • HP. This one is fairly self-explanatory, most RPGs feature Hit Points as an abstraction of unit health and well being; how far a unit is from death, to be more precise.
  • MP. Magic Points, used for casting spells and using abilities, another RPG staple, often also called Mana.
  • CT. Charge Time, in the Tactics series, is a bar that fills up to 100, granting a unit a turn when its CT is 100 or more. This determines the initiative order of units, as well as when spells are cast.
  • Move. How far a unit can move on its turn, in squares.
  • Jump. How high a unit can jump while moving, a unit will have to find alternate routes to bypass squares it cannot jump to.
  • Speed. Each invisible Clock Tick, the unit's CT increases by its Speed value, meaning that units with high Speed get turns more often.
  • Weapon Power. A rating indicating the relative strength of a weapon. Used in damage calculations for physical attacks. FFT allows you to dual wield weapons under certain circumstances, with each weapon having a separate Weapon Power.
  • Physical/Magical Attack. Two stats with very similar usage. They are used in damage calculations for physical and magical attacks, respectively. Unlike Weapon Power, these are innate to the character, and grow as the character levels up.
  • Class, Shield, Accessory, and Weapon Evasion. These four evasion percentage values are used to determine the unit's chance to evade attacks (by lowering an enemy's chance to hit). How these stats are used depends on which direction the unit is attacked from, and whether the attack is physical or magical. Weapon Evasion only applies if the unit has a weapon equipped, as well as a special ability that allows blocking.
  • Bravery. A special stat modified in combat and via special events, it determines the chance for the unit to use a Reaction Ability (such as Counter) and is also used in damage calculations for certain weapons or classes.
  • Faith. Another special stat like Bravery, it determines how much a unit is affected by magic spells (both friendly and hostile).
  • Zodiac Sign. Every unit is assigned a sign of the Zodiac that never changes over the course of the game. The twelve Zodiac signs have compatibilities with each other, and compatible units inflict more damage on one another, while incompatible ones deal less.

So, keeping in mind that I'd like to keep the stats in S3 pretty close to FFT, which of these are worth keeping, and which ones need to be replaced or revised?

Stats Worth Keeping

Hit Points are a no-brainer, really. You always need some way to represent how hard a unit is to kill, and while there are some interesting alternate ways to approach this problem, I don't think they are compelling enough to warrant complicating such a crucial aspect of every character.

Furthermore, a simple HP stat lends itself nicely to the way Tactics handles armor, that is, by simply boosting the unit's max HP instead of modifying some Damage Reduction value. I like the abstraction this provides, since Damage Reduction is hard to balance in these sorts of games (in Disgaea 3, for instance, the equivalent stat's damage reduction capability grows at a much slower rate than a unit's damage potential as it levels up, making the stat essentially useless). It's also ultimately not a very interesting way to grow your character in a game without some sort of aggro and tanking mechanic.

Move and Jump are also obviously necessary. Units will need a way to represent how far they can move, and how they can traverse the landscape, and these stats allow those abilities to be easily modified as well.

CT and Speed are the quintessential stats that make the Tactics series interesting, and different from other strategy RPGs. They add interesting tactical considerations, since you have to worry about the order your units get to act in, as well as casting times. This leads you to plan your actions more carefully, so that your big attacks can hit before an enemy can move out of the way, or otherwise screw up your plans.

The presense of the Speed stat also adds interesting character development possibilities, since you can build a character with high Speed, and use that as the unit's primary strength, since it will get more turns than units with a lower Speed.

Weapon Power is a simple and elegant way to manage the damage contribution that a character gets from a weapon. Having a stat like this makes it easy to compare two weapons to see which is better, at least on the surface, and interesting formulas can be used to base damage calculations off Weapon Power combined with other stats, ensuring that all classes don't use the stat in exactly the same way, while maintaining its use as a useful comparative between different weapons.

The different kinds of Evasion used in Tactics are another interesting departure from most other games. Suffice it to say, I think Evasion combined with the way HP is handled, facing modifiers, and an otherwise 100% success rate for attacks gives the game a unique feel, and I intend to stick closely to this system in S3. I actually have a whole 'nother post forthcoming about the way Evasion and Facing will work, so I won't go into detail at this point.

New And Revised Stats

While MP or Mana are just as tried-and-true as HP, they are an uninteresting way to represent what should be one of the most important parts of a character: the fundamental source of its power and badassery. Games like WoW and Dragon Age show that you can differentiate how a class works and, more importantly, how it feels to a player very effectively simply by changing the resource that the class spends to use its abilities.

Consequently, S3 will not use a simple MP system, but rather the dual resources of Focus and Stamina, which are spent and replenished differently and which fit nicely into the lore of the game. Unlike a game like WoW, however, and because a big focus of S3 will be switching classes like in FFT, all units will have both of these resources, but they will use them in slightly different ways. A post outlining the details of the Focus and Stamina system is in the works, and I will go into the details at that time.

FFT's Physical Attack and Magical Attack stats are the primary method of influencing the damage output of a character using a weapon or casting a spell. They are a clean and straightforward way to measure and build a character's ability in one of these two fields of expertise, and the classes are roughly divided among these two paths as well, so that building a character with high PA predisposes that character to be good in those classes.

I really like the directness of these stats, and I intend to go the same route in S3. I am, however, considering adding a third such stat to help diversify character builds, and more cleanly distinguish a third "tree" of classes that primarily depend on this new stat. If I decide to go this route, PA would likely become something like Brawn, MA would become just Magic (or maybe Brains?), and a third Attack stat called Agility would be added for nimble and ranged classes.

As I said, this is still just something I am considering, and while I think there would be some interesting potential there, particularly in hybrid classes that depend primarily on two of these stats, or even all three, it could turn out while designing classes or testing things out that the original mix of Physical and Magical Attack is enough.

The remaining pieces of the FFT stats system are the two alignment stats (Bravery and Faith) and the Zodiac system. Of these, Zodiac is closely tied to FFT's story, and frankly I consider both it and Faith to be deeply flawed and not very interesting. Bravery, on the other hand, has some promise, but in FFT it has minimal effect on the gameplay for the most part, and only certain physical classes use it for more than chance of counterattack.

For S3, I am planning a much more integral stat called Morale, which will resemble Bravery in some regards, but I intend for it to be used as a more direct representation of the concept of unit and squad state of mind. Just like the resource system, I have an in-depth discussion of Morale in the works, so I will hold off going into detail at this time, though I will say that I want Morale to feel like an intrinsic and dynamic measure of a unit's current status, like HP, rather than a static stat that only changes from equipment or levelling.

What's Next

Hopefully, this post gives you an idea of how a unit's internal workings will feel. I know I haven't gone into a lot of depth about the new systems I will be introducing, but this post is already plenty long enough, and they deserve their own space to be properly fleshed out.

My next Designing S3 post will likely go into detail about either Morale or Evasion, so stay tuned for that.

Also, as always, I would greatly appreciate any comments you may have on the set of stats outlined in this post. It is only through brainstorming, feedback, and iteration that this game has the chance to be any good.

Filed under: Designing S3 1 Comment

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

Designing S3: An Introduction

If you take a look at my About Me page, you'll see that one reason why this blog exists is to eventually serve as a design document for a game I've wanted to make for a long time now. I've been putting off this intro post, even as I develop drafts of actual design articles, but I think the time is right to start revealing information about what this game is and what my goals are in designing it.

The game I intend to someday make happen is called Setting Sun Saga, and it is a turn-based tactical RPG based closely on the model of Final Fantasy Tactics.

Why a FFT clone then, if we should call it that? Because FFT is one of my favorite games of all time; because I have many ideas about how to make my own game of this type, as well as a setting and the beginnings of a story I want to present with it; and because there are not many games of this type made anymore. What few tactical RPGs are released these days inevitably come out of Japan, don't take themselves seriously, and don't use FFT's unique approach to character classes or unit initiative, both of which I consider integral to the game's appeal.

In any case, though FFT will be the basic model for this game, which I will refer to as S3 from this point on to save on some otherwise tiresome typing anytime I wish to refer to it, below are some points I plan to emphasize in my design that will distance it from FFT and make it its own game.

  • A completely custom setting, with a set of classes, abilities, and mechanics that hopefully feel new and different.
  • More non-linear and player-driven narrative, taking cues from some of my other favorite games, like Planescape: Torment and the Fallout series, I hope to give this game a little bit of the freedom and meaningful choice that those classic western PC games offered.
  • New and interesting battle mechanics, with a major goal being adding interesting new decisions while maintaining FFT's surface simplicity and making sure that the unit stats and combat results remain clearly understandable.
  • More emphasis on custom units, one of my biggest problems with the original FFT is that you get a large roster of special story units as the game goes on, and these characters are clearly much better than any custom units you may have been cultivating. This is the opposite of what I want for S3, where I plan to keep the roster of special characters very small, and add depth and unique characteristics you can give your custom characters, to foster your connection with them and increase their utility.
  • Greater control of unit development, I want to stay away from the trap a lot of Japanese RPGs fall into, where characters' stats develop arbitrarily because they happen to level up while in a specific class, for example, leading to arcane hacks like trying to de-level them or otherwise working around the game if you want your characters to develop in a specific way.
  • Mechanics not limited by hardware, the Playstation, the original platform for FFT, didn't have an FPU. Consequently, all the formulae controlling the game are designed to work using only integer math, and while I definitely have no desire to fix things that are not broken, I will be reviewing systems to see if they can be made more robust on modern hardware.

So there you have it, hopefully now you have a clearer picture of the kind of game that S3 will be.

In the coming weeks, I will be posting articles about specific aspects of the game design, and I hope you will join me in discussing these deisgn decisions and provide your feedback on how to make Setting Sun Saga a success.

Filed under: Designing S3 2 Comments