Renaming Hitpoints?
In the interest of making the game terminology more immersive and fitting to the setting, I had considered renaming Hitpoints to Grit. And then I thought back, way back, to some of my games I made in high school. One was called Twilight (cut me some slack this was before the vampire movies) and was about a frozen planet where humanity lived underground and could only survive on the freezing surface by regularly taking stimulants. It was built as an RPG and had a pretty standard approach for the time, including a series of attributes for each character.
Now in my youthful edginess I tried to get away from the standard D&D statline, so I renamed Dexterity to Agility. Similarly the equivalent of Constitution became Endurance. I think I even went as far as daringly renaming Hitpoints to Life.
In theory this was neat as the statline looked more unique. What happened in practice? Everyone just mistakenly called Agility “Dexterity” instead, because that was so ingrained with the people I gamed with. Now you might think this is specific to my gaming group, and it may very well be, but in reality I think a lot of players gravitate to the terminology they are most familiar with. Even if they did eventually call Agility by its proper name, I can imagine they’d describe it as “like Dexterity in D&D”. It’s like players are mentally stuck in a rut and default to something known and comfortable if threatened with new ideas or terms.
So instead of trying to forcefully add unique terms to Dinosaur Cowboys I’ll just stick with what I (and my players) know best. Hitpoints will be Hitpoints, and anyone from console gamers to hardcore pen-and-paper players will be able to understand and relate to them. It makes the game feel more familiar, which helps for teaching and remembering it. Plus I hate the idea of being unique for the sake of being unique.
Fad of Alternatives to Hitpoints
Speaking about Hitpoints, I also want to talk about the current designer fascination with alternatives to Hitpoints. Go ahead and Google it to see what I mean. The main complaint stems from the idea that Hitpoints are too abstract, why can a high level fighter take more damage than a peasant, they don’t reflect damage well, performance doesn’t degrade, it’s a binary state of alive and 100% or dead, waa waa boo hoo.
Now I’ve been guilty of this in the past, so I can’t fault the idea too much.
Generally I think two outcomes happen when people try to move away from Hitpoints. Designers either call Hitpoints something else and abstract the numerical element with “Light, Moderate, Severe” wounds that have their own scaling system. Or they try to do a damage track of sorts that degrades performance as an entity takes damage, and end up with a death spiral (generally “…suffering an initial failure makes the second failure more likely, which makes the third even more likely and so on. There is virtually no escape from a death spiral once it’s begun.”).
Personally I love Hitpoints. They are familiar and easy to track and record in low quantities (like the base of 8 HP in Dinosaur Cowboys). They may confuse players as to what exactly Hitpoints represent, but I’ve never seen a player actually complain about that. Heck Movement/Speed doesn’t do the best job of simulating what a character is doing either, but no one minds that (ie: is the character running that whole time? Is it the distance they cover in what frame of time?)
Anyways Hitpoints certainly aren’t going anywhere in this game, except down as your Neotechnoist exposed in the open has laser fire poured into him.
Ideas About Playtesting
The discussions I’m about to link are old hat to a lot of game designers, but I figured they still provide an interesting read.
First of all a great post about the downsides of playtesting. It’s a bit strongly worded by some folks standards, but I think it targets a big demographic at sites like The Forge, especially the bit about playtesting endlessly. Ben Lehman: Playtesting: Stop.
Next up is a counterpoint that has a terrific quote I want to focus on afterwards. First of all the article. Playtesting & The Designer as Expert.
And the quote:
“Talk to playtesters to find out problems, but ignore their solutions. Talk to other designers to work out solutions, but ignore their problems.”
As a programmer I really related to this comment, but really hadn’t been following the advice. In terms of computer programming you would perform a user test, but you certainly don’t ask the user how to fix a problem that is identified. And yet game designers often do exactly that when getting feedback from playtesters. I’m guilty of this in relation to a lot of my forum posts. The biggest problem I feel it leads to is rules fragmentation, where you take a fix from a player or two that doesn’t fit in with your theme or goals, and before you know it your nice, clean ruleset is a mess. And then people go “Well, I guess I need more playtesting” and it spirals from there.
Anyways interesting stuff that is worth considering, instead of just going with the status quo. Either way the theory and practice of game design sure is a cool topic.
Leave a Reply