05 julio, 2006

Diseño de juego y de niveles, ¿juntos?

Recientemente me ha llamado la atención en varios juegos la intima relación que proponen entre diseño de juego y diseño de niveles, hasta el punto de tener mecánicas que sólo se encuentran en unas pocas ocasiones. Hablo por ejemplo del God of War, Fahrenheit, Half-Life 2... En todos ellos se pone un énfasis especial en ofrecer la mayor variedad posible en la jugabilidad, con retos de diferente naturaleza que no se repiten. Además, da la sensación de que las mecánicas y el nivel donde se utilizan van íntimamente ligados: Kratos se encuentra un laberinto de vigas sobre las que usa la mecánica de hacer equilibrios.

Obviamente, todos los juegos aspiran a tener variedad, y a sacar el máximo de sus mecánicas de diseño. Sin embargo, es típico plantear una serie de elementos de diseño a priori, y luego construir niveles donde aplicarlos. Los juegos de coches, FPS, RTS...la mayoría siguen esta premisa. Podemos analizar el Project Gotham Racing, el F.E.A.R. o el Warcraft III independientemente del nivel, puesto que la jugabilidad es siempre más o menos la misma. También los juegos que están basados en diseño emergente o mundos abiertos tienden a empezar por definir los elementos del juego y luego construir niveles o misiones. Es el caso de GTA, Oblivion, etc.

Supongo que debido principalmente a limitaciones técnicas y de producción, los juegos que hermanan diseño de juego y de niveles tienden a ser bastante lineales. No se pueden permitir el lujo de hacer contenido que el jugador no vaya a ver, ya que casi todo el contenido es único y resulta costoso de producir. No estoy seguro de qué prefieren los jugadores típicamente: una experiencia más lineal pero muy variada y rica, o una más libre, basada en un conjunto de elementos establecidos previamente, y donde se juega con las interacciones entre ellos. Parece que hay juegos que tienen éxito en ambas categorías.

A la hora de plantear un juego de este estilo, me vienen varias cosas a la cabeza. Primero, hay que establecer una relación muy estrecha entre diseñadores de juego y de niveles, quizás hasta el punto de no hacer distinción. En God of War tenían 4 diseñadores de niveles y 3 diseñadores de combate, pero ningún diseñador "de juego" (y sospecho que David Jaffe hacía un poco de uber-diseñador, diseñando el alto nivel de todo). El combate es la parte más trasladable y constante de God of War, así que creo que tiene sentido tratarla por separado, pero no me cuesta imaginar a los diseñadores de niveles introduciendo mecánicas nuevas.

La segunda consideración es que la forma de trabajar día a día cambia. Típicamente el número de mecánicas distintas en el juego será grande, y los diseñadores necesitarán experimentar mucho con ellas para hacer que mecánica y nivel encajen bien. Esto es como cambiar el diseño del juego con la misma facilidad con que los motores y herramientas de hoy permiten cambiar un nivel. Para programadores esta es la peor de las situaciones, ya que el programador prefiere una lista de requisitos inicial, pequeña y coherente. Cambios drasticos en el diseño y máxima variedad son enemigos de un código sencillo y elegante. Por otra parte, recuerdo a los programadores de Jak & Daxter mencionar que un aspecto muy importante para ellos es la capacidad de programar muchos comportamientos y escenarios únicos, usando un lenguaje de script especial (GOAL), lo que les distingue de la competencia.

En definitiva, un modelo de estructurar la jugabilidad opuesto a la moda del mundo libre y emergente, que creo seguirá vivo y triunfando aún durante largo tiempo.


Mostrar/ocultar resto...

3 Comments:

At 6/7/06 09:01, Anonymous Anónimo said...

En una experiencia completamente lineal como "God of War" cada mecánica de juego se convierte en una herramienta imprescindible para el diseñador de niveles a la hora de crear un flow de juego variado y que mantenga al jugador pegado al mando.

Cada nuevo enemigo, cada arma, cada puzzle, cada escenario, cada habilidad, es en definitiva una recompensa para el jugador y una forma más de construir esa "curva de dificultad". Como digo, son recursos muy valiosos; tu juego siempre debería ofrecer algo nuevo al jugador constantemente.

 
At 6/7/06 13:08, Anonymous Anónimo said...

"Típicamente el número de mecánicas distintas en el juego será grande, y los diseñadores necesitarán experimentar mucho con ellas para hacer que mecánica y nivel encajen bien. Esto es como cambiar el diseño del juego con la misma facilidad con que los motores y herramientas de hoy permiten cambiar un nivel"

"Cambios drasticos en el diseño y máxima variedad son enemigos de un código sencillo y elegante"


En relación a esto que comentas creo que el paradigma de AOP (Aspecto Oriented Programming) y AOSD (AS Software Development) tiene mucho que decir en el campo de desarrollo de Juegos, y pueden, sino ser la solución al problema que expones, sí ser el próximo paso en cuanto a paradigmas de desarrollo se refiere.
Al igual que la OOP/OOD se han impuesto a la programación procedural en el terreno del desarrollo de juegos, y la programación procedural se impuso al assembler en su día, todo apunta a que en un futuro cercano el paradigma de orientación a objetos será complementado (enriquecido) con la programación orientada Aspectos.

¿Y que ventaja nos va ofrecer la AOP/AOSD en relación con el desarrollo de videojuegos?
Pues justamente evitar el problema que comentas: la variedad, la diversidad, los distintos comportamientos de las mecánicas y elementos de gameplay podrán ser enriquecidos, ampliados y adaptados con las variaciones requeridas en cada momento o nivel determinado del juego, evitando de esta forma la repetición de las mecánicas de juego dónde los niveles de un juego no son más que calcos entre sí con distintos gráficos.

En el paradigna AOP, y desde el punto de vista del código, dichas mejoras o variantes de cada mecanismo de gameplay quedarán perfectamente aisladas ofreciendo claridad, sencillez, elegancia y eficiencia en el enjambre de clases y código, permitiendo la variedad de comportamientos, las excepciones, los ajustes diferenciadores que de una forma ordenada,controlada y rigurosa permitirá disponer de un motor de juego que como tú bien dices, además de ofrecer la posiblidad de cambiar un nivel, también ofrecerá la posibilidad de cambiar (ajustar, amplicar, adaptar, diferenciar) el diseño del juego (y más concretamente las mecánicas de gameplay del mismo), asegurandose además que dichas mecánicas y los niveles encajen a la perfección.

Hoy en día la AOP es ya la evolución a la que se tiende en la ingeniera de software empresarial (en lugar de hablar de variedad de mecánicas de juego hablamos de funcionalidades 'cross' que afectan a las funciones verticales o 'core' en las que se estructura un aplicativo, como pueden ser consideracioens de autenticidad, seguridad, logging,..). Espero y deseo que la AOP sea igualmente el paradigma que se imponga en el software aplicado a videojuegos y entretenimiento.

 
At 6/7/06 17:31, Blogger sgarces said...

No es la primera vez que oigo hablar de AOP en esos términos, y resulta intrigante. Es lo que todo programador desearía: dividir el programa de "aspectos" independientes y poder aplicarlos o combinarlos con total flexibilidad.

Es por esto que leí un poquito sobre AOP; pero me decepcionó lo que vi. En el fondo, las implementaciones que había consistían en recubrir un módulo o una función con capas, donde cada una de estas capas representa un aspecto. Así, si haces una llamada a función, puedes, efectivamente, aplicar consideraciones de seguridad, logging, etc, de manera complementamente independiente y ortogonal.

Desconozco si existen implementaciones (o incluso lenguajes) que lleven el paradigma AOP más lejos, pero de no ser así resulta demasiado limitado. En su lugar, la posibilidad de dividir y combinar funcionalidad ya existe en OOP (p.ej. dividiendo la funcionalidad en pequeños objetos y combinándolos mediante composición), pero el problema que sigue habiendo es que un programa grande, con mucha variedad, lleno de casos "excepcionales" (que no se puedan derivar fácilmente de un diseño común), va a ser más costoso y difícil de programar que uno más reducido y/o coherente.

Hay muchas cosas que se pueden hacer para aliviar el problema, pero soy escéptico (desde muy limitada experiencia) que AOP sea la "silver bullet".

 

Publicar un comentario

<< Home