The answer lies in writing emitters. Obviously you'd use a generic database, but this isn't a problem where there's a magical universal format that is meaningful. So some of this discussion is pie in the sky. There has to be adapters written. If you want a meaningful UI there has to be a UI skin that's equally customizable. Surely we don't think by convention alone we will be able to know how to example fields on objects in a meaningful way. It's going to take configuration, and a simple wizard might work but it's not going to be "nice." I mean, each codebase doesn't even agree on what the format should be in the first place. Some users won't even be consistent. They might even mix serialization with key pairs.

In other words, this isn't a simple project and for it to be worth using it'll require way more work than anyone has admitted here yet.

Well, Plamzi, like Runter said, you're discovering exactly why this project is extremely difficult, if not basically impossible in practice. The schema is actually very easy to design… I just told you how to do it. You don't need to know any relationship other than this thing being associated with that thing, really. It's the UI that will be difficult, not the data model. The need to customize the data representation model for every single game makes it rather difficult, to say the least, to have a meaningful, generic editor that presents the data in any format other than key/value associations with an entity.

You could perhaps get away with config files that define the relationships, but then yes of course the individual MUD developer will need to write said configuration. It's easier than starting from scratch, I suppose, but on the other hand if s/he were to write even a relatively simple editor in-game it'll have more tight integration with the actual data structures than your generic editor is likely to ever have.

Honestly, I don't think that the payoffs of a fully generic editor meant to accomodate any possible format are worth the costs, if indeed the problems are meaningfully solvable. FWIW I've thought about this a fair bit and I'm just not seeing how you'd do it usefully – and it sounds like you're running into exactly the same dilemmas! :smile:
That said, I think it would be incredibly nice to have a framework for designing your own editor, where the framework takes care of a flexible data model with output adapters to a format of your choice. You would be responsible for putting together the UI – and the framework can help there by providing GUI component templates for common use cases.

A bit OT, but has anyone ever designed a mushclient or similar GUI for building?

Not that I'm aware of, but it's still early days for MUSHclient GUIs. I've seen several muds start developing their own in the last couple of months, and as soon as someone creates one for building it should be easy enough for others to copy them.

The next version of Mudlet will have an autoinstaller for custom scripts, which (combined with its strong portability) could make it a very appealing option for designing GUIs. You could even have a special interface for your building port, so people connecting with Mudlet would automatically download and install the "builder's GUI" (either a generic one, or one tailored specifically to that mud).

Like I mentioned in another thread it'd be easiest building OLC into an automapper and communicate updates over a data protocol using generic variable names. The client would need an extendable automapper and probably support for custom input fields. Not sure if MC provides either. It'd be less involved than what has been suggested so far, but probably still too much work for the vast majority of MUDs to bother.

Can you tell us more about 'emitters' and what they do? I haven't come across this term before.



Not sure if you think that a magical universal format exists in this case or doesn't. I'm leaning heavily towards the latter myself.




Yep, tons of work on the UI side as well as on the back end. And as you correctly emphasize, the true test for usability will be customizability, which is precisely what's difficult to pull off well. I don't think anyone here would be interested in a "basic" web OLC that handles only certain highly generic test cases.



Another great point. This almost compels the project to limit the use of any back end database to storing and restoring UI states, without attempting to know anything about data interrelations. Would you agree?



Actually, I discovered this some weeks back when embarking on a very similar project and just wanted to make sure the OP of this thread realizes all the complications as well. In my project, I decided a back end database would complicate more than help things. I can see how it can be used as quick storage, but anything beyond that would seem to me to reduce flexibility (or at least make it even more difficult to pull off_. The OP is encouraged to peruse the link above, where I share some details.



The web editor POC I put together in a few days is actually about 30% there – it lets people configure GUI components quickly but the input/output part has not even been started. (FYI, I was originally planning for output to be exclusively flat files, but there shouldn't be a problem to configure and export (or run) a set of db insert queries instead of a file.) Here's a direct link to the code as it is now. Several people have gotten it, so it may resurface at some point in a more usable state. Personally, I'm going to take it in a different direction (a live client) and drop attempts at supporting multiple MUDs.

The OP is also encouraged to download and reuse any part of my code, which may come in handy for the UI part of his project, should he decide to undertake it.

emitter = Adapters specifically for taking usually raw data and transforming it to an actual format. The term is most common, I guess, in serialization libraries.

The point was that for this to be useful it has to actually produce data in a format that's useful to an end users game. This makes it very difficult for anyone who isn't able to easily write one of these adapters to use. It's a problem that anyone who has used a generic rom2.4 editor has encountered if their game has more or less fields. In this case, it seems like we wouldn't be able to assume any base format at all. Unless you want your users to select from a few stock formats. But that's weak, and of course, some users might just need some type of database partial dump. Who knows?

Aren't there dozens of offline buildering programs out there?
http://www.gammon.com.au/forum/?id=638
http://tdod.org/wiki/index.php/Resources...

Somehow, a live client brings this to my mind.

No I wouldn't… what is this great evil with databases? They're just storage mechanisms. A schema can be quite simple. In fact, I already gave you the schema you need. You don't need to design some wacky complicated schema for each MUD. And in fact * 2, your flat file is already defining the same kind of schema that the database would use.

People tend to view DBs as these big monstrosities but in the end of the day a DB is just a storage mechanism… you can make it as complex or as simple as you like. Your flat file is, after all, just a sequence of key/value pairs.

Perhaps when you hear "DB" you think some large installation of something like MySQL with a server, a client, bla bla bla, in which case I'd understand your concerns… but really there are many ways of having a DB, be it as a serialized dictionary in Python, a sqlite file, etc.

LPC doesn't use a binary storage format. LPC is code. Where a DikuMUD has a rigid file format that always keeps things like the short description in either a fixed position or with a key/value pair format, an LPMUD will have a chunk of LPC code that sets that description from one (or more) functions. The exact details vary from one mudlib to the next.

However, that doesn't matter. There's no reason to care about exact formats of anything at the database level. The output layer (which folks above are calling "emitters") takes the data and wraps it into whatever output format you've requested. If you want this to work for YOUR MUD, you may well have to write your own emitter frontend, but if the API is clean and easy to follow, this shouldn't be hard.

The idea is, if your MUD doesn't support some feature, your emitter will ignore it. If your MUD requires some feature that isn't present in the generic data set, it will have to provide a stub/default value.

As an example:

WileyMUD (modified original DikuMUD):

#ROOMS
#3000
Travelers road~
  This road is well worn as many people must pass by this place to travel
the protected ways of the land.  Looking about you several buildings to
each side and some in the distance marker this place as a highway town, built
on the prospects of continual travelers passing through.
  To the west stands a building with a small sign above the door reading,
"Supplies", opposite a larger building sits hanging a sign with the words,
"Griffin's Inn" written upon it.  North and south this road seems to continue.
~
~
city~
~
0
D
north~
~
~
~
-1 3007 -1 -1
D
east~
A door made of hard ironwood sporting the crest of a griffin.
~
door griffin~
isdoor closed~
-1 3001 -1 -1
D
south~
~
~
~
-1 3002 -1 -1
D
west~
A sturdy door with a metal handle.
~
supply supplies door~
isdoor closed~
-1 3009 -1 -1
S

Converting that to an LpMUD format:

// Automated conversion of WileyMUD by Quixadhal
// Original:   WileyMUD III, Room [#3000]
// Target:     Final Realms 2.1b4, /d/Shylar_30/rooms/Travelersroad_3000.c
// Performed:  1100804.213853.906

inherit "/std/outside";

void setup() {
    set_zone("Shylar_30");
    set_short("Travelers road");
    set_long( "  This road is well worn as many people must pass by this place to travel"
        " the protected ways of the land.  Looking about you several buildings to"
        " each side and some in the distance marker this place as a highway town, built"
        " on the prospects of continual travelers passing through."
        "\n  To the west stands a building with a small sign above the door reading,"
        " \"Supplies\", opposite a larger building sits hanging a sign with the words,"
        " \"Griffin's Inn\" written upon it.  North and south this road seems to continue."
        "\n" );

    set_light(80);

    add_exit( "north", "/d/Shylar_30/rooms/Travelersroad_3007", "road" );
    add_exit( "east", "/d/Shylar_30/rooms/GriffinsTale_3001", "door" );
    add_alias( "east", ({ "door", "griffin" }) );
    add_item( ({ "east", "door", "griffin" }),
        "A door made of hard ironwood sporting the crest of a griffin."
        "\n" );
    add_exit( "south", "/d/Shylar_30/rooms/Travelersroad_3002", "road" );
    add_exit( "west", "/d/Shylar_30/rooms/Supplyhouse_3009", "door" );
    add_alias( "west", ({ "supply", "supplies", "door" }) );
    add_item( ({ "west", "supply", "supplies", "door" }),
        "A sturdy door with a metal handle."
        "\n" );
}

Look at the things that are common here. Both formats have short and long descriptions, both have "detail descriptions", both have exits. Were I to make a generic format, I'd make it present such data in a general fashion that's easy to parse:

{
    "room id" : 37281932819,
    "short description" : "Travelers road",
    "description" : "  This road is well worn as many people must pass by this place to travel\
the protected ways of the land.  Looking about you several buildings to\
each side and some in the distance marker this place as a highway town, built\
on the prospects of continual travelers passing through.\
  To the west stands a building with a small sign above the door reading,\
\"Supplies\", opposite a larger building sits hanging a sign with the words,\
\"Griffin's Inn\" written upon it.  North and south this road seems to continue.",
    "exits" : {
        "north" : unique room id of wherever this pointed, generated when uploaded or created,
        "east" : different unique room id,
        "south" : different unique room id,
        "west" : different unique room id,
    },
    "exit aliai" : {
        "east" : {
            "door",
            "griffin"
        },
        "west" : {
            "supply",
            "supplies",
            "door"
        }
    },
    "details" : {
        "key" : {
            "east",
            "door",
            "griffin"
        },
        "value" : "A door made of hard ironwood sporting the crest of a griffin.",
        "key" : {
            "west",
            "supply",
            "supplies",
            "door"
        },
        "value" : "A sturdy door with a metal handle."
    }
}

Obviously, I hand-cobbled that as I typed, but the idea is there. The tricky part is to figure out how to store the raw data so it can be most easily manipulated. The "item" descriptions are a good example, as they point multiple "keys" to the same value. Other things may have multiple keys mapping to multiple values. Some output formats may not allow for this, so you might end up writing emitters that will choose single values to fit (first, best fit, whatever). That, however, falls on whomever makes the emitters.

I would suggest that for the Dikurivative family, you may get folks to help with writing emitters for stock codebases such as CircleMUD, SmaugFUSS, ROM, etc. Anyone running such a MUD will probably want to take your generic emitter and tweak it for their own use. The LpMUD folks (and MUSH/MUCK people too) are more likely to write totaly custom ones, but again… if the format is clear and well documented, that's not a big problem.

Where do these emitters live? You *could* have some of them on your own site to provide alternate output formats, but they'll probably end up living as conversion scripts at each MUD's own host to take JSON (or whatever you use) and mold it to their custom game's format. They could also live inside the game code itself, which might query for an object from your repository and convert what it gets back internally.

Actually, so far it sounds to me like you agree but you hate to admit it. A generic "id", "key", "value" structure for all tables means you're just storing key-value pairs in reference tables. You can look up the value for a key, and you can get unique values, but you can't do a single join based on such tables. If you don't have a "fact" table where multiple keys of different types sit across from each other, then you are not really storing relationships and your schema is incomplete. And if you do want to store a "fact" table, then it also sounds like we're in agreement that it would be difficult to keep that table flexible and offer tools to customize it.



Databases are wonderful. I'm just about done moving all my MUD's data into one, with fabulous results. But a back-end database is not the answer to every question. When I began work on the builder site project, I asked myself, "Do I need a database as primary storage for the world data?" Being extremely comfortable with JS / PHP, to me the answer was no. "Would a database make things easier?" To me the answer again was no. "Would a database make a flexible and secure implementation more difficult?" Yes. "Would it help or hurt the end user experience to have to read to/from a back-end and load a new page every time something significant changes?" It would hurt. So, in my POC I did without one, and hit no major stumbling blocks.



You didn't–you were just patronizing me (no offense taken). A schema requires at least one fact table, and that is where the trouble begins for a tool that attempts to be customizable . While I totally agree that you can pull off a web-based OLC with a back-end database, either dynamically generated from a config, or with a wizard for end users, you'll be writing tons of additional code on both the server and client side to achieve an end result that's likely to perform worse, be less secure and maintainable, and less straightforward/pleasant to use. That's, like, my opinion.

Just so I get things straight here, when plamzi says schema he means a RDB schema, and when anyone else says schema they mean…I'm not sure, but not what plamzi means. Is that it?

@Plamzi re " I asked myself, "Do I need a database as primary storage for the world data?" Being extremely comfortable with JS / PHP, to me the answer was no. "Would a database make things easier?" To me the answer again was no. "Would a database make a flexible and secure implementation more difficult?" Yes. "Would it help or hurt the end user experience to have to read to/from a back-end and load a new page every time something significant changes?" It would hurt."

I think I disagree on most of those conclusions you've came to. You didn't give any explanations, but why would you being comfortable with js/php matter? Usually as people get more comfortable with languages that's precisely when they realize that what they thought was complex (especially with their data store) turns out to be more manageable. What alternative are you even suggesting to a database here? Also, I dunno what you're talking about wrt having to reload a page because you're using a database. Maybe what you're actually talking about is frontend store vs backend store, but that has nothing to do with a database and fwiw you can stream in data from a backend easily avoiding the "load a new page" part.

OK, first read this post. I'm definitely talking about a front end store solution. I think my being comfortable with JS / PHP matters a great deal because I see an opportunity to get the same end result in a much easier way, with the data living only in exported/imported flat files and in the JS + forms on the page. On the server side, a few tiny scripts I could write from scratch would effectively turn it into file storage for the app (which the local browser's sandbox doesn't offer).

Now let's move on to why you'll almost certainly end up reloading the page if your primary storage is a database of "shared records" like the OP is suggesting. In a simplified example, the user updates a room description in the UI: at some point you'd have to make sure that the record is updated in the database. The way to do that in an async way safely (i. e. if you don't want to let users run whatever queries they feel like on your database) and easily (parametrically, without having to compose queries) would be a web service, e. g. RESTful or SOAP, which can handle a restricted set of valid database update requests. That may not be huge additional work if you know exactly what parameters the update requests may take, but if your UI is different for different MUDs, then you'll be having to support (as in write) potentially hundreds of different web service requests (they are not trivial to write). Unless you love creating oodles of work for yourself, at some point you'll decide you can just POST the data, validate and insert using some tried and true server-side logic (e. g. some kind of ready-made Ruby module I imagine), and then return a new page rebuilding the form page with the updated user description. That is the typical flow of the vast majority of web forms currently in existence because async form posts are labor-intensive, hard to debug and maintain, and most importantly, inflexible.

In my proposed solution, nothing needs to be kept apprised of a room description change because no individual record needs updating anywhere but in the DOM itself. Periodically, the JS can scan the DOM and dump the data into a temp save file so users don't lose progress. It's possible to store that state as a glob or a set of key-value pairs inside a database instead of a temp directory, but in my book that's equivalent to a simple file storage solution. I believe DH and I appeared to disagree there only because we mean different things when we say "database schema". To me it implies that you're storing relations, not just references.

Sounds like a false argument with claims of oodles of work that is "labor-intensive, hard to debug and maintain, and inflexible" when originally all I wanted to know is why you believe those things. Which, of course, I disagree with. Maybe you believe those things to be true because you're comfortable with a certain web design model, but it's nonsense. Furthermore, you confused me originally talking about PHP. That doesn't inspire a front-end solution. And fwiw most people who deal with frontend stores just dump serializations. And most js newbs and js professionals are going to get the same milage.

I've actually provided detailed arguments (which you haven't addressed) about why using a heavy back end would buy you nothing given the requirements of a project like this one. You can't just quote the conclusions without the arguments, and then say that they're false. That's just not cool (although it sure is easy).

Look, if you think it will take you 0 time to put together a flexible database schema, a flexible web service + async update logic, and a UI keeping all these moving parts together, then more power to you. FWIW, I have 0 bias against solutions involving back end-intensive solutions and have deployed / coded many. I'm just not the kind of person who brings a bulldozer to hammer in a nail just because they're comfortable driving one. By the time the bulldozer gets there, I plan to have done the job and moved on to other stuff.

Yep, why bother implementing anything when adding a simple 'implements serializable' makes so you can write and read the file without coding anything at all. Creating a file format seems very bothersome when you can do that, and if it is not enough, definitely not less work than using a db.

Wow…

Ok, so this has turned into quite the hot-topic while I've been out of town…

Anyway, everyone seems to have their own ideas. I realize that it just isn't worth the time trying to get everyone
to agree (which is typically the downfall of this entire subculture). However, I have decided to go through with my
project for my ROM codebase. Perhaps after I am done with it, I will add stock MERC, SMAUG and ROM capabilities and
keep an open license. This way, if someone wants to customize it, they can write the code themselves. :smile:

This avoids pointless arguments about the "theory" of data storage or other things that aren't really worth bringing up. We aren't talking
about revolutionizing storage issues for MUD codebases. What exactly does it take to get some positive comments on trying to do
something new around here?

Jeez.

Thanks Quix for your polite posts and interest in the OT :wink: