This topic is near and dear to my heart so let me share some thoughts:
I have spent significant time prototyping things with Ruby and while some things are slow (which will become less and less of a problem because of moore's law -- though with multicore stuff soon we'll have to really deal with proper threading), all in all, it is a FANTASTIC language. I just can't say enough good things about it. I've used it for all sorts of different things (including things like writing a cross-platform native feel gui-based batch telnet/ssh client, changing one color to another in 50 gif files in one shot, updating the MP3 tag information on my MP3 library, network monitor plugins, and scripting for network device provisioning). Ruby is one bad *** language as far as I'm concerned. At this point, I believe if I ever start writing a game from scratch, I'd use Ruby underneath. For more information:
Ruby's Home
http://www.ruby-lang.org/en/A Neat Little Interactive Ruby Web Tutorial
http://tryruby.hobix.com/Now that said, Ruby will (unfortunately, from my viewpoint) only be a part of this project. Traditionally, MUD clients are either a stand alone client or a java client. Previously, you haven't been able to make a web based client using anything but java applets and applications. Web 2.0 and AJAX turns this whole paradigm on its head. AJAX allows you to use javascript (very very different from java) to communicate back and forth between a web browser client (which interprets the javascript) and a web server (which tells the client what to render). This means you can make changes to portions of a web page, and that those changes can be essentially pushed by the server. This in turn means you could write a client for a MUD directly inside of a web browser -- the game becomes part of the web site. Now, to make all this magic happen is a lot of work! There is a lot to keep track of and manipulate... this is where Ruby on Rails (RoR) comes in. RoR is a web application framework -- it creates a lot of the javascript/AJAX stuff for you (allowing us to do statistic updates and things similar to the existing DirectX-based DL-Client which eliminates the need for prompts), and it allows you to easily add a database on the backend (in our case this would be useful to keep track of individual user client settings, for example). Here's where you can find out more about RoR:
http://www.rubyonrails.org/I'm highly interested in making this a simple easy to use interface. To this end, I really would like to keep to many of the concepts utilized by 37Signals:
http://www.37signals.com/Specifically, I really enjoyed some of theories in this book:
http://gettingreal.37signals.com/toc.phpIt is possible that we will charge for people to use this client and make some effort to pay the programmers who create it for their efforts, though this has not been ultimately decided.As far as I know, this is still in the conceptual phase I haven't written any actual code on this client. I have, however, done enough research to believe that it is, in fact, possible to make as described.
Keep the thoughts flowing.
Best regards to all,
--Nezmar