Converting RPGs and Boardgames to Computer Games

edited September 2006 in Play Advice
In a previous thread I attempted to hijack, Frank was going on about the new online Blood Bowl. Instead of being a buzzkill there, I decided to address something more generally here.

When I ran my Blood Bowl seasons, I actually had entire rule sets for how much money each game brought in, and salaries for characters, etc, etc, etc. (some may recognize some of this in what I attempted later with the Gladiator supplement for TROS with Lance). I did all those numbers myself, in an attempt to make the leagues more interesting. Couldn't solve the fact that the players couldn't get themselves to even play the games. I mean, I'd play my skaven team, so carefully selected and crafted, and in the middle of the match be thinking to myself, "Man, I'd rather be pouring lemon juice on a paper cut right now."

Funny, but I think I recall at the time saying something like, "What this game needs is to be far more complicated, but the complications be taken care of by computer." Now that I think about it, I think that a friend of mine and I might even have started to program it out on his Mac using some visual C thing. Heck, I'm getting deja vu here...didn't somebody already do this previously? I could be flashing on the Space Hulk computer game or something...


I recall a couple of years ago talking to the Federation & Empire guys, who were saying that they were looking into a computerized verson of F&E. My comment to them was the same. Sure, it might speed the game up a lot to have the machine simply do the calculations, and this alone might make the game something that more than two dozen people in the whole world play regularly.

But doing so verbatim would be missing an opportunity to get rid of all of the kludges that exist in F&E, due to "playability" factors. And to introduce all sorts of new elements that would make the game far more interesting. Like having the battles play out ala Star Fleet Battles or something like that (on which F&E is theoretically based) in real time. So that, for instance, players could decide their starting fleet placement, and losses would be randomized. That's more interesting and less work than the defender selecting their losses (the tactics remain, but move to the battle prep phase). I'm sure we could brainstorm up about a dozen improvements to the game in very short order.

But I see this all the time, games moved over to computer verbatim. Starting in the wayback with games like Wizardry emulating D&D. Why in god's name would you create a wargame (c'mon, it's what it is, especially on a computer) where you used an abstraction like hit points - which exist primarily because in a TT miniatures game keeping track of wounds in any more detailed a fashion would be a nightmare - would you use that same abstraction on a computer, which could add complexity to the modeling while still keeping the effort level precisely the same. Wargames are always seeking simulation accuracy, and just have to limit themselves so that a game doesn't become unplayably long. A computer can handle all of this in the flash of an eye for you.

OTOH, with games like Final Fantasy, it's hard to argue that it's not been successful to make such conversions. And, yeah, I've seen more realistic models come and go with little fanfare. But I think that this is, like the D&D phenomenon itself, a matter of what people are used to. CRPGs do take a lot of time and effort to program, so I suppose you don't want to rock the boat. If you have a RPG or boardgame you know works at some level, why change it and have to do the playtesting and such all over again?

But that's not the same thing as saying that it's good design. It's simply the economically sound thing to do. Which I care zero about.

So, am I off my rocker? Or is this just lazy design?



  • I can't recall the company, but yes, there actually was a computer game for Blood Bowl. Not half-bad really. Some of the graphics were a little lacking at the time, but the play was good.
  • I get what you're saying, Mike, but I think you're overlooking the fact that a human still needs to be able to understand it all to play. For instance, World of Warcraft uses hit points. When I'm playing, I keep an eye on my hit points to make sure I don't die. Now, I don't actually pay much attention to the numbers, especially as the numbers skyrocket in higher levels; I pay attention to how much of a green bar I've got left. It's all player interface right there.

    Now, we could, say, have different wound levels for the different parts of the body and higher wounds make those parts not work well, and have different damage types for different weapons, so that when I take a heavy piercing wound to my arm I lose manual dexterity and when I take a medium crushing wound to my leg I limp around and stuff, but if that gets implemented, I as a player still need to be able to keep track of what's happening, continually making the decision, "Do I press on or do I try to rest/heal/retreat?" My little character dude limping around and dropping his weapon could tip me off, here, but I'd really rather have a little green bar telling me how close to death I am. Now, we could abstract all the glorious complexity of the cumulative wound levels to produce a green bar like that, but at that point, why did we go through all the rigamarole to do all these complicated wound levels if all we needed was a little green bar?
  • Because the little green bar sucks!

    Your argument is Petito Pricipi. You like the bar, because it's about resource management, and that's the resource you monitor. Well, what if it weren't about resource management and, instead, about how well your character is fighting? And the important skill is not watching the bar, but estimating whether you can take that wolf over there, while you're limping?

    You're really telling me that the little green bar would be more fun, more viceral, than that?

    Well, perhaps I'm just too different from everybody else or something. But I think that the FPS model actually shows us that people are interested in "real" damage and not just some abstraction. Do you then run into problems of character death? Then you solve that on a system level. This is only one example. We could go round and round and round with this about each individual thing, with you saying that the new system could be implemented badly overall. Well, sure it could. Or it could rock. All I know is that there's modeling capacity that isn't being used, because people just want what they know.

  • Not quite, Mike. I'm saying that, whatever the system involved, it needs to be able to be understood by the player in an amount of time necessitated by gameplay.

    A game that was all about how well I could fight, and I had to keep track of my limping, nerve-stunned self, would rock. If there was at the end of the rollercoaster of trauma a "too many wounds, now you die" thing, I'd really, really need some way of keeping my eye on it, and mentally figuring out what all my various wounds added up to while simultaneously fighting that wolf... that's going to be too much.

    If you've played or seen Grand Theft Auto, the cars actually take damage very much like this. You get a little dinged up, then a big dent, then the hood starts flapping and smoke comes out, and then there's a fire, at which point you know you need to get the hell out of the car. It's a very neat piece of gameplay. But if I had to keep track of all four tires, the engine, the windshield, and my transmission without being able to see them, then it would be really damn annoying.

    I'm not arguing for the little green bar; I'm arguing for a means by which I am able to keep track of what is happening in the game.
  • Well, if you're looking for a means... I forget what the game was, but there was a computer "RPG" that I played back in the '80s which had hit locations that worked like this:

    On the right side of the screen, you had a "body outline" of your character. Below that was a bar for overall "hit points". Damage to body areas was represented by having them change color: when they were green, that area was OK. Yellow meant wounded, red severely wounded, and black... well, that meant it was cut off. (The background was black, so the "black fill" made the area disappear.)

    The "hit point" bar followed those colors as well, in addition to shrinking, turning yellow when you were below 2/3, and red when below 1/3. This was helpful in that the color change drew attention to the bar, helping you see when your damage was getting bad.

    While I'm on the subject, I'm reminded that Castle of the Winds used a similar thing for inventory, which worked quite nicely. You had locations where you could wear/carry things -- legs, torso, hands, neck, fingers (for rings), head, etc. Backpacks, sacks, pouches, and other containers showed up as windows (which could be minimized). To wear something around your neck, you simply dragged it onto the character outline's neck area. To remove armor, you dragged it off your character, and into the backpack, sack, or whatever where you wanted to keep it.

    It was really quite an elegant and intuitive way to handle inventory... and allowed adding a bunch of extra calculation "in the background", since each item had both a space requirement and a weight, and each container had space and weight. A "status bar" at the bottom of each container window had how much space and weight you'd used of the amount that container could take, like so:

    Space: 20/30 Weight: 135/500

    There was a similar weight bit for your character on the "body inventory" window. I don't think the game did, but you could combine that with the above idea, and have the text turn yellow or red when you're getting above certain capacities (those that correspond to some sort of penalties).
  • I understand where JBR is coming from, but I'm with Mike. As Voivod so (bizarrely and) eloquently put it, "Macro solutions for mega problems." There's a conceptual problem at the root of why CRPGs are what they are. This needs to be fixed with a conceptual solution. The medium is ripe for a change -- it's not like we're limited by processin power anymore -- but we get gameplay rooted in 20 year old tropes.

  • All I'm saying is that we are limited by the processing power of my eyeballs connecting to my brain. If I can't keep track of it, I can't make play decisions based off of it. Building a better interface to compress information is a great solution. Just right now, the amount of number crunching that the computer can do far outstrips our ability to display that information in a digestible format.
  • I think the body outline thing suggested by Efindel sounds like the right kind of solution, Joshua. (though in Mike's model, I gather you wouldn't even have the HP bar underneath. . .for death/dying purposes, you'd just track the color of the head and torso areas, the limb damage being more about impairment, and possibly bleeding. hmm, maybe a BLEEDING RATE bar at the bottom?) I agree with Mike and Lukzu, changing the whole paradigm of how we do CRPGS is the way to go, rather than holding back because we're afraid of things like "But without the HP bar I won't know when I'm gonna die!" Which is a red herring, I think. (Like a lot of TTRPG trad fears: "But without a GM/Hitpoints/skill system we'll have chaos at the table!") Thing is, you want to completely overhaul how the thing works, playing to the strengths of the computer. . .THEN devise an interface that the user can process sufficiently with his eyeballs-to-brain-to-mouse-hand apparatus. You won't merely LOSE your on-screen tracker for speedy processing, you'll have it REPLACED, with one that fits the new, innovative design. I've played a lot of games of the Final Fantasy variety, and believe me, we could use more of this kind of innovation.

  • edited September 2006
    Posted By: Joshua BishopRobyWhen I'm playing, I keep an eye on my hit points to make sure I don't die. Now, I don't actually pay much attention to thenumbers, especially as the numbers skyrocket in higher levels; I pay attention to how much of a green bar I've got left. It's all player interface right there.
    I direct you to the excellent run and gun and drive game: The Getaway. A direct design decision was that there be no clutter on the screen. They wanted to immerse you in the game. So you never see your hit points, there's no map, there's no inventory screen. If you're injured, you get wounds on your character. He starts to really limp and pant when he's near death, and you feel it.

    Navigation instructions are conveyed by the car blinkers: to the left? Left turn blinker. Which also means you have to learn the city better.
    Posted By: Joshua BishopRobyJust right now, the amount of number crunching that the computer can do far outstrips our ability to display that information in a digestible format.
    I strongly disagree. I think the state of the art in conveying that information is pants, and game devs especially are lazy about pushing that envelope. The the bleeding edge is way out there.

    Editing to add:

    And part of the premise here is that a computer game should require the same kind of strategic decisions that a board game should. That you should be able to make ideal decisions based on perfect knowledge. What if all the data was there, but you didn't have time to process it? Like you're commanding an army of thousands, each of which have realistic wounds. You can review each and every one of them. But you have a war to fight! That sounds like a dandy game to me.
  • edited September 2006
    JBR and Mike both have good points on this. On the one hand, the more detailed the simulation, the more I like it. I come from a background of things like Third Reich and ASL, where there's a lot to keep track of, and part of the joy of the game (and the strategy, really) is in keeping track and making sense of all of the input in a timely fashion. (Or making the other guy forget about some detail, like why you have a stack of 2-5 armor stashed away near the border with Turkey, for example.)

    By computerizing the inner workings, you can dig for more information, and tweak it as necessary - and expect those tweaks to show up in the game. At the same time, there does need to be a final abstraction of all of this data if you're going to play in a more timely fashion, instead of poring over a few pages of statistics and settings for each figure in Blood Bowl (awesome game - there was a computer version at one point in the mid90s - you can download it from The Underdogs Archive - an abandonware site. Note: You'll need to do some kludging to get it to run under XP, most likely.)

    But as long as the tweaking has a detectable effect on the upper layers of the abstraction, then having the chassis exposed is good for folks who want the kind of fine control that you can get.

    But I also agree with Joshua - ease of interface is crucial.
  • edited September 2006
    Something I know a little about. (I've been working in the video-games industry for eight years now -- now working for Rockstar Leeds). Anyway, one of those 16-bit "outline" games was Midwinter (screenshot), but that was still just a Runquest style "hp per location deal, really". The cars in GTA (and, I suspect, the damage in The Getaway) are basically just a hp track that switches between "Healthy/Undamaged", "Dented/Bloody" and so on down to "Dead/Exploded" at either certain percentages of "Full Health", or at certain HP levels.

    As well as the whole interface thing (which is a huge issue in video games development, both input & output sides) another issue is balance. If you've got a detailed simulation running over buckets of information, which is then abstracted out to be shown to the player, it is quite hard to balance, and strange emergent quirks appear. A better (and much more commonly used) solution in my experince is to have a simple core system that needs little abstraction, much like current boardgames. Much, much easier to code, debug & balance. And since it's all abstracted anyway, the player doesn't really notice. (Really, it's amazing how much 'intelligence' people will give to purely random behaviours -- I think it's in our nature to try and find 'meaning' in what we see, even if there is none there).
  • edited September 2006
    I agree with Mike: especially the idea that fighting should be about fighting, not resource management.

    It's interesting to consider what solutions have been tried. There's the solution of displaying things more visually, as The Getaway does. The problem is that it's still just hit points: you see your character limping, so you know you'll die if he takes another hit, so you recover until he only has a bloody patch, then you know he can take a shot.

    There's the solution of making the resource management more complex: giving separate hit points to different body areas, say, or giving you three different bars to manage, which recover at different rates, together with armour points etc etc.

    Now, personally, I like games like Call Of Cthulhu, where, as you get more insane, you start seeing things that aren't there (which you see as you play). Or that Assassin's Creed one, where the defining attribute is Confidence: you can take out a guard when you're fighting alone on a rooftop, but not when you're surrounded by onlookers.

    So the resources you have to manage, and the effects they create, are directly tied into the theme of the game. Much more interesting than relying on the old standby of hit points / attack / defence.

  • Posted By: Graham WalmsleySo the resources you have to manage, and the effects they create, are directly tied into the theme of the game. Much more interesting than relying on the old standby of hit points / attack / defence.
    Yeah, that sounds good. But attack/defense/hitpoints has an interface pretty much everybody knows (health bar, hp, obvious animation/graphical changes), and I think it's fairly intuitive too (but then again, I've been playing computer games of one sort or another for over twenty years now).

    More interesting 'thematic' resource management has got to solve the interface issue as well. It can be done, obviously, but it's not an easy problem.
  • Y'know, I remember the game Bushido blade had a life bar like your average vs. fighter, but it also had a complex and lifelike system of moves, which would impair movement based on hit location, AND if you pulled it off right, you could deliver an instant killing blow. it was a small, kinda limited game, but fun. Could speak to what we're going for here.

  • I think we're still focusing far too much on the Hit Point problem here. Joshua has, at least, stated his position in general terms saying that if you can't absorb the information that it's not useful. But I'll continue with the exposition on this point at the risk of people missing the overall point.

    Let me restate my position, however. Graham got it. If you assume that hit points are worth tracking, then, yeah, a little green bar is the way to show it. I personally hate, even more, the method used in The Getaway, where the appearance is simply a cycle displaying hits - I'd rather have the bar there as the appearance thing gets really cliche after about the second time you go through the cycle. Better an abstraction than that.

    As Graham puts it, however, you're assuming that we want your ability to resist being killed to be a resource. I think this is the flawed assumption here. Warren admits that he can grasp it quickly as an interface because it's common. But this is, once again Argumentum ad Populus. Everybody is used to it, so it must be right. Baloney.

    What I'm saying is that if the paradigm were to simulate how people really got damaged, that you wouldn't have to worry about figuring out your resource level. Because there wouldn't be any. Ablative hit points simply are a crummy way to simulate injury and wounding. Even Rolemaster understood that, relegating HP to something like pain/blood loss.

    But, put another way, you can take a hit to your hand that can incapacitate your hand, and simply not have it have any affect on the chances that you'll die. Heck, you can probably have your hand crushed to unrecognizability and still not be in any danger to your life at all.

    Oh, sure, now somebody is going to tell me that a bone chunk could get loose and then make it's way to your heart, and cause a cardiac arrest. Sure, and if you want to model that in, great. But hit points won't model that well at all.

    Now, I'm not suggesting that we develop some neural suit that you can wear to feel pain (though that might be interesting, no?). But I think that there are easy visual cues that you can put in that give an idea of affected performance. This is what I'm talking about, changing the paradigm from unrealistic resource management abstractions, and instead making injuries act like real injuries. No, not as indicators of dwindling resources, but as actual impediments to action.

    Actually I've seen some games in which pain does cause the character to reel for a moment - that's a realistic effect it seems to me. But what if the hit actually made your hand unusable. That's really easy to tell when you see the damage, or try to use it, or even if a message has to pop up saying "Left hand mangled." I'm sure somebody with a video game programming background could even come up with something superior. Sure, even a little outline of the man in the corner like you've seen elsewhere, with the hand red indicating that it's too damaged to use. But, no, not with individual hit points. If I hit your hand twice, either one or the other will incapacitate it, the effects do not add up in some linear fashion.

    How, then, do we find out if the character is killed? Well, that first assumes that this should be a possibility. But, let's say we want this, a character is killed when he takes the sort of injury that causes death. Actually he'll be incapacitated by things like shots to the heart, and actual death will occur, as it always does, when the brain doesn't get enough oxygen. Instant death is caused only by shots that destroy a significant portion of the central nervous system.

    All of this could be modeled. Pretty easily, too. Sure you'll still be using some abstractions. But they'll be ones that make gameplay into something other than resource management. It'll be wound assessment as compares danger levels. In fact, I wouldn't mind if this didn't much matter at all as a tactical concern, because that's largely how it is in real life. That is, if you get any injury at all in real life, your flight instinct will come on. That's not a bad model for such a game either. It could either force you to run, or, like real injury, it could simply make it so that continuing to fight would be a rather difficult thing to do in many situations. Leg out of commission? Well you'll probably fall down then. And you certainly can't do HTH combat well. You can still shoot maybe. If the pain isn't making things dizzying.

    I understand that the game The Ship actually has a model that, at least, is pretty lethal, if not precisely what I'm talking about here. The paradigm there is finding out who your assassin is, or who is out to assassinate you. Really these things are far more important than who has what weapon. RPGs have simply taught us different.

    But HP are just one small dimension of one sort of character interaction. What about models for social interaction? At the moment it's "Do you have the widget this guy needs, to get the key from him" largely. No way to do better than that? Economy modeling is done very well in something like "Capitalism" ...why can't RPGs have something like that built in to simulate changing economic conditions (sometimes caused by character actions)? Why are such models still based on the bookshelf game "Stocks & Bonds" which had the limits of rolling 2d6 (or drawing cards in some editions)?

  • Operation Flashpoint works just like this, I believe. Highyl lethal modern-era FPS game. Head or toso = kill. Hits to leg tended to make you gimpy, or even unable to stand. Arm hits make your weapon sights much harder to aim. Awesome game, niche-market product made by an independant developer out of the Czech Republic.
  • I believe the '80s RPG that I was speaking of before (the one with the body outline bit) had elements of this as well. If a character's head went black, they were dead, regardless of their hit point total. If I remember right, a character whose head went red was unconscious. (This was one of those games where you play a whole group, not just one character, so it wasn't too horrible to have happen.) The system also enforced penalties for black, red, and yellow body areas, but these weren't so visible since they were automatically figured in.

    Of course, there are paper RPGs that have damage systems of these sorts as well -- frex, CORPS.
Sign In or Register to comment.