A standard RPG gaming API

[Klintus Fang]

I have a dice rolling dll/static library that I wrote as well. It abstracts away the random number generator and instead provides a series of die data objects. It also over rides some of the basic operators so you can put the "dice" in arithmetic expression. I even over rode the ',' operator so you can write things like:

int damage = 2,d6 + 5;

in your code. The library then generates two random numbers from 1-6, then sums them together with the number 5, all inlined of course.

You can derive from the class that constructed these default objects and create your own (arbitrarily complex) "dice" as well.


But I never distributed it except to one person. I mentioned having it at a message board a while back and no one expressed interest except that one person.

 

[Davin]

what rpg problem needs to be distributed across a network?

One possibility is to actually host special data or computations on a particular site where it is not permitted, illegal, or infeasible to put it on everyone's computers.

 

[Davin]

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.

Oh, you mean like web browsers, email, FTP sites, file & print servers, etc.??

 

[Klintus Fang]

Davin: that is true. I thought of that too.

but the only person who has the right to distribute such content would be the owner of the content, and that is not any of us.

my philosophy there is let them worry about how to distribute their content. it's their's after all. and the companies who are really protective of their content and refuse to distribute it under the OGL or something similar aren't likely to distribute it online through some means created by a handful of people on the internet unless that technique has become so enormously pervasive that there is no other logical choice.

 

[Klintus Fang]

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.

....

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?

This is an excellent idea. Of course it does probably lock out non-windows users. Or does campaign suite compile on other platforms? but at this point, even though I like and use linux, I don't really care about that anymore.

shoot, I even develop my linux code nowadays using MSVC++ because that development environment is so amazingly convenient.

 

[Twin Rose]

This is an excellent idea. Of course it does probably lock out non-windows users. Or does campaign suite compile on other platforms? but at this point, even though I like and use linux, I don't really care about that anymore.

shoot, I even develop my linux code nowadays using MSVC++ because that development environment is so amazingly convenient.

BCB 6.0 will compile to Linux and MAC native environmetns, whether or not this works for libraries (obj files, DLLS, whatever) remains to be seen as I've yet to really get into the platform as much as I would like. I'll find out and be sure to keep everyone up to date

 

[Klintus Fang]

well, gui's are always the problematic issue there, though there are multi-platform gui development packages out there. I've never used them, don't know how good they are, and don't even know what they are called, but I do know that at least one exists on the market.

 

[Sm!rk]

My mention of standard breaking down weren't so much about what features you choose to implement, its deciding to use X, Y and Z generators in your generation process but then not sharing the end result in kind.

Frankly, with VB there is no other option for you. While VB and Java can both use C/C++ libraries, that is not the case for VB going the other way. I doubt you can make any sort of sharable component with VB short of maybe activeX controls. But in regards to what a few have already said, there is no cross-platform-ability with VB at all. So the point is now confused in my mind, huh?


At some level I see no difference with using libraries and TCP as the communication. Libraries will no doubt be quicker since the bindings are in place and don't have to be renogiated with each connection. And TCP or any network protocol offers obscure thoughts like a real random die server on a linux machine connected to a radioactive source, which I can poll to get random die rolls from my Palm or PPC. Of course random NPCs or whatever, might be an interesting thought for ad-lib LARPs where you manage and create everything on the fly and get streamed the data to a PDA or notebook.
Or even "real" living worlds, where DMs from anywhere can download time segments that they then run with their campaign. Then later they upload specific changes, like thief guild member Snarky was killed. PC X and Z purchased the shoddy warehouse at 123 Port Road.

Thats just some examples you could find many different uses. So it is powerful, but what kind of work load will it be to finalize a standard for the interoperability of any number of apps. And you'll defintly need some standard or else who else will be building these other useful products? In this sense GPL and the like are contracts between different programmer that say, you don't rip me off, I won't rip you off (In an untrusting world...).
And while the lego analogy is appealing, there is no way this can be as simple as lego interoperability, where you have one inny nub, and one outty nub.


Anyway to interject some egoism, I wouldn't mind coding to some adopted standard agreed upon by a community at large, but there is very little chance I would code to an SDK from one particular developer, unless they own the world like MS does.

 

[Klintus Fang]

The last application you describe Sm!rk sounds a lot like NWN or Everquest or Ultima Online!

As for coding to another small developers SDK, how comfortable I am with that really depends on what the development environment looks like and how restrictive it is. If its simple, lightweight and doesn't force me to code in a way that complicates my coding style I'm fine. If it ties my code in someway to the owner of the SDK or allows that owner to leverage my work for its profit I am not happy with that.

I have to like the tool the code links in with too. And I am still undecided about CS. But I wouldn't say I'd never work in such an environment.

A freeware SDK would be nice.


But anyway, back to the very original point of this thread: I think that establishing a data format should come first and in any case is required no matter what the other details end up being.

I don't have a lot of experience defining data formats, other than hacking up our own off the cuff formats for in-house tools at work. I'm intrigued by XML because an XML data definition appears to have the feel of a class definition. I feel like I'm designing a class hierarchy when I take a stab at encoding something in an XML format. The two things appear to compliment each other very well. And I have lots of experience with the former so the latter seems pretty straightforward because of it.


In any case, I keep mentioning (I think it was on another thread) that what I would really like to do is encode the SRD game mechanics in an XML format (or something else if that turns out to be better). I envision being able to do things like, check the rule_definitions.xml file to see what the stats are. Abstractly I'm thinking of everything as a "stat". Ability scores are stats, a character's race is a stat. A character's name is a stat. I'm trying to figure out if some carefully defined schema could encode the idea that stats exist and that there are rules for constructing "things" that contain "collections" of stats (characters, monsters, or at a lower level, pieces of equipment) and then rules for transforming those things (leveling up characters, adding or taking equipment away from characters, killing characters , or whatever).

I'm wondering if it's possible to encode it all in such a way that it is then possible to build a model of the rule system from the rule_definition file without assuming anything about the rules other than the most basic primitive things (in fact I know it's theoretically possible (after all my mind is able to construct an ad-hoc model of the rule system just by reading the SRD as is...) but is it practical?).

Does this seem implementable? Is it a waste of time to implement even if it is doable? I'm curious what others think, but I don't want to hijack this thread either.

 

[Luke]

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.

Functional decorations is a big issue to watch out for. You don't notice it too much if you're always using the same compiler and libraries built with the same compiler.
Essentially, at a machine-code level, the functions in the DLL and the code calling the DLL, need to agree on many things for it to work.
This includes: what name-mangling is done (eg does an underscore get put on the front of the function name, or does the name get capitalized), how parameters are passed on the stack (left to right, or right to left), and who cleans up the parameters off the stack (the caller, or callee).
Generally things default to an industry standard of _cdecl, until Microsoft threw out a typical "decommoditizing protocol" on the standard, so that you virtually have to wrap every export function with another Microsoft DLL using properly "_cdecl"ed functions, to get cross-compiler portability happening.

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.

Using C++ in DLLs is typically only any good when the same compiler uses the DLLs, as was used to create the DLLs. Just about every different C++ compiler does their own variation on name-mangling, which makes the function names in DLLs useless to any other compiler (or VB app).
You can get away with exporting 'C' functions from your C++ work, if you decorate them properly.
You can check out different compiler DLLs with utilities like Quickview, so see how different the name-mangling is.

This sort of thing is possible if you carefully set all the right standards in place, and all the developers stick to them.



In general, I'd have to agree that Java is, unfortunately, the best way to port code libraries around. You pay for that with speed and deployment issues. Suddenly, everyone needs to buy-in to the download and installation of a Java run-time on their machine. If you've noticed that PCGen requires you to occassionally update the Jave run-time you have from Sun, you start to appreciate that more standards need to be put in place for Java configuration management, that everyone has to adhere to. One person in your big chain of interconnected software can cause you to need a large download and update. I couldn't personally tell you if that would cause backwards-compatibility issues with other existing software, but I've certainly seen it where different versions of 3rd party material is used.
I gather that a segment of the PCGen community find the Java run-time updates a pain, and that's just for a *single* app.

I think that the SOAP/XML was perhaps the best portability solution mentioned so far. It is the single, genuinely portable way to pass information around, and call functions with parameters (web services). It's essentially is a "nice" layer on top of tcp/ip, with the benefit of working for those stuck behind firewalls.
Whilst this sounds attractive in putting together a massive RPG utility, composed of different RPG functions spread across the web, this too has a large number of problems:
- You have to be on-line to make it work.
- All contributors need to have reliable servers constantly on-line, with decent develop and testing procedures that keep the services available.
- You pretty much have to run a web server of some kind to make your service available.
- There is a *big* issue with version control, where the service providers and all clients are talking the same data formats. This is much harder than the very slowly progressing D20 XML project, where it addresses the relatively simple task of simply defining the database content.
- It's *very, very* slow, compared to binaries (EXEs, DLLs, SO). Just stop to think about calling a name generator service 20 times to generate an NPC party on the fly. That's just a *name*, with potentially classes, equipment, skills etc to follow. Though you could get single services to package large result sets independantly, that's not the spirit, or intent of capabilities.
- I'd predict that SOAP/XML is pretty unfamiliar to most people who would otherwise like to get involved in such a project.

In all, as a person reasonably experienced with managing and implementing medium to large size developments, I see so many pitfalls concerned with managing the whole process (from requirement specification, through to implementation on an agreed platform capable of delivering expectations, through to on-going configuration management), that I would predict a very hard (but perhaps fun!!) road for those embarking on it. Chances of success would be quite low, or at least, well under the expectations of those eagerly watching on and waiting for it.