I agree with everyone.  I, too, started to come up with the same
design that Laura showed, but concluded as Jacob did that there's
a point where your abstraction goes too far;  that it may finally
allow all things to be represented, but has gone past "useable".
And it was the limitations in Neverwinter Nights that made me want
to go that far.

So where does that leave us?  Is there a line that can be made
where some rules are coded, and some are in data, that take care
of all cases, or are we eventually going to hit the same problem
as Bioware did?

--
  Crwth


|| From Jason:
|| 
|| 
||  --- Jacob Proffitt <jacob@...> wrote:
|| 
||  > Okay, two replies to the same post is weird.  I just want to make
||  > sure you
||  > don't get the feeling that I'm denigrating your design.  I think it
||  > might be
||  > the only real solution that has a chance of success given that you
||  > want the
||  > xml to contain the full and complete description of your objects.
||  > It's a
||  > good design given that requirement.  I just wouldn't personally make
||  > that a
||  > part of my functional requirements is all.
||  > 
||  > Jacob
|| 
||  One key piece of making all the rules fit within the XML is that it
||  makes it very easy to separate the Open Gaming License content from the
||  code. If you can factor the rules into the XML, then it is easy to say
||  that the XML is Open Gaming Content and the code is whatever license
||  you want. Strict adherence to the Open Gaming License very nearly
||  requires this.
|| 
||  Also, I think Laura's design has another thing going for it,
||  abstraction. With something like what it appears she's aiming for, it
||  could be quite possible to create a generic D20 engine in code and then
||  have the XML to specify the parameters of a game or character creation,
||  whatever. Such a system maybe more cumbersome for the programmer and
||  designer of the XML, but in the end it pays off in flexibility. You
||  could use the same program to do your work for multiple D20 games by
||  simply pointing it at a different XML ruleset.
|| 
||  That said, I fully understand Jacob's point. There's a real value to
||  having something that you can use sooner rather than later,
||  particularly in a hobbyist endeavor, or even when you have a deadline
||  looming. I'm not knocking Jacob's position, really. I'm just pointing
||  out two very strong advantages of complete separation of code and data
||  in this case (if you consider the XML to be data).
|| 
||  If you look at one of the most prominent D20 computer games available
||  today, Neverwinter Nights, the designers definitely followed Jacob's
||  idea of mixing code and data. Some things in NWN are hardcoded, but
||  much of the game can be changed by a module builder by modifying the
||  2DA files that describe things. However, some of the things which they
||  chose to hardcode forced them into compromises later. For instance,
||  they were unable to properly implement the spell casting prestige
||  classes because they had hardcoded the list of spell casting classes
||  and spell progression tables, and I guess they felt it too much work to
||  go back and add new ones or to change it so that the spell progression
||  could be stored in external data.
|| 
||  I guess there's a lot to be said in favor of either approach, and which
||  one you choose depends a good bit on your goals for your project.
|| 
||  Cheers,
||  Jason
|| 
||  __________________________________________________
||  Do You Yahoo!?
||  Tired of spam?  Yahoo! Mail has the best spam protection around
||  http://mail.yahoo.com
|| 
|| 
||  
||  Yahoo! Groups Links
|| 
|| 
|| 
||  
||