10 Feb, 2009, Tyche wrote in the 1st comment:
Votes: 0
RocketMud version 0.3

This is a ruby version of Brian Graversen's SocketMUD™. It should run
on any platform that Ruby runs on. It's been minimally re-architected to
be more object-oriented.

RocketMUD has pretty much the same feature set of SocketMUD with the
exception of MCCP support. I didn't see any point in bothering with it.

* Supports 'say', 'quit', 'help', 'who', 'linkdead', 'shutdown', 'commands'
and 'save' commands.
* Supports ansi - see help ansi for details
* Event scheduling system
* Any help file changes are automatically detected and loaded.
* Code is reloaded by the tick event so there is no need for a copyover
command. This is rather simple and crude and if you mess up the code and
it can't be loaded you just might have to kill and restart the server.
* Player files are stored in YAML format instead of the Dikulike format.
There is just a single player file, .yml, not a .pfile and .profile.

Release 0.3 fixes some bugs and makes it work with Ruby 1.9
- Changed load_control to check file modified time against the last time files were loaded.
- Removed isalpha and isprintascii and implemented regex where needed.
- Made last_modified a generic function, so code loading can use it.
- Ruby 1.9.1 compatibility fixes
- converted event constants to symbols
- convert class variables @@do_echo, @@dont_echo to constants
- make sure constants.rb only required once
- termguard code conatined misleading messages and undefined constant
- load_helps would attempt to load directories
- removed unused constants and moved to their own file.
- Fixed SOL_SOCKET bad parameter - Chris Bailey
- Changed color code to do integer rather than string compares. - Chris Bailey


The latest release can be found at:
ftp://sourcery.dyndns.org/pub/mud/rocketmud
The discussion forum can be found at:
http://teensymud.kicks-ass.org/forum/lis...
10 Feb, 2009, tphegley wrote in the 2nd comment:
Votes: 0
What are the advantages of using Ruby over C or C++? I have never looked at ruby or python or pearl. I have barely looked at some Lua. I'm just curious as I really only know C and some C++.
10 Feb, 2009, Stormy wrote in the 3rd comment:
Votes: 0
Ruby's primary advantage over C and C++ is development time. Its primary disadvantage is performance, though the new interpreter brings a speed boost and you can use C-extensions for speed-critical portions of your program (however, neither of these will match the speed of C or C++).

Subjectively, you may find other advantages: it's an interpreted language, has a strong, growing community, and, among a lot of other things, it's the language Ruby on Rails is built on. One of the biggest advantages, in my opinion, is that it's very enjoyable to use.
11 Feb, 2009, Tyche wrote in the 4th comment:
Votes: 0
tphegley said:
What are the advantages of using Ruby over C or C++?


Brevity
11 Feb, 2009, Lobotomy wrote in the 5th comment:
Votes: 0
Tyche said:
…with the exception of MCCP support. I didn't see any point in bothering with it.

Why?
11 Feb, 2009, Sandi wrote in the 6th comment:
Votes: 0
How would you compare Rocket to Socket? (guess I'm asking you to compare Ruby to Python, aren't I?)
11 Feb, 2009, David Haley wrote in the 7th comment:
Votes: 0
I thought that SocketMUD was in C…
11 Feb, 2009, Caius wrote in the 8th comment:
Votes: 0
DavidHaley said:
I thought that SocketMUD was in C…

It is. However this thread is about RocketMUD.
11 Feb, 2009, David Haley wrote in the 9th comment:
Votes: 0
Err, umm, not to point out the obvious, but please go read post #6.
11 Feb, 2009, Stormy wrote in the 10th comment:
Votes: 0
Sandi said:
How would you compare Rocket to Socket? (guess I'm asking you to compare Ruby to Python, aren't I?)


RocketMUD is essentially a straight Ruby translation of SocketMUD, which is written in C. There's another codebase, NakedMUD, that is built on top of SocketMUD and also uses Python scripts.
11 Feb, 2009, elanthis wrote in the 11th comment:
Votes: 0
To those asking about Ruby vs C, let me give you a very brief rundown:

+ Ruby requires less typing to get more done, so it's easier to whip up new functionality in less time than with C.
+ Ruby does not require the programmer to constantly track pointers and memory bounds, so an entire class of errors disappears with Ruby.
+ Ruby comes with a very complete standard library, reducing the need to write code for common tasks.
+ Ruby is a true OOP language which makes implementing the natively OO-style concepts of a MUD/game engine much more logical than a procedural language like C.
+ Ruby is very applicable to a number of programming contexts, so Ruby experience will also help you build the support code for your MUD (e.g., an integrated website) without needing to learn multiple languages.
* Ruby has a large set of add-on libraries, just like C, including bindings to almost every popular C library.
* Ruby is slower than C, but not to any measurable degree for the kinds of workloads that even a very huge MUD would incur.
- Ruby is dynamically-typed, which – while great for small self-contained scripts or highly reusable components, like in AI modules or CGI processors – can often be a real pain in complex applications making heavy use of intertwined classes/types with very specialized behaviors (like almost every MUD/game server design is going to have), and usually requires the programmer to write _more_ code for protecting against those kinds of errors than language-supported type annotations would require.
- Ruby is not available on all MUD hosts, and many that do offer Ruby will offer older versions that are significantly worse than the latest releases in terms of library coverage, performance, debugging features, and so on.

All in all, I would say that usinig Ruby for a MUD server is highly preferable to writing it in C; I only recommend getting used to commenting your code very well and in writing unit tests. Granted, using just about _any_ language is preferable to C for almost every kind of project, and good comments and units tests are always a great idea, so maybe that isn't saying much. ;)
11 Feb, 2009, David Haley wrote in the 12th comment:
Votes: 0
elanthis said:
All in all, I would say that usinig Ruby for a MUD server is highly preferable to writing it in C; I only recommend getting used to commenting your code very well and in writing unit tests. Granted, using just about _any_ language is preferable to C for almost every kind of project, and good comments and units tests are always a great idea, so maybe that isn't saying much. ;)

Yeah dude, thanks for nothing and your non-statement :tongue:

More seriously now…

elanthis said:
* Ruby is slower than C, but not to any measurable degree for the kinds of workloads that even a very huge MUD would incur.

Do you have any empirical data for this? Has anybody successfully run a "very huge MUD" written completely in Ruby?
11 Feb, 2009, Tyche wrote in the 13th comment:
Votes: 0
DavidHaley said:
elanthis said:
* Ruby is slower than C, but not to any measurable degree for the kinds of workloads that even a very huge MUD would incur.

Do you have any empirical data for this? Has anybody successfully run a "very huge MUD" written completely in Ruby?


Ruby scales up to huge and very huge easily. It starts sucking wind at enormous, and goes into a state of shock at gigantic.
Empirically speaking, of course. ;-)
11 Feb, 2009, David Haley wrote in the 14th comment:
Votes: 0
Seriously though, if you have any more substantial data on this it'd be nice :wink: I'm just curious to hear what kind of worlds people are using on Ruby MUDs. Or, for that matter, any similar language like Python, Lua, whathaveyou.
11 Feb, 2009, Sandi wrote in the 15th comment:
Votes: 0
Stormy said:
Sandi said:
How would you compare Rocket to Socket? (guess I'm asking you to compare Ruby to Python, aren't I?)


RocketMUD is essentially a straight Ruby translation of SocketMUD, which is written in C. There's another codebase, NakedMUD, that is built on top of SocketMUD and also uses Python scripts.

Thank you for realising my error. I'll try this again. :redface:

Two people I know are looking at NakedMUD. We'd all need to learn Python, however. I'd rather teach them mushcode. One hacker and two newbs makes more sense to me than three newbs. On the other hand, mushcode isn't good for anything but MUSHes, and one of guys is a real programmer, and we all know how they react to mushcode. :)

So, I guess what I'm really asking is, which of the three would you choose if your intention was to create a MUD that incorporated scripting as an in-game building tool?
11 Feb, 2009, David Haley wrote in the 16th comment:
Votes: 0
Very frankly, I'd never choose MUSHcode over a language like Python. I imagine that you knew that already given your comment about how "real programmers" react to MUSHcode. :wink:

Personally I'd probably not pick SocketMUD because it is closer to the bare bones, as I understand it, than e.g. NakedMUD. You'd also have to stick in all the scripting interface yourself, which you wouldn't have to do with the other two. As for Ruby vs. Python, well, I prefer Python, so I'd pick based on that.
11 Feb, 2009, Davion wrote in the 17th comment:
Votes: 0
Sandi said:
So, I guess what I'm really asking is, which of the three would you choose if your intention was to create a MUD that incorporated scripting as an in-game building tool?


I would personally go with Python. I picked python up because I really like the syntax, the style of scoping and the fact that all code looks like psuedo code. It kinda pulls away from C's use of all those crazy symbols. I'd suggest something else other than NakedMUD though. I haven't looked through it thoroughly, but you might end up having to buckle down and modify the core code which uses the Python C API (which is anything but pretty) to get a major change done. IMO it might be simpler just to stick with a single language. Go with something like SourceMUD or Evennia which are purely written in python. Evennia is a pretty wild project; django is quite the framework!
11 Feb, 2009, Cratylus wrote in the 18th comment:
Votes: 0
Quote
which of the three would you choose if your intention was to create a MUD that incorporated scripting as an in-game building tool?


:(

-Crat
http://lpmuds.net
12 Feb, 2009, quixadhal wrote in the 19th comment:
Votes: 0
Cratylus said:
Quote
which of the three would you choose if your intention was to create a MUD that incorporated scripting as an in-game building tool?


:(

-Crat
http://lpmuds.net


To expand on Crat's comment, if you want in-game scripting as a building tool, you might want to take a good long look at the flavours of LPMud that are out there. There is a bit of a learning curve, as you aren't directly hacking the driver (or you shouldn't!), but are instead interfacing with it and possibly with a mudlib layer atop it as well.

However, they've been doing that since 1991, and are pretty good at it.
12 Feb, 2009, hollis wrote in the 20th comment:
Votes: 0
DavidHaley said:
Seriously though, if you have any more substantial data on this it'd be nice :wink: I'm just curious to hear what kind of worlds people are using on Ruby MUDs. Or, for that matter, any similar language like Python, Lua, whathaveyou.


I just tested my combat system, which is written in Python. NPCs are fairly heavily scripted (read: each has about 20-30 lines of code as AI, most of which are blocks of if/else statements. Each script is run every second to choose a combat action). I've stress-tested with up to 300 simultaneous combatants. The game runs fine up to about 200 combatants. Past that it begins sucking wind (ticks begin losing time), and 300 is the point where I'd say gigantic shock sets in (lag is noticeable). Keep in mind none of the code has been optimized, and there is a heavily used O(n) operation that could easily be turned into an O(1) operation (checking if characters have an affect). I'm fairly confident with a day or two of optimization, I could get to 500 combatants with no noticeable issues.

The codebase is NakedMud, and I tested on a Macbook Pro with a 2.16GHz core duo processor.
0.0/50