Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Detection based on direction

Author
Message
Lord Herakles the Great
13
Years of Service
User Offline
Joined: 24th Mar 2011
Location:
Posted: 20th Jul 2011 10:44
Link
My game is a stealth game where the whole point is sneaking behind the enemies' backs. I already have raycasting to determine whether there is a clear line of sight between the enemy and the player (so that you can hide behind cover objects to break the line of sight) in the game and working beautifully. But that's currently the only thing that determines whether the enemy can see you. Even if you are standing behind the enemy, so long as there is nothing blocking the line of sight he can see you, as if he has eyes on the back of his head. How do I make it so that he can only see you if he is facing in the right direction?

Hail to the king baby
I love Evil Dead.
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 20th Jul 2011 11:06 Edited at: 20th Jul 2011 11:31
Link
Interesting question. Here is my suggestion: Calculate the direction (angle) between the player and the enemy. You can do it by making a (signed!) difference between their x and z coordinates and then using dbATANFULL to get the angle. Then determine the enemy's "sight range" by adding, maybe 35-40 degrees (how much is a human's peripheral sight?) to the right and left of his facing direction, and determine if the angle falls into that range. If yes, he can see the player.

(EDIT: corrected "x and y" to "x and z" coordinates, since y is vertical.)

(You need to figure out if you need the player-enemy or the enemy-player angle, i.e. in which order you subtract the coordinates from each other. I think it will be player minus enemy coordinates because we need to compare angles from the enemy's point of view.)

The angle comparison will be a bit awkward because you need to handle stepping through 360 (or zero) degrees in both directions. Maybe you can try to add a constant big number to all angles to avoid lots of "if" statements for values ranging around 360. For example, if the enemy is facing 20 degrees and his sight range (calculating with +/-40 degrees) is between -20 (=340) and 60 degrees, then add a constant 1000 to it, that makes a range of 980 and 1060. If you add a constant 1000 to the player-enemy angle as well, these numbers are already easily comparable. I hope this works as I think it should work...
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 20th Jul 2011 11:09
Link
P.S. This sounds an interesting game, I hope you will present it when it reaches beta stage.
Back to top
Profile PM
Lord Herakles the Great
13
Years of Service
User Offline
Joined: 24th Mar 2011
Location:
Posted: 23rd Jul 2011 06:29
Link
Sorry for taking so long to respond. I've been dealing with a different programming problem for the past two days.

That's some daunting math you described, Mireben. Advanced mathematics never was my favorite subject, so it will take some doing to get all that in my code. I'll have to think about it later, though, because I'm having an unanticipated problem with the raycasting.

I though I had it working, but evidently I was wrong. I've made it so that the enemy points at the player if there is a clear line of sight between the two. The problem is that the enemy is constantly pointing towards the player even if there is something blocking the line of sight (such as a cover object). Here is the relevant section of code:



I've been trying to make this work for the past two days and it feels like I'm banging my head against a wall. Is it blatantly obvious what's wrong and I'm just being an idiot?

Quote: "P.S. This sounds an interesting game, I hope you will present it when it reaches beta stage."


Of course! I might even give the entire source code with it (though I haven't made up my mind about that yet).

Hail to the king baby
I love Evil Dead.
Back to top
Profile PM
JTK
14
Years of Service
User Offline
Joined: 10th Feb 2010
Location:
Posted: 23rd Jul 2011 06:39
Link
My guess is this snippet here:



You're using the assignment operator= in both if statements that should be using the comparison operator==. Both if statements will always execute as it is right now.

Regards,
JTK
Back to top
Profile PM
Lord Herakles the Great
13
Years of Service
User Offline
Joined: 24th Mar 2011
Location:
Posted: 23rd Jul 2011 10:46
Link
Thanks, JTK! That fixed it! Yeah I often get = and == confused with one another.

I'll see about implementing Mireben's suggestion after the Weekend.

Hail to the king baby
I love Evil Dead.
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 23rd Jul 2011 14:23 Edited at: 23rd Jul 2011 14:41
Link
Daunting math? Come on, it's pretty simple. I've made a demo program to show how it works. Copy-paste the attached program into an empty Dark GDK project in Visual Studio and run it. Controls: arrow keys to move player (cube), A and D to turn the enemy sight around. The program shows if the enemy can see the player or not.

It took a few experiments to get it right. My "add 1000" idea didn't work out as I hoped, so if part of the enemy's range of sight is to the left and the other part is to the right of the zero angle point, then I have to check the angle in two parts. Also, I had to increase the originally suggested sight angle, because 35-40 degrees were not very realistic. Since the sight range is a cone, with a narrow cone the enemy did not see the player even if the player was standing right next to him. With a broader sight range (I used 70 in the demo, you can experiment with changing the enemyRange variable) it's much more realistic at close range but less realistic when the player is at a far distance from the enemy where the cone is too wide. Maybe you can fine-tune this method with taking into account the distance as well. You will see how well this works out for you. It's not perfect but still the best idea I can think of to solve this problem.

EDIT: Exchanged the attachment, I've made the "if" condition shorter.

Attachments

Login to view attachments
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 23rd Jul 2011 14:43
Link
P.S. The demo code looks long because I have to create and draw the objects and handle the controls, but the math itself is only this much:

Back to top
Profile PM
Lord Herakles the Great
13
Years of Service
User Offline
Joined: 24th Mar 2011
Location:
Posted: 26th Jul 2011 09:15
Link
Thanks, Mireben. That looks alot easier than I thought it was going to be. Unfortunately, I've got another bug with the damn raycasting. It seems as if the enemy is only pointing towards the player when the player is colliding with something, rather than when there is a clear line of sight. This error has left me utterly baffled. I have absolutely no idea what could be causing it to do this.

Here is the relevant section of the code (not much different from before):



Here is the entire code, just in case.



And just for good measure, I have attached the entire project folder to this post. Just use the shortcut to run the EXE, it's never worked by hitting F5 in Visual Studio for some reason that I still haven't figured out.

I apologize if I'm being a nuisance, but I really need help.

Hail to the king baby
I love Evil Dead.

Attachments

Login to view attachments
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 26th Jul 2011 21:11
Link
I haven't got much time now, but if nobody answers earlier than me, I will look at it a bit later.
Back to top
Profile PM
Lord Herakles the Great
13
Years of Service
User Offline
Joined: 24th Mar 2011
Location:
Posted: 27th Jul 2011 08:28
Link
Thanks. I'll be sure to put something in my game along the lines of "Big thanks to the people of The Game Creators forum community. This game wouldn't have been possible without their generous help." Or something like that.

Hail to the king baby
I love Evil Dead.
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 27th Jul 2011 21:34
Link
I have tested your program, put a few debug prints onto the screen and finally solved the problem. There are two changes to be made. First, you do not update collision data after the player moves. This must be done, otherwise the collision structure will remain in the original position of the player. After all the position, move, rotate, etc. calls that you make on the player object, call:
You can put it, for example, just before the camera collision lines.

The same should be done for enemies. Maybe you won't notice much difference as long as they can only rotate in one place, but as soon as they move too, not updating will cause an error.

The second problem is how you issue the raycasting command. If you give the Player_Character_Mesh as the first parameter, it checks whether the ray collides with the player object - and nothing else. All other objects will be left out of the check. In this form, as soon as the player position updating is corrected, all enemies will always see the player.

Instead, issue the command like this:



This means: check for collision with all objects, but we will only see the player if the returned object number (the first object the ray collides with) is the player. The program works well after these corrections.
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 27th Jul 2011 22:00 Edited at: 27th Jul 2011 22:11
Link
Regarding the project you posted: next time you attach a complete project, remove the big ncb file. It is a symbol table generated by the compiler and if it's missing, then it is recreated immediately when you open the project in Visual Studio. It's not needed to open the project, it only increases the download size by a bunch of megabytes. (In fact, I didn't need the EXE and the intermediate files in the Debug directory either since I recompiled the project anyway.)

You stored the Data inside the Debug directory. It is possible to set up the project so that the target directory for the EXE will be another place (for example, a "bin" directory) that is separate from both Debug and Release. The advantage is that you don't need two copies of the Data if you want to test both compilations, and the project's final directory structure can be created separately from the intermediate files of the compiler. If you are interested, I can write down how to do this.

For me the project started with F5 from Visual Studio.
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 27th Jul 2011 22:27 Edited at: 28th Jul 2011 07:18
Link
P.S. I cannot fully explain the behaviour of the program before the corrections, but the important thing is that after these changes it worked.
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 27th Jul 2011 23:05 Edited at: 28th Jul 2011 07:20
Link
One more P.S. I know why it doesn't start from Visual Studio. When you start from VS, the working directory is where the project files (the vcproj and cpp files) are. When you start outside VS, the working directory is from where you start the EXE. Your Data directory is in the Debug folder, but VS searches it in the project directory.

Try this: In the project properties dialog box, go to the "Debugging" tab, and in the "Working Directory" property, set the directory where the compiled EXE is. After that it should start from Visual Studio.

EDIT: Loading very complex objects - like human models - from within Visual Studio can be very slow on some computers, but with the present models it should load fine.
Back to top
Profile PM
Lord Herakles the Great
13
Years of Service
User Offline
Joined: 24th Mar 2011
Location:
Posted: 28th Jul 2011 10:26 Edited at: 28th Jul 2011 10:26
Link
Thansk, Mireben. I did everything you suggested and it all works now.

Quote: "Regarding the project you posted: next time you attach a complete project, remove the big ncb file. It is a symbol table generated by the compiler and if it's missing, then it is recreated immediately when you open the project in Visual Studio. It's not needed to open the project, it only increases the download size by a bunch of megabytes. (In fact, I didn't need the EXE and the intermediate files in the Debug directory either since I recompiled the project anyway.)"


Thanks, I'll do that from now on. I didn't really know the functions of the files Visual Studio creates. Now I'll be more careful what I put in the zip.

Quote: "Loading very complex objects - like human models - from within Visual Studio can be very slow on some computers, but with the present models it should load fine."


Yeah, the current models are placeholders until I finish making the human models. I work on that during the weekend and I work on programming during the week.

Anyway, I'm trying to get the direction code in the game, but I'm having trouble. This is the detection code:



The problem is that it doesn't do anything. The raycasting code is always being triggered, even when it's not supposed to, so it's still like the enemies have eyes on the backs of their heads. It should be working as far as I can tell, so what is going on?

Hail to the king baby
I love Evil Dead.
Back to top
Profile PM
Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 28th Jul 2011 20:31
Link
Aah, it actually took me a while to notice...



this should be == double equation sign.

Some people suggest to write if conditions the other way around to avoid such mistakes:



because then, if you get it wrong, the compiler will complain, since it is not possible to change the value of a constant. However, this won't help you if you happen to compare two variables. We just have to get used to checking this twice when typing.
Back to top
Profile PM
Lord Herakles the Great
13
Years of Service
User Offline
Joined: 24th Mar 2011
Location:
Posted: 28th Jul 2011 23:45 Edited at: 28th Jul 2011 23:46
Link
== seems to be becoming my nemesis. It's the little "typos" like that I need help with, because if there is actually something substantially flawed in my code, I can usually figure it out by myself. With these little typos it's just a matter of spotting them, which is something I am not very good at.

The new version (with everything from this thread working) is attached to this post. Obviously this is a very early pre-alpha stage of development (the characters aren't even humans yet, they're just slightly modified cubes), but now that the enemies have basic AI, there is something to actually do in the game (avoid the enemies).

Hail to the king baby
I love Evil Dead.

Attachments

Login to view attachments
Back to top
Profile PM
JTK
14
Years of Service
User Offline
Joined: 10th Feb 2010
Location:
Posted: 29th Jul 2011 05:05
Link
The way that I used to remind myself of the differences (besides placing the constants on the left as mireben suggesed) is such:

"=" -> Equals -> Assignment
"==" -> Exactly Equals -> Comparison

So, when reading my code, I would replace "Equal" and "Exactly Equal" in my mental readings.



It worked for me... I hope this helps.


JTK
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-11-19 08:21:31
Your offset time is: 2024-11-19 08:21:31