Cutting Out The Suck
You might remember an article I wrote some time ago on "Red Line Analysis" of games. This was based on a trick I heard a professional writers' group use - they drew a red line at the point in the manuscript where they expected a reader or editor to quit reading. They'd return the manuscript, and the original author would endeavor to move the red line back, a little further with each revision.

As noted last year, I think the same thing can be done with games. I can't count the number of times when I've asked someone how they liked a game, and they tell me at which point they gave up playing. Usually it's due to filler making the game too tedius, some really critically annoying bug, or "the straw that broke the camel's back" of minor points of suckage accumulating until the player no longer likes the game. Sometimes it is a point (like a boss monster) where the difficulty jumps to a frustrating level very suddenly.

My favorite was an explanation of why a friend never got very far in Final Fantasy 7. "I quit when the houses started attacking me." I agreed that it was lamest monster in the game, and a very tedious random-encounter sequence. Maybe that was cool in Japan, but it was really lame in

The Suck List For Apocalypse Cow
Apocalypse Cow went alpha last week, which is kind of a fuzzy definition. Traditionally (especially in the hardware world), alpha testing meant that unit and module testing could begin, but that all of it didn't yet work together as a unit. For games, I consider Alpha to be kind of like the "rough draft" of the entire game - the first point at which you can say, "Okay, test this game."

For Apocalypse Cow, I'm trying to figure out how to implement the "red line" analysis on the game. My answer was, instead of a bug list, to create a "suck list." It's not about fixing bugs (though that's part of it) - it's about getting rid of everything that sucks.

To cut out the suck, I'm going through the game, and noting everything that sucks. As I'll be asking anyone testing it for me to do. Then, as with bug lists, there are priorities to be assigned. I'm used to bugs being prioritized "A," "B," "C," and / or "D," which typically mean something at beginning of testing, but in late testing everything gets almost arbitrarily assigned an "A' or "B" priority because everyone knows the C's and D's won't get fixed, or possibly even looked at. A bugs are typically disasterous crashing / game-destroying bugs, and B bugs are "critical."

Well, for the alpha-stage suck-list, this weekend I came up with a different priority scheme for Suckage. It seemed amusing and useful when I came up with it, so I'm sticking with it for now.

So here they are:

Blinding Suckage
Ther top priority is "Blindingly Sucking" problems. Anything issue that would be hard for a tester to see past to look for other areas of suckage is Blindingly Sucking and must be remedied before anyone else even looks at it. Crash bugs, major game-balance problems, and things that ruin saved games are obvious candidates for this category. But since I'm working with volunteer testers - including a lot of friends whom I wouldn't want to jeopardize relationships with by forcing them to sit through hours of annoyance, I also have to include anything that sucks too bad to be ignored by a sane human being. I don't want anybody to have to deal with Blinding Suckage but me.

Examples of Blinding Suckage: The Upgrade UI and the in-game HUD are absolutely horrible and provide little feedback to the player unless he knows what to look for. The player's helicopter jitters (badly on some machines). Missions aren't always ending when the timer runs out. The lighting is broken on some interior levels, rendering them almost unplayably dark (except you can fire your gun and use its dynamic lighting as a flashlight).

Embarassing Suckage
The next priority is "Embarassingly Suckage". These are things that suck so bad I'd be kind of embarassed for anyone else to see it until I get them fixed. They are things that kind-hearted testers might ignore as they push deeper into the game, but would probably leave a bad taste in their mouth to make them less likely to try out a future version. But I might let close friends hammer on a version with Embarassing Suckage without feeling like I am abusing their friendship too much.

Examples of Embarassing Suckage: The Zeppelins aren't dissapearing when they die. The tanks are shooting fireballs backwards and out of their treads. There is far too much stand-in content. There aren't instructions or feedback for some of the more complicated missions. The mid-game story screens need to be in with at least "placeholder art." So does the end-game story screens. Need to turn off dynamic lighting on most AI attacks - they are HAMMERING lower-end machines on the late-game interior levels.

Pre-Beta Suckage
Moving on down the priority list, there's the list of things that "Suck Too Much For Beta." Pretty much anything that noticeably sucks at this point that doesn't make the other two lists goes here. With the possible exception of some stand-in content and some known fine-tuning issues, anything with a known suck-factor must be removed before the game goes beta. Then in beta we'll find a bunch of Subtle Suckage. But that's a whole 'nother story.

Some examples of Pre-Beta Suckage: Dialogs are too wordy - need fewer words and a larger font. Need to fix sound effect priority. Guns far above / below the player in interior levels are still shooting. Player's guns should change visuals as they are upgraded. More powerful AI should differ in appearance from their earlier-game cousins (the ol' "different paint job means different danger!" trick). All sound effects need to be in and getting triggered (even if some sound effects are temp).

Indeterminant Suckage
I don't actually have this category yet (there's way too much obvious, high-priority suckage to deal with), but I thought this last category might be one for things which Might Not Suck. Maybe it's something that people have mixed opinion on, or maybe it's something that sucks a little, but enables something very cool, and you can't find a work-around to get rid of the suck but keep the cool. This would be a category for the sorts of things that need to be investigated further.


The Long Road To Beta
As the examples show, I've got a lot of suckiness to cut out before going beta.

The cool part about it is that during the first half of alpha, I get to clear out a whole bunch of low-hanging fruit. If the game is any good, it is during this stage that it goes from being a lamentable mess that kinda resembles a game to a pretty honest-to-goodness GAME.

Labels: Apocalypse Cow, programming

- posted by The Rampant Coyote @ 7:52 AM (Permalink)