Thanks to the group that stuck with me through it. I didn’t die, but I can’t say the same for the other melee DPS in the group.

I’ve run it successfully despite a lot of bad pugs but I much prefer doing it with a guild group. Becky saw how bad it was on normal mode today when she ran it with one of her Hunters. By comparison, Forge of Souls and Pit of Saron are cakewalks.

Maybe it’s because Halls of Reflection is a healing test, or maybe it’s because most pugs can’t seem to assist. When I ran it earlier today on Normal mode, I made sure everyone knew to assist off the main tank (a mediocre Death Knight, but it’s tough to be a good DK tank). At the least, a successful HoR group can pull 3k DPS per character, minus the healer and maybe the tank — any less and I’m out of mana or dead before I can keep the group’s health up. I feel like HoR was really built around the Holy Priest, even more so than the Tribunal encounter in Halls of Stone.

Edit: My second Oculus of the day disbanded before I could pick up a drake. I replaced a healer who quit after a wipe on Eregos: people are still convinced this is hard, which just goes to show they never tried it before 3.3 nerfed him. Amber Void, Emerald Void, and Ruby Void are much more attainable now than they were a month ago.

Buttons are laid out to match the Logitech G13 — the exact choice for each button is still being tweaked, but it’s pretty close to done. Main chat and Grid are next to each other to watch player health, discussion, and DBM warnings in the chat log.

Tanking is done using the same UI with different buttons (replacing the set by virtue of the extra bar groups with multiple talent specs).

Addons:

• Recount
• Bartender4 (no reason not to use Dominos)
• IceHud
• Mik’s Scrolling Battle Text
• Buffalo 3
• Grid
• Clique
• Omen
• Atlas
• AtlasLoot Enhanced
• CT Expense History
• CT Mail Mod
• CT Map Mod
• Bagnon
• Auctioneer Suite
• oRA2
• Deadly Boss Mods
• Obituary
• RatingBuster
• Gearscore
• Acki’s Recipe List
• Lil’ Sparky’s Workshop
• GuildGreet
• Viewport

I haven’t bothered to deactivate the Blizzard target and group yet. The group window marks the assigned tank in Random PUG mode.

I also use a macro to relocate and resize the Objectives window.

/run WatchFrame:ClearAllPoints()WatchFrame:SetPoint("TOPLEFT", "UIParent", "TOPLEFT", 1100,-250)WatchFrame:SetHeight(475)WatchFrame.ClearAllPoints = function() end WatchFrame.SetPoint = function() end WatchFrame.SetAllPoints = function() end


Classes: General

• Area-of-Effect Damage Caps: We’ve redesigned the way area damage is capped when hitting many targets. Instead of a hard cap on total damage done, the game now caps the total damage done at a value equal to the damage the spell would do if it hit 10 targets. In other words, if a spell does 1000 damage to each target, it would hit up to 10 targets for 1000 each, but with more than 10 targets, each target would take 1000 damage divided by the number of targets. 20 targets would be hit for 500 damage each in that example.

This potentially hurts my bear, especially when doing Sholazar dailies. The mobs have relative low hit points (~6000) but I may not be able to swipe down all 22 Wolvar quickly enough. This won’t impact Icecrown/Argent Tournament dailies as I’m typically only hitting seven or eight scourge at a time. This will mean low level instance runs need to be handled a little more carefully (no pulling the entire Scarlet Cathedral).

Druids

• Prowl: This ability no longer has multiple ranks and penalizes movement speed by 30%.
• Rebirth: The cooldown on this spell has been lowered from 20 minutes down to 10 minutes. Cannot be used in Arenas.
• Rejuvenation: The base duration on all ranks of this spell is now 15 seconds.
• Tranquility: The cooldown on this spell has been reduced to 8 minutes, down from 10 minutes.
• Talents
  • Balance
    • Eclipse: This effect will not activate again within 15 seconds of either type of Eclipse effect firing, in addition to the existing 30-second cooldown for each type of Eclipse. In addition, Eclipse now grants a 40% critical strike chance to Starfire and 40% increased damage to Wrath, up from 30%.
    • Force of Nature: Health on the treants has been increased.
  • Feral Combat
    • Predatory Strikes: The Predatory Swiftness buff from this talent now has an 8-second duration.
  • Restoration
    • Gift of the Earthmother: Redesigned. This talent now increases spell haste by 2/4/6/8/10% and reduces the base global cooldown of Lifebloom by 2/4/6/8/10% instead of its previous effects.
• Pets
  • Avoidance (passive): Now reduces the damage your pets take from area-of-effect damage by 90%, but no longer applies to area-of-effect damage caused by other players.

The Prowl change has no impact at level 80. Since I’m not Moonkin spec, Eclipse changes and the treant health buffs don’t directly impact me but I think it will help other raiding druids.

Predatory Strikes isn’t a direct nerf to me like it would be to talented PvPer. Declaring the duration at eight seconds clarifies the buff duration.

The Rejuvenation change won’t really impact how I heal: I would usually really Rejuvenation before it expires on the tank. The Rebirth change is huge for me and my parties and should make encounters like Ony25 or ToC10 easier — I’ll end up losing a DPS on about a quarter of the runs (or a tank on raids) and getting Rebirths in faster will make those encounters a lot easier.

I’m more likely to use Tranquility than before: now, it’s only used for encounters I know will stress Wild Growth. I’m much more likely to pop it on any AOE boss now, not just the ones that were tougher AOEs. Honestly, I can count the times I’ve needed to use Tranquility on one hand (usually in OS25).

Gift of the Earthmother means I will concentrate a little more on Haste when gearing or gemming. I’m constantly using Lifebloom in conjunction with Rejuvenation when running heroics or to keep the tanks topped off on raids, so reducing the cooldown is a little better, although I’d really like to see a reduction in mana cost — I’m not running around in Tier 7. On heroics, when I’m with a good tank and the group isn’t taking heavy damage, mana isn’t usually a problem but on some encounters (ToC 10, for instance) I can blow through my whole bar. I’m more likely, with the lower cooldown, to apply Lifebloom to more than just raid tanks.

Finally, I’ve been looking forward to the dungeon finder. This has the potential to let me complete Heroic Dailies on weekdays (I log in around 8pm PST) and being able to teleport directly to the instance will save a ton of time, and I like that it supports returning to town to repair or buy reagents. I’m not happy about losing the Heroic Daily and Dungeon Daily quests, but understand the new system replaces them. I’ll need to make sure that I always have bag space free to hold onto daily random rewards (yes, this can be a problem at times).

Oh happy day: Looking for Group channel is back by default.

I’m curious about the rewards for weekly raids. I can be assured my guild will be running those every weekend.

• I lost my version of Radar that supported chat, so I had to rewrite it from scratch. This version only supports standard layout US keyboards (the shift-modifiers are hard-coded) and I haven’t tweaked the fonts, set up an input box, or limited the input string to make things look nicer.
• I likewise lost the code to add names and chat messages above the arrow sprites, so I rewrote that. This version should be more correct than the one from 2005.
• I’m using the standard Python logger (based on log4j) instead of a custom logging class.
• I’m using a Singleton logger instance for all the arrow sprites.

The arrow sprite logic has gotten complicated enough that I need to develop good unit tests for it. I’ve been developing with rapid integration tests, but I believe I’ve hit the point with the sprite where significant changes could break the correct behavior it’s exhibiting now. A good suite of unit tests against the sprite will help with later refactoring and will also provide a base for testing sprites in other projects. Unit tests should be written before I approach anything as complicated as, say, collision detection (which PyGame handles nicely now) or basic AI or pathfinding.

I’ve looked into using py2exe to package the application as a Windows executable. It looks like, with a few hours of testing and pruning, it’ll work well and still produce a relatively small executable.

I’m considering using Thrift to automate generation and interpretation of the client-server messages. I’m willing to pay a little more in bandwidth and processing time rather than spending time writing custom binary packing and unpacking code for messages. Thrift should let me abstract the process a little more, and I’m very curious to see how well it works for me in practice.

Finally, I’ll implement the server. With the minimal prediction in place on the arrow sprites, I’m very curious to see how well the client runs and how much rubberbanding will take place.

Komodo Edit is still working well for me, although I wonder if the Komodo IDE would help to speed up my develop-test iteration cycle.

Grab the Radar2.zip file here. Install Python 3.1 and Pygame 1.9.1 for 3.1, add Python to your path, and test the program with python Main.py.

Creating a logging bean
Create an annotation package with a Log interface:

import static java.lang.annotation.ElementType.FIELD;
import static java.lang.annotation.RetentionPolicy.RUNTIME;
  
import java.lang.annotation.Documented;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;
  
/**
* Injects a logger of an appropriate type into beans.
*/
@Retention(RUNTIME)
@Target(FIELD)
@Documented
public @interface Log {
  
}


Create a logger injector:

import java.lang.reflect.Field;
import java.util.HashMap;
import java.util.Map;
  
import org.apache.log4j.Logger;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanPostProcessor;
import org.springframework.util.ReflectionUtils;
import org.springframework.util.ReflectionUtils.FieldCallback;
  
/**
* Auto injects the commons Log implementation into the bean when a field is annotated
* with Logger.
*/
public class LoggerInjector implements BeanPostProcessor {
  private static Map>String , Logger< loggers = new HashMap>String , Logger<();
  
  public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
    return bean;
  }
  
  public Object postProcessBeforeInitialization(final Object bean, String beanName) throws BeansException {
    ReflectionUtils.doWithFields(bean.getClass(), new FieldCallback() {
      public void doWith(Field field) throws IllegalArgumentException, IllegalAccessException {
        // make the field accessible if defined private
        ReflectionUtils.makeAccessible(field);
        if (field.getAnnotation(Log.class) != null) {
          String cls = bean.getClass().getName();
          field.setAccessible(true);
          Logger logger = null;
          if (loggers.containsKey(cls)) {
            logger = loggers.get(cls);
          } else {
            logger = Logger.getLogger(cls);
            loggers.put(cls, logger);
          }
          field.set(bean, logger);
        }
      }
    });
  
    return bean;
  }
}


Declare your logger bean in your application context:

<bean class="mypackage.annotation.LoggerInjector"/>


Attach the Logger to your class:

import org.apache.log4j.Logger;
 
import mypackage.annotation.Log;
 
// in your class fields
 
/**
* Logger
*/
@Log
private Logger logger;
 
// use it
logger.error("Invalid request type: " + requestType);


Interface-oriented design
Define your data objects and factories as interfaces (methods), then provide factory implementations to create or retrieve instances of your data objects:

<bean id="myDaoFactory" class="mypackage.factory.myDaoFactoryImpl"
  factory-method="getFactory" scope="singleton"/>


Autowiring
Use the Autowired annotation to automatically add beans to your consuming classes.

/**
* Storage engine.
*/
@Autowired
private Storage storage;


Non-SQL databases
Non-SQL databases should be handled through high level “use case” calls against a storage engine rather than direct puts and gets.

We’ll call it, for lack of a better term, Mystery Quest.

One outstanding question remains: do you believe players need feedback when collecting correctly clues, interviewing witnesses, and assembling evidence?

Procedural content is usually dry, obviously generated, and tends to lack any personality. Consider, for instance, the first episode of Castle: the killer didn’t just act like a serial killer, he worked to frame a victim, made the killings look like those from the book but with subtle flaws, and left a trail of contradictory evidence that was very hard to pick out from the activities of the obvious suspect. This would be pretty darn hard to generate procedurally.

The Parts of a Mystery
A mystery quest is composed of:

• clues – items and states that act as evidence of the action and actors
• witnesses – in these terms, NPCs who saw the action/actors or discovered the results of the activity
• motive – the underlying reason that the activity took place
• suspect – the actor(s) responsible for performing that activity

Assume for now that I don’t have any shell actors, that is that I don’t have plans for a system that creates cut-outs or intermediate actors (someone framed for the crime).

Starting a Mystery
I’ll use 20th/21st century terms to describe starting mysteries in the context of crimes. There’s no reason mysteries couldn’t be set in a fantasy medieval, steampunk, 19th century, or far future milieu but I choose to use language and scenarios common to our contemporary period.

Given a mystery (which I’ll describe shortly), the player needs to be notified of the mystery in some way, in a detective game by notification by the police or a client, for actions such as:

• crime occurs; the witness notifies the police or authorities
• witness finds a body or out-of-place person
• victim of crime is admitted to a hospital
• victim of crime discovers something is missing (from their home or person)
• witness finds victim is missing
• player character (PC) notices something is odd or incongruous (clue grants the quest)
• PC witnesses/notices crime taking place (online or offline)
• witness or victim expresses a worry or concern to the PC

Within each of these is some cause, such as PC witnesses/notices crime taking place may be caused by a:

• break-in
• mugging
• murder
• theft

Causes and Sources
The intersection of the cause and source defines the broad mystery. The source indicates who begins the mystery, while the cause describes what kind of crime or action took place by the actor(s).

Sources

• player character – the PC was either the victim or witness, or obtained a clue independently
• contact – an NPC with a relationship to the PC starts the mystery, such as a vendor NPC’s bark, the player asks the NPC for updates, or the player finds a quest indicator (such as a quest board)
• victim – an NPC without a relationship to the PC starts the mystery (if the PC is a detective, the victim contacts the PC for assistance; if the PC is the police, the victim seeks help)
• witness – an NPC without a relationship to the PC starts the mystery (the PC runs into the NPC; the NPC has a quest marker)

The role of victim and witness both allow the player to start the mystery but each should fulfill different criteria toward completion of the mystery.

Causes

• missing item
• missing stranger – an NPC without a relationship to the PC is missing
• missing contact – an NPC with a relationship to the PC is missing
• theft
• burglary
• robbery
• assault
• murder
• poisoning
• disease
• harassment
• treason
• perjury
• arson
• property damage

For each mystery source, the time, location, witnesses, and clues need to be established.

For each mystery cause, the motive, means, and evidence need to be established.

Clues may become evidence, but clues may also be misleading.

Motives are generally soft: they don’t have a lot of meaning within the game but are needed to provide flavor for the player. Motives flesh out the NPC actors who are suspected of the crime.

• conspiracy
• passion
• poverty or desperation
• vengeance
• vigilantism
• accident
• orders or job

Witnesses are a second form of evidence. While they aren’t collected like clues, they are interviewed to provide additional direction (a new location to look for clues, a victim or suspect actor, another witness to continue the narrative). Witnesses can be described using two axes:

Witness Helpfulness

• Helpful
• Neutral
• Misleading
• Obstructive
• Hostile

Witness Accuracy

• Accurate
• Mostly Correct
• Half Correct
• Incorrect

Witness attributes provide an opportunity for skills use (Interviewing, Charm, Character Reading, etc.) to help the player evaluate whether the witness is accurate and helpful in continuing the investigation. Likewise, systems with PC reputation may adjust the witness attributes. Witnesses may need to be found and interviewed more than once: their statements may change (become more correct or change helpfulness) as the player obtains more clues or speaks to other witnesses.

Means depends on the crime committed and will need to be defined individually for each cause. For a death, means may be one of:

gun, knife, icepick, newspaper, pillow, animal, syringe, food, blanket, bag, telephone, wire, lighter

You should be able to pick out how some are appropriate or inappropriate for particular causes.

Time establishes when the action took place and may also impact the decay of clues or witnesses. Determining the time of the crime can be a reflection of the chosen difficulty of the system (cold cases are harder than recent murders).

Location establishes where (in which room) the action took place and can also impact the decay or spread of clues and witnesses. In a busy game, clues may be picked up by other players and moved from the room, or some clues attached to some objects may be obscured by later, replacement clues to more recent actions.

Putting it all together
To solve the mystery, the player will need to meet certain criteria:

• obtain some percentage of the original clues (50% or more)
• do not assign any incorrect clues to the mystery (the player should be able to deduce or discover this from in-game evidence or tools)
• contacted and received statements from some percentage of the original witnesses (50% or more)
• identified the victims of the mystery (100%)
• correctly identified the actors (100%)
• correctly eliminated innocent suspects (100%)

When the mystery is solved, the player can bundle up the results and turn it in for some reward. It’s up to the game system to determine how correct the player needs to be and what rewards are appropriate to that setting.