Question: why am I telling you about something written for the obsolete Amiga?
Answer #1: because its being ported elsewhere. The server already runs on Linux. Answer #2: you can run the latest Amiga version of the system, along with the scenario (world) for it, on Linux or Windows using the Univeral Amiga Emulator.
In technospeak, AmigaMUD is a free, softcoded system with a cached on-disk database and dynamic single inheritance, supporting multimedia I/O via a custom client.
In simpler terms, the AmigaMUD system normally consists of at least two pieces. One piece is the traditional MUD server program, which runs on a server machine on the internet somewhere. The other piece is a special client program that users have to run on their own machines to get the full multimedia features of the system. The server also accepts regular telnet connections, but since telnet doesn't support all that fancy stuff, users won't get it with that kind of connection. Unfortunately, the only custom client is for the old Commodore Amiga computers (68K variety). I plan to create a client in Java, but have not yet done so.
*Update* My friend Don wrote a Java client for me. It doesn't have the full functionality of the old Amiga one, and is a bit of a system hog, but it does work. No sound, however - that's hard to do properly in Java.
The AmigaMUD server does not require that the entire database be in RAM while the server is running. It can read and write the database from its own on-disk files as needed. This allows a large world to be run on a machine with not a large amount of available RAM. However with home computers typically having at least 64 Meg of RAM, this capability is becoming less important. However, by having an on-disk database, which stores absolutely everything about the world, there are no artifacts with the persistency of the world - if you drop a rock on a hilltop when you leave the game, it will still be there when you re-enter the game, unless some other player or an in-game "robot" (or other activity) moves it. Similarly, an AmigaMUD programmer would have to go out of their way to make your character not be carrying the same stuff when you re-enter the game as it had when you left the game. There is no need for things like "rent" or "storage lockers".
The system supports the following features through its Amiga clients:
- sampled sound output
- music output
- synthesized speech output
- bitmap image manipulation
- tiled display, with tile caching
- multimedia "effects" routines cached locally
- character cursor definition and control
- character icon definition and control
- keypad input
- mouse "button" input
- mouse "region" input
- text window with input history, output history, input line editing,
scrolling, resizing, etc.
- ability to use internal or external editor for editing descriptions,
messages, MUD programs, etc.
Unfortuately, the music output was never finished in the Amiga client,
and its not clear how one would do synthesized speech in other
environments. Similarly, the Java client has no sound support, and does
not have any input history. Nor does it allow any use of an external
editor for text, nor does it have any support for editing MUD-code. It
does, however, support the on-the-fly addition and subtraction of new
GUI windows within the client context.
In addition to the features mentioned above, the server supports:
- full user programming while the system is running, including dynamic
updating of key world functionality
- an object inheritance model which inherits values, rather than
structures, thus leading to significant space savings
- hundreds of builtin functions for a wide variety of purposes
- full support to aid parsing of fairly complex user commands,
while still having no specific knowledge in the hardcoded server
- efficient MUD program execution
- a highly readable MUD programming language, not dependent on
external files
- several levels and kinds of caching, for improved performance
- full persistence in the programming language - the only kind of
variable, other than function-locals, are fully persistent - they
automatically retain their value across server reboots
The system includes a reasonably well developed sample scenario, which includes generated graphics and/or bitmap graphics for all locations, simplified online building (via mouse "buttons"), a quest system with 6 quests, simple combat, socials, a few hundred locations and a couple dozen machines (robots or mobiles). Also included with AmigaMUD is extensive documentation on all aspects of running and using the system, as well as documentation on playing and building within the supplied scenario.
If AmigaMUD (which needs a new name) is so good, why hasn't anyone heard of it? The simple answer is that it isn't really as good as I've made it sound here, and it has so far been only available for Amigas. A more honest answer might be that it is a system developed by a single person, who is a programming language geek, and who has done almost no playing of other MUD systems. Does that mean the system is worthless? I'd like to think it isn't, prefering to think that what it really needs is lots of input to the scenario from other people, who do have more experience with MUDs. The server framework is likely pretty good, and the client was quite pleasant to use - it was just that there was nothing really special about the world (other than being able to build new rooms and objects just by clicking mouse buttons). This is all solvable, however, with lots of help from other people. My priority has to be to get the non-Amiga versions available, and most importantly, to get a client written.
If you really want to learn more about AmigaMUD, to see if you think it might have promise, I've put some copies of the documentation here on my website:
- my introduction to MUDs and AmigaMUD:
Intro.txt (22K)
- documentation on the Amiga custom client:
MUD.txt (68K)
- documentation on running the server:
MUDServ.txt (33K)
- information on how to play in the sample world:
Playing.txt (36K)
- information on online building:
Building.txt (101K)
- basic information on AmigaMUD programming:
Programming.txt (75K)
- information/tutorials on several key programming concepts:
ProgConcepts.txt (120K)
- reference information on all builtin functions:
Builtins.txt (190K)
- information on the new bytecode facility:
ByteCode.txt (8K)
- full source to trivial scenario:
simple.m (9K)
- guide/tutorial on the sample scenario sources:
Scenario.txt (160K)
An early snapshot of the AmigaMUD system can be found on the Aminet archives. Search for "AMClnt-1.0", "AMDoc-1.0", "AMNet-1.0", "AMScen-1.0", "AMSrv-1.0", and "AMCastle-1.0". That snapshot runs fine under the Univeral Amiga Emulator (UAE) - the version I currently have is 0.8.29. Sound works best if you set it to Accurate. AmigaMUD runs fine on any CPU that you have ROM and Workbench for, and is happy with "fast RAM". Below are some snapshots of running the 1.0 scenario (or the "Castle" one) under UAE:
|
|
|
|
The Amiga system didn't stand still - newer versions of the hardware came out with better graphics, and a newer version of the operating system came out. The biggest software change was the switch to AmigaOS 2.0. Most of the work I did to track that was in the MUD client program. It became able to work in windows instead of its own screens, and was able to use higher resolution displays. That lead to problems with all of the graphics - I could scale the images that I had, but what should I do with the programmatically generated graphics?
My answer was to introduce a fixed-point type (I used 16 bits before the decimal point and 16 bits after it), and to use it for graphics calls, so that they would scale with changes in display size. Since that needed the period (".") for a decimal point, I had to change the end-of-input-line from "." to "$". I similarly had to change a lot of the graphics code. I did, however, keep "Pixel" versions of most graphics builtins. However, I changed the drawing system to use "start"/"length" instead of "start"/"end" for lines, rectangles, etc. That required changing all of the pixel positions that were kept.
That latest version of the AmigaMUD system and scenario is the one used in the "OnUAE" page. In this version, I added several more sounds, put in 3-character forms of all of the "monster" names, and added specific icons for most monsters. There were also some minor additions to the world.
For more recent work, see CGMud, for which the following is a image of the Java client running on Linux:
