I created a mechanism for drawing custom polygon shapes in the level editor. These shapes can be used to draw boundaries. Unfortunately because they’re created as Box2D polygons they must meet these requirements:

1. Must be convex. Concave shapes are not allowed. However concave shapes can be simulated by using multiple polygons.

2. Must be drawn clockwise. I don’t really get why this must be done, but hey, its not my rules.

3. Must not exceed 8 vertices.

I’m looking forward to creating some interesting maps!

-James

Just a small update. I fixed a problem with stacks of boxes becoming unstable when gravity was enabled. The problem was from having sleep disabled for box2d objects. Sleep needs to be enabled to simulate resting contact.

-James

Hey everyone! James is really working hard on the physics engine, and it’s been a while since my last post.  So, I figured I would give you a little video update to show they we are still working hard.  The boxes have no gravity effecting them, but the player does, so it makes for a little fun!

-Zach

I just got finished adding a ‘weight’ to the player so he now adds force to objects he’s standing on. So, for example, as the player stands on a box the box and player will fall from the added weight of the character, and, any box moving upwards will also move the character with it.

-James

Added friction to moldering, both for air and ground. The equation is:

Acceleration = Acceleration - (Acceleration*u);

where u is friction. This value is different depending on whether player is on ground or in air. For example, I set u to .35 when on the ground. This prevents the player from slipping around. However, I can make this value lower to simulate ice, or higher to simulate sand.

-James

I stayed up late and wrote code. Holding ‘B’ in the level editor draws collision boxes which create static Box2D shapes. These save and then load in-game and prevent Box2D objects from wedging between what would have been joins between touching tiles.

This removed a major glitch from the game (and Box2D engine?) allowing for a smoother game experience. Now I need to work out a few other Box2D related Moldering glitches.

-James

I’ve done a lot of work over the last couple of days rewriting buggy code. I scraped a lot of the in-game physics and brought in an external engine, merging it with the engine we already had. I don’t think the transition could have been any smoother, which is all any programmer could hope for.

The outside code is open source, so we aren’t limited in its uses. I used the Java version of Box2d, “JBox2D” and created a scaled down version of each map which now contains all of the ‘non-player’ physics objects. I also managed seamless interaction between the player and physics objects.

I’ll be posting a video in the next couple of days demonstrating some of the basic capabilities in an interesting sandbox level. So, check back for an update.

-James

Here’s a short demonstration of what I’ve been working on. You can see the new physics implementation working its magic.

Note: the guys look like they’re overlapping, but it only looks that way because I haven’t incorporated image rotations to take into consideration the true angle of the bounding box. They do not actually overlap.

You will see the physics engine evolving more over the next couple of weeks.

-James

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