# Character Generation [technical/theoretical]



## JamisBuck (Sep 1, 2002)

Yah, I've been really quiet for a while now.  But it's just because I've been thinking...alot.  I should mention up front that this discussion will be heavily technical, and in fact I discourage non-programmers and casual programmers from reading this, since it may just confuse you (no offense intended, honestly--this confuses _me_).

I'm convinced that there has to be a way to (flexibly and efficiently) generate characters (PC's and NPC's) both randomly and semi-randomly (ie, with limited input from the user).  I'm also convinced that all of the character generation software written to date is doing it _wrong_.  This is not a reflection on the talent or effort that has been invested in these projects.  PCGen, most notably, is an incredible piece of software that is far and away the most sophisticated program of its type.  However, every program available (and I certainly include my own generators when I say this) suffers from at least one significant defect: when a new ability is released in some published source, it requires (or may require) _the program itself_ to be modified to support the new feature.

Naturally, projects like PCGen (which have pretty much categorized the entire bulk of published material) have reached a point where almost anything that comes out can be incorporated without significant modification to the program.  But they can't guarantee (and I'm not singling out PCGen here--_no existing software_ can guarantee) that any feature that might be concieved by publisher or fan can be accomodated without modifying the program again.

Now, the bad news is, I don't have a solution.   But I think that I may be on to one.  I've been doing a lot of research, thinking, and modeling, and I believe that if we can _understand_ the problem, we can build a system in which any new feature can be implemented simply by changing the data; the program itself need never change in response to published material.

I would like to get some experienced software engineers talking about this issue.  I believe it will tend toward the theoretical, and in fact I hope it does, because if we start talking about implementation too soon, we'll lock our thinking into a limited set of solutions.

So, a few ground rules for this thread:


Try to keep things generic, at least initially.  An ideal solution would apply to more than simply random character generation.
Limit implementation discussions to examples of what you mean by a particular approach.  If possible, avoid discussing implementation issues at all.
Let's try to identify related issues that exist in other fields of software design, and see if we can apply existing solutions to this.  
[/list=1]

For example (and this is where my thinking has led me to date): character generation can be considered an N-Body problem.  Each character has a set of "n" attributes (the "bodies").  A change to one attribute may affect any number of other attributes.

Now, N-Body problems have many different solutions--physics simulations use them all the time to model the affects of forces on a set of bodies.  Perhaps we can apply some of these solutions to a character generator.

I know that if we can identify the problem, we can find a solution.  I've been trying to do it myself, but I think this could really benefit from a larger group applying their minds to it.  Please, contribute!  What other ways can we look at a character generator?  Let's brainstorm and discuss, and see if we can't invent a better mousetrap!

Thanks,

Jamis


----------



## PeterDonis (Sep 1, 2002)

I've been working for some time now (in my copious free time ) on a character generator that basically works as you described. Every attribute, stat, spell, power, object, etc. that a character can have is an "item" that can be of various types and have various data fields attached to it. Then you have a (potentially huge) table of effects that one item can have on others. The problem is that these effects can cascade indefinitely, so it's a highly non-trivial task to figure out how to ensure that, every time an item is added, dropped, or changed, you catch *every* possible repercussion of that change. If the system for defining such effects is sufficiently general, I believe the goal that you've stated can be met, but as I said, it's a highly non-trivial task (in the mathematician's sense of "non-trivial", where tasks that are "trivial" are those which require anything less than a Ph.D. to accomplish ).

Peter Donis

(edit) One other thought: the N-body problem actually has no analytical solutions for N greater than two in classical physics (in quantum physics you can argue that the N-body problem has no solutions even for N=0, since the vacuum is not necessarily a stable state). All the models out there for many-body problems are numerical approximations, which are not general enough to apply to all situations. Which indicates to me that we'll never come up with a single program that can handle every possible rules variation that the d20 community can dream up. But we can still try.


----------



## Knightcrawler (Sep 1, 2002)

Hey Jamis,

I probably fall under the "casual programmer" group but I had a couple of ideas after I read your post.  First off you have to decide if your creating it for just specifically D&D or a more generic character generator.

Even if your going for more of a generic character generator that can be used with many different system there are certain things that pretty much all RPG's have.

1, Attributes 

2. Defense/AC  

3. Skills

4. Attack Bonus

PCGen right now is moving many of the mechanics that are built into the actual program to the data files.  My idea is to have some configurable variables built into the program and then have the data files themselves specifically define what those variables mean to that particular set of data files. 

This of course will be much easier if the generator is for specifically D&D or even D20.  But I would think that would work for almost any gaming system because of the basic similarities between them.

Well just my two cents.  I'll go back to lurking now.


----------



## Davin (Sep 1, 2002)

JamisBuck said:
			
		

> *I'm convinced that there has to be a way to (flexibly and efficiently) generate characters (PC's and NPC's) both randomly and semi-randomly (ie, with limited input from the user).*



Now *that's* an interesting idea!  I wasn't quite sure where you were heading with all that 'till I got to the end of your missive, but I think I figured out your intentions there.  However, I also think that it's tremendously ambitious -- doable, but quite difficult.  And you're right, it's going to have to be thoroughly designed, modelled, and tested before coding anything that won't be thrown away.

You talk about the final system being completely data-driven.  I think that can be done (at least much easier) if you put *some* kind of environmental restrictions on it.  For instance, a good starting point might be to assume that it's a d20-style game you're working with (D&D3e can be used for a specific example during development if desired).  But in a larger sense, you could make this do more...such as design Mechs or Spaceships or decks of TCGs (the latter of which I've given some thought to myself).  But it might be nice to limit ourselves to a single "field" for now.

Also in regards to the data, we're going to have to have some kind of database of information to drive this code.  For instance, choosing a weapon would have to include information about its attacks, damage, synergy with abilities (e.g. mighty bows, etc.), or choosing a feat would have to know what the prerequisite chain is.  So an early question I see (though the answer may be obvious) would be "where are we going to get/keep this information?"  Are we going to lift it from some other source (like E-Tools or PCGen or whatever), or try to design it to use such a source directly, or are you intending on rebuilding everything from scratch just for this purpose?



> *Let's try to identify related issues that exist in other fields of software design, and see if we can apply existing solutions to this.*




Ok - I'm already seeing several possible approaches...

It looks like it's a classic example of a multivariate optimization problem.  (Think epic-level [non-]linear programming...)  Mathematical techniques have been derived for dealing directly with problems of this sort, which I expect we could use.  However, I'm not quite enough of a math person to be able to tell you exactly what they are or how to use them.  Maybe someone else better qualified could fill us in on this subject?
This could also be handled with an expert system.  Expert systems are nice because they can find their way to a solution rapidly and easily.  Their difficulty lies in needing to pre-define all the possible interactions and ramifications for it to assemble and use.
The next step up from an expert system is an AI system.  Properly programmed, an AI system would be a perfect solution.  But it can be extraordinarily difficult to program something that complex and give it enough knowledge (associated data) to be useful (unless you're a leading-edge AI researcher, whom I'd love to find hanging around here).  [Oh, and heuristics wouldn't be helpful here unless you're also planning to write a gaming & DMing AI as well to test the final results.  ---  NOT!]
Another possible approach that might just work is a system called "simulated annealing".  (I understand the principles, but have never worked with any of the details.)  I doubt I can describe it properly, but let me try...  Think of the process of crystallization in a hunk of cooling molten metal.  When it starts cooling, large areas of the metal can no longer migrate far from their current position.  As the metal cools, this region of localization gets smaller and smaller, thus each crystal of the final product is slowly limited to narrower and narrower positional choices until it is finally locked into place.  Building a character could be much like this, starting with a rough form, then defining smaller and smaller details (interacting things of the same scale) until you end up with the smallest pieces being defined.  (I'm not sure I described that very well, but maybe you can see what I'm talking about?)
Theoretically, you could also use a "genetic algorithm" approach, but that doesn't sound like it has as much promise in this particular case.  (In general, it works better for small numbers of things taking a very long time on each one.)

Does that help get any juices flowing?


----------



## Archimedes (Sep 1, 2002)

*Two Giant Steps*

Well, Jamis, you’ve certainly got my attention.

In software engineering, the goal is generally to define a problem and implement a solution given limited time and resources.  So you want to avoid Analysis Paralysis.

If you’re going to define the problem as ‘A complete theory of RPG definition’, you’ve gone past the realm of engineering and into Computer Science or Mathematics.

Unless I’m completely misunderstanding you, N-Body algorithms would seem to be a bad fit.  All the ones I’ve seen have assumed large values of n, all bodies have an effect on each other, and all those interactions are homogenous.  None of these assumptions would be true for RPG character generation.

I’d consider tackling your problem in two large steps.

First, you’ll need to design a descriptive language for RPG character generation.  In other words, it would be a formalized and general way to describe the rules for character generation.  As Davin said, restricting this to D20 would be much easier than going general right away.  A language that could describe D&D, Inomine, and Classic Deadlands character generation would be ambitious as a first attempt. 

Second, design and build a program that would carry out any valid instruction written in your descriptive language.  Yeah, easier said than done here too.

Oh, and please remember that at first we’ll be talking past each other quite a bit until we can settle on common terms for what we’re trying to do.  We’ll need to be patient.

Sam


----------



## Archimedes (Sep 1, 2002)

PeterDonis said:
			
		

> *I've been working for some time now (in my copious free time ) on a character generator that basically works as you described. Every attribute, stat, spell, power, object, etc. that a character can have is an "item" that can be of various types and have various data fields attached to it. Then you have a (potentially huge) table of effects that one item can have on others. The problem is that these effects can cascade indefinitely, so it's a highly non-trivial task to figure out how to ensure that, every time an item is added, dropped, or changed, you catch *every* possible repercussion of that change. If the system for defining such effects is sufficiently general, I believe the goal that you've stated can be met, but as I said, it's a highly non-trivial task (in the mathematician's sense of "non-trivial", where tasks that are "trivial" are those which require anything less than a Ph.D. to accomplish ).*




Checking all these cascades at run time can be done using the Observer Design Pattern.  See Gamma E., R. Helm, R. Johnson, et al. _Design Patterns: Elements of Reusable Object-Oriented Software._ Addison-Wesley, Reading, MA, 1995.  The Observer pattern is trivial, but potentially expensive in computer resources.  Since you're only checking a few hundred, it shouldn't be too bad. 

Sam


----------



## jmettraux (Sep 1, 2002)

So Jamis complains that character generators are too static.

In the field of Business Processes (workflows), the latest workflow engines accept a workflow engine which describes the flow between various activities.
Business Process analysts write such 'workflow definitions' and they get launched by the workflow engine.

We could have a generic charactor engine, which we could instantiate for a 'generation-run' with a 'definition'. There could be a definition for DnD, one for RoleMaster, one for DnD FR,...

a copper piece reflection.


----------



## JamisBuck (Sep 1, 2002)

Thanks for all your ideas!  This has already been extremely helpful for me.  I'd like to respond to each posters comments:

Peter: Thank-you for your comments on N-Body problems.  I've not had a chance to do any deep research on it, and the information you provided does seem to indicate that the multi-body approach may not be appropriate for what I have in mind.  Also, you are absolutely correct in that what I am trying to do is non-trivial--I fully expect it will be a large scale project requiring lots of brilliant minds to come up with the design.

Knightcrawler: I should clarify that when I said "generic", I was actually referring to a process that could be applied to problems outside of the realm of RPG's.  I apologize in advance to everyone who misunderstood my meaning there.  Yah, that increases the difficulty of the problem considerably, but I know it can be done.  Keep in mind that initially, we're just talking theory.  The _implementation_ that we eventually decide upon will of course be more specific (possibily even system specific, as suggested by other posters).

Davin:  If we can "harvest" data from other sources, I'm not against doing so.  However, I have a feeling that any satisfactory solution we come up with is going to require more information than existing systems provide.  We may be able to harvest some of their data, but we'll have to massage it.  That's just me trying to predict the future, though.  You're absolutely right about the need to be more specific, but I think (as I mentioned above) that we can at least theorize in general about the class of the problem, and then restrict our implementation to a specific realm.

Thanks also, Davin, for the wonderful list of possible approaches to the problem.  That is EXACTLY what I was hoping to see.  I hadn't considered this as an expert system, but it really is (in many respects).  Still, you're right about that probably not being the best approach.  An AI approach is good, though--I suspect that we'll probably combine lots of different technologies to create what we come up with.  The "simulated annealing" suggestion really got me thinking--I'll have to do some more reading about that.

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.

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?

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  .

Thanks for your comments!

- Jamis


----------



## Twin Rose (Sep 1, 2002)

At GenCon, I was able to add 2 new abilities from T20 - EDU and SOC - with no hard coding into Campaign Suite.  The fact is they aren't hard coded - they are parsed at run time.

Each addition 'type' of point, say "Saving throws" or "Hit Points" has a method attached to it that determines generation or numbers.  The method references the statistic seperately, and can in most cases be edited at run time as well - sometimes, in the data file and then re-run from startup, but it's not in and of itself found in the Campaign Suite source.

Jamis, I think you should go ahead and check out the program, and see how we did it and also that we -are- d20 covered and will continue to be in the future.


----------



## CRGreathouse (Sep 1, 2002)

This must be the suingle most complicated undertaking I've ever seen in the realm of RPG programming - one one of the most ambitious ever!

I'm going to read over the posts here and the references, go over some related sites to brush up on this, and get back to you if I have any ideas.  Kudos for trying something this big!


----------



## JamisBuck (Sep 1, 2002)

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 (Sep 1, 2002)

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 (Sep 1, 2002)

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 (Sep 1, 2002)

JamisBuck said:
			
		

> 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.
> ...


----------



## jmettraux (Sep 1, 2002)

JamisBuck said:
			
		

> *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 (Sep 1, 2002)

JamisBuck said:
			
		

> *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. 



			
				JamisBuck said:
			
		

> *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 (Sep 1, 2002)

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 (Sep 1, 2002)

jmettraux said:
			
		

> *
> 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 (Sep 1, 2002)

JamisBuck said:
			
		

> *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 (Sep 1, 2002)

Luke said:
			
		

> * 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?
> ...




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.


----------



## Twin Rose (Sep 1, 2002)

smetzger said:
			
		

> *
> 
> 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. *




It really becomes difficult when you are asked to program something subjective, or 'common sense'.  Computers lack this ability, and code can be very difficult to do.  Especially while trying to keep things strictly data-oriented.  And then you get into the problem of having 10,000 checkboxes for every possible situation, which makes things hard on the end user.


----------



## PeterDonis (Sep 1, 2002)

Archimedes said:
			
		

> *Checking all these cascades at run time can be done using the Observer Design Pattern.  See Gamma E., R. Helm, R. Johnson, et al. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995.  The Observer pattern is trivial, but potentially expensive in computer resources.  Since you're only checking a few hundred, it shouldn't be too bad.
> 
> Sam *



I've heard of the book but haven't read it, I'll try to look it up. It's mentioned in some other books on OOP that I do have, but unfortunately they don't talk about the Observer pattern. Can you briefly describe it? (Since I haven't read about it, it's possible that I'm re-inventing it in the project I'm working on.)

Peter Donis


----------



## Cergorach (Sep 1, 2002)

Hmm... Interesting concept.

Let me start by saying that i'm no programmer (i dabble), and some of the terms you use are only vaguely familiar (N-Bodies or example). But i think i understand what you want to do and i can 'brainstorm' with that.

My very first question would be, what exactly do you want to accomplish?

1.) DnD (like) generator
2.) D20 generator
3.) OGL generator
4.) RPG generator

The lower you get on the list, the more complex the program gets.

1.) The program needs to understand the concept of the DnD (like) game, things are not specifically hardcoded into the program. But it has only limited under standing of the game concept (six attributes, levels, hit points, etc.). You could effectively input just about any type of race, skill, feat, spell, class, item, etc.

2.) The program needs to understand thing like Magic, Damage, Levels, etc. For example, Call of Chtullu uses a totally different way of using magic, Wheel of Time does it also in a completly different way. There has to be a way to define concepts that can then be explained through an external file. This would only be done on a limited scale, Different ways on how to implement Magic, Damage, AC, and other new concepts.

3.) The program has to keep up with all the possibilities that the OGL brings with it. If someone makes a level less OGL game, the program needs a way to understand that without a complete rewrite.

4.) The program needs to understand the concept RPG character creation (if not the whole idea behind a RPG ruleset). You would have to look at just about every RPG out there (and think up some) and start to write guidelines on how RPGs operate (specifically character creation). Those guidelines need then to be rewritten into a program that (effectively) understands how a RPG works when fed the rules for it.

I personally think that #4 is the most interesting. It's the most usefull for everyone, RPG content is completely seperate from the program, and it's the most challenging.

My idea would be to structure it allong this way:
a.) RPG Interpreter
b.) Specific game concept files
c.) Game feature files

a.) The program that reads (b) and then understands (c).

b.) The files that define the rule concepts how to hit your opponent, how damage works, how magic works, etc.

c.) The files that define things like (for example for DnD) skills, feats, spells, items, races, classes, etc.

Now the RPG Interpretor (a) would be a monster of a program (i think), because it would have to be very flexible and open (there are so many different RPG systems out there). It would be rather inefficient in it's use of memmory and processor ussage.

A solution could be to use (a) as a compiler, if fed (b) then it would compile an optimized version of itself that would then accept (c). The compiled program should then be able to run on a standard machine without to much of a problem.

(b) and (c) should be standardized in it's notation, much like the .lst files that PcGen uses.

Now, pardon me if this was not what you meant, please move along then ;-)


----------



## Sir Whiskers (Sep 1, 2002)

Jamis, 

I don't know if this reply will be much help, but after reading this thread is seems to me that one aspect of your problem has not been mentioned. The purpose of any generator is to create something viable. For example, when generating a character, you want that character to be effective (able to affect the campaign world in a useful manner) and survivable. Certain combinations of abilities, skills, feats, etc. are more effective than others. 

Any useful generator would have to possess a mathematical model of "effective" - in essence, a goal to achieve. The user inputs certain limits on the generator (race, class, level, or whatever) and the generator tries to reach as close as it can to an optimal result. Since certain aspects of almost any generator are random (ability scores, hit points), the generator would theoretically never generate a 100% match to "optimal" - it would simply try to achieve the closest match, within the limits of the user's parameters and the random factors.

It seems to me that creating such a model of "effective" would be extremely complex - probably requiring a number of algorithms to take into account the common sense used by all game creators. Once created, however, users could conceivably add or modify the material, simultaneously modifying the values for "optimal". For instance, a 3E campaign that eliminates the sorcerer's limit on spells known, without making any other changes, should increase significantly the value for being a sorcerer vs a wizard. The program would then tend to generate many more sorcerers than wizards.

An example of using values in a related way is the anti-spam program written by Paul Graham. He assigns values to various text found in email messages, prioritizes them, then has the program search for, and add up, the values. He's able to identify spam something like 99.5% of the time using this method. Here's the link to his article : http://www.paulgraham.com/spam.html (If anyone is curious, I found this article through Infoworld.com). In effect, he's identified the components of something he doesn't want (spam) and the program tells him if it exists. A generator would check combinations for what it wants (optimal) and keeps trying until it gets reasonably close.

Again, not sure if this helps, but I thought I'd throw it out here.

Good luck!


----------



## JamisBuck (Sep 1, 2002)

SirWhiskers: thanks for your input.  That was very appropriate, and something that I had not explicitly considered.  I'll add it to my research objective document, which I'm drafting right now. 

Cegorach and Scott: thanks also for your input.  I'm afraid I'm still not being very clear in my objectives, and I hope to remedy that soon with a release of a formal document detailing my goals.  For now, just let me state that I hope to formalize the _theory_ of entity generators; not just d20, or even RPG entities, but even things like prepopulating databases for testing and validation purposes.  The document I am drafting right now will hopefully clarify all of that.

This thread has already been extremely valuable to me, in that it has helped me solidify in my own mind what, precisely, my goals are.  I know many of you will not share those goals, or even be remotely interested in them, but I hope to find at least one or two of you who won't mind thinking and researching this with me.  Even failing that, I may at least come up with a proposal that I can present to my thesis committee for my own thesis. 

- Jamis


----------



## Archimedes (Sep 1, 2002)

PeterDonis said:
			
		

> *
> I've heard of the book but haven't read it, I'll try to look it up. It's mentioned in some other books on OOP that I do have, but unfortunately they don't talk about the Observer pattern. Can you briefly describe it? (Since I haven't read about it, it's possible that I'm re-inventing it in the project I'm working on.)
> 
> Peter Donis *




I’d be happy to.

I don’t know what languages you’re familiar with, so I’ll keep it general.

Start with two classes named something like Observer and Observed.

Give the Observer class a method that’s traditionally named Update.  Pass a reference to an Observed as an argument since the Observer may be watching more than one Observed and it’ll need to get at the data anyway.

Give the Observed class a list with type Observer and two methods, Add & Delete, that accept a reference to Observer as arguments.  These methods add and remove the given Observers from the list.  Most importantly give the Observed a method that’s traditionally named Notify.  This method loops through the Observer list calling Update on each Observer reference.

These classes are usually used as Mix-Ins in languages that support multiple inheritance.  In something like Java you can use Interfaces or Delegation.  In the class that inherits from Observer you’ll want to override the Update method according to purpose and use the Observed’s Add method to register with said Observed.  The later is often done in the Observer’s constructor.

In the class that inherits from Observed you’ll want to add the Notify method to the end of whatever method is used to modify the Observed.

Setting up this pattern is trivial in languages like Python, Ruby, or even LISP(Someone did mention Paul Graham).  It’s also fairly simple in C++, but a little harder than it needs to be in Java.

You can make your objects both Observer and Observed, with the Observer notifying it’s own Observers when updated.  That’s how you can avoid writing those logic tables of cascades yourself.

You can get fancier with the Observer if you want, using different Notify method that call variant Update methods or even using a vector instead of a list and registering a callback to replace Update when calling the Add method.

Maybe that’s enough for you to start looking.  You should be able to find examples written in your language of choice out there somewhere. 

Sam


----------



## Archimedes (Sep 1, 2002)

JamisBuck said:
			
		

> *This thread has already been extremely valuable to me, in that it has helped me solidify in my own mind what, precisely, my goals are.  I know many of you will not share those goals, or even be remotely interested in them, but I hope to find at least one or two of you who won't mind thinking and researching this with me.  Even failing that, I may at least come up with a proposal that I can present to my thesis committee for my own thesis.
> 
> - Jamis *




I'm somewhat interested in the research and don't mind thinking about the problems at all.  Please remember that my background is more practical than theoretical so I'm not going to be familiar with some of your jargon at the start.

Sam


----------



## JamisBuck (Sep 2, 2002)

I have finished the rough draft of my research proposal document.  I did it in LaTeX (as my first attempt to use that language), so of course you can view it in pdf, postscript, and HTML. 

http://www.jamisbuck.org/research_goal 

PDF version 

PostScript version (gzipped) 

Please check it out and comment on it; I've tried to be very explicit in what I do and do not intend to accomplish with this project.  If you feel any part to be ambiguous (a definite possibility), please let me know so I can clarify it.

If, after reading the document, you feel that this is something you want to be involved in, please email me.  But please note: I want to avoid discussions of implementation.

Well, we'll see what happens. 

- Jamis


----------



## Fractalwave (Sep 2, 2002)

*workflow definition*



			
				jmettraux said:
			
		

> *
> 
> 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.
> 
> ...




Yeah, this is what we (another company, totally non-gaming industry) did in coming up with a way to handle similar data from disparate systems in order to allow the business software from different companies to talk to each other and talk to the banking infrastructure; purchase orders, to shipment, to invoice, to payment, etc.

In that case, I was the workflow designer / business process engineer and did the database modeling.

What you end up realizing is that you can't accommodate EVERYTHING. But what you can do is accommodate all the common things, just use the occassional translator. It's enough to allow communication and to allow for recognizability of the different datasets.

You create an engine that takes information in, let's you tweak it according to what type it recognizes that information to be...d20, gurps, t20, d10, George's own homebrew rpg...whatever...and lets you spit it out. In this case, you don't necessarily have to allow for imports, though it'd be nice. Just create it and spit it out.

We do a lot of the same type of thing in Campaign Suite. In fact, the further in development we go the more we've discovered we could do in various gaming systems with the same piece of software that it's to the point we've discussed dropping the d20 logo entirely. Why limit ourselves?

But there's always something really off-the-wall that some writer does that you just can't handle and is so weird (read: imaginative) that not enough use it to justify accommodating it.

I think, ultimately, you end up with an interface and work-flow that the user defines to some extent, odd as that may seem. But I'm not sure how doable that is. What we've done is a bit of a compromise on the ideal as we know the compromise is doable. 

Of course, if someone ever really creates a decent artificial or machine intelligence that learns rpg's... The fuzzier the better!


----------



## PeterDonis (Sep 2, 2002)

Archimedes said:
			
		

> *
> You can make your objects both Observer and Observed, with the Observer notifying it’s own Observers when updated.  That’s how you can avoid writing those logic tables of cascades yourself.
> *



Thanks for the lucid exposition. I understand the pattern, and it's basically what I was thinking, but the issue is that at run time, each object has to know as it's created which other objects it needs to register with. That's what you need the (potentially massive) database table for--the alternative is to have every object register with every other, but then each object, as it's notified of another object's change, has to know whether that change will affect it, and if so, how. So again you still need a database table that tracks these cascading effects. I'm not saying the problem isn't solvable or that the pattern you've described isn't the right way to go--just that, even if the basic concept of the pattern is trivial, the implementation still isn't.

Peter Donis

(edit--P.S.) Another issue is that some cascading effects can happen when you add or delete an object rather than just changing its data, so objects also have to notify other objects when they are created or destroyed, and the other objects have to know how to deal with that too.


----------



## Fractalwave (Sep 2, 2002)

PeterDonis said:
			
		

> *
> That's what you need the (potentially massive) database table for--the alternative is to have every object register with every other, but then each object, as it's notified of another object's change, has to know whether that change will affect it, and if so, how. So again you still need a database table that tracks these cascading effects. I'm not saying the problem isn't solvable or that the pattern you've described isn't the right way to go--just that, even if the basic concept of the pattern is trivial, the implementation still isn't.*




That's why you end up limiting the implementation to what is commonly used. The problem with that is you also might end up with something that is so generic it can't handle some of the really great things that we love about the different systems.



			
				PeterDonis said:
			
		

> *
> (edit--P.S.) Another issue is that some cascading effects can happen when you add or delete an object rather than just changing its data, so objects also have to notify other objects when they are created or destroyed, and the other objects have to know how to deal with that too. *




This is something that we have run into in a limited extent within Campaign Suite. You think something is unrelated but it isn't.

You don't have to completely link all the pieces of the database. In other words, you can create an npc that's an elf, then delete the elf race. It doesn't matter because it picks up what it needs when you created it. The problem then becomes what happens later when you need that npc to have something else that is elf-only after a certain level and you inadvertently deleted the item or the race so it can't run a check.

You can end up with a database that is not optimized and repeated information in different tables. Then you have to remember to update all the different tables and it potentially runs slower. So go for a happy medium, perhaps?


----------



## Fast Learner (Sep 2, 2002)

*Constrained Design*

Very interesting idea.

This doesn't really strke me as an expert system, though the random generation portion would have elements of such a system.

It seems to me that character generation (or entity generation) is a problem that I'll call Constrained Design (I'm sure there's a real term). A lot of the (non-random generation) issues seem to resemble the kinds of issues you deal with when designing anything within a set of constraints.

Software that, for example, is used to design computer chips works like that. It lets you draw connections and gates and such, but always insisting that you perform your design within a set of constraints. It keeps track of resistance and power levels, the physical constraints of the 3-D layered environment, and only allows you to work within whatever rules you set in the software itself (size of the chip, form factor, voltage, etc.). With such software you can design chips that do just about anything, as long as you meet the constraints programmed into this session. It might have semi-random features like pathfinding and auto-calculation of various best-times, and might even allow you to simulate the chip running within the environment.

I have no idea what kinds of concepts and algorithms have sprung up around this kind of design, but I'm sure they're out there.

Sorry I don't have more to contribute -- while I program, my education and work experience were CIS focused rather than CS, so a lot of these terms are well outside my realm of knowledge.


----------



## Fyrie (Sep 2, 2002)

Wow, what a great thread.  I definately fall under the newbie programmer title as I have only been programming professionally for a little over a year.

I find this topic to be extremely interesting, and I would hope that Jamis would document his program and design process and design diaries so people like me could learn from him.


----------



## Archimedes (Sep 2, 2002)

PeterDonis said:
			
		

> *
> Thanks for the lucid exposition. I understand the pattern, and it's basically what I was thinking, but the issue is that at run time, each object has to know as it's created which other objects it needs to register with. That's what you need the (potentially massive) database table for--the alternative is to have every object register with every other, but then each object, as it's notified of another object's change, has to know whether that change will affect it, and if so, how. So again you still need a database table that tracks these cascading effects. I'm not saying the problem isn't solvable or that the pattern you've described isn't the right way to go--just that, even if the basic concept of the pattern is trivial, the implementation still isn't.
> *




My thought is the Rules Definition would contain these dependencies.  The program would know what object to construct when it reads a rule and what other objects it would need to keep an eye on.  The Abilities would know they need to keep an eye on Race, the Reflex Save would know it needs to keep an eye on Dexterity, and AC would know to keep an eye on the Ring of Protection after equipping said ring initializes that observer releationship.  These dependencies can be listed once in the Rules Definition and you can forget about them.



			
				PeterDonis said:
			
		

> *
> Peter Donis
> 
> (edit--P.S.) Another issue is that some cascading effects can happen when you add or delete an object rather than just changing its data, so objects also have to notify other objects when they are created or destroyed, and the other objects have to know how to deal with that too. *




Would having your familiar killed be an example of what you’re talking about, or, as Dee was saying, are you talking about removing an element from the game completely?


Sam


----------



## Davin (Sep 2, 2002)

Jamis,

The more I read and think about this stuff, the more I'm thinking you'll need to proceed in one of three directions, depending on your tolerance for complexity and difficulty.  (I'm guessing you'll want to aim for #2, vague though I may be about it.)

The first and easiest (logic-wise) method is something of a combination between an expert system and a simple AI.  It would be based on an inference engine design and any implementation of code would be unexpectedly simple.  Offsetting this would be that the data structure input would be extremely large and complex.  You'd have a huge set of fuzzy rules that defined your problem (inputs, constraints, and goals) and the inference engine would simply handle connecting all that stuff together and evaluating results.  Different problems would simply get a different (huge) rule set.
The second possibility I see (but I don't have enough experience here to see clearly) is a "pure math" sort of solution.  I know there are tremendously complex methods out there for actually calculating answers to problems of this complexity (though I don't know what they are offhand).  But the basic concept here is to find and implement (even if just in theory) a mechansim that will deal with your problem.  The problem itself would be defined by a large set of numeric and pseudo-numerical inputs to the algorithm, the creation of which would itself be a daunting challenge.
Finally, the "ultimate" option is so extreme that others here have written it off as impossible (though it's not).  However, it's a subject well beyond a Master's (or probably even a Doctoral) thesis.  What I'm speaking of is a *common-sense AI!*  Such things are being worked on, with some considerable success, but building such a framework takes man-decades and computer-years of work.  Lest you think I jest, visit Cycorp (here) and prepare to be astounded at what they've been doing for the last decade or two.  I even see now that their site has changed from a "pure research" orientation to one that is now selling commercial "knowledge" products based on it.  (I hope they still have some of their fundamental research concepts available for perusal.)  You know... now that they're opening up to outside use of their system, maybe you _could_ make use of their fundamental work by buying into it (probably not cheap!), if you could provide it enough "common sense" knowledge about your particular tasks of interest.
[/list=1]


----------



## Davin (Sep 2, 2002)

Whoa!!  I've just been browsing through the Cyc site and finding that they've been *BUSY*.  (The site itself is full of information that will take longer than I've got just to skim through.)  But the real news I wanted to mention is that they've gone public with OpenCyc, with full systems available on SourceForge and community development and use of nearly their entire system.

Jamis, it looks like your project may have been obsoleted already.  Or perhaps it's just been redefined to "implementing a generic constructor technology in OpenCyc."

Good luck!


----------



## Davin (Sep 2, 2002)

Oh, just to whet your appetite a bit further, here's a short quote from the "Overview" page at their web site:


> The Cyc product family is powered by an immense multi-contextual knowledge base and an efficient inference engine. The knowledge base is built upon a core of over 1,000,000 hand-entered assertions (or "rules") designed to capture a large portion of what we normally consider consensus knowledge about the world. For example, Cyc knows that trees are usually outdoors, that once people die they stop buying things, and that glasses of liquid should be carried rightside-up.
> 
> This foundation enables Cyc to understand and reason about its application domains:
> 
> ...




So, do you think it has possibilities for use with D&D or more generic conceptual work?


----------



## PeterDonis (Sep 2, 2002)

Archimedes said:
			
		

> *
> My thought is the Rules Definition would contain these dependencies. <snip> These dependencies can be listed once in the Rules Definition and you can forget about them.
> *




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.



> *Would having your familiar killed be an example of what you’re talking about, or, as Dee was saying, are you talking about removing an element from the game completely?
> *




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


----------



## jmettraux (Sep 2, 2002)

Archimedes said:
			
		

> *
> 
> 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?*




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)


----------



## JamisBuck (Sep 2, 2002)

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.

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. 

Archimedes and Charles Greathouse have both contacted me and expressed an interest in theoretical discussions of the underlying concepts of complex entity generation.  If anyone else would like to be involved in these discussions (active involvement only, please -- no lurking), please e-mail me.

Thanks, everyone for your comments and suggestions!  

(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...)

- Jamis


----------



## Davin (Sep 2, 2002)

JamisBuck said:
			
		

> 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 (Sep 2, 2002)

PeterDonis said:
			
		

> *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?



			
				PeterDonis said:
			
		

> *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 (Sep 2, 2002)

jmettraux said:
			
		

> *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.
> ...




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 (Sep 3, 2002)

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 (Sep 3, 2002)

*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 (Sep 3, 2002)

*Re: I'm on it, too*



			
				Firzair said:
			
		

> *
> 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 (Sep 3, 2002)

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 (Sep 4, 2002)

Archimedes said:
			
		

> *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 (Sep 4, 2002)

*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 (Sep 4, 2002)

*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


----------



## smetzger (Sep 4, 2002)

*Re: How I wanna do it*



			
				Firzair said:
			
		

> *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
> ...




Similar to what I am doing.  Skills I divide by Class and Cross-Class and have a probability for Class skills.  Feats you need to first determine what feats you are eligable for, then chose the feat, then look at a Keyword to see if you must make a further selection like you need to do for Weapon Focus.  Then you need another Keyword to apply the rules of the feat to the character.  Plus if the feat is a Metamagic feat this should influence random generation of prepared spells.  It quickly diverges from a simple list of weights and names.


----------



## smetzger (Sep 4, 2002)

PeterDonis said:
			
		

> *
> 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).
> *




Luke is using C++ Builder for RPM and I am using C++ Builder for my character generator.  We are both also using Paradox for the database.  So, we have a good posibility to do something that can easily interact with each program.  

I wouldn't mind comparing notes with you.  The thing that I most struggle with is database structure.  I am using in memory ClientDataSets and they seem to be working quite well, if you haven't looked into them I think it would be worth your time.


----------



## JamisBuck (Sep 4, 2002)

Sanglant: you're thoughts have almost _exactly_ paralleled my own, actually.  That is pretty much how I've been modeling entities.  I don't really think that I'm overcomplicating the issue, though. I'm just trying to _define_ the issue.  And I'm trying to define it in such a way that it _can_ be applied to more than just character generation.  (Again, your thoughts on that concept have neatly paralleled my own--I even wrote a brief paper once about how to apply character generation concepts to cities and towns.)

Off the board, Archimedes, Charles and I have been discussing the issues, and have begun to define the parameters of the problem.  Both Archimedes and Charles have been very helpful in encouraging me to see past my preconceived processes.  We'll be sure and post any conclusions we find, though it may be some time before we get that far.

- Jamis


----------



## Sm!rk (Sep 5, 2002)

Luke said:
			
		

> If nothing else, by aiming for the stars you can hit the moon.




You can also hit the sun and burn up...


Read the CADD and your research goals Jamis and am still unsure if you are categorizing generation and random generation as the same generic concept. I guess you are looking to create a system (or theroize a system) that would allow from 0-100% randomization of the complex "object", in this problem domain, is a roleplaying game character. And where 0% randomness is the user entering in everything.


My input is that there are really two systems there, the system that defines the "order" and the system that defines the "rules".

In the above "order" is defined to mean wether the entity is a valid construct. Can I have a strength of 5 and still weild a huge greatsword. This has nothing to with generation, since you'll never generate an entity that disobeys the "order". (Think as opposite to chaos. Other analogies, the order creates truth/true entities, all other entities are lies.  )

And then the "rules" are what will flesh out and create a specific entity. Be it a greatsword wielding giant sorcerer, or an intelligent laser mounted turret. These can be thought of as possibilties only, you can have the giant just mentioned or one that uses a longsword. Neither of them are more "correct" than the other but both are true if they saitisfy the order. But you would never make a greatsword wielding kobold (too weak) in D&D because that violates the order.


So order would be the objects from your CADD with all the inter-relations checking a valid character. I don't see any value in making this also a random process inless you wanted to randomly generate game rule systems, which could be done if you think of this first process as bootstrapping (in the often used sense for building compilers). But thats another topic...
I would recommend you check out the d20xml yahoo group if you haven't already, they are currently trying to define that exact thing, the order of characters (using xml of course). This seems to me as a reasonably simple task of defining your data set. However much generic you want it extends that task considerably.

The second would be the rules, and this is where I am interested. Some of the things suggested are routes I would research, however I've done a bit of research on genetic algorithms and they would certainly be an approach to accomplish the random task. I support that because its here today and works, and is actually surrounding all thing in the world, solving problems and has been for billions of years. (Talk about tried and true.)


But, and these are unknown to me from your posts, what are the current problems as you see in random generation?
Generating invalid characters won't happen since the order system would prevent that.

The only problem I currently see (with your generators for instance) is that they only satisfy one segment of the randomness table, that is completely random. There are no connections between the random data, I want to generate a specialized wizard that favors defensive spells, or a bard that is passive aggressive, or a half-orc that was raised by orcs and now lives in a human city as a rogue. (These things can be solved by RI which means real intelligence, humans, you and me. Trying to get expert systems or AI is really pie in the sky at this point, there are not at our level so will fail in some of the tasks I want, because you see I want intelligent selection of spells, not AI selection of spells.)


Anyway, the reason I see this as two systems is because of the desire for random generation. And that random generation isn't a static beast. I want all my wizards of Thay to share a similar list of attack spells, or spells that only they have, and then whatever else is left randomly generate. SO each target in the order dataset can be randomly generated from a list, or many lists, or combinations of static lists and random lists.


Neither of these systems are all that difficult sounding, doing it to be completely generic is impossible, unless your systems are also systems of this system.  In other words, you have still another system that you use to define your order system, which in of itself is an order system. For instance your generators have parts of a "random generation and validity grammar", but only partially.

So something like Definer-of-all-Things is definately needed, and while I know nothing about it, there may be things of this nature to define project time and other similar tasks (tasks with dependencies) in the buisness world.

Things like simulated annelling would definately be helpful, as would genetic algorithms. But with approaches like that you then have to "build" the order system each time a change is made, in those cases the building is the genetic selection or annelling process which is time consuming for any complex order.

Or your user end product only represents and understands your genetic code, whereas its built by another process, (either selection for random generated, or engineered which would be needed to match an already existing system.) SO the user would have to generate a new genetic code to add a new primary ability to D&D, but a new item or skill or feat will not since they are in the second system mentioned and only target data.

The idea of a game rules system defined as genetic code is very interesting. The possibilties are endless, by definition.


Tis getting a bit long, I'll leave it at that for now.


----------



## JamisBuck (Sep 5, 2002)

Keep in mind that the CADD document is only a very (VERY) partial reference document that refers to a very (VERY) specific problem domain.  Also, please keep in mind that, right now, with these discussions, I am actually not trying to write any software.  I only trying to define an abstract system that describes not only d20 characters, but also things university students and users of software.  Once the properties of these "entities" are known in general, it becomes possible to create either a pseudo-random generator of those entities, or a user-directed generator of those entities, or a mix of the two.

It sounds to me that one of your concerns is with validating the data, Sm!rk.  However, the data that defines the entity, also defines the valid possibilities that define the entity.  I'm talking not just about data, but about _meta_data.  The logic that interprets the data, then, must make sure that any attempt at generating an entity keeps everything within the constraints defined by the metadata.  It works in a way similar to how databases prevent you from inserting records with duplicate keys, or (for databases that enforce referential integrity) from deleting a record that other records refer to.  The metadata in the database makes sure that illegal operations on the data are not allowed.

Sorry I didn't address all your points, Sm!rk, but my son is requiring some supervision and I need to sign off.


----------



## BeerSkunk (Sep 5, 2002)

*N-Body Concept*

I've been focusing on this very problem with my Campaign Manager software.  How to take into account all possible additions to a character without the need to re-compile the software.

Let me give some clarification on my terms:
Object - Anything we want to model (town, house, charater, etc)
Body - An Object that is an attribute for another Object

Starting with Jamis' original proposal of an N-Bodied Object, I think it makes sense to look at our generic Object as nothing more than a collection of N-Bodies that describe it.  Each of those N-Bodies also has N-Bodies that describe them as well.  For conceptual purposes, think of an infinitely expanding tree where each Object is represented by a node on that tree and has N-children(Bodies) that describe its attributes.

Now we have a generic Object with a host (N) of other Objects that are used to describe it.  There are absolutely no relationships between the N-Bodies that make up our Object.  This is exactly what we want.  In order to have relationships such as cause/effect between our Bodies, we would have to enforce some sort of rules to govern those relationships, which we don't want to do.

The rules used to describe the relationship between the N-Bodies of an Object can be seen as a View of our data (Object).  For instance, D&D is one way of viewing D20 character data.  Star Wars is another View of D20 character data.  What a particular View does is interpret the relationships between the N-Bodies of an object and enforce those relationships.

So, what we have are actually two systems.  One, the generic character generator which simply spits out data about an Object.  And second, we have a View of that data that comprises the game rules for interpreting that data.

Those are my thoughts on the matter.  Scrambled and served hot.


----------



## PeterDonis (Sep 5, 2002)

smetzger said:
			
		

> *
> Luke is using C++ Builder for RPM and I am using C++ Builder for my character generator.  We are both also using Paradox for the database.  So, we have a good posibility to do something that can easily interact with each program.
> 
> I wouldn't mind comparing notes with you.  The thing that I most struggle with is database structure.  I am using in memory ClientDataSets and they seem to be working quite well, if you haven't looked into them I think it would be worth your time. *



Delphi 5 doesn't have TClientDataSet in the VCL, and I haven't quite persuaded myself to shell out the $$ for a version upgrade at this point (it will happen eventually if past experience is any guide ). However, so far I'm finding that I don't need an in-memory dataset type object to do what I need to do--I can get it done with a leaner set of objects if their relationships are carefully defined.

I have C++ Builder but I just don't like working with the C++ language as much (in terms of functionality there's basically no difference between C++B and Delphi except for multiple inheritance, and I can live without that). I'm using Access 97 for the database, mainly because I find it a lot easier to generate a database structure in Access than in Paradox (I don't have the full Paradox package so I have to use the Database Desktop that comes with Delphi, which is pretty clunky).

I wouldn't mind comparing notes either, but if we're going to do that in more detail we should probably do it offline (my e-mail address is in my profile on this board).

Peter Donis


----------



## BeerSkunk (Sep 5, 2002)

*Scrambled thoughts and warm milk*

Long post.

I was giving this some more thought this evening and was original approaching the problem from the generator's point of view.  In other words, I was focused on how the generator could spit out various Objects to fit any type of game character, city, or whatever you wanted.  Well, that's basically impossible.  Your generator would have to know about every possible combination of attributes and how they affect each other.  Not the way to go.

So, I turned things around.  Now the model I have is a generator that just spits out data.  Nothing else.  It's up to the Object to request data from the generator in order to populate itself.  So, the Object knows what attributes its made of, and the generator has been reduced to spitting bits and bytes on demand.

Well great.  Now I have a generator that creates an infinite amount of data and can populate any Object that requests data from it.  Perfect.  I can generate data for any type of Object.  The only thing else we need is something that tells us how to interpret the attributes of an Object.  Basically, we need a rule book.

Lets add another piece to the puzzle then.  We'll call it the Object Analyzer (OA).  For every Object we have, we have 1-N Object Analyzer(s).  For instance, a Character object may have a D&D OA, a Star Wars OA, and a Cthulhu OA.  The OA's job is to look over the Object, inspect its attributes, and apply specific rules based on the values of those attributes.  The job of the OA is the most difficult piece of the puzzle.  It has to be flexible to rules changes, therefore it's likely to be some form of non-compiled script as some other posters have brought up.  The implementation isn't important, however.  The concept is that our data is separated from our game logic that tells us how to interpret that data.

Looks like we're almost there.  We have a dumb, random data generator, and we have dumb Objects that are just collections of data, and finally we have really smart Object Analyzers that contain all of the rules specific to various games (the application of an OA could be for anything, it doesn't have to be limited to games).

This setup gets us very close to where we want to be I think.  The data that describes an Object is infinite flexible without breaking anything.  Lets say a new rule comes out for Vampire and we have to add a new attribute to the Character object.  We just add the data in, modify the Vampire OA, and it's done.  None of the other OA's will even care about the new data.  They'll just ignore it.

I congratulate anyone who thoroughly reads through this post.


----------



## JamisBuck (Sep 5, 2002)

BeerSkunk: I like how you've broken the problem into discrete parts.  However, I don't know that I agree 100% with you.

Your assumption (as I see it--correct me if I'm wrong) is that a Character will be *essentially* the same, and that any OA will be able to interpret any Object.  It seems to me that the collection of attributes and the rules that interpret them are more tightly coupled than that.  If I have (for example) a D&D character, I really _can't_ interpret it under the Star Wars rules--it's got too many extra parts, and too many parts missing.  It does, indeed, look *kind of* like a SW character, but not closely enough.  It'd be kind of like taking a Honda into a Saturn dealership and asking them to treat it like a Saturn.

What you have called the generator, I think I would simply call the database, and then refer to the entire collection of database, objects, and OA's as "the generator".

I think you made some good points, however, and I'd like to think about them some more.  The OA concept has potential, even though I think it needs to be more tightly coupled with the data (objects).

Thanks for the post!

- Jamis


----------



## BeerSkunk (Sep 5, 2002)

*The evolution of the Yugo*

You're quite correct in your assumption.  The Character object would be a vast collection of data.  As new games come out, old games are changed, and new information about a character is required, the Character Object would evolve to incorporate all of that data.

So, to use your vehicle example, lets suppose you take your Honda to the Saturn dealership and they say, 'Well, it's like a Saturn, but not quite.  It needs x, y, and z.'  So, they add the extra parts and voila.  It's now a Satonda.  Great, lets go to the Mazda dealer.  They add a few extra pieces and now it looks like a Mazda to them.  A Mazsatonda?  After a few more rounds of this, the car eventually morphs into a Tarrasque and devours everything in its path.  Humanity is ultimately saved! 

Our gangly beast of data does make certain requirements on those who view it.  It requires that when a Saturn dealer (Cthulhu) looks at our Honda (D&D char) he's able to recognize common parts that make up our car.  He recognizes our tires, steering wheel, motor, etc.  He's also able to look at the parts and map them to a language he understands.  Lets say the Honda wheel is labeled a 'RoundThing'.  The Saturn dealer then needs an interpreter to tell him that a RoundThing is what he would call a 'Tire'.  So, based on the model I've set forth, there is probably also a fourth piece now that would be necessary for Interpreting our common Object so that the OA could recognize it and make sense of all of its parts.

Addressing your point about coupling data.  I would argue that part of the nature of the original problem (avoiding the need to rebuild the generator every time a new game or piece of data comes out) is because data and the rules are coupled.  The very act of coupling them dooms the effort, because now data has become self aware.  So, like a 2 or 3 year old running wild through the aisles at Wal-Mart, the data becomes unruly and difficult to manage because it's in constant need of attention.  It's environment (the game) constantly changes, therefore the data is needing to constantly change.  If the rules are coupled with the data, then those too will have to constantly change, which in turn necessitates that our generator is also constantly changing.  Damn toddlers!

We're not going to eliminate the need for changes, nor would we want to.  We really just want to limit the changes so that our generator isn't broken by them.  This is why I separated things into three parts, possibly more as time goes on.  The parts so far are an arbitrary set of data, an Object, and an Object Analyzer  (possibly an Interpreter as mentioned above).   You could couple the Object and the OA into a single entity.  The only reason I chose to separate the two is because I believe that the data needs only to be data, and that it's possible for multiple, arbitrary OAs to share a single data set as long as they can interpret them.  If you couple them, you would need a separate Object/OA entity for every possible game.  If you try to combine them so that a single Object/OA entity covers every possible game, it would become so large and complex it would be unmanageable.

I have more to say on the topic, but it's getting too much to post here.  I will add one caveat that I am well aware that some of my concepts have huge holes in them, but I can't address everything here.  Some of them I'm probably not even aware of.


----------



## JamisBuck (Sep 5, 2002)

lol!  Toddlers running rampant--_there's_ a metaphor and have never thought to apply to character generation. 

So, from your examples, an OA would never _remove_ data from an object, it would merely ignore anything it didn't understand, and _add_ anything else it needed.  I think I can see how that would work.

I think I would argue counter to your assumption that "self-aware" data need more attention, though.  By giving a datum the ability to make its own decisions, you've actually delegated responsibility to it.  You can focus on other things and accept that the data will know what to do under any given circumstance.  Perhaps I'm still not seeing your entire philosophy here, but it seems like removing the logic from the data requires you to pay _more_ attention to the data...

And don't worry about ideas having holes in them.  I haven't seen a theory yet for entity generation that doesn't have holes in it.  That's what these discussions are all about--patching up holes and finding models that can hold enough water to be robustly implemented.

- Jamis


----------



## BeerSkunk (Sep 5, 2002)

*Melted ice cream*



> By giving a datum the ability to make its own decisions, you've actually delegated responsibility to it. You can focus on other things and accept that the data will know what to do under any given circumstance.




Okay, lets assume our datum is intelligent.  Does it know what its relationship is to other datum in our set?  If so, does it know what its relationship is to other datum based on the context it's being viewed in?  Simplified example: Does Strength know that it affects Base Attack and Damage?  If so, this works fine for D20 games, but what about a new game that comes along?  Does Strength also know that in NewGameX it also affects Skill points?


----------



## JamisBuck (Sep 5, 2002)

Ah, I see what you're driving at.  By coupling logic and data, it becomes hard or impossible to teach an object new tricks.  A good point.

I'll think about this some more. 

- Jamis


----------



## Sanglant (Sep 5, 2002)

*Regarding Evolving Yugos*

BeerSkunk -

I'd argue that the data without the rules is useless.  For example, the number 12 appears on a characters sheet.  Without tying that to something else, say Strength, the number itself is useless.  But, by tying it to Strength we have given the data definition.  It has a purpose.  It also has rules associated with it (anything that relates to Strength).

Now, I do think your approach has merit.  I just don't agree with the assertion that rules and data must be decoupled.  In fact, by the nature of the problem we are trying to solve, a universal generator, it is imperative, in my opinion, that the rules be _defined_ by the data.  Without that it'll still take a programer changing the code to add more rules.

That's not what we want.  It shouldn't take any programming skills to create new rules.  It'll probably take more cognitive skills than the average bear, but that's a different problem.


----------



## Sanglant (Sep 5, 2002)

*Re: Melted ice cream*



			
				BeerSkunk said:
			
		

> *
> 
> Okay, lets assume our datum is intelligent.  Does it know what its relationship is to other datum in our set?  If so, does it know what its relationship is to other datum based on the context it's being viewed in?  Simplified example: Does Strength know that it affects Base Attack and Damage?  If so, this works fine for D20 games, but what about a new game that comes along?  Does Strength also know that in NewGameX it also affects Skill points? *




Argh! Posts while I'm posting ... must reply.  

As part of allowing generation of entities for NewGameX, it would be necessary to create Rules that describe it's differences, i.e. you'd add a Rule that describes how Strength affects Skill points.

Don't think of coupling Rules with Data as making them part of the data element.  Think of them as independent entities that can be used to connect other entities together.  Example: NewGameX has a Rule (entity) that describes the relationship between Strength and Skill points (two other entities).

Am I making sense?  I think maybe I need to draft a formal paper on what I'm trying to get at.  I'm starting to think I'm not explaining my thoughts very well.


----------



## BeerSkunk (Sep 5, 2002)

> I'd argue that the data without the rules is useless...




Agreed.  Data without rules is useless.



> ...For example, the number 12 appears on a characters sheet. Without tying that to something else, say Strength, the number itself is useless. But, by tying it to Strength we have given the data definition. It has a purpose. It also has rules associated with it (anything that relates to Strength).




This is where my Object Analyzer concept comes in.  Some thing, separate from the data that applies rules.  What the OA is, or how its implemented is anyone's guess.  There are numerous ways of doing it, but the point is to keep data from knowing about how they interact with other data in our set.  I assert that should be the job of some other entity.



> Don't think of coupling Rules with Data as making them part of the data element.  Think of them as independent entities that can be used to connect other entities together. Example: NewGameX has a Rule (entity) that describes the relationship between Strength and Skill points (two other entities).




I think we're in sync here.  Keeping the Data and the Rules separated.  You're right that the Rules could very well be independent data entities.  They could be something else entirely.  I don't know how the Rules will be implemented, but essentially we're in agreement.  It should be the Rules, as separate entities, that give the Data meaning, not the Data itself.

Please correct me if I'm misinterpreting you, or throw blunt objects at me if I'm not making sense and need to clarify myself.


----------



## Sanglant (Sep 5, 2002)

*AGREED!*

I agree that we agree.  

I think we basically just debated long enough that we could see through each others jargon and come to the conclusion that we are saying the same thing.

Now all we need to do is define it.


----------



## tarchon (Sep 10, 2002)

I've made stabs at this problem before with White Wolf character generation  (Characturge ).

It's obviously an old problem with software development, and you generally see several kinds of approaches to solving it.

A. The software is enormously complex and comes with its own script (or procedure if you prefer) language that exposes variables (or objects for later generations) to manipulation by "power users."  Microsoft likes this approach a lot, which is why all of their networking products are virus havens.

Upsides: Very flexible, limited expertise required of casual users.
Downsides: Hideous amounts of development time required.

B. The software is really essentially a library - "users" build applications out of components.  These are things like MFC, OWL, LabView.  Nowadays they typically they come with some kind of GUI CASE tool, so that they approach the script language solution.

Upsides: Even more flexible
Downsides:  Even casual users generally have to be fairly savvy.  Development time ridiculous.

C. The software itself may be fairly inflexible, but it uses some interprocess communication scheme to allow it to act as a part of other software, via DDE, OLE, COM, AFX controls, etc.  Computer scientists love this because it's complex and theoretically rich.  Developers generally grumble about it because it's complex and theoretically rich.  Another important working example of this in real life is SAP.  SAP sucks.  On the other hand, Office also uses this approach, and it actually does tend to work fairly smoothly.

Upsides: Not so hard to develop, once you get past the interprocess comm hump, though it can be a big hump.
Downsides: Requires developers to be familiar with arcane protocols, expressed in bizarre computer science jargon, that are highly platform dependent and become obsolete every year or two. 

Of course, many real solutions use combinations of all three of these.

I have actually tried using OLE in my character generators, and back in the mid 90s I had a test version of VtMChar (my older Vampire character generator) that you could embed via OLE.  Part of the reason for this was that many users wanted note taking capabilty in it, and it seemed like it would make sense to be able to either embed character sheets in word processor documents or embed word processor documents in the character generator.  However, I heard nothing but chirping crickets when I floated the idea in public, so I never took it beyond the test stage.

My next approach was (A), which led to  Characturge with its template files.  My big motivation for this was that White Wolf kept revising Vampire and adding new games, and I didn't want to keep adding Options to VtMChar.

I learned several things from this.  First, even in WW's much smaller RP community, plenty of people were ready and able to develop templates.  Second, the more general character generator by nature had to be much clunkier than the highly specific VtMChar.  Third, no matter what I added, White Wolf's developers would continue to add weird rules that woule require some new functionality.  Eventually, with grad school taking ever more time, I stopped working on it.  People still email  me asking for the source code, and I might eventually give it out if I get around to it. 

My first plan to push it forward if I ever got time was to write it in a more portable language than VC++.  I thought Java was the answer.   Then I actually saw Java applications in the field.  After I had three JREs loaded on my system to run each different Java app, I decided it wasn't the answer after all, though I did end up using a Java component in my networked dice roller. 

The next thing I tried was to build it using DHTML.  This almost worked (very flexible, widely known API, those nasty rendering tasks were taken care of), but I could never get a reasonable data persistence mechanism worked out because browser developers were getting continually more paranoid about data persistence.

My current thought is that the best thing you could do is to build it around some open source browser code, say like Mozilla.  Most browsers have enough objects and enough rendering power exposed as it is to do anything you could possibly want to do in character generation.  With some alterations or additions to the serialization capabilities (say a sandbox for storing persistent character data, which is really no different than caching or cookies), you'd have something vastly ahead of any character generation software  currently extant.


----------



## Luke (Sep 17, 2002)

[Bump]

Any progress guys?

I was wondering if there were any lessons to learned from the E-Tools generators, so I had a quick look.

It's quite happy generating chaotic evil paladins.

I guess that's a lesson of a different kind...


----------



## JamisBuck (Sep 17, 2002)

We had a pretty lively discussion a week or two ago off the board, and tossed around some interesting ideas.  Nothing ready for "public consumption" yet, but we'll keep everyone posted.  Things are quiet right now as we are all kind of digesting what has been discussed and reformulating our theories, but hopefully we'll have another burst of creative energy soon.


----------



## MJEggertson (Sep 17, 2002)

*scratches head*

What the? How did I miss this thread? Damn it, I'm way too tired to digest this all tonight. I'll be back...


----------



## smetzger (Sep 17, 2002)

tarchon said:
			
		

> *
> My current thought is that the best thing you could do is to build it around some open source browser code, say like Mozilla.  Most browsers have enough objects and enough rendering power exposed as it is to do anything you could possibly want to do in character generation.  With some alterations or additions to the serialization capabilities (say a sandbox for storing persistent character data, which is really no different than caching or cookies), you'd have something vastly ahead of any character generation software  currently extant. *




I would think that J2EE would provide the flexibility for this type of thing.  BUt I don't think it would be a practical solution because of the headaches of distributing the server portion.


----------



## MJEggertson (Sep 17, 2002)

This is very fascinating, and I applaud the discussion so far. Also, I would love to be part of the email discussion. I can’t rifle a message off right now, I’m at work, so I’ll do so when I’m at home. But if any of you are composing something right now, please add me to the list, mike@rpgprofiler.net.

I think there are also two discussions happening. One, about being a generator, and another about how to implement a totally customizable data/ruleset. I’m for the moment going to focus on the data/ruleset, and some theory on how one would go about the design of a program that uses absolutely no hard-coded data.

We know the program has to be flexible, to allow for rule mods, splat books, etc. The question is how do we handle the data, and how do we handle the mods?

Sanglant’s idea of a character being an entity collection I think is bang on. If we focus on d20 products, this is rather easily done. The system is designed around incremental changes to properties (entities) of a character. But as a general theory, the question rises, how are these entities defined? We need to prevent a hard-coded approach, otherwise we’ve defeated the purpose of this discourse.

I use a program on a daily basis that I think we can learn a lot from. It’s a raw numerical data crunching tool, but it is very flexible, customizable, and most of all, it’s rediculously fast. Probably the biggest concern when implementing a custom data library of undefined size is program speed, memory consumption, and general performance, as I think it was Luke that mentioned. Even back in the day of MacIIs, when a few megs of ram was hard to come by, this program could throw around data matrices a meg in size and operate on them in a few seconds. Even on user-written ‘scripted’ tools. How?

Through the combination of compiled and scripted languages. The program has a C-like language that it reads. Depending on the context, this language can serve as a script that is parsed at run-time, and making calls to other pre or user defined functions (acting essentially as a macro language), which is of course slow. But in another context, the program reads this language, compiles it at start up, and the resulting functions/methods/objects are kept in memory and can be executed just as fast as any hard-coded function call or operation.

I think a project like this needs something similar to the above. AI routines, interpolative procedures are nice, but in the end, they will not be perfect, and run the possibility of introducing quirky behavior to the program. The only way to really accomplish this is to let the author of a dataset/tool/addon to define it themselves.

The structure of the language that the theoretical application would use is irrelevant to the current discussion. It could be data-driven like xml, it could be language driven, like a C-style, whatever…

But how to use it? To be flexible and be able to accommodate any new material, the entire data set, the operations, and everything needs to be defined outside of the actual application. What your program essentially ends up being is a wrapper for a language of some type, that generates a UI.

At start up, the program scans the data files, the procedure files, the rules files, compiles them, and once done, the program operates without lag or slowdowns, as if everything was hard-coded. Compiling at start up is time-consuming, but this can be worked around. Say, for example, you look at each file, and save an md5 digest or something. At start up, the program digests the code of a rule, and only re-compiles it if it has changed. Startup is lightning fast after the first compile.

The program resolves conflicts by building a hierarchy of the data and methods it compiles. If the base rule set defines MethodA, but it is redefined in the implementation of a splat book mod, then the program determines which implementation takes priority.

The bad side to the above, is it will obviously require anyone who wants to add a tool to be reasonably proficient at programming. And of course, the author of such a program needs to develop a language. But the language need not be complex.

What need be done? As I see it, you need to define three things. What a character is. This will be an entity collection. You then need to define your entities. What are they? In the end, they boil down to an arbitrarily complex structure of numeric and string data. Finally, you need to define some methods that operate on these entities. The methods are essentially operations that are performed on the entity data.


----------



## smetzger (Sep 17, 2002)

MJEggertson said:
			
		

> *
> I use a program on a daily basis that I think we can learn a lot from. It?s a raw numerical data crunching tool, but it is very flexible, customizable, and most of all, it?s rediculously fast.   *




hmmm ....  Matlab?


----------



## MJEggertson (Sep 17, 2002)

Nope. Better than Matlab, as long as you're only using matrices and vectors. It's called Igor Pro, and it's very user-unfriendly, but it's very powerful.


----------

