A Problem Existent In Past Thief Games

[Dunedain]

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.

 

 

New Horizon: Don't forget, when thinking about guards spotting you in Thief, you have

to factor in Garrett's special training with the Keepers. This gives him an ability to hide

in shadows that defies ordinary explanation. So what would be a "realistic" chance for

you or me trying to hide in the shadows being spotted by guards is not the same as the

chance a guard has to spot Garrett doing the same thing.

 

By the way, the Minimalist Project is just great! It made Thief III much more like Thief I

and Thief II, as it should be. In fact, I only played Thief III after the Minimalist Project

came out, because I wanted to experience it like Thief I and II, with as many of the silly things

Ion stuck in there (which I read about extensively before it came out) removed as possible.

It made the Thief III gameplay much truer to Thief I and Thief II, thanks!

 

I'm looking forward to The Dark Mod carrying on that fine tradition.

[Order of the Hammer Bureaucrat]

In case anyone's interested my most powerful computer is a PCI nVidia 5500 256MB video mem (not PCIe mind you) with only 256MB of RAM and 1.2 GHz Athlon and Windows XP. Although my main computer is a dual processors Pentium Pro 200MHz with 512KB on-die L2 cache each running debian. Yes, I'm a cave-man.

 

I will buy something with at least 16GB RAM and dual processor dual core as soon as I get a real job. maybe SLI with both cards installed.

 

I think the secondary processors should be used for things like AI and physics. Regarding Garrett's special keeper training alowing him to do what we can't do in RL: I always thought that the majority of his skill lies in mind manipulation of surrounding people, masking his thoughts and diverting their attention sort-of; and he can't do what some people can do in real life, look at the post here on the forums about the google video of russian climbing - if he could do that he wouldn't need rope arrows.

 

editing, just rememberd what I wanted to say, though not how it connects to the thread. A possibility is to use inexpensive USB "VR" gloves on both hands combined with a goggle display or surround monitors to eliminate the old "press forward to run, backwards to backstep, turn, strafe left, etc" buttons replacing it with touch here on the wall, slide your hand here, hold your fingers steady on the cleft, etc. Just look at the russian climbing video on google video how the guy runs and jumps. To an outsider, of course, a thief-player or more correctly a modded darkmod player would look like a freak waving his hands about and doing various mudras.

Edited January 2, 2006 by Order of the Hammer Bureaucrat

[DopeFishhh]

Hammer where do we get these vr goggles and gloves? I very much doubt they would be inexpensive

 

While we are comparing penis size computer specs, Dual opteron 252, 4GB ram, 6800GT, on a Tyan K8WE. Why you may ask? the Opteron 940 socket is on it's way out so i can stand to pickup some cheap 265's when they aren't so popular anymore. Also 4gb of ram is absolutely amazing, i can turn off swaping in windows, you wouldn't believe how often windows will hold you up to do some housekeeping. Furthermore even though most applications aren't multi threaded, windows is so you can still reap the multi cpu/core benefit with single threaded applications.

 

To enable 64bit mode on some programs can be as simple as a recompile with certain settings, though games will require a bit more effort on the programmers part to get 64 bit going. I'd say the start of 2007 is where you might see 64bit exclusive games coming out. and farcry had more than some extra content in 64bit mode, they completely removed the fog that hides the backplane culling and extended it out to cover the entire map (you can see further for those who didn't understand that).

 

And has anyone seen that new shakycam farcry tech demo video? pretty cool shit. I'll see if i can find a link.

[Dunedain]

AGP 8X has more than enough bandwidth for even the fastest video card. The only reason

they went to PCI-Express was so you could do SLI. Which is fine, but nVidia should not have

stopped making AGP video cards suddenly like that. It's ridiculous, I got a top-of-the-line system

just before the first PCI-E systems came out, and then immediately nVidia stops releasing new

AGP video cards, even though it wouldn't hurt the performance of the video cards at all to use

AGP 8X, and would force anyone with an AGP system to get a new motherboard for no good reason??

nVidia needs smacked hard for that, what a rip-off.

 

They should definitely release an AGP version of the 7800 GTX.

[sxotty]

AGP 8X has more than enough bandwidth for even the fastest video card. The only reason

they went to PCI-Express was so you could do SLI. Which is fine, but nVidia should not have

stopped making AGP video cards suddenly like that. It's ridiculous, I got a top-of-the-line system

just before the first PCI-E systems came out, and then immediately nVidia stops releasing new

AGP video cards, even though it wouldn't hurt the performance of the video cards at all to use

AGP 8X, and would force anyone with an AGP system to get a new motherboard for no good reason??

nVidia needs smacked hard for that, what a rip-off.

 

They should definitely release an AGP version of the 7800 GTX.

That is not true, there are many advantaged to PCIe the problem is that game developers will not utilize the new methods offered them by PCIe until AGP is dead for the most part. That unfortunately will take a couple of years. If you are wise you will sell whatever top AGP card you have while they get a premium, and buy a decent PCIexpress system instead. I sold my modded x800pro VIVO on ebay for a decent sum ($325) and did not feel bad about it.

[Dunedain]

sxotty: I'm not sure what you're talking about, other than giving a bit more power to

the video card slot (but you still need extra external power connectors conected to the

card for all the high-end video cards anyhow, so who cares), there's nothing I can think

of that PCI-E does that AGP doesn't do for a single high-end video card. Perhaps you

are referring to an ability to swap textures in to the video card from main memory faster

than AGP? But we all know that doing that will always cause a performance hit, you simply

must have enough RAM on the video card to handle the textures for the game you want

to play or it will hurt performance unacceptably for serious game playing. So that's a

non-issue, too. And neither of those things has anything to do with performance, which

is what matters and is what I was talking about in my post above.

 

So what are these performance advantages to PCI-E over AGP 8X you are talking about?

[sxotty]

So what are these performance advantages to PCI-E over AGP 8X you are talking about?

 

Calculating physics on the GPU would be an example of where PCI-E works better.

[Domarius]

From what I remember reading, the bandwidth can be made wider simply by devoting more PCIe channels to the slot or something, so in the same way we have been previously inventing the hard coded 4x, 6x, and 8x AGP, we can just simply devote more PCIe channels to increase the bandwidth.

 

I read somewhere that 4 PCIe channels was equivelant to 16x AGP... something like that.

[woah]

I makes me feel uncomfortable to know that it has been 6 days since someone has posted anything in this part of the forum. D:

[Ishtvan]

We're too busy debating features. The scary part is, that's actually true.

[Domarius]

I makes me feel uncomfortable to know that it has been 6 days since someone has posted anything in this part of the forum. D:

What, the public forum? Wouldn't it be better that we're tied up in the development forums than chit-chatting here?

[DopeFishhh]

there's alot of reasons to go to pci-express.

 

agp is a parralell bus, there are several problems with parralell busses that require extensive amounts of engineering to solve. for instance you need to make sure each trace is exactly the same length or some signals will reach the target faster than others skewing the whole transfer, and this is exaserbated when you up the transfer speed of the bus. also you introduce noise suceptability with parralell traces meaning your speed is further limited.

 

serial has the minimal amount of traces, look at sata vs pata cables now. and because the chip techonology has caught up we can run them at massive frequencies and completely eliminate the problem of only having 4 wires to transfer on.

 

pci express groups it's system into a node based point to point system, so you can split the channels up to provide all sorts of slot speed combinations. and now that there's less traces, motherboard manufacturers can more easily map out the traces between components, this equates to either cheaper boards or more components being placed on board.

 

as for why agp should be ditched? well if we decide to stay with old technology just because it might inconvienience a few people then we would still be AT cases, Parralell IDE, PCI graphics. AGP itself was just a modified PCI slot and there is alot of justification in ditching the standard in favour of PCI-Express.

[sparhawk]

If parallel busses have this problem, then why not go for parallel serial busses? It would require more wires, but you have the advantage of the serial bus, without the disadvantage of the parallel, because you could treat each serial individually and you wont need the signals to have the same length.

[OrbWeaver]

The amount of logic required to synchronise signals from multiple high-speed serial buses would make that very costly to implement compared with just increasing the clock speed of a single serial bus.

[sparhawk]

But I guess there is a limit to increasing the clockspeed.

[DopeFishhh]

They do that, thats what pci-e slots greater than 1x are, multiple pci-e links working together to transfer from one point to another. serial is using the minimal number of wires to transfer data. the way the pci-e standard works is that it's a point to point system, data travels along it much like data travels in packets over the internet. Using this system they've been able to solve the co-ordination problem.

 

There's some more problems with parralell that i forgot about. parralell is half duplex, meaning you can only transfer in one direction at a time. this is because you have too many wires to get full duplex transfers going. if you wanted to have a full duplex parralell bus you'd have to double the number of wires. if you already had a 16 bit bus that would mean you'd have to have 32 wires, it just gets too big. But with serial you only need 2 wires for half duplex and 4 for fully duplex.

 

not only that, because you couldn't possibly have enough wiring space to connect each individual regular pci slot up you need to make them share the bus and the bandwidth. pci-e divides up the bandwidth between the slots in fixed amounts, so a 1x couldn't hog the whole system it could use 1x max, 16x could use 16x max. i can't remember the speeds exactly you'd have to look them up but i believe that even a 1x slot has double the bandwidth of a regular pci slot and a 8x has double that of an agp 8x.

[Cyberwolf]

I've been thinking about the silhouetting issue and I'm wondering if there is a way for the actual brushes in a map (walls, entities and such) to dynamically "know" what color(s) they are? I know that somewhere in the way that the D3 engine calculates dynamic shadows and light, there has got to be some sort of collision detection routine...actually i have no idea how they managed to get the dynamic lighting to work.

 

For example, in D3, I point my flashlight at wall1. Does the flashlight "tell" wall1 to light up, or is all the lighting done independently of a map's brushes ever appearing in the code?

[sparhawk]

actually i have no idea how they managed to get the dynamic lighting to work.

 

That's pretty easy. For each light caclulate how far it extends. For each triangle in reach, calculate the amount of light based on the distance and angle and adjust it's colour according to the colour. The colour is determined by the texture obviously. Repeate this for each light that hits the same triangle.

 

This is the easy part. The hard part is to make this performant enough to actually use it in a game. The theory behind the lighting is the more easy part and there are already enough books that explain it in more detail. Of course you have to be moderately good in math to read them.

[Cyberwolf]

That's pretty easy. For each light caclulate how far it extends. For each triangle in reach, calculate the amount of light based on the distance and angle and adjust it's colour according to the colour. The colour is determined by the texture obviously. Repeate this for each light that hits the same triangle.

 

Ok, I'm trying to come up with a way that silhouetting will be able to be done without having to send snapshot textures back and forth from gpu to cpu all the time, but it's kind of a feature that will more or less have to be statically placed by level designers rather than it being a check the guards are able to perform anytime, anywhere.

 

In the graphic attached, imagine a square room. A guard is in the southeast corner, near a torch (the green lines are lit areas, the rest of the room is black). The idea is for a map designer to be able to place a sort of 'invisible light beam' entity, aimed specifically at areas where known silhouetting problems will occur. The invisible light beam is a totally invisible object, but imagine it casting an invisible floodlight on the brushes that it is pointed towards.

 

In step 2, the thief steps between the invisible floodlight, and the lit wall, which will cause an invisible 'shadow' to be cast against the wall, and a change in the "color" of the affected entities will occur, even though the player will not see this happen, as it is all done on an invisible color pallette. The idea is that if there is a guard who is looking in the direction of the floodlighted wall when the 'shadow' is cast, he will notice the silhouette, NOT because he himself was performing silhouette checks every 2 seconds, but because the actual WALLS give off an alarm when there is a dramatic change in the checksum of the invisible color.

 

I hope that makes sense? is it possible?

[Cyberwolf]

Actually from looking at the picture, I'm thinking that the object would certainly have to be carried by the guards to ensure correct angles, which actually would allow for the check to be done dynamically. The guards "pick" certain times and locations to "shine" their invisible floodlight lantern, and the brushes return a checksum of how much "floodlight" hit them. This would vary slightly as subtle lighting changes occur naturally, or as the guard's positioning may be slightly different, but the guard would certainly notice large changes in the amount of light. This might actually add another awesome way to distract guards (they get jumpy when they notice large changes in the area's lighting).

[Ishtvan]

We have no way of accessing how bright the walls are, no access to the D3 renderengine. I don't think something the guards carry and shine on a wall to get the brightness of the wall is going to work, for that reason.

 

You might try a mapper placed light beam entity, but there isn't a way to get separate parts of the wall to alert the AI specifically; the walls and all map geometry are all one entity called World. The walls aren't separate entities themselves.

 

What you could maybe do is have that mapper-defined light beam in place, then whenever an AI is looking at the player, do a trace just past the player on all sides and see where it hits something. When the trace hits something, check to see if the point of collision is also within any mapper-defined light beams, and you might be able to detect silhouetting.

 

There are some problems with that system though: The major problem is that mapper would have to place a light beam entity pointing at every single wall that's lit up, originating from the light or lights that are illuminating it. That would be a pain. Other issues: Different walls may be darker or lighter in color, i.e., differ in how much light they reflect, and the system has no way of knowing that from the information we can get (although maybe you could manually create a table with the texture names). With D3's dynamic lighting, you can push a crate around and create a shadow anywhere on the wall. The system would have to know when this happened, maybe using something like a trace from the light beam origin to the spot on the wall that was hit in the AI trace, and seeing if something would be in the way blocking the light beam. Also, you'd have to sync it with lights turning on and off.

[Cyberwolf]

We have no way of accessing how bright the walls are, no access to the D3 renderengine.

 

Gah, I guess there's no way that'd work then. foiled again

[bob_arctor]

Could you not allow us to see into the developement forums and watch the debates unfold?

[sparhawk]

You wouldn't want to spoil the surprise.

[Schatten]

To increase effectiveness in discussions, it was decided to resolve disputes in personal duells.

 

I'm still recovering from a gunshot wound oDDity gave me for suggesting a "Very Easy" game mode for beginner players.