Quest Pals Tutorial 1 : Basic 4-Way Movement

ITS GAME MAKING TIME!! YOU PUMPED?!

Seriously now. Get a little excited. I know we are discussing the mighty “Simple 4-Way Movement”, but often getting started can be the hardest part. You have so many ideas, things you want to try, weapons you want to fire, worlds to blow up… or something like that. Look, the point is, getting it all out in front of you and actually STARTING THE GAME can be an achievement in and of itself.

* * * * *

So take a deep breath, and keep your wits about you; you might be surprised, actually, how complicated a simple movement behavior can be (and if you think I’m joking, look at the last section of “Stencyl for Noobs : Positioning and Movement”). But don’t worry: this tutorial is here to help. Almost nothing in game design is straightforward if you want it work smoothly, but with a little figurative elbow grease I hope to not only get you through it but equip you with the problem solving skills you need to succeed.

But enough with the introductory sphiel. Let’s get into it.

* * * * *

What does our behavior need to accomplish?

Well, we want our character to be able to move left, right, up, and down. Sounds so easy your pet hamster could do it, right? But if it was, I wouldn’t be writing this tutorial about it.

First, we need the character to recognize when to move. As you might guess, that will be done with key presses. Press the left control, move left. Since this is four-way though, we don’t want diagnol movement (that would be eight-way), so make sure you set both x and y speeds accordingly so they don’t overlap. Second, we want our character to stop moving when all key presses have been released. So:

1. Move in the direction indicated when you press a key
2. Stop moving when all keys are released

Before going any farther, let’s do a little preliminary set-up. Make four control attributes for each direction:

• Left Control
• Right Control
• Up Control
• Down Control

Easy…?

OK. So in essence, our behavior sounds pretty simple. How about we try something like this:

This might work… until your unsuspecting player presses two buttons at once. Your character will still move, but maybe not the way the player anticipated. Ultimately, out of all the buttons that are being held down, the bottom-most one will “win”, because it executes last. This doesn’t break the behavior, but it makes it very unpredictable on the player’s side. And if there is one big no-no I’ve learned about gaming, bad controls will ruin the player’s experience in lightning speed fashion. Also, what happens when the buttons are released? Does the player need to be stopped? Ah, but you can’t just freeze the player every time a button is released; just because you release one button doesn’t mean the others are no longer down.

Suddenly our movement behavior isn’t so straightfoward. Honestly, look at the pre-packaged behaviors that come with Stencyl. They can look pretty hairy, and that’s for a reason. I reiterate that almost nothing in game design is really that straightforward. Fortunately, we’re going to get it tackled. Part of it is just knowing your tools and the appropiate “tricks” to the trade.

We want a way to delegate priority. We want to figure out a consistent way of determining which key press to listen to when multiple keys are down.

Making A Priority List

“What?! WE’RE GOING TO USE LISTS?! THIS IS ONLY THE FIRST TUTORIAL, DUDE!!”

Look, lists really aren’t all that big and bad. They’re actually really useful in the right place. And the way we are going to use lists in this tutorial is pretty simple.

Essentially, we are going to let our key presses “get in a line”. A general idea of how our list will work:

1. When a key is pressed, it goes to the front of the line (inserted at the start of our list). Whichever key press is at the front of the line is the one we listen to.
2. When a key is released, it gets out of line (removed from our list) and lets others move up (if any are waiting).

So we have two basic commands: “add to front of list” and “remove“. Both in one form or another are found under Attributes >> Lists.

Insert zero at the specified spot to indicate the position at the front of the list.

To understand the beauty of this method, let’s illustrate. Let’s say Up is pressed, then shortly after Left is pressed, and then Right is pressed third. Our list looks something like this afterwards (the left position is the front):

[ Right , Left , Up]

Since Right was last pressed, it steps in front and is the one that gets listened to. Now Right is released, getting out of line. Left and Up are still down, so they haven’t been removed and move up in line, making Left the new “front of the line”.

[ Left , Up]

The “line” method makes it so that our behavior can remember which order keys were pressed in. As long as a key is held down, it stays in line, waiting to move up. All we have to do is get the first key in line to know which way we want to move! Making sense? Let’s put it into action.

Adding and Removing Key Presses from the Line

We are going to add some keyboard events to our behavior to accomplish this. Look below.

Here, you can see what I did for Left Control and Right Control. When the key is pressed, we add a text (unique to each control) to the list at the BEGINNING of the list (position zero). When the key is released, we take that unique text out of the list.

Do the same thing for Down Control and Up Control (using the texts “Down” and “Up”, for instance). Yeah, its a lot of keyboard events, but that’s OK. Looking good so far!

Move or Don’t Move?

(NOTE: If you were directed here by the Grid-based movement tutorial, you can stop here and return to that one.)

Now let’s start hammering out the actual movement logic. Since we need to be checking who’s in line on a consistent basis, we will put our logic into the “Always” event (When Updating).

First, we need to check and see if any key presses are in our list attribute. If there are, we need to look at the first one and figure out which way to move. HOWEVER, if there are no keys waiting in line (no keys are down), stop the movement!

Use an if and otherwise-if to get the desired effect. Our condition will be checking to make sure the list is NOT empty.

Setting Speeds

Once we know at least one key is waiting, let’s get whichever key is sitting at the front of the list through “get item # from list (Priority Line) as text”. Then, just check it against all of our potential candidates (left, right, up, down). So long as your didn’t do something weird like randomly add the text “baked potato” to the list, one of your if/otherwise-if statements should execute.

From there, based on the direction selected, apply the appropriate x-speed and y-speed based on our speed attribute (Movement Speed). As a refresher:

• Right : Positive X-Speed, No Y-Speed
• Left : Negative X-Speed, No Y-Speed
• Down : No X-Speed, Positive Y-Speed
• Up : No X-Speed, Negative Y-Speed

Finally, in the branch that stops movement, set both x-speed and y-speed to zero.

Congratulations! You’ve got a working 4-way movement behavior (Its not completely finished yet, but the movement part works; the next part on animations is in the next tutorial)! I know it looks like a lot, but really, its a lot of repetition of the same thing among our four keys. Make sure you added your key events for Up Control and Down Control too!

Remeber that our final otherwise condition for stopping speed is part of the FIRST if statement sequence, not the group that reads the item from the list.

In Conclusion

Try attaching this to your character and moving them around on screen (make sure you set up your actor’s physics properly!). That’s a bit of work to move in four directions, isn’t it? But that’s how game design works; you have to be ready to problem solve and work to really get good at game design. So in closing, our key points:

• You have to consider how to make different actions work together, such as multiple key presses. You will encounter this A LOT. If multiple behaviors are looking at the same GA, for instance, you want to be sure that they aren’t fighting over who sets its value, just to name one example. Think about keeping things ORGANIZED.
• PRIORITY! This is going to come up again, I assure you, because it pertains to the above. Priority is what will help us keep different actions from doing unruly things that we don’t want. Remember, keep your behaviors from nasty infighting! We don’t want no riots. X-(

In the next tutorial, we will add some animations to our behavior. If you haven’t already been introduced to the mighty Animation Manager, you’ll be seeing that next, and that uses a different form of priority which we will also discuss.

Advertisement