Boundaries and Gravity

[Fred50]

Hey guys im developing a game and i cant seem to make out the boundaries for my guy and gravity. If you can help it would be really nice.

[Fool Running]

What do you mean? Gravity is just your guy wanting to go "down". Not sure what you mean about boundaries.

[Fred50]

What do you mean? Gravity is just your guy wanting to go "down". Not sure what you mean about boundaries.

Yes and boundaries as i dont want my guy to go off screen

[CodeBunny]

There isn't one way to do that - you can program any control/navigation system you want (though if you want to do it well it should make programmatic sense).

You've given us essentially no information. Could you maybe specify what your game is and what you need help with?

[Daslee]

It's really hard to make it. I have 106 lines of jumping with gravity and falling from cubes (Including collision detection while walking). First of all u must learn collision detection, then something about gravity, then try to do something with gravity, later create Cube class and adding cubes add it to ArrayList of Cube(s) then you could check on which cube you are by arraylist number. Then set ground as that cube on which you are. Check if player is jumping and y position is more than or equals to ground then set jumping as false, and set y velocity to 0. Im too lazy to explain here everything, but try to do it yourself when you learn something about gravity, and collision detection.

[CodeBunny]

@Daslee: that seems to be specific to your project - he may have entirely different requirements for control, which is why I asked for more info.

@Fred50: Simply put, things are not that simplistic. It's not just "gravity and boundaries" - we have to program the details of how everything functions, and the way these things work is part of the game as a whole. A top-down game will have different mechanics than a platformer, RTS, or RPG, for example.

If you want something robust enough for a game, you need to put together a simple "pseudo-physics" framework that allows you to abstract the collision logic. This really isn't that hard, but it requires a general understanding of what exactly you want to accomplish and how you want to go about doing that. I'll offer an example setup that should work for a simple 2D platformer; you could easily make a similar setup for a 3D project.

Okay, so you will have a two different components in this system:

Body: A simple "body" that represents a physical object (e.g., the player). It needs a collision identifier (most likely a bounding box), a location, and things like velocity, mass, acceleration.

Surface: A traversable section of the world. It also needs a collision identifier (either a bounding box or a line segment, either works well).

Maintain a list of all Bodies and all Surfaces. Now, each time you update the game, you do several things:

• Accelerate all Bodies in the direction of gravity (probably -Y) at the rate of gravitic acceleration.
• Compare all Bodies to all Surfaces that they collide with. For each body, build a list of the surfaces it is in contact with.
• Have each Body resolve its collisions (stop falling/slide/bounce/whatever) with the Surfaces in its list.

Now, we've got the basics of our "physics" system going. The nice thing about this is that we can easily extend it and add more functionality. For example, we could give Bodies and Surfaces friction. We could have surface normals on our Surface objects, allowing Bodies to slide downhill.

The most useful thing, however, is that we have an easy way to tie player input with the environment. Since we build a list of the Surfaces the player is standing on every frame, we can factor that into player controls. Example: the player can only jump if he is standing on a surface.

You see how this works? By making your setup more abstract and more of a "system," it's easier to do cool things with it.



NOTE: You mentioned that you wanted to stop the player from moving offscreen. This is not a collision issue, this is a camera issue. It's a different problem with a different solution, and is connected to your rendering more than anything else.

[Daslee]

@Daslee: that seems to be specific to your project - he may have entirely different requirements for control, which is why I asked for more info.

@Fred50: Simply put, things are not that simplistic. It's not just "gravity and boundaries" - we have to program the details of how everything functions, and the way these things work is part of the game as a whole. A top-down game will have different mechanics than a platformer, RTS, or RPG, for example.

If you want something robust enough for a game, you need to put together a simple "pseudo-physics" framework that allows you to abstract the collision logic. This really isn't that hard, but it requires a general understanding of what exactly you want to accomplish and how you want to go about doing that. I'll offer an example setup that should work for a simple 2D platformer; you could easily make a similar setup for a 3D project.

Okay, so you will have a two different components in this system:

Body: A simple "body" that represents a physical object (e.g., the player). It needs a collision identifier (most likely a bounding box), a location, and things like velocity, mass, acceleration.

Surface: A traversable section of the world. It also needs a collision identifier (either a bounding box or a line segment, either works well).

Maintain a list of all Bodies and all Surfaces. Now, each time you update the game, you do several things:

• Accelerate all Bodies in the direction of gravity (probably -Y) at the rate of gravitic acceleration.
• Compare all Bodies to all Surfaces that they collide with. For each body, build a list of the surfaces it is in contact with.
• Have each Body resolve its collisions (stop falling/slide/bounce/whatever) with the Surfaces in its list.

Now, we've got the basics of our "physics" system going. The nice thing about this is that we can easily extend it and add more functionality. For example, we could give Bodies and Surfaces friction. We could have surface normals on our Surface objects, allowing Bodies to slide downhill.

The most useful thing, however, is that we have an easy way to tie player input with the environment. Since we build a list of the Surfaces the player is standing on every frame, we can factor that into player controls. Example: the player can only jump if he is standing on a surface.

You see how this works? By making your setup more abstract and more of a "system," it's easier to do cool things with it.



NOTE: You mentioned that you wanted to stop the player from moving offscreen. This is not a collision issue, this is a camera issue. It's a different problem with a different solution, and is connected to your rendering more than anything else.

I think that you must do tutorials on youtube about all this things, because I see you know a lot about them. 

[CodeBunny]

I just recently started putting up dev videos (here's my first: http://www.youtube.com/watch?v=GI63eeaXbWs&feature=plcp), and I've considered doing some "tutorial" ones.

And thanks.

[matheus23]

I just recently started putting up dev videos (here's my first: http://www.youtube.com/watch?v=GI63eeaXbWs&feature=plcp), and I've considered doing some "tutorial" ones.

And thanks.

Oh... that is you? Didn't know that

[CodeBunny]

Yup.

[abcdef]

Code Bunny

I saw your video on YouTube and it looked great. You mentioned you did all the lighting in software rather than hardware, just wondering if you were going to post the method strategy you used to do that (as it sounded quite interesting)? (I also noticed you intend on making commercial games so don't worry if this is something you don't want divulge).

Thanks

abcdef

[CodeBunny]

I was actually planning on doing a video on how I do my 2D lights (focusing on the generalities; the general process I use is more important than the actual algorithm for the lights I've shown), I just haven't gotten around to it. Enough people people have asked me how I do my lights that I think it's a good idea.

[CodeBunny]

Well, I decided to put that tutorial together: http://youtu.be/0FZIKX1Y_8I