Why do a 3D mud?
by Tommi Leino
Majik is a project to create an online role-playing environment set in
a complete and ever-evolving medieval fantasy world with the help of
modern 3D-technology. This article tries to make clear why we are
doing our project, a former text-based mud, in a true 3D perspective
and what made us take such decisions.
A carrot, growing.
Majik has been through various incarnations, each experimenting in
different ways with the boundaries of computer multi-user role-playing.
As the developers came mostly from a mud background, it was an obvious
choice for us to begin with a room-based engine.
The two of the first incarnations were based on a Diku mud engine and
the latter one was even quite playable, but customizing the engine
grew to be a great pain. One had to reboot the server when adding a
new feature or just fixing a bug. It was very easy to set up the game
with Diku, but that was all. It is no wonder why all the muds based on
Diku look very similar. :)
We decided it was time to discard the Diku mud engine and switch to
LPMud instead, particularly MudOS because we saw it was well supported
and more advanced. We also looked at DGD, but it just didn't catch our
interest at the time. We also decided not to use any stock mud library
since we knew that these mud libraries were just conventional libraries
for creating an ordinary mud. Another reason for this was that we were
too tired of meddling with limitations and wanted an environment with
In fact, however, there were still some limitations. We had the third
incarnation almost ready, you could even grow carrots there, but as we
were recoding our battle system we saw that it was just too unrealistic
and limiting to do the battles in a single room with no possibility to
move around, making ranged combat very hard to simulate. We didn't
really want to cut in the realism and accept the limitations, so we
tried to come up with a few different approaches to the problem, but
none were adequate.
One of these approaches was to have a separate "battle mode". When a
battle had been initialized one would be sent to a grid mapped room
where one could move one grid each turn. However, this created many
difficulties and made it impossible for the others in the room to
watch the fight. This didn't solve the problem of ranged combat, as
the users couldn't set their initial positions in the grid map when
entering the battle mode. Also, one could always stand next to the border
ready to flee, so it would have been possible to run out of the combat
instantly, leaving the opponent standing at the center of the grid
We didn't like the idea of having a separate battle mode since it was so
artificial and felt kludgy. We began testing to see if we could integrate
the grid map to room descriptions so it could always be visible. It was a
good improvement. One could navigate better from room to room as they
could see the picture of the room and the exits from it instead of
looking at the description saying which directions one could go to.
It also enabled the possibility to implement a "map" command
where one could see the nearby rooms as a nice map. In addition, the map
displayed also other players and monsters in those rooms.
Moving around inside the rooms was painful and boring. All the rooms
were exactly the same size and it felt just pointless having to
type the direction command 10 times since you could previously do the same
with just one command. It would have had actual meaning only in the
battles. We wanted to remove the "all rooms are square" limitation.
We wanted real caverns, roads, woods and such. We got them, but again
there arose new problems. First, you would really need to look at the map
each time you moved, resulting in a flood of text (only few lines in
"brief mode", though) and secondly, this was a radical rewrite of the
previous concept, conflicting with our library's inner workings so much it
would be easier to code the library from scratch rather than trying to
patch it to support this new grid map system. These approaches were more or
less kludgy patches over the old implementation just testing the concept.
This led the to the development of Majik's fourth incarnation, surprisingly
called "Majik 4". We were sworn in blood to avoid moving away from
text-based games. We thought it would be impossible to get the same
feeling with graphics as with the textual descriptions and our own
imagination. We said strongly "No!" when someone even spoke of it. Thus, we
had no choice but to try to integrate the grid map to our mud without
needing the users to download a special client program in
order to play the game. We begun the development using a DGD driver,
as it felt much more elegant and more fitting for the fourth incarnation
than MudOS was. We tried, but the coders just didn't have enough
motivation to try to meddle with telnetable muds anymore as we already
knew that we could do it better if we just required the users to
download a special client program.
It could have been possible to do it without requiring the client
(well, barely), but then we would have required the users to have a
standard telnet program that could do a VT100 terminal emulation so we
could move the cursor around the screen freely, but most of our users
used a special mud client such as TinyFugue and zmud. It just would
have required much more to try to bang the fact to the users' heads
that they really couldn't use any of those.
The fourth incarnation finally solved the problem of ranged combat and
all other related problems along with it. We finally got a
chance to do realistic battles. It was great fun to form up a line
with fellow adventurers and shoot arrows to the heads of approaching
orcs. It was also fun to see surprises in our AI code, such as when
fleeing away from a monster and circling a building, the monster had
changed direction and came up from the other side. It was nice to see
all the lighting effects, a whole room was not lit if you brought only
one torch, it would just light up a certain radius and you couldn't see
through the walls. It was practically a rogue like game, the only
difference being that the mud-like room descriptions were still there.
It was multiplayer, and it was not randomly generated either.
We got the fourth incarnation to the point where the base code was
almost ready. You could go shopping, cut an orc's arm off and
eat it afterwards, improve in skills, cast spells, use different
combat maneuvers, solve puzzles, and generally do almost anything you
could imagine being in the initial base code. It just was lacking the
world. While waiting for it to build up, we had an extreme urge to
break the limitations found in our engine by one way or the other, still
using the same server as we really didn't want to do any total
The first and the most serious limitation found in the system was that we
had a limited amount of "tiles", the ASCII characters we used to describe
the ground where the user was standing on. We actually ran out of the ASCII
characters. We had to cut in the compatibility and add colors for the
tiles, but in the end, we came to the conclusion that the characters were
not an option. We needed another way to describe the environment accurately
enough and decided to break the limitation by coding a 2D tile-based
It worked fine but then we remembered the other limitation which we
wanted to break. A 2D engine allowed no chance for height differences
in the landscape. We couldn't have real mountains, we could only have
some boring "mountain terrain" which would only have mountain's
colors in a pattern and then trying to walk over it would result in
the server informing something like "You can't pass". That would have
worked just fine if we would have used a 1km x 1km scale, but in
the fourth incarnation we were using a unified 1m x 1m scale for both
"areas" and the wilderness. No mountain is so steep from every angle that
you couldn't pass anywhere.
Thus, we had to move on and code an isometric 3D client, practically a
2D one but it could display the height differences accurately, though
only from a fixed point of view. We made it in a Java to make it platform
independent. It would have worked just fine if we wouldn't have had grids
slanting more than 45 degrees and as we had to break the barrier we found
a new problem. Players could end up behind a mountain, not being able to
see their own characters.
There were two ways to solve the problem. A "mountain hiding" system which
would make the mountain transparent, or at least translucent if there were
something of importance to see behind the mountain, or make the client
truly 3D so that it could be rotated in any way.
The isometric view also had other problems, such as you couldn't see
the sky, which was something you could do even in the third incarnation.
As we pondered it for a "while" (half a year) we came up with the conclusion
that only true 3D didn't have any inadequateness in the way it
represented the graphics. We also realized that it would be in fact
easier to do a 3D client than a 2D one. In a 2D client, every tile,
character, etc. needs to be drawn by a graphic artist. For example,
look at the gigantic amount of graphics in games like Baldur's Gate.
Also, the code for calculating LOS (line of sight) could get rather
complicated while it is a matter of fact in the 3D perspective.
With our theory of almost everything being dynamically generated, it
could actually be possible to do the whole world without needing that
much graphic artists, one could survive long time without any.
So, what would you prefer: to climb up a mountain and turn to face
whatever direction and see for miles or see a message in a room saying
"Wow, you can see for miles" (not forgetting that miles can't be simulated
in a room-based mud), or in a 2D client, seeing a flat world from a
constant isometric angle without even being able to see more than few feet
forward, even if you were standing at the top of the highest mountain in
The server, in fact, is not that much more complicated than it was with
the fourth incarnation. The client just represents the grid map in a
more visual way. We could have used Majik 4's server for a base
for the fifth incarnation (Majik 3D), but we just saw it "more fun" to
write it from scratch once more, this time using C++ and Python,
forgetting about DGD and MudOS (even though we still love LPC). Just
wanting to say that it is really possible to code a 3D Massively
Multiplayer Online Role Playing Game (MMORPG) using an
LPMud driver as a server, and that it is not so hard after all, the
the main point being: It is not limiting, the straight opposite! I am
not saying that it is the graphics that matter, it is only the
January 2000 Imaginary Realities, the magazine of your mind.
© Copyright Information