Tu estás aquí: ¡Bienvenido! » Referencia » Artículos » Cómo Crear un Prototipo de Juego en Menos de 7 Días: parte 2/3
Usuario
Buscar páginas
Esta Pagina
General

Cómo Crear un Prototipo de Juego en Menos de 7 Días: parte 2/3

Este artículo se encuentra en proceso de traducción.

Si quieres sumarte anuncialo aquí:

2. Diseño: Creatividad y el Mito de las Lluvias de Ideas

Una gran idea aparece en una fracción de segundo, pero esperar a que esa luz llegue puede ser insoportable. No se puede forzar la aparición de una gran idea, pero esta sección puede ayudar a cultivar tu creatividad.

Una Lluvia de Ideas en Forma tiene un Porcentaje de Éxito del 0%

En serio lo intentamos, ¡de verdad queríamos que las lluvias de ideas funcionaran! Programamos “reuniones de lluvias de ideas”, usamos marcadores de colores diferentes y notas “post-it” de gran tamaño colocadas sobre pizarrones, incluso con frases motivacionales como “cielo azul” para ayudar a que nuestro pensamiento fluyera. Pero al final, de todos los juegos que creamos, ni uno solo fue resultado de reunirnos como grupo en una sesión de lluvia de ideas.

¿Por qué no? Fue muy impactante para nosotros, pero tras mucho investigar, parece que simplemente no es posible programar la creatividad. No se puede decir “¡Hey todos, reunámonos a las 4:15 para realizar una lluvia de ideas, y a las 5:00 tendremos cuatro ideas geniales para comenzar a trabajar!

Pero no es imposible. Aún hay (al menos) dos cosas razonables que se pueden esperar de una sesión de lluvia de ideas bien conducida. La primera, por supuesto, es que pone a todo el mundo a pensar. Y quizá más tarde, quizá de camino a casa, o en la ducha, o mientras sacas a tu mascota a pasear, una idea brillante emergirá de tu cabeza. O quizá no. Pero hasta donde podemos decir, tu misterioso cerebro desarrolla mucho pensamiento cuando menos lo esperas.

La segunda forma en que encontramos útil la lluvia de ideas fue cuando había algo concreto sobre lo cual discutir. Por ejemplo “¿Cómo podemos mejorar esto?” en contraste con “¡Hey, propongamos algo arbitrario! Teniendo una idea de juego a medio formar, por ejemplo, en cierta manera fue útil que el resto del grupo le exprimiera el jugo. Todos son mejores críticos que el mismo autor ¿verdad?

Reúne Arte y Música Conceptuales para Crear un Objetivo Emocional

Como alternativa a la lluvia de ideas, encontramos que reunir arte y música con algún tipo de significado personal fue particularmente fructífero. La gente comentó que muchos de los juegos como “Gravity Head” o “On a Rainy Day” generan un fuerte estado de ánimo y tienen mucho atractivo emocional. No es coincidencia. En este y en muchos otros casos, la banda sonora y el arte inicial crearon un sentimiento combinado que influyó muchísimo en las decisiones sobre el tipo de juego, la historia y el arte final.

En palabras del señor Gabler: “La idea tras “Tower of Goo” surgió mientras escuchaba (por alguna razón) el inicio de “Tango Apasionado” de Astor Piazzolla depués de caminar a casa, y tuve en la mente esta visión borrosa de un pueblo al atardecer donde todos salían de sus casas, cargando sillas, mesas y cualquier cosa que pudieran para contruir una torre gigante en el centro de su ciudad. No se porqué exactamente, pero la gente quería trepar arriba y más arriba - pero no eran muy buenos ingenieros civiles por lo que había que ayudarles. El prototipo final terminó en algo más atractivo, y reemplacé la música final por la más animada “Libertango” de Piazzolla, he aquí un caso donde un objetivo emocional inicial básicamente creó todo el juego.”

Tango y unos cuantos hombres trepando arriba y más arriba…

Simula en tu Mente - Pre-prototipa el Prototipo

¡Es fácil! Todo lo que debes hacer es imaginar a la audiencia de tu juego dicendo “¡Guau!” Y entonces trabaja hacia atrás y llena los espacios en blanco. ¿Qué hace que disfruten tu juego? ¿Qué emociones están experimentando? ¿Qué está ocurriendo en el juego que los hace sentir de esa manera?

En cada uno de nuestros juegos más exitosos, nunca fue sorpresa que fueran divertidos al jugar - en los mejores casos, sabíamos que la idea era sólida antes de tocar una línea de código, porque con anterioridad habíamos corrido una simulación del juego como un pequeño experimento mental. Lo inverso también funciona. No hay juego que accidentalmente o sin esperarlo se volviera exitoso. Siempre lo supimos con anterioridad. (Desafortunadamente esto no nos alejó de desarrollar ideas definidas a medias.)

Simular en tu mente también hace que el desarrollo del prototipo final sea realmente sencillo. Ya que sabes exactamente lo que estarás haciendo, no perderás tiempo realizando costosas “decisiones de diseño” a prueba y error revolviendo código.

Un miembro del equipo admite: “No era raro que pasara los primeros 3 o 4 días de la semana haciendo al tonto viendo videos musicales en busca de “inspiración”, o tirado boca abajo en un sillón oyendo música y ocasionalmente llenando de sangre mi cabeza con algunas pésimas simulaciones. Finalmente el Jueves o Viernes daba vueltas en pánico porque aún no tenía ni idea de lo que entregaría el Lunes, por lo que tomaba las ideas más fuertes y las modificaba en base a la que fuera mi obsesión de la semana hasta que se sentía como un juego divertido, entonces no dormía por el resto de la semana tecleando en la computadora y dibujando hermosas imágenes. Para mí, (y creo que para todos) los días ocupados en “pre-producción” fueron sin lugar a dudas más valiosos que los días empleados en el desarrollo como tal.

Un primer prototipo en papel para “On a Rainy Day” - útil mientras simulas en tu mente.

3. Desarrollo: Nadie Sabe Cómo lo Hiciste, y a Nadie le Importa

Una vez que tengas una buena idea, aquí hay algunos consejos para que consigas crear un pequeño demo ¡en poco tiempo!

Primero Construye el Juguete

Inicia con la base mecánica. Ya sean sistemas elásticos, comportamiento de enjambre, gravedad, etc., nunca tomó más de unas cuantas horas tener el tema básico funcionando. Este “juguete” debería ser la mecánica básica del juego restando cualquier objetivo o decisión. Aún no hay ganar o perder, solo algo divertido con qué jugar.

Sr. Gabler: “Con “Super Tummby Bubble”, el “juguete” solamente eran unas cuantas burbujas dentro de un pequeño contenedor. Después de jugar y lanzarlas alrededor por un rato, lo llevé a un punto donde poenr mis dedos en las burbujas se sentía realmente satisfactorio, así que era el momento de introducir algo de jugabilidad. Las características del juego en este caso eran burbujas de diferentes tipos de parásitos, un concepto de “reventar”, un concepto de “cadenas”, contadores de puntuación, etc.

“Super Tummby Bubble” - Juguete (izquierda) vs Prototipo final (derecha).

Si puedes salirte con la tuya, Simúlalo

Se podría decir que esta es una de las lecciones más importantes del proyecto. A menudo la solución “correcta” no es la mejor solución. Simular estratégicamente te ahorrará tiempo y dinero; hará tu juego más rápido, y tus dientes más blancos. ¡Simula liberalmente y a menudo! No crees complicados sistemas de iluminación y sombras cuando una simple imagen como sombra y unas texturas retocadas resultarán igual de efectivas (“Darwin Hill”). No configures un complicado sistema de reconocimiento de patrones para analizar los dibujos del usuario cuando puedes evitarlo con el mismo efecto (“Suburban Brawl”). No dibujes splines o crees tu propia biblioteca de arte vectorial cuando unos mapas de bits escalados brindan el mismo efecto más rápido y más fácil (“Tower of Goo”). Hemos encontrado que esta regla es también una fantástica lección para la vida. Vagos, tomen nota.

“Darwin Hill,” “Suburban Brawl,” “Tower of Goo” - todos simulados, y nadie se dió cuenta. Shhh!

Cut Your Losses and "Learn When to Shoot Your Baby in the Crib"

Al inicio del proyecto se tenía el deseo de salvar todo - un poco más de de tiempo y esfuerzo y seguramente un mal juego ¡podría convertirse en el trabajo de un genio! Un protototipo de estos condenados al fracaso inició como un hermoso sistema de resorte que se aplastaba y comprimía y te hacía desear tomarlo y arrastrarlo por todos lados, pero simplemente no se estaba convirtiendo en un juego convincente. La creación del sistema elástico original tomó unas cuantas horas, pero luego se quemó y consumió una semana adicional de programación desperdiciada en un triste intento de forzar la mecánica para convertirse en un juego.

Es importante reconocer rápidamente ideas de juegos sin salida, reduce tus pérdidas y continúa adelante. Como notamos, la espontaneidad es más valiosa que el tiempo invertido en tratar de salvar el código existente. Siempre puedes volver atrás si la inspiración te llega más tarde.

Sr. Kucic: “Mi “Potato” terminó siendo un sistema de cuerpo suave perfectamente simulado creado en Flash. El único problema fue que no era de ninguna manera divertido. Causó más dolores de cabeza que el death metal, desperdició una semana y ni siquiera se movió realmente. Debes llegar a saber cuando conservarlos y cuando archivarlos.

“Matt's Potato” - bask in its glory.

Mucha ambientación no salvará un mal diseño (o "No puedes pulir un mojón")

Nos dimos cuenta que los jugadores son más listos de lo que puedas pensar, y que pueden notar cuando tratas de engañarlos. Si el gameplay es horrible, no hay salvación - todo el arte, música y parafernalia del mundo no lo harán un gran juego. Es como tomar un mal gameplay y aventarle los más modernos personajes de películas animadas en 3D, nadie se dejará engañar.

Sr. Gray: “Con “Spin to Win”, el 'gameplay' consistía en rotar el ratón para hacer girar varios círculos - literalmente girar discos. Para ocultar el hecho de que no resultaba divertido, agregué mucha ambientación con un estilo de arte y música de magia de los 60's. Pero no importaba qué tanto puliera el juego, no conseguía que brillara. A pesar de todo el trabajo adicional, rápidamente se convirtió en uno de los juegos más odiados del sitio.

“Spin to Win” - completamente vestida sin ningún lugar a cuál ir.

¡Pero la estética general si importa! Aplica una saludable porción de arte, efectos y música

De hecho esto va contra una de nuestras hipótesis originales. No pensamos que el arte o los efectos de sonido consiguieran marcar una diferencia, ¡pero estábamos equivocados! De hecho, jugar un juego bien pulido se siente mejor que jugar el mismo juego con arte descuidado y sonidos pobres. Aunque es importante hacer la siguiente distinción - pulir la estética (como en la sección anterior) aún no salvará un mal diseño, pero si tiene el poder de hacer que un buen juego sea aún más jugable. Esto no quiere decir que necesitas gráficas fantásticas o sonido surround. Quiere decir que puedes beneficiarte de hacer que todo el conjunto se convierta en un paquete perfectamente conjuntado. Recuerda, aún una estética “asquerosa” puede resultar perfecta si la enmarcas en la forma correcta.

Un prototipo no liberado - el arte no necesita ser complicado para tener una composición sólida.

A nadie le importa tu grandiosa ingeniería

De nuevo, vale la pena notar que un gran ingeniero no necesariamente hace un gran prototipador. Las soluciones “correctas” o “reutilizables” a menudo no son lo que buscamos para un código rápido. Para cada problema, debes ser capaz de ofrecer una gran cantidad de soluciones y estar preparado para seleccionar la que haga el trabajo - rápido. El usuario final nunca verá tu gran ingeniería, y no les importa.

Sr. Shodhan: “Al sobreingenierizar, es fácil terminar con herramientas genéricas o demos tecnológicos que nunca se traducirán en algo jugable. Esto puede compararse a una estrella de rock ejecutando un solo de guitarra técnicamente brillante pero que ¡deja a la audiencia bostezando! Para la ronda de “evolución”, hice un programa con superficies subdivididas y una apariencia cell shaded para modelos 3D que evolucionaban al alimentar árboles de descencencia. Había mucha tecnología brillante, ¡pero no había absolutamente nada de gameplay!”

“Árboles evolutivos” - toda esa tecnología no contribuye a la diversión.

 
referencia/articulos/prototype_a_game_2.txt · Última modificación: 26/11/2011 a las 21:21 por jenriquez
Este sitio funciona sobre el motor wiki de DokuWiki.
© 2003-2008 Hugo Ruscitti