…so named by gentleman RC, who did the character art.

Exswinkbike 1.0

Development time: ~20h including creation of background art assets, mechanic tweaking, and briefly flirting with creating an editor (not quite ready for primetime.)

Exswinkbike Prototype 1
Exswinkbike Prototype 2
Exswinkbike Prototype 3

The Practical Value of Cloning

As the name might indicate, Exswinkbike started as a clone of Excitebike. So the design goal here wasn’t particularly lofty; it was mostly intended as a learning experience.

A note on cloning: in learning how to create art, one must master the ‘fundamentals’ – figure drawing, perspective, realistic rendering and the like. One way to approach this is copying the works of great masters. Picasso mastered photorealistic painting before venturing into cubism and making bulls of handlebars. Likewise, every competent artist has copied thousands of Bridgeman or Hale-Richter hands, heads, feet. Copying great works is a great way to master skills. In games, this is cloning. There’s nothing wrong with cloning successful mechanics as a learning experience; people who are learning to program games often start by making a Pac Man or Asteroids clone. As aspiring game designers this is what we need to be doing and doing rigorously. At some point I’ll move on to cloning Ski Stunt Simulator, Mario 64, and things of greater complexity. I encourage any aspiring designer to do the same.

‘Clone’ is not a bad word.

Aesthetics * Skill Ceiling * Input Sensitivity * Abstraction Layer

In its current state, Exswinkbike is similar to Excitebike in two ways. First, the agent you’re controlling is a motorbike with a rider on it which is viewed from a slightly angled side perspective. Second, succeeding at the game is mostly about properly aligning the bike to match the terrain you’re trying to land on. There it parts ways with Excitebike, now more closely resembling an amalgam of Trials and Ski Stunt Simulator, with just a sprinkling of Excitebike.

Exswinkbike has the beginnings of some nice impact aesthetics, provided by the physical nature of the mechanic. These could be enhanced with basic particle effects (dust or smoke particles from the tires, an explosion of particles if the rider hits the ground) and faked video effects (a screen shake on impact).

The input is at the “second layer” of input abstraction because your mouse movement controls the rider, not the bike. So, to influence the direction and rotation of the bike, you move the rider around. Moving the rider changes the center of mass for the whole system, altering rotational vectors. The result is that you can tuck her against the bike closely and lean her forward to increase the speed of your rotation, or push her away from the bike and backwards to decrease or reverse your rotation. The skill is in predicting the direction and speed of rotation you’re going to want and compensating early, sometimes before the bike is even in the air.

In terms of process, I’d call this one a “creep” design. As I accomplished each small, incremental design goal, I supplanted it with another, larger one. I decided that instead of a one-to-one clone of Excitebike, it would be more fruitful to create a basic physics rig for a motorbike. So I built out basic shapes for the bike, tires and suspension, imported them, and constrained them using springs, adding an “engine” torque to drive the back wheel. I decided that powering only the back wheel was adding unnecessary complexity, and was causing the bike to flip more easily than I’d like, so I distributed the force evenly between both wheels. Then I decided I wanted to add a rag doll rider to the rig, which added up to more complexity than anything I’d tweaked and balanced previously. On top of that, I decided I wanted to make the controls mouse-driven, and to funnel all control through the rider rather than map it directly to the bike.

Exswinkbike has a high skill ceiling because the mechanic is simulation-based. Physics-based mechanics have high levels of input sensitivity and react uniquely to minute differences in input. Instead of pressing one button and getting a specific effect, the player sweeps the mouse around in broad gestures to approximate the intended effect. As far as the computer is concerned, the long, sweeping mouse movements are just a series of tiny incremental button presses that have specific effects, but perception blurs this and makes it seem fluid. Functionally, there are infinite numbers of positions and postures the rider can assume. These effects, which speak to the finicky nature of physics-based mechanics and second layer input abstraction, make the initial learning curve steep. By design, however, the frustration inherent in such a steep learning curve is mitigated to some degree by the fact that it’s fun to crash – failure is partially enjoyable.

Prototypes & Evolution

The process here was somewhat broken for rapid prototyping or commercial purposes; this was mostly a great learning experience. The evolution:

Exswinkbike Prototype 1

This is around three hours’ work. There was a promising feel from the get go: a good impression of speed and some satisfying impact and overlap when the bike recoiled from hitting the ground. I quickly hacked in loss and victory conditions; if the body of the bike touched the ground, you lost. If you made it to the checkered polygon, you won. Of course, ‘winning’ simply means it says ‘win’ instead of ‘lose’ (and resets you just the same.) The most annoying part about creating this initial setup was the respotting, actually, since I had to ‘unphysicalize’ all of the bike’s physics objects, move them to where they were going, and re-run the setup script to get them back to being physics objects again. All in all, though, it’s not hard to build a basic physics mechanic in Virtools if you have a clear idea what you’re creating.

…and this is where I went a bit wrong moving forward. I decided I wanted to create an increasingly complex physics system, but approached it in more of a “bolt-on” fashion. Ideally, you should frontload any complexity and the design process should be a whittling down. In his commissioned essay in Rules of Play, famed designer Reiner Knizia says as much: “I like my game designs to begin with elaborate concepts and too many features, and then later streamline the game play, only retaining the best parts of the design. I find this process easier than trying to bolt on additional elements later, and overall it has led me to more satisfying game designs.”

Exswinkbike Prototype 2

This is where the bulk of the time that went into this project was spent. When dealing with large numbers of constraints and springs, a system such as this is in danger of becoming unstable very quickly. And indeed it did. The actual tweaking of variables is not so tough, but it’s difficult to make progress if every variable you alter is in danger of causing the entire rig to explode (literally.) Consequently, I spent a lot of time learning about what specific values would cause this rig to go belly up and working around those constraints. One variable that was surprisingly important was the “dampening” parameter applied to each object. A good analogy for this parameter is drag, or air friction. The default value is relatively high and was hampering the speedy feel I was going for, but it took me quite some time to realize what I needed to alter to change the impression of speed. An interesting point raised here is that of variable setup.

When creating mechanics, there are two disciplines. The discipline of tweaking abstracted values and curves to achieve a specific feel is relatively straightforward – a very aesthetic, intuitive judgment, but a fairly obvious one. The ability to effectively tweak a mechanic is dependant on the strength of your vision. If you have a crystal clear vision for the mechanic you’re trying to create, tweaking variables is relatively easy. The second discipline, system design, is much more difficult. You need to set up a system in which the variables exposed will allow you to achieve the desired feel through tweaking. This second discipline is a much more subtle, challenging one to master. Once you have a specific mechanic in mind, there isn’t really a ‘right’ or ‘wrong’ way to go about creating it. You need a very clear vision of the feel you’re trying to create so you have something against which to measure progress. Past that the implementation is up to you. The ultimate litmus test is this: does it work?

If it works, it works. No one will care why and how.

Exswinkbike Prototype 3

This was the last iteration before I added art and altered the wheelbase to become more stable. In some ways, I like this prototype more that the current working version. It’s finicky, difficult to control, and somewhat obnoxious, but it has a certain charm. Because of the level of difficulty, and perhaps because I’ve played a lot of Ski Stunt Simulator and Trials, it feels like a real accomplishment to grab the reins and really get it to do what you want.

In the final version, I changed the wheelbase of the bike to be a bit wider for more stability, and adjusted the skeleton of the rider until it was possible to tuck her up, close to the bike, for faster rotation.

Moving Forward

I’m going to submit Exswinkbike to the IGF next year. Moving forward, I’m going to experiment with a few different structures. I feel like there is much greater potential for physics-based mechanics than what has been explored thus far. A lot of the physics mechanics out there continue to be shoehorned into existing structures, most often a series of levels (as in a traditional platformer.) A physics-based mechanic dictates a different structure, I think. I’m not quite sure what that structure is, but the first thing I’m going to try is a series of “personal best” parameters that will be tracked and accessible via menu. In the next iteration, the level will have three checkpoints. Between each checkpoint, the player with have an array of personal best values – things like lowest time to checkpoint A, fastest speed, highest point reached, longest air time, most flips in a jump, most backflips in a jump, longest wheelie, longest nose manual – all of which will be constantly updated as the player plays. Each time you score a new personal best in any of those areas, you’ll be prompted and unlock more abilities. I’m going to test a few additions to the existing mechanic that will be unlockable, including a piston like apparatus for controlled jumping, some kind of glider or pseudo flying addition, magnetic grappling for the tires, a gravity reversal device, and the ability to change direction mid air. We’ll see how it goes. Feel free to make suggestions.

- Swink