A standard RPG gaming API

[Klintus Fang]

Perhaps we are talking past each other. What manual configuration are you talking about?

The API would define a method to allow programmers to expose those functions that they wish to expose. I imagine that most functionality will be exposed as function calls requiring no interaction with the called programs GUI. It would simply be sitting quietly on the task list, answering requests made via this API.

Some programmers may wish to implement certain functions by invoking their GUI to supply details. But this would in no way be a requirement.

The API would be nothing more and nothing less than a definition of how to talk to one another. What was implemented and the other details would be up to each implementation. It's merely a comm spec.

the manual configuration I'm talking about is the idea that the user might have to manually configure the other application. I realize its up to the designer of the other application. But you cited the manual interaction with the application as the reason that the libraries won't work.

but back to the library issue: there's no reason you can't put pop-up windows and dialogs in your library if you want. so I still don't understand what the tcp-ip connection is buying you, other than maybe the ability to pass information between two computers.

I still think libraries are better, and the reason I've been argueing it so hard is because I've thought about it a lot over the past 12 months. There are lots of great applications out there for doing this or that minor task. And my opinion is that they would all be alot more usefule if the developers would design them as two pieces. One piece is the core computation code that should compile easily on any OS whatsoever. The other piece is the gui that wraps around it and used the library. If they were designed that way (which is trivially easy to do) then it would only be a tiny step to publish the libraries api and let others leverage the work you've done directly. If people are really, really protective of the idea that their name has to be revealed to the user when the library is used then they can put pop-ups or dialogs in the library if they want. But by making that choice they make it so their library will no longer easily carry from one platform to another.

Either way I'm still confused: what is wrong with shared libraries?

I know that opening a tcp/ip port isn't that big of a deal but I still don't see what value it gives you other than adding an extra layer to the means by which developers can share their work.

And I know that I am being stubborn, but I haven't seen any compelling reason for why tcp/ip is better than just compiling as a library and publishing the api? distributed computing is one thing that was mentioned but what rpg problem requires more than one computer in order for it to be solved quickly, i.e., what rpg problem needs to be distributed across a network?

 

[Klintus Fang]

A better (imo) method that would require almost no work at all on the users' parts would be for the group to set up a central (very low volume) server somewhere that would contain a small database of port numbers, schema/envelope urls, user-friendly names, and addresses to download the applications. If this was in place then users would be able to quickly configure the app and say "get spellbooks from this application" (either on a local system or via a SOAP-based web service), "get magic items from here and here," "get names from here," etc. The user wouldn't need to have any urls or port numbers or anything. If the user didn't already have the application in question (assuming it wasn't web-based) then a link would be provided for downloading it or more information.

well, if it is elevated to that level then we're talking about something that makes some sense. but that sounds like a huge undertaking. you've got a chicken and egg problem too I think. You need to converge on a data format and you have to implement it in your code and you need to build the tcp/ip infrastructure into your code. I realize you don't have to write the parser but you still have to write the code that interfaces with the parser and translates the results into your program's internal data structures. I think converging on a data format and then deciding who will be responsible for it all once it is established will be a big obstacle.

 

[DMFTodd]

More random thoughts on things that have been said:

Central Server Web Site: That idea sounds like you'd have to have an on-line connection to use any of these tools. That would be a very bad requirement in my mind.

TCP/IP Vs. File Sharing: I'm not an expert in the field by any means, but I don't know of any standard that shares a TCP/IP port for programs to talk to each other. COM objects, DLL libraries; those I've heard of, used, and written.

"Little" Programs: That's what I think this market is missing as well. I'd like a little utility program that could calculate experience, produce random tables, do random weather, make a random NPC, or other such things. They'd have to be built without a user-interface - just a program you pass info to and get results back (or at least the ability to run that way). I'd pay some money to include those sorts of things with DM's Familiar.

 

[Fast Learner]

well, if it is elevated to that level then we're talking about something that makes some sense. but that sounds like a huge undertaking. you've got a chicken and egg problem too I think. You need to converge on a data format and you have to implement it in your code and you need to build the tcp/ip infrastructure into your code. I realize you don't have to write the parser but you still have to write the code that interfaces with the parser and translates the results into your program's internal data structures. I think converging on a data format and then deciding who will be responsible for it all once it is established will be a big obstacle.

I don't see the chicken and egg problem the way you do. Yes, we'd have to define some XML DTDs and standard SOAP calls first, but that's an issue no matter what. Once you have a DTD defined for a spell, for example, and a standard call to ask for a spell (name alone should be sufficient for direct access, otherwise something with level or just something generic) then you could ask any spell server in the world for a spell, far into the future.

Said spell server could be a local application as well, as towngen is suggesting, so that those who want to sell their applications could provide the same flexibility without having to serve it on the net. The TCP/IP concept is superior to libraries because then they won't have to be compiled/made into any application, but instead can be safely called as new versions of the (serving) application are released. TCP/IP combined with XML and SOAP allow you to write the spec and then add in as many applications as desired at any later time. Since everyone would be using the same basic language for making the requests then it wouldn't matter where the serving application resides, locally or on the net, and it wouldn't matter what OS you were using since the author simply has to know the right calls and use them in his/her code. If at some point in the future you need to update your spec (say, to support something in d20 Modern that's a new concept), the changes needed to each application would be uniform and fairly straightforward, eliminating any limitations or peculiarities of a given OS.

It's all about the ubiquity.

 

[towngen]

Ok, now I think I am understanding you. An no, I don't think you're being stubborn. You're simply speaking until someone actually understands you. That's one of the big difficulties with message boards. So much is lost in a conversation when you're not sitting in front of them chatting. Personally, I think it's cool that you care enough about this to continue to attempt to be heard. So in that sense I say, "Right On Man! Say it again!" Anyway, you're participating in the dialog and I appreciate it.

All that being said I still disagree with the library thing. If there were such a thing as a cross platform object format than any language could compile into I think I would support your idea.

But let's take my town generator for example. I just finished re-writing the entire underlying code from my original hack and slash spagetti code into nice well organized class objects. I would guess that so far about 75% of all the computations are being done inside those class objects. Once I get into the more automated part of the town construction process, more like 90% of it is going to be in those class objects. I have about 3 man-months of work in the code so far. Exactly how can I distribute a compiled cross-platform library from my code without starting over and writing it in C++ and distributing my source code? And even if I did that, what good would a pile of C++ code be to someone who is going to write a program in Java and happens to not know squat about C++? You can't compile it to a relocatable object file with a header file listing all the exported functions because that is platform specific. Good luck trying to get an OBJ written for a PowerPC (Mac) to run on a Pentium, or visversa. Finally, if it is a commercial application you wish to link to, are you really wanting to compile it into your application and redistribute it yourself? I can't imagine many people going for that. However if you mean a library like a DLL, then it's already fully compiled and thus is no longer platform indepentant. Perhaps I'm just a blockhead this evening and I am still misunderstanding, but I just don't see how it's possible. If you see how it's possible, please enumerate clearly HOW I can do what you're suggesting with my town generator written in VB 6.0 because I just don't understand. I'm not trying to be difficult, I just don't get it.

Fast Learner, the web based clearing house for port addresses is kinda cool. It might be simpler to implement as just a local host file formatted somewhat like an ASCII ini file. Everytime a new program comes out they could just include a text file to cut & paste onto the end of the API's host file. Then whenever you ran a program that supported the API, it would read the host file and know everything else out there and what they support. That way no central authority has control over the official list of who's listed. The lines to include would simply be distributed with the program. A small simple platform specific (or non-specific if you can find someone willing to write it in Java) program could even automate the process of updating the host.ini file with the new lines. That would help with version control too. Of course, if we're going to make a program that handles this file, then the file probably ought to be XML instead of an ini style file. But if we gotta have people regularly getting into the file, it better be a real simple format like INI.

Has anyone looked into the DLL question I asked a couple days ago? Does anyone know how the architecture of Linux, Mac, and WinNT handles calling dll's from separate applications? In Win98 I believe it's cool, as long as you call the same copy of the dll on the harddrive, it's the same instance of the dll. In the others, do they invoke separate instances of the DLL, or are they all sharing the same instance? If they maintain separate application spaces for all user-level dll's, how difficult is it to elevate the DLL to run at the system-level so that only a single instance is visible to all application spaces? ... Anyone ... ?

 

[Sm!rk]

Sm!rk, I understand what you are saying, and I agree with some of it in theory.

That was an off-topic aside to address your mention of speed concerns. If it matters then VB should be ignored flat out IMO. However, thats really beside the point the issue as I hear it is that you could write your app in COBOL, and it should be interoperable. (Thats not gonna happen of course, but firm guiding principles are ok, or wishful thinking anyway.)

because that's all I had time to do. I don't really know. I'm just trying to come up with examples. The issue is that I don't know what all people are going to want to export, or import, or why, or what the resources are for people writing these programs, etc...
...

Any sort of sharing will break down if any person is allowed to withhold, or decide what they *want* to export for public consumption. This is what all the OS licenses attempt to prevent to some degree.
What I am hearing and saying is more of a LGPL approach, what you seem to be proposing is RFC formats which are totally open and unowned. For instance TCP/IP is an open standard.

For example I have a port number for a town generator, what commands do I send to it to get meaninful data from it? Is this defined per app, or generically for all apps obeying such and such rules?

You also go on to say that if my app wants a generated town I would effectively launch your app, in that case any system basically equates to a shortcut on my desktop. And at that point tcp or dll it doesn't matter you might as well use export as a means to communication between apps. (ie export an XML data file describing a town, then my fancy diorama program loads and prints that said town out for your to later fold together)

The only real advantage against doing it the export-way is that the interface will be nicer for the enduser. They'll load up my app, click a button to generate a town (which calls and uses your app, preferrably behind the scenes) then prints it out.
Your town generation process could have also used someone elses random store and tavern/inn generator which in turn could have generated from someone elses random NPC or barmaid generator. If that whole trail of processing could be made with one click in my app it would be fantastic.
*But* IMO the interface would suffer if it was anything but invisible to the user. Even if your program is the best interface ever designed, its no doubt different than mine, and any others you use will have the same effect. In the above example there was my app, your town generator, the tavern generator and the barmaid generator. I will generate one town with 3 inns and each inn has 2d4 barmaids, in the ideal I would merely seed those generators with some overall goal and then get little or no interaction with the generation process, it doesn't really matter to a diorama.


There are some other issues (many) one being the communication medium between all these different apps, then there is the issue of building the trail (who said legos?), so instead of fancy pants barmaid generator, I want to hook it to simple old boring female name generator. I don't want a fully stat-ed barmaid, just a name. Who is controlling that lego building, and at what point is it done? Does every app have to include some standard lego building options for each piece of their trail or is this dealt with on the user end behind the scenes of the program logic. An example of the latter is Unix daemons or NT services, you can use any number of programs for your ftp server, but they all talk ftp so thats how that bit of magic works.

And just as TCP needs some overhead of just establishing the communication you will for each protocol (ie PC Generator, Town Generator, Poisoned Wine Visual Appearance Generator.)

 

[towngen]

I agree that REQUIRING a web connection is bad. Being able to make use of one IF it is around is cool, but the requirement thing is bad.

I agree that the use of TCP/IP for communication inside a single machine may seem a bit odd to some at first. But it works, it's not difficult to do, it's a fast link, and every machine on earth has a TCP/IP stack in the OS (ok, not those still running DOS 3.3, but those freaks don't count ) even if they don't have a network card.

I'm still curious about the dll clearing house theory, if only I could get some info on those platforms I know nothing about. I'd really rather not attempt to research it myself and risk getting it wrong. It would be so much easier if someone on here knew and would speak up ... or at least speak up with a guess ...

 

[towngen]

SM!RK, I think I agree with everything in your post except the part about the standard breaking down if they can decide what to export or not. Do I HAVE to export the individual churches that I create that are normally inside the town? The whole standard is for crap unless I can export individual barmaids? What about every possible weird permutation of the contents? I want a function to create towns, but this is a dry county so NO TAVERNS OR BARMAIDS! It just gets too crazy. I gotta be able to limit it somewhere. And the only reasonable way to do that is leave it up to the individual developer what to export or not to export.

The only other caveat I would add is that (as a minumum) I'd like my program to appear as a minimized application, or maybe a little splash screen that can be turned off with a click to the "don't show anymore" option. Or something like that. But then perhaps I'm a bit more picky than most because I wish to sell my program. If it was something that I could just write in a couple days or hours I probably wouldn't even bring it up. But each application must have the right to implement it's own level of visibility. The market will decide and reward those who choose well. If "Joe Bob's BarMaid Generator" has horrible splash screens and constant nag buttons to register and plays the Marcarena while generating, people might be irritated with it and uninstall it. But again, let the individual program decide what to pop. The market will inform the pocket books of those who choose poorly.

As for the question about what arguments a function call to create a town would take, well there are 2 ways I can think of off ahnd to define that. Either we (1) define <waves hand like a Jedi> "All Town Generators will ...." and we write it down and distribute it with the API, or we (2) create a method of the program telling the other program what it needs for arguments. Method 2 could take the form of an automatic query/response between the 2 programs (some extra program complexity required for this one, but it would be slicker), or it could be more simply implemented by publishing an actual human readable document that states what the parameters are. Or possibly some combination of the 2.

 

[Klintus Fang]

I have a few more comments. First, I don't see how having a cenralized server were data is stored and retrieved adds any value for the end user. It's a cool idea, but I don't see how it adds any value. If that data was subject to constant change, or if there was so much of it that it couldn't reasonable be stored on the end user's hard-drive then serving it from the net makes sense, otherwise, I don't see how it serves any useful purpose. It just puts a potential obstacle in the end-users path (if the network connection is down). I don't think any user would like that usage model.


With respect to what towngen has said: you keep going back to the "cross platform" argument for why tcp/ip is better than a dll/so file. And then you use your towngen program as an example. But your towngen program is a VB app so it won't run on anything but a Window's machine anyway so how is tcp/ip solving any sort of cross platform problem in your case?

As far as dlls/so files go: if you write them as non-gui based, number crunching applications there are almost no cross platform issues. True you have to compile the code twice, once as an so file on linux and once as a dll on windows, but the exact same code will compile on both without changes (usually). There are minor obstacles you might encounter if you use some non-standard libraries like linux's readline library, or if you use 64-bit integers with printf's, but aside from minor issues like that, the latest versions of most all compilers nowadays, can compile any code that is compliant with ANSI standards without difficulty. I do it all the time.

Your code's not C or C++, that I understand. It's VB. That means it will only run on Windows. There is no way around that. But a VB app can communicate directly with C/C++ dll's. I haven't done it personally but I know that is how a lot of applications are actually built: write the computational core in C/C++ then plug into it with a VB frontend.

As far as Java goes: I've always disliked java, so I don't really know what is possible with it. It would be interesting to find out if there is a way to export a dll/so interface in such a way that a java app can call it. I don't know if that is possible. If not then tcp/ip may be the only way to go for Java.


Finally, I agree with Sm!rk in one very fundamental way:

*But* IMO the interface would suffer if it was anything but invisible to the user.

You may want to require that the user interact with towngen's user interface directly when a town is created (you at least seem to be implying that). But it's not a good design choice, unless towngen is the most important application the user is using. I've been working off and on on a kingdom generator and so I will eventually need to create scores of towns all at once. In that case if the user has to interact with towngen directly to create those towns, towngen is essentially useless to me.

 

[Twin Rose]

The direction that we've been going with Campaign Suite is leading us towards an "RPG SDK". This means APIs and docs for programming would be available to any and all programmers. We're trying for a bit smoother interfacing for our data files, but all would be fully customizable.

What I would like to see, then, is CS becomming the 'editor' for Campaign and game specific information, with the DLL files and APIs 'open' to all to use, while interchanging data files.

This is an ambitious goal of mine, but much of the ground work is already done. I have a lot of experience writing DLLs, and I even made a dice roller "SDK" (such as it is), available on my site with source included.

I would happily share my process, but at this time, I am working towards making it open for all anyway - that's the point of an SDK, is it not?