Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="nopantsyet" data-source="post: 2136830" data-attributes="member: 3109">That's just mind-boggling!Anyway, I had quite a bit of catching up to do. All good stuff.Your comments illustrate what I see as the first fundamental design decision. What is the line between the data model and the functional API? As reanjr pointed out, you can build a lot of functionality into XML files, including embedding script code. And does the application have functional significance or is it just a user interface?I initially thought I would like every d20 rules engine to have the ability to share data simply by adding a new "Save As" function. But the more I think about it, the more I realize that there are good reasons to include rule information in the data. Namely, usable overrides.Ever try using PCGen with custom data in a group of non-technical people? I felt like tech support. Entities such as characters must be portable. And that includes the overrides and special rules. You cannot expect everybody to load the same versions of the same data just to view a character. Plus, you want to have the flexibility to simultaneously use conflicting overrides. (e.g. two fighters tweaked in different ways)This is where I come to the "unified data model." Because there are statistical and mechanical aspects to nearly every entity in the game. You cannot fully divide them without making important sacrifices to usability. History is a prime example. I think it's very important in order to create a usable application. And keeping with the principle of portability, that should be part of the data of the character. Which places it firmly in the data model. I history being implemented something like this. All changes are stored as atomic entities which are both descriptive (view character at an earlier time or view differences between change points) and functional (roll back a level). I think rollback will be more useful for DMs, who may make numerous revisions to an NPC before putting it into play. All changes should be attributed to a rule (e.g. "Ranger level 4") or an explanation provided at the time of change (e.g. "magical fountain granted permanent +1 bonus to Will save").So where I end up is that there is a data model that contains descriptions/statistics as well as mechanics. In many or all cases, those mechanics will be implicit to the data model:But are there any cases where that might require code to implement something more complex? Are there any spells or class abilities that couldn't be implemented simply by defining modifiers and conditions?Planesdragon - I'm interested to see your proposal. Let us know what happens.</blockquote>

Verification