Character Generation [technical/theoretical]

[JamisBuck]

Chris, thanks for pointing out your Campaign Suite software to me. I was not aware of it. Unfortunately, I do not run windows, and so cannot try the program. I will email you separately to ask you some questions about the program--from what I read, it does seem to do more of what I have envisioned than other software I am aware of.

Charles, I look forward to your contributions to this! I've been trying to do this all myself and have just kept talking myself into circles. I realized that for a project of this magnitude, it will require a community of developers to help out. Yah, it's big, it's grandiose, and it is daunting, but I'm sure it can be done.

 

[Luke]

N-Body, multivariate optimization, expert systems, and *especially* genetic algorithms!

Could be a fantastic discussion, but anything this generically ambitious is likely to take a *lot* of computing power. You're also probably going to want to do in script (slower again) to meet licensing requirements. Even if you generate with very simplistic randomness, it takes enough time to fully calculate creatures after you've decided on the random factors. Users typically want an answer within a couple of seconds per randomly generated NPC/monster. Sure, you'd allow for greater time as a DM preparing the "boss monsters" for an adventure, but you'd hopefully have specific, non-random ideas for those in any case.

I'd return to the classic engineering use case scenario, and see what the deal breakers are (Einsteinian thought experiments).

Take the Druid as an example. It's a known case, but lets see how we go with a D20 scenario, rather than a D&D one. Let's start with core D&D, except there is no druid which has a big problem with metal. Pretend you are going to have a system that, if you create an unexpected druid class with a metal problem, will still do sensible things.
What's sensible? Well, no weapons or weapon proficiencies that involve metals. What about heavy armor proficiency? Wouldn't make sense if there is no heavy armor that doesn't contain metal (is there? quick now! - anyone except Charles Greathouse ). How does a generic system allow you to specify this metal issue in the first place, in such a way that it will affect subsequent random generation?

Approaching from the other end:
Try something as simple as race and alignment. Can the specific campaign have an affect? If we're in MiddleEarth, we'd expect some pretty different results generating race and alignment when comparing Hobbiton to Mordor (there's always a chance you'll find a couple of LG halflings near Mt Doom, though). Apart from the fact that race descriptions give the most basic alignment variation descriptions, you may even have different alignment spreads for the same race, based on *where* they're found.

I mention these just because initial suggestions seem to point to some kind of utopic answer. I'd really suggest that serious thinking be put into considering the boundaries of the problem, before possible ways that it may be solved. I don't, for example, that the Druid metal problem would be generically solved in scripted code, in anything like the time it takes for a typical gaming session.

How about assigning skills? There's a bucket of issues there, like:
- No database I'm aware of specifically states whether or not a race has legs. How do you know that a race can "Jump".
- What does "Bluff" mean to a race that doesn't communicate (speach or telepathy)?
- What does "Innuendo" mean to a Gelatinous Cube?
- What does "Swim" mean to a dire bat?

What about items geenration, and the possibility of magic?
- Some play high magic, average, low magic, or even no magic (D20 modern?). All this points to being able to specify different tables for different campaign settings (and possibly different locations within the same world map...).

I''m afriad that any practical random generation solution is likely to lead to all sorts "ridiculous" results every now and again. From what I know of trying to sensibly codify things, a huge amount of effoty that takes a huge amount of time is likely to improve things only slightly.
Another side is that a good solution is likely to consider an encapsulating environment beyond "I want a random NPC/creature", such as identifying a campaign location that points to certain alignment, race and class spreads.
It points to a greater campaign-specific approach, such as CS, or my own RPM.


I asked this board about this very question a couple of months ago, and nobody could come up with anything really feasible.

At the moment, in my own RPM program, I have a little known and very under-utilized "Table Generator" feature. It allows you to build your own tables of items, classes, races, alignments, spells etc. At the moment I've only entered in a couple of the DMG wandering monster tables that actually generates an encounter for random races.
Based on questionnaire feedback for RPM, people *really* do want random race/item expansions, so I'll be into expanding that. It'll probably go as far as basic tables for specific adventure or campaign location random tables, classes and alignments - but nothing *too* smart.

I really think it comes down to setting yourself practical boundaries that you can live with...

 

[JamisBuck]

Luke, you raise some very good issues. However, I disagree that generating a random "entity" has to take an eternity to do if you are doing in with a "generic" engine. My current NPC generator (in which everything is admittedly hard-coded) can generate 100 NPC's, including spellbooks, feats, and skills, in seconds. I am confident that a well-designed and thought-out engine could generate a complete character (including racial templates, spells, equipment, prestige classes, and more) with sub-second response time, on hardware commonly and inexpensively available today (I'm talking sub-gigahertz processors here).

Your point about unforeseen effects is a good one, though, but it only reinforces my statement that we need to think this through as thoroughly as possible before we implement anything. Of course, any piece of software is rewritten several times--I know that from experience, no matter how well thought-out it was. I don't expect to get this right the first time, especially since we've never done this before. And please note that my goal is not to create a dataset that never needs to be rewritten, but to create a program that never needs to be modified in response to a new type of datum. The entire "can't use metal" issue should be solvable in the data (and yes, probably through the use of scripting, but since that's an implementation issue, I want to steer clear of discussions on that right now). If someone comes along and says "my new class X can't use anything flammable and requires that their weapon be able to contain at least a gallon of water", I don't want to have to go back in and release a new version of the software--just the data. Am I making any sense at all?

I know this is not going to be trivial. It is going to require a LOT of work (heck, it's already taken me over a year and a half) and it's going to require a LOT of hard thinking. But saying why it can't be done is dooming yourself to failure. I only ask that people contribute if they want to help succeed; let's keep the comments positive and constructive.

Thanks,

Jamis

 

[Luke]

I know this is not going to be trivial. It is going to require a LOT of work (heck, it's already taken me over a year and a half) and it's going to require a LOT of hard thinking. But saying why it can't be done is dooming yourself to failure. I only ask that people contribute if they want to help succeed; let's keep the comments positive and constructive.
QUOTE]
This will be a very positive exercise. If nothing else, by aiming for the stars you can hit the moon.
I think that trying to define the boundaries of what you're trying to achieve will give it a much greater chance of success. I mention things like the appropriate skills, or the druidic metal problem as examples of where you might want to start setting your boundaries.
"Use Cases" are typically accepted as being the way to define what you're trying to solve, and I threw a few hard ones your way to see where you're at with your expectations.

I'm still not sure I understand what you really mean by all this. For example, you mentioned PCGen's problem is that a change to the database means a change to the program. PCGen isn't actually an NPC generator in any way, far as I understand, unless you're just referring to data/code coupling problem. I can tell you about how I address that in a generic way with RPM, but that's an implementation detail.

I personally find it easier to deal with a problem starting with the requirements. Take the simple question of race and class. The DMG has tables for generic wilderness encounters, and for dungeons.
Placed in a campaign context, to me this suggests being able to define basic tables on an area basis. That area could be as large as a continent (what races exist in your world), as medium as a "state" ("climate/terrain" table), or as small as a given cave system (specific dungeon table).
From there you consider what classes they may be. Do certain areas have different class distributions?
Do you anticipate offering a way to define tables, and choose which ones are appropriate?
Do you want a wizard-style app that starts with race->class->feats->skills->spells->items ? This seems to be the logical progression.
Do you want an option for class->race , rather than race->class?
Do you want an "auto-mode" where the wizard plays itself behind the scenes?

 

[jmettraux]

jmettraux: that's an intriguing idea. It leans more towards implementation, but I'd like to read more about it. Is there anything online, or any books you would recommend?

If you google-search for "workflow definition" you'll be directed to a lot of products or article, picking the right one will be hard.

http://www.wfmc.org contains a reference document about workflows.

I haven't found anything instructive enough to show you about workflows, I could post some products screenshots, but I haven't got any such applications at my home office.

The classical workflow engines take as input a workflow definition (edited by a workflow designer / business process engineer) that is instantied (a workflow instance). The engine interprets the definition and manipulates the instance.

The generator could take as input a generation task definition : a document describing how to compose a character.
If it's generic enough there could even be definitions for treasures or dungeons, with the same engine.

Programming is setting the level of abstraction a bit higher, it is also said to be 'extending a language'.
Here, we would have a language describing how to generate a character.

with this approach there would be three 'roles' :
engine-developers, definition-designers and end-users. (compliance-officers... a 4th role...)

The role of definition-designers could of course be taken by a genetic algorithm : running the engine a lot of time with different definitions against acceptation criteria would soon point to an adequate 'definition' for a given game system.


Luke is right when saying that 'use-cases' are required for setting the scope (boundaries) of the 'project'.

 

[Archimedes]

Archimedes: you're right about the dangers of over-analysis. However, given that we have an extremely flexible schedule and no real resource constraints, we can pretty much do whatever we want with the scope...within reason. It may be that our discussions here will prompt others to begin implementing systems based on partial analyses, and I'm sure those have a high chance of success, but keep in mind that my ultimate goal here, is really just to design. Naturally, we'll want to actually produce software eventually, but right now I want to find one of the best solutions possible for this problem. Your suggestion about a description language for RPG's is exactly what I've been working on for some time (with both Basilisk and Medusa), but I've actually tabled work on that for now since I want to focus more on analysis of the problem.

Also, Archimedes, you're exhortation towards patience until we settle on common definitions is an excellent one. Discussions will probably fluctuate around the true issue for a while until we settle into how the dynamics of this group will really work.

If others are prompted to implement what we discuss or improve existing applications, then I’ll consider us to already be successful. The fruits of our discussion here will probably have a bearing on traditional interactive character generators also. That’s where my interests are now anyway.

I believe that the solution to parts of this problem lie in learning what needs to go into the description language, so I suspect much of our discussion will revolve around that topic.

My recommendation for patience comes from hard earned personal experience. Users are quite often surprised when terms don’t mean what they think.

Thanks, all, for your ideas! One last thing: I thought I'd post some of my analysis of the relationships between many of the attributes of an NPC. I worked heavily on this document for a few months, but it has guided my thinking ever since (at least until I realized that I needed to be thinking on a more theoretical level). The document is not particularly well written, but it should give you something to work from in discussing interrelations between attributes. (Please note that the document is too focused, really, for our current discussion, but it is an example of the kinds of interrelationships we'll be dealing with). The document may be read here: http://www.jamisbuck.org/CADD.html .

I’ve done a quick examination of this document.

It seems to be a good description of the character view. My opinion would be that creating a game view in addition would make some interrelations easier to grasp.

You may also want to add a few more attributes such as ECL, Divine Rank, or even Animal Companions. Oh, you probably want to include the epic stuff like ESB & EAB.

Oh, and it would help to include an Equipment.Other attribute for equipment the character owns but isn’t carried, wielded, or worn. I know those items are included in the base Equipment attribute, but redundancy can help in understanding data contained in a view.

You could also consider putting in an Events attribute for including things like taking a dip in a pool that increases the character’s DR or eating a fruit that increased the character’s Wisdom.

I hope you don’t mind that I’ve copied that document for my own use.

Back on topic. Does anyone know of a RPG that doesn’t include some sort of Base Statistics like the D20 ability scores?

Sam

 

[JamisBuck]

Luke, thanks for clarifying. I completely understand the need for setting boundaries on a project. But I think I haven't been clear enough myself on my goal.

Ultimately, I hope what we do here can result in a character generator. But mostly I want to look at the theory behind a character generator. What are the concepts involved? In fact, I don't even want to focus on a character generator. I believe the concepts involved in a character generator can apply to larger set of problems. One of my current "to-do" tasks that I've set myself is to identify similarities between random 'entity' generation (towns, characters, dungeons, kingdoms, etc--there really isn't much difference) and other "real world" problems, such as grade processing at a university, or resource allocation on a project. Obviously, the problems of grade processing at a university and resource allocation on a project have been solved (in many different ways)---my questions are, first, can the paradigms they used to envision those problems apply to character generation, and second, can the solutions that have been devised for solving those problems be applied to character generation?

Now, this "theoretical" approach may not be what most people on this list want to involve themselves in. It really is an academic exercise, and I think many people on this board are looking for solutions now, to very specific problems (random character generation). In fact, if nothing comes of it here on this list, I may consider tackling it as my Master's thesis when I start grad school in January. But an academic understanding of the problem can make a HUGE difference in how random generators are implemented. Consider: if no one had taken the time to study grammar (not specific grammars mind you, but the general linguistic theory of grammar) and to find out how grammar theory can be applied in Computer Science, where would all our compilers and parsers be right now?

To continue the example of compilers and language theory, I want to point out that I don't hope to invent something completely new. I hope to find some other discipline (workflows, for instance, as jmettraux suggested) which has a (possibly unexpected) bearing on the problem at hand.

Again, character (and 'entity') generation is just a byproduct of the research I've been doing. The boundaries everyone has been recommending (such as limiting the scope to the D20 system, etc) are excellent suggestions, but not very applicable to what I'm trying to (and which I hope I have explained somewhat lucidly above).

Also, it should be pointed out that when I say "character generation", I am no longer merely referring to "random" generation. Whether the character is "generated" by hand, with a user explicitly setting values for each attribute of a character, or whether the character is purely random, or whether the character was generated by some intermediate method, it is all the same to me. The means of representing the character and the data involved will all be the same. In this regard, I consider PCGen a "character generator", even though there is (currently) no support for random generation.

I know I keep bouncing back and forth between "keep in generic" and "talk about a character generator", but the fact is, right now a character generator really is the best defined "problem" of the sort I want to tackle. I am going to continue to look for other problems that at least intersect this set; but for now, working on defining a character generator may give us insights into this larger set.

I'm tired, and I'm afraid I'm still not making sense. I'm going to see if I can work on a draft of the project goals, which I will post online. I admit I should have done this before posting on the board...ah, the value of hindsight...

- Jamis

 

[Archimedes]

The role of definition-designers could of course be taken by a genetic algorithm : running the engine a lot of time with different definitions against acceptation criteria would soon point to an adequate 'definition' for a given game system.

I don't think I'm understanding you. Wouldn't it be better for a knowledgeable user to build the Game Definition than the Shakespeare Monkeys? How does this genetic algorithm help?

Sam

 

[smetzger]

Luke, you raise some very good issues. However, I disagree that generating a random "entity" has to take an eternity to do if you are doing in with a "generic" engine. My current NPC generator (in which everything is admittedly hard-coded) can generate 100 NPC's, including spellbooks, feats, and skills, in seconds. I am confident that a well-designed and thought-out engine could generate a complete character (including racial templates, spells, equipment, prestige classes, and more) with sub-second response time, on hardware commonly and inexpensively available today (I'm talking sub-gigahertz processors here).

Well, I am not so sure about this. My experiments in 2e character generation and now 3e character generation indicate it to be an intensive process in which you constantly have to weigh speed vs. memory usage. I think it will take several seconds for one character. This is given my interpretation of 'generic engine' which is: All game rules are assigned in the data and all relative weights for random character generation is also assigned in the database. When I say 'rules are assigned in the data' this could be done via keywords or scripting code. Also, I am assuming that relative weights can be modified by many things, for instance when randomly determining weapons carried for a dwarven fighter with weapon specialization in battleaxe; the weapons will all have a weight and then his dwarven race should modify these weights and then his weapon specialization should further modify these weights.

Admitedly, I am not much of a theoretical programmer; I am much more practical and KISS oriented. But I think you first need to clearly identify what you mean by 'generic engine'. You will also need to decide if you want this to be a purely random character generator or if you also want a GUI which will allow the user to edit characters. If you also want the GUI, than I would suggest that one expand the definition to allow for a user to manually edit any part of the process and then allow for random generation to complete the process.

 

[smetzger]

How about assigning skills? There's a bucket of issues there, like:
- No database I'm aware of specifically states whether or not a race has legs. How do you know that a race can "Jump".
- What does "Bluff" mean to a race that doesn't communicate (speach or telepathy)?
- What does "Innuendo" mean to a Gelatinous Cube?
- What does "Swim" mean to a dire bat?

Well strictly from a rules point of view there are no restrictions on skills based on your race. The race in question should have racial modifiers for certain skills that are difficult for the body type. However, quite often the d20 monster description does not include such things.