Jouez en 2 contre 2 et 3 contre 3 : le mode équipe
Faites équipe avec un ami, mettez vos propriétés en commun et gagnez ensemble — opolyx propose désormais des parties en équipe 2×2 et 3×3.
En clair
Certaines parties sont meilleures avec un partenaire. Le mode équipe oppose deux camps — 2 contre 2 dans une partie à quatre joueurs ou 3 contre 3 dans une partie à six — pour que vos amis et vous jouiez pour une seule couleur, et pas seulement chacun pour soi.
Être dans le même camp change tout dans votre façon de jouer ensemble. Vos coéquipiers sont des alliés, pas des rivaux, et le plateau s’ouvre :
- Si vous tombez sur la propriété d’un coéquipier, vous ne payez rien — le loyer n’est jamais facturé qu’à l’équipe adverse.
- Échangez librement argent et propriétés entre coéquipiers — il n’y a pas de règle des 50 %, vous pouvez donc offrir purement et simplement à un partenaire en difficulté ce dont il a besoin.
- Si un coéquipier fait faillite, tout son patrimoine vous revient, et non à la banque — une équipe n’est éliminée que lorsque tous ses membres ont disparu.
- Vous gagnez en équipe : le dernier camp debout, ou le camp le plus riche lorsque la limite de tours est atteinte — et les deux coéquipiers reçoivent la récompense de victoire (XP et une carte).
Coordonnez vos échanges, couvrez-vous mutuellement et chassez ensemble l’équipe adverse du plateau. C’est le même opolyx que vous connaissez — avec un partenaire à vos côtés.
Pour les curieux techniques
Le mode équipe reprend le jeu de règles Classic avec un seul nouveau concept par joueur : l’équipe. Le moteur ajoute un champ PlayerState.team et une poignée de sélecteurs (sameTeam, teamOf, aliveTeams, teamNetWorth) que les règles lisent : computeRent exempte les coéquipiers, doProposeTrade saute la règle des 50 % entre eux, et l’élimination dirige le patrimoine vers le coéquipier vivant ayant le plus petit emplacement plutôt que vers la banque. Les conditions de fin sont évaluées par équipe — la dernière équipe debout, ou l’équipe la plus riche au plafond de tours.
Trois migrations l’implémentent. Postgres interdit d’utiliser une nouvelle valeur d’enum dans la transaction même qui l’ajoute, donc 0028 valide à elle seule le game_mode de l’équipe ; ensuite 0029 permet à create_game de l’accepter (avec une vérification d’effectif complet et équilibré) et ajoute award_game_winners pour la récompense à plusieurs gagnants ; et 0030 ajoute la colonne team sélectionnable et son RPC de salle d’attente.
-- 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 $$ ... $$;Aucun changement de l’enum event_kind n’a été nécessaire — les données d’équipe voyagent dans des champs de payload facultatifs sur des événements existants (game_started.players[].team, player_eliminated.inheritedBySlot, game_finished.winnerTeam). Les équipes choisies (et non la parité) sont injectées dans initializeGame ; le daemon refuse de démarrer une partie en équipe dont l’effectif n’est pas complet (team_roster_not_full) ou n’est pas équilibré (team_not_balanced). Les tests Engine 214 / daemon 82 sont au vert, et la propriété de terminaison de fast-check mène désormais les parties 2×2 et 3×3 jusqu’à leur conclusion.