Iconfactory Contact/Feedback for: Software

Denis Tretyakov's Avatar

Denis Tretyakov

24 Feb, 2012 01:00 PM

Hello  ,
    I'm a fan of your game Ramp Champ. That's so cool))
    So let me say a few words about me, I am an iOS-developer, and now work on a game project that uses a similar model of throwing objects.
    I usually make 2D-games, so I'm faced with the problem of how to implement the same behavior of the object ball as in your game (rendering, physics and collisions, the definition of collision with other objects)?
        Can you help me with this issue?

Thanks in advance,
Denis Tretyakov

  1. Support Staff 1 Posted by Sean on 24 Feb, 2012 04:05 PM

    Sean's Avatar

    Hi Denis,

    At it's heart, Ramp Champ is a 2D game. All the sprites, etc. are just normal 2D images. What we did, though, was use a 3D physics engine (Bullet - http://bulletphysics.org/) behind the scenes to simulate some of the game world. Basically I configured the 3D engine with a handful of simple shapes to represent things like the ramp, the sides, the ball, and the targets. Everything was just made of boxes as far as the physics engine was concerned except for the ball which was a sphere. Keep in mind that all of this is behind the scenes - we never rendered any actual 3D shapes, but the physics engine didn't know or care about that.

    When the lanes themselves were designed, the designers had to come up with positions and sizes for the targets and stuff in 3D space even though it only drew 2D sprites. The 3D positions were stored in the game and used to setup the physics engine when the lane was played. We had a simple editor that showed the lane from the front as it is seen in the game while also showing a kind of line-drawing side view that showed depth so the designers could visualize where they were positioning the various targets in 3D. This made things a lot easier for them but was a lot of work to put together.

    When the player flicked to throw the ball, a force was applied to the sphere in the physics engine and then the physics engine mostly did the rest. As far as the physics engine was concerned, the ball was rolling down the ramp and hitting the boxes that made up the targets. The physics engine knows when objects hit each other and has notifications of that. The boxes in the 3D world were tagged so I could tell which target they were, so when the ball hit something and I got a notification of a collision, the game could then handle it accordingly and remove the box from the 3D physics world, score points, or whatever.

    As the physics engine ran each game tick, I'd read out the 3D position of the ball and targets and such from the point of view of the physics engine and then used a perspective matrix to do the math of converting that 3D point to a 2D screen point and then just moved the sprite on screen to the right spot according to where the physics engine told me it was. (This is basically what 3D engines do when it comes time to render a 3D shape on your 2D screen.) Since all the targets just moved left/right and our "camera" was positioned so that it was looking directly at the targets, we were able to get away with this without worrying around rendering any actual depth for the targets since they never moved in a way that'd visually require it. The ball was slightly trickier because it moved into the screen and thus needed to shrink as it went deeper into the screen. I think what I ended up doing was to just convert two 3D coordinates into 2D for the ball - one for the left side of it and one for the right. Then I used the difference between them to scale the ball sprite accordingly. That resulted in a surprisingly decent 3D effect since the ball image was a circle and was moving quickly.

    The only other trick left was getting the ball to go behind things when it should, but that ended up not being very hard. We just sorted all of the targets and lane parts (like the sides, the ramp floor, etc) according to their z-position in 3D space. As the ball moved it's z-ordering was set to match it's depth into the screen and so as the ball's z ordering increased it'd be rendered behind other sprites that were to be considered closer to the viewer without doing anything fancy.

    I hope this makes some kind of sense to you and helps you out. Good luck!

  2. Sean closed this discussion on 24 Feb, 2012 04:05 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac