123
-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|682|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Concept/Design -> Gauntlet collision algorithm

Fri, 06 Aug 2021, 08:05
Pakz

Gauntlet collision algorithm (GDC video)


I was doing some practise programming on the ipad and iphone and had this GDC video about this old arcade game "Gauntlet" playing in the background. There was a part where the speaker was talking about the collision method used in this game. I was just noticing how slow my code was and tried to implement this collision algorithm.

I was succesful!

When you have lots of collision going on in the game. Say a thousand sprites and you need to make sure they check their position against each other. Then in stead of checking 1 vs all others in a loop you divide the area up in sectors.
You put each sprite into these sectors, and this is as simple as clearing the sector list and putting them in again based on the position divided by the sector w and height. You do this every frame and when you have these lists per sector set up, you can then check 1 sprite vs the ones in the grids on and just besides it.

It took me a while to get working as I'm currently also trying to learn this new scripting language "Lua" but it all seems to work now!

Here is the video where I got the idea from. At minute 27 or so the part on the collision method is talked about.


View on YouTube
Fri, 06 Aug 2021, 08:14
Jayenkai
An hour of text!? Gawd.. Exactly the sort of video I hate. Why people can't just write this stuff down, I've no idea.

The way I'd do it...

Have a spare "Bullet Map" array, and empty it at the start of your bullet drawing loop.
Then, during the bullet drawing, BulletMap(Floor(BulletX/8),Floor(BulletY/8))=BulletNumber

Then, during the enemy drawing, if BulletMap(Floor(EnemyX/8),Floor(EnemyY/8))>0 then Bullet(number in the array)=Off, BulletMap(here)=0, EnemyHealth-1
It's not exact, but it's definitely quicker than doing the giant 100 bullets vs 100 enemy loop.

-=-=-
''Load, Next List!''
Fri, 06 Aug 2021, 08:26
Pakz
So you divide the game world into 8 by 8 pixel grids? Do you not check using a circle or rect overlap, but just if the bullet and player/npc is in the same 8 by 8 grid?

Tech text sometimes is confusing and usually written by and for academics
Fri, 06 Aug 2021, 09:10
Jayenkai
Nah, splitting it to 8's usually enough.
For fast-paced bullets, you don't "really" need pixel perfect precision, as long as the bullet's close enough to the enemy, it oughta do damage, right?!
If you'd like, you can then do some extra "closeness" maths and damage the enemy a bit more based on how close the bullet is.
.. But in general, my games tend not to do that!!

Of course, enemy bullets shooting at the player should always be a bit more precise, since that's "fairer" on the player.

-=-=-
''Load, Next List!''
Fri, 06 Aug 2021, 11:16
PHS
Interesting.
Fri, 06 Aug 2021, 15:16
cyangames
Makes sense, it's maginally quicker to check for a couple of equals cases as opposed to a box collision case, esp when you are tightly CPU bound. I use similar stuff in NES coding when it comes to background collisions as it just makes sense to do it that way, a lot of it comes down to hardware limitations.

-=-=-
Web / Game Dev, occasionally finishes off coding games also!