DAW project 2023/2024 - first phase

[pmhsfelix]

Goal

The goal of this project is the development of a Web-based system allowing multiple players to play the Gomoku game.

Architecture

This system will be composed of a centralized backend service and one or more frontend applications. The frontend applications will run on the user's devices, providing the interface between those users and the system. The backend service will manage all the game related data and enforce the game rules.

Frontend applications will communicate with the backend service using an HTTP API. These applications will not communicate directly between themselves. All communication should be done via the backend service, which has the responsibility of ensuring all the game rules are followed, as well as storing the game states and final outcomes.

Project phases

This project is divided into two phases:

• The first phase consists of the development of the backend service.
• The second phase consists of the development of a browser-based frontend application, which will use the backend service developed in the first phase.

The HTTP API exposed by the backend service, developed in the first phase, can also be usable by an Android-based frontend application, developed in the context of the Programação de Dispositivos Móvies course.

Functionality

The HTTP API should provide the functionality required for a front-end application to:

• Obtain information about the system, such as the system authors and the system version, by an unauthenticated user.
• Obtain statistical and ranking information, such as number of played games and users ranking, by an unauthenticated user.
• Register a new user.
• Allow an user to express their desire to start a new game - users will enter a waiting lobby, where a matchmaking algorithm will select pairs of users and start games with them.
• Allow an user to observe the game state.
• Allow an user to play a round.

Game rules and evolution

The Gomuku game does not have a single set or rules. Instead, it allows for multiple variations on the game rules, such as:

• Board size (e.g. a 15 by 15 grid or a 19 by 19 grid).
• Opening rules.
• Variants

The backend service and exposed HTTP API should be designed in a way to allow the evolution of these gaming rules, including allowing different games to use different rules. The frontend applications should adapt automatically to these evolving and dynamic game rules.

Delivery

The first phase should be delivered until October 21, 2023 (end of week 6), via the creation of a 0.1.0 tag on the group's repository. Any change after that date should result in the creation of a patch tag (e.g. 0.1.1).

The second and final phase should be delivered until December 9 (end of week 13), via the creation of a 1.0.0 tag. Any change after that date should result in the creation of a patch tag (e.g. 1.0.1).

The backend service should be executable via the docker-compose system without any other dependencies. I.e. the backend service should be executable on any machine with docker desktop, via a docker compose command, without requiring any additional software installation or configuration.

The delivery should also contain:

• The HTTP API documentation required for a frontend client application to use this API. This documentation should not include any information about the internal backend implementation.
• A single technical document, with the backend internal software organization, the data model, and the main implementation challenges.

Both these two documents should be linked from the README.md file, located in the repositories root directory.