The days sort of blur together over the summer without something to keep them separate; hopefully when classes start for me in a week that'll help.
I added an Effect class. Right now it's only set up to modify the basic statistics; while I might want to get something fancier later, most of the things I can think of (buffs, debuffs, poisons, heal over times, etc) will be covered by this.
Effect is a class with ints for duration, ATK, DEF, AP, HP, mHP, MP, mMP, resP, resF, resE, and resC. The Person class now has an array of Effects called Effs that is all the Effects on it; there's also a function for cATK (and all the other variables) that goes through each effect and adds their modifier to the base value.
The primary thing missing now are multipliers. I'm not sure I'll want them, and if I do it would be relatively easy to code (essentially, I would also have it add up a temporary multiplier as well as a temporary base, and then multiply them at the end before returning). I almost want to code it now in case, but it seems silly to put in possibly pointless code.
I've been putting off the battle interface. That won't be possible for too much longer :P
Tuesday, May 27, 2008
Saturday, May 24, 2008
Coming Soon
I like to keep a sort of mental to-do list of the next steps I should take. I rarely make this into an actual list or flesh it out fully- knowing that the next steps are "make a simple battle map system," "come up with basic abilities," and "come up with actual numbers for the classes" is helpful but knowing "wow, there's fifteen different things that need to happen for this to work" isn't. It is helpful on some levels- and if there were more people involved, it would be critical to make sure tasks are split and people are working on what's most important.
One other thing I should mention is modular programming. Essentially, you design everything so that it doesn't need everything else functional for it to function- it makes it so you can test, say, an inventory-management program before items are fully done, or make sure that items work properly before making a battle system that can use them. The question, though, becomes how much I should try and keep the sophistication of each component at the same level- should I finish coding the classes before I move on to abilities, or should I code enough for the classes to be able to reasonably test other things, and then come back to improve them once I have a basic program running?
If I had done more planning, the "finish each component" method might work- but it's not really an option when I'm still musing over other critical things. Should movement be just speed plus a single action, or an action points system where you can attack multiple times if you don't move? Should units move in some initiative order, or should a player's entire party move together?
One other thing I should mention is modular programming. Essentially, you design everything so that it doesn't need everything else functional for it to function- it makes it so you can test, say, an inventory-management program before items are fully done, or make sure that items work properly before making a battle system that can use them. The question, though, becomes how much I should try and keep the sophistication of each component at the same level- should I finish coding the classes before I move on to abilities, or should I code enough for the classes to be able to reasonably test other things, and then come back to improve them once I have a basic program running?
If I had done more planning, the "finish each component" method might work- but it's not really an option when I'm still musing over other critical things. Should movement be just speed plus a single action, or an action points system where you can attack multiple times if you don't move? Should units move in some initiative order, or should a player's entire party move together?
Friday, May 23, 2008
Minor progress!
The Person class is made, and I've got child classes for the different character classes.
I decided to go with Person because it's synonymous enough and there are already enough 'Character's floating around in C# for me to be sure I wasn't treading on anything, and this'll prevent mistakes in the future.
I've also got the Ability class made- right now its key feature is the effect method, which is overloaded for three inputs:
effect(Person user)
effect(Person user, Person targ)
effect(Person user, List targs)
For all abilities, the two wrong methods will pass back an error (with the ability name in it- always try to make your code easier to debug), and the other one will do what the ability is supposed to. I don't know how abilities will be aimed yet, but the abilities already have range and aoe variables to tell the aiming interface what it should tell the user to pick. The function returns a string- an output of either "This method shouldn't have been called!" "[name] doesn't have the MP to use this ability!" or "This ability did X!"
Mad screenshot action!
I decided to go with Person because it's synonymous enough and there are already enough 'Character's floating around in C# for me to be sure I wasn't treading on anything, and this'll prevent mistakes in the future.
I've also got the Ability class made- right now its key feature is the effect method, which is overloaded for three inputs:
effect(Person user)
effect(Person user, Person targ)
effect(Person user, List
For all abilities, the two wrong methods will pass back an error (with the ability name in it- always try to make your code easier to debug), and the other one will do what the ability is supposed to. I don't know how abilities will be aimed yet, but the abilities already have range and aoe variables to tell the aiming interface what it should tell the user to pick. The function returns a string- an output of either "This method shouldn't have been called!" "[name] doesn't have the MP to use this ability!" or "This ability did X!"
Mad screenshot action!
Why is it always about Marx
Let's talk about classes.
D&D has 11 (if you only open the PHB), FFI had 6, WoW has 9.
How many classes should there be? Enough that no useful tactical role is unfilled, and not so many that it becomes possible to forget about one of them when writing down a list. It seems better to go from tactical role to class, instead of the other way around- it makes it clearer what division there should be between a fighter and a barbarian, for example, or if there should be a division at all.
So, tactical roles:
Support is also easy to break down. There are three primary kinds of support: weakening your enemies, strengthening your allies, and undoing enemy actions (i.e. healing and dispelling). The tank probably don't need multiple varieties.
Then, one could make hybrids- but that's probably counterproductive, especially in a system which stresses making a good group. It's hard to balance hybrids, anyway, and so it seems likely that it's easier to just ignore them.
So, we have four main roles and seven main flavors. It seems like four makes for a good party size- it's certainly the traditional one. I like three, but it seems to constrain party choice a bit much. That might be a good thing- it makes the choice between having a tank or another dps char, instead of just saying "oh, I'll take both." The primary benefit of four characters seems to be that it makes it easier to balance support chars, or at least make support chars still desirable while not very powerful- a support character needs to boost 3 companions by 33% to compensate for not doing anything, or 2 companions by 50%.
So, temporary class list: Guardian, Soldier, Archer, Wizard, Sun Priest, Moon Priest, and Star Priest. I'll have to think about making the support characters all priests, and whether it's better to do astronomic or anthropic religions- but for now it works.
I haven't even touched on what makes up a character- I should probably discuss that a little. Generic ATK and DEF variables will probably suffice, as well as HP. I haven't decided yet if combat will be a la FF or FFT; FFT seems like it would be more interesting (especially since it makes it easier to do ranged attacks in a nice way, as opposed to the two-rows method of things like Disciples II). Abilities will have to be classes in their own right, with a range, effect, cost (looks like we need MP as well), and such.
D&D has 11 (if you only open the PHB), FFI had 6, WoW has 9.
How many classes should there be? Enough that no useful tactical role is unfilled, and not so many that it becomes possible to forget about one of them when writing down a list. It seems better to go from tactical role to class, instead of the other way around- it makes it clearer what division there should be between a fighter and a barbarian, for example, or if there should be a division at all.
So, tactical roles:
- Tank- high defense, low-med attack, low range.
- Melee dps- high attack, low-med defense, low range.
- Ranged dps- high attack, low defense, high range.
- Support - low attack, low-med defense, low-high range, other utility.
Support is also easy to break down. There are three primary kinds of support: weakening your enemies, strengthening your allies, and undoing enemy actions (i.e. healing and dispelling). The tank probably don't need multiple varieties.
Then, one could make hybrids- but that's probably counterproductive, especially in a system which stresses making a good group. It's hard to balance hybrids, anyway, and so it seems likely that it's easier to just ignore them.
So, we have four main roles and seven main flavors. It seems like four makes for a good party size- it's certainly the traditional one. I like three, but it seems to constrain party choice a bit much. That might be a good thing- it makes the choice between having a tank or another dps char, instead of just saying "oh, I'll take both." The primary benefit of four characters seems to be that it makes it easier to balance support chars, or at least make support chars still desirable while not very powerful- a support character needs to boost 3 companions by 33% to compensate for not doing anything, or 2 companions by 50%.
So, temporary class list: Guardian, Soldier, Archer, Wizard, Sun Priest, Moon Priest, and Star Priest. I'll have to think about making the support characters all priests, and whether it's better to do astronomic or anthropic religions- but for now it works.
I haven't even touched on what makes up a character- I should probably discuss that a little. Generic ATK and DEF variables will probably suffice, as well as HP. I haven't decided yet if combat will be a la FF or FFT; FFT seems like it would be more interesting (especially since it makes it easier to do ranged attacks in a nice way, as opposed to the two-rows method of things like Disciples II). Abilities will have to be classes in their own right, with a range, effect, cost (looks like we need MP as well), and such.
Game Design: The Basics
I haven't designed a game before. Or, to be more accurate, I haven't finished a game before. So take this how-to as descriptive, instead of normative- if I'm suggesting something silly, point that out.
At the beginning of a project, it's nice to have in mind the skeleton of the project. What will the game look like to play? What will be in the game? What will the back end of the game look like?
The last one seems most important. It's easy to waste time fiddling with the interface (should health be here? Or there? What about there?) and ignoring important things like where that health is stored (a property of the character object, which is possessed by the player object? Or do you not need a player object?). Generally, game companies will have different people working on different things- one person figures out how many classes are necessary while another person figures out how many classes are necessary. That is, character classes and data classes. I'm going to assume a basic programming background in most of my posts, but that shouldn't be too important- if you're only interested in the design parts of the post, or the technical part, just skip through the parts you don't like (and to facilitate that, I'll start putting "design" and "technical" labels on my posts).
So, here are some crude graphics and explanations:
This is how I want the work to look (well, hopefully with a better art department). There's some number of regions that all have the same basic layout- a tavern where one can interact with other players and modify the characters in their party, a training zone where they fight monsters or groups of monsters one at a time (i.e. running around in the woods looking for things to kill), dungeons where you fight a predetermined arrangement of monsters (first you fight the two guards, then three cultists, then a group of skeletons, then two more guards, then a priest and a demon), and a raid zone which is essentially dungeons with more than one adventuring party.
I'll go into the various things in more detail later, but first I wanted to mention procedurally generated dungeons. I didn't think about it much before reading a post of Squidi's on it, but it'll be familiar to anyone that played Diablo (I or II)- making content with extremely high replayability by having it randomized from predefined pieces. It's something that I'll get into when I work on the dungeons themselves- which will probably be once the tavern and the training zone are both up and running.
Interface:
I'm actually going to ignore interface for a while. The battle and dungeon interface seem relatively straightforward- the combat will either be similar to Final Fantasy or to Final Fantasy Tactics, and there's little wrong with either of their interfaces. For the rest of the game- should the tavern just be a chatroom, or more like Habbo Hotel? (I can't believe I linked to that in all seriousness. I'll get over it) Should there be an attempt at overland consistency (i.e., you wander through the training zone until you find dungeon entrances) or should there just be a screen that says "travelling" and then poof, you arrive?
Players need to be an object because the server is going to have a list of players; each player then has a list of characters owned, items owned, current party, etc.
I'm going to digress for a bit and talk about class-based systems vs. skill-based systems in RPGs. Oblivion (or Morrowind) is probably the most famous skill-based RPG out there, whereas D&D is probably the most famous class-based RPG out there (or, a probably more relevant example would be the early Final Fantasies). In a class-based system, a character can be described in one word- their class. Other changes are largely decorative or minor specializations- your wizard might focus on evocation spells, but his difference from other wizards is still smaller than his distance from other classes. In a skill-based system, the common baskets of skills and abilities don't exist- and so instead of "paladin" my character would have "blade, restoration, block, heavy armor, speechcraft, armorer, and athletics." Switching out, say, heavy armor for medium armor will change how the character plays and isn't restricted.
Generally I prefer skill-based systems. The freedom in making whatever archetype you like is one I like. The primary problem is that it's harder to have special abilities (it's clear that paladins should get Lay On Hands, but it's not clear if everyone who gets the Healing skill should get that ability, or what level of Healing they should need to get it), harder to communicate information quickly (which took longer to say, paladin or those seven skills?), and harder to compare character combinations. No one wants to have to deal with this, especially if you have multiple characters you're adding to the group- it's much better to be able to go "ftr/ftr/rmg" than listing the skillsets of three characters.
I'm not sure the best way to code this, yet. I could make a different object class for each character type (class, but type helps lower confusion a bit) with the Character superclass, or I could make the Character class that has however many instances, each of which is a different class, or I could just have character type be a variable in the Character class which other things look up.
This doesn't talk about things like abilities being their own class, which seems like the best way to do it, and I've largely ignored items. This post is already pretty long, so I'll get to them later.
At the beginning of a project, it's nice to have in mind the skeleton of the project. What will the game look like to play? What will be in the game? What will the back end of the game look like?
The last one seems most important. It's easy to waste time fiddling with the interface (should health be here? Or there? What about there?) and ignoring important things like where that health is stored (a property of the character object, which is possessed by the player object? Or do you not need a player object?). Generally, game companies will have different people working on different things- one person figures out how many classes are necessary while another person figures out how many classes are necessary. That is, character classes and data classes. I'm going to assume a basic programming background in most of my posts, but that shouldn't be too important- if you're only interested in the design parts of the post, or the technical part, just skip through the parts you don't like (and to facilitate that, I'll start putting "design" and "technical" labels on my posts).
So, here are some crude graphics and explanations:
This is how I want the work to look (well, hopefully with a better art department). There's some number of regions that all have the same basic layout- a tavern where one can interact with other players and modify the characters in their party, a training zone where they fight monsters or groups of monsters one at a time (i.e. running around in the woods looking for things to kill), dungeons where you fight a predetermined arrangement of monsters (first you fight the two guards, then three cultists, then a group of skeletons, then two more guards, then a priest and a demon), and a raid zone which is essentially dungeons with more than one adventuring party.I'll go into the various things in more detail later, but first I wanted to mention procedurally generated dungeons. I didn't think about it much before reading a post of Squidi's on it, but it'll be familiar to anyone that played Diablo (I or II)- making content with extremely high replayability by having it randomized from predefined pieces. It's something that I'll get into when I work on the dungeons themselves- which will probably be once the tavern and the training zone are both up and running.
Interface:
I'm actually going to ignore interface for a while. The battle and dungeon interface seem relatively straightforward- the combat will either be similar to Final Fantasy or to Final Fantasy Tactics, and there's little wrong with either of their interfaces. For the rest of the game- should the tavern just be a chatroom, or more like Habbo Hotel? (I can't believe I linked to that in all seriousness. I'll get over it) Should there be an attempt at overland consistency (i.e., you wander through the training zone until you find dungeon entrances) or should there just be a screen that says "travelling" and then poof, you arrive?
Players need to be an object because the server is going to have a list of players; each player then has a list of characters owned, items owned, current party, etc.I'm going to digress for a bit and talk about class-based systems vs. skill-based systems in RPGs. Oblivion (or Morrowind) is probably the most famous skill-based RPG out there, whereas D&D is probably the most famous class-based RPG out there (or, a probably more relevant example would be the early Final Fantasies). In a class-based system, a character can be described in one word- their class. Other changes are largely decorative or minor specializations- your wizard might focus on evocation spells, but his difference from other wizards is still smaller than his distance from other classes. In a skill-based system, the common baskets of skills and abilities don't exist- and so instead of "paladin" my character would have "blade, restoration, block, heavy armor, speechcraft, armorer, and athletics." Switching out, say, heavy armor for medium armor will change how the character plays and isn't restricted.
Generally I prefer skill-based systems. The freedom in making whatever archetype you like is one I like. The primary problem is that it's harder to have special abilities (it's clear that paladins should get Lay On Hands, but it's not clear if everyone who gets the Healing skill should get that ability, or what level of Healing they should need to get it), harder to communicate information quickly (which took longer to say, paladin or those seven skills?), and harder to compare character combinations. No one wants to have to deal with this, especially if you have multiple characters you're adding to the group- it's much better to be able to go "ftr/ftr/rmg" than listing the skillsets of three characters.
I'm not sure the best way to code this, yet. I could make a different object class for each character type (class, but type helps lower confusion a bit) with the Character superclass, or I could make the Character class that has however many instances, each of which is a different class, or I could just have character type be a variable in the Character class which other things look up.
This doesn't talk about things like abilities being their own class, which seems like the best way to do it, and I've largely ignored items. This post is already pretty long, so I'll get to them later.
Thursday, May 22, 2008
RPG MMO
A while back a friend and I played a game where you could, essentially, fight parties from early Final Fantasy games in PVP. I had forgotten about it until we talked again recently about support characters in D&D.
We were going over the familiar complaint that, in 3.5e D&D, clerics simply make better fighters than the Fighter class does. The most probable reason for beefing up the cleric was that they wanted to make it a more attractive class- everyone who has put together a D&D party knows the pressure of "ok guys, we need a cleric." No one wants to play the support character when they could be playing a primary character, but the entire party will suffer if someone isn't the support character.
A very similar thing happens in MMOs, because the MMO group is very similar to a D&D group. Someone's got to be the priest. Some people enjoy it- and actually the only character I got to 60 in WoW was a priest. It was nice to always have a spot in groups or raids, but it got pretty boring after a while to be concerned solely with the party's HP.
My solution was to suggest giving everyone multiple characters. If you've got two slots, then devoting one of them to support is no problem- and I think a lot of people would prefer to have, essentially, a character worth 1.5 and a character worth .5 than two characters worth 1.
So what would happen if you gave everyone, instead of a character, a party? Most of the mechanics would work rather similarly- the primary difference is that it needs to be easy to control multiple characters. This can be done either through good AI (probably not; as mentioned before, the best AI available tends to be sub-par and I'm a far way from being able to afford the best AI possible) or by making combat turn-based.
Turn-based combat is easy to do in single-player games, and gets more troublesome in multiplayer games. Something has to be done to keep things moving (turn time limits and a preset default move if no orders are given in the time limit seems best), and unless players move simultaneously puts a soft cap on the number of players that can be in a party.
Speaking of parties, how would you combine adventuring groups well into the traditional MMO group? If there are synergies between different character types (which is the best way to do things) it becomes hard to optimize groups out of optimized subgroups; if you only need one paladin for the group of 9 people, if each subgroup has a paladin there will be a problem.
There are two main solutions: make it so synergies like that stack (i.e. 1 paladin and 1 death knight is only slightly better than 2 paladins or 2 death knights) or make it so each person has a stable of characters. You can only take out 3 or 4 people on adventures, but you have 6 others sitting back at the tavern, so that if the raid doesn't need your paladin you swap him out for your death knight.
The stable approach seems superior, in that it allows you to switch out characters without having to start the entire group over- if you decide that your group of fire mage, ice mage, and lightning mage really does need a meat shield, you don't need to create a new group to have that and level up the two mage types that you want to keep again.
Unsurprisingly, I don't have a good name for this one either- I guess RPG MMO will suffice for now. It seems like it'll be the easiest one to get fully workable, and so I'll devote most of my time to it (despite having already started work on MGC).
We were going over the familiar complaint that, in 3.5e D&D, clerics simply make better fighters than the Fighter class does. The most probable reason for beefing up the cleric was that they wanted to make it a more attractive class- everyone who has put together a D&D party knows the pressure of "ok guys, we need a cleric." No one wants to play the support character when they could be playing a primary character, but the entire party will suffer if someone isn't the support character.
A very similar thing happens in MMOs, because the MMO group is very similar to a D&D group. Someone's got to be the priest. Some people enjoy it- and actually the only character I got to 60 in WoW was a priest. It was nice to always have a spot in groups or raids, but it got pretty boring after a while to be concerned solely with the party's HP.
My solution was to suggest giving everyone multiple characters. If you've got two slots, then devoting one of them to support is no problem- and I think a lot of people would prefer to have, essentially, a character worth 1.5 and a character worth .5 than two characters worth 1.
So what would happen if you gave everyone, instead of a character, a party? Most of the mechanics would work rather similarly- the primary difference is that it needs to be easy to control multiple characters. This can be done either through good AI (probably not; as mentioned before, the best AI available tends to be sub-par and I'm a far way from being able to afford the best AI possible) or by making combat turn-based.
Turn-based combat is easy to do in single-player games, and gets more troublesome in multiplayer games. Something has to be done to keep things moving (turn time limits and a preset default move if no orders are given in the time limit seems best), and unless players move simultaneously puts a soft cap on the number of players that can be in a party.
Speaking of parties, how would you combine adventuring groups well into the traditional MMO group? If there are synergies between different character types (which is the best way to do things) it becomes hard to optimize groups out of optimized subgroups; if you only need one paladin for the group of 9 people, if each subgroup has a paladin there will be a problem.
There are two main solutions: make it so synergies like that stack (i.e. 1 paladin and 1 death knight is only slightly better than 2 paladins or 2 death knights) or make it so each person has a stable of characters. You can only take out 3 or 4 people on adventures, but you have 6 others sitting back at the tavern, so that if the raid doesn't need your paladin you swap him out for your death knight.
The stable approach seems superior, in that it allows you to switch out characters without having to start the entire group over- if you decide that your group of fire mage, ice mage, and lightning mage really does need a meat shield, you don't need to create a new group to have that and level up the two mage types that you want to keep again.
Unsurprisingly, I don't have a good name for this one either- I guess RPG MMO will suffice for now. It seems like it'll be the easiest one to get fully workable, and so I'll devote most of my time to it (despite having already started work on MGC).
Civilization
The second idea doesn't have a name yet; I'm using MGC as a stand-in.
I've probably put more hours into the Civilization series (including Alpha Centauri) than any other game series (hmm, maybe not WoW), and that's probably true for anyone that likes empire-building games.
I don't know how much of Civ's success comes from its simplicity. As strange as that must sound to someone not familiar with the series or good at the games, they are remarkably simple- you only deal with a few resources, happiness exists solely as the face of the population cap, etc. The simplifications are almost always good simplifications- food, production, and commerce (or, as I think of them from SMAC, nutrients, minerals, and energy) are good ways to simply describe regions, and allow cities in different climes to have very different specializations.
But there's also a lot of important things that get glossed over. Why do the people in my lowland city, unhappy about the crowding, not leave and go to a city with more prospects? Why can't I transport food to hilly city, so I have more miners? Why, out of the twenty-one squares my city of 4 population controls, are only 5 producing resources?
Essentially, Civilization is a game of cities. This may make sense in Alpha Centauri, where cities are self-contained bases, but not in Civilization. History is not a story of cities. The entirety of Egypt should not be three cities- there might be three large population centers, but they should be settled throughout the entire river valley. Now, cities are certainly important, and should be the focus of history- but not the whole story.
On the most basic level, the change I'd like is to make a Civ clone that's, instead of a game of cities, a game of regions- the map could even look the same, but each square would have a population, production, etc.
There are other changes that I'd like to make that are more complicated- culture should be, instead of a number, a set of objects. French culture is a style of cooking, Les Miz, and the Eiffel Tower, not 6,766 in Paris and 354 in Marseilles.
One of the other things that I'd like to do is model population better. As mentioned before, people should move- when new land has opened up in America, you don't just wait for the settlers sent over from England to reproduce, more people buy boat tickets to get land. When Alexandria gets too crowded, people move upriver or elsewhere. When Gaul is taken over, slaves get sent back to Rome.
So, what's a good way to model population? Civilization does them as identical groups of 1,000 or 10,000 people, who, in some versions, have an ethnicity (so they can be unhappy when they're ruled by the wrong people). You can turn them into specialists (primarily in SMAC and Civ4, I don't remember much specialization in the other games but I may be misremembering), and they are either happy, neutral, or unhappy (talents, citizens, and drones in SMAC).
Ideally you'd model each individual person- what their profession is, what their wealth is, what specific cultural elements they like, their religious feelings, their political feelings, etc. A large number of people are the same, though- why not instead deal with representative individuals?
A region on the Nile could have 840 farmers, 100 craftsmen, 40 priests, and 20 nobility. Each would be represented by one or two people, who would have things like an age distribution, wealth distribution, income distribution, etc. A few clicks reveal that the farmers are dirt-poor and only produce 1.25 times the amount of food they require to survive, the industry is based around tailoring imported cloth and making statuettes of Hathor, and that the nobility own 20% of the land in the district. The clergy own the other 10%, and the remaining 70% is in the hand of the king (i.e., the player), worked by the peasantry.
When changes happen (some heretic introduces Set worship to the region), a few representative individuals might split into two- Bob represents the farmers that worship Hathor, Joe the farmers that worship Set. Since the clergy are all priests of Hathor, Joe is unhappy that his spiritual needs aren't satisfied. You order a temple erected, the clergy's religious distribution alters, and then Bob and Joe recombine (with a religious distribution) since their happiness levels are now the same (and you decided not to ostracize Set-worshipers).
But if you do decide that there should be religious intolerance against Set-worshipers, some will decide that it's best if they switch back to Hathor. Others will pack up and leave the region, heading to somewhere that appreciates them, and some might pick up pitchforks and storm your keep.
Another thing I'd like to see is a more realistic tech system- which seems like it's best modeled by random tech breakthroughs. You shouldn't be able to, at 4,000 BC, knowingly set yourself on the path that leads to nuclear fission- you should be able to say "ok, my king is giving extra support to innovators in nautical fields," and that leads to breakthroughs or not depending on fate and the populace you have. Throughout history, the vast majority of inventions have not been made by people whose job title was inventor- it was probably some porter who figured out how to make a wheelbarrow, some farmer who figured out how to irrigate crops, etc. Also, dealing with new technologies as objects makes it easier to deal with their transmission realistically- you don't discover refrigeration and suddenly all your ships have it; you discover refrigeration and it spreads from city to city, based on trade routes and the wealth of regions that it's spread into.
What's most likely is that first I'll go for just having something workable which deals with all regions separately, and then make it progressively more complex.
I've probably put more hours into the Civilization series (including Alpha Centauri) than any other game series (hmm, maybe not WoW), and that's probably true for anyone that likes empire-building games.
I don't know how much of Civ's success comes from its simplicity. As strange as that must sound to someone not familiar with the series or good at the games, they are remarkably simple- you only deal with a few resources, happiness exists solely as the face of the population cap, etc. The simplifications are almost always good simplifications- food, production, and commerce (or, as I think of them from SMAC, nutrients, minerals, and energy) are good ways to simply describe regions, and allow cities in different climes to have very different specializations.
But there's also a lot of important things that get glossed over. Why do the people in my lowland city, unhappy about the crowding, not leave and go to a city with more prospects? Why can't I transport food to hilly city, so I have more miners? Why, out of the twenty-one squares my city of 4 population controls, are only 5 producing resources?
Essentially, Civilization is a game of cities. This may make sense in Alpha Centauri, where cities are self-contained bases, but not in Civilization. History is not a story of cities. The entirety of Egypt should not be three cities- there might be three large population centers, but they should be settled throughout the entire river valley. Now, cities are certainly important, and should be the focus of history- but not the whole story.
On the most basic level, the change I'd like is to make a Civ clone that's, instead of a game of cities, a game of regions- the map could even look the same, but each square would have a population, production, etc.
There are other changes that I'd like to make that are more complicated- culture should be, instead of a number, a set of objects. French culture is a style of cooking, Les Miz, and the Eiffel Tower, not 6,766 in Paris and 354 in Marseilles.
One of the other things that I'd like to do is model population better. As mentioned before, people should move- when new land has opened up in America, you don't just wait for the settlers sent over from England to reproduce, more people buy boat tickets to get land. When Alexandria gets too crowded, people move upriver or elsewhere. When Gaul is taken over, slaves get sent back to Rome.
So, what's a good way to model population? Civilization does them as identical groups of 1,000 or 10,000 people, who, in some versions, have an ethnicity (so they can be unhappy when they're ruled by the wrong people). You can turn them into specialists (primarily in SMAC and Civ4, I don't remember much specialization in the other games but I may be misremembering), and they are either happy, neutral, or unhappy (talents, citizens, and drones in SMAC).
Ideally you'd model each individual person- what their profession is, what their wealth is, what specific cultural elements they like, their religious feelings, their political feelings, etc. A large number of people are the same, though- why not instead deal with representative individuals?
A region on the Nile could have 840 farmers, 100 craftsmen, 40 priests, and 20 nobility. Each would be represented by one or two people, who would have things like an age distribution, wealth distribution, income distribution, etc. A few clicks reveal that the farmers are dirt-poor and only produce 1.25 times the amount of food they require to survive, the industry is based around tailoring imported cloth and making statuettes of Hathor, and that the nobility own 20% of the land in the district. The clergy own the other 10%, and the remaining 70% is in the hand of the king (i.e., the player), worked by the peasantry.
When changes happen (some heretic introduces Set worship to the region), a few representative individuals might split into two- Bob represents the farmers that worship Hathor, Joe the farmers that worship Set. Since the clergy are all priests of Hathor, Joe is unhappy that his spiritual needs aren't satisfied. You order a temple erected, the clergy's religious distribution alters, and then Bob and Joe recombine (with a religious distribution) since their happiness levels are now the same (and you decided not to ostracize Set-worshipers).
But if you do decide that there should be religious intolerance against Set-worshipers, some will decide that it's best if they switch back to Hathor. Others will pack up and leave the region, heading to somewhere that appreciates them, and some might pick up pitchforks and storm your keep.
Another thing I'd like to see is a more realistic tech system- which seems like it's best modeled by random tech breakthroughs. You shouldn't be able to, at 4,000 BC, knowingly set yourself on the path that leads to nuclear fission- you should be able to say "ok, my king is giving extra support to innovators in nautical fields," and that leads to breakthroughs or not depending on fate and the populace you have. Throughout history, the vast majority of inventions have not been made by people whose job title was inventor- it was probably some porter who figured out how to make a wheelbarrow, some farmer who figured out how to irrigate crops, etc. Also, dealing with new technologies as objects makes it easier to deal with their transmission realistically- you don't discover refrigeration and suddenly all your ships have it; you discover refrigeration and it spreads from city to city, based on trade routes and the wealth of regions that it's spread into.
What's most likely is that first I'll go for just having something workable which deals with all regions separately, and then make it progressively more complex.
Noblesse
I'm horrible with names. The first game idea has the working name of Noblesse.
Civilization and Total War are probably the two largest influences on my view of computer gaming- aside from RPGs, they probably dominate my gaming time over the last few years. One thing that's always been lacking, though, is the dynastic politics that make European history so interesting (well, if you're into that sort of thing).
Feudalism, with its kings, dukes, and barons, is replaced by nearly omniscient gods directing mortal armies to destroy each other. It's nice to see games that openly acknowledge this, like Dominions 3, but that's making your game more honest, not more realistic.
So, let's talk about modeling politics in games, specifically an empire-building game. There are simple ways to do it and complex ways:
The simplest way is just percentage approval- what you see in Total War. You have a number of factors that influence how likely the peasants are to riot, of which the most important are religion, garrison size, and taxation level. It's a pretty hideous simplification, but it works- it rewards spreading your religion, it rewards having garrisons, and it requires you to invest in order to get higher tax levels (without spawning enemy armies).
But that's just dealing with peasants. What about local nobility? What makes them loyal to you, instead of defecting to neighborhood kingdoms? Historically, there was a significant difference between, say, ducal levies and royal levies, but most empire-building games ignore that for simplicity's sake.
So, the more complex ways involve simulating all of the power groups and how they interact. If you raise corn taxes, the nobles are happy but factory owners are unhappy, since that's the noble's revenue and the factory owner's expense.
Minor nobility also become more important- there are a number of battles where barons and their armies switched sides, betting they'd be better off with the new king than with the old one. Machiavelli discusses in The Prince the difference between a locally-governed and nationally-governed state; the locally-governed state is easy to take pieces out of, since there will be someone willing to open the door for you, but is hard to digest- the locals are attached more to the baron than the king, and if you try to replace the baron that betrayed his king for you, there's a strong chance he'll betray you. The nationally-governed state is difficult to conquer, since you fight the unified might of the state; but once taken, everything quickly falls into place since who is at top was already easy to change.
The problem with nobility is that they're harder to model well than power groups. Power groups can be predicted fairly reliably because of their composition- the clergy chose to be clergy, and all face similar problems and have similar desires (with respect to the things that make them clergy, at least). It's also difficult to make good AI, especially if I'm running a one or few man show- AI designed by multiple people who have been working in the field for over a decade can still be hideously simplistic, and is beaten trivially by a human who knows what they're doing. If the game centers around politics, there needs to be a way to make the politics real.
So, why resort to artificial intelligence? You can get real intelligence easily enough. There are already hosts of multiplayer empire-building games- it shouldn't be that hard to make one where there are multiple levels of nobility that interact. Higher rank nobles get to tax everyone below them, raise armies using royal funds, and set policy for the kingdom (which the lower nobility can flaunt at their risk), and everyone controls some small segment of the world, building things and such. The games I talked about tend to already have systems like this- Battledawn gives you a percentage of the income of everyone you've conquered, but doesn't have a hierarchy (either you're a conqueror or you're conquered- there's no tree) and is fairly simplistic.
Essentially, a "build a nation, conquer the world" clone with a lot more emphasis on politics. It brings to mind this- it's more fun to be the emperor taking over Europe than it is to deal with politics, but games based around politics instead of just strategy (Diplomacy, for example) have their niche.
Civilization and Total War are probably the two largest influences on my view of computer gaming- aside from RPGs, they probably dominate my gaming time over the last few years. One thing that's always been lacking, though, is the dynastic politics that make European history so interesting (well, if you're into that sort of thing).
Feudalism, with its kings, dukes, and barons, is replaced by nearly omniscient gods directing mortal armies to destroy each other. It's nice to see games that openly acknowledge this, like Dominions 3, but that's making your game more honest, not more realistic.
So, let's talk about modeling politics in games, specifically an empire-building game. There are simple ways to do it and complex ways:
The simplest way is just percentage approval- what you see in Total War. You have a number of factors that influence how likely the peasants are to riot, of which the most important are religion, garrison size, and taxation level. It's a pretty hideous simplification, but it works- it rewards spreading your religion, it rewards having garrisons, and it requires you to invest in order to get higher tax levels (without spawning enemy armies).
But that's just dealing with peasants. What about local nobility? What makes them loyal to you, instead of defecting to neighborhood kingdoms? Historically, there was a significant difference between, say, ducal levies and royal levies, but most empire-building games ignore that for simplicity's sake.
So, the more complex ways involve simulating all of the power groups and how they interact. If you raise corn taxes, the nobles are happy but factory owners are unhappy, since that's the noble's revenue and the factory owner's expense.
Minor nobility also become more important- there are a number of battles where barons and their armies switched sides, betting they'd be better off with the new king than with the old one. Machiavelli discusses in The Prince the difference between a locally-governed and nationally-governed state; the locally-governed state is easy to take pieces out of, since there will be someone willing to open the door for you, but is hard to digest- the locals are attached more to the baron than the king, and if you try to replace the baron that betrayed his king for you, there's a strong chance he'll betray you. The nationally-governed state is difficult to conquer, since you fight the unified might of the state; but once taken, everything quickly falls into place since who is at top was already easy to change.
The problem with nobility is that they're harder to model well than power groups. Power groups can be predicted fairly reliably because of their composition- the clergy chose to be clergy, and all face similar problems and have similar desires (with respect to the things that make them clergy, at least). It's also difficult to make good AI, especially if I'm running a one or few man show- AI designed by multiple people who have been working in the field for over a decade can still be hideously simplistic, and is beaten trivially by a human who knows what they're doing. If the game centers around politics, there needs to be a way to make the politics real.
So, why resort to artificial intelligence? You can get real intelligence easily enough. There are already hosts of multiplayer empire-building games- it shouldn't be that hard to make one where there are multiple levels of nobility that interact. Higher rank nobles get to tax everyone below them, raise armies using royal funds, and set policy for the kingdom (which the lower nobility can flaunt at their risk), and everyone controls some small segment of the world, building things and such. The games I talked about tend to already have systems like this- Battledawn gives you a percentage of the income of everyone you've conquered, but doesn't have a hierarchy (either you're a conqueror or you're conquered- there's no tree) and is fairly simplistic.
Essentially, a "build a nation, conquer the world" clone with a lot more emphasis on politics. It brings to mind this- it's more fun to be the emperor taking over Europe than it is to deal with politics, but games based around politics instead of just strategy (Diplomacy, for example) have their niche.
First!
So, a bit of background. I play a lot of games- computer, console, board, card, pen-and-paper, etc. I tend to analyze things quite a bit, and so that led to an early interest in game theory and game design- what makes backgammon different from chess? Is there a way to make backgammon less reliant on randomness, or is the randomness a good thing? What would make Civilization more realistic? What would make it more fun? Where do the two coincide, and more importantly, where do they not coincide? What sort of dungeons make a game of D&D fun? What sort of combat systems make a game of D&D fun? Are players satisfied by a cinematic boss fight, or do there need to be mooks beforehand? What specifically makes mass battles such a bad plan?
I'm making this blog as both an attempt to get feedback on my ideas and to keep myself honest. I can't count the number of projects I've started and never finished- hopefully keeping a public log of the work I'm doing and advertising it will make me less likely to abandon ideas after a bit of consideration.
At the moment, I've got three ideas, which I'll explain in the next three posts.
I'm making this blog as both an attempt to get feedback on my ideas and to keep myself honest. I can't count the number of projects I've started and never finished- hopefully keeping a public log of the work I'm doing and advertising it will make me less likely to abandon ideas after a bit of consideration.
At the moment, I've got three ideas, which I'll explain in the next three posts.
Subscribe to:
Comments (Atom)