Not many people knew about the utilities and parsing engine that I wrote for AoC. Most of this is because I have no desire to share (and thus help support whatever stupid shit you plan on attempting to do) and each time someone saw anything they wanted it (bribes included). Which is funny, because none of this stuff is rocket science. It’s all pretty straight forward.

Anyway, some background.

AoC’s UI is horrible. The hooks you have to do anything useful in it are pretty limited. Even EQ1 had the ability to make something as simple as a timer (with some creativity, enchanter timers were very common). WoW of course took this to the other extreme. The concept of XML+LUA = \\’ is a good one, but when taken too far it tends to ruin things. Content designers then need to start taking all of these “automation” tools into consideration and then design around it. This is of course the wrong answer to this problem, but that’s what happens.

So AoC first came out and said “YES API YES” and then quickly backed the fuck off of that statement shortly around release. This is good and bad, but uninspired content designers often put annoying tedium into a game. For instance, mobs that lack emotes, visual indicators or other such items to indicate something is happening or about to. Instead you just need to count to N and react. Most designers learned this was bad, but of course AoC lags behind. The only real benefit here is that someone can’t write a UI mod that will play the game for you (one button tanking, like in WoW, etc).

So what I did about it…

Combat logs are the key to any MMO. So first, you need a combat log parser. Sure, there is conan stats but it was fairly lacking in the beginning and never gave me all the stats I wanted. This is why the CLOG library came to be. It was a parsing engine that I wrote that originally just parsed AoC files. Now it’ll pretty much parse anything, but that’s not really the point. AoC wasn’t the best at logging (not even second best), but if it happens in game it should be in a log. With this information you can determine raid and mob state.

This is obviously very useful information to have. We often used it to determine exactly what went wrong on a wipe. Now if you have a handful of state machines tracking everything as it happens live, you’ve got a pretty good representation of what is going on in game as it happens.

This is only part of the solution. Now you need to get the information to someone who can use it. Chat bots are very common in AoC. Since AoC’s chat protocol is based off of AO’s, it was pretty easy to look at some original work (from Slicer) and write my own AoC chat bot. There other other bots out there, but this one was written from the ground up to do what I wanted. Beatrice, as we had come to know and love her, maintained guild roster, snarky comments and provided a ton of utility that the AoC UI never did. Ever wanted an AoC raid ready check? We had it. Ever wanted an AoC loot request system with voting for merit awards? We had it. Just about anything other than automatically tracking raid attendance and loot you can do with a chat bot. I even had had the bot talking with the forums.

So now that you have a mechanism for interacting with people in game you can obviously see the next step. You get the pool boy to talk to his mistress. Hector was broken into two chunks. One would monitor a combat log on a client that was in raid. This information would then be passed to Hector proper where he would then maintain state (which encounter you were on, what players were doing and how the encounter was going). Anything that was interesting could then be relayed to Hector’s lover Beatrice, which would of course be relayed to in game. And of course, since Beatrice was watching in game conversation she could send anything necessary back to Hector (!dps, !topdmg, !healing, etc).

So, to simplify a bit AoC Client -> Live Combat Log -> Log Relay -> Hector -> Beatrice -> In game guild chat.
In game guild chat -> Beatrice -> Hector or Forums or Guild Management System (GMS)

Boosh. All of those tedious timers that you had to sand bag someone with, gone. Of course you can do tons more than just deal with timers, but it’s probably one of the most useful things.

We had all sorts of other crazyness going on at TELoE. Every raid was tracked and everything about that raid was parsed. How long it took us to do something, how much damage, what type of damage, how much idle time someone had.. all of this was looked at. A subset of this data was permanently stored and then dynamically graphed.

This all may sound fairly time consuming, but everything was written over a period of a year or so. Once everything was in place it only took about 2 minutes after every raid to feed stuff into the system and then you could forget about it. It all was very easy, very useful and made AoC that much more entertaining.

And no… I’m not releasing any source code. I’m not telling anyone exactly how the state machines worked. It’s all pretty self evident. You could already be doing this for yourself or your guild. I’m sure what I did wasn’t unique. I certainly had fun doing it (more fun than I was actually having with the game at times) and that’s really all that matters to me.