[motherhamster] SVN: james/247 Press CTRL or Z to dig. Collision is better, but still not at all elegan

[Brian Fisher]

I'm afraid I don't really have any experience directly relatable to
what you are trying to do here... so I guess I'll just pontificate on
your situation and hope something helpful comes out :)

On 4/13/07, Bob the Hamster <Bob at hamsterrepublic.com> wrote:
> Hey, Brian. I could use some input on how to make wall collision not
> suck. I am using a circle for my player's hit-detection, but the gid is
> of course, grid-based.
>
I am biased towards apriori, or continuous collision detection
methods. Which is to say that you decide where you will detect and
resolve collisions either before you move/as you move. That's opposed
to aposteriori or discrete collision detection. Which is to say that
you would detect and resolve collisions after moving/collide at the
position you are at.

Basically detection is generally much easier and significantly faster
with discrete - however resolution can be harder because you may have
multiple collisions to resolve at once, which can lead to stuff like
bouncing and getting stuck or wedging your way through places you
shouldn't. Also it is only appropriate for things that will always
move less than half their minimum dimension in one detection step

Detection is much harder and slower to do with continuous - however
collision resolution is generally rather easy because you always
resolve one collision at a time, The other major plus is that in the
absence of bugs, there is no type of motion or occasion that can let
you get into a "bad" state, so if you have a fairly simple way for
stuff to move and interact, it can be "perfect"

There's a whole lot of other issues with the two approaches when it
comes to stacking many objects, rotational or complex motions & forces
and all that, but none of those issues should come up for you.

Anyways, what it comes down to with your whole circle collide with
grids thing is that discrete detection will be easy and fast to do, no
math worse than multiplication really. With continuous detection
you'll need to do solve quadratic equation stuff with all the dirt
tiles you may collide with. So it would be a fair hassle, honestly,
and discrete I think may be the best choice

However if you can treat the player as a grid aligned rect on the
other hand (or as a collection of grid aligned rects) then continuous
detection is actually super easy, and in my mind would be the obvious
choice (discrete detection isn't too different with either circle or
grid-aligned rects)

So does all that make sense? any of the things you want more info on?


> I would like to be able to crawl up non-steep blocks, and I am not sure
> how to best distinguish from player move/dig velocity, gravity velocity,
> and jumping velocity.
>
I think the thing that would make the most difference is what non dirt
things you will collide with and how they should affect you...

If you wanted to go with "disitnguishing between velocity types" I
would think you'd want to stick with a system where various reasons
for moving "take turns" telling the player what to do. So say you are
in a falling/jumping state. Then accelerate down due to gravity, apply
any in-air adjustments then try and then move and deal with
collisions. If you have decided your feet are stable, apply any
walking movement then deal with collisions.

However I'd tend to go with not distinguishing between different types
of velocity, and basically having all objects first go through a pass
to apply forces & controls and then go through a pass where all
objects move and collide at once (to stick with the a priori method).
The reason for that is so that if something is thrown at you or
dropped on you or whatever while you are moving, the collisions would
always be able to resolve in a consistent way, as opposed to if
objects all take turns moving for different reasons, where every
collision could end up resolving one of 2 ways, depending on which
object happened to end up doing the movement into the other.

As far as climbing not too steep ways, a lot of that would naturally
fall out the way you want though collision resolution. so if you hit
something below your center  when going to the side, the collision
resolution could result in some upward force being applied to you
(climbing). If if hit above your center, it could result in some
downward force. Note that if you were doing circle collision for the
player with proper physics-y resolution stuff would behave exactly
that way naturally, but if you did axis aligned rects, you could make
your collision resolution stuff behave that way too with no real
trouble. (i.e. collide as a rect, resolve more like a circle)

Does all that make sense?