Drak's Waypoint Example?
Blitz3D Forums/Blitz3D Beginners Area/Drak's Waypoint Example?
| ||
Hi all, a LONG, LONG time ago, Drak had made a waypoint example. Since I'm making a level editor and needed waypoints to write to the final game script, I decided to try and add an extra mode for the enemies, called "Roaming". What Roaming SHOULD do, is turn the enemy blue (for now), and wait a couple seconds before roaming close to its waypoint. BUT. If the player gets TOO close, the enemy will go into "Pursue" mode again, and start pursuing the player again. If the player gets away, the enemy returns to its waypoint, waits 1 to 5 seconds, and then starts roaming randomly again, keeping nearby its waypoint. NOW.... I am HORRIBLE with enemy roaming math, so can someone PLEASE help fix this? :) Also, one small glitch, when you are chased by a couple of enemies for a while, the game crashes at this line: In: Here's the code: Pay PARTICULAR attention to THIS part of code: Thank you for all help! :) Last edited 2012 |
| ||
It works absolutely perfect as I wrote it. That's not my original code. You added a bunch of stuff to it, and it's the stuff you added that's screwing up MY original code. MY original code here works without glitch or hiccup: http://www.blitzbasic.com/Community/posts.php?topic=89386 Last edited 2012 |
| ||
Anyhow, if you actually read and understand the code it's a very simple program. ONLY when the "enemy" targets and chases the player does a "waypoint" get created. The enemy return to this "waypoint" when a)the player gets too far away, or b) when the enemy hits the player. It then returns to the "waypoint" and deletes it until it goes into pursue mode again in which it creates a NEW "waypoint". That't it. There is no actual pathfinding in this example. Now, if you want the enemy to wander around that could very, very, easily be done without all that other stuff you added. |
| ||
Ok, how is roaming done? |
| ||
Instead of returning the enemy to the waypoint when the player gets too far away, place it into a wander state instead. In that wander state, simply keep checking the distance to the player from the enemy, and if that distance is too small, switch back to pursue state. Also, in the wander state, just run a simple timer to control when the enemy switches back from wander, to return to waypoint. |
| ||
Now, the reason you're getting that error code is because you're bypassing the state where the enemy drops a waypoint. The return waypoint does not exist until they move through state 2, which you switched into state 6. Therefore, you'll always get that Object does not Exist error because they return waypoint does not exist in your code. |
| ||
With only a few simple lines of code wandering can be implemented. Try this: |
| ||
Is there a way u can make it so that the enemies when in "Wander" mode, are on a timer, and they randomly stop wandering for a couple of seconds, then start wandering again? :) Thanks, Drak! :) Last edited 2012 |
| ||
Drak, be careful of this guy ok. Unless you want to write his entire game for him. |
| ||
Tu, stop hijacking my thread. -.- U have NO right to be in here! Get away from my thread. -.- Last edited 2012 |
| ||
Drak, be careful of this guy ok. Unless you want to write his entire game for him. I'm aware of Rez's behavior in the past. I do truly like coding though and hopefully he learns something from this. I have no intention of writing a whole game for anyone. :) Is there a way u can make it so that the enemies when in "Wander" mode, are on a timer, and they randomly stop wandering for a couple of seconds, then start wandering again? :) Yes I can easily do that. Why don't you give it a try first though. Tu, stop hijacking my thread. -.- U have NO right to be in here! Get away from my thread. -.- Rez, everyone has a right to be here. This is a public forum. Enay was adressing me anyway, not you. |
| ||
I did, Drak. Here's what I tried so far: |
| ||
Here's what I would do: 1. Wander for a few seconds. 2. Stop. 3. Turn in a random direction. 4. Go back to wander mode. 5. All while checking to see if the player is in range. Repeat. You'll need to add new states for some of these actions. |
| ||
I don't know how to do timed movements. only regular movements... |
| ||
The code I posted doesn't use timed movements. It uses a counter, adding 1 each frame until the threshold is reached. |
| ||
Well, could u show me a countdown timer so I can attempt to solve this problem easily? Im better with countDOWN timers, as opposed to count UP timers. |
| ||
Here's what I have so far: |
| ||
Read my code. It's VERY simple. Under the enemy TYPE there is: Field timer Field timer_max When the enemy is created timer is set to 0 and timer_max is randomly set at a number between 400 and 1000. Each frame: e\timer = e\timer + 1 until e\timer is greater or equal to e\timer_max. If it is, then move on to the next step and reset e\timer to 0. Read the code, it's all in there. |
| ||
Ok, I've TRIED. keyword... TRIED to understand how it works, but it's still stumping me.... |
| ||
You still don't understand what my counter is. EVERY FRAME it adds 1 to the count. Not 1 per second. ONE per FRAME. Now, try and undertand what is happening here. I added it with 4 VERY SHORT lines of code. It took me about 2 minutes. |
| ||
Ok, so you first initiate the timer. Then if the FRAME count is < or equal to the max frame count, then start roaming randomly, otherwise, reset the frame count to 0, and rotate the enemy so that it's yaw is a random rotation within 360 degrees, then set their "case" back to 1. Am I correct? :) |
| ||
Yes, each enemies' e\timer actually counts the frames that have passed, correct. If that number is less than the maximum, they roam. (remember the maximum was set randomly between 400 and 1000 at each enemies creation) When it reaches the max, they go back to status 1, which is idle. While idle the counter continues to count and if they sit too long, they go back into wander mode, and repeat, and repeat, until they see the player. So yes, you are correct. |
| ||
YAY! I finally learned something! =D I think o.o |
| ||
Hey Drak, u might wanna update ur tutorial 1 more time so other ppl can see it without having to search for this thread :) |
| ||
I've taken it to the next level. I changed the enemies to Dwarves. I added player to object collision, player to land collision, and object to object collision. I fixed a rotation glitch when the enemy returns to its waypoint, due to collision. PROBLEM is, the enemies wont pursue the player anymore.... Here's the project: http://www.mediafire.com/?do051b8fw2h5tyj Thanks for any help! :) Last edited 2012 |
| ||
The enemies did pursue the player in my example. If they don't now, then something you added or changed modified the enemies' behavior. Without any code no one can help. Last edited 2012 |
| ||
Why don't you remove your changes, implement them one by one, and deduct what change you made that's causing the "bug". |
| ||
I DID give u the source... It's in the mediafire file |
| ||
I think he means post it in a codebox here? |
| ||
ooooo! my bad! sorry bro! :) |
| ||
Ok, without looking through the code... do the enemies change to the proper color even though they don't follow? That is the reason I had the enemies' color change, so it's easy to see what state they are in. If they don't change color, then they're not switching to the proper state. If they do switch color but don't follow, then there is another problem. |
| ||
Well I took out the media (the dwarf) so I could run the program. I couldn't replicate the problem. The enemies still pursue fine. Oh, and CameraRange(1,999999999)? Seriously? 999 million units? The default is CameraRange(1,1000) and you don't even have to type it in. You can't see things 999 million units away let alone 1000. Last edited 2012 |
| ||
Problem with that camerarange also, is your seriously reducing the resolution of the world. Remember it's stored as a 32 bit number. |
| ||
Yea, they switch colors. |
| ||
If they switch colors then they are changing states correctly. Now, as I said before I couldn't replicate the problem with the code that you posted. The only change I did was replace the dwarf with a primitive. |
| ||
Well the problem its having is with collisions. |
| ||
Can u get this to work with collisions? Thanks, Drak! :) |
| ||
I'm not following why you need collisions with this code example. I took care of the collisions by saying if:;psuedocode: If distance between enemy mesh and player mesh < 1 DamagePlayer() End if |
| ||
Well, because I don't want the players to walk through an enemy NPC. |
| ||
This is an example on controlling types using states. It is not a collision tutorial. It's not meant to be made into a different game, either. In this example code, the player is meant to avoid the enemies. The purpose of a tutorial is to use it to learn so you can implement things into your (original) code. If you're having trouble with collisions that's a whole different subject than the thread title. Last edited 2012 Can u get this to work with collisions? Yes I can, but this again is a tutorial on controlling npcs using types. So, no I will not. Last edited 2012 |
| ||
ok, fine.. -.- |