12 replies to this topic

[Firetaffer]

How would one go about developing such a system?

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?

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.

Thanks in advance.

[SimonForsman]

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)

Edited by SimonForsman, 28 April 2012 - 03:57 AM.

[KrimsomKing]

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();

gluOrtho2D(0.0f, GameWindow::Inst()->getScreenWidth(), GameWindow::Inst()->getScreenHeight(), 0.0f);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glTranslatef(0.375, 0.375, 0.0);

glDisable(GL_DEPTH_TEST);

glDisable(GL_LIGHTING);

return TRUE;
}

I put an image like this:

glPushMatrix();
applyTransfo();

srcImg->Bind();

glBlendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA );
glColor4f (1,1,1, alpha);

glBegin(GL_QUADS);
//Draw our four points, clockwise.
glTexCoord2f(0, 0); glVertex3f(0.0f, height, 0);
glTexCoord2f(1, 0); glVertex3f(width, height, 0);
glTexCoord2f(1, 1); glVertex3f(width, 0.0f, 0);
glTexCoord2f(0, 1); glVertex3f(0.0f, 0.0f, 0);
glEnd();

glColor4f (1,1,1, 1.0f);

glPopMatrix();

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.

[DrMadolite]

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.

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.

Boolean if:
If ((xMario + xMoomba) / 2 <= diRadius && (yMario + yMoomba) / 2 <= diRadius) {
// Die/Demorph else if code
} Else {
// No change
}

(diRadius is the estimated distance between the center of Mario and the center of Moomba.)

Edited by DrMadolite, 30 April 2012 - 08:12 AM.

[lmbarns]

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.

Attached Thumbnails

• 

Edited by lmbarns, 30 April 2012 - 10:31 AM.

[Servant of the Lord]

Check out GLEED2D.

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).

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.

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).

Edited by Servant of the Lord, 30 April 2012 - 03:34 PM.

[BeerNutts]

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).

[Firetaffer]

Thanks everyone!

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!

[BeerNutts]

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.

[Olof Hedman]

Also, if you for some reason do not want real physics, you can use the collision part stand-alone in many physics engines.

That is because physics simulation and collision detection is really two very different problems.

[Ravyne]

Firstly, the structure of the world and collision data are not inseparable -- they are related, but the data that defines them need not be one and the same. For example, you can have "primitive-based" collision (lines, curves(splines), and shapes) in a tile-based world, or you can have tile-based collision in a hand-drawn world.

All you need for collision is a method for determining whether something is "inside" of a shape, or "outside" of a shape. For lines and splines (planes and parametric surfaces in 3D), because there is no inside or outside, you simply choose one side to mean outside.

In rough order of complexity to calculate inside/outside:
Axis-aligned boxes and cubes
Circles and spheres
Lines and planes
Triangles (the trivial case of convex n-gons in 2D, because triangles are guaranteed to be convex)
Non-aligned boxes (again, boxes are known to be convex)
Convex n-gons in 2D
Axis-aligned ellipses and ellipsoids
Tetrahedrons (the trivial case of convex n-gons in 3D, because tetrahedrons are guaranteed to be convex)
Non-aligned cubes (again, cubes are known to be convex)
Convex n-gons in 3D
Non-aligned ellipses and ellipsoids
Curves and Surfaces (splines)
Concave n-gons in 2D and 3D

Edited by Ravyne, 01 May 2012 - 01:29 PM.

[Vincento0]

Hi all, I'm working on a platform game that doesn't use tiles - I use box2d for collision detection. The idea is to place boxes/spheres that will determine the world collisions, but the question is how to place artworks on top of it? How is it done in games such as Braid or Limbo ? I dont see any tiles repeating, it looks like the whole level is covered with a single image. I suspect using a single big image would be probably slow and memory consuming (the image would have to be like 10000x10000px). I cant think of any clever solution to this.

[Servant of the Lord]

This thread is 5 months old - typically you should start your own thread where you'd get more focused help. Posting here, most people wouldn't see the thread, and those that do see the thread would think to themselves: "Hey, 14 people already responded, so I don't need to help also" not realizing a new question was asked. Posting a new thread actually increases your chances of getting help.

Anyhow, in answer to your question:

Tiles are just placements of similar size images in a uniform grid. You could just as easily place images of any size freely without a grid, even rotating and scaling them.

First you'd draw a background, usually a single image, that since it's so far away doesn't need to be 10000 by 10000, just 1000 x 1000 or so. See parallax scrolling.
Second, your game would draw images on top of the background, wherever you tell the engine to draw them, not constrained by a grid, and of any size, scale, and rotation you specify.
Thirdly, your collision rects for the images would be calculated automatically from the position, size, scale, and rotation of the images where placed in the level.

See GLEED2D (a 2D level editor) and Parallax scrolling (for nicer backgrounds).

There is no reason you can't draw an image randomly where you please over the game window; people only make tile-based games for some of the nice conveniences tile-based grids bring, but that doesn't mean images have to be drawn in rows like that.