Q: Best method of collision detection (fighter)
Mike Zaimont
(obligatory, these days) Hi, all.
I'm writing a fighting game (24 BPP, DJGPP/DOS, yes I know....) just to
see if I can, and I'm wondering about the most efficient way to get
collision detection.
Since only *parts* of the guys can hit the other player (i.e.
arms/legs/etc), and I *really* hate doing manual bounding boxes, I came
up with a few ideas:
1. Get my artist to do the bouding boxes (in my dreams), then use #2.
2. Painstakingly draw bounding boxes for all the frames, then if those
collide use bitwise collision detection.
3. Use only bitwise collision detection, thus avoiding bounding boxes,
but you could hit someone if they touched your back while you punched...
or, the way I though I'd use:
4. Have each frame with an invisible projectile associated with it
(over the fist/etc, and just as big as the fist) and just use my
existing projectile->sprite collision routine to tell me if I hit the
other guy.
Is there a better way? Or is there a way that's almost as accurate with
less up-front work?
--
Mike Z
Andreas Magnusson
In article <6e7jo2$a...@bgtnsc02.worldnet.att.net>,
"Aaron & Rebecca" <NOS...@for.me> writes:
> x-no-archive:yes
>
> Mike Zaimont <jzai...@worldnet.att.net> wrote in article
> <6cvhjs$6...@bgtnsc02.worldnet.att.net>...
>> (obligatory, these days) Hi, all.
>>
>> I'm writing a fighting game (24 BPP, DJGPP/DOS, yes I know....) just to
>> see if I can, and I'm wondering about the most efficient way to get
>> collision detection.
>>
>> --
>> Mike Z
>>
>
> I remember reading something about using BSP trees for collision detection
> ( in 3D games ) in the BSP FAQ. I'm afraid that I don't know where the FAQ
> can be found anymore. Anyone know?
>
> Aaron Cosand
>
Didn't Bretton Wade post it here a little while ago?
Well it's located at:
http://reality.sgi.com/bspfaq/index.shtml
/Andreas
"Te audire no possum. Musa sapientum fixa est in aure."
Shamen Regger
If you are looking for a test of fighter to fighter you can use the infamous
col-spheres or go for bounding boxes to first determine if they are near and
then test for polygonal intersection if the bounding boxes intersect.
Concerning physics/after effect: Once you determine the collision has taken
place, find the point of collision (mostly time wise, but that depends on which
approach you take be it temporal or that volume sweep method). Regular physics
equations come in from there taking in center of gravity, velocity, etc...
I have seen it where certain games have pre-determined collision resultant
paths,
as for a fighting game, ususually this is the case. Leg intersects chest
first, call anim. 3.
Mike Zaimont
Thanks to the people who replied (all four of you).....however, it's
ironic:
I posted this several weeks ago (!) and since then, I have solved the
problem, and moved on :^)
I decided to use the "conventional" method ("leg intersects chest first,
call anim 3"), and am now trying to figure out exactly how the combo
system should work....I'm going for an OMF-style thing, where each move
will only hit once per juggle-combo....
As if anyone (but me) cares, but thanks again!
--
Mike Z
Kris
In article <6eabq7$d...@bgtnsc03.worldnet.att.net>, Mike Zaimont
<jzai...@worldnet.att.net> writes
You are not alone! I know it seems as though everyone on this newsgroup
is only concerned about the process of making Quake like games, but I'm
also working on a fighter. It would be interesting if there was a
newsgroup purely for programming beat-em-ups. Aometimes I wonder if the
guys on this newsgroup are real gamesters, or just enjoy programming
first perspectives because it's a challenge. I've never once seen a
thread about the technicals of fighter AI, or how Mortal Kombat or
Streetfighter or House of the Dead where made (real games in my eyes).
I think a good way to make combo's is to test for the keypresses whilst
your guy is doing a kick or punch ( or whatever). When you want the
move to combo into the next move, then say, ok if the key for the next
attack is pressed on frame ?? then ignore the rest of the frames of
animation and go on to the next move. That way you can control the
timing aspect of the combos so that people with lousy skill can't do
certain combos.
As an example, take StreetFighter - when Ryu does a hard punch, you
would set your combo function to test whether or not the dragon punch
code has been entered as Ryu pulls back his hand, if so then skip the
rest of the punch frames and go into the dragon punch.
Kris
Andrew James Bednarz
Kris <j...@wishingtree.demon.co.uk> wrote:
: You are not alone! I know it seems as though everyone on this newsgroup
: is only concerned about the process of making Quake like games, but I'm
: also working on a fighter. It would be interesting if there was a
: newsgroup purely for programming beat-em-ups. Aometimes I wonder if the
: guys on this newsgroup are real gamesters, or just enjoy programming
: first perspectives because it's a challenge. I've never once seen a
: thread about the technicals of fighter AI, or how Mortal Kombat or
: Streetfighter or House of the Dead where made (real games in my eyes).
Im currently writing a plain 2d platform adventure (in the
style of the Codemaster Dizzy games).. not that there is anything
particularly difficult about that but as you I am SO *#*$&#$&^# sick of
3d 1st person perspective games..
--
Bed
bed...@yallara.cs.rmit.edu.au
http://www.geocities.com/Hollywood/2430
"Loving you was like loving the dead" - Black No.1, Type O Negative
Brian Shields
Kris wrote:
>
> In article <6eabq7$d...@bgtnsc03.worldnet.att.net>, Mike Zaimont
> <jzai...@worldnet.att.net> writes
> >Thanks to the people who replied (all four of you).....however, it's
> >ironic:
> >I posted this several weeks ago (!) and since then, I have solved the
> >problem, and moved on :^)
> >I decided to use the "conventional" method ("leg intersects chest first,
> >call anim 3"), and am now trying to figure out exactly how the combo
> >system should work....I'm going for an OMF-style thing, where each move
> >will only hit once per juggle-combo....
> >
> >As if anyone (but me) cares, but thanks again!
> Hey Amigo,
>
> As an example, take StreetFighter - when Ryu does a hard punch, you
> would set your combo function to test whether or not the dragon punch
> code has been entered as Ryu pulls back his hand, if so then skip the
> rest of the punch frames and go into the dragon punch.
>
> Kris
That would look really good for combos, and esp. when you get hit mid
move, so your character's limbs don't sudenly jump mid-move. Just a
thought.
- Brian
--
Brian Shields
Birmingham University School of Computer Science
Please remove the anti-spam statement in the domain name
from my address to reply
Dave
I started coding a fighter a long time ago and I got acceptable results by
building a pre-defined table. Take this into consideration....
(never did finish my fighter though....)
Ahead of time you will know which frames of your fighters are block,punch,kick,
etc.
So why not build a pre-defined table that tells you the outcome of two frames?
For instance a kick to the face frame compared to a fighter standing still
frame would equal a HIT. Then you could have a table for the power of that HIT.
The only other table you might need is one that holds the distance between two
frames needed to even trigger the HIT table look up. I've always felt this was
the easiest method of doing those Mortal Kombat 2D type games. It requires a
pre-built table, but the actual code in the game loop would just be a simple
table look up depending on frame value.
'
Let's look at this: (In somewhat basic code...)
'
total_frames=1000 ' how many total frames in game (every animated frame!!)
'
' The idea is to ahead of time define a power to each animated frame and then
' later during the game you compare the power values to each other if they are
close
' enough! You should define a scale from 0 to the largest power you need. A
larger
' scale would give you better flexability.
' For our little example we'll assume 0 is no power at all and 1000 is max
power!!
' 1000 might be a power ball, laser or whatever!!
'
Dim compare_frame(total_frames) ' Power of frame
'
' Let's say a standard kicking frame=1 and a standing (not blocking) still
frame=0
' So you would pre-define these table entrys as..
compare_frame(1)=200 ' 200 power for a standard kick
compare_frame(0)=0 ' no power at all for just standing stll!
'
' So.....
'
if compare_frame(player1)>compare_frame(player2) then ' player 1 hit player
2!!
if compare_frame(player2)>compare_frame(player1) then ' player 2 hit player 1!!
if compare_frame(player1)=compare_frame(player2) then ' they hit each other?!?!
'
You would still need to set up a distance array look up table to see if the two
frames are actually close enough to warrant a power loop up. If player 1 is
kicking at the left side of the screen and player 2 is standing still at the
right side, that wouldn't trigger a hit!!
'
Hmm...maybe I'll get back to coding a fighter after all...... :)