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

[Bob the Hamster]

On Sat, Apr 14, 2007 at 02:32:46AM -0700, Brian Fisher wrote:
> 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.

Yes, I am resolving before I move. By adding my velocity vector to my 
position vector, it is easy to know where I will be if the movement 
is allowed to continue.

> 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

I am solving that issue by making an iterator that goes along a line 
from your current position to your possible future position in 
smaller-than-a-tile sized increments.

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

Yeah, probably not.

> 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

Quadratic?

I think my brute-force method will be okay.

> 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?

Yeah, it makes sense. Right now I am just taking a chaotic 
experimentation approach.  Zen game physics design.

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

What I am trying now is that I just have one velocity. My reason for 
wanting to keep different velocity types separate is because I didn't 
want gravity to cause you to dig down while you were trying to dig 
sideways.

But I found a better approach to that. pressing the arrow keys not only 
accelerates you in a direction, it also kepps track of what direction 
you are trying to go, and only that quadrant of the circle will be 
diggable. Si if you walk to the side and dig, you only dig in the 
direction(s) you are pressing. You don't dig down unless you push down 
no matter the gravity, and you don't dig up unless you push up, no 
matter how fast you are jumping.

(I'll check in the code that implements that behavior later this 
weekend.)

> 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?

Basing hill-climbing on whether a tile is above or below your center of 
gravity caused problems. That resulted in considerable bouncing and 
catching.

I think what I have to do is when you collide with a tile, the tile 
needs to check to see if there is a tile above it. If not, then it 
accelerates you upward. I haven't tried it yet, but I think it will 
work.

---
James