Me and my friend are currently trying to make a game. In this game we wish to have nice collision detection. But we cannot seem to find the way to update the masks in the definiton while loop. :S We have tested it alot of times, with different values and even some really unlogical stuff.
Each time we move the player, the game crashes when it collides with the mask. Its like the loop goes on forever, even though the player and the bush should be going away from eachother when we move the mask and the background.
def check_collision():
while pygame.sprite.collide_mask(player, rock):
bg.x -= 1 #the x-value of the background
rock.x -=1 #the x-value of the object
This is just collision when going left using the button "a".
We also move the background and all the sprites instead of the player.
We need to use masks.
We know that it checks the collision, but the mask wont update after bg.x and rock.x are changed.
We assume that this is because the images aren't moved on the screen. And therefore we have tried putting a blit inside the while loop. It still would not work.
Thank you for helping, and a final question, is there any way to manually move a mask/object?
First of all, collision detection using masks is very time-intensive. Whether or not your game has entered an infinite loop, the processing requirements of a bitmask-bitmask overlap check will make your game run far too slowly.
A simple optimization exists, however:
Any object which is able to collide with things must have some maximum size -- that is, you can find a rectangle which will always contain your player, and your boulder can fit inside another. Therefore, if your player's box doesn't collide with the boulder's box, they can't possibly overlap. Since you insist on collision masking, (which can add some realism to any pixelart game), you can compute the per-pixel collision whenever (and only whenever) the bounding boxes collide.
Now, on to your coding style: >:O
It is never a good idea to put a potentially infinite loop within a function which should ideally compute an instant collision check. In the best-case scenario (which is certainly achievable), you would have one function to check whether two objects collide, and tell you some more useful information (the position of one relative to the other, etcetera); while a separate method of every moving object would fix the collisions.
This would translate to something like:
class CollidingObject:
#This class controls an object which can move and fix collisions
def __init__(self):
self.x = 0 #add relevant initialization code here
self.y = 0
self.xVel = 0 # X and Y velocity (for movement)
self.yVel = 0
self.xSize = 0 # the width of the object in pixels
self.ySize = 0 # the height of the object in pixels
def iscolliding(self, other):
# using x and y as the center of the object,
# this returns an empty tuple if they don't collide
if ((self.xSize + other.xSize) / 2 <= abs(self.x - other.x)) and
((self.ySize + other.ySize) / 2 <= abs(self.y - other.y)): return ()
"""
use pygame collidemask here to compute whether they collide.
if they do, return a vector of 'other's' position relative to self.
(this can be used to decide how to separate the objects)
"""
def restitute(self, overlaps_with, distances):
"""
Given some objects which overlap, and a list of 2D vectors of their
relative distances, this separates them however much you like.
"""
pass
As to where your colision checking is done, that depends upon your implementation of object management basics. I will heretofore assume that all of your in-game objects are contained within an iterable; and that on every frame you iterate through your objects, once to render, once to move them -- a structure something like this:
while NOT_QUIT:
for object in objects:
object.draw_to_screen()
object.move() # moves the object -- collisions, etc in here
event_handling_stuff() # handles events
In this case, every object can compute collision checking for anything which follows it in objects. In doing so, each object can collect how far it has to move from each. Afterwards, each object can move to be as far from each collider as possible.
In a few games I've written, I'd make objects move farther apart the more overlapped they are, giving collisions an elastic quality which makes even very rough restitution algorithms look very sexy. Generally, you can tinker with constants once you have a working check going and that would be the least of your worries.
Hopefully this will have helped you two a little (I realize now I went off a bit on a tangent, but you were asking about how to do the wrong things more efficiently :P).
tl;dr: Don't try to fix collisions within your collision check function. Instead, separate it into one which finds all collisions to other objects, and another which fixes all collisions for an object at the same time.
Add other questions and I'll update (:.
UPDATE 1
Expanding here on the "vector of other to self" bit (which was explained a tad crudely:/)
Generally when two objects collide in real life, they bounce back somewhat in the direction they came from (when you drop a rubber bouncy ball on the floor, it bounces back from whence it came -- it doesn't just phaze through the floor). In most programming applications, you'd want to make bouncy balls (and other colliding things) behave in the same way (well, sometimes you might want the ball to phaze though the floor, but that's even easier than bouncing IMHO :P).
To know which way an object must bounce back, you have to know the direction from which it came. More strictly, you have to know the angle at which it collided. This is very easily found if you compare the distance and direction between the centers of each object during the collision. This will provide a pretty accurate representation of two objects bouncing, if the centers you are using are close enough to their centers of mass (in most games the middle of an object is an easy and good approximation).
So, since we don't need to worry about center of mass and all that, we just measure the vector distance between object positions:
#Continuing the previous example, we put some code like this in 'iscolliding' :)
if they collide (pygame mask stuff) :
x_distance = self.x - other.x
y_distance = self.y - other.y
return (x_distance, y_distance)
This code can give you the line along which each object should move to resolve the collision as fast as possible. The rest is a matter of accelerating each object along this line, making sure they don't go closer together (pay attention to signs), and tweaking constants to create a realistic effect.
Related
As part of my current pygame project (I am very new to pygame), I have created multiple rectangles that move at random around the screen. As one of the features of this game, I want to make it so if one rectangle is close enough to another one, it moves towards it. Another feature I want to add is that rectangles cannot collide with each other, but I don't want to just do the regular
if rectangle1.colliderect(rectangle2):
rectange.x -= 10 # That is, it's previous position
because it will make the animations look odd.
The main way I can see to solve these problems is to use some sort of function that could check if a rectangle.x - 30 is another rectangle (or something similar), but I am unaware of one that exists.
I have attempted to look through google, but I haven't found anything as all the posts are different problems that aren't quite the same.
Thank you for any responses!
Use inflate to create a rectangle that is larger than the original one and surrounds it. Use this rectangle to find other rectangles in range:
test_rect = rect1.inflate(dist, dist)
if test_rect.colliderect(rect2):
# [...]
I am making a game in which the change in velocity of a ball depends on the point at which it collides with an object. I looked up the documentation but was unable to find something to do the job.
Is there any way to get the coordinates of the point of collision in Pygame?
Yes, work out the difference in the x and y co-ordinates of your ball and object. Then use mask.overlap from pygame to return a tuple of the point of collision. An example would be:
def collide(obj1, obj2):
offset_x = obj2.x - obj1.x
offset_y = obj2.y - obj1.y
return obj1.mask.overlap(obj2.mask, (offset_x, offset_y))
You can find the docs for 'mask.overlap()' here.
I support the answer given by Abishake Srithar. This is not meant to displace that answer, just add information to it.
A slight caution about the result of this mask.overlap() call. It does not give you the center of where the point of contact might be.
As you can see in the description in the docs here, the overlap is searched for by proceeding top to bottom in columns moving left to right. Which means that overlap() returns the leftmost, upper (sort of) point of the overlap.
So if your update/move of the objects causes the objects to overlap over an area (which is likely), the point returned by overlap() is the leftmost, upper point of that overlap. It is not the center of the area, or the point where the two objects might have first touched if they were not overlapping.
An example is if this were two spheres colliding, it will give you the edge of the overlap and not actually the centerpoint of the collision. This could change your angles of reflection.
This difference can affect the collision physics.
It is likely good enough for most games but I thought it worth pointing out.
So i started some kinda big pygame project, everything went more or less well.
But now i'm really stuck at how to detect the directions of collisions.
So i got my character (2d sidescroller), and a sprite group for the obstacles which are by now all rects. Now however collision detection works fine, but is, and if it is then how, it possible to detect on which side of the obstacle rects the character rect collides with it?
Addition in case someone stumbles upon this question: The janky solution I ended up implementing used a "scaffolding" of four (invisible) lines per obstacle, one for each side. Once a collision with a specific obstacle was detected I looked up the four lines around the colliding rectangle in a dict and then went to check which of these lines was currently colliding with the player sprite. It kind of worked but the whole project was a mess anyway.
There are many 2D physics libraries that including collision detection and usually a large project like you said would require other physics like constraints, ray casting and bodies. A great library for python is pyBox2D and has good documentation on their github. pyBox2D will also fully handle collisions for you but you can also setup custom collision handlers.
For you question you ask how to check which position a rect collides with, you can do this using the pygame.Rect variables that are given like so
import pygame
def determineSide(rect1, rect2):
if rect1.midtop[1] > rect2.midtop[1]:
return "top"
elif rect1.midleft[0] > rect2.midleft[0]:
return "left"
elif rect1.midright[0] < rect2.midright[0]:
return "right"
else:
return "bottom"
rect1 = pygame.Rect(100, 100, 20, 20)
rect2 = pygame.Rect(100, 90, 20, 20)
print(determineSide(rect1, rect2))
Note this does not check for collision but simply checks where rect2 is relative to rect1.
Maybe you can check which one or two of the four corners on one Rect are inside the other. There is one problem, though - if the Rects are touching by the corners, it's up to the rest of the program what to do then. I haven't written a code snippet for this myself, but I'm working on a platformer as well and plan to create one.
I am working on a simple 2d game where many enemies continually spawn and chase the player or players in python + pygame. A problem I ran into, and one many people that have programmed this type of game have run into is that the enemies converge very quickly. I have made a temporary solution to this problem with a function that pushes any two enemies randomly apart if they are too close to each other. This works well but is about an O(n^2) algorithm which is run every frame and at high enemies the program starts to slow down.
When my program runs with this function the enemies seem to form round object I nicknamed a "clump". The clump seems to usually ecliptic but may actually be more complex (not symmetrical) because as the player moves the enemies are being pulled in different directions. I do like the way this clump behaves, however I am wondering if there is a more efficient way to calculate it. Currently every enemy in the clump (often >100) is first moved in the direction of the player, and then pushed apart. If there was instead a way to calculate the figure that the clump creates, and how it moves it would save a lot of computation.
I am not exactly sure how to approach the problem. It may be possible to calculate where the border of the figure moves, and then expand it to make sure the area stays the same.
Also my two functions currently being used to move enemies:
def moveEnemy(enemy, player, speed):
a = player.left-enemy.left
b = player.top-enemy.top
r = speed/math.hypot(a,b)
return enemy.move(r*a, r*b)
def clump(enemys):
for p in range(len(enemys)):
for q in range(len(enemys)-p-1):
a = enemys[p]
b = enemys[p+q+1]
if abs(a.left-b.left)+abs(a.top-b.top)<CLUMP:
xChange = (random.random()-.5)*CLUMP
yChange = ((CLUMP/2)**2-xChange**2)**.5
enemys[p] = enemys[p].move(int(xChange+.5), int(yChange + .5))
enemys[p+q+1] = enemys[p+q+1].move(-int(xChange+.5),-int(yChange+.5))
return enemys
Edit: some screen shots of how the clump looks:
http://imageshack.us/photo/my-images/651/elip.png/
http://imageshack.us/photo/my-images/832/newfni.png/
http://imageshack.us/photo/my-images/836/gamewk.png/
The clump seems to be mostly a round object just stretched (like an eclipse but may be stretched in multiple directions), however it currently has straight edges due to the rectangular enemies.
There are several ways to go about this, depending on your game. Here are some ideas for improving the performance:
Allow for some overlap.
Reduce your distance checking to be done after a fixed number of frames.
Improve your distance checking formula. If you are using the standard distance formula, this can be optimized in many ways. For one, get rid of the square root. Precision doesn't matter, only the relative distance.
Each unit can keep track of a list of nearby units. Only perform your calculations between the units in that list. Every so often, update that list by checking against all units.
Depending on how your game is setup, you can split the field up into areas, such as quadrants or cells. Units only get tested against other units in that cell.
EDIT: When the units get close to their target, it might not behave correctly. I would suggest rather than having them home-in on the exact target from far away, that they actually seek a randomized nearby target. Like an offset from their real target.
I'm sure there are many other ways to improve this, it is pretty open ended after all. I should also point out Boids and flocking which could be of interest.
You could define a clump as a separate object with a fixed number of spacial "slots" for each enemy unit in the clump. Each slot would have a set of coordinates relative to the clump center and would either be empty or would hold a reference to one unit.
A new unit trying to join the clump would move towards the innermost free slot, and once it got there it would "stay in formation", its position always being the position of the slot it occupied. Clumps would have a radius much larger than a single unit, would adjust position to avoid overlapping other clumps or loose units that weren't trying to join the clump, etc.
At some point, though, you'd need to deal with interactions for the individual units in the clump, though, so I'm not sure it's worthwhile. I think Austin Henley's suggestion of splitting the field up into cells/regions and only testing against units in nearby cells is the most practical approach.
I think you're looking for flocking.
The best intro to flocking / steering behavior movement: http://www.red3d.com/cwr/steer/ . See the attached paper red3d paper. And the related OpenSteer
I would like to create a list of objects that collide with the user. However, I don't want to use the sprite.collide_rect_ratio() method because it creates a rectangular area that is too big for the collision (i.e. the objects seem to collide even though they are not really touching). I want to use the pygame.sprite.collide_rect_ratio(ratio): to fix the problem. How do I implement the method so that it returns a list of objects the user collides with?
It would implement the same code except with a smaller collision area as the following code:
sprite_list = pygame.sprite.spritecollide(myself, all_sprites_list, False)
Thank you.
This may be of use to you,
What you may want to look into is "Per Pixel Collision", which will first use the bounding box of the object (what i suspect the collide_rect function does).
What you will need to do is find where the rectangles collide and how far within each other they are. You then check to see if there are any opaque pixels from one sprite touching any opaque pixels from the other sprite...
This Link may be of use to you, its a very well done tutorial for a C++ framework similar to pygame.
The Per Pixel Collision code is half way down the page, and acts how I describe above.
Hopefully this is useful to you as it negates the need for the rectangle ratios due to 'invisible collisions'.
a quick google search may help you more with this type of collision detection.
For a bit of a boost heres some sample pygame code:
for s in sprites:
# if no intersection then 'intersection' will be of size 0
intersection = s.Rect.clip(user.rect)
if intersection.width != 0 and intersection.height != 0:
# perform collision detection
Here is an already written and tested version From the pygame wiki. Reading every thing on that page will give you a good knowledge on pixel collision and some good sample code which you can use straight away.
apologies if this was too far off topic but I feel this could be very useful to you as ratios (i feel) would not perform well for collision detection.
You may also want to look at Rectangle documentation in pygame.
As for your question, looping through all sprites and using the collide_rect_ratio method would be the only way of using such a method to get a list of colliding sprites as far as i know.