There are several things that can be seen in the images here. The first and most obvious is the general format of the custom client presentation. Others include examples of the mouse-buttons available in the standard scenario, examples of icons, generated versus custom graphics for regions, etc. Another example from the standard scenario would be a shot of the icon/cursor editor, which uses the left-half of the screen as a very simple paint program to let you modify your own icon and cursor.
|This overall image is a photograph of an old Commodore 1080 monitor displaying the client. The graphics portion (the top half) is explained more below. The text window has a scrollbar on the right, various menus controlling the client, and simple text everywhere else. The bottom line (the hard-to-read prompt is "input> ") is where input commands are typed. Output from the MUD does not interfere with that line - it appears on the second-from-bottom line, and the text scrolls up from there. When the user hits enter, the current input line is scrolled up and cleared. Prompt-change commands from the server directly affect the prompt in the input line.|
Those not interested in some Amiga technical details can ignore this paragraph. The Amiga GUI system allows for multiple "Views", which represent entire GUI setups. This is somewhat like Linux allowing multiple consoles, except that each one can be running the GUI. Each View can be composed of multiple "Screens", each with its own bit depth, resolution, colour palette, cursors, etc. Normal windows are created within screens. The AmigaMUD client can use a View with two screens. The top screen, for graphics, is 320x100x32 colour. It contains only a "borderless, backdrop" window. The bottom screen is 640x480x4 colour, and contains one regular window. This multi-depth, multi-resolution trick is made possible by the Amiga's "Copper", a simple custom co-processor which is synchronized to the video beam scanning, and can load hardware control registers from memory. Between the screens on the view, it blanks the display for two scan lines (visible in the photo), reloads the registers, and re-enables the display. If I were to drag my SVGA monitor over to my Amiga A4000T, the client could double its sizes, and can also run both of its areas within normal windows on the user's desktop. This latter mode is what I would use for a JAVA version. Of course, all the Amiga stuff has been completely obsoleted by today's 1600x1280 true-colour real-time 3D displays. :-(
|The first graphics snapshot is one of the second area a player will encounter, after leaving the mini-mall area. This is the central town area. The first image shows custom graphics done by a player.|
|The second version shows the generated graphics that are displayed if the image cannot be found on the client machine. Note that this is custom generated graphics, in that I spent quite a while positioning the rectangles, lines, circles, etc. to get the desired effect. Examples of simpler "auto-graphics" will be shown later. I've doubled the size of both of these images so that they look reasonable on today's higher resolution displays.|
The general structure of these displays is that the graphics area is divided horizontally in two. The left half is used for an overhead view of the current region (set of rooms, defined only by being the set that is displayed in the image). This can be a custom image created by an artist, custom generated graphics created by a scenario programmer, or automatically generated graphics selected by the room creator from a set provided in the scenario. The character is represented by a small cursor, which is the blue smiley face north of the fountain in the park. At the same location was the NPC "Packrat", who is represented by the white flower icon in the upper-left corner. I chose to automatically place the icons for other characters so that a reasonable display is possible even when many are present. Each character has their own icon, which defaults to a smiley face, but can be edited within the scenario.
The right half of the display is used for the display of the short name of the current location, and for various sets of "mouse buttons", which are simple rectangles containing descriptive text, which can be clicked on by the user. Code in the scenario decides what graphics is displayed, what buttons are displayed, and what to do with button clicks. The first two images show the standard set of buttons, which are just movement buttons, plus the builder '@' button. More on that later. The 'L' button simply does a 'look around', and the other buttons attempt to move the character in the chosen direction. In the standard scenario it is also possible to move by clicking the mouse in the left half of the display, selecting a direction based on the position of the click relative to the position of the character cursor. Some players found this a bit confusing, in that the system doesn't try to move the character to where the click was made, it just tries to move once in the chosen direction. The presence of doors, the possibility of traps, etc. all combine to make the latter a harder thing to do nicely.
|One of the doors in the town leads into the Builder's Guild, which also has custom graphics provided by a player.|
|It's generated graphics variant is shown here. In both of these images, the player has clicked on the '@' build button, bringing up the top-level set of buttons for building. "EXIT" returns to the standard button set, "Room" brings up the top level of room-building buttons, "Object" brings up the top level of object-building buttons, "Poof" allows builders to teleport around their own rooms, "Symbol Here" allows builders to assign a symbol to the current room, and "Tables" goes to some symbol-table manipulation buttons.|
|Next, I went into the Proving Grounds, which is the combat area of the scenario. Here we see a much simpler form of generated graphics. The white icon is that of a "wild dog", one of the generic "monsters" in the Proving Grounds. The button set is the first set of buttons in the room-building set. They allow the creation of new rooms, manipulation of links between rooms, changes to the room's name, description and nature, etc. The "Auto" button leads to another set of buttons which allow the setting of "autographics" for the current room.|
|"MORE" leads to another set of room buttons, which is shown on the next image. Here, the graphics are simple autographics of roadways, with a virtually invisible circle under the player representing a manhole cover (very anachronous!). The white 'G' is the icon for a gremlin - it is in the second icon position because a snake moved out just before I was able to take this snapshot. The button set is the second room building set, and allows the setting of some basic room properties, and special entry/exit messages.|
|I then entered the sewers and caverns beneath the small village. The first image there shows a cavern, which is done by autographics. After chasing some snakes and rats, I managed to get a rat in the image with me. The button set is the set for controlling autographics, which are the generated graphics like this image. You can override the default colours for the elements of autographics, and can choose which type you want.|
|The next image shows a larger cavern, this one with custom graphics by a player. A goblin (larger 'G' than the gremlins) was with me here. The button set shows the choices for autographics types. The goblin icon is in red since I told the scenario to display icons in red via "icons red". White got lost in this image.|
|The spider den also uses some custom graphics by a player. Here you find a few special spiders, which can give you a nasty surprise. The button set is the top level object building set, which allows the creation, selection and modification of objects.|
|The second spider den image shows the same room, after all the spiders have been vanquished.|
|Deep in the caverns, one encounters the troll area, which is centered around an underground chasm. I have custom graphics for one end of it, but not for the other end. The button set on the first image shows some of the actions that can be setup for objects.|
|The second image shows me confronting the bridge troll (of course!), and the rest of the object actions.|
|One of the trickier quests involves getting through the doors room. This can be easier with two players, but is do-able by a single player. The button set shown is that for manipulating symbol tables. "Symbols" shows the symbols in the table, and "Describe" describes a chosen symbol. The description can take various forms, all dumped out to the text window. The most common forms are dumps of the visible properties and their values on an object, and the pretty-printed dump of some routine in the scenario.|
|Beyond the doors room is an area I call the troll maze. It uses custom generated graphics which change as the player moves around in the maze. The various colours indicate the nature of the rock around the player. This is a 3D maze which can be quite difficult to solve.|
|To show what a lot of NPC's look like all together, I went to the snake pit and stirred them up. Some had left by the time I took the snapshot. This room is autographics - note the yellow arrow indicating that you can go up.|
|There is a reasonably large area near the goblin city, so I was nice enough to provide some maps.|
|The map was bought in a friendly goblin-run store.|
|Much of the underground area uses the "tunnels" form of autographics.|
|Back on the surface, I came out near the stream and encountered a moose. This area uses standard autographics, with the colour set changed and some small additions (such as the stream itself).|
Another style of graphics that can be used for this kind of image is tiled graphics, where a set of small tiles are combined to produce larger images. I built that into AmigaMUD and my custom client as well. To go with it, I built a test scenario that consisted of my big Lego castle done with a tiled view. You can see some images from that scenario here.