True for you. Very very not true for me. While I don't use serialized JSON for storage (because I did even more work to store pretty much everything in SQL), I frequently generate JSON formatted data I/O. Use cases include:

* A web OLC that helps make most content creation tasks 100x easier.

* A world map dump that can be read easily by a web-based cross-platform automapper.

* GMCP data packets that can be picked up by multiple custom clients (plus a Mudlet plugin) and displayed differently.

If you are not looking to do anything more with your Dikurivative's world data than you're already doing, then that's your prerogative, and making any changes is naturally pointless. Or, you can re-invent the wheel and write custom &/or hackish stuff in your server and your client enhancements (I've done it myself, so who am I to judge). Just don't say that JSON is "harmful" to a Diku codebase. There's no case to be made for that.

File size and processing speed can become an issue when loading huge worlds. Not sure if this could result in a 1 second hotboot turning into a 10 second hotboot, but it's likely to be slower.

It's established there's no real advantage to JSON, so you'd likely end up wasting time to make your MUD's reboot slower.

How often do you reboot your MUD?

Oh wait.. Dikurivatives… every day then.

There seems to be a very odd echo chamber thing going on with some folks in this thread.

How about addressing some of the real-world examples and experiences of people showing what they've done and thereby proving that what you're saying is *anything but* established? How about addressing the fact that every modern server application uses a universal data exchange format like JSON or XML to enhance extendability and agility? Why would something that benefits modern server applications harm a Dikumud? I mean other than unhealthy fear of progress…

Heh, Planzi, because it's not the way their grandpappy did things!

Changing anything to do with the file formats would make a DikuMUD into a MOO or a Mush… Tyche said so! Because what makes a DikuMUD isn't the game mechanics or the way it uses templates to fill in different data values for instances of objects which all use the same underlying code. It's the file format!

When programing/testing it would make a difference. Player files could become problematic as well, and are problematic on many MUDs. So it'd make sense to discuss performance.

Yeah, except I didn't listen to tall tales like the one spun in this thread and updated our codebase to allow for runtime code changes. Of course, that was extremely harmful to its overall Diku-ness, but it made working on it that much nicer.



Nah, it's the file extension. If you stuff JSON into your existing .diku files, you'll be fine! :)

All of this can be done without touching the area format. I've added an JSON HTTP API for interacting with in-game stuff to my server with good results. I wouldn't want a web-based OLC interacting directly with the files, myself. Ditto for the rest of these. You don't need to have JSON area files in order to use JSON with external utilities.

I can see why you wouldn't want to open up the world files for editing (if you don't have a layer that resolves conflicts), but why not read-only access? If, for example, your world files can be served by a web server to a client, the client will cache the data, and then you can have a worldwide auto-mapper that places absolutely no burden on your game sever. While it's true that your world files don't *have* to be stored in JSON, if they are, it will make a feature like that a lot easier.



That's undoubtedly true. It's also true that if you do have JSON area files, you'll be able to do some things easier, and you will likely be able to reuse the same code in more places.

I'm still curious about the performance. The lack of an insightful response speaks for itself. It doesn't help either that CPU core speeds have decreased in the past decade.

Haha, I see what you're doing now.

Well, so, the CPU concern is a valid one. Especially since nowadays we're pushed to upgrade our OS, which makes older hardware perform worse. There's also the issue of JSON adding a lot of bloat and taking up increasingly valuable disk space.

When all is said and done, I would have to upgrade my smartphone every year just to be able to run 10 parallel MUD servers that use JSON for storage.

Oh come on.. it's not like I contrive to respond with Perl examples to posts about DikuMuds. ;-)



You are missing the real problem.
The JSON object specification is a specific form of associated array, which doesn't match what
many languages actually use. The keys must be strings. They cannot be numbers or symbols.

That problem with JSON also exists with Python implementations.

>>> json.loads (json.dumps( { 'one': 1, 1: 42, 451.78: "xxx", "1":"one" } ) );
{u'1': 42, u'451.78': u'xxx', u'one': 1}
>>> yaml.load (yaml.dump( { 'one': 1, 1: 42, 451.78: "xxx", "1":"one" } ) );
{'1': 'one', 1: 42, 451.78: 'xxx', 'one': 1}
>>> pickle.loads (pickle.dumps( { 'one': 1, 1: 42, 451.78: "xxx", "1":"one" } ) );
{'1': 'one', 1: 42, 451.78: 'xxx', 'one': 1}
>>> json.loads (json.dumps( { 1: "one", 2: "two", 3: "three"} ) );
{u'1': u'one', u'3': u'three', u'2': u'two'}

If you're trolling then well done.

If I were building a new product I would never use the diku format nor the procedure it uses for generating the files.
If I were working with an existing diku product I would never spend the effort to change to anything else.

So the reason these two things hold true for me is simple: I see a lot of merit in using json/other format because of how easy and well maintained it is, but I don't see any deficiency that it's solving other than ease of implementation, removing the need to maintain the library, and removing domain-specific knowledge for future developers.

But even more important to me is that I would only ever consider some type of more mature database solution (I like postgres) for this problem for almost the same reasons.

Oh noes! My DikuMUD (based off DikuMUD Alfa) uses .wld, .mob, .obj, .shp, and .zon file extensions. It's NEVER been a DikuMUD over all these years. :(



I accept that this is true. I'm just not sure how much of an actual problem it is in real practice. I've never tried to use numbers (integers or floats) as key values in a hash/mapping/dictionary, or in a C structure for that matter… which *IS* where this argument started. I've also never used arrays or other mappings as keys in mappings. In fact, the only "weird" thing I've ever done with respect to mapping keys is using objects as the keys themselves.

The times I've done that has been when building lookup or dispatch tables, and in all cases it's never been anything I'd want to save. For example, using the socket objects as keys to a mapping which holds the associated player/login objects. Very useful when looping over socket data to be able to easily call the right parser to handle input. Not something that's going to be saved to disk.

So I'm not saying it's IMPOSSIBLE for someone to find JSON unusable because of its inability to use non-strings as keys… but if that's the case, maybe JSON isn't the real problem, and a horrible design should be addressed?

Performance: Alter Aeon base world footprint is 100 meg of simple, block tagged text files. Typical boot time is approximately 1.5 seconds. A lot of this data is numerical fields in formats roughly like:

#B3 0 30 99 1 0 1671800

Switching to full JSON with identifier information for every field would probably double the overall file size. With a high speed JSON parser, that might result in a boot time on the order of 3 seconds.

Honestly I don't see much of a performance problem with that, though if you have a huge wilderness that requires you to load two gig of rooms you'd probably just want to use binary formats instead.