A standard RPG gaming API

[towngen]

Greetings all!

As some of you may be aware, I am creating a town generation program. Having thought for quite a while about the state of the computer programs that are written for this community, both commercial and non-commercial, it occured to me that one of the big missing things from all the programming efforts is interapplication compatability.

One of the reasons that D&D 3e has been the success it has (IMO) is the whole idea of an RPG standard, so everyone can participate and add something. Granted some of the specific licensing issues seem to have stifled some of the creative contributions people have tried to make, but perhaps we can "get around" some of these licensing issues by letting applications talk to one another.

Suppose I have a great character generation utility. The user interface is awesome, it prints beautiful character sheets, etc... BUT, it only has the core material in it because of licensing and copyright issues. Suppose another utility has all the material I want in it, but I don't want to use it all the time for whatever reason. Wouldn't it be great if I could simply export the character from 1 utility to the other, make some changes, then export it back prior to printing?

Or suppose I really like a certain NPC generator out there, but I can't stand the names it creates for the NPC's. And there is also a really cool name generator program out there. Wouldn't it be cool if I could write a program that would tell the NPC generator to create some NPCs, then import them from the NPC generator, and call the name generator to rename them, then stuff them in a database for by a campaign management utility.

Anyway, this idea would require the support of the other applications programmers out there to implement in their programs to work, but it would allow the end user to <potentially> have a richer and better set of programs to select from. And yes, I do have a slightly ulterior motive I will confess to. I am lazy and don't feel like adding an NPC stat generator into my town generator, it would be much easier to simply make use of another program for that purpose. Plus it makes it easier to avoid having to release the program using either the d20 or OGL licenses if my program doesn't contain any of that stuff.

So, after my feeble attempt to justify why I think this is a good idea, here is my idea:

Let's create a public domain, royalty free, platform independent, programming API to allow for interapplication communication.

So far, the only solution I can think of that can handle such a requirement would be to have the applications communicate through a TCP/IP session. As far as I know every platform in existence that is worth mentioning can talk TCP/IP. You can simply connect to yourself to allow a communications session, but you don't necessarily have to restrict the API to a single machine. A remote machine could have the application you are linking to.

At this point, the communications would simply be a comm channel to allow 2 applications to send strings to one another. We would need to develop all the particulars, such as possibly restricting it to only TCP not UDP, assigning a default port address, figuring out who should monitor the ports, for an how to validate connections, etc...

It seems to me that XML would be the logical choice for the format of the data to send. The API would define a set of specific tags and their meanings. I'm not an expert on XML at all, but from what I've read this seems to be a good way of handling the format of the data. By sending ONLY standard ASCII strings (no binaries), machine independence is assured even if speed is somewhat diminished.

So anyway, please comment on what you think. I'd like to from both developers and non-developers.

Specifically:

From non-developers: Would software that had the ability to communicate like this have much additional value for you? (ie. is it worth our effort to develop?) What kind of things would you like to be able to have programs do for each other? Etc...

From developers: Obviously, I'd like to hear any techinical problems you see with my idea, as well as any improvements you can think of. Do you see any advantage to such a standard existing? Or would it be a disadvantage to any extent? Assuming a reasonably positive response from non-developers, do you think you might implement something like this in YOUR software? Would you like to help develop such a standard? Are there any people out there who are experts in XML that can advise me/us on if that is a good idea, or should a more primitive form of communications be used? Is there any functionality you specifically wouldn't want to share, or viseversa? Etc...

From anybody: Other issues/ideas I forgot to include.

Cheers!

Walter

 

[annadobritt]

Umm. Could you explain in layman's terms what this would mean for the non-developers?

I think I might understand what you'd like to do. Having the other problems be like legos that you could hook together to create a program? Or am I way off base here?

 

[towngen]

if only programming were as simple and quick as legos ....

But yes ... that's kinda the idea.

Each program that supported the API could include or exclude whatever support it wanted.

I suppose some more examples might help stir the imagination some ...

Suppose that Bob the programmer builds an NPC generator. They could choose to expose a function to the API that ... say for example ... created an NPC based on gender, race, character level, and alignment. When they released their program, they would include a document say what they exposed. There should probably be a programmatic way of querying a program for what it supports as well, but that's a tangent for this example.

Then. sometime later, Jack is writing an encounter generator. In one of the encounter tables there is a chance to encounter an NPC party. Not wanting to recreate the wheel, since Bob already did such a great job on his generator, Jack decides that whenever an NPC party is rolled if checks at the appropriate TCP/IP port to see if any other applications are running that respond "yes" to a query "can you generate an NPC". If it doesn't find any such application, it pops up a message box and asks the user to start an "RPG-API" program (if they have it) that supports NPC creation. It might have options to respond, "OK, it's started now.", "No, I don't have it." If the user answers No, it rerolls for something else. If the user answers yes, then the program attempts to contact the other program via the method detailed in this API and Bob's generator does the work returning the answer to Jack's generator.

Now, Jack can write his software faster, because he isn't re-inventing the wheel. He is leveraging what was already written to create something.

Now suppose that someone later on creates a monster advancement tool. Jack might go back and incorporate it's functionality into his program.

Now suppose that Sally has a combat manager utility. They might create a function to "import an encounter", so that the user can directly import the results of the rolled encounter into the combat manager.

What is so cool about this is that all Jack did was expose to the API the work he already did. He doesn't need to have any idea who Sally is, or what her program is trying to do with the data. It simply responds to a request for data.

Suppose that Robert creates a database utility to store created encounters, then feeds them to the combat manager when selected by the user. Again, Sally never needed to know that Robert was going to do that. She simply exposed some of the functionality in her program, and Robert connected to both her and Jack's programs.

 

[DMFTodd]

I think that's an excellent idea (not sure about that TCP part of the spec though, sounds awfully complicated for a user to setup) and something I've been hoping for as well.

Just some random thoughts in no particular order:

1) I've already done something along these lines for DM's Familiar. I didn't want to write a character generator so I wrote a utility that could import d20 standard stat blocks. I then got users to provide PCGen templates and E:Tools templates to create the stat blocks the correct way. It works great!
My point being, this is a valid idea. It's had a real world test.

2) I think there is a d20 XML group out there, somewhere, already trying to decide on a format. I don't know if they've gotten anywhere or not.

3) I don't think the purpose should be to reinvent the wheel, we have excellent programs out there already. For character generation, PCGen is the standard. The project should use PCGen as the starting point and see how to expand on it. For random tables, Bruce Gelke's Tablesmith is the standard. The project should look at how to expand on it. Etc.

 

[towngen]

There is nothing for a user to setup for an internal TCP/IP connection. There is a predefined IP address for internal loopback. All the program does is connect to it at a specific port. The user doesn't have to do or know anything.

The reason I was thinking TCP/IP is suppose that someone on a LINUX machine is running a program in that windows emulator program. And they are also running a program that is in a Java VM. Both should have access to the TCP/IP driver in LINUX, so they can still talk. Everything has TCP/IP. Even Macs ...

Ok, snide comments about Macs aside, I'll comment on your other points.

On importing the stat blocks, are you having the user cut&paste from the clipboard, or using a file? Either way, suppose that the user wants 100 2nd level Orc fighters for a war party. That's either a ton of cut&pasting or a little crunching on the hard drive. But you're right, the idea is identical, just more freeform.

Hopefully, the d20 XML guys will find this. Or else, someone can point them here. I'd love to hear their input.

I agree, certain programs out there have shown themselves well adapted for certain tasks. Wouldn't it be great to make better use of those programs? I think it would increase demand for those programs that expose worthwhile functionality, because other people will create add ons that drive demand for the original program (which you would have to have for it to work).

 

[Brent]

Have you considered SOAP for remote function calls? I like the XML data transfer, I was unaware that someone was working on a standard set of tags. I will have to see if I can find them!

 

[Fast Learner]

Absolutely!

I would *very* much like to see this. I would like it to also allow for external TCP/IP connections so all of the software doesn't have to be local.

FYI the d20 XML group can be found at http://groups.yahoo.com/group/d20-xml/

 

[Klintus Fang]

I too like this idea. It seems to me it has to start with a standardized format (XML does seem to be the way) for the data files.

It doesn't much matter at all if the programs can talk to each other if each doesn't understand what the other is saying.

The issue of having ports open on my machine is a little worrisome to me though. What about security concerns?

 

[Klintus Fang]

For character generation, PCGen is the standard. The project should use PCGen as the starting point and see how to expand on it.

that may be true on for many people, but if I work on anything in the near term its going to be a full featured character generation engine that's built on C++ and isn't hobbled by Java.

 

[Davin]

Good idea

A good idea, but difficult to develop on a wide scope. (For one thing, it's hard to get a lot of people to agree on a standard. For another, you're talking about a ton of definitions to deal with and it'll take quite some time just to come up with it.) I think organization and standardization (as in preparing for connections) is going to be a lot tougher than the pure communication part of the project.

TCP/IP sounds like a good idea if complete interoperability is needed. Coding for TCP/IP communication is easy enough, but there are still technical issues to overcome. For instance, only one program can listen on a given port at once. However, if you restrict yourself a little you have other options. For instance, if your application runs on a Mac (for one example), then its reasonable to assume that any local applications are also Mac applications and you can use any Mac-specific intra-machine communications facilities to best advantage. (But that does keep you from talking to another kind of machine.) For another example, if you're running under Windows you can work with DLL interfaces (or SO interfaces under Linux), giving you an advantage in several functional areas.

You've also got issues about automatically starting up non-specific programs. There's lots to worry about there.

As far as I've been able to tell from my brief contacts there, the D20-XML Yahoo group is concentrating solely on a *character* definition. Thus, anything for exchanging other kinds of data isn't in their purvue and will need to be developed separately.

Klintus Fang - You needed worry about port security as all the communication would be behind your firewall within your own machine (unless you choose differently).

Don't forget that XML, while regular, isn't trivial to parse. Some OS's may or may not have software assistance for that, assuming that they've even got the software up to date for it. Don't assume that anyone (either from the coder's standpoint or the user's) can handle XML input trivially.