Physics and clipping in a 2D shooter
Author
TLDR VERSION AT THE BOTTOM
Hey guys, I've been working on a Metroid-themed online shooter (2D Metroid that is), and I'm trying to find a good way to implement basic movement physics, and would like to hear from some of you about a beautiful thing called Clipping, and a good way to implement it.
Now, I'm working in C# (2008), meaning XNA.
Now, let me explain my object model:
Let's take a class, conveniently named PC (playing character). PC has, for physics purposes, a Speed(X,Y), Acceleration(X,Y), and Position(X,Y) property.
The player class itself shouldn't handle it's own physics, since it's just an abstract representation of the player, the World class should handle it, which also keeps all objects (consider them tiles on a map, but not restricted to grid-like movement), players (PC), bullets etc. in one place, so that they are easily accessible. The world class could have an "UpdatePhysics" or w/e method, or we could make a whole physics class, it doesn't really matter.
What I am asking you is, what would you do now to make this work? What would be the best way to implement movement, collision detection (incl. clipping) into the project?
I don't need code, I can make that. I need ideas, a sketch or anything that would lead me into making a semi-good or good physics model for my game.
You can add anything you want to my classes (like extra properties etc.) if you think it's necessary, but please keep it simple.
I hope i haven't caused too much of a confusion. If I have, just tell me, I'll gladly try to explain it better.
Thanks for all the replies!
TLDR: Gimme ideas to make a decent physics engine, and I'll work on it.
You might want to add rotational acceleration and velocity.
other than that, you can apply an acceleration to the objects as you want and using
v = u+at
and
s = ut + 1/2 a(t^2)
you can have basic physics-based movement. The lack of gravity should simplify your simulation....though you might want to add some inate drag factor in the world so that objects don't speed up indefinately.
Collision detection can be done however you wish. In 2d you could possibly even get per-pixel collisions working if you wanted. However if bounding circles and quads are sufficient (and usually they are) these are easier to implement. You could then either add properties to your classes to allow them to have bounding volumes, or create hte bounding volume as a seperate class (cBoundingCircle, cOOBoundingBox, cAABoundingBox), and inherit as appropriate.
other than that, you can apply an acceleration to the objects as you want and using
v = u+at
and
s = ut + 1/2 a(t^2)
you can have basic physics-based movement. The lack of gravity should simplify your simulation....though you might want to add some inate drag factor in the world so that objects don't speed up indefinately.
Collision detection can be done however you wish. In 2d you could possibly even get per-pixel collisions working if you wanted. However if bounding circles and quads are sufficient (and usually they are) these are easier to implement. You could then either add properties to your classes to allow them to have bounding volumes, or create hte bounding volume as a seperate class (cBoundingCircle, cOOBoundingBox, cAABoundingBox), and inherit as appropriate.
Author
Of course I have gravity, but that's easy (negative, or in my case positive Y acceleration).
It's a METROID-themed shooter, meaning it's like super mario with guns and 8-directional shooting, simulating a D-pad ^^
Anyhow, thanks for the help, I'll get to work and hopefully some of the GDnet community will help me test this once in beta,
peace out.
It's a METROID-themed shooter, meaning it's like super mario with guns and 8-directional shooting, simulating a D-pad ^^
Anyhow, thanks for the help, I'll get to work and hopefully some of the GDnet community will help me test this once in beta,
peace out.
broadly speaking, I would use composition to make my actors. Actors (your character, enemies, bulets, ...) would be composed of a physical object, used for collision, a render object for drawing, input object, to plug-in AI or player inputs, and probably composed of sub-actors.
Now, for the physics object, they would also be composed of a collision shape (box, circle, polygon, or a collection of those), and a rigid body (mass, inertia, position, orientation), special actuators (path following, gravity, force fields, ...).
Your objects would need some form of grouping, such as bullets (so you dont end up testing collisions between bullets), and you can filter out other group of objects for collision. In its simplest form, bitfields and bit masking.
to speed up collision detection (since what you can only test two objects at a time), is to organise your map using space partitioning, or if you like, some sort of spatial coherence, to reduce doing unnecessary tests. For 2D games, you have sweep and prune, either 1D or 2D, or split your game world into a regular 2D grid, each cell of the grid probably the size of a floor sprite, and recording the objects that cover the cell and put them into a list. Your collision shapes would have some sorting information recorded to quickly traverse the list of objects and test collisons against over nearby objects once every frame.
For pure collision detection and response in a horizontal shooter, I'd recommend you look at this.
Now, for the physics object, they would also be composed of a collision shape (box, circle, polygon, or a collection of those), and a rigid body (mass, inertia, position, orientation), special actuators (path following, gravity, force fields, ...).
Your objects would need some form of grouping, such as bullets (so you dont end up testing collisions between bullets), and you can filter out other group of objects for collision. In its simplest form, bitfields and bit masking.
to speed up collision detection (since what you can only test two objects at a time), is to organise your map using space partitioning, or if you like, some sort of spatial coherence, to reduce doing unnecessary tests. For 2D games, you have sweep and prune, either 1D or 2D, or split your game world into a regular 2D grid, each cell of the grid probably the size of a floor sprite, and recording the objects that cover the cell and put them into a list. Your collision shapes would have some sorting information recorded to quickly traverse the list of objects and test collisons against over nearby objects once every frame.
For pure collision detection and response in a horizontal shooter, I'd recommend you look at this.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
