Well, that was fun!

We (IGDA Phoenix) put together a little Game Jam last weekend. Nothing too huge, just six or seven of us, friends and acquaintances from local studios. Instead of the traditional ‘pick a theme’ or ‘insert random quantity’ methods employed by most game jams, we decided to make this Jam’s theme “Backburner.” Essentially, pick a game idea you’ve been kicking around for a while but haven’t had time to implement. Then talk it over with some bright chaps, think about implementation for a few minutes, and dive in. Make that sucker in a weekend!

Jamming is fun because it puts the focus on what’s fun about game design and development and provides a hard-as-a-hammer deadline at the back end which really helps design ideas crystallize and prevents any kind of waffle. It’s easy to prioritize tasks and test whether or not an idea is working if you only have two days to make the whole game. I think the games that got completed are unassailably fun. Says me. Anyhow, play em and judge for yourself:

Conformity by Scott Anderson

Download Conformity here!

Controls: Click and rotate

It started out as an experimental abstract game idea that Rohit came up with about not conforming. The core of the game was the shape and I started to prototype it a couple of days before the jam. Manipulating the shape was appealing enough that I decided to work on it during the jam and put gameplay into it.

During the jam I went through a variety of failed experiments, including a raycasting collision system that didn’t quite work. In the end I ended up with something inbetween Rohit’s original experimental idea and a casual game. To me the shape looked like a web or a net and that’s how I thought up the final “fishing” mechanic.

Interestingly enough you can still apply the conformity metaphor to the game successfully. The rest state is conforming, while you conform you are always safe but can never make progress. In order to make progress you need to break the mold, but if you are too risky you will get hurt.

During the jam I went through a variety of failed experiments, including a raycasting collision system that didn’t quite work. At one point near the end of the jam the game reminded me of cheesy pornographic arcade games, so I threw in a sexy picture as a joke. In the end I ended up with something inbetween Rohit’s original experimental idea and a casual game. To me the shape looked like a web or a net and that’s how I thought up the final “fishing” mechanic.

_______________________________________________________________________

Raptor Assault by Matthew Wegner (Art by RC Torres and Wadam Mechtley)

Download Raptor Assault here!

Controls: WASD

Mostly, it was a test in executing a feel. I wanted to do everything I could think of to make it seem more like a helicopter: first with the physics control, and then with additional visuals like the grass. The ragdoll raptors were an amazing afterthought.

_______________________________________________________________________

Alone or Gravity Guy by Steve Swink (Art by R.C. “Sharkfox!” Torres)

Download Gravity Guy here!

Controls:

A, D – Rotate
Spacebar – Grab hold (when touching walls)
Click and drag – change gravity direction/amount

I started with the idea of infinite gravity control. I wanted to be able to set direction and amount of gravity at any time as much as the player wanted and see what came out of that. Also, I wanted the player to be compressed by gravity (not really in there at the moment, but I did a spring rig dude that looks pretty cool.) Other stuff I didn’t get a chance to try: enemies who affect gravity in their own way, creating ‘gravity wells’, objects that behave differently under gravitational manipulation, areas with fixed gravity directions, making a traditional platformer guy who was unaffected by his own gravity manipulation. Good times!

We started with five designer/programmers and two artists. Three created something show-able; everyone had fun. Success! I think we’ll plan for another jam in two months’ time. If you’re local in Phoenix, come on down!

Making games is my favorite game to play. For me, it’s more fun, more challenging, and ultimately more rewarding to create games than it is to play them. For quite some time I have had a powerful desire to give this experience – the joy of creating levels, designing and balancing systems, and tuning game mechanics – to as many people as possible. I do a reasonable job in my various game design classes at the Art Institute of Phoenix, but the audience is necessarily limited. I want to reach out, to provide these rewarding experiences on a larger scale.

So, what I really want to do is test the assumption that tuning game mechanics is fun, hot, and compelling to everyone. If the sloggy tedium of game development and massive learning curve are removed, is what’s left super fun? My Jumper Exercise seems to indicate as much. As soon as a goal is provided, this simple little mechanic test has a great deal of capture. I tell my class to “make this mechanic fun” and turn them loose. The students have a blast playing with it and often continue fiddling for an hour or more before completing the write-up portion of the assignment. Last week I took this exercise to Gavalin Peak middle school to show at their career day, having some of the 7th and 8th graders play with it; it seemed to have some awesome traction there as well. Providing ‘game design with the boring parts taken out’ as a focused, encapsulated experience should be hot, innovative, and fun.

I can’t help but wonder what would happen if the goals were a part of the system. Can I make a satisfying progression out of tuning a bunch of different game mechanics? Tuning the same mechanic differently to accomplish different tasks? What kinds of tasks and objectives would require different tunings to be successful and would players be able to figure that out? Would it be fun to figure that out, to discover tunings that allow them to optimize results for different assigned tasks? How about level design elements? Could I include spatial manipulation, iteration, and other fun elements of level design in this progression? What if the whole game were a level editor as well?

So, that’s what “Tune” is all about; does game design with the boring parts removed make a compelling game? I think it does, and I want to explore that question fully. Another interesting question is ‘could a game teach game design?’ That’s sort of a secondary goal, to teach the nuts and bolts of game design in a simplified, interactive, easy to understand way, to perhaps help capture and educate future game designers or to contribute to a better understanding of what game design is. So, like the underlying question behind Guitar Hero, “does it rock?”, my question boils down to “is it game design with the boring parts removed?” If ever I get stuck or am unsure about a design decision, I can refer to that. In fact, I’m printing it out and putting it on the wall next to my desk .

Next Steps

So, milestones.

By the end of today, I’ll have completed the brainstorming portion of the project: brainstorming different mechanics that might be fun to tune, what elements of level design I can bring in to the overall game progression and how they might fit in, how the overall system design will work – collection, resources, how everything will fit together and such, UI design and how to present all this stuff in a logical, simple manner, and art treatment.

After that, I’m going to create a master list of questions to be answered from which I’ll generate a prototype map, a short list of the kinds of experiences I want the player to have (and references from game, film, music that create those kinds of experiences), and a series of art and gameplay mockups. Then it’s time to prototype like a maniac. Once I know what I’m creating I should have a better idea how to schedule it – I hope to do a prototype every Monday once I get all the concepts complete.

So I’ll be updating the site each Monday with progress reports and new stuff to show. I’d love feedback; feel free to contribute!

Swink

Exswinkbike
CritterSwing
Swinkeroids
Wormsworth
Bionic Commando 3d
Jumper Exercise
Noteswinger

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