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)

(Rate this game! 100 votes, average: 3.28 out of 5)

Loading...

Rolling Assault represents the evolution of a simple physics prototype I created a few years ago. This prototype had some merit so an artistic friend, Creath Carter, took it upon himself to create some content to the replace the lifeless polygons. We fleshed out the game a bit more in order to enter it into the IGF that year. This is the result:

Humble Beginnings

Over the summer of 2003 I spent a lot of time creating physics-based gameplay experiments. I used Virtools, our middleware of choice, and even posted all of the source code for the benefit of the Virtools developer community. The now-hibernating site was called DevLab–it’s still online, although it hasn’t been updated in awhile.

Anyway, one of the tests I created attempted to simulate the motion of a tank tread. Here is the resulting prototype, which took a few hours to create:

(Rolling Assault Physics Prototype 1)

The game is playable through the Virtools’ plug-in. Use the left and right arrows for control.

This was generally the scope of the prototypes I was creating at the time. The controls are there, along a first pass at balancing the motion so it “feels” pretty good. A goal structure is clearly absent, though, along with such pleasantries as a reset key (right-click and do reset through the Virtools web player if you need to).

Life’s First Creath

As bare as it was, the treads test was fun to screw around with. Creath Carter, a friend from my school days, thought the mechanic had enough potential to bestow upon it some sexy artwork. I had worked with Creath in the past and he knew his way around Virtools. It was a welcome turn of events and saved the project from being completed shelved along with the rest of the physics game experiments.

A mere six days after this first prototype, this version was posted to DevLab:

(Rolling Assault Physics Prototype 2)

Here is the playable Virtools link. Use A/D for left/right controls and mouse movement/click for turret control.

In addition to the new artwork, this version took a second pass at tuning the physics. The addition of the turret also added the ability for the player to right themselves when they get flipped over. On the whole, this new version seemed like a lot of fun to play. Even though there were no enemies to blast, yet, it was easy to imagine what it would be like to play an actual game from this point.

The IGF Version

In August–a month after the first version was created–we decided to put together a playable level of the game and submit it to the Independent Games Festival. The game wasn’t selected as a finalist, but the IGF did serve as a very useful deadline. The contest rules require that your game be roughly in “beta” form with one playable level of content. I had about 5 days that I could spend on the game, in between other projects, but it felt like a feasible goal. I had a lot of energy back then.

We came awfully close to achieving our goal. The final version of the prototype has four enemies, a longer level, music, some sound effects, and slightly-refined controls. There were a few pieces of content that didn’t make it in, unfortunately, including a sweet multi-stage end boss.

(Rolling Assault Game Screenshots)

It’s Judgment Play

One the big issues with physics-based game design is the issue of inertia. Naturally, any Newtonian physics engine that mimics reality will have such things as inertia, the conservation of angular momentum, and so on. But are those things necessarily conducive to a fun, responsive play experience? Not really. More often than not the limitations of reality actually get in the way.

Rolling Assault suffers in this regard. The control seemed fine in the early prototypes. It was satisfying to roll around; the wheels’ motion was aesthetically pleasing. However, as soon as we introduced very specific movement goals–dodge this missile, jump over this barrier–the sluggishness in the tank’s motion becomes apparent. The tank simply isn’t nimble enough to perform directed tasks without some degree of player frustration.

Solutions to Sluggishness

There are two obvious solutions to this problem. One is simply to remove high-fidelity movement requirements from the game’s design. This could be accomplished by putting more emphasis on accurate aiming and the game’s overall weaponry. The tank’s motion would change from a focal point to an abstracted means of scrolling the level forward. The player’s attention would instead be drawn to predictive aiming and observing enemy movement rather than the exact position of the tank. This would require completely rethinking enemy design.

Another solution is to tune the tank’s physics setup to be more responsive. One way to accomplish this is to exaggerate directional changes. For instance, if the tank is moving right and the player wants to go left, the game would provide additional impulses to overcome inertia. As soon as the tank is moving left properly, though, it would scale back the leftward impulses. This sort of anti-inertia logic is actually present in Amoeball and did help make the game feel more responsive. The complexity of the tank would require some additional tweaking–do you boost the torque of the wheels (which are already pretty slippery to begin with, since they are perfect spheres with infinitesimally small contact points)? Or do you fake it with impulses? Add torque on the main body so the player can arbitrarily control rotation mid-air? It would be an interesting design exercise, to say the least.

Play It! It’s Free!

All told, I’m pleased with how Rolling Assault came out. The game is well under a man-month of combined effort, and reasonably entertaining for how little time has been invested in it.

The one-level prototype of Rolling Assault is available exclusively at Fun-Motion. It’s a wee download, weighing in at 5 MB, and completely free. If you’ve read this far definitely check the game out. My rambling words can only do so much good without hands-on experience.

Download Rolling Assault physics game here (5 MB).
(there is no quit key, just alt-F4 when you’re done playing)

(Rate this game! 89 votes, average: 3.16 out of 5)

Loading...

I Hate Clowns is a fun little game we developed in the Fall of 2003. It was the run-up to the Independent Games Festival deadline. Along with Beesly’s Buzzwords, we decided to submit whatever projects we had playable at the time. I Hate Clowns was created in the spare time of a very busy three days. The game is a little rough, as a result–the artistic production borderlines on placeholder. The fun is all there, though, so we decided to post it online for the world to enjoy.

Die Clowns, Die

The premise of I Hate Clowns is simple: You throw metal pies at clowns who are being inexplicably launched into the air like skeet shoot targets. You have a limited number of metal pies with which to brutalize these poor entertainers. Take it, clowns!

I Hate Clowns is a physics game in a very pure sense. Except for the scoring, the rest of the game mechanics rest on the physics engine: the ragdoll clowns, the metal pies, the physical dimensions of the playfield, etc. If we ever revisit the project it would be easy to extend the gameplay by designing more complicated playfields with various physics contraptions.

Scoring

Hitting an airborne clown, before he touches the ground, is worth 10 points. Each subsequent pie that smashes that clown before he meets the earth is worth an air combo of 2 points. All hits after that are ground hits and worth 1 point. It is possible for one pie to bounce between multiple targets and rack up multiple points.

Level Progression

Despite the simplistic scoring mechanic, there is some flexibility to changing the player experience. In the early levels most players learn to fire as many pies as possible as fast as possible. This usually results in the wailing akin to the moans of a thousand clowns. Later levels, though, play with the variables. Some levels severely limit pie count and require enough accuracy to pull off air combos at will. One level, “The Saddest Clown”, gives you 50 pies and a high point goal, but with only one clown (who truly becomes the saddest clown of all). There are 47 levels in total.

The Player Experience

Our goal with the game was to avoid complicated game mechanics and required learning curves. Instead, we just wanted the player to have fun and laugh a little. The sounds inch up to insanity, each level name is a terribly horrible pun, and we play a little with time scaling by slowing some levels down and speeding up others. The end result is the game is fun to just pick up and play for a few minutes. No explanation needed.

(I Hate Clowns Game Screenshots)

Play Free, Online!

The game is available to play right in your web browser with the Virtools Web Player. If you already have the player installed, the game is ~800k. Otherwise you’re looking at a few MB install beforehand. Check out the landing page for the game right here.

Mile Pie Club

I Hate Clowns was a fun project that took well under 10 hours to crank out. It certainly won’t make us any money; I’d be surprised if anyone would be willing to pay for something this sparse. Still, it’s a hoot to play and a great way to kill time when you should be working (especially if you should be working on games). It’s also a great way to kill clowns. Enjoy!

Play I Hate Clowns online here (800k)