Project: Little Robo Climber (Controls, Animation Model)

A Little Robot Dude

A Little Robot Dude

Hello internet!

Today I want to talk to you all about a project I’m putting together — a technical demonstration. Unsurprisingly, it’s a game, and I thought I’d go over my process here. This will cross multiple posts as the project develops.

First and foremost, I wanted something to add to my portfolio that would be fun to play and complete. Previous versions of my portfolio have only included partially completed tech demos, which are limited in how impressive they can be. Additionally, I wanted to work on something that could function as a scaled down version of some other projects I’m hoping to do in the future.

In this case, that means a 2D game that uses animation modeling as the base for it’s controls, and that’s what we’ll be talking about today.

So, with that in mind, I started doing some animation. Simple stuff. I designed this little robot character. He’s not much more than a glorified stick man, but that’s ok. I don’t need him to be complicated. More complicated characters take more time to animate, and this is something I’d prefer to do quickly.

While I drew him up, I thought of what kind of game I want him in — a platformer for sure (they will always be my favorites), but what else? Thinking about this, I thought of what I wanted the little guy to be able to do — walk, run, jump, crouch, crawl, cling to edges, push and pull.

So thinking about that, I determined the controls for this little guy. Arrow keys and two buttons (A and B). Left or right will make him walk; double tapping left or right will make him run. Down will make him crouch, and down with left or right will make him crawl. Button A will make him Jump, button B will make him ‘grab’. Grab something and press left or right to push/pull. Grab while next to an edge (in the air) to grab it.

The Little Robot Dude Sprite Sheet

The Little Robot Dude Sprite Sheet

So; after determining what I want the Robot Dude to do, I animated the 28 frames that will represent his motions. On this sheet we have: Standing, Starting to Walk, Jumping, Grabbing, Grabbing Edges, Hurt, Looking Up, Falling (2 frames), Crouching, Crawling (2 Frames), Walking (4 Frames), Running (4 Frames), Pulling (3 Frames), Pushing (3 Frames), and Stopping Walking (2 Frames).

This also represents the complete animation model for the character. It’s a very simple model, but it’s very important for the game’s controls. This may not follow, so let me talk about control models.

There’s too many buttons in gaming, usually. It stems from old ideas — if we make a simple game controlling a little guy, we’ll be inclined to use arrow keys to move him around. Expanding on that, we add a button to make him jump, and another one to pick things up. Over time, he has many buttons for a equal number of actions. Now, most people (designers especially) understand why this is bad — too many buttons are too difficult to remember and make for a poor model for controlling a character.  So, if we want more complex controls, we need to develop context sensitive input, or to skip the jargon, we need to make the same buttons do different things as appropriate.

There’s a few ways to go about this, but the method of context sensitive controls I’m most familiar with is via an animation model. What this means is that you don’t control the character directly, but instead you direct the animation of the character. For example, pressing left doesn’t make the character go left, but rather instructs the walking animation.

The way these models work is by defining a number of states that the character can be in, and then defining what the inputs for each state (or context) are. We can represent these states and their inputs pretty clearly like this.

State 1 State 2 State 3
State 1 Loops Press A Press B
State 2 Press A Loops Press B
State 3 Press A x Hold B

So, in this example, there are three states. The active state is listed on the left, and the state they transition to on the top. The intersection is what causes the transition — what we can see is that state 1 and 2 are persistent — they don’t end, they just repeat themselves until something happens. Likewise, State 3 doesn’t end until the player lets go of the B button, or presses the A button. Pressing the A button switches between States 1 and 2.

Here’s an except from the model for the Little Robot Dude.

Stand Crouch Start Walking Walking Stop Walking
Stand Loop Press Down Press Left/Right x x
Crouch Release Down Hold Down x x x
Start Walking Collision x x Hold Left/Right Release Left/Right
Walking Collision x x Hold Left/Right Release Left/Right
Stop Walking Wait 2 Frames x x x x

So here we can see how pressing buttons change states. The importance of the Start and Stop walking states is for animation clarity in foremost, but also for additional controls. Pressing Left or Right in the Stop Walking state, enters the running state — practically to the player, this means from the standing state, tapping left or right twice, or tapping left or right once while walking will send the player in to the ‘run’ state. Additionally, the player can always enter the ‘Hit’ state, and they can enter the ‘Fall’ state from any state except the Jump State.

There’s more to talk about, but this is where I’ll cut it for today. Later this week, we’ll talk about overall game objectives, and more details on the Mechanics and Flavor.


Tags: , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: