Lo resolvemos con nuestro líder tecnológico
Para el proyecto educativo del Banco de Rusia, hemos realizado un llamativo juego web "El misterio de la hucha perdida" . Ella llama la atención de los escolares sobre el tema de la educación financiera, presenta los términos y les enseña cómo administrar sabiamente el dinero. El juego no solo gustó a los niños, sino también a los adultos de diferentes ciudades de Rusia: fue jugado por más de 30,000 personas.
Hemos estado pidiendo a nuestro líder tecnológico durante mucho tiempo que nos cuente sobre el desarrollo del juego web. No solo contó, sino que también escribió un artículo apasionante sobre nuestra experiencia en este proyecto, sobre las dificultades encontradas y también compartió los trucos de la vida en el desarrollo de juegos de navegador. El resultado es un material lleno de utilidad. Sigue leyendo.
Un juego web es fundamentalmente diferente tanto de un juego de computadora normal como de un sitio web normal en un navegador. En un juego normal, todos los recursos del juego están disponibles sin conexión, el motor del juego conoce información sobre el procesador, la memoria y la tarjeta de video de la computadora. Un sitio normal requiere pocos recursos informáticos y, en caso de problemas, simplemente puede volver a cargar la página.
Teníamos suposiciones sobre las características de un juego de navegador: restricciones significativas en el tamaño de RAM disponible y usado (por ejemplo, en el TOR se indica que 1 GB de RAM debería ser suficiente para dispositivos móviles), el equilibrio entre la calidad de los recursos del juego (imágenes, texturas, sprites, sonidos, videos) y su velocidad de descarga.
A esto se agregaron los requisitos del cliente: el juego debe ejecutarse y funcionar en todos los navegadores de escritorio y móviles declarados (incluido IE 11), con las especificaciones de hardware más bajas posibles. Estos requisitos se basaban en el hecho de que se suponía que el juego debía mostrarse en cualquier oportunidad conveniente, en cualquier dispositivo que tuviera a mano, por ejemplo, en la escuela.
Cómo se eligió el motor
Ya teníamos experiencia en el desarrollo de juegos, por lo que las instrucciones para elegir un motor se indicaron inmediatamente:
- Phaser — /.
- Unity Web — .
- LibGDX, Godot, PlayCanvas.
Las opciones desconocidas cayeron por una razón obvia: había que dominarlas y estudiarlas, lo que, de alguna manera, asustó, aunque no parecía imposible. La opción Unity se cayó porque el motor y las restricciones de exportación no permitían, por ejemplo, usar audio en IE 11. Y también porque el Javascript exportado desde Unity era muy grande, e IE 11 es mucho más lento en el análisis y ejecución de código que los modernos. navegadores.
Por lo tanto, se decidió tomar una versión nueva del motor Phaser (en el momento del desarrollo, era la versión Phaser 3.11). Elegimos este motor también porque toda la lógica y el renderizado son software, lo que significa que podríamos controlar absolutamente cualquier aspecto del futuro juego en el código.
Como escribieron
Al principio, no teníamos ninguna mecánica elaborada, pero sabíamos que definitivamente sería un juego de plataformas. Por ello, decidimos armar al menos algún prototipo para refrescar nuestro conocimiento del motor, así como para realizar mediciones aproximadas de los recursos consumidos y la carga en el navegador.
Tomamos de los ejemplos “movimiento del personaje” y “mapa de mosaicos” listos en la documentación, ensamblados, lanzados - funciona: el personaje camina, salta, se mueve en plataformas. Lanzado en todos los dispositivos disponibles, todavía funciona. Se agregaron botones de control virtual de los "botones virtuales" de ejemplo y se lanzaron en el móvil; todavía funciona. Se agregó una pequeña mecánica: golpear, enemigo, infligir y recibir daño, recolectar monedas, fue suficiente para el prototipo.
En el prototipo, había incluso un poco más de lo necesario. Por ejemplo, se implementó la mecánica de controlar dos personajes, entre los cuales se podía cambiar en cualquier momento.
Después de un prototipo exitoso, comprendimos cómo se implementaría la arquitectura y cómo se organizaría el código. Si hablamos de la parte de infraestructura, entonces esto es trabajar con el motor en términos de carga de recursos, creación de objetos de juego, cambio de pantallas. En cuanto a la lógica del juego en sí, esta es la implementación de personajes, la implementación de mecánicas de interacción con botín, trampas, enemigos.
La pila de desarrollo se tomó bastante típica para un proyecto similar: webpack, webpack-dev-server, babel, babel / preset-typescript.
Que dificultades fueron
Se encontraron dificultades para cumplir con los requisitos de desempeño y en la comunicación del equipo. Tuve que trabajar con nuevas herramientas y transferir materiales entre sí en nuevos formatos, por lo que no siempre todo salió bien la primera vez.
Por ejemplo, se estipuló en el TOR que el juego intenta determinar el rendimiento del dispositivo al inicio, y se muestra una notificación correspondiente en caso de bajo rendimiento. En esta etapa, nos enfrentamos a dos problemas. En primer lugar, el navegador no proporciona prácticamente ninguna información al respecto. En segundo lugar, el rendimiento de una pestaña del navegador en particular en un momento determinado depende en gran medida de factores externos: cuántas pestañas están abiertas, si hay sitios pesados en otras pestañas, si el navegador está minimizado.
Se probaron varias hipótesis teóricas y prácticas, de las cuales nació la solución final. La solución es la siguiente:
- En la pantalla de carga del juego, donde el progreso es de 0 a 100%, la carga real de recursos termina en 92%.
- Después de eso, se crea una escena fuera de la pantalla, en la que se colocan animaciones pesadas y un poco de física.
- Luego, dentro de los 5 segundos, se mide el tiempo de renderizado promedio de un cuadro.
- Después de eso, se toma una decisión sobre el rendimiento del dispositivo y el progreso alcanza el 100%.
Muy importante fue el requisito de que el juego fuera completamente funcional en IE 11, lo que también causó inconvenientes. Resultó que con las herramientas de desarrollo ejecutándose, la ya lenta ejecución de Javascript en este navegador se ralentizó aún más.
Es decir, te enfrentas a los frenos en el juego, abres las herramientas del desarrollador para encontrar el motivo y el juego se ralentiza aún más.
Mecánica de juego
La mecánica del juego en sí no es complicada, y está inspirada en gran medida en juegos existentes.
El personaje principal, por ejemplo, es un sprite de animación de una pieza junto con un arma. Esta solución se eligió para evitar la desincronización de las animaciones de swing y armas. Por lo tanto, la verificación de daños se realiza de la siguiente manera: en el momento de ciertos cuadros de la animación de impacto (cuadro del tercero aproximadamente), calculamos el área de intersección, que es válida para varios cuadros de animación más. Así es como logramos lograr el funcionamiento realista del arma.
La desventaja de esta decisión en la animación del personaje principal fue que para cada género en cada nivel necesitas su propio conjunto separado de animaciones preparadas con armas. Y en el segundo nivel, se requirió otro conjunto adicional: en zapatillas de crédito. En total, obtuvimos cuatro juegos completos de animaciones para cada personaje.
Otra cosa divertida aquí es que cuando eliges un arma para la batalla final, de hecho, eliges al personaje completo del nivel correspondiente. Entonces, todos los héroes con una espada usarán zapatillas de deporte normales.
La mecánica de agarrar las llaves del cofre fue interesante. Para la tecla que necesitaba ser capturada, el área de activación se hizo más pequeña que el sprite visual de la tecla, y también se movió ligeramente hacia un lado al azar. Esto llevó al efecto deseado "mi llave no se ensamblará la primera vez"; a veces es necesario intentar recoger la llave varias veces para llegar al área de actuación. De lo contrario, fue demasiado fácil, aunque en la versión final el área de activación se incrementó ligeramente para reducir el porcentaje de intentos fallidos.
Todas las demás mecánicas son en realidad las mismas: activan el enfoque y la intersección del personaje y los objetos del juego en ciertos momentos y animaciones.
La mecánica con el Dragón del Seguro, el vuelo sobre el abismo y la batalla final fueron un poco más complicadas. Las técnicas eran las mismas, pero las pausas y la inactividad se orquestaron adicionalmente para reproducir las animaciones de otros personajes en este momento.
Conclusiones y consejos
Decide un género desde el principio.
Los juegos en la web son un fenómeno real, con su propia audiencia y sus propias reglas. Dichos juegos no requieren instalación, le permiten organizar sesiones de juego cortas, atraen más mecánicas que apariencia.
Consejo: trate el desarrollo de juegos web como un juego real, no como un "guión más en la página". Pruebe, perfile y evite pérdidas de memoria y sobrecarga de CPU. Los jugadores y las baterías de sus dispositivos estarán felices.