ZylonBane

Ook.

Note the title of the thread. Would you feel better if this were moved to Off-Topic?

The inclusion or not of health potions is not a core game mechanic. Whether archers are armed with regular Nerf arrows or razor-tipped Kill-O-Matic arrows is not a core game mechanic. The damage model, however, IS a core game mechanic, independent of damage stimuli (both positive and negative). So if you want to talk about that, talk about that, and stop trying to muddy the waters. Well, unless you realize how weak your argument is and are muddying the waters on purpose in an ineffectual attempt to confuse things even further. See, that's the fundamental problem with your proposal-- there's no such thing as "luck", except in the vernacular sense. Probability theory does not recognize the concept of luck. What you're suggesting is that the odds of performing any particular task should degrade over time, which not only has no basis in reality, but pretty much runs counter to it-- in real life, you generally get better at performing tasks the more you do them, not worse. If your system were implemented consistently, the player would eventually die just from walking. It seems likely that what you really want is a simulation of a foul-tempered DM watching over the player, throwing a hissy fit and killing the player when they consistently roll "too good". If you don't want the player to consistently succeed at something, just give that thing a low base probability of success. There's no need to monkey around with some screwball decaying-luck system. WRONG. If the system can change state to penalize the player, then that state change can be reverted. It's all just numbers. You do realize that, don't you? Of course a game could be created that didn't include health potions, but that would only be because the designer decided not to include them, not because there's anything intrinsic preventing them from being implemented.

And this is yet a THIRD argument you keep trying to combine with the other two. A "health potion" is nothing more than an item which modifies one or more variables internal to the damage-modeling system. Such items can exist for any possible system anyone could conceive of. Your own "luck multiplier" system could have the player picking four-leaf-clovers to increase their luck. So let's see if I can sort out your muddled mess-- First argument-- hit points are silly Second argument-- players are allowed to take too much damage Third argument-- items which allow instant recovery from damage are silly Arguments #2 and #3 are entirely within the purview of FM authors, so that just leaves you with #1 as any sort of meaningful argument. So, what was it you were saying about the more often the player does something, the less likely they should be able to do it successfully? Sounds rather counterintuitive, doesn't it?

The reason it hasn't been pointed out is because it's obvious to anyone who isn't being deliberately obtuse, such as yourself. The reason a single arrow has a 0% chance of killing a player at full health is this: Difficulty scaling. It has ABSOLUTELY NOTHING to do with the particular damage-modeling system, it has to do with the designer making a conscious decision that it takes more than one arrow to kill a player at full health. You're never going to get anyone to take you seriously if you keep confusing the design of damage-modeling systems with how they're used. So decide what you're arguing against-- unrealistic capacity to absorb damage, or unrealistic modeling of damage. They're two distinct arguments, and conflating them doesn't help anybody.

Anyone else get the impression that Oddity would be the least popular dungeonmaster ever?

Are you talking about a luck modifier that's applied automatically, or a special "luck" power that must be explicitly used? If the former, ugh. Sounds like a bandage slapped on a fundamentally flawed system.

Very, very low, of course. And reality manages this without a magic multiplier in the sky. So I don't see why you think one should be necessary.

You say you understand, then prove that you do not. Q. If I flip a coin 100 times and get "heads" each time, what are my chances of getting "heads" the 101st time? A. 50%. The exact same odds as every other flip.

No, it's PHYSICS. On average, object X, dropped from height Y, onto surface Z, will take N% structural damage. Conventional HP systems have a solid -- if highly abstracted -- grounding in reality. Your luck/multiplier system does not. In fact, the fundamental basis of your system is that past events affect the probability of future events-- which is one of the things that probability theory teaches us is absolutely false. Got woo? But what the heck, let's stick your multiplier onscreen as a bar. When it's full, you're chock-full-o'-luck and can survive almost anything. The more dangerous things you do, the lower it gets, and when it gets really low and you try something dangerous, you die. Well congrats Odd, you just invented the health bar. If the thing you hate so much is the deterministic aspect of the damage model, why not simply propose that a bell-shaped randomization curve be applied to all damage? In pen-and-paper RPGs, this is exactly what any multiple die roll simulates.

For some reason I'd expect an "*official*" thread to have less bletcherous proofreading of the title.

Keepers were only important for the plot. In actual gameplay you never interacted with a single Keeper (unless you consider the TDP training mission). Also, the concept of Keepers is dangerously specific to Thief, unlike the relatively generic city guards, religious fanatics, and tree-huggers that TDM is creating.

And replace it with WHAT, exactly? The concept of hit points exists for two excellent reasons-- First, the necessity of calculating the player character's physical status. A human's ability to function effectively is a complex aggregate of their health, constitution, endurance, fatigue, state of mind, and dozens of other variable factors. All this complexity cannot be modeled meaningfully in the relatively simplistic gameworlds currently available, so there's no point in trying. Thus, games abstract the whole mess into hit points, much like D&D's "armor class" concept is an abstraction of physical armor, reflexes, perception, etc. Second, there's the necessity of communicating health information to the player in real-time. In real life, you "just know" how your body is doing-- millions of nerves all feeding status reports to your brain continuously. Since games can't currently plug into the base of your spine, character health data *must* be represented in a way that can be mentally processed in roughly the same amount of time as it take in real life-- which pretty much leaves no option but a bar graph or two (or three). Then you have the question of why, at a certain point, the player just falls over dead. Again, there are two unimpeachably excellent reasons for this-- First, player "death" is merely (sometimes) an abstraction of the player character becoming sufficiently injured that they could no longer function effectively. Sure, yet another minor scratch or bump won't outright kill you, but they add up to degrade your performance. Can you go on with a twisted ankle? Yes. But can you go on with a twisted ankle, a scratched eye, bruised ribs, and a bleeding head wound? No. So the game just "kills" you. Yeah, it could instead put up a message like, "You're too beat-up to complete your mission", but the difference is purely academic so why bother? Second, when it comes to damage you have to draw the line somewhere. Fact of life, that. Games can degrade player performance instead of slaying them outright, but that generally sucks because it rapidly leads to downward-spiral situations-- you become less and less capable of dealing with whatever hurt you in the first place. It's usually better to just slay the player and let them start off fresh. If you were really as smart as you think you are, you wouldn't need all this explained to you.

Of course you do. You also want the computer to punch the player in the nuts every time they make the slightest mistake. Sorry, not all of us play Thief prostrate and naked with jumper cables attached to our nipples. Myself, I think an auto-hiding health bar is retarded. Health status is something I need to know before I take damage, not after.

Umm, did you even read what I said? SS2 already works exactly this way. Many people have experienced it, and found the experience pleasing.

I don't think there would be much point to such an option. The way TDM is currently handling readables is exactly the way System Shock 2 handles readables, and as far as I can recall nobody has ever complained about it. If anything, the only time it's mentioned is to praise it-- there's just something extra immersive about having to physically go find a safe place to hunker down before reading something. It elevates readables from "just reading" to something which the player must actually accommodate within the gameworld.

Jesus, I'm almost afraid to ask what Macsen is in charge of. Not anything important, I hope. The guy just seems... loopy.

Please, the only way a guard would be rendered invisible by a slight blurring would be if he were so far away that he was only a few pixels tall. You're essentially arguing that a slight decrease in screen resolution (from, say, 1024x768 down to an effective 640x480) would blind you. Clearly this is false. The human eye reacts more to motion than detail anyway.

I think most people were overreacting to the word "blur" anyway, as if I were proposing an effect similar to smearing Vaseline all over a camera lens. All I ever had in mind was a subtle but noticeable softening of the scene behind the readable.

Okay, no more Sugar Frosted Lead Paint Chips for you.

I'm sure it is. I thought I made it fairly obvious that my last post was being silly. However, now a serious suggestion-- how about, when viewing a readable, slightly blurring everything behind the readable? Y'know, to simulate the player focusing on something close. It would serve as nice subtle indicator that the player is in a "mode".

Aren't there virtual "render to file" plugins for OGL, specifically for generating print-quality screenshots?

Yeah, I figure it'll probably be one of those things that take two minutes to get used to. I'm just imagining-- "Hey look, I can read this parchment on the wall!" *click* "Woah hey, now there's two of them! Ahhh, it's on my face, get it off!!!"

Sounds shiny! It'll probably look a bit odd when you walk right up to a parchment, click it, and a clone of the parchment appears floating in front of you, but I guess there's no way around that.

Well, you've got the thumbs-up from the semi-literate demographic. Anyway, how will readables be rendered in-world? Will you just use a generic illegible-scribble texture, or is there any chance you could display the actual text? Seems like it wouldn't be too hard to auto-generate a low-res texture based off the full-size view.