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");
SELECT * FROM room_parts WHERE room_id = 12;
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.