20 May, 2011, plamzi wrote in the 1st comment:
Votes: 0
Due to my ill-concealed hatred for OLC, I've sunk an ungodly amount of hours into a new (and I think, exciting) project. Before I sink an even ungodlier amount, I'd like to gauge the amount of interest the community has in a configurable web UI for MUD zone creation. If there is interest, I would very much like to informally "sign up" a few devs who can help me test the configurability aspect (as in make it work for your MUD) as the tool is being created.

If you're not into reading bullet lists, head over to the basic demo @ http://bedlam.gotdns.com:8088/areabuilde... (and keep in mind that it's in a POC stage). Make sure to view the sample profile link.

The concept:

* A free online web-based zone builder that makes building for multiple MUDs easy / fast / fun on any platform.

* The UI will be configurable via "profiles" and will make only the most basic assumptions about the game being built for (e. g. there are rooms, some of which will be linked, the MUD can read zones from flat text files, etc.).

* Admins of different MUDs who wish to take advantage of this tool will create a profile (config file) which controls how the UI is organized (form design) and the formatting of the output. They will be able to tweak and update these profiles to ensure that the zone files created by the tool remain compatible with their game.

* Building will take place "offline," with no special access to the actual MUD required for anyone who wishes to build.

* Builders will have accounts, will be able to save (session or export) / resume (via load or import) / email to self / submit zone (email to MUD admin).

* The product of the tool will be a full set of world files, each in a pre-defined text format, ready or nearly ready to be put into play.


Sneak Preview:

20 May, 2011, KaVir wrote in the 2nd comment:
Votes: 0
I remember the days when muds wanted to add OLC to get away from offline building tools (like MZF). Still, the grass is always greener on the other side of the fence, and I'm sure you'll find people interested in trying it out.

Personally I think it'd be interesting to combine it with a browser-based client, giving the users a sort of "builder mode" that has the advantages of both OLC and a browser-based building tool.
20 May, 2011, plamzi wrote in the 3rd comment:
Votes: 0
KaVir said:
I remember the days when muds wanted to add OLC to get away from offline building tools (like MZF). Still, the grass is always greener on the other side of the fence, and I'm sure you'll find people interested in trying it out.

Personally I think it'd be interesting to combine it with a browser-based client, giving the users a sort of "builder mode" that has the advantages of both OLC and a browser-based building tool.


In my experience, the most productive zone builders (read, those who actually finish a zone) create their zones offline anyway, at least the first pass (99% of the work). What I'm going for is not a full replacement for OLC but offering the right tool for the right job. OLC is good enough for tweaking, very poor at helping you build large zones fast. Sure, there's a bit of a wonder factor when you're building and seeing things come alive, but that wears off fast (and the web UI will match that factor by showing Bedlam icons for room backgrounds, fantasy mobs, and objects, as people create them).

Sure, I can work towards a custom UI that plugs live into my builder instance but that's not going to do anyone else any good. By taking the UI offline and making the forms customizable, I will be able to offer this tool to anyone else whose MUD has rooms and is able to read flat file world data. At least, that's the goal, but since it's a hugely involved affair (much more involved than custom building for my game only), first I'd like to see if there's any interest.

There are many good reasons to jump on board of such a project, I think. The most obvious ones: it supercharges building, it's in the cloud and can be done anytime anywhere, the builder gets to keep their creation. Another benefit I haven't mentioned is that the learning curve for a new/young builder will drop dramatically. By today's standards, OLC is plain weird. But everyone knows how to fill a web form. And building for a MUD shouldn't be any harder than that.
20 May, 2011, Hokai wrote in the 4th comment:
Votes: 0
I like this idea
20 May, 2011, Scandum wrote in the 5th comment:
Votes: 0
Back when I dealt with building 90% of the work was writing and debugging scripts, it'd be extremely tedious doing this offline.
20 May, 2011, Kline wrote in the 6th comment:
Votes: 0
Hokai said:
I like this idea
21 May, 2011, Runter wrote in the 7th comment:
Votes: 0
Well, the reason offline editing is appealing is because at least at first glance the data seems more important than the environment the data is used in. I think something like this would be better suited as a web OLC rather than a web offline creation. The interface itself is looking good.
21 May, 2011, Lyanic wrote in the 8th comment:
Votes: 0
This seems somewhat familiar. Possibly like a tool that I've used for the past decade… :-p

I suppose the key difference is that mine isn't configurable, and thus its output format is tied to that of my game.
21 May, 2011, Dean wrote in the 9th comment:
Votes: 0
Runter said:
Well, the reason offline editing is appealing is because at least at first glance the data seems more important than the environment the data is used in. I think something like this would be better suited as a web OLC rather than a web offline creation. The interface itself is looking good.


This, I think.
21 May, 2011, plamzi wrote in the 10th comment:
Votes: 0
Well, I'm glad I asked before dedicating a small lifetime! :biggrin:

It sounds like there may not be an audience for this: devs of established games already have similar tools or are troubled by the necessary offline aspect (which makes this a tool for their builders, not for the devs themselves). And devs of new games (if they even know about this forum) probably don't know enough to decide whether something like this is worth having. In either case, I think this was a missed opportunity.

Going to alter course, then, table configurability and focus on a tool customized to my game. That way I can build the UI a lot faster, and I don't have to keep it offline.

Thanks for your honest responses.
22 May, 2011, quixadhal wrote in the 11th comment:
Votes: 0
Actually, if you make it somewhat configurable, it could be a nice web-based online OLC interface. You just need to have each action in a table so it emits the right OLC commands for the target game. Obviously I'd focus on your own first, but if you keep that stuff loadable, others could alter it to suit their own game's needs.
22 May, 2011, plamzi wrote in the 12th comment:
Votes: 0
quixadhal said:
Actually, if you make it somewhat configurable, it could be a nice web-based online OLC interface. You just need to have each action in a table so it emits the right OLC commands for the target game. Obviously I'd focus on your own first, but if you keep that stuff loadable, others could alter it to suit their own game's needs.


Not interested in layering this over OLC – that just sounds like tying one's feet to a dead horse, and will make configurability even more hellish. From what I've seen so far, people are not exactly clamoring for a web-based OLC so I sense it will be a wasted effort.

But, if anyone's interested in integrating something like this into their own OLC in a custom solution, I will package up and send them the website code so far (before I start coding in a different direction). PM if you want it.

I figure I'll finish migrating my world files to SQL and plug this UI into the database–that way I don't have to worry about import/export at all, and the server can be told exactly what has changed and what needs to be refreshed. That was my original plan but then I wanted to try and make a community contribution…
22 May, 2011, Scandum wrote in the 13th comment:
Votes: 0
It's possible to use MSDP / GMCP as a universal interface, which would eliminate the configuration problems, though adding an implementation burden server side. If you create a good enough automapper there might be some interest.
23 May, 2011, Runter wrote in the 14th comment:
Votes: 0
14 Jun, 2011, Nathan wrote in the 15th comment:
Votes: 0
I'd like to interject that making this configurable for many games doesn't seem like it has a downside (other than a bit more time spent on clean design). I'd suggest you try and make it as open to adjustment as possible, and not force it to be an online tool (in the sense of needing the game to work). If you make this work with some kind of configuration file then you can write the one for your game, and leave any ones for other muds up to someone who wants it. In the same way and if you want to use SQL, then write a simple plugin architecture that permits you to write an interface to sql without forcing the issue. That could be good for anyone wanting to integrate it into their database.

Your choice, but it seems to me that flexibility is favorable in most cases.
14 Jun, 2011, plamzi wrote in the 16th comment:
Votes: 0
Nathan said:
I'd like to interject that making this configurable for many games doesn't seem like it has a downside (other than a bit more time spent on clean design). I'd suggest you try and make it as open to adjustment as possible, and not force it to be an online tool (in the sense of needing the game to work). If you make this work with some kind of configuration file then you can write the one for your game, and leave any ones for other muds up to someone who wants it. In the same way and if you want to use SQL, then write a simple plugin architecture that permits you to write an interface to sql without forcing the issue. That could be good for anyone wanting to integrate it into their database.

Your choice, but it seems to me that flexibility is favorable in most cases.


The POC shows precisely that you can structure the UI using a config file. The same config file can be used to structure the output for any given MUD (the code for actual output generation was not written). The idea was to leave config file creation and updates to MUD devs who want to make use of the tool.

I realize that SQL can be an added layer, but it will at least double the scale of an already big project to have to support both flat files and SQL queries. At this point in time, I have much more important projects with more immediate benefits, which is why I wanted to gauge the interest and do an either/or but not both.

Several people have requested the POC code, so maybe one of them will continue in the universal flat file direction.
14 Jun, 2011, Rarva.Riendf wrote in the 17th comment:
Votes: 0
Quote
I realize that SQL can be an added layer, but it will at least double the scale of an already big project to have to support both flat files and SQL queries

Well you need some sort of database to store the data, and it is way better to use one that use simple sql request. At the very least using another engine is then up to the one who want it. Some engine use flat files as well, even with sql, so it is a wint on both side.

http://en.wikipedia.org/wiki/Flat_file_d...

Maybe you could wotk together btw ?
http://www.mudbytes.net/topic-3437
14 Jun, 2011, plamzi wrote in the 18th comment:
Votes: 0
Rarva.Riendf said:
Quote
I realize that SQL can be an added layer, but it will at least double the scale of an already big project to have to support both flat files and SQL queries

Well you need some sort of database to store the data, and it is way better to use one that use simple sql request. At the very least using another engine is then up to the one who want it. Some engine use flat files as well, even with sql, so it is a win on both side.

http://en.wikipedia.org/wiki/Flat_file_d...


It is possible to generate flat world files entirely on the client side, without any need to talk to a back-end db or anything but the most basic server-side scripts–this translates into much less work. Flat-file db or not, it will be at least double the work to have a configurable UI that is able to parse and generate flat world files as well as to generate the right db queries for direct insertion.

I did get a sense that devs would rather have something that plugs into their MUDs directly, but it's not like we have a standard API for reading/writing world changes to a live server. Some people have databases they'd want to write to, others might expect a flat file to be overwritten someplace on their server and the server to be alerted to re-process, yet others might want a background telnet connection pushing the changes via good old OLC, which itself can vary from one game to another…

From a practical standpoint, I think that once you decide you'll be making a web-based OLC replacement rather than an offline world editor, you either have to kiss "universality" goodbye, or bundle the whole thing with its own API which devs would have to implement on their server if they want to have the "live" functionality. Did I say double the work? It's probably close to x3, x4.

Rarva.Riendf said:
Maybe you could wotk together btw ?
http://www.mudbytes.net/topic-3437


I think JohnnyStarr wants to use his project to improve upon his Ruby on Rails skills. His idea is very close to mine but his generated more excitement than mine did, maybe because of his choice of a more fashionable server-side framework. I, on the other hand, intend to write my own (minimalist) php and offload as much as possible on the client. Different strokes.
14 Jun, 2011, Rarva.Riendf wrote in the 19th comment:
Votes: 0
You mean you are storing your data directly in the file format your mud handle ? Otherwise I really do not get what you mean.
Using a db is way easier and less work than using your own fileformat to parse data, be it a real one or a simple one ( I use Derby with Java, well enough for small apps as an example, and it use flat files, so you can really move it easily,no need for dumping a database recreate it etc) Or use XML (basically the same thing as a flat files db when used this way)
And once you have a 'framework' that use one, it is easy for everyone, including you, to make the final output whatever you want.
Loading a room, will be some query that will fill an object with values but just looking at the code will make so all coders know what do to to load them from the database themselves without using your tools, thus able to do whatever they want.

Or do I miss something obvious ?
15 Jun, 2011, plamzi wrote in the 20th comment:
Votes: 0
Rarva.Riendf said:
You mean you are storing your data directly in the file format your mud handle ?

… And once you have a 'framework' that use one, it is easy for everyone, including you, to make the final output whatever you want.


That's exactly what I mean. If all the UI needs to do is be able to import and export (generate) relatively small but varied flat world files, then I see a database as an unnecessary complication. If you have a config file which specifies how the data should be exported into flat files out of the forms, then that same config can be used to parse a flat file and load it into the forms (user upload). JS on the page can use the same exporter/importer logic to periodically back up all the data to a flat file using ajax post. The data doesn't have to live anywhere except in a flat file (in the user's possession, or temporarily stored on the server) and in the UI where it gets modified.

With this approach, you don't have to worry about how to load various and variously related objects into a database, which is bound to get messy (Are you going to be building a schema for every MUD supported by the UI? Are you going to be building some kind of universal schema that you think any MUD will fit into?). Plus, you get user file import functionality 'for free', whereas if a database is your primary storage, you would need separate logics to import a user file into the UI (or the db) and from the db into the UI.

For the above solution, the only thing that's needed on the server are several basic php files that generate files from post requests and serve them back.

Databases and server-side frameworks are great. But you don't need a bazooka to hunt field mice.
0.0/21