I'm working on a very basic platform engine. This is my first attempt so please excuse me for sloppy programming pratice and such I've got a working platform engine. A player that moves and a "world" loaded from a file.

My problem is that the movement and physics isn't that good and i really don't like how it looks.I'd like to know what to do with the code to get a smooth movement and physics that works properly! I've implemented collision detecion, which I think works okay but if someone thinks diffrently please explain what I should do to make it better.

It seems like the choppiness is more because of the way you're performing the movement than because of the way you're drawing.

A 32x32 character jumping 50 pixels upwards instantly? This will make it look choppy because motion is not instant. Typically, a jump will follow some sort of parabolic arch which follows a height = velocity + time * acceleration formula. This makes it so that as time passes the jump will go from quickly going upwards, to slowing, before peaking out and starting to fall.

If you want to make it so that the jumper will go a maximum of 50 pixels upwards in say 5 time steps you just do:

Okay! Yeah that sounds pretty logic.. do you think I should change the code for the left and right movement aswell?I'm not completly sure how to implement the velocity for the movement so if you could point me in the direction (I know that you already given my a hint)

1) Make all your ints float, and then cast them to int when you need to do drawing and such. This will make things much smoother.2) Rethink your logic to be more like real physics. In other words, as a person in the real world your downward velocity is not just "gravity." It could be ana accumulation of any number of forces. Each movable object in the world has 3 components:• Position• Velocity• Acceleration(s) applied to velocityIn the real world, there is no way for your position to just magically change. Your position only changes when your velocity is nonzero, and its your velocity that changes your position. Similarly, there is no way for your velocity to instantly change. It can only be changed by accelerations. You can however cause all sorts of accelerations. When you jump, your legs are applying a single large acceleration upwards. Meanwhile gravity is constantly applying a downward acceleration to you, so eventually it overcomes that single up acceleration and you come back down.

That should get you started. Then when you press left you apply a negative X acceleration, right you apply a positive, etc. When you jump you apply a positive Y acceleration. Pretty easy. The big thing is that in most platformers you want the ground friction amount to be very high (that means a very low value in that GROUND_FRICTION coefficient) as sliding can be really annoying. But you notice if you play Mario he actually has momentum, which is what you get without too much friction.

While it is correct for all intents and purposes, due to the fact that most graphical positional systems do not follow the Cartesian Coordinate system, you have to make a decision between using the same system as your graphics do or writing some form of translation between the two. Typically, people go with changing their system instead of having the translation.

Graphical representation

0

1

2

3

0

1

2

3

Cartesian (Described above)

0

1

2

3

3

2

1

0

Basically, you either have to use a inversed accelerations and a Y-Position system where small values appear higher up, or you'll need to write a translation system for your game that will convert the Cartesian to the Graphical (Typically by having something like screenPosY = screen.height - object.position, every time you want to draw something). Where as, just writing your game's physics from the other view point feels more much intuitive (At least for people like me.)

While it is correct for all intents and purposes, due to the fact that most graphical positional systems do not follow the Cartesian Coordinate system, you have to make a decision between using the same system as your graphics do or writing some form of translation between the two. Typically, people go with changing their system instead of having the translation.

Graphical representation

0

1

2

3

0

1

2

3

Cartesian (Described above)

0

1

2

3

3

2

1

0

Basically, you either have to use a inversed accelerations and a Y-Position system where small values appear higher up, or you'll need to write a translation system for your game that will convert the Cartesian to the Graphical (Typically by having something like screenPosY = screen.height - object.position, every time you want to draw something). Where as, just writing your game's physics from the other view point feels more much intuitive (At least for people like me.)

Yes good point. I neglected to mention this. If you're using Java2D you are probably using the graphical representation, which means reversing gravity to cause a positive Y (because up is down, as UprightPath said).

Even things like Slick2D use this system (Which, since it's meant to be sort of analogous to Java2D is understandable).

Another thing to note, about his example is the idea of the 'Delta', which appears in the World.update(float delta) class. If I'm correct (And I'm not sure, heh) this delta refers to the amount of time since the last update was called. In some cases, this will always be the same or close enough not to matter (Especially if you have something managing your update rate), in other cases this will vary enough that your objects might seem to move in a more "jerky" method, as you'd described earlier. This really only happens when you go from having very small deltas to suddenly having a very large one.

I included the delta because he mentioned he's using variable timestep.

Delta is usually how many seconds the last update took. That way you can express everything in terms of meters or pixels per second, and if you multiply times delta that's what you get. If you're using fixed timestep, you don't have a delta. I've also just made a delta of 1.0 mean it was the target update time (like if I want it to run at 60fps and the last frame took 1/60th of a second). Either way works as long as you're consistent.

Hey again! I was able to implement the physics and it workes fine!But what would progaming be whiteout some problem! As I said the movement is perfect but now my collision detecion get screwed up by using this new vector class that you wrote for me.

You'd put a check where the comment "//change position by velocity" is in the prior code. Otherwise you're moving the character twice (I'm assuming that you're checking after you've run the update code, which means you're adding velocity.x/y twice, and the second time without applying the delta.)

You'd put a check where the comment "//change position by velocity" is in the prior code. Otherwise you're moving the character twice (I'm assuming that you're checking after you've run the update code, which means you're adding velocity.x/y twice, and the second time without applying the delta.)

Well this is how I've done it this far:

in my frame class I've the detection of collision... (It has to be here due to the way I draw my world.)

1 2 3 4 5 6 7 8 9 10 11 12 13 14

privatebooleancheckCollision () {

for (intn = 0; n < map.getBlocks().size();n++) {

if (player.getBounds().intersects(map.getBlocks().get(n).getBounds())) {

With this code I've managed to get it to stop when it hits a block from above due to the gravity... but when I hit a block I get stuck and can't move. What should happen to the gravity and the two booleans (collision,isOnGround) when the object hit a block?

You'd check for these in the direction you're moving. So, if your velocity.y is of the same sign as your gravity, then you're obviously falling down, and only have to check up. If your velocity is the opposite sign of gravity, then you check up.

This takes a bit of math, really. And a bit more information. But, if you can write something that figures out which is closer, the X or the Y collision you might~

Hmm, the way that my world is implemented is on the first post.You mean that I should check this every time I move? I'll will have to think about how I should implement this collision testing but if you could help me I would be very glad TIA!

Actually, looking now, what I said was somewhat wrong. Collision Left/Right should not affect the isFalling flag. Only a downward collision should if you're using simple collision physics.

I'll have to think about the collision system, because the only system I've really done using it is using another method than the rectangle1.intersets(rectangle2). However, if you get a collision, you can probably figure out which edge the collision would have occurred on.

Say, you have...

Player and Block. Player has a velocity vector. Player and Block have a distance vector (distance.x = player.x - block.x, distance.y = player.y - block.y). From that distance vector, we can figure out which corners are important in figuring out the collision. Top left, top right, bottom left, bottom right. From there, you just follow the the player's velocity vector, plotted from the important corner, to see whether it bumps into the vertically or horizontally.

Sorry, I can't provide a better explanation of it, I can see it in my head, but this math is beyond me this morning.

For collision detection I typically just do a raycast in the direction of my velocity and if I hit anything then I clamp the position change to only be as far as the distance to the item the raycast hits. If it doesn't hit anything, move the position the full velocity distance.

Yeah, this is where it goes from merely writing the physics engine to actually deciding how you want your physics engine to work.

For Raycasting, I'm not completely sure how well that will work. I'm only passingly knowledgeable about the subject, but it seems to me that using such a method can result in missed collisions if the objects in question are greatly different in size (Such as player being much larger than the object). Like, allowing a player to pass through a bar because it's not in the raycast path.

If you can figure out where the closest collision occurs, you can figure out which of the velocities need to be changed and stuff like that.

I just looked back at your code, which I must admit I didn't do initially, it seems as though it'd be difficult to figure out collision direction, because it will always find the first object that you'd collide with from the TOP-LEFT side of the screen. Instead of finding the closest object in the direction of your velocity. This means that if you're moving fast enough that you might land on several objects (velocity.X > 20, or velocity.y > 25), you'll always get the one that's further from you if you're moving left, up or up-and-left, which will make figuring out where the closest collision is happening difficult.

For Raycasting, I'm not completely sure how well that will work. I'm only passingly knowledgeable about the subject, but it seems to me that using such a method can result in missed collisions if the objects in question are greatly different in size (Such as player being much larger than the object). Like, allowing a player to pass through a bar because it's not in the raycast path.

If that's happening to you then your raycast is not written correctly, or you have very funkily shaped collision areas.

I've done my mentioned approach loads of time and it works great. Granted I usually use circle colliders so that makes it easy, but still.

Okey guys! I feel a little lost now! You talking about some funky raycasting and stuff Of what I understood from your replays was that it was difficult to calculate the collisions and when to stop which velocity due to my world implementation? Have I understood you right?

What I want is a simple platformer with the basic movement and physics

In the Platformer I'm working on right now, instead of using a List<Block> style thing, I'm using a Block[][]. This means that I can customize my iterator so that I can control the direction of consideration. This allows me to find the point of first collision rather easily. From there, I can figure out where the collisions will occur.

The simplest way to raycast would just be to iterate over each pixel looking for collisions each time. Here is a more correct way to do it. As I see it that's the best way to do collision - because it's not discrete (therefore you can't be moving so fast you pass over things).

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org