1. When the game starts, some kind of maze with a start and stop and some guards or challenges should be displayed. The player can move freely at this point. The player character should follow the mouse cursor (without needing to press a mouse button).

2. If the player clicks on the start image, then the level is activated. Touching a wall or some guard or challenge element ends the game. Further progress should be prevented and a  message should be displayed.

3. If the player makes it to the end image (without needing to click) the level is complete.

4. When a level finishes, a new level should be displayed, and the player can again move freely until a start is clicked.

5. After at least three levels, a winning game over image or message is displayed. This must be more than the little text on screen I have in the example. The same restriction applies for the losing message.

6. You can use the little text example to display a level or a hint if desired.

7. Each level must

1. Use a different background image.

2. Have different non-player character images.

3. Have a different challenge to get to the end. This difference must be in both images used and the kind of challenge. This means the code implementing it will also be different in style. Look at the example online game as well as the more "adventure-game" style challenge I showed in class for some initial inspiration. You may use the key-door example as one of your challenges.

4. I would recommend searching online for images. I did a search like "key image transparent background" to find the key I used in the example.

8. You do not need to restart at the current level when you fail. I would recommend starting at a higher level when developing the game so you can skip doing the earlier levels when testing.

Code Style

Use good code style throughout. Add docstrings to functions you write. This project is likely a good place for one line comments giving some guidance as to what is going on.

Checkpoint

On Friday, December 1, a checkpoint is due. This is to ensure that you utilize goodtime management and don't wait until it's too late to finish a complete product. The checkpoint will be worth 25 points.

The requirements of the checkpoint are:

  Decide on your theme and complete your short theme description text document.

  Have a very basic first level completed. You should have the ability to click on the start, get through an obstacle, and make it to the end. This can be accomplished with very minor modifications to the provided handout code.

  This doesn't need to be your final version of your first level (e.g. you don't need to incorporate your theme or change the map/players yet). The goal is to show that you can run the starter code and modify it slightly.

  Meet with a TA or Professor Kopta during help hours (https://utah.instructure.com/courses/907916/pages/getting-help)or office hours to check off your checkpoint. If the help hours are too busy and we don't get to you in time, you will not receive credit. Do not wait until Friday if you want to avoid this risk. You may also check off your work with Prof. Kopta or Colin or Will (the two TAs who sit in the back of class) after class on Monday or Wednesday.

  Warning: the checkpoint requirements are a bare minimum and do not represent substantial progress. Wise students will have more than this done by the checkpoint date.

  The checkpoint is due by 5:00pm (the end of help hours on Friday).

Submitting

Make a short video showing a play-through and at least failing on one level.

On gradescope, submit all .py files, imagefiles, and any other needed files along with the text description of the theme and the video file.