25.7. Game Page Logic

Our home page is ready, the database functions operate, and we have access to ready-made functions in game_logic.py. After we add one final bit of code, we can finally play our Minesweeper game!

25.7.1. The play() Function

The play() function controls the game page. It renders the mines.html template, collects and validates data from the form, calls a function to analyze each guess, and redirects players to the home page as needed.

Open the main.py file in Visual Studio Code, then code along with each of the following videos.

25.7.1.1. Collect and Validate Guesses

25.7.1.2. Collect Checkbox Data and Call check_guess()

25.7.2. play() Summary

  1. By typing the URL of the game page into the address bar, players can access the board before hiding any mines. To prevent this, we redirect them back to the home page if they arrive at the page through a GET request.

  2. We need to collect two pieces of information from the game board: which cell the player selected and whether or not they clicked the Flag Mine checkbox.

    1. Each button on the board has the same name, and the value for each one matches its cell coordinates (like A10).

    2. However, the value for the New Game button is the empty string.

    3. The checkbox input has a different name from the buttons.

    4. The syntax for requesting the button and checkbox data is slightly different.

      1
2
3
4
5
      # Request button data from the form:
request.form['button_name']

# Request checkbox data:
request.form.get('checkbox_name')

  3. Even though each button has a defined value, we still need to include some server-side validation. Invalid input redirects the user back to the home page.

  4. After validating the data, we call the check_guess() function to see if the player clicked a mine or made a safe choice on the board.

25.7.3. Update mines.html

As the user plays the game, the appearance of the board changes. There are 4 possibilities for the cells in the table. Each one is either:

  1. Unselected: These appear with a gray background and have an active, blue button.

  2. Selected and safe: These appear with a white background and display a number showing how many mines are in the surrounding spaces.

  3. Flagged: These appear with a goldenrod background and have an active, blue button.

  4. Mined: These appear with a red background and an inactive button. Clicking a mined cell ends the game and reveals the locations of all remaining mines on the board.

The play() function calls check_guess() each time the user clicks a button on the board. The results determine the how that cell should change after it is selected.

To finish our Minesweeper game, we need to update the code in mines.html. Our goal is to properly display the board after each turn. Also, we’ll provide different feedback messages to indicate victory or defeat.

Open the mines.html template in Visual Studio Code, then code along with the following videos.

25.7.3.1. Change Cells After Click

25.7.3.2. Add Feedback Messages

25.7.4. mines.html Summary

  1. Each time a player clicks a button on the game board, its appearance changes.

  2. We use 5 session key/value pairs to determine the styling and content for each cell:

    1. flags: This key points to a list of all the cells the player marked with the Flag Mine option.

    2. guesses: Points to a list of safe cells the player has clicked.

    3. mine_counts: Points to a dictionary that contains the number of mines surrounding each space on the board.

    4. hit_mine: A boolean value. Set to True when the player clicks on a mine.

    5. mines: Points to a list containing the locations of hidden mines.

  3. By adding an extended if/elif/else block to mines.html, we can check the conditions for each cell just before it is rendered on the page.

  4. Adding another Jinja3 conditional inside the <header></header> element allows us to display different feedback messages to the player.

25.7.5. Test the Game!

Yay! Our Minesweeper game is ready. Play a few games to see how the application behaves.

Tip

When your teacher and/or parents ask why you’re playing games instead of doing homework, tell them you’re beta-testing a coding project.

As you play, you will find some glitches and rough spots in the game. This is expected, and it’s the whole point of testing! Keep a record of the flaws you find, and note how serious each one is. Errors that crash the application or impact the gameplay should be addressed before minor annoyances.

Even though the game functions, we can’t call the application “complete” just yet. In this chapter, we focused on getting the game up and running, and we accomplished that goal. However, the project does contain a number of shortcomings. How to fix these is up to you! You have a good starting place right now. Your ideas will determine the next step.

Note

No project is ever really done. Unusual bugs will pop up that need to be fixed, or new feature ideas will pop into your brain. Coding an application is a continuous process of tinkering, testing, and discovery!