Cómo hicimos un juego de mesa con control remoto - Parte 2

La última vez que te conté sobre el componente técnico de nuestro juego de mesa "inteligente", qué problemas encontramos y qué sucedió al final.



Hoy quiero hablar con más detalle sobre la aplicación móvil, el primer juego y cómo crear miniaturas para él.

El primer artículo se puede encontrar aquí: Cómo hicimos un juego de mesa con control remoto - Parte 1

Atencion Muchas fotos en.

En los comentarios al último artículo, señalaron correctamente que es mejor no hacer un juego, sino una plataforma sobre la cual ya se pueden crear juegos utilizando la mecánica disponible. Inicialmente, lo planeamos, pero como resultado, nos dimos cuenta de que no podíamos hacer algo aparte del juego. Solo por la falta de experiencia en diseño de juegos o diseñadores de juegos familiares que podrían decirnos qué mecanismos deberían ser compatibles.

Por lo tanto, decidimos que implementaremos todas las funciones básicas de la plataforma (movimiento, resaltado dinámico, indicaciones) en nuestro primer juego, que nosotros mismos inventaremos. Y luego, utilizando la experiencia adquirida, haremos un diseñador de juegos completo.

Aplicación móvil

Como escribí anteriormente, toda la gestión de la plataforma se lleva a cabo a través de una aplicación móvil que se conecta a través del protocolo BLE.


De hecho, para implementar cualquier juego, debes escribir una aplicación móvil completa para él, en la que describas todas las reglas y la mecánica.

En el proceso de redacción de la aplicación, realizamos todas las pruebas conectándonos a la plataforma, lo que no es muy conveniente. Por lo tanto, para simplificar la depuración, creamos un emulador de software simple dentro del marco de la aplicación, en el que los datos se muestran de la misma manera que se mostrarían en el campo de juego.


Al principio, encontramos un problema de que los datos que abandonan la aplicación se pierden. Descubrimos que cuando se usa BLE, el tamaño máximo de paquete que se puede enviar es de 20 bytes. Por lo tanto, dividimos todos los datos salientes en BLE en paquetes de 20 bytes, el parámetro "Puerta" se escribe en el encabezado. Este parámetro ayuda a Arduino a comprender a qué componente de la plataforma pertenece este paquete. Desde el lado de Arduino, el procesamiento de estos paquetes es elemental:

if (NewCommandReady) { switch (CurrentGate) { case 1: processLEDCommand(); break; case 2: processDriverCommand(); break; case 3: processMagnetCommand(); case 4: // break; } //  NewCommandReady = false; } 

Después de dividir la transmisión de datos entre el teléfono inteligente y el módulo BLE en paquetes de 20 bytes, los datos dejaron de desaparecer, pero a menudo llegaron al Arduino en forma distorsionada. Resultó que no tomamos en cuenta que el puerto serie Arduino tiene un búfer de 64 bytes. Cuando el búfer se desborda, los datos se pierden y los siguientes se distorsionan. Aumentar el tamaño y crear su propio búfer no siempre ayudó. Tuve que escribir un protocolo contenedor encima del transporte BLE para enviar y recibir datos de manera confiable.

Debido al uso de dicho "protocolo", el intercambio de datos se ralentizó un poco al verificar la integridad de los datos transmitidos, sin embargo, la confiabilidad es más crítica para el juego: será una pena si la visualización de AOE de alguna habilidad está incompleta o si el héroe no se mueve al confirmar el movimiento en un teléfono móvil.

Para mostrar objetos en el campo de juego, utilizamos el principio de capas en los subsistemas de ventanas del sistema operativo:

• Cada objeto o acción que se resalta (héroes, obstáculos, la forma en que se mueve el héroe, el alcance disponible de la habilidad y el resto) usa su propia capa.
• Cuando se aplican capas (por ejemplo, la región AOE sobre el alcance disponible de la capacidad), se recuerda el estado inicial de los LED. Como resultado, es posible devolver el color original cuando la capa superior desaparece.

La mayor parte de los datos transferidos entre la aplicación móvil y la plataforma es el repintado de los LED. Para fines de optimización, se agregaron un par de algoritmos:

• Para volver a pintar diodos, se utiliza un búfer en el que se realizan cambios hasta el momento en que estos cambios deben mostrarse en la placa física.
• Repintar un solo LED dentro del mismo comando está excluido.
• Al volver a pintar (por ejemplo, el desplazamiento del área de capacidad AOE en 1 celda), se analiza el estado actual de la placa LED. Si el color del LED en el nuevo estado no difiere del anterior, el Arduino no recibirá ningún comando para volver a pintarlo.

Jugabilidad

Entonces, decidiste jugar. A continuación describiré cómo se ve desde un lado:

1. Insertamos el enchufe en la salida y encendemos el juego.
2. En cada inicio, se realiza una calibración automática para determinar el número exacto de pasos del motor paso a paso para mover 1 celda.
3. Paralelamente, conectamos el teléfono inteligente al juego mediante Bluetooth.
4. En la aplicación móvil, cada jugador selecciona el personaje que quiere jugar. Después de que todos hayan elegido, presione "INICIAR".
   
   
   
5. Cada uno de los personajes tiene su propio color. El juego resaltará automáticamente la celda donde debes colocar la figura de tu héroe.
6. El juego tiene lugar secuencialmente. El primer movimiento lo realiza el jugador que primero eligió al héroe, el segundo, el segundo, etc.
7. Cada héroe tiene un cierto número de Puntos de Acción (OD) que pueden gastarse en moverse por la arena o aplicar habilidades.
8. Cada habilidad tiene su propio tiempo de recuperación, que se calcula en rondas. Dentro del marco de la aplicación móvil, hay 2 conceptos: Mover: el intervalo desde el principio hasta el final de las acciones actuales del jugador. Ronda: la suma de los movimientos de todos los jugadores que participan en el juego. Actualmente, el turno de un jugador está limitado a 30 segundos.
9. Los obstáculos se colocan en el campo a través del cual el jugador no podrá pasar o usar la mayoría de las habilidades. Ahora simplemente se resaltan en rojo en el campo de juego, pero en el futuro tendrán una encarnación física.
   
   
   
10. Puedes mover el campo con la ayuda de habilidades especiales que tiene cada héroe. Por ejemplo, la teletransportación de un mago. A diferencia del movimiento estándar, cuando un jugador pavimenta la ruta de su héroe celda por celda, cuando usa estas habilidades, el jugador indica solo el punto final. Como resultado, existe la necesidad de un algoritmo para encontrar la ruta más corta a un punto específico, evitando todos los objetos con los que es posible la colisión (figuras de otros héroes, figuras de obstáculos, etc.).
    
    
    
    
    Este problema se resuelve simplemente con la ayuda de gráficos y el paso de BFS a través de las celdas.
    En resumen, la esencia del algoritmo es marcar las celdas por distancia, desde la posición actual del héroe hasta la celda especificada (indicada en naranja), a la que debe moverse el héroe.
    
    Después de encontrar la celda deseada, se busca la ruta de retorno en las celdas de tal manera que la distancia desde el punto de partida hasta la celda siguiente sea 1 menor que la celda actual (el pasaje está marcado en amarillo). Después de regresar a la posición inicial (celda verde), se forma una secuencia de puntos, que es el camino más corto. Es esta secuencia la que se transmite a Arduino como equipos para mover al héroe.
    
11. Después de la muerte del héroe, el juego mueve automáticamente su figura a la "zona de origen". Zona de inicio: una celda en la que se coloca la figura al comienzo del juego. Cada jugador tiene el suyo. Después de comenzar el juego, no puedes ingresar o usar la habilidad en la zona de inicio. Esto se hace para que sea imposible atrapar al jugador en el avivamiento. Para un jugador cuyo héroe es derrotado, el juego termina en 1 ronda. Después se reincorpora a la batalla.
    
    
    
12. En este momento, el jugador cuyo héroe fue el último en permanecer en el campo derrotando a los oponentes está ganando. Pero la condición puede ser diferente, por ejemplo, el que obtuvo N frags primero gana.

Esta es una jugabilidad que funciona en la versión actual. Debido a la falta de experiencia en el diseño de juegos, quizás no vemos escuelas u oportunidades obvias. Por ejemplo, siempre es doloroso esperar su próximo movimiento. En la implementación actual, el tiempo de espera puede llegar a 1,5 minutos. En la próxima versión del prototipo, planeamos agregar lectores de etiquetas RFID, lo que diversificará el juego. Por ejemplo, use tarjetas con etiquetas RFID que pueda aplicar fuera de su turno.

Miniaturas

¡Las miniaturas aman todo! Y no somos la excepción. Por lo tanto, en paralelo con la colección de mecánica y programación, nos dedicamos a inventar nuestras propias miniaturas. Creo que de las fotos está claro que nuestro juego es sobre gatos de fantasía que luchan en la arena.
Porque no sabemos cómo dibujar la palabra en absoluto, recurrimos a nuestro amigo, quien con gran placer comenzó a dibujar "gatos de pelea".

Ella tomó a nuestras mascotas como base. Entonces, en su casa vivía un gato enorme y vicioso apodado "Pirata", es él quien yace en el corazón del Guerrero en miniatura.

Después de un par de semanas, obtuvimos nuestros primeros bocetos.


De los artículos sobre la producción de juegos de mesa, me di cuenta de que en Rusia, la creación de miniaturas es bastante mala y muchas las ordenan en Finlandia o Alemania.

Antes de participar en la producción de miniaturas, necesitábamos hacer modelos maestros de cada héroe, que son suficientes para un prototipo. Al principio queríamos hacerlos con arcilla polimérica, pero resultó que entre nuestros amigos no había miniaturistas, y por encargo era demasiado caro en ese momento. Por lo tanto, decidimos que primero los imprimiríamos en una impresora 3D. Para hacer esto, nuestro amigo nos hizo modelos 3D de nuestros primeros héroes en Zbrush.


Con la ayuda de la impresión FDM, no fue posible imprimir figuras de calidad aceptable, lo cual era bastante esperado.

Afortunadamente, mi esposa tiene impresoras 3D SLA en el trabajo.

La estereolitografía (SLA) es una tecnología de impresión 3D que le permite convertir materiales líquidos en objetos sólidos utilizando una fuente de luz, capa por capa, utilizando el proceso de fotopolimerización. El grosor de la capa durante la impresión con tecnología SLA es varias veces menor que durante la impresión con FDM, por lo tanto, la calidad del producto terminado es mayor.

Pocos días después nos dieron nuestras primeras miniaturas.


La calidad de estas miniaturas es mucho mayor, pero aún no alcanza la producción obtenida por moldeo de plástico. La culpa de esto es el soporte, que después de la eliminación deja marcas notables. En teoría, podríamos "cortar" las figuras en partes separadas e imprimirlas individualmente, sin el uso de soportes, y luego pegarlas. Pero llevaría mucho tiempo y, además, aún podría cambiar en el futuro.

Cada figura se encuentra en su propia base, que también imprimimos en una impresora 3D. Dentro de la base hay un imán de neodimio. El tamaño y el grosor del imán se seleccionaron empíricamente para que la figura se magnetizara tranquilamente al electroimán en el carro de la plataforma, pero no reaccionó a las figuras vecinas.

Total

Por el momento, estamos comprometidos a mejorar las características físicas de la plataforma y la confiabilidad de todos los componentes. Reemplazaremos la madera contrachapada con policarbonato y plástico ABS, mejoraremos la fijación de los componentes de la plataforma entre sí y haremos que el campo de juego sea extraíble para que pueda cambiarse a un campo de otro factor de forma (por ejemplo, hexagonal). El siguiente paso es crear un MVP completo, lo cual no es una pena mostrarle a la gente.

Con el juego un poco más difícil. Por supuesto, quiero concentrarme completamente en la implementación de la plataforma, sin referencia a un juego específico. Sin embargo, somos conscientes de que nadie está interesado en una plataforma sin un juego.

Gracias a todos por sus críticas / consejos / intereses. Tuvimos una idea sobre la creación de una versión sin utilizar la mecánica, pero con la capacidad de determinar la posición y el tipo de la figura en el campo. Creo que el próximo artículo será escrito después de la creación de MVP .