05 May, 2014, alteraeon wrote in the 21st comment:
Votes: 0
It's been my experience that you ALWAYS have to do error checking, whether its human editable or not, as well as allow for format changes and loading of older data files so that your backups don't become obsolete. Pfiles in particular can be restored and loaded at any time - you need to handle things well enough to be able to load files from as long ago as you have archives. Last I tested, AA could legitimately load playerfiles from our 1997 archives.

It's not that JSON wouldn't work, it just seems to me very much overkill, and if you're using C/C++, another translation layer you'll have to go through. I personally recommend using strong tags on fairly small data blocks, with only identifying information for the particular block you're working on. Examples of a data block might be a 'block of integers' or 'a list of extra descriptions', or 'a list of objects'.

The vast majority of the information in AA is stored in 1) numerical format, 2) single strings, 3) lists of extra descriptions, 4) numerical tables, and 5) objects. We've got primitives for loading and saving these, and that takes care of most everything, without the overhead of having to save every variable name to the already hundreds of megabytes of data files. The cost is that you have to add a couple lines of code into the load and save routines and possibly handle file version updates. With a gigabyte of data files, I'm ok with that cost.

Alter Aeon MUD
http://www.alteraeon.com
05 May, 2014, Nathan wrote in the 22nd comment:
Votes: 0
Viriato said:
Hello.
Java has it's own serializing format, and you can use libraries to do it in other formats, like JSON. For Java serialization you need to implement Serializable in your classes, basically, and be aware that a serialized class cannot be de-serialized if you make changes in the class code meanwhile (you can do some changes, like add a new variable, but can't do others, like change a variable datatype from string to int).
There are some more details about it, so if you are interested, PM me and I'll be glad to share what I know.


I would not advise using Java serialization unless you are working an environment where you will make no changes to a class. Also, I suspect that the most minor file corruption could break Java serialization. In any case, you are much better off using cross platform serialization (like JSON) that can be dealt with in other languages as well.
06 May, 2014, quixadhal wrote in the 23rd comment:
Votes: 0
This is a big part of the reason I won't use C or C++ for anything new unless you're paying me to do so.

Why would I put up with the headaches of all this fixed-structure nonsense, when other languages just let me use objects and add or remove fields on the fly? Restoring an old player file? Big deal… any fields added since it was saved just end up with "undef" as the value. It's not going to fail to load, or load with things in the wrong places…

If you care about updating objects, you can always slap a version ID in, and if the loaded ID is < the current ID, call $self->update()… which you have to code, but which can put sensible defaults into new fields, or convert legacy values to their current equivalents.

It's much easier than the dinosaur practice of having to hardcode everything, and go change ALL the code every time you change anything.

But that's just me. :)
07 May, 2014, wifidi wrote in the 24th comment:
Votes: 0
What codebase is closest to plain English in terms of area control, for example being able to write: "If an evil player enters, a pit opens." Within reason it could mean "exactly one evil player" or "at least one evil player". My question is more about how close MUDs are to plain English control.
07 May, 2014, quixadhal wrote in the 25th comment:
Votes: 0
None.

You're looking for natural language processing AND an expert system to correction interpret the results of that processing. No mud codebase that I've ever heard of even comes CLOSE to touching that. Even an Infocom ZIL game, which LOOKS like it deals with English, is pretty codelike under the hood.
09 May, 2014, Nathan wrote in the 26th comment:
Votes: 0
wifidi said:
What codebase is closest to plain English in terms of area control, for example being able to write: "If an evil player enters, a pit opens." Within reason it could mean "exactly one evil player" or "at least one evil player". My question is more about how close MUDs are to plain English control.


You might be able to accomplish that with some kind of scripting trigger, but you'd need to be able translate english to code. So, like:

- some kind of script trigger on entering a room (needs to know who triggered it and be set on the room itself):

if( isPlayerEvil( entering_player ) ) {
'''
do here whatever you mean by "a pit opens". if that means they should "fall" through into another room or whatever. if
you want functionality regarding number of players then you have to count players and track the number of them that are evil
in the room and maybe have an exit trigger that decrease the count too.
'''

teleport_to( pit, player ); '''could be move_to(…), just depends on what you call it'''
}


* that code is merely hypothetical

I suppose the room could have time-triggered code that tries to figure out the number of evil players in a room and do something about it, but then you need such a subsystem and may have to decide how often it should run. You could probably write single player interactive fiction (text only, though) with that behavior (Inform?), but I don't know of any multiplayer game where you can just code behavior by stating what you want in English

I can't say as I know, but I assume some codebases have good support for that kind of scripting. Anyone?
10 May, 2014, Idealiad wrote in the 27th comment:
Votes: 0
Well, there was a mud which used Inform 7 (Guncho), though I don't know the status of it these days. You might be able to find the code on Bitbucket. Inform 7 is a text adventure system with a natural language like syntax. Guncho added multiplayer and network connectivity.
10 May, 2014, hitsuzen wrote in the 28th comment:
Votes: 0
Thanks for the suggestion of lamdamoo – I've played on mushes that were based on that, and I like the mechanics there, but my understanding is that lambdamoo has serious performance issues because it's so old. This is true right? Because I was hoping to have a few areas in my gameworld that are pretty much 'inaccessible' by design due to the number of enemies guarding those rooms (like a room filled with 12 or 20 zombies – you wouldn't try to go into a room like this ever because you'll just get killed by stun lock, the purpose of having a room like this is to convey to the players the seriousness of the situation and to make them think of taking alternate routes to reach places; this could be achieved with just "a door is locked", but you know, not quite as scary).

Actually, I don't have a lot of experience with certain mud codebases in terms of entity support - is it unreasonable to expect support for 15-50 (50 would be the very max, and unlikely for me to consider) entities in a single room, all taking actions?
10 May, 2014, Idealiad wrote in the 29th comment:
Votes: 0
Lambda might be old, but there's an active MOO dev community with newer cores, maybe they're better. I think the group is called MOO-talk on Google Groups.

You know, now that you mention it that reminds me that the HellMOO devs released their core. Wayfar 1444 bases its game on that, and Wayfar has a lot going on under the hood, so I suspect the performance with Hell might be just fine.
10 May, 2014, hitsuzen wrote in the 30th comment:
Votes: 0
I've played HellMOO, it cannot handle 20 entities in a room, the admins ban anyone who instigate situations that cause this, even, because it destabilizes the server.
20.0/30