Overview

In this tutorial, you will use Python to create your own version of Wordle, a popular word-guessing game.

Learning objectives:

1. Use test-driven development (TDD) by writing tests before implementing the code needed to make those tests pass.
2. Handle errors and unexpected situations using exceptions.
3. Organize your code clearly using Model-View-Controller (MVC) pattern, with a clear separation between the game logic and the user interface.
4. Configure your program using configuration files rather than hard-coding settings directly into the source code, making it easier to modify the game's behavior without changing the program itself.
5. Develop different types of user interfaces, including a terminal-based interface and a web-based interface using Flask.

How to play Wordle

The objective of Wordle is to guess a hidden word within a limited number of attempts.

1. The game selects a hidden word of a predetermined length, typically five letters.
2. The player has a limited number of attempts to guess the word, typically six guesses.
3. Each guess must contain the correct number of letters.
4. After each guess, the game provides feedback for every letter:

• A letter is marked correct if it appears in the hidden word in the same position.
• A letter is marked present if it appears in the hidden word but is in a different position.
• A letter is marked absent if it does not appear in the hidden word.

5. The player wins by correctly guessing the hidden word before using all available attempts.

6. If the player uses all attempts without guessing the word, the game is over and the hidden word is revealed.

Importantly, the dictionary contains a limited set of valid words. If a user enters a word that is not present in the dictionary, the application informs them that the guess is invalid, but the attempt is not counted. The user can therefore enter another valid guess without losing an attempt.

The game may use different symbols, colors, or other visual indicators to display the feedback for each guess, depending on whether it is played in the terminal or through a web interface.

Project preparation

• Fork this project in GitLab.
• Clone the forked project into a folder of your computer.
• Open the project in Visual Studio Code (VSC).
• Create a virtual environment by typing the following command in the terminal integrated in VSC.

python3 -m venv .venv

• Activate the virtual environment: source .venv/bin/activate (Linux/macOS), .venv\Scripts\activate (Windows PowerShell).
• Update pip with the following command:

python3 -m pip install --upgrade pip

• Install the dependencies with the following command:

python3 -m pip install -r requirements.txt

Project structure

In addition to the Git-related files and the requirements.txt file that you are already familiar with, the project is organized into the following folders:

• assets: This folder contains resources used by the application, such as the dictionaries from which secret words are selected and the configuration files used to customize the program. It can also contain other static resources, such as logos or images.
• src: This folder contains all of the project's source code. This is where you will complete the existing implementation and add new code files as needed. Some files have already been provided and will be explained as you progress through the assignment.
• tests: This folder contains the tests that your code must pass in order to be considered correct. Throughout the project, you will add and run tests to verify that your implementation behaves as expected.

The model-view-controller pattern

As the Wordle application grows, it is important to organize the code in a way that makes it easier to understand, test, and modify. To achieve this, the project follows the Model-View-Controller (MVC) design pattern.

MVC separates an application into three main components:

• Model: The model contains the core logic and data of the application. In this project, it is responsible for representing the state of the Wordle game and implementing its rules. For example, the model may store the secret word, keep track of the player's guesses, determine whether a guess is valid, and generate the feedback associated with each guess. The model should not depend on how the game is displayed to the user.
• View: The view is responsible for presenting information to the user and collecting user input. In this project, you will implement two different views, a terminal-based interface and, if time allows it, a web interface using Flask. The view should focus on how information is displayed rather than on the game logic itself.
• Controller: The controller acts as an intermediary between the model and the view. It receives input from the user through the view, requests the appropriate operations from the model, and updates the view with the results. In this way, the controller coordinates the interaction between the user interface and the game logic.

This separation of responsibilities provides several advantages. Since the game logic is independent of the user interface, the same model can be used with different views, such as a terminal application or a web application. It also makes the code easier to test, since the core game logic can be tested independently of the interface.

If you look inside the src folder, you will find three subfolders, corresponding to the three components of the MVC pattern: model, view, and controller. Each of these subfolders may also contain an exceptions folder with the code responsible for defining and handling errors specific to the corresponding MVC component.

We start our implementation with the model.

The model

Unless the application is very easy, the code of the model should not appear in one single file. To have a better idea of which files we need, we need to think of what we need to implement the game rules.

As identified in the previous exercise, implementing the Wordle game requires several different components. This suggests that the game logic should be divided into multiple modules rather than implemented in a single file. We'll use object-oriented programming to implement these modules.

The dictionary

The dictionaries used by the game are provided as text files in the assets folder. We need to implement the code responsible for loading and managing these dictionaries, as well as the operations required by the game rules.

Before implementing the dictionary, it is useful to identify the operations that it must support and define the expected behavior of each one. This will allow us to design and test the dictionary component before writing its implementation.

Test-driven development

Rather than implementing the methods in class Dictionary immediately, we will first define their expected behavior through tests. For each operation, we will write one or more tests that describe the expected result. We will then implement the corresponding functionality with the goal of making all the tests pass.

In this project, we will use pytest to automatically test the different components of our application. pytest is a Python testing framework that discovers and runs test methods and reports whether they pass or fail.

To keep the tests organized, we will group related tests into test classes. Each class will correspond to a component or a specific group of functionality that we want to test. For example, all tests related to the dictionary could be placed in a class called TestDictionary. A test class is simply a Python class whose name starts with Test, and its test methods are functions whose names start with test_.

def rectangle_area(width, height):
    return width * height

class TestRectangleArea:

    def test_area_of_rectangle(self):
        assert rectangle_area(5, 3) == 15

    def test_area_of_square(self):
        assert rectangle_area(4, 4) == 16

assert rectangle_area(5, 3) == 15

assert 10 > 5

assert not 10 < 5

assert "hello".upper() == "HELLO"
assert len([1, 2, 3]) == 3

assert "Python" in ["Python", "Java", "C++"]

from src.model.dictionary import Dictionary

from src.model.dictionary

import Dictionary

We will now add tests to verify that words are correctly normalized when they are added to an empty dictionary. In other words, we want to write tests for the method of class Dictionary that adds a word to a dictionary.

Before writing the tests we need to consider three situations that may affect the way a word is stored:

• Leading and trailing whitespaces: Words loaded from a file may contain unintended spaces or other whitespace characters (such as tabulation characters) at the beginning or end. These should be removed before the word is stored.
• Accented characters: When playing Wordle in languages other than English, words may contain accented characters. Since players are typically not required to enter accents, these should be removed so that comparisons between guesses and the secret word remain consistent.
• Letter case: Players may enter words using uppercase letters, lowercase letters, or a mixture of both. To ensure a consistent representation, all words should be converted to lowercase before being stored.

Run the tests with the following command:

python3 -m pytest tests/model/test_dictionary.py

As expected, the tests should fail, and this is exactly what we want at this stage. The method to add words has not been implemented yet, so there is no functionality for the test to verify.

project/
├── src/
│   └── ...
└── tests/
    └── model/
        ├── test_dictionary.py
        └── test_game.py

We can now implement the method responsible for adding a word to the dictionary. Before doing so, however, we need to ensure that all words are stored in a consistent format. Therefore we will first implement helper methods that convert a word to lowercase and remove its accents. Once these operations are defined, we can use them when implementing the method that adds a word to the dictionary.

import unicodedata

word = "café"
normalized = unicodedata.normalize("NFD", word)

normalized = ''.join(
    char for char in unicodedata.normalize("NFD", word)
    if not unicodedata.combining(char)
)

In the previous exercises, we tested that a word can be correctly added to an empty dictionary. We should now verify that the Dictionary class also behaves correctly when words are added to a dictionary that already contains entries.

In particular, we need two tests:

• one to verify that a new word is correctly added to a non-empty dictionary;
• one to verify that a word that is already present is not added a second time.

Both tests require the same initial setup: a dictionary that has already been initialized and contains one or more words. Duplicating this setup code in every test would make the tests unnecessarily repetitive and harder to maintain.

Fortunately, pytest provides a mechanism called fixtures that allows us to define reusable test setup code. A fixture can create and initialize the objects or data required by one or more tests, allowing each test to focus on the behavior it is intended to verify.

Once the tests have been written, your task is to implement each method in class Dictionary so that all the tests pass. In this way, the tests act as both a specification of the required behaviour and a guide for the implementation.

Handling errors

In the previous code, we added to the class Dictionary a method that randomly selects a word with the specified length. However, we neglected the case where the dictionary does not contain any of the words of the specified length. We have here an error condition that we should carefully address using exceptions.

age = -1

if age < 0:
    raise ValueError("Age cannot be negative")

try:
    age = int(input("Enter your age: "))
except ValueError:
    print("Please enter a valid number.")

try:
    ...
except Exception:
    ...

except ValueError:
    ...

class InvalidWordError(Exception):
    pass

if not word:
    raise InvalidWordError("The word cannot be empty.")

try:
    process_word(word)
except InvalidWordError:
    print("The word is not valid.")

dictionary.contains(word)

If you look inside src/model/exceptions, you will find a file named NoWordOfLengthException.py. This file defines a custom exception class called NoWordOfLengthException. The class does not currently contain any additional code; it simply inherits from Python's built-in Exception class.

with pytest.raises(ZeroDivisionError):
     res = 3/0

Test coverage

Now that we have completed the implementation of our Dictionary class guided by the test-driven development principles, we may want to verify that our tests cover all the important cases. To do so, we can run the following command:

python3 -m pytest --cov=src.model.dictionary

Game logic

Now that the dictionary component has been implemented, we can move on to the core of the application: the game rules.

To support a complete game of Wordle, the application must provide functionality that allows a user to:

• Create a new game. Each game has its own configuration, including the required length of the guesses, the maximum number of attempts allowed to guess the secret word, the secret and the dictionary from which the secret word is selected. Some of these settings may have default values.
• Submit a guess. The game must accept a player's guess and compare it with the secret word, producing the appropriate feedback for each letter.
• Determine whether the game has finished. The application must be able to determine whether the player has guessed the secret word and won the game, or whether the maximum number of attempts has been reached and the game has been lost.

In addition to implementing these operations, the game must keep track of its state throughout its execution. This includes the guesses submitted by the player and the result of evaluating each letter in every guess.

Although Wordle is a relatively simple game, it would not be advisable to place all of this functionality in a single class or file.

A better approach is to separate the different responsibilities into distinct components. For example, we can define one class to represent a guess and its letter-by-letter evaluation, and another class to represent the game itself and implement the game rules. This separation will make the code easier to understand, test, and maintain.

The view

The view is responsible for the user interface. It allows the user to interact with the application by entering guesses and receiving feedback about the progress and outcome of the game.

Before implementing a graphical or web-based interface, we will first develop a simple terminal interface.

An important aspect of the MVC pattern is that the view should not interact directly with the model. Instead, the controller acts as an intermediary between the two components: it receives input from the view, invokes the appropriate operations on the model, and then instructs the view to display the resulting information.

The view will therefore provide the following operations:

• ask_guess: Wait for the user to enter a new guess and return the value entered.
• show_invalid_length_guess: Display an error message when the user enters a guess whose length does not match the length required by the current game settings. Since the terminal allows the user to enter a word of any length, the application must provide feedback when the guess is too short or too long.
• show_invalid_guess: Take the guess entered by the user and display an error message indicating that it is not a valid word in the dictionary.
• visualize_guesses: Display all the guesses submitted by the user. Each guess includes feedback for its individual letters, indicating whether a letter is in the correct position, present in the secret word but in a different position, or absent from the secret word. This method may use a helper method to display a single annotated guess and call it for each guess submitted during the game.
• visualize_win: Display a message informing the user that they have won the game.
• visualize_loss: Display a message informing the user that they have lost the game.

In addition to implementing these operations, the view is responsible for decisions related to the presentation of information. This includes the style of messages and, in particular, the use of colors to represent the different states of the letters in a guess.

Although a terminal interface may appear relatively simple, Python provides libraries that make it possible to create more expressive and visually appealing terminal applications. In this project, we can use the rich library and its console API to display formatted and colored text, allowing us to provide clear visual feedback to the player.

from rich.console import Console

console = Console()

console.print("Hello!")
name = console.input("Enter your name: ")

console.print("[red]This is an error message.[/red]")
console.print("[green]Operation completed successfully.[/green]")
console.print("[bold blue]Important information[/bold blue]")

console.print("[bold]Welcome![/bold]")
console.print("[yellow]Warning: check your input.[/yellow]")
console.print("[red]An error occurred.[/red]")

from rich.text import Text

text = Text("Hello world!")

text.stylize("bold blue", 0, 5)

console.print(text)

text = Text("Success: operation completed")

text.stylize("bold green", 0, 7)
text.stylize("bold", 9, 26)

console.print(text)

from rich.table import Table

table = Table(title="Student Results")

table.add_column("Name")
table.add_column("Score")
table.add_column("Status")

table.add_row("Alice", "18", "Passed")
table.add_row("Bob", "12", "Passed")
table.add_row("Charlie", "7", "Failed")

console.print(table)

The controller

The controller coordinates the interaction between the view and the model. It receives input from the view, invokes the appropriate operations on the model, and passes the results back to the view for display. The view and the model remain independent of each other: neither needs to know about the other; only the controller interacts with both.

More specifically, the controller is responsible for the following tasks:

• Reading the game configuration. The controller reads the game settings from the configuration file assets/wordle.ini, rather than hard-coding these values in the program.
• Initializing the game. Using the settings read from the configuration file, the controller creates and initializes a new game.
• Running the game. During each iteration, the controller asks the view to obtain a guess from the user, submits the guess to the model, and retrieves the resulting annotation. It then passes this information to the view so that the guess and its feedback can be displayed.
• Finalizing the game. Once the game is over, the controller determines the outcome and instructs the view to display the appropriate message, informing the user whether they have won or lost.

The settings are given in a INI configuration file.

[game]
word_length = 5
max_attempts = 6
language = en
dictionary = assets/dictionaries/wordle_en.txt

Now we can focus on the flow of the game.

It is now time to create the main entry point of the application: the script that starts the game.

👉 Time to play. Execute the application with the following command:

python3 -m src.wordle_console_app

This ends the tutorial. If you still have time, you can learn how to create a Web interface with Flask

Advanced: Graphical interface with Flask

Flask is a lightweight Python web framework that allows us to create web applications. It provides the functionality needed to receive requests from a web browser, execute Python code in response, and send a response back to the browser.

As you may recall from the course on networks, the browser and the web server communicate using the HTTP protocol. HTTP provides a certain number of methods, but two are particularly important in the context of this project:

• GET is generally used to request information from the server, such as displaying a page.
• POST is generally used to submit information to the server, such as a user's guess.

Browser                         Flask application
   |                                  |
   |       GET /                      |
   |--------------------------------->|
   |                                  |
   |       HTML page                  |
   |<---------------------------------|
   |                                  |
   |       POST /guess                |
   |       guess = "example"          |
   |--------------------------------->|
   |                                  |
   |       Updated page               |
   |<---------------------------------|

The communication between a browser and a Flask application is slightly more complex than it may initially appear. When a user interacts with a web page—for example, by clicking a link or submitting a form—the browser sends an HTTP request to a web server. The web server is responsible for receiving the request and determining how it should be handled.

However, a traditional web server does not know how to directly execute a Python web application. To solve this problem, the Python community developed WSGI (Web Server Gateway Interface), a standardized interface that defines how a web server communicates with a Python web application. WSGI is specified in PEP 333.

The basic architecture is therefore:

Browser

   │
   │ HTTP request
   ▼

Web server

   │
   │ WSGI
   ▼

Python web application

   │
   ▼

HTTP response

   │
   ▼

Browser

A WSGI server, such as Gunicorn or Waitress, is responsible for running the Python application and communicating with it through the WSGI interface. These servers can accept HTTP requests themselves, but in a production environment they are often placed behind a separate web server. The web server can handle tasks such as serving static files, managing HTTPS connections, and filtering or forwarding incoming requests, while the WSGI server focuses on running the Python application. The web server placed in front of the application server is called a reverse proxy. A typical production architecture therefore looks like this:

Browser

   │
   │ HTTP/HTTPS
   ▼

Web server / Reverse proxy

   │
   │ WSGI
   ▼

WSGI server

   │
   ▼

Flask application

First Flask application

To become familiar with Flask and its terminology, let's start with a simple example. We will create a small Flask application and use it to explore some of the concepts introduced in the previous sections.

Inside the src/playground folder, create a new file called flask_sample_app.py. We will gradually build our example application in this file.

App initialization

A Flask application is represented by a Python object created from the Flask class. Add the following code to flask_sample_app.py:

from flask import Flask

app = Flask(__name__)

The app object represents our web application. It is responsible for receiving HTTP requests and determining how they should be handled.

The argument passed to the Flask constructor is the name of the application's module or package. In most cases, using __name__ is the appropriate choice. __name__ is a special Python variable containing the name of the module in which the code is defined. In our example, its value is src.playground.flask_sample_app.

Flask uses this information to determine where the application is located and where it should look for resources associated with it, such as templates and static files, which we will introduce later.

Routes and views

When users interact with a web application, they request specific URLs (Uniform Resource Locator), such as http://example.com/wordle. The application must determine what to do when a particular URL is requested.

Flask introduces the concept of a route for this purpose. A route associates a URL with a Python function that should be executed when that URL is requested. The function is called a view.

For example, the following code defines a route for /, which conventionally represents the home page of a web application:

@app.route("/")
def home():
    return "Hello, world!"

Here, / is the route, while home() is the view function associated with that route. When a browser requests /, Flask calls home() and sends the returned value back to the browser.

👉 Add this code to flask_sample_app.py.

Running the application

We can now start the application from the terminal with the following command:

flask --app src.playground.flask_sample_app run --debug

The command should produce some output in the terminal and then appear to stop responding. This is expected: Flask has started the development server and is now waiting for incoming requests.

Among the messages displayed in the terminal, you should see something similar to:

Running on http://127.0.0.1:5000

Open this address in a web browser. You should see:

Hello, world!

Address already in use
Port 5000 is in use by another program.

Debugger PIN: 123-456-789

👉 Add the following code to file flask_sample_app.py :

@app.route("/about")
def about():
    return "About page"

@app.route("/hello/<name>")
def hello(name):
    return f"Hello, {name}!"

@app.route("/status")
def status():
    return "<h1>Everything is working!</h1>"

As you can see in the second route, routes can also have dynamic parts. In the third route, the view return some HTML code, the code used to create a web page.

👉 Play with the application to make sure that all routes function correctly.

Templates

In a real web application, we generally do not want to write complete HTML pages directly inside Python functions. Doing so would mix the application's presentation with its Python code, making the application harder to organize and maintain.

To address this issue, Flask supports templates. A template is typically an HTML file that defines the structure of a web page while including placeholders for information that will be provided dynamically by the Python application.

Flask uses the Jinja template engine to process templates. For example, consider the following template:

<!DOCTYPE html>
<html>
<body>
    <h1>Hello, {{ name }}!</h1>
</body>
</html>

The expression {{ name }} is a Jinja placeholder. When the template is rendered, Flask replaces it with the value associated with the variable name.

By default, Flask looks for templates in a folder named templates. This folder is normally located relative to the module or package in which the Flask application is defined. The location can also be customized using the template_folder argument when creating the Flask application.

👉 Create a folder named templates inside src/playground, and create a file called hello.html containing the template shown above. Then modify your Flask application so that the /hello/<name> route renders the template:

from flask import render_template

@app.route("/hello/<name>")
def hello(name):
    return render_template("hello.html", name=name)

The call to render_template() performs two tasks:

• It loads the template file hello.html from the templates folder.
• It passes the value of the name variable to the template.

For example, if the user visits /hello/Alice, Flask calls hello("Alice") The function then renders hello.html, passing Alice as the value of name. Jinja replaces {{ name }} with that value, and the browser receives the resulting HTML:

<h1>Hello, Alice!</h1>

In this way, the Python code remains responsible for handling the request and preparing the data, while the template is responsible for defining how that data is presented in the browser.

Wordle interface

For our Wordle game, we would like to create a web interface that provides the main elements needed to play and configure the game:

• The game board. The board consists of a grid of tiles. The number of columns corresponds to the number of letters in a valid guess, while the number of rows corresponds to the maximum number of attempts. Each tile represents a single letter entered by the player.
• A virtual keyboard. The keyboard is displayed below the game board and provides an overview of the letters used throughout the game. As guesses are submitted, the keys can be colored to indicate the status of each letter.
• Game settings. The interface should allow the user to start a new game and modify settings such as the language, the required length of a guess, and the maximum number of attempts.

All the code related to the web interface will be located in the src/view/web folder. This folder already contains two important subfolders:

• templates: This folder contains the HTML templates used to define the structure and content of the web pages. As HTML is not part of the SIP program, the templates are provided and you will not need to modify them.
• static: This folder contains static files, that is, files that are sent to the browser without being dynamically generated by the application. It includes the style.css file, which contains the styling instructions for the web interface. As with the HTML templates, the CSS file is provided as part of the project, since CSS is not covered by the SIP program.

Game Configuration

The game configuration is stored in the wordle.toml file, located in the assets folder.

We use the TOML format because it provides a more structured way of representing configuration data than the traditional INI format. TOML supports features such as nested tables, arrays, and explicit data types, which are useful when configuration becomes more complex.

For example, the configuration can organize language-specific settings hierarchically:

[languages.en]
label = "English"
flag = "🇬🇧"
dictionary = "assets/dictionaries/wordle_en.txt"

[languages.fr]
label = "Français"
flag = "🇫🇷"
dictionary = "assets/dictionaries/wordle_fr.txt"

Here, en and fr are sections nested within the languages section. In contrast, an INI parser would generally interpret [languages.en] and [languages.fr] as two separate section names rather than as nested sections.

Application Factory

As we have seen, a Flask application is an instance of the Flask class. Routes, views, configuration settings, and other application components are registered with this instance.

In our first example, we placed all of this code in a single file. This approach is convenient for a small example, but it quickly becomes difficult to manage as an application grows. In a larger project, we therefore want to split the code into several modules.

This raises an important question: where should the Flask application object be created?

One possibility would be to create a global Flask object that can be imported by the different modules of the application. However, the Flask documentation recommends avoiding this approach in larger applications, as it can lead to problems related to imports, testing, and the management of multiple application instances.

Instead, Flask recommends using an application factory. An application factory is simply a function that creates and configures a new Flask application. All the instructions needed to initialize the application, such as loading the configuration and registering routes and other components, can be placed inside this function.

The application factory is conventionally defined in a file called __init__.py. In our project, this file will be located in src/view/web/__init__.py

from pathlib import Path
import tomllib

from flask import Flask

from src.view.web.wordle_state import initialize_game

def create_app():
    app = Flask(__name__)


    with open("assets/wordle.toml", "rb") as f:
        config = tomllib.load(f)


    app.config.from_mapping(
        GAME=config["game"],
        SETTINGS=config["settings"],
        LANGUAGES=config["languages"]
    )

    return app

The create_app() function is our application factory. When we later start the application using the flask command, Flask will locate and invoke this function to create the application.

The function performs the following steps:

1. Creates a Flask application by instantiating the Flask class.
2. Loads the configuration from assets/wordle.toml using Python's tomllib module, which is part of the standard library.
3. Registers the configuration with the Flask application using app.config.from_mapping().
4. Returns the configured application.

The configuration is stored in app.config, Flask's configuration object. We store the three main sections of our TOML configuration under the keys GAME, SETTINGS, and LANGUAGES.

Notice that these keys are written in uppercase, following Flask's convention for application configuration keys:

app.config["GAME"]
app.config["SETTINGS"]
app.config["LANGUAGES"]

The values associated with these keys are the corresponding sections loaded from the TOML file.

At this stage, the factory only creates the application and loads its configuration. As we continue developing the web interface, we will add the remaining initialization steps, such as registering routes.

Initialization of the game

If we run the application at this point, Flask will start successfully, but requesting a URL will result in a 404 Not Found response. This is because we have not yet defined any routes or view functions.

Before defining the routes, however, we need to implement some functions that will manage the state of the Wordle game for the web application. We will place these functions in a new Python module called wordle_state.py, located in src/view/web/.

👉 In __init__.py, add the following line inside the create_app() function, before return app:

app.extensions["wordle"] = initialize_game(
    config["game"],
    config["languages"],
)

Board view

We will now create the board view.

{"letter": "", "state": "unknown"}

Keyboard state

We now implement a function for handling of the virtual keyboard state.

{
    "A": "unknown",
    "B": "absent",
    ...
    "Z": "unknown",
}

unknown < absent < present < correct

Game status

We now implement a function to keep track of the game status.

Routes and views

We now define the routes and implement the corresponding views to display the game, submit guesses, start a new game, and modify the game settings.

Rather than defining all routes and views in a single file, we group related functionality using a Flask concept known as a blueprint. In this project, we can define two separate blueprints:

• game, which contains all the routes and views related to the game itself.
• settings, which contains all the routes and views related to configuring the game.

from flask import Blueprint
bp = Blueprint('game', __name__)

Once the blueprint has been defined, we can start associating routes with it. We begin with the route for the index page, /.

We will then incrementally build the corresponding view to render the index page and display the game interface.

In order to show the game interface, the function index() must build the board view and the keyboard state. These are components that are needed by the template index.html. Let's define them.

It is now time to render the index.html template. This template requires several arguments, some of which correspond to values that we retrieved in the two preceding exercises.

return render_template(
  "index.html",
  game_settings=game_settings,
  general_settings=current_app.config["SETTINGS"],
  language_settings=current_app.config["LANGUAGES"],
  board_rows=board_view,
  keyboard_states=keyboard_states,
  active_row=active_row,
  error_message=request.args.get("error", ""),
  status=status,
)

The blueprint must now be registered with the Flask application. Otherwise, the routes associated with the blueprint will not be available to the application.

from . import game
app.register_blueprint(game.bp)

It is now time to test the application.

👉 Type the following command:

flask --app src.view.web run --debug

If you enter the URL http://127.0.0.1:5000/ in your browser, you should see the game board and the virtual keyboard. You should also be able to enter a guess in the first row. However, you will not yet be able to submit the guess, as we have not implemented the route responsible for handling it.

👉 Now try entering the URL http://127.0.0.1:5000/?error=test. You should see the message "test" highlighted in red in the interface. This demonstrates the purpose of the error_message argument that we added to the render_template() call.

Let's now implement the view associated with the /guess route. This will allow the user to submit a guess and receive feedback.

return redirect(url_for("game.index", error="The word is not in the dictionary"))

👉 In template index.html uncomment lines 86-88 by removing {# at line 86, and #} at line 88. Run the app and play the game!

Is everything working as expected? You should now notice, however, that there is no option to start a new game. Let's add this functionality!

Game settings

The only remaining functionality is to allow users to modify the game settings: the language, the number of attempts, and the length of the guesses.

In the index.html template, the code responsible for displaying the interface elements that allow users to change these settings is located on lines 13–50.

👉 Uncomment this code to enable the settings interface.

There are three types of settings:

• "language", whose value is the code of the currently selected language.
• "word_length", whose value is the length of the guesses.
• "max_attempts", whose value is the maximum number of attempts allowed.

👉 Use the application and make sure you can change the settings correctly.

Conclusions

We have reached the end of this tutorial. Throughout the project, you have progressively built a complete application while applying several important software development principles and techniques.

Here are some of the key concepts you should remember:

• Test-driven development (TDD). You learned how tests can guide the development process by defining the expected behaviour of your code before, or alongside, its implementation.
• The Model-View-Controller (MVC) pattern. You learned how to separate the different responsibilities of an application by distinguishing between the model, which manages the application's data and logic, and the views and controllers, which handle user interaction and presentation.
• Modular software design. You learned the importance of organizing an application into separate modules and components, each with a clear responsibility. This makes the code easier to understand, test, maintain, and extend.
• Exception handling. You learned how to identify error conditions and use exceptions to handle them appropriately, rather than mixing error-handling logic with the normal flow of your application.

You also learned how to:

• Write automated tests using pytest, including tests that verify both the expected behaviour of your code and the correct handling of exceptional situations.
• Build a terminal-based user interface, allowing users to interact with the game directly from the command line.
• Build a web-based user interface using Flask, including routes, views, templates, forms, redirects, and blueprints.
• Organize a Flask application using an application factory and modular blueprints.
• Use Git to track your changes and progressively develop the project.

If you still have time, you may try to add the functionality to play Dordle.