12

A* is the logical choice. Your main concern is going to be with generating good navigation nodes. The nodes will tell you everything you need to know about how traversable each node is with respect to each unit. Having size information associated with your nodes will be very helpful to you. In the above, we see a size 1 unit can use any of the nodes. Where ...


11

This is frequently referred to as flocking or a boids simulation. It's an algorithm that combines three behaviors to simulate the motion of a group: Separation: steer to avoid crowding local flockmates Alignment: steer towards the average heading of local flockmates Cohesion: steer to move toward the average position of local flockmates The combination ...


11

It seems like what you're looking for is the Optimal Reciprocal Collision Avoidance algorithm. The preceding paper is also worth a read. Although the paper may be a bit involved the theory behind the algorithm is fairly straightforward: Assume that you already have a simulation (game) with agents (units) that have some sort of bounding volume around them. ...


4

This is a pretty interesting question, and i'm going to try to contribute with what I can. First, I think you have to clearly define the boundaries for the game you are trying to create, and define those questions (some may already been answered). How far the is the monster aggro ? How many monsters at the same time is your target? How is your terrain ...


4

Since your AI is steering based it's pretty simple. You need to weigh your forces based on how important they are. The closer you get to obstacles the more important they should be, otherwise chasing should be the most important. There are a couple different ways to implement it, but I always found having some "max force" worked best where you iterate over ...


3

I had a similar problem this week, so I thought I'd post what I did. Dijkstra's algorithm is inherently discrete, so it will always give you directions that tend to funnel everyone into the same few cardinal directions. I would recommend taking a look at Continuum Crowds (Treuille/Cooper/Popovic) and Hybrid Vector Field Pathfinding (Moersch, Hamilton) as a ...


3

Traditionally if you're travelling parallel to the axis of a box, traditional collision handling won't make you go around the corner like that. That's because there's no local information on whether you should go around by going up or by going down. I see two obvious options: Local approach - make the collision shape a box with bevelled corners, e.g. a ...


2

Typically the process is something like this... Determine the object's motion vector Mass-project the object's vertices onto a line (2D) or plane (3D) along the motion vector to see whether they intersect the obstacles. (There may be cheaper ways to rapidly reduce the object's vertices to two points which represent the maximal profile of the polygon, but I ...


2

Totaly agree with Adam. Randomness make experience much brighter, but it must me balanced with skill-challenge very nicely, across tons of testing and recalculating. Naturaly, even skilled player should think like "Yeah, i can handle this" in first few minutes (or longer, depends on your planned gamesession time). But after this, he get in some random ...


2

If you approximate the obstacles with bounding spheres, then testing a new obstacle to see if it might collide with any existing obstacle is not too hard. http://twobitcoder.blogspot.co.uk/2010/04/circle-collision-detection.html explains the process well. All you need to add on to that is some tests to make sure the position at the collision time (if there ...


2

I can think of three different approaches to your problem. One involves using an object silhouette or shape as a preview of where it's going to be placed; another is a real-time positioning of the object, providing interaction with surrounding instances; the last one is again real-time positioning though by computing the last valid position. Paintbrush ...


2

This is an interesting problem. I can think of two mechanical (brute-force-ish) approximate approaches. My math-fu is not strong enough to opine if an analytic solution is practical here. I hope there is such an approach! But here’s my “just get it done” suggestions. By Gridded Area, approximate We only care about the blue area. Represent that to the ...


1

I found out logical mistake, I should do the sum of angles as totalAngle and then divide it by the count of angles so I get totalAngle / movements.size(). With that I get a middle vector (in the middle of all the normals). Another thing is that my checkCollision wasn't working properly so I had to change that. I also had to check if the collision occurs on ...


1

You should use Pyhsics2D.IgnoreCollision() since Box Collider 2D inherits from Collider2D, not Collider. Found more info here, check this one out.


1

You are on the right track. I have re-implemented collision avoidance for my RTS taking Recast as example. General approach is quite simple: Each agent (that's how they call units in collision-avoidance) checks for neighbours and obstacles and chooses path depending on its desired movement direction, other agents desired directions and allowed space. ...


1

The dot product has two nice properties for collision avoidance. The dot product is closely related to the cosine of the angle between two vectors. The dot product of a unit vector A and a second vector B of any non-zero length, the result is the length of vector A projected in the direction of vector B. So as you can see in the image; if the angle is ...


1

I don't think there's an efficient way of solving the problem exactly, but here's how I'd try to tackle it. First, I'd use bounding volumes around each object, instead of the objects themselves. Each object can be approximated by the union of more than one bounding volume, though. The simplest solution would be to compute a single bounding volume that ...


1

It's been a while since I did anything like this, but if I recall correctly you want to test a point on the circle against the line that defines the wall, and if the point has bypassed the line (IE, the line is closer to the center of the circle than the radius of the circle), a collision has occurred. The "pushing" effect comes from blocking the ability to ...


1

If the enemy paths are not very dynamic (Dynamic would be every couple agents are attacking different targets and paths to those targets have to be updated every couple frames) Then I would do a combination of flowfields and steering behaviours if performance is your main concern. There are some more complicated subjects involved like space partitioning ...


1

For path finding, A* (pronounced a star) ought to fit your situation real nice (for people who don't know what binding of Isaac is, it's basically the original legend of Zelda). For avoidance, I can't think of any named algorithms, but I think it will basically be pretty simple to code up some heuristics (rules) to where if an enemy is in the path of a ...


1

I'm wondering about this too! Sad to see there aren't any replies. I did something similar -- parts not included for walking in the navmesh, like static objects in the scene, would be a problem when my agent would get to them and just continue to walk and walk.. and walk. Maybe this can be of use to you. For now, I worked something up so that my agent ...


1

I would reccomend removing your box collider and then add it back again. It will automatically resize to fit your texture. It looks like it is a bit off to me. The ground detection looks fine, but both the corner circle colliders are too low. This will cause unrealistic looking collision detection, unless you have reasons for the collider offsets.


1

TL;DR: process collisions Manhattan-distance style http://en.wiktionary.org/wiki/Manhattan_distance, each axis independently one-by-one (move in X, then move in Y, then in Z, rince and repeat) properly rounding each axis before processing the next. AABB / Voxel collision systems work the same way old tile-based 2D games did, you add a 3rd dimension but ...


1

As per your comment my reading was wrong. I thought LocalPos was relative to the player, because I assumed that's what HelperMethods.PointToLocalSpace was supposed to be doing. But if LocalPos is still world coords, then your description at the end of the question gives it away. Your if statement: if (Math.Abs(LocalPos.Y) < ExpandedRadius) can be ...


1

This question is probably irrelevant now, but for future reference, as well with anyone coming here with the same problem: I would use the "java.awt.rectangle", and store the X, Y, and width and height values there. It includes one of my favorite methods: public boolean intersects(Rectangle other). I'm assuming there is a class called "Entity", but if the ...


1

I'm going to expand on Dirk's answer a little bit. You might get 2 collisions (for example once for colliding enemy 2 with enemy 5 and once for colliding enemy 5 with enemy 2) and thus reverting the swapping of velocities. You could resolve this by starting your second loop not with k = 0 but with k = i+1. This will allow you to get rid of the IF block ...


1

You might get 2 collisions (for example once for colliding enemy 2 with enemy 5 and once for colliding enemy 5 with enemy 2) and thus reverting the swapping of velocities. You could resolve this by starting your second loop not with k = 0 but with k = i+1. (Furthermore, you should make sure the collision boxes are not overlapping after you swapped the ...


1

In order to solve this you need to implement something between the touch position and the position of the object. Instead of setting the position directly to the new touch position you'll want to first test to see if the touch position is valid. If the new position is free from overlap, then you're done and you can move the rectangle there. However, if ...


Only top voted, non community-wiki answers of a minimum length are eligible