I've decided to leave DDO, most likely permanently.
I was originally going to post this sometime back in April. However, it collided with the forum change, and once the forum changed, my account wasn't able to post for several weeks. That got fixed recently, but I've been swamped with some RL stuff, so I haven't had time to post this.
Anyway, the obvious reply is "you'll be back someday". Maybe I will. Likely I won't. Based on my history with games, it isn't particularly likely. After I left Diablo 2, I haven't looked back since. Same with other games like Starcraft before that, or a MUD I used to admin before that. Although Turbine's "premium" business model is great in that I can return at any time, and although I've put over $200 into the game over the years -- probably more than all my other computer games put together, so there's the view of "getting my money's worth" to recoup the money spent -- I typically haven't gone back to a game once I've left. Maybe if I have the urge to kill kobolds or solo Abbot asteroids every so often, but not in any serious fashion.
I was extremely fortunate to have been a member of Over Raided for the past nearly 3 years. Having been in guilds of all sorts of sizes and cultures and on different servers, I cannot think of any other guild in the game that is as open to trying out new things, experimenting with outlandish concepts, and willing to think "outside the box" to solve problems as Over Raided. Unlike many guilds where the guild atmosphere and culture revolve around (and primarily benefit) the leadership, Over Raided's leadership focuses on keeping its members interested in the game, by figuring out what the members are looking to get out of the game and getting members together to help each other out with their respective goals, as weird and esoteric as they may be. I doubt there are many guilds in the game where members would be willing to just stand around in elite ToD part 2 just so some guy can solo attack the boss to "collect data" -- while the healer is having to heal everyone, and everybody's buffs are ticking down. Or the same in part 5 of Shroud where everyone is instructed to just stay away from the big red guy lest an accidental guard proc ruins the data, resulting in the DDO version of dodgeball. I want to thank each Over Raided member, present and past, for the years of discussion and camaraderie, and having fun achieving our goals.
However, at this point I've already completed most of what I wanted to get out of this game: figuring out the game mechanics, modeling them, and then using that knowledge to help accomplish extremely difficult goals with the guild, such as being the first guild to reach guild level 100. That's not to say that I've done everything, and I know that there are many parts to the game that I haven't touched, such as playing a caster and the analysis for that. But a lot of what I find intellectually interesting has already been done now, such as figuring out how to solo each of the raids. The remaining things that I'd be interested now are beyond the purview of the guild, such as looking at the code flow for why lag occurs (which obviously would require digging in the code which is against the EULA) and RL responsibilities such as working on my dissertation, which the guild could help only so far as it's an example of successful multi-agent collaboration with multiple objectives.
I also admittedly don't really like Turbine's design direction nowadays, but that's more a personal thing, rather than "right" or "wrong"; although bugs may just be due to oversights or not enough time spent on debugging, a gaming company's design decisions and direction are far more deliberate, and reveal the type of customer base that it seeks to attract. I simply don't fit particularly well long-term with the type of customer that Turbine is catering to, although I was brought in by the release of F2P and it's been an interesting intellectual journey for the past several years examining how the game works. The times when lag wipes the party in the middle of the raid, even though they occur at semi-predictable times and I've offered to give Turbine the videos and data about them, are somewhat frustrating, but ultimately it's more about the direction of the game than the day-to-day playing quality for me.
I had a variety of in-progress projects with DDO. Since I'll be leaving, they likely won't be completed, so they won't be released. However, this list will hopefully inspire other players to look at the game in a new light and work on them, and perhaps one day the community will be able to benefit from them.
Running Abbot Tiles Quickly
In the course of working on the 2-man Abbots, I had come up with a way to run tiles extremely quickly (typically less than 1-2 minutes) with a very high probability of success, with the help of guildies. To use this method, the person with goggles only needs to look at a few parts of the tiles board to guide the other person, so it's relatively easy to do, although hard to explain and the execution is very difficult. Because of this and that guildies are expected to understand the raids, our tile runs were typically faster than asteroids, meaning that in Over Raided Abbot runs, quite often people are actually sitting around waiting for the asteroids puzzle to complete. Back when I was keeping track of each run, we were waiting for asteroids around 60-70% of the time. When Nix and I were preparing for the 2-man Abbot, we were regularly solving it in around 40-60 seconds or so (total for both sides) in this way, although that's because we were under a severe time crunch; in guild runs we completed somewhat more slowly to be more sure of success, but still significantly faster than asteroids.
I think it really comes down to how you view the problem theoretically. When figuring out how to 2-man Abbot with one-rounding all the puzzles, I did a variety of analytical work in looking at the game mechanics of the tiles puzzle, which was the key to coming up with this method. I think in general, unfortunately, not enough people are willing to invest the time to really examine a problem, and instead just take their strategies from what everybody else is doing rather than thinking up of an original solution. But many of the raids have better ways of completing them than what people typically do; Shroud portals can be sped up significantly if the group splits up, but people typically won't do that.
Abbot Tile Puzzle Solver
The tiles puzzle in Abbot can be algorithmically solved, just like any other puzzle (such as the "lights out" puzzle for part 3 of Shroud). The difference is that the tiles puzzle is time-dependent, i.e. the patterns vary over time, so it's more difficult to see how to do it. However, it's periodic (pattern repeats), so people proficient at doing tiles can typically see a solution after several cycles. I think the tiles puzzle concept is actually very well done because it has a knowledge component (i.e. understanding how it works) as well as an execution or "mario skills" component, and that's mixed together with a coordination component. So doing it successfully means you have to be fairly well-rounded in your playing ability.
Unfortunately the tiles puzzle gets a lot of complaints, but I think a lot of it is simply that people haven't really bothered to go into the puzzle and spend time on it themselves. As I've mentioned elsewhere, if people are complaining about waiting in asteroids for 10 minutes, then it simply means nobody in the group has bothered to learn to do tiles quickly. If people aren't willing to wait 10 minutes for someone to solve the reaver puzzle, I don't see why people should be willing to wait 10 minutes for the tiles puzzle to be completed. I'm not talking about people using the faster method above, but just doing tiles in general.
I was working on making a solver for it, but never got beyond coding the basic architecture and the graphical output. Obviously you wouldn't apply it "online" because it would take too long to input the timings for all the different tiles for a particular puzzle, but I had a bank of different actual Abbot tile setups from past videos, and patterns could in theory be randomly generated (given the rules of the puzzle which can be estimated). So the plan was people would be able to just generate puzzles and practice solving them offline, so that when it came time to do the puzzle they could see effective patterns to use much more quickly. It would also have an automatic solver using concepts from linear optimization, so that for a given puzzle, people could see recommended paths. I only got as far as figuring out the game mechanics and getting the basic stuff coded though, and not the actual algorithm that would solve a given problem. An example of the output is below, although the path was manually coded (whereas it was planned to be automatically solved):
Ship Buff Layout
When Over Raided was still leveling up, I was planning on writing a guide for ship buffs and how they should be placed. There are a variety of complaints about how long it takes for people to get ship buffs (especially waiting for the last 1 or 2 stragglers in the group to get them), but I think part of that is just that many people haven't really thought about how to lay them out. There are ways to lay them out so that getting them is relatively quick, such as separating them thematically (say, caster buffs in this section, melee buffs in that section, etc.),
The guide would have had images of each of the ships, the layout of the buffs, and several possible paths for them depending on the focus for the guild (different guilds have different needs, so the buffs would be laid out differently depending on their need). I got as far as getting some of the images for the ships and determining the coordinates of the buffs for each ship, but never got around to actually drawing the coordinates onto the ship images and stuff.
The same principles used to measure run speed can also be used to measure swim speed. The main conclusion is that base swim speed is 5.25 m/s (so it's 75% of the base run speed which is 7.00 m/s) and each point of swim increases this by 1%. There are a few surprising things about it though especially how it interacts with certain effects, though I'm not sure if I'll get around to testing all the stuff I've noticed about it.
I've been working on figuring how attack reach works, i.e. when you swing your weapon, whether or not it will actually hit your target. It turns out that this is actually fairly complicated; your range depends on both your angle to your target and on which attack of the attack sequence you're in. For THF, each glancing blow of the attack sequence also has a different range. Further complicating this, other things like moving will also affect your range.
I had recorded down some of the data on attack reach at different angles, but never got around to putting all that data into a couple of nice overhead plots. It would've been useful tactically to know how to maximize your attach reach in a given situation, depending on your weapons.
I had done some preliminary testing on the to-hit system, with the conclusion that it does not work as advertised. I was in the process of collecting more data about it to figure out how it actually worked. Like many other game mechanics such as the renown system and attack speeds, I probably would've ended up figuring out what the actual formula is and posting about it. It takes quite a bit of data though and a variety of different setups to verify things, and I never got around to finishing that.
Combat Log Reader
I coded up a preliminary version of a combat log reader. The code basically takes a DDO video, performs optical character recognition (OCR) on the combat log portion, and stitches the text from different frames together into one continuous combat log. This is why my UI setup is the way it is -- the blue background in the chat windows maximizes the contrast with the (slightly yellow) combat text to make it the most legible; in fact it works better than if I had used a black background. This is also why the combat log takes up the entire height of the UI; this way I don't need to video capture as often (in terms of frame rate), saving hard drive space. Even so, I have over 500 GB of DDO video as it is.
In theory I don't necessarily need to have the blue background at all. The filtering part of the code can be made good enough to filter out a lot of extraneous stuff. For example, compare the raw input frame with the filtered output prior to performing OCR:
raw frame input
after color filtering
after color and brightness filtering (input to OCR)
the three images in animated format
However, having the blue background is nice to ensure that I don't have to worry about explosions or other bright effects messing up the OCR, if they happened to be where the combat log was. It's basically there so that I don't have to worry about things as much, in terms of adjusting the filter settings.
At present the OCR script has processed over 6.5 million lines of combat log text containing over 412 million characters, with an accuracy rate above 99.999%. The main error is confusing ',' and '.' but that's generally irrelevant, since I use it primarily to tabulate the numbers (such as damage numbers), and not the text. This is how I'm able to empirically determine proc rates to arbitrary accuracy -- I simply video record me doing something, and then feed it through the combat log reader, and then do the post-processing work of counting up the results in Excel. It's also proved useful in analyzing certain raid situations, such as looking at the damage of Abbot in a 2-man situation to better prepare for it. The combat log reader also allows for the most fundamental validation of how the game behaves, more fundamental than "what the forum says" or even "developer intent", since it records directly what the game reports as its output. The only errors would be if the combat log values were incorrect (i.e. if it reports you doing 46 damage when you actually did 54 damage), and the only things that are inaccessible are things that are kept server-side such as monster AI routines and data that the client doesn't present in text form, such as the position of monsters.
Although the thing works, it's rather unwieldy to actually use, and I end up having to manually tune several of the variables for each video. There are also certain restrictions on the UI setup for it to work. For example, the location of the combat log has to be given, and it can't move for the duration for the video. Nevertheless, it's pretty reliable when set up correctly, and makes it a lot easier to record data from the game and analyze different aspects of the game.
I was working on making it more intuitive to use so that it could be made publicly available, but never really got too deep into that (it effectively means making the program more intelligent to handle a greater variety of possible situations, so that those situations don't have to be specified within the code before each run and people don't have to understand how the different variables are used in the code). The code is also fast enough to parse the text about 2x fast as real time (i.e. a half-hour video would take roughly 15 minutes to process, although it depended on the frame rate of the video), so in theory it could have been made into a real-time thing such as a DPS meter, but obviously that part of it never got off the ground either.
There are a few other things. I sort of wish I stuck around until dragons and aberrations were released for the monster manual, so that I could see if my HP estimates for Velah and Lolth's Immanence were correct. I guess someone else will have to verify them though whenever Turbine gets around to adding their entries to the monster manual.
I will likely make a final edit to some of the threads I was involved with and post some final thoughts in the coming weeks, whenever I have time for them. After that, however, the probability of my being involved with the forums and then with the game will rapidly approach zero.
See you in another game.
Some random images:
First guild airship in the game.
Graffiti in the Marketplace.
The biggest afro ever.
On top of the central pillar in Shroud part 1.
On top of Horoth's Throne in the Tower of Despair.
On top of Suulomade's perch in Vision of Destruction.
On top of the tower in front of the entrance to House Cannith in the east part of the Marketplace.