Honestly, I'm not sure this is *quite* the forum for this, because while it's about the Pathfinder RPG, it's also about the application of programming to that RPG. Or maybe vice versa. Anyhow, if a mod decides this isn't the right place, I'd appreciate a move. Also, from a legal perspective... my understanding is that you can create a computer game that uses the OGL elements of the Pathfinder RPG, as long as you meet the legal requirements involved - including a copy of the OGL itself, not using Product Identity or Trademarks (including indication of compatibility), and clearly identifying which portions are OGL.
I have been thinking for a long time how I'd implement some of the rules of the game as an object oriented computer program, but I'm not a very experienced programmer, and one of the things that has been bugging me is class levels. This has been made worse by the inclusion of archetypes.
Possibly the best way to do it would be to treat each class level as a kind of template that added features to a character. Each level would be a separate template.
So, for example, a Barbarian 1 template would add a d12 hit dice, toggle a number of skills as "class skills", add 4+Int skill ranks, add 1 to the BAB, 2 to the Fort Save, and grant the "Fast movement" and "Rage" powers. It would require a nonlawful alignment and an Int Score of 3. The Barbarian 2 template would be very similar, adding hit dice and skills, increasing BAB and Fort by 1 each, and adding a rage power and uncanny dodge. It would require the Barbarian 1 template to already be applied.
Now, I think this would work just fine, allowing for multiclassing and single classing with ease. The problem comes in with archetypes. You don't want to allow someone access to both Barbarian 1 and Invulnerable Rager 1. You could simply make each of them require the lack of the other, but this approach sets up a LOT of requirements - you'd essentially have to treat each archetype (and combination of archetypes!) as a separate class, with a multitude of checks to make sure none of these classes could be taken concurrently. You'd also be duplicating a lot of material, since some archetypes do not change the base class all that much, with many levels being identical.
Perhaps a better solution would be to only create those levels that were different, but then you'd have to create even more built in checks - making sure that someone who took a level in an archetype would take all further archetype levels that came after.
Then you have problems like Domain or Bloodline selection. A cleric with the Travel domain is almost a different class than a cleric with the War domain, and the fact that they get two domains complicates the issue more. Do you develop a cleric class for every combination of domains? That will get very tedious, very quickly. Perhaps one option would be to treat Domains as templates in a similar manner?
Anyway, just looking for some thoughts on this. Are there some options that might be better that people can think of?
I like that, my only problem with it is that if you put the entire class into a single object, you'll need some internal way to tell what abilities get accessed at what levels. I can't just have a character inherit the whole of barbarian on his first level. If I divide it up by level, though, I'm not just checking to make sure there's only one instantiation of Barbarian per character, I'm making sure there's only one per level per character.
|
| 1 person marked this as a favorite. |
I don't think there's enough commonality in what gets added on a level gain to try and write one thing that encompasses all the possibilities - I think you're better off having each level of each character be a separate object type (with a few elements & data types, etc., to deal with the few things that are pretty much the same across all classes).
So a 2nd-level Barbarian extends (or subclasses) a 1st-level Barbarian by adding things.
And a 1st-level Barbarian extends a 0th-level Character by adding the basic Barbarian things, a 1st-level Cleric extends a 0th-level Character by adding basic Cleric things, ... (or, more likely, 1st-level Cleric extends 0th-level Divine Caster, which extends 0th-level Character).
You can't add a 2nd-level Barbarian directly to a Character - you have to add a 1st-level Barbarian as well.
It's a little complicated to calculate the cross-class things like total character level, hit points, etc., but it's not impossible.
Java isn't an ideal language to use, though - you really want a language where multiple inheritance was designed in from day one, or you're going to have a lot of problems with classes like Mystic Theurge.
Truthfully, I wanted to keep the discussion language neutral but you are right - possible issues of multiple inheritance may require settling on one. I personally favor C++ over Java, which at least gives me the option of multiple inheritance if that's the best way to do it.
That said, do I even want to use classes as classes in the first place? A character class isn't exactly an object, its more of a property. I don't want to create a "cleric", I want to create a "character" that can be modified into a cleric.
Maybe I'm wrong, but I don't think you can build classes during run time that inherit just the right combination.
I suppose what you could do is give characters an internal class array, and as they increase in levels, create a new instance of the char_class object that are added to the array.
So for example, Billy the 0th-level character is being freshly made. The player chooses Barbarian. Now, we create a new char_barbarian_1 object, and add it to player_Billy's profession_list. However, this still wouldn't give class functionality to player_Billy, you'd have to reference it indirectly through the char_barbarian_1 object belonging to Billy.
Hmm, might be useful to call "character classes" something like "professions" to help ease confusion in the discussion.
|
|
Also, from a legal perspective... my understanding is that you can create a computer game that uses the OGL elements of the Pathfinder RPG, as long as you meet the legal requirements involved - including a copy of the OGL itself, not using Product Identity or Trademarks (including indication of compatibility), and clearly identifying which portions are OGL.
I'd double-check on that, assuming you're making this for anything other than your own use. After all, Paiz themselves (OK, Goblinworks) aren't even using the system for their own game.
|
| 1 person marked this as a favorite. |
Hmm, might be useful to call "character classes" something like "professions" to help ease confusion in the discussion.
You'll have lots of overlapping terminology like this. Great fun :P
But if you look at it, RPGs are pretty object oriented themselves; lots of discrete objects (characters, monsters, equipments) with methods (class abilities, spells) and a great deal of inheritance (creature types, templates). So OO is a good paradigm for this, but it also means that terminology clashes are inherent to the exercise.
Because you can combine multiple archetypes on a single class, you're either stuck with multiple inheritance, or creating separate child classes for every archetype combination in a class. Pick your poison.
You could give a character a list of flags for all class abilities, and flag them to true/false/higher values depending on class level combinations, like adding up levels of classes giving Uncanny Dodge.
| 1 person marked this as a favorite. |
Having put a lot of thought-time into these exact problems, the best conclusion I've come up with is each "thing" needs to be an effect. To get a little more specific, the traits level 2 grants you is just a series of effects. You gain an effect that may increase your BAB by x, increases your 6th daily spell slot by 1, grants you abilities per your class, etc. This framework can work across the board. Feats are also applied via effects, spells, etc.
This is because pathfinder is a very fluidic system. This is because most effects override other effects and grant things like saves to effects that say they don't get saves. Each release of content also often times contains rules that say basically 'yeah that's true but let's do something different in xyz conditions' so for the sake of maintainability this is simply easier. Especially concerning errata, instead of need to retool your structure for templates you simply modify the base effects and those changes will bubble up in the final result a user sees.
So, when you're viewing a character, you've got your base stats and type, a.k.a. "race," then everything else is dynamically applied in real time when you view the character. This architecture can be used in a simple character manager type application or even a game.
| 1 person marked this as a favorite. |
I haven't had much time to think on this, but the concept had me brainstorming a bit.
First off, I'd separate class abilities into their own distinct class. This is because some class abilities are actually shared, such as Uncanny Dodge, and you don't need to pigeon hole yourself by giving too much power to the "Character Class" class.
Also, class abilities increase in power individually. Sneak attack constantly grows and at different rates depending upon the character class. This is another great reason to keep most of the logic of application set into the class ability class.
I would recommend the decorator pattern for this.
Also, some class abilities work off of character level, caster level, class level, or even character ability scores (such as Charisma + 3 times per day). This means that they will need to either be concrete classes with reference pointers to their character, or abstract classes that are passed a character reference when asked to "apply" themselves to an attack. Either way works. I personally favor the concrete classes in order to fully work more in tune with the decorator pattern.
If you truly wanted to, you could use the composite pattern on class abilities to support times per day or other shared and common logic. Also, the decorator problem will help you with class abilities that need descriptors. Descriptors will help you handle how odd effects will change the functionality, such as Plant Shape II will certainly remove access to your claws. In this example, you can keep a list of descriptors such as "Hands", and every affect that removes "Hands" will temporarily terminate the ability.
Now, moving onward, a character class itself needs to be nothing more than a list of class abilities that get "applied" as you level. Most of the logic being removed and placed upon class abilities, a character class then is mostly a manager of a class ability list. Nothing more. This means that you only need one class to handle all 20 (or less) levels of a particular class as it would use a map or dictionary to link levels to class ability access.
This will work very well with archetypes. An archetype now only needs to inherit the bass character class and simply change the class ability list appropriately and you're done.
I have other thoughts on non-leveling structures, but for now this is what you were asking for so I'll keep it short and stop.
| 1 person marked this as a favorite. |
Since I've missed the edit window on my above post I'm making this new post. Let me clarify what I mean by an effect.
An effect would be an abstract object that simply takes a target object, provides a linq expression (from the .net world) and apply/remove methods.
Children objects would define what each expression means while generally leaving the target open unless that was necessary for the effect in question.
As these are added to a character, a delta is assigned to represent its placement in a FILO type list for the character in question. Then, a character would have this effect list ordered by that delta. At run time your code would loop through this list and call the apply method on each effect.
+1 to Imper1um. Dictionaries are just the way to go...
Have you given much thought to Python...I know it is probably not the most favored among people, but for quickly banging out a prototype it is too good. Plus you can make dictionaries of dictionaries, so for example:
class Ddict(dict):
def __init__(self, default=None):
self.default = default
def __getitem__(self, key):
if not self.has_key(key):
self[key] = self.default()
return dict.__getitem__(self, key)
pfsClass = Ddict(dict)
pfsClass['Barbarian']['Abilities'] = "Rage"
pfsClass['Rogue']['Abilities'] = "Sneak Attack"
pfsClass['Paladin']['Abilities'] = "Smite"
>>pfsClass
{'Barbarian': {'Abilities': 'Rage'}, 'Rogue': {'Abilities': 'Sneak Attack'}, 'Paladin': {'Abilities': 'Smite'}}
**EDIT**
At which point then you can do some simple IF statements based on level number to decide of the abilties dictionary gets appended to.
Secondly, I would recommend focusing on CORE first. Build out your concept for how to handle classes and leveling based off of CORE. Once you've got that figured out, archetypes should just basically be handled as another class.
|
Also, from a legal perspective... my understanding is that you can create a computer game that uses the OGL elements of the Pathfinder RPG, as long as you meet the legal requirements involved - including a copy of the OGL itself, not using Product Identity or Trademarks (including indication of compatibility), and clearly identifying which portions are OGL.I'd double-check on that, assuming you're making this for anything other than your own use. After all, Paiz themselves (OK, Goblinworks) aren't even using the system for their own game.
WotC licensed the ability to create computer games solely to Atari. I don't know how that applies to the OGL (it was definitely true of the d20 license). As Kthulhu points out, the fact that PFO isn't using any OGL mechanics is probably a clue that either you can't make a video game, or that it's too risky from a legal standpoint.
-Skeld
Also, from a legal perspective... my understanding is that you can create a computer game that uses the OGL elements of the Pathfinder RPG, as long as you meet the legal requirements involved - including a copy of the OGL itself, not using Product Identity or Trademarks (including indication of compatibility), and clearly identifying which portions are OGL.I'd double-check on that, assuming you're making this for anything other than your own use. After all, Paiz themselves (OK, Goblinworks) aren't even using the system for their own game.
I think Goblinworks is doing that because the PFRPG system doesn't provide what they are looking for in their game, which is supposed to encompass more than just adventurers.
And believe me, I fully intend to consult a lawyer if I ever decide to make this publicly available. I'm actually thinking of doing this in three parts. Part 1 would be to develop a rules library that describes most of the system, but leaves out functionality (for example, it could derive a character's attack bonus but not tell you how to use it). This library would be Open Source (but possibly not GPL, because of Part 2), and could be used in a variety of programs from VTTs to character builders to varying types of game engines. Part 2 would be to develop a game engine, probably proprietary, that used the above rules library. There would also be a campaign maker kind of utility. Rather than having a built in campaign, the game engine would load modules made from the campaign maker. Finally, Part 3 would be to make and sell the modules, which is where the revenue stream from this project would come from. Sort of taking a leaf from Paizo's book of business models, the game engine is freely usable and people can make their own content and never pay me a dime, but hopefully the quality of products makes them want to.
It's like having the entire game be downloadable content, but allows people to write their own DLCs and distribute them. Might even offer a hosting system where users can sell modules they have made.
But that's getting far afield.
GrenMeera, decorator classes definitely seem like the way to handle this!
Edit: Wow, lots of new stuff while I was typing, lol! I'm not a professional programmer so I'll have to do more research - I have never heard of a dictionary in a programming context before. I'd rather not use Python, I already know a fair bit of C++ and am open to languages using a similar syntax (Java, C#), but I don't want to have to put too much time into learning a new language. I have little enough as it is. (Basically, my Saturdays are devoted to PF and my Sundays are for programming, and the rest of the week is for Economics.)
Yes you want to access things in databases. In a way, this goes without saying. However I would like to add that a database is a very generic term and need not be a high level language such as SQL.
I say this mainly because, in the game production world, you protect your IP by writing your own custom database. It's not like Knights of the Old Republic or Dragon Age data can be found in a SQL server while the game is running. Trust me when I say that they have databases, but it is always part of some obfuscated DLL. Aside from protecting your IP, it's almost necessary if you plan on protecting against hacks/cracks that break the game.
Also, the databases are being used to reference your class abilities, classes, feats, knacks, etc. This can all be done with dictionaries, which I also thought goes without saying. However, since you said you are a bit unfamiliar with them and prefer C++, take a look first at stl::map (or a boost equivalent).
I agree with Buri in that most of the core logic of changing a character should be at the low level end of "effects" (class abilities, feats, knacks). I still maintain that the decorator pattern is the best implementation, using the character class as a mediator to the application of character data itself.
Hard coding, like everything else in programming, has it's place depending on the context. Constants are definitely handy and when things like certain memory addresses are attempted to be reassigned exceptions should be thrown.
Agreed, but a little beyond the scope of this thread. Anybody have some good best practices links?
http://msdn.microsoft.com/en-us/practices/bb190332.aspx
I agree that a database is the way to go.
Don't make a character class a programming class.
A character is a class (with an array of levels, and some derived values). Each level is really just a reference to a database entry.
There should be a Class table; this references all the things that are core to the class; HD, Skill Points, Class Skills, and I would even put in BAB, Fort, Ref, Will (with another table to determine how those increase at given levels).
Another ClassLevel table shows what features the class gets; these reference another table with the actual ability descriptions.
Archetype should be a table, which lists what class each archetype is for, and what features it modifies. A simple (if tedious) algorithm can then determine compatible archetypes. And ArchetypeLevels would also exist.
Building the character would involve reading a lot of different tables in the database (which is why there'll be so many derived values), but this way, a new product involves no code changes, just database updates.
I'm seeing a trend here that I'd like to comment upon. Essentially, I've been project manager on multiple released video games and I almost feel like I need to throw on my manager hat for a moment.
Databases are not code. They are a storage qualifier. They are a method for data retrieval. Yes, there are programming languages for setting up a database, but that's not my point. Logic and algorithm design are actually independent problems from data storage, despite the fact that you should design your data storage to quickly reflect easy serialization.
The question that was posed is about rule implementation and class architecture. Let's try to keep that in mind, because saying "put it in a database" doesn't actually solve the core problems being addressed any more than "load it from a file" does. I agree that most of the information should be set aside in a custom non-SQL database, but you need to design your program work flow long before you start setting up your loaded databases.
Class hierarchy and algorithms should always come before data storage. We're losing focus.
If I had the authority I'd make a stance to start supplying UML diagrams just to enforce policy on design at this point, but since I don't have that authority... I'll... makes myself a sandwich.
Don't make a character class a programming class.
I'd like to disagree on this simply because of two simple things.
Multi-classing means that an 'n' number of possible level tables must exist and therefore might as well be managed by an intermediate piece of logic, even if it doesn't do much work itself, it's organized.
Secondly, the top level class (which in this example is the Player in all it's glory) can easily become bloated. If you can separate one of its jobs into another class, then you should most likely do so. Almost all structural design patterns are meant to solve this very issue in different ways.
Perhaps this is because I'm not a database guy but I do not see a database as the primary holder of logic to be desirable due to the varying kinds and ways stats may be modified. To create a model that can uniformly and easily describe every feat, spell, class feature and item would be maddening to me. After this, if Paizo releases something that fundamentally breaks the model then there's a lot of re-engineering that needs to take place.
However, if you use code apart from a database that can easily understand things like OOP principals that can dynamically shift things around then that is much easier for me to implement.
I agree a database should be the primary store of what an effect is but also believe that it can only do so in a very abstract way that can be more easily parsed and understood in a code environment.
I think the database should hold the data, and no logic.
A Character object should be able to handle figuring out the character's stats from the combination of his class levels (and the base stats that have nothing to do with class). I can see value to a Level object, of which a Character has an array. But that Level object should be generic; I don't think there should be a BarbarianLevel that subclasses Level, and a BarbarianLevel1, BarbarianLevel2, etc. Just a Level, which reads off a database, file, whatever, for the values of its properties.
I suppose you could structure it, instead, as:
A Character has 1 or more Classes, each of which has a property of classLevel. CharacterLevel is sum of ClassLevels.
That way a barbarian 3 is a Character with an instance of the BarbarianClass in his classes array, and the classLevel on that is 3.
I feel like just having an array of levels is a better fit than having an array of classes, which each have their level specified. But I can see it either way; I'd have to do some more thinking to see which would end up better in the long run.
|
|
Both the database and the logic are important components, and both need to be designed to fit the problem.
If the database schema satisfies the golden rule of database design (don't have two almost-but-not-quite identical copies of the same data), and has relationship and access capabilities that match the demands of the program logic, you've made considerable progress on the design.
I don't have much programming experience, but I think I would sort out archetypes by creating an Nx2 array for base class features. The first column would be the name of the feature, and the second column would be all ones. When adding an archetype to a class, I would have the program check for a one in all of the appropriate class features, and then change the class feature name and overwrite the one with a zero. That's the most straightforward way I can think of to prevent multiple archetypes that modify the same class feature.
Then you would have an array of class feature names that also tells you which entries are still available for swapping out via archetypes.
I have no idea how useful or efficient this approach would be, since my programming experience is limited to fortran, matlab, C, verilog hdl, and a bit of unrealscript. Most of these aren't object oriented.
I had a similar thought (and C# is also my language), but I'd do it slightly differently (aside from naming conventions - ugh). See the bolded sections below. Apologies to any non-coders for whom the changes don't mean anything.
I'm a programmer in C#, so thinking in code, here's a few things:
public class PFCharacter {
private List<PFClassLevel> mClassLevels;
}public abstract class PFClass {
protected abstract string mName;
protected abstract int mMaximumClassLevel;
protected abstract List<PFSkill> mClassSkills;
protected abstract List<PFAbility> mAbilities;
protected abstract int mHitDice;
protected abstract int mSkillPointsPerLevel;
}public class PFBaseClass : PFClass {
protected overrides int mMaximumClassLevel = 20;
private List<PFArchetype> mArchetypes;
}public class PFPrestigeClass : PFClass {
protected overrides int mMaximumClassLevel = 10;
private List<PFRequirements> mRequirements;
public class PFArchetype {
private string mName;
private Dictionary<PFAbility, PFAbility> mReplacementAbilities;
private List<PFSkill> mAddClassSkills;
private List<PFSkill> mRemoveClassSkills;
}public abstract class PFAbility {
private string mName;
private int mLevel;
private PFAbility mReplacementAbility;public abstract void ApplyToCharacter(PFCharacter character) {}
}public class PFClassLevel {
public int mLevel;
public Dictionary<PFSkill, int> mSkillLevels;
}You get the point, but, yeah, that's the general concept how I would do it. Needless to say its missing a lot, but I don't have enough energy to iterate all the concepts.
Bobson, actually that's very similar to what I was talking about.
The only difference being that I'd make your PFArchetype class derive from PFClass and remove the name and class skills variables. This makes it so that all objects that you can level in have the same abstract base class. This will come in handy for both data storage (databases) and for any management/factory singleton classes you use to present the choices to the player.
A little work turning the PFCharacter and PFAbility classes into a decorator pattern and this is the general idea.
I'd probably alter the PFClassLevel class a fair amount, particularly since you don't reference which class you are leveling in any way from the character down. I'm actually a bit uncertain what you're using this class for, so I'll stop commenting on it there.
In any case, this is also missing a "rolled HP" for each level you've gained as well, but I'm sure you left the HP and other stats out of the PFCharacter for simplicity anyway.
I'd also use a Dictionary of Lists instead of a List for Abilities in PFClass since they should reference at which level they are acquired.
Well, those are my first pass design critiques. All in all I still think most of that is the correct idea, which is what inspired me to comment.
Maybe instead of trying to emulate something existing like Pathfinder, you should just start from ground zero and make an original game using this approach.
Nothing says you can't decide to "evolve" in a direction that looks like Pathfinder, but it would be interesting to see what you come up with if you don't feel hobbled by turning all the text of this game into code structures.
Lol, but that's part of the challenge!
That, and I have seen way too much Open Source software that suffers from a "permanent alpha" status. Once it becomes "playable" many of the developers turn to creating neat features and options rather than fixing some of the core faults that keep it from being a finished game. By chaining this to a given rule set, it keeps things on track. First you implement CRB and Bestiary. Then you implement APG, then UM, then UC. You don't move on to the next step until you have fully implemented the previous. Heck, the only reason I'm thinking about archetypes at this point is because I'm trying to think ahead, and it may be the best way to implement things like sorcerer bloodlines, wizard schools, and cleric domains.
Bobson, actually that's very similar to what I was talking about.
The only difference being that I'd make your PFArchetype class derive from PFClass and remove the name and class skills variables. This makes it so that all objects that you can level in have the same abstract base class. This will come in handy for both data storage (databases) and for any management/factory singleton classes you use to present the choices to the player.
A little work turning the PFCharacter and PFAbility classes into a decorator pattern and this is the general idea.
I'd probably alter the PFClassLevel class a fair amount, particularly since you don't reference which class you are leveling in any way from the character down. I'm actually a bit uncertain what you're using this class for, so I'll stop commenting on it there.
In any case, this is also missing a "rolled HP" for each level you've gained as well, but I'm sure you left the HP and other stats out of the PFCharacter for simplicity anyway.
I'd also use a Dictionary of Lists instead of a List for Abilities in PFClass since they should reference at which level they are acquired.
Well, those are my first pass design critiques. All in all I still think most of that is the correct idea, which is what inspired me to comment.
Yeah, I'd probably have structured it a little different (and chosen a different naming convention) if I were writing it from scratch, but it's still Imper1um's implementation at heart. He had the right idea, I just expanded on it in turn. I'll note that PFClass is useless in the current implementation - it and its subclasses are not actually referenced by PFClassLevel or PFCharacter.
-------
Really, the fundamental question is whether a character's core is a list of classes (regardless of the question of whether it's a List<> or something else) with some indication of how many levels are taken in it, or whether it's a list of class levels, which also happen to also be organized in a list on a class object.
For the non coders, it's the difference between referring to a character as a Barbarian 3 / Fighter 2, and by saying "Barbarian, Barbarian, Fighter, Barbarian, Fighter".
1. Don't make PFClass Abstract. Every class conforms to the same rules. some may have requirements (Need to add public List<PFRequirement> to the properties), but hardcoding each class is a no-no.-snip-
The two are not connected. You can have a PFBaseClass and a PFPrestigeClass without hardcoding a sub-class of those for each class. But while they share most functionality, base classes have things prestige classes don't and vice versa. That's practically the definition of a base class with two subclasses. Then each base and prestige class is an instance of the appropriate class, populated with different values from whatever your data store is (XML, database, or hardcoded).
Basically, having "class PFBarbarianBaseClass : PFBaseClass { public int HD = 12; }" is bad, but "PFBaseClass barbarian = new PFBaseClass { HD = 12 }" is acceptable (although not ideal).
2. Don't change mReplacementAbilities into a Dictionary<PFAbility, PFAbility>, class PFAbility has the mReplacementAbility property to give when it is replacing another ability.
I was wondering what that was for, and I still don't quite get it. Are you saying that each ability should know what its replacement is? What do you put in that spot when you have a PFAbility in the class? And why would you even care what the replaced ability is once it's replaced? For that matter, why should a vivisectionist's sneak attack (which would be "Bombs(replaced by sneak attack)" under your model, if I'm understanding it right) be any different from a rogue's (which would just be "Sneak attack(replaced by nothing)"). It makes much more sense to pull that information out of the ability and store it as part of the archetype.
You look up the ability from the base class, and check to see if it's a key in any dictionaries for any archetypes you have. If so, add the replacement to the character, if not, add the ability to the character.