[HELP] Collision system

Hey Guys!

Unfortunately I don't have anything that could lighten the mood around here, but I thought I should ask for some advice on my latest project before getting too involved in its development. So what is this game I'm speaking of?.. Well basically, it's like bowman but with more obstacles in the way - a simple project, but I want to get it done before moving onto time-consuming projects.

I'm seeking advice for the collision system: What's the fastest method for finding collisions against objects with a fast moving projectile for a game like mine?

I've thought of a few different methods, but the best was something along these lines:

• Create a collision layer to check for collisions against (so gfx, and collision checking is separate).
• With a loop and shapeFlag hitTest, predict the future path of the projectile (positions in-between movement). If there's a hit, move the projectile to the new position (where a hit was found) and break the loop; if no hit is found, move the projectile normally.
• Check the colour of the object that registered a hit, and react accordingly (so a green coloured object in the collision layer could make the bullet stop completely, blue slows down the projectile, red plays a special animation, etc.)

My main concern with the system mentioned above is that because of the loop (which I need for precision collisions), it may become too intensive. Or would it run fine, as the shapeFlag hitTest won't be demanding no matter how many shapes are being checked against?

Thanks for any advice you can offer. :)

Viza.

It really depends on how easy it is to get a mathematical representation of the possible collisions. If you need to shapeflag hittest every obstacle you will be losing a lot of speed there. If you just need to check against circles or convex polygons you can use math instead.

IMO with only a single projectile just doing a wide box-box hittest to narrow down contenders then doing a more detailed collision check on the obstacles that remain should be fine.

I think what you are asking for is discussed in this thread:
http://board.flashkit.com/board/showthread.php?t=754442

Otherwise, shame on me :D

If anyone needs some mood therapy aren't we talking superbowl today? And if that's not enough, how 'bout a song: "Baby keep smiling..dum, dum, dum...you know the sun is shining..dum, dum, dum" :D

Yeah, that's what I'm worried about: redundantly checking for collisions with objects that are too far away for a hit to be possible. I had a couple of ideas to reduce the amount of objects being checked (like splitting up the playing area into sectors, or grouping with arrays).

I could possibly get away with using basic shapes such as squares and circles, but I'm trying to avoid that as it would dramatically cuts my freedom in creating levels.

Thanks a lot for the suggestion. I was going to play with the idea of narrowing down the search with a vague bounding-box check first, but I was uncertain whether it would bog the game down more so than a simple shapeFlag check (because of having to loop through mc's, and also possibly a normal shapeFlag)... So am I wrong to think that; or is it something that I should just test out myself?

Viza.

Well to start, you could simply cull out any objects that are not on the screen. Following that, do a box to box with the arrow against all the shapes that remain, and then a more detailed test against the one or two that are left. I cant imagine more than 20 or so obstacles being on the screen at a time, and with only that many tests you should be fine.

Sorry Phreax, just noticed your post now...

I actually followed that thread when it first was discussed, and I understand the math involved. However, that cannot be applied to a level with objects that change dynamically (moving objects, destrcutible terrain) and instead would require much more compex equations; and I'm not prepared to lose that many nights of sleep. :P

LOL, thanks for the song.

I can't imagine this being very processor intensive, especially considering that only on the morecomplex levels will there be more than 15 obstacles to check against. The reason why I'm trying to push for the best performance is because I plan to over-do the concept with lots of pretty effects and a thick layer of polish. :D

Viza.

@691175002: So will all of those checks be saving fps, or would I be over comlicating things and instead be dropping frames?

Thanks for your advice. :)

Viza.

Hmmm, couldn't you just look at the speed and direction then create a vector, scan along those points and find the hit location?

you might digg into vector collisions- very accurate + gives you lots of xtra info like angle, speed, depth,...
and then you dont check the collision with the actual prjectile but instead with the moving vector because it´s very likely that your framerate will never be able to capture the excact moment of collision.

if the motion if your projectile is not effected by random forces, and if your targets don't move, you can solve for all collisions up front...

Look up "raycasting". It is basically the same thing that hese guys above are talking about. You pretty much just create a line, then input the possible target's x value and if the height is within a certain value, it is a hit.

Since he would prefer to use art based collision, a lot of math solutions wouldn't work.

You could solve the collisions up front by dropping a massive amount of hittests before the game, it would probably take one to two seconds to determine where the arrow will hit.
If you determine the number of frames the arrow will fly before actually shooting it, you will completely eliminate any overhead involved with hittesting in real time, however a loading bar could break the flow of the game.

IMO it really isnt necessary. I frankly cannot see your game doing more than 40 hittests a frame when done properly. Save the effort, this really isn't a complex task unless you make it one. Lots of games do hundreds of hittests a frame and they are fine.

I agree with 691175002, I made this a while ago with AS3, uses a loop the size of every bullets velocity and checks a getPixel on every iteration of that loop. Doesn't loose a frame

http://soap.com.au/chris/gunGame

I can give you the source if you want

Thanks for all of the helpful feedback. :)

Many of you are suggesting to solve this using good 'ol mathematics, but as 691175002 pointed out the environment is going to be artbased and there could (I want to leave this option open) be random factors in the game (such as moving targets, shutting/opening obstacles, etc.).

Thanks 691175002. I think I'll just leave it with the method you suggested earlier. As I stated before, there won't be a great deal of collisions to handle so I shouldn't really be trying to over-complicate things. I just wanted to make sure that I wouldn't be losing fps on a collision system so I could add plenty of particles and such without a noticable slow down. :p

Malee, I suppose it would be helpful to check out your source code just to see how your handling things. PM it to me, if you don't mind. :)

Thanks for the replies guys, I appreciate it.

Viza.

ooh i would love to have that too malee! I love playing with that game lol.... i make stairs where they arent supposed to be...





Thanks alot malee:
|
|
\/

http://soap.com.au/chris/attachments/gunGame.zip

mr_malee, that could be an evil worms clone, since you're on your "favorite-old-schoolers-tribute-mission" :D

Viza, I just woke up but I can't see why math shouldn't work on moving targets and artbased gfx.

Well, perhaps I'm missing something but the way i see it is:
- If you want to do this with pure math-based collisions, than I'd have to convert all of my objects into basic math shapes (circles, rectangles, squares, etc.) to find a collision. Or of course I could use vectors to outline my shapes, but that's extra work for something that doesn't need it at all.
- Predicting a collision with obstacles constantly moving/changing would be an even bigger pain in the ass, as I'd imagine I'd have to base everything on time (so I'd have to go over all of my tweens if I have any, and find their motion times), and then create over-complex equations to compensate for the ever changing environment.

So basically phreax, yes, it could be done; but is it worth doing?..My answer is no. :)

Viza.

Wouldn't a cheat way like this work? No vector objects.

Tidenburg, isn't your .fla basically using a shapeFlag hitTest to find a collision?..

Viza.