Orbyk - Point of contact

The development of Orbyk is underway. The visuals are fairly raw but I have gotten collision detection to work. Calculating point of contact for the rebound was another story.

It took several attempts to get it right and I am still tweaking it. I spent too much time figuring out complicated math that when it did work, it still didn't help me (but I still needed to do it to know that it would not work). I had one solution that worked well at very slow speeds. It turns out that the closer to the objects edge the detected collision was, the more accurate the calculation was. Once I realized that, after detecting a collision, I would slowly back the object up until it almost didn't register the collision and then did the calculation.

Some collisions that are exactly on the edge or corner could be calculated wrong. I have been too lazy to correct it at the moment ( When I make the main shape a sphere instead of a cube, it will have to change), So I added rebound validation. If I detect a rebound off of a side, I verify that another block is not resting up against that side. If a block does exist to that side, then the calculation was an edge case and was wrong.

I had it working beautifully until I added user input and decided that I was representing speed and direction in a poor way. In the process of correcting movement, I had to revisit my collision and rebound logic.

Orbyk

Orbyk was a PocketPC game that I wrote in college. It is like the game breakout, except upside down and in 3D. The view of the game is directly over the top of the game area so you see the ball bounce up towards you and then fall back down to the floor. The bricks are layed flat on the floor and are not stacked. The paddle was removed. To move the ball, you would use the stylus to give the ball spin in the direction that you wanted the ball to go. When it would move in the new direction when it hit the floor. So you had to think one bounce in advance.

The 3D part was simulated. The walls and bricks were designed to look like they have depth. The ball was rendered on the fly. It was like a 4 colored beach ball. The colors made the spin easy to see. We also shaded it to give it more depth.

The rendering was all done manually. We worked directly with the raw display memory. All of our images, tiles, and fonts were hand crafted in NxN arrays, one RRGGBB hex pixel at a time.

Redrawing the whole screen would tear. You could see the rip on the display if we cycled all the colors. To account for this, the only time we would redraw the whole display was at state changes ( menus, pause, or lost and gained focus). The ball was in constant motion. We rendered the ball directly over the existing seen and rubbed out only what was left of the ball from the seen before. We tried clearing the ball before drawing it again, but we could see it rip each frame. The ball rendering was optimized as much as possible.

It was a very addictive game and it quickly ran the battery out on my PocetPC every chance it got.