The Mob Factory - Alter Aeon MUD

Alter Aeon 17th Anniversary

2012-01-10T10:35:00.000-08:00

As of this weekend, it's been 17 years since I started on Alter Aeon. It all began with:

#include "stdio.h"

void main() {
}

When I started, I remembered so little C that I had to go look up what a structure was and how to use it. The game server code has since then landed me two good jobs and served as my final project for my engineering degree.

We're up to over three hundred thousand lines of source code now, with another twenty or thirty thousand lines of help files, faqs, rules, and other information. It's sometimes helpful to step back and see how far things have come.

This weekend, in celebration, we'll be having one of the rare scripted RP events that I occasionally do. These events are time consuming, with a lot of prep work and hassle trying to manage and keep everything working well, but they are hugely popular with the players. This time we have a storyline with a fairly plausible "end of the world as we know it" theme, and with any luck it'll be as successful as our 15th anniversary was a couple years ago.

Thanks to all the players who have contributed and help make Alter Aeon great over the years. See you all there!

-dentin

Year End Event at Alter Aeon

2011-12-13T08:30:00.000-08:00

We'd like to welcome everyone to the year-end celebration at Alter Aeon!

Starting on the 21st of December and going through new years eve, weplan to have a number of things going on:

The release of a new low level area near Indira

As part of our ongoing efforts to give level 8-12 players more questsand areas to explore, we'll be opening a brand new area north of theOld Indira Forest on the island of Kordan.
A major update to the troll caves on Archais

Originally created over 15 years ago, the troll caves were recentlytaken offline and given a major makeover. We'll be officially openingthe updated area, which should now be suitable for levels 24-30.
The release of a new high level stone giant area west of Finspang

This area, created by the original builder of the Undead City of Jo'Kerin,shows a different side of stone giants. If you're only familiar with the giants that reside in the Ash Mountains, you'll be surprised.
An object creation contest, open to everyone (this is currentlyrunning and submissions will close on Dec 23rd)
Daily gifts will be given out to everyone who logs in!
Several different minor contests and activities similar to the famousHalloween Pumpkin Cannon

We'll also be running sales on various credit purchases in game ifyou're into that sort of thing.

I'll post a more detailed schedule closer to the 21st. We hopeto see you there!

Playerbase and Userload

2011-11-01T08:43:00.000-07:00

When it comes to growing a playerbase, I've become more convinced than ever that it's got to be a staged process unless you have a LOT of money to blow on it. Having a lot of money is in fact how a lot of big MMOs handle growth - when they officially open, they basically go to full capacity overnight. This means that they can focus all of their development effort on one specific expected player load, and don't have to worry about nursing a small user base through the various stages to become a large user base.

This whole staged growth process has become a lot more apparent to me over the last couple of years:

When the player base is very small, it attracts a certain class of isolationist explorer player, one that doesn't need much in terms of a help system, documentation, or maps.
A bit larger and you start to get power levelers that like to compete with each other for in-game prestige.
Larger still and you start to get quasi-social players, players who like to group with others and help out. They don't show up earlier because explorers don't like to group, but with power levelers there's someone to group with and someone to help. This stage is an easy place to stall at, because these quasi-social players do not have the thickest hides and are less competitive than the power levelers; if they are abused by the power levelers, they will simply leave.

Power levelers tend to form small cliques with these quasi-social players, and then drive off all other quasi-social players not in their clique. This appears to happen because the power levelers in one clique, competing against those in another clique, try to get an advantage by driving off the other clique's support staff.

If restrictions, rules, and code are not put in place to protect them, the quasi-social players will never reach critical mass and will cycle out as fast as they cycle in.
The next stage brings in true socialites, players that typically gain levels only as a side effect of being in a group that is running experience while they chat.

True socialites are another huge ratsnest of problems. They tend to be drama queens or drama magnets, and are as capable of stirring up political *CENSORED*storms as they are of keeping other players interested and happy. There isn't a lot that can be done about this, other than to shutdown flamewars and ensure that rumors about admin 'unfairness' are killed immediately.

True socialites are heavily looked down upon by the explorer and power leveler communities, and they must be given substantial protection from abuse. Unfortunately, socialites can tolerate a lot of abuse - unfortunate because when they take abuse, they dish it back out tenfold in the form of bitching to other players. One sufficiently pissed off socialite that isn't immediately shut down can crater the happiness and opinions of two dozen other players.
The last stage that I have familiarity with is the 'true newbie' stage. This is where you get true newbies coming in, and your game has progressed far enough that true newbies are actually able to make some forward progress.

True newbies are a huge problem. From a technical standpoint, they are generally completely ignorant of the game style, and the newbie areas must be very well built to retain even a fraction of them. This category also appears to contain the largest percentage of 'low functioning' individuals - I do not mean that as an insult, rather an observation. Not everyone has the mental capacity to be an explorer or apower leveler.

These new players must be afforded additional protections that even the socialites did not require. I'm still workingout the details of a lot of this, but a good chunk of it amounts to protecting these players from themselves.

These are just the social problems. There are also scaling issues, each of which presents a 'critical mass' hurdle that must be passed. Certain areas may require a minimum number of players to be handled; assembling a group of that many players may be impossible below a certain user load. In the case of Alter Aeon, many of the automatic control systems rely on statistical data to function correctly. With few players, the lag time on getting statistically relevant data may be literally months.

This kind of lag time really hinders the ability of a game to make quick andeffective updates to increase retention. If you have a thousand new character creations per day, you can pretty quickly determine if a change is an improvement or not. If you have one new character creationper day, it becomes very difficult to determine if you're doing the right thing. I suspect this is at least part of the reason that MMOs take out funding in order to start big and improve the game quickly.

I think at Alter Aeon, we're past a lot of these initial hurdles, and could probablyreboot the game from scratch pretty quickly; once you get the various protectionsin place, they remain largely functional even though they fall into disrepair at higher userloads.

That said, I know there are bigger, nastier hurdles ahead of us. I just don't know what they are (yet.)

Halloween 2011 Events!

2011-10-26T08:41:00.001-07:00

If you like vampires, mummies, demons and other things that go bump in the night...

Stock up on supplies and get ready for a fight.

Come see us on October twenty-ninth, it all starts at midnight.

This friday night/saturday morning at midnight, a new area will be opening in the land of Alter Aeon. This place is known as the nightmare plane - little is known of it as yet, but if the name is any hint it sounds terrifying.

This new high level area, months in the making, consists of nearly 350 rooms, over 150 beasties and a host of new fame and fortunes waiting to be found. Over a half a dozen new quests lines are available to explore.

All day sunday, we will be running arena and other events every few hours to give everyone a chance to participate and say hello. We'll have novelty items and prizes for everyone.

On sunday night/monday morning at midnight, an invasion will begin, with incursions all day on Halloween. There will be prizes for all levels outside of the new player zones.

New this year is a special quest zone to help stop the invasion and get a permanent deed added to your character. This zone is set up to allow groups to progress at their own pace without interference from other players or groups that may also be trying to stop the invasion.

We hope to see you there!

wxWidgets keyboard handling

2011-09-26T19:25:00.000-07:00

The cross platform code that isn't.

A couple of weeks ago, another piece of wxWidgets infrastructure in the Alter Aeon client was replaced with custom code. This time, it was the bulk of the keyboard handling code that fell in battle.

In theory, the wxWidgets keyPressEvent is where you should trap out various key combinations; things like 'a', the escape key, and 'control-c' pairs. Certainly under linux, nearly all of these worked correctly, and the ones that didn't were obscure and not really worth hunting down. When I first ported to Win32, all that changed.

In Win32 builds, a lot of keys were not handled by the key press event. You'd press the key combination, and nothing would happen. It was like the operating system was trapping out the key combination and never bothering to pass it up the stack. As it turns out, that's pretty much exactly what was happening.

I did eventually get the Win32 builds to work by intercepting a handful of keys at the keyDownEvent and keyUpEvent layers. When I finally found these, it was hugely helpful; in the end, I trapped on the order of 30 key combinations to do away with things like annoying system beeps and idiotic behavior of the default keystrokes, in addition to handling our own special control combinations.

Enter Mac OSX. Enter a whole new raft of keyboard weirdness. I hacked on this for about an hour, and quickly realized that I was on the path to madness. The code was becoming a rat's nest of ifdefs with key combinations trapped out in multiple different layers in different operating systems.

About the only thing that could be called consistent between any of the operating systems was that the keyDownEvent and keyUpEvent were always reliable. The solution then seemed obvious: move everything down into the keyDownEvent, and ignore everything else. Intercept the keyboard control -before- wxWidgets could do anything stupid with it.

Keyboard control now works consistently and reliably on all three platforms.

2011 Cleric Class Update

2011-09-19T13:43:00.000-07:00

The 2011 Alter Aeon "Cleric Update" is now live! This update contains a lot of changes to improve traditional cleric spells, add a new mode of casting for mages, and clean up other spells and skills that have traditionally not been as awesome as they could be. Here's a list of the most major changes:

- Mages now have the ability to 'channelcast' (ccast) certain elemental spells in combat. Channelcasting takes longer than regular casting, but is interruptible and costs substantially less mana. This feature allows mages to become a true 'blaster' class without compromising healing mana.

The channel casting skills are 'fire focusing', 'ice focusing', 'lightning focusing' and 'crystal focusin'. The fire plane is easiest to reach, and hence it's the lowest level and easiest to channel. The crystal plane is much harder to reach and only high level mages will be able to channel from it.

- Added a necromancer spell 'bone dragon', which allows you to fly around over the landscape.

- Ice imprison and crystal prison have been updated.

- Ward good and ward evil are now more powerful.

- The charm spell has been updated to make it easier to land and to use control points similar to controlled necromancer minions.

- The peace spell has been improved.

- A level 19 curse, 'overconfidence', has been added.
- A level 19 spell, 'hold undead', has been added.
- A level 28 spell, 'sacred touch', has been added.
- A level 29 spell, 'solace', has been added.

As always, you can use the 'spell find' commands to find the teachers or trainers for new spells and skills.

For those of you who don't know anything about us, Alter Aeon is a multiplayer text-based game with a lot of features and settings to help make it blind-friendly. Over half our playerbase is blind or visually impaired, and we have blind builders and staff helping to expand and improve the game.

Everyone is welcome to play, so if you're new to the game feel free to stop by and check us out. For more information and soundpack downloads, see our web site at:

http://www.alteraeon.com

Happy hunting!

2011-09-09T13:06:00.000-07:00

I'd like to announce the release of the Alter Aeon client version 1.089, which makes this the first official 'non-beta-numbered' release. An awful lot of updates and effort went into this revision. Here's a short list of the big feature updates:

- Full, non-beta MacOSX support, including versions of MacOSX from 10.5 forward. Unfortunately, we don't support the older PPC macs, just newer Intel based ones.

- We've submitted the Mac version of the client to the Mac App Store, and hopefully you'll be able to get it there for free in the next few days!

- The graphical rendering system has been pretty much completely gutted and rewritten. This makes the client faster and more consistent between different versions of windows. This got rid of a lot of bugs with different service packs.

- The keyboard handling has been rewritten to use low level keyboard codes for pretty much everything. This also gets rid of a lot of service pack bugs that we could never track down before.

- Lots of performance and memory optimizations, to make things run faster and more smoothly

- You can now change the font on buttons and the map

In a lot of ways, this was a sort of 'maintenance' release, where we weren't trying to add features so much as make the existing features work as smoothly and correctly as we can.

Of course, this means the next release will probably start adding features again. We have a lot of neat ideas queued up, so expect to start seeing some of them here in the next few months. Until then, you can download the new Alter Aeon 1.089 client version at:

http://www.alteraeon.com/AlterAeon.exe

Happy hunting!

We're famous! (Again!)

2011-07-13T08:04:00.000-07:00

If you've ever tried to get attention in the gaming world, you know how well-neigh impossible it is. There are literally tens of thousands of game developers of every budget category, from the smallest single-person outfits to kings like Blizzard and CCP. Even getting someone to review your game can sometimes be a lost cause.

With that as a backdrop, Alter Aeon this weekend got a spontaneous review on the GamingHUD web site. This is a pretty big website that reviews a lot of mainstream games. For AA to even be seen by fish of this size is pretty amazing.

The review also isn't some slapdash piece of filler material. The reviewer spent a lot of time on the game and even emailed me for additional information. The final article came out very positive and very long.

The link is:

Alter Aeon MUD - A World of Infinite Possibilities

Feel free to check it out and maybe drop a thank you to the author for their hard work.

wxWidgets GTK font rendering

2011-07-09T13:50:00.000-07:00

In my previous post, I managed to fix the bugs in wxDC::DrawPoint() by using my own custom drawing class. Unfortunately, a lot of the places I where I used DrawPoint were also places where I needed to draw text, and in order to draw text I needed a wxDC. No problem, I'll just draw the text using a temporary wxMemoryDC on the bitmap, and to make sure there's no clobbering problems I'll make sure that I don't intermingle direct drawing scope with the DC object scope.

This appeared to work, except for the scrolling/updating windows. For some reason, even though there was a Clear() call before the font rendering, the windows would never clear. If I destroyed and recreated the bitmap every time, it worked fine but was very slow. If I cleared after drawing the text, the clear worked. If I cleared before drawing the text, the clear did not work.

Eventually I figured out the reason:

Under wxGTK, wxDC drawing and rendering are done to a separate bitmap/bitmap layer that is permanently attached to the real bitmap. When font data is drawn using wxDC::DrawText(), the text is drawn to the hidden layer, then the hidden layer is blitted in its entirety on top of the real bitmap. The end result is that anything you do prior to constructing the DC and rendering text with that DC is overwritten/deleted when the DC destructs.

Just how the hell does this make any sense? Nevermind, forget I asked. On the plus side, this explains why full screen font rendering is so slow in wxGTK. I never could figure that part of it out.

For roughly a day, I was utterly at a loss when faced with this problem. Switch back to the old code and lose the MacOS X platform; stay with the new code and lose wxGTK (and possibly other platforms, I only ever tested it on GTK.) I couldn't even think of a way to work around it.

Eventually, a possible solution presented itself: add font rendering to my custom bitmap class. I wasn't real clear on how to do this at first, but the key breakthrough came when I realized I could just use a cheap glyph rendering scheme. Use wxDC to draw each of the letters I needed (ascii chars 32 through 126) into tiny, clean bitmaps, then use a modified alpha channel copy routine to draw them to my custom bitmaps.

I'm proud to say that I now have proper text rendering and graphical drawing primitives on all three platforms. And to think that all I needed to do was rewrite the entire wxDC rendering system to do it!

I should have just done it in the first place, as I recommended to myself in a past life. Sometimes our older selves are no wiser than we are in youth.

wxDC DrawPoint broken under wxMAC

2011-07-09T13:17:00.000-07:00

To follow up on my previous post, I had written my own routines for handling alpha channel support under wxWidgets, and finally everything seemed to be working properly. Both Win32 and Linux/GTK builds seemed to work exactly as expected using my alpha channel bitmaps where I needed them. For most other places, I still used wxDC primitives, as wxDC direct drawing seemed to be a bit faster than going through a bitmap/blit interface, and I still needed to use wxDC to render fonts.

I figured porting to MacOS X would be a snap, and for the most part it wasn't too bad. There were some issues with Repaint() not working the same, but adding a few explicit paint calls in the right place fixed that up.

However, something was wrong with some of the graphics in the various windows. The sky bar, normally with lots of little stars in it, still had stars in it, but instead of one pixel there were two: one at offset (0, 0), and one at offset (1, 1). I also noticed 'fuzz' on the corners of various windows and buttons, and in a handful of other locations.

Long story short, wxDC::DrawPoint() draws two pixels under wxMAC. Not one, but two. I found a couple bug reports regarding this from a few years ago, where it was basically acknowledged as a "verified bug", and the ticket was never closed. Advice was "these routines are slow and shouldn't be used for high performance drawing". Thanks guys.

I have some mighty fine choice words to say to the developers regarding this, but I'll try to keep this post on topic.

If something as fundamental as DrawPoint() is malfunctioning on a major development platform, I figured it would probably be a good idea to transition away from the classes that implement it in favor of my own drawing routines. So, I started using my bitmap class, which just happens to have a DrawPixel() function that works properly.

As expected, this fixed the drawing problems on all three platforms. But alas, using my bitmap class exposed another set of very nasty wx bugs, which I'll discuss in the next post.

wxwidgets has no alpha channel

2011-07-09T12:56:00.000-07:00

A few months after I ported the Alter Aeon client to the wxWidgets toolkit, I decided I wanted to add alpha overlay support to the automap and main window.

Encouragingly enough, this appeared to be trivially supported: wxColor included an alpha value, bitmaps could be defined as having an alpha channel, etc. Pretty much everything looked good to go, so I started experimenting with it.

Alas, it was not to be. It turns out that there are precisely three places where the alpha channel is used:

1) loading a PNG from PNG data that has an alpha channel,
2) drawing a bitmap containing alpha channel data using wxDC::DrawBitmap, and
3) wxDC::DrawText, which politely draws text on top of the underlying pixels.

For all other locations, there simply should have been this assert:

wxASSERT("Alpha channel is stubbed here and works on precisely zero platforms ever, ha ha, the joke is on you")

After upgrading to wx 2.9 and a pile of scouting around, I came across wx/rawbmp.h, which has some direct access functions that allow access to the alpha channel. With this, I managed to get alpha channel working - but there were other problems with 2.9, so I downgraded back to stable, 2.8.12.

The alpha channel code that worked under 2.9 works properly under wx 2.8.12 in wxMAC and wxGTK, but apparently isn't implemented under Win32, which happens to be my main development platform.

Rather than bash my skull repeatedly against the wall, I did what any sane developer would do: throw out the broken toolkit module, and write one that works. In the end, I ended up with a wxBitmap derived class that has drawing functions that actually work properly and support alpha channel drawing when I need them to.

However, there's a problem with this as well, which I'll detail in a later post.

Future Plans - Clerics

2011-07-01T08:44:00.000-07:00

The cleric class has long languished - not because it was useless, but because until recently there wasn't a lot of reason to have a really high cleric level. Prior to the 2010 christmas expansion, there weren't a lot of cleric spells or skills above level 30; and many cleric spells didn't scale in power as you gained levels, like mage and necromancer spells do.

As a result, cleric has been a useful, powerful class - but not something you want to be your primary. Our future update to cleric aims to change that.

The biggest updates to the class aren't likely to be new spells and skills. Rather, we want to fix existing spells and skills that aren't up to snuff with the rest of the class.

Take for example the 'peace' spell. This could be a very powerful, useful spell - if only it worked differently. We're currently imagining room effects, duration effects, and a handful of other options to improve this.

Another spell that's long been on the todo list is charm. The current version of charm has basically been dented into the ground to prevent charm armies. With this update, we're planning to switch it to a control point system similar to necromancers. This should make charm a lot more useful while at the same time limiting "charmy" problems.

Other things that could use similar kinds of improvement are turn undead, the ward spells, curses, and the monitor skill.

All this said, we do plan to add more spells and skills. So far these hit most of the major groups - character buffs and enhancement, a possible brew skill, some new curses, new damage spells, and a new undead spell.

The schedule for this is some time in august, about a month after the thief updates of the previous post. After this, we still have a ton of things to work on, including elemental channeling for mages, god code, and a couple of new character classes.

Future Plans - Thieves

2011-06-23T07:33:00.000-07:00

Now that level 35 is installed and running in the game, I figure it's probably a good idea to let everyone know about the game's direction and where we're headed. Things aren't going to be static; there's a lot of really neat stuff planned out for this year.

The next major update is scheduled for some time around mid to end of July. The focus of this update will be the Thief class, which is currently the least played class in terms of high levels, and the class with the fewest skills.

At a minimum, the thief update will include an entire tree for shadow skills. I'm not a fan of traditional ninja skills though, so don't expect Naruto style effects. The basis for the shadow skills will be a type of channeling/synergy with the shadow plane, which has already made itself known with the Guildmaster Assassin in Jo'Kerin.

Also on the high priority list are a couple of miscellaneous skills ('untanking' in group combat, room analysis out of combat), and updates to lock picking to make it more incremental and less hit or miss.

For medium priority stuff that might get implemented, we have disguise skills, bribe improvements, and haggling (possibly for bulk purchases.) My guess is that at least some of this will get into the final build.

For low priority, we've been mulling over the idea of distraction skills, but the effects are pretty ill defined right now. We also really need to take a look at the way poison damage is done, to try to make poisons function in a reasonable way. It's pretty unlikely that either of these will be done for the update.

That concludes things for the proposed thief update. Again, we hope to have it out prior to August. I think it will address a lot of the shortcomings of the thief class, without necessarily making thief into another fighter class with differently named skills.

Coming up next - clerics get some love too.

Alter Aeon Area Openings

2011-04-09T16:33:00.000-07:00

Draak and Shadowfax have been working for years on the Naginag Combine, and they've just completed another major expansion to it. Here is the official announcement, copied from board 8 in-game, from Shadowfax.

---

I am proud to announce the opening of the city of West Naginag and its sister area, the village of Ooahu. Usually we open areas with little fanfare, but these areas deserve special mention for a number of reasons.

Just the sheer amount of effort and time that has been put into this project is remarkable. Ten years ago, Draak and I came up the concept of the Naginag Combine. The idea was to build a collection of interrelated areas that were all part of the same empire. We showed Dentin our plans and released the first Combine area in 2002, what is now Draj and Zin. In response to the positive feedback about that area, we scheduled more Combine areas to build. I drew a picture of West Naginag during the summer of 2003. Now, after nearly eight years, it's finally finished.

West Naginag and Ooahu are a lynchpin that tie all of the mainland Combine areas together. We left it for last, but it also took so long to make because I wanted it to be perfect. Whether you want to immerse yourself in the lore, play through engaging quests, or just get some fame, eq or good xp, these areas should have something for everyone.

Once again we push the code to the limit, introducing consumables with custom spells, rechargable wands, mobs that make full use of necromancer abilities, "wearable" objects for your inventory, epic quests that unlock the secrets of the region, and a host of other fun little goodies for your enjoyment.

If you do it more than once, write a script...

2011-02-25T08:47:00.000-08:00

There's a saying often used by Unix System Administrators: if you're going to do it more than once, write code to do it for you. For the last few days, I've been writing code to handle clan equipment automatically, so I don't have to be involved.

This has been a very time-consuming process, so much so that you might be tempted to ask, "if it's going to take so long, why not just do it by hand?" And indeed, that's tempting.

But one of the things that has occurred to me writing this code is that clan equipment is simply a complex process. Every single line of code I've written reflects some check, some detail that I would have had to remember and check manually. Each of these details is important. And the odds of me remembering them all when I do it by hand are near zero.

In short, while doing it by hand would definitely be faster in the short term, it's basically guaranteed to be wrong. And I've got direct proof of this while I'm looking at the existing clan items - they're spread out across the vnum ranges completely at random, built and set up in different ways by different builders, with some of them violating various constraints and some not. It's a complete mess.

That is what 15 years of doing it manually looks like, and that's why I'm not going to allow it to be done manually anymore. I am replacing myself with a (not so short) set of scripts. I'm ok with that, because those scripts will do a better job than I would have.

Scaling

2011-01-09T16:39:00.001-08:00

When we released the necromancer expansion back in November, I expected a pretty large spike of new players. I figured we'd get a bunch of new people from the announcement, but also a lot of high levels would want to try out the new class from scratch to see how it worked.

And new players we got; perhaps four times as many as usual, which again was about what I expected. What I didn't expect was that we would be nearly incapable of handling them in terms of areas and content. There wasn't really any fighting over equipment and quests, but from time to time it seemed newbies literally had to queue up to get their turn at a particular quest item.

This got me thinking about scaling. If we can't effectively handle four times the standard newbie load, we'll be limited to a player base less than four times the size of our current one. And it's not just newbie areas; we have to think about it everywhere, from areas to exp thwacking to the who list to the the size of Ralnoth. We might not have five hundred people logged in right now, but even if we did the game probably couldn't handle them all.

Here are some things I think could help with that:

- Instancing. Instancing allows you to create private copies of areas for players, so that they don't interfere with each other. This is great for quests, in that each player or group can be on their own private copy of the quest, and don't need to worry about someone else getting through it first and taking the quest item. Judicious use of instancing can help eliminate quest bottlenecks, and it makes the world seem a lot bigger than it really is.

- Gold and experience thwacking. Right now, gold and experience are thwacked globally, so that if a mob is run too much the returns on it drop for everyone. This is fundamentally dependent on the number of players; a better way would be to put thwacking on individual players, so that the actions of one player don't break the game for someone else.

- Item maxload. Having limited load on items is another thing that's fundamentally dependent on the number of players. Once the player load rises to a certain level, a maxloaded or rarity-based item will simply never load again. Maxload and rarity effectively need to be removed to fix this.

- The who listings, and other display systems. Having a five hundred person who list would be ridiculous. Beyond a certain point, you pretty much have to switch to a query system instead of a global listing system.

Some of this stuff is already in transit or is being worked on; in particular, instancing was booted in earlier this evening and is being tested as we speak. Maxload for the most part was phased out last week.

It's a decent start. One bottleneck at a time...

Spells, skills, and class design

2010-12-30T18:58:00.000-08:00

One of the things that takes a lot of time is tweaking the spell and skill trees to make the classes more fun to play. The various factors I have to balance are a lot more restrictive than you might expect:

1) The spells and skills within each group, for example "mage fire spells", should have proper dependencies. Greater Fireball should probably be dependent at some level on 'basic fire magics'.

2) The spells and skills within each group, for example "mage fire spells", should be separated by similar level differences, to spread the group out across a level range. If there's too much clumping, there's dead zones where you don't get a new spell for a long time, then suddenly get a bunch followed by another dead zone.

3) Spells and skills for the entire class should be evenly distributed across the entire level range, again to limit dead zones and make sure players have something to learn at every level. Necromancer is a good example of how to do this; every three levels, you get 5-6 spells and skills, from level 1 up to about level 28. Mage is a good example of how not to do this; there's 6 spells between levels 2-4, 12 spells between levels 12-14, and 4 spells between level 26-28. Mage is currently very clumpy and needs more work.

4) Low level spells and skills should be useful and interesting. Having a spell like 'ventriloquate' below level 10 makes no sense at all; newbies will think it's actually useful (it's not) and waste practices on it. It's ok to put useless stuff at higher levels, because high level players are more likely to do research before wasting scarce practices on something.

5) Really high level spells have to actually be useful, even if it's a specialized use.

The above generally result in me spending a lot of time staring at various views of the spell lists for each class. You have to keep an eye on groupings across level ranges, while making sure you haven't done anything dumb to the dependency trees for each group, and making sure you don't move useless things into the low level ranges.

And even though it may not seem that way, the above are actually really important. It seems to give you more to do, and you know that you get important, useful stuff even at low levels. I've certainly noticed a difference with my characters.

Christmas Expansion - Update

2010-12-25T12:32:00.001-08:00

We finally got everything done and installed, and it went off pretty easy. The biggest hitches were minor display bugs in explorer points, with a few minor typos and what not elsewhere.

One of the things that surprised me was the time breakdown for the various spells and skills. We only added 12 of them this time; here's a rough time estimate for each.

Level 25 mage skill 'melt' - approximately 6 hours. This skill was in multiple pieces, as it can operate on multiple targets. Not much debugging time required.

Level 27 mage skill 'spell lore' - approximately 1 hour. This was a very easy hook into the spellcasting code.

Level 6 cleric spell 'faith shield' - approximately 4 hours, most of it testing and design, trying to figure out how to not break anything.

Level 31 cleric spell 'breath of life' - approximately 5 hours. Required several debug passes to get the math right, largely because I wrote the core of it while I was very tired.

Level 33 cleric spell 'area heal' - approximately 2 hours, because this reused a lot of well-done code from 'area refresh'.

Level 34 cleric spell 'astral bridge' - approximately 16 hours. The spell itself only took about two hours, but before I could implement it I had to completely rework the waypoint code. Refactoring and updating the old code took the bulk of the time, and it broke waypoints for a lot of players.

Level 32 cleric spell 'group waypoint' - approximately 2 hours, because the astral bridge and other waypoint code was already in place.

Level 8 thief skill 'listen' - approximately 4 hours.

Level 29 thief skill 'fast talking' - approximately 3 hours, had to come back and extend its use into other thief skills that didn't have the facility before.

Level 26 warrior skill 'cleave' - approximately 5 hours. Ran into an irritating bug where cleave would cause a death which would cause an autocleave which could cause a death which could cause an autocleave...

Level 32 warrior skill 'whirlwind' - approximately 3 hours. The event handler for this was very straightforward.

Level 8 necromancer spell 'bone blade' - approximately 2 hours.

Explorer points - about 10 hours. This had a lot of hooks for display and interfacing, which usually takes a lot of time. Multiple debug passes.

Various achievements - about ten minutes each when done in groups.

There was also a lot of infrastructure and other work that went on to enable all this; between bug fixes, infrastructure, and design, the times above are perhaps a third of the total.

Alter Aeon Christmas Event

2010-12-21T10:01:00.000-08:00

Every year for Christmas (and for a bunch of other holidays), we do something special. Usually this amounts to in-game events to open new areas, or for special prizes, things of that nature. This year, in addition to the usual things, we'll also be adding something else: a bunch of new code.

For each of the five classes, we'll be adding a few new spells and/or skills. A lot of this stuff is high level, but it's also focused more strongly in some classes than others. Cleric is probably the class that benefits the most, but it's also been the class with the least amount of scaling. Necromancer doesn't get much new stuff, but it does get a few critical reworks of existing spells and skills that didn't work out as designed.

Adding new spells and skills like this is always a hassle. Coming up with new stuff is hard, because it has to be useful, interesting, and above all preserve the physics/theme of the game. There's no point in just adding a bunch of lookalike damage spells that are successively more powerful.

There's also the problem of integrating new things into the existing spell and skill trees. One of the major things about this release is that there's been a lot of reworking of the spell and skill trees for the various classes. Thief, warrior, and cleric have all seen pretty significant changes to their skill groups, primarily to make space for the new additions.

There are a few other things I'll mention, such as new achievements, but since we're keeping the actual spells and skills under wraps until Christmas morning, I'll stop here.

Alter Aeon Necromancer Class

2010-11-03T08:11:00.000-07:00

There's been a lot of talk on this blog and the Alter Aeon Forums about a new Necromancer class. Official work on it started about a year and a half ago, and up until about three months ago pretty much everything that was done was under-the-covers structural stuff.

Once all the infrastructure was in place, I started hitting spells and skills really hard. In the last three months I've implemented about 50 new spells and skills, some with rather exotic (compared to other spells and skills) features.

And finally, two days ago, the first ever Alter Aeon class expansion was officially unveiled. Necromancer is now live on AA!

Some of the available spell and skill groups for necromancers involve:

- creating animated entities of various sorts
- raising your own undead
- summoning demons for fun and profit
- using dragon teeth as powerful spell components
- blood skills involving your own blood
- controlling undead and demons
- soulsteal and other spirit-based spells

As always, a full spell at skill list can be found on the Alter Aeon Spells and Skills pages.

One of the crowning features of the new class is the minion system, which allows high level necromancers to create and manage several minions at once.

The class plays very differently from any of the others, and is looking like a great addition to the game. There's definitely still some balancing issues remaining, but for now it's looking extremely solid. Further, it's downright fun for me to play. I wish I had more time to do so.

We're Famous!

2010-10-21T07:02:00.000-07:00

Ok, not entirely famous, but it's a start. We have our first reviewed and edited article on an external web site:

Mudding Communities Are Alive and Well in Alter Aeon

The site BrightHub is a large site with articles about nearly everything, and people who act as dedicated editors to make sure that articles pass a minimum sanity check before being posted.

This is important because articles like this can be used to bolster notability in Wikipedia, and get AA out there to a much larger audience. Stop by and take a look, and spread the word if you've got any friends that might be interested!

Necromancer Class Open Beta

2010-10-03T17:02:00.000-07:00

The necromancer class is officially in beta test on alteraeon.com, port 4000. There's basically no rules on this port, other than to respect others, and give testing priority over anything else. So if someone's trying to run a real test, don't screw with them. One additional note: pk balance is completely off, and I have no intention of fixing it until the mob balance is halfway sane. Don't submit bug reports having to do with pk balance issues.

Pretty much everything is implemented except for the Demonlore skill tree, and what I'd call four problem spells/skills:

Lvl 16 consumption
Lvl 16 bone wall - already have wall spells
Lvl 21 flesh wall - already have wall spells
Lvl 27 skeletal dragon - already have craploads of minions

Consumption was supposed to be some kind of corpse eating thing to recharge your undead, but so far with the way they're working out that doesn't make much sense. The wall spells are really problematic, as I have to come up with something very different from icewall for them to make sense. And for skeletal dragon, well, the last thing we need is an even more powerful minion.

The Demonlore tree is problematic because I can't really see any interesting way to make it different from the 'Raised Undead' skill tree. The both create various minions, using control and soulstones, and have the same kinds of skills. I really hesitate to just make a skill tree that's effectively a different mob type copy of some existing tree.

Beyond that, things appear to be going well. The class seems to be quite a bit too powerful for now, but at the same time all the testers are five-class level 33, so perhaps I'm seeing a side effect of that. I think in the long run, the only real way to get legitimate test data is to boot in the code and see what people do with it for real.

One thing I am really surprised about is just how terrible most people are at testing. I have one tester that typically sends me 20 messages overnight with comments and questions about the class; the remainder have yet to send me 20 questions total for the entire time the port has been open.

As a result of this, I probably need to rethink my beta testing strategy. Maybe the thing to do is to autoupdate everyone on login so that their levels come out in some mangled, pre-determined format; for example 32/27/22/17/12, with the classes picked at random. I think having everyone be 5x33 just leads to people seeing what it's like to have that many levels.

Potions and Herbs and Spells oh my

2010-09-14T06:25:00.000-07:00

After what feels like more than a decade, we've finally updated the system for brewing potions. The old system was pretty hard to deal with from a code standpoint, and didn't give builders a lot of options. From a player standpoint, the old system didn't really allow for invention or thinking about your potions.

The new system changes that by adding affinities for ingredients, where different spell components are more likely to brew particular spells or spell groups. Players get the ability to actually influence what comes out of the brew, as do builders who can set those affinities if they want.

The new code also uses a staged algorithm for the PRNG such that I can add and remove things chunks of the algorithm without causing major damage. We can also tweak the probabilities on specific brews and components now if necessary.

As with any change, there's been some complaining about this, but it's largely been well received. It helps that there's information about how the new system works; I updated the brewing article on the AA articles page with a bunch of new information. Here's the link:

The Art of Alchemy

People have managed to brew quite a few interesting things so far. You can find the list of public potions brews as the Alter Aeon Potion Recipes web page.

The accidental fanfic

2010-08-04T08:53:00.001-07:00

I've been working on the next stage of the newbie quests for the island of Kordan, and one of my major stumbling blocks has been explaining exactly why another stage exists. The general theme with this sort of thing is that there's a continuous storyline as you progress from one quest to another; you work your way deeper into the conspiracy to take over the world (or whatever), and ultimately emerge the hero.

The problem was, I didn't have any such story or conspiracy constructed, and wasn't feeling particularly inspired. So, I decided to try something new. I sat down and wrote some crap.

It turns out that my crap looks like a pretty decent, if dry, story. I accidentally created my first piece of fanfic!

I've posted it on the Alter Aeon Fan Fiction page and added a section for myself. The direct url is:

Plans and Portents - the Story of Qoorik

Miscellaneous

2010-06-25T11:08:00.000-07:00

It's been a long time since I updated here; I'd like to say that I've been busy working on things instead, but while I've been busy it seems little of it relates to Alter Aeon.

The first reason for this post is the mapper. I've built new area maps for the web pages! You can find these at the standard Alter Aeon Maps location. These maps include the level of areas, as well as a number of new areas that have been added in the last six months.

Speaking of new areas, we've had an awful lot of stuff come online in the last six months. It would probably have been more if I'd get off my can and worked on the west continent and the demon city of Qoorik.

Lastly, the necromancer class and skillset continues to make its slow and steady progress. I've got the spell and skill trees set up in what I think will make a good, solid class. Honestly, it's far better laid out than any of the other classes are; all the skill trees make sense (to me at least), the level spreads look good, and it's largely new techniques and behaviour. There's a lot of use of charmies and mob armies.

I'm stealing a handful of spells and skills from other classes though. Cleric will lose demon lore and probably undead lore as well as durhams, preservation, and animate corpse. Mage on the other hand, will lose fear and possession. Not huge losses, but enough that I'll have to do some grandfathering.

One thing that does concern me is the upcoming druid class split, scheduled for after necromancer. My current vision of druid has sky/water/earth skill trees, which may serve to simply gut cleric in regard to offensive capability. I'll probably have to rework these simultaneously, and it won't be pretty. It may be possible for me to steal more stuff from mage to compensate. I don't know yet.

Farther down the line is paladin, which I'd intended to be a specialized cross between warrior and cleric; basically a fanatic nutjob fighter with a direct line to his god. I'm not sure I can come up with enough stuff to make this a sane, standalone class.

My final goal is 8 classes, but there simply may not be enough variation in the game world to support it.

Objects - followup

2010-04-28T20:38:00.000-07:00

For reasons unrelated to the previous post, I ended up doing a lot of object work in the last couple of days. I discovered that the linkages between rarity, and the bind/artifact/rare flags were not just overly complex, but in some cases really inappropriate. It took several hours and multiple tries to work out all the details, and we now have a much better rating system for flags and rarity.

The general summary is that binding is much weaker, artifact and rare are stronger, you get an extra artifact per rack, and rarity is being deprecated.

Rarity I was the most surprised about; there were literally thousands of objects with rarity on the game. I wrote a function to remove it from everything that didn't strictly need it; this cut the number down to under a thousand. It's still a useful mechanic to have on certain special items, but having it on this many of them really doesn't seem appropriate. Rarity will also be a major issue with a larger player base, and we need to use a new mechanic for a lot of these things.

Weakening the bind flag caused issues with a lot of equipment that was built to take advantage of binding. A good chunk of it was in newbie areas, where I myself used it to get fairly powerful equipment to low levels. On the other hand, a lot of the other binding objects were problem objects that needed to be adjusted anyway. We've had a problem with bind flag overuse for a while now, and this helps address that.

The addition of another artifact flag is a major change, but it comes with a caveat: one artifact flag has to be bound, while the other must be unbound. A similar restriction is in place for rare flagged items.

This seems to be a really interesting idea. The bound objects are slightly more powerful but cannot be sold; the unbound objects can be sold and will serve to keep the equipment market functional. The fact that builders must build both bound and unbound equipment should help with equipment diversity and address some of the concerns that players have about "everything becoming bound".

All in all, I've been getting a lot of positive feedback on it. I know it's inconvenient for builders to update things (I make a point of it to personally take my share of pain from the older areas), but so far the consensus seems to be that it's worth it.

Objects - rarity and timers - TL/DR

2010-04-19T09:39:00.000-07:00

There are several different types of 'powerful' objects, with various limitations, that can be built on Alter Aeon:

Rarity based: Only a certain number of the item can be on the game at once. The limit is a long term (multiple week) average, so there may be none or there may be a lot of them on at any given time. If the long term average is too high, the item stops loading.

Binding: The object binds to whoever picks it up, preventing trading and selling. There are usually a low number of these per zone, between 0 and 3. The building code warns if there are too many of this in any given zone.

Artifact: One artifact is allowed per zone. Artifacts can be much more powerful than normal equipment.

Rare: Two rare items are allowed per zone. Rare items can be a bit more powerful than normal equipment.

Timered: The item has a timer and will at some point self destruct.

Each of these four classes can be more powerful than normal equipment, and as names like 'artifact' suggest, sometimes they can be very much more powerful. Some of these different classes interact with each other, making the calculations and code messy; for example, Rarity and Binding contribute to make Artifacts more powerful, but only to an extent.

This complexity in itself is problematic, but there are two other major issues to consider as well:

Rarity based: For any 'good' and useful piece of rarity equipment, it is obtained repeatedly until it is well past its loading limit. If the item is also Binding, it can't be traded and eventually it begins loading again as players stop playing the game. If it's not Binding, players trade occasionally (one or two trades per year) for the few pieces that exist, and it never loads again.

Timered: Noone will ever use the item. If it's not permanent, people aren't interested.

Rarity doesn't make any sense if all it does is give a small number of players a monopoly on an item; for them it's not rare, it's just a part of their set that noone else can ever get. For everyone else, it's so rare as to be impossible to obtain.

Timers on the other hand are the opposite end of the spectrum. Regardless of how good it is, people won't use it if it's timered. There seems to be some small exception for this with timered enchanted equipment, but I suspect this is because the timers are really long and the equipment doesn't self destruct when the enchant wears off.

Timers are of course, the obvious natural mechanic for controlling rarity based equipment. If something is limited load, simply make its duration in-game finite. This would guarantee turnover and make the item available to more people.

One final thing to consider is the way that timers currently work: they're not based on real time, but rather some amount of game time. You get an item, and you know it'll time out after you've used it for a while, but you never quite know when without checking it each time. If you log off for a week, you're likely to forget about it and suddenly find an important item vanishing unexpectedly in the middle of a battle.

This leads to one possible improvement: RL timered equipment. You have something, but you know exactly how long you have it for. Having something say "This will expire at Mon Apr 19 11:33:15 2010" is very different than having it say "This item will last for two RL days of game time, which could be two months from now if you don't play very often". It also has a built-in sense of rarity attached to it.

I like it.

Myspace

2010-04-16T15:27:00.000-07:00

Today, I did the unthinkable: I constructed a myspace page. I suppose technically, I had already done that with my personal page last year; but in reality it was simply the bare minimum login and I had done nothing at all to it since it was created.

I really have to hand it to the myspace developers; they've created one of the single most dysfunctional, hard to use, and unconfigurable interfaces I've ever seen that still happens to mostly work. It reminds me a lot of Gimp.

Actually, Gimp is worse. But not by much.

At any rate, if you still have a MySpace account, feel free to add us! Our myspace URL is:

http://www.myspace.com/alter_aeon

Dprocs

2010-04-13T12:05:00.000-07:00

We have a rather interesting interpreted language in-game that can be used to perform actions on a handful of triggers; an example might be to add an arbitrary 'use' function to an object. As an example of this, I once built a vacuum cleaner object which could be used to suck up pretty much anything you pointed it at. Sucked up things ended up inside the vacuum.

One drawback of this language is that it didn't have any concept of global data. I added that feature today, using a surprisingly small amount of code.

A surprisingly small amount of code that took me about three hours to write.

Once again, software complexity rears its ugly head. I actually made two false starts on this problem, each of which I had to back out before finally getting a minimal solution to it. The interpreter isn't really that complicated or large by any real programming standard, but it's still larger and more complicated than I could easily wrap my brain around.

It took about two hours to really figure out the best way to handle it, then about an hour to implement it. Most of that time was just trying to understand what was already there and how it all worked. And this is code I wrote!

On the plus side, my actual implementation, when I finished, had 2 bugs in it, both trivial. It's good to know that thorough understanding up front does in fact result in far fewer mistakes.

Leading by Leading

2010-04-06T20:24:00.000-07:00

If there's one thing I've learned over the years, it's that public debate about radical new game features is seldom a good thing. It's not the players don't have good ideas; it's that vocal minority groups serve to deadlock and kill otherwise good ideas.

This reminds me of the Knesset in Israel. They have so many fanatic fringe groups that it's virtually impossible to get anything done.

On March 16, I globally removed and disabled permanent player killing. I didn't post about it, I didn't request for comments; I simply did it, and waited for the fallout.

There wasn't any. Or rather, the people who would have made a big deal of it were unable to do so - there was no way to invoke righteous indignation from the population by blowing things out of proportion. Propaganda doesn't work when people can try it for themselves and say, "no, that's not true".

The next day, I changed the way magic resistance works for players. I've been wanting to do this for over a decade, but never felt like it would be appropriate. Fallout level? Again, very little. Again, largely because the bullshit espoused by the vocal minority was quickly killed by players simply trying things for themselves.

I like this idea of leading by leading instead of leading by consensus. Decide what to do, make it happen, just be prepared to clean up the mess afterward. It's not that I'll never mess up, but it's definitely easier to apologize and fix it than to debate it up front.

More Clienty Goodness

2010-03-16T14:42:00.000-07:00

Since I've posted last, I've released two versions of the Alter Aeon client, with a host of improvements and new functionality. A lot of this has been layout and theme changes, but there's also a more substantial newbie mode and other feature updates. I even managed to get a primitive mouseover compass working in the automap!

Here's a screenshot of what the new interface can do and looks like:

(Note - this is the X/FVWM/GTK version of the client, so the window decorations around the outside will look a bit different from the Windows version.)

We've got a lot of other improvements coming in later versions, but now it's time to get back to work on game mechanics.

Welcome to the new year!

2010-01-08T20:17:00.000-08:00

Alter Aeon has survived yet another year, and while there have been a lot of ups and downs overall things are looking pretty positive. We've put a lot of work into making the game accessible, more playable, and more fun - and it's really starting to pay off. I've gone back to playing AA in my spare time for fun; that's something I haven't really done regularly in over a decade.

I've posted a very large '2009 year in review' article on the Alter Aeon Website. This took me several hours to put together, from both the postings here on this blog as well as going through the entire coding changelog for the last year.

Naturally, the things I found important and worth talking about come from a very biased, immortal based perspective. Fortunately, one of our more vocal players, Subtle, wrote up and posted his own player-centric year in review. I wish more mortals would do this; I think it's really cool to have a permanent record, even if it's not a feel-good propaganda piece.

New Maps Available!

2009-12-22T18:00:00.000-08:00

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

2009-12-21T12:33:00.001-08:00

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

2009-12-12T08:29:00.000-08:00

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

2009-12-04T11:17:00.001-08:00

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

2009-12-01T20:54:00.000-08:00

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

2009-11-28T08:00:00.000-08:00

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

2009-11-25T08:41:00.000-08:00

[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

2009-11-22T19:02:00.000-08:00

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

2009-11-20T09:31:00.000-08:00

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

2009-11-17T11:06:00.000-08:00

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

2009-11-10T12:05:00.000-08:00

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

2009-11-07T14:52:00.002-08:00

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

2009-10-20T13:54:00.000-07:00

[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!

2009-10-11T11:39:00.000-07:00

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

2009-10-07T17:02:00.000-07:00

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

2009-10-03T11:17:00.000-07:00

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

2009-09-23T18:23:00.000-07:00

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

2009-09-17T08:20:00.000-07:00

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

2009-09-06T21:10:00.000-07:00

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!

2009-09-02T19:35:00.001-07:00

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

2009-08-29T21:07:00.001-07:00

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

2009-08-20T11:28:00.000-07:00

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

2009-08-12T19:23:00.000-07:00

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

2009-07-12T20:17:00.000-07:00

[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?

2009-07-11T06:39:00.001-07:00

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

2009-07-09T12:46:00.001-07:00

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

2009-07-03T20:43:00.000-07:00

[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

2009-07-02T13:23:00.001-07:00

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

2009-06-25T20:34:00.000-07:00

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

2009-06-14T16:17:00.000-07:00

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

2009-06-07T18:54:00.001-07:00

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

2009-05-25T19:53:00.000-07:00

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

2009-05-18T19:35:00.000-07:00

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

2009-05-14T10:33:00.000-07:00

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

2009-05-12T08:47:00.000-07:00

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

2009-05-11T07:10:00.000-07:00

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

2009-04-30T19:20:00.001-07:00

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

2009-04-23T13:13:00.000-07:00

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

2009-04-18T07:54:00.000-07:00

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

2009-04-08T07:24:00.000-07:00

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

2009-04-05T21:24:00.000-07:00

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

2009-03-29T09:50:00.000-07:00

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

2009-03-22T09:01:00.000-07:00

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

2009-03-12T19:54:00.000-07:00

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.

Chaos seems to reign

2009-03-01T18:23:00.000-08:00

The field of software arguably contains some of the largest and most complex functional systems ever created by man. Even relatively simple systems can demonstrate incredibly complex behavior, and can hide potentially major flaws through indefinitely long periods of use, only to demonstrate them at inconvenient times. The Alter Aeon server codebase is no exception.

Pretty much the most complicated discrete object in the server is the socket stack. It handles a huge number of protocols and a bunch of different filtering layers, with hooks in various places. The last major redesign of the socket stack was around 1998; it is a testament to the design of that module that it has required no major modification in that entire time period, though many minor modifications have been made to it.

Unfortunately, the server is not made of such lovely discrete objects. Often, obscure bugs lurk in the sea of wild code that makes up the substructure of the system. This weekend I had the incredible good luck to catch and haul two of these bugs to the surface.

For years, there have been a handful of issues that occurred seemingly at random. In the early, old days, some of these would even cause a server crash and reboot the game; but after being unable to find and fix them, the crashes were gradually protected against and ways were found to ignore these spurious events.

Examples of the two most common of these are deceptively simple: sometimes, the get_room function would be asked to find a room but be given no instructions on how to do so, and other times a character (a monster or player, it was difficult to tell) would die and simply 'get stuck'.

In reality, these are monstrously difficult. The get_room function lacking instruction was mindboggling - it happened perhaps twice a year, the reports were never the same, and there were thousands of places that could be calling the function. Even as our debug facilities improved, no progress was made - there just seemed to be no rhyme or reason to it.

The dead character bug was just as bad. The entire destruct and event handling process was revisited and inspected several times, but no holes were ever found. Until thursday.

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

In the course of trying to add some new restrictions to the 'charm' spell, I noticed that the destruct sequences for the charm, possession, and entangling roots spells looked a little goofy. We didn't check or clear certain important things, but there were comments indicating that we didn't need to because something else over there would take care of it. Keep in mind that this was entirely my code; I had written this well over a decade ago.

In the course of looking at this, I suddenly had a realization: there were no 'holes' in the logic for charm or possession, but maybe, just maybe, there was a hole in entangling roots. Entangling roots did come later, and quite frankly the code for it was a complete hackjob.

Within ten minutes, I had my answer. There was indeed a conflict between entangling roots and the 'special' code that made possession and charm work. The problem then became, how exactly do you fix such a mess? After about two hours of thinking about it and five more of carefully backing things out and reorganizing, I got what appears to be a stable fix. There's still some debug logging in it, but this bug appears to be properly killed. The new code is simpler, the checks are stronger, and we don't rely on obscure handlers to clean up messes. I hope.

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

I thought that was the end of my troubles in the short term, but then Glorida shows up with some obscure problem of his own. He's been working on mob programs, and had built something rather complex that simply was not working. Not only wasn't it working, but it was doing something weird, and it was doing it reliably.

This is another one of those 'fairly complex' pieces of the system. It took me about two hours off and on to get it loaded into my brain so I could really think about it. It then took me probably another hour to really understand what was going on, and figure out what was happening. And then it occurred to me:

This explains a lot of those debug log reports over the years!

The symptoms he uncovered showed up as a very unusual sort of 'doing things before other things have completed' recursive issue. One example of it is that a monster would 'say' something to trigger another monster, and the second monster would perform its action before the first monster could fully complete its 'say' command. In obscure cases, this chaining could be several layers deep.

For simple things like monsters talking to each other, the worst that can happen is that some things get out of order, and you might not understand why it works sometimes but not others. But monsters do substantially more than just talk to each other.

And this is where the problem arose. In the course of doing more complicated actions, those actions could be interrupted mid-stream by other monsters trying to complete their triggers. One such set of actions would cause the get_room function to be passed trash. Another such set of actions would damage one of the monsters so that it could never properly die. Both of these sets of actions, and a number of others with similar strange effects, were possible and implemented in monsters on the game; and they were sufficiently rare to explain the infrequent bug reports.

This bug was easier to fix than the first, taking only about three hours to really think about and put together a proper solution. This fix also appears to work, though it does break a dozen or so special monsters that relied on the old behaviour to function.

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

There are several morals to this story, which all software engineers worth their salt will immediately recognize:

1) Never assume you'll remember anything about code you've written. When you start working on objects so complicated that it takes you an hour every day to load it into your head so you can go to work, what makes you think you'll remember every detail after a year?

2) Think about the design of any halfway complex system and stick with it. The charm/entangling roots bug was caused entirely by undesigned/spaghetti code for the character destruct process. It was never properly designed because I wasn't experienced enough at the time to know how. It's better now.

3) Never underestimate the power of race conditions and call trees. When even simple/obvious actions can invoke arbitrarily complicated effects capable of invoking other effects, you're walking on very, very dangerous ground.

Software continues to become more complex as time goes on. It pushes at the limits of our minds, bringing programmers to the limit of what they can understand and then begging them to add one more thing. It allows arbitrary expression, but with that comes the cost that our comprehension is limited even for structured objects, to say nothing of more arbitrary and abstract ones.

Where does the future of software lie? Undoubtedly toward increasing complexity. But we will need either better tools, or better brains, to be able to manage it. We are such a young species.

Bugs, bugs, and more bugs

2009-02-27T21:14:00.001-08:00

One nice thing about the (relatively) small userload we have right now is that reboots and the occasional crash aren't so much of a problem. Which is good, because today has been awful.

A confluence of factors served to get some really terrible code into the system, but by far the biggest one was my acceptance of pretty well untested code without thoroughly testing or reviewing it myself. This was the cause of several crashes and an almost-severe memory corruption fault (which was fortunately cleared by a crash in a different, unrelated section of code.) While my code was definitely not bug-free, it was at least not crash worthy material.

The only saving grace in this mess is that I found and fixed a bug that has been occasionally plaguing the system for over ten years: memory structs on players were not being properly cleared in an obscure scenario, resulting in use of mob structures after death. Were it not for the crash-resistant pooling memory architecture that we've been using since 1996, this would have caused major problems over the years. As it was, it simply cut warnings and bailed.

In exchange for this though, I now have a host of other plausible wierdnesses, including a bug that appears to corrupt the destruct timer on dead players. Again, the design of the codebase is happily tolerating this and simply cutting warnings, but it is disturbing nonetheless.

WxWidgets Review

2009-02-24T12:22:00.000-08:00

Now that I've had a chance to settle down and not work on the client for a couple of weeks, I'm probably in the right frame of mind to write a proper review of wxWidgets.

First off, wxWidgets is a multi-platform GUI toolkit. It's been used to build a variety of applications, including the current version of the Alter Aeon Mud client. It works on a bunch of different platforms, including Linux, Windows, Mac, and a handful of less popular operating systems. I've used it to build the most recent versions of the Alter Aeon Mud Client, a standalone executable designed for the players of Alter Aeon. It has a graphical automap and basic colored-text console facilities.

In the case of standard dialogs and standard types of objects, it works quickly and well. Everything always looks 'as it should' for the platform it's on. Unfortunately, things work less well for even slightly more complicated objects.

Take for example the standard wxTextCtrl object. This uses what's known as a 'native' library - the guts of this object are based on the system libraries where it's built. On Windows it uses one of the standard text window DLLs, while under Linux it can use GTK or other libraries. Because of differences between these system libraries, the behavior of the wxTextCtrl on different platforms is vastly different.

Scrolling may or may not work depending on the platform; URLs, if enabled, may or may not display in Windows depending on the version and service pack level. Performance varies; disabling certain features may break window formatting, and Append may insert arbitrary line feeds after ever call. When editing text, attempts to move the cursor past the end of the text triggers a system beep at full volume. The list goes on, and not all of these are fixable without editing wxWidgets itself.

One recommended solution for these kinds of problems is to use the wxRichTextEdit class. This is a ground-up reimplementation of the text window, with an interface similar to the wxTextEdit class but far more comprehensive. This class actually works pretty well, and it's consistent across platforms as you'd expect.

The only problem is that it's slow. Dog slow. A dog with no legs slow. Using it as a text console display becomes almost useless beyond a few thousand lines of text. And that was pretty much the whole point of what I wanted to do.

Fortunately, there's another solution: the Scalia wxStyledTextEdit class, which is an add-on module from another open source project. This class is designed to do fairly complex text formatting and styling, including multiple styles simultaneously and syntax highlighting. I don't actually need most of that stuff, but I figured I'd give it a try as well.

The downside of this class is that the interface to make it work is quite complex. It's a heavyweight class, designed for very complicated types of things. It's got nearly everything you could possibly need - and some things you don't, including implementation bugs. Quite frankly, I never got to testing the performance of this class, simply because I could never figure out how to change the background color of the window. It's not like I didn't try.

As a last resort, the drawing primitives in wxWidgets are actually pretty good. In approximately one week, I was able to construct my own text window class with the features and performance that I required for this application. Remember that if you have a lot of trouble with one particular module, getting out a wxDC and building your own is always a viable option, and if it doesn't work it's no-one's fault but your own.

Compared with my experience with QT, there is absolutely no comparison: QT has better documentation, better cross platform support, fewer cross platform bugs, better performance, and a more consistent design. Unfortunately, QT is LGPL, requiring an installer for binary applications, and the QT libraries are upwards of 50 MB in most builds. So on that count, wxWidgets wins: it makes drastically smaller and easy to work with executables.

Score for wxWidgets: 5/10

It does most of what it's supposed to do, but don't use it for anything important.

New AA forum

2009-02-19T10:29:00.000-08:00

Hey all, just a quick line to let you know that the new Alter Aeon forum system is up and running. This should hopefully provide a place for people to go on the web, instead of to the user boards in the game. It may also provide a place for new people to search and look for miscellaneous information.

On other news, I've been sick, but even so there's been a raft of changes. Most of these are minor little things, but there's a handful of very important ones such as the changing of object lists from singly linked to doubly linked. That particular change got rid of some fairly nasty lag spikes we were seeing due to very large storage lockers. As always, see the Alter Aeon changelog for full details.

For the rest of the week, I have a handful of web page things to do and clean up, and I need to figure out how to handle moving over a bunch of builders from bport to the main port. I may also get screwed for a few days next week working for my old job.

New client release

2009-02-14T20:09:00.000-08:00

Finally, after a week of work, there is a new Official Alter Aeon Mudding Client for all to use! This version fixes a huge number of bugs in the previous code base, and has faster scrolling among other improvements. Beeping in the input window has been killed and control-c now works again.

It has been a long, hard five-day-slog to get to this point, but using a custom window class has made so many things better. Gone are all the hacks I had to put in to make the old libraries work; now they're back to the nice clean code they should have been. Scrolling works right, select works right, context switches work right - and best of all, it's fast as hell under Windows. I really wasn't expecting this level of performance.

The final hitch was getting the input window working reliably. Through some stroke of luck I found the event handler responsible for intercepting control C and the backspace events. With some really nasty state-handling code and about two hours of experimentation, I finally have an input window class that traps out all the beeps and handles selection copy without stupidity.

If I had known this to start, it would have saved me so much time and effort. Time lost that I could have spent elsewhere; such is life. But going forward, it's so liberating - no longer am I at the mercy of crap that can't be made to work the way I want it to.

If it fails, its my own fault. And I can live with that.

Sucking further wxWidgets

2009-02-11T20:56:00.000-08:00

I've managed to fix and clean up more code in the last two days than in the last four months simply by throwing out these broken toolkit parts and writing my own display class. Bugs that I never could figure out are gone; workarounds for problems that should never have been there in the first place are no longer needed. It displays, it's solid, and it works. I've been mudding with it all day long.

So far, I have a fairly primitive display class with a scroll bar, display window, and border that changes color when it locks. The display window has primitive and buggy line wrapping, but it's usable. There is currently no URL clicky support or select/copy support. Performance is even pretty good.

Performance isn't as good as it should be though - when resizing narrow, it takes far too long to recalculate line numbers. I suspect most of the time doing this is spent in pointless object conversions between various objects. First thing tomorrow, I'm going to be switching over most of the wxString objects to regular const char *'s. There's an awful lot of string processing that needs to be done, and doing it in wxString land is problematic.

After that, I need to rework the way the line data is stored so I can handle select/copy and proper line wrap. This same code will also help with URL support, so it's possible that all three could be done pretty quickly. At this point, the display window is fully featured.

Next up, after the display window, is the typing bar/input window. This one is more troublesome; it's one of those things I'd really rather not re-implement, but I suppose if I have to I can. Either way, I have to do something with it:

1) The input bar beeps if you backspace too far. This is a show-stopper. Computers should NOT make noise unless actively requested to, especially for trivially ignored failure cases. It appears to be impossible to turn off this buggy behavior in the library.

2) It also appears to be impossible to reliably set and maintain the font and font color for this object. Backspacing until it's empty often has unpredictable results. No modifications to the class have been made, and it produces different results on different windows versions more and less frequently. This smacks of being a library/DLL bug.

Hopefully I can find some other input window class that is less problematic, and still have multi-line support. Multi-line paste is mandatory, as I paste a lot of notes and descriptions.

wxWidgets sucks...

2009-02-10T08:22:00.001-08:00

... but even though it sucks, I can't really blame it. I think the problem is endemic when using pretty much any large toolkit, especially younger ones or ones that are built on top of other toolkits.

First, some background. wxWidgets is a windowing library to allow people to quickly and easily develop GUI applications. It's cross platform and in general built on top of other toolkits. This means that the layers of toolkits upon toolkits is often at least two levels deep, exponentially increasing the likelyhood that bugs in one layer will foul up things elsewhere.

These sorts of interactions are causing me huge difficulties with the display and input windows in the client. After much soul searching, I have what appears to be three choices going forward, each with various pros and cons, none of which are ideal. In short:

1) Use the native wxTextCtrl class. Pros - some minimal screen reader support, cut/paste works, already mostly working. Cons - scrolling doesn't work worth a shit, different performance on different windows versions, urls are unreadable for at least some people, no way to disable beeping on backspace, and easily a third of the style flags and other functions don't work or don't work correctly, often with no workaround. Further, the god damned thing intercepts certain keystrokes, specifically Control-C, before I can get at them, and there appears to be no workaround for this.

2) Use the scintilla derived display class. Pros - someone else maintains it. Cons - pain in the ass to get working, manual url and cut/paste handling, bigger, vastly more complicated than my application requires, and inability to configure simple, important things like the background color.

3) Write my own. Pros - it will do exactly what I want, when I want, with the interface that I want. Should be fast and small. Cons - I have to do all the work.

After all the crap I've been through in the last month trying to get the default text controls to do incredibly simple, obvious things, I'm heavily leaning toward option 3 at this point. In the time I've spent trying to get existing controls to work, I could have without question written my own custom primitive. Or rather, I now know enough to write my own. The road would have been rockier in the beginning.

I think this is a prime example of why I rail against toolkits in general. They are very risky; there's no guarantee that what you're using will work, or can be made to work the way you want it to. In this case, I have lost a huge amount of time trying to work around toolkit limitations.

Option 3, here I come.

Somebody Likes Us...

2009-02-05T09:02:00.000-08:00

I just thought I'd put up a quick note pointing at a post on ehowton's blog:

Eric's perspective of Alter Aeon

It's a neat little piece on AA, including screen shots.

Graphical automap

2009-02-04T10:37:00.000-08:00

After a long hiatus, I got a new version of the Alter Aeon Mudding Client built and released for Windows. This version fixes a lot of bugs, but is still subject to the quirks and peculiarities of whatever version of Windows it runs on. This is really irritating, as the URL linking is black (and hence invisible) on some versions of windows, but not on others.

The big update is the graphical automapper, which renders squarish blocks based on terrain and some flags. Auto-generated tiles are what I'm using right now, and all things considered it's not terrible, though it's also not great. Here is a link to a screenshot of the Linux/X version of the client, to give you a rough idea. The Windows version looks similar, with slightly different font sizes and different borders/edges.

As usual, with a new release comes new bugs: the control keys appear to no longer work, the 'vanishing url' problem is still present, diagonal exits don't work (this requires a server and protocol change), and a number of more minor bugs have been reported. It's also lacking blind/visually impaired support, though the default support is already much better than for the old client.

All this (except for blind support, which may be impossible) needs to be fixed before it's suitable to take over the place of the old client. It's getting a lot closer though.

One thing I'm grudgingly coming to terms with is the player desire for triggers and variables in the client. Normal mudders aren't going to use it until it has reasonable features for scripting. I really don't want to encourage scripting, but it may be a necessary evil to getting people to use it.

My hope with this project is that low quality graphics and a visual display are better than no display whatsoever. The game is complex, well balanced, and solid - people who play it tend to stick around and find it entertaining for long periods of time. Getting people into it seems the hardest part.

A possible vote in favor of a bad client being better than no client comes from friends of existing players. I can't even remember how many times I've been told some version of the following:

"I tried to get my friend into it, but he/she just couldn't understand how a game that's only words could possibly work."

Even if it's just a cheesy icon indicating where you are, it at least gives non-mudders a reference: everyone's played old school tile-based games. I hope.

Another major concern I have is that I'm now officially encroaching on what I'd call the territory of other, vastly better funded games. This marks the first real foray into adding graphics to the system; right now that consists of low quality, autogenerated graphics, using a mapping system which doesn't even work reliably (due to area linearity and such.) What I have is crude, primitive, and unartistic.

People can get low quality graphics anywhere; and attempting to compete with modern high-quality rendered 3D games is a non-starter, unless you have a reasonably large budget. Further, the game as it stands is fundamentally not designed to be 3D rendered. It would take a major rework to add support for that, and likely result in the destruction of most of the interesting game content.

So the big question becomes: what is the next step for the client, after it's stable and usable by the default population?

Right now, the only big hitter I have on my list is another type of automap, one that uses the generated area maps from the Alter Aeon World Maps page. The server would send approximate X/Y coordinate pairs, and the client could map them to the appropriate position on the generated maps. This would give people an idea of which areas they were near, and approximately where they were at.

Beyond that, I really don't know. I'm sure something will present itself.

Gaming Articles Suck!

2009-01-30T06:06:00.000-08:00

It's been a while, so I figured I should post some observations about the web pages and traffic. Things work differently than I had expected, though honestly I didn't know what to expect anyway.

The biggest surprise so far is that all of the articles we've written and put up over at the Mudding and Gaming Articles page are worthless.

Ok, not completely worthless; in fact, there's a huge amount of good information in them, ranging from general gaming hints to specific strategies for advanced players. But in terms of web traffic, they've so far shown to be worth substantially less than I expected. The obvious impact of the articles on the overall site, from the standpoint of driving external traffic, seems to be minimal.

Take for example the heaviest hitting articles:

1) [48] The glossary of mudding terms;
2) [45] The muds and mudding faq;
3) [37] Alternative mudding clients;
4) [30] Equipment optimization;
5) [28] High level attack strategies.

The number out front is unique pageviews per month. The heaviest hitter has 1.5 views per day, while the main AA pages have over 100. Note that even fan fiction, artwork, and the historical archives beat several of these. Further, an eyeball's estimate places the -total- hits from the articles pages at approximately the same value as the new player mudding guide. In short, one of the more time consuming aspects of the web pages, article development, has virtually no obvious impact on the overall site quality.

[Note - 'no obvious impact' is not the same as 'no impact'. The pages have definitely improved the site in other ways. It's just not obvious.]

I can think of a couple of good reasons for this. One might be that the articles are buried, and having to click through two layers to get to them is a real hindrance. To unbury the articles, it would be simple enough to have an 'article of the day' show up on the main page, if I can find screen real estate for it.

The other, more obvious reason is that the articles don't have wide appeal. They are for the most part written for a very narrow audience of Alter Aeon players. The search engines seem to be reflecting this, in that the most general of the pages, the glossary and mudding FAQ, are the only pages with nonzero page rank.

Wider scope articles that still sell AA are more problematic. Adjusting some of the existing articles to have broader gaming scope may help. Even so, there's a limit to how broad an article on turning the undead can be.

On the plus side, each article contributes some non-zero amount of traffic to the site, and helps give it breadth and depth.

As a side note, this blog is equally boring as a source of information for people. I don't post anything overly controversial or interesting to the general public. Because the site is so narrow, and because my prose is so mechanical, the Alter Aeon Mob Factory drives virtually no traffic as well. It probably doesn't help that the layout is still the basic default.

Google Adwords - The Content Network

2009-01-27T12:32:00.000-08:00

In preparation for the advertizing bump due in a little over two weeks, I've started looking at little harder at statistics, and at some of the other options. One of the easier things I can test out is to turn the Google 'content network' back on, as this is known to bring in a lot of web page hits for not a huge amount of cash. I've been fiddling with this for the last couple of days. But it's clear that the content network has some problems:

1) Even after these last couple of days, I still don't have things set up properly.

The content network has huge numbers of impressions, and above certain thresholds it's possible to blow your entire advertising budget for the day in a -very- short period of time. I've finally got it cranked back far enough that I don't run out for the day, but it's still about four times higher than the level I'm shooting for.

My advice if you're going to use the content network is to start out at $0.01 and raise it up by a penny a day until you figure out the appropriate level for what you're trying to do.

2) Content network click rates are stupidly low.

Expect at best one tenth the click through rate of regular adwords ads. Rates like 0.04% (four clicks per ten thousand impressions) so far seem typical.

3) Content network clicks are damn near worthless.

If you don't have some way of tracking or testing content clicks for click through, you're fooling yourself. Keep in mind that there's a fundamental difference between someone searching for information, and someone presented with information incidentally while they're looking for something else.

Regular adwords suffers much less from this problem than the content network, because of 1) the negative feedback ad system which kills bad ads, and 2) because people searching for something are still looking for something instead of being shoved things they don't care about.

My own experience and statistics for this show that the content network is 10 times (!) less likely to result in a saved character or a new player than regular adwords search traffic. Price your content ads to reflect the difference for your own site.

4) Content clicks can be gamed, sometimes badly.

I have so far had only one serious incident of content network click fraud, but it can and will happen if you run an extended campaign or one with wide coverage. Sometimes, Google will refund and clear the damage to your account; in my case, they did nothing, even though it was clearly and obviously fraudulent.

The only recommendation I can give for this is set your daily limit to the lowest possible value that still serves everything you want to serve. Then watch carefully for days when the budget is exhausted more quickly than usual. Assume there will be no recovery for click fraud; your only recourse is to limit the damage.

Where do we go from here?

2009-01-24T09:07:00.001-08:00

There's been a lot of development and other Alter Aeon activity over the last couple of weeks, but the bigger question is, to what end? While making ad-hoc changes can improve things, it's not necessarily the best way to get to a particular destination.

There is a method to the madness here, and a specific end goal. In February, I'll be approximately tripling the advertising budget, and if I'm going to be spending that kind of money we damn well better be ready for it. I have no intention of getting traffic to the site only to fail the new arrivals in other ways.

This still leaves a lot of things to be done:

- Getting proper ad and propaganda materials ready.

- Level 33 should be in and available. Happy high level players advancing to a new goal will help new players feel like there's something interesting going on.

- A proper new version of the dClient should be available, hopefully with a prettier automap and better blind support.

On the plus side, the statistics collection on new players is rapidly improving, and we have a much better idea of where people drop out and where problem spots are. The 'saved character' rate is actually quite high now that false negatives have been properly weeded out; of the new connections that begin the character creation process, approximately half of them get to level 1 and save. This is excluding multis - it's a pretty close measure of brand new people who have never seen the game before.

The 50% 'player save' value is also consistent against the dClient numbers, which I had not expected. I would have thought that the dClient numbers would be higher, and they are after a fashion - but not nearly as high as they should be. The dClient clearly needs more work and polish.

In addition to this, I'm in the process of collecting statistics for the islands to see where new players drop out. This is a longer term collection, which will hopefully tell us how to streamline and improve areas on the islands.

Status Update

2009-01-23T20:27:00.000-08:00

Events so far this week on Alter Aeon:

- The first pass of microleveling is installed. It's required to get to level 31 and level 32. We're still thinking about the best way to handle level 33 and higher. There's also a new mode for showing the who list that can be toggled with the 'set who' command.

- We got a new article up on the web, courtesy Morpheus: The Black Art of Poison Brewing, which talks about brewing poisons using the 'brew poison' skill.

- Minor additions and updates to the Mud Terms Glossary.

- Various web page updates, which I've been slacking on recently. One of the more interesting ones is the Alter Aeon Quests List, which is now sorted by geographic area. You can see which quests are on which islands, or on the mainland.

- A 'resurrect' spell has been added, which is effectively a more powerful summon using the corpse of a dead teammate. Resurrect ignores distance and various nosummon flags, making it easier to put a group back together after deaths. You must be grouped and have a corpse to use the spell, so there's not much potential for abuse.

- A new 'faq' section has been added, detailing how the in-game text editor works.

- A new version of the TinyAeon custom Alter Aeon client has been released, with hopefully improved screen and scroll handling. Even better, a new version is on its way and should be uploaded in the next couple of days.

There's also been a boatload of minor fixes, to everything from specp 25 (the shopkeeper reload specp) to channel replay. This week has seen a lot of cleanup and improvement to various things, though the microleveling additions spiked a lot of controversy. It's looking fairly good now though, thanks to good comments from lots of players.

High levels

2009-01-17T09:44:00.000-08:00

As a result of the recent high level observations, I've been making minor changes and cleanup to the player experience. One of the things I looked at was int/wis requirements on spells.

The reason for looking at int/wis was mostly newbie based; new players have limited practices available, and have to decide where to spend them on which stats. If you train stats based on the minimum-cost method, you'll find that stats are naturally separated by two, for example int 18 and wis 16, or int 18 and wis 14.

Under the old int/wis system, the values were hand picked and mostly but not completely followed an algorithm for this that left the int/wis requirements separated by 3. This left new players with a subtle but weird choice to make: should my secondary casting stat be my second highest stat, or third? 3 is between 2 and 4, so keeping the costs even was inefficient.

With the new system, the separation is always 4, so that's never an issue. Also, all the values are calculated, with (currently) no exceptions, and all the spells are consistent. Plus, I got to delete a lot of lines of code.

Unfortunately, there are some complaints, and this seems to be where it always breaks down. No matter how small a change you make, someone gets upset, or pissed off, or threatens to leave. Most of the new players will never even know that there was a change, or the ones that do will adjust their characters within a few days at most. The real complaints come from the highbies.

One such player confronted me while I was in the middle of writing this post. In this particular instance, the change has moved the 'sanctuary' spell from 17/20 int/wis to 18/22, which honestly is a bigger change than I expected (the high mana cost of the spell is bumping up the requirements from what would otherwise be 17/21.) This player is a high level thief/warrior, and doesn't have the natural int/wis to cast sanc now, though they barely had it to begin with. After months of arduous effort, the total 105+ in question finally managed to get a 20 natural wisdom, just as the spell requirement changed from 20 to 22.

I'm not sure how I feel about this. Part of me wants to say 'WTF, a total 105+ with a 20 wisdom?', and other parts of me think other things. But an additional point was raised that brings up yet another design related question:

Why bother to have thief and warrior classes if it's effectively mandatory to have caster classes to do anything interesting?

I'm not sure how I feel about this one either. The game has always been multiclass. I expect people to make full use of whatever skills and spells are available in each class, and to use those spells and skills to compensate for weaknesses in other classes. To have a level 20 cleric incapable of casting sanctuary or other cleric spells simply isn't something I would have expected; after all, sanc is an EXTREMELY powerful spell used by virtually everyone virtually all the time. The game is practically built around it.

In short, I don't know that it's legitimate to have a warrior-only character and expect it to be able to stand on its own and compete with multiclass characters of similar level (or total levels.) The game just isn't designed that way. That type of operation is generally reserved for single class games.

Still, the player is pissed and will likely continue to be so. I have a shitty set of choices to decide from. Compromise a subtle change that I know in the long run is what should be done? Make an exception for particular spells? Make an exception for bitching players? Ignore it?

I'll let you, the readers decide. And then probably ignore the result.

The death (dearth?) of high levels

2009-01-14T19:35:00.000-08:00

It has finally been made sufficiently clear to me that there is a problem with boredom at high levels. As near as I can tell, it's not that people actually run out of stuff to do; it's that they run out of -fun- stuff to do.

Consider the plight of a total 118 or higher. When it costs you a billion experience per level, you pretty much have three options:

1) Run experience for weeks straight to get one measly level, ignoring anything dangerous like EQ or quest runs

2) Do EQ and quest runs and forget about getting a level

3) End up halfway in the middle without incentive to get more exp and not wanting to do anything else because you'd lose the exp you already have

Of these, option 3 is the worst case, and unfortunately probably the most likely. Fortunately, all of the above have an easy solution: microlevels, also known as level staging.

In short, it's a way to bank off experience or whatever the level requirement is in the short term, and give people the ability to work on the level at their own pace. It's even better if you can display that somehow, so that others can see them making progress. Everyone likes feedback about how they're making progress.

This brings me to a whole slew of ideas:

- display of the microlevel on the who list somehow?
- more use of fame for microlevels?
- use of quests for microlevels?
- abandoning exp completely for microlevels?
- going to levels 33-40
- limit rate of acquiring microlevels and levels?

All of these things are something to think about, but either way we're looking at opening up level 33 this year. Whatever I set up, I'd like to do it such that we only open at most one level per year - it's far too easy to get massive inflation otherwise.

For the display thing, the current display model is something like:

[30 32 23 32] Jerk doesn't exist

Suppose Jerk has 16 microlevels on his way to level 33 warrior:

[30 32 23 32] 16 Jerk doesn't exist

I like the way this looks; perhaps other formats would be prettier. Microlevels for each class, with only the highest being displayed sounds like a reasonable way to handle it.

I also really want to do more with requirements other than experience. We did some of this with fame, in requiring fame to gain levels, but right now a quad 32 only has to use 700 fame to get there. The current level requirements for fame right now are:

30 - 25 fame
31 - 50 fame
32 - 100 fame
33 - 200 fame

Note that the level 33 setting has never been used, but 200 fame sounds like a good value for it. For a dual-32 having used 350 fame, another 200 to get to level 33 seems fair. Pro-rating this per microlevel would help people to know where exactly they stand.

Other possibilities for level requirements could be as simple as explorer tokens, or some periodic event. I'm definitely open to more ideas in this area.

For implementation of this, if I had my way I'd make microleveling required for any level higher than 30. This still might be doable, so long as the level and other costs associated with it don't go out of bounds. Microlevels seem kinda stupid and redundant if you can get 15 of them in an hour. 50 million exp spread across 30 microlevels to get to level 31 leaves only 1.6 mil per microlevel; perhaps the real cost for it should be more along the lines of 300 million, or 10 million per microlevel.

This would be a huge increase in the cost of level 31, but with the idea of giving some bonus for each microlevel it might be well tolerated. Consider a temporary bonus for each microlevel, perhaps hp for each of the 32 microlevels on the way to warrior 33. When the final level is actually attained, the microlevel bonus goes away and is replaced by whatever the real level gives you. Players can then start accumulating another set of microlevel bonuses.

Ok, enough ideas for today. Feel free to post back.

Google Page Rank

2009-01-14T13:20:00.000-08:00

As I posted a while back, the AA website's page rank recently went up; since the site went from 2 to 3, there's been a factor of 1.5 increase in overall traffic to the site. Newbie logins, and Google Analytics stats all seem to reflect this general increase.

However, I'm not sure I buy it. When I look at the competitive analysis trend lines in Analytics, I see a pretty regular pattern leading up into December, then things start to look a little different. Going into January, it appears that the global amount of traffic in all categories has increased by the exact same factor of 1.5 I'm seeing on AA. I'm not entirely sure what to make of this. I've seen January increases before, but I never paid much attention to it. I always figured it was people waiting to go back to school, bored and without much to do.

One possibility is that the competetive analysis numbers I'm seeing are related to reclassification of the web site. When a page/site changes page rank, does Google reclassify the site to compare it to the new group? It's possible that the wierdness I'm seeing is simply the new competition in the new page rank category. It would be nice to have more information on this.

Whatever the reason, this influx of newbies is really refreshing. I can only hope that it's not a temporary blip, and that it continues going forward. For too many months did I work on the web site to see no gain whatsoever.

In other news, I found out the reason for the massive drop in players around the October time frame: competition. A rather large group of dedicated blind mudders for all intents and purposes got bored and left to go to another (very large) mud. I've learned several things from finding this out:

1) I need to pay more attention
2) My mortals are bored
3) It's possible to do what I want to do. The target mud has on the order of a thousand players on it. That's the short term goal for AA.
4) I'm slacking. This is my fault. See #1 above.

So I suppose I have a belated new-years resolution: I will pay more attention to the competition and what they are doing.

More xml

2009-01-12T06:24:00.000-08:00

The ongoing XML saga continues, with updates to the code to properly escape the font color tags and the addition of the wholist at http://dentinmud.org:8080/xml/wholist.

Beyond that, the main web pages got another facelift, and I think I'm done propaganda blitzing for a while. That gets old real quick.

Time to try to get some bug fixes into the server and the client if time permits today.

Deathlogs

2009-01-09T14:43:00.001-08:00

One more real quick post before I bail out for tonight: I got Alter Aeon an entry on deathlogs.com, which is a repository of PK kill logs for a handful of muds. While I don't anticipate that this will bring in a huge amount of traffic, it's yet another external link.

xml xml xml

2009-01-09T13:51:00.001-08:00

I really hate that hitting enter while in the title bar automatically posts, even if the post body is empty.

Today, I added support for XML dumping of player data via the web interface. This was at the request of the player Cu, whose XML data can now be seen at http://dentinmud.org:3004/xml/players/cu. The idea was to export various player statistics so that he could dump it into a database and do databasey things with it; in short, a third party app using AA data.

I really dislike XML, but I like this plan. I also hope to export other data, hopefully without compromising the game itself, so that more things can be done with it.

This reboot also brings in a handful of minor changes to newbie sends and the email command, but more importantly it brings in a major change to area checking. We now have code to check linkages between areas and figure out how far off in terms of relative position they are. This should help us line up the world and get things to be a little more grid-like.

This gridlike preparation is in anticipation of graphical maps in the dclient.

In other news, there's a bunch of presentation/toolkit bugs in the client, pointed out by various people. Some of them do not look easy to fix.

Propaganda

2009-01-07T19:34:00.000-08:00

I've been reading SEO stuff off and on for a few months and I've been trying to incorporate various principles into the AA pages as I run across them and understand them. Recently, I got a guide with a whole bunch of short tips in it, and I've been going through it (very slowly.) This week's tip was deep linking.

So tonight, I spent several hours submitting various AA pages for deep linking to other web sites. This was mostly the glossary and article index, but I learned something very unexpected from this adventure: trying to get sub-pages linked with indexes means that I have to make the sub-pages useful to said indexes.

In short, by doing this, I'm improving the web page content in the most meaningful possible way: I'm making it more useful to external parties. In retrospect it's obvious. But it's something I could have missed for a very long time if I hadn't bothered to try it out.

Xmas event log!

2009-01-07T12:11:00.000-08:00

I finally got the 'will christmas be saved' event log posted on the web. To see who all participated and in what way, you can find the log here:

Alter Aeon 2008 Christmas System Event

It's also linked to off our Alter Aeon System Events page.

This looks like it was a pretty fun event, as there were a lot of participants. There were even several deaths during the final battle, all of which are recorded for posterity in the event log.

In other news, version 971 of the Alter Aeon Custom Client is available. This version has mostly bug fixes in it, but also moves some of the direction buttons around and in general has a slightly nicer looking interface.

When will we have a real client?

2009-01-06T19:43:00.001-08:00

Client work continued hard and heavy today, with two major additions going in: first, the hp/mana/movement status bar is functional. This is a bunch of progress bars, red for hp, blue for mana, and yellow for movement, that goes between the command-entry window and the main window. As you get beat up or heal, your stats update in real time, and the bars get redrawn to give a graphical representation of your current status.

A lot of this code was portable from the old client codebase, but between two different sets of library bugs on two different platforms, I ended up spending several more hours than is reasonable getting it all working. And in the end, I ended up doing a full client release with a trivially obvious bug in one of the display settings: the mana bar displays movement numbers if the client window is made wider than a certain amount.

The second thing I got working was to use the autoexit data to highlight/darken the various direction buttons. So if you're in a room with 3 exits showing, those three direction buttons will be lit. You can use the others if you want anyway (eg. to find doors by bumping into them), but if you're running from something or exploring, this should help.

The surprising thing about the autoexit buttons is how ugly they are. The display is just plain ugly, and I'm not real sure why. I'll have to poke around with it a bit more and see what else I can do with it.

I looked a little at the scrolling issue listed in the previous post, but it's entirely unclear to me how you would hook such an event with this library. I'm also pretty well stuck on the accessibility functions. Unfortunately, noone makes howtos for something this specific.

Tomorrow, other things permitting, I'm going to try to get new style automaps working. That should be fun, and probably overly ambitious: I have enough bug fixes and miscellaneous cleanup to probably consume the day already, and web page work is starting to fall behind.

For web pages, I have a large number of directions for the blind maps project, and an event report from christmas which needs to be put up.

This would be easier if I could fork copies of myself.

Client updates

2009-01-05T19:06:00.000-08:00

I'm in the process of getting another client build out. This version will be almost entirely bug fixes, with a number of wierdnesses with scrolling and the dialog boxes fixed. It should be available at http://dentinmud.org/TinyAeon.exe by the time anyone reads this post.

I'm still running into problems with the toolkit regularly, but I'm slightly more effective and figuring them out and getting it to work anyway.

Next up on the client todo list is going to be auto-scroll-lock on mouse scrolling, and autoexit highlighting of the direction buttons.

In other unexpected news, there's been some serious pk stupidity on the game, and I've made some code changes to try to improve things.

Merging merging merging...

2009-01-04T19:15:00.000-08:00

Keep them dawgies mergin!

Over the last couple of days, I've been trying to get stuff merged in from one of the other coders, as well as fixing up various issues and trying to get some things caught up. While doing this, I'm starting to get a better idea of what I really can and cannot do in a certain period of time.

One thing I should probably do is set aside just one day per week that is going to be dedicated to doing nothing but implementing one single feature. I can actually get quite a bit done in a 3 hour or 5 hour block, and with another 3 to 5 hours to clean things up, it can be booted into the game and functional. But in order to get this time, I need to ignore things like minor bug fixes and all the crap detail work that so easily can bog one down. Not that detail work isn't important, but sometimes big new features are important too.

In other news, I got a freaking pile of directions and 'blind maps' from one of my blind users. The only problem is that there's so much of it, it's going to need a database just to make it all accessible.