Log in

No account? Create an account
FF Sparks (Casual)

Riverdark Project

So, in an effort to feel like I'm doing something useful outside of work, I've sort of started to revive work on the Riverdark Project over the past few weeks. I've decided to re-do a lot of the code in hardcode, and make it simply possible to override in softcode. I'm going to create an RDP plugin module for TinyMUSH 3.1, which will provide core functionality all RDP systems will use; other modules of RDP will be loaded by the RDP plugin module, rather than as standalone TinyMUSH 3.1 modules -- i.e., only 'rdp' will ever show up in the modules list in @version, but something like '@rdp/version' would show you all the version info and all the installed RDP modules.

I've begun to prototype RDP's module API and some of the core stuff -- I'm making RDTags into hardcode, as well as several other support systems I always use. Why am I posting about this? 'cause I'd love feedback from those who are at all familiar with the design I've been doing for RDP, as to what they'd like to see. I was initially considering making RDP require MySQL, and hardcoding it to use a SQL data store, but I'm not certain that's the best path, for instance.

Feedback? Ideas? Questions as to what the hell the Riverdark Project is? :)


*Raises hand*

I'll bite. What the hell -is- Riverdark?
The idea is to create a core system that plugs into MUSH and provides a complex, theme-independent system for building a game. Sort of like how Firan is, but designed from scratch.

So the basic RDP module would provide some core functions that all modules would use, and some core administrative commands, and support for reading RDP config files, etc.

Then you might load rdp_npc to load in an NPC system. You might load rdp_combat to add a combat system. You might load in rdp_socioecon to add in a socioeconomic system. Etc.

The idea is that you have a nice, packaged set of tools that provides an efficient, clean and comprehensive set of systems to create a really in-depth game without having to code them, and that it's modular so you don't need to worry about 'well, I don't want the economic system' or 'well, I don't want vehicles' or whatever.

Basically, I want to make it easier for people to make cool, in-depth MUSHes without having to invest years and years in development of systems.
Basically, I want to make it easier for people to make cool, in-depth MUSHes without having to invest years and years in development of systems.

Now -that- I can understand. If anyone could do something like that, you can. It would rock!
Sounds wonderful! I can't wait to see how the project works out.

I (heart) RDP!
I was going to ask the same question, but I see it was answered. Cool!

Um, hate to sound grandma, but... and chance of seeing another red-headed 'net girl? I don't if you've checked that other e-mail lately, but she is missed. *hug*
Yes; with 2.0 Pro public beta out, I'm trying to catch up on those posts as well. That's the other thing I'm doing. :)
Well, I'm not the brightest guy that ever lived. So filter the following comments through that...

I understand that part of the RDP is to provide representations of resources (game resources, like alliances, trade goods, and property) and their owners and relationships between them. That seems like something that's going to be accessed on a fairly regular basis by the code running your server/simulator (MUX, or MUF, or whatever).

I'd be hesitant to make it depend on MySQL, or any SQL server, for that matter, unless the server was embedded in the same process space as your MU* server. The reason for that is, interprocess communication between your MU* server and your SQL server will have to take place through a pipe, and will likely take on the order of tens or hundreds of microseconds. Communication within the same process will be a lot faster.

The extra overhead is justified if you need things that only an SQL server can provide, which is the ability to store objects that are not in core, but still have them be part of a search; the ability to do complex, arbitrary searches on data; or some of the peculiarities of relational algebra, like joins.

If you're simply using it as a backing store for your objects, I don't think that you're going to need any of these things. At best you will need searches, but it's likely that you could accomplish the same thing by keeping references to all objects in a particular class and running your test case on each one sequentially, and seeing which dbref's match. For a handful of objects (hundreds) and/or infrequent searches (say, at initialization time only) I woul suspect that it's much faster than going to an external backing store like MySQL.

A better solution is going to be dependant on which MU* server you use. I recently had reason to ponder a similar scenario and discovered that one possible answer may be 'metafile'. I'm told that it comes as a standard component of MacOSX. It's the absolute guts of a relational database - no multi-user service over Internet, no SQL interpreter, etc. It's a library that you link in to let you do things like GDBM or the Berkeley DB's, except that it can handle additional things - at least columns in data and programmatic queries; possibly also indices (although I think you'd have to do the equivalent of planning queries yourself - not a problem if you're not doing joins, really).

I guess the point is - there's a lot of overhead involved, so only go the MySQL route if you really, really need to. I'd hope the DB in TinyMUSH 3.1 is sufficient; if not, have a look at Metafile.

Just my $0.0113 (after taxes).
It's useful because a lot of the system design relies on relational database stuff. The other problem is that the GDBM attribute system MUSH uses is seriously flawed when you get into huge numbers of uniquely-named attributes; the only game I know of which has a system like this handled entirely in-DB has a huge database bloat and efficiency problem.

However, Metafile sounds useful, I'll look into it. :)