El primer videojuego de mi y mi novia. Desarrollo con unidad. Parte 1

Si no tenemos en cuenta los lanzamientos para Android y una docena de proyectos abandonados justo antes de que estuvieran listos, entonces s√≠, es nuestro primer juego apropiado para m√°s de una plataforma. ¬ŅC√≥mo empez√≥ todo? Muy simple Trabajamos en otro proyecto, llam√©moslo "proyecto A", y hab√≠amos estado trabajando en √©l durante mucho tiempo cuando decidimos hacer un juego durante un par de meses y usarlo para entrenar nuestras habilidades de marketing, y luego inmediatamente lanza nuestro "proyecto A" cuando tengamos m√°s experiencia en la promoci√≥n de juegos. Pero el plan fall√≥ y el "proyecto A" se mantuvo intacto durante todo el a√Īo. Pero esta historia no se trata del "proyecto A", se trata de un juego l√≥gico llamado "Cubicity: Slide puzzle".



El primer borrador fue el siguiente: gráficos mínimos, interfaz de usuario mínima y también todo lo mínimo posible, el juego tenía que estar al estilo de los juegos casuales de hoy que inundan el mercado, así como Match-3. Como resultado, nuestro objetivo se veía así: las fichas redondas se conectan a la figura y se mueven con un deslizamiento en 4 direcciones. Aquellos que ya han jugado Cubicity saben que no hemos cambiado completamente la tarea, sino que hemos mejorado ferozmente otros aspectos al ser un equipo de solo dos personas.



Si algunos de los lectores esperan encontrar aqu√≠ un secreto del desarrollo exitoso y r√°pido del juego, entonces no existe tal secreto. Aqu√≠ no compartimos una amplia experiencia o conocimiento, solo contamos la historia de un proyecto de una peque√Īa empresa. Y a√ļn no sabemos si tiene √©xito o no. Pero para muchos de ustedes, nuestros lectores, este es un mensaje del pasado enviado por los desarrolladores.

Volvamos a la historia de c√≥mo se cre√≥ Cubicity. Principalmente trabajamos solo con Unity y aqu√≠ est√° el conjunto est√°ndar de cada desarrollador decente de Unity: Newtonsoft.json, Zenject, Cinemachine, Dotween, etc. Como se puede ver en la imagen de arriba, el primer prototipo del juego inclu√≠a solo cubos y fichas. Despu√©s de una semana de pensamientos sobre c√≥mo mejorar el juego y atraer a los jugadores, hubo un momento eureka ... Para buscar algunos personajes c√ļbicos o redondos en la tienda de Activos. Y as√≠, algunos paquetes de personajes fueron comprados sin dudarlo. La misma situaci√≥n ocurri√≥ con los bloques en los que los personajes se mueven ahora. Tambi√©n se escribi√≥ una lista de nuevos elementos de juego con casi 30 elementos nuevos de los cuales elegimos en primer lugar cosas neutrales como bloques / flechas de redireccionamiento, elevador y teletransporte. Decidimos dejar el resto para los nuevos niveles y presentarlos uno por uno en 30-35 niveles.




Para ser sincero, ni siquiera podemos recordar qu√© nos inspir√≥ a hacer tantos niveles en el primer paso, pero tenemos lo que tenemos, por lo que el primer lanzamiento incluy√≥ 95 niveles. Son demasiados, para decir la verdad, y lo lamentamos. ¬ŅPor qu√© arrepentirse? Porque el juego no estaba completamente listo y muchas cosas cambiaron despu√©s del lanzamiento. Parec√≠a que est√°bamos atrapados en el D√≠a de la Marmota, porque necesit√°bamos hacer modificaciones en cada nivel de 95. Se pasaron dos meses de trabajo continuo en todos los niveles. A√ļn as√≠, esos niveles no estaban 100% listos, pero no est√°bamos lejos de all√≠. En los d√≠as m√°s productivos, 10 niveles se transfirieron f√°cilmente de la cabeza al papel y luego a la escena. Pero tambi√©n hubo d√≠as en que sientes que eres Hank Moody de California, que sufre el bloqueo del escritor, y crees que llegaste al fondo, pero el nuevo d√≠a trae nuevas ideas.

En cuanto al componente visual, fue un poco más difícil. El dibujo, como en la mayoría de los juegos, se lleva a cabo en la superficie fuera de la pantalla con una resolución inferior a la nativa y los blits a la superficie primaria, pero la IU se dibuja sin cambios en la resolución para una mejor claridad y legibilidad. Por lo tanto, obtenemos lo mejor de los dos mundos: no una interfaz de usuario borrosa ni un renderizado pesado en el juego. Después de numerosos experimentos, elegimos 2x MSAA + FXAA para antialiasing, porque ofrecen la mejor imagen con la menor cantidad de recursos. Concluimos razonablemente que un juego lógico no necesita 60 cuadros por segundo, y decidimos no reinventar la rueda y establecer el límite de cuadros a 30 fps (incluso las consolas suelen hacer esto). Establecer el límite del marco tiene un efecto positivo no solo en el consumo de energía, sino también en el calentamiento del teléfono, lo que evita que el teléfono se acelere debido al sobrecalentamiento.

Luego tuvimos que tomar una decisi√≥n dif√≠cil, y esos fueron los puntos finales. Cada vez que se iniciaba el nivel, los personajes se eleg√≠an al azar de los disponibles para el jugador, por eso ser√≠a problem√°tico dibujar una figura en miniatura de alg√ļn personaje. Puede que no lo creas, pero pasamos mucho tiempo resolviendo esta tarea despu√©s de postergarla continuamente. Los cubos en los puntos finales no parec√≠an una idea tan terrible, y la pintura en papel ayud√≥ a pasar el nivel y llevar a todos al lugar correcto. M√°s tarde, se decidi√≥ utilizar los mismos caracteres en lugar de cubos, pero de menor tama√Īo. Se hizo mejor, pero solo para nosotros. Unos d√≠as m√°s tarde, estos personajes se volvieron y resaltaron, y se hizo mucho m√°s claro qui√©n es qui√©n, pero a√ļn no fue satisfactorio. La versi√≥n final se adopt√≥ un mes despu√©s, por prueba y error, y luego se dedic√≥ un par de semanas a crear iconos para los acabados. ¬°Adi√≥s verano, hasta pronto!



En nuestra humilde opini√≥n, las nubes resultaron ser bastante agradables. Pero, de hecho, este es el truco m√°s simple. Cuando decidimos agregar nubes, lo primero que pensamos fue hacer un video de fondo 360. Este enfoque fracas√≥, ya que para plataformas m√≥viles es deseable ajustar el juego en el l√≠mite de tama√Īo para la descarga a trav√©s de LTE. Si quer√≠amos que el video no se sobrecomprimiera, ten√≠amos que darle 10-15 MB. Combinado con la presencia de niveles nocturnos en el juego con sus nubes, es demasiado (toda la construcci√≥n final del juego para Android toma 61 MB). El segundo deseo era escribir nuestro propio sistema para las nubes. Fue tentador para un desarrollador, pero para una persona que quer√≠a terminar el juego lo antes posible, no era adecuado. La soluci√≥n lleg√≥ en forma de crear una textura para la nube y crear un sistema de part√≠culas con una vida √ļtil infinita de la part√≠cula, y tambi√©n un n√ļmero limitado de part√≠culas en general. Despu√©s de eso, agregamos tama√Īos aleatorios entre dos constantes junto con rotaci√≥n aleatoria. El resultado fue realmente satisfactorio, nuestro cielo estaba lleno de nubes que eran bonitas y no nos hicieron llorar al mirarlas.



Shadows en el juego (en la versión móvil) consiste completamente en quads que se arreglan simplemente a mano, ya que no queríamos agregar sombras reales a la versión móvil. Una de las razones es la ausencia de sombras suaves en las plataformas móviles con OpenGLES 2.0 y, por supuesto, la degradación del rendimiento en dispositivos débiles.



Como se mencion√≥ anteriormente, usamos 2x MSAA + FXAA para suavizar, ¬°pero eso no es todo! Tambi√©n agregamos AmplifyColor a nuestro procesamiento posterior, ya que es un gran activo por dinero razonable que le permite aplicar diferentes Lut-s en el procesamiento posterior. Una lut correctamente seleccionada mejora la imagen. Durante el proceso de desarrollo probamos diferentes enfoques, incluida la pila est√°ndar de postprocesamiento de la unidad, pero en la construcci√≥n sus sombreadores y opciones tomaron mucho. Algunas soluciones fueron muy hermosas, pero funcionaron extremadamente mal en tel√©fonos no muy nuevos (cr√©anme, si creen que todos ahora tienen al menos un tel√©fono "normal", se equivocan. Una gran cantidad de personas a√ļn posee tel√©fonos chinos de $ 40 y se queja a usted en los comentarios que su DOOM no va bien en su basura).

El equilibrio del juego no siempre es fácil de alcanzar, e incluso ahora a veces pensamos que los niveles pueden ser demasiado difíciles, que esos niveles difíciles pueden aparecer con demasiada frecuencia, etc. Después de equilibrarnos como pudimos, decidimos introducir herramientas para facilitar la vida del jugador (Retroceder, Bomba, Bloque de hielo, Teletransporte), y sí, se hizo más fácil vivir, pero no para nosotros, solo para futuros jugadores. La cantidad de trabajo y errores aumentaron para nosotros.

Llegamos al men√ļ del juego, con nuestros poderes menguantes y nervios reprimidos. La creatividad pis√≥ los frenos. Hablando francamente, tuvimos que inspirarnos en otros juegos, por lo que les agradecemos mucho. Y finalmente lo hicimos, la interfaz de usuario estaba lista en dise√Īos anteriores.



Quer√≠amos estar a la moda tambi√©n. As√≠ que decidimos agregar ahorro en el almacenamiento en la nube y no nos arrepentimos. Esta tarea no fue la m√°s f√°cil, ya que en diferentes plataformas hay diferentes proveedores de almacenamiento en la nube. En Steam hay Steamworks, para dispositivos m√≥viles es GooglePlay y GameRoom. As√≠ que tuvimos que unificar el sistema de ahorro para poder sustituirlo por la plataforma deseada. Al principio, decidimos usar EasyMobile para estos fines, pero pronto abandonamos esta idea. El complemento es bastante bueno y tiene una gran cantidad de posibilidades, pero realmente no nos gustaba trabajar con almacenes nativos en la nube. Como resultado, elegimos Firebase Realtime Database y la autenticaci√≥n de Facebook. En resumen, tuvimos que pasar por el infierno para que todo funcionara (y esto no se trata de programaci√≥n, sino de configuraciones de 100500 que tuvieron que hacerse en ubicaciones de aplicaciones de 100500 y en Facebook, Firebase, etc.). Tambi√©n en la base de datos hay l√≠mites de tr√°fico y para guardarlo, cada vez que escribimos, creamos un GUID y lo escribimos tanto en la base de datos como en el dispositivo. Por lo tanto, si vemos que los GUID en el dispositivo y en la nube coinciden, podemos estar seguros de que no necesitamos leer todos los datos de la nube, pero podemos usar una copia local de los datos. Como resultado, se agreg√≥ la sincronizaci√≥n, pero ... Uno de los errores m√°s extra√Īos para nosotros fue el comportamiento no obvio de la base de datos de Firebase en algunos casos. Como usamos Json, serializamos clases para almacenar el estado, pero Firebase a veces se comporta un poco extra√Īo.

Si pasamos un objeto de diccionario a Firebase, por ejemplo:

var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, new SlotState() }, { 2, new SlotState() }; 

Cuando lo leamos de la base de datos, no obtendremos un objeto Json, sino una matriz de Json (¬ŅQu√©?)
Bueno, ok, usaremos listas en todas partes y no tendremos problemas, ¬Ņverdad? Pero parec√≠a no estar bien.

Si escribimos en Firebase:

 var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, new SlotState() }, { 100500, new SlotState() }; 

O incluso:

 var dict = new Dictionary<int, SlotState> { { 0, new SlotState() }, { 1, null }, { 2, new SlotState() }; 

Cuando lo leamos de la base de datos, obtendremos un objeto Json con claves y valores.

Bueno, la l√≥gica de los desarrolladores se puede entender, pero puede generar errores que pueden aparecer despu√©s de un tiempo (¬ŅRecuerdas los GUID agregados para guardar que mencionamos anteriormente? Como resultado, una lectura rara de la base de datos con entradas relativamente frecuentes) .

¬ŅCu√°ndo es el lanzamiento? Esta pregunta se escuch√≥ con mayor frecuencia. Pero era necesario estar bien preparado para este d√≠a. Tuvimos que hacer una lista de mercados, elegir una fecha de lanzamiento, evitar grandes ventas, hubo muchos matices que retrasaron el lanzamiento durante aproximadamente 2 meses. Siguiendo el consejo de un art√≠culo, elegimos martes y mi√©rcoles para su lanzamiento. Decidimos solicitar una revisi√≥n en 4pds, hablar sobre el juego en varios foros y publicitarlo en las redes sociales, en particular en Instagram (por supuesto, por una tarifa). Lo que result√≥ de todo esto, lo descubrir√° en la segunda parte de esta historia, pero eso es m√°s tarde.

¬ŅQu√© tenemos al final? Crear un juego no siempre es un proceso r√°pido. Y es posible que el tiempo esperado para desarrollar el juego tenga que multiplicarse por 5. Obtenga personas que puedan ayudarlo con consejos pr√°cticos en industrias desconocidas. Rel√°jese en cada oportunidad, ya que crear algo, no solo juegos, requiere mucha energ√≠a. No es correcto estar cerca del lanzamiento sinti√©ndose agotado y ser menos √ļtil que al comienzo del proyecto. Y dinero, busca dinero, lo necesitar√°s. Y de parte nuestra, gracias por su atenci√≥n, buena suerte y nos vemos en el pr√≥ximo art√≠culo.

Source: https://habr.com/ru/post/443020/


All Articles