2 gegen 2 und 3 gegen 3: der Team-Modus
Tu dich mit einem Freund zusammen, legt eure Grundstücke zusammen und gewinnt gemeinsam – opolyx hat jetzt Team-Partien zu zweit und zu dritt pro Seite.
Kurz gesagt
Manche Partien sind mit Partner besser. Der Team-Modus lässt zwei Seiten gegeneinander antreten – zwei gegen zwei in einer Partie zu viert oder drei gegen drei in einer zu sechst –, sodass du und deine Freunde für eine Farbe spielt und nicht nur für euch selbst.
Auf derselben Seite zu stehen ändert alles daran, wie ihr zusammen spielt. Deine Teamkameraden sind Verbündete, keine Rivalen, und das Brett öffnet sich:
- Landest du auf dem Grundstück eines Teamkameraden, zahlst du nichts – Miete wird immer nur dem anderen Team berechnet.
- Reicht Bargeld und Grundstücke frei zwischen Teamkameraden weiter – es gibt keine 50-%-Regel, du kannst einem schwächelnden Partner also einfach schenken, was er braucht.
- Geht ein Teamkamerad bankrott, fällt sein gesamter Besitz an dich und nicht an die Bank – ein Team ist erst raus, wenn jedes Mitglied weg ist.
- Ihr gewinnt als Team: die letzte verbliebene Seite oder die reichste Seite beim Erreichen der Rundenobergrenze – und beide Teamkameraden bekommen die Siegprämie (XP und eine Karte).
| Zwischen Teamkameraden | Teamregel |
|---|---|
| Miete | Auf dem Grundstück eines Teamkameraden zahlst du nichts |
| Handel | Freie Übertragung – keine 50-%-Regel |
| Bankrott | Der Besitz geht an deinen Teamkameraden, nicht an die Bank |
| Sieg | Die letzte verbliebene Seite; beide bekommen die Prämie |
Stimmt eure Handel ab, deckt euch gegenseitig und drängt das gegnerische Team gemeinsam vom Brett. Es ist dasselbe opolyx, das du kennst – mit einem Partner an deiner Seite.
Für technisch Neugierige
Der Team-Modus ist das Classic-Regelwerk mit einem neuen Begriff pro Spieler: einem Team. Die Engine bekommt ein Feld PlayerState.team und eine Handvoll Selektoren (sameTeam, teamOf, aliveTeams, teamNetWorth), die die Regeln lesen: computeRent nimmt Teamkameraden aus, doProposeTrade überspringt zwischen ihnen die 50-%-Regel, und beim Ausscheiden geht der Besitz an den lebenden Teamkameraden mit dem niedrigsten Platz statt an die Bank. Die Endbedingungen werden pro Team ausgewertet – letztes verbliebenes Team oder reichstes Team bei Erreichen der Rundenobergrenze.
Drei Migrationen bringen das an Land. Postgres verbietet es, einen neuen Enum-Wert in derselben Transaktion zu benutzen, die ihn hinzufügt – 0028 committet den Modus team also für sich allein; 0029 lässt create_game ihn dann zu (mit einer Prüfung auf vollständige und gleich starke Besetzung) und ergänzt award_game_winners für die Belohnung mehrerer Sieger; 0030 fügt die wählbare Spalte team und ihre Lobby-RPC hinzu.
-- 0028_team_mode_enum.sql — its own migration (see above)
alter type game_mode add value 'team';
-- 0030_team_picker.sql — pickable side; NULL = slot-parity default (slot % 2)
alter table game_players
add column team smallint check (team is null or team in (0, 1));
-- SECURITY DEFINER lobby write (RLS has no user write on game_players):
-- a player sets their own seat; the creator may set any seat (to arrange bots).
create function set_player_team(p_game uuid, p_slot int, p_team smallint)
returns void language plpgsql security definer as $$ ... $$;Eine Änderung am Enum event_kind war nicht nötig – Teamdaten reisen in optionalen Nutzdatenfeldern bestehender Ereignisse mit (game_started.players[].team, player_eliminated.inheritedBySlot, game_finished.winnerTeam). Gewählte Teams (nicht die Platzparität) werden an initializeGame durchgereicht; der Daemon verweigert den Start einer Team-Partie, deren Besetzung nicht voll (team_roster_not_full) oder nicht ausgeglichen (team_not_balanced) ist. Engine 214 / Daemon 82 Tests grün, und die fast-check-Terminierungseigenschaft treibt jetzt auch Partien zu zweit und zu dritt pro Seite bis zum Ende.