Local Multiplayer Party Game with Full Controller Support

The problem: local multiplayer breaks beginner code

Couch multiplayer looks simple and is not. Four controllers must be assigned to four players, a keyboard must be split between two, a controller that disconnects mid-round must come back to the same slot, and a rematch must start clean without reloading the game. Beginner projects usually hard-code keys and scatter match state across scripts, so the second round starts with the first round's scores still in memory.

These are exactly the areas where gameplay programmers are tested, and they are also the areas most student games avoid by being single player. Party games also give fast, honest feedback: four friends on a sofa will tell you in ten minutes whether a round is fun.

What already exists and the gap

• Jackbox Party Pack runs party games on a shared screen with phones as controllers, focused on trivia and drawing.
• AirConsole turns a browser or smart TV into a console with smartphones as gamepads and hosts a catalogue of third-party games.
• Unity's PlayerInputManager and the community MultiplayerInput addon for Godot solve part of device assignment, and Godot's own proposals discussion shows local multiplayer input is still an open topic in the engine.

The commercial products are platforms for finished games, not something you learn from, and the engine helpers leave the hard parts (rejoining, rebinding per player, clean match flow) to you. The gap for an FYP is a small, polished party game whose input and state architecture you can explain completely.

What you build

A two to four player party game on one screen with at least three short rounds.

• Players: join by pressing a button on any device, pick a colour and character, play rounds, see results and rematch.
• Host player: controls settings, round order and whether bots fill empty slots.

Main flows: join, play a sequence of rounds with a running score, handle a disconnect, show final results, rematch without reloading.

The technically interesting part

The interesting work is the architecture under the fun.

1. Input as actions, not keys. Define actions once (move, jump, action, pause), then create one binding set per player at runtime from whichever device joined. Rebinding writes per-player overrides to disk.
2. Device lifecycle. Keep a table of player slot to device id. When a controller disconnects, pause, show which player lost control, and let any unassigned device claim that slot.
3. Match flow as an explicit state machine. Every screen is a state with enter and exit functions that own their data. A rematch is just a transition back to round intro, which proves no state leaks.
4. Shared camera framing. Compute the bounding box of all players each frame, smooth it, and clamp zoom so nobody leaves the screen.

Show your supervisor the state diagram, the device table live on screen in a debug overlay, and a rematch after a disconnect.

How to evaluate it

• Group playtests: at least three sessions of four players, one of them including people who have never played. Record where they got confused and what you changed.
• Input reliability: a scripted test plan of 20 cases (join, leave, swap, disconnect, reconnect, rebind) run on the final build, all passing.
• Readability: ask players at sofa distance to read the score and round instructions; fix anything they cannot.
• Performance: stable frame rate with four players and the busiest round, measured on a mid-range laptop.

Suggested plan

1. Weeks 1 to 2: design three rounds that share components; build the join screen first.
2. Weeks 3 to 5: input system, device table, match state machine, first round.
3. Weeks 6 to 9: rounds two and three, shared camera, results screen.
4. Weeks 10 to 11: settings, rebinding, disconnect handling, accessibility options.
5. Weeks 12 to 15: three group playtests, balance changes, builds, report.

Path to a product

Party games sell on Steam and itch.io, and a small polished one can build a following through local events and university gaming societies. Enter a public jam or showcase to gather wishlists before a paid release. Even without sales, a finished multiplayer game with clean input code is a strong portfolio piece for gameplay roles at studios in Lahore, Karachi or anywhere else.

Scope warning

Do not build online multiplayer, matchmaking or accounts in the core scope. Do not make more than three rounds until those three are fun. Avoid custom art pipelines; free assets are fine.

Learn what you need on Sefism

• Game Programming Patterns : the State and Command patterns are the backbone of match flow and input.
• Godot Engine Documentation : InputMap and device ids if you use Godot.
• Unity Manual and Scripting API : the Input System package and PlayerInputManager if you use Unity.
• Game Maker's Toolkit : design videos on game feel and readable multiplayer.
• Programming roadmap : the fundamentals that make state machines and clean code easy.
• How to build a developer portfolio as a beginner : how to present a finished game to employers.

Get help with this idea

The risk here is building five half-finished mini-games. Tauseef can help you pick three that share components, plan the input and state architecture early, and design group playtests that give you evidence for the report. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session