Mischievous Ramblings II

The Game Manager

The Game Manager is live!

I've started a new blog dedicated to the subjects of software development and managing software development. Many of my posts on those subjects have been copied from this blog to there, and I'm officially declaring it live as of today.

I expect to do most of my posting on those subjects over there from now on, and I hope to create at least one substantial post weekly.

Hope you'll come by and visit.

Illusion of Control

Illusion of control relative to chance outcomes tells us:

Participants were engaged in a computer game in which outcomes occurred independently of responses. Depending upon group assignment, positive outcomes occurred randomly on either 33% or 66% of trials. Outcome relative to chance was manipulated by varying the number of response alternatives from which participants could choose (two, three, or six). After 50 and 100 trials, participants rated the control they had over accruing points and were asked to suggest specific rules as to how points were obtained. Illusion of control was related to percentage of trials producing favorable outcomes but was insensitive to performance relative to chance. Thus, participants ignored basic statistical probabilities in assessing their control, relying solely on the likelihood of positive outcomes. Furthermore, illusion of control was not related to participants' scores on Burger and Cooper's 1979 Desirability of Control scale.

I recall watching EA people (including Trip Hawkins) testing World Tour Golf during development. I'd added the Wind Direction and Force indicator, but hadn't hooked the wind into the ball flight code yet. At the end of an evening's testing, Trip told me that the wind was too strong and it needed to be reduced.

I didn't bother to tell him it wasn't hooked up, I just said something like I was sure he'd be happier with it in a later version. :-) And he was.

From the GDC

It's Friday morning at the GDC, which means there are 12000 zombie programmers wandering around Moscone West.

I can't believe how exhausting this event has been. The emotional storms of the last couple of years have been completely absent, but the sheer number of things to do and people to speak with has been at least as tiring.

Monday's tutorial on Learning AI (that is, AI that learns) was fascinating. Like almost all good technical presenters, the speakers made it sound easier that it probably is. Naturally, I am energized to go home and start writing AIs again. We'll see.

Tuesday's Quality of Life summit was actually rather depressing. There was a presentation by a lady from Vicarious Visions (I have her name in other notes and will add it at some point) on the adoption of Watts Humphries' Personal Software Process (PSP) on Spiderman DS. They thought it was very successful and plan to spread it to other game teams. I wrote about the PSP a bunch of years ago and thought that it was perhaps a bit heavy, but their experience suggests otherwise.

Dave Perry (Shiny) and Julian Egglebrecht (Factor V?) were part of the studio heads panel at the end of the QoL day, and both seemed to indicate that they feel extended crunch is a natural and effective part of our business. Julian described a 16-hour day crunch lasting 9 months and was certain they'd gotten more real output from the team during that time than if they'd been working 40 hour weeks, but had no data to back that up. David was up front about saying he didn't believe studies and that his experience was more reliable. Naturally I disagree.

Wednesday I spent much of the day talking to book publishers and the various game development programs -- it seems that I may have a new career as author and/or lecturer. I'm speaking at DigiPen on the 24th and talking to Full Sail, Central Florida, Savannah, UAT, and Collins College as soon as I get home. AK Peters seemed most interested in a book on managing software development, but Thomson Course, Morgan Kaufman, and Charles River Media were all also attentive. The guy from Addison Wesley seems to have not shown up, but they've got a website.

Grand Death Auto: What’s A Parent To Do?

Grand Death Auto is not the first time that some new technology or art form has been blamed for depraved acts by youths. It's not even the first time that video games have been blamed for senseless acts of violence and even deliberate murder by young American men.

As parent to an 11 year old boy, I struggle with the question of what is appropriate for him to see and do. He wants desperately to play Halo and Halo 2, and despite the fact that I play CounterStrike: Condition Zero, we've decided that Halo is not yet appropriate for him.

This is not to say that we expect him to never play a shooter -- in fact we rather expect that he's already done so at friends houses -- but that we expect him to understand that we consider them to be inappropriate for him at this time.

Do we think that he'd turn into a raving lunatic axe murderer if we let him play Halo? Nope.

But we do want him to develop a little more awareness that violence is not a good option for solving most problems in real life before he spends a lot of time with realisticly violent computer games.

The court in the GDA case linked above found that the children who fired on a freeway did so without murderous intent. The fact that they were unaware that guns can hurt people seems unbelievable to me, but they were considered to be less culpable than they would have been were they adults. They're children, and we don't expect them to understand the world completely.

And that's exactly why we want to limit the access our children have to certain classes of violent video games (and movies, for that matter) -- because they are children and they do not understand the world fully. Because of that, they are impressionable in a way that adults are not (or should not be, at least).

Maybe I Have To Rethink Ludology

Ludology is the study of play, or games. It's a recently popular term come into vogue among people who want computer games to be more than an economic phenomenon. As the child of academics, I have a knee-jerk distrust of academia, and while I participated in a number of far-too-deep discussions about the nature of games in my youth, I do not participate in more modern academic conversations about "ludology".

But Are you thinking about what we are thinking? from Ludology.org presents a stunning snapshot of the way fascism creeps into the body politic. Although the author explicitly states "What follows has nothings to do with videogames", there is a brief nod to the idea that simulation could assist us in understanding how fascism creeps in.

The "Post 9/11" game, where you struggle with maintaining freedom in a world falling apart.

I don't think it'll sell -- games are supposed to be escapist.

IGDA Article

I'm pleased that Jason Della Rocca agreed to let me write a paper on the economic stupidity of long-term crunch mode for the IGDA.

I'm even more pleased that it's up. You'll also find a copy of Why Crunch Mode Doesn't Work: 6 Lessons here on my site.

The gist of the paper is six important lessons that the extant literature teaches us about Crunch Mode:

1. Productivity varies over the course of the workday, with the greatest productivity occurring in the first four to six hours. After enough hours, productivity approaches zero; eventually it becomes negative.
2. Productivity is hard to quantify for knowledge workers.
3. five-day weeks of eight-hour days maximize long-term output in every industry that has been studied over the past century. What makes us think that our industry is somehow exempt from this rule?
4. At 60 hours per week, the loss of productivity caused by working longer hours overwhelms the extra hours worked within a couple of months.
5. Continuous work reduces cognitive function 25% for every 24 hours. Multiple consecutive overnighters have a severe cumulative effect.
6. Error rates climb with hours worked and especially with loss of sleep.

Overtime (especially uncompensated overtime) is not just hard on people. It's hard on the bottom line when it's used as a long-term strategy, as ea_spouse wrote. It makes software take longer to be done and introduces more bugs than working reasonable hours would. In the long run, extended hours reduce total useful output.

Crunch Mode is a tool that managers can use effectively, but it's a sharp tool that can cut both ways, and it must be used judiciously. The basic rule is: use Crunch Mode only short-term and allow teams plenty of time at normal hours to recover. Long-term Crunch Mode ends up costing you progress both directly (less gets done) and indirectly (more errors get made).

Previous Posts covering this or similar topics include:

• It's Not Just Abusive. It's Stupid
• Can People Really Program 80 Hours a Week?
• Staying awake
• National Institutes of Health: Sustained Reduced Sleep Can Have Serious Consequences

From a Computer Game Magazine

2:00pm	Wake up.
2:05pm	Grab food at Burger King drive through.
2:15pm	Arrive at work.
2:15 - 10:00pm	Program.
10:00 - 10:15pm	Eat dinner. Usually Dominos pizza.
10:15 - 3:00am	Program.
3:00am	Eat dinner, read or watch a movie, sleep.

- Tim Sweeney, Epic Games, www.3DGPU.com, June 2003

Staying awake…

Re: Can People Really Program 80 Hours a Week and It's Not Just Abusive, It's Stupid!:

According to The Promise of Sleep, pages 231-232:

The comparison between sleep deprivation and alcohol intoxication is striking in this regard. Researchers in Australia have found that there is more than just a surface similarity between the two. The Australian investigators split 40 volunteers into two groups. One group was kept awake for 28 hours, from 8:00 A.M. until 2:00 P.M. the next day. The other group was given 10 to 15 grams of alcohol every 30 minutes starting at 8:00 A.M., until each volunteer's blood alcohol level reached 0.1 percent, which is more than legally drunk in most locales. During these periods, both groups were given hand-eye coordination tests. The Australian researchers found that after 17 hours awake (at 1:00 A.M., when biological alerting is declining), the sleep-deprived group had the same test scores as drinking volunteers who had blood-alcohol levels of 0.05 percent. After 24 hours awake, the sleep-deprived group had the same coordination deficits as those with the maximum blood-alcohol level, 0.1 percent.

In other words, if you've been up for 17 hours, that's equivalent to having a blood-alcohol level of 0.05 percent (about 2/3 the legal limit in most states). If you've been up for 24 hours, that's like a blood-alcohol level of 0.10 percent (about 125% of the legal limit in most states).

Does your company have rules against programming drunk or stoned? Is that just because it's illegal or because it's inefficient?

This is Why I Left

UserFriendly 2004.12.15.

"And this is what the nice children want."

Dang it.

More ea_spouse coverage

Value "EA" T-Shirt

(from Intelligent Artifice, where there are more links.)