[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.

really all you need is an efficient loop, maybe a simple cell data structure. Will you know the max speed of any projectile?

if so you can create cells the size of this maxspeed and add/remove objects from the cell, so you only need to loop over objects in the current bullets cell. Very simple and efficient.

I think computing collisions at the spawn time of a bullet is going to be much more CPU intensive than a loop. Especially if objects are going to move, you'd have to loop over every single object, find its future position compared with the bullets future position and see if an intersection happens. You also would have to keep the loop running until all objects have been checked otherwise you'll get inaccuracy problems. Sounds bad to me.

Yep, I see what you're saying Malee. I had a similiar idea not so long ago but ditched it because I thought I was starting to get a lil too ambi,tious in creating a nice collision system when it could get away with crappier (yet suitable) methods such as hitTest.

Imo, the most CPU consuming part of this system will be calculating the arrows position between movements/frames (because it onvolves a large, repeating loop). So far I got this working with pixel-perfect accuracy and I'm only dropping one or two frames (it actually uses your method Malee, so thanks! :p).

I'm going to decide between 3 simple methods:

Solution #1:Have an array containing all mc's of grouped obstacles (so 2-3 obstacles per mc). Loop through array to find a bounding-box collision between mc's. If there's a hit break the loop and look for a shapeFlag collision between all obstacles inside mc (this use the loop that I was talking about in the above paragraph). If there's a collision break the loops, find the pixel colour of the shape in collision layer, and act accordingly.
Solution #2:Find a collision between all obstacles and the arrow using a shapeflag hitTest accompanied by a loop to get pixel-perfect accuracy. When a collision is found break the loops, find the pixel colour of the shape in collision layer, and act accordingly. [NOTE: This is the same as solution #1, but ignores all of the extra fuss of grouping mc's as I thought that would be overkill with only 10 obstacles on screen most of the time]
Solution #3:With the use of a loop (to get pixel-perfect results), check the pixel colour of collision layer every step between movements of arrow. I figured this would be OK as long as the getPixel command isn't so demanding on the frame rate.

So yeah, they seem to be the best and simplest options, but i just need to find the most suitable one (solution 1 seems to be the least demanding, followed by 2, and solution 3 comes last (but I'm not completely sure, as I've never experimented with finding pixel colours and such)).

Sorry for making this simple scenario appear to be a lot more complex than what it trully is, but I just want to make sure I'm not throwing away a good frame rate because I took an easy way out.

Viza.

putting all hittable objects within 1 mc is a good idea, so you only check for a shape flag hitTest on the movement loop, then when a hit is found go into that mc and find which specific object touched.

Its not like every arrow will be hitting something every frame, so sounds good to me.

remeber you don't need to be super pixel accurate, you can move in steps, but make sure that the step size is never bigger than the smallest enemy/ obstacle and you'll cut the movement loops down heaps.

HAHA. So it looks like after all of those helpful replies I'm pretty much reverting back to my original plan in the very first post :p... Unless someone else can point out that one of the other solutions will be just and easy and more beneficial?

Oh and yeah Malee, I've optimized the loop and so far there's no slow down. :)

Viza.

well I dunno, its my personal opinion that the loop method will work better.

anyway, get a demo up so we can shoot stuff :D

Yup, thanks Malee, That's exactly what I wanted to hear.

Eh.. I wasn't planning to give anyone a peek this early, as there's not honestly a lot to show. Here's a demo of the current build anyway (thanks ever for the quick 'n free hosting): v.4 Firing Test demo

As you can see this is certainly no game yet and there's still a few kinks that needed to be fixed, but you'd be suprised with how much of the core engine is ready... Once I sort a few more things out and have made a couple of levels, I'll show it off again to hear some of your comments. :)

Viza.

Uhm, dead link?

it is flatlining is what it is...

This one should work:
http://truimagz.com/hosting/viza/Pri...0test%201.html

It was an error with Everfornever's free file hosting. :rolleyes:

Viza.