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.
Subscribe to:
Posts (Atom)