¿Alguna vez has pensado en tu propio juego? ¿Y qué hay de tu propio juego multijugador? Yo creo que si! A muchos de ustedes les gustaría aferrarse al desarrollo de su propia obra maestra, donde se fusionan su imaginación multifacética y su perfeccionismo excepcional. Te entiendo y quiero contar mi historia de esta manera fascinante.

Antecedentes
Todo comenzó en 2007, cuando apareció un juego j2me en línea basado en el trabajo de Sergey Lukyanenko. Todavía no tenía una computadora y estaba muy impresionado con este juego en un teléfono móvil, sobre todo en el mundo abierto. Me involucré y, a pesar de la ausencia de tutoriales, descubrí rápidamente lo que estaba sucediendo.
El tiempo pasó, pero el interés no se desvaneció, ya no había suficiente solo un juego. El deseo de aprender cómo funciona esto y la aleatoriedad impulsaron el uso de errores con prohibiciones posteriores. La posterior graduación y la elección del "programador" profesional impulsaron el desarrollo de mi primer software con fines de lucro en el mundo en línea.
Tan pronto como se fortaleció mi conocimiento en el campo de la OOP, ¡ya decidimos con mi compañero de juegos y artista desarrollar nuestro propio MMO, que sería cien veces más genial!
¿De qué se trata nuestro juego?
Nuestro juego glorifica a dos facciones en guerra, Oseon y Weiland. Cada uno de ellos tiene su propio planeta; a su vez, alberga los edificios necesarios para el desarrollo del jugador.

Planeta de origen facción Oseon
Los planetas de facción están protegidos por un sistema de 12 puertas. Habiendo capturado todas las puertas, los jugadores obtienen acceso al planeta enemigo. No es suficiente teletransportarse a través del camino abierto, después de eso es necesario capturar la ciudadela, el edificio principal del planeta. Al encontrarse en una situación difícil, los jugadores del lado ocupado reciben tropas de reserva con parámetros 1.4 veces más altos que los suyos.
Las batallas tienen lugar en un modo paso a paso, algunas las comparan con otras similares en "Héroes", otras las llaman una especie de ajedrez. En parte, están bien, hay unidades con magia aquí, y tendrás que pensar unos pasos adelante con tu cabeza.

Batalla con el enemigo
Sin embargo, el cruel mundo de los juegos PvP tiene otras mecánicas interesantes, comenzando por el desarrollo habitual de depósitos ricos y terminando con la caza de cazadores de tesoros.
Prototipo
Como no teníamos experiencia en la creación de juegos MMO, decidimos tomar todo lo que es malo. Nuestro conjunto incluye: Anthill, Netty, MySQL. Estas no eran exactamente esas tecnologías. Después de mucho trabajo realizado, nos encontramos con muchos problemas: la falta de un editor de interfaz, los micro-registros de la tarjeta al mover, el ingreso de texto y mucho más. En pantalla completa, el juego parecía asqueroso.

El prototipo del juego. Desarrollo minero
En algunos casos, al cambiar el estado del juego, la cámara virtual del motor comenzó a comportarse de manera extraña.

El prototipo del juego. Retrasos
Después de un año de desarrollo, cuando ya no era posible retirarse, completamos la mecánica básica del juego, reunimos un editor de mapas y decidimos que había llegado el momento de probarlo en público.
Agregamos el juego a VK (sin catálogo) y anunciamos el lanzamiento en nuestro grupo, donde había unas 100 personas.
En este momento, el juego tenía un control incomprensible que involucraba el teclado, había muchos errores, así como mapas que eran demasiado simples, que solo tenían dos capas (pasto y árboles). Y después de tres días de jugar el juego en VK, solo 15 personas se registraron, las personas no entendían cómo jugar. Y decidimos rehacer todo desde cero.
Capturas de pantalla de la versión anterior
Genial en línea

Menú de interacción del jugador

Pelea
Lech, no es eso, ¡vamos primero!
Probablemente, muchos, ante el fracaso, piensan que esto no es de ellos, porque se ha pasado mucho tiempo, pero no hay un resultado visible. Pero darse por vencido es estúpido cuando has recorrido un largo camino. Después de un par de meses, nosotros, con la experiencia existente, decidimos retomar el juego.
Decidimos crear definitivamente la nueva versión del cliente con gráficos de representación a través de una tarjeta de video. De los muchos frameworks, Starling parecía ser el más atractivo, tenía una API similar con un flash estándar, era compatible con Adobe y era posible usar gráficos existentes sin mucho esfuerzo. Finalmente, la nueva versión funcionó sin problemas.
Para rasterizar el vector sobre la marcha, tomé el generador Dynamic TextureAtlas . Pero en la biblioteca subsiguiente hubo que reescribir casi por completo y abandonar los atlas, la animación ocupaba mucho espacio y no podía encajar en el atlas de los tamaños permitidos.
Tarjetas
Después de descubrir las tecnologías en el cliente, decidimos ocuparnos de las tarjetas del servidor . Cada planeta puede constar de una o más ubicaciones, entre las cuales puede ir hacia la derecha o hacia la izquierda. Para cada ubicación, se creó una parte del mapa, que inicialmente constaba de dos capas. Más tarde, decidimos agregar otra capa, y luego otra capa, y como resultado nos decidimos por cuatro:
- hierba / tierra;
- piedras \ agua;
- decoraciones del tamaño de una jaula;
- Amplio paisaje.
La idea era que las tres primeras capas se dibujaran en un mapa de bits y se enviaran a la memoria de video. Este es un buen enfoque cuando, en lugar de tres capas, se dibuja una en el fondo. Pero no estuvo exento de problemas: al cambiar MovieClipa al siguiente cuadro para la rasterización, se deben dibujar todos los cuadros anteriores. En la entrada de la ubicación, el juego se congeló, por lo que se decidió transferir todas las fichas a BitmapData por adelantado y hacer copias rápidas de Pixel. Pero al mismo tiempo, se obtuvo un friso desagradable al comienzo del juego en el momento de rasterizar una gran cantidad de fotogramas. Es posible que haya visto que algunos navegadores se congelan en el inicio al cargar recursos. No queríamos que nuestro juego fuera igual de inválido, así que limité el tiempo para dibujar mosaicos para cada cuadro. Aquí puedes leer más sobre cómo hacerlo.
Todas las tarjetas tenían un tamaño de 20x16 fichas cuadradas de 64px. Los datos del mapa se escribieron en un archivo en formato binario, donde los límites de la capa se determinaron de antemano y solo quedaba para registrar el número de fotograma de MovieClip. Por lo tanto, el peso del archivo de mapa fue de 1280 bytes. Pero más tarde, el formato se convirtió a JSON para que sea más fácil trabajar con datos.
Como resultado, el trabajo en mapas ocupó una parte importante del desarrollo del cliente. Para poder crear mapas hermosos, se escribió un editor en Flex.

Editor de mapas
Cada uno de los 14 planetas tiene su propia flora y fauna, para que pueda comprender visualmente en qué planeta se encuentra.

Variedad
Además, programáticamente, agregamos mitades de fichas para la tarjeta, desde arriba y desde abajo, que simplemente duplican las fichas vecinas. Esto se hizo para elementos interactivos prominentes, como los botones de menú. Se agregaron campos de ubicaciones vecinas con la niebla de guerra a izquierda y derecha; esta fue una gran idea que resolvió varios problemas a la vez. El juego comenzó a verse mucho mejor en pantalla completa.

Tarjeta con niebla de guerra a los lados
Servidor
Al tratar con el cliente, estábamos buscando simultáneamente un programador de servidor, pero no había muchos que quisieran escribir un juego dudoso sin la documentación normal. Algunos comenzaron a escribir e inmediatamente se retiraron, porque no estaba claro qué escribir, y profundizar en las espinas de la lógica del juego era aburrido. Después de un tiempo, determinamos que necesitamos un especialista que pueda diseñar el servidor en Java, y si abandona el proyecto en el futuro, podría agregarlo. El solucionador artesano local nos ayudó con la arquitectura del servidor. Él, podría decirse, nos puso en el camino correcto: mostró cómo hacer un servidor y tomó prestada la arquitectura del curso de formación Mail.ru. Solver no fue la excepción y después de un tiempo nos dejó. Después de otro año de esfuerzo, logré escribir toda la lógica básica del juego. Ahora, mirando hacia atrás, no sé por qué no escribimos el servidor en Akka.
Puede leer sobre arquitectura aquí: arquitectura de un servidor de juegos en línea utilizando Skyforge como ejemplo ; también puede encontrar conferencias en Intuit. En nuestro servidor, por supuesto, no 2 millones de líneas, sino también bastante. No se utilizan fibras (como en Skyforge), y nuestro servidor probablemente resultó ser menos legible. Por cierto, el código que se usó para la misma fibra para la multitarea no abarrotada en Skyforge se publicó mucho más tarde, cuando todo ya funcionó para nosotros.
Mientras estaba ocupado con el servidor y pegué la lógica en el cliente, el artista completó los detalles faltantes, que inmediatamente cayeron en el cliente. Tan pronto como el servidor estuvo listo, lanzamos una prueba alfa. Esta vez todo fue casi como debería, pero los errores y errores del servidor tuvieron que repararse durante mucho tiempo.
De ida y vuelta. Mecánica de juego propia
Me gustaría contarte sobre otra cosa inusual en el juego. ¿Cómo llamarías a un jugador que específicamente forma un ejército incompleto y pierde a otros jugadores / bots? Los llamamos "ciruelas". Fusionan experiencia y bajan su nivel intencionalmente, por lo que se vuelven más fuertes a su nivel. Esto es importante cuando el nivel de jugadores que pueden ser atacados es limitado y les da más oportunidades de desarrollo. Cada vez es más fácil derrotar a enemigos de alto nivel y obtener más recompensas. Es como bombear tu persa, pero en la dirección opuesta. Aunque puede parecer más simple que el juego clásico, la pérdida de experiencia requiere inicialmente más tiempo y habilidad para el bombeo. Si bajas el nivel de un personaje débil, esto no te dará una gran ventaja y solo atraerá al jugador al promedio. Subir y bajar el nivel puede ser infinitamente largo. Incluso habiendo alcanzado el máximo desarrollo para su nivel máximo actual, el jugador puede ascender a un nivel aún más alto para acceder a nuevas tecnologías y fusionar su progreso de la experiencia nuevamente, manteniéndose tan fuerte en tecnología.
Los principiantes tienen un problema cuando no pueden hacer nada a tales enanos bombeados. Resolvimos este problema introduciendo restricciones, dividiendo a los jugadores en dos grupos: solo puedes atacar bots en bots, con restricciones en el nivel máximo en otros jugadores y en los mismos jugadores combinados que ellos. Por lo tanto, casi dejaron de ejercer presión sobre el equilibrio del juego, y lo más importante, podían continuar haciendo lo que quisieran.
No funcionó, no fartanulo
Ingresamos al catálogo de juegos de VK el 4 de febrero de 2018, y no la primera vez. Nuestra primera solicitud fue rechazada sin explicación, pero al volver a presentar la solicitud se nos agregó al catálogo.
A pesar del largo tiempo de desarrollo del juego, no fue posible capturar todos los detalles; cometimos muchos errores. En primer lugar, cometieron un error con la plataforma: no todos los jugadores están listos para pasar mucho tiempo en un juego 2D basado en navegador, lo que requiere una mecánica. Muchas personas están acostumbradas a juegos más simples y más comprensibles, donde hay más diversión desde el principio. Nuestro entrenamiento en el juego, por decirlo suavemente, fracasó. Después de completar el tutorial, los jugadores olvidan con seguridad lo que había allí, y tal vez ni siquiera leen.
Según las estadísticas de VK, tenemos una gran cantidad de jugadores, en su mayor parte solo aquellos que alguna vez jugaron ese viejo juego y que ya están familiarizados con la mecánica permanecen durante mucho tiempo.
48 semanas después ...
Aproximadamente un año después del lanzamiento de la versión alfa, quedó claro que Flash pronto dejaría de funcionar en los navegadores. Desde ese momento, decidí que debía trasladar al cliente a algo más tenaz. Por supuesto, es mejor escribir en un idioma familiar, así que elegí LibGDX. Este marco de Java nos permitió no reescribir alguna parte de la lógica, sino simplemente copiarla del servidor. Tiene buenas abstracciones para los mapas de mosaico y una implementación para Tiled, que nos permitió escribir rápidamente código para nuestros mapas. Pero también hay debilidades: representación de fuentes, falta de editores de interfaz visual en vivo, etc.
Por el momento, se escribe un cliente alfa para Android, que implementa el 50% de todas las funciones del juego.

Cliente de juegos móviles
El desarrollo aún está en curso. Si desea dibujar o escribir algo para un cliente móvil, escriba.
También me gustaría expresar mi gratitud al ingeniero de sonido Peresvet Mukhanov y al compositor Artem Davydov, escribieron todo lo que se puede escuchar en el juego en muy poco tiempo y con una calidad muy alta.