The Steam store page lists Machine Party as an online co-op game for two to four players. That is the reliable starting point for a multiplayer guide. It tells a group the supported party range and the broad online scope, but it does not publish a complete menu path, public matchmaking specification, room-code rule, local split-screen promise, cross-play policy, or voice-chat policy. Use this page to prepare and test a lobby without presenting an unverified community observation as a permanent feature.
Confirm what “online co-op” means here
Steam’s Online Co-op category is a product-level signal for online cooperative play. Machine Party’s own description adds the two-to-four-player range and places friends inside dangerous party-game situations. Together, those sources justify saying that the base game is designed for online sessions with two to four participants. They do not answer whether every round is cooperative, whether the final result is competitive, or whether the host must own a particular item or unlock.
Start a lobby test by writing down the exact Steam product and the party size. If you see an invite, create-room, quick-join, or public/private option, record its label and current date. Do not rename an option in a guide just because a similar game uses a familiar term. Menu labels are part of the evidence, especially for a new release whose interface may change.
Use a two-player smoke test
Two players are the safest first test because the Store page lists two as the minimum. Have both players launch AppID 4108000 and verify that they are on the same broad release branch. Then test one ordinary action at a time: open the multiplayer entry, invite the second player if the interface offers an invite, wait for the second player to appear, and observe the ready/start state. If the game uses another sequence, write that sequence down rather than forcing it into this outline.
The purpose of a smoke test is to identify whether the group can reach an activity, not to prove every network configuration. Record whether the player list updates, whether a ready indicator appears, and what the game says when the host starts. If the session fails, save the exact message and platform. “It did not work” is not enough to distinguish an invite failure, a platform mismatch, a full room, a service interruption, or a version mismatch.
After the two-player test works, add a third player and then a fourth. The official upper boundary is four, so a fifth participant should not be treated as a missing troubleshooting step. A guide can say that the Store page lists four as the maximum public party size; it cannot claim that the game silently blocks a fifth person in every menu until that behavior is observed.
Keep lobby roles explicit
The host may see controls that joining players do not. Avoid telling every participant to change the same setting until you know which screen owns it. Ask one player to read the lobby heading, one to watch the roster, and one to verify the action that begins the activity. This small division makes screenshots and later bug reports easier to interpret.
If one participant drops, note whether the current activity pauses, ends, replaces the player, or continues. That behavior is a separate intent from the initial invite flow. It should only become a published rule after a reproducible test with the same activity and a clear version scope. A result from one mini game does not necessarily describe all modes in the collection.
The Modes hub explains why each activity needs its own evidence card. The Support hub is the correct destination for OS, controller, Vulkan, or performance questions. Keeping those boundaries prevents a network symptom from being misreported as a mode rule.
Private, public, and room-code claims
Players naturally search for private lobbies, public rooms, invites, and codes. At the time of this audit, the official Steam page confirms online co-op but does not document the exact room model. A current community discussion mentions room behavior and a third-party MachineParty+ project, but a mod page is not official base-game documentation. Do not claim that a particular number of digits, a public browser, text chat, voice chat, or a mod feature belongs to the unmodified base game unless the game itself or the developer states it.
When testing a private session, capture the entire label around the room control and note whether the invite is a Steam invite, a generated identifier, or a direct menu action. If a string is required, do not call it a redemption code. A room identifier has a different purpose and should be documented under Lobby only when its current behavior is confirmed.
The same rule applies to public matchmaking. Seeing another player in a session does not prove that the game has an open browser or automatic matchmaking. Record how the player arrived and whether the host chose public access. If the developer later publishes a support article, use that first-party scope instead of a generic guide to another co-op game.
Do not assume local play or cross-play
The phrase “party game” often leads players to ask about one-PC multiplayer. The exact Store page does not establish local split-screen, shared-keyboard support, Remote Play Together, or controller count. Keep those as unanswered questions until the current game screen or official documentation answers them. A third-party suggestion for a workaround is not a native feature.
Cross-play and cross-save are also separate. Steam’s listing and the checked official publisher page do not announce an additional platform service for this product. Do not transfer a cross-platform feature from another Oro Interactive title or from a community mod. If a future update adds it, attach the claim to the dated announcement and explain which platforms are actually included.
A useful invite checklist
- Confirm everyone owns and launches the base Machine Party product, AppID 4108000.
- Choose two players for the first smoke test, because two is the official minimum.
- Open the multiplayer entry and copy the exact menu label into the test note.
- Invite or join through the visible in-game/Steam action; do not infer a hidden room-code route.
- Confirm that both names appear in the roster and identify the start/ready control.
- Start one activity and record the result, party size, platform, and date.
- Add a third and fourth player only after the smaller session is understood.
- If a player cannot join, save the exact error and test whether it follows that player, host, platform, or activity.
What to report to this hub
A high-quality lobby report includes the public version label if the game provides one, otherwise the date; the default branch or test branch; Windows or Linux/SteamOS; controller or keyboard; party size; host/join order; menu labels; and the exact result. Do not include account names or private invite tokens. If a screenshot includes a room identifier, redact it before publishing.
This hub can safely explain the official two-to-four-player boundary and an evidence collection method. It cannot yet promise a universal matchmaking path, local co-op, cross-play, cross-save, voice/text chat, or specific disconnect recovery. Those limits are not a failure of the guide; they are important scope information for a game with a new public documentation footprint.
Lobby summary
- Officially documented: online co-op, two to four players, base AppID 4108000.
- Needs live verification: menu path, invite sequence, public/private options, room identifiers, drop-in behavior, and activity-specific rules.
- Not claimed: local split-screen, cross-play, cross-save, native voice/text chat, or a mod feature in the base game.
- Best evidence: exact current menu text, a reproducible session, platform and date, and a source link.
Check Updates after an official multiplayer announcement. Until then, use the smallest reproducible test, keep the party size inside the Store boundary, and treat every extra lobby feature as a question rather than a fact.