Physics Games and Physics-Based Game Downloads

(Rate this game! 103 votes, average: 2.41 out of 5)

Loading...

Sprinky is an attempt at creating a physics game where the player controls a spring like object. The game itself is quite playable, at least in the sense of a working prototype with multiple levels. The physics play mechanic, though, falls short of my expectations. The learning curve is too brutal, and the kinesthetic feel is distinctly clumsy. I’ll try to explain some of the design decisions involved in the making of Sprinky to shed some light on prototyping a physics mechanic.

Designing the Physics Rig

The inspiration for Sprinky was, quite obviously, to mimic the behavior of a real-life Slinky. My friend Steve Swink had actually created a Slinky-like contraption in Virtools, but I wanted to try another method for controlling its motion. The problem with designing physics-based control schemes is that it’s difficult to make the motion appear muscular in nature. It’s easy enough to apply external impulses or torques to objects, for things like jumps and turns. The resulting motion looks odd, though, as if driven by a puppeteer. I wanted to limit the object’s physical exertions to its own contractions and expansions.

Havok powers the physics engine in Virtools (well, more specifically the engine is Ipion, a company/engine Havok bought out years ago). To accomplish the sense of an internally-influenced physics rig, I used springs on the left and right sides of the sprinky.

(Sprinky Physics Rig)

Moving the mouse up and down extends and contracts the length, and moving the mouse left and right alters the ratio of lengths between the left and right side. The result is a realistic sense that the sprinky is applying force to the world around it, rather than having arbitrary external forces applied to it.

This first physics test is playable with the Virtools Web Player. The source CMO is available for any Virtools developers out there, too.

Adding Gameplay Elements

The next step was to add some flavor to the gameplay. I decided to go a very simplistic route in designing the rules for interacting with the environment. There are five types of object flags in the game: normal, ice, rubber (all variants on friction), and two types of game-over-if-touched flags (one for if any piece of the sprinky touches, and one for if any of the middle pieces of the sprinky touch).

The flat-poly prototype with the test levels is playable with the Virtools web player. The end result is a surprising amount of flexibility in designing courses. It’s possible to ramp up the game’s difficulty by using combinations of the two game-over flags. The actual difficulty in playing the courses arises from the failings of the core mechanic, though, so let’s talk about that.

Damned Hard

It’s obvious to anyone who’s played Sprinky for even a few minutes: The game is hard. And frustrating. While it is possible to complete all of the levels, sure, you have to be something of a masochist to actually enjoy the experience. It’s very hard to learn how to control the sprinky, partly due to some problems with the physics design.

Before we get into specifics, I do want to say that I think there is something to be said for the nebulous quality of how “well-tuned” a physics mechanic is. The quantifiable components that go into tuning a physics mechanic can be vague. Is a spring constant of 0.13 more or less enjoyable than 0.12? There is definitely an element of gestalt at work that can be difficult to componentize.

Mouse-Flip Problem

One design problem with Sprinky’s controls was how to handle the sprinky flipping over. If the player does a 180 flip, should left and right still correspond to the sprinky’s left and right, or should they correspond to the world’s orientation? This problem is nonexistent in games like Ski Stunt Simulator, since the avatar has an obvious top and a bottom.

One available solution was to color-code the sprinky or otherwise indicate which end should be up. It seemed counter to the goal of using a Slinky-like object in the first place, though. After all, one of the distinguishing features of a Slinky is its ability to walk end over end.

The solution I implemented was to flip the mouse X axis when the sprinky itself flips over. The crippling downside to this occurs when you lie near horizontal, though. The mouse cursor will constantly flip. It’s very hard to right yourself in the game when you fall over because of this.

(Sprinky Game Screenshots)

Unresponsive Movement

Generally, the sprinky feels unresponsive. This is due to a few factors. Primarily, the rig has a lot of jitter and bounce in it. Movement takes awhile to pass through all of the joints and springs, causing wave and jitter motion. It feels more like you’re guiding the sprinky than directly controlling its actions. As a result it’s very hard to get accurate movement and to really connect with its motion. The kinesthetic feel is completely missing because of the lag between moving the mouse and waiting for the rig to catch up and stop oscillating.

What to Change

This all begs the question: What would I change if I were to spend more time on Sprinky? This may sound odd, but the first thing I would do is completely scrap the current rig and rebuild it. In my experience it’s very difficult to massage numbers on a physics control setup that “feels” bad until it feels good. It’s much faster to rebuild everything. If I don’t manage to get that juicy physics-based feeling within the first day of development I’ll start over with a different approach. It’s just too easy to lose all objective reference as time goes on.

All Tarted Up

My friend Creath Carter created some fantastic artwork for Sprinky (he also did the artwork for Rolling Assault). The sexed-up version of the game was entered into the Independent Games Festival 2004. The art version of the game is available exclusively on Fun-Motion. Feel free to chime in with your thoughts on how to fix the control system, too. I’d love to hear people’s opinions on what exactly is so hard.

Download Free Sprinky Game (4.3 MB)