Darkened Software

I was recently watching a 64 year old computer gamer try and play “Call of Duty: Modern Warfare 2″ on the XBox 360.  It was not any fun for him by any stretch of the imagination and turning the difficulty setting down really did not help him much at all.  On the easy level he did not die quite as fast but he still died far too often to get into the fun of the game.

This made me a little sad, here is a guy that would love to play these types of games but is not going to pay 60$ to get punished time and time again.  Maybe this one case is not significant but it does tie into a trend I have notice a lot recently.  Every time I meet someone and they find out I work in games they always say ” I used to play a lot of game”.  So I always ask them why they stopped and the most common response is ” I got frustrating … I died to much”.

Well watching his struggle 2 things became clear.

1. He had a very slow positional sound reaction time ( slow at best and almost none at worst).
2. His eye to hand coordination was a little slower in general but the fine motor control coordination was a lot worse.

Call of Duty does a couple of things that make these issues a punishing problem in general:

1. You need to rely on the positional sound to hear grenades landing next to you as the “Grenade Icon” is almost useless and does little to point to were the grenade might be in relationship to you.  For the slightly hard of hearing it is impossible to detect, especially if your living room is not well set up for 5.1 sound.
2. In this game you have to snipe enemies to get through most levels and sniping involves both quick visual reaction times and the need for very detailed hand motor control.

We could go and give players longer to react to audio and visual cues but that would just make the game too easy for the rest of us and only partly solve their problem.  Instead what if we gathered each individuals reaction times for the environment they are in.  Then the game could auto tune for the individual characteristics of each human instead of making the bad assumption that they are all the same.

Info games want to acquire:

• How long it takes someone to react to a sound, the average is 180 ms but this vastly changes based on age and hearing damage.  Also a lot of people have dead zones in their hearing range from over exposure to certain sounds in their life.
• Can people hear position sound information?  Just because someone has 5.1 sound hardware that you can detect it does not mean it is set up properly and they can distinguish the difference, sometimes the sound needs to play longer for the positional information to come across.
• How long does it take someone to react to visual, average is 220 ms but depending on size of image, contrast in the image.  This can be almost 3x times as slow based on age and visual conditions.
• How long does it take to do large and small movements, older people usually have fine large movement control but hands can shake or overshoot for small movements.

Just like the little test many games do were they ask you to look up and then set your invert Y setting.  Games could ask you to use the directional stick to point to were a sound is coming from, quickly put the cursor over a target.  Basically a simplified version of the DMV reaction test would be all that is needed.

This information to turn on things like:

• A partial auto aiming system if they do not have fine motor controls.
• Put in delays between when something pops up and before it starts firing if they have visual recognition issues
• Over compensating with either louder and more drawn out sounds if they have hearing issues.

Why is this important, the market for our games is still expanding and now including older and older people.  Not all of them want to just play Wii bowling or Peggle so we need to make our more in depth games inclusive.  Also we do not want the current gamers to just stop playing, they should never get frustrated and leave games.  A big part of that is recognizing that their bodies are no longer going to be in perfect shape and we have to design around that to ensure we do not frustrate them.

This confirms a lot of things I have suspected about motivation , every programming lead really needs to see this TED Talk

Had a situation recently were someone at work needed to leave early and someone else had to pick up their bug.  The person picking up the bug complained that he was taking over a bug just so someone could go off and do something they deemed unimportant.  This does point out a common mistake in reasoning that employers and other people make.

You have to ask yourself:

If someone needs to leave early one day a week to go LARP’ing is it any different than someone else leaving early to drive his kid to Chemotherapy treatment?

In both cases them being able to leave early makes the employee happy which I suggest you do any time you can because if they have any loyalty at all they will then help the company out when it needs it the most.  And that time will come.  As a lead do not let people ever bitch about why other people are not at work.  It really should be a “don’t ask don’t tell situation” and people should never feel pressured to explain or come up with excuses as to why they need to leave.

Now in the case when it is not just an occasional event:

As an employer you really do not care if someone chronically leaves work early to donate time at a hospital or drink themselves to death while raving.  The end effect in either case is they might not be getting enough work done for you to be on your payroll.  In the chronically missing in action case the reason for is does become a little important.  If you think the reason is fixable you can decide if they are worth trying to wait it out.

I really dislike the double standards at a lot of these work places, some people can send out an email every day about how they are leaving early to take their kid to some event and no one thinks twice about it.  But if some 18 year old sent out an email ever day about leaving early to skateboard at the park before the sun goes down they would be on probation in a hell of a hurry.

Bare min Programming Lead Schedule:

8 hour day ( not really but lets dream )

- 2 hours of meetings

- 1 hour of play game, assign bugs, verify features, code reviews check-ins, track schedule

- 1 hour of debug broke builds and peoples crashes, shoot down feature requests

= 4 hours left

• Average intern requires 1 hour a day just for checking in to ensure they are not spinning their wheels or off track ( 20 min 3 times a day )
• 1 hour a day if significant tech discussion is needed such as the case of starting a new task they have not done before which is most of them.

- ( 1 hour * 3 + 1 hour )

= 0 hour left

At best you can put 3 interns under a lead before they have zero time to do anything preventative or any duties beyond the min a lead should be doing to keep things from falling apart.

So unless you have senior programmers that can offload the mentoring and monitoring of the interns having a whole bunch of “free labor” is not all that free.  You will quickly reach the point were the whole team will suffer from a lack of lead attention just so you can get a some of questionable quality free intern coding.

Nothing is really free…