Hold Your Breath?

[Gildoran]

I'd love to see a berserk-like effect with intensity depending on exposure.

 

Has anybody played Grand Theft Auto: Vice City? There's an interesting mission where you have to rush a guy to the hospital, but you start off intoxicated. They had a great effect where they blended previous frames with the current one, leading to blurred vision and a time-lag between when you started to do something and when you noticed its effect. At time went on, the effect gradually and imperceptibly lessened until you were sober again.

[Dram]

LOL

 

It would be interesting to use the heathaze shader cos you could make it more intense as time went on hehe

[OrbWeaver]

Actually for gas-in-the-eyes a simple blur shader would suffice.

[Dram]

Actually for gas-in-the-eyes a simple blur shader would suffice.

 

True, but distorting the view may be an interesting touch. I guess we'd have to try it out to see which fits best.

[Springheel]

(And BTW, this is the one situation where doing it automatically seems a bit counterintuitive, since it's meant to be a trap ... but if it takes 30 seconds before any damage then it's a trap that doesn't cost anything. Logic-centric gameplay works better when there's a real cost to erring.)

 

There's no issue here. We already said that 'explosive gas' (gas arrows, etc) will damage you immediately, unlike 'environmental gas', which you would be able to detect. So if a mapper wants to make a trap that damages the player immediately, then they use explosive gas. If they want a timed trap the player can get out of, they use environmental gas. They can even use both together if they want to, hitting the player with a small amount of damage immediately and then forcing them to get out or take more.

 

None of these scenarios requries a hold breath key.

[Mr Retarded]

Would it be possible to set how much damage the gas does every successful 'hit'? That way, a trap could be set with extremely high damage on each hit. After all, don't you want the mapper to be in control of their traps?

[Dram]

I think that's the plan yeah.

[bob_arctor]

Of course automatically you have to remember that it wouldn't be *breathe in then hold* more a kind of *ulp!* closing of the mouth and holding chest still.

 

Which is great.

 

Automatic for the win.

 

Imagine though the reaction you'd get to a holding breath key outside this message board. Most gamers would think this is madness.

[SneaksieDave]

Agreed, it's unnecessary complexity. It's automatic in water, no player-perspective reason it shouldn't be consistently automatic in a gas trap, too.

[sparhawk]

I guess this is yet another feature where everybody "knows" front up that it is BAD but when it is implemented and in use, suddenly it is found usefull.

[OrbWeaver]

Are there any examples of such features from past experience?

[sparhawk]

Sure.

 

In principle. Almost EVERYTHING that has been proposed beforehand, has been argued to death, by one or the other member, while features that were just introduced, without much propsing it first, usually were accepted as being good. I don't recall any feature, that has been introduced in such a way, that has been thrown out, because people didn't like it.

[Springheel]

There's not exactly a long list of things that fall into that category.

 

And just implementing features without any discussion isn't exactly the best workflow for a team effort.

[sparhawk]

Stereotypic discarding is also not a good workflow.

[Springheel]

Well, you're right. Any time someone proposes an idea, there are really only three responses. Either you like it, you don't like it, or you're not sure. So over the course of the past two years, all three options have become 'stereotypical'.

 

But that doesn't turn a bad idea into a good one or vice versa.

[OrbWeaver]

In principle. Almost EVERYTHING that has been proposed beforehand, has been argued to death, by one or the other member, while features that were just introduced, without much propsing it first, usually were accepted as being good. I don't recall any feature, that has been introduced in such a way, that has been thrown out, because people didn't like it.

 

Is it not the case, however, that the sort of features that are implemented without discussion are the sort of features that would never have stimulated much argument?

 

Otherwise the developer probably would have discussed the idea beforehand, in order to avoid working on a feature that nobody wanted.

[sparhawk]

Just an example. The readables were implemented in a way that is not the same as in Thief. It was not announced, it was just implemented. I bet whatever I have, that, if the coder would have announced it beforehand for discussion, it would still not be done because everybody would say how this would not be neccessary in this way or that it should be done in another way and so on. As it is, it was implemented and everybody liked it.

[demagogue]

Heh ... this is called the inheretance (or entitlement) bias in economics/cogsci ... people having affinity for (or at least overvalue) something they already have, but are skeptical of (or undervalue) something that threatens to change what they already have, even if it's the *same* feature introduced in different contexts.

 

I tend to think that the more transparency the better ... try to present options in both contexts if you can, so ideally you'd have the skeptical discussion and a little demo of a "nonstandard" option so people can see how it feels in-game going on at the same time (and force the skeptics to frame their arguments in terms of how it plays out). Hard to get rid of the bias totally, but you can recognize it's there and you can let the two sides of it counteract each other in some respect.

 

Anyway, I guess if I think about it, both DX and T2 both used discrete gas-stims even for rooms that were supposed to be gas filled and that worked for most trap-purposes. And now you are talking about adding something more constant & water-like ... automatic? hmmm ... I can see it both ways. I guess I have nothing new to add, except:

 

ZB: re: no first -breath sound, I'd think if you're going to have any breath-holding at all you might want *some* audio-cue. It doesn't have to be an elaborate *huupf*, but something small and telling, an *ugnh* (?). It might be strange either running through corridors or walking into a dark room, before the player registers the gas, and all of a sudden a *breath-left* meter pops up (although altered vision would help). I know it doesn't happen with water, but then again it's always obvious that you're in water, but it might not be obvious you're in a gas chamber for a second. It might not be missed, but it's just an intuition.

Edited April 27, 2006 by demagogue

[SneaksieDave]

And thus, we've achieved meta-arguing.

 

What are good reasons for including another key, another action, the complexity surrounding it - instead of just using the mechanic that's already there for the same reason?

[Mr Retarded]

A good reason for adding the breath holding feature is the puzzle increase. Take any standard puzzle. Stick it in a gas filled room. Standard, 'realistic' puzzle timer. If you fail to complete the puzzle before you run out of air; You die.

 

Regarding complexity. Something is only as complex as you make it... While I don't know anything about coding, I'm sure that (mostly nonsense) sentance still stands.

Edited April 27, 2006 by Mr Retarded

[demagogue]

A good reason for adding the breath holding feature ...

 

Yeah, but should it happen automatically?

[Mr Retarded]

Yes. Why make something more complex than it needs to be?

[Springheel]

Just an example. The readables were implemented in a way that is not the same as in Thief. It was not announced, it was just implemented.

 

That's completely untrue. We had decided most of the details about how we wanted readables to work. We wanted them to be real-time, we wanted to be able to see the world around the edges of the book/scroll. Gil just took that and applied it to fixed readables in a way that made sense.

[Dram]

Imagine though the reaction you'd get to a holding breath key outside this message board. Most gamers would think this is madness.

 

Not true, many fps games have the holdbreath key when using snipers to be more accurate when shooting.

[Darkness_Falls]

That's completely untrue. We had decided most of the details about how we wanted readables to work. We wanted them to be real-time, we wanted to be able to see the world around the edges of the book/scroll. Gil just took that and applied it to fixed readables in a way that made sense.

I have to back Springheel up here. We did discuss, at length, making readables real-time and seeing around the edges, etc. Gil was the first to actually put something like this in action, and so far it's a nice, intuitive, efficient and concise solution. I like it better than Thief®-style readables. Until I see something better, it has my vote so far.