20 Oct, 2007, Asylumius wrote in the 22nd comment:
Hades_Kane said:
In the same way that not every ROM MUD that uses snippets has every (or even most) snippets available for ROM, I highly doubt that we would all of a sudden see every new MUD popping up that decides to use some stock/pre-built areas use ALL of them. I also doubt that many existing MUDs would make great use of the areas, but undoubtedly many of the 'stock' games would, but with enough variety in the areas available, I highly doubt many MUDs would add ALL of them, and I think in the same way we see a lot of variation in the snippets used, we would see similar variation in the areas that people choose to make. With that, you might try several MUDs and see some of the same areas, but I doubt it would be "EVERY MUD having the exact same stock world." For one, I think most of the 1500+ MUDs at TMC would likely not over-use the area repository, and secondly, I think it would be even a stretch to say "every NEW MUD" having the exact same stock world.
I think you are far overstating how much use it would get, and if you are in fact right that all of a sudden "EVERY MUD" would make use of it, then I think that speaks even more strongly for such a repository because it would be a hugely popular idea and if MudBytes, for example, added that, they would see their traffic and interest in the site explode.
Asylumius said:
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.
In the same way that not every ROM MUD that uses snippets has every (or even most) snippets available for ROM, I highly doubt that we would all of a sudden see every new MUD popping up that decides to use some stock/pre-built areas use ALL of them. I also doubt that many existing MUDs would make great use of the areas, but undoubtedly many of the 'stock' games would, but with enough variety in the areas available, I highly doubt many MUDs would add ALL of them, and I think in the same way we see a lot of variation in the snippets used, we would see similar variation in the areas that people choose to make. With that, you might try several MUDs and see some of the same areas, but I doubt it would be "EVERY MUD having the exact same stock world." For one, I think most of the 1500+ MUDs at TMC would likely not over-use the area repository, and secondly, I think it would be even a stretch to say "every NEW MUD" having the exact same stock world.
I think you are far overstating how much use it would get, and if you are in fact right that all of a sudden "EVERY MUD" would make use of it, then I think that speaks even more strongly for such a repository because it would be a hugely popular idea and if MudBytes, for example, added that, they would see their traffic and interest in the site explode.
At least at first, I doubt many MUDs would being incorporating the areas from such a repository into their MUDs. Likewise, I think most existing MUDs would probably avoid it all together, favoring original content.
That said, I still believe that eventually the content would get stale and become all but stock. I can see how such a system would benefit new MUD admins initially, but I really don't think that in the long run it would go to increase the quality of new MUDs. This is of course just my personal opinion, but once I see an area on enough MUDs, it becomes a turn off. When somebody's makes a post on TMC looking for Admins on a new MUD with nothing but a few snippets, a few widely available area files, and a "fantasy theme" we know exactly what kind of response it's going to get.
Whether or not having all these areas available somewhere would be beneficial to new MUDs depends 100% on how that MUD's admins develop their game, but I still believe that over time players would get tired of them and prospective admins would give MUDs using them no more consideration than hearing, "QuickMUD!!!" and they would become stagnant. I could be completely wrong, but then again so could you.
As far as being a feature that would bring in a lot of traffic, meh. If it's good for the community and worth the investment to Admins, great. Personally, I don't care if our traffic takes a nose dive into the toilet and never comes out, as long as the content on MudBytes is unique and useful.
Like I said though, I'm in favor of an area repository, I'm just not sold on the whole translator deal.
The above is in fact my opinion and NOT the indisputable, unyielding truth from God himself. It is, however, my hippie, left field, whack job, crazy opinion that, thanks to the interwebs, I'm allowed run naked through the streets of forums every screaming at the top of my lungs.
20 Oct, 2007, Hades_Kane wrote in the 23rd comment:
If people continued to contribute areas, I don't think it would become anymore stale and stock than a group of snippets.
Also, there is a difference between trying to think of something useful for new Admins, and something useful toward increasing the quality of new MUDs. There are a lot of crappy snippets out there, and I think it can be argued that doing away with most snippets and making it harder to download and setup pre-packaged codebases would help the quality of new MUDs. Making things easier and more useful new Admins is what I feel is partly to blame with the overall downturn in quality for new MUDs. So, if we're discussing ideas to make new MUDs better and have more quality, then I think we're completely on the wrong topic discussing what would make things easier and more useful.
I do agree that given time, people might get tired of the same areas, but that's going off of the idea that there would initially be a handful of areas and nothing more available. If people continue to contribute areas as they do snippets, the field of available areas will be ever changing. I also think that many people might hold the same attitude, and as certain areas become over used, hopefully they would be phased out of many MUDs as they replace those with either original areas, modify them, or replace them with newly used areas. If that doesn't happen, then so be it, but I do think that overall it could be beneficial in helping MUDs become more fleshed out.
Also, no matter how unique and useful the content on MudBytes is, if you have only like 5 people connecting to it a month, then what's the point? It is a resource site aimed at providing help and resources to the community, and if no one is coming to the site then it's not fulfilling it's entire purpose which makes any work and effort put into the site useless.
Also, I would think that "good for the community and worth the investment" would be parallel to being content "unique and useful" would it not?
I am at least moderately concerned, however, if the Administration of the site has little desire or care for how much traffic the site draws. As a MUD developer advertising on the site, and as (so far) a small time code contributor to the site, I wonder if I'm wasting my time in contributing to the site if the Administration is more concerned over advancing personal agendas over the traffic of the site. Afterall, as someone who is concerned with driving traffic to their MUD or their code releases, then it is indeed in my best interests to see traffic to the site overall increase. I would think and hope that the Administration of the site would share a similar opinion.
If something has a chance at driving traffic to the site, that would be because it is useful and good for the community. So I really don't see a conflict here.
In regards to a translator, I'm not sure that a full area translation would be worth the effort. That's why I've stated I think the most efficient approach would be to work only on translating room layout and description. Since I doubt that there would be too much of a change between most derivs of a parent codebase, I think that would be the easiest way to reduce down to a common denominator, and I doubt it would be too difficult to include a small amount of instructions on copying over some code for room values that might differ from deriv to deriv. Likewise, with just area layout and description, I think it would be much easier to work between completely different codebases. Included notes such as recommendation for area interactivity, theme, quests, mobs/objects etc. would definitely be a boon as well.
Also, there is a difference between trying to think of something useful for new Admins, and something useful toward increasing the quality of new MUDs. There are a lot of crappy snippets out there, and I think it can be argued that doing away with most snippets and making it harder to download and setup pre-packaged codebases would help the quality of new MUDs. Making things easier and more useful new Admins is what I feel is partly to blame with the overall downturn in quality for new MUDs. So, if we're discussing ideas to make new MUDs better and have more quality, then I think we're completely on the wrong topic discussing what would make things easier and more useful.
I do agree that given time, people might get tired of the same areas, but that's going off of the idea that there would initially be a handful of areas and nothing more available. If people continue to contribute areas as they do snippets, the field of available areas will be ever changing. I also think that many people might hold the same attitude, and as certain areas become over used, hopefully they would be phased out of many MUDs as they replace those with either original areas, modify them, or replace them with newly used areas. If that doesn't happen, then so be it, but I do think that overall it could be beneficial in helping MUDs become more fleshed out.
Also, no matter how unique and useful the content on MudBytes is, if you have only like 5 people connecting to it a month, then what's the point? It is a resource site aimed at providing help and resources to the community, and if no one is coming to the site then it's not fulfilling it's entire purpose which makes any work and effort put into the site useless.
Also, I would think that "good for the community and worth the investment" would be parallel to being content "unique and useful" would it not?
I am at least moderately concerned, however, if the Administration of the site has little desire or care for how much traffic the site draws. As a MUD developer advertising on the site, and as (so far) a small time code contributor to the site, I wonder if I'm wasting my time in contributing to the site if the Administration is more concerned over advancing personal agendas over the traffic of the site. Afterall, as someone who is concerned with driving traffic to their MUD or their code releases, then it is indeed in my best interests to see traffic to the site overall increase. I would think and hope that the Administration of the site would share a similar opinion.
If something has a chance at driving traffic to the site, that would be because it is useful and good for the community. So I really don't see a conflict here.
In regards to a translator, I'm not sure that a full area translation would be worth the effort. That's why I've stated I think the most efficient approach would be to work only on translating room layout and description. Since I doubt that there would be too much of a change between most derivs of a parent codebase, I think that would be the easiest way to reduce down to a common denominator, and I doubt it would be too difficult to include a small amount of instructions on copying over some code for room values that might differ from deriv to deriv. Likewise, with just area layout and description, I think it would be much easier to work between completely different codebases. Included notes such as recommendation for area interactivity, theme, quests, mobs/objects etc. would definitely be a boon as well.
20 Oct, 2007, Tyche wrote in the 24th comment:
I've already written this program.
20 Oct, 2007, Davion wrote in the 25th comment:
Hades_Kane said:
I am at least moderately concerned, however, if the Administration of the site has little desire or care for how much traffic the site draws. As a MUD developer advertising on the site, and as (so far) a small time code contributor to the site, I wonder if I'm wasting my time in contributing to the site if the Administration is more concerned over advancing personal agendas over the traffic of the site. Afterall, as someone who is concerned with driving traffic to their MUD or their code releases, then it is indeed in my best interests to see traffic to the site overall increase. I would think and hope that the Administration of the site would share a similar opinion.
We aren't going to sell our values for a few hits ;). But if you're really worried about our traffic (which there's no reason to be…), just think of us when you're out in this big old internet posting link backs to valuable resource material. We already have a few projects on the go for MudBytes and adding another big project could push a release back even farther. They are projects we feel will suite the site better; we are after all, all about the code ;).
Hades_Kane said:
In regards to a translator, I'm not sure that a full area translation would be worth the effort. That's why I've stated I think the most efficient approach would be to work only on translating room layout and description. Since I doubt that there would be too much of a change between most derivs of a parent codebase, I think that would be the easiest way to reduce down to a common denominator, and I doubt it would be too difficult to include a small amount of instructions on copying over some code for room values that might differ from deriv to deriv. Likewise, with just area layout and description, I think it would be much easier to work between completely different codebases. Included notes such as recommendation for area interactivity, theme, quests, mobs/objects etc. would definitely be a boon as well.
I think room and exit layout will be the easiest, but there's no way you can just end there. An area is hardly just rooms and exits so calling it an area convert would be an outright lie! I don't think porting mobs and objects are totally out of the question, or even resets for that matter. If I were to do that, I'd most likely use a template system for it. Gather what information I'd need from an object, feed it to a templater, output in X format. There is no way in hell that this data is going to be a mirror image of the other, but it'll be close and exist. Balancing is an issue for snippets as well, so cookie-cutter areas will end up like cookie-cutter snippets. Being stuck with simply editing mobs/objects stats, creating shops, and maybe a few quests isn't nearly as bad as being stuck with hacking an entire area together.
21 Oct, 2007, Davion wrote in the 26th comment:
While roaming back in this thread, it seems I missed a small post. I do that. Now.. Tyche…
This is a pretty bold statement! This seems to be a feature people want! Care to elaborate on some of the problems meantioned in an area converter here?
Quote
I've already written this program.
This is a pretty bold statement! This seems to be a feature people want! Care to elaborate on some of the problems meantioned in an area converter here?
23 Oct, 2007, Tyche wrote in the 27th comment:
I created a utility that can read various versions of TinyMud, TeenyMud, TinyMuck, DikuMud, CircleMud, Merc, ROM, and Smaug databases/zones/areas and outputs either a TeensyMud database or a "universal" YAML file. It understands Rooms, Exits, Zones, Resets, Objects/Things, Mobiles, TinyCode/MobProgs, Affects, ExtraDescriptions, Tiny Characters (not Diku player files), Helps, Dice, Shops and Specials. It translates all flags to a set of common symbols, and will renumber and reassign all oids/vnums.
Adding other formats like PernMush, AberMud, CoffeMud and many others would be easy. For systems like more modern Mushes and Muxes, LPMuds, Cold, and MOO that represent rooms, mobs and objects through execution of code (or minimally runtime initialization), it would be far easier to dump the objects via the mud's code than to parse each mud's programming language looking for some rather lib specific initialization mechanisms.
Actually the "universal" format isn't relevant to the task of translation, other than it being a convenient mechanism to store the snapshot of the objects in memory. The more important and useful intermediate format is how the dynamic objects themselves are handled. Outputting to another mud specific format other than TeensyMUD would be trivial.
Adding other formats like PernMush, AberMud, CoffeMud and many others would be easy. For systems like more modern Mushes and Muxes, LPMuds, Cold, and MOO that represent rooms, mobs and objects through execution of code (or minimally runtime initialization), it would be far easier to dump the objects via the mud's code than to parse each mud's programming language looking for some rather lib specific initialization mechanisms.
Actually the "universal" format isn't relevant to the task of translation, other than it being a convenient mechanism to store the snapshot of the objects in memory. The more important and useful intermediate format is how the dynamic objects themselves are handled. Outputting to another mud specific format other than TeensyMUD would be trivial.
23 Oct, 2007, David Haley wrote in the 28th comment:
How do you deal with issues of data loss? I suppose you just accept to lose that data. More interestingly, how do you deal with needing data where you don't have any? That is, if format A simply doesn't have some concept, and format B requires it, what value do you use?
23 Oct, 2007, Guest wrote in the 29th comment:
I don't know how Tyche deals with missing or unsupported elements, but in the case of the AFKMud areaconvertor when it runs over an area that doesn't support new stuff we've added, I just have the code assign sane defaults to it as the job is processed. If they need fine-tuning the OLC exists for a reason :) If I run into something the other area has but we don't, it just gets dropped since it has no relevance to us anyway.
23 Oct, 2007, Tyche wrote in the 30th comment:
DavidHaley said:
How do you deal with issues of data loss? I suppose you just accept to lose that data. More interestingly, how do you deal with needing data where you don't have any? That is, if format A simply doesn't have some concept, and format B requires it, what value do you use?
There isn't any generic answer as it depends on the data. I either drop it, translate it, set it to a default, or provide an option switch for alternatives.
24 Oct, 2007, Davion wrote in the 31st comment:
Is this project of yours open source? I'd love to take a look at it.I've been considering using YAML as the markup language. Also, can you reverse the translation into any of those formats?
26 Oct, 2007, Tyche wrote in the 32nd comment:
Davion said:
Is this project of yours open source? I'd love to take a look at it.I've been considering using YAML as the markup language. Also, can you reverse the translation into any of those formats?
I haven't decided what to do with it yet. It doesn't write an area file yet, well at least not for a Diku derivative one anyway. Yes you would be able to round trip a translation. That might be useful for renumbering areas.
Random Picks
In the same way that not every ROM MUD that uses snippets has every (or even most) snippets available for ROM, I highly doubt that we would all of a sudden see every new MUD popping up that decides to use some stock/pre-built areas use ALL of them. I also doubt that many existing MUDs would make great use of the areas, but undoubtedly many of the 'stock' games would, but with enough variety in the areas available, I highly doubt many MUDs would add ALL of them, and I think in the same way we see a lot of variation in the snippets used, we would see similar variation in the areas that people choose to make. With that, you might try several MUDs and see some of the same areas, but I doubt it would be "EVERY MUD having the exact same stock world." For one, I think most of the 1500+ MUDs at TMC would likely not over-use the area repository, and secondly, I think it would be even a stretch to say "every NEW MUD" having the exact same stock world.
I think you are far overstating how much use it would get, and if you are in fact right that all of a sudden "EVERY MUD" would make use of it, then I think that speaks even more strongly for such a repository because it would be a hugely popular idea and if MudBytes, for example, added that, they would see their traffic and interest in the site explode.