|
-
Style Through Simplicity
[Optimising] Bullet theory (collsion checks)
Hey guys, here I am again needing some more optimising advice. This time however, I’m being sensible and trying to optimise as I go along rather than when the game is complete and I realise it runs at 2 fps.
The game is my latest shooter 'Bullet Theory' which some of you might know I'm working on (very slowly) from the topic I made asking for help converting the name to Japanese.
Anyway, as the title has bullet in the name, you might expect there will be a lot of bullets involved and you would be correct (see screenshot), therefore I need to make sure that everything is optimised as much as possible to prevent slowdown.
My question is, when checking if enemy bullets are hitting the player, would it be faster to check if the bullet is in the same area as the player before performing a collision check, or would it be faster to simply perform collision checks on all of the bullets regardless of their position in relation to the player?
I'm already doing the area check system when checking if the players bullets are hitting an enemy because there are multiple bullets and enemies involved, however, there is only one player ship which leads me to think that doing an area check could slow the game down more than it speeds it up. I'm just using shapeflag hitTest for the collision detection (the player only gets killed if the ship is hit right in the middle).
So would doing the area check simply add un-needed code, or would it speed it up overall due to less collision checks?
Any advice would be appreciated as always 
Ali
-
In one of my latest projects, the way I did the collision checking for the bullets against the enemies was something like this:
1) All the enemies are in a enemy_container_mc
2) My bullet is shot, it checks its point hitTest against the enemy_container_mc
3) On finding collision with the enemy_container_mc, it does a for..in and checks for hitTest against the enemies through the enemy array.
4) Finds the enemy against which it has collided and does the specific actions required from there on and removes itself.
Hope that helps. 
BTW: Long time dude. You've come a long way. Cheers!
Edit: Hmm, re-read your message, will need to think about this one :P
Last edited by adit_ya_sharma; 11-15-2006 at 12:37 PM.
-Aditya
-
Hype over content...
Mate, that looks a lot like my current game.
I really hope you're not having a shield in there Ikaruga style 
Squize.
-
Style Through Simplicity
-
In your picture i see that alot of bullets are only for showcase. How about check which bullets are actually going to have a better probability of hitting the player's ship and only assigning those bullets into an array to check through for collision.
-
Style Through Simplicity
The player ship can be anywhere on the screen, so all the bullets could in theory hit the player. I could probably somehow predict which ones don't have a chance of collision, but it would be very hard to do and would probably kill it.
Ali
-
Hype over content...
Sorry, should have given a proper answer.
In my game I've just split the screen into quarters, and then just loop through which bullets are in the same quarter as the player.
It's going to sound a bit weird, but the quickest way I've found to calculate which quarter a sprite is in is by using hitTest. So I have 4 mc's on the stage, set _visible=false and then just hitTest against them, which gives me the quarters ( Hope that makes sense ).
Squize.
-
Style Through Simplicity
Yea, that’s what I’m doing with the enemy collisions except ive split it into 4 horizontal bars, and im using coordinate checks rather than hitTest, but I know what you mean.
This is where my question comes in though, because if you do it like that, you are doing a hitTest for every bullet to check where it is, and then 25% of them (approx) have to do another check for collision with the player, so therefore you are doing more checks than you would be if you just checked all of them for collision in the first place. Is a standard hitTest faster than a shapeflag hitTest? If so, is the difference enough to justify the extra checks?
Ali
-
I'm working on a shooter as well....I'm using a heavily modified version of the goToAndStop engine, which helps quite a bit with collision checks, since most of them are just coord. checks to see if the player is in the same tile as the bullet, rather then the actual collision.
if the bullet is in the same tile as the player, I then run a bitmap.hitTest pixel collision to get an accurate collision between bullet/player ship.....
it works out quite well, and it's pretty speedy as well......
I used the same method when testing player bullets against parts of the map level (i.e. walls/level objects...etc) .....testing tile coordinates, and only if that tile is not empty, run a bmp hitTest on it......it's quite fast and more accurate then the regular hitTest....this way I can have any kinds of shapes inside my level/tiles and still get accurate collision....same for objects like NPCs....
paul.
-
Hype over content...
-
Style Through Simplicity
Pentru - Cool, sounds good. Wouldn’t be much use in my game though as all the extra calculations would just be extra work where its not needed (I don’t really have anything to collide with other than bullets). Good luck with your game I think that puts it up to about 5 people making shooters now unless some have given up.
 Originally Posted by Squize
That's actually made me think... bugger, think I may have done something stupid 
Hehe The reason I posted this topic was because I was about to do the whole area check thing and then i thought.. hang on... so looks like It was a good job I took a few seconds to think about it . I think that we have just about determined that the fastest way would be to just do the collisions checks ignoring anything else. Sorting the bullets like you suggested could work (worth a try), but on the other hand it could just have the same effect in giving it extra work to do.
Much. iopred showed ages back that surprisingly enough bounding box hitTest is quicker than a math's based check too, which freaked me out ( Although not as much as realising I've done something really dumb in my game  ).
Squize.
I thought so, I read on a game development board somewhere (non flash) that one of the benefits of point collision in shooters is that its faster to calculate, but I had a feeling this wasn’t the case with flash. Still, I think that overall it would be faster just to do the collision checks than doing all the area checks first.
Something to think about anyway 
Ali
-
Hey Timmy!!!
I was going to suggest just the bonding hit area, mainly because I use it alot and haven't done math stuff. They always seemed to work really good, till something happens and breaks it from my stupid little mistakes.
I found it funny that in my current game I'm takin the changing energy method to kill bad guys from Ikaruga into mine.
-
Style Through Simplicity
The basic hitTest function can be very useful in a lot of situations. If I used it here though you would be dead before you could blink .
Ali
[EDIT]
Does anyone know of any explosion maker programs? Free would be nice . I’m having problems coming up with some good looking explosions for my game. ParticleIllusion is good, but way too expensive for what i need it for, anyone know of any others?
Thanks.
Last edited by alillm; 11-15-2006 at 04:06 PM.
-
Hype over content...

You could always put a 1x1 mc inside your player sprite, turn that nasty ol' visible to false and use bounding box hitTesting against that.
( Trying to make amends for being a dumb ass earlier )
Squize.
-
Style Through Simplicity
Oh yea, nice one No idea why I didn't think of that.
You could always just edit your post from before, nobody would ever know and your reputation would remain intact just kidding.
Ali
-
Hey Timmy!!!
Ya, I didn't think of that till after I posted and looked at the picture again. Well I know in 3Ds Max you can get some pretty cool explosions, but its not free. Umm theres always the way of going with actual movies and cutting the background so its just the explosion. Which might be some work. Sorry if I'm not much help, just kinda goin on and on.
-
Style Through Simplicity
Yea, unfortunatly 3DS is a bit of of my price range, blender can do particle effects (thats what im using for the ship models) but i'm not sure how good they would turn out, i will give it a try though.
Ali
-
Hey Timmy!!!
Blender is definitely a good one too. I just started playing around with it, so I'm not too sure what kind of effects it can do. I did find this though, it's in German I think but it can be changed to english. Looks pretty cool though.
http://www.east-power-soft.de/
go under Software / PROGRAMME / SIMPLY EXPLOSION MAKER
And there will be a link up top for english
-
Pumpkin Carving 2008
http://board.flashkit.com/board/showthread.php?t=709276
A free explosion renderer as well as links to tutorials to make explosions.
The 'Boose':
ASUS Sabertooth P67 TUF
Intel Core i7-2600K Quad-Core Sandy Bridge 3.4GHz Overclocked to 4.2GHz
8GB G.Skill Ripjaws 1600 DDR3
ASUS ENGTX550 TI DC/DI/1GD5 GeForce GTX 550 Ti (Fermi) 1GB 1GDDR5 (Overclocked to 1.1GHz)
New addition: OCZ Vertex 240GB SATA III SSD
WEI Score: 7.6
-
Senior Member
In many non-Flash games they'd use a QuadTree:
http://en.wikipedia.org/wiki/Quad_tree
And represent the ship as a set of four points (a bounding box around the ship). They'd do the same with all the bullets. Then by starting at one of the points in the ship, they'd check the current "quad" for any "bullet" points. If there were some, they would compare the current ship point against the bullet point with a bounding box check. If there was collision on the box, they'd do a pixel-to-pixel check to determine the final collision.
The depth of the quad tree will determine how much constant overhead exists with every bullet. The points will need to be updated with every game loop to keep things accurate. The advantage being that the actual overhead for collision checks is trivial because you just arn't checking that many.
In the end, this is close to the approach Squize describes as well.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|