what is the physics of your setup?
Are you asking me more detail for what I'm trying to do? Or more detail for how I've implemented the solution so far?
i'm asking what physics you want to employ for your flash display? i infer there's no gravity but, i'm not sure about that. i infer there's something to impel your square's to move but, i'm not sure about that. i have no idea if there's friction and i have no idea what force would cause a square to stay aligned with a wall while it slides.
Ah, I see.
Ok, I have a top-down view of terrain. There are some tracked robots that move around on this terrain which may contain walls (or other features that impare movement to some degree).
Right now the robots move around just fine, they each can have different mass, speed, accelleration, turn rates. Included is a friction setting based on the terrain that changes how a robot moves with regard to acceleration, turning, skidding tolerance, etc.
The big issue right now is interaction with other robots and walls, namely collision, and what happens as a result of collision.
I realize that not having a robot turn as a result of angled collision sounds odd at face value, but this is a result of the gameplay more so than an external force. These are programable robots. The player assigns actions and logic to be carried out autonomously, as opposed to controlling them on the fly. It's not my intention to cause a robot to always become 'stuck' when it strikes a barrier as this seems too much of a penalty gameplay-wise. So, I don't want the robot to have complex pathfinding routines built in, but neither should a realitively trivial barrier become nearly insurmountable. Currently, my two cosessions to balance this are 1) allowing a robot to turn in place if it gets caught against a wall, and 2) not having the wall effect the robots desired heading when colliding (basically, these are related).
For example, say a robot has has its throttle set to 100% and is now following an instruction to steer towards waypoint 1. If it encounters an angled barrier along the way, it could slide along the angle, hopefully eventually coming around it even though it looses some speed depending on how steep the angle is. Now, if the collisions resulted in realisticaly spinning of the robot according to which corner is hit, it would tend to end up flush, head on into the wall, stuck. The robot will try to turn back towards the waypoint, but the strike the wall and spin again.
As far as friction is concerned, it only applies with regard to the terrain. I'm not looking to have differing wall friction. Right now, speed reduction is simply a function of the angle of collision.
Due to skidding, a robot could collide with a wall on any side. So instead of keying off the robot's heading, each robot has a velocity vector.
When two robots collide, they don't have to rotate (but would be ok here) but I do want them to be pushed depending on the mass difference and friction.
Walls and robots are all straight edges, and need not be curved. Curved surfaces would be a nice bonus, but the game need not have them.
have you ever seen an irobot product in action? there are several algorithms used for different scenarios. relative to this discussion are the algorithms used when an obstacle is encountered. i would recommend using the irobot algorithms.
i would allow users to prioritize this list of obstacle-encounter algorithms. and, the list could be absolute or incorporate some degree of randomness in choosing an algrithm and some/or some amount of time to employ an algorithm before switching to a new algorithm.
Google searching turns up two types of information:
1) An iRobot flash game associated with the Will Smith move
The first didn't look relavant on the surface. But I couldn't get the game to work across a dozen sites anyway.
I'm thinking your refering to the second set?
Certianly, gameplay suggestions are welcome, but it should be noted that getting the robot to employ different navigation algorithms isn't my problem at the moment. However, without actually researching the specific methods at this time, I can't see any reason a player wouldn't be able to build what you describe.
I'm struggling with implementing the colision functions in the code, not the logic the player will use as a part of the game.
The player has assigned the robot to move foward, but an angled wall is in the way, and has the effect of pushing the robot sideways. How does the game resolve this? Well, the robot slides along the wall. But how does the game know which way the robot slides? I'm using gskinner's collision detection, but it only tells me if there is a collision, not which side the collision is on. So I have tried putting movie clips on the corners of the robot, to detect directionality to the obstacle. This will tell me whether to slide left or right, but doesn't tell me what angle the wall is at, and therefore exactly where to adjust robot. Getting the bearing to the obstacle won't work. The best I came up with is comparing the robots vector with the rotation of the wall and the corner of the robot that's touching. These three bits of information will yield the angle of the wall, (but ONLY if the walls are rectangles). From there the game can adjust speed, and shift the robot off-course.
Another technique might be to get the x,y positions of the obstacle corners using a little trig. Then I have to find which two corneres produce a line that intersects with the robot. Once that is found the program will know where to adjust the robot.
Both these seem a bit awkward, and I feel like there are better ways to do this. Like there is something obvious I missed.
the beauty of the irobot algorithms are they are not dependent on the knowledge of the obstacle. the robot has no knowledge of the obstacles shape, angle or any other characteristics. the robot doesn't even know which way it's facing and yet it never gets trapped in a loop or immobilized.
Sure, but some physical reactions still occur when the robot collides with a wall. From an actionscript perspective, the robot has to be placed somewhere in regards to those happenings, which is completely seperate from how the robot reacts to such collisions.
Again, the player will be free to program his robot(s) however he wants to, including creating roomba navigation. Of course, it remains to be seen how appropriate or competitive such behavior would be in regards to certian puzzles or chalenges.
After thinking about this for a bit, I have realized that this is very similar of the problem of getting a ball to bounce off a wall at the correct angle. While I'm not looking for the angle of reflection, but the angle of the wall. Both of these problems require finding the same information.
Knowing this, I think I'll be able to adapt bouncing ball tutorials, which are in abundance.
So far, it looks like they are finding the x,y points to get the slope of a line segment. If this works, all I need to do is figure out how the code will know which points of the polygon to use to make the correct line.
There has to be a better way than testing every segment, and finding the one that intersects? I mean, we already know one of then intersects by virtue of colliding with the shape, it seems in efficient to have to keep searching to find the correct segment. Finding the closest two points won't work. Any other ideas?
actually, those are not similar at all. in the ball-bounce example, you know the angle of the ball's movement and the angle of the wall. the angle of rebound is determined by those two knowns.
you have an obstacle, that may be a wall, and you appearently don't know its angle. or, maybe you do know its angle but you can't determine which side is hit.
In the ball example, how do you know the angle of the wall, when that wall happens to be a rectangle at some rotation? (or worse, a polygon)
The only thing I can see is to find each corner point from the height, width, and rotation with some trig, and that still doesn't tell me which line segment was hit. I'd then have to check each line segment to find the right one.
I feel like there might be a matematical shortcut or some method I'm not considereing.
Well, if that's the only way, does anyone have any ideas on how to check if those found line segments intersect the robot? Right now I'm thinking that I'll have to additionaly find the 4 line segments that make up the robot and check them against the 4 line segments of the wall, to determine which side of the wall was hit. That's up to 16 checks per robot per frame, and doesn't sound efficient.
1 person found this helpful
I think what you are finding is that there really is no such thing as "light physics!"
In anything except for the simplest cases it gets complex pretty quickly. I've seen some great stuff on the polygonal site about these types of questions. For example this entry is about how to find the closest "features" of polygons.
And here is a post on motor2 which is great for all kinds of "light" physics simulations. You should
And check this out: If he can do this, you can check for quite a few robots!
Interesting site, too bad Motor2 is AS3.
It seems that collision detection is the most computationaly intensive part of physics models. I may have to revisit flade and see how to integrate it into what I'm building.