Character Generation [technical/theoretical]

[Davin]

Davin: thanks for the information on OpenCyc--it looks like an incredible project! And wonderful, too, that it's (at least partially) open-source. I think it is definately an avenue to consider.

Yep - and their web presentation doesn't really do the engine justice, either. I've seen TV specials and other such things about it in the past and it's pretty phenomenal what it's doing under the covers.

I want to consider to investigate other avenues as well, though, because I hope to compare various approaches and find those that are most appropriate to this problem. The KB approach, though very generic, may not be the best way to model entity generation. I definitely need to read more about it, but because of the non-deterministic nature of entity generation (especially random generation) I have to wonder how well a KB would do in this case. It may be that the KB would be only one component of a successful generator, perhaps performing the validation of generated entities. Like I said, I need to do more reading.

Please do - you may find all sorts of other options out there.

But keep in mind that the KB by itself isn't the whole job -- you still have to wrap an application around it. But I can think of lots of ways the KB will do work for you. For instance, you can describe in it not only that AC is dependent on DexMod which is dependent on Dex, but how "valuable" that AC is to you in the end result and how that importance varies depending on how many hit points you have or what class you choose to be. It also has a built-in math-reasoning sub-engine, so it wouldn't surprise me at all to find it could do the random numbers for you. So you might just describe a "character" (or whatever) to it, give it some starting parameters (for things you wanted to select) and let it come up with some partially-random answers for you to fill out the rest.

If anyone else would like to be involved in these discussions (active involvement only, please -- no lurking), please e-mail me.

I'd love to play around in this area, but I'm already dealing with negative time in my life as it is, so alas I won't have any extra time to contribute (beyond throwing in my 2cp occasionally). So I guess I'll have to decline to participate this time. But please keep us informed here occasionally on your progress!

(on an unrelated side note: we let our 8-month-old son play with a percentile die the other day, and he managed to fit the entire thing in his mouth...it was quite a task getting it out again! so, parents, beware: percentile dice may not be the best toy for your infants...)

Well, silly! Of course not! He's not old enough to handle a whole percentile dice yet! Ya gotta start him off slow, with 4-sided's and 6-sided's. He's probably old enough to handle 8-sided's now too.

 

[Archimedes]

I agree, the rules definition would have to contain all the dependencies. The question is, how? Dependency information is often not explicit when rules are defined. Example: the Timeless Body feature of monks and druids in d20/3E. Say you have a monk who is already middle-aged (and hence has suffered aging penalties) when he reaches high enough level to gain this feature. All three of his physical ability scores are affected, but only indirectly, because the feature doesn't change the ability scores themselves, it just changes the way ability scores are changed by aging; the program has to be smart enough to spot this and go back and re-calculate the new aging effects (or non-effects, in this case) without an explicit dependency on the item that was just added. (This example is interesting to me because it's one of the bugs I've observed in E-Tools, and I'm wondering if the above is the reason why it wasn't caught.) Again, nothing here that isn't do-able, but it does add complexity.

Yes, a rule that modifies a rule. That’s not the only one, as you’ll find more like that in the splat books. You can have stats depending on rules that depend on other rules.

For building character generators, I’d use a programming language that treats methods as first class objects. In such languages you can replace the methods of individual instances on the fly. For example; switching out how aging works based on some other change. Of course, I think we’re still keeping with this having to be data driven.

Yes, it’s complex, but it could get worse. It’s not obvious to me how anyone would handle a situation like this in Java without resorting to a long parade of conditional statements, one of the things I’d most want to avoid when writing something like a data driven character generator. Peter, what language are you programming this in?

I was talking about more or less what Dee was talking about--deleting an item from a character (her example was deleting the elf race after having made other changes that are triggered by the character being an elf). The program would have to be able to spot that deleting "elf" should undo everything that was done when "elf" was added, or else the character becomes potentially inconsistent with the rules.

Peter Donis

Yes, a program would have to spot something like changing your race back to ‘None’ or to some race other than “elf”. The Observer pattern can be made to cover this or most other cases where you need to keep coupling loose but communications open.

Now, removing “elf” from the database (whatever form that database may take) and thus from the rules of the game entirely without going through the program is a whole other matter. I’d prefer for the program to throw an error in that case and warn the user that they’ve ruined the underlying data.

Sam

 

[Archimedes]

The 'knowledgeable user' would just then rank definitions that were automatically selected as usable by the batch test program rather than write definitions.
Of course, and before, he would have to write the selection criteria.

I was rather fuzzy when talking about using a genetic algorithm approach (idea introduced by Davin). I think (haven't measured) it would be easier for a 'knowledgeable user' to write a basic constraint test and then separate good performing definitions from sufficient performing definitions.

(I stop writing about this subject, I have to take my morning coffee)

We’ve got to be talking about two different things. I was taking ‘definition’ to mean the game rules used to construct the character. Perhaps your ‘definition’ was referring to procedures to randomly generate those characters. In that case, I can see what you’re getting at.

Sam

 

[Brent]

I'll have to reread this thread a bit slower to really give it the thought it requires. Although I am a programer, I work in the Finance Department. I do business modeling. What you are talking about has some similarities.

I take all of the data I can get my hands on and present it to executives who are not always very technical. They are then able to perform various what-ifs and see what the end result is. A well designed program should allow the user to be able to change any attribute they want in what ever way they desire and still provide a realistic result.

As I said, I have to give this some more thought. I can say that my solutions are data-driven, but I will warn you that this type of modelling requires a lot of resources.

 

[Firzair]

I'm on it, too

Hi everybody,
I'm currently trying to accomplish just this: a program that could handle D&D, Rolemaster, GURPS and all others.
I'm working on the framework for it, the rules will all be in the database.
Objects are defined by attributes which have a number of attributes by themselves (like type, calculated etc.) and every item has rules and prerequisites (optional).
So the idea is (short example):
- You define race and its attributes
- You define Creature where one attribute is race
- You define Party which is a set of Creatures and some more attributes
Later on perhaps you define a house which has occupants (Creatures) and so on...
As all data is parsed you could just enter a new data and it's automaticly active. For generation, the program would go by the rules entered, so perhaps you entered a new skill and it's rules, a newly generated character and all existing characters can use it.

One part which bothers me especially is the language of the data. I designed the program for being able to relabel all data without changing the rules or the internal names. So somebody designed some feats in english, I import them and just rename them and change the displayed description (the original description would be saved) and can use them in my native language without much hazzle.
I realized there are many players out there who can't speak english

Greetings
Firzair

 

[smetzger]

Re: I'm on it, too

As all data is parsed you could just enter a new data and it's automaticly active. For generation, the program would go by the rules entered, so perhaps you entered a new skill and it's rules, a newly generated character and all existing characters can use it.

What do you mean by this? Could you provide more details? I have found that the rules and the random generation are two different beasts that are related but quite different. Could you elaborate on how you have combined the two?

Thanks,
*:> Scott

 

[binkley]

I worked on something general like this for a long time. I called it "Layer" code because it it was based on arbitrarily deep stacks of hash maps. They behaved as union maps (think BSD if you know the union filesystem). The effect is that if you want a key from the stack of layers, the code has a function assigned to each key (you set this up the first time you insert the key).

The default key just pulls the topmost value. An example: "gender". If your PC started off male, the first value would be "male". Subsequent layers would not have a "gender" key, so they would be invisible to the default code. But when you 'acquired' a girdle of gender changing, it would be represented with a layer with a single key, "gender", whose value would be code that flipped the value, so the that the topmost value for "gender" would then be "female".

For the "HP" key, however, you'd use code which was an accumulator, so that it would sum up the HP you got at each level advancement, and return that value.

One advantage to this is that is is completely neutral with respect to keys/values. You can put any old thing you like in there. And it is trivial to store to serialize and deserialize. And lastly, it makes adding/removing items also trivial: just add/remove their layer from the stack. And if you lose levels (Boccob forbid!), just roll stack back to the point before level advancement. (I've already coded the history functionality; it behaves like transaction points for databases).


Cheers,
--binkley

 

[PeterDonis]

Peter, what language are you programming this in?

Delphi 5 (Object Pascal). I could do it in C++ but I find Pascal a lot easier to work with for stuff like this (the syntax is much more transparent to read).

Now, removing “elf” from the database (whatever form that database may take) and thus from the rules of the game entirely without going through the program is a whole other matter. I’d prefer for the program to throw an error in that case and warn the user that they’ve ruined the underlying data.

Sam

My approach in the project I'm working on is simply to not let the user remove "elf" from the database at all while in character generation/editing mode (you'd have to load a separate module which requires shutting down any open character files). A bit clunky, but it simplifies the problem for the time being, since now the only time you have to worry about a character not being consistent with the rules is when you first load the character file--if all the items in it resolve successfully, you're good for that editing session.

Peter Donis

 

[Sanglant]

Overcomplicating the problem?

Jamis,

I may be jumping in over my head a bit here, but bear with me. First, let me say there are tons of great ideas on this thread already. However, I think you may be overcomplicating the problem a bit. I'm not entirely certain I can really explain my thoughts on this very coherently, but I'll give it a shot.

Think of character as a collection of small entities. The complexity of the character generation process doesn't stem from the number of entities, but rather from the relationships between those entities. The relationships create the complexity. However, if you break down the entities into sufficiently small pieces, you can minimize that complexity.

For example, take a character class. Instead of defining it via traditional means, define it by the incremental benefits. Take the dragon disciple: at 1st level they receive +2 Fort, +2 Will, d6 HP, +1 nat armor, and 1 bonus spell. This collection of additions would be grouped under an entity like dragon disciple (1). Similarly there would be a dragon disciple (2) ... (10) that described the incremental benefits at each level. If there are generic bits that do not change for a given level and class (such as HP for most classes) that information could be cataloged in an additional entity referenced by the individual level entities.

Following this type of thinking you end up with a description of a character as follows (each line is a separate entity with a relationship attaching the indented item to the preceding non-indented item):

Character
|-Class
| |-Sorcerer (1)
| | |-SorcererLevel
| |-Sorcerer (2)
| | |-SorcererLevel
| |-Sorcerer (3)
| | |-SorcererLevel
| |-Sorcerer (4)
| | |-SorcererLevel
| |-Sorcerer (5)
| | |-SorcererLevel
| |-Dragon Disciple (1)

The next important aspect of this is time. All relationships have a potential time factor. They could have a start and/or end time (or neither). This provides for historical snapshots as well as sequential information.

The other advantage I see to this entity-relationship model (particularly with a very fine grained implementation) is its ability to go well beyond character generation. It becomes possible to use the same basic system to describe entire campaign worlds. Additionally it allows you to build a campaign world in a more logical manner, one entity and one relationship at a time.

Since I'm not sure how clear I've been, let me try to summarize. Basically, anything can be an entity (e.g. country, city, building, room, character, class, attribute, modifier, class level, item, item type, treaty, organization, etc.) and all of the information about that entity can be described by static data (data that never changes with time) and a collection of defined relationships to other entities.

Did that make sense?

BTW, I'm very interested in any feedback anyone has on this idea.

 

[Firzair]

How I wanna do it

I wanted to integrate the rules for character generation into the items, so you always get "character by the rules".
Example: One attribute of the object Creature is character level. Character level is defined something like this:
Type: Integer
Calculated: True
Rules:
Value = #SUM(Creature.Class[*].level) + Creature.race.ecl
1: +Feat
3: +Feat
4: Inc Creature.attribute[]
6: +Feat
... and so on

By these rules the generator knows what to do when a character gains a new level. Likewise all other rules are coded.
My idea for different generators was to overwrite some things by using tables for the generation, something like TableSmith.
So you want a generator that only uses NPC-Classes, you'd have a table like this:

Generator-Name: NPC-Gen
Tablename: Class <- refers to the item selection for object class
1, Warrior <- 1 is the probability, Warrior the result
1, Adept
1, Expert
...
So everytime the Character get's to select a new Class the generator uses this table for class selection.

I think it would be quite powerful.

Greetings
Firzair