18 Oct, 2007, Davion wrote in the 1st comment:
Votes: 0
Hades_Kane said:
I don't see many area repositories, so that might be a bit of a selling point, but really it would only be useful for new startup stock games as anyone who has done -anything- with their game will soon find their areas are no longer compatible with stock games,


Seeing as pretty much no one has done this on any major site, I think this would be an awesome focus of your site. It's something I've been thinking about adding to MudBytes for a little while now, just never got the effort to do so. This might also give these programmers a reason to keep thier MUD able to read stock format. As many solitary programmers will tell you, building sucks.

Hades_Kane said:
I imagine the only people who would really be interested in using an area repository are the people who wouldn't have the capability of taking an area not compatible with their game and converting it


This is something I've thought a lot about and have come down to this- Translation. Some form of literal translator for most of the area formats. My main idea was to convert all area's to a common format, and then have the ability to spit out an area file that will load in a codebase of your choice. This is no easy task. You'd basically require your website to have the loading protocals to most of the codebases out there, then a way to output it in that format. This is all just an idea floating around in my head though, could just be my insane ramblings ;). I think something like this would be quite handy.
18 Oct, 2007, Kayle wrote in the 2nd comment:
Votes: 0
Actually, MudBytes has recently opened a sort of Area Repository. >.> I'm actually moderating it, and they have an Area folder under most of the codebases available for download.
18 Oct, 2007, David Haley wrote in the 3rd comment:
Votes: 0
I think the idea is to have a section explicitly devoted to areas, where you can search by properties relevant to areas, and so forth. I'm not sure that folders hidden away in several sub folders of a "code repository" is quite obvious enough. :wink:

Davion said:
This is something I've thought a lot about and have come down to this- Translation. Some form of literal translator for most of the area formats.

There are a few problems. The first is the formats, and that's actually simple enough. The real problem is that different area formats actually represent different data: there are some notions that simply don't exist for some code bases. So, if you make an area for format X, and want to translate it to format Y, but Y requires you to have a lot of information that X doesn't have … what do you do? If X has more information than Y, well, you can just throw away that information (even though it might drastically change an area). So IMHO the really hard part is not just going from one format to the other, but in dealing with discrepancies in what is actually stored in the formats.
18 Oct, 2007, Davion wrote in the 4th comment:
Votes: 0
DavidHaley said:
The real problem is that different area formats actually represent different data: there are some notions that simply don't exist for some code bases. So, if you make an area for format X, and want to translate it to format Y, but Y requires you to have a lot of information that X doesn't have … what do you do? If X has more information than Y, well, you can just throw away that information (even though it might drastically change an area).


That's pretty much the whole reason why I haven't put for the effort into some hard code. But this is all part of translation. A large part of this is going to rely on the universal format that would be invented. Each field will have to have some way to represent itself in each of the codebases. Building the translater is what's going to take a lot of time (and require a lot of knoweldge on all the codebases you're dealing with.) I think translating between Diku's will be trivial. The hard part will be getting an LP area to work on ROM and visa versa :).
18 Oct, 2007, David Haley wrote in the 5th comment:
Votes: 0
The only way for that to be feasible is if you restrict yourself to stock versions of the codebases. It's easy to see why it would be all but impossible to have a "universal format" that included specific MUDs. It would be crazy to try to capture every single MUD out there in some universal format.

Now, if you're limiting yourself to the stock versions, the problem is one of merging concepts from each codebase family. Most concepts will be fairly ubiquitous (e.g. 'room', 'exit', 'mobile') but obviously there will be big differences when you get down to nitty-gritty details.

To be honest, I'm just really not sure the project is worth it. :thinking: Translating between "cousins" (e.g. Diku derivatives) might be a much better target, but trying to translate between very different branches might be harder than it's worth.
18 Oct, 2007, Davion wrote in the 6th comment:
Votes: 0
DavidHaley said:
Translating between "cousins" (e.g. Diku derivatives) might be a much better target, but trying to translate between very different branches might be harder than it's worth.


Lets say, end result then? Don't have to start big ;). But the entire thing might be more than it's worth. Kinda on the fense about it. I have things on the go anyways and probably can't get to working with this idea, tis why I threw it up here.
18 Oct, 2007, Guest wrote in the 7th comment:
Votes: 0
DavidHaley said:
The only way for that to be feasible is if you restrict yourself to stock versions of the codebases.


I think it would be insane to think of trying anything beyond this myself. Coders using evolved and modified codebases should keep compatibility with the parent area format, if only for this very reason. Most area releases are done on the main distribution. Such as Smaug 1.4 instead of AFKMud, or Rom 2.4 instead of Dawn of Time, etc. The lowest common denominator for the particular base.

Regardless, it's not going to be an easy project. The area translation code I wrote into AFKMud has a lot of branches and conditional checks, and that's just for flavors of Smaug areas.
18 Oct, 2007, Asylumius wrote in the 8th comment:
Votes: 0
Even if most MUD admins did keep their code somewhat backwards compatible with stock load_xxx() code, most of them would wind up with an area that's still 90% useless.

My old codebase wasn't terribly different or special, and aside from a lot of new fields the area structs weren't THAT different, but even if I did download someone else's area and loaded it, even a ROM area, most of the flags wouldn't match so the various entities attributes would all be random(ish). The dice would probably all have to be reworked to fit in with my MUDs combat/level logic.

For anyone running a MUD that isn' almost completely stock, importing areas (even from a universal format) would require going through every mob, obj, room, prog, and whatever other sections exist and applying minor tweaks. At this point, you're better off just writing the area yourself or just using the descriptions from other areas and pasting them in.

Technical issues aside, I don't really think this would help anyone. When most of us see a stock ROM MUD with 20 odd snippets from one of the popular code repos, we don't get excited. If everyone with a stock(ish) MUD could download a handful of areas and just plug them in, after a while, people (players mainly) will just get bored with them. Nobody cares if your MUD has Midgaard, and eventually these areas would end up the same way.

My suggestion is either learn to enjoy building or create systems that don't require the kind of time and detail building entails.
18 Oct, 2007, Hades_Kane wrote in the 9th comment:
Votes: 0
An alternative to a universal area format and all that other stuff would to create something that could take the layout of the rooms and the descriptions and plug that in. I think most people would agree that writing the descriptions is the most tiresome part. Usually for me, after I get all of the descriptions done (and only the descriptions), the area is a day or two from being finished depending on scripts. So, that might be a better focus than trying to convert object, mob, and program/script data from one codebase to another. It would also force at least some variation in the areas, but would still be useful enough for people to use.
19 Oct, 2007, David Haley wrote in the 10th comment:
Votes: 0
That would be helpful, but personally I find the descriptions to be fairly easy. The real challenge for me is twofold: (1) a rich interactivity of an area based on progs and their interactions, and (2) balancing the objects and mobs in some coherent matter. Of course, (2) is more or less easy depending on what policies you have in place for balancing. But for me, in any case, drawing a map and describing what is where is relatively easy, and the bulk of the work is in setting up the rich interactivity and autonomy (simulated life) I expect from areas.
19 Oct, 2007, David Haley wrote in the 11th comment:
Votes: 0
To elaborate a bit:
Only considering basic room layout and room descriptions is probably the task most likely to be successful. Being able to harmonize layouts would be a great start, even though it still leaves a lot to be done.

That said, I think the points Asylumius makes are important. Is it really that valuable to be able to share the same areas across MUDs? Would there even be demand for such a thing? It would be a good way for people to get started, I suppose, but they can already do that with the existing stock areas. Before any such endeavor is seriously considered, it would be worthwhile to see just how much demand there would actually be.
19 Oct, 2007, Darwin wrote in the 12th comment:
Votes: 0
Could a mod split this thread? The current conversation is no longer on the posted topic.
19 Oct, 2007, Guest wrote in the 13th comment:
Votes: 0
Split at post #17 which appeared to be a pretty clear point of departure.

The idea of being able to use an area writing utility to accept the descriptions for the rooms, and possibly the names and exit descriptions as well sounds like it would be pretty useful to me. Especially if it was able to write out several different stock formats. It could even be a springboard to a full scale translation system later on where you could convert freely from one stock format to another.
19 Oct, 2007, Darwin wrote in the 14th comment:
Votes: 0
Probably the best "standard" format to use would be an XML type. It would make importing/exporting areas a bit easier. The guts of the utility could then use the imported data to write out the converted area file, or vice versa.

Still, there would probably be extra data, not enough data, or incompatible data to deal with. How that is dealt with would probably take a hefty bit of work.
19 Oct, 2007, Cratylus wrote in the 15th comment:
Votes: 0
Automated translation between area formats is IMO probably
a lot like automated translation of human languages. An amusing
exercise is to use the altavista babel fish to compose a message,
run it through a language or two a few times, then put it back
into English and see what it looks like.

English to German and back (just one run):
Quote
Automated translation between range formats is IMO probably much like automated translation of the human languages. To see an amusing exercise is to use the Alta Vista Babel of fish, in order to exist an announcement to let it run by a language or two some mark, then it back in English set and which it looks as.


English to Japanese and back (just one run):
Quote
The translation where between of the format of area is automated like the translation where language of the human is automated IMO perhaps is many. Message, it should use babelfish of altavista for forming in order to move that language due to two several times being, next funny practice inserts that in English, and sees in those where that is visible.


This exercise is amusing because in the end, it's sometimes
possible to tease out what was meant using your human
capacity to fill in blanks and interpret context.

The reason there is still a need for human translators is that
there are nuances and quirks in some languages that
simply do not map to another, and creativity is required
to fill the lacunae of meaning. I found an amusing exploration
of this concept here: http://www.xibalba.demon.co.uk/jbr/lingo...


A computer program lacks this gift of interpretation,
so even a minor error in translation requires human intervention.
And this is just for minor variances in dialect for common
codebases. You should see about translating LPC areas to
a Diku derivative.

I coded a limited sort of Smaug-to-Dead Souls translator a while
back. Definitely opened my eyes to a lot of the challenges
involved in a Universal Translator project. I would suggest that
anyone undertaking such an endeavor not strive for one-button
perfection, but rather to make it so the heavy-lifting gruntwork
is done *relatively* well, so that the human intervention that *will*
be required later involves touching up and minor adjustments.

I just don't think a universal area translator would ever
rise above the "sounds like it would be a neat idea" level. As a fun
project for yourself you can do worse. As a useful resource for
the community…I'm not sure I'd aim quite that high.

-Crat
http://lpmuds.net
20 Oct, 2007, Hades_Kane wrote in the 16th comment:
Votes: 0
DavidHaley said:
To elaborate a bit:
That said, I think the points Asylumius makes are important. Is it really that valuable to be able to share the same areas across MUDs? Would there even be demand for such a thing? It would be a good way for people to get started, I suppose, but they can already do that with the existing stock areas. Before any such endeavor is seriously considered, it would be worthwhile to see just how much demand there would actually be.


If I weren't interested in having all original areas built for my MUD, and were more or less using the areas a filler, or would otherwise be fine with "stock" or "pre built" areas, then I would much rather pick and choose from a large database of areas rather than just go with what the MUD is packaged with. If there were large enough of a database, with varying enough of themes, then I think that a good number of MUDs would end up with a nice mix of stock, pre-built, and original areas and it would break up the monotony of hundreds of MUDs with an almost exact list of the first 20 areas that the player will see.

Personally, I'd have no interest in using it, and it's likely I would be able to contribute considering the relative specifics of my game's theme (unless I was simply interested in expressing creativity in an area not used for my game [which isn't entirely out of the question]) but I do think that plenty of starting games would use it. I mean, think about how many MUDs out there are mostly stock, and I think you have an extremely large target audience outright.
20 Oct, 2007, Asylumius wrote in the 17th comment:
Votes: 0
Quote
If I weren't interested in having all original areas built for my MUD, and were more or less using the areas a filler, or would otherwise be fine with "stock" or "pre built" areas, then I would much rather pick and choose from a large database of areas rather than just go with what the MUD is packaged with. If there were large enough of a database, with varying enough of themes, then I think that a good number of MUDs would end up with a nice mix of stock, pre-built, and original areas and it would break up the monotony of hundreds of MUDs with an almost exact list of the first 20 areas that the player will see.

Personally, I'd have no interest in using it, and it's likely I would be able to contribute considering the relative specifics of my game's theme (unless I was simply interested in expressing creativity in an area not used for my game [which isn't entirely out of the question]) but I do think that plenty of starting games would use it. I mean, think about how many MUDs out there are mostly stock, and I think you have an extremely large target audience outright.


This would probably hold true for a while, but eventually I think these areas would become so over used that people won't want them. Snippets are widely available and, to an extent, so are coders, which makes that "half" of the game easier to create. It's certainly understandable that people would appreciate being able to download areas to "get off the ground" with but one thing I think a lot of people don't realize is that they probably won't be as interested in those areas, even if they are just a starting point, if EVERYONE has them.

I suppose it's an alright idea. If people want to use it, then I suppose it's worth making. I'm still not entirely convinced an "universal format" is necessary. In fact, forcing people to pick from area formats from their most common denominator (ie, ROM, Smaug, Circle) might be a good thing, in that it would stop EVERY MUD from having the exact same stock world.

I doubt the end result of a global converter would be very useful or justify the huge number of modules it would require. The project would either requires insane amounts of very picky code that still wouldn't work for everyone's areas -OR- would leave the areas in a state that would require more tweaking to get playable than most people would care to do for areas they probably intend to replace later.

Maybe a separate repository for areas, maps, concept materials (drawings, writings, etc), area building docs / programs, etc. is the way to go?

In the end it comes down to whether or not people are willing to invest the time it would take to populate a database (whatever that would be) with enough quality material to make it appealing to builders.

One thing that I think would be really nice is a set of tools or resources that are aimed at helping area BUILDERS, specifically. Not necessarily just a big list of area files that an admin can plug into their MUD but things sort of like I listed above, that would help area creators be more productive and creative. Giving people a big bag of used, hand-me-down area files that are incomplete or don't work doesn't sound like the best solution.
20 Oct, 2007, Guest wrote in the 18th comment:
Votes: 0
Asylumius said:
I doubt the end result of a global converter would be very useful or justify the huge number of modules it would require. The project would either requires insane amounts of very picky code that still wouldn't work for everyone's areas -OR- would leave the areas in a state that would require more tweaking to get playable than most people would care to do for areas they probably intend to replace later.


Probably true. I imagine it would require BOTH an insane number of modules ( one each for read/write ) and insane amounts of picky code that still wouldn't work for everyone's areas. Even if we stuck strictly to converting formats for stock codebases. As I mentioned before, the conversion routines I wrote for AFKMud just to translate Smaug formats requires several exceptions and conditions be checked and that's within the same family tree :)
20 Oct, 2007, kiasyn wrote in the 19th comment:
Votes: 0
I think you're all overestimating the difficulty of this. To teach it the file formats you would probably have to come up with a new file format, similar to:

#AREA {$area_name|no_tilde}~
#VERSION 3
#AUTHOR {$author|no_tilde}~
#RANGES {$low_hard_level} {$high_hard_level} {$low_soft_level} {$high_hard_level}
#FLAGS {$flags}

#MOBILES
{$mobile_section|use_module 'mobiles'}
#0

EOF

Module mobiles:
#{$vnum}
{$short|no_tilde}~
{$long|no_tilde}~


etc.
20 Oct, 2007, Asylumius wrote in the 20th comment:
Votes: 0
I think two things make it complicated and/or less useful:

1. The various flags, options, and fields in one codebase won't match up the those of another. The lack of parallels between the data would often result in the names and descriptions being the only re-usable data in the area.

2. Any variation in the format will cause the parsers to either bug out or apply the wrong data to the wrong fields. If I add a "happyness" field to my mobs in Rom24b6 and a night_description, suddenly we need a modified module, depending on how I've coded my MUD to save/load that data.

This brings us back to the issues that yes, it's possible, and probably not even that difficult (technically speaking), but once you get to the point where you lose a certain amount of usable data in translation, what's the point?

I just don't see it meeting the level of convenience that it would need to be any better of a solution than logging on a MUD and copying it's areas one room at a time.

My $0.02.
0.0/32