09 Jun, 2011, JohnnyStarr wrote in the 1st comment:
Votes: 0
I've been learning Ruby on Rails for about 3 months, and it's really been fun.
I have created a few web apps, and I have decided to create a shared mud building environment that would allow collaboration across mud platforms.

The idea would be to generate shareable records of generalized data. Such as Rooms, Objs, Mobs, etc.
These could be created and committed to the universal library. A standard would have to be agreed upon for generic mud data. Now, the cool part is configuration. Meaning, once you have created YOUR area / zone you would decide on output. The site would allow you to designate generic values to static area file values.

An example might be:
room_description => ROM.room.short_description
room_description => SMAUG.room.short
room_description => CUSTOM_MUD.room.room_description

Obviously SMAUG doesn't have a room.short field, but it's an example of how you could designate the values based on standard OR custom output.

This is very useful for admins with little coding experience who haven't really customized their stock codebases.

Summary:
The site would be live, and available to all to maintain their mud's areas.
The project would of course be open source, so if you wanted to customize it to your liking, and run it on your server you could (which would allow the output of your files to be stored directly into your area folder if desired)
Those who wanted to share areas, and game objects could do so if they wanted to.
Those who wanted a private storehouse for OLC through a web browser would have 24/7 access.

Now, before I get this going, does this sound good to anyone else? Is anyone interested in getting involved with this project?

Discuss :)
09 Jun, 2011, Zeno wrote in the 2nd comment:
Votes: 0
http://www.mudconnect.com/discuss/discus...

I'm still learning Rails but I'm all for helping out. I'll try not to break things and contribute what I can while I learn? ;)
09 Jun, 2011, JohnnyStarr wrote in the 3rd comment:
Votes: 0
MudConnect said:
Create a Rails app that let's me edit Merc .are files from a web browser.

Bonus points if I can edit a running MUD and see my updates in game without a restart.

(Comment added by audiodude on Sun May 22 5:44:12 2011)


Sweet, that's exactly what I have in mind.

Rails 3 is fantastic. My favorite part of working with RoR is models. It's so nice to not have to write
direct SQL. My advice for learning Rails is to not use "scaffold". It sort of slowed down my learning experience.
Routes/Controllers should be hand written so that you can fully comprehend what you are doing as you go.
Views are a chore, but if you know CSS you are half way there.

Anyway, glad to get such a quick response. I will slowly get the project started and get it on github so we can both be working
on it. I have a feeling this could be pretty cool.
09 Jun, 2011, Zeno wrote in the 4th comment:
Votes: 0
Sounds good. I wouldn't use scaffolding for a real project, but I did use it while I was learning.

I don't have much thoughts on the details of how this would turn out, but we have the general concept and I think it'll unfold as we go.
09 Jun, 2011, Rarva.Riendf wrote in the 5th comment:
Votes: 0
Quote
An example might be:
room_description => ROM.room.short_description
room_description => SMAUG.room.short
room_description => CUSTOM_MUD.room.room_description

May I suggest to leave this to an external filter and do NOT store anything that is too engine dependant ? You can still start with doing this olc filter first but do not tie your building app to the final result.
It would also help a lot to not be tied by vnum as an example. Or to be able to easily change the range they use etc.
I still use them cause I am lazy and it is not a burden to me, but most people would want to get rid of them and use a real database instead.
For exits flag as an example, instead of deciding for people flag like lock unlock magical etc, only a list of string parameters you can fill yourself that will then automatically create checkboxes would b enice.
All these parameters would be decided before you launch the editor, but then the Editor UI would be created according to each mud owner wishes.
So an exit could have {open close locked unlocked } as parameter for a mud owner and {open close locked unlocked pickable unpickable } for another, and it would be up to the mud owner to then configure the output filter. Well, I would code that ;p
09 Jun, 2011, Runter wrote in the 6th comment:
Votes: 0
It's good to see people learning Rails. My advice would be to start small and break down large goals into small, learnable tasks. Learning how to do each independently will accelerate your understanding of Rails. And keep in mind that Rails isn't the only route to success. Rails is a large framework. It may make more sense to start with a minimal web framework for other projects. I, for example, find that I do not need Rails for small web applications. You could look at other frameworks like Sinatra. Sinatra does less, but it exposes more to the user and takes a small-ball approach.

Sintra
09 Jun, 2011, JohnnyStarr wrote in the 7th comment:
Votes: 0
Nice feedback guys.

Interesting info on Sinatra. I have often felt that for tiny apps rails is a bit too hefty. While i was learning PHP I was excited to see how fast and easy it was
to access a database and get a small site up and running. rails at first seems to be ideal for sites large and micro, however having to bend over backwards to appease rails conventions may hinder such a small app.
09 Jun, 2011, Runter wrote in the 8th comment:
Votes: 0
JohnnyStarr said:
Nice feedback guys.

Interesting info on Sinatra. I have often felt that for tiny apps rails is a bit too hefty. While i was learning PHP I was excited to see how fast and easy it was
to access a database and get a small site up and running. rails at first seems to be ideal for sites large and micro, however having to bend over backwards to appease rails conventions may hinder such a small app.


I think Rails was designed to fit the 99% use case for commercial software development. And more so than being artful it's interested in standardizing practices (which makes sense) so that as you go from project to project and understand the structure and the code without relearning conventions. Rails is, without a doubt, opinionated software, but it marries with technology that's not very opinionated to produce something powerful and flexible.
11 Jun, 2011, JohnnyStarr wrote in the 9th comment:
Votes: 0
Not sure if I agree that Rails is flexible.
I guess what matters is that the chosen opinions on using the framework are made by people a lot smarter
than most of us. And more experienced.

I enjoy using PHP despite it's bad reputation. I'm a little uncomfortable
with the $ sigil used for every variable. But it's pretty nice to fire up a page and connect to mySQL with 4 lines of code.
At the same time, this is controversial because directly accessing a database without a built in Model layer can be cumbersome
and in larger applications can be disastrous to maintain.

I'm kind of on the fence at this point. I guess as long as I keep learning core web design, the framework / language chosen isn't
as important.
11 Jun, 2011, Runter wrote in the 10th comment:
Votes: 0
The framework it self is "on rails" and is intended to take a stand, but the underlying technologies are flexible. Ruby and coffeescript are both pretty nice. Once you understand rails you'll find that just about anything has a configuration, a hook, or an initializer. Also, I don't use activerecord for my models. I use datamapper. Saves you some headaches on the migrations.
11 Jun, 2011, JohnnyStarr wrote in the 11th comment:
Votes: 0
BTW, Totally awesome Kijami thing Runter.

How exactly do you get involved?
Can you tell me more about it?

PS: I promise I'm not trolling here :)
11 Jun, 2011, Runter wrote in the 12th comment:
Votes: 0
We focus on marketing social media software to NGOs and charitable organizations for interesting ways to fund raise and bring more attention to their causes.
11 Jun, 2011, Dean wrote in the 13th comment:
Votes: 0
+1 to the idea.
11 Jun, 2011, quixadhal wrote in the 14th comment:
Votes: 0
Actually, a nice way to store (or present) the data might be as JSON or XML. Just label your fields with the FUNCTION of the data, rather than whatever some specific codebase calls it. That way, even LpMUD people could make use of it. You could easily have filters to transform the data into a specific file format later.
13 Jun, 2011, JohnnyStarr wrote in the 15th comment:
Votes: 0
Great idea Quix. I prefer JSON for use with javascript.
The only downside to this sort of development, is that it will be fun, but probably not useful in any other application.
I guess that's the way most things go with MUD dev.
15 Jun, 2011, Raduryn wrote in the 16th comment:
Votes: 0
I want to throw a second (third?) to the idea needing to be available for LPMUD users as well… the LP community is huge (at least comparatively speaking, from my experience) and you wouldn't want to ignore them entirely.

It sounds like a neat idea… the only thing I'd have to say is that these days, one of the largest selling points of a MUD is that the world is unique, all areas custom or whatnot… if you're sharing areas between MUDs, you're losing that to some extent. But then again, maybe I just have misunderstood what it is that we're talking about here.
15 Jun, 2011, JohnnyStarr wrote in the 17th comment:
Votes: 0
The main idea is that game objects would be globally available using an abstract convention.
This means the site's community would have to agree on a generic structure that could be converted into
any desired format. Correct me if I'm wrong, but doesn't LPC use a binary storage format? Obviously this
may not be a one-size-fits-all solution. With enough time and configuration, I'm sure a happy balance could be
reached for just about any customization.

I would like to start off small and work my way up depending on demand.
16 Jun, 2011, plamzi wrote in the 18th comment:
Votes: 0
JohnnyStarr said:
The main idea is that game objects would be globally available using an abstract convention.
This means the site's community would have to agree on a generic structure that could be converted into
any desired format.


What about customizations that extend typical structures? Are you going to be creating generically labeled table columns like "int1" - "int10" and "string1" - "string10", or will you be adding these upon request?

What about customizations which are in essence additional structures/objects requiring a unique table? For instance, my game has an extended mobile format in which you can associate an array of equipment separate from any equipment loaded in the zone reset command list – this array would need its own table. I imagine more customized games have more extensions than that… An even bigger source of headache would be mob / obj / room scripts, which can take on many forms and formats. Are you going to be open to creating custom tables and the corresponding UI elements to support such scenarios?

I have a hard time imagining an abstract database schema that would cover most bases. At the bare minimum, you would need some very very wide tables stuffed with all kinds of data types, where each user can choose a subset they need to utilize (e. g. some people will need 20 int slots for special item properties, some will need 4, so you have to add 20 columns). I can't even think of a way to address custom structures in a generic way. Can you?
16 Jun, 2011, David Haley wrote in the 19th comment:
Votes: 0
Quote
I can't even think of a way to address custom structures in a generic way. Can you?

This is basically what relational databases were invented for. Have a table with three columns: entity id, key name, value. (You might need a table per value type.) Then you can have whatever fields your heart desires…

If you really need structures with nesting, you could arrange that with formatting rules on the key name (bla.foo), or extent the relational table to include a field id, and then a parent id, and allow you to specify the parent field id for a given field entry.
16 Jun, 2011, plamzi wrote in the 20th comment:
Votes: 0
David Haley said:
Quote
I can't even think of a way to address custom structures in a generic way. Can you?

This is basically what relational databases were invented for. Have a table with three columns: entity id, key name, value. (You might need a table per value type.) Then you can have whatever fields your heart desires…

If you really need structures with nesting, you could arrange that with formatting rules on the key name (bla.foo), or extent the relational table to include a field id, and then a parent id, and allow you to specify the parent field id for a given field entry.


The question is not whether it's possible to define relationships in a relational database. The question is how do you design a schema (and a builder UI to go with it) where some of the elements and relationships are not known ahead of time? And the next question is who will be designing / extending the schema for the site to handle custom properties and objects? Will the main developer attempt to anticipate every possible demand, or add tables upon request, or will he offer some kind of advanced configuration wizard?
0.0/85