Reading the Player

Last unit your bob moved by itself, the same way every time. That's an animation, not a game. The thing that makes it a game is that the player is in charge — push the joystick and the bob goes that way; let go and it stops. All it takes is asking the joystick, every frame, which way it's being pushed, and moving the bob to match. You already have the frame loop; now you put a question to the player inside it.

What you'll see by the end

The bob began near the top-left corner. In the picture it's lower and further in — because it was steered there, pushed right and then down. Run it yourself and the bob goes wherever you push, the instant you push it.

The whole program

Hide
Screen Open 0,320,200,16,Lowres
Colour 0,$111
Colour 1,$F40
Colour 2,$FD0
Cls 0
Ink 1
Bar 0,0 To 23,23
Ink 2
Bar 6,6 To 17,17
Get Bob 1,0,0 To 24,24
Cls 0
X=40
Y=88
Do
   If Jright(1) Then Add X,3
   If Jleft(1) Then Add X,-3
   If Jup(1) Then Add Y,-3
   If Jdown(1) Then Add Y,3
   Bob 1,X,Y,1
   Wait Vbl
Loop

The top is familiar — make the bob image, set a start position. The new part is what happens inside the loop:

Do
   If Jright(1) Then Add X,3
   If Jleft(1) Then Add X,-3
   If Jup(1) Then Add Y,-3
   If Jdown(1) Then Add Y,3
   Bob 1,X,Y,1
   Wait Vbl
Loop

Four questions, then draw, then wait — every single frame.

Asking the joystick

If Jright(1) Then Add X,3

Jright(1) asks the joystick a yes-or-no question: is it being pushed right, right now? It's true while the stick is held right and false otherwise. There's one for each direction — Jleft, Jright, Jup, Jdown — and they're built to drop straight into an If, exactly like the comparisons you met in unit 4.

The (1) is which joystick. AMOS numbers the two control ports 0 and 1; a joystick normally lives in port 1, so Jright(1) reads the stick you'd reach for. (Port 0 is where the mouse sits.)

So each line reads: if the stick is pushed this way, move the bob that way. Push right, X grows, the bob goes right. Push up, Y shrinks, the bob goes up — remember y counts downward, so less y is higher on screen.

Why it's checked every frame

The four Ifs sit inside the loop, so they run fifty times a second — the joystick is asked afresh on every frame. That's what makes the control feel alive: the moment you push, the next frame moves the bob; the moment you let go, the Ifs all come back false and it stops. Reading input once wouldn't do — a game has to keep asking, frame after frame, because the player keeps changing their mind.

Input, then move, then draw

Look at the shape of the loop now: read the player, update positions, draw, wait. That's the game loop from last unit with one line of work added at the front — read the player — and it's the shape nearly every game has. Everything else you add later (enemies, bullets, scoring) slots into that same skeleton: ask what's happening, change the world to match, draw it, wait for the frame.

Type it and run it

Type the program in and press F1, then push your joystick. The bob follows. (No joystick handy? Many emulators let you drive the joystick from the keyboard or numeric keypad — check your emulator's settings.) Press Esc or reset to stop, since this loop runs forever.

Try this: go faster

Change the 3 in each Add to 6. The bob now moves six pixels a frame in every direction — twice the speed. The step size is the speed, the same as it was for the automatic movement; the only difference is the player decides when to take each step.

Try this: fire to do something

Add a line inside the loop that reacts to the fire button:

If Fire(1) Then Paper 4 : Cls

Now a press of fire clears the screen to colour 4. Fire(1) reads the joystick's button the same way the direction functions read the stick. (That : lets you put two commands on one line — handy for a short reaction.) It's a rough effect, but it shows the button is just another question you can ask.

If it doesn't work

• The bob won't move. Check you're reading the right port — Jright(1), with the 1 — and that your emulator has a joystick set up in port 1. With no joystick configured, the questions are always false.
• It moves the wrong way, or only some directions work. Check each If pairs the right direction function with the right change: Jup with a minus on Y, Jdown with a plus, because y grows downward.
• The bob shoots off and never comes back. Nothing here stops it leaving the screen — that's expected for now. Keeping a bob inside the screen edges is the job of the next unit but one.

What you've learnt

Reading the player is what turns motion into a game. Jleft, Jright, Jup and Jdown each ask whether the joystick is pushed that way — true or false, ready to drop into an If — and Fire reads the button. The port number in brackets picks the joystick (port 1 for the usual one). Asked every frame inside the loop, these questions make the bob answer instantly to the stick. The loop's shape is now read input, move, draw, wait — the skeleton under nearly every game.

What's next

You're steering the bob by hand. Next — AMAL — you'll hand a movement back to AMOS: describe a path once, set it running, and let a little animation language move the bob for you while your program gets on with other things.