Based on this response it seems to me that you didn't follow what I meant. Of course you can do joins: you have entities with ids and you can join based on those ids. The relationships are defined by those ids.

Look up some DB theory… you don't need wide tables to represent relationships. You might start with database normalization for example, to see how you can establish relationships with very narrow tables.


That's silly. Reading from the file system is not that different from reading from a database. And I already explained how a database could just as easily be in a rich server-like environment (e.g., MySQL) or a much simpler file-based format (e.g., serialized dictionaries, sqlite, etc.). Given what you told Runter, that you either had your flat file format or a "heavy back end", I think that you have missed this point. You seem to have a rather colored perception of what it means to have a database, and only think of the larger client/server environments.

In fact, in some cases, it would even be faster to read from a serialized binary format than parsing text!


Well, yes. :tongue:

I think I have to agree with Idealiad here: you seem to be using the term "schema" to mean something different. You don't need a "fact table" to have a schema; a schema is what I gave you (the id/key/value etc. structure).


Nobody's saying it would take zero time. People are trying to understand what you hate so much about it, because we believe that a relational structure is superior to a flat file.
But we also believe that this entire task, no matter how you approach it, is so difficult as to nearly be not worth undertaking. Again, my belief is that a realistic goal is to develop a framework, not attempt to develop an end-product that could serve as an editor without anything more than a little configuration.

By 'id' people typically mean the unique id column of a table. If you meant a foreign key, then maybe you should look up some basic DB theory to avoid further confusion.

OK, so as I understand it, you're proposing a number of narrow tables, with one foreign key each. This works fine for any single properties (e. g. Room Number | Room Name Key | Room Name (String)) but how are you going to describe the relatively simple relationship of 4-6 exits to the same room in a 3-column table? Let's try: Room Number | Exit Key (e. g. 0 is North) | Exit Name (North) – no unique key here unless you add a 4th column. You'd want to add one in most scenarios, especially if you're building this for a website with multiple simultaneous users. Or are you still going to insist that 3 columns will do?

Now let's say you religiously stick to 3-4 column tables. Does that really solve anything? All you've done is placed an artificial restriction on yourself that each property of each object will get its own table, even though many of those properties (e. g. room name, room description) are only related to one object and will mostly be accessed together. Why not have a table containing all the single property keys against the Room Number primary key? Or are you going to be writing 20-join queries just so you can populate a room edit form?

The real challenge here is not whether you can design a database in which no table exceeds 3-4 columns: you can (although for most MUDs that will mean hundreds of tables, and I wouldn't want to maintain it). The real question is what do you do when a user places a unique demand. I asked it a while back and it seems that the OP answered it (wisely, I might add) by deciding to build the site for his code/codebase first. Incidentally, I reached the same decision some weeks back, although our implementations will differ significantly.

And lest I get an undeserved reputation as a db-hater, let me put this in print, again: Having ditched the idea of a universal design tool, I can now hook my site directly to my MUD database. Whereas a dedicated db seemed a liability in a universal tool, it makes every sense to plug my UI into one that already exists, and is about to start feeding the world data to the live server. That's going to make my UI a true OLC replacement.

By 'id', I meant 'id'. It so happens that an id can be referred to by other tables. It is not necessarily a foreign key into anything. It might be, or might not be. If you're going to use fancy words, well…… :wink:


I did suggest that you look up database normal forms, because therein lies your answer. (In fact, you said it's ok yourself later on, so I'm not sure what the issue is.)


You're assuming that you know all of these relationships for a given game ahead of time.

But you don't.

So, you can't.

Indeed, the general representation that seems so clunky to you is in fact flexible, because it lets you represent general relationships.

I still kind of think this kind of project – a fully generic "edit any game in the world editor" – is a waste of time, though, so I will admit that I am starting to lose interest. :sad:


You say that as if it's a bad thing…


Then why are you giving me so much trouble about it not being feasible…? :thinking:


You keep saying this, although you've never really given solid reasons why. I guess you've said you think it's clunky and "heavy" although that seems based on a rather particular perception of what DBs are.

I don't really think it's a pointless topic of discussion.

Your right, it's not pointless. But is it necessary? :smirk:

If you want to make a generic editor that works on many data representations without knowing interrelationships in advance, then thinking about your data representation is kind of important, yeah… whether you go with a database or not, for that matter.

Can someone tell me what is actually being achieved here? Surely the only thing to be resolved is what will initially be stored (in general) and then how it gets stored gets driven by implementation. All this talk about data representations and relationships seems like a side track into design by committee. Data can be transformed, and representations can be switched and thrown away. An implementation could start with a simple representation and extend it as need be.

Nobody wants to go argue with Scandum over his next new protocol, so we're hanging out here? *grin*
(BTW: I dub it M2CP – Mud 256 Color Protocol)

To the OP, if you want to make your life simpler, you might want to use your ROM data layout, but wrap it in JSON so it's stupidly easy to parse. That way you can easily read/write it via any web-based junk you might use or create, and all you need is one added output routine in your MUD code to spit out the JSON version alongside the regular one.

Just a thought…. rewriting the ROM (or any DikuMUD) loading routines for PHP/Java/etc doesn't sound like much fun to me.

So, are you saying in this case to use JSON in my ROM C++ code as well?

I had given it some thought. I imagine the site would store data in a mySQL db, but when exporting data, you could
export to a JSON file and download it to the ../area folder. Then add JSON to the actual MUD project.

Is this what you mean?

PS: I didn't much like the idea of outputting to Diku/ROM .are output either. YUCK. :tongue:

Yes. The simplest way to generate JSON data is to add output routines to your game itself to spit out JSON files alongside the regular format it uses. If they're complete, you *could* also read them in, although that's not needed unless you want to fully move away from the ROM format entirely. The reason I suggest doing it that way is that your game already has everything loaded and in the state you know is correct. If you do it any other way, you have to reassemble the ROM data files into some internal state from which you then dump them into JSON (or SQL).

That's a smart move, and chances are there's a JSON library for every interface you will use. And if you write the JSON reading routines, then that gets you a step closer to a true OLC replacement, i. e. a tool that lets you modify the online world itself.

Agreed. And I wouldn't use MySQL for the website either. Just use JSON for everything – even to represent your database-like mappings, if you have any.

If I wanted to go that route (which I'm not) it'd be a standard, not a protocol, so that'd be M2CS. I was only looking for feedback however, not for people to get emotionally invested, argue, and get their feelings hurt when they don't get their way. I understand it's unreasonable to assume that level of maturity.

On topic, the big problem with JSON (and pretty much any general purpose data format) is that complex data requires nesting, which most C codebases do not support.

I guess one option is creating a snippet for an associative array handler and a JSON parser. I'm not aware of any good scaling O(1) or even O(LogN) ones that are available for C.

So are you suggesting that the JSON files would be uploaded, manipulated and then downloaded? Or, would they be stored on the server?
If it was strictly a local thing, you wouldn't really need PHP would you? As the local javascript could do most of this anyway.

The JS can do all the transformations you need, but it can't write them to a local file, nor can it read from a local file. If you're going to support any kind of import/export to file, you would need the web server to act as your hard disk. There are general purpose js + php snippets floating around that will make this fairly easy.

You can make use of the same similar logic for reading/writing JSON files from/to your game server. Or, you can wire the JS directly to the server using telnet running on the page. I imagine you can write a simple command on the server to take a JSON string and store/process it.

Assuming your chosen JSON library ( http://www.json.org/ – take your pick ) doesn't directly support serializing and deserializing arbitrary data structures, it's not that hard to walk your data and either build a simpler structure you can serialize, or emit the appropriate JSON code to store the elements as you go. Reading that back in may not give you a direct load, but it would put all your data in memory where you can then easily move it into the right structures without having to parse it from a clunky file format.

The point of using JSON is that there are already libraries available for almost every language you might care about, so you don't need to re-invent the wheel, and data dumped from one implementation should be readable from any other.

Using that approach something like: { "name" : "A room", "vnum" : 1234 } isn't going to work because in Diku land you can't store the name until you get the vnum. You'd have to store it into a dummy data structure first, and populate the actual data structure when the JSON object is closed. So you're looking at about 10 dummy data structures, each with specific event handling, which means you're basically creating a more complex duplicate of db.c. It'd be doable if you got rid of the old file handling and switched entirely to JSON, though then you also have to add support for area saving.. more work.

An alternate approach would be embedding JavaScript in C: https://developer.mozilla.org/en/JSAPI_U... which should give both JSON parsing and storing. Not sure if anyone has tried that.

Edit: On second thought you can populate an actual object and properly link it when done, so no need for dummies, just object open and close event handling.

Why not just use sqlite?

Your site stores data in the db. The mud accesses that db with the C sqlite library.

Out of curiosity, couldn't you have it work like remote building? A UI that just takes what's already there, fancies it up into windows and clickies and spits out your work in the correct order.

Or to be really flexible, you could set up something where it'd just spit out a string of commands that would do in-game what you've designed elsewhere? You'd be able to specify how it does what, or design your own custom UI. Write a description into the box, and it generates "redit create 1111/ redit 1111/ description/ <your description>/ .f/ @/".

Just wondered.

Yes, in theory I'm sure this could be accomplished. But you could just log-in to your mud and use
commands just as easily if not more so. Plus, you would be limited to the functionality of the OLC
(assuming the mud has one to begin with). The goal is to have a repository full of data to build areas
quickly.

Also, the main advantage of a web front-end is sharing information with others. I'm sure it would be
easier to develop a desktop application to do this (there are quite a few out there).