Game development lab: a game loop, gravity and collisions in the browser

This lab gives each student a small game of their own, Catch the stars, made of three files: index.html for the page, style.css for its looks and game.js for its rules. They edit the files in JupyterLab’s file editor and play the game in a second link, the Preview, which is served from the same folder. Short Python scripts read game.js and print what is in it, and do the game’s arithmetic again, so a student can check how a game works as well as change it.

It is not an attack lab, and it has no engine and no library: a game is plain JavaScript on an HTML canvas, and the browser is the only runtime. Every copy has no route to the internet and none to any other student, so nothing can be downloaded into it and nothing in it can reach anybody else.

What students learn

What a game loop is: a function that runs once for every frame, updates the game and then draws it, and asks the browser to call it again. How a game keeps its numbers in named constants such as GRAVITY, PLAYER_SPEED and SPAWN_EVERY, and its levels in a table of data, so that making it harder means changing data and not code. How gravity works in a game, as a number added to a speed on every frame, which then moves the position. And how a collision is found, by testing whether two boxes overlap on both axes. It suits introductions to game development and to programming through games; check your own awarding body’s unit for the exact wording, none is quoted here.

Run it in your browser

The lab starts one service, jupyter, which writes the game, a starter notebook and the short scripts into its work folder and starts a plain file server on the folder game. Two links open from the lab’s page: JupyterLab, the workbench, and Preview, the game itself. JupyterLab asks for no token, because the platform’s own door already knows who is opening it. There is no browser inside the lab, so the scripts cannot show the game, only read its code; a student plays it in their own browser on the Preview link, with the arrow keys or the on-screen buttons. The Preview shows the saved files, so after editing a file a student saves it and reloads the Preview. The terminal beside the lab has no Python of its own, so it reaches the lab’s with docker exec jupyter, followed by the command to run inside.

  1. Open the Container page. Open Build on the bar and choose Run a container. Anybody may open it, and the Git lab and the SQL lab start with no account. Every other lab needs a free account: create one, sign in, then press Start.
  2. Find the lab. The Sample labs card lists every sample. Find Game development: a game loop in JavaScript.
  3. Press Start. Start runs it as it is, in one press. Edit the file first opens the compose file so you can change it before you start.
  4. Open it. On the lab’s page, the lab bar has two links. Press Preview to play the game, then press JupyterLab, open the folder game and double-click game.js. Next press Open terminal and type docker exec jupyter python3 steps/loop.py to list the game’s named constants and functions.

What to ask students to hand in

Their own version of the game: the three files from the folder game, downloaded from JupyterLab with File, Download. Then a sentence or two in their own words on one number they changed, for example GRAVITY, PLAYER_SPEED or a row of LEVELS, and what it did to the game. Nothing is marked automatically: the sentence shows whether it was understood. For stronger work ask them to run steps/fall.py before and after the change and say what moved, or to add a fifth level to the table and explain how the script’s output changes.

A basic lesson on this lab

Game Loop Basics is a small lesson worked in this lab. In it a student lists the three files of the game, reads its named constants and functions and the loop that runs on every frame, works out the levels from the table, follows a falling star for ten frames, runs the box overlap test on fixed pairs, and asks the Preview’s server for the page. It is deliberately small: it shows a teacher what a lesson worked in a lab is, and the lab does the rest. Copy it into a module of your own to change it.

The code on GitHub

The compose file has no Dockerfile: it runs one stock public image, the Jupyter Docker Stacks’ own scipy-notebook, pinned to a dated tag, as its own unprivileged account with 512 MB of memory. The image is licensed BSD-3-Clause and is not distributed by us. The file writes the game and the scripts from fixed text when it starts, so every copy is the same and nothing is downloaded. The limits are honest ones: the game is small, there is no engine and no way to fetch a library from the internet, and no browser inside the lab, so the scripts read the code rather than run the game, and where a star starts is random each time it is played. Nothing is kept when the lab stops, so a student downloads their files first.

Set it as work

Say in the task what to hand in.

  1. Make the lab. In your module add a task and choose the Container lab card, then In a GitHub repository. Give https://github.com/mitsurutech/lab-game-web with the branch main. The compose file is the default, compose.yaml. Fork the repository first if you want to change it, for example to start students from a different game.
  2. Publish and try it. Publish pins the commit you were shown, so a later change in the repository does not alter a lab you have already set. Start your own copy first.
  3. Hand it out. Assign it like any task, with a due date if you want one, and say in the task what to do and what to hand in.
  4. Mark what is handed in. Open a student’s copy and the work they handed in, mark it, and send it back with a reason if it needs more.

Try this lab, and what it costs

A free personal account can work through the basic lessons in this lab, with enough free credit each month to follow most lessons and no card. For a class, a school or college has its first 365 days free for up to 50 students, then pays per student a year, with every lab included and staff free.

Questions people ask

Why are there two links?
JupyterLab, the first, is where a student edits the files and runs the terminal. Preview, the second, is the game itself, served from the folder game, the way a player would see it. Keeping the game in its own tab means it is not wrapped in an editor.
Can the scripts show me the game?
No. There is no browser inside the lab, so a script can read game.js and repeat its arithmetic but cannot draw it. Play the game in your own browser on the Preview link. The scripts print the same numbers every time, which is what lets a class compare answers.
I changed a file and the Preview did not change. Why?
The Preview shows the saved files. Save the file in the editor, then reload the Preview. If it still looks the same, try a hard reload, because a browser may keep an old copy of a file.
Why is there no token or password to type?
A lab’s web page is reached only through the platform’s own door, which already knows who you are and lets in only you and the staff who teach your module. So JupyterLab is started with no token. Do not run it like that on a machine anybody else can reach.