The copyright situation for this article is unclear. It does not belong to the author of this site. Please see the copyright notice. If you have information about the copyright contact me!

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.

Wow! What a wild carrot!

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 no restrictions.

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 map.

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 rewrites anymore.

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 graphical client.

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 world.

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 perspective.