Bounciness Fixed, Now Quick Sand

I fixed the bounciness by adding a state variable called impact that is true when the player makes contact with a block. When impact is true, the magnitude of the contact force is equal to:

mass * velocity.magProj(new Vector(nTheta + Math.PI, 1)) / dt

In my bouncy build it was mass * velocity.magProj(new Vector(velocity.getTheta() + Math.PI, 1)) / dt which is wrong. I don't know what I was thinking.

When impact is false the magnitude of the contact force is equal to:

sumForce.magProj(new Vector(nTheta + Math.PI, 1)

The reason the player sinks is not exactly clear to me. After the impact force is applied to the player, he bounces up for about 2 frames then lands again and gets another (but smaller) impact force. After this, f_net in the y direction is zero. The problem is that there is some left over velocity (on the order of 2 pixels per frame) from the impact. It looks like the impact force is slightly too small. Maybe? I'm not sure.

In this video, the player is shot off the screen as if from a cannon because it is getting the normal forces from the sides of the blocks. This should be fixed when I fix the sinking.

The sinking isn't just in the Y direction. It happens on the walls too. I'll figure this out soon...

So. Much. Physics. Maybe classical Newtonian physics was a bad idea but now I'm stuck with it. Hopefully it pays off in the end.

I've finished my exams so I think I'll be up most of tonight coding.

Map

Now that I finally started this blog, I can go back and highlight some of the things I've already done. We'll look at the Map class. The map is composed of blocks, and at the moment there are six types of blocks (air, ground, and 4 orientations of triangles).

This is my first large project in Java, so this is a learning experience. I spent quite a bit of time trying to decide which class "knows" the block position and height. For a while I thought that a block should know these things, but it just wasn't working the way I wanted to. So, I landed on the map owning these state variables.

The Map class takes a .txt file and outputs a .map file and a .png. I will allow users to create their own maps.

Let's look at an example:

this text:

111111111111111111111111111111111111111111111111111
110000000000000000000000000000000000000000000000001
110000000000000000000000023000000000000000000000001
110000000000000000000000054000000000000000000000001
110000000200000000000000000000000000000000000000001
111111111100000000000000000000000211100000000000001
111111111111111111111111111111111111400000000000001
110000000000000000000000000000000000000000000000001
110000000000000000000000000000000000000000000000001
110000000000000000000000000000000000000000000000001
110000000000000000000000000000000000000000000000001
110000000000000000000000000000000000000000000000001
110000000000000000000000000000000000000000000000001
110000000000000000021111111111300000000000000000001
111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111111111

Makes this image.

This is the image that I used in the bouncy physics demo. The screen doesn't move with the player yet. I know I'll have to implement this to do it, though.

I have yet to decide on how I will handle the number of blocks on screen at a time. It should probably scale with velocity of player but for now, it'll be static. I should probably zoom out from what I had in the physics demo yesterday (26 blocks wide, 14 blocks tall).

Size Update (686 lines and 25KB)

Early build is a buggy, bouncy physics engine

This is the very first build of Kromapoka. It's only a physics engine at the moment but I have great ideas for this platformer. It is written in Java and is my final project in AP Computer Science A. Even after I turn this in, I will continue working on it and plan on selling it to pay for college. Cornell is expensive...


The bounciness is a soon-to-be-fixed bug. There are two types of contact force. One for impact and one for non-impact (no velocity in the direction of the block). I have yet to implement non-impact force. So, that's why the player bounces


Why Kromapoka? What a weird name, right?


One of the main story elements of this game will be that a yet-to-be-named baddie has stolen all the color from the world and you must bring it back. Color restoration.


color --greek--> chró̱ma
restoration --greek--> apokatástasi̱

 I changed chroma to kroma because Google thought Chromapoka was a misspelling of Chromebook.


I put a lot of work into my physics engine so that it matched classic Newtonian physics. You know, all that stuff your high school physics teacher taught you. Forces, DVATs, and the like. For each frame, the player (and other objects soon) has all the forces on him summed up and from there the position delta is calculated like so:



        xPos += velocity.getX() * dt + .5 * acceleration.getX() * Math.pow(dt, 2);
        yPos += velocity.getY() * dt + .5 * acceleration.getY() * Math.pow(dt, 2);


I won't reveal too much of my code in general, but this is nothing special. What's special about this platformer? Why didn't I jump in that video? Maybe both of these questions have the same answer.