Jump to content
The Dark Mod Forums
Sign in to follow this  
woah

A Problem Existent In Past Thief Games

Recommended Posts

There is a certain problem existent in all past Thief Games that often irritated me during gameplay. It consists of a situation in which you, the player, are in a shadowed, dark area, but the remote background behind the player is lit in bright light. An AI-guard or -servant positioned in the foreground approaching the player would not notice or emit even the least significant audible that they had realized your presence, yet it is quite apparent that--in real life--one would see the black-filled silhouette of the player against the brightly lit background.

My question is, would it be possible to employ a feature of which would make it possible for AI to notice you in such an instance? Likewise, would it be feasible (meaning that one of your poor coders wouldn't have to spend months of day and night headbashing, solving a near impossible logical conundrum that would, in turn, only distinguish itself applicatory in a rarity of situations)?

Such a feature would need to have its own schema as an AI's perception of your presense in the above situation would be further dependent their distance and the intensity of light in the background.

Give me your thoughts on this :)

Share this post


Link to post
Share on other sites
It's been discussed at length in some threads, do a search for "silhouetting."

As it stands currently, we thought we might have a way to do it without much modification to the current lightgem, but it turned out not to perform well enough to be feasible. I wouldn't say we've given up on it, but it's on the back burner for now. If you have any implementation ideas that weren't already mentioned, we're always open to suggestions.

Share this post


Link to post
Share on other sites
Problem with silhouetting is, that it is a huge performance drain. We could do it with our current codebase, but it wouldn't help because it would not run in reasonable time.

Share this post


Link to post
Share on other sites
Sparhawk, is it possible to create a sound that could only be heard in one direction on a map. Say the Thief is in the middle of a long east/west hallway, with a guard on either end. Its it possible to create a sound that only travels in a westerly direction, so that the western guard would be alerted but the eastern one would not be?


Heres why: If its possible to make a unidirectional sound, it seems that a zone could be constructed along any area that in RL would present a danger of backlighting that could mimic that danger by emitting a sound that +only+ travels away from the source of light. The player would not hear this noise either and could not avoid making it unless he or she avoided that path. Any AIs "downwind" a certain distance from the direction the sound travels would be alerted as if they had seen a silhouetted figure crossing a patch of light but AIs between the Thief and the light source would not be alerted at all. If such a zone is possible, map builders could place them along the lines of sight of light sources, using their best judgement to guesstimate the range and area of the "backlighting danger zone" for each. For a source of light that radiates in all directions, like a lantern in the middle of an empty field, a series of zone similar to a cut pie or the sections of an orange could be constructed with the light source at the center. Each section of pie would send a slight differently oriented unidirectional sound out moving away from the light sources. If the sections were thin enough, it seems it could effectively mimic the backlighting danger of such lighting scenairo.

One problem is this: Imagine Im the thief sitting in one of these zones with the sound heading east. A guard is downwind from me to the east, but his back is to me. He should not be alerted by backlighting but because its a sound he would be, an unrealistic development. Perhaps one way to accomodate this would be to have the AIs constantly glancing from side to side, so that even if his back is to the Thief, the players suspension of disbelief could probably accomodate being spotted due to a chance sideways glance. Are these sounds possible, and if so, is the idea feasible in terms of processor consumption, yada yada yada? Edited by Maximius

Share this post


Link to post
Share on other sites
Ah, it's what I feared.

Anyways, just so this thread isn't a total waste, I have an unrelated question about programming in general.

I started learning Java Programming not too long ago in college, and I'm enjoying it very much. If my other classes didn't consume so much of my time, I would dedicate more of my own personal time to it. Being that you all seem to be quite learned in programming, I would be curious as to how to approach programming for games.

One of my questions is, why is C++ preferred over Java in game programming? I've also heard C++ and Java are quite similar to one another. Does anyone here know both Java and C++? If so, could they explain to me the general differences?

Lastly, being the experienced programmers that you seem, could you direct me to some good beginning C++ programming tutorials, and game programming tutorials? Also, could you give me any pointers as a novice--but eager--programmer just recently only sticking his toes in the water? To give you an idea of how much of a newbie I am, the most complex program I've ever written is one in which calculates the greatest common factor of an indefinite array of numbers. Edited by woah

Share this post


Link to post
Share on other sites
[quote name='woah' post='49091' date='Nov 27 2005, 10:36 PM']To give you an idea of how much of a newbie I am, the most complex program I've ever written is one in which calculates the greatest common factor of an indefinite array of numbers.[/quote]

To make you happier, I don't know how to do even that...

Share this post


Link to post
Share on other sites
[quote name='Forsaken' post='49093' date='Nov 27 2005, 10:40 PM']To make you happier, I don't know how to do even that...[/quote]

Well, I'm sure my algorithms in the program are inferior, but I formed it in a way that avoided wasting memory by averting storing every singal factor of each number. All I know is that it had a lot of 'if' statements...

Share this post


Link to post
Share on other sites
The reason C++ is prefered over Java is mostly speed, I think. C++ is compiled into the computer's native bytecode and can be run directly by your computer, so it's quite fast. Java on the other hand is compiled into a machine-independant bytecode. In order to run a Java program, your computer has to run a simulation of another computer that runs your java program. Since emulating another computer takes quite a bit of overhead, Java programs run much slower than C++ ones.

There's nothing wrong with using java for games that won't be taxing your computer's resources (except that it usually requires the person running the game to have a Java environment), but if you want to write a game where every bit of CPU and memory count, you should probably do it in C++.

[b]Edit:[/b] As for learning C++, I would probably recommend starting with C to get used to working with [i]pointers[/i] and [i]structs[/i] ([i]structs[/i] are similar to [i]classes[/i]). C++ is merely C with a few features tacked on to make it easier to write object-oriented programs. Once you know C, C++ is a breeze (especially if you know Java). Just stay away from templates. ;) My favorite C book is the one by Brian W. Kernighan and Dennis M. Ritchie, since the book is quite concise and the authors of the book created the C language. As they put it, "C is not a big language, and it is not well served by a big book."

Share this post


Link to post
Share on other sites
To woah - do you know what the line #include <iostream> means? My Visual Studio 2003 doesn't seem to like it... I never wrote in C++, in C# only, but got along some C++ tutorials and wanted to look into it. It's a regular Hello World program.

"but I formed it in a way that avoided wasting memory by averting storing every singal factor of each number. All I know is that it had a lot of 'if' statements..." - why are they stored in the first place? Aren't they supposed to be destroyed automaticly? I don't think C++ has a garbage collector, but there must be a function to tell the program not to store anything. I mean, the program calculates the factor, displays it, and shuts down, right?

Share this post


Link to post
Share on other sites
[quote name='Maximius' post='49086' date='Nov 28 2005, 03:13 AM']Sparhawk, is it possible to create a sound that could only be heard in one direction on a map. Say the Thief is in the middle of a long east/west hallway, with a guard on either end. Its it possible to create a sound that only travels in a westerly direction, so that the western guard would be alerted but the eastern one would not be?[/quote]

Sure it COULD be implemented, but this doesn't help to fake silhouettes. Silhouettes are dependent on the relative position of a light the AI and the player, so you can not cerate a generic silhouette.

Share this post


Link to post
Share on other sites
[quote name='woah' post='49091' date='Nov 28 2005, 04:36 AM']One of my questions is, why is C++ preferred over Java in game programming? I've also heard C++ and Java are quite similar to one another. Does anyone here know both Java and C++? If so, could they explain to me the general differences?[/quote]

C/C++ is directly translated to machinecode while Java is interpreted via a virtual machine, which makes it much slower and not suitable for high performance games. Also the memory managment is not very suitable, because you never know when the garbage collection decides to do it's job, which makes it unpredicatable.

Share this post


Link to post
Share on other sites
@Maximus: I just wanted to add that, I don't think the faking directional sound solution would work for silhouettes, because you're not just calculating whether the player is inbetween the AI and a light, but you have to calculate whether the player is contrasting with something that is lit by some light, which may be somewhere else entirely. I.e., a light could be somewhere off to the side, hitting a wall, but the bright wall would silhouette the player to an AI that looks along an angle that puts the player in front of the wall.

The problem is, without access to the renderer, we can't really tell if the wall is bright without either calculating the lighting ourselves along various points on the wall surface, or capturing an image of the wall (from the point of view of the AI). Both of these things have so far proven too slow to be practical.

Share this post


Link to post
Share on other sites
[quote name='Forsaken' post='49098' date='Nov 27 2005, 11:37 PM']To woah - do you know what the line #include <iostream> means? My Visual Studio 2003 doesn't seem to like it... I never wrote in C++, in C# only, but got along some C++ tutorials and wanted to look into it. It's a regular Hello World program.

"but I formed it in a way that avoided wasting memory by averting storing every singal factor of each number. All I know is that it had a lot of 'if' statements..." - why are they stored in the first place? Aren't they supposed to be destroyed automaticly? I don't think C++ has a garbage collector, but there must be a function to tell the program not to store anything. I mean, the program calculates the factor, displays it, and shuts down, right?[/quote]

Well right, I didn't actually store it, just initialized some variables for the simple computation of the GCF; my teacher likes to refer to "storing" in the sense of declaring and initializing variables. In fact, I haven't even learned how to store data computed from a class in a file yet.

[quote]do you know what the line #include <iostream> means?[/quote]

No idea D: Edited by woah

Share this post


Link to post
Share on other sites
C++ is not a good language for learning the fundamentals of programming. It is complex and full of nasty things that are important in high-performance applications but not helpful in learning how to design programs.

At uni we started with ML and then moved onto Java for object-oriented stuff. Personally I think Python is an excellent language for education as it is as simple to understand as Basic but with all the power of more advanced languages like Java.

Share this post


Link to post
Share on other sites
Java is what I learned in and its a good language to learn in. He's already done it so he might be ready for C++ like I was after I finshed myJava course.

Spar nailed it, with the differences between the two.

As for getting started, do a search for "Learning C++ in 21 days", I use it as a reference, its very very good. It's a free online book.

Share this post


Link to post
Share on other sites
Argh, I posted a reply with some simple diagrams I had dreamt up but they got all screwy with the formatting. Thanks for your responses guys. Edited by Maximius

Share this post


Link to post
Share on other sites
How about a (not massive) lightgem penalty at doors, maybe optional. Just to simulate blocking out light. I think it would be understandable, if you imagine a thief in dark clothing on a wall it could escape your attention because you don't focus on the wall. At the least though you will look a lot more at a doorway, and only if it's pitch black will there be no silhouetting, at most darknesses you would see a shape blocking the light.
So maybe: If 100% black, no penalty
Less than 100% black in area around player, lightgem penalty.
Or maybe an option for mappers to set penalties for doorways they see will be silhouetting.
Obviously not realistic or always working, but a good addition I reckon. It'd make you think twice about standing in doorways for a start.
This wouldn't be a massive penalty because otherwise you'd be creeping through a corridor then BANG guards would be saying "KILL HIM" because your lightgem was shining away. Maybe just enough for them to go "hmm what's over there?". Edited by bob_arctor

Share this post


Link to post
Share on other sites
One has to be wary of increasing the realism to such a point that the game no longer becomes fun to play. In reality, remaining unseen in anything greater than total darkness is exceptionally difficult, but a game that was this difficult would be more frustrating than enjoyable.

Share this post


Link to post
Share on other sites
I reckon just a simple "don't stand in doorways" rule would add a bit of realism plus add a new gameplay thing, that you have to be in or out, so time your moment to slip past.

Share this post


Link to post
Share on other sites
Logical fallacies aside, I believe that silhouetting--though realistic--would only prove to frustrate the player. This is especially because the bright lit light emitting object is behind you; it's unlikely that you would realize that you were revealed when the enemy catches site of you, and it's also unlikely that you could guess why immediately. Edited by Ombrenuit

Share this post


Link to post
Share on other sites
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.

For wall shadows alerting the AI or similar specific backlight situations, you could probably fake that with volumes and scripts that when entered by Garrett could check which direction the AI is facing to see if he is facing the wall with the shadow, or facing the light source that Garrett is standing in the way of. Maybe 2 or 3 volumes each covering a 15 degree arc. Only to be used in specific circumstances where the player can plainly see that the AI should notice something.

Share this post


Link to post
Share on other sites
Personally, I would not find it at all frustrating if the game were realistically difficult, as far as shadows and sillhouettes are concerned (I find it frustrating that the AI don't respond). Maybe I'm wierd. I like the idea of not knowing quite why or how the AI detected me, it adds spice and randomness to the game, while being more consistent with reality. Having the AI detect you visually more realistically just means you have to use natural cover more, rather than relying on the unrealistic ability to be invisible in the middle of the room. If you don't want to be seen, don't stand in doorways any longer than necessary. hide behind statues, pillars, whatever you can find. Look around you, look behind you. Is the wall behind you brightly coloured? Get away from it. Quite simple, you just have to adjust your playstyle to deal with the challenges the environment provides.

The problem is, everyone is trying to devise methods that simulate reality, which is very computationaly expensive, when the focus should be on a hack that gives the appearence of sillouhettes triggering the AI.
I think it shouldn't be too hard to devise a hack to simulate it on some primitive level. I do agree though, that if you can't find a method that gives acceptable performance, then we should wait until technology permits.

Share this post


Link to post
Share on other sites
Argh, this has been discussed a lot before. Yes, some team members have concerns that keeping track of silhouettes and AI lines of sight would be too frustrating, and others disagree. 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.

Even simple hacks introduce a lot of complications if you think about it: How does the system know a doorway is a doorway? Are you relying on mapper placed brushes? If so, this is going to make the mapper's life hell, and may lead to maps with inconsistent behavior between missions and in the same mission if the mapper inconsistently placed the brushes. Those are the main reasons why special case brushes are bad.

Even if the mapper did place some entity for every single bright surface, how are you going to update this in realtime to match the dynamic lighting? You might find a way to update for torches getting extinguished (although it would be hard since you'd have to make sure the torch was definitely casting on the object and you'd still have to take into account other light sources that were still on), but what about moving objects in front of light to cast a dark shadow on a surface that used to be bright and have a silhouetting entity? There wouldn't really be a way to detect this, since again we don't have access to the renderer to check if the surface is still bright or not.

Share this post


Link to post
Share on other sites
Well, it looks like it will have to go in the 'too hard basket' for now... Not being a programmer I wouldn't know where to start in terms of implementing a framerate freindly form of sillhouette detection, so I can hardly expect anyone else to magically come up with a solution. All I can do is reiterate my desire to have the AI respond realistically to player shadows and sillhouettes as and when it becomes technologically feasible (which might not be possible with the D3 engine)... :)

Oh well...

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...