New Maps Available!

I finally got the server to generate what I consider an acceptable quality map from the live game data. These maps show a rough outline of where areas are, with lines for roads, trails, and rivers, and area fill for water. I'm actually really proud of these - a year ago I wouldn't have really thought this possible.

This would pretty much have been impossible without all the mapping work that has been going on, but that mapping work couldn't have been done without previous versions of the mapper. Either way, things are looking pretty good these days.

You can find the new maps listed as 'trade route' maps on the main maps page:

http://www.alteraeon.com/maps

Or, see these links for individual map pages of Sloe, Kordan, and Archais.

Various updates

It's been a while since I posted, so I thought I would just drop a general overview of what's been going on in the last couple of weeks.

The largest major change, at least in terms of useful functionality, has been updates to the grouping code. I've been playing a lot, and I've noticed that putting together groups is a lot harder than it really should be. This is a social game, after all. Getting people together into fun, functional groups is part of the process.

After that are changes to the who listings. I quickly prototyped a 'who idle' command on request, but within about five minutes of first using it I was in love. I ended up adding a bunch of who list configuration switches; see 'set who' for options and status. You can now change from the default who display to idle time based, list short or long form, and enable or disable microlevels and titles. I haven't even gotten any complaints about it.

One big yet unobvious change had to do with the PRNG (pseudo random number generator) upon which the game is based. For quite some time now, I've been using a pretty fast lagged fibbonacci generator instead of a linear congruential. On a whim, I downloaded the diehard PRNG tests and tried them out. As expected, the old random number generator failed a lot of them horribly.

So, I ripped the old one out and put in a new one that does actually pass the tests. Other than monster lore sends changing, noone will ever notice - and I can rest slightly more assured that there's not hidden correlations lurking in my generator that are causing weird behavior.

Last on the list of big ticket things is, of course, mapper updates. We've got global area maps that are almost ready for general public display. I'd really like to have oceanography working first, so maybe I'll work on that a bit tonight.

All in all, a lot more getting done than I expected. It's been a good week.

New Alter Aeon Article

People sometimes send me articles for the web site, and sometimes those articles get lost. I recently found one in my mailbox from somewhere around April. Without any further ado, I present:

Morpheus' Guide to Running and Finding Gold

This newbie-level article talks about the basic ways to get gold in the game, and gives things for new players to do that will help them acquire enough gold in game for the occasional purchase. It also touches on trading with other players, which is usually where the large transactions take place.

New DClient release

Version 0.983 is out. This is mostly a bugfix/maintenance release:

----------------

The center direction/scan button now does a customized scan/look.
Function key presses now release scroll lock.
The 'you are here' diamond in the automap is now thicker.
Add 'mini status bar' menu option to allow hpbar above input window.
Minor updates to group status bar look.
The vote menu can now be updated from the server.
Added 'check for updates' option under 'help' menu.
Minor improvements to url clicking in the main window.
Improve road and trail display in the automap.
More fixes to 'disappearing text' bug in input window.

----------------

As always, it can be downloaded from the Official Alter Aeon Website.

Weeds, heading off into them

I've been on a big DClient kick the last few days, with intent to get a new 0.983 release out probably by this weekend, and a 1.0 'official' release by January. I'd managed to pare down the feature list and clean up a number of niggling bugs.

This morning when I woke up, I knew I wanted to do DClient work. But I couldn't quite recall what I was supposed to work on, and before I could look it up my brain spotted a nice looking patch of weeds and headed into them, full steam ahead.

Instead of working on the newbie 'demo mode' of the client, I somehow ended up working on audio. I've been avoiding sound and audio for months now, yet for some reason I decided today was a good day to do it. It took me about four hours, but I've got audio working on my Linux dev machine, and I implemented a full mixing stack as well to allow an arbitrary number of sounds to play simultaneously.

The only problem is, now that I can play audio, what do I do with it? The initial implementation pretty much only does one thing: it plays a short algorithmically generated 'click' whenever a command is sent to the server. While great for testing, it doesn't really add to the gameplay experience.

Now I have to find both ambient background music as well as triggered audio samples for various events. I'll also have to get the audio layer working on Windows, which could take anywhere from a couple of hours to several days.

Global mapping - a story of invention

When I first started this mapping project, my goals were grandiose. I had a vision of the dclient showing a very high level map with the location of cities and perhaps roads between them, updating a small amount in real time as you walked from place to place.

This large vision seemed so close, and yet so far - while easy in principle, the biggest issue was in generating the maps. Mud areas in general do not have to respect linearity. You can arbitrarily connect any room to any other room; in short, generating a cartesian, mappable layout becomes a builder constraint, not a tool constraint.

When faced with 20k rooms of previously built nonlinear content, the task seemed ridiculous and daunting. Initially, I tried piecemeal mapping: each area would have an internal, generated layout, and we'd try to move them around like puzzle pieces to get everything to fit. This didn't really work that well, but some new mapping tools were built and I was able to collect a lot more data.

The next idea was to try a form of annealing, where rooms would update their x/y/z coordinates based on what rooms they were connected to. This worked slightly better, in that it tended to smooth out big gaps and it forced areas to fit in places they didn't before. But it had the drawback of taking a very long time to settle, and it still didn't deal with nonlinearities.

Around this time, the idea of the big/small room distinction came about. Cities on maps are generally very small compared to the surrounding landscape; in Alter Aeon, this was definitely not true. The main city of Ralnoth was easily half as long as the Great Southern Road. I decided to declare cities, towns, buildings and other terrain as 'much smaller' than outdoor/wilderness/linkage areas.

This big/small transition appeared to work very well on the few initial areas I tried it on. Older areas required the most rework, but a lot of 'small' areas had limited linkage to their surroundings anyway, and the transition was easy. The southeast portion of the continent was hit the hardest, as it was designed on a unified grid. It had to be extensively retconned, but even that work happened quickly thanks to the dedication of Draak and Shadowfax.

As part of the big/small experiments, I extended the previously failed area map code to cross all zones, and used that to generate some cheesy room maps showing absolute and relative positions of everything. After a bit more work, I was able to show nonlinear linkages on the maps as well - and this is when things really started to get done. Seeing the problem spots, it was surprising how few of them there really were. We began to aggressively target those.

Meanwhile, the annealing/smoothing code was running in the background, continuously updating the 'real' positions of rooms, as opposed to where we thought they should be. The most recent advance was the realization that the 'perfect' and 'real' maps should be as close to each other as possible, and in fact the 'real' map should try to match the 'perfect' map. I made a few very minor changes to the algorithm, and the global map consistency (not to mention convergence speed) has increased greatly.

After all of this, I'm almost to the point where I can generate the high-level maps I originally wanted in the first place.

The lesson to take away is that invention happens in bursts and is often triggered by random things. Ideas are easy, but implementing them is hard; further, you never know which experiments are going to fail or succeed until you spend time on them. There were several dead ends along the way in this project, but each provided tooling or insight into new things to try.

Overall, if I had known the final form of things at the beginning, all of the code work could probably have been done in a couple of weeks, and all of the area work to follow in another month (with builder help of course). As it stands now, the mapping saga has been going on since the beginning of the year, with breakthroughs and advances from time to time.

An Example of Mob IACT Programming

[Reposted from the Alter Aeon Forums.]

An 'iact' is a type of interactive procedure that is used to make mobs perform actions. You can do some pretty complicated stuff with them, including interactive (hence the name) discussions, intelligent quest triggering, and the like. As examples, Thantos responds to Dentin's name, and the fire giants in the fire plane will give up quite a bit of history of the area if you just sit down and talk to them about it.

As common as these are, there's a lot of confusion about how iacts work. Most of this seems to stem from the fact that iacts are a form of finite state machine, and most people aren't used to thinking in state machine terms.

As an example, let's consider a mob that would unpack and wield weapons when fighting, then stop using and put them away when not fighting. This seems like an ideal example to demonstrate a simple state machine iact, as well as give an introduction to how iacts work.

The general idea is that the mob in question, let's call him Bob, has a weapon and a backpack. When Bob is in combat, the weapon should be out of the backpack and wielded, so Bob can defend himself. When Bob is not fighting, the weapon should be stored in the backpack, which Bob should be wearing.

The easiest way to do this is via four states in a state machine:

1) Not fighting. In this state, you wait for fighting to begin.
2) Start fighting. In this state, Bob is fighting, and should unpack his weapon and wield it.
3) Fighting. Bob is fighting for his life, and may need to retrieve his weapon if disarmed.
4) Stop fighting. Bob is no longer fighting, and should disarm and repack his weapon.

Here's a diagram of the four states, with the arrows being transitions between the states. Each block contains the name of an iact procedure, and in smaller text the iact code for that procedure:



Click on the image for a larger version.

As various things happen to Bob, he moves from one state to another. Most of his time will be spent waiting for fighting to start. When fighting does start, he'll quickly get out and wield his weapon in the 'start_fighting' procedure, then he'll transition to the 'fighting' procedure. While 'fighting', he'll continuously try to rewield his weapon if he's disarmed. When fighting stops, he'll transition to 'stop_fighting', which will unwield the weapon and put it away. Then he'll go back to 'not_fighting' and wait for another battle to begin.

I'm a deadbeat

I was looking at the list of big-ticket/high priority items on my whiteboard, and it occurred to me that a lot of them are half done.

Not the good kind of half done, where it's a huge project and a lot of pieces are in and functional.

The bad kind of done where infrastructure is in place and working, but it's not doing anything valid in the game context.

A good example of this is the recent boat code. This largely works, and probably only needs a couple of hours to get it in god-level beta test. Instead, it's sitting there in the code base, largely complete but unconnected.

How about clan wars? I spent time adding a lot of infrastructure for this, then never hooked it up. It also probably doesn't need more than a few hours to get it in beta test.

Classes are a bigger picture. I have more structure reworks to do, but I have been avoiding them. This one is a bit more understandable, because the project is so large - but this isn't exactly a huge piece of the puzzle.

Part of the reason for this is because I'm constantly 'firefighting' instead of doing new development. I'm always fixing minor bugs, heading off social/political issues, trying to manage things and people. I'm starting to think it would perhaps be better for all involved if I simply stayed invisible most of the time. I used to do that a lot, for exactly this reason, but for some reason fell out of the habit.

Another part of the reason is that the detail work isn't any fun. It's painstaking and precise, and there's always negative feedback from players to look forward to. Nevertheless, leaving a heap of half-finished projects on the queue isn't helping anything either.

No pain no gain, perhaps.

Halloween Havoc

I finally got the event report up for Halloween Havoc! You can see the report on the Alter Aeon System Events page.

This event was special for me in that nearly all of it was run by, well, not me. I was present for some of it, but I actually got to log in and play a mortal for a while. For the most dangerous (in terms of administration) part, the pk arena, Morpheus handled it, with some help from the gods Taran and Draak.

This is a very good thing, and it should teach me a lesson: delegate. We have gods that are capable of running, handling, and managing system events. Let them do it.

I like this plan.

There are also plans for thanksgiving and christmas-time events in the near future.

Web Page Updates

Yesterday, I spent far too much time working on changes to the Alter Aeon web site. I spent some time hacking down the menu so that there were fewer items that are better organized; I also managed to switch over the layout to a more standard looking block based design. Along with this came a number of other minor updates and improvements.

It never ceases to amaze me that you can work on a web site, get to the point where you've done the best you can, then come back a month later and improve it even more. For me, it's like my creativity is tapped out - I have to take a break to let new ideas percolate in. I think part of it might also be that I have to get used to a new design or layout before I can compare it against something else.

Regardless, of the half dozen or so people I asked, their opinions were an almost universal 'much better' for the new version. Here's to hoping that this 'much better' translates into a higher conversion into newbies!

For a look at the new layout, here's a link to the Alter Aeon Web Site.

Software Reuse

There is an old saying in the nootropic (mental-performance enhancing drug) community:

"The guys in the 60's had this truly brilliant idea of using drugs to expand conciousness and improve thinking. Unfortunately, all they had at the time was LSD." [Just to ensure proper context, this is said without sarcasm. It really was a good idea, however LSD turned out to be a complete flop in achieving this goal.]

I've recently been doing some work that involved C++ templates, so allow me to reword this for modern usage:

"The c++ guys in the 90's had this truly brilliant idea of direct language support for generic code and module reuse. Unfortunately, all they had at the time was c++ templates."

Sailing the seven seas

As a side effect of the ongoing mapping and world linearization project, I had a strange idea: why can't I hop in a boat and sail from the mainland to the islands?

The short answer is that in most muds, rooms have no absolute position data. Since this is no longer true for Alter Aeon, having long-distance boats suddenly seemed possible. So, I set aside a short period of time to do it.

It was nowhere near enough.

As a first step, I created boats and allowed some lookup of position to figure out where I could place them. This worked reasonably well.

For the second step, built a quick lookup function to go from boat position back to nearest room. This allows people to disembark.

Next, I had planned to simply use that lookup function to build maps, so that sailing around would have a functional map display. We can also use the map generator to construct blind descriptions, so that blind players can still see when land is near. This is where the problems began.

While we do in fact have positional data for rooms, the reverse lookup is quite a bit less trivial. In order to build maps, the lookup has to be quick and efficient. To complicate matters, the world grid moves around dynamically the rebuild time has to be short as well. There are also difficulties with a single room appearing in multiple places, and with multiple rooms vying for the same space.

I initially tried a rather complex space partitioning scheme, but after sleeping on it I realized I should just use a hash table. I implemented the various hash table routines in about an hour, and with around 3 hours total I have most of the corner cases cleaned up in the map.

Next, I pull up the anchors and see about doing some exploring.

Software Complexity Crisis

[This rather large post is almost entirely a personal rant. I complain a lot about wxWidgets in here, because it's fresh in my mind and a very good example of a specific type of software engineering crisis. Note that I'm still using the WX libraries for the Alter Aeon client project; clearly it has value to me in spite of its faults, and I appreciate the effort the WX team has put it. That said, if I could easily move to any another library that met my constraints, I would do it in a heartbeat.]

Various recent attempts on my part to use large software libraries have made me re-examine the issue of the general software-engineering crisis. I've run up against typical software crisis problems many times in the past, so I tend to keep my eyes open when I see material related to the topic. This is one of the reasons that Vernor Vinge's book "A deepness in the sky" caught my attention.

One of the basic premises of this book is that complexity failure can be sufficient to bring down entire societies. This was put very succinctly in a blog posting by Jeremy Bowers on his iRi Blog, part of which I quote here:

"One of the less well known concepts which informs his sci-fi writings is one possible fate of societies that do not or can not end in a "singularity", which is the eventual unavoidable collapse of the society in a cascading failure state brought on by excessive, uncontrollable complexity in the ever-more-sophisticated systems that drive the society. In this case, take "system" in the broad sense, including not just software, but business practices, government, and societal mores. A failure occurs somewhere, which brings down something else, which brings down two other something elses, and perhaps quite literally in the blink of an eye, you are faced with a growing complex of problems beyond the ability of any one human to understand or contain."

This relates to software in that I'm beginning to see more and more examples of how this can occur. Two software platforms in particular come to mind - IBM's WebSphere, which I was peripherally involved with a decade ago, and wxWidgets, which I am involved with today.

Both of these platforms are very complex. Both form an abstraction layer which builds on top of other layers - in the case of wxWidgets, there is a huge amount of API reuse from the lower layers of Windows, or GTK, or X, depending on which configuration it's built for. Each of these layers is built upon other layers, and other layers, sometimes with very deep call trees.

The most egregrious example of this kind of layering that I can recall was in WebSphere. A friend had asked me to take a look at a stack trace from a WebSphere crash; somewhere deep in Java land, a 'null object exception' had been thrown. (Thank god it wasn't a NULL pointer, that would have been much worse!) The exception handler that caught it was basically the main loop, because apparently no other layer could be bothered to check for failure conditions along the way.

There were over 160 stack frames to walk through. Not one of them was due to a recursive algorithm or function. I don't know about you, but that level of stack depth is quite frankly beyond my ability to manage or debug. I don't care what it does.

WxWidgets is clearly beginning to show stress of its own, of a different character: it's becoming more and more impossible to guarantee consistency across platforms. The WX guys have made tremendous progress in this regard, so that most of the core features work right, but there are simply too many details to keep track of and too many paths that will never be tested.

Here's a couple of examples of this, one of which I'm STILL fighting:

-------------------------------------------

When I first started switching the Alter Aeon client project over to WX, I initially used the wxTextCtrl class, which is built out of Microsoft system libraries in the Win32 world, or built on the GTK libraries in my development environment. I had hoped to use the class for both the input window, and for the main display; with a small amount of effort, I got the client running and working, but there were minor, very persistent issues.

The first of these was the input window. Various events, such as backspacing when empty, cause a system beep/bell under windows. They don't cause a bell under Linux. And further, there's no way to disable this. I don't know about you, but I'll be damned if I'm going to ship a product that beeps every time someone hits backspace.

I managed to take care of some of this by trapping out various keystrokes in the CHAR handler. It seemed like a poor hack at the time, but at least it helped. However it didn't help enough; a number of keystrokes simply don't generate CHAR events, yet they still fucking beep. I finally ended up writing a raw keyboard event handler, which tracks nearly all of the keyboard state, to trap out events that would generate a beep when passed to the lower layer. In the time it took me to disable beeping, I could have written and debugged a keyboard handler from scratch, with exactly the desired behaviour.

While beeping has largely been taken care of, other issues with this so-called standard class have not. The biggest one is that the color of text displayed in the class returns to black occasionally, and depending on the versions of the system DLLs for the particular Windows installation. My first attempts at fixing this were effective on all my development environments, but failed on about half of the release environments - text typed in the window would occasionally simply vanish.

By adding forced color setting in various places where it shouldn't be needed, I eventually managed to fix this problem for about 90% of my users. Out of sheer disgust at this point, I did some extremely vicious forced color setting in various event handlers, and this appears to have fixed 'most' of the problem. I still am receiving sporadic reports of it happening on current client builds, but at least the problem goes away now and seems to be triggered at random.

When attempting to use this same class for the main window display, I ran into what seemed to be minor issues regarding the scroll bars and scrolling of text in the window. No matter what I tried, I never did find a way to get reliable scroll positioning for this class across all platforms.

After fighting this off and on for several months, I became desperate. I finally wrote my own text display class from the ground up, using nothing more than bitmaps and font drawing routines. The total from-scratch implementation time was less than the time I had previously wasted trying to get the scrollbars to work properly. It's also faster, especially for very large data sets.

-------------------------------------------

This, my friends, is the software engineering crisis in action. Each layer, while hiding some of the problems of the lower layers, introduces its own; the overall result is a system with fewer catastrophic issues, but exponentially more minor issues.

Those minor issues are surely tolerable, are they not? To an extent, yes - but at what point do you die the death of a thousand cuts?

Catastrophic issues might be catastrophic and obvious failures, but that's one of the best things about them: they're catastrophic and obvious. They HAVE to be fixed. They must be understood, they must be cleaned up and dealt with. The minor problems on the other hand, can just keep accumulating. They just keep getting worse, they just keep getting more obscure, more complicated, more difficult to find and rectify. And worse, they compound each other.

In a good scenario over the long term, they become so prevalent that the system no longer becomes usable. In a bad scenario, the system becomes critical and unmaintainable. It's a swiss cheese of buggy modules and misunderstood patches.

Is that really what you want to build critical infrastructure out of? Is this where we're headed? I certainly hope not.

DClient 0.982 Released!

After a lot of hard work, intermediate releases, bug reports and beta testing, the latest version of the Alter Aeon game client is now available! It's only been about a month since the last release, but the number of updates and new features is pretty impressive. Here's some of the major things that have been updated:

• Grouping status bars added.


• A new version of 'left hand layout' is now available.


• Added basic support for color themes and backgrounds.


• Side buttons now use the same color scheme and format as popup and function key buttons.


• (For builders) 'connect' command allows connecting to arbitrary ports.


• Redraw flicker reduced in popup windows.


• Add support for GMUD color scheme.


• Smoother scrolling for the automap.

In addition, there's been a pile of minor bug fixes, as well as a lot of work to clean up and improve the interface. You might also notice things like removal of scrollbars and word wrap on popup windows that don't need them, fewer buttons to be confusing for newbies, and improvements in the input text bar. Here are some examples of a couple of possible configurations:





The basic theme support and the overall interface cleanup should help us a lot with new players. The first 30 seconds of pretty buys you the next 30 seconds, etc. It seems to take forever, but incremental improvements do really add up over time.

Again, the download is at http://www.dentinmud.org/AlterAeon.exe. Snag a copy and check it out!

Yet Another wxWidgets Fail

I've been trying off and on for a while to get transparency to work in my Linux/GTK builds, and for whatever reason it's just not working (at all.) After running some experiments last night, the best I can determine is that there simply is no alpha channel available in the wxBitmap/wxMemoryDC that I'm trying to use.

It's not that I didn't try to get one. Supposedly all you need to do is construct bitmaps with a 32 bpp and everything else will take care of itself; however, even simple operations like putting a pixel or drawing onto the DC returns 0xFF for the alpha channel every time. The alpha simply disappears. Because the alpha is gone, when I attempt to draw or blit the bitmaps, I get a full overwrite instead of a proper alpha blend.

Once again, it's beyond me how something so simple can silently fail so catastrophically while giving no indication of error or dysfunction. I'm using the modules according to the published API, and the expected results do not occur.

Naturally, there is coupled to this another issue: wxWidgets does not have very good drawing/shading and blending primitives. I could probably draw what I want using the tools, but it will be costly, both in time and processing power.

The obvious two solutions present themselves:

1) Find another library, such as OpenGL, that can I can integrate into the toolkit, or

2) Write my own graphics subsystem.

Size is, in my mind, at a premium here, so I would prefer not to bloat out the executable with another five megabytes of drawing and 3D utilities. It also just so happens that I've done a lot of game and graphics programming in the past. Graphics programming that included various primitive libraries.

Now, the only issue is how to get direct access to wxBitmap data so that I can do my drawing elsewhere, then copy into the bitmap for blitting. It just so happens that there's an undocumented 'wxRawBitmap' class that looks like it might do the job. Hooray for undocumented features. What the hell.

Client Customization

As part of my quest to improve the client, I accidentally embarked on sanitizing the button color scheme and making various colors consistent across the codebase. When this was done, it occurred to me to fiddle with them, and I ended up with some very interesting results, which you can find in the dentinmud.org screenshots directory.

Here's some direct links:

Red Alter Aeon Screenshot

Blue Alter Aeon Screenshot

Default Color Alter Aeon Screenshot

I personally like the blue a lot, but that's just me. A lot of players expressed concern at the blue layout or found it ugly. The red one was almost universally disliked, which I found surprising. Attempts to tweak it were really unproductive; for whatever reason, it seems very difficult to come up with red background color schemes that don't look terrible.

The current plan for the next day or so is to at least make these run-time selectable, though most players disable all of the buttons when they play anyway.

Strange as it may seem, I think the blue adds a whole new level of cool factor to the initial impression of the client. It's definitely eye catching, which is probably a good thing given the stunningly high dropout rates of people who try the client cold.

PK, PPK, PK, PPK...

Player killing on Alter Aeon has always been limited to registration, and while we have various arenas and temporary PK, we also have permanent registration - known as PPK.

PK has never bothered me much, but it's never really interested me either. PPK on the other hand I've tried a couple of times. I could never get into it, and it also seemed like I could never get away from various instakill issues.

Instakill reared its ugly head again a few days ago, and after fixing the specific instakill bug, it occurred to me to simply cut all PK damage in half. That clearly reduces the instakill problem, yes? However, there are some problems.

The biggest of these is that the existing PPK population doesn't like it. There's a few of them that do, but largely the response has been negative. A number of them say that PPK has gone from a threatening, risky affair to an irritation they can easily and always run from and survive. Others note that the power to heal has been effectively doubled, giving casters with a lot of mana huge advantages. Both of these criticisms are good, and sufficient to convince me to revert the change.

However, the instakill problem still lives. The current consensus is that judicious limiting of various instakill mechanisms is the best way to go forward. Barring any major objections, we'll probably go that route.

The mapping saga continues

While in the dentist's office yesterday, I had a brainstorm regarding mapping: why not run a real-time simulated annealing algorithm to automatically generate the global coordinate grid? When I got home, I took a few hours to implement it, and last night I booted an initial version into the game.

These new position values don't currently do anything, as I'm still working out the bugs and looking for general problems. One thing that appears to cause quite a bit of trouble are nonlinear 'portal' links that bridge a large distance; another major problem are god/builder rooms that link to unusual locations for plot device reasons.

Flagging these troublesome exits isn't something we can currently do, but it's become clear that we will need to do so in order to make the grid coherent.

Finding the problem exits is also difficult, but it's made somewhat easier by an extension to one of our existing mapping routines. By calculating a 'stress energy' for the linkages in each room in the map, I can get a pretty graph showing where maximum grid distortion occurs. These points of maximum distortion usually occur near a positional anchor, which are used to set the position of continents or isolated zones.

However, once the map for a given area has stabilized, the maximum distortion points typically indicate one of the nonlinear links described above. Once the approximate location is known, finding and marking the link is substantially easier.

All in all, I think this is working well enough that we may be able to use it globally for all area placement. Over the next week or two I'll be generating some area and room maps based on this data, and we should be able to refresh the god area and room maps on the web pages soon.

Class updates

As part of the groundwork for getting additional classes into the game, Locane and I have been digging through the code and trying to condense common routines and eliminate dependencies. He's been working largely on uncontroversial skill changes, to merge together the skill handling routines and make it easier to add skills in the future. I've been working on player regen and healing. This is a bit more controversial.

Quite a bit more controversial, as it turns out.

The fundamental problem with regen and healing is that the algorithm was put together over a decade ago, and hasn't been fundamentally altered since. In its simplest form, caster levels are pitted against fighter levels, and regen is heavily tilted in favor of the winner; higher casting level means greater mana regen and less hitpoint regen, while higher fighter level is the reverse.

This balancing act was a zero-sum game. Gaining a single level in a class could force you to trade hitpoints for mana; and at higher levels, a caster for example has no choice but to gain levels in fighter classes. The only thing that made this balancing act of a system usable is cast level equipment, which allowed players to push around the balance point.

Unfortunately, adding new classes isn't really compatible with this. We have also received a number of complaints over the years about unusual side effects and problems with the system. I finally made the decision to try something radical, rather than continuing to tweak the existing code.

The last couple of days, while hectic, appear to be quite an improvement. The level/balance dependency is gone, and I've even managed to keep cast level somewhat usable. Most players have increased net regen, which is probably bad in the long term, but in the short term allows work to progress.

Something unusual is that the value of mana regen varies wildly based on the player and their playing style. I have a couple of fighter primaries totally geared out like casters; these players complained loudly about being dented. This type of player would gladly trade hitpoint regen into mana at a 4:1 ratio, double the standard 2:1 typically found with heal spells. Most other players are happy with 2:1, as they burn through mana and hitpoints almost equally as they play.

The plus side is that this work has eliminated yet another choke point for pushing through additional classes. Unfortunately, there remain quite a few equally controversial areas that will need to be updated.

Client release 0.981!

After much debugging, version 0.981 of the Alter Aeon Mud Client has been released! This release has a number of cool new features, including:

- popup windows for things like your equipment, stats, spells, and who list

- function key buttons that make sense

- inlined automap in the main window

- cleaned up and prettier user interface

This version of the client is quite a step forward, and we've got a lot of positive feedback from players. Grab a copy from the main Alter Aeon web site, at:

http://www.dentinmud.org/AlterAeon.exe

Here is the full changelog of additions and updates in this release.

Version 0.981 - Sep 02, 09

---

The automap is now undockable.

Minor bug fixes to main window mouse selection and screen clear.

Disconnect dialogs and quit/program exit will no longer echo commands to the screen, so newbies won't see things like "quit -check".

Fixed bug so font size changes immediately update the scroll bar.

The 'you are here' diamond in the center of the map should now pick more contrasting and visible colors based on what room you're in.

With command pushthrough, pressing the left arrow key after selection will now deselect and put the cursor on the left side of the window.

A voting reminder option is now available in the voting menu.

An option to open all voting sites at once has been added.

Fix bug in status bar hp/mana/mv display when changing window size.

Minor improvements to url clicking.

Add support for function key button bar.

When the automap is docked, it's now resident in the upper right corner of the main window instead of off to the side.
'Left side layout' has been removed.

Some of the menu items have been moved around.

The enemy hitpoint bar now floats in the main window when it's active.

The enemy hitpoint bar can now be disabled from the preferences menu.

The main window scrollbar can now be disabled from the preferences menu.

Control 1-9 now enable/disable various features.

Control-B has been removed to free up keyboard space.

Hitpoint bar red color is now slightly brighter.

Client update

I've been working on the DClient code for the last couple of days, and it's coming along nicely. I had intended to do another interim release on thursday; after discovering that the Windows build of fundamental display primitives is vastly different than the Linux version, I had to go back to the drawing board and come up with a rendering/display system to avoid those issues.

Conveniently, with the new rendering system, the original problem that forced me to write the rendering system has vanished. I could probably figure it out if necessary, but at this point, I just want to get my work done. I'm still keeping the rendering system though; every piece of WX I replace is one step farther away from needing to use it at all. At some point, all that will be left is the event loop, wxDC functions, and Win32 resource management.

The improvements in this version of the client are primarily a simpler user interface with a lot less clutter. We also have popup-style windows for things like score, equipment, inventory and the who list. I've also prettied up some of the buttons, and have enough infrastructure in place to possibly start doing some window decorations.

If everything goes stunningly well, I should be able to get a testing release out Sunday night. More likely however, it'll be monday or later.

Periodic Update

Over the last month or so, we've been hitting game development really hard. There's been a lot less focus on web presence and advertising, and a lot more focus on 'what makes the game fun' and how to make the game the best it can be. Some highlights of this process are:

- addition of 'credit' code, which allows for in-game microtransactions

- 'trade' code, which allows secure transactions

- a 'freak' multiplier for turn undead

- skill changes and updates, part of a global skill system restructuring

- initial conversions of class code, to allow for easy addition of more classes in the future

For a full list of the mortal changes, see the Alter Aeon Changelog. Keep in mind that there's at least as many builder and admin level changes as there are visible mortal changes!

There's also been a great deal of cleanup and reorganization of the immortal building tools, to help us get more areas up and running quicker. This was brought on in part by a couple of areas which had problems not detected by the automated area checkers. This should help a lot when we get ready to pull over another round of bport builders to the main port.

Regarding advertising, I've temporarily turned most of it off, and the newbie/login numbers do appear to reflect that. One of the reasons I shut it down was to see the net effect; another was difficulty justifying the money for such a low increase in player base. Advertising works best on a market that would use the dclient; but the dclient isn't good enough yet to convince people to play. I really need to get another client release out and get it polished up.

wxWidgets sucks

This is becoming less of a mud development blog than a 'bitch about wxWidgets sucking' blog. I've run into yet another piece of wxWidgets wierdness: wxBitmapButtons don't work. The documentation claims bitmaps can be used instead of the default graphics; trying this results in a very small bitmap wedged inside a ten pixel thick border of default graphics. There appears to be no way to turn this behaviour off.

I'm sure that there's a perfectly good reason why it behaves this way. It might be intentional; it might be that my development platform (GNU/Linux) is more buggy than other platforms; it might be that I'm simply terrible at operating this toolkit. Regardless, its unacceptable, and it is only with great reluctance weighing my application requirements that I did not switch to something else this very night.

Screw this toolkit. I wrote a text window class for exactly this reason, and quite frankly if I'd have done it to start with I'd have saved myself a lot of time. I will not make that mistake again, and as of right now I'm creating an image button class. I might not know what I'm doing, but at least I'll know it works properly, on all the platforms I need it to.

I get the feeling that by the time I'm done with this, I'll have using only the event handling loop and the font selection dialog. It seems like those are the only widgets that actually function as documented.

wxWidgets - focus problems using multiple top level windows or frames

[Updated Jul 14, 2009 - this turned out to be a code bug on my part, at least partially. Further details in the comment section.]

As I'm sure you all know, I've been putting together a graphical/GUI client for the MUD Alter Aeon for the last few years. About 9 months ago, I switched to using the wxWidgets toolkit instead of QT, for reasons of executable size and licensing.

This switch has cost me on the order of 3 full months of development time trying to work around bugs in the wxWidgets ports on various platforms. I hit another one of these porting bugs/issues today; fortunately it only cost me about four hours, and amazingly enough, I found a workaround/answer that didn't involve rewriting the component from scratch.

Long story short: if you have multiple wxFrames or top-level windows in an MSVC build, the default is that you can't focus on any but the first one. My exact scenario:

1) App creates main window frame.

2) Main window frame later on dynamically creates a handful of new popup-style frames.

3) All of these new frames are immediately defocused and placed behind the main window frame. Attempts to raise or focus them are completely and utterly ignored. The FLOAT_ON_PARENT window style does nothing.

Oddly enough, minimizing the main window sometimes allowed the children to gain focus or 'disconnect' from the main window so the focus worked properly. It wasn't reliable, and it was never clear to me exactly why or how, but it never did what I ultimately wanted anyway.

There's no documentation on why any of this should happen, at least nowhere I could find. It all worked fine in the Linux port! After multiple hours of screwing around with it and reading unrelated documentation, I finally tried something I found in an obscure post, and it worked.

The solution:

1) Don't bother to hook the focus event. It doesn't do shit anyway.

2) Hook the Activate event in your new frame. You've probably never seen this before. Neither had I. I still don't know what exactly it's supposed to do.

3) In your Activate event handler, SetFocus(), then Skip() and pass the event down. The SetFocus() brings your new frame to the top and allows it to take focus in the future.

That's it. It's all of like three lines of code; I hope it doesn't waste nearly as much of your time as it did of mine.

[Note - I understand that the wx guys are doing this basically for free, and that they're up against a nasty set of ports to get everything working properly. Still, it's cost me a lot of time, and if I had known better I would probably have just paid for a proper QT license and found some other way to reduce the file size.]

Where do we go?

I've been doing some serious thinking about the game, the market, and the business model I'm trying to work with. I still think the business model is sound; I've been able to pay most expenses and use the remainder for (admittedly ineffective) advertising for years. This year will be different, as I'm dumping some of my personal money into it, but even so the numbers have risen and will compensate somewhat for that increased outflow.

The biggest problem I see with regard to expansion right now is, unfortunately, market based. If you go out to any gaming news site, it's not just that there's a handful of games being advertised - it's that there are hundreds (if not thousands) of games being advertised. It's reached the point where you're lucky if you can even find a WoW ad amidst the piles of other crap.

The gaming market right now is, as near as I can tell, in the middle of a huge investment bubble. Hundreds of companies have come on line with venture or public funding to be the next 'WoW killer'. These startup companies are pumping hundreds of millions of dollars into advertising for a limited number of players; several new cookie-cutter MMOs come out every week.

On the plus side, most of these will fail. As with all bubbles, this one will collapse, and most games will go under. There's simply not enough players right now, and once you've seen one cookie cutter game, you've seen them all. In some ways, being a text based game protects us, as we have a limited niche that isn't facing ridiculous competition.

So what do we do about it? In the immediate short term, scale back plans of massive growth, and wait for the bubble to pop. But we can't just rest on our laurels either; we should be doing something. What best to do?

Make the game the best game it can be, that's what. Most of the games that will fail, will fail precisely because they -are- cookie cutter games. Do you not think that the players on WoW would pay $5 more for a game that was $5 better than WoW? The reason that they don't is because there aren't any games $5 better than WoW.

I currently have two projects in various stages to this end. The first is the ongoing upgrade to the client, which is coming along slowly but steadily; I probably won't have a new release this weekend, but should have one soon. I think with that release I'll start looking for a graphic designer or other artistic input to make the interface pretty.

The other project is only in the planning stages: add more classes to the game. I get a lot of comments from newer players that the limited class selection looks strange and seems thin compared to other games. It also has issues (which some players call features), such as limited room for long term expansion, high level characters all being the same or very similar, a small number of high-end playing styles, and what I would consider bogus skill groupings.

I think I have a rough model of how to do class expansions now, but it will probably be several weeks before we have enough detail fleshed out to really start implementing it.

Client innards

I've been working on the client recently, to try to build little pop-up windows that contain useful information, for example what you're wearing, your inventory, or your stats. The basic guts of this are working, and other than the buttons being ugly it seems pretty useful.

One big problem I have yet to deal with is automatic update of the data in the windows. It's neat having the info there and all, but if it automatically updated when things changed, it would be WAY more useful. I'll have to do a bit of server side work for that to work properly.

With any luck, I'll be able to get a new client release out in the next few days, or at the very least a test build for people to experiment with. I think this will be an excellent addition to the client, and it opens up a lot of possibilities to do other things as well.

Gold balancing in MMOs

[Update 2009/07/04 - I've posted an updated version of this post as an article on the Alter Aeon web site.]

All too often, articles talking about gold balance do little more than state simply that 'most MMOs have problems with gold balance'. Rather than waste your time, I'll describe a successful example of a gold economy, and what it took to get there.

Alter Aeon handles its gold economy fairly well, after many years of tweaking. The foundation for this stability is accurate gold tracking:

- All gold sources and sinks are tracked and understood

- Real-time gold stats are available

- Unexpected or 'dangerous' gold changes are logged

- Large gold changes, even valid transactions, trigger notifies just in case

- There's a single global value representing all gold in circulation

Just tracking the flow of gold through the system was useful, but completely ineffective in actually managing the economy. Usually when a game manages to get numbers, they have active immortals adjust things on a continuous basis to keep the economy under control. We decided that this would be a complete waste of time for an immortal; we have computers to do boring tasks like this.

Therefore, we don't bring immortals or builders into the picture at all. Nearly all gold drops are calculated from statistics and game parameters. Adding this helped tremendously, but was still not enough to stabilize the economy on its own. In the long run, we ended up with several layers that each contribute to the whole system:

- Mobs drop gold based on their death or theft rates; object gold is similarly modified with every looting of a treasure object. The purpose of this dynamic feedback is to prevent one source from dominating or becoming the 'easy gold'.

- Large quantities of gold are taxed. Characters holding more than a million gold are taxed on the amount above a million gold, to the tune of about 2% per week. The purpose of the tax is to prevent packrats from accumulating unlimited hoards.

- Clan and guild bank accounts can only hold a limited amount. Since the very existence of the clan indicates that gold is being paid in dues, this limited amount is fairly high (on the order of 50 million gold.)

- Player shops can hold an unlimited amount, but generally shops have high rent rates, so gold turnover has so far not been a problem there.

- Dynamic pricing of items alters the price of items for sale in shops based on how often they are shoplifted. If a particular item is stolen too often, the price is lowered and the theft difficulty is raised to make the price more cost-competitive.


But by far the most critical part of the system is the global offset controller. This control system monitors the total quantity of gold in existence, and subtly tweaks the gold sources based on that value. The short-delay term of the control system looks at local deviations from the long term expectation, and fairly aggressively modifies the global gold sources. This short-delay term can change total gold influx on the order of 50% in a one week period if necessary.

As the total quantity of gold in existence changes, the long-delay term of the control system slowly adjusts the set point for the short-delay calculations. If a large amount of gold is in circulation, the short-delay set point will be lowered, globally lowering the input of gold into the system.

The net result of all this is that we have a system that allows for fairly substantial deviations in the short term, but always returns to long term stability. Total gold in circulation has varied by approximately 10% (peak of 528 million to trough of 482 million) over the last two years, and I no longer hear the once-common complaint that gold is worthless.

Web pages

I've just completed the first pass of an all-CSS layout for the official Alter Aeon MUD site. To retheme the site, it should be as simple as picking new colors, and generating two header images for the image banner across the top. At least that's the hope.

One of the reasons for doing this is the possibility that the dark, ominous colors are driving people off. I've heard more than a few comments to the effect that the current color scheme is 'off-putting' and/or looks evil. (It does after have demon horns in it.)

I've certainly noticed this in RL in terms of dress. When wearing my usual fare of all black, people are much, much less likely to approach me than if I'm wearing blue jeans and a light shirt. If web page viewers are even remotely similar, a difference of 2:1 wouldn't be impossible.

With all this in mind, I'm perfectly willing to try some lighter color schemes and see if it helps. Perhaps a nice light blue ice theme to begin with.

I should probably think a little harder about the image backgrounds. It should be possible to do image under- and overlays to perhaps pretty things up a bit.

FYI, this is all hand-written CSS, with the pages generated using GNU M4. Take a look at the source time time if you're bored.

Skills, spells, and classes

Today, a long-pending project finally got turned on for general use in the game: monster lore, and a few specialized versions for particular mob types. The current specialized skills are demon lore, elemental creature lore, undead lore, animal lore, and dragon lore.

In coming up with appropriate class distributions for these, I once again ran into the shortcomings of only having the four basic classes. There's really just a few things that don't fit nicely into combinations of those four buckets.

So I've been thinking really hard about just how much effort it would be to add other classes to the game. The first most obvious one would be a ranger class, which already has a handful of skills and could probably appropriate a bunch of stuff from cleric and mage.

I wouldn't just want to add one more class; if you're going to change the infrastructure enough to allow easy addition of classes, you might as well make a handful of them and get some really solid groupings going. I'd feel better about it if I had more than just ranger to work with; I think a lot of other skill sets can simply be specializations of existing classes, and don't justify a separate class.

Good examples of these would be necromancers (cleric), elemental casters (mage), and barbarians (warrior). I don't think any of these so much need a separate class as just appropriate spell and skill trees.

There's also a question of how many classes are ideal. Keeping with the exponential leveling scheme, a level 30 character should have levels of approximately 30, 25, 20, 15, 10, and 5, with levels in six classes. I'd actually expect there to be more people in the upper ranges similar to Boa, with something more akin to 33, 32, 31, 27, 22, 17, 12, 7, and 2, for a total of 9 classes. This indicates to me that even the most hardcore players would have difficulty bringing up to the top more than ten or so classes.

As far as code modification, there's a handful of specps and some other places where the code would definitely need work, but I'd like to think that once the fifth class is added, a sixth and more would be much, much simpler.

The final issue is: does this improve the game enough to justify the effort? It certainly adds some concept of end-game and more opportunities to advance high level characters, so perhaps the answer is yes. Then again, perhaps not. What do you think?

Trading

I've been out for almost a week, so when I came back it was time to pull forward code from Locane and get some other minor things out of the way. As it turns out, he's been working on secure trading between players, and while I was away I read some articles on that same subject.

There seems to be quite a hubbub going on in the MMO world regarding trading, in particular gold farming. The general consensus seems to be that gold farming is something that should be utterly squashed wherever it crops up; further, anyone caught selling gold (or other in-game currencies) for real life cash, outside of the game environment, should be penalized as harshly as possible. Most games delete not only the accounts of the farmers, but the accounts of the purchasers as well, and occasionally the accounts of anyone they trade with.

This seems ridiculously harsh to me.

When I first started the game, I didn't really have an opinion on this topic. I originally didn't think trade would be big enough for it to really be a problem. Over the years, players began to donate to the game simply because they liked it; we (I and the other admin at the time) decided to give minor perks to those contributors as a way to say thanks. Many years later, we now offer a wide host of things for purchase from the game store.

While we were setting all this up, I got a lot of very good advice from some very bright people. The overwhelming majority of them were very clear on one point: thou shalt not sell things that unbalance the game. This includes characters, equipment, gold and a number of other nasties I have seen for sale on (less than successful) games in the past.

Players don't like the idea that someone without skill can buy their way to the top. If you take a look at our list of purchasables, you'll notice that everything on that list is either convenience, customization, or a minor boon. This policy has worked rather well for us over the years.

But back to the issue at hand, which is trading. I don't see any reasonable way that it can be completely prevented, and from my standpoint anything that's traded had to be obtained by someone somewhere. If they're going to be doing it anyway, I'd much rather put in some sort of secure mechanism for it, so people can't be ripped off.

Locane's code starts this off by handling in-game currency only. Once that's stable and working well, I'm going to add the ability for people to trade dollars, but only ones that have already been donated. Once dollars are donated to the game, you can buy donation things with them or trade them to other people. Eventually, I'll probably set up business accounts that let people withdraw those dollars from the game.

It will be interesting to see if this model works for any other MMOs. So far, I'm not aware of any that have tried it.

One major concern I have is regarding duping and generation bugs. If someone finds a way to exploit gold or certain items into existence, it may quickly become very difficult to clean up.

Customization

After a week of forcing myself slowly, piece by piece through this code, I finally managed to boot in player customization on character create. I don't know if it's just me being in a coding funk for a week or not, but it seemed abnormally hard to get this done and installed.

The upshot is that we now have basic character customization for new players. They get to pick a handful of obvious traits, from which a generic long description is created. This will hopefully solve two problems:

1) The long description problem, which is that most players seem utterly incapable of generating proper long descriptions. Those who are capable don't want to take the time. Everyone now has a sane long by default.

2) Far more important is the issue of player investment. Specifically, new players are insufficiently invested in their character to return after their initial playing session. The hope is that customization will pay off in the long run, as the people who do take the time to customize will be more likely to return. I should be able to verify this over the next few months by tracking stats.

There's still a lot of work that needs to be done here, including ways (other than long descs) to see your features, and ways to change them. Changing them is actually going to be more interesting than I expected - as was pointed out to me, age is technically quested for via the fountain of youth, why not quest for most of the other attributes as well?

Things like changing hair length or style are clearly easy to do (got some scissors?), but other things might be interesting for players. Changing skin color for example, could be a pretty involved process.

Now that this is done, there's a whole raft of low level changes on my todo list. Lack of player investment is only one part of the problem; the remainder is that the game just isn't as fun as it should be for low levels. I have several more quests to add, as well as a couple more shopkeepers and more utility items. There are also some structural additions to be made, but those can wait for a while.

Newbie Statistics

I had a brainstorm the other day for how to pull a certain class of statistics from the various logfiles and other data we track in the game. The idea is that we grab all the new characters created in a one month time period, then see how many of them continued to log in for successive months. I decided to try this on four month time periods to filter out storage characters and other infrequently used but legitimate pfiles.

Here's a chunk of sample data, looking at how many of the players we got in January continued to log in for February, March, and April:

Total created in 2009-01: 230
Total last saved in 2009-04 or earlier: 198
Total last saved in 2009-01: 146 Average Total Levels: 8
Total last saved in 2009-02: 21 Average Total Levels: 22
Total last saved in 2009-03: 16 Average Total Levels: 28
Total last saved in 2009-04: 15 Average Total Levels: 30

Some quick observations to distill it down:

- Of the 230 characters created in January, 198 have not yet logged in for May. Only 32 of 230 (14%) have been active this month.

- Nearly all of the dropouts are in the first month, with 146/230 logins (63%) never bothering to log in again.

- Once you get past that critical first month drop out period, we lose people at a relatively steady rate.

- The first month players actually get more than one level. They get 8 on average. Even having leveled multiple times, they still don't return.

When I looked more closely at the data, I found some obvious patterns for nearly all of the people that drop out in the first month. In particular, they play the game for a reasonable period of time (15 minutes to two hours), get a handful of levels, learn a few things, then log off. About half of these never sign in again. The remainder sign in a small number of times, generally for only a couple of minutes, then sign back out.

There's a really obvious reason: The game isn't fun enough to hook newbies at low levels. They're bored, and don't know what to do when they return.

Ways to improve this:

- Add more really low level quests in the encampment. (I already have a couple ideas for this.)

- Add more quest guides for the Vemarken and other Sloe quests.

- DClient changes to make quests and other things more obvious and interesting (in progress.)

- Build the low level generic skills (cooking, skinning, etc) and make them useful. This may involve some form of low level crafting.

- Possibly give return bonuses. I believe I saw a game at one point that gave increased experience if you returned after a long absence.

This is more than enough stuff in the short term to keep me and probably several other people busy. Unfortunately, the only things I can offload onto others are the first two, and I'll probably still end up being involved at least incidentally to do cleanup and monitoring. I generally have a better idea of where the dropout points are for really low level players, because I spend more time watching them.

If I get all of this done before the end of May, I will be very surprised. It's a good short term goal though. (The return bonuses are excluded for now, as I don't know if we want to go that route. I'll have to think about that one a bit more.)

Advertising/Public Relations

Last night on a whim, I searched for the mud Dragon Realms just before I went to bed. DR is arguably one of the biggest and most successful muds of all time; they are fully commercial, with accounts going for as much as WOW accounts. They regularly top 700 concurrent users, and that's just for the one server. They have at least one additional.

An hour later, it was way past my bedtime and I must have had over 50 browser tabs open. This sort of thing is an amazing way to get ideas of where to post and link to Alter Aeon; they've already done most of the hard work, and Google has made it accessible.

Today, I began trimming tabs. I'm down to probably only 15 or so, most of which are waiting for some event to occur. I know I can repeat this process for a handful of other large games easily enough. I'm about 90% certain that the main AA pages can breach Google Page Rank 5 by the end of the year, possibly sooner.

While copying isn't a great way to be a leader, it can at least get you into second or third position. Given that we're in about 30th place right now, I'm totally up for doing some copying.

MishMash

A quick note - I built up a Muds and Mudding lens over at Squidoo. Squidoo is one of those new things which I don't entirely understand, like I don't understand Facebook or Myspace. But other people do, so perhaps it's not such a bad idea. The url is:

http://www.squidoo.com/mudding

I've been thinking about and doing a bit of work on the client recently. One of the newer changes was the addition of an enemy hitpoint bar; the current release client has this bar between the automap and the buttons. I moved it to be in the regular prompt bar, and this serves to make the screen a lot less 'busy'.

All this has got me thinking about what to do next. I really should allow for an unhooked/floating automap, so users can position it wherever they want. I've also been thinking about having a sort of 'list window' where people can perform actions on list items, such as looking in containers, getting things from containers, etc.

Until recently, the mechanics of how to do this in the code have been somewhat questionable. As usual, talking to my girlfriend about it generated a solution: uuid strings for objects and characters, that you can always use to get an exact command reference to that object or character.

I started on the first stage of this process last night, with infrastructure. The game has had a really, really bad PRNG for years; I threw something together with basically no experience about ten years ago and we've been using it ever since. Looking at the code, I'm actually somewhat surprised it didn't cause a lot of visible trouble over the years.

We now have a brand new, 10-register lagged fibbonacci PRNG driving the game. Not only is it faster, but it actually produces reasonably high quality random numbers to drive the game mechanics. Using this, im now generating proper UUIDs that I can have some amount of confidence in.

The list window however I'm less sure about. I suspect this needs a proper design.

Articles and Propaganda

There's a new article out for thieves. It's a pretty comprehensive overview of the various stealth skills, such as sneak, hide, stealthy movement, searching, and even how these affect other skills such as backstab. It's a real treasure trove of information:

The Thieves Creed - Stealth and Hiding

With this addition, we've now cleared 30 official articles, not counting things like FAQs, the quest guides, or other related things. The web site is actually becoming useful to players.

The articles are continuing to show their value, both in greater and lesser extent than I had expected. I regularly refer people to the articles when discussions and Q/A happens on public channels. I really had not expected this, and I'm constantly surprised at the things people ask. A good example is the article on Time, Age, and Aging, which I refer people to regularly. Other articles, such as the article on attack strategies, are much less active, though much more comprehensive.

One other area that did not work out as I had expected has to do with the web traffic to the articles. I was expecting substantially higher numbers in regards to web traffic than what we've been seeing. I think this might be a critical mass problem however, in that traffic has been picking up recently.

In other news, the maps and quest guides have been very, very popular on the web pages. They are now the second and third heaviest hitters on the site.

Client release and changelog

A new client release, 0.980, is out! The changelog is at the bottom of this note, with the previous changelog for 0.979 since I didn't post that anywhere else. At some point, I need to get the changelogs integrated into the server code.

The biggest two changes from my perspective were automap improvements and the enemy hp bar. The automap was by far the hardest, as display code has to be nearly perfect, and it has to handle a boatload of corner/edge cases. There's really not a lot of ways to do it cleanly, and for some scenarios you simply have to special case it. Here is an example of a particular problem area before the changes:



Here is the same location with the new mapper:



For compact areas such as this one, it makes a huge difference.

The enemy hitpoint bar is another interesting addition, in that it displays the condition of whatever you're fighting, similar to how Diablo II does it. There's a problem with it however - the current location is off to the side, above the automap. This turns out to be remarkably hard to see and use while fighting, even though it's close to the scrolling text and the input window.

I think what's going on is that the left hand side of the client is now simply too 'busy' for the eye to easily handle. Diablo II handled this by putting the enemy hp bar in a well defined, easy location (top dead center), and you knew that the middle of the screen was the most important place to look. The hp and mana bubbles were left and right bottom corner respectively. Each location is very easy to deal with.

For the client however, we have the big main window, which pretty much needs to be scanned continuously in order to keep up with things, the typing bar at the bottom but sorta off to the side, the hp and mana bars above that but right next to it, and the enemy status bar to the left somewhere in the lower middle of the screen. It's just not that easy to find things.

One option I've been kicking around is to make the status bar two levels deep, with the enemy hp directly above your hp. Not only does this give a good way to directly compare yourself against the target, but it puts both things in a very visible, single location.

I did some looking around at adding audio, and think I've found some libraries that should do the job. It's a lot of work though, and it might be best for me to figure out how to do actions and triggers first.


Changes in version 0.980 - May 08, 09
-------------------------------------------------------------
Keypad '5' now performs 'scan'.
Keypad '-' now walks 'down'.
Keypad '+' now walks 'up'.
Minor improvement to url clicking.
Don't lock main window unless more than one character is selected.
Diagonal exits now display a bit more cleanly.
Added basic zoom in/zoom out on landscape scale changes.
Left hand layout now puts automap at bottom of screen.

The automap is now either on all the time or off all the time, it no longer toggles based on login state.

Allow ctrl-+ and ctrl-- to more reliably change font when using keypad movement mode.

A display window for a target hp bar is now visible above the left hand side automap.


Changes in version 0.979 - Apr 28, 09
-------------------------------------------------------------
Add walking via number keypad. Toggleable using 'preferences' menu.
Clear scroll lock when a button is clicked.
Add 'local echo' option under 'preferences' menu.
Help message when you disconnect/are disconnected is now highlighted.
Prevent beeping for additional key combinations.
Add mousewheel support.
The 'quit' dialog buttons have been changed from 'Quit' to 'Exit Program' instead.

Command queue cleared when you're disconnected, so your next connect attempt doesnt immediately error out at the name prompt.
The '//clear' command now clears scrollback, like the menu.
The 'clear' command in game now works. It sends two screens full of blank lines, so you don't lose your scrollback.

Mapping colors tweaked to better show towns and cities.
Default ansi colors tweaked a bit to get more color saturation.
Ansi color palette options added for ZMud style colors and bright colors.

When you start fighting, the area map will display 'Combat!' instead of the area name.
A new "Left Side Layout" option has been added under preferences. This moves the buttons and automap to the left side of the screen, whereit's closer to the various text windows.

Warriors and clerics

Today, I installed a bunch of changes to the game - the first major skill updates in quite some time. The overall additions were:

Potion throwing - mid level thief, increases chance of spells being cast when potions are thrown at mobs. This whole potions being thrown at mobs thing is pretty new in itself.

Potion bottling - allow conversion of liquid container brews into potions suitable for later use or throwing.

Iron claw - mid level warrior skill to lower the chance of disarm.

Revenge - seriously amped up berserk when one of your group members dies.

Protector - single target tanking, another group skill.

These skills took me on average about 4 hours each to build, test, and install. It's a pretty short period of time all things considered, but a couple of them were pretty simple to do as well. I've had single skills in the past that were substantially more complicated and time consuming to set up.

One of the comments I saw after all this was installed was along the lines of "I'm surprised that warriors don't have more attack skills", which is a valid complaint (of sorts.) Warriors really -don't- have a lot of single attack skills. One of the main reasons I haven't added more is that I didn't want to create a whole bunch of cookie cutter skills that are basically all the same stupid generic damage thing.

At the same time, mage has something similar to this: there are a number of damage spells, often the only difference between them being the damage type or mana/damage throws. Perhaps having a bunch of similar kinds of skills for warrior isn't really any different, and might make people happier. I'll have to think about that a bit more.

I always viewed mage and thief as being the 'standalone' classes, the ones best suited to soloing. Cleric and warrior have always struck me as being more group oriented. The available skills seem to reflect that, in that thief has basically no group skills and mage can cast spells on other people. Cleric and warrior are the glue that hold groups together, and a lot of the skills I've added for warrior reflect that.

Remapping of cities

In the quest for linearity and mapping in the game, the answer for towns and cities is clear and obvious: all rooms are the same size. I remapped and expanded the main city in Alter Aeon today, which really cleared up a lot of conflicts and has left no rooms on top of each other. It maps clean, and it wasn't even a lot of work. Here's an example of the client map for the new version:



There's lots of roads, lots of places for shops and other stuff, and a few dead spots to allow for expansion. Most of the player comments have been positive, which is surprising - generally anything that messes up someone's directions causes all kinds of havoc.

This doesn't address the issue of how to handle large expanses of space though, for example forests and other linkage areas. You really don't get an idea of how big the world is until you put into perspective the relative size of cities.

Take for example, my home town. It's a small town of 5-10k people, and from the recent Google maps it's a little over a mile in diameter. Meanwhile, the state in which in which it's located is around 250 miles in diameter (except that its squarish.) Take a penny and tape it to your wall. That's the size difference, and that's just one state, not an entire continent. For a continent, tape a quarter to skyscraper.

I'd like to think Ralnoth in the game is probably about the same size. The currently expanded Ralnoth is about 12 rooms wide and 25 tall; let's say 15 for the sake of argument. Meanwhile, the entire game is perhaps 400 rooms across and tall, neglecting portals to islands and the like. This makes the entire Alter Aeon mainland around 30 miles in diameter.

We have entire mountain ranges, jungles, swamps, other cities, and the shores of two oceans on the mainland. All within 15 miles of the central city of Ralnoth. Starting to see the picture?

A more reasonable continent size is on the order of 500-1000 miles. Even for a 500 mile wide continent, the scale of Ralnoth would imply walking through a minimum of 7500 rooms to get from one side to the other. This is probably not reasonable from a gameplay standpoint, so we need to find a different approach.

The simplest and easiest is to simply define cities to be much larger than they are. If we declare Ralnoth to be ten miles across instead of 1, we end up with a much more reasonable room count. But in that case, even the smallest house represents half a square mile of land area.

A better approach seems to be to change the size of roads and paths, such that the desired distances can be achieved. This kills the dull/boring wilderness areas and gets people out into the world to do something interesting.

I think there's a couple of different ways to handle this. One is to have different sized rooms and render them as best you can. Perhaps using terrain or other flags you can automatically decide what rooms are what size.

But it seems to me that a far better and easier way is to separate large and small sized zones from each other. When you leave one, you end up in the other with a different set of maps. For example, leaving a town shows the town zooming to a small size relative to the forest you're walking in. So many games have done this in the past, that it's a trivially obvious feature. It also happens to be a very good candidate for my overall mapping problems.

I'll let you all know if it works out.

More PR

Over time, you tend to run out of things to say on blogs, and I think I'm hitting that wall. It's not so much that you run out of stuff entirely, it's that you tend to repeat the same things over and over.

I'm rapidly finding out that running the game as a business very much falls into this category. You're never done with PR, web page improvements, enhancements to the newbie experience, game additions, etc, but there's only so many ways you can say "I worked on the web pages today." I suppose such is the drudgery associated with a business.

This pretty well explains what I've got to look forward for the next few weeks. I've found some new avenues to pursue regarding getting traffic to the site, and as usual there are articles to post and other PR work to be done. This is all slowly paying off, but it's definitely slow - I suppose like guitar, if everyone could learn it in two weeks, it wouldn't be impressive. The PR:4 thing is a real boost however, in that it shows that it's actually possible to improve things. I hope to hit PR:5 by the end of the year, but I suspect we're a long way away from that.

I just got more advertising set up for Alter Aeon on Top Mud Sites, though I suspect it will drive the same type of people as the Mud Connector. This market for players is really limited, but in the short term it's going to have to be our bread and butter.

(Another neat web site I stumbled across is Mud Stats, which collects periodic statistics from games and sorts them. Stats collection appears to be every few hours, so it's pretty up to date.)

On a somewhat depressing note, I shut off the Google ads completely and the overall newbie load does not appear to have changed by any noticeable amount. It's only been a few days so far and the stats may yet be bogus, but if it's really that hard to pull in true newbies the future of the game could be very questionable. I need to look at this a lot harder I suspect.

Setting Priorities in a Business

Something I need to constantly remind myself about is prioritization. There's only one of me, and there's way more things that need to be done than I have time for. One has to prioritize. You're not choosing between things that are right and things that are wrong; you're optimizing to get the most out of your time.

Here's what I'd consider a rough priority list, not necessarily in any order:

- Improve the Mud Connector banner ad to drive more traffic
- Improve the main AA pages - add a couple of images, some player quotes
- Release another client version with true non-mudder additions
- Improve level 5-29 experience, especially in groups

Some of these are easier than others, but of all four of these, I note that none of them are on my board. Not that the things on my board aren't important, but somehow, these irritating bottlenecks have managed to avoid being written there.

How exactly do the four most important bottlenecks not get placed on the todo list? There are multiple reasons; first and foremost, these bottlenecks are continuous, persistent things. They almost always require improvement, and focusing on them exclusively would mean nothing else gets done.

It could also be that they are too obvious - of course that needs to be done! Or it could simply be that I lack the incentive to work on them. I find incentive to be in short supply these days.

With the influx of newbies from the Mud Connector and other sites, things appear to be going reasonably well. But as I've told others, the Mud Connector is a limited market that will saturate in just a few short years, if not sooner. We have to work on other things as well.

Improving Google PageRank

In a totally unexpected twist of fate, the main Alter Aeon web pages breached PR:4 over the weekend. I was actually not expecting this at all; it's only been 3 months since we went from 2 to 3, and I figured we were well below the required popularity for this jump. If this increase is anything like the last one, our traffic and the quality of our web hits should increase substantially. In fact I only noticed it because the web hits were abnormally high today.

This leaves the very open question of how to get to PR:5 though. I haven't submitted links or done link propaganda in a while, mostly because I was running low on quality sites to hook up to. I'm pretty sure getting PR:5 is going to be a lot harder than 4.

Also related to this, I've been setting up ad campaigns at a few other sites. These should be coming on-line in the next few days.

All this advertising is actually paying off (though in a limited, short term kind of way. More on that later.) The rate of verified, saved unique newbies has doubled since November; the actual number of logins has tripled. Pretty much all of the stats agree on the relative increases, so I know that I'm seeing something legitimate. How long it will take for that to push up the average userload is an open question however.

One unfortunate aspect is that these logins are fairly expensive. I'm not tremendously over budget with ads, but I'm not breaking even either. I need the userload (and associated purchases) to increase between 50 and 100% in the next few months for things to work out.

Now, the short term aspect of things: nearly all of the new advertising is on mud lists and other mudding related sites. This is a problem, as the total pool of mudders is small, and the pool size is shrinking. I saw a statistic somewhere that the total number of mudders is only on the order of a hundred thousand; if things go well this advertising market will saturate quickly.

The only real answer to this that I've been able to come up with is to focus more on the custom AA client. To get a million accounts, I'll need to pull from the global pool of ordinary, non-mudding gamers. In order to do that, I need to get away from text-only interfaces and complex clients.

There's enough web work to keep me busy for a while, and I have to get the game's taxes done this week, so I won't be improving the client for a while. But it's becoming clear that the client is very, very high priority.

Clients and Newbies

I recently released a new client update for Alter Aeon, one that includes (but is not limited to) the following cool changes:

- vastly upgraded automap
- vote menu
- 'last command select'
- various settings now save
- function key alias mapping

This really is a big step forward in the evolution of the client, and I've received a lot of compliments on it. Unfortunately, there is a problem with this client release, and it all goes back to the problem of newbie retention. But before we go into that, here's some background on the current state of newbies on the game.

-----

There appears to be three primary types of new player right now:

1) Sighted players from mudlists, who generally already have a client. These players usually don't download the custom client, and if they did they probably would go back to their own client anyway.

2) Blind players who use blind clients. They generally don't use the AA client, as it has crap for blind player support.

3) True new players who probably have never mudded before. These people are the long-term future, as the number of mudlist players is shrinking and blind players will eventually get their eyes fixed. This is also by far the largest market to tap. You don't compete with World of Warcraft unless you're hitting up ordinary sighted people.

The mudlist players will pretty much do their own thing. There's a limit to how much you can do with them, as they have their own opinions already. Many are unrecoverable, as they have been damaged by some other mud.

Blind players we seem to be doing reasonably well with. I have no complaints here, other than making the AA client work really well with readers would probably help a good amount.

The third category, by far the biggest market, is the problem. Since they have no prior mudding experience, odds are very good they downloaded the client, which shows up easily in my stats. I can also track logins based on web page hits. If this class of player is sticking around, I'll see it by looking for newbie players using the client.

This is exactly what I don't see. I see the expected players log in with the client, just as they should. There's a large initial dropout rate, but a good percentage of them level and play for a while. After that they all disappear. We're not keeping people entertained.

I suspect what's going on is they play for a while, run out of stuff to do or don't see the point, and bail. That pretty much describes my first mudding experiences; I got a low level character and basically just wandered around looking at stuff. None of the text meant anything in particular to me, and I would wander ridiculous places because I didn't know where to go or what to do. I didn't even know what the point of the game was.

I clearly need to add a lot more statistics tracking and try to see where the dropoffs are occuring - what level ranges, number of logins, etc. With this information in hand we can improve the introductory areas; but so far, my initial numbers indicate that the dropoffs happen for the newbie areas that are well tested and considered in good shape. So what is really going on?

-----

The final piece of the puzzle revolves around the massively improved automap function in the new client. I tried really hard to play with the mouse for a while, and it worked as well as could be expected. Unfortunately, when using and concentrating on exploring using the map, the entire text window (which contains everything that's important) disappears. Not from the client, but from your mind. It simply isn't as important as the automap. Looking back at it takes effort.

So say you're exploring with the map. You see unexplored spots on the map, you know you can go that way, and you click the button to go there. Nothing happens. You click the button again - you just want to go explore that part of the map - and nothing happens again. How irritating.

Nothing happens because you're fighting. But unless you take your eyes off the map and look back to the main window, you don't notice it. You just get irritated that you didn't move when you clicked the button. And all the scrolling crap in the main window, highlighted and all, really doesn't mean anything to you.

I've got a few things in the works to combat this, including audio sounds for fighting, changing the buttons in combat, and changing the area description to list various positions such as "Combat!", sleeping, resting, etc. That will have to wait until next week though, as I've got a lot of web work to get caught up on as well.

It's definitely a good problem to chew on.

Statistics can lie

Today's topic is the Alter Aeon "asshole" detector. We've had code in the game for years that tries to do a rough estimation of how big an asshole people are, and after multiple years of tweaks and updates, we have something that produces pretty valid results that correlate spectacularly with bad behavior.

The problem is that it correlates with the wrong bad behavior.

Take a look at the following asshole numbers:

10.249 Demon
-1.848 Cow
-6.941 Woem

In this example, Woem is a very well-liked socialite, and is known for being a nice, helpful person. At the other extreme is Demon, who currently holds the top seven slots on the all-time asshole list. As of this writing, he has no competitors for top slot.

However, Cow is the real problem here. This guy is a real asshole, and is extremely discriminatory toward blind players (and other groups.) I have considered several times explicitly flagging him as an asshole. Both fortunately and unfortunately, most of his bad behaviour happens on private or clan channels that I don't or cannot monitor - fortunately it stays away from the general population, unfortunately it festers and breeds hatred in his social circles.

After thinking about it for a while, the explanation appears to be related to spam. Demon, and his predecessor Gamlin before him, are both prolific and irritating spammers. They would both constantly pester people and spam channels with inane and generally low-brow conversation. Even I have ignored them for periods of time simply to stop the stupidity and prevent them from bothering me. On the other hand, I cannot recall ever having ignored Cow.

The overall point is that people feel free to ignore spam because it's meaningless, irritating, and usually undirected. On the other hand, ignoring the purveyor of a pointed, directed and possibly malicious attack seems like a bad idea. If I wouldn't do it, why would I expect anyone else to do so? Cow remains off the asshole list because people don't dare ignore him. He's too dangerous.

Somehow, I need to find a way to either counteract this, or allow people to mark or flag assholes. This is of course the age-old problem of automated board moderation, and I don't expect there to be an easy answer.

On the plus side, the current algorithm could simply be renamed the 'spammer factor' instead of the 'asshole factor'. At least then people wouldn't have misconceptions about what it meant.

Web 2.0

Begrudgingly, I am being dragged into the 21st century. First it was XML formatted output of various pieces of data; now it's XML RSS feeds.

That's right! Alter Aeon now has its first RSS feed on the changelog page:

Alter Aeon Changes and Updates Page

It just so happens that I have a player that's a web developer for a living, which is really nice - he helps me work through protocol and presentation issues that otherwise would take me quite a while to figure out. He tells me that I've not quite got the right idea for the descriptions in the current feed, but I should have that fixed in the next day or two.

I'm also planning on having the player boards in both XML and RSS formats by tomorrow, now that most of the infrastructure is in place. One of the big showstoppers for doing work on the boards (which are the logical place for an RSS feed anyway) was the lack of unique message IDs. As of yesterday, this is no longer an issue.

Honestly though, I'm not sure how much of this is relevant or useful. How many people will use the feeds? Will anyone other than my resident web guru bother to use the XML output?

Either way, Alter Aeon is rapidly heading into the world of new media, and it's really hard to tell where we're going to make the most gain. An excellent example of this is my recent experiment with Twitter.

A couple of weeks ago, I set up a Twitter just for the hell of it and linked it up to the main web pages. I've been using it to just drop periodic status reports about what I'm working on, and hooked up the game to post reboot notifications there. In virtually no time, I have 8 followers there, while this blog currently has only one, despite being active for months. Additionally, I've received quite a few web hits from new people through Twitter, also more than from here.

You never know what's going to work, and just to make things complicated, things work differently for different numbers of users. As the game grows, I'll have to constantly be adding and reorganizing. At least it'll be fun.