Tinselcity

Análisis de Espías y Confidentes

Tomo como base el juego que tengo delante. Para quienes no lo tenéis, esta descripción, con sus fotos y demás, debería ser suficiente. La descripción intenta describir las instrucciones de forma imparcial, anotando algún detalle aquí o allá, que surge de la experiencia de haber jugado. Si se prefiere, también están al final las instrucciones originales en PDF, de modo que se pueden leer esas directamente.

Elementos generales del juego

Hay toda una serie de elementos que podemos identificar fácilmente porque son elementos que aparecen en la mayoría de juegos de mesa y eso facilita mucho la labor.

Tenemos así:

  • Jugadores. Un número variable entre 2 y 6 (idealmente 6). Cada jugador tiene una ficha espía, una agenda de claves y también una ficha confidente y una clave.
  • Hay un tablero. En nuestro caso el mapa de Europa, aunque lo que realmente importa es el mapa de ciudades y pueblos y sus conexiones.
  • Hay un turno, que indica qué jugador está moviendo. Pero además hay un concepto de ronda, porque cada vez que el turno da una vuelta por todos los jugadores, hay que realizar el movimiento de confidentes. El turno además tiene unas ciertas reglas sobre cómo se realiza.
  • Hay tarjetas, de varios tipos.
    • Hay tarjetas de órdenes del servicio secreto.
    • Hay tarjetas de viaje, pasajes de barco y de avión. Estas llevan la implicación de que hay ciertas ciudades especiales (que tienen puerto o aeropuerto).
  • Hay unos dados (dos).

Mucho de esto surge directamente de la tabla de componentes del juego que nos dan las propias instrucciones. Identificar todas esas cosas es relativamente sencillo. Hay un par de detalles que no se mencionan ahí pero que deberían ser familiares para cualquiera que haya jugado a juegos de este tipo: el turno y la ronda. No siempre existen ambos. La idea de ronda (el concepto de que ocurra algo cuando todos los jugadores han jugado un turno) en muchos juegos resulta irrelevante, y solo importa en el aspecto de que indica el orden que sigue el turno. Pero en otros muchos existe.

En cualquier caso, identificar estas dos cosas, turno y ronda, es algo que surge tanto de la experiencia en el dominio del problema como la experiencia en el desarrollo. Es decir, que nos ayuda a poder identificar los elementos relevantes tanto el tener experiencia en programación, como tenerla en el tipo de problemas que estemos tratando. Por suerte, si no tenemos experiencia en programar y diseñar sistemas, la podemos conseguir a base de practicar. Y si no tenemos experiencia en el dominio del problema, tenemos dos opciones: Podemos estudiar ese dominio o podemos consultar con alguien que sí la tenga (un experto de dominio).

Detalles: El mapa

Ya avanzaba en la primera impresión que en el tablero habría diferentes cosas. No las he destacado arriba porque son detalles más específicos y queremos empezar siempre con una visión general, amplia.

Ciudades y pueblos En el tablero hay lo que las instrucciones llaman ciudades y pueblos. Que nadie se ofenda si llaman “pueblo” a su “ciudad”; en realidad no hay una correspondencia totalmente directa con la realidad: son solo dos formas de distinguir dos tipos de casilla. Las instrucciones hacen referencia a ello en varios puntos. En el tablero podemos distinguirlas con facilidad.

Los pueblos no tienen más variedad, pero en cuanto a las ciudades, podemos ver que tienen un cierto color y número. Además, algunas ciudades pueden tener aeropuerto o puerto, que se indican con los iconos del avión y el barco, respectivamente. Por último, ciertas ciudades, una de cada color, está marcada especialmente con un círculo y un dibujo de un espía de ese color. Estas son las ciudades de partida de cada espía. Según vemos en las instrucciones tienen relevancia porque cada espía empieza la partida ahí y porque algunas tarjetas de órdenes del servicio secreto indican que se debe acudir “a su ciudad de partida”. Por último, está la ciudad de Ginebra.

En el mapa, ciudades y pueblos están conectados y las fichas se pueden mover entre casillas conectadas. Esto del movimiento entre casillas parece que será un elemento a resolver en algún momento. En el juego de mesa en vivo, con los jugadores presentes, son ellos mismos quienes controlan que no se hacen trampas y los movimientos son válidos. Pero al cambiar la situación, parece que será algo que tendremos que considerar de alguna forma.

Además, volviendo al tema ese de los números y colores que tienen las ciudades, vemos que lo que hay realmente son 6 rutas. Estas se explican también en las instrucciones y son el movimiento que realizan las fichas confidentes al final de cada ronda. Es otro elemento más del tablero que, seguramente, tenga algún tipo de representación en nuestro programa.

Detalles: Claves y agendas

Si miramos con más detalle el tema de las claves y de las agendas, vemos algunas cosas más:

  • Que yo tengo cierta tendencia a usar “clave” de forma algo confusa, porque las propias instrucciones a veces también las llaman de forma confusa. Hay dos cosas diferentes:
    • Hay 6 claves, estas sí, claves. Son las claves que debemos encontrar como objetivo del juego.
    • Hay 6 sobres de pistas, que las instrucciones llaman “sobres de tarjetas microfilm”. Cada sobre contiene 8 pistas.
  • En realidad, en el tema de gestionar las pistas de su clave, el jugador interviene bastante poco o nada. Es decir, hay unas reglas estrictas sobre cómo se entregan estas pistas y no hay decisión por parte del jugador. No podemos dar la pista que queramos. ¿Por qué anoto esta idea? Porque lo que significa es que, con casi total seguridad, esto sea algo que podremos o deberemos automatizar en gran medida, como ya hemos visto antes que ocurre con la validación de los movimientos en el tablero.
  • La “agenda”, donde cada jugador va anotando las pistas para encontrar todas las claves, se rellenan de dos modos: Al recibir una pista, esta la escribimos en la agenda, pero también en cualquier momento podemos hacer deducciones, basándonos en todas las claves y pistas que tenemos y anotar lo que queramos. Así que tendremos que contemplar estas dos ideas.

Puede parecer evidente, pero también anoto que todos los jugadores ven el tablero pero solo cada jugador ve su propia agenda. Sí, parece muy evidente, pero es una idea relevante porque implica que hay unos elementos compartidos entre todos los jugadores y otros a los que solo tiene acceso cada jugador. Esto tendrá algunas implicaciones, por ejemplo en el interfaz del usuario o en las comunicaciones que se realicen. Es interesante anotarlo y tenerlo en cuenta.

Detalles: Turno, Ronda, Confidentes...

Si pienso un poco más en todo esto, veo que hay muchos elementos del juego que originalmente manejan los jugadores pero que en realidad son temas mecánicos que será bueno automatizar. Es decir, que hay muchos elementos de los que nos podemos encargar de forma automática.

Llevar la gestión del turno es bastante evidente. Pero también todo el movimiento de los confidentes al final de cada ronda, que jugando en vivo requiere que sean los jugadores los que los muevan, parece muy razonable que se realice de forma automática. Lo mismo ocurre, como ya decía antes, con la gestión de los sobres de pistas.

Otra cosa evidentemente automatizable son los dados. No ya solo por cuestiones como las anteriores de que sea mecánico, sino por evitar las trampas que podrían ocurrir si dejáramos que fuera el jugador quien dijera qué tirada ha sacado, claro.

Algunas ideas más

Como ideas adicionales que me surgen, anoto estas:

  • El tema del movimiento. Hay que mover siempre lo que digan los dados. No se puede mover menos y no se puede mover adelante y atrás entre dos ciudades o pueblos. Recuerdo de cuando jugaba que, a veces, resultaba imposible llegar a la ciudad que querías aunque estuvieras cerca porque te sobraban puntos. Algunas veces podías “dar un rodeo” y terminar cayendo donde querías, pero esto no siempre era posible. Por eso, algunas veces, mis hermanos y yo perdíamos ahí un buen rato intentando llegar antes de darnos por vencidos. Sería bueno que el juego de alguna forma pudiera calcular todos los movimientos válidos que puedes hacer. Más que nada porque va a tener que validar el movimiento para comprobar que se puede realizar, así que resultará más cómodo si directamente le damos la opción al jugador de solo poder realizar movimientos válidos. Esto lo anoto y además añado una anotación sobre la dificultad que esto puede llegar a tener. No muchísima dificultad pero sí que habrá que pensar alguna forma eficiente de hacerlo.
  • Hay un tema de la finalización de la partida que se podría considerar variar. En el juego original, al llegar a Ginebra un jugador y dar sus claves, el resto de jugadores van confirmando si son correctas, para validar si ha ganado o no. Aquí hay dos detalles a tener en cuenta. No tomo ninguna decisión ahora, simplemente lo anoto como cosas que convendrá tener en cuenta.
    • Las instrucciones originales explican que el jugador muestra todas sus claves y sugiere que todas se validan y todas se comprueban. Así, en cuanto un jugador va a Ginebra e intenta adivinar, todas las claves quedan al descubierto y el juego se vuelve solo una carrera por llegar otro jugador a Ginebra. Una alternativa a esto es hacer una pequeña variación: El jugador muestra sus claves una a una y se comprueban una a una. En cuanto una clave no es correcta: a. solo al jugador que intentaba ganar (y que queda eliminado) se le muestra la clave real, y b. ya no se comprueban más claves. Esta variación es algo que adoptamos casi desde el principio cuando yo era pequeño, porque prolonga el interés de la partida un rato más y además evita algún comportamiento tonto en el que un jugador va directamente a Ginebra, dice cualquier cosa inventada y obliga a mostrar todas las claves.
    • Además, dado que estamos automatizando la gestión de pistas, probablemente tendrá más sentido que la comprobación del intento de ganar sea también automática. Esto hace que ya no tenga necesidad de ser pública a la vista de todos. Habría que considerar, eso sí, si se hacen públicas las claves acertadas hasta el primer fallo o no. Hacerlo sería el comportamiento más cercano al original. No hacerlo prolongaría el tiempo de juego de cada partida.
  • Anoto también que hay bastantes reglas relacionadas con la ejecución del turno. Si es posible, hay que elegir barco o avión primero. Si no, entonces se tiran los dados. Pero antes de todo eso, si un confidente se movió a la ciudad donde estabas, ni haces ni lo uno ni lo otro sino que contactas. Si contactas, entonces hay que coger una tarjeta y seguir las instrucciones. Esto implicará otro movimiento pero con condiciones especiales (sin dados, sin contactos, o con las instrucciones especiales de la tarjeta)… En fin, habrá que contemplar todo esto y codificarlo de alguna forma para que sea correcto.

Y así en un primer análisis, esto es todo.


Discusión

Escribe el comentario. Se permite la sintaxis wiki: