GameMaker Visual Scripting Tutorial

Build one tiny GML Visual setup in GameMaker where a key press moves the player and another opens a door, without writing a line of code.

GameMaker includes a visual scripting system called GML Visual. Instead of typing code, you drag action blocks into events. Each block does one thing, and the blocks run from top to bottom.

This guide builds one small setup: a player that moves when you hold the arrow keys, and a door that disappears when you press a key. That is the whole goal. Finish it, run it, and you will understand how events and actions fit together.

GameMaker updates often, and action names or their categories can shift. If something below does not match your editor, match the current GameMaker manual’s GML Visual reference. It is the source of truth.

Understand the two ideas first

GML Visual rests on two concepts.

Events are moments in the game loop. The manual describes them as points where things happen based on what you set up. Examples include when an instance is created, every game step, and when a key is pressed.

Actions are what you do in that moment. Move an instance. Change a variable. Destroy something.

You add events to an object, then drop actions into each event. When the event fires, its actions run in order. That is the full model, and everything else builds on it.

Create the project

Start a new project in GameMaker and choose GML Visual as the project type when asked. If you pick code by accident, the manual notes that objects can convert between GML Visual and GML code, but starting in the right mode is simpler.

Keep the project small. You need:

• Two sprites: one for the player, one for the door
• Two objects: obj_player and obj_door
• One room

Draw the sprites yourself as plain colored squares if you like. A blue square for the player and a brown rectangle for the door are enough. Art can come later.

Make the sprites

Create a sprite named spr_player. Draw a simple shape. Set its origin to the center so movement and rotation behave predictably later.

Create a second sprite named spr_door. Make it a tall rectangle. Center its origin as well.

Naming matters. Prefixes like spr_ and obj_ help you tell assets apart at a glance once your project grows.

Create the player object

Create an object named obj_player and assign spr_player as its sprite.

Now add movement. The manual describes three keyboard event categories:

• The regular keyboard event, which fires every step while a key is held down
• The pressed event, which fires once when a key first goes down
• The release event, which fires once when a key comes up

For smooth movement, you want the one that fires every step while held. In the event list, it may appear under a label like “Key Down.” Pick that category, then choose the right arrow key.

Add your first action

With the right-arrow event open, find the movement actions. The manual lists an action called Jump To Point. It places the instance at a new position.

Drag Jump To Point into the event. Set the x value to a small positive number and the y value to zero. Then tick the relative option.

Relative is the key detail. Without it, the instance teleports to that exact spot in the room. With it, the instance moves that many pixels from where it already is. The manual’s own example uses a negative x with relative ticked to move left.

Repeat for the other three arrows:

• Left arrow: negative x, zero y, relative ticked
• Up arrow: zero x, negative y, relative ticked
• Down arrow: zero x, positive y, relative ticked

Remember that in GameMaker’s room space, y grows downward. Up is negative.

Use a variable instead of repeating a number

Typing the same speed in four places is fragile. If you want to change it, you have to edit every event.

Add a Create event to obj_player. This runs once when the instance appears. Drag in the Assign Variable action. Name the variable move_speed and give it a small value.

Now go back to each arrow event. Replace the typed number in Jump To Point with move_speed, or a negative version of it for left and up. One edit in the Create event now changes speed everywhere.

This is your first real graph: a Create event that stores a value, and four keyboard events that read it.

Create the door object

Create an object named obj_door and assign spr_door.

You want the door to open when you press a key. For this first graph, “open” means the door is removed from the room, so the path is clear. It is simple, and you can see it work.

Add the keyboard event that fires once on press. The manual calls this the Keyboard Pressed event. Choose a key you like, such as the space bar.

Drag in the Destroy Instance action. By default, its scope is self, which means the instance running the event destroys itself. Here, that is the door.

Notice that the event lives on the door, not the player. Keyboard events run on any instance that has them, so the door listens for the key itself. That keeps the logic next to the thing it affects.

Build the room

Open the room. Place one obj_player instance on one side and one obj_door instance in the middle.

You do not need walls yet. The goal is to see two behaviors work: movement and opening.

Run and test

Run the game. Check each behavior:

• Holding an arrow key moves the player smoothly in that direction.
• Letting go stops the player.
• Pressing your chosen key makes the door vanish.

If the player jumps across the room, you forgot the relative option on at least one action. If the door does not respond, check that you used the pressed event and not the release event, and that the key matches.

If nothing moves at all, make sure the instance in the room is obj_player and not a copy of a different object.

Read what you built

Open each event and read the actions out loud in plain language:

• “When this instance is created, set move speed.”
• “While the right arrow is held, jump to a point a little to the right, relative to here.”
• “When space is pressed, destroy myself.”

If you can say it in a sentence, you understand it. That is the real skill GML Visual teaches. Code later is the same idea with different syntax.

Where to go next

Pick one improvement and stop after it works:

• Make the door open only when the player is close, using a check on distance or collision before the destroy action.
• Add a sound action to the door’s pressed event.
• Swap Destroy Instance for a change of sprite so the door looks open instead of vanishing.

Each one teaches a new action without throwing away what you built. Check the manual for the exact action names before you search for them.