teamSize++ and Other Things

Lots of things to say today: the biggest is that I'm no longer working alone. My roommate has joined me. He's a pretty awesome programmer and really good at math.

Quicksand Fix:

We decided to fix my engine instead of using someone else's. I fixed the quicksand (for real this time) by adding the non impact force to the impact force (if impact is true). Here is the new snippet:


protected Vector calcContactForce(float theta) {
    if(impact) {                              
        if_contact = new Vector(theta, (float) (mass * velocity.magProj(new Vector((float) (theta + Math.PI), 1)) / dt)).add(new Vector(theta, sumForce.magProj(new Vector((float) (theta + Math.PI), 1))));
            // impact plus notImpact
        }
        else {
            f_contact = new Vector(theta, sumForce.magProj(new Vector((float) (theta + Math.PI), 1)));
        }
        return f_contact;
    }
}

I was so happy when I finally got this.

Zooming and Cropping:

The view now moves with the player and scales with velocity according to a Gompertz Curve.

Redoing Collision:

My roommate is redoing the collision system to make it more general (so that it can support more shapes and maybe even rotated shapes down the line). It's not done yet though.

Size Update:

justin@agartha:src$ wc -l *.java

   21 AirBlock.java

   31 Block.java

    7 CanDraw.java

    5 CanMove.java

   32 GroundBlock.java

   57 KromFrame.java

   42 KromGenericLine.java

   61 KromLine.java

  175 KromPanel.java

   39 KromPoint.java

  114 KromRectangle.java

    9 KromShape.java

   64 KromXLine.java

   59 KromYLine.java

  105 Map.java

  160 Physics.java

   37 Player.java

   87 SlantBlock.java

   69 Vector.java

 1174 total

justin@agartha:src$ wc -c ../bin/*.class

  775 ../bin/AirBlock.class

 1200 ../bin/Block.class

  173 ../bin/CanDraw.class

  251 ../bin/CanMove.class

 1122 ../bin/GroundBlock.class

 2474 ../bin/KromFrame.class

 1632 ../bin/KromGenericLine.class

 1541 ../bin/KromLine.class

 6910 ../bin/KromPanel.class

 1474 ../bin/KromPoint.class

 4054 ../bin/KromRectangle.class

  423 ../bin/KromShape.class

 1302 ../bin/KromXLine.class

 1302 ../bin/KromYLine.class

 4327 ../bin/Map.class

 5169 ../bin/Physics.class

 1551 ../bin/Player.class

 1944 ../bin/SlantBlock.class

 2315 ../bin/Vector.class

39939 total

Huge size increases. We passed 1000 lines. Woohoo! Almost 40KB too.

Git is Magical:

We are using git for version control. The subheading sums it up.

I think that's it. I'll be showing a video of all the recent changes whenever the new collision system is working.

Unity is better for 3d. All I need is a physics engine.

I've decided to use http://www.jbox2d.org/ as my physics engine. I suggest you play with this: http://gwtbox2d.appspot.com/

This engine was used in Angry Birds and others, It is free and open source (zlib license). I've decided to stick with java because it is cross platform by default and a port to android wouldn't be too hard.

Thinking about switching to Unity

So, that solution to the quicksand I stumbled upon wasn't a solution at all. It looked like it fixed the problem but the character was actually just bouncing a tiny bit. I knew the problem was still there because I could still push the character through walls.

I think at this point it is fair to say that my physics engine is broken. I don't know if it is worth the effort to go back and fix the entire engine. I've been thinking about using Unity instead. They've promised support for GNU/Linux with Unity 4. I assume this will include an editor too.

I've been wanting to learn C++ anyway and I don't want to give up on Kromapoka just because I made some mistakes in my physics engine that I can't find.

A friend of mine recently told me that I should be a lazier programmer. I realized that I should stand on the shoulders of giants instead of trying to right every line of code myself. The people that make these engines are much better than me and are asking coders to use their engine.

I just have to wait for unity 4. I will not boot into windows to code. That just seems so backwards to me.

EDIT: Just found out that the port is only for the publisher. Maybe Wine will have to do. Also, my comment about C++ might be incorrect. I think it's C#. O well, pretty close anyway.

Quicksand Fix and Open-Source

Sorry for the long delay since my last post. I've been working 8-5 and that doesn't leave much time for working on this. However, I was tinkering with the physics engine yesterday while my scripts were running. Through a stroke of luck, I fixed the quicksand bug.

I changed the non-impact contact force from

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

to


new Vector(theta, 10 + sumForce.magProj(new Vector(theta + Math.PI, 1)));


I still don't know why it works...


Other than fixing that, I have been thinking about licenses. I want Kromapoka to be open source but I still want to put money toward paying for college.


maybe a license along the lines of: 

Users have the right to edit any and all files under this license. Users are forbidden from distributing this work, in whole or in part, whether commercial or not. Distributing derivations without written permission from the author are also prohibited.

I realize that I am just opening the avenue for pirates. I prefer to ignore the pirates and sell to the honest customers. I don't think I need to worry about making sure they use the same license because they can't legally distribute derivations anyway.

My scripts are done. Back to work!

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.