2012 Halloween Havoc

[Repost from in-game]

Alter Aeon is pleased to announce our annual Halloween Havoc! The action starts on Monday, October 29, and continues until midnight on the 31st. Our preliminary schedule has several area openings, a number of voluntary pk events, pumpkin cannon contests, and other things.

Monday, Oct 29:

On monday, we will have the official release of Castle Kraftrager, on the island of Archais. Also known as the drake tower, this zone has a couple of interesting quests and lots of new beasties to fight.

Tuesday, Oct 30:

On tuesday, a new addition to the fire plane, the untamed wilds, will be released. This area is an extension to the tunnels and caverns below the fire giant keep, and is intended for very high level players.

Wednesday, Oct 31:

On wednesday, a handful of areas will be released on the western edge of Archais. The island archipelago has several new quests and deeds, including a cursed temple and hang gliding.

In addition, today, a new area was opened north of the Great Desert, near the Ash Mountains on the mainland. This area has many undead and elemental creatures, and should provide high level players with an interesting experience.

On all three days, we will be running arena and other events every few hours to give those in different time zones a chance to participate and say hello. We'll have novelty items and prizes for everyone.

We hope to see you there!

This code sucks?

A colleague recently asked me, ‘how can you tell code is crap?’ This is a very good question, one dear to my heart given a recent project I worked on.

The biggest indicators all seem in some way to link back to a high Kolmogorov complexity. The basic idea is that the code is more complicated than it needs to be to do a given task. Sometimes tasks require complicated code; sometimes, your given task is to optimize in a way that requires complicated constructs. But in general, one should not make code more complicated than it needs to be.

Some of the indicators I've been able to come up with off the top of my head:

• 1) Lack of data hiding
  
  Any halfway complicated software module is going to have some internal state that it manages, and that nobody else has any business touching. Bad code often has cases where unrelated modules directly mess with data belonging to some other module.
  
  Data hiding takes many forms, and can be enforced by tools or simply willpower. Whether classes, undefined structure types, local variables, file scope data, or intentional exclusion of header files, there are many ways to hide and protect data. Bad code typically ignores those protections.
  
  
• 2) Lack of chokepoint interfaces
  
  Chokepointing is a crucial part of managing complexity. It's very similar to an object-oriented interface, but I think that calling it a chokepoint better conveys what's happening: At the chokepoint, the complexity is the bare minimum of what is required for communication between the two sides.
  
  In short, by chokepointing complexity at well defined locations, you can more easily manage global complexity. Bad code typically doesn't have good chokepointing.
  
  
• 3) Logic holes and unhandled cases
  
  Few things increase complexity faster than unhandled or fallthrough logic. Consider the case of a well chokepointed module, with a single commonly used interface that has a 'fall through' condition: every external module that uses that interface can potentially get a different output for exactly the same input.
  
  While this would seem an obvious bug to be fixed, keep in mind that computers are deterministic - all of the modules on the system may always get the same consistent result. And it may be that all of them get a usable result, except for an obscure usage in some minor library.
  
  

There's three more indicators that I don't think are directly attached to the complexity issue:

• 4) Presence of any unexpected behaviour in the output
  
  If I've learned anything over the years, it's that any unexpected output needs to be examined and understood. Far more often than not, unexpected output is an indicator of #3, logic holes and unhandled cases.
  
  
• 5) Bad customer interfaces
  
  If the publicly exported interface to a paying customer is crap, odds are good the code inside is crap. Customer interfaces should be simple, powerful, and obvious. They require attention to detail, and if that attention isn't present, it's probably not present in the code behind the interface either.
  
  
• 6) Too little, or too much unfilterable debug logging
  
  The purpose of debug logging is to give visibility into the system to allow for debugging and analysis. If there is too little debug, odds are good failures are simply being ignored. If there is too much debug and no good way to filter it for important messages, odds are good the programmer missed something.
  
  

I can also think of one indicator of bad code that appears to violate the Kolmogorov complexity rule (IMHO, it doesn't actually violate the rule if you include the probability of programming bugs and programmer error into the definition of your given task.)

• 7) Lack of sanity checks
  
  Sanity checks directly increase complexity, because they generally change the actual behaviour of the program when they trigger (unlike debug logging, which simply reports state without modification). However, they are cheap, fast, and very, very effective. While they do increase program complexity, they typically add a layer of reliability to the system.
  
  

This is definitely not a comprehensive list, but I've encountered each of these over the last month, on this one project alone. If any of you have other candidates, feel free to post them in the comments.

Alter Aeon 17th Anniversary

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