RPG Resources

Friday, December 09, 2011

8 Reasons Why Vehicles Suck in RPG's

I was thinking the other day about games that put a lot of emphasis on vehicles- the Battletech, Mecha-style setting out there.  I had a friend that was really into them in high school, but they just never really did it for me.  I also remember looking at car chase/vehicle combat rules for Shadowrun (1e), Palladium, etc., and just sort of groaning at the complexity of them.  Vehicles rarely make it into my games, and here's why:





1)  Attack of the map eater.  Doing tactical combat in an RPG relies on being able to visualize and map the terrain.  In any vehicle that moves much faster than a human being, or really any platform that requires constant motion, you move through an entire maps worth of space every round or so.  Knowing what terrain is coming for a mile in every direction in a burden for the DM, and hard to quickly add to a map.

2)  That other game.  Rules for vehicle combat almost always seem to follow their own internal set of logic that doesn't match the rest of anything in the game.  Part of it is an attempt to deal with the issues of speed, maneuvering, keeping control of the vehicle, etc.- it's just a scale that doesn't match up well to the character-scale activity of the game.  The result is a sub-system that could be its own separate game.

3)  Wait in the car, Bob.  Vehicle skills usually cost the same as non-vehicle skills in a game.  That means to be good at flying space fighters or helicopters or driving get-away cars, you have to give up utility at fighting hand-to-hand, social interactions, sneaking around, and all the other things that RPG characters do when they aren't behind the wheel.  Building a character that really excels at vehicle combat usually means building a character that is gimped at most anything else.  That gives a GM two equally ugly choices: tell players not to specialize in vehicles, and then make them rare (possibly ruining a player's character concept), or continually try to come up with reasons why there needs to be a vehicle combat in every game, so a vehicle-centric character doesn't get left out of the loop.  Alternatively, vehicle-oriented characters end up being cast in the role of the get-away driver, sitting outside keeping the engine warm because they are too inept at sneaking, shooting, and bluffing to be brought along anywhere.

4)  Hold still while I make thirteen more rolls and update my charts.  The level of detail involved in tracking vehicle combat in a tabletop RPG- relative speeds, absolute positions, rolls to maneuver the vehicle, terrain, regular combat roles- means more rolling and more record keeping than regular combat.  What does that mean?  It means that as the fight 'speeds up' (moves from foot to behind the wheel of a car), it actually slows down as you try to keep track of all of this information.  What you want is the freeway scene from The Matrix Reloaded; what you get is live coverage of the World Accounting Championships.

5)  William Faulkner knew how to write a tailpipe joke.  Related to number three: once operating a vehicle becomes important enough that characters have made a major investment in vehicle skills and equipment, the GM is increasingly constrained by the need to come up with scenarios where vehicles and vehicle combat are important.  That may mean cutting out settings and scenarios that might be otherwise interesting for the group, but are going to render that vehicle worthless.

6)  Sit tight.  For non-vehicle characters, a vehicle scene or combat can be a real bore.  In some cases (if the characters have guns, and don't mind killing whoever is in the other vehicle), they can shoot out windows or jump onto another car or something.  In many other cases- chases, vehicle combat that takes place in the air, in space, underwater, etc.- non-drivers don't have much to do but check and re-check their seat belts.

7)  Move 400 squares.  The way RPGs typically represent movement doesn't match vehicle movement very well.  Having a max move of X squares and being able to double-move at the expense of making an attack works fine for combat on foot.  Even a simple car, on the other hand, has 1) a top speed over 100 MPH, 2) limited acceleration, 3) a limited ability to slow down quickly, and 4) a limited capacity to turn, particularly at high speeds (physics nerds may note that 2-4 all actually fall under the category of 'acceleration', but the need to drag vector mechanics into a tabletop game only proves my point).  That means that a vehicle combat can potentially move through several different terrain scales- a car moving at 20 MPH is very different from one moving at 100 MPH or 5 MPH- and needs to provide players with advance information about the upcoming terrain.

8)  This car has a speed of 117.4 MPH, and a goodness rating of 12.  Vehicle stats often seem like they were bolted on long after the rest of the game was designed.  The provided stats are often pretty inadequate for doing either a good simulation or a good abstraction.  Vehicles usually come out looking like player characters that can walk 100 MPH or get treated like some weird gasoline drinking druid animal companion.  Often missing from these stats are acceleration and braking rates, turn rates or turn speeds, which get lumped into something called 'maneuverability' in systems that also track speed in exact .5 MPH increments.  Meanwhile, more abstract systems will say you need 4 people to crew a ship, without making it clear what exactly the other four are doing while the pilot makes all the rolls.  Just triggering the seat airbag sensors, I suppose.  Giving 'maximum ranges' is also inexplicably popular in non-post-apocalyptic survival games.  If we're playing Road Warrior, tracking how much gas is left in the tank is important.  Otherwise, I don't think we really need to play through what happens if I forget to plug in my electric car or speeder bike at the end of a long day of wandering around a city hunting for clues.

I feel like some game publishers have noticed this problem.  Shadowrun, for instance, has moved Riggers towards being more about drones and security systems and slightly less about operating vehicles over the years, or at least expanded the drone options significantly.  Drones can get involved in combat more like regular characters and less like a 60 MPH weapons platform; riggers become more like a minion-master archetype and less the guy who has to wait in the car until the mission is over. Maybe I'm making too much of it, but starting with 3rd edition I feel like I remember seeing a lot more drone rigger options, and less emphasis on cars and helicopters.

My one positive memory of vehicle combat is West End Games' Star Wars RPG.  Starship combat, at least at the starfighter level, seemed to run reasonably smoothly.  For one, there was no characters sticking their heads out the windows to fire guns, or people trying to jump onto the hood of the next car- the scale was clearly enough delimited from character-scale combat that a different set of expectations came into effect.  Particularly in the later (2.5ish) edition, everyone could potentially have something to do- on a small freighter, you could have a pilot, co-pilot, multiple gunners, and a techie/engineer all acting in a round.  The abstract units used in outer space combat meant that mapping wasn't that much of an issue- features were expected to be much larger than they would be during a regular combat, and space is mostly empty anyway.  In a pinch, you could use stacks of coins to represent relative altitude in abstract units.  And since D6 Star Wars generously allowed characters to default to attributes for a lot of skills, even non-trained characters could contribute without a big investment.

No comments:

Post a Comment