Teeter - small game with neat interaction and physics puzzle

[melax]

Hiyo, I wrote a little game. It can be found at:
http://www.melax.com/teeter.html

Given the objective of the game, I thought the bullet forum was the best place to mention it. Hopefully the crowd here likes it and is able to solve the main puzzle.

I have already had a handful of people successfully test the game so hopefully everything works smoothly for you.

Any feedback is appreciated.

[Erwin Coumans]

Genius

If you could mix the challenging gameplay of the 2D Super Mario Bros platformers with this (with predictable/repeatable animated sequences) that would be very nice. Perhaps exploit the 'moving' csg cylinder platform a bit further. Also it is too easy to just blow away all, there is no penalty/risk/challenge with that

Can you tell a bit about how you do the movement for the character controller? Does it use discrete distance/penetration checks, or does it perform a sweep/time of impact?

Also, did you make any interesting improvements in your GJK implementation? Can you share any of those optimizations you mentioned earlier in this Molly Rocket forum thread?

Thanks,
Erwin

[melax]

Hi Erwin, Thanks for trying it out.

For the character controller I'm using a rather old-school system. The gameplay is just first person so I can get away with it. It is continuous in that it projects a path to determine if there are any collisions and then adjusts the path (project onto collision plane) as necessary. When you're in "jello world" it's similar except that it uses a smaller sphere sweep test against the polygons in the vicinity. Ideally I would like to have a more unified solution for all things in motion.

My physics code isn't exactly the magic bullet of physics engines I didn't want to invest too much time recreating something that you (and the other physics engine authors out there) have already perfected. I just created enough to give me the basics and in a way that I could experiment easily.

The rigid bodies (gems and bricks) use discrete distance checks. I used the easy approach of just finding and adding at most 1 body-body contact per timestep. So if things are moving fast enough then the contacts are lost as fast as they are added. The gems use a position constraint type of grab with a maximum force just enough to keep the gem where you are holding it as you turn and move about. The bricks use a spring grab. For ccd I just use a small sphere sweep against the environment after the impulse solver phase. You might have noticed that if you carry a gem and move along a wall, such that the grab point is behind the wall, then the gem wont slip through, but it might jiggle instead of sliding smoothly along.

For calculating the weight on the balance I actually use the value of the impulse on the joint holding up the apparatus. If you directly grab the teeter balance and apply force to it and look at the scale on the wall you can see how it changes the "weight".

For non jointed objects, the physics update conserves angular momentum. Its a no-brainer, but you have to use runge kutta to update the orientation. If you turn of gravity and watch a long rectangular box spinning then you can see the difference compared to constant spin.

For GJK, instead of hillclimbing, I took your advice and just iterate over all vertices to find support points.

In addition to rigid body dynamics there are other systems at play...
The jello thing uses a voxel based approach. The other digging uses a bsp merging approach. When the game starts up it merges all the hallways, rooms, and ramps together. The moving csg still uses bsps but just for quick clipping instead of commiting the result back into the hierarchy. So potentially you could have lots of moving holes in a scene. Any of these systems would be a good candidate for parallel processing.

I'd like to focus more on the fun tech and the specific implementation/optimization details but then there's all that other stuff a project needs such as rendering, windows hassles, sound, recording guitar riffs, art creation, fixing textures, making heightmaps, game design etc..

[Erin Catto]

This is a cool little game. It's impressive that you have a complete system with graphics, sound, physics, geo-mod, etc.

We had a balancing puzzle in TR too. I love these sorts of physics puzzles in games. With some commercial physics engines these puzzles would be difficult because they don't provide access to the reaction forces.

If I was going add one more feature it would be collision sounds. They add so much to the physics.

Do you use a single dynamic BSP for collision? Is it a triangle soup or a collection of convex volumes?

Please make more games!

[melax]

My pleasure Erin I'm glad you enjoyed the game. And thank you (and Erwin) for all you've contributed to the community.

There may be reasons, other than API limitations, why you cant get impulse values out of a particular physics engine. Consider that physics engines have to compete with one another in the "benchmark races" such as the classic stacking of boxes. A physics engine might be doing optimization tricks, such as putting individual rigidbodies to sleep, that would give correct looking behavior but would not necessarily be computing correct values at all points. In such cases the impulses at the bottom of a stack wouldn't equal the weight of everything above it.


The environment does have a single bsp so yes there is a collection of convex volumes (leaf nodes). Actually the room where you can blow holes in the floors/walls is a 2nd separate bsp that allows for boolean operations meanwhile the main bsp disables them. Otherwise the player could literally dig tunnels anywhere. The moving hole also has a bsp so that I can efficiently clip the room's polygons and conversly use the room's bsp to clip the moving hole's polygons. Even though the moving hole and the holes used to dig with are convex in this demo they actually dont have to be.


I only really need the bsp structures for efficient geomod. If I had an artist creating art, I would get support for polygon soup, but obviously you couldn't tunnel through such non-manifold areas.

Thanks for the note about collision sound effects. Yea I believe that would really make a noticable difference.