ft_transcendence
ProjectM6
Team web application with a game, accounts, chat and the modules you pick: the end of the core curriculum.
Requires
Unlocks
Nothing else
Guide
ft_transcendence is the final project of the common core (milestone M6, Reported by students), done as a team. You build a complete web application, historically a real-time multiplayer Pong website, with user accounts, a real-time feature, security requirements and a deployment that starts with a single command in Docker. On top of a mandatory base, the team picks modules (frontend framework, backend framework, database, remote players, live chat, two-factor authentication, AI opponent, monitoring, accessibility and more) until it reaches the required score. It is the project where everything from the core meets: C rigour, Python and web skills, Docker from Inception, networks from NetPractice, and team work. The module rules change between subject versions; check the version you register for.
What you will learn
- Designing and shipping a full-stack web application with a team
- Real-time communication with WebSockets: game state, chat, presence
- Authentication done right: password hashing, sessions or tokens, OAuth with the 42 intra, two-factor authentication
- Web security basics: HTTPS everywhere, input validation, protection against SQL injection and cross-site scripting
- Containerised deployment with Docker Compose and one start command
- Splitting a large scope into modules, planning, code review and integration
Before you start
- Previous nodes: Inception (Docker Compose), The Answer Protocol (a networked multiplayer server), and every exam of the core. This guide follows the classic subject; inclusion and placement in the new core are Reported by students and should be checked on your intra.
- Tools: Docker and Docker Compose, git, a code editor, the latest stable Firefox (compatibility with it is reported as mandatory) and your team's chosen stack.
- Team size is reported as three to five students. Agree on roles (frontend, backend, game, infrastructure, security) and a shared definition of done.
- Module scoring reported for recent versions: major modules count two points, minor modules one point, with fourteen points required; older versions counted seven major modules, two minors equalling one major.
Plan of attack
- Week 1: read the subject together and choose modules as a team. Prefer modules that reinforce each other (a backend framework plus a database plus remote players) over scattered small ones.
- Week 1: write the architecture down: services, data model, API endpoints, WebSocket events. Set up the repository, CI, the Docker Compose stack and HTTPS from day one.
- Week 2: accounts and authentication: registration, login, OAuth with the 42 API, profiles. Hash passwords and validate every input on the server.
- Week 3: the core real-time feature (the game) running on the server, with clients sending only inputs, so the server decides the state.
- Week 4: the remaining modules, one owner each, merged through reviews.
- Week 5: hardening: run the full stack from a clean clone with the single start command, test on Firefox, check for console errors, review secrets handling.
- Week 6: rehearse the defence: each member demonstrates and explains every module, not just their own.
git clone your-repo transcendence && cd transcendence
cp .env.example .env
docker compose up --build
Common pitfalls
- Credentials, API keys or
.envfiles committed to git: a fail. - A stack that only works on one teammate's machine or needs manual steps after
docker compose up. - Plain HTTP anywhere, including WebSockets (use
wss://). - Unhandled errors or warnings in the browser console during the demo.
- Game logic computed on the client, letting players cheat or desynchronise.
- Picking too many modules and finishing none: a module is only counted when it fully meets its description.
- Members who cannot explain parts written by others.
How it is evaluated
- Peer evaluation of the whole team. The evaluator clones the repository, checks there are no secrets, and starts the project with the single command.
- The mandatory part is checked first (single-page application behaviour, browser compatibility, security requirements, the game or core feature). Any failure there stops the evaluation.
- Then each claimed module is checked against its description and counted only if complete.
- Every member is questioned. Points beyond the required score count as bonus in recent versions (Reported by students).