d20Engine: Core Mechanic

[nopantsyet]

I am in agreement with those points, JBowtie.

I think it makes sense to use a license that permits commercial uses provided it remails compliant. Should it ever happen, I would see commercial support of this as a good thing.

I have MediaWiki set up on my server. (I also have vBulletin, but I think Wiki better lends itself to this type of collaboration. I don't have a source repository, but I would probably opt for SourceForge for that. But in the end, I don't care as much where it is as long as I can easily mirror it.

Anybody have a suggestion for a name for the project? I've been using d20Engine as a placeholder setting up the Wiki, but it's pretty bland, so I'm open to ideas.

 

[reanjr]

The beauty of ontologies is that they can be modified easily. Because, and get ready for this, we are going to argue over the model. With all due respect (a large amount of respect) to d20-XML, this is why it didn't go anywhere: everyone has their opinion on the "correct model". Perhaps because "using XML" was too generic, and each person's idea of chosen implementation (whether language or approach) was too different.

Ontologies make abstraction of that. As soon as you start thinking about "how my program will load this", you know you are going in the wrong direction. Ontologies are all about "what is this and what does it do?" instead of "how do I use this?", and hence greater potential for agreement on a model (I think everyone will agree, for example, that there are Special Abilities, and that they come in Sp, Su, Ps, or Ex flavors). And you can work on a specific sub-tree of definitions, to aggregate later. Or, if you don't like the "consensus" (or compromise, which will probably be the case), then you replace a branch with your own definitions.



For me, anyway, the ontology will serve to produce "intermediate" libraries which my programs will use (e.g. javascript code generation based on rules, maybe even C++ classes). Each person's program implementation will be different (I see Java, C++, .NET, libxml2, Delphi, Lisp mentioned), but using standards for the ontology and rules means that they will always be able to regenerate the intermediate libraries required for each different implementation. I personally am not going to install a Lisp interpreter in my program, however nice the language is, nor would I be looking forward to coding a Lisp to javascript converter. I much prefer to XSLT/XPath/Parse from OWL to get what I need, and regenerate at will.

My mentions of Lisp are really just to say that an XML-based scripting language ends up like Lisp, so it is worth looking at for ideas. I have no intention of creating a Lisp interpretor. Just a unique way to look at XML.

This is why I will resist anything other than a standards-based ontology, such as using a custom scripting language to define rules (after the PCGen experience and trying to make my tools interoperable with it, I can say that a constantly moving target is no fun).

Well, that's what I am trying to hammer out right now is a standard for the XML to be in that is designed specifically for this purpose. I am focusing on making it self-desribing so that the standard never has to change, but instead you can use the code to the standard to create a new standard. Same basic approach as OWL, I'm just of the opinion that a custom XML language would be easier to work with.

Bah, my job is to babysit executives so they understand what needs to be done (it's called "pre-chewing the food"). So Visio and Powerpoint are my main weapons.

I'm sure you've heard the old adage that Power Point is designed so that your audience can pretend they understand what you are talking about by using visual cues.

PHBs never cease to amuse (annoy?) me...

 

[reanjr]

4) Not everything needs to be defined in the core ontology, and we should ignore stuff that is not in the SRD for the initial version. Future work can extend and generalize.

For instance, ability score generation. We can just ignore that part of the game

I don't see this as "versioned". You add rules as needed. If your gaming group doesn't have a ranger, you need not define the favored enemy rules. The community at large can slowly build up the complete rule set.

To elaborate on the last point - I don't think we need to generalize the core mechanic. Every program can (and probably will) hard-code that assumption. I don't have any books that require dice pools, and when I get one I can owl:import the core ontology and create some new terms and relationships. Unlike OO programming, I can retroactively add superclasses and properties.

That's a big assumption since it is integral to everything else. I've seen house rules on this very board of people who wanted bell curve results, so they use 2d10.

On language choices, everyone is entitled to their own opinion. I think initially it would make sense to use Python because:
1) It's cross-platform.
2) It's dynamic - early on we'll do lots of prototyping and refactoring; having static types will trip up people.
3) Code snippets are short and readable.
4) A lot of the existing RDF/OWL tools are written in Python, short-circuiting the parser problem. Sparta in particular is a cool little library.

4. That's what I was talking about earlier with a particular language used tends to attract developers of that language. While this doesn't matter for the application, that's why I chose XML over something like Java for the rules.

As for the choice of Python, I'm reminded of something I read recently, something along the lines of "After 15 years of evolution, Python has almost accomplished what Lisp did in the 1959." I'm not saying you should use Lisp, of course, I just thought of it because Lisp was on my mind.

For collaboration, a wiki makes the most sense. I'll put together a wiki, mailing list, and source code repository this weekend if no one else has done so by then (space on my website permitting).

That would be cool. It would be nice to have actual documents to be viewing for discussion.

 

[reanjr]

I am in agreement with those points, JBowtie.

I think it makes sense to use a license that permits commercial uses provided it remails compliant. Should it ever happen, I would see commercial support of this as a good thing.

I have MediaWiki set up on my server. (I also have vBulletin, but I think Wiki better lends itself to this type of collaboration. I don't have a source repository, but I would probably opt for SourceForge for that. But in the end, I don't care as much where it is as long as I can easily mirror it.

Anybody have a suggestion for a name for the project? I've been using d20Engine as a placeholder setting up the Wiki, but it's pretty bland, so I'm open to ideas.

I think the work on the SRD file should be well under way before you start on actual source code. Just my opinion. It will ensure that you tailor the app to the SRD rather than the other way around, which may prevent bad assumptions being made and poor end-user design decisions.

I suggest OpenRPG as a name. I really don't think we should ever refer to d20 (unless you are talking about the die) as it is almost assured that we will not be making a d20 product.

 

[Firzair]

I think the work on the SRD file should be well under way before you start on actual source code. Just my opinion. It will ensure that you tailor the app to the SRD rather than the other way around, which may prevent bad assumptions being made and poor end-user design decisions.

I suggest OpenRPG as a name. I really don't think we should ever refer to d20 (unless you are talking about the die) as it is almost assured that we will not be making a d20 product.

Yeah, D20 should be out for the name. But there's already an OpenRPG I think (some app for playing RPGs over the web).
How about RPGEngine or RPGAPI?

On another note: now that I've read a bit about OWL it seems quite functional for describing the rules. But it's a pain to write all that stuff without some GUI as it would be prone to errors.

Greetings
Firzair

 

[nopantsyet]

Good point re: the d20 moniker. I like RPGEngine.

After sleeping on it, I'm back on wanting to keep the core mechanic in the definition rather than the application. We can discuss it more once we move over to the Wiki. I'll slap "RPGEngine" up on the site and try to put some structure in place. More to come.

 

[nopantsyet]

The Wiki is up. I haven't done anything special to it yet other than set up some starting points. Here's the link: RPGEngine Wiki

 

[andargor]

The Wiki is up. I haven't done anything special to it yet other than set up some starting points. Here's the link: RPGEngine Wiki

Since ontologies may be imported, and that we may have several versions of it, it would probably be a good idea to use a specific URL for the namespace. I think that some subdirectory of the wiki (such as where we can dump files) would be a good starting point.

I'm reading the OWL Guide from W3C right now, and I think that when I get back from my business trip I'll start with what seems easiest: classes and instances of spells, equipment, psionic powers, feats (without rules, yet), etc. Essentially what's in my database. Then the Spell ontology may be imported into a "master model", for example.

Then I'll look at SWRL (simply because it's supported in Protégé) to see if rules can be defined for feats...

I'm trying to use the approach where each sub-ontology has no knowledge of the overall model, meaning that it is as self-contained as possible.

And I agree that straight d20/SRD is the way to go, since variant ontologies can replace the existing ones, as required.

Andargor

 

[nopantsyet]

I read the W3C guide for OWL as well. I'd like to find something that delves deeper. Off to amazon.com I guess...

 

[Planesdragon]

Naming

You know, I saw this thread when it was new and I didn't actually *read* the darn thing until it came in my e-mail.

If no one's got their heart set on RPGEngine, I'd like to humbly suggest the name "Prometheus," or "PRD-XML." While I can see an argument for keeping them apart, it would make my own life significantly easier to just be able to use them as one thing.

(Not to mention that we've already waved the logo and trademark license by the relevant bodies, and they didn't mention a thing.)