A Coding-Only Guide to Making the Game

imageA Coding-Only Guide to Making the Game
Creating the Files

Overview

Creating the Files

  • If using DrRacket:
    1. Make a new folder for each team, naming them after the students.

    2. Into each folder, download the DrRacket file and the [unzipped] teachpacks

  • If using WeScheme:
    1. Start a new program for each team, and click "save". Name the projects after the students.

    2. Into each file, copy and paste the code from the online template, then click "save". Note: for this and all other curriculum files, please make sure you are copying the WeScheme code and NOT the DrRacket code. They are very similar, but not interchangable.

  • We suggest using student names (e.g. - "janelle+chris") for the file/WeScheme name, but anything will do. If you’re in WeScheme, we assume you’ve logged in using a class-wide username and password, so that every student can access their games.

Running the Game

Overview

Running the Game

  • Near the end of the game file, you’ll see an expression that defines a level, (define game_level ...), passing in animation functions and images. You can define other levels if you wish, with different images or animation functions.

  • The last line, (play game_level) will run the game using the level created above. By default, this line will be executed every time the student clicks "Run". You can stop this by adding a semicolon at the beginning of the line: ; (play game_level). This can make it easier for student to experiment with their code and test cases while they’re developing, and they can always run the program manually by typing (play game_level) in the Interactions window.

Making Characters Move

Overview

Making Characters Move

  • Every Bootstrap game includes at least three "characters": the Player, the Target and the Danger.

  • Each is controlled by an update- function (e.g. update-player, update-target, etc.), named for the character it updates. These updates are like the pages of a flip-book: given a page, the update function generates the next logical page in the book.

  • These functions take the current coordinate as input, and return the next coordinate. If the Target moves to the left by 20 pixels each frame, then the body of the function should return (- x 20).

  • You’ll note that there is also a function called update-mystery. This function is actually for animating projectiles, if students insist on having them! (In the curriculum, this is kept a secret early on in order to encourage students to think beyond violent games.

  • The update-player function is slightly different from the rest:
    • It takes two inputs: the y-coordinate of the player (a number) and the key that was pressed (a string, such as "h", "left" or "q").

    • It is called only when a key is pressed, instead of each time the screen is redrawn.

  • If you’d like the player to move differently depending on which key is pressed, you’ll need to use cond. For example:

     

  • Notice the else clause at the bottom! Without it, pressing a key that is not "up" or "down" will end the program with an error!

Changing Your Game Images

Overview

Changing Your Game Images

  • Open the Game Template (either the WeScheme or DrRacket file). Towards the top of the program, you’ll see some values defined for the BACKGROUND, PLAYER, DANGER and TARGET.

  • At the moment, they are defined to be simple images. For example:
    (define BACKGROUND (rectangle 640 480 "solid" "black"))

  • To find new images, use your favorite search engine, such as images.google.com.

  • Try adding "filetype:gif" or "filetype:png" to your searches. If it has a transparent background to begin with, you don’t have to edit one in later.

  • Make sure that PLAYER, TARGET, and DANGER images are at least 100x100, and BACKGROUND images are at least 640x480. A background that is too small will look stretched out.

  • If you are using DrRacket, you can download the images and open them your favorite image editor (e.g. - Photoshop, Paint, GIMP or Acorn).

  • If you are using WeScheme, you can edit the files without ever leaving your browser! Instead, open the file in an online editor like Pixlr.

  • Make sure that character images have transparent backgrounds. You may want to resize them to ensure that the background is at least 640x480, and that the characters are at least 100x100.

  • When you are done editing the images, you’ll want to save and add them to your games. If you are using a program on your computer to the files, save them into the same folder as your student games. If you are using an online editor like pixlr.com, you can save the file directly to an image-sharing site like imgur.com, or upload it to other sites like Flickr, Dropbox, etc. Wherever you choose to save it on the web, be sure to remember the address for your new image!

  • In the student game file, replace the definition for each image with code that will load the image from your computer or the internet.:
     

  • Time to test it out! Click "Run", and then evaluate those variables in the Interactions window. Typing BACKGROUND, for example, should show you the image you used for the Background. Once you see all images loading successfully, click "save".

  • You can rotate, scale, or flip the images using Racket functions:

     

Making the Target and Danger Come Back

Overview

Making the Target and Danger Come Back

  • The teachpack will automatically regenerate the characters if the onscreen function returns false when given the character’s x- and y-coordinates.

  • By default, the function returns true - meaning that the characters are always considered onscreen. Once they get moving, they fly off the screen, never to return!

  • The "onscreen" logic should also take into account that the characters have width and height! For example, a 200px-wide character will still be partially onscreen even when it’s x-coordinate is -50. For this reason, we recommend a "buffer" of roughly 50 pixels on all sides.

  • In the lesson plans, students write functions that check the left and right sides of the screen separately:

       

  • Then they write a single function, called onscreen?, which is only true if their characters are protected on the left AND the right:

     

  • If you have an unusually wide or tall character image, you may wish to use larger buffer values.

Detecting Collisions

Overview

Detecting Collisions

  • To detect whether or not two characters have collided, the game code needs to know two things: how close they are, and how close they are allowed to be before a "collision" occurs.

  • You can illustrate this by using the *distances-color* variable. Setting it to any color will draw triangles to show the distance between the player, target and danger. Setting the value to the empty string "" will hide them again.

  • The lengths of each the legs is calculated by the line-length function. Modify the body so that it correctly calculates the distance between a and b. You can do this using abs or cond:

     

  • The hypotenuse length is calculated by the distance function. Students will code the distance formula here, using the line-length function:

     

  • Finally, collide? starts out always returning false, so nothing collides even when you have the distances all working. Use the distance formula, with some threshold:  

Exploring the Teachpack

Overview

Exploring the Teachpack

The bootstrap-teachpack lets you do more – try the Supplemental Lessons for some ideas and challenges: play with 2d motion, random numbers, a different collide? function, or harder play based on

*score*

.