Side-scroller game for OUYA

[Paul]

Yes, you'd have to squash/stretch the aspect ratio of the image depending on its depth I guess.  If you're placing the background at arbitrary depths, I guess you squash the billboard on the fly.  If you're only using a few "layers" of background, then you could optimize the source images for the necessary aspect ratio.

Of course the alternative to this, while staying in the GL world, is to simply use an orthographic projection matrix and programmatically move the background billboards on "conveyor belts" as you scroll.  I assume that's the default approach for a side-scroller implemented in GL?

The easy way to think of orthographic is that the size of the object on the screen is independent of its z-coordinate.  Like a detailed engineering drawing, where you want an undistorted representation of dimensions.  With perspective, the size on screen is inversely proportional to its z-coordinate, technically speaking.

I feel like that would further complicate the "tree floating over the pits" issue (assuming the background conveyer belts moved at a slower velocity than the forground)., and would require manually handling two factors (scaling and velocity) versus a single factor (y offset).  My thought is to just let the 3D engine handle most of the work.  I actually don't have to do a whole lot of math, because jPCT has interface methods to make this easier.  The process would work like this:

1) Calculate the two furthest corners of the sloping "ground polygon":

Code: [Select]

Interact2D.reproject2D3DWS( myCamera, myFrameBuffer, 0, groundY, leftCornerPoint );
Interact2D.reproject2D3DWS( myCamera, myFrameBuffer, screenWidth-1, groundY, rightCornerPoint );
2) Create the ground polygon using the camera position as the third corner:

Code: [Select]

groundPolygon = new Object3D( 1 );
groundPolygon.addTriangle( myCamera.getPosition(), .5f, 1, rightCornerPoint, 1, 0, leftCornerPoint, 0, 1 );
This would only need to be calculated once (simply move the ground polygon with the camera - only one of them is needed).  It could even be calculated ahead of time and the values hard-coded.  Then when an object is about to enter the view, adjust its y position:

1) Calculate the y-offset of the ground:

Code: [Select]

float groundDistance = myWorld.calcMinDistance( myObject.getTransformedCenter(), new SimpleVector( 0, -1, 0 ), 100000 );
2) Translate the object:

Code: [Select]

if( groundDistance >  0 && groundDistance < 100000 )
    myObject.translate( 0, -groundDistance, 0 );EDIT: Of course you'd need to take the object's height into account for the translation, but you get the idea

[littleguy]

Sounds like you have it figured out.  I forgot you were using a higher-level rendering api, I was just thinking low-level nuts and bolts....

[Paul]

Actually, I thought of another potential concern with this setup.  Because the 2D panel is at a distance from the camera, it could end up experiencing some scaling or tile-edge alignment problems.  A better way to do this would be to draw the 2D foreground elements as an overlay on top of the 3D scene (and use the "conveyor belt" scrolling that littleguy described).  This will of course require a couple more calls to reproject2D3DWS to calculate a scaling factor for the grid to match the depth where the 3D characters are located (for hit detection purposes).  This again would only need to be calculated one time (like the sloping ground polygon), and the value could also be calculated ahead of time and hard-coded.

[Paul]

I had a thought about a solution for the "trees floating over the pits" problem.  Instead of requiring the person designing the map to worry about the problem, have the engine calculate the x-position for midground objects based on their distance.  Then the person designing the map only has to think in terms of the 2D grid.  For example, a (really tiny) map file might look something like this:

Code: [Select]

[Details]
#  1) Spaces are ignored
#  2) Multiple objects may be placed on each square

#  LEGEND:
#  B = Brick
#  T#,# = Tree [z-depth (0 -> 1.0)] [, x-offset (-1.0 -> 1.0)]
#  ; = End Square

[Foreground]
          ;         B;         B;          ;          ;          ;          ;          ;
          ;          ;          ;          ;          ;         B;         B;         B;
          ;          ;          ;          ;          ;          ;          ;          ;
          ;          ;          ;          ;          ;          ;          ;          ;
          ;          ;          ;          ;          ;          ;          ;          ;
         B;         B;         B;          ;          ;         B;         B;         B;

[Midground]
          ;          ;          ;          ;          ;          ;          ;          ;
          ;          ;          ;          ;          ;          ;          ;          ;
          ;          ;          ;          ;          ;          ;          ;          ;
          ;          ;          ;          ;          ;          ;          ;          ;
          ;          ;          ;          ;          ;          ;          ;          ;
          ; T.5,-.5 T;      T.25;          ;          ;         T;          ;   T.2,.75;
Even with the added complexity I put in there for allowing x-offset and stacked objects, the map designer can still very easily see where the pit is located (columns 4 and 5), and avoid placing any trees over it.  This would be even easier with a map-maker GUI like I have planned at some point.

EDIT: For anyone having trouble visualizing how this would look in practice, here is a rough example of how the above map file would appear in-game:

[Vincentmrl]

Hey Paul, what about making some levels with 3d backgrounds and rotating levels (something like what klonoa does), It doesn't necessarily take that much of processor, it could be simple textures etc. The rotating 2.5D levels are just perfect for games with a story. Maybe something like carts going on the z axis to other sections of the levels. These scenes could be used in zones like this

[Paul]

I don't really want to do that because it would add complexity (would require two different map-control engines, and two different map definition syntaxes).  Processor requirements are only one factor - the other factor is time (how long it will take to develop).  Thinking of maps in 2D is much simpler all around (smaller map files, less rendering and camera logic, less math, simpler hit detection, etc)

[Paul]

I don't really want to rule anything out at this early stage, though.  It might make sense to have a second perspective for the game once I start getting into it (what comes to mind is the overhead view in NSMB when going from level to level, or the FPS rooms in Jurassic Park).  I'll start with the first engine and see where things go.

[Paul]

I had a thought about a solution for the "trees floating over the pits" problem.  Instead of requiring the person designing the map to worry about the problem, have the engine calculate the x-position for midground objects based on their distance.

Actually, this won't work -- I was thinking in terms of a single screen where the camera is not moving, but for a moving camera, the background grid shifts right compared to the foreground grid as the camera moves.  Consider this for example (overhead view, camera at the bottom):



At this point, the tree is in grid 5 and not floating over the pit.

Then if we move a little to the right:



Now the foreground grid has move 3 squares, while the background grid has moved only one square.  This results in the tree being directly over the pit when viewed from this perspective.

So, there are a couple of ways around this.  The first would be to simply design the maps so there are no background objects on squares that are close to pits (it might not even be possible, considering how much slower the backgrond moves in comparison to the foreground).  Probably a better solution would be to change the sky panel, so that it has a ground texture from ground-level down.  So instead of this:



You would have something like this:

[Tom.K]

Probably a better solution would be to change the sky panel, so that it has a ground texture from ground-level down.

Just to make sure: That would work like with 2 background layers (ground and air) or you will merge both textures into one (which isn't a good idea in general)?

[Paul]

It would be more versatile (for mixing and matching, swapping, etc) to have two separate panels for the background.  To avoid edge alignment problems, the ground panel would need to overlap the sky panel a bit.  Of course that could lead to z-fighting, so the sky would have to be a tiny bit further away than the ground (but close enough that they don't look like two separate panels.)  It'll probably take some trial and error to get it right.

[Paul]

Another way would be to use foreground tiles to create the "ground" (basically certain tiles would be solid, and others would not).  This would cause it to move at the same rate as the foreground, so I'd have to try both ways to see what looks better.

[Paul]

A third alternative would be to make the midground (where all the objects are located) a raised platform.  The side of the platform would be textured with the ground image, and since all the objects are sitting on top of the platform, they would never look like they are floating in mid-air.

Actually I kind of like this idea.  It would allow the camera to actually be moveable if I wanted to do some kind of zooming out of 3D for certain areas like Vincentmrl was talking about.  For those areas, you'd just put a texture onto the top of the ground plane, make the sky the inside of a cube instead of a panel, and turn the foreground blocks into cubes instead of flat squares, allowing full camera motion.  I wouldn't use this everywhere, but would certainly be nice to have the option if I wanted to use it in a couple places for dramatic effect or something.

[Paul]

Hmm..  Expanding on this even further -- if there were always a textured ground panel, then there would no longer be any need to make the ground slope downward to avoid further away objects seeming to float off the ground.  They would simply approach the vanishing point as normal 3D, and would actually make the whole scene look a lot more realistic without adding too much complexity (just a couple extra polygons and another texture).

For anyone having trouble visualizing, the world would be basically set up like this:

[littleguy]

Yeah, I was thinking the same, just putting midground objects on their own ground or make them extend all the way to the bottom of the screen.  This could be done entirely in billboards as well, like classic side scrollers.  Or 3d midgrounds as you mention.

   

[Paul]

Yep, this one is exactly what I am thinking.  The midground is a raised platform with texturing on the side, and the top of the ground is textured, with all the midground objects billboarded.  Guess I should have studied how it was done in other games rather than trying to reinvent the wheel, haha!