Terrain Thoughts
Posted in MUD Development
Last dog watch, 8 bells (8:16 pm)

I've been thinking about terrain for a while now, and I think that there are some things that are immutable, and some that aren't. The fact that a point is designated as "hilly" or "mountainous" doesn't mean I can't also add an elevation data point. In fact, it makes more sense, because not all hills occur at the same elevation. So the trick is to determine what is immutable (the fact that there are mountains here won't change, but a forest is just ground with trees).

While reviewing Designing Virtual Worlds, by Dr. Richard Bartle, I ran across this sentence:

Thus you can have a hill, a forested hill, a snow-covered, forested hill, and so on.

/me thumps forehead with hand. Of course! Perhaps there are MUDs out there that do this, but I've never seen one. They always have some hard-coded description written for a room. If I define a basic terrain type, then add things like ground cover and vegetation, I can create a dynamic room description that could change with the weather. Snow could melt into water which could evaporate in higher temperatures automatically. It seems like with just a little work in the beginning, a large, complex terrain system could be created. CPU cycles are pretty cheap nowadays, so the overhead can't be that terrible. I think I found my direction!

One of my ideas, which is still hanging out in my backbrain, is to use multiple "overlay" maps, each one defining different parameters. A map engine would check each overlay at any specified x- or y-coordinate and return all the information stored for that point. One overlay could be weather, another might be mineral deposits. A third could be a daylight map (imagine a sine wave defining sunrise/sunset, being shifted every n minutes. You could have time zones! Always daylight or nighttime arctic and antarctic areas! A fourth may be weather, cloud cover, rain, hail, tornado, etc. Devoting more overlay maps to geology, ground cover, and vegetation could yield a very sophisticated "world terrain model" that wouldn't be very computationally intensive.

Leave a Comment »
Terrain Dilemma
Posted in MUD Development
Last dog watch, 3 bells (7:31 pm)

I'm having trouble deciding how I want to handle terrain in my MUD. Traditionally, you have "rooms" that are grassland, mountains, swamp, ocean, etc. My biggest dilemma is the mountain and hills part—do I declare spots as "mountain" or "hill," or do I set an elevation at every point and interpolate hilly areas. The latter is how I believe most MMOs do it, because they have a graphical client, so they use a height-map and let the user see the hills or mountains.

If I use the height-map, then it's difficult to tell you're "on" a hill unless you scan the areas around you and look for regular changing elevations. If you use a simple "hill" designation (such as 'H' on my ASCII map), then how big is the hill?

I really need to think some more about this before going forward…

Leave a Comment »
That MUD Thing
Posted in MUD Development
First watch, 3 bells (9:49 pm)

Well it's been an awful long time since I did any work on my MUD. Tonight I thought I'd write some test code to process a world map. I created a text file with two types of terrain, water and land. The base world size is 180x90, and for simplicity is an ASCII text file.

So I put together a class, read the file in, and then use a function to extract a localized map based on an x- and y-coordinate and a radius.

The first image here is the localized map, the second is a snapshot of the same area from the worldmap text file, with x=125 and y=25 and a radius of 5. I added a highlight to show the part of the map the client is localizing.

localized map

world map extract

The next couple of things to do are:

I haven't worked on this project for quite a while now, but I've had other things going on. Some day I'll actually have this thing up and running.

PS: The class that does all this work, both .h and .cpp, are a combined length of 100 lines including comments and whitespace.

Leave a Comment »
Posted in MUD Development
First watch, 2 bells (9:22 pm)

I just finished adding code to handle autosaving for the MUD engine. I'm afraid it takes a lot longer than I want. Due to disk I/O overhead, my loop processing time jumps from 4-6 microseconds on a normal loop to 750 microseconds or more with just two rooms being saved. I realize that I have 200,000 microseconds per loop right now, and I have 5 loops per second, but still...I want tight code! I wonder how the MySQL server handles this? I'll have to switch over and test the MySQL storage layer and see which one is quicker.

Leave a Comment »
Automatic Temperature Equalization
Posted in MUD Development
First dog watch, 2 bells (5:16 pm)

One thing I've really wanted to get in to my MUD design was a temperature model. Every separate room would have it's own ambient temperature. People could do things to affect this temperature such as light a fire, stoke a furnace, etc. Objects entering the room would slowly equalize to the room's temperature, plus any insulation factor they may have. This requires some more code on the living-object side, since I have temperatures I should have a comfort zone and a "damage" zone. Anyway, to make a long story short, here's what I've got so far:

MUD Terminal with Temperature Equalization

You can see that I've taken some damage (my state went from feeble to faint), and my comfort level went from freezing (I started at 0 degrees) and went all the way through Cold, Comfortable, Hot, and Blazing. Things are really working well. This all happens automatically, I just set the temperature of the room and forget about temperatures after that.

Login Attempts and Some Loading
Posted in MUD Development
First watch, 5 bells (10:45 pm)

I just called it a night on the coding, I didn't write much today, I had a bunch of other things to do, but I did want to spend an hour or so writing some more code for the MUD. I added a maximum limit to the number of attempted logins, with a forced disconnect if you hit the limit. Log entries are made on every missed password, as well as at the max-attempts threshold.

After finishing that, I tackled some basic loading issues I've needed to work on for quite a while. I got most of the basic data loaded back in to the system. Specifically, the location the player last saved at is now restored at login. Some other data is also restored, such as height, length, width, weight, temperature, etc. I have to fix the brief and verbose description loading next. It's turning out to be a bit more complicated than I thought it would be, but I guess I should expect that by now.

Leave a Comment »
Fixed Messaging, Added State on Prompt
Posted in MUD Development
Middle watch, 1 bell (12:54 am)

I cleaned up a bunch of small issues with messaging, things are running pretty good. What I really did was change all instances of class Message to be a boost::shared_ptr instead of passing pointers or references to Message. It was a good idea, and fixed a few small issues I was running in to.

The problem is every time I start my run through the command objects, I end up adding features to them instead of cleaning them up. I need to concentrate on a cleaning run, perhaps I'll have time to work on that tomorrow or Sunday.

Anyway, here's a fresh screenshot:
telnet window of MUD output

You can clearly see my state is feeble (I have 14/90 life points currently). States are changed for every 10% of life you are missing, going down: perfect, excellent, tough, strong, healthy, good, okay, poor, weak, feeble, faint. If ANSI color is enabled, the state fades from bold green to normal green to bright yellow to normal yellow to bold red to bold red on white background (my current state).

Leave a Comment »
More Development, Lots of Cleanup
Posted in MUD Development
First watch, 5 bells (10:59 pm)

This has been the best kick I've ever been on for my MUD project. I have developed more features, cleaned up and documented more code, optimized more functions than I ever have before. I've even been thinking about writing a separate blog for MUD development, but I'm afraid when I run out of steam it won't get updated for months.

Anyway, these last two days I've been working on a few features. One of the main ones is text formatting. Originally, I wrote commands and help output with static line ends, so no matter how wide your client could display text, you still get newlines where I say you do. I did already write configuration code for a client's X and Y "resolution", or the width and height of the client terminal window in characters, so I could format lists into columns and write them out. I finally realized I could use the terminal X size and dynamically format all output to each client. Most of the work involved has been rewriting help() functions in the commands, that's where most of the text comes from right now.

The original write() function to each client socket takes a std::string, parses it for color tokens, and outputs an ANSI color coded (or no color if the client is colorblind) string. I added an overloaded write() that takes a std::vector<std::string>, which gets formatted into columns and written directly to the client. I had several functions that all did the same thing, so I moved it to the client socket to make everything easier.

I also fixed problems with my Utility class's stringToVector() function (it would push_back blank strings sometimes) as well as some column formatting errors I never saw coming. All in all, it's really coming together now.

Once I finish this round of function clean-ups, I'm off to the land of loading and saving. That's the biggest feature I just haven't written yet.

Leave a Comment »
Posted in MUD Development
First watch, 4 bells (10:14 pm)

As I mentioned earlier, I added the special Items of Interest question-mark command as well as a brand new shiny aliasing system. It took me about two hours to do both.

Example of MUD aliasing system and question-mark command

Leave a Comment »
New Ideas
Posted in MUD Development
First dog watch, 2 bells (5:09 pm)

One day as I was passing through Richard Bartle's website, I ran across his idea of a Virtual Venice MUD. As I've continued to work on my server, I realize I'm more interested in the idea of a virtual world than any kind of super-spiffy new game, but I digress…

What I found interesting is how he accesses what I call Items of Interest—something in a room that is mentioned in the description but may not be a virtual object, take this excerpt for example:

Fondamenta di S. Lucia.
You find yourself on a wide, paved area running from the Fond dei Scalzi in the northeast to the frontage of the Stazione Merci in the southwest. The path runs alongside the Canal Grande, with the Stazione Ferroviaria S. Lucia to the northwest; there is a tourist information centre attached to the station to the west. North is the Chiesa degli Scalzi, and east, jutting out into the canal, is the "Ferrovia" vaporetto stop.
A vaporetto is a waterbus; it is larger than, but not as fast as, a motoscafo. Both types of waterbus use the same stops: they ply the Canal Grande, and shuttle passengers to and from the out-lying islands. They are operated by the ACTV (Azienda del Corsorzio Transporti Veneziani), and are quite a bargain considering the scenery their passengers get to see.

You can see that the user just typed vaporetto? and the server responded with a more detailed description. All of the servers I've been on would require you to type look vaporetto or look at vaporetto, and not just the item name itself. What a simple, but neat idea, and it saves typing, too!

This can't be very difficult to implement in my codebase, so I'm going to give it a shot tonight and see how it goes.

PS I ended up implementing this as well as my aliasing system last night (the same night I posted this entry).

Configurable Prompt
Posted in MUD Development
First dog watch, 3 bells (5:56 pm)

While waiting after hours for some things to finish up, I wrote a new feature into my MUD3 codebase: configurable prompts. The original version was non-changeable. The late version had only static content. The new, shiny version is dynamic and parsed each time it is written out. But don't take my word for it—have a look yourself:

MUD3 Configurable prompt, small version

1 Comment »
Object Nicknames
Posted in MUD Development
First watch, 1 bell (8:42 pm)

I added nicknames to objects last night, and it only took about 5 minutes to do. I know I'm on the right track, programming-wise, when it's easy to add new features. I think things are organized pretty well, and so far it all runs real good. I think my next objective is deciding how to deal with multiple objects with the same name and how to address them. Perhaps something like look at second stone. I've seen other instances where they use 2.stone or stone 2, which I suppose are shorter and quicker to type. I'm still thinking about it though. Perhaps tomorrow I'll have a new idea…

Leave a Comment »
Posted in MUD Development
First watch, 2 bells (9:00 pm)

I just got rooms working! It's only taken five years to get rooms! Okay, I only have one room, but it's a start!

Here's what it looks like (sans color):

jacob@mobilechicken:~> telnet localhost 2600
Connected to localhost.
Escape character is '^]'.
Hi this is the greeting
What is your name?jacob
Welcome to the machine
Starting Room
  This room is rectangular, with a low ceiling. There are no exits, because
the exit code hasn't been written yet. There is a small statue on an old
table in the middle of the room.
Occupants: Jacob is here
Contents: There are items here, but I can't tell you what they are.
Starting Room
SILd:>look statue
The statue is of Grock the Troll, and is most shiny.
Starting Room
SILd:>look table
It has four legs and a top. Some people eat on them.
Starting Room

As you can probably tell, the Contents aren't working right, but I'll figure it out. I've got a problem with dynamic_casting boost::shared_ptrs.

Leave a Comment »
MUD Items and a Short Roadmap
Posted in MUD Development
First dog watch, 2 bells (5:01 pm)

I'm currently working on a central Item system that knows about everything, but it's in pieces right now. If you could see the code you'd know it's in no state to distribute, but I'll work it out soon. So don't worry MP, I haven't forgotten about you. Just give me some time to work this problem out.

Some of the cool features I have implemented in the class are: solid/liquid/gas state changes based on ambient temperature (or burning up on state change if it won't liquify), notification on state change (or not!), temperature of item, ownership and location of an item, disassembling items into their component parts, magnetism, item quality, collections/stacks of items (flowers, papers) etc. I'm getting excited about the code, but it's too early to say for sure what features are here to stay.

The socket driver is rock solid, and sleeps most of the time. My typical loop processing times are under 10 microseconds. ANSI color looks sharp and is easy to output, but for some reason my terminal doesn't show bold text. I guess I should use a better client than my standard X terminal.

The entire design is very modular, with several top-level classes that all work together. I still don't have rooms or movement, though. Some of the highlights of the existing codebase are: completely C++, multithreaded driver, very spare use of pointers (except for boost::shared_ptrs), std::map lookup of commands, event processor to handle future timed events, flat file or MySQL database storage system, four logging levels (DEBUG, INFO, WARN, ERROR) that can go to separate files/tables, fully implemented chat system, central messaging system and a standardized message "packet", banning of IP addresses, reverse-DNS lookup of public IP addresses (shows up in who list). Socials and emotes are in, too. There are over 100 and they are extremely easy to add, with full support of reflexive, possessive, subjective, objective (did I miss any?) pronouns.

I'll have to write a complete set of features some day for this project. But heck, it's been around in one way or another for at least 5 years now, so I'm in no hurry…

Leave a Comment »
MUD Progress
Posted in MUD Development
Forenoon watch, 2 bells (9:26 am)

Believe it or not, I've had a bit of time to work on my old MUD codebase. Had a few problems with loading data, but I think I worked them out. Now it's time to get collections and assemblies working…