The Answer Protocol
ProjectM5
Multiplayer text adventure TCP server that follows the 42TAP protocol, in the language of your choice.
Requires
Unlocks
Guide
The Answer Protocol is a late core group project (milestone M5; placement Reported by students) in the language of your choice. Your team implements a multiplayer text adventure, a small MUD: a TCP server that holds a shared world of rooms, items, non-player characters and quests, plus clients that connect to it, all speaking a line-based protocol specified in an RFC-style document called 42TAP. Because the protocol is fixed, any client should work with any server, so reading and following a specification precisely is the whole point. Details below come from student repositories (Reported by students); check them against your subject.
What you will learn
- Reading and implementing a protocol specification, including its ambiguities
- TCP servers: sockets, many concurrent clients, partial reads and message framing
- Connection state machines: connected, authenticated, terminated
- Shared mutable state under concurrency (one goroutine, thread or task per client) and locking
- Designing a game world as data: rooms, exits, items, NPCs, quests, combat
- Structured logging of every protocol exchange
- Team organisation on a medium-size project
Before you start
- Previous nodes: NetPractice (ports, addresses) and the M4 projects. Any language is allowed; teams report Go most often, C++ sometimes. Pick one with good concurrency support that the whole team knows.
- Tools: your language toolchain,
ncortelnetto talk to the server by hand, and a JSON library. - Read the whole RFC before designing anything, and list every command and every error code in a shared document.
- Reported team size: three students.
Plan of attack
- Day 1: read the RFC together. Reported basics: UTF-8, one message per line ended by a line feed, a maximum message length, a greeting with the version, then
CONNECTwith a unique name. Note every place where the RFC contradicts itself (students report CRLF versus LF) and decide your behaviour. - Day 1: split the team: server core, world and game rules, clients.
- Day 2: server skeleton: accept connections, buffer partial lines, handle several messages in one packet, enforce the state machine, answer unknown commands with an error.
- Day 3: world data in files: rooms with exits, items, NPCs. Commands
LOOK,MOVE,TAKE,DROP,INVENTORY,WHO,QUIT. - Day 4: social and game features: chat (global, room, group), groups,
TALK,ATTACK,STATUS, quests. Asynchronous events pushed to clients. - Day 5: a command line client and a graphical client, both strict about the protocol.
- Day 6: automated tests that open sockets and replay scripted sessions, structured logs, and a README documenting any deviation from the RFC.
S: WELCOME 42TAP/1.0
C: CONNECT neo
S: OK
C: LOOK
S: OK {"room": "lobby", "exits": ["north"], "players": ["neo"]}
C: MOVE west
S: ERR 301 no exit in that direction
The session above is illustrative; use the exact messages from the RFC.
Common pitfalls
- Assuming one
recvequals one message: TCP is a stream. - Race conditions on the shared world (two players taking the same item).
- A client that hangs because the server sent an event while it was waiting for a reply.
- Unknown or malformed commands crashing the connection instead of returning an error.
- Silent deviations from the RFC: document them or fix them.
- No automated tests, which students report as a weak point during evaluation.
How it is evaluated
- Peer evaluation of the team. The evaluator starts the server, connects with your clients and with raw
nc, and walks through the commands of the RFC. - Malformed input, very long lines, many simultaneous clients and abrupt disconnections are tried.
- Reported minimum content includes several rooms, NPCs, items, at least two kinds of quest, combat, chat, groups and a protocol log.
- Every member explains the part they did not write.