What is Motion?
Motion is a nearly universal game mechanic and refers to playable characters moving as result of user input, non-playable characters responding to automated or scripted motion, or a combination of both elements. Each of these types of motion fall under the general category of “Motion” but you’ll see that they have specific use cases.
The first type of motion that you’ll be working with is automated or scripted motion. This is useful for controlling non-player characters (NPCs) since their behavior is (typically) independent of the player input.
Your game can have several NPCs with different movement patterns and triggers that move regardless of user input. Each NPC can have its own automated motion script that moves it around the stage. You can use automated motion to create highly complex and difficult enemy movement patterns that don’t rely on input from the player and that act independently of the player character (PC).
Example: Automated Motion
As covered in the Working with Input article, the “move [ ] steps” block within the Motion category requires no user input and can be triggered at the start of the game by using the gameStart Event (green flag clicked). However, this method doesn’t provide much control, even for automated motion. If you’re looking for a starting point from which you can scaffold to introduce more advanced motion scripts it’s not a bad place to start, but for this project you’ll be changing the sprite’s x and y positions, even for the automated motion of the NPC.
As you build out your motion system, think of it as you’re creating your studio’s “physics engine.” This term will be covered in more depth later, but for now just keep in mind that if you’re developing an automated system of motion that you want to reuse, you can build it out into reusable code that can be saved in your backpack and integrated into later projects.
In this example there are two sprites: the Robot hero and the enemy Alien. The Alien is the NPC, so his movement is going to be completely automated. Right now there isn’t much of a goal for his motion other than to just get the sprite moving around the screen.
To accomplish this, you’ll need to use 3 new blocks: “glide [ ] secs to x: [ ] y: [ ],” “wait,” and “pick random [ ] to [ ].” You’re going to see that this results in a highly randomized motion, and if you determine the objective to be needing to avoid the NPC, it could quickly become quite difficult. This is a good opportunity to practice tweaking code values in order to balance game difficulty. Additionally, this step is a good phase for your youth to collaborate and play test each other’s games, providing feedback on the difficulty and then allowing for iteration based on player feedback.
Take a look at this screenshot of the NPC script:
Let’s break down the code:
- The first step is to initialize the sprite position with the “go to x: [ ] y: [ ]”
- The movement itself is contained in a forever loop. This is fine for now, as the script will continue to execute the automated motion until the stop button is clicked. When working on this for a game, you’ll want to impose limits for the duration of this motion.
- Next is the actual motion itself. This particular example uses the glide block:This block is found in the Motion category. It takes three input parameters: time, final x value, and final y value. Essentially, this block smoothly moves the sprite from it’s current location to the specified values. The movement takes as long as specified in the time value.
- The next 3 blocks are added to increase the randomness of the sprite motion. Let’s take a closer look:
The “change x by…” and “change y by…” blocks should be familiar. Once the sprite glides to the random location determined by the previous block, the sprite then moves an x and y value randomly generated between -20 and 20.
- The last block is “wait [ ] secs.” This is the delay function within Scratch. This script pauses for .25 seconds before looping back to the beginning and running again. This is included in order to make the motion seem less jumpy.
If you have an idea for the game objective at this point, go ahead and implement it when programming the motion. For example, if you know that you want the hero character to have to avoid the NPC, you could write the automated motion script to be driven by that goal. If you’re unsure, just complete this activity with the intention of solely practicing the mechanic.
Activity: Create Automated NPC Motion
Create an automated motion mechanic for the enemy NPC in your game. Use the above steps for guidance. At the end of this activity you should have the following:
- NPC sprite that moves once the game starts. This can be randomized or not- the difficulty and purpose are up to you.
- An understanding of how you can program complex motion scripts that act independently of player input.
- An understanding of how enemy motion relates to the purpose of your game. The implementation and usage of this mechanic will change depending on the intent.
Input Driven Motion
The basic input driven motion that you’ll be using right now is actually much less complex than the automated motion script that you just wrote. This is because for right now, the character is using the “when [ ] key pressed” Hat block. This block handles a lot of the complexity of the motion at the expense of flexibility and control. The only other block that’s needed for basic input responsive motion is the change x and y block. Remember, you want to think of your sprite’s position and movement as being plotted on the coordinate plane. This is why you’ll want to get in the habit of using the change x/y block as opposed to the move block.
Example: Input Driven Motion
Take a look at the script that is used to power the player motion. It’s rather straightforward:
The breakdown is simple: Create as many Hat blocks as you need inputs. In this case, once the game starts the sprite moves to its initial position and then waits for player input before moving. Make sure to change the correct x and y values for the corresponding motion! Look back to theWorking with Input article if necessary.
Activity: Create Motion with Input
Create motion that is responsive to input for the hero PC in your game. Use the above steps for guidance. At the end of this activity you should have the following:
- A hero sprite that moves in response to player input.
- An understanding of how motion with input is constructed.
Congratulations! You now have a working motion system in your game! You’ll be modifying this over the next few activities, but you’ve taken the first steps toward creating your motion engine.