Archive for August, 2008

Team Fortress 2 Arena Mode: Epic Design Failure

Posted in Game Design on August 29th, 2008 by mawhortn

I try not to hate on industry designers too much, but sometimes the decisions they make are so obviously boneheaded that I want to smack them. Team Fortress 2’s new arena mode is the most fun update to the game yet made, but contains a ridiculously bad team system. The maximum team size is 8v8, and anyone who joins over the limit is forced to wait in a cue (obviously servers should just be made 16 player servers, which isn’t totally Valve’s fault) for the round to end. On rounds end you join whichever team lost, and every member of the winning team stays on. Not only does this make for a lot of complete domination by one team, but people can’t switch to balance it out. People from the winning team who die are put in the queue, so they can be put on the losing team, but this just means that you never get the satisfaction of a complete win unless you never die and also frustrates players who are leading their team in points but die one round. Which brings me to another matter. The arena mode gives a mvp list for each team at the end of the round, but still boots losers randomly. Shouldn’t the best players of the losing team be kept on? Or better yet, how about just letting people join teams like every other counter-strike clone mode and sort it out for themselves. Sure, team stacking sucks, but you could have a balance check system if you really wanted to (again you run into the problem of switching the best players to the other team, which makes all their previous efforts be for naught). And you could keep the old arena system around and rename it randomswap while you’re at it. Every single player who has to wait in spectator for a round is being directly pissed off by the developers. Every server I’ve been on has had angry players in it who hate the system. Whoever came up with the team structure for arena mode should be fired and forced to work designing movie tie-in shovelware for the rest of his career.

Edit: Oh and while you’re fixing things, add the mvp display for both teams to non-arena mode games…

And all those claims of Valve’s iterative design methodology and massive playtesting must be bullshit given how bad their last few updates have been. Or their designers just can’t balance things properly. Or both.

Theory Vs. Practice

Posted in Game Design on August 26th, 2008 by mawhortn

http://www.gamasutra.com/view/feature/3765/the_designers_notebook_the_tao_.php

You can see in the comments section of this article the deep feelings on designers’ parts about Theory Vs. Practice. If you take a look at the feature section of Gamasutra or read up on back issues of Game Developer you’ll see that there’s a lot of theory and very little practice. Most people try to give examples when writing articles, but very few people have written articles like “Balancing Starcraft” or “Level Design in Open World Games” or “How We Designed Grand Theft Auto”. Noone talks about what they do at work every day or how they actually came to make their design decisions, which I feel is very unfortunate given that there are tons of people like me (and experienced designers for that matter) hanging on to their every word. I’m guilty of this too, of course, given that I haven’t released anything yet. But I try to give practical examples or point out design flaws in real-world games. Some of the best articles are practical how-tos, some of which are useful even for non-programmers: http://www.gamasutra.com/view/feature/3725/measuring_responsiveness_in_video_.php

Getting Stuck

Posted in Game Design on August 5th, 2008 by mawhortn

The most frustrating thing in the world for any player is getting stuck. How do you prevent this without being too obvious in quest descriptions or environment art?

The reason players get stuck is either lack of clear communication on the part of the designer or “bad” intuition/thinking on the part of the player. Or both. In many cases the designer fails to communicate what actions the player can do, where the player can do them, or how the player has to do them. My frustrations with Resident Evil and Okami recently have been a result of such bad player thinking and design.

In Okami I misinterpreted the villagers comments about withered trees to mean the giant spirit trees rather than the trees in the village. Partly, this is a result of ambiguity and partly not talking to a certain NPC. But both problems could’ve been fixed by a little bit of helpful writing in a single line of NPC dialogue. And this frustration resulted in about two hours of wasted time. That and the hint dialogue on the sign leading to the next area seemed to suggest an entirely different solution to the problem.

In Resident Evil I tried shooting Ashley (who was clamped to the wall) but didn’t notice that you could shoot the clamps specifically (I think it took more than one shot to break) and didn’t make the logical leap from being able to shoot locks off doors to being able to shoot the clamps, which, given that there are many things in the environment you can’t shoot and break, makes sense. Another leap I didn’t make was kicking the chains off doors to open them. In this case the chains should partially break on the first kick so that the barrier doesn’t seem impassable.

All of these problems, in my mind, can be taken care of by trying to think from the players’ perspectives as well as good playtesting. If and when they do occur, the cheapest solution is often to fix dialog  or add a more obvious hint that can only be accessed after a certain amount of tries/time (puzzle designers have this figured out). Failing that, communicate the mechanics more clearly in tutorial/by gradual or obvious introduction. These sorts of things cause players to quit games and feel intense anger/annoyance/dissatisfaction and so should be a high priority for elimination.

Team Fortress 2

Posted in Game Design on August 1st, 2008 by mawhortn

Behind all the pretty graphics and class-specific visual profiles and almost-good balance that people raved about when Team Fortress 2 was released is the unsung hero, satisfying kills. Sound is a huge part of the feel of a game and it contributes a lot of the magic here. The sound of crits, gibs, and point captures are all very satisfying and meaty. The shotgun, which is shared by several classes, has a report that’s a punch to the gut. The gibs and ragdoll physics are also exaggerated just enough to be comical while also reminding you of your weapons’ powers. The kill freeze frames take some of the annoyance out of dying as well as pointing out your foe and domination/revenge assists a standard human action with graphical highlighting.  The feel of shooting rockets or stabbing backs is subtly augmented by great blood effects, which also do a good job of informing the player which shots are hitting. TF2, while not a perfect game, certainly has all the intangibles. It feels great to play.

Sandbox On Rails

Posted in Game Design on August 1st, 2008 by mawhortn

The midpoint of interactive freedom between Pong (least free) and Garry’s Mod (most free). GTA is a sandbox game with linear missions thrown in to tell a story, whereas Hitman is a linear narrative with sandbox style missions thrown in. Sandbox on rails allows for players to come up with a plan and create unique solutions to the linear sequence of problems presented to them, and represents an optimal amount of freedom vs. narrative control. Would work great for a cinematic 2 hour game experience as well.