Comprensión de corte vertical

o cómo crear iteraciones de la función base de tu juego.

En cuanto a la gestión en general y de priorización de proyectos en particular, surgen

muchas dudas entre los desarrolladores, especialmente en pequeños equipos o indias
que no tienen la figura clara de un productor. Esto no se aplica al desarrollo del juego,
pasa a otro tipo de proyectos también, pero es cierto que dependiendo de la naturaleza
de lo que está creando es más o menos intuitivo de manejar. Estoy hablando de las
típicas preguntas como "¿qué construir primero?", "Necesito tener el juego programado
antes de que puse finales gráficos en él?", "¿Cómo que dividido el trabajo en tareas más
pequeñas?".

Nota: Este artículo no habla de la "rebanada vertical" como el concepto común de la

industria sobre generar una demo vertical para mostrar a los editores o los actores, sino
como un concepto continuo desarrollo ágil para priorización inteligente.

El problema
En este punto, supongo la mayoría de la gente cree tareas pequeñas de su gran tarea (el

juego) y hacer un seguimiento de ellos, esperemos que con HacknPlan (si no

Planifique su trabajo como este, pero gustaría probar, te recomiendo leer este artículo).
Sin embargo, muchas personas todavía no saben qué orden seguir para ensamblar
todas estas piezas pequeñas juntas. Desarrollo de software clásico (y juegos de
desarrollo demasiado) utilizando el modelo de cascada popularizó la idea de dividir el
trabajo en piezas técnicas (motor de programación, programación en jugabilidad,
gráficos, sonido...) y desarrollo independiente basado en un contrato previamente escrito
(el documento de requisitos o GDD para juego dev), con la idea de ponerlos juntos en
algún momento cuando avanzaron bastante. Pero, como se imaginarán, esta
metodología tiene defectos muchos y muy importantes:

 Si no pones cosas a trabajar juntos pronto, tienes altas probabilidades de desarrollar

problemas inesperados en el futuro. Marcadores de posición y cosas temporales
trabajan bien para la creación de un prototipo, pero más tiempo mantenerlos en el
proceso de desarrollo, más adelante encontrará problemas derivados de la sustitución
con lo real.
 Más adelante tienes cosas final (o semifinales) trabajando juntos como algo "tangible",
más adelante realmente sabrás lo que es la sensación del juego, la experiencia del
usuario, lo que transmite al jugador. Cuanto antes usted tiene algo parecido al
resultado final mejor, porque usted puede validar trabaja bien como un todo.
 Si presenta todo en paralelo en un nivel funcional (funciones) y uno de estos requisitos
el cambio o incluso se elimina (y esto sucede todo el tiempo, especialmente con cosas
creativas), ya perdió el trabajo. Tener un contrato fijo es bueno nunca porque asume
que todo va a trabajar al final y esto podría conducir a decisiones equivocadas.

Estos problemas podrían ser incluso peores en equipos muy pequeños o los
desarrolladores individuales, donde la multitarea es tan pesada. Imagino eres un lobo
solitario y está diseñando el juego, programación y hacer el arte también. Hacer un
prototipo de la mecánica principal del juego con el arte de marcador de posición y
validar es divertido, así que adelante. Si su habilidad principal es la programación,
puede tener la tentación de aplicar muchas características tiene en mente, refactorizar el
código y construir una gran infraestructura, trabajar sobre el rendimiento, en muchos
mecánicos que no son core... manteniendo los marcadores de posición. "El juego está
casi listo, sólo necesito crear el contenido". Yo mismo ha dicho en el pasado y fue un
gran error. Me fui lejos en el desarrollo de la mecánica y material técnico sin el trabajo
en diseño gráfico o nivel (que era muy importante para el juego como un puzzle), pero
me di cuenta demasiado tarde que la 'apariencia' del juego no era el que esperaba y los
problemas de diseño que habría visto antes si había creado una experiencia completa
incluyendo diseño de real nivel manera anteriormente en el proceso. Terminé
renunciando en el proyecto, lamentablemente.

Una solución de
No hay ninguna bala de plata para facilitar la gestión de proyectos, pero hay formas de
organizar el trabajo que puede ser adecuado para usted si usted ya experimentó
problemas como los mencionados anteriormente (o desea verlos venir y evitarlos). Por
lo tanto, ¿cómo conseguimos la apariencia y sensación del juego pronto y al mismo
tiempo ser capaces de construir el juego paso a paso de manera iterativa? Mediante la
construcción de lo que se denominan sectores verticales del juego.

Lo que yo llamo rebanada vertical es similar al concepto de MVP (mínimo producto

viable) desde el método lean startup, donde se crea la pieza más básica de software que
da algún valor para el usuario, con el fin de validarlo, e iterar sobre él otra vez y otra
vez, recibiendo retroalimentación durante el proceso. Si usted sabe sobre desarrollo ágil
de software, esto sonará familiar ya que es un concepto similar aplicado desde un nivel
alto, punto de vista funcional. Pero incluso si usted utiliza Kanban, Scrum o cualquier
otra metodología ágil en este momento, usted puede construir sus iteraciones hacer
rodajas horizontales, agrupar funcionalidades por temas técnicos en lugar de
funcional (frecuente cuando se planea el proyecto por personal técnico).

¿Significa esto que estamos hablando de crear una versión básica del juego para ver si
es divertido? ¿No es un prototipo? Bueno, no exactamente. Una ayuda de prototipo te
das cuenta si tu proyecto vale la pena desarrollar con el mínimo, que no necesariamente
incluye muchos aspectos del juego que sería importante para un MVP. Estamos
hablando del juego estúpidamente simple mínimo que podría crear (no importa cómo
básicos parece), construido con la calidad de un producto final. No significa que
usted necesita para crear la versión definitiva del personaje principal de su juego
durante la primera iteración, pero al menos una aceptable que podría quedarse si no hay
posibilidad de mejorarlo. Entonces, lo hacemos una y otra vez y otra vez.
Gradualmente desarrollamos rebanadas verticales del juego basado en
características y ponerlos al lado del otro.

¿Qué estamos haciendo aquí? Estamos validando estas piezas y garantizando. Si

construimos a un mecánico, con un jugador de carácter, de entrada y algunas otras
cosas, nos estamos asegurando que funcionalidad es seguro y está listo para conseguir
libertad. ¿Podría ser mejor? OK, bien, todo lo puede. Puede mejorar o pulir más tarde si
tienes la oportunidad de. Tienes algo aceptable, algo que, en caso de que gastar todo su
presupuesto ejecuta fuera de plazo o cualquier circunstancia te puede pensar, usted
puede ofrecer y está bien. Características de corte es tan común cuando un proyecto
comienza a tener problemas de calendario y dentro de presupuesto, pero si usted tiene
listos 10 características y 10 hacer, es más fácil decidir lo que hacer que tener 20
características al 50%.

Un ejemplo práctico
Utilicemos un ejemplo para ilustrar esto. Super Mario Bros, de imaginar que no es un
juego que supongo que nunca ha utilizado como ejemplo para un artículo relacionado
del desarrollo del juego. Para simplificar el ejemplo, supongamos que hay 3
desarrolladores, Laura el programador, mate el artista y Sven el diseñador de niveles,
creando este juego por primera vez.

En una iteración basada en la técnica:

 Laura el programador, con el prototipo en una mano y los GDA en el otro, comienza a
construir toda la mecánica del juego: correr, saltar, romper los bloques con la cabeza,
la estrella de encendido, la seta, los enemigos... Matt no tienen el arte listo todavía,
pero ella sabe que finalmente será como se define en el documento, por lo que ella
continúa usando el arte de marcador de posición.
 Mate el artista, después la GDD, comienza a crear todos los sprites del juego. Como se
siente más natural, empieza con Mario, que consiste en varias animaciones: corriendo,
saltando, cada vez más grande, cada vez más pequeñas, lanzar bolas de fuego...
Después de que haya terminado, él irá para el siguiente activo en línea, digamos que
los azulejos de los niveles y también algunos enemigos y fondos.
  Sven el diseñador de niveles, basada en el documento de diseño, comienza a diseñar
los niveles usando lápiz y papel. Que él sabe que tendrá varios tipos de azulejo,
objetos interactivos y enemigos para componer la diversión 4 niveles por mundo.
 En algún momento, Matt ha terminado de la hoja de sprites de Mario, con todas las
animaciones y cosas. Ahora Laura puede reemplazar la versión provisional del sprite o
feo marcador de posición con una marca nueva. Ella también desarrolló toda la lógica
para los enemigos, pero sin embargo, no están listos como Matt también está creando
azulejos para empezar a construir los niveles que Sven está creando. Tiene 8 niveles
diseñados en papel ahora haciendo uso de todos los elementos que tenía disponibles
como se indica en el GDD.
 Ahora, puesto que la vida es dura y la mierda ocurre, se corta el presupuesto y
necesitan recortar características para liberar algo más pequeña en alcance de lo que
fue bellamente diseñado en papel al principio. ¿Qué hacer ahora? Deciden cortar la
característica que hace que Mario lanzar bolas de fuego, ya que no es como base como
otros, que significa la animación creado Matt se desperdicia. También piensan que tal
vez la barra giratoria de fuego y el cañón de bala podría ser quitado demasiado, y no
empiezan a construir esa parte pero lo no es doloroso! Pero adivina qué, Sven
diseñado ya varios niveles que hacen usan de esos elementos, así que les corte
significaría que tiene que rediseñar los niveles haciendo uso de otros elementos.
Usted consigue el punto.

 En una iteración de la función basado en:

 El equipo decide que la primera rebanada vertical del juego que van a construir es un
nivel donde hay solamente una tierra plana con agujeros, así que Mario puede correr,
saltar sobre ellos y llegar al final de la etapa.
 Laura implementa (o refina, que probablemente se habría implementado para el
prototipo) la mecánica de correr y saltar. Profundamente son probados y equilibrados
para ser lo suficientemente bueno para un juego final. Funcionalidad pequeña, pero
muy pulido.
 Mate, en lugar de construir el activo todo de Mario, sólo crea dos animaciones:
correr y saltar. También crea una imagen de fondo y algunos azulejos para el suelo.
 Sven no tiene un gran trabajo por hacer en esta iteración, pero crea un nivel pequeño
con agujeros que desafía al jugador en los diferentes saltos que pueden hacer. Este
nivel probablemente se descartarán en el final, pero se ha implementado con la
calidad de la producción final no importa lo simple que es. Da una sensación
temprana acerca de los saltos y cómo pueden ser utilizados para niveles más
complejos, puede ser incluido como un nivel de tutorial si quisieran.
 El equipo consigue este pequeño segmento del juego, que se ve bien y se siente bien
en sus manos, incluso aunque es un muy simple pseudo juego. Han garantizado su
juego tendrá funcionalidad que funciona bien de salto y allí será de retos con
agujeros.
 Seguir adelante con más iteraciones: un segmento vertical del bloque rompiendo
funcionalidad con todos los gráficos implicados y un nivel que utiliza, luego otra más
para el primer enemigo y la posibilidad de saltar sobre ellos... Una vez bastante
características, algunos niveles pueden conseguir su forma final como normalmente
estas características y los elementos se introducen secuencialmente y paso a paso en
el juego.
 Pero bueno, en algún momento la mierda ocurre demasiado y se corta el presupuesto.
¿Qué le cortan ahora? Bueno, están siguiendo la GDD, pero puesto que han sido
trabajando en rebanadas verticales y asegurándoles, que ya tienen algo, ser mejor o
 peor, está en un estado de 'cerca de envío'. Si quieren cortar en características como el
lanzamiento de la bola de fuego o el cañón del bala, pueden, como estas rebanadas
verticales no han comenzado aún a cualquiera de los aspectos técnicos del
desarrollo, por lo tanto, ningún trabajo se desperdicia.

En este ejemplo se simplificaron demasiado, pero creo que se pueden ver los beneficios
de este enfoque. Cada iteración o milestone como una versión reducida de su juego,
en vez de como una versión inacabada del mismo y reducirá las posibilidades de
sufrir las consecuencias de incidentes durante el desarrollo, o al menos minimizarlos. Es
importante destacar que, para este proceso, iteraciones no deberían durar mucho tiempo,
o podría tener internamente los mismos problemas que hemos descrito para el proyecto
(muchas cosas en paralelo que todavía no están montados juntos).

Conclusión
Como dije al principio no hay ninguna bala de plata y probablemente esto no podía (y
no debería) ser aplicado 100% de las veces, pero iterativo desarrollo es buena en
escenarios de incertidumbre, como abarca las posibilidades de cambio como una
parte natural del proceso de . Hay otras prestaciones interesantes de este enfoque:

 Es el camino a seguir para el acceso anticipado, como usted no debería enviar un juego
inacabado, pero uno menos en alcance, de modo que los jugadores pueden obtener
una comprensión real del juego.
 Ya tienes tu juego en un estado 'potencialmente enviar' desde el principio, tienes
bueno mirando a mostrar pronto, lo que es bueno para empezar a construir una
comunidad, generar interés en el juego o preparar una campaña de crowdfunding.
 Usted puede comenzar QA pronto en el desarrollo, para que distribuya la carga a lo
largo del proceso y no se hace un cuello de botella en el extremo. Cada rebanada
vertical debe analizarse como parte de la iteración, verifique que es lo suficientemente
bueno como para la entrega.

Eso es todo, espero que ha disfrutado de este artículo y tienes algunas ideas para
mejorar la gestión de su proyecto.

¡Planificación feliz!