UnnyWorld: post mortem

Después del cierre de nuestro juego UnnyWorld, muchos desarrolladores que eran amigos pidieron escribir un post mortem sobre el juego . Decidí compartir ejemplos específicos, de los cuales se ha acumulado una cantidad decente durante el período de desarrollo. Se considerarán los errores que cometimos, intentaré dar un par de consejos útiles.



Anteriormente, publiqué un artículo "Tres años de desarrollo de mi MMO" , que trataba más sobre la búsqueda de inversiones, el equipo y nuestro camino hacia el "éxito". Desafortunadamente (¿o afortunadamente?), El proyecto tuvo que cerrarse. En este artículo trataré de revisar los errores cometidos y, posiblemente, daré al menos un par de consejos útiles.

Sobre el juego en pocas palabras

Convencionalmente, Unnyworld se puede dividir en dos partes: constructor de ciudades y arena.
La parte sobre el constructor es cierto Choque de clanes. Tienes tu propio planeta, que necesitas equipar. Y puedes atacar a otros planetas para robar recursos.



Ataca a otros jugadores, eres uno de tus personajes y lo controlas.

Arenas: MOBA 3v3 típico con diferentes modos (captura de bandera, captura de puntos, etc.).



Cada personaje tiene sus propios hechizos, que se pueden combinar con otros jugadores.


Antes de la batalla, puedes cambiar hechizos.



El ciclo del juego en su conjunto se ve así:

1. Para los hechizos de bombeo, se necesitan pergaminos que caen de los cofres. Los cofres se pueden obtener de varias formas gratuitas (para una liga, para ganar el Battle Royal, etc.) o comprar.
2. Para bombear el hechizo, debes construir y mejorar la construcción del héroe hasta cierto nivel.
3. Para mejorar la construcción del héroe, es necesario mejorar otros edificios (edificio principal, altar, etc.).

Es decir, tratamos de conciliar de alguna manera el régimen del planeta y las arenas. Probablemente hicimos todo mal.

Falta de un plan y estrategia claros

Sí, muchas cosas se discutían constantemente, pero se dieron cuenta de que estaban fuera de lugar, sin analizar a fondo lo que había que hacer en primer lugar.

Como resultado, intentaron hacer todo a la vez. ¿Necesitas un sistema de gremios cuando el juego tiene un usuario y medio? Hmm, apenas.

¿Necesitas un sistema que te permita crear una combinación personalizada, invitando a amigos y co-gremios cuando el juego tiene una CCU pequeña? No estoy seguro

Durante el proceso de desarrollo, probamos muchas cosas para hacer algo que probablemente no era necesario hacer en esa etapa. Como resultado, las cosas verdaderamente necesarias no fueron implementadas.

Falta de experiencia

Porque Antes de que trabajáramos principalmente solo con juegos de un solo juego, pisamos una gran cantidad de rastrillos al elegir una u otra tecnología.

Hablemos un poco sobre la parte técnica de la pregunta.

Selección de tecnología

Un poco de aclaracion. En su mayor parte, somos puramente desarrolladores de clientes. De todo el equipo, solo un par de personas tenían experiencia trabajando con tecnologías de servidor. Sobre la administración, generalmente me quedo callado. Intentaré pasar por tecnologías específicas con un pequeño resumen para cada una.

¿Qué proveedor de la nube usar? AWS? Azur? Capa suave

En ese momento no había una diferencia fundamental. Además, teníamos un préstamo para SoftLayer como startup.

Oh, boi, si supieras lo mal que estaban las cosas:

- Saport no está particularmente versado en el problema. Hubo casos en los que recurrí a ellos sobre un problema en cierta máquina virtual (no pude conectarme, etc.). A lo que recibí la respuesta:

Reiniciamos el auto, ahora todo está bien

- Hubo casos en que la máquina virtual subió durante horas . Como puede ver, esperé 4 horas, pero la máquina virtual nunca se creó.



- Mantenimiento frecuente.



- Sucede que, sin previo aviso, un automóvil se reiniciará o se cortará una red privada.

Como resultado, cambiaron a Azure. No hubo tales problemas. El soporte responde rápidamente y siempre ayuda si algo sucede.

Bueno: -

Malo: no analizaron correctamente todas las opciones posibles. Pero el servidor es la parte más importante para un juego en línea = /

Por lo tanto, debe iniciar de alguna manera las instancias del juego en el servidor, lanzarlo a través de un sistema API después de autorizar al jugador a la instancia deseada. Que vamos a hacer Y tomemos una solución llave en mano que gestionará este negocio dependiendo de la carga. Wow, hay una cosa llamada Kubernetes. Es cierto, ella está en beta ... Pero de todos modos, ¡intentemos!

Si descartamos el hecho de que necesita experiencia para trabajar con esta tecnología, incluso con la configuración básica de este negocio, logró caer. Algunos servicios se cayeron, etc.

Bueno, que mas hay? Mesosfera y Apache Mesos! Todo es igual para él, es difícil sin experiencia. Si algo se cae, entonces sin una pandereta no puede solucionar el problema.

Como resultado, escribieron todo ellos mismos. Las instancias comienzan con el supervisor, al igual que el pequeño administrador que se encuentra sobre ellos (escrito en Java). Aplicación Java ttl'it en el servicio de descubrimiento de estado (el número de salas libres en instancias, etc.). Al autorizar y solicitar crear una sala para la API utilizando esta información sobre instancias, la solicitud va al nodo correcto, lo que aumenta la sala en la instancia correcta.

Es decir las instancias siempre se ejecutan previamente. Con una escasez, estamos planteando un nuevo VPS.

Bien: analizó las alternativas.

Malo: pasé mucho tiempo en el prototipo. Para la primera versión, no tenía que pensar en estas cosas en absoluto, sino que simplemente comenzó las instancias sin ninguna queja. Fue posible codificar directamente las direcciones de instancia en el cliente en el prototipo.

Utilizamos www.consul.io para el servicio de descubrimiento. Esta es probablemente una de esas soluciones de las que no nos arrepentimos. Es cierto que hay problemas como estos cuando la configuración se rompe durante el reinicio. Pero esto es raro y con un reinicio no planificado del automóvil. En general, todo el tiempo fue un placer trabajar con el cónsul.

Bien: hicieron una solución preparada, pero no comenzaron a cortar algo por sí mismos.

Para la implementación, los scripts de bash se usaron originalmente.


Más tarde, transfirí todo el despliegue a Ansible. No puedo tener suficiente hasta el día de hoy. Hubo, por supuesto, problemas al principio. Pero el sistema es bastante simple de aprender, y la documentación a granel.

Bien: escriba rápidamente un script bash, no se requieren conocimientos especiales.

Malo: al cambiar a un sistema de implementación normal, tuve que tirar casi todo lo escrito anteriormente.

Para la comunicación entre sus servicios probamos www.rabbitmq.com . Pero él tan fuera de tema en unos días podría desmoronarse. Como resultado, lo hicieron de una manera simple: todos los servicios interactúan a través de sockets tcp puros o solicitudes http con keep-alive, si necesita enviar solicitudes solo en una dirección.

Bien: analizó las alternativas. Elegimos una buena solución.

Malo: falta de experiencia con la tecnología. No hay necesidad de arrastrar cosas a la producción que no puede solucionar en caso de problemas.

Jugar en línea significa que necesitas una sala de chat. Escribe tu mismo? Es poco probable que sea escalable. Tomemos algo listo. XMPP? Ejabberd? Parece bueno En general, probamos tanto el erizo como MongooseIM, pero finalmente nos decidimos por un erizo. Hubo algunos problemas al subirlo a sus servidores (jambas con temporizaciones en mensajes, bloqueos, etc.). Decidimos usar su solución en la nube ejabberd-saas.com . Sí, está pagado. Pero funcionó sin problemas.

Bien: analizó las alternativas. Elige la opción adecuada.

Malo: en lugar de resolver los problemas locales, decidimos usar una solución de nube paga. Tarifas desde 200 euros. Teníamos varias regiones de juego. Para un equipo independiente, esto viene en una cantidad muy sustancial, que se gastaría mejor en otras cosas.

Al principio, generalmente no teníamos ningún sistema para recopilar métricas en los servidores. ¿Por qué la solicitud se ralentiza? ¿Qué tiene de malo el servicio? ¿Cuántas habitaciones hay disponibles ahora? Sí, ¡ni siquiera pudimos ver cuántas habitaciones hay disponibles actualmente!

Más tarde, me di cuenta de que hay que hacer algo. Intenté usar Graphite + Grafana. Incluso la imagen previa al acoplador hizo con todo esto: github.com/Suvitruf/docker-grafana-graphite-diamond

Pero no funcionó. No quería perder tiempo en esto, decidimos usar algo ya hecho. La elección recayó en www.datadoghq.com

Todo es genial Medidores, alertas, gráficos. El controlador del cliente es casi el mismo que para el grafito. Belleza Pero ... 10 + $ por cada host por mes. III ... sale a 200 + $ por mes.

La constatación de que cabreamos un montón de dinero en esto fue demasiado tarde. Decidimos, sin embargo, hacer esto en nuestros servidores. Configurar www.influxdata.com . Como resultado, un automóvil por un par de docenas de dólares procesa en silencio las métricas de decenas / cientos de automóviles.

Bien: lo probamos rápidamente. Encontramos una alternativa lista para usar. Se dieron cuenta (aunque tarde) de que la decisión fue incorrecta. Configure un sistema conveniente localmente.

Malo: no entendí correctamente el problema. Gasté mucho dinero.

En cuanto a las métricas, el mismo problema con el rendimiento. Al principio, no somos especialmente un cliente ni un servidor en los perfiles. Como resultado, las pérdidas de memoria en las instancias del juego del servidor se descubrieron demasiado tarde. No pudieron determinar y reparar de inmediato. Como resultado, escribieron para que después de crear un cierto número de habitaciones, la instancia del juego se reinicie.

Un poco sobre soluciones conceptuales y DG

Ahora no puedo construir el orden correcto a tiempo para todos estos eventos, nombraré algunas decisiones clave que tomamos.

División del juego por región.

Los jugadores solicitaron un servidor asiático y un servidor en América del Sur (antes de que este servidor estuviera en Europa y EE. UU.). ¿Por qué no hacerlo, eh? Lo hicieron Como resultado, un usuario y medio se repartieron en 4 regiones. Una vez que haya varias regiones, deberá realizar un sistema de transferencia. ¿Es lógico? Es lógico.

Bien: un par de personas obtuvieron mejores ping (｡ • ́︿ • ̀｡)

Malo: mucho tiempo dedicado a crear regiones, sistemas de transferencia, etc.

Es necesario escuchar las sugerencias / sugerencias de los jugadores, pero no debes huir inmediatamente y darte cuenta de todo esto.

Reemplazar una cuadrícula cuadrada con hexes y rehacer ataques en planetas

Anteriormente, los planetas se veían así:



Y los ataques:



Cambiar a hexes ha simplificado muchas cosas técnicamente. Además, se veía mucho mejor, es más fácil trabajar con elementos del juego.

Sistema de hechizos reelaborado

Solía ​​verse así:



La actualización en sí se realizó para las piedras que cayeron de los cofres. Todo no era obvio, confuso.

Como resultado, reemplazaron el sistema de piedras con pergaminos como en Choque real.



Para mejorar el hechizo, necesitas una cierta cantidad de pergaminos. Todo es simple y claro.

Bien: notaron un lugar problemático y lo rehicieron.

Malo: inicialmente no analizaron cómo lo percibirían los jugadores. Muchas cosas que son obvias para los desarrolladores, los jugadores perciben de una manera completamente diferente. Por lo tanto, los comentarios deben recopilarse en las primeras etapas posibles, organizar pruebas de juego, etc.

Comprar en Twitch

Incluso acordamos con www.twitch.tv realizar compras en el juego en la página del juego.



Pero desde nadie transmitió nuestro juego, entonces el significado de tal decisión es generalmente cero.

Bien: un lugar potencial para el retiro de dinero justo de los jugadores.

Malo: si tu juego no se transmite, entonces no tiene sentido. Solo tiempo perdido.

Modo Battle Royale

A raíz de la exageración, decidieron cortar ese régimen en el juego. Pero desde Había poco en línea en el juego, luego, en este modo, solo había bots, lo que elimina todo a la nada.

Sobre errores

En un proyecto así, es difícil no hacer errores. Hubo muchos errores de GUI relativamente inofensivos.



Hubo errores más graves, por ejemplo, cuando los jugadores murieron instantáneamente en el centro de la arena. No pudimos volver a intentar este error localmente. Ocasionalmente se les ocurrió a los jugadores, pero no pudimos solucionarlo.

Un error divertido cuando al cambiar el personaje el modelo del anterior no fue eliminado. Como resultado, fue posible organizar una fiesta con fuerza.



También hubo errores relacionados con la plataforma / motor.

Por ejemplo, a veces toda la GUI podría simplemente desaparecer. Pero si entra en la jerarquía de objetos y simplemente hace clic en el objeto, entonces aparece de nuevo.


Informamos sobre este problema, Unidad. Respondieron que podrían darnos un empleado para ayudar por $ 10k por mes ლ (ಠ_ಠ ლ)

En la plataforma de Facebook, Gameroom tuvo un problema con la escala cuando el juego reaccionó al tachy en el lugar equivocado.



Esto, sin mencionar errores en varias bibliotecas. Por ejemplo, en algunas máquinas Steamworks.NET, github.com/rlabrecque/Steamworks.NET/issues/121 podría bloquearse .

Resumen

Casi no invertimos en marketing, esperábamos que hubiera una afluencia orgánica de jugadores. Como resultado, el juego no alcanzó esa masa crítica, después de lo cual los bots no serían necesarios y habría una afluencia orgánica de nuevos jugadores.

Especialmente nadie participó en la gestión de contenido y la comunicación con los jugadores, no hubo boletines.

Durante el desarrollo, se perdió mucho tiempo en la selección y prueba de varias tecnologías.

No había un plan claro para la implementación de características / contenido.

En general, la mayoría de todos estos problemas se deben a la inexperiencia.

Que sigue

Unnyworld ha sido cerrado. Decidimos hacer el proyecto más pequeño en el marco de las oportunidades actuales.

Un artículo no cubre todo. Y lo que escribí sobre, para un extraño, puede parecer un conjunto incoherente de hechos. Desafortunadamente, no es un experto escribir tales textos.

Si tiene alguna pregunta, con gusto le responderé en los comentarios o en un nuevo artículo.