This problem (which I have coined the ‘shuffle’ problem, for lack of a better term)  is not acceptable for the quality of game we are creating. It seems to stem from the objects on the bottom not being processed before the objects on the top necessarily. An ad-hoc solution would be to sort all the objects by their Y-coordinate and work from the bottom up. However, while this works great for things experiencing gravity, it doesn’t help us when we want to work on the horizontal axis.

As a result I’m reworking the physics engine entirely. I think I have found a great resource in Box2D. I have been implementing it and everything is going good so far.

I’ll keep the blog updated as things develop.

-James

Solved: See this post.

So, now that I have drag, expressed as:

        k1=.09;
        k2=.01;
        drag=(k1*accAccumX)+
             (k2*(accAccumX*Math.abs(accAccumX)));
        accAccumX-=drag;
        grandVelX=accAccumX;

My objects will reach a maximum velocity and slow down accordingly. However, they don’t slow down appropriately when on the ground. What I need to devise is a friction when the player is on the ground. This way he doesn’t float along until drag is enough to stop him, but rather stops the player quickly when the controls are released. Like in real life, friction will stop you quickly instead of letting you drag on. Then I can change the value when the player is on ice, or sand, or just grass and have the appropriate effect.

I’ve been looking into it and I can’t find exactly what I am looking for.

Possible solutions:

1. increase the drag (or create a new one) when the player is on the ground, although this isn’t necessarily the best way.

2. Create a new variable ‘friction’ and do something like this:

      if (player is on ground)
          velocity = velocity * friction;

This doesn’t seem right either.

Any thoughts?

I was having a lot of problems trying to create a drag force as a result of speed. I finally got it after realizing that you don’t multiply the drag to the acceleration you add it as it’s an opposing force.

For anyone interested the code looks like this:

        k1=.09;
        k2=.01;
        drag=(k1*accAccumX)+
             (k2*(accAccumX*Math.abs(accAccumX)));
        accAccumX-=drag;
        grandVelX=accAccumX;

In this case there are two coefficients of drag, k1 and k2. K1 is general drag and k2 is the limiting drag. As the object reaches higher speeds the k2 drag will be higher and as a result you will have more negative force.

In the real world you would have much higher coefficients, but in a game you’ll want to mess with this value to get the desired movement you want.

Now we can alter these drag values when in water or other fluids.

Feel free to use this code without my permission. It’s a very general equation.

-James

I’m reading Game Physics Engine Development by Ian Millington. It’s helping me figure out lots of collision and force related equations. However I still have a code problem this book isn’t helping to resolve. Let me break it down:

The game has a main cycle…

1. Update every object

2. Draw the result

3. Repeat

A problem occurs when an object applies force to another object and the second object appears to lag behind. What’s happening is that the lagging object was updated before the force applying object and as a result the lagging object doesn’t update until the next cycle. In this scenario the drawing function has been applied before it updates again and as a result it doesn’t reflect the new force.

I was thinking of several approaches:

1. Calculate any remaining force applications by adding a third aspect to the main game cycle at the end to make sure everything is up to date.

2. Create a “flag” in each object which tells an object whether to update or not and apply a second update while turning this flag off. I could have this flag automatically turned on again after every update.

3. My mind started to wonder about a contact resolver class and how I could implement something to mastermind all the physics equations.

EDIT:

I was able to fix this problem by keeping track of all the new forces and adding a third stage to the update process. During the original update stage all new forces are added to a list. After all the updating has been done, all the forces are taken care of. Thanks goes to h4tt3n for suggesting this was a good approach.

EDIT: This above is just an adhoc approach now that I’ve utilized and thought about it, it can be improved. Check back on this blog for an updated approach.

-James