Java Monkey Engine, o "no todo tiene que hacerse en C++"

Me comentaron en el curro la existencia de este Engine para Juegos, y yo pensé, "un Java3D pero más bonito".
Me pasé de listo, resulta que no, esta es la historia de jME:

jME was created by Mark Powell in 2003 while he was investigating OpenGL rendering. After discovering LWJGL he decided that Java (his language of choice) would be perfect for his own graphics tools. These tools soon grew into a primitive engine. After reading David Ebery's 3D Game Engine Design, a scene graph architecture was implemented. It was then that jME became part of Sun's Java.net software repository. jME soon saw others joining the project to enhance it's capabilities. It has since grown to encompass many advanced modern graphics features and turned into a stable platform for game development. Joshua Slack joined jME at the end of 2003 and became a core member and integral part of the jME team.

iscarding can mean a variety of things, but the most significant in Graphics programming is culling of data. jME's camera system uses frustum culling to through out scene branches that are not visible. This allows for complex scenes to be rendered quickly, as typically, most of the scene is not visible at any one time.

Frustrum es una tecnología bastante conocida para el tratamiento de escenas 3D, que te permite "obviar" aquello que está oculto al punto de vista en el que se está posicionado. Podeis echarle un vistazo a este artículo de Gamasutra que lo explica muy bien (hay que estar registrado en Gamasutra, es gratis).
En definitiva un Engine de gráficos para JAVA que está muy bien y que viene a cubrir un hueco que había.

Un YouTube de juegos caseros, con XNA

XNA es una de las ideas felices de Microsoft que más me ha sorprendido desde que supe de este proyecto.
Podríamos decir que XNA es un gran SDK enfocado a juegos y en el que podemos desarrollar tanto para Windows como para XBOX 360.
Como ya he comentado en otras ocasiones, el valor añadido que los usuarios le dan a un juego/plataforma cuando se le da la posibilidad de crear sus propios proyectos, es enorme. Tenemos ejemplos de Open Source que son muchos más útiles que su contrapartida "cerrada", o como comentaba el otro día, tenemos MODs de juegos que hacen del producto algo muchísimo más interesante que si se tratara del juego en sí, sin nada más. La posibilidad de hacer grandes cambios en un juego o en un programa (desde la IA, hasta los gráficos), da pie a que se den resultados que ni los propios creadores tenían pensado o ni siquiera pudieran sospechar.
Los ejemplos los hay a montones y sólo hay que acercarse a cualquier juego que te permita MODificarlo, para ver los resultados.
EL caso es que XNA es algo parecido a eso, pero a una escala mucho mayor. Tenemos a Microsoft que ha pensado en una plataforma (XBOX 360), en casi todos sus aspectos, a saber, no sólo es potente y no demasiado cara (comparada con PS3, aunque cara comparada con Wii), también tenemos XBOX Live! que le da una dimensión más a la consola, además también se ha pensado en los estudios, no se deja de lado a los desarrolladores a los que les ha dado la posibilidad de crear en un gran IDE de desarrollo como es Visual Studio 2005 (conocido por todos, con sus ventajas y sus defectos) y con este SDK que facilita la tarea enormemente. Ahora entra en juego XNA.
XNA, no es algo nuevo, desde que salió la XBOX 360 se viene hablando de ella y se ha intentando potenciar con más o menos éxito. Ahora Microsoft, que ya tiene cuatro millones de usuarios en su XBOX Live!, se ha visto preparada para darle un empujón más a XNA.
Qué tal si hablamos de una plataforma en la que tu haces tus juegos, los cuelgas al igual que en YouTube cuelgas tus videos, y la gente juega con ellos votándolos?, esa es la visión de Microsoft.
Las posibilidades que da esto son prácticamente ilimitadas, Microsoft quiere premiar a los mejores juegos poniéndolos a disposición de todos desde Xbox Live Arcade, dándoles beneficios en dinero, es decir, quiere potenciar el desarrollo Indie, quiere hacer de XBOX una plataforma con juegos gratis o muy baratos, creados por los propios usuarios y para los usuarios y fomentando una comunidad en donde los bajas, votas y comentas a modo de "YouTube for Games".
El modelo YouTube es tan revolucionario que hasta cuesta trabajo creer que salga a ganancias (teniendo en cuenta los costes del Ancho de Banda, por ejemplo), ha revolucionado de tal forma que ahora los más grandes también quieren usar este modelo, a su manera claro está, para poder ofrecer nuevas posibilidades y dar un nuevo valor añadido a sus productos.
Si esta aventura tiene éxito, ¿que otra plataforma puede imitar esto?, ¿acaso Sony puede hacer un SDK para el desarrollo Indie?, si hasta los propios desarrolladores van a sudar tinta china para sacarle el partido que se merece el procesador CELL... Ya decía Phil Morrison que nadie va a sacar el 100% del Cell pues bien, si eso ocurre desde luego que es culpa de Sony. Esto es como si yo vendo un coche que tiene 1000Cv de potencia pero justo después te digo que solo vas a poder usar 200Cv... ¿que diferencia hay con uno de 200Cv?, ninguna, así que no me lo vendas como uno mejor, tu coche da lo que da y lo demás es indemostrable (por mucho que tenga un motor increíble, en teoría).
Esa es la gran ventaja de Microsoft frente a Sony, de momento Microsoft a dado hechos, Sony solo problemas, retrasos, cancelaciones y dolores de cabeza. Desde mi punto de vista, tendrían que echar desde Phil para abajo y fichar a unos cuantos de Nintendo, lo mismo les iría mejor.

El caso es que XNA, el modelo que quieren crear de "YouTube for Games" y XBOX tienen aun muchísimo recorrido. Todos los desarrolladores van a querer embarcarse en el carro de XBOX ya que si es más barato hacer juegos (gracias a las herramientas), es más sencillo (gracias a una arquitectura mucho más balanceada, aunque menos potente) y los resultados pueden ser espectaculares (véase Gears Of War) ¿qué mas se puede pedir?, pues que tengamos millones de desarrolladores potenciales que cuelguen sus juegos y tú puedas divertirte con ellos, solamente eso.
A todo este gran compendio de aciertos yo solo le veo una pequeña pega y es que Microsoft, está trivializando el desarrollo de los juegos. Al igual que crear una película, hacer un juego decente requiere de un esfuerzo, un tiempo, unos conocimientos y un presupuesto, que no están al alcance de todos, de hecho está al alcance de muy pocos. Por la misma razón que en YouTube solo encontramos vídeos más malos que buenos, muy pocos de creación propia, y aun muchos menos con un mínimo de calidad. Por esa misma razón, encontraremos muchos juegos muy malos, bastantes malos, y alguno (muy pocos) medianamente buenos o regulares. El sueño de XNA, de democratizar el desarrollo de un juego, es bonito, pero a mi modo de ver practicamente irrealizable.
No creo que encontremos demasiados juegos colgados desde el principio. Coger una cámara y grabar a tu hijo de dos años bailando es mucho mas fácil que hacer un come-cocos. Aun teniendo las herramientas de forma gratuita, habiendo gente con un gran talento, y teniendo la plataforma necesaria para dar a conocer tu trabajo, tengo serias dudas de que vayamos a ver algo decente a medio plazo.El crecimiento de YouTube ha sido enorme gracias a la facilidad de crear algo muy sencillo, en poco tiempo y con un coste casi nulo. No veo un "Youtube para juegos" con varios miles, ni siquiera cientos de juegos hasta dentro de bastante tiempo.
Espero estar equivocado.

Juegos con Código Abierto

No es noticia que un estudio quiera alargar la vida de un juego de todas las formas posibles. Tenemos desde secuelas, hasta nuevos mapas, objetos, misiones, expansiones al poco tiempo de haber salido... etc.
La vida de un juego es en la mayoría de los casos de meses, raro es el caso como WoW (que merece un estudio a parte), en que un juego puede tener tantos seguidores durante un año o más.
Para los estudios, es una necesidad alargar la vida del juego a través del mecanismo que sea para poder amortizarlo al máximo. Normalmente ofreciendo renovar el juego en algún aspecto.

Desde mi punto de vista una de las formas más acertadas para alargar un poco el ciclo de vida de un juego es a través de las comunidades de jugadores que se crean alrededor de los buenos juegos. Los auténticos Fans pueden hacer de un juego un éxito total, un ejemplo es Half Life, un mod como Counter Strike ha conseguido tantas ventas para Half Life que ya forma parte de la distribución normal del mismo juego. OSea, que te compras el juego y el MOD ya te viene :).

Ejemplos los hay a montones, los jugadores de Oblivion para PC, habrán probado algunos de los muchos MODs que hay para este juegazo de antología. Desde mejoras en las texturas, hasta una revisión completa de cada una de las criaturas del juego (Obscuro). Prácticamente cada nuevo juego que sale, tiene MODs de los usuarios.
Conodísimo es el caso del Hot Coffe, para GTA San Andreas, el éxito o la polémica también se debió al enorme desconocimiento que tienen la mayoría de los medios de comunicación (sobre todo la televisión) sobre lo que hablan. Se llegó a confundir el Hot Coffee y las "sordidas" imágenes del jugador haciéndolo en un montón de posturas distintas ;) con las chicas que ibas encontrando por la calle , con el propio juego original. Tal fue la confusión, que al final tuvieron que salir los chicos de Rock Star Studios diciendo que su juego es otro, que eso que veían era un MOD. Mo le vino demasiado mal, de todas formas, la publicidad que se le hacía en todos los telediarios...
El mundo esta lleno de gente con una capacidad y una calidad en el trabajo que los estudios saben que cualquier juego que saquen puede ser mejorado con creces y en muy corto tiempo si abren la posibilidad a los MODs.
Normalmente todo esto se consigue a través de SDKs para cada uno de los juegos, creo que fue el Quake (ID) quienes fueron de los primeros en los que podías hacer mapas. Era muy divertido (yo hice mi fcultad :D)...
Todo esto viene a colación por que me he encontrado un SDK, muy interesante, en el que además viene el código fuente del CORE del juego en sí, se trata del SDK del Civilization IV.
Yo he re-jugado a este juego no hace demasiado y la verdad que es un grandísimo juegos de estrategia por turnos (para mi la auténtica estrategia es por turnos, el RTS me gusta, pero me estresa un poco :D).
Además me he encontrado esta noticia en la que se dice que se quiere liberar el código fuente del Second Life. Para mí, esto es un error, pues como saquen el código fuente entero (creo que será parte, no entero) el juego se va a ver inundado de Hacks y Cheats que van a cargarse la Segunda Vida.

Raytracing en el motor de Quake 3

Hoy me he encontrado una cosa bastante impresionante, por lo "bonito" que se ve y por que no tenia ni idea que alguien estuviera haciendo esto.
El tema está en que la renderizacion es RayTracing, nada de técnicas de motores, de HDR y demás... nada, un rayo de renderización como toda la vida se ha hecho.
Obviamente la calidad en las sombras y demás es acojonante increible, fijaros en las sombras, en los reflejos y todo lo demás...
Dificilmente las cosas vayan a evolucionar por este camino, digamos... a medio plazo, pues la potencia de cálculo necesaria da miendo solo de pensarlo :)... pero es muy, muy interesante ver que hay gente por ahí que esta haciendo este tipo de cosas.
Recomendado echarle un vistazo a los video y a las fotos.

Diseño de un juego en Red

Hace poco me pidieron que posteara algún artículo sobre el juego en Red, y como me pareció buena idea, me puse en ello poco a poco.

El resultado han sido dos artículos,un poco técnicos, pero no demasiado… en el que explico cuales son las técnicas más habituales en la programación de los juegos en Red.

Técnicas de programación de juegos en Red:

Para poder empezar con un sentido, creo que antes de nada podría intentar clasificar los distintos tipos de juegos en red, pues las soluciones posibles buscadas para cada uno de ellos no son las mismas.

Por un lado tendríamos una clasificación por tipos de red, es decir juegos en LAN o juegos en WAN, y por otro lado tendríamos una clasificación por tipos de juegos, esto es FPS, RTS, o MMG (Massively Multiplayer Games), como veis me he ceñido a solamente tres tipos de juegos.

Con esta clasificación no quiero decir que, necesariamente, las soluciones tengan que ser distintas para LAN (redes locales) que para WAN (Internet) o para cada uno de los tipos de juegos, pero lo que si es verdad es que esos dos tipos de redes son muy distintos y las características de nuestra solución deberán ser tales que sean aplicables para ambos o para una sola de estas redes.

En el caso de la LAN tendremos una red bastante rápida, eso es, con gran ancho de banda(BW) y con un retardo (LAG) muy pequeño. En este tipo de redes solemos tener muy pocos problemas de sincronismo, y el número de jugadores es, por lo general, no superior a la centena (en el peor de los casos). Pero ¿que pasa cuando estamos en una WAN en la que hay un retardo mucho más alto y el ancho de banda es mucho menor?

Por otro lado, tenemos el tipo de juego al que se le quiere aplicar la solución, no es lo mismo de exigente un RTS sobre LAN, que un FPS sobre WAN (mucho más exigente), además estas dos soluciones son completamente distintas a un MMG, que siempre es sobre WAN (las técnicas para MMGs las comentaré en el segundo artículo).

Con todo esto ya tenemos el contexto claro.

El problema del sincronismo:

El problema principal con el sincronismo se debe a que es necesario que cada uno de los jugadores vea exactamente la misma escena en el mismo instante de tiempo en sus monitores, aun teniendo cada uno de ellos retardos con el servidor totalmente dispares.

Examinemos con detenimiento el problema:

1). Supongamos que estamos en un juego en el que el jugador(j1) en el instante t0, está en una posición dada en el monitor y el jugador (j1) desea avanzar, para ello j1 pulsará la tecla de avance. Lo que ocurre en ese instante es que un mensaje (m1) sale del ordenador de j1, en el instante t0, para informar del movimiento del jugador j1 al resto de jugadores de la partida (ya se que es un poco lió… podéis verlo mucho mejor en el gráfico).

2). Supongamos que ese mensaje llega al servidor en el instante t1 (t1 = t1+tr1, donde tr1 es el tiempo de transporte, o tiempo que tarda el mensaje (m1) en llegar al servidor desde el ordenador j1), el servidor gestiona el mensaje, lo procesa y lo envía cada uno de los clientes (incluido j1).

3). Supongamos que el mensaje llega a todos los clientes en el instante t2 (t2=t1+tr2+tp1, donde tr2 es el tiempo de transporte del mensaje desde el servidor hasta el resto de jugadores, y tp1 es el tiempo de procesado del mensaje (m1) en el servidor). Fijaros que estamos suponiendo que se tarda lo mismo en llegar a todos los ordenadores a la vez, cosa que en realidad no es cierta, pero que podemos suponer sin perdida de generalidad, para este caso.

Para cuando los mensajes lleguen a los clientes (en t2), está claro que el jugador que ha iniciado la cadena de mensajes (j1) ya habrá pasado por la posición a la que quería llegar, de hecho es muy probable que este en otra posición bien distinta, por tanto, lo que ven los jugadores es una posición errónea, es más, cuando el mensaje llegue a j1 de nuevo (pues el mensaje de j1 llegará de nuevo a sí mismo a través del servidor) y vea que hay una discordancia entre la posición que dice el servidor en la que está y su actual posición, intentará corregirla (o no, depende de la implementación), con lo que la confusión aumenta aun más.

Como se puede observar, un problema de estas características, que viene dado por el transporte de los paquetes, es inherente a los juegos en red, es decir, no podremos en ningún caso evitar el problema, lo que si podemos es paliar los efectos (que no las causas) e intentar que los jugadores tengan la mejor experiencia posible. Para paliar estos efectos podremos usar distintas técnicas, como son Predicción y Extrapolación.

Para poder explicar bien estas técnicas necesitaremos saber, antes de nada, qué es el determinismo en los juegos.

Decimos que una un juego es determinista si una situación en un instante I1, llegaremos siempre la misma situación resultado en el instante I2, si usamos el mismo método y siempre que se den exactamente las mismas condiciones.

Para conseguir el determinismo en los juegos, básicamente tendremos que quitar cualquier variable de aleatoriedad. Para ello, un método usado normalmente es el cálculo y negociación de una tabla de números aleatorios a priori antes de empezar la partida.

Todos los jugadores en red tendrán la misma tabla, que será usada cada vez que en el juego se requiera un número aleatorio. Esta tabla permite que dada una situación, cuando tenemos que decidir algo que requiera cierta "aleatoriedad", siempre llegaremos a la misma situación resultante si usamos el mismo número en la tabla.

Este mecanismo nos permite dos cosas muy importantes, por un lado evitamos tener que calcular los números aleatorios en tiempo de ejecución (lo que nos ahorra bastantes ciclos) y por otro lado hemos descartado la aleatoriedad en nuestra partida.

Una vez que sabemos esas cosas podemos continuar con las técnicas de sincronismo de las partidas en red

Técnicas de sincronismo: Predicción y Extrapolación.

El jugador j1 conoce su posición real, y además conoce lo que quiere hacer y el tiempo que tarda (de media) un mensaje en llegar desde su ordenador al servidor... ese tiempo será (t0-t1), que se calcula básicamente haciendo un ping entre ambos ordenadores o de una forma mucho más compleja que no explicare aquí por ser un poco “espesa”, para nuestro caso nos sirve el Ping.

Pues bien, como el ordenador que controla j1 sabe lo que quiere hacer, donde está y a donde quiere llegar, y además conoce el tiempo que tomará al servidor transmitir esta nueva posición, se puede presentar en el monitor de j1 el cambio de posición, con ese retardo calculado, para que la situación que ve j1 sea justamente la que está llegando al resto de los jugadores de la partida.

Pero con esta solución tenemos solamente parte del problema solucionado. Es decir, hemos paliado el problema al meter un retardo en la representación igual al retardo necesario para que el mensaje m1 llegue del origen al resto de jugadores, pero esto degradaría enormemente la experiencia de juego, pues para el refresco de cada posición se tendría que esperar un tiempo de retardo!... sin embargo, cuando jugamos nosotros no notamos esta degradación, ¿Qué pasa entonces?.

Bien, fijaos que hemos empezado diciendo que el jugador j1 quiere hacer un movimiento y ese cambio de posición es el que se le manda al servidor... supongamos que en vez de estar molestando al servidor a cada movimiento, con cada nueva posición (muchas nuevas posiciones en cada segundo), ¿que tal si solamente le enviamos el diferencial cuando valga la pena informar de él?. Es decir, si estamos avanzando y anteriormente estábamos avanzando, ¿que necesidad hay de decirle al servidor que continuamos en esa dirección?, será mucho más efectivo si ahorramos ancho de banda y en vez de enviar cada nueva posición, simplemente enviamos, cada cambio en el estado.

Si el jugador j1 iba hacia la derecha y ahora quiere ir hacia arriba, eso sí que se manda, pero si se estuvo tres segundos hacia la derecha, no hay necesidad de estar enviando cada nueva posición al servidor dentro de esos tres segundos.

Detrás de esta idea está la técnica llamada "de Extrapolación".

Cada uno de los clientes (jugadores en la partida) “extrapola” la posición del resto de jugadores, es decir, se la inventa!, y la compara con lo que le llegue por red (que a menudo le llegam posiciones referentes a un instante pasado), si la comparación da positivo, es decir que se inventó bien la posición, entonces no hace nada, pero si resulta que se inventó mal la posición, la refrescará en la situación de partida y ya está. El resultado de una extrapolación fallida son esos “saltos” que vemos que algunas veces dan los jugadores contrarios (lo que se suele llamar “lagazo”).

Los algoritmos de extrapolación de la posición son variados y algunos realmente complejos, como veis, del buen hacer de este algoritmo dependerá muchísimo la calidad del juego en red.

Otras técnicas más específicas para juegos en los que hay escenarios muy grandes y el número de jugadores es extraordinariamente alto (como por ejemplo, WoW) lo comentaré en un segundo artículo (por no aburrir, más que nada ;)).

La IA en la Nueva Generacion de juegos

He leido últimamente en bastantes ocasiones () el concepto de “Next Gen A.I.”… y he pensado en comentarlo en un articulo, pero sin demasiada profundidad, sin demasiados tecnicismos y dando una visión general de qué es la I.A en los juegos y por qué se supone que la próxima I.A. será mucho mejor que la presente.
La IA en un juego es fundamental para que la inmersión sea lo más real posible…. Todos hemos visto como de simple era matar a los monstruos en Doom y como se ha llegado hasta comportamientos más complejos como F.E.A.R por poner un ejemplo… o como hemos llegado a situaciones totalmente inesperadas con la IA de Oblivion… cómo hemos llegado hasta aquí, y qué nos espera en el futuro es de lo que va este artículo.

La IA en los juegos:
Lo primero que habría que comentar sobre la IA y que siempre te dicen en la Universidad o en cualquier curso de IA medianamente profundo, es que eso de Inteligencia Artificial es un nombre demasiado pretencioso ;), en general la Inteligencia que vemos en los juegos está muy lejos de ser ni siquiera parecida a la Inteligencia humana, creativa o inesperada y por lo tanto ya de entrada el nombre es muy engañoso.

La inteligencia en los juegos va a ser tan fundamental, que a mi parecer va a estar, en poco tiempo, a la altura de los gráficos y el sonido.

Una de las razones que los jugadores dan para los juegos online es que jugando con personas tenemos enemigos que son “muy listos” o “muy buenos” y eso le da un grado de realismo al juego que no tiene cuando es Offline. Seguramente muchos de vosotros hayais probado el Battlefield 2, o el Battlefield 2142 tanto en modo Offline como en modo Online, y aunque la inteligencia es buena en Offline, no tiene nada que ver cuando se juega Online (dependiendo de lo manta que sea el otro, claro ;)). Y aunque normalmente los juegos suelen tener un grado de dificultad, este grado no suele variar la IA o su comportamiento (a veces sí, por ejemplo en los RTS), sino la cantidad de enemigos o el grado de “accuracy” (puntería) que tienen.

Entonces qué es lo que tiene la nueva generación para que la IA sea distinta?.

Como todas las tecnologías, la IA avanza, pero la verdad es que no avanza todo lo rápido que se quisiera y, desde luego, que el avance en la IA no es la razón fundamental para que sea un elemento importante (o de igual importancia a los gráficos, por ejemplo) en la nueva generación. Dejando de lado el marketing que conlleva introducir un nuevo elemento a tener en cuenta, y que ese elemento tenga un efecto tan grande en la inmersión, la verdad es que ahora mismo el hardware nos permite muchas cosas que antes ni siquiera se planteaban.

Tener varios hilos de ejecución va a tener un efecto tan grande en todos los aspectos del juego que, en cuanto pase un tiempo y los desarrolladores tengan la destreza suficiente para aprovechar toda esa potencia, vamos a ver cosas muy nuevas y realmente interesantes.

Me gustaría comentar alguna de las técnicas de IA que se usan en los vídeo juegos y analizar, por que ahora esas técnicas van a tener un mayor impacto en el resultado final.

Antes de nada comentar, que como en todo, hay muchas técnicas y que cada una de ellas puede ser muy buena para determinados casos, pero no demasiado buenas para otros. Además, no se trata de hacer un estudio de las técnicas, ni mucho menos!, sino nombrar que algoritmos se usan en cada caso y relacionarlos con experiencias que hayamos visto en los juegos que hayamos probado.

Para distintos tipos de juegos hay distintos algoritmos a tener en cuenta, por ejemplo no tiene nada que ver (o poco que ver) la IA de un juego RPG como Oblivion, con uno RTS, o un FPS. Yo me voy a centrar en esos tres tipos de juegos en este artículo, para no extenderme demasiado.

En un juego FPS tipo F.E.A.R, o Ghost Recon o BattleField hay que tener en cuenta antes de nada que lo que se desea es un BOT que sea bueno, que no haga movimientos “tontos” y que su puntería sea natural (el ordenador puede ser tan bueno como quiera!), además sabemos que los niveles son “cerrados” y en ocasiones no demasiado grandes, sabemos también por donde tiene que pasar el jugador en cada momento para ir hacia el objetivo, por que puntos tendrá que pasar obligatoriamente y qué opciones tiene. Todo eso lo sabemos por que tenemos un mapa (un nivel), finito, manejable y cerrado.

En el caso de F.E.A.R o Ghost Recon es muy claro que los enemigos aparecen una vez que rebasamos ciertos puntos específicos en los niveles (esquinas, pasillos, calles… etc). A estos puntos se le llama Trigger y están programados de antemano por el diseñador de niveles para que cuando el jugador pase por ahí ocurran ciertas cosas o aparezcan los enemigos. Una vez pasado el punto los enemigos “ven” y “oyen” al jugador usando determinadas técnicas, el sonido es un objeto (tal como se lee, un objeto ;) del juego) que sale de un punto concreto y llega a otro. Si un sonido generado por el jugador llega hasta el enemigo, ese sonido (que se sabe de donde partió) tendrá determinadas características de dirección, volumen y degradación (dependiendo de la distancia de partida), esto se usa, por ejemplo, en el Splinter Cell o en el Oblivion, en donde si vamos en modo silencioso no nos escucharan con la misma facilidad que si vamos de pie o corriendo. Además esta característica es muy importante en el desarrollo del juego.

Pues bien, tanto la vista como el oído, como el tacto (si le dan un tiro, lo siente y sabe de donde viene) son dos elementos fundamentales para los juegos del tipo FPS.

Como hemos dicho, una vez pasado el Trigger los enemigos salen y si nos ven o nos oyen o nos sienten, tendrán que calcular varias cosas (como mínimo), a saber, donde están ellos, donde está el jugador objetivo, y como llegar hasta el de la forma “más segura” o “más rápida”. Para el cálculo de rutas, se usa el Algoritmo A*.

En este conocidísimo algoritmo se tienen en cuenta factores como los objetos que hay que sortear, el inicio, la meta y el coste que tiene llegar por cada uno de los caminos calculados. Podríamos decir que calculamos un camino (sea del coste que sea) y lo vamos refinando según iteraciones (no es exactamente así, pero podemos darlo por bueno para esta explicaciónJ) hasta encontrar el mejor. Esto quiere decir que con A* podemos encontrar un camino “no óptimo” hasta la meta y después pulirlo hasta que nos guste el coste o simplemente no tengamos mas tiempo de calculo. Aunque una ejecución completa de A* nos garantiza el óptimo, podríamos encontrar un camino "no optimo" hasta la meta de forma muy rápida usando A* y quedándonos con una solución parcial del mismo.

En A* usamos un heuristico (o regla por la cual mejoramos la solución actual) que nos llevará de un punto a otro por el camino más corto, o que más ganancia nos represente (dependiende del heuristico lo que queramos maximizar o minimizar).

Además del uso de A*, el diseñador del nivel predefine determinadas opciones o caminos pre-determinados (waypoints o Pathnodes, estos conceptos se usan también para la definición de caminos de patrulla, por ejemplo) para llegar de un punto a otro de forma más inteligente (no siempre el camino más corto es el más inteligente) y darle cierta prioridad, peso o de forma probabilística (al azar) a cada uno de esos caminos posibles. Todo eso combinado con A* nos debería dar un camino hasta la meta bastante bueno en terminos de realismo y en los que se maximiza la ganancia, ya sea esa ganancia preservar al NPC o hacer que llegue lo antes posible hasta su meta, además el objetivo también puede variar según el estado actual del juego, como por ejemplo el número de tropas que nos quedan, como está de cerca del final del nivel (en ese caso será más cauteloso!), etc…

En la imagen, un ejemplo de WayPoints en el diseño de un nivel.

También tenemos los juegos de estrategia en tiempo real (RTS). En ellos no se tienen que tener en cuenta todos esos factores, además el juego tiene más tiempo para hacer bien las cosas (en comparación con los FPS) y no suele usarse los waypoint o pathnodes como en los FPS, pues cada partida es completamente distinta y carecería de sentido. Se suele usar A* (que es el rey de los algoritmos para PathFinding) con heurísticos mucho más complejos que en el caso de los FPS, pues se tienen en cuenta muchas más variables.

En los juegos de estrategia en tiempo real, se nota enseguida si los programadores han hecho un buen trabajo o no. Se deben tener en cuenta muchos factores, tantos como variables tenga el juego, eso es diplomacia, dinero, tropas, tipo de tropas, contexto (otros jugadores), posibles ataques, mejora de tropas, mejora de edificios… y muchísimas cosas más. Está claro que predefinir una táctica sería absurdo en este tipo de juegos, por que cada partida es totalmente distinta de otras.

Para los juegos de estrategia en tiempo real, se suelen definir tendencias en los jugadores controlados por el ordenador, son Agentes con una personalidad, es decir, algunos son más pacíficos, otros optan por la defensa, otros por el ataque… etc. En general, esa es la aproximación más “sencilla” desde el punto de vista del programador, que puede predefinir estrategias genéricas de comportamiento encaminadas a un mismo objetivo (planning), por ejemplo, generar muchas tropas, o muchas defensas, o muchos recursos… etc.

Lo que suele ocurrir es que los jugadores controlados por el ordenador pasan de un estado a otro de forma “cíclica” (esto es raro, pero podría ser) o disparada por eventos externos (dependiendo de cómo vaya la partida). Es posible entonces, ver como un jugador pasa los primeros minutos de la partida centrado en los recursos, para pasado un tiempo o dadas ciertas condiciones, pasar a “estilo constructor” y empezar a crear tropas, en vez de generar recursos… etc, lo realmente difícil aquí es hacer una estrategia multiobjetivo.

Los algoritmos de los juegos de estrategia en tiempo real, son tan variados como distintos son los juegos en sí. Pues se han de tener en cuenta distintos factores según el juego, lo normal es que los scripts y estrategias sean muy distintos, no pasa como en los FPS, en donde las técnicas están más “estandarizadas” (podéis buscar Planning, Agents o AI RTS para más datos, os adelanto que este campo es complejo)

Y pasamos al que a mi parecer, son los más difíciles de todos, por tener un número totalmente incontrolable de casos posibles… me refiero a los juegos RPG tipo Oblivion. Es tan difícil hacer un mundo totalmente abierto, en donde cada uno de los NPC (Non-Player Character) tiene una “vida” y además tantas posibilidades de interactuar con los demás NPCs que es abrumadora la sola idea de querer hacerlo medianamente bien. En el caso de Bethesda lo han hecho tan bien, que parece mentira.

Para darle una vida a cada uno de los NPC se tiene que dedicar un tiempo de desarrollo a cada uno de los NPC. Cada NPC tendrá un tipo de personalidad, en el sentido de que estará mas dispuesto a atacar a otro NPC o defender su “propiedad”, además tiene que tener definidas las habilidades especificas de ese NPC, puede ver mejor?, oir mejor?, de que raza es?, tiene mas o menos fuerza?. Todos esos factores se tienen en cuenta para definir un NPC y su inteligencia.

Si os habéis fijado bien en el Oblivion, os daréis cuenta de que cada NPC cena, come, habla, se levanta a unas horas específicas, que tienen conversaciones entre ellos (aunque algunas absurdas y realmente graciosas) y que esas horas no son iguales para todos necesariamente (cada uno tiene su vida).

Para definir toda esa ingente cantidad de parámetros Bethesda ha creado herramientas específicas de definición de personajes y se les ha dado un Path (camino de recorrido) concreto por el que puede (o debe) andar… por ejemplo el dueño de una tienda ira de la tienda a su casa y de ahí a la tienda a determinadas horas, la gente con misiones concretas te las puedes encontrar en distintos sitios del mundo y hay ciertos NPCs que están en los bosques. Lo que es muy difícil es que nos encontremos un NPC con total libertad (creo que ninguno).

De nuevo cada NPC tendrá que calcular Paths hasta objetivos y sus estrategias en el combate variarán según el estado en el que se encuentre, según el estado del enemigo y según la posición relativa de cada uno. Además las armas para algunos NPCs van mas allá de armas como espadas, o hachas, sino también habilidades que bien combinadas pueden hacer mucho daño (combos), todas esas combinaciones pueden estar pre-determinadas, aunque en el caso concreto del Oblivion lo desconozco (es de suponer que sí).

Bien, habiendo hecho este breve repaso por algunas de las técnicas de IA para los juegos, la pregunta que nos podemos hacer es, que nos ofrecerán las nuevas consolas y los nuevos procesadores para hacer más “inteligentes” los juegos… está claro que las técnicas no van a cambiar demasiado, pero lo que si que va a cambiar es el tiempo que se le dedica al cálculo de cada una de las soluciones buscadas, ahora el NPC tendrá mucho mas tiempo para calcular el mejor camino con lo que los heuristicos serán mucho mas complejos y tendrán más variables en cuenta, por lo que nos los encontraremos (a los NPCs) buscándonos la espalda, o generando plannings mucho más complejos en los RTS. Todas esas mejoras y mucho más, será lo que nos encontraremos en la nueva generación de vídeo juegos, mejorando de forma brutal la inmersión en los mismos.

Update:
Windup hace un comentario a este artículo y por el cual hago una correción al uso y la forma de funcionar de A*. Ciertamente en la versión primera de este artículo cometo un error al comentar que la solución dada por A* puede ser parcial, cuando no es cierto, pues con A* siempre tendremos una solución unica (no parcial) y además óptima. Desde aquí pido disculpas si al leer el artículo se ha llevado a error y doy las gracias a los lectores como Windup por tenerme en guardia ante las meteduras de pata.

Algunas direcciones de interés:
http://www.computing.dcu.ie/~bgorman/
http://www.aiwisdom.com/bygenre_rts.html
http://www.technomagi.com/josh/gdc2003/ai_strategy_fri.html
http://www.peachpit.com/articles/article.asp?p=102090&seqNum=2&rl=1

DirectX 10, la verdadera nueva Next-Gen, Parte II

DirectX 10, parte II.

Unificación de los Shader:

Como ya comenté en el anterior artículo, el problema de la infrautilización de los Shaders teniendo un path fijo se podría solucionar haciendo una unidad de ejecución más genérica con el objetivo de tratar en cada momento cada punto según su necesidad de píxel o vertex, en vez de esperar que salga de una unidad de ejecución para que entre en otra.

Si pudiéramos mirar dentro del Pipeline de Direct3D podríamos ver como en un mismo momento, tenemos al Vertex Shader con unidades de ejecución vacías, mientras que el Píxel Shader esta saturado de trabajo o viceversa .

La solución más obvia a este problema es la Unificación de los Shader, es decir, si tenemos a partir de este momento una unidad de ejecución que puede adaptarse a las necesidades puntuales, en vez de tener un estricto Path, es de suponer que el rendimiento final será mayor.

La pregunta que se puede hacer uno es ¿Por qué hasta ahora no se ha hecho de la forma más genérica?. El problema que supone la genericidad no es pequeño, es mucho más eficiente hacer unidades de ejecución de propósito específico que de propósito general, además es más barato, es más flexible a subidas en la frecuencia del reloj y supone un reto tecnológico mucho menor, por ello se explica que hasta ahora no se haya afrontado el problema, de hecho, NVIDIA no ha seguido este camino y continúa con el Path fijo (pues no está del todo claro que sea peor!), al contrario que ATI que ya tiene desarrollado el primer producto con Shaders unificados (la tarjeta gráfica de la XBOX 360). ATI sacará al mercado las tarjetas con nombre R600, que serán las que tengan Shaders unificados.

Entonces la pregunta es, ¿es necesario o no el tener los Shaders unificados para DirectX 10?. La respuesta es no, simplemente se deben soportar Shaders 4.0, da igual la implementación que cada uno de los fabricantes siga (ya sea de Shader unificados o nó), simplemente tienen que cumplir con ese requisito.

Geometry Shader (Shader Model 4.0):

El elemento más importante, a mi parecer, en DirectX 10 será la introducción de otro elemento de ejecución en el pipeline que estará situado entre el Vertex y el Píxel Shader, se trata del Geometry Shader (en verde en la figura), que tratará triángulos enteros (todos los objetos en una escena están formado por un número mas o menos grande de triángulos, ver Pez).

Qué hace este nuevo Shader:

El Vertex Shader tradicional, toma un solo vértice a la entrada y debe tener un solo vértice (tratado) a la salida, es imposible para el Vertex Shader crear o destruir triángulos. El Geometry Shader, sin embargo, permite operar sobre primitivas geométricas enteras, esto es líneas, triángulos y puntos, y a su vez permite operar sobre las primitivas vecinas. El Geometry Shader además, puede crear nuevas primitivas, nuevos triángulos, antes de enviarlos por el Pipeline.

Incluso es posible que el Geometry Shader envíe los resultados de nuevo a memoria, permitiendo que los datos vuelvan al inicio del Pipeline sin tener que pasar por la CPU, con ello se podrá acelerar muchísimo los sistemas de partículas como humo o explosiones que normalmente cargan mucho la CPU, siendo de esta forma independiente este efecto de la CPU. Además, se podrá usar también como una herramienta muy poderosa para los “cube mappings”. Un “Cube Mapping” se utilizan para que la textura de un objeto refleje el mundo que hay a su alrededor. Pues bien, el Geometry Shader junto con un array de texturas puede acelerar este efecto.

Veamos como:

Para hacer que un objeto con una textura de metal refleje el mundo que tiene alrededor, se debe determinar qué es lo que rodea a este objeto y mapearlo encima. Normalmente, esta tarea lleva hasta seis pasadas, pero con el Geometry Shader junto con un Array de Texturas podemos hacer el mismo efecto en una sola pasada, es decir estamos dividiendo por seis el tiempo que tardamos en hacer este efecto tan común (agua, objetos metálicos, cristal… etc).

Ejemplo de texturas y efectos en recreación de rostros humanos.

Ejemplo de Real (izquierda) Vs Renderizado en Crysis con DirectX 10(derecha).

Este nuevo modelo de Shader (Shader Model 4.0) va a permitir una gran cantidad de efectos que antes no eran posibles, cosas como Displacement Mapping, Stencil Shadow Extrusion, Motion Blur y muchos otros (lo pongo todo en inglés por que no me gusta pasar los nombres de los conceptos al Español).

Cada uno de estos efectos va a mejorar muchísimo la calidad final de cada una de las escenas. Encontrándonos con unas texturas que van a rozar lo real (ver imágenes de Crysis, arriba). Además DirectX 10 trae características de morphing, así que esperad transformaciones de personajes en cosas, cambiando de forma mucho más a menudo y con mucho menor coste. Por otro lado, también se espera que la GPU se encargue de parte de la física gracias a DirectX 10, lo que significará una mayor cantidad de objetos interactuando entre ellos. ATI, de hecho, mostró una demo en la que se veía un océano cuya física era tratada enteramente por la GPU

Además de todo eso, por hacernos una idea de los cambios, en Shader Model 3.0 en número máximo de instrucciones por cada Shader era de 512, ahora será de 64000, el número de registros temporales (algo muy importante para los programadores) pasará de 32 a 4096. Además se pasará de cuatro a tener hasta ocho objetivos de renderizado (para los que no sepan de lo que hablo, no me refiero a objetivo de cámara, sino a objeto de renderizado) y el número de texturas disponibles para un mismo Shader pasa de 16 a 128, el tamaño de textura más grande pasa de 2048x2048 a 8192x8192. Por último no se soportará en adelante puntos flotantes de 16Bits y serán todos de 32Bits (FP16 a FP32).

Esta parrafada de números, lo pongo mas que nada para que nos hagamos una ligera idea del cambio que supondrá DirectX 10 y las nuevas herramientas que tendrán los desarrolladores.

Screenshot de Flight Simulator X, con DirectX 9.

Screenshot de Flight Simulator X, con DirectX 10.

En estas imágenes podemos ver ejemplos del efecto que supone toda esta cantidad de herramientas nuevas en DirectX 10, frente a DirectX 9, por ejemplo, las texturas del agua (sistema de partículas, mayor número de triángulos, morphing de triángulos, física avanzada), los árboles (mayor numero de triángulos, luz entre los objetos), las nubes (Texturas volumétricas, luz entre objetos) suponen un salto como no recuerdo otros en cuanto a gráficos se refiere. De DirectX 7 a DirectX 8 hubo un gran salto, una mejora grande, pero como este no, desde luego que no hay parangón, la calidad que vamos a ver en PC con DirectX 10 y la cantidad de objetos en la escena va a ser tan abrumador que pueden llegar a causar rechazo, y no es broma, me refiero al efecto conocido como Uncanny Valley (de nuevo en Inglés).

Entonces, viendo todo esto ¿significa que DirectX 10 le da ventaja al PC frente a las nuevas consolas (PS3 o XBOX360)?, la respuesta es a la vez, si y no... me explico:
Lo que DirectX10 trae al PC es un kit de herramientas que antes no estaban disponibles en DirectX9, pero que se podrían haber programado los desarrolladores de los juegos "a pelo" sobre el Hardware en cuestión y de esta forma suplir las carencias de DirectX. Pero claro, esto aunque no deja de ser posible es una Utopía. Ningún estudio en sus sano juicio haría algo así para PC por que se tiene que cubrir una gran familia de tarjetas gráficas. La ventaja es que eso no ocurre en las consolas, en donde los desarrolladores tienen que hacer las cosas sobre un mismo hardware conocido.
Esa y no otra es la razón por la que consolas con mucha menos potencia que un PC mueve juegos que un PC con las mismas características técnicas que la consola apenas podría ni soñar. Pero no dejemos de lado a los estudios de video juegos y el negocio en sí.
Tener un Kit como DirectX 10 acelera de forma brutal el desarrollo de un juego con muy buena calidad, es decir, tendremos juegos más buenos a menos coste (relativo a la calidad) para los estudios.
Eso nos dará juegos mas completos en PC que en consolas, por el simple hecho de que es mucho más facil hacerlo en PC, pues ya ha habido alguien que ha trabajado para ellos, simplificando muchisimo la tarea (Microsoft y su Directx 10).
En el mundo de las consolas están solos, cada cosa que quieran hacer "extra" les va a suponer un tiempo de desarrollo y un coste económico. Coste, que en muchas ocasiones será tan alto que no será posible hacerlo o simplemente no interese. Entonces el razonamiento no es si es posible hacer este tipo de cosas en las consolas, la respuesta seguramente será sí!, la pregunta que nos tenemos que hacer es, ¿se pueden hacer esas cosas sin DirectX 10 a un coste razonable para los estudios?, si la respuesta es sí, lo veremos, si es no... tendremos que experar a la siguiente generación o como mínimo casi al final de la vida de las consolas de la presente generación, yo personalmente me quedo con esta última opción.

Hacer juegos es como hacer cualquier otro Software?

Aunque esto no es un Blogde Blogs ;) , la verdad es que suelo empaparme de lo que comentan algunos desarrolladores de juegos en sus Blogs comparando un poco con lo que yo pienso, e intercambiando puntos de vista, que suele ser muy productivo :).
En fin, el caso es que me he encontrado en el Blog de Tadhg Kelly un artículo analizando si crear juegos es como crear Software.

Many developers believe that games do not need a central creator figure and that customer focus and willingness to adapt are what matters. I basically disagree with this idea on the basis that games are not software applications which can be definitively made better according to an objective standard. They are entertainment, which relies largely on subjective perspectives of what works, regardless of whether they are so-called interactive or passive entertainment.

Bajo mi punto de vista, cada tipo de Software es lo suficientemente diferente (ya sea de Telecomunicaciones, Médico, entretenimiento... etc), como para considerar que cada campo es único. Al igual que los Arquitectos hacen casas, edificios, hospitales, colegios... cada una de esas construcciones requieren una especialización por parte de quien los proyecta, y de quien los construye. Sin embargo, todos los estudios de arquitectura se organizan de una forma parecida.

En este caso, los distintos tipos de Software requiere de conocimientos muy específicos, pero la forma de trabajo creo que son muy extrapolables (suponiendo que algo pueda ser más o menos extrapolable ;)). Es lo mismo si el Lead Software tiene que lidiar con ingenieros expertos en Bases de Datos o de Engines Gráficos o de IA... en todos los casos los problemas son parecidos, las soluciones y la organización de los equipos tambien, no obstante que duda cabe sobre que cada nicho de negocio tiene sus peculiaridades.

DirectX 10, la verdadera nueva next-gen

He pensado en hacer una serie de artículos sobre DirectX 10 que llega justo con el revuelo de la salida al mercado de Wii y PS3, aunque en realidad el salto tecnológico que va a suponer es, en mi opinión, muy superior al de ambas consolas.
He partido el artículo, pues me ha salido bastante largo, y al final no se si se quedará en dos o tres partes, en la primera explicaré qué es DirectX10, que diferencias trae con respecto a DirectX9. En el segundo haré una pequeña introducción al nuevo Pipeline que introduce DirectX 10, qué mejoras suponen los Shaders unificados (ya se intuye del primer artículo) y una comparativa con screenshots de DirectX 10. En el último artículo comentaré qué podemos esperar de DirectX 10.1, por qué esas mejoras no estan en DirectX 10 y qué supondrá desde el punto de vista visual y en el performance. Finalmente en ese artículo haré mi análisis subjetivo y comparativo entre PC y las consolas, intentando centrarme en la estrategia de Microsoft.

DirectX 10, PARTE I.

Introducción:

DirectX 10 ha sido llamado, desde que se sabe que esta en desarrollo, de distintas formas, a saber DirectX Next, Windows Graphics Fundation 1.0 y 2.0, aunque finalmente se ha decidido llamarlo DirectX 10 como continuación de le familia DirectX, para mí, es más un D3D 10, pues el resto de las tecnologías de DirectX no han sufrido los cambios de Direct 3D.

Antes de nada habría que empezar contestando muy brevemente a la pregunta ¿qué es DirectX?, pues bien, se puede decir que DirectX nació como una herramienta de abstracción que aísla el Software (SW) que usa el sonido, los gráficos y los dispositivos de entrada como Joystick, volantes y demás, del Hardware (HW) que hace el trabajo. Es una interfaz (API) que se “monta” encima de los drivers de cada uno de los dispositivos, con el objetivo de aislar al software cliente (juegos, por ejemplo) de los drivers.

Esta aproximación, aunque cómoda para los programadores e impulsadota de un SW más estándar (los desarrolladores no se preocupan del HW, sólo de DirectX) no deja de estar sujeta a ciertas restricciones que la propia API provoca al SW, es decir, nos podemos encontrar con casos teóricamente posibles desde el punto de vista de la capacidad del HW pero que la propia API no es capaz de gestionar, suponiendo con ello un problema insalvable.

Este es el aspecto negativo que conlleva usar una API como DirectX, pero a su vez, lleva otros aspectos positivos que compensan en el cómputo global. Hacer el SW independiente del HW, siempre que este disponga de un driver que cumpla con los requisitos de DirectX, es muy cómodo para ser utilizado por los desarrolladores, pues supone que estos no se tendrán que preocupar de la incómoda gestión del Hardware y esto ya es de por sí, tan importante u util que compensa los problemas de "performance" que pueda causar.

Aunque todo esto que comento parece muy cómodo en el papel, lo cierto es que hasta ahora DirectX no cubre la totalidad de las tareas que se pueden realizar sobre el HW y esta situación no esta exenta de problemas. Hasta ahora nos hemos encontrado casos como una Radeon X800 o una GForce 6800, ambas DirectX 9, pero que cada una de ellas soporta diferentes tipos de Shaders, cada uno de ellos implementado por el fabricante y sobre el que el desarrollador debía hacer las operaciones específicas de cada familia para poder aprovechar la totalidad de la tarjeta gráfica. Este caso no lo volveremos a ver en DirectX 10, pues a partir de su implantación los desarrolladores y los usuarios finales sólo se van a tener que preocupar de las características que ofrece DirectX, siendo cada una de las tarjetas compatible con una versión concreta de DirectX y significando que el hardware deberán cumplir unas características tecnológicas muy concretas. Microsoft regulará la introducción de las nuevas características gráficas a partir de futuras extensiones de las versiones de DirectX 10 (como por ejemplo DirectX 10.1), y ATI y NVIDIA verán su campo de acción reducido a cumplir esa tecnología de la forma más óptima posible (que no es poco).

Obviamente, todos esos cambios no se harán de espaldas a los principales fabricantes de tarjetas gráficas y será con ellos con quienes se negocie la salida de cada una de las tecnologías. Esto para el usuario final es muy bueno por que su elección se reducirá a conocer que extensión de DirectX que cumple el HW que desea comprar y el desempeño final de ese HW.

Los desarrolladores, por otro lado, no se tendrán que preocupar de que sus motores aprovechen tecnologías que usa una familia concreta de tarjetas gráficas y los usuarios no verán infrautilizado su HW por que algunos estudios no aprovechan al 100% la potencia de las gráficas no implementando determinadas características de sus tarjetas gráficas.

La nueva API, que ha sido desarrollada desde cero, tendrá una relación mucho más estrecha con el Sistema Operativo (S.O.) y podremos ver como más de una aplicación, al mismo tiempo, hace uso de las características 3D de la tarjeta (hasta ahora imposible) y será muy raro ver al SO sufrir bajadas en el rendimiento por culpa del driver de la tarjeta de Video. Además, veremos como podremos cambiar “on the fly” el driver de video y podremos resetear el estado de la tarjeta sin que eso afecte al SO, ni haya que reiniciarlo.

Toda esta estabilidad la da la nueva tecnología llamada Vista Display Driver Model(VVDM) que reemplazará al modelo de driver de video en Win XP y de la que hablaremos un poco más en el último artículo de esta serie.

Este nuevo modelo y la estrecha relación de DirectX 10 con el SO, hace del todo imposible que Windows XP pueda ejecutar DirectX 10 y por tanto será exclusivo de Windows Vista (además del componente de marketing que tiene la exclusividad en Win Vista y la necesidad que crea en el usuario de actualizarse a Vista). Veremos también, como la compatibilidad hacia atrás de DirectX 10 con DirectX 9 no será directa y se hará a través de un emulador, esta versión se llamará DirectX 9L.

Entonces, cuales eran las restricciones principales que DirectX 9 suponía para los desarrolladores? Y cuales son las nuevas características que oferta DirectX 10?

La principal y más importante restricción era sin duda la llamada “The Small Batch Problem”, este problema es muy conocido entre los desarrolladores por el cuidado que deben tener de no sufrirlo, se trata del “API overhead” introducido en la gestión de los objetos en escena, me explico mejor:

El Juego, para cada uno de los objetos que debe renderizar en una la escena, hace uso de la API, esta a su vez llama al Driver de Video que será el SW que hace uso de nuestra tarjeta de video. El problema está en que todas estas llamadas API+DRIVER deben ser gestionadas por la CPU, pudiendo llegar a tener un coste del 40% del tiempo de ejecución. Con DirectX 10 este cuello de botella se ha reducido a menos de la mitad.

Obviamente, este problema no es menor si tenemos un gran número de objetos (como personajes, una silla, un coche … etc) en escena, pues cada uno de esos objetos necesitan un tratamiento específico y llamadas al API y al Driver. Actualmente la limitación que causa la API esta en aproximadamente 500 objetos, con DirectX 10 se esperan poder tener hasta miles de objetos en una misma escena.

Esta limitación de objetos en escena hace sufrir la inmersión del jugador en el entorno y se espera que tengamos escenas realmente impresionantes con la nueva tecnología, mucho más cercanas a la realidad.

Otra de las restricciones en DirectX 9 y las GPUs actuales es el hecho de tener caminos de Pipeline fijos, de nuevo me explico mejor:

Actualmente las tarjetas de video disponen de dos componentes principales a la hora de gestionar los objetos, vertices y puntos de una escena, esos dos componentes son el Vertex Sader y el Píxel Shader. Para que nos hagamos una idea, los objetos son tratados primero por el Vertex Shader y después estos son pasados por el Píxel Shader en el camino a la renderización final y por el que cada punto es tratado dependiendo de una serie de factores como el ambiente, la luz… y un largo etcétera (todo esto, simplificando bastante!).

Pues bien, el número de elementos de ejecución tanto para los Vertex Shader como los Píxel Shader son uno de los puntos a favor de cada una de las tarjetas gráficas. Para hacernos una idea, actualmente la ATI X1900XTX cuenta con ocho unidades Vertex y cuarenta y ocho (16*3) para píxel, en cuanto que una NVIDIA 7950GT tiene 24 pixel Shaders y ocho Vertex Shader (mas info aquí). En un caso real (como el presentado en la gráfica de abajo) no es de extrañar que suceda que en un momento concreto necesitemos muchos Píxel Shader pero pocos Vertex y viceversa. Con el estado actual de las cosas y puesto que contamos con un Path fijo, esta situación es inevitable, pero si en vez de tener unidades especializadas en cada una de las tareas, simplemente tuviéramos unidades de ejecución genéricas, podríamos reutilizarlas y no tenerlas infrautilizada algunas, mientras que otras están saturadas..

En el siguiente artículo contaré qué son los Shaders Unificados, qué es Shader 4.0 y veremos ejemplos del salto tecnoglógico que supone DirectX 10 con respecto a DirectX 9.

Cual es el momento de la IA en el desarrollo de un juego?

Ahora que parece que los procesadores podrán dedicarle más tiempo a la IA, se estan repensando los esquemas de en qué momento debe aparecer la IA en el desarrollo de un juego.
Por regla general, no es extraño diseñar el juego y que el desarrolo de la IA aparezca después, sin embargo hay quienes abogan por que aparezca antes, casi junto al diseño.
El PodCast esta en Inglés pero no tiene desperdicio, obligado escucharlo.
Os dejo aqui un estracto:

"Whether you’re a programmer who’s always wanted to work on the game design or a designer who thinks there might be something to this “programming” thing, here’s your chance to talk with someone who has worked both sides of the fence. We’ll focus on AI and the ways in which AI development does (or should) overlap with the game design process, drawing case studies from the presenter’s experiences as Lead Designer for Rise of Nations, Alpha Centauri, and Civilization II.

We’ll talk about why delaying AI development “until the design docs are final” is a wasted opportunity, and how both AI and Design benefit from simultaneous prototyping. We’ll explore not only the traditional use of AI to determine goals and strategy for computer players, but also the critical role of AI in supplying “personality” to computer-controlled characters. Perhaps most importantly we’ll talk about the sometimes-unexpected ways AI techniques can be invaluable in content generation..

Programando la PS3 vs XBOX360

Con la llegada de la PS3 tendremos también el estreno de un nuevo CHIP llamado CELL del que se ha hablado mucho y sobre el que los desarrolladores de juegos tendrán que poner su arte y conocimientos para sacarle el máximo partido a la consola de Sony.

Algunos ya han comentado que el CELL será un gran procesador siempre que se le pueda sacar todo el rendimiento que de él se espera, pero la pregunta está en si eso será fácil para los desarrolladores.

El CELL cuenta con 1 procesador principal (Power Processing Element o PPE) que es básicamente una variación de un Power PC 970 con una cache L1 de 32KB de Datos y 32KB de Instr., además una L2 de 512KB, todo ello a 4GHz. Junto a este PPE hay ocho módulos de procesamiento llamados Synergistic Processor Element o SPE, con toda esta artillería no es de extrañar que tenga una marca teórica de nada menos que 256 GFLOPS.

Cada uno de los SPE tendrá una memoria única de 256KB, 128 registros con una anchura de 128 bits y elementos de ejecución de 128bits, se puede decir que cada SPE es una máquina de 128bits. Con esta capacidad de procesamiento tenemos que cada SPE puede ejecutar 2 Double-Float, 4 Floats o Long integers, ocho integers... etc, cada uno en un solo ciclo de reloj. Además cada SPE contiene siete elementos de ejecución de los que solamente dos podrán estar activos a la vez.

Esta arquitectura, bastante impresionante, tiene un 'pero' y es que cada SPE solamente puede acceder a sus 256 KB de memoria y no verá nada más 'allá', para pedir una palabra fuera de esos 256 KB se debe acceder a un DMA conectado a un BUS llamado Element Interconnect Bus (EIB). Esto presenta un problema a la hora de procesar grandes cantidades de información, pues hay que optimizar el "troceado" para que no haya perdida de rendimiento.

En la PS3 no veremos títulos con más de 256 MB de texturas, debido a la política de memoria, mientras que si que los habrá en X360.

Sony ha elegido bien, sin embargo, y su consola podrá ser programada en Cg (http://developer.nvidia.com/page/cg_main.html y http://en.wikipedia.org/wiki/Cg_programming_language), C++ y la API de gráficos será OpenGL|ES (http://www.khronos.org/opengles/), esta librería es un estándar con la que muchos desarrolladores están acostumbrados a trabajar, no solo en el mundo de los videojuegos sino también en CAD/CAM y otros. Además, es conocido que la curva de aprendizaje de OpenGL es muy buena y aumenta las posibilidades de encontrar buenos desarrolladores y los estudios podrán contratar a gente nueva para los desarrollos en PS3. En cuanto a Cg es una excelente elección por la facilidad de uso que tiene para los desarrolladores en cuanto a gestión de objetos gráficos, con una gran potencia, yo personalmente no he programado con Cg, pero después de haber visto algunos ejemplos y haber leído un poco, desde luego que tengo ganas de probar un poco :d...

El aspecto más duro al que sin duda se enfrentarán los desarrolladores en la PS3 no será hacer juegos, sino hacer juegos buenos y rápidos. Y no es que esto sea fácil para las demás, el problema es que esto será más difícil en la PS3.

Con el esquema del procesador que ya hemos comentado tenemos básicamente ocho elementos de ejecución más o menos independientes, que se deben usar organizadamente para poder sacarle el máximo rendimiento.

Uno de los aspectos más complejos en cualquier sistema software que se desarrolle es el hecho de la concurrencia, hacer que varios hilos de ejecución se coordinen para un objetivo común es un problema bastante complejo de afrontar.

El desarrollo de un juego con varios hilos de ejecución es el nuevo reto de los estudios de desarrollo, los procesadores de las nuevas consolas tienen varios CORES de ejecución (XBOX360 cuenta con 3 procesadores en uno, PS3 cuenta con 8 elementos de ejecución, un PC puede tener entre 1 y cuatro CORES en un mismo procesador). Este nuevo elemento en el panorama de los juegos no hace mas que enriquecer cada uno de los aspectos de los mismo, podemos tener un hilo de procesamiento para el reenderezado, otro para la física, otro para el sonido y otro para la IA... obviamente las posibilidades aumentan muchísimo cuando cada uno de los aspectos principales del juego cuenta con una unidad de ejecución que no tendrá que compartir. Este enfoque no carece de problemas, pues hay que organizar muy bien la ejecución para que la física tenga el resultado junto a la IA y el resto antes de renderizar la escena. En el siguiente artículo podemos ver este enfoque más en detalle .

Sony, consciente de que este va a ser su caballo de batalla, ya desde el principio dio algunas directrices a los desarrolladores para enfrentarse a este esquema de programación paralela. Un o de ellos es, por ejemplo, la cola de trabajo, si cada una de las operaciones que tiene que realizar la aplicación se ponen en una cola de trabajo en orden y según se van quedando elementos de ejecución libres se les va asignando la tarea tendremos un resultado que organizado a su salida nos ofrecerá el resultado esperado... obviamente el overhead que supone la organización a la entrada y a la salida de la cola, tanto como la potencia que requiere la solución de las distintas dependencias entre las distintas tareas no son gratis. Este esquema será muy valido cuando hay una alta independencia entre las tareas a realizar, caso en el que no están los juegos.

Otra de las aproximaciones, por nombrar dos, es que sea el programador quien a base de artificios típicos de la programación concurrente sea quien realice la coordinación entre las distintas tareas y cada una de ellas se va asignando a cada uno de los módulos de ejecución. El problema que presenta esta aproximación es que se necesita mucha destreza. Un ejemplo del dolor de cabeza que esto puede suponer es el QUAKE III Arena, que en su versión multithreaded era capaz de incrementar el rendimiento nada menos que en un 40%, sin embargo, fue notoria la cantidad de problemas y la fragilidad y poca estabilidad de este tipo de ejecución en el juego, que era tremendamente inestable con muchos drivers gráficos excepto con unos cuantos. Desde el punto de vista de John Carmack, en la mejora del rendimiento se ve hacia donde van los juegos actualmente, pero en la fragilidad se ve la dificultad a la que se enfrentan los desarrolladores ().

Como ultima nota dejaré este interesante articulo en donde se explican los modelos de programación y si se puede considerar fácil o no la programación en la PS3. .

En definitiva, lo que vemos es un proceso de involución en la abstracción en el desarrollo software, ya que ahora se debe tener muy en cuenta sobre qué hardware va a correr cada juego para adaptar el código de forma que se saque el mayor rendimiento, esto es un problema para lo estudios que lo que desean es tener que hacer las cosas una sola vez y poder disfrutar de ese trabajo en el mayor número de plataformas posibles.

Hasta aquí lo objetivo... ahora lo subjetivo. ¿Es difícil la programación en la PS3?, yo creo que la respuesta es si. Lo cierto que la programación de cualquier sistema concurrente conlleva una serie de problemas que en la PS3 se aumentan, debido a su arquitectura, sobre si va a ser un problema capital para la PS3, creo que no. De todos es conocido el "dolor" que supone programar en la PS2 y aunque se ha tardado en pillarle la medida, creo que se han hecho títulos increíbles para el hardware de que estamos hablando, BLACK es un ejemplo muy claro, cualquiera que haya probado este juego se da cuenta del impresionante número de objetos que se mueven en la pantalla, lo cierto es que es increíble lo que han llegado a hacer con la PS2. No creo que con la PS3 vaya a ser necesariamente mas difícil, al contrario, creo que Sony ha trabajado en facilitar las labores de desarrollo usando OpenGL y Cg.

Sin embargo, si lo que nos preguntamos es si es mas fácil desarrollar en la XBOX360, por lo que cuentan los desarrolladores, Microsoft ha creado herramientas de desarrollo muy superiores de las que tiene Sony, no obstante se debe pensar que Microsoft es una empresa de Software, cosa que no lo es Sony, o al menos si la comparamos con la maquina de hacer Software que es Microsoft.

Comenta John Carmack que es deseable que el desarrollo de un juego sea un 20% mas fácil a tener un 20% mas de potencia para poder hacer cosas. Esto es totalmente lógico si además pensamos que la XBOX360 es una excelente máquina con un Hardware que no la deja demasiado detrás de la PS3. Lo que ha conseguido Microsoft, es una plataforma de desarrollo fácil, cómoda y cuyo código se puede mudar fácilmente al PC, mientras que pasar código de la XBOX360 a la PS3 y viceversa, va a ser una tarea compleja, por la diferencia en las arquitecturas de la consola.

Creo que en todas las plataformas vamos a ver gráficos muy parecidos, pero que el motor interno y el comportamiento del juego va a ser muy distinto dependiendo de la consola. Un ejemplo lo tenemos en Assasins Creed, el impresionante juego que están haciendo en el estudio de Ubisoft en Montreal, parece que va a tener un aspecto igual en ambas consolas, sin embargo, ya se ha adecentado que la IA en la XBOX360 será un poco mejor que en la PS3, y la verdad es que esto no deja precisamente bien a la consola de Sony. En mi opinión este caso se va a repetir durante un tiempo hasta que la PS3 alcance la calidad en el desarrollo de la XBOX y a partir de ese momento Sony llevará las riendas en los juegos.

Update: Me comentan (lo ví, pero no hice el update en su momento)... y es cierto, que Ubisoft ya ha dicho que la IA será la misma para ambas consolas (el código será el mismo) y que la diferencia no será apreciable... Lo cierto es que cuando dicen que el código de la IA sea el mismo no significa, per-se, las mismas soluciones de la IA, pues el tiempo de CPU dedicado a ese hilo no es el mismo. Aunque ciertamente, no creo que veamos diferencias apreciables en el juego.
Update:A lo largo de artículo comento las características técnicas que el CELL debería haber tenido. Son 3,2Ghz en vez de 4Ghz y Siete (7) SPE, uno de ellos usado como unidad de ejecución del sistema operativo.