A standard RPG gaming API

[MythosaAkira]

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...

A good idea, and one I've batted around with various other folks over the years (and you can see what has resulted )

I'll be frank and say that I think the best chance for success with something like this is not programs communicating with one another while running, but having a standard set of file formats for import and export. Communicating via TCP/IP or the like sounds cool, but this sort of thing should be approached in the simplest manner as possible, and then expanded upon as time goes on. With the varying schedules, agendas, and egos of everyone involved, shooting for the stars at the start will result in a lot of talk and little to show for it.

Off the top of my head, I would suggest to first consider what standards are out there (such as the export formats of PCGen and eTools), and work from there. Have a few standards for various things (magic items, monsters, spells, etc.), get a few programs out there using them, and then go from there. Also, regardless of how many people are involved, the main decisions should be made by a few people; committees usually aren't very efficient in that regard (are there exceptions? Certainly - but they are exceptions).

Hopefully these are some coherent suggestions; I'm kind of thinking out loud here. The main thing I'm getting at is that I've seen ideas like this come around regularly over the years, but they are usually too ambitious in the beginning and never end up getting anywhere.

 

[Klintus Fang]

Re: Good idea

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).

If it never goes outside my machine that kind of defeats the purpose of using TCP/IP to begin with, doesn't it? But your right, it's my choice and I probably would instruct my firewall to keep the ports closed unless I knew for certain I could trust the program using them.

In any case I don't see the usefulness of TCP/IP here. But either way, I agree with Mykosa. It would be wiser to start simply with defining the data formats and then writing the programs to read and write in those shared data formats. The first step in intercommunication has to be a shared language or else the idea will probably never go anywhere.

Once programs can talk to each other that way, then I'd say its worth worrying about the issue of dll/so vs. TCP/IP.

 

[towngen]

SOAP? All I know about SOAP is that it has something to do with XML. Perhaps you can explain it and it's merits?

I'm not working on any tags yet. I was going to wait to see if everyone agrees that XML is the way to go. Then try to get some advise from people who actually are familiar with XML (or talk them into doing it!). My total knowledge of XML is what I've read in a few web pages on the subject. It sounded ideal from the descriptions I read, so that's why I suggested it, but I guess I'll have to learn it if we decide to use it.

As for security concerns, I wouldn't worry. The API isn't going to support anything but commands that we want. This isn't opening a pandora's box. We can implement some basic security so that a player can't log into the DM's campaign manager and download the next session's encounter list from the campaign manager. Of course, it would be up to the campaign manager program to implement any security features, but still, the API shouldn't need to support any general purpose file I/O commands or system commands. I would argue very strongly against including anything in the API which would cause any security concerns at all.

I'm not personally going to program in any language except in VB or VC++, but the API must support those who like Java or anything else. Otherwise, we are limiting the support base the API can get before we're even started. This will only work if a lot of people start using it when they make their applications. Eventually, it will develop a life of it's own and become it's own force in the marketplace. It must be able to include everyone. Even Macs ... <sigh> ...

 

[towngen]

Re: Re: A standard RPG gaming API

Mythosa, I agree that the API shouldn't start out too big. But it can be expanded on as we go. The TCP/IP idea is one so that the identical standard will apply for all platforms. Personally, I'd rather just say do it all via the clipboard, or something trivial like that. But TCP/IP also allows the ideas of distributed processing.

As for the comment that you can't have multiple connections to a single TCP/IP port, actually you can. A single winsock object can only have 1 connection, but nothing prevents you from using 2 winsock objects on the same port. How you do think a web server allows more than one person to connect at the same time all on port 80? The web server just creates a new instance of the winsock object and allows a new connection.

Ok, in order to start defining data formats as is suggested by several, we need to know if XML is the way to go or not. What does using XML give us? Personally, I would rather just define it ourselves, but I wanted to hear the arguements for and agains XML first. Why would it be better than just defining a string format ourselves?

Suppose we just created something like this:

OpenSession(<calling program name>,[user name],[password])
CloseSession(<calling program name>)
CreateReturnObj(<unique id key>,<object type>,[attribute list])
CreateEditReturnObj(<unique id key>,<object type>,[attribute list])
ReturnedObject(<unique id key from the create request>,[error codes],[object string itself])
RunCommand(<unique id key>,<command>)
KeepAliveReq(<unique id key>)
KeepAliveAns(<unique id key>,[error codes])
UnrecognizedCommand

As per standard syntax, <key> mean that the key is mandatory. And [key] means that it's optional. Obviously the symbols <, >, [, and ] and not included when really coding.

Open and close session are self explanatory.

The 2 create object calls would each require 2 arguments, and have a third argmument as options. CreateReturnObj would be a command to just create it and return immediately, without any poping of the user interface. CreateEditReturnObj would tell the program that it is allowed to open it's user interface for interaction before returning the resulting object. The unique id's would simply be a serial number so that if multiple requests are being processed at once, it can identify which request it's answering.

ReturnedObject would be the format of the message returning the object (or an error).

The general command would be for other stuff, not when you are asking for an answer, but just want the program to do something.

The keep alives would be for a program to query and see if they are still working on the specified request or not. It would have to be answered quickly.

The unrecognized command would be the standard answer for anything that didn't fit into the above categories (or later defined terms).

The list of objects would simply have to be defined and agreed upon ahead of time. Same for the error codes, commands, and the formats of the objects themselves.

Anyway, this is just something I came up with in the last 5 minutes. Parsing and handling something like this would be very easy. The TCP/IP connection is very easy (just read about winsock if you're using programming in Windows and not familiar with TCP/IP, it's not difficult). We would just have to agree on the list of objects, commands, error codes, and formats of each supported object. As we agree, we add them in to the standard. Everything need not be supported right away, so we can start with a handful of most wanted objects (probably characters, monsters, and treasure), then expand as time goes on.

But like I said, this is just a quick "off-the-cuff" stab at a comm spec that wouldn't use XML. I don't know much about XML, but lots of people talk about it like it's great, so I figured I would hear the pros/cons about it. Anyone want to give and pros/cons about XML?

[can't spell, sorry hehe]

 

[Klintus Fang]

I'm not all that familiar with Comm objects. But I don't understand why one wouldn't just want to write ones code as libraries then compile it into a dll on Windows, compile it into an so file for linux and compile it into whatever mac uses for shared libraries on Mac. Then make it available to people that way.

As far as distributed computing. We're not going to be simulating fluid mechanics problems. Why do we need distributed computing? We'd probably spend more time passing data back and forth over the TCP/IP ports then we would actually crunching data if we took an RPG computation problem and distributed it across a network.

 

[Klintus Fang]

I just downloaded and installed microsoft's MSXML4.0. Which appears to come with dll's and an api that I can use directly from within any C++ program.

I've also been reading through the help files it comes with to get a feel for what XML is all about and I am quite excited by the prospects now.

It seems to basically be a format for laying out a hierarchical structure for you data. And the XML parsers will automatically arrange it for you and give you ways of accessing the content directly via function calls as though the file itself were a class object. It looks like some of parsers actually arrange the file in memory as an unseen (unseen by the programmer) class object that you can then pull values out of and then place values into.

That is very interesting.

XML Schema also look quite interesting too, though I only supreficially can tell what they are for at this point.

I think I'm going to sit down and attempt to implement pieces of the SRD in XML file. And try to encode the rule mechanics themselves.

Just to see if understand how it all is suppossed to work.

 

[chilibean]

Couldn't distributed computing help get around copyright violations. I mean, your not distributing the program, your only distributing the RESULTS of the program.

 

[chilibean]

Klintus, let us know how the XML stuff goes. I'm interested in this.

 

[Fast Learner]

XML has multiple advantages, many of which have been mentioned. The key advantage for us, as I see it, is the way XML schemas work: a schema describes what the xml data you're working with is supposed to look like. As such you can interpret and "understand" the data based on the schema. In a sense a schema is a combination of a template and a meta data description.

The goal of the d20 xml group is to create a schema that can accurately describe characters (including classless creatures, I believe). Assuming they actually come up with something (you'd be surprised how complex it can be), other schemas that would be of value would be a town/city schema, a nation schema, maybe a spell schema (though I think that's included in the d20 xml project), perhaps an "encounter" schema, etc.

With a schema "in hand" an application can interpret xml data intelligently.

SOAP (specifically the RPC -- Remote Procedure Call -- portion of it), as I understand it, allows you to create and pbulish a method for calling a procedure remotely (passing xml data back and forth). For example someone could write a SOAP-compatible "character name server." Using the definition for this server's SOAP procedure call you could basically tell it to execute a procedure (like NewName()), along with some parameters (like "race" or "quantity" or what have you) and the server would return an xml stream containing the name (the format of which would be defined by an xml schema). Effectively it allows you to ask other applications to execute procedures and return information to you.

All super-keen stuff.

 

[towngen]

Well, I've looked into XML a little more and it does seem like I don't have to worry about parsing the XML text. I can just get an activeX control to do it for me. I assume that a similiar prepackaged block of code exists for java as well. So VB, VC++, and Java as have relatively easy access to XML parsers.

It seems to me that we should put a proprietary wrapper around the XML data that would be unique to our imprelmentation of it. That way, only someone who has written a program to the RPG-API can even get their XML data to the parser. That would be an extra level of security.

XML is starting to make me kinda nervous though. Can a tag be imbedded in XML that causes the parser to run some code? If so, then a malacious person could possibly get into your computer via an imbedded XML tag (something like putting a VBscript into an HTML email which is run automatically by Outlook to spread a virus). So if we are going to use off the shelf parsers for the XML stream, we need to be CERTAIN that things don't get out of hand. Does anyone here know about this?

Does anyone know enough XML to create the functional equivalents of those couple functions I wrote in a previous post in XML?

The reason to use TCP/IP comes down to platform independence. Is there any other way to create a platform independent method of interapplication communication? Sure we could use the file system. Everything understands ASCII text files. But that is order's of magnitude slower than a internal loopback IP connection. So people are already complaining about Java's relative slowness. What if 1 java application is talking to another through the file system? Think about compounding time delay effects when you consider the order of a single string getting transfered: open, write, close, flush file IO buffers, wait for receiving program to notice a new file exists in the common directory, open, read, close. That is in comparison to a TCP/IP triggered event in the receiving program that never had to wait for a physical disk drive to actually do anything.

The other issue with the file system is that it prevents distributing computing unless you want to deal with REALLY slow connections and all the security headaches of opening your file system to the whole world. Programming a connection with winsock in windows is very simple to do, both in VB and VC++. Considering how much web stuff has been written in Java, I can't imagine talking to an IP port is any kind of issue at all in Java.

Klintus, I'm not really sure what you are suggesting with the libraries thing. Do you mean distribute source code? I doubt any commerical applications would ever distribute their source code. I don't plan to distribute the source to my town generator. It's written in VB. The source wouldn't do anyone any good on a Mac or a Linux box anyway. Anything that involves distributing source code isn't going to work.

The issue of skirting license agreements with distributed computing is exactly one of the reasons I like it so much. I can write my program without including any OGC in it, but still have access to that material by using someone else's program that does use OGC material. Plus, if there are only certain things that can be done with OGC material in a program, if they expose the results of their program to others, then the programs that don't have any OGC in them, but merely import a finished character for example, can do anything they feel like with it. After all, how can they be bound to the OGL, if their program contains exactly ZERO OGC?

Have you ever noticed that when someone gets stomped on for a copyright violation the demand is always, "stop distributing that program". This is exactly complying with that. You aren't distributing the program. You are distributing the results of the program. So does it constitute a copyright violation? Can I legally create a character with paper and pen and the books and mail it to my friend? If so, why can't I automate the process?

Anyway, back to the API discussion, how would a person make a SOAP function call in VB? Is there a SOAP activeX control, or is it a dll call? Where can I get this functionality and add it into my VB program? What about VC++. If it's only a Java library for XML then it doesn't do us any good. Is it usable on a Mac? What about Linux? What if I wanted to write a Win32 console application?