Juegue 2 vs 2 y 3 vs 3: modo Equipos
Forme equipo con un amigo, pongan en común sus propiedades y ganen juntos: opolyx ya tiene partidas por equipos de 2×2 y 3×3.
En palabras sencillas
Algunas partidas son mejores con un compañero. El modo Equipos enfrenta a dos bandos — 2 vs 2 en una partida de cuatro jugadores o 3 vs 3 en una de seis — para que usted y sus amigos jueguen por un color, no solo por ustedes mismos.
Estar en el mismo bando lo cambia todo en la forma de jugar juntos. Sus compañeros son aliados, no rivales, así que el tablero se abre:
- Si cae en la propiedad de un compañero, no paga nada: el alquiler solo se cobra al otro equipo.
- Los compañeros pueden pasarse dinero y propiedades sin restricciones: no hay regla del 50%, así que puede regalar sin más a un compañero en apuros lo que necesite.
- Si un compañero se arruina, todo su patrimonio pasa a un compañero de equipo, no al banco: un equipo solo queda fuera cuando todos sus miembros han caído.
- Ganan como equipo: el último bando en pie, o el bando más rico cuando se alcanza el límite de rondas, y todos los miembros del equipo reciben la recompensa de victoria (XP y una carta).
| Entre compañeros | Regla de equipo |
|---|---|
| Alquiler | No paga nada en la propiedad de un compañero |
| Intercambios | Transferencias libres — sin regla del 50% |
| Bancarrota | El patrimonio pasa a su compañero, no al banco |
| Victoria | El último bando en pie; todo el equipo recibe la recompensa |
Coordinen sus intercambios, cúbranse las espaldas y saquen juntos al equipo rival del tablero. Es el mismo opolyx que ya conoce, pero con un compañero de su lado.
Para los más técnicos
El modo Equipos es el conjunto de reglas de la Clásica con un nuevo concepto por jugador: el equipo. El motor añade un campo PlayerState.team y un puñado de selectores (sameTeam, teamOf, aliveTeams, teamNetWorth) que leen las reglas: computeRent exime a los compañeros de equipo, doProposeTrade omite la regla del 50% entre ellos y la eliminación envía el patrimonio al compañero vivo con el número de asiento más bajo en lugar de al banco. Las condiciones de fin se evalúan por equipo: el último equipo en pie, o el equipo más rico al llegar al tope de rondas.
Lo implementan tres migraciones. Postgres prohíbe usar un nuevo valor de enum en la misma transacción que lo añade, así que 0028 confirma por sí sola el valor team de game_mode; luego 0029 permite que create_game lo acepte (con una comprobación de plantilla completa y equilibrada) y añade award_game_winners para la recompensa de varios ganadores; y 0030 añade la columna team seleccionable y su RPC de sala de espera.
-- 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 $$ ... $$;No hizo falta cambiar el enum de event_kind: los datos de equipo viajan en campos opcionales de payload sobre eventos ya existentes (game_started.players[].team, player_eliminated.inheritedBySlot, game_finished.winnerTeam). Los equipos elegidos (no la paridad) se enhebran en initializeGame; el daemon se niega a iniciar una partida por equipos cuya plantilla no esté completa (team_roster_not_full) o no esté equilibrada (team_not_balanced). Las pruebas de Engine 214 / daemon 82 en verde, y la propiedad de terminación de fast-check ahora lleva partidas 2×2 y 3×3 hasta el final.