D20 Modern supplement available [RolePlayingMaster]

[Twin Rose]

Gee, I dunno. If I as a DM am using CS and one my players is using PCGen [for whatever reasons], would certainly be nice to be able to take his character from PCGen and have it available in CS so that I could use use CS to keep track of its stats during the campaign.

I hate to say it, but thats not a terribly hard concept to grasp.

Not since you were referring specifically to proprietary technology.

Thats nice, but its not useful to me.

Yeah, I read you loud and clear. You want to have a tool that does everything you think it should and in completely proprietary formats that if an enduser who purcahses it doesn't think it does everything he needs it to do, but wants to utilize data from parts of it he does use in other programs, he can't.

Its wonderful in this day and age where the big players are putting together ideas like Web Services [and no, I won't debate whether they will take off or not] and looking at how to allow people to distribute data between different platforms with as much ease and security sa possible, that some small botique software vendors are still stuck in the "dark ages" so to speak.

The OGL, which I ams ure you are familiar with, rather makes proprietary file formats difficult. They need to be human readable AND human understandable. All the developers provide documentation on the files use. But many of us are too busy moving forward to take the time to look back, though it is certainly planned to work that way eventually. We are taking steps to work together, but it's rather difficult when you are talking about developers literally spanning the globe.

 

[Hollywood]

.lst is a proprietary format yet because no other software uses their format. Get the point? Additionally, saving character information if you reference an open 'datasource' of OGL'd data could be fine as a closed file format.

The OGL, which I ams ure you are familiar with, rather makes proprietary file formats difficult. They need to be human readable AND human understandable. All the developers provide documentation on the files use.

But many of us are too busy moving forward to take the time to look back, though it is certainly planned to work that way eventually.

Often too many boutique, and no I'm not saying you fall into this class and it applies to non-boutique vendors, simply code-and-go rather than actually plan things out, in other language go through a design phase and produce a design document, in the first place. So it would not be surprising to see folks continue on divergent courses, etc.

We are taking steps to work together, but it's rather difficult when you are talking about developers literally spanning the globe.

Funny that you mention that, but there are many successful projects out there whose developers span the globe... Linux kernel, JBOSS J2EE app server, NetBeans [with a lot of help from Sun], etc.

But whatever.

 

[Twin Rose]

Funny that you mention that, but there are many successful projects out there whose developers span the globe... Linux kernel, JBOSS J2EE app server, NetBeans [with a lot of help from Sun], etc.

But whatever.

You're still talking about seperate platforms, by seperate people. CS was the first, or one of the first, released with others coming later through beta trials and final releases. I can't possibly predict who will be next, and I really see no need why I should go out of my way to hunt them down - my days are busy enough trying to scrape out a living doing this that adding to it just to help others makes no sense. They are welcome to come to me, I've shared my data, worked with people like Todd who approached me. But to do constant searches for others, trying to get their attention, asking them what I can do for them isn't good business sense.

 

[Hollywood]

I can't possibly predict who will be next, and I really see no need why I should go out of my way to hunt them down - my days are busy enough trying to scrape out a living doing this that adding to it just to help others makes no sense.

Ok, hows this.. take ENWorld, its a well attended place by most people looking to hawk software for d20, no? So if you post something that you are looking to form a group to talk about putting together common formats for certain data or ways of doing things to benefit the END-USER, I bet you'd have some interested parties talking to you. You don't need to take lead it, but it takes 5 minutes to start if off.

They are welcome to come to me, I've shared my data

I'm scrounging the site looking for the data/scripting/et al. formats.. none available.

But to do constant searches for others, trying to get their attention, asking them what I can do for them isn't good business sense.

No, but providing a good experience for the END-USER who buys your product is. And if being able to import/export information from PCGen because the END-USER prefers that program to create characters in, but likes CS to use at the table, gets you another several hundred sells, its in your interest to pursue it, no? Better off, it'd be better to allow PCGen [used as an example only] to have information on your formats so that they could write a CS importer/exporter and thats less work for you and gives more value to your END-USER. However, if both PCGen and CS had, along with other 3rd party vendors, had agreed to use the same format [we're talking about future versions, not current versions mind you], then there wouldn't need to be import/export tools and neither of you would have to write stuff for the other.

And to get back on topic, Luke put together the d20 modern, or a subset of it, for RPM. If RPM, CS, PCGen, DM Whatever, etc. had agreed to utilize a common format... boom, your END-USERS could get RPM's d20 Modern download and you wouldn't have to do that work, but maybe you would add the vehicles section to it and Luke wouldn't hav eto do that work, etc. As is right now, CS customers either need to wait til you release d20 Modern download, or do it themselves while RPM END-USERS are happily creating new stuff for the quesiontable d20 Modern rules.

 

[Twin Rose]

And to get back on topic, Luke put together the d20 modern, or a subset of it, for RPM. If RPM, CS, PCGen, DM Whatever, etc. had agreed to utilize a common format... boom, your END-USERS could get RPM's d20 Modern download and you wouldn't have to do that work, but maybe you would add the vehicles section to it and Luke wouldn't hav eto do that work, etc. As is right now, CS customers either need to wait til you release d20 Modern download, or do it themselves while RPM END-USERS are happily creating new stuff for the quesiontable d20 Modern rules.

He did it differently than I am doing it, basically making d20M an extension of the current SRD - which is something I'm doing differently. In fact, I'm trying to allow for greater flexibility as I can see where the trends are going. His scripting language is different from a data-file with scripting code in it - and PCGen uses .lst files that I'm not 100% comfortable with in that I feel they leave a chance for OGC to become a part of code. That's okay for them - they have an open source project. Tapping the RPM script would require extensive coding, and even mroe so I believe every time some 'new' D20 rule came down the pike. As you can see, we have different philosophies as well as different products.

The end result might make for characters to move from one to another, in fact plain ol' text statblocks seem to work for most, but certain aspects are just plain done differently. Each, of course, we believe is best for the ease of use of the end user.

 

[Luke]

Very much hijacked...

(Luke's thread has sort of been hi-jacked. )

I'll say. I certainly welcome all sorts of community discussion, but I started this as a kind of "press release" on a free RPM download, and I'm very surprised at Chris taking the opportunity early in the thread to advertise his own program and its future directions here. Nothing prevented Chris from starting his own thread.


I had thought that there was a protocol of politeness that we all basicly adhered to.


I noticed a "Genie rocks" post appear within 2 hours, that looked a lot like an ad. It was by somebody anonymous that had registered for their first post. At least that was amusing.

Chris, when a developer makes an announcement, and a competitive developer makes a counter-announcement on that thread, along with criticisms of technology choices - don't you think it starts to suggest a nasty turn on these friendly boards?

Some info for you on RPM:

- RPM has an extremely flexible development environment within in it, that doesn't require me to rip out code and replace it. Anybody wanting to take the time can add their own stuff to what is a very flexible framework for this. In fact, there is no special built-in coding for a Monk's BAB, or even Cleric domains. RPM's flexible framework allows for it, so anyone can do it.

- RPM already has a COM component in it that contains a chat capability and can make network connections that can even access the full scripting environment within RPM. So far there hasn't been much call for me to extend and really use it.

- There's no problem using maps from other sources, and the RPM sample dungeon uses maps from CC2 and DungeonCrafter. This should be a no-brainer.

- RPM is not new. It has been available for download for almost 2 years now, with open invitations to the community to download, try and make any suggestions to the development of the program. The development is "market driven", in that I work on what the community tells me is important.

- RPMs scripting engine inherits a built-in capabiity to deal with XML. I look forward to the arrival of good XML content. I've actually downgraded my personal, internal use of XML, since I've found it to be generally great for communication ( basically import/export), but terrible for database storage. In my experiments with multi-tier on-line database editors with XML, I found images to be a particular problem (not that much of an issue though).

- In short, I believe that my choice of technology balances the best for major requirements:- power to people wanting to create their own content, lots of editors for them to do it with, powerful scripting capabilities to get fancy if required, fast database/memory caching for instantaneous character/creature recalculation on the fly.

As far as I can see it offers unparalled, properly integrated power for character/creature development that fits right into adventure building and in-game play. I don't see any other in-game play solution that easily does templates, levelling etc to near the same degree.

 

[Hollywood]

The end result might make for characters to move from one to another, in fact plain ol' text statblocks seem to work for most.

Not when they don't take into account custom feats, classes, abilities, equipment, etc. and send that data along with it. Without that extra information, if needed, the statblock is pretty useless.

Tapping the RPM script would require extensive coding, and even mroe so I believe every time some 'new' D20 rule came down the pike.

No, I believe thats Luke's point is that by encapsulating the actual game mechanics code in script, anyone can add something new even to a closed program. Correct me if I'm wrong Chris, but last I looked, I couldn't manipulate the game mechanics with your program to allow for my house rules - a simple example would be; we allow cross-class skill limit to be the same as the class skill limit, no double jeopardy. That would be one of the most simple house rules.

Each, of course, we believe is best for the ease of use of the end user.

Have you actually done feasibility and usage studies on this? Or are you just relying on feedback from those who take the time to download a trial version or actually purcahse it? Best for yourself is not always best for anyone else and often you will find that what, with all the best intentions, what you think is best for the end-user actually ends up being the worst.

(Luke's thread has sort of been hi-jacked. )

Sorry, that was completely my fault.

Chris, when a developer makes an announcement, and a competitive developer makes a counter-announcement on that thread, along with criticisms of technology choices - don't you think it starts to suggest a nasty turn on these friendly boards?

I don't necessarily get the feeling that was the case, at least I hope it wasn't.


- RPM has an extremely flexible development environment within in it, that doesn't require me to rip out code and replace it. Anybody wanting to take the time can add their own stuff to what is a very flexible framework for this. In fact, there is no special built-in coding for a Monk's BAB, or even Cleric domains. RPM's flexible framework allows for it, so anyone can do it.

- RPMs scripting engine inherits a built-in capabiity to deal with XML.

What scripting language are you using?

I look forward to the arrival of good XML content. I've actually downgraded my personal, internal use of XML, since I've found it to be generally great for communication ( basically import/export), but terrible for database storage.

Yes, thats exactly what I've been saying.


As far as I can see it offers unparalled, properly integrated power for character/creature development that fits right into adventure building and in-game play. I don't see any other in-game play solution that easily does templates, levelling etc to near the same degree.

 

[Twin Rose]

>> Chris, when a developer makes an announcement, and a competitive developer makes a counter-announcement on that thread, along with criticisms of technology choices - don't you think it starts to suggest a nasty turn on these friendly boards?

Actually, if you look again, you'll see that I was making a jab at Leopold meant in fun between myself and someone I know rather well. It sense escalated witht he questions and etc that Hollywood posted, which I tried to address. I didn't mean it as a criticism, you will also see that I clearly posted that they were different philosophies and ones that I couldn't go back and change now - whether I wanted to or not.

Additionally, you will notice my expressed desire to work with other developers on things, and ways that I am working to try and fascilitate that.

 

[Luke]

Not when they don't take into account custom feats, classes, abilities, equipment, etc. and send that data along with it. Without that extra information, if needed, the statblock is pretty useless.

Exactly right Hollywood.
I get a lot of requests to do a PCGen import, but I'm not at the point of doing it properly - and I'm not prepared to pretend that a statblock import will do the trick. If you have special sources (3rd party races, classes etc) that aren't in the target system, the target system can't do a proper job of maintaining it.

The game mechanics behind the races, templates and classes is extremely important - especially to a system like RPM. RPM will let you fiddle extensively with characters/creatures - adding and subtracting templates, classes, or even the base. I make a special point of recording the raw roll ability dice rolls for that reason, since extensive playing revolves around that. This is great for a DM tinkering an adventure.
The in-game mechanics of RPM also mean that the mechanics behind that statblock is important. For example, if you add the magical "Disruption" ability to your mace, and crit a creature, RPM can determine if they're undead, and prompt for the save.

No, I believe thats Luke's point is that by encapsulating the actual game mechanics code in script, anyone can add something new even to a closed program. Correct me if I'm wrong Chris, but last I looked, I couldn't manipulate the game mechanics with your program to allow for my house rules - a simple example would be; we allow cross-class skill limit to be the same as the class skill limit, no double jeopardy. That would be one of the most simple house rules.

Right again. I've actually planned for this kind of eventuality from the start. The game mechanics in RPM are effectively "open-source".
To begin with, the mechanics are typically attached to the things they effect (eg the skills, feats, classes, races themselves). This means that the sources you activate for your current campaign will activate the code you require for those sources.

That said, there are still plenty of *core* rules that may also be affected.
I've also planned for that. The "Game Rules" configuration section of RPM will very soon have the "Source" field, meaning that it acts like all the other tables (feats, skills, races, items etc), and only shows and uses what you've chosen.
In addition to that, you can add you're own house specials into "Game Rules", and you can selectively turn certain sections on and off.
I find these days that I do comparatively little work on RPM itself. For example, anybody could have done the "D20 Modern" I just released. RPM itself didn't change one bit, since I just used the existing framework.
That's how I got it out within a few days of the SRD being released :
1 - Create a new "Source" and set it as the default entry.
2 - Just copy-and-paste for the encyclopaedia.
3 - Use of the open editors for classes, feats, skills, abilities etc.
4 - Export the source, and stick it up on the web page.

I plan to soon split the RPM "Core" source into "Core" and "Core fantasy". That way, you could play a Modern or Sci-fi game without having spells, skills, and races appear as inappropriate options. If you really want meta-magic feats, then turn them on "Core fantasy". The Psionics already has its own source, so you could mix it easily with D20 Modern, using 2 mouse clicks...

To be honest, I'm sure Wizards planned for separate StarWars, SciFi, Modern etc genre from the start. I'm surprised that a distinction between core and core fantasy wasn't built into the core books - as with GURPS.

Sorry, that was completely my fault.

Not a problem, and I didn't mind your comment, as I didn't mind Leopold's. Leo didn't even mention PCGen (which I would have been cool with anyway) - pretty different from Chris, who carried on about CS and included some comments about RPM that were inappropriate and wrong.

What scripting language are you using?

Essentially its a super JavaScript, enhanced for RPG. I picked it because:
- Its very fast.
- Its object-oriented (allowing for rule replacement).
- Its available on every Windows machine.
- Many, many thousands of people already know it (through web programming).
Those are are interested have shown independant ability to modify the scripts for their house rules. There are plenty of examples of the super enhancements to see how it entends the basic JScript language.

Regards,

 

[Hollywood]

Ok, I'll have to respond when my head's clear of beer.... too much to digest right now!