Sorry for the lack of updates, lately. I've had my head buried in code. Right now I'm working my way through the base classes in the game and doing a lot of set-up for error handling and logging code. Once I've got the base classes finished, I need to write a data loading interface. Then it'll be time to start writing the actual tools to create the data.
Anyway, there'll be another design document update soon, I promise.
Saturday, July 11, 2009
Wednesday, July 1, 2009
More Art
Here's another couple of pieces of concept art. The first is another Mullen portrait by Glen Zimmerman, while the second is a warrior woman by my good friend Matthew Stinson.
Saturday, June 27, 2009
Concept Art
I was finally able to get some of our concept art scanned in. Here's a couple small pieces from artist Glen Zimmerman (the link goes to his Deviant Art page). The first is a portrait of a Mullen, followed by a tree-creature that hasn't been named yet.
Tuesday, June 23, 2009
Design Analysis: Area and Local Maps
With Area and Local Maps, we get into the real meat of the map and exploration systems. While the World Map is essentially a reference tool, the other two types of maps have extensive gameplay mechanics associated with them.
An Area Map looks, at first, very similar to the Areas depicted on the World Map. It'll display geographical features in more detail, but an Area should be easily recognizable whether you're looking at the World Map or the Area Map. There are two important graphical differences, however. First, Adventure Sites (dungeons and the like) and Towns show up on the Area Map as icons once you've located them. Second, exploration status in Area Maps is shown per-pixel, rather than across the Area as a whole. like the World Map shows. Parts of an Area Map that you havn't explored thoroughly are displayed in washed out colors, and parts you havn't explored at all are shown in greyscale. This gives the player immediate and obvious feedback on where he might find new Adventure Sites, which is important because Adventure Sites are the real meat and potatos of the game.
Unlike Attributes and the World Map, this is the original design for Area Maps. The design goal is to provide the player with a sense of the scale of the world, while putting their adventuring entirely in their own hands. There's nothing stopping a player from taking his initial party and heading right out for places unknown to make their fortune -- in fact, it's encouraged. The two biggest influences in this section (meaning Area and Local Maps and their interactions) are Ogre Battle and Wizardry. Ogre Battle is the inspiration behind both the multiple-party system and the Area Map exploration system; in Ogre Battle, the player has access to (potentially) dozens of parties of characters and has to send them out to conquer each region. In the process of moving around the map, parties can discover hidden cities, temples, items, and teleportation gates. The process of exploration is a very big part of Ogre Battle, and it was the first game I ever played where that type of gameplay was presented in a manner that was both intuitive and rewarding. Wizardry, on the other hand, is the inspiration behind the dungeon crawling Local Map segments. Actually, in point of fact, when I originally wrote up what would eventually become the Fate of the Mullen project 5 years ago, it was more or less a straight-up Wizardry clone, with a single dungeon.
That's a nice lead-in to Local Maps. Local Maps, while no longer in the Wizardry first-person corridor style, still are heavily influenced by that game. Exploration of Adventure Sites is intended to be the part of the game the player spends the most time with. Sites are intended to appeal to players who like pitting their hand-picked adventuring teams against unknown, uncharted lairs, ruins, dungeons, and caves. They're the best source of experience (and thus character advancement) as well as being involved in the vast majority of quests and being the source (directly, from treasure chests laying around, or indirectly from the spoils of combat) of most of the treasure in the game. In this way, Adventure Sites (and thus Local Maps, because they're really the same thing) should appeal to explorers, perfectionists, completionists, treasure hunters, and questers. Socialites have to look to the party systems to get their fix.
I mentioned before that the original design of Fate (back when it was called "Sorcery" -- yes, it really was a Wizardry knock-off) was as a first-person dungeon crawl. Why, then, did I decide to change to a tile-based system? Two reasons: firstly because it's easier to design a 2D tile engine (and acquire 2D tile art) than a 3D one, which is what Wizardry really used. Secondly, because I intend to have enemy encounters actually move around on the map and allow players, or rather their characters, to detect them -- visually and audibly -- before they actually make contact with the party. That kind of thing is much simpler from a UI point of view when an entire group of 6 people isn't limited to a single person's viewpoint. Another, secondary, consideration is that Wizardry's approach works great for room-and-corridor games, but I wanted some more wide-open levels as well, and in my opinion an overhead perspective is much more functional for that kind of thing.
That about wraps it up for Part 2 of Maps and Explorations. Part 3, the final part, is next, in which I'll cover Exploration in an official capacity and give information on Towns.
An Area Map looks, at first, very similar to the Areas depicted on the World Map. It'll display geographical features in more detail, but an Area should be easily recognizable whether you're looking at the World Map or the Area Map. There are two important graphical differences, however. First, Adventure Sites (dungeons and the like) and Towns show up on the Area Map as icons once you've located them. Second, exploration status in Area Maps is shown per-pixel, rather than across the Area as a whole. like the World Map shows. Parts of an Area Map that you havn't explored thoroughly are displayed in washed out colors, and parts you havn't explored at all are shown in greyscale. This gives the player immediate and obvious feedback on where he might find new Adventure Sites, which is important because Adventure Sites are the real meat and potatos of the game.
Unlike Attributes and the World Map, this is the original design for Area Maps. The design goal is to provide the player with a sense of the scale of the world, while putting their adventuring entirely in their own hands. There's nothing stopping a player from taking his initial party and heading right out for places unknown to make their fortune -- in fact, it's encouraged. The two biggest influences in this section (meaning Area and Local Maps and their interactions) are Ogre Battle and Wizardry. Ogre Battle is the inspiration behind both the multiple-party system and the Area Map exploration system; in Ogre Battle, the player has access to (potentially) dozens of parties of characters and has to send them out to conquer each region. In the process of moving around the map, parties can discover hidden cities, temples, items, and teleportation gates. The process of exploration is a very big part of Ogre Battle, and it was the first game I ever played where that type of gameplay was presented in a manner that was both intuitive and rewarding. Wizardry, on the other hand, is the inspiration behind the dungeon crawling Local Map segments. Actually, in point of fact, when I originally wrote up what would eventually become the Fate of the Mullen project 5 years ago, it was more or less a straight-up Wizardry clone, with a single dungeon.
That's a nice lead-in to Local Maps. Local Maps, while no longer in the Wizardry first-person corridor style, still are heavily influenced by that game. Exploration of Adventure Sites is intended to be the part of the game the player spends the most time with. Sites are intended to appeal to players who like pitting their hand-picked adventuring teams against unknown, uncharted lairs, ruins, dungeons, and caves. They're the best source of experience (and thus character advancement) as well as being involved in the vast majority of quests and being the source (directly, from treasure chests laying around, or indirectly from the spoils of combat) of most of the treasure in the game. In this way, Adventure Sites (and thus Local Maps, because they're really the same thing) should appeal to explorers, perfectionists, completionists, treasure hunters, and questers. Socialites have to look to the party systems to get their fix.
I mentioned before that the original design of Fate (back when it was called "Sorcery" -- yes, it really was a Wizardry knock-off) was as a first-person dungeon crawl. Why, then, did I decide to change to a tile-based system? Two reasons: firstly because it's easier to design a 2D tile engine (and acquire 2D tile art) than a 3D one, which is what Wizardry really used. Secondly, because I intend to have enemy encounters actually move around on the map and allow players, or rather their characters, to detect them -- visually and audibly -- before they actually make contact with the party. That kind of thing is much simpler from a UI point of view when an entire group of 6 people isn't limited to a single person's viewpoint. Another, secondary, consideration is that Wizardry's approach works great for room-and-corridor games, but I wanted some more wide-open levels as well, and in my opinion an overhead perspective is much more functional for that kind of thing.
That about wraps it up for Part 2 of Maps and Explorations. Part 3, the final part, is next, in which I'll cover Exploration in an official capacity and give information on Towns.
Design Excerpt: Maps and Exploration, Part 2
Here's part 2 of the Maps and Exploration excerpt, Area Maps. As an apology for the lateness of this excerpt, I'm tossing in the Local Maps section as well.
Area Map
Area Maps display a subsection of the World Map, roughly US state/European country sized, in greater detail than the World Map does. Smaller geographical features, such as ponds, streams, groves, and so on can be seen, and known towns and adventure sites are marked. Similar to the World Map, portions of each Area Map that have not been visited are displayed in greyscale, with possibly missing details. The main difference is that Area Maps are not separated into discrete sections like the World Map; instead, each party has an “exploration radius” around it. Any parts of the Area Map that have not been covered by a party's exploration radius are considered unexplored.
Movement on the Area Map is dependent on the type of party. The primary party (the one the player's character is in) is under the player's control and moves wherever the player selects from the map with a right-click. Secondary parties move based on their orders from headquarters. Speed of movement is determined by several factors: whether the party is mounted (and what they're mounted on), how many characters are in the group, how thoroughly they're exploring their surroundings, and whether they're living off the land. Similarly, exploration radius is determined by the party's overall speed, the number of characters in the group, how thoroughly they're exploring their surroundings, and the highest Scouting and Survival skills in the party.
Local Map
Local Maps display a single site in an Area Map. They provide the greatest detail, displaying buildings and terrain down to a resolution of one to two square meters. Unlike in the other two map types, Local Maps display the characters in the party graphically and may show enemies as well. Also unlike the World and Area Maps, Local Maps rely extensively on light and line of sight. Only the section of the Local Map that is both within line of sight and lit by some sort of light is colored; areas that have been in line of sight and lit in the past are displayed in greyscale, and areas that have never been seen are solid black. The third main difference is that Local Maps are displayed graphically using a tile map, rather than a single large background image or a background image with icons, as the World Map and Area Maps are displayed.
Movement on the Local Map is controlled either with a simple point-and-click interface or with keyboard commands. Speed is constant on the Local Map (characters automatically dismount, and the party moves at the speed of the slowest party member so as not to spread out too thinly in a dangerous area).
Friday, June 19, 2009
Design Analysis: World Map
The World Map is a pretty straightforward (and superficial) piece of design. To be perfectly honest, there's nothing the World Map allows a player to do that can't be duplicated using other, already-existing means, except to provide a graphical representation of the entire playing area. In support of that single function, it has a bunch of minor graphical features (the flags showing where your parties are, "fading" Areas to show which have been visited, etc. The player isn't likely to spend any appreciable amount of time looking at the World Map, compared to the time in Area and especially Local maps.
Why did I decide to do things this way? Well, again, this wasn't the original design. Originally, I was going to let the player move around on the World Map exactly like they do on the Area Map (which will be described in some minor detail in the next excerpt). Then I realized that there was really no point to that -- you could already do the same thing in the Area Map while having a much better idea of the terrain you were crossing -- and it made things more complex from a coding point of view. To be clear, no functionality was removed with the design change; you can still choose a path from one Area to another Area (and keep setting waypoints in from Area to Area, if you so desire) from within the Area Map. Reducing the World Map to a purely descriptive element simplified and streamlined the design of the map system a great deal without sacrificing functionality; I call that a win-win situation.
Tomorrow I'll continue the excerpts and analysis with Area Maps.
Why did I decide to do things this way? Well, again, this wasn't the original design. Originally, I was going to let the player move around on the World Map exactly like they do on the Area Map (which will be described in some minor detail in the next excerpt). Then I realized that there was really no point to that -- you could already do the same thing in the Area Map while having a much better idea of the terrain you were crossing -- and it made things more complex from a coding point of view. To be clear, no functionality was removed with the design change; you can still choose a path from one Area to another Area (and keep setting waypoints in from Area to Area, if you so desire) from within the Area Map. Reducing the World Map to a purely descriptive element simplified and streamlined the design of the map system a great deal without sacrificing functionality; I call that a win-win situation.
Tomorrow I'll continue the excerpts and analysis with Area Maps.
Design Excerpt: Maps and Exploration, Part 1
This particular section of the design document is several pages of text, so I'm going to split it up into multiple posts over several days. Here's part 1, describing the World Map.
Maps, Movement, and Exploration
There are three types of maps: the World Map, Area Maps, and Local Maps. Each map covers a different level of detail and has its own movement parameters.
World Map
The World Map displays the entire (known) world, divided into Areas. Only broad geographical details (large lakes or rivers, forests, mountains, oceans, plains, very large towns, etc) are visible. The Area that the primary party is currently at is displayed with bright, vibrant colors, with a waving flag denoting the actual position of the primary party. Areas that secondary parties are currently at are displayed with less vibrant colors (except if the primary party is already there), with a smaller waving flag denoting their estimated position. Areas that have been visited, but have no active parties present, are displayed with washed out colors. Areas that have not been visited at all are displayed in greyscale and may have missing details.
Movement on the World Map is very abstract. In actuality, there isn't any real movement on the World Map itself. The World Map exists to show the relative layout of the land and to provide feedback on how much of the world has been explored. In order to move from Area to Area on the World Map, a party must move across the boundary of an Area on the Area Map. They are then transported to the World Map and may select either of the Areas sharing the boundary that was crossed to move to – either the Area the party came from, in the case of an accidental crossing, or the Area across the boundary.
Thursday, June 18, 2009
Design Analysis: Attributes
Design Analysis will be the counterpart to the Design Excerpt series. In Design Analysis, I'll explain the reasons behind each design element from the excerpt.
Today's excerpt and analysis is the Attribute system.
In Fate, Attributes and Skills are inexorably linked. Actually, Attributes are essentially "super-skills" that provide bonuses to every linked Skill. They actually don't do anything on their own. The strongest character in the world would gain no benefit from his Strength if he didn't have any Strength-linked Skills at rating 1 or higher. However, as soon as he invested experience in raising one of those Skills to rating 1, he would instantly have a significant boost to that Skill -- all the way up to +50 effective rating for a major link. As you'll see when I get to the Skills excerpt and analysis, +50 rating is absolutely huge.
So, why design the game this way? Well, one of the design goals was to have an "open" system, where you could mix-and-match abilities and character designs to make whatever kind of character you wanted to play. That lead directly to the Skill system design (as well as the level-less experience system). At first, Attributes were going to be a more standard "Strength raises damage with melee weapons, Agility makes you harder to hit, etc" design. But then I looked at it and realized that sort of system can limit options pretty severely. For example, if only Strength increased melee damage, then only a strong character can be an effective melee combatant. That prevents even such basic character archetypes as the fencer or the dirty tricks-using rogue.
Since I wanted to keep character design open, I therefore couldn't restrict such basic concepts as damage, avoidance, and the like solely to Attributes. The next logical thought, then, was to do a mixture -- Attributes had direct effects like before, as well as distributed effects as described in the excerpt. However, after running a few simulations with my preliminary combat Skills, I decided that I really didn't see a good way to mix-and-match direct and distributed benefits in a manner that wouldn't overly bias character design. And, too, as I did some more brainstorming, I realized that using Attributes only as Skill bonuses actually made things neat and streamlined.
With the system as designed, if an Attribute ends up being "too strong", I have about 20 different "dials" I can turn. Since the entirety of the worth of an Attribute is in how much effective Skill increase it gives a character, I can modify which Skills it bonuses, at what rate it bonuses those Skills, and at what rate performance in those Skills increases with Skill rating. With the original, direct system, I would only be able to alter the equivalent of the bonus rating it provided.
At the same time, from the player's point of view, things are very direct. You know exactly how much every Attribute rating increase will help you. There's no nebulous "increases melee damage" or "reduces chance to be hit". Every +1 Attribute rating provides a straightforward +x bonus to Y skills. You'll know exactly which Skills will be bonused by what amount, and you'll know exactly what that amount will buy you. This means you can easily plan how to spend your precious experience to improve whatever you want at the best rate. In general, Attributes are vastly more expensive than Skills, but they bonus many Skills at the same time. If you have an Attribute with many links to Skills your character uses, then that Attribute will be a good buy; similarly, if you have an Attribute with few or no links to Skills your character uses, it won't be a good buy and you probably won't spend on it.
That leads me to another important concept for Attributes: they don't really measure anything objective. A character with a Strength of 2 is not twice as strong as a character with a Strength of 1. Attribute and Skill ratings are purely game mechanics constructs. A character with a higher Skill or Attribute rating is more skilled/stronger/etc, but there's no definitive measure of how much better they are. In addition, there's no link at all between two different characters' Attribute ratings -- one character with Strength 10 may be "stronger" in melee combat than a character with Strength 20 (by virtue of having higher effective Skill rating). That kind of distinction, in my opinion, is something better kept to the individual's concept of their character. It also gives me a lot more design freedom. I can give some giant boss monster a Strength of 30 and not have to worry about having a character of the smallest race being "stronger".
Today's excerpt and analysis is the Attribute system.
In Fate, Attributes and Skills are inexorably linked. Actually, Attributes are essentially "super-skills" that provide bonuses to every linked Skill. They actually don't do anything on their own. The strongest character in the world would gain no benefit from his Strength if he didn't have any Strength-linked Skills at rating 1 or higher. However, as soon as he invested experience in raising one of those Skills to rating 1, he would instantly have a significant boost to that Skill -- all the way up to +50 effective rating for a major link. As you'll see when I get to the Skills excerpt and analysis, +50 rating is absolutely huge.
So, why design the game this way? Well, one of the design goals was to have an "open" system, where you could mix-and-match abilities and character designs to make whatever kind of character you wanted to play. That lead directly to the Skill system design (as well as the level-less experience system). At first, Attributes were going to be a more standard "Strength raises damage with melee weapons, Agility makes you harder to hit, etc" design. But then I looked at it and realized that sort of system can limit options pretty severely. For example, if only Strength increased melee damage, then only a strong character can be an effective melee combatant. That prevents even such basic character archetypes as the fencer or the dirty tricks-using rogue.
Since I wanted to keep character design open, I therefore couldn't restrict such basic concepts as damage, avoidance, and the like solely to Attributes. The next logical thought, then, was to do a mixture -- Attributes had direct effects like before, as well as distributed effects as described in the excerpt. However, after running a few simulations with my preliminary combat Skills, I decided that I really didn't see a good way to mix-and-match direct and distributed benefits in a manner that wouldn't overly bias character design. And, too, as I did some more brainstorming, I realized that using Attributes only as Skill bonuses actually made things neat and streamlined.
With the system as designed, if an Attribute ends up being "too strong", I have about 20 different "dials" I can turn. Since the entirety of the worth of an Attribute is in how much effective Skill increase it gives a character, I can modify which Skills it bonuses, at what rate it bonuses those Skills, and at what rate performance in those Skills increases with Skill rating. With the original, direct system, I would only be able to alter the equivalent of the bonus rating it provided.
At the same time, from the player's point of view, things are very direct. You know exactly how much every Attribute rating increase will help you. There's no nebulous "increases melee damage" or "reduces chance to be hit". Every +1 Attribute rating provides a straightforward +x bonus to Y skills. You'll know exactly which Skills will be bonused by what amount, and you'll know exactly what that amount will buy you. This means you can easily plan how to spend your precious experience to improve whatever you want at the best rate. In general, Attributes are vastly more expensive than Skills, but they bonus many Skills at the same time. If you have an Attribute with many links to Skills your character uses, then that Attribute will be a good buy; similarly, if you have an Attribute with few or no links to Skills your character uses, it won't be a good buy and you probably won't spend on it.
That leads me to another important concept for Attributes: they don't really measure anything objective. A character with a Strength of 2 is not twice as strong as a character with a Strength of 1. Attribute and Skill ratings are purely game mechanics constructs. A character with a higher Skill or Attribute rating is more skilled/stronger/etc, but there's no definitive measure of how much better they are. In addition, there's no link at all between two different characters' Attribute ratings -- one character with Strength 10 may be "stronger" in melee combat than a character with Strength 20 (by virtue of having higher effective Skill rating). That kind of distinction, in my opinion, is something better kept to the individual's concept of their character. It also gives me a lot more design freedom. I can give some giant boss monster a Strength of 30 and not have to worry about having a character of the smallest race being "stronger".
Design Excerpt: Attributes
Here's the first in the promised series of design document excerpts. This is the section on Attributes, with one example Attribute (of seven, total) fully detailed. I'll post another excerpt tomorrow. Do note, with this series, that things are subject to change between now and when the game is finished.
Character Attributes
Purpose of Attributes:
Attributes measure how capable a character's body or mind is in a certain field. Attributes provide bonuses to the effective rating of linked skills and may also provide bonuses to other aspects of the character.
Attributes are rated from 1 to 50. Each +1 attribute rating should provide exactly the same effect, no matter if you're raising an attribute rating from 1->2 or 49->50. The diminishing returns should come in from the rising price of increasing the attribute rating, not from reduced effect.
Formula for attribute increase price:
(A^2/sqrt(B)) * 100, where A is the new attribute rating and B is the old attribute rating.
Skill bonuses:
Bold text indicates a major linked skill, to which an attribute provides its rating as a bonus to the skill's effective rating.
Normal text indicates a standard linked skill, to which an attribute provides ½ its rating as a bonus to the skill's effective rating.
Italicized text indicates a minor linked skill, to which an attribute provides ¼ its rating as a bonus to the skill's effective rating.
All skills should add up to 1.5 total attribute rating bonuses, from a major+normal, major+2minor, 3normal, 2normal+2minor, or normal+4minor layout.
Endurance
Linked Skills: Swimming, Survival, Blood Magic, Impact Weapons, Two-Handed Impact Weapons, Brawling, Dodge, Shield Block, Plate Armor, Health, Stamina, Long Blades, Two-Handed Blades, Spears, Heavy Thrown Weapons, Chain Armor, Spellsong
3 major, 8 normal, 6 minor; total skill increase per rating point = 3 + 4 + 1.5 = 8.5
Monday, June 15, 2009
Progress
I've been busy this last week or so, finalizing the technical design document for review. I'll start posting sections of it for people to see in the coming week.
The next stage was to be the content design document, but that stage is being delayed for now due to real life circumstances (not mine, for the record). Instead, the next milestone will be completion of the toolset for the game. At the moment, I've decided on a unified Map Editor (for World/Area/Local maps) and a unified Data Editor (for characters, quests, items, and so on, which will all be XML based and so, yes, fully moddable).
Once these tools are complete, I will release them on FileFront for people to examine. One of the goals of the game is to allow user-created content, and releasing the tools early is one way to facilitate that. Note that the initially released tools will probably not be compatible with the release version of the game, because there will almost certainly be changes in the relevant code along the way, but the overall design of the tools will not change.
The next stage was to be the content design document, but that stage is being delayed for now due to real life circumstances (not mine, for the record). Instead, the next milestone will be completion of the toolset for the game. At the moment, I've decided on a unified Map Editor (for World/Area/Local maps) and a unified Data Editor (for characters, quests, items, and so on, which will all be XML based and so, yes, fully moddable).
Once these tools are complete, I will release them on FileFront for people to examine. One of the goals of the game is to allow user-created content, and releasing the tools early is one way to facilitate that. Note that the initially released tools will probably not be compatible with the release version of the game, because there will almost certainly be changes in the relevant code along the way, but the overall design of the tools will not change.
Thursday, May 28, 2009
I Love "Eureka!" Moments
I'm currently at work writing up the list of possible effects (conditions that can apply to characters as a result of spells and techniques, etc) and came to "Afraid". Normally in RPGs this is a "can't control your character" effect, which in general I don't like, so I've been trying to think of a good way to handle fear, which is an important element of combat, especially against extremely powerful foes like dragons. Then the Eureka came: I already have a mechanic in place that can easily replicate many of the actual effects of fear -- the Aggressive vs Conservative and Assertive vs Passive personality sliders. In a nutshell, aggressive characters take more risks than conservative ones and assertive characters are more likely to interpret your commands loosely than passive ones are.
So, Fear effects in Fate will temporarily modify the targetted characters' aggressiveness (making them less likely to attack all-out/more likely to defend themselves) and assertiveness (making them more likely to modify your orders). This means that characters who are frightened will defend themselves (or heal themselves/the party) more, choose attacks that increase their defenses or reduce their opponents' attack abilities, and be more likely to "panic" and choose to do something that isn't what you told them to do. In short, it's a middle ground between full loss of control and the boring stat reduction that is the usual alternative.
Unfortunately, I think I'm going to have to stick to boring stat reductions for the PC, as it doesn't use the AI command system. Oh well.
So, Fear effects in Fate will temporarily modify the targetted characters' aggressiveness (making them less likely to attack all-out/more likely to defend themselves) and assertiveness (making them more likely to modify your orders). This means that characters who are frightened will defend themselves (or heal themselves/the party) more, choose attacks that increase their defenses or reduce their opponents' attack abilities, and be more likely to "panic" and choose to do something that isn't what you told them to do. In short, it's a middle ground between full loss of control and the boring stat reduction that is the usual alternative.
Unfortunately, I think I'm going to have to stick to boring stat reductions for the PC, as it doesn't use the AI command system. Oh well.
Tuesday, May 26, 2009
Interesting Choices, part 2
So, how does the concept of interesting choices affect game balance? I'll use the traditional pen and paper fantasy RPG archetypes as an example: fighters vs mages. Right away there's an obvious imbalance; mages wield great cosmic power! (to borrow from Disney's Alladin), while fighters hit things with swords. No comparison, right?
Maybe in "reality", but reality in general makes a poor game. As a wise man once said, "physics is a house rule". Think of it from a player perspective -- given a choice, would you rather play the guy who runs up and hits the "attack" button endlessly, or the guy who picks and chooses his spells carefully to conserve his power and reduce his foes to ashes?
This is an application of the Interesting Choices design I referred to in the previous post. In traditional RPGs, fighter type characters often have few to no choices in combat except to hit that big "attack" button, while mages get long lists of spells with varying and interesting effects. While generally the fighter is as effective in his own way compared to the mage, it's far less fun to have one button to push instead of several dozen. In other words, fighters don't generally have many (or any) Interesting Choices to make in combat, while mages generally have quite a few.
Even leaving aside game design holes, the sad state of non-spellcasting combat in most systems is even sadder when you consider the plethora of excellent "fighter type" myths to draw on. Miyamoto Musashi certainly had plenty of interesting choices to make in his sword duels. Cuchulainn had many tricks and abilities at his disposal without relying on spells. So did King Arthur and Gilgamesh, Beowulf and Paul Bunyan, and so on. In point of fact, I can't think of a single heroic mythological figure who does use "run at the enemy and swing my weapon in a single repetitive motion until one of us dies" as any kind of tactic in battle; even Conan is cunning and fights dirty if the situation calls for it.
So, how does Fate introduce Interesting Choices to the non-spellcasting character archetypes? That ties neatly into one of the big inspirations behind the Warrior-based classes in the game, although it applies to Rogue-based classes as well. In most modern fantasy stories with a swordfighter for a protagonist, a certain amount of detail is given to the fighting style the character uses. Despite other flaws in the books, for example, the sword fighting scenes in The Wheel of Time books by the late Robert Jordan are envigorating to read, with cleverly named manuevers that are both evocative and descriptive. Similarly, in the Drizzt Do'Urden books by R. A. Salvatore, while the techniques the titular swordmaster uses aren't named as Jordan's are, there's a very clear and evocative description of just how he fights. Even in the inestimable Princess Bride, there's the famous Duel of the Cliffs of Despair, with its Capa Ferro and Bonetti's Defense.
So, in Fate, just as spellcasters get to spend experience on spellcasting skills and proficiency with individual spells, so to do fighters and rogues get to spend experience on fighting styles and individual techniques. Some of the fighting styles will be full of colorful, Jordan-esque names, while others will be more clinically named along the lines of modern fencing or the Princess Bride swordfights; indeed, there may actually be multiple names for the same technique as taught by different schools. They will all, however, give the more "mundane" characters a variety of options in combat rather than to just hit Attack.
I can't say yet just how many schools there will be nor how many techniques per school, but I will say that people who want to play a fighter but get too bored to finish the game with one should hopefully be happy with what they see in Fate.
Maybe in "reality", but reality in general makes a poor game. As a wise man once said, "physics is a house rule". Think of it from a player perspective -- given a choice, would you rather play the guy who runs up and hits the "attack" button endlessly, or the guy who picks and chooses his spells carefully to conserve his power and reduce his foes to ashes?
This is an application of the Interesting Choices design I referred to in the previous post. In traditional RPGs, fighter type characters often have few to no choices in combat except to hit that big "attack" button, while mages get long lists of spells with varying and interesting effects. While generally the fighter is as effective in his own way compared to the mage, it's far less fun to have one button to push instead of several dozen. In other words, fighters don't generally have many (or any) Interesting Choices to make in combat, while mages generally have quite a few.
Even leaving aside game design holes, the sad state of non-spellcasting combat in most systems is even sadder when you consider the plethora of excellent "fighter type" myths to draw on. Miyamoto Musashi certainly had plenty of interesting choices to make in his sword duels. Cuchulainn had many tricks and abilities at his disposal without relying on spells. So did King Arthur and Gilgamesh, Beowulf and Paul Bunyan, and so on. In point of fact, I can't think of a single heroic mythological figure who does use "run at the enemy and swing my weapon in a single repetitive motion until one of us dies" as any kind of tactic in battle; even Conan is cunning and fights dirty if the situation calls for it.
So, how does Fate introduce Interesting Choices to the non-spellcasting character archetypes? That ties neatly into one of the big inspirations behind the Warrior-based classes in the game, although it applies to Rogue-based classes as well. In most modern fantasy stories with a swordfighter for a protagonist, a certain amount of detail is given to the fighting style the character uses. Despite other flaws in the books, for example, the sword fighting scenes in The Wheel of Time books by the late Robert Jordan are envigorating to read, with cleverly named manuevers that are both evocative and descriptive. Similarly, in the Drizzt Do'Urden books by R. A. Salvatore, while the techniques the titular swordmaster uses aren't named as Jordan's are, there's a very clear and evocative description of just how he fights. Even in the inestimable Princess Bride, there's the famous Duel of the Cliffs of Despair, with its Capa Ferro and Bonetti's Defense.
So, in Fate, just as spellcasters get to spend experience on spellcasting skills and proficiency with individual spells, so to do fighters and rogues get to spend experience on fighting styles and individual techniques. Some of the fighting styles will be full of colorful, Jordan-esque names, while others will be more clinically named along the lines of modern fencing or the Princess Bride swordfights; indeed, there may actually be multiple names for the same technique as taught by different schools. They will all, however, give the more "mundane" characters a variety of options in combat rather than to just hit Attack.
I can't say yet just how many schools there will be nor how many techniques per school, but I will say that people who want to play a fighter but get too bored to finish the game with one should hopefully be happy with what they see in Fate.
Thursday, May 21, 2009
Interesting Choices, part 1
One of the key aspects of game design in general, and one of the most heavily emphasized areas in the design of Fate, is the concept of "Interesting Choices". Anyone can tell you what a choice is; you have the option to do A or B, where the actions you take to perform each option are different to one degree or another.
However, there's a very big difference between a choice and an interesting choice. An interesting choice requires that there are consequences for every possible option, and that the risk:reward ratios between the various choices are reasonably balanced. As an example, if you have the choice to either A) Kill the big bad boss instantly with no chance of failure, or B) attempt to fight him the traditional way, where no matter which choice you make the rewards are the same, that is not an interesting choice. The rewards are the same, but the risk levels are vastly different, making one choice obvious and therefore boring.
Similarly, if you have a decision tree that branches out to points C and D, but no matter which choice you take, the rewards are essentially the same and you end up back at the same point E, that is also not an interesting choice. As a matter of fact, I would go so far as to make the argument that it isn't a choice at all, as there's no substantive difference no matter which option you take.
Now that I've explained the general theory behind Interesting Choices, how does that relate to the design of Fate? Well, a better question would be "How doesn't it relate?". I've taken the concept and applied it pretty much everywhere I could think of, right down to the nuts and bolts of the experience system design. As I mentioned previously, characters are not forcefully restricted from being able to "do everything". Instead, the player must make a choice about what areas to focus on and what areas to leave by the wayside. If the player chooses to focus on a limited skillset, the character will be quite proficient at that skillset, but will be ignoring several other skillsets which could potentially provide it with performance increases. On the flip side, spreading out your experience over several attributes and skills means that your character can do more different things and will likely be at least partially relevant in any situation, but you're sacrificing the ability to reach the upper tier of effectiveness with any of your choices.
That same type of choice -- width vs depth, risk vs reward, conservative vs aggressive -- pervades the design philosophy. I detest "easy choices". If a choice is too easy, it ceases to become a choice except in the masochistic sense. There is certainly a market for that kind of thing -- a good example is Iron Man modes in games, where saved games are deleted upon loading, so that you can't save-reload to avoid bad consequences -- but in my opinion it needs to be restricted to metagame concerns only. Difficulty levels, Iron Man, options that you would find in the game's configuration menu. Easy choices once you're actually IN the game just fall flat.
I think that's enough for now. In part 2, I'll explore how the Interesting Choices combat affects the balance between fighters, rogues, and spellcasters.
However, there's a very big difference between a choice and an interesting choice. An interesting choice requires that there are consequences for every possible option, and that the risk:reward ratios between the various choices are reasonably balanced. As an example, if you have the choice to either A) Kill the big bad boss instantly with no chance of failure, or B) attempt to fight him the traditional way, where no matter which choice you make the rewards are the same, that is not an interesting choice. The rewards are the same, but the risk levels are vastly different, making one choice obvious and therefore boring.
Similarly, if you have a decision tree that branches out to points C and D, but no matter which choice you take, the rewards are essentially the same and you end up back at the same point E, that is also not an interesting choice. As a matter of fact, I would go so far as to make the argument that it isn't a choice at all, as there's no substantive difference no matter which option you take.
Now that I've explained the general theory behind Interesting Choices, how does that relate to the design of Fate? Well, a better question would be "How doesn't it relate?". I've taken the concept and applied it pretty much everywhere I could think of, right down to the nuts and bolts of the experience system design. As I mentioned previously, characters are not forcefully restricted from being able to "do everything". Instead, the player must make a choice about what areas to focus on and what areas to leave by the wayside. If the player chooses to focus on a limited skillset, the character will be quite proficient at that skillset, but will be ignoring several other skillsets which could potentially provide it with performance increases. On the flip side, spreading out your experience over several attributes and skills means that your character can do more different things and will likely be at least partially relevant in any situation, but you're sacrificing the ability to reach the upper tier of effectiveness with any of your choices.
That same type of choice -- width vs depth, risk vs reward, conservative vs aggressive -- pervades the design philosophy. I detest "easy choices". If a choice is too easy, it ceases to become a choice except in the masochistic sense. There is certainly a market for that kind of thing -- a good example is Iron Man modes in games, where saved games are deleted upon loading, so that you can't save-reload to avoid bad consequences -- but in my opinion it needs to be restricted to metagame concerns only. Difficulty levels, Iron Man, options that you would find in the game's configuration menu. Easy choices once you're actually IN the game just fall flat.
I think that's enough for now. In part 2, I'll explore how the Interesting Choices combat affects the balance between fighters, rogues, and spellcasters.
Wednesday, May 20, 2009
Fate of the Mullen Overview
Alright, so now I get to describe our flagship game. World of Olume: Fate of the Mullen is a fantasy themed computer RPG (role-playing game), set in an original world and designed to appeal to fans of old-school CRPGs such as Might and Magic or Wizardry.
Probably the first question people will have after seeing the title is "What is a Mullen and why should I care?", and that's a pretty good question if I say so myself. Mullen are a race of gaunt, bipedal humanoids whose main distinguishing feature is a softball-sized, ruby-like gem set into their foreheads. These gems allow the Mullen to access a kind of ancestral memory; every Mullen clearly and accurately recalls everything that any of their direct ancestors experienced or learned. In fact, this racial memory means that the Mullen are the only race that actually knows what the world was like before the Second Genesis (but more on that later, in another post). Why "Fate of the Mullen"? Because, not to spoil the plot too thoroughly, the fate of pretty much the entire race ends up in the hands of the player's character and its allies. As a hint: their ancestral memory is both their greatest strength and their greatest weakness.
When I started designing Fate, I asked myself some questions: What kind of RPG do you enjoy the most? What do you enjoy about that kind of RPG? What elements of other RPGs do you also enjoy? Is there any reason you can't combine them? How much of all that do you actually think you can pull off by yourself? After stirring those thoughts around for a while, I came up with the following formula:
Fate of the Mullen will be an entirely 2D game, using a mix of tile-based and pre-rendered maps. The player will only directly control their main character -- the one they create at the start of the game -- but that character will be the leader of a party of hearty souls and the player will be able to give general orders ("Heal the party!" or "Fight with all your strength!", etc) to each party member. Those party members will have their own individual personalities and will favor different types of abilities and may or may not follow your orders to the letter. For example, a pacifist priest may well ignore your orders to directly attack the enemy and instead cast a spell to increase the accuracy or attack power of other party members. To keep the "Why won't they do what I tell them to?!" factor to a dull roar, each NPC will have a personality profile that will be available to the player to view, so that the player can make informed decisions about who to bring along.
Most games would stop there and call it a day; not Fate. In Fate, you'll be able to expand your operations as the game goes on and recruit additional parties. These "extra" adventuring parties can either be sent out on their own to explore and adventure and bring back news and loot, or they can be brought along with the main character's party -- for example, if you know for a fact that you're going to be facing an extremely tough battle in a certain adventure site, you can bring along another party to tip the odds in your favor. However, the player's control over "extra" parties in combat is limited further to giving only a single general command to the entire group ("Fight defensively!" or "Take out the minions!" for example), and again each party member will impart their own spin to the commands.
I'll talk more about the decisions behind the party AI system in another post; for now let me get on with describing the game. Characters are made with a non-level-based, not-really-class-based system; while there are character classes, they mainly exist to help the player and the AI build their character effectively. Characters earn experience points for completing quests and defeating enemies, as normal for CRPGs, but instead of needing a set amount of XP to "level up" and improve all their capabilities in one fell swoop, the player or AI instead can choose to pay XP to advance any of their stats, skills, spells, weapon techniques, and so on individually at any time (even in the heat of battle!). The main function of classes in this system is to alter the XP cost of advancing your character's capabilities. Warriors, for example, will find it cheaper to advance their physical stats and combat skills, but more expensive to learn spells; Mages, on the other hand, get Arcana spells cheaply, but tend to pay more to increase their Strength and heavy armor skills.
In this way, characters can be built to do anything and everything, but it will be most efficient to "color within the lines", so to speak. There's absolutely nothing stopping the player from creating a Warrior who is an expert with a sword, wears full plate armor, carries a hulking tower shield, casts Magebolts and Benedictions, and so on -- but it will be very expensive and the character will sacrifice power for versatility in a very notable fashion. Now, I like making characters that can do two or three things fairly well just as much as the next guy, so there's even a system in place to allow this: you can take more than one character class. Essentially, classes are arranged in a tiered system, with Warrior, Priest, Mage, and Rogue at the bottom tier, then expanding outwards from there. Each character may have one class from each tier, as long as they meet the requirements. As an example, you can have a character start out as a Warrior, but work on his Reaction and Intuition stats and Stealth and Scouting skills and, once he reaches the required amounts, can pay the XP cost and take on the 2nd tier class "Scout" (part of the Rogue family). Scout will provide its own XP cost weights, which will make it easier to continue to develop the character as a lightly-armored strike-and-fade fighter. The counterbalance is that each tier of class offers less powerful and/or less broad bonuses, so your base class will always be the biggest factor in the development of your character.
The last major component of the game is the movement and exploration system. Essentially, the game is divided up into three map levels: World map, Area map (generally covering a state- or country-sized chunk of the World map), and Adventure Sites. You start the game only being able to access the starting Area map and the towns and Adventure Sites it contains. After a certain point in the game, you'll be able to explore past the boundaries of your current Area, which will bump you up to the World map to select a new Area to enter. Each Area has both obvious sites (major towns, poorly-hidden dungeons, and the like) and hidden sites ("Stand by the gray stone when the thrush knocks, and the last light of the setting sun will shine upon the keyhole..."). You decide where to send each party on the Area map, how fast you want to move, how thoroughly you want to search for new sites, and so on. Moving quickly is unlikely to uncover any well-hidden location unless you happen to ride right over top of it, but you're also less likely to blunder into monsters, so it's a tradeoff. Quests may tell you exactly where to go and automatically open up the Adventure Site on your Area map, or they may just tell you the general area to search in ("Those boggs al'ays come from th' West, they do, Sir") and leave the hard work to you and your party.
Alright, I think that's a big enough wall of text for now. I'll post some more details up tomorrow. For now -- bed!
Probably the first question people will have after seeing the title is "What is a Mullen and why should I care?", and that's a pretty good question if I say so myself. Mullen are a race of gaunt, bipedal humanoids whose main distinguishing feature is a softball-sized, ruby-like gem set into their foreheads. These gems allow the Mullen to access a kind of ancestral memory; every Mullen clearly and accurately recalls everything that any of their direct ancestors experienced or learned. In fact, this racial memory means that the Mullen are the only race that actually knows what the world was like before the Second Genesis (but more on that later, in another post). Why "Fate of the Mullen"? Because, not to spoil the plot too thoroughly, the fate of pretty much the entire race ends up in the hands of the player's character and its allies. As a hint: their ancestral memory is both their greatest strength and their greatest weakness.
When I started designing Fate, I asked myself some questions: What kind of RPG do you enjoy the most? What do you enjoy about that kind of RPG? What elements of other RPGs do you also enjoy? Is there any reason you can't combine them? How much of all that do you actually think you can pull off by yourself? After stirring those thoughts around for a while, I came up with the following formula:
Fate of the Mullen will be an entirely 2D game, using a mix of tile-based and pre-rendered maps. The player will only directly control their main character -- the one they create at the start of the game -- but that character will be the leader of a party of hearty souls and the player will be able to give general orders ("Heal the party!" or "Fight with all your strength!", etc) to each party member. Those party members will have their own individual personalities and will favor different types of abilities and may or may not follow your orders to the letter. For example, a pacifist priest may well ignore your orders to directly attack the enemy and instead cast a spell to increase the accuracy or attack power of other party members. To keep the "Why won't they do what I tell them to?!" factor to a dull roar, each NPC will have a personality profile that will be available to the player to view, so that the player can make informed decisions about who to bring along.
Most games would stop there and call it a day; not Fate. In Fate, you'll be able to expand your operations as the game goes on and recruit additional parties. These "extra" adventuring parties can either be sent out on their own to explore and adventure and bring back news and loot, or they can be brought along with the main character's party -- for example, if you know for a fact that you're going to be facing an extremely tough battle in a certain adventure site, you can bring along another party to tip the odds in your favor. However, the player's control over "extra" parties in combat is limited further to giving only a single general command to the entire group ("Fight defensively!" or "Take out the minions!" for example), and again each party member will impart their own spin to the commands.
I'll talk more about the decisions behind the party AI system in another post; for now let me get on with describing the game. Characters are made with a non-level-based, not-really-class-based system; while there are character classes, they mainly exist to help the player and the AI build their character effectively. Characters earn experience points for completing quests and defeating enemies, as normal for CRPGs, but instead of needing a set amount of XP to "level up" and improve all their capabilities in one fell swoop, the player or AI instead can choose to pay XP to advance any of their stats, skills, spells, weapon techniques, and so on individually at any time (even in the heat of battle!). The main function of classes in this system is to alter the XP cost of advancing your character's capabilities. Warriors, for example, will find it cheaper to advance their physical stats and combat skills, but more expensive to learn spells; Mages, on the other hand, get Arcana spells cheaply, but tend to pay more to increase their Strength and heavy armor skills.
In this way, characters can be built to do anything and everything, but it will be most efficient to "color within the lines", so to speak. There's absolutely nothing stopping the player from creating a Warrior who is an expert with a sword, wears full plate armor, carries a hulking tower shield, casts Magebolts and Benedictions, and so on -- but it will be very expensive and the character will sacrifice power for versatility in a very notable fashion. Now, I like making characters that can do two or three things fairly well just as much as the next guy, so there's even a system in place to allow this: you can take more than one character class. Essentially, classes are arranged in a tiered system, with Warrior, Priest, Mage, and Rogue at the bottom tier, then expanding outwards from there. Each character may have one class from each tier, as long as they meet the requirements. As an example, you can have a character start out as a Warrior, but work on his Reaction and Intuition stats and Stealth and Scouting skills and, once he reaches the required amounts, can pay the XP cost and take on the 2nd tier class "Scout" (part of the Rogue family). Scout will provide its own XP cost weights, which will make it easier to continue to develop the character as a lightly-armored strike-and-fade fighter. The counterbalance is that each tier of class offers less powerful and/or less broad bonuses, so your base class will always be the biggest factor in the development of your character.
The last major component of the game is the movement and exploration system. Essentially, the game is divided up into three map levels: World map, Area map (generally covering a state- or country-sized chunk of the World map), and Adventure Sites. You start the game only being able to access the starting Area map and the towns and Adventure Sites it contains. After a certain point in the game, you'll be able to explore past the boundaries of your current Area, which will bump you up to the World map to select a new Area to enter. Each Area has both obvious sites (major towns, poorly-hidden dungeons, and the like) and hidden sites ("Stand by the gray stone when the thrush knocks, and the last light of the setting sun will shine upon the keyhole..."). You decide where to send each party on the Area map, how fast you want to move, how thoroughly you want to search for new sites, and so on. Moving quickly is unlikely to uncover any well-hidden location unless you happen to ride right over top of it, but you're also less likely to blunder into monsters, so it's a tradeoff. Quests may tell you exactly where to go and automatically open up the Adventure Site on your Area map, or they may just tell you the general area to search in ("Those boggs al'ays come from th' West, they do, Sir") and leave the hard work to you and your party.
Alright, I think that's a big enough wall of text for now. I'll post some more details up tomorrow. For now -- bed!
Tuesday, May 19, 2009
What is Rimurstar Productions?
Rimurstar Productions is a small, independent game development company currently located in Jacksonville, Florida. Or, to be more precise: Rimurstar Productions is me, and I'm currently located in Jax.
I started Rimurstar for a few reasons. First, because I have about a billion ideas swarming around in my head wanting to get free, and it's getting kinda crowded in here. Second, to keep me busy doing positive, productive work. Third, as a sort of running resume of my work.
What kind of games and products will Rimurstar Productions be working on? Right now there's just one, World of Olume: Fate of the Mullen, which I'll get into in a later post, an old-school styled computer RPG. There is another computer game in the wings, although serious work won't start on it until Fate is nearing completion, and there may be other World of Olume products as well.
I think that's enough about me and Rimurstar for now. In my next post I'll start describing Fate of the Mullen, my current project.
I started Rimurstar for a few reasons. First, because I have about a billion ideas swarming around in my head wanting to get free, and it's getting kinda crowded in here. Second, to keep me busy doing positive, productive work. Third, as a sort of running resume of my work.
What kind of games and products will Rimurstar Productions be working on? Right now there's just one, World of Olume: Fate of the Mullen, which I'll get into in a later post, an old-school styled computer RPG. There is another computer game in the wings, although serious work won't start on it until Fate is nearing completion, and there may be other World of Olume products as well.
I think that's enough about me and Rimurstar for now. In my next post I'll start describing Fate of the Mullen, my current project.
Subscribe to:
Posts (Atom)