A Problem Existent In Past Thief Games

[woah]

Well, if you do create some sort of AI recognition of silhouetted players, it wouldn't necessarily need to be implemented in an exactly realistic form. Thief doesn't disapoint me in that it is unable to simulate a mirrored instance of reality, but, more or less, that there are many situations in which I find it rediculous how unaware and blind the AI is--and thus the game presents itself as no real challenge. If such a feature is extremely discouraging to the player, I would first see to that the AI's recognition system relative to such a situation is not too sensitive in its responsiveness, and then tone it accordingly.

[Forsaken]

And there is always the difficulty level.

[New Horizon]

I'm not interested in extreme realism. I want to be challenged but not at the expense of the gameplay. If we're talking about having AI realistically react to shadows and light, then the game will no longer be playable. I tested the limits of realism with the Minimalist Project and jacked the AI vision and audio sensitivity, way the hell up. The game totally lost the gameplay dynamic that made it fun...guards spotted you realistically...yes, but reality in exchange for gameplay...at least in this case, was a poor idea. There are some things that can be made more realistic, without unbalancing the gameplay but the hide and seek dynamic of Thief has always been one of the most fun parts of it. It almost has an innocence about it.

[sparhawk]

Any mission author could just put a tiny light in any doorway that needed it. If you made it small enough to not touch the door jam you wouldn't even know it was there, but it would show the player as more visible.

 

There is no real need for that in Doom 3 because that bug in Thief, that you went totally dark when standing in a doorframe, is not present in Doom 3 as it is a unique bug for Thief.

[sparhawk]

That's why, if we ever do find a way to implement it, we'll do extensive playtesting before putting it in the final version.

 

It's not a question of how. We already know how to do it, we already have code in place that could easily be modified to support silhouetting. the only reason we can't put it in, is because it will make any map slow to a crawl when more then one or two AIs are looking for you.

[sparhawk]

Actually we could allready support a crude form of silhouetting with the current code in place and with practicaly zero performance overhead.

[Ishtvan]

It's not a question of how. We already know how to do it, we already have code in place that could easily be modified to support silhouetting. the only reason we can't put it in, is because it will make any map slow to a crawl when more then one or two AIs are looking for you.

 

Okay, I guess I should say if we ever find a practical way to implement it.

[Maximius]

Actually we could allready support a crude form of silhouetting with the current code in place and with practicaly zero performance overhead.

 

 

Tell us more, Grand Architect of the Code, we beseech thee!

Edited November 29, 2005 by Maximius

[morricone]

It's not a question of how. We already know how to do it, we already have code in place that could easily be modified to support silhouetting. the only reason we can't put it in, is because it will make any map slow to a crawl when more then one or two AIs are looking for you.

 

There's no need to do silhouette test more often than 2 times per second.

 

Have you ever thought of implementing it as a fragment shader? They should be fast enough to do a quick test. But I'm still thinking of a way to do it.

[sparhawk]

Tell us more, Grand Architect of the Code, we beseech thee!

 

Since I take a snapshot of the player, I could make the snapeshot such that it is one pixel smaller than it needs to. In this case the surrounding would show through. From this we can determine if the player is in front of a brighter thing and we could check which AI would be in a range that matches the angle. Of course then we would be back to four renderpasses instead of two as we have now.

 

But we already discussed such an approach many moons ago IMO.

 

Anybody got the unintended reference to Harry Potter?

[AtariThief]

This has already been studied and a reason for this "disappearing act" was given. It seems that Garrett is an aprentice/master under the keepers. The training does some cool trick to make the Thief invisible when in darkness. Essentually a cloaking effect. Just give the same reason for the mod if you like.

[OrbWeaver]

Have you ever thought of implementing it as a fragment shader? They should be fast enough to do a quick test. But I'm still thinking of a way to do it.

 

A fragment shader is totally useless for this, as it is a function performed by the graphics card at the very final stage of rendering. There is no way of getting information back from a shader into the game, and even if there were the shaders are so limited in scope that they would not be suitable for this anyway.

[bob_arctor]

Well to Bardic surely if you put a tiny light inside the wall because it's dynamic it would not nothing, and if it's floating in the doorway then you will see it.

 

And to Ishtvan: you are giving FM authors the power of sound propagation aren't you? Thief II FMs have relied on the authors. Making them just put a little doorway tag (maybe even linked to sound propagation) isn't hard. Especially as if it's set by default by you guys to a good amount so they would work hard to cock it up. Default being a small increase in visability.

 

I didn't know there was total darkness in tII doorways. Well there was in those deep ones, but I never really thought about it. Just got used to it.

 

Sounds interesting way of checking for silhouetting but I still think a doorway penalty, even just for simming the fact AI look where they're going, i.e., through doorways, not to their sides (periphreal vision). So you wouldn't stand in doorways happily, you have to see as well as you can through from the room before, chose your moment, and go for it!

Edited November 29, 2005 by bob_arctor

[sparhawk]

Why in hell would a doorway justify a penality??? I don't get it.

[Mr Retarded]

Speaking of doorways, will there be any way of looking through doors without opening them fully? Such as looking through a key-hole or only opening it a little bit?

[sparhawk]

Nope. We discussed that idea, but there are enough advantages for the player already against the AI, so we don't want to have another one.

 

It can be added if somebody wants it, as a seperate mod, but it will not be in tour official build.

[OrbWeaver]

I liked the door opening method in Raven Shield, where you would use the mouse wheel to carefully ease a door open or closed.

[Ishtvan]

You can open the door only a little by frobbing it to open it, then frobbing it again quickly to stop it before it opens all the way. [Disclaimer: Don't know if this is a permanent feature or not, just how it's set up in the current build]

 

Even using the borders around the 4 rendershot idea for silhouette detection is still not accurate, because there are holes in the camera coverage where a bright background would be ignored (think about a bright wall at a 45 degree angle so it's right between two perpendicular render shots, and an AI looking at an angle that includes the player and that wall).

 

... you are giving FM authors the power of sound propagation aren't you? Thief II FMs have relied on the authors.

 

Yes, we're trying to make it as customizable as possible, so that FM authors can play suspicious sound with script, define a new suspicous sound and put in the parameters, and define a unique script that can run on AI and things in response to that particular sound, if desired.

[obscurus]

I'm not interested in extreme realism. I want to be challenged but not at the expense of the gameplay. If we're talking about having AI realistically react to shadows and light, then the game will no longer be playable. I tested the limits of realism with the Minimalist Project and jacked the AI vision and audio sensitivity, way the hell up. The game totally lost the gameplay dynamic that made it fun...guards spotted you realistically...yes, but reality in exchange for gameplay...at least in this case, was a poor idea. There are some things that can be made more realistic, without unbalancing the gameplay but the hide and seek dynamic of Thief has always been one of the most fun parts of it. It almost has an innocence about it.

 

 

I am, however.

 

I guess it depends on what sort of 'gameplay' you want, and what you mean by playable. For me good gameplay means sneaking around is just as difficult as if I were in a real, populated mansion trying to sneak around. For me good gameplay means using cover to hide behind, rather than being invisible in shadows. Shadows should help, as they do in RL, but you are not invisible or undetectable in them.

 

I've played Thief to death a zillion times, and I now find wandering around invisible in shadows somewhat boring and unchallenging. I guess you could say I find it excessively playable. It is ridiculously easy to prance around in the shadows without the AI seeing you, even though you know that they should if they were real people in the same situation. That is bad gameplay IMO. I want the option to jack up the realism of the game to a level that is generally approaching what I would find in RL (as far as is possible with current technology). I want a much, much, much more intense challenge. I want daytime missions where there are no shadows to save you, and careful timing and patience are the only option. I want an extremely frustratingly difficult game that takes hours (days) of painstaking sneaking to finish a level. I want AI that will see, hear sense me as easily as a real human opponent would, in much the same way a real human would. I want to do it all without the use of weapons, and limited gadgets.

 

I understand that I am probably in the smallest minority, and that I can't expect anyone to cater purely to my eccentric tastes, but it would be nice if at least there was the option (through difficulty settings or what have you). And if there is an implementation of sillhouettes that is not going to kill my framerates totally, even if it is not perfect, I'll take it.

[morricone]

A fragment shader is totally useless for this, as it is a function performed by the graphics card at the very final stage of rendering. There is no way of getting information back from a shader into the game, and even if there were the shaders are so limited in scope that they would not be suitable for this anyway.

 

Don't get me wrong. This is what I have thought of so fare:

For each enemy which can see the player, do

1. An RTT from the enemies postition pointing at the player. Use special matierials for that. e.g. the player has alpha 1, the rest alpha 0 and the lighting as a monochrome palette. (for this the RTT surface doesn't even have to be that big)

2. Let a fragment shader decide wether the contrast is high enough so that the player silhouette can be seen. (IIRC you can pass pointers even in shaders around (but I could be wrong))

 

This should be fast enough, but I don't know the D3 engine very well so the material changing isn't maybe very easy to do. And only people with a compatible card can get this extra difficulty.

 

If some points aren't clear (because of my languange ) don't hesitate to ask me.

 

edit: mmh... I just thought over it again and there still would be a problem if there's a very small bright surface directly behind the player, but that should be negligible.

 

It just so happens that I've got another idea

For each enemy which can see the player, do

1. An RTT from the enemies postition pointing at the player.

2. An RTT from the enemies postition pointing at the player with the player model invisible

3. Check wether there are big differences between the two images.

Edited November 29, 2005 by morricone

[Ishtvan]

You can do that, and it will be accurate, but the problem we encountered (Sparhawk will correct me if I'm wrong) was a significant bottleneck in transferring the rendered image from the GFX card to RAM in order to do image analysis on it. Right now we do two extra renders to get data for the lightgem, but even this can slow down performance a lot on some systems. Sparhawk did tests with rendering more than two images, and I think it's safe to say that doing an extra image for every AI that's looking at the player would lead to an unplayable performance.

[sparhawk]

That's right. The problem is not the speed of the hardware, because GFX cards and CPUs are fast enough to do this. The real bottleneck is using the GFX hardware to do something and get it back into the program to act upon it.

Consider this. When I runt he lightgem, I do a renderpass of the full scene to determine how bright the player is. When I render this to a texture the performanceimpact is practically zero. The scene is rendered to a texture and what happens is that the CPU instructs the GFX card to do this. When I add the single function that retrieves this texture back from GFX card memory into the main memory, so the program can use that info, the framerate is reduced about 10FPS per second on average. One should thing that rendering the entire scene is MUCH slower than transfering 16KB of data fmo the GFX memory to the main memory, but it isn't. The transfer of the 16KB is MUCH slower then anything you can throw into the renderengine.

Shaders also are run on the gfx card, so you would have to transfer back the data into the main program somehow.

 

The problem with this is, that this interface dates back to the times of early EGA and VGA adn it has been improved only in one direction.

[OrbWeaver]

Does a mirrorRenderMap use the same RTT mechanism? The performance seems fine for mirrors but maybe it uses some other kind of hack.

[Ishtvan]

That information sparked an idea: There is probably no way to do this without access to the renderer, but, what if we could write the image analysis into the shader itself, and have the GFX card return only the 32bit float result to RAM, rather than the whole 16Kb image?

 

(I don't know what the best way would be to have a shader return something to RAM, maybe we could use the image capture again, but have the image be of some dummy texture that is just 1 pixel, where the brightness value of that pixel is written by the shader that has done image analysis on the whole image?)

[Ishtvan]

Does a mirrorRenderMap use the same RTT mechanism? The performance seems fine for mirrors but maybe it uses some other kind of hack.

 

Images from the mirror textures don't have to go back into main RAM, they can just be displayed as a texture from the GFX card straight to your monitor. That's why it doesn't cause any noticable performance drop ( I think ).

 

Both the lightgem and the potential silhouette detection system have to be accessed by the AI though to gauge their responses, so they have to go back to RAM.