16 Oct, 2010, Quarlash wrote in the 21st comment:
Votes: 0
Ludwig said:
Quote
why not a central repository of areas broken down to key sections (or fields) with a standard open format


I expect 95% of all uploaded rooms would be missing descriptions. :lol:


Terminology:
Field(s): Relating to a Database, fields are columns in a table which hold information (Not to be confused with physical space that you may play sports in, or harvest crops :wink:).
Region: What most would understand as an 'area' from a stock mud, i.e. the contents of a '.are' file (From the Diku side of the family). Not necessarily conforming to the expectations of an area from a stock mud(May have more, less, or different fields in the same or different format).

Think of it less as pre-built objects and think of it more as individual fields submitted to a database. Tools (internal or external via api) could be used to select (random or through specified criteria) a listing of specific fields into a predefined output (or "as is" and let the requestor manipulate the format). You could request an entire region, or descriptions of typical 'rooms', basic layouts of contained space within a region (If it's sectioned into 'rooms' or set to a grid of # by # feet or other measurement), or even descriptions of mobs, or even more unstructured dungeon plans (For those from awhile back, think of the preparation needed by a Dungeon Master prior to playing a game of D&D. Not only did they usually need a dungeon prebuilt on graphing paper, but they frequently needed a general planned overview of how the game would go.)

The system could organize by category of submitted region/area/dungeon design. Not all types of Muds use areas which (in a conventional stock-mud sense) have a description for each physical location that your character occupies. Certainly, there are other objects in the same visible space, but a description may be built from those visible objects rather than pre-defined as a "room" object.

The system could initially be built with a priority list of formats for import/export by profiling the currently active muds and finding out which types are most popular coming from certain stock origins. Further, you could hook into the API and with the exported request, either request additional fields of information, or a somewhat altered format (As most muds that were once stock may not be anymore).

I'm openly brainstorming here, but there's nothing that even limits the level of creativity available from story developers who might want to offer unstructured stories to potentially muse others into more structured region development.
11 Nov, 2010, Ludwig wrote in the 22nd comment:
Votes: 0
Why did you quote me? Are you trying to explain something to me or did you take offense to my joke (the joke being that many builders leave out room descs entirely)?
11 Nov, 2010, jurdendurden wrote in the 23rd comment:
Votes: 0
JohnnyStar said:
Quote
Say I was running QuickMud and so my .are files are being output in the traditional style, but I
wanted to convert the code to output into a "Key" style like SmaugFUSS? Well, this would just be
a matter of either adding a new configuration file, or changing the "Rom" format file.


The beauty of databases is that you can make a query for anything. Your configuration file could just be one fancy query per codebase. Could even centralize further and rather than have config files, could just pop a new table into the DB to keep track of all codebases and their query strings.

I kind of want to set up something like this for my mud, where there is a "pool" of mobs/equipment/furniture/etc.. that builders can just plug into an area, instead of having to start from scratch. I seem to have the hardest time keeping builders and I think it's because building is just so time consuming. On that token, I've taken steps already to speed the process up for them, and I think this could be a pretty major way of speeding it further.

Keeping that in mind, I think that this could become very cookie-cutterish, so I'll probably just let them keep the ability to alter the object once they've pulled it from the DB to keep creativity there, but offer a nice outlet for PnP building.
12 Nov, 2010, quixadhal wrote in the 24th comment:
Votes: 0
The problem with this idea is that not all codebases use a fixed format for data structures.

A DikuMUD (or any of the zillion variants) has a nice fixed structure that you can easily parse and mutate into whatever output form you want. So, converting from Smaug to Circle is not difficult, just tedius… and some data will get lost in translation.

However, none of that applies to an LpMUD, TinyMUD, MOO, or any of the other codebases out there. In an LpMUD, each room is an object that's defined by a chunk of LPC code. Most MUDs do have common inherited code and certain common events, but there's nothing preventing the builder from overriding that and doing something entirely different and unique.

If you were going to make a RDBMS driven system, you'd probably have to resort to key/value pairs because otherwise your room table will never have enough columns to handle even a small fraction of the codebases out there (even just the Diku ones).

CRATE TABLE rooms (
room_id SERIAL NOT NULL PRIMARY KEY,
mud_id INTEGER NOT NULL REFERENCES (muds.mud_id)
);

CREATE TABLE room_parts (
room_id INTEGER NOT NULL REFERENCES (rooms.room_id),
part_name TEXT NOT NULL,
part_val TEXT
);

INSERT INTO room_parts(12, "description", "You are in a maze of twisty little passages, all alike.");
INSERT INTO room_parts(12, "dark description", "You can't see anything!");
INSERT INTO room_parts(12, "is_light", "0");


And so forth…

A room is then collected by something like
SELECT * FROM room_parts WHERE room_id = 12;


Complex structures like exits might have to be serialized further. The problem with just making an exit table is, of course, what's to say all muds HAVE exits of the traditional sort? A fully coordinate based one might not.

Obviously, the more narrow you make your audience, the less any of this matters. :)
12 Nov, 2010, plamzi wrote in the 25th comment:
Votes: 0
Another vote for a SQL db instead of flat files. You can not only query the db in all the ways that you need but you can also format the result easily in xml (existing php or perl parsers e. g.) and somewhat easily in any custom format.

SQL opens up a ton of possibilities, not the least of which is that it lends itself naturally to be a back end to a website with multiple users. Imagine a site with easy to use tools that can serve different builders for different MUDs at once. They can not only use it as a repository but they can actually build there and export their files when done. You can hook a Joomla CMS and use its authentication layer to ensure people only get to the parts of the db they're authorized to see.

I just finished implementing a MySQL db for all player objects and stats and for a new unique quest system. It's holding up very well so I'm about to import all the world files as well (entity indexes are already in the db). When that step is complete, the next step for me would be to offer my builders the ability to build inside a browser. Everyone knows how to fill in a web form, and building a room/mob/object shouldn't be harder than that.

Of course, my project would be less challenging than a central repository because I'd only need to support my own world file format. But I'd be happy to lend some code bits if you decide to use SQL in the back end.
20.0/25