I found this poking around and thought it interesting. I'm a total coding n00b, but I have a lot of walk-over-to-Frank's-office-and-bug-him type help to tap developing in the Visual Studio/C#/XML/Windows environment. So that's what I'm looking at.

(which I guess means I'm also tossing my hat into the developing SR software ring for the good and ill it will come to )

I'd really like to hear some comments/analysis of this schema as a good or bad distillation of SR gear/mechanics/etc (Rather than reasons why approaches X, Y, and Z that aren't XML are better).

Thanks.

I haven't looked into his proposal, but I'm actually writing my own. Working on some for SR4 first, then I'll be going back and focusing on SR3 (more complex, but more personally rewarding).

~J

I think this proposal wrongly separates "definition" vs "usage". It only allows using a pre-defined set of elements, or to always redefine the same things. This is a problem with generator tools.

Say I have defintions for "Car" and "Car Enhancement". I can "use" these for someone who owns a "Car"+"Car Enhancement". That is ok.

But what if I want to flood the market with such a car named "Enhanced Car"?

Solution 1: for each one, I use "Car"+"Car Enhancement"
Problem 1: copy/paste is tedious task if at all implemented!
Solution 2: I create a new definition for "Enhanced Car" and use it
Problem 2: I need another program to create the definition

The preferred solution would be to label the "Car"+"Car Enhancement" as "Enhanced Car", but a "definition" cannot be created easily from a "usage". Nothing created through combination can be re-used, so car/deck/gun generators are semi-useless or need to require much much more work.

What I would propose is something much much simpler, that does not really need XML (not that I say XML must not used for it). First, do not separate between "definition" and "use". A thing:
. has intinsic properties (like price, name, weight...)
. refers to other things (gun has ammo)
. inherits properties from other things (jackrabbit is a car)

thing {
name=Car
}

thing {
name=Car Enhancement
}

thing {
name=Enhanced Car
is_a=Car
has_a=Car Enhancement
}

This way, anyone can reuse the "Enhanced Car".

I am (very slowly) working on a more understandable explanation for my proposal. My inspiration comes from class-based vs prototype-based languages.

My understanding (and I freely admit that it is imperfect - hence the thread) is that definitions record data that is likely to be static (barring errors). And that usage is an instance of data run through a number of rules.

In your example (I won't be showing code snippets sorry)...

The tool would have Enhanced Car recorded on the player in question's character sheet as a usage (I like the term instance, but that could just be WoW talking) of the definitions. Really the whole character is a useage of the definitions.

I guess I'm not sure what you mean by 'flood the market,' loic.peron. Do you want Enhanced Cars to be available to your other players? Or other users of a given chargen tool?

It seems like a tool could populate a list of Available Cars with Enhanced Car if it were designed to do so...

Can you explain more fully the break you see between the definition and usage approach?

(And thanks, folks, for your answers and discussions so far)

Okay, lets use definition=class and usage=instance to further the object-oriented-language bindings.

You are right in that following the original proposal a character instance would have an instance of a car enhanced with an instance of car enhancement. Everything produced by a generator is only a bunch of instances.

What I want is use the design rules to create a new car/deck/gun/character and have it handy as if it were canon; I mean not all available cars have been listed in any sourcebook, and new models get produced every time. In practical terms it means to be able to hand it over to anyone (including me) to use as he wishes, either players or masters, to use in any program - I do not envision only character generators, but any generator, and eventually any SR-oriented program like a MUD or MMORPG.

Here is then the problem: Yes I can create an instance of a car and add an instance of enhancement to it, but No I can not re-use it as it is not a definition.

Here is the - in my eyes - fundamental problem with this class/instance separation, as it does not allow any reuse of the product of generators, be it a new car, a new gun or a generic gang punk. Or at the expense of doubling all the work needed for programs to produce instances and definitions.

What I envision in a prototype-oriented system, where there are only instances, and thus anything available may be used as a definition, wether it comes as-is from a sourcebook or from a generator.

You may search a by for prototype-based vs. class-based object-oriented approaches - I do not have a good link to provide at this time.

The basic idea is to be abe to use any instance as a template for a new one, and be able to add or alter any new property to an instance. All existing 'Ares Predators' are copies of the original template, but some of these also carry some enhancements. Any one can be used as a template for a new 'Ares Predator II' template if one wishes, for example one with a Smartlink enhancement.

I don't think there is any inherent difficulty here.

All you are trying to ensure you can do is the following;

Building a Character
Select a Gun from Gun Collection
Modify Gun
- Add Modified Gun to Character
- Add Modified Gun to Gun Collection

All you need to do is ensure the definition of the Modified Gun meets the requirement for all gun in the Gun Collection.

Just make the Gun modifications part of Gun properties collection?

See, I'm still not understanding the objection. Unless something uses entirely off-the-walll new features (in which case anything designed to enforce canon or anything like it would fail), I don't see why you wouldn't be able to do exactly what you just proposed with an XML data format.

Though… I just reread the thread, and I'll grant that it's entirely possible that Wordman's proposal is flawed in the ways you outline, and that in general you aren't saying otherwise.

~J

I see no difficulties with XML per se but several with Wordmans implementation, too.

But ... the discussion wether you can ensure consistency or reuse your gunmodel with several chars is *totally* independent of the choice between xml, unformatted ascii, binary-streams, or whatever .. Your data-model tells you in which *format* data is saved (wether on the disk or in ram), neither how it is saved, nor how you read or use it nor how you ensurce consistency . . .
Your data model tells you "XML with the following dtd" or "Object with the following attributes, saved as strings" . . .
Consistency is a question of your program-implementation. Some data-models will make it easier (XML is one of those in most cases) others harder (unformatted ascii).
Some data-models make wtiting interpreters or converters easy, others hard (binary streams written to disk in raw access) . . .
(Reusing is more easy with a nice data model, but it is possible or impossible whatever format you use).
(Okay, maybe I *am* a bit itchy in this field ... But I am studying computer science and perhaps my tutors made me do it)

On the whole I suppose xml would be a fine 'language' to save your chars, guns, . . .
(I am working on a xml implementation atm)