Before choosing a technical approach, describe the actual experience. Do players share one screen, take turns remotely, or interact in real time? Is the session private, public, cooperative, or competitive? Each choice changes the systems and support needed.
Walk through one complete session
Follow a player from finding or creating a session to joining, playing, leaving, and reconnecting. Decide what happens when the host disappears or a player stops responding. If accounts, chat, invitations, moderation, or stored progress are needed, include them explicitly rather than treat them as incidental details.
A network test should include imperfect conditions. A smooth session on one local network is useful development evidence, but it does not prove the experience works across ordinary player connections. The developer needs a defined test plan and a way to investigate problems without collecting unnecessary personal information.
For an early idea, consider whether a local or turn-based test can answer the main design question first. That is a scope decision, not a claim that one approach is always better. If real-time multiplayer is central, prototype that risk early. A clear multiplayer brief helps the team estimate and test the actual experience instead of assuming it is a small feature added after the rest of the game is complete.