Un millonésimo tirador desde cero: una ruta de desarrollador independiente

Durante los últimos cinco años, he administrado programas educativos en la industria del juego en la Escuela Superior de Informática Empresarial de la Escuela Superior de Economía . Realizamos muchos eventos gratuitos con oradores interesantes, reuniendo una audiencia a través de Leader-ID. En una de las últimas reuniones, se escuchó otra historia genial, donde varias personas de ideas afines lanzaron un juego de lanzamiento que trajo más de 200 mil dólares.

La historia es buena porque, además del final feliz, también describe fallas importantes, gracias a las cuales se obtiene una experiencia invaluable. Y lo más importante: los muchachos están felices de compartir todos los detalles y la lista de rastrillos que recolectaron en este largo viaje.


Conoce a Dmitry Svetlov. Durante más de 10 años, dirige su propio estudio de visualización arquitectónica: 3Dmode. En algún momento, cuando las cosas ya iban bien en la empresa, tenía la necesidad de conquistar nuevas alturas, y decidió volver a su pasión infantil: la creación de juegos.

Los siguientes tres años, él, junto con un amigo, se dedicaron a desarrollar un juego de disparos de arriba hacia abajo basado en un navegador. Trabajaban principalmente por las tardes. El año pasado, un amigo estudió el código todo el tiempo. Pero el proyecto como resultado no salió a la luz. Luego siguió un segundo intento, el tirador de realidad virtual Sacralith: la historia del arquero, y resultó ser exitoso.


A continuación hay un recuento de la conferencia de Dmitry, en la que contó muchos detalles interesantes y señaló cinco obstáculos principales que el equipo tuvo que enfrentar en el camino hacia un lanzamiento exitoso.

Optimismo


Suena extraño, pero de hecho, se convirtió en la razón principal del fracaso del primer proyecto. Cuando Dmitry, junto con su programador amigo, comenzó a hacer un tirador de arriba hacia abajo basado en un navegador, no tenían dudas de que todo saldría bien.


Pero a pesar de su rica experiencia en trabajar con gráficos en 3D y la experiencia de un amigo programador, los chicos no lograron lanzar el juego. La creencia en el éxito los cegó.

Si miras hacia atrás, puedes ver cuántas imágenes de "personas seguras que representan claramente el objetivo final y lograron alturas sin precedentes". Dichos personajes se replican incansablemente en el espacio de los medios, promoviendo una idea simple: "lo principal es creer, y todo saldrá bien". Sin embargo, hay un defecto significativo en este enfoque.




Esquema de desarrollo de competencias El diagrama anterior indica las etapas por las que pasa cada especialista. Obviamente, la mayoría de los que creen ciegamente en el éxito están en la primera etapa. Pero la realidad es que las personas que logran resultados no son tan talentosas como trabajadoras. Pero esto tampoco es lo principal.


Para hacer un proyecto, necesita poder hacer proyectos. Fue precisamente comprender cómo "comenzar", cómo "hacer" y cómo "completar" un proyecto que no era suficiente para lanzar su primer juego.

El pesimismo saludable es exactamente lo que viene con la experiencia. Y no se trata de la fe en la propia fuerza, sino de la precaución y la prudencia banales. "Novato", al salir de casa, llevará a un jugador con él, mientras que "profesional" tomará un paraguas, pastillas para el dolor de cabeza y, posiblemente, armadura corporal.

Expectativas irrealistas


Al comenzar un proyecto, está dedicando una cierta cantidad de tiempo y recursos para el desarrollo, así como representando ingresos y gastos potenciales . Es bueno cuando las expectativas y los números reales están cerca, pero para la mayoría de los desarrolladores independientes esto está lejos de ser la primera vez. Cuando la gente hablaba de la muerte del flash y la extinción de la era de los juegos de navegador, todavía creían en el éxito vertiginoso.

Había algo similar con Sacralith. Uno de los principales participantes, incluso cuando le mostraron las métricas actuales, creía ciegamente que el proyecto traería millones de dólares. Y eventualmente trajo millones, pero rublos. Por eso, dejó el equipo.

Ingresos de Sacralith


Para muchos, esta es la parte más interesante de la historia.


Ingresos en Steam

Mirando estos números, vale la pena recordar que solo la mitad de esta cantidad lo alcanzará. Steam dejará 30%, IVA 5%, luego tenemos control de divisas y una serie de otros impuestos.


Ingresos en la tienda Oculus Las

ráfagas en los gráficos son ventas organizadas por nosotros con descuentos del 35-50%. Y en PS Store, las cosas son aún peores: no hay forma de vender nada sin promoción. Como resultado, en total en todos los sitios actualmente se venden unas 12 mil copias.

Inicio del desarrollo y costos del proyecto.


El desarrollo de Sacralith: The Archer`s Tale comenzó en 2007. Al mismo tiempo, Dmitry tomó un curso de reciclaje profesional " Game Project Management " en la Escuela Superior de Economía, Escuela Superior de Economía, porque en algún momento se dio cuenta de que era necesario comenzar con la administración.

Los costos para todo el proyecto fueron los siguientes:


El

cálculo del presupuesto de desarrollo es muy aproximado. Si Dmitry se pagara un salario de al menos 150 mil rublos. por mes, el costo total de desarrollo aumentaría en más de tres millones.

Se han utilizado una variedad de técnicas para optimizar los costos. Por ejemplo, para grabar animación facial, la compañía fabricó su casco, que cuesta solo 70 € (el original cuesta 1800 €).


También se ensambló un escáner facial especial (costo 80,000 rublos). Anteriormente, escanear un personaje en el estudio costaba 30,000 rublos.


Ejemplos de caras de personajes

Tiempo y problemas con su cálculo.


Sobre el ejemplo del trabajo de su estudio 3Dmode, Dmitry habló sobre la planificación. En los primeros años de trabajo, el estudio a menudo no se mantenía actualizado. Dmitry decidió realizar un estudio interno e introdujo un sistema de seguimiento del tiempo en el que las tareas se dividían en categorías.

Inicialmente, el proceso de evaluación del tiempo requerido fue el siguiente:


Después de analizar el costo real del tiempo, el circuito comenzó a verse así:


El tiempo real de producción ya era de 12 días.

No tuvo en cuenta el tiempo de "cambios internos", las expectativas de los comentarios de los clientes. Hubo un coeficiente de x1.2 para el seguro contra situaciones imprevistas, por ejemplo: un especialista clave se enfermó, el render se bloqueó, el servidor se cortó ...

Y todo esto sucedió con tareas previamente conocidas y cumplidas. En el desarrollo del juego, todas las tareas resultaron ser nuevas. Por ejemplo, durante la grabación de las animaciones de movimiento del monje para Sacralith, los chicos colaboraron con el estudio Pilot (esta es la compañía que creó los personajes populares Hryun y Stepan). A primera vista, todo era natural, pero después del render final, la escena parecía de alguna manera antinatural. Durante mucho tiempo no pudieron entender por qué. Después de dos semanas de búsqueda, se encontró la razón. Resultó que no había problemas con la animación del cuerpo, pero todo era la apariencia antinatural del héroe.

El equipo tuvo que desarrollar urgentemente un sistema de carácter de mirada procesal. Dependiendo de la situación, el héroe podría mirar claramente la cámara, los puntos clave de interés o simplemente bajar la mirada. Nadie pensó que tomaría otro mes de desarrollo. Y había muchos de esos "detalles" en el camino al lanzamiento.

Entropía y neuroticismo de planificación


La planificación es la herramienta más importante para trabajar con proyectos complejos. Pero el valor del plan en condiciones de incertidumbre total e imprevisibilidad tiende a cero. Es mucho más importante ver claramente su destino que seguir cuidadosamente una ruta previamente establecida. Si cada participante en el proceso comprende lo que está haciendo, por qué lo está haciendo y cuándo necesita terminarlo, el desarrollo avanza.


Al crear Sacralith, Dmitry reemplazó el plan con un esquema condicional que consistía en objetivos simples. Por ejemplo, el objetivo final era lanzar en febrero y 5,000 ventas a un precio de $ 20 al comienzo.


El esquema de objetivos

El siguiente principio que utilizó el estudio fue el principio de MVP (producto mínimo viable), es decir. creando un producto mínimamente viable en cada etapa de desarrollo. Con este enfoque, crea un disco de trabajo, que mejora aún más en todos los indicadores principales.

En la imagen a continuación, puede ver que ya en la primera etapa debería aparecer una máquina viable, que posteriormente "crece" con detalles.


En el ejemplo de Sacralith, el equipo identificó la siguiente pirámide de desarrollo, que consta de características, ventajas y valores:

  • Características (características del juego): tiro con arco, sistema de bombeo, enemigos y escenas cortadas.
  • Ventajas (en relación con los competidores): buena física de flechas y gráficos coloridos.
  • Valores (ideas principales): el simulador de arquero más sangriento de la Edad Media.

Después de identificar estos componentes, puede comenzar a trabajar en MVP. Es importante centrarse en los valores del proyecto. Cuanto mejor los demuestre en una etapa temprana de desarrollo, mayores serán las posibilidades de éxito de su producto.


Puede comenzar con las características, como se muestra en la pirámide superior izquierda, pero esta es una mala opción. La opción normal es cuando creamos características que pueden demostrar valor (abajo a la izquierda), y la mejor opción es cuando pensamos en cómo demostrarnos valor (abajo a la derecha).

Testarudez


Calidad útil en los negocios, pero si hablamos de desarrollo independiente, a veces se interpone. Echemos un vistazo al ejemplo de creación de animaciones de maquetas para Sacralith. Para grabarlos, necesitas un equipo especial y actores que representen los movimientos que necesitas.


Grabar maqueta de animación. Uno de los actores de la foto, el fundador del estudio Pilot,

Dmitry dijo que estaba tratando de obtener la máxima seriedad en los movimientos de los actores. Y, a pesar de todos los esfuerzos, en los gestos de los actores se deslizaron notas de familiares para ellos Khryun y Stepan. Sin embargo, fue esta naturaleza cómica de los personajes lo que permitió a los desarrolladores echar un nuevo vistazo al proyecto.

Como resultado, el humor apareció en el juego, los personajes se volvieron más carismáticos. Sí, todas estas decisiones aparecieron espontáneamente, pero el producto final solo se benefició de tales cambios. Por lo tanto, en condiciones de recursos limitados, es importante seguir el flujo y, a veces, incluso cambiar el destino. Por supuesto, si cree que esto beneficiará al producto final.

Una historia similar fue con los modelos de personajes. A diferencia del esquema de desarrollo clásico, el equipo de Dmitry utilizó el enfoque exactamente opuesto:

  1. los chicos recopilan una base de datos de activos prefabricados (sonidos, modelos 3D, alrededores) que están disponibles o disponibles para su compra en una tienda especializada;
  2. sobre la base hacen el diseño de niveles y personajes;
  3. elaborar el guión y finalizar la configuración (un estilo de juego único).


Tubería clásica (esquema de desarrollo)


Tubería elaborada por Sacralith,

es decir el desarrollo no procedió del plan y el escenario, pero el escenario se adaptó a los modelos disponibles y otros recursos. Este enfoque ha ahorrado mucho tiempo y dinero, por lo que el producto final fue capaz de generar ganancias para los creadores.

Primeras reseñas: cebollas reales, pero todos piensan diferente


El trabajo en el producto no se detiene después del lanzamiento del juego en la plataforma (Steam y otros). Las primeras revisiones (especialmente negativas) deben percibirse adecuadamente, tratando de encontrar un núcleo racional. E incluso si fue escrito solo unas pocas palabras, debe preguntarle al autor qué lo confundió exactamente en su producto.

Por ejemplo, después del lanzamiento de Sacralith, los desarrolladores recibieron varias críticas enojadas sobre las cebollas poco realistas. Como resultó del diálogo con el usuario, el problema era la ubicación de la flecha en relación con el eje. En el juego, este momento se realizó históricamente cierto, como en la Edad Media. Pero en los arcos modernos, el "estante" para la flecha está a la izquierda. Debido a esto, los usuarios se indignaron, diciendo "¡los desarrolladores nunca han tenido un arco en sus manos!" Rehaciendo rápidamente este detalle, los muchachos inmediatamente recibieron un comentario positivo de la audiencia. Logramos convertir varias críticas negativas en positivas, lo que resultó en las necesarias 90% de críticas positivas.



Robo


Seguramente, muchos de ustedes temen que una idea brillante pueda ser robada. Si regresa al comienzo del artículo y recuerda las palabras de Edison, comprenderá que no debe temerle en absoluto. Por el contrario, para mejorar y hacer un producto más exitoso, es importante informar a todos sobre su idea y recoger cuidadosamente las críticas, y luego mejorar el desarrollo.

Resumen


Espero que esta historia y la experiencia de Dmitry sean útiles para aquellos que están desarrollando su proyecto de juego o están pensando seriamente en ello. Lo principal es superar su autoconfianza, escuchar críticas y métricas reales.

Si está interesado en ver su actuación en vivo, donde hay un poco más de detalles, está aquí .

All Articles