[font=verdana,geneva,sans-serif]How would one go about developing such a system?[/font]
[font=verdana,geneva,sans-serif]I have an understanding of how to create a tile based map system using 2D arrays however how would a system such as the one in (off the top of my head) Snuggle Truck or Braid be created?[/font]
[font=verdana,geneva,sans-serif]More specifically how would the collision detection work with these non-rectangular shapes, since I am under the assumption that I should be able to load up an image into the game and someone get the player or an object to collide with it somehow.[/font]
[font=verdana, geneva, sans-serif]Thanks in advance. [/font][font=verdana, geneva, sans-serif][/font]
you could use a black/white collission image for example or in the case of suggletruck you might get away with only storing the height of each "column" (with the height at 0 or -1 for "gaps") then you can use the height to generate the actual displayed terrain.
You could also use polygons for the terrain (and store the level as a list of polygons)
[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!
Why not use the alpha of each image you put out on the screen as an alpha map? Alternatively, you could set up an alpha map as a separate black & white image or a circuit path on your image (a bunch of 2D triangle to test out.
As for avoiding tiles, Putting some images together of what you want to show, texture them on quads, putting the quad at Z = 0.0 with not rotation in ortographic projection (a 2D setting and that should work.
I prepare my 2D like this:
int Gui2D_Manager::Prepare2D()
{
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
There's some functions there, but I use a standard transformation 4x4 matrix to do the transformation but never apply transfo on Z. I blend the bitmap the standard way, and it work.
[font=verdana,geneva,sans-serif]More specifically how would the collision detection work with these non-rectangular shapes, since I am under the assumption that I should be able to load up an image into the game and someone get the player or an object to collide with it somehow.[/font]
I'm a complete newbie (warning), but I'm thinking that the collision detection is proximity based and the visual shapes are just superficial eye-candy.
Distance between the reference points of the objects Mario and Moomba < x, where x is the condition for dying or demorphing to mini-Mario.
Simply put, the two coords are basically just compared up against eachother, and it's up to the programmer to sync this up with Mario and Moomba's image sizes. If they're too close on the x and y axes combined, then you die or demorph.
That snuggle truck game looks like the curves are pretty straight other than the joints.
Like, there's curved ground but it has straight posts above it rotated at different angles. The tops of the mounds are fairly flat. In a html5 game I made I did really simple collision based on bounds of the object's image being drawn (x+width, y+ height), then could stack/rotate them however to make a terrain like that truck game at least. You could easily build a collision framework and draw a nice clean hill graphic on a layer above to make it look pretty. I imagine it would only be faster with a faster language than javascript.
You could use polygons like circles, ovals, rectangles, and triangles to as collision boundries.
Or, you can just use lines and splines to define boundaries that can't be crossed (though I personally don't know the math behind that).
[background=rgb(250, 251, 252)]More specifically how would the collision detection work with these non-rectangular shapes, since I am under the assumption that I should be able to load up an image into the game and someone get the player or an object to collide with it somehow.[/background]
[/quote]
How does collision detection work with non-cube 3D models in a complex world in a 3D game? They don't bother checking collision for every little triangle that makes up the 3D model, until such precious is needed. For 2D images, you don't bother checking per-pixel collision until you need such precision. You can check a generic axis-aligned rect first and only if it passes that rect, then you check per-pixel or per-triangle (if you need it).
Basically, you'd assign some geometric shape to objects in your game, and use a 2d physics engine to handle all the collisions. So, some objects might be a circle, line, rectangle, or other complex polygon.
In fact, the game I made was a non-tile 2D action game (see the link to my old Blog in my sig; it has all the source code as well).
[font=lucida sans unicode,lucida grande,sans-serif]Thanks everyone![/font]
How does collision detection work with non-cube 3D models in a complex world in a 3D game? They don't bother checking collision for every little triangle that makes up the 3D model, until such precious is needed. For 2D images, you don't bother checking per-pixel collision until you need such precision. You can check a generic axis-aligned rect first and only if it passes that rect, then you check per-pixel or per-triangle (if you need it).
That's understandable, I read something the other day about how some collision handling is used with the bisection method, until they really need per-pixel precision. Also the editor looks nice, I had been messing around with Tiled before thinking about this and (quite obviously) it was tile based.
Basically, you'd assign some geometric shape to objects in your game, and use a 2d physics engine to handle all the collisions. So, some objects might be a circle, line, rectangle, or other complex polygon.
That snuggle truck game looks like the curves are pretty straight other than the joints.
Like, there's curved ground but it has straight posts above it rotated at different angles. The tops of the mounds are fairly flat. In a html5 game I made I did really simple collision based on bounds of the object's image being drawn (x+width, y+ height), then could stack/rotate them however to make a terrain like that truck game at least. You could easily build a collision framework and draw a nice clean hill graphic on a layer above to make it look pretty. I imagine it would only be faster with a faster language than javascript.
So when you come down to it all the objects are just made up of bounding boxes (or spheres)? That makes sense.
I think I have a decent grasp on how I would achieve this, however on the subject of collision I have a rather silly question: which is how do I tell which side of the object my player has collided with. Even with tiles. What I am doing is checking to see if player.x is within the x boundaries of the object, and the same for y. However I am not too sure on how to tell whether my player is colliding from the top or the left for example, so I don't know which velocity, dx or dy, to stop.
So some pseudocode:
# With each object being a tile.
If player.x > object.left && player.x < object.right
&& player.y > object.top && player.y < object.bottom then
dx, dy = 0, 0
end
I do feel silly for asking this but I guess it's the beginners forum so here I gooooo!
So when you come down to it all the objects are just made up of bounding boxes (or spheres)? That makes sense.
I think I have a decent grasp on how I would achieve this, however on the subject of collision I have a rather silly question: which is how do I tell which side of the object my player has collided with. Even with tiles. What I am doing is checking to see if player.x is within the x boundaries of the object, and the same for y. However I am not too sure on how to tell whether my player is colliding from the top or the left for example, so I don't know which velocity, dx or dy, to stop.
So some pseudocode:
# With each object being a tile.
If player.x > object.left && player.x < object.right
&& player.y > object.top && player.y < object.bottom then
dx, dy = 0, 0
end
I do feel silly for asking this but I guess it's the beginners forum so here I gooooo!
Well, you certainly could detect the collisions yourself. My first few games I wrote my own collision detection algorithms. But, then I found out about 2d physics engines. I personally use chipmunk-physics, but Box2d is popular as well. 2d physics engines have made making games Sooo much easier for me.
The idea is, you define the physical properties of an object (shape, mass, friction, etc.) and then give it some force or velocity. You put these objects in a 2d "world" and then tell then engine to go every frame. So, all you have to do is assign the force or velocity to your objects, and the 2d engine handles the collision. You can set it up to get callbacks on collisions, or just to have them react as any physical object would (2 balls hit each other, they would bounce away like pool balls).
Again, my old blog (in my sig) details implementing a game using chipmunk-physics. Take a look if you are interested, but start at the initial posts.
[/font]
