Juego propio en 72 horas: rastrillo, muletas y alpacas.

Para armar un equipo de ensueño, de una sola vez para cortar una obra maestra que explotará por completo. O, como corresponde a un genio solitario, para construir y lanzar al mundo un fenómeno de juego durante la noche, un juego es un imán para el dinero y la fama. Al parecer, en la sala de fumadores y en varias reuniones de TI, esas fantasías oscuras atormentan no solo a los estudiantes más jóvenes, sino también a tíos respetables. Es más difícil para ellos admitirlo.

¿Cómo ser un desarrollador cuya carrera profesional está tan lejos de ser un desarrollador de juegos como el Hobbiton de Black Gate? Haga caso omiso de la obsesión y finalmente termine la biblioteca que se vería tan triunfante en el currículum. Pero si entierras tus propios sueños, no a tu manera, bienvenido a cat. Encontrarás una historia honesta sobre cómo Kick del mundo de TI practicó frente a un espejo y contusiones llenas. La historia del juego, desde el esquema hasta el lanzamiento.

imagen

De patrones de pensamiento vagos a un concepto terminado


En una primera aproximación, el plan era el siguiente: en un tiempo mínimo para pasar por el ciclo de desarrollo del juego, cuya etapa final es el lanzamiento de un lanzamiento completo.

Los límites de tiempo razonables y la necesidad de publicar el juego ayudan a evitar la trampa típica que espera a los novatos en el desarrollo del juego: ¡perseguir la imagen del "juego de los sueños"! La mayoría de las veces, el concepto "ideal", cuando se concreta, se convierte en un proyecto más allá del alcance de un equipo independiente. La idea misma se convierte en una imperfección, que tarde o temprano se esconderá tímidamente "en la mesa".

Para evitar el fracaso sin gloria con el desarrollo de un simulador submarino o un tirador 3D en línea, es mejor hacer una pausa y lanzar un juego simple. Por cierto, la simplicidad no significa una sala de juegos primitiva hello-word, un clon de serpiente truncado y otras variaciones de artesanías no reproducibles y no originales.

Granja cuatro en fila con mayordomos, plantas vs. Hamsters ... ¿Qué idea exótica elegir como bola de prueba? Tal vez algo sobre pelotas. Y como este es el primer panqueque, deja que el juego sea plano, en 2D. El lema de cualquier evento dudoso es menos razonamiento, directo al grano. Por lo tanto, se solucionó la primera idea relativamente sana. Entonces, un bosquejo de una mezcla salvaje de billar y air hockey en el escenario de una civilización antigua:

imagen
Concepto del juego

Esta es la disposición de las bolas (zengs) en medio del juego. El jugador apunta a un gato zeng en un cocodrilo zeng para golpearlo en uno de los seis bolsillos y ver un poderoso efecto especial de la explosión. El primero en noquear a todos los zenges del campo es Etsvatsephala (un gran compañero). Oh si El escenario de la civilización antigua todavía está detrás de escena.

Harina de elección: plataforma objetivo y kit de herramientas


Después de que el concepto del juego se describió en términos generales, no fue difícil determinar la plataforma y las herramientas.

La vista en el mercado de PC amenaza los problemas con los servicios de distribución en línea. Tome al menos el sistema Steam Direct para su publicación en la popular tienda Steam. Para la adición de cada producto, se aplica un impuesto de aproximadamente 6,000 rublos, y desde el momento del pago hasta la publicación, debe tomar un mes para que los empleados de Valve "se aseguren de que están tratando". La moderación del juego antes del lanzamiento lleva otros cinco días.

La colaboración de la indie igrodela con GOG.com, otro gigante de la distribución digital, comienza con completar un cuestionario sobre el juego. La tienda toma algún tiempo para que el juego sea considerado, y el riesgo de negarse a publicar es bastante alto: el juego puede no parecer lo suficientemente único, básico o puede no cumplir con otros criterios ...

El sentido común dicta que tiene sentido ponerse en contacto con monstruos como Steam o GOG.com si tiene un producto listo (o casi listo) de la calidad adecuada. Pero el lanzamiento del juego para una audiencia móvil es una opción más rápida y asequible. Por supuesto, estoy insinuando Android: un pago único de $ 25 por activar una cuenta de desarrollador y acceder a la Consola de desarrollador de Google Play es más barato que los $ 99 anuales en la alcancía de Apple por publicar en la Apple Store. Tengo una cuenta de desarrollador de Google Play desde tiempos inmemoriales, y esto inclinó la balanza a favor de Android.

En cuanto a Android, los temerarios, al activar una pista resbaladiza de desarrollo para esta plataforma, a menudo se encuentran en una encrucijada: ya sea para hacer un juego en Canvas, aprender la API de OpenGL o lidiar con un motor de juego completo. Para mí, ni siquiera había una opción: era mucho más tentador llevar el mouse en el hermoso motor GUI que pasar la noche en un depurador e investigar por qué la escena tampoco escala, luego se congela.

Obviamente, era necesario elegir un motor que cumpliera con los requisitos:

  • La capacidad de portar juegos para su lanzamiento en Android
  • Gratis
  • Umbral de entrada bajo
  • Velocidad de prototipos
  • Documentación fresca y clara, o una comunidad activa

Después de algunas búsquedas, tres motores despertaron interés: Cocos2D, Unreal Engine y Unity. Cocos2D impresiona con su ligereza y C ++ como lenguaje de desarrollo, pero escribir un juego en él no promete ser rápido. Una elección difícil entre Unreal Engine y Unity terminó en la victoria de Unity: al primer conocido, parecía que era más fácil para un principiante entender este motor. ¡Lo que vale al menos un elegante tutorial en línea sobre la creación de juegos en 2D!

Para el desarrollador independiente, Unity está disponible bajo el plan de tarifas personales, es decir, de forma gratuita. Las empresas cuya facturación anual o cantidad de fondos recaudados excede los $ 100,000 están invitados a usar una suscripción paga. Bueno, tan pronto como sea, de inmediato, pero por ahora, inicie Personal.

Sobre desarrollar un juego solo: donde el tiempo desaparece


Como resultado del lanzamiento entre diferentes plataformas y motores en la computadora, Unity 2017, Visual Studio Community y Android Studio se registraron. Por cierto, las compilaciones oficiales de Unity están disponibles para su instalación en Linux, y mi openSUSE Leap se instaló sin ningún problema. Sin embargo, la mayor parte del desarrollo del juego se realizó bajo Windows porque Photoshop está allí. Y el único desarrollador del proyecto a tiempo parcial es el único diseñador que aporta un pimiento especial al proceso de gamedev.

Por ejemplo, a menudo tenía que cambiar entre dos tareas: escribir código y dibujar gráficos. Tan pronto como el proceso de desarrollo fue bloqueado por la necesidad de agregar nuevos gráficos a la escena, fue necesario posponer todo y diseñar. Para paralelizar estos procesos, se utilizaron activamente imágenes de "trozos", esbozadas de alguna manera y hasta el último reemplazo de gráficos completos.

imagen
Desarrollo gradual de gráficos

También hubo éxitos en el estancamiento creativo cuando los gráficos, que se consideraron finales, provocaron el rechazo del autor o de los jugadores, y no estaba claro cómo solucionar la situación. La práctica ha demostrado que un par de nuevos conceptos artísticos contribuyen a romper el punto muerto. Le indican en qué dirección debe rehacer la imagen o la reemplazan por completo.

En cualquier caso, una gran cantidad de arte no entrará en el ensamblaje final del juego, y esto es normal. De un montón de bocetos sin éxito, nace uno que todos miran y dicen: “Sí, esto es todo. La misma alpaca ".

imagen
La misma alpaca

Y aquí está el campo de juego después de numerosas iteraciones de rehacer:

imagen
Captura de pantalla del campo de juego.

Resultó que de 72 horas, aproximadamente 40 se gastaron solo en dibujo y diseño. El tiempo restante se dedicó al ciclo de pruebas de desarrollo, acelerado por tres factores:

Disponibilidad del juego para el lanzamiento. ¿Un juego cuya funcionalidad no se avergüenza de considerar completada, lista para pasar por el usuario que la ve por primera vez? ¿Deja de ser así si abandonas una o dos funciones? Si no fuera por el TK de solo lectura previamente compilado y traducido mentalmente, el juego podría mejorarse y desarrollarse por siglos. Mientras discutían sus impresiones con los jugadores y el surgimiento de sus propias ideas, aparecía una nueva lista de deseos casi cada hora, y luego guardaba la lista de características para el punto de control.

Rechazo de un hermoso código. Se puede discutir con esto, esta práctica se puede considerar dañina tanto para el proyecto como para el desarrollador, y estoy de acuerdo con la mayoría de los argumentos ... Pero el hecho es claro: si el proyecto es pequeño y el tiempo se acaba, la pureza del código se desvanece en el fondo. Lo principal es que el código fuente aún se puede entender. Pero el código de espagueti y la copia y pegado de grasa no son tan dañinos si no solicita una doble porción.

Gama para el funcionamiento de piezas. ¿Se dedicó el tiempo a la explosión, pero todavía no gana el premio a los mejores efectos visuales? ¿Las rarezas en la animación de sprites solo son visibles ahora, porque otros objetos llamaban la atención sobre sí mismos? Depuración de secciones complejas, ajuste de efectos especiales, ejecución de animaciones ... Para tales eventos, un buen enfoque es aislar el bloque de interés tanto como sea posible y colocarlo en un proyecto limpio (o al menos en una escena separada). En primer lugar, esto elimina los efectos secundarios de otras entidades del juego. En segundo lugar, ayuda concentrarse en la tarea actual, experimentar sin riesgo de estropear y romper algo en el vecindario. Por ejemplo, en una escena separada, era conveniente ajustar los parámetros de los efectos de las explosiones cuando un zeng golpeaba un bolsillo, y en el proyecto de prueba, seleccione las opciones para texturizar el fondo.

Errores que nunca se volvieron fatales


Caídas intransigentes en las pruebas beta abiertas, referencia nula ¬- huevos de pascua cerca de las líneas con la frase "// TODO", deslizándose como agua entre los dedos, errores ... El hecho triste: la mayoría de los errores son el resultado del descuido y la falta de propiedad del instrumento. Unity tiene documentación detallada, y por buenas razones. Muchas de las soluciones técnicas de Unity no son obvias. Atascarse en la documentación genera horas adicionales de depuración y deambular por Google ... lo que lo devuelve a la documentación en línea.

Damas y caballeros, este es el "Top 3" de los errores más sabrosos y lentos que adornaban el proceso de desarrollo de El Zengo. Son curiosos porque son casos especiales de problemas típicos que surgen durante el rápido desarrollo de la falta de tiempo para un estudio detallado del área temática.

3. No funciona como yo quiero


Ooh, cuánto tiempo se perdió en depurar simulaciones de colisión de zengs ... Por supuesto, en Unity, todo el cálculo del movimiento de los cuerpos funciona de forma inmediata. Y en el prototipo crudo del juego, fue explotado con entusiasmo: los zenges rodaban por el escenario con gravedad cero, rebotaban entre sí y desde los lados, y no había dudas sobre sus trayectorias después de las colisiones. Pero llegó el momento crucial para dibujar los vectores zengi, y de repente se reveló que el rebote real de los zenges entre sí (el arco gris en la captura de pantalla) es diferente del esperado (línea blanca):

imagen
Rutas de rebote zenga esperadas y reales

Zeng se desvió del camino previsto debido a demasiada fricción y el momento de torsión resultante, cuya causa por el momento seguía siendo un misterio. El hecho es que cada zeng es un GameObject generado al cargar la escena, al que se agregan los componentes Rigidbody 2D y Circle Collider 2D.

Rigidbody, un "cuerpo sólido", define la física del comportamiento de un objeto en el mundo del juego: masa, resistencia, gravedad y otras características útiles. Colisionador: el componente responsable de calcular los límites del objeto y las colisiones con otros cuerpos. Ambos componentes tienen la propiedad "material" para establecer el coeficiente de fricción y elasticidad.

Entonces, arreglar el rebote incorrecto de zengs se redujo a la pregunta: si dos componentes están unidos a gameObject, Collider y Rigidbody, y cada uno de ellos tiene la propiedad "material", ¿qué material se aplicará?

imagen
Propiedades del material del colisionador y del cuerpo rígido en la unidad

Entonces, si Collider no tiene un material definido, entonces se usa el material Rigidbody. Si está configurado, entonces la propiedad prioritaria del Collider. Para el material no especificado explícitamente, el Rigidbody utiliza un material con valores predeterminados de elasticidad y fricción. Por lo tanto, el error fue la suposición errónea de que la propiedad Rigidbody con fricción cercana a cero se aplicaría con el material Collider especificado. Y ella valía la pena el sábado por la noche.

2. Se comporta de manera diferente en diferentes dispositivos.


El comportamiento diferente en dispositivos con diferentes versiones de la API apareció por casualidad al representar sombras de texto. Un texto con el nombre del juego fue agregado a la escena. El componente Shadow se adjunta al texto:

imagen
Componente de sombra agregado al texto en Unity

Color oscuro, transparencia. Sombrea perfectamente el texto en todos los dispositivos ... excepto en el viejo Android con API 15, en el que la sombra se veía obstinadamente azul pálido en lugar de azul:

imagen
Sombra dibujada incorrectamente en la interfaz del juego

No fue posible determinar rápidamente la causa del error y las soluciones, por lo que en aras de la velocidad de desarrollo, la sombra tuvo que ser abandonada.

En pocas palabras: mantente alerta. En diferentes dispositivos, incluso los elementos triviales del juego pueden verse y funcionar de manera diferente. Esto a menudo se manifiesta en pequeñeces apenas perceptibles.

1. No se inicia en un dispositivo específico


La noche anterior al lanzamiento (¿o cómo es habitual comenzar tales historias?) Se descubrió que en uno de los teléfonos inteligentes el juego básicamente no quiere comenzar. Tuve que aferrarme con urgencia al depurador y ver qué salió mal.

Por diseño, el juego se lanza por la fuerza en orientación horizontal. En Unity 2017, la configuración de orientación predeterminada (Editar -> Configuración del proyecto -> Reproductor -> Orientación) es responsable de esto:

imagen
Establecer la orientación de la pantalla en Unity

Al exportar a un proyecto para Android Studio, la configuración de orientación predeterminada se convierte en la propiedad screenOrientation especificada en el manifiesto:

android:screenOrientation="landscape" 


Parece que lo que podría salir mal? De hecho, en todos los dispositivos, el vuelo es normal ... Excepto para Android 8.0.0 (API 26), en el que la aplicación se bloquea cuando se inicia con la excepción:

java.lang.IllegalStateException: Only fullscreen opaque activities can request orientation

Se soluciona desactivando la transparencia en el estilo especificado en styles.xml:

 <item name="android:windowIsTranslucent">false</item> 


Accidente detectado de forma absolutamente accidental que conduce a la moralidad: la corrección de la operación debe verificarse en todas las API compatibles con la aplicación.

Sobre promoción y monetización, o "Hoy entendí mucho"


Después de preparar un grueso paquete de materiales promocionales para su colocación en la tienda de Android, bajo los alegres gritos de un programador y diseñador, tuvo lugar un lanzamiento. Sin embargo, pronto quedó claro que, además del nombre del juego en Play Store, era imposible de encontrar. El Zengo, como un galeón hundido con doblones de oro, descansaba en algún lugar en el fondo del océano de juegos y estaba esperando a su buzo ... Al parecer, los buzos no se sumergen tan profundamente.

Cero descargas por semana fue en contra de las expectativas. Observación: las expectativas no eran fantasías sin fundamento, sino que se basaban en experiencias reales, aunque desactualizadas. En 2014, cuando Google Play estaba expandiendo activamente y atrayendo a nuevos desarrolladores, el autor publicó un juego de lógica sin precedentes. Y aunque el objetivo principal de la publicación era el uso personal para fiestas con amigos y colegas, y el diseño dejaba mucho que desear, los asuntos del juego fueron sorprendentemente fluidos. Apareció en la sección de noticias, desde donde se arrastró a los mejores juegos por categoría en Rusia y países vecinos. Y todo esto sin el más mínimo esfuerzo.

Desde entonces, Google Play se ha desbordado de aplicaciones, los desarrolladores han comenzado a colocar grandes sumas para evacuar desde la parte inferior hasta avanzar a la parte superior, e intenta dar a conocer el juego para que, de algún modo, un usuario potencial pueda encontrarlo y encontrarse con un negocio.

imagen
Negocio de elefantes. Prince está esperando una aventura no planificada

Empresas que ofrecen servicios de promoción, reseñas de videos de YouTube, reseñas en portales de juegos, publicidad en varias plataformas ... Si no rechaza absolutamente la promoción paga, se sorprenderá gratamente por la cantidad de formas de deshacerse de un par de salarios con estilo. Pero, ¿qué tan efectivos son, en qué combinaciones y proporciones dan el mejor efecto para un juego en particular? La pregunta permanece abierta.

Los métodos gratuitos probados, que incluyen temas en foros de juegos, relaciones públicas moderadamente insolentes en redes sociales y propaganda desenfrenada en el círculo de la comunicación, arrojaron resultados modestos. La conclusión se sugiere a sí misma: si realmente piensa en la promoción del juego, hágalo con anticipación y asigne los recursos apropiados. Al mismo tiempo, todos los esfuerzos pueden reducirse a cero, si no se mantiene al tanto de las tendencias del mercado y las características del público objetivo.

Epílogo


¿Es posible en un par de meses lanzar el juego usted mismo o un equipo pequeño, sin perjuicio del trabajo y la vida personal? Y así, sin superación personal y "triunfo de la voluntad" sobre la falta de sueño. Si, bastante! Y con los motores modernos, un IDE y stackoverflow, es más fácil que nunca.

Pero si el desarrollo de un juego independiente no es un fin en sí mismo, y surgen preguntas sobre su promoción y monetización, entonces ... hay matices. Promoción: un monstruo con tres cabezas: una ciencia separada en la que un pequeño error de cálculo ya es una pérdida; un proceso continuo que necesita monitoreo constante; agujero negro por tiempo, esfuerzo y dinero.

Y finalmente El desarrollo independiente no se trata solo de código, gráficos y un curso de geometría que sería bueno releer. También es comunicación con personas entusiastas que están listas para dejar comentarios e incluso participar en el proyecto con puro entusiasmo. Por ejemplo, el desarrollador dio una gran cantidad de consejos y críticas sobre el juego y la interfaz de usuario, que generalmente es genial sobre las muertes casuales. Y la música para la segunda versión de El Zengo fue creada por el compositor, a quien le gustó el juego. Si te esfuerzas y buscas, seguramente hay quienes quieren probar el juego y dejar un comentario. Y con una buena selección de herramientas y observando las reglas simples del fanático desde el desarrollo, simplemente se proporciona la inspiración del lanzamiento y no un bombeo débil de experiencia.

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


All Articles