Character Generation [technical/theoretical]

[smetzger]

Re: How I wanna do it

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.

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]

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]

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]

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]

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

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]

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]

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]

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]

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.