1. objetivos del proyecto

PFC
LOST IN DARKNESS
ÍNDICE
1. OBJETIVOS DEL PROYECTO
Introducción
Pág. 2
Pág. 2
1. Nuestros objetivos
Pág. 3
2. Breve Historia de los FPS
Pág. 4
3. Breve Historia de los Survival Horror
Pág. 8
4. Estructura de un videojuego
Pág. 10
2. ESPECIFICACIONES DEL PROYECTO
Pág. 11
1. Argumento del juego
Pág. 11
2. Esquema y mecánica de juego
Pág. 16
3. DISEÑO
Pág. 17
4. DESARROLLO
Pág. 21
1. Modelado 3D
Pág. 21
2. Diseño del escenario
Pág. 22
3. Diseño del enemigo monstruako
Pág. 24
4. oFusion: Integración en Ogre
Pág. 26
5. Implementación
Pág. 29
5. EVALUACIÓN
Pág. 42
6. CONCLUSIONES
Pág. 45
1. Conceptos que hemos aprendido
Pág. 45
2. Objetivos que no se han podido cumplir
Pág. 45
3. Conocimientos de la carrera aplicados al videojuego
Pág. 45
7. RECURSOS UTILITZADOS
Pág. 46
1. Software utilizado
Pág. 46
2. Hardware utilizado
Pág. 60
8. MANUALES
Pág. 61
1. Instalación
Pág. 61
2. Uso
Pág. 61
3. Requerimientos
Pág. 64
9. ANEXO I : CONCEPTOS RELACIONADOS
-1-
Pág. 67
PFC
LOST IN DARKNESS
1. OBJETIVOS DEL PROYECTO
1.0 Introducción
La industria de los videojuegos ha alcanzado un status equiparable a la del cine o de la música
llegando a superar las recaudaciones anuales de éstas y llegando a obtener unas ventas
comparables a las de cualquier estreno de una película Hollywoodiense.
Aunque los videojuegos han evolucionado bastante en su corta historia y han conseguido
penetrar en la sociedad aún les queda mucho camino por recorrer: No existe una sola persona
en la tierra que conozca a alguien que no haya escuchado una canción o haya visto una
película. Sin embargo, es bastante fácil encontrarte con alguien que no haya jugado jamás a
un videojuego.
Algunas de las posibles causas de este escenario pueden ser:
•
La rápida evolución de los videojuegos: Con el paso de los años y el aumento de la
tecnología los juegos han incrementando su complejidad haciendo más difícil el
acercamiento de un no jugador. Un ejemplo: Los primeros dispositivos de control
incluían una única palanca de control y un solo botón de acción. Actualmente los
dispositivos de control presentan dos palancas de control, una cruceta digital, y más de
ocho botones.
•
La industria del videojuego está poblada mayoritariamente por trabajadores
masculinos. Habitualmente se ha olvidado al mercado femenino teniendo así que,
salvo excepciones puntuales, el sector esté copado por videojuegos enfocados al
público masculino (juegos de deportes, violencia o acción).
•
Actualmente la industria del videojuego sufre de lo que podríamos denominar como el
mal de las superproducciones, nos explicamos: Conforme el número de jugadores
alrededor del mundo ha ido creciendo se han comenzado a dedicar más recursos y
presupuesto a la creación de juegos dejando lugar solo a grandes empresas provocando
primero el abandono de empresas que no pueden seguir el ritmo impuesto por las
grandes productoras y segundo impidiendo el surgimiento de pequeñas compañías con
-2-
PFC
LOST IN DARKNESS
ideas innovadoras y que podrían aumentar o diversificar aún más la oferta de
videojuegos.
1.1 Nuestros objetivos
Como estudiantes de último curso de la Ingeniería Técnica de Informática hemos querido
aprovechar la ocasión que nos brinda el Proyecto Final de Carrera para introducirnos en la
fase de creación de un videojuego poniendo en práctica gran parte de los conocimientos
adquiridos durante el transcurso de la carrera y aprendiendo nuevos conforme las dificultades
y exigencias del proyecto han ido apareciendo.
Sabemos que la complejidad de los juegos se ha ido incrementando exponencialmente durante
su corta historia. Inicialmente los juegos eran producidos por un equipo no muy numeroso de
trabajadores, incluso dándose el caso de que podía ser una única persona la que se dedicara a
realizar todas las tareas de creación del juego.
Actualmente, los equipos de desarrollo que se disponen para la creación de un videojuego
medio comercial son muy extensos contando con profesionales especializados en cada uno de
los campos en los que se divide la implementación de un juego: diseñadores, programadores,
animadores, beta-testers, etc.
Aún así y dado que somos unos grandes aficionados del mundo de los videojuegos nos hemos
decidido a intentarlo teniendo en cuenta el auge de la industria y al hecho de que la demanda
de trabajadores para este sector ha aumentado, cabiendo la posibilidad de poder formar parte
del mismo si conseguimos aprender ciertas nociones básicas.
Dentro de los múltiples géneros que podemos encontrarnos, para la creación de nuestro
proyecto hemos elegido una combinación de dos de los más exitosos: los FPS y los Survival
Horror.
A continuación veremos las características de cada uno de ellos, un breve resumen de su
historia así como un listado de los juegos abanderados de estos géneros.
-3-
PFC
LOST IN DARKNESS
1.2 Breve Historia de los FPS
(Información basada parcialmente en la wikipedia)
FPS son las siglas del término inglés First Person Shooter, en castellano Juego de Acción en
Primera Persona. A los FPS también se les conoce como Shoot em up y es uno de los géneros
más populares desde la aparición de Doom a principios de los años 90.
Id Software es, para muchos, la compañía iniciadora del género. Suyos son Wolfenstein 3D y
Doom.
Wolfenstein 3D apareció en 1992. Con este juego, Id Software mejoró la tecnología usada
hasta entonces en la creación de videojuegos añadiendo capacidades de gráficos VGA y
tarjeta de sonido.
Pero en 1993 Id lanza Doom, juego que sustituiría rápidamente a Wolfenstein 3D. Doom
mejoraba sustancialmente el aspecto gráfico de la anterior obra de Id y además introducía el
sistema de juego multijugador en red lo que aseguró la permanencia de este género entre los
formatos de juegos habituales; es mucho más atractivo jugar contra a un oponente humano,
conocido o no, en Internet.
Aunque Doom estaba creado con un motor de juego que representaba un entorno
tridimensional el jugador sólo dirigir o apuntar el arma al enemigo, sin importar la altura a la
que se encontrase éste. Fue Descent, juego en el que el usuario pilotaba una nave espacial,
uno de los primeros, sino el primero, en llevar la libertad total en 3D al género, pudiendo
mover la nave en todas las direcciones.
Doom contribuyó a la popularización del género aunque no fue el primero y, contrariamente a
lo que se piensa, este honor se le ha de atribuir a Catacomb 3D y no a Wolfenstein 3D como
la gran mayoría piensa. La importancia de Doom en la historia de este tipo de juegos es tal
que durante los primeros años a los FPS se les denominaba juegos tipo Doom.
-4-
PFC
LOST IN DARKNESS
Con Doom también se introdujo otra de las características clave del género de los FPS: la
posibilidad de crear niveles o mapas, cambiar la apariencia gráfica o incluso el modo de jugar
para después distribuirlo entre los seguidores de los FPS. Gracias a esta característica la
vigencia de algunos de estos juegos se incrementa con las aportaciones de los aficionados
creadores de nuevo contenido.
Este entusiasmo en la dotación de nuevas posibilidades a FPS que llevan su tiempo en el
mercado ha llegado hasta el punto de que se creen las denominadas Total Conversion, donde
todo el contenido original ha sido sustituido dejando sólo el motor original del juego.
Generalmente estas modificaciones del juego son gratuitas siendo una de las condiciones que
imponen los desarrolladores del juego original a los aficionados.
Actualmente la mayoría de juegos del género incluyen editores de niveles con la copia del
juego.
Con el paso de los años han ido apareciendo juegos a la estela de estos pioneros del género
que han ido añadiendo nuevos detalles y evolucionando el concepto de FPS. Algunos de estos
juegos son:
•
Duke Nukem 3D de 3D Realms, uno de los primeros FPS ambientado en entornos
“realistas” como ciudades y con objetos de la vida cotidiana. Como nota curiosa,
destacar que su secuela directa (ha habido otros juegos de la franquicia), Duke Nukem
Forever lleva en “desarrollo” más de 9 años!
•
Quake de Id Software, es el primer juego de este género con escenarios y personajes
completamente tridimensionales. Con este juego se inicia la moda de licenciar los
motores gráficos los FPS a otras compañias. Las secuelas de Quake se han ido
sucediendo hasta la actualidad cuando hace pocos meses hemos recibido la cuarta
entrega de la serie. Mencionar que la tercera parte (QuakeIII:Arena) enfocada
exclusivamente en el juego en red ha sido (y es) uno de los juegos on-line preferidos
por los jugadores de todo el mundo.
•
Unreal de Epic, sorprendió en su día con sus gráficos, aún hoy igual de
impresionantes. Una de sus secuelas originó otra de los sagas de juegos multijugador
preferidos por los usuarios: Unreal Tournament del que se espera una nueva entrega,
-5-
PFC
LOST IN DARKNESS
con la coletilla 2007, que promete exprimir al límite la capacidad de las tarjetas
gráficas más punteras disponibles actualmente.
•
Half-Life de Valve Software, considerado como un juego de culto este FPS le daba
mucha importancia al argumento haciendo que la historia dirigiera las acciones y
objetivos del jugador. Posteriormente han ido apareciendo otros FPS inspirados por las
ideas de este juego tan revolucionario. Recientemente, hará poco más de un año, ha
aparecido la segunda entrega de Half-Life. Una de sus modificaciones, Counter-Strike,
ha creado un nuevo subgénero, el de los juegos multijugador por equipo.
•
Medal of Honor de EA, donde nos vemos inmersos en plena Segunda Guerra Mundial.
A destacar que algunos de los componentes del equipo de desarrollo de este juego
fundó el suyo propio (Infinity Ward) creando Call of Duty, el exponente, para muchos,
de los FPS ambientados en conflictos bélicos.
•
Return to Castle of Wolfenstein de Id Software, nos propone una revision al “clásico”
con gráficos actualizados.
•
Serious Sam I y II de Croteam, fueron dos juegos de bajo presupuesto (en contra de la
dinámica actual en la que el coste de los juegos se ha incrementado
considerablemente) que recibieron muy buenas críticas por su sistema de juego simple
pero entretenido.
•
Deus Ex de Ion Storm, FPS que añadía elementos de juegos de rol y aventura dotando
al jugador de una gran libertad a la hora de tomar caminos y decisiones que afectaban
al desarrollo del juego.
•
Doom 3 de Id Software, usando complejos sistemas de luces y efectos de sombras que
proporcionan las modernas tarjetas gráficas se consiguió crear una atmósfera lo más
terrorífica para el jugador.
Inicialmente, este tipo de juegos fue exclusivo de los PC’s debido al poco poder de cálculo de
las consolas en aquel momento. Con la llegada de chips gráficos incluidos en los cartuchos
(SuperFX para SuperNes) y add-ons (32-X para MegaDrive) se pudo disfrutar por primera
vez de este género en las videoconsolas aunque, eso sí, con versiones rebajadas con respecto a
los originales en PC.
Esto nos lleva a comentar que los FPS están entre los juegos que más recursos de ordenador
consumen, provocando que muchos jugadores actualicen sus equipos para alcanzar los
-6-
PFC
LOST IN DARKNESS
requerimientos de este tipo de juegos. Los FPS han sido catalizadores para el desarrollo de las
tarjetas gráficas (aceleradoras) 3D.
Actualmente, las consolas son lo suficiente potentes como para soportar FPS a una calidad
comparable a las versiones de PC pero siguen sin contar con la misma popularidad y
aceptación debido a que el sistema de control de los PC’s (teclado + ratón) sigue siendo más
preciso que el joystick1 o joypad2 de las consolas (aunque también se encuentran disponibles
estos periféricos para consolas sin llegar a ser el estándar de control).
Aún así ya podemos encontrar en el mercado de las videoconsolas FPS de gran aceptación
entre el público como pueden ser: Halo (1 y 2 para XBOX, la tercera parte en preparación
para XBOX360), KillZone (PS2, la segunda parte en preparación para PS3) o Metroid Prime
(1 y 2 para GameCube, la tercera parte en preparación para Wii).
Debido a su realismo y a su alto grado de violencia, los FPS han sido relacionados en
numerosas ocasiones con desafortunados sucesos tales como los de la masacre del Instituto
Columbine aunque no existe prueba clínica que demuestre que los FPS puedan crear en la
persona un comportamiento violento.
Se espera que este año 2006 sean lanzados al mercado más de 20 FPS (entre ellos los
esperados Enemy Territoy: Quake Wars, Huxley, Medal of Honor: Airborne, Prey y Unreal
Tournament 2007 del que ya hemos hablado anteriormente).
Sin riesgo a equivocarnos podemos afirmar que el futuro de los FPS es bastante prometedor
ya que el uso de las capacidades de las nuevas tarjetas gráficas, IA’s más elaboradas gracias al
potencial de los nuevos procesadores y el uso de físicas realistas (con engines físicos como el
Havok 3.0) permitirán a los desarrolladores crear experiencias de juego revolucionarias.
1
2
Joystick: Dispositivo de control mediante una palanca de mando analógica.
Joypad: Dispositivo de control mediante una cruceta digital.
-7-
PFC
LOST IN DARKNESS
1.3 Breve Historia de los Survival3 Horror
(Información basada parcialmente en la wikipedia)
El género de los Survival Horror fue inaugurado por el desconocido Sweet Home y tiene sus
máximos exponentes en títulos como Alone in the Dark, Silent Hill y Resident Evil, siendo
este último el que más popularidad ha otorgado al género.
Sweet Home es un videojuego de Survival Horror lanzado en la FAMICOM (la NES4
japonesa) producido por la compañía CAPCOM creadora de juegos como Street Fighter II,
Ghouls & Ghosts o el propio Resident Evil.
Aunque podría pasar por un juego de rol, Sweet Home es considerado por muchos el primer
Survival Horror de la historia de los videojuegos y ha servido como fuente de inspiración para
los juegos de la saga Resident Evil o BioHazard, como es conocida en Japón.
Sweet Home explica la historia de un grupo de cinco personas que se adentran en la mansión
de un pintor recientemente fallecido para fotografiar sus cuadros. Lo que este grupo descubre
al entrar es que están encerrados y la mansión está poseída por el espiritú del pintor y otras
criaturas por lo que deben buscar la salida antes de que sea demasiado tarde.
En los juegos del tipo Survival Horror el protagonista cuenta con poca libertad de
movimientos (caminar, correr, apuntar y atacar) y es común contar con un inventario
reducido, es decir, poca munición, pocos ítems curativos, dificultades para salvar la partida,
etc.
La finalidad de estos juegos es crear una atmósfera angustiante a base de recortar la libertad
del jugador presentando en momentos puntuales el “susto”, por así decirlo, como si de una
película de terror se tratara. El objetivo final del juego es sobrevivir mientras eludes todas las
dificultades, enemigos y sobresaltos por los que te hacen pasar los creadores.
3
Supervivencia en inglés.
Siglas de la consola doméstica de 8 bits de Nintendo: Nintendo Entertainment System lanzada a finales
de los años 80.
4
-8-
PFC
LOST IN DARKNESS
Otra característica de estos juegos es la presencia de pequeños puzzles o acertijos para
resolver a lo largo del juego requiriendo ciertas dotes de investigación y observación por parte
del usuario. De esta forma se le añade un toque aventurero que sirve como contrapunto a los
momentos de tensión presentes a lo largo del juego
En los últimos tiempos, el survival horror se ha puesto de moda gracias a los recientes
Resident Evil 4 o Silent Hill 4 y ante la próxima aparición de una nueva entrega de Alone in
the Dark para Xbox360. Igualmente, también se encuentran en preparación las próximas
entregas de las sagas Resident Evil y Silent Hill para las consolas de nueva generación.
-9-
PFC
LOST IN DARKNESS
1.4 Estructura de un videojuego
Todo videojuego ha de tener la siguiente estructura de capas:
1. Creación del mundo:
En esta fase se recopila la información necesaria que define el mundo del juego:
a. Los modelos del mundo (escenario y entidades del juego).
b. Las características de las entidades (vida, velocidad, etc.).
c.
2. Lógica:
En esta fase se determina el comportamiento del mundo como conjunto:
a. Recoger las señales de entrada (teclado, ratón, joystick, etc.) del jugador.
b. Determinar cómo se verá afectado el mundo del juego a partir de esas señales
de entrada.
c. Evaluar los posibles cambios en la lógica del juego.
d. Calcular el nuevo estado de juego
3. Render5:
En esta fase se representa el mundo actual con los cambios derivados de la interacción
del usuario o de las entidades del juego presentando:
a. El mundo 2D/3D con sus personajes, animaciones, escenario y la física
asociada.
b. El sonido del mundo
4. Destruir Mundo
Esta fase es complementaria a la de Construir Mundo borrando de memoria todas las
entidades cargadas en esa primera fase y, en definitiva, destruyendo el mundo del
juego.
5
Es la parte del código que pone en pantalla los ambientes y objetos.
- 10 -
PFC
LOST IN DARKNESS
2. ESPECIFICACIONES DEL PROYECTO
2.1 Argumento del juego
Son las 23:35.
Conduces tu TAKURA SPIRIT del 78 por la carretera comarcal; dirección: tu cabaña del
bosque, ese refugio espiritual donde te escondes cada vez que los fantasmas del pasado vienen
a acecharte.
Maldices al alcalde Carter. Prometió arreglar la carretera durante la campaña electoral del
pasado verano. Salió reelegido por amplia mayoría pero todo el mundo cree que no acabará su
mandato: se muere de cáncer de colon. Extraño que no sea de pulmón, el viejo Vince Carter
fuma 3 paquetes de Winston al día. Según Doc, el médico del pueblo, no le quedan más de
dos inviernos, tres a lo sumo si la suerte le sonríe. Vince lo tiene asumido. Se le ve más
simpático que de costumbre, como si quisiera arreglar los estropicios que ha cometido durante
todos estos años de mandato.
Aunque, realmente, piensas que sí ha hecho cosas buenas.
Reacondicionó el parque de la ciudad para el uso público. Había quedado inservible desde
aquella sentada hippie del 75 con refriega policial incluida. Una de tantas paradojas de la vida
que has podido recopilar a lo largo de los años ha sido ver pasear por el parque Wells a
algunos de los componentes de aquella sentada con su vestido de Armani, su maletín
Samsonite y su móvil 3G. Dónde quedaron los ideales, piensas.
El bueno de Vince recuperó hace 10 años el viejo edificio Munroy, emblema de la ciudad, en
posesión de una multinacional de las hamburguesas desde finales de los 80. Al edificio
Munroy, de principios del siglo XX, se le conoce cómo “El pequeño rascacielos de
Springfield” debido a su altura y a su impresionante fachada. Vince reconvirtió el edificio en
la nueva biblioteca municipal, la envidia de las poblaciones colindantes, no sólo por el
impresionante inmueble en el que se ubica si no también por la importante colección de libros
que alberga. Últimamente has pasado muchas tardes documentándote para tu nuevo trabajo.
- 11 -
PFC
LOST IN DARKNESS
Recuerdas que fue tu profesor en secundaria. Era bueno, no al nivel de Robbin Williams en
“El club de los poetas muertos” pero influyó mucho en tu decisión de dedicarte a lo que
haces. Cuando Jonah Jeremies dejó la alcaldía, hará ya dos décadas, Vince abandonó la
docencia y se involucró en las tareas municipales, primero como concejal y finalmente como
alcalde.
- “Bob” - te dijo en una ocasión – “piensa en tus relatos como si puertas mágicas que se abren
a otros mundos. Posibilidades de viajar a dimensiones paralelas. Nunca le des la espalda al
otro lado…” Fue al finalizar la clase de literatura contemporánea. Siempre te quedabas a
charlar un rato con él pidiéndole consejo sobre como encarar tus primeras redacciones. Vince
agradecía tu interés por la escritura, más de una vez te había expuesto como ejemplo al resto
de la clase, con el consiguiente enrojecimiento de tus mejillas. No todos los alumnos
entendían lo que Vince quería ejemplificar y a veces acababas con un ojo morado por pura
envidia.
Gracias a él y a aquella preciosa chica que conociste en secundaria eres escritor. No un
escritor muy famoso pero has conseguido cierto reconocimiento entre la crítica. Acabas de
conceder una entrevista para el New Yorker. Te han preguntado sobre tu nueva novela,
“Perdido en la oscuridad”. No esperas mucho, una pequeña columna en la sección literaria de
los viernes. En definitiva, un pequeño empujón para acelerar las ventas. Mañana tienes otra
entrevista para la televisión. Tienes una semana ajetreada conla promoción de tu libro. Como
dice Peter Fender, tu agente literario: “Tienes que prostituirte para que, de vez en cuando, te
dejen ordeñar a la vaca.” Peter y sus analogías escatológicas. Siempre bromea diciéndote que
puedes convertirte en el nuevo Dan Brown.
- Métete con la iglesia. – dice - ¡Seguro que conseguirás la atención de los medios!
Pero tu estilo es otro. Te dedicas a escribir novelas de terror. Lo tuyo no es provocar a la
opinión pública, tu fuerte es describir situaciones donde el miedo es el instinto más básico.
Te aficionaste a la obra de Stephen King una noche lluviosa en la que no podías dormir. Tus
padres no estaban en casa, habían salido a cenar con unos amigos. Te habían dejado al cargo
de la tía Emmylou, la solterona – comprensible debido a su poca agraciada fisonomía-, que se
- 12 -
PFC
LOST IN DARKNESS
durmió después de su segunda copita de anís sentada en la poltrona de tu habitación mientras
intentaba leerte un fragmento de “Las mil y una noches”. Fuiste al despacho de tu padre con
la intención de coger una de las revistas que tu padre guardaba en el segundo cajón del
escritorio. Solamente tenías 10 años pero las hormonas ya habían comenzado a ejercer su
cruel influjo sobre ti, comenzaba la adolescencia. Satisfecho de haber conseguido la revista
sin oposición alguna de ningún adulto te dispusiste a salir del despacho de tu padre, dirección
el cuarto de baño, cuando alzaste tu mirada de niño pícaro y reparaste en el libro que reposaba
sobre la mesa del escritorio. La encuadernación te llamó la atención: el color negro
predominaba sobre todos los elementos que formaban parte de la composición y en el centro
de la portada bajo unas letras que chorreaban sangre se intuía la sombra de lo que podía ser un
vampiro.
La novela era “El misterio de Salem’s Lot” de Stephen King.
- ¿De dónde obtiene la inspiración adecuada para escribir relatos tan sobrecogedores? – te
preguntó uno de tus fans en la feria del libro del condado de Hampshire del pasado verano.
No supiste contestar, o no quisiste…
Recuerdas lo bien que se portó contigo Peter hace tres años, cuando sufriste aquel bloqueo
que te impedía escribir. Fue una temporada larga de sequía literaria. No es que seas un autor
muy prolífico pero acostumbras a escribir un relato largo por año. Afortunadamente tenías
preparados varios relatos que no habían sido publicados y pudiste cumplir con tus
obligaciones con tu editorial. Aquel verano de hace tres años fue muy duro, tuviste que
superar la pérdida de tu musa, tu ser más preciado. Este recuerdo te lleva a pensar en el
incidente que lo desencadenó todo…
Piensas en Mary.
Conociste a Mary en secundaria, en el club de lectura. Iba un curso por delante de ti y
adoraba, al contrario que tú, a los autores antiguos. No soportabas sus continuas referencias a
los libros de Homero. Siempre has preferido la lectura de los autores “vivos” y jamás has
comprendido la necesidad de idolatrar de algunas personas. Pero con Mary eras diferente
porque era tú Mary. Ella era dulce y supiste que sería tu compañera desde el día en que la
conociste.
- 13 -
PFC
LOST IN DARKNESS
El amor no tardó en aflorar y te declaraste a ella durante el baile de graduación del instituto.
La llevaste al patio del instituto, se sentó en uno de los desgastados bancos y le confesaste lo
que sentías y que ella intuía. Nunca olvidarás la mirada que te dedicó Mary en el momento en
el que le dijiste que la querías.
Os graduasteis los dos como filólogos en la Universidad de Stanford. Siempre pensaste que a
ella se le daba mejor la escritura pero decidió dedicarse a la docencia y fuiste tú quien se
propuso hacerse un nombre dentro del mundo de la literatura.
Has vuelto a esquivar ese bache. Si no fuera por que conoces el camino y lo has recorrido a
plena luz del día el resultado habría sido muy diferente.
Vas a poner la radio. Estás cansado de escuchar esa antigua cinta de Garth Brooks. Presionas
‘Eject’ con tal fuerza que la cinta cae al suelo del coche. Te reclinas para recogerla, estiras el
brazo, casi la tienes, un poco más y ya está. Cuando vuelves la vista a la carretera ves algo en
la mitad de la calzada pero es demasiado tarde. Vas a chocar con… eso.
Consigues dar un volantazo pero finalmente has embestido a esa cosa que grita con un
estremecedor alarido de dolor. Piensas que demandaras al bicho si te ha abollado la carrocería
de tu apreciado bólido pero desechas este pensamiento en cuanto ves que, debido al brusco
cambio de dirección te diriges a la cuneta, precipitándote por ella.
[…]
Pero… ¿Qué ha pasado?
Eres Bob Garret, escritor de novelas de novelas de terror, y acabas de sufrir un accidente de
coche en el trayecto a tu cabaña en el bosque, al norte de tu ciudad, Springfield.
Tu vehículo ha quedado inservible, cuatro vueltas de campana lo han conseguido, y decides
llegar hasta tu cabaña caminando los escasos 1000 metros que te separan de ella. Entre tu
destino y tú se interpone una loma franqueada por pinos. La luz de la luna, combinada con
una ligera niebla le da un aspecto bastante tétrico al bosquecillo pero tu dolorida cabeza
- 14 -
PFC
LOST IN DARKNESS
todavía recuerda este lugar por el que tantas veces has corrido cuando eras un niño. Crees
haber visto millones de veces ese paisaje y podrías caminar por él con los ojos vendados pero
hoy notas que algo ha cambiado. Presientes que algo va a pasar, y nada bueno.
Pese la difícil situación debido a la posición del coche volcado has conseguido abrir el
maletero. Una pala, la rueda de recambio, una escopeta, cartuchos y una linterna son su
contenido.
Te llevas contigo la linterna. Conoces el camino pero está oscuro y esa cosa anda suelta y
seguramente estará cabreada después del golpe que ha recibido. Así que decides extremar las
precauciones. Cargas la escopeta de caza heredada del tío Tom y te la echas al hombro.
Comienzas a caminar en dirección a tu casa. Esperas que la tormenta del pasado fin de
semana no haya cortado las comunicaciones y puedas avisar por radio a la comisaría.
Se te empieza a erizar la piel, no sabes si por el frío o por el miedo…
- 15 -
PFC
LOST IN DARKNESS
2.2 Esquema y mecánica de juego
Por tanto, una vez hemos visto cuáles son las principales características de este tipo de
videojuegos (tanto FPS como Survival Horror) la creación de un videojuego que combine
estos dos géneros ha de cumplir con las especificaciones mínimas siguientes:
Dotar al jugador de la posibilidad de moverse en un entorno 3D atractivo y realista con
la atmósfera adecuada para provocar en el usuario cierto sentimiento de angustia o “miedo”.
Para conseguir este propósito será necesario:
o Presentar una serie de entidades en pantalla que ejercerán el papel de enemigos del
protagonista y actuarán en consecuencia a ello siguiendo y atacando al jugador por todo
el escenario de juego (siempre y cuando le hayan detectado antes).
o Tanto jugador como enemigos han de sufrir los efectos de la física dotando de esta
manera de más realismo al conjunto.
o Reproducir sonidos y música para crear el ambiente de juego.
o Reproducir vídeos (introducción y demostración).
o Diseñar un escenario coherente y adaptado a la temática del juego donde el usuario
pueda experimentar todas las características de este tipo de juegos.
o Creación de menús vistosos y atractivos para el usuario.
- 16 -
PFC
LOST IN DARKNESS
3. DISEÑO
Para que con nuestro proyecto podamos cumplir con la estructura de capas de todo videojuego
hemos decidido:
•
Representar el entorno tridimensional interactivo con Ogre3D como motor gráfico
debido a su potencia y a que es software libre. Además nos permitirá mostrar, gracias
a una serie de overlays, información sobre el estado del juego (vida, munición, etc.).
•
Tratar la física de las entidades del juego con OgreODE como motor de física. Habían
otras alternativas como NxOgre, OgreNewt, etc. pero elegimos OgreODE ya que
contaba con una demo donde se implementaba, muy básicamente, un FPS.
•
Tratar la reproducción de sonido con el gestor de sonido SoundManager que hemos
podido encontrar en el código fuente (abierto) de la aplicación “Stunt Playground 2.0”.
•
Tratar la reproducción de vídeos con el plugin Theora para Ogre3D que permite
decodificar vídeos .OGG con los formatos Theora (para la parte de la imagen) y
Vorbis (para la parte del audio).
•
Crear la interfície gráfica de usuario o GUI con CEGUI, integrado con el motor
gráfico Ogre3D.
Tanto el motor gráfico, el gestor de sonido, el de vídeo y nos permiten cumplir con la primera
y tercera fases o capas de la estructura de un videojuego: Creación del Mundo (con la carga
de modelos, sonidos, vídeos, etc.) y Representación o Render del mundo (dibujando por
pantalla los elementos y reproduciendo vídeos y sonido).
Para cumplir con la segunda capa, la de Lógica, el motor de Ogre3D nos proporciona el
acceso a la información de la entrada de teclado y ratón permitiéndonos de este modo utilizar
esta información para determinar los cambios que sufrirá el mundo de nuestro juego.
OgreODE nos proporciona el soporte para representar los efectos de la física (y su influencia)
en los elementos del juego.
También queremos que nuestro juego realice diferentes funciones básicas dependiendo del
contexto en el que se encuentre el usuario. Esas funcionas serán las siguientes:
- 17 -
PFC
LOST IN DARKNESS
o Reproducción de vídeos: Tendremos que crear un estado en el que se muestren vídeos
por pantalla.
o Menú principal: Tendremos que crear un estado en el que se muestren el menú principal
del juego por pantalla. Sería interesante también la posibilidad de reproducir vídeos cada
cierto tiempo (con un timer, por ejemplo).
o Pantalla de juego: Tendremos que crear un estado en el que se desarrolle la partida del
jugador. Se ha de permitir en todo momento volver al menú principal, pausar el juego o
la posibilidad de reproducir vídeos.
o Pantalla de pausa: Tendremos que crear un estado en el que pueda pausar la acción de la
partida. Se ha de permitir despausar el juego y/o volver al menú principal del juego.
Por tanto, y dadas nuestras necesidades, el esquema o grafo de estados por los que
pasaría nuestro juego sería el siguiente:
Imagen 1 : Grafo de Estados por los que pasa LiD
- 18 -
PFC
LOST IN DARKNESS
En cuanto a las entidades del juego hemos decidido definir las siguientes estructuras de datos:
o Jugador:
Aquí guardaremos la información relacionada con el protagonista del juego: posición, vida,
munición, el modelo del arma, etc.
o Enemigo:
Aquí guardaremos la información relacionada con cada uno de los enemigos del juego:
posición, vida, modelo del enemigo, estado, etc y las rutinas necesarias para determinar el
comportamiento de éste con respecto al mundo que variará, en gran parte, de las acciones
del jugador.
Los estados por los que puede pasar una entidad del tipo enemigo son las siguientes:
•
IDLE, es el estado inicial en el que el enemigo se encuentra estático (pero animado).
•
MOVING, es el estado en el que pasará la mayor parte del tiempo. Si el jugador no
está dentro del campo de visión (o detección) del enemigo, éste seguirá un camino
prefijado. En el momento en que el jugador es detectado por la entidad Enemigo éste
comenzará a seguirlo.
•
ATTACKING, es el estado al que pasará Enemigo en el caso de que esté a la distancia
para realizar un ataque.
•
ATTACKED, es el estado al que pasará Enemigo en el momento de ser impactado por
el arma del Jugador.
•
DEAD, es el estado al que pasará Enemigo en el momento que su contador de vida
llegue a cero.
De la estructura o clase Enemigo hemos creado dos subclases o clases herederas (Zombie y
Monstruako) para los dos tipos de enemigos que vamos a presentar en el mundo del juego
cada una. Cada clase heredera implementa los métodos necesarios para diferenciarse la una
de la otra cargando los modelos y sonidos correspondientes.
o Horda, será una colección de enemigos (tanto Zombies como Monstruazos) que nos
servirá para poder ejercer un control, en todo momento, sobre cada uno de ellos.
- 19 -
PFC
LOST IN DARKNESS
4. DESARROLLO
En este apartado debemos indicar, de acuerdo con la estructura en capas típica de una
aplicación tipo juego, en qué capas nos estamos moviendo. Partiendo de aquí luego iremos
bajando a la estructura del elemento en sí.
Todos los objetos y clases que se exponen a continuación se han desarrollado en las
siguientes capas:
•
Crear mundo: puesto que hemos relacionado los datos de nuestra aplicación con
OGRE. Leer y cargar en memoria los datos necesarios del juego e inicializar el motor
con estos datos.
•
Destruir mundo: hemos destruido los datos de la aplicación.
•
Lógica de juego: hemos gestionado la entrada y salida y determinar como afecta al
mundo, calcular el estado del juego, comportamiento de los enemigos (estados, IA),
comportamiento del mundo ante la física (escenario y enemigos).
•
Render: hemos mostrado siempre el estado actual del mundo de nuestra aplicación
juego en 3D, con sus efectos gráficos y sonoros, sus animaciones, su escenario, etc.
De acuerdo a lo descrito anteriormente y en diseño, en el apartado Implementación se expone
la estructura el juego o proyecto a fondo, mostrando detalle de las clases participantes y luego
haciendo énfasis en los métodos de cada una y los principales del motor gráfico OGRE.
Comenzaremos por los objetos más generales e iremos desglosando específicamente.
4.1 Modelado 3D
Llegado a este punto, estamos desarrollando en la capa de crear mundo de nuestra aplicación
tipo juego. Realmente estamos creando datos, porque los modelos digitales en 3D no dejan de
ser datos para una aplicación de estas características. Así pues, creados previamente los
modelos de nuestra aplicación luego los podemos utilizar e inicializar el motor gráfico con
estos elementos 3D.
El modelado es un apartado realmente importante en la creación y desarrollo de videojuegos.
Al establecer las fases del proyecto, se incluyó el modelado digital en 3D. Esto requería no
sólo conocer a fondo las herramientas y manera de realizarlo sino también encontrar el modo
adecuado de integración en OGRE. Todo ello teniendo en cuenta que todas las utilidades
siempre han estado en fase de desarrollo, desde el inicio del proyecto hasta la actualidad y
nunca en una versión release definitiva.
Posteriormente en la bibliografía y recursos utilizados se hablará de todas las herramientas
estudiadas y utilizadas para testear, pero el software principal ha sido el 3D Studio Max 7 de
Discreet, usado bajo licencia de Discreet.
- 20 -
PFC
LOST IN DARKNESS
Este programa de modelado y animación se ha utilizado fundamentalmente para 2 elementos:
el escenario y uno de los enemigos, llamado monstruako.
A continuación vamos a explicar en alto nivel como se han desarrollado estas tareas, sin
profundizar en el más bajo nivel de modelado.
4.2 Diseño del escenario
Cabe decir que se poseían conocimientos de diseño digital en 3D, pero aun así se ha
necesitado un tiempo de documentación y formación para utilizar más a fondo esta inacabable
y potente utilidad.
Como en todo juego siempre hay un boceto o esquema inicial de la escena deseada.
Luego se debe modelar utilizando primitivas de dibujo, splines y otros elementos para darle
forma y realismo a los objetos.
- 21 -
PFC
LOST IN DARKNESS
Otro mundo muy amplio es el de la texturización. Una vez diseñado el modelo hay que tener
paciencia y tesón para lograr tener unas buenas texturas. Esto aumenta considerablemente el
detalle y realismo del nivel antes de finalizarlo.
- 22 -
PFC
LOST IN DARKNESS
4.3 Diseño del enemigo monstruako
El desarrollo para modelar un enemigo es muy parecido al del escenario. Lo único diferente
es que un modelo animado requiere mucho más trabajo: huesos para asignar al modelo y
simular movimiento en animaciones físicas.
Se debe empezar por un boceto.
Luego modelarlo con primitivas, splines y otros elementos para obtener polígonos.
- 23 -
PFC
LOST IN DARKNESS
A continuación texturizarlo. En este caso hay varias alternativas: asignar una textura simple,
asignar una textura de Adobe Photoshop ajustable al modelo, etc.
En este caso debemos crear un esqueleto de huesos (bones) con el 3Dstudio, asignarlos al
modelo 3D correctamente para que cada hueso o parte del cuerpo simule el movimiento
adecuado y luego animarlo (biped animation) en frames.
- 24 -
PFC
LOST IN DARKNESS
*Huesos animados separado del modelo 3D
4.4 oFusion: integración en ogre
Una vez se dispone de todos los modelos debemos integrarlos en nuestro motor gráfico
OGRE. La herramienta utilizada para exportarlos es oFusion creada por Andrés Carrera y de
la que podemos consultar en la bibliografía todos sus recursos.
Es una herramienta en pleno desarrollo, a la espera de más y completas versiones. Permite
exportar a OGRE escenario, meshes (modelos 3D optimizados en memoria), luces, cámaras,
animaciones físicas de los modelos, etc. En definitiva toda la escena completa. Nos
proporciona un ‘viewport’ en tiempo real de cómo quedaría la escena en el engine. A pesar de
que facilite bastante las cosas, las texturas de todos los modelos (enemigos, objetos,
escenario) deben convertirse a OgreMaterial siguiendo procedimientos y tutoriales del
- 25 -
PFC
LOST IN DARKNESS
oFusion lo que forma la parte más compleja del proceso de integración. Es un proceso largo y
complicado y requiere el uso de programas VertexShader y PixelShader para adecuar las
texturas al engine.
Luego el mismo oFusion proporciona una librería con instrucciones de carga en el engine
llamada OgreOSMScene. El formato de la escena es OSM (exportado desde 3Dstudio).
Así pues podemos disfrutar de nuestros modelos en movimiento en una aplicación juego o de
cualquier otro tipo 3D mediante OGRE.
- 26 -
PFC
LOST IN DARKNESS
*Escenario de prueba para física, animaciones y efectos
- 27 -
PFC
LOST IN DARKNESS
4.5 Implementación
Partiendo de un proyecto vacío de Visual C++ 7.1, se ha utilizado un ‘project wizard’ del
motor gráfico, para así tener un esqueleto básico de código en un fichero llamado main.cpp.
Éste contiene las cabeceras, tratamiento de las excepciones para OGRE y otras interfícies, así
como la primera y más importante llamada a un objeto de nuestro proyecto: GameManager.
GameManager* juego = new
GameManager()
Aquí estamos creando el juego en si. Obtenemos una variable ‘juego’ a partir del constructor
de la clase ya mencionada.
La clase GameManager, como su propio nombre indica, gestiona el funcionamiento del juego
al más alto y amplio nivel: cambio de estado, entrada/salida, recursos, etc.
Como elemento principal de ésta tenemos:
std::vector<EstadoJuego*>
Estados
que es un vector de ‘EstadoJuego’ clase que posteriormente se comentará. EstadoJuego son
los diferentes estados de juego que tenemos, al estilo de cualquier juego comercial: intro,
pausa, jugar, otros, etc. De esta manera tenemos métodos para cambiar de un estado a otro y
por supuesto cada estado tendra su código para sus necesidades.
Esta clase también contiene un puntero al gestor de entrada y salida de la aplicación:
InputManager*
así como las variables de OGRE necesarias para la inicialización del motor:
Ogre::Root* mRoot;
Ogre::RenderWindow*
mRenderWindow;
Ogre::SceneManager* mSceneMgr;
Ogre::Viewport* mViewport;
No entraremos a fondo en los objetos puesto que existe un completo manual de nuestro
‘engine’ que explica perfecta y ámpliamente la estructura de los objetos y métodos.
Simplemente se hará referencia a la necesidad de su inclusión y sus funciones.
- 28 -
PFC
LOST IN DARKNESS
El objeto Root es el más importante de OGRE. Si éste no existe o no es creado, no se puede
utilizar ninguna característica. Posee la función de inicialización.
El objeto RenderWindow hace referencia a una ventana sobre la cual se puede renderizar
una escena. También muy necesaria para aplicaciones o juegos.
El objeto SceneManager es el gestor de un escenario que tenemos en una render window.
Controla todos los contenidos de la escena en memoria: paisaje, cielo, luces, entidades
(meshes, nodos), efectos, eventos y establece que partes de la escena se mandan al sistema de
renderizado para la visualización (render window).
El objeto Viewport es la sección de pantalla visible al jugador o usuario.
El objeto Camera nos permite visualizar el contenido del escenario. Renderiza puntos de
vista. Está muy relacionado a la clase viewport.
Los métodos más interesantes de nuestra clase implementada son:
- Contructor GameManager()
Inicializa las variables Root e InputManager
- Destructor ~GameManager()
Borra el vector o pila de estados de juego y también limpia el entorno de root y gestor de
entrada y salida. Es importante borrar los punteros para la correcta gestión de memoria y
posterior utilización.
- GameManager* GameManager::getSingletonPtr()
Método que devuelve un puntero a la clase. Cabe decir que la clase está creada como
Singleton, es decir, sólo puede haber una instancia de la misma clase en todo nuestro proyecto
- GameManager::start(EstadoJuego* estado)
Este método inicializa todos los recursos del juego, el gestor de entrada y salida con sus
procesadores de eventos y por último establece el estado inicial indicado por parámetro.
Para inicializar los recursos implementamos un método llamado setupResources() de la
misma clase, el cual carga un fichero típico de OGRE llamado resources.cfg que contiene los
paths a todos los recursos del juego como modelos, texturas, escenarios, música, efectos,
materiales y derivados.
Para el gestor de entrada y salida añadimos 3 procesadores de eventos de OGRE
(teclado,
ratón y movimiento de ratón) puesto que queríamos controlar el juego con estas interfícies.
mInputManager = new InputManager(mRoot->getAutoCreatedWindow());
mInputManager->getEventProcessor()->addKeyListener(this);
mInputManager->getEventProcessor()->addMouseListener(this);
mInputManager->getEventProcessor()->addMouseMotionListener(this);
- 29 -
PFC
LOST IN DARKNESS
Así pues nuestro personaje se podrá controlar mediante teclado y mediante ratón (estático o
en movimiento).
Por último se especifica el estado inicial del juego y se establece mediante el método de la
clase cambiarEstado(estado).
Este método usa instrucciones típicas del manejo de estructuras de datos como pilas y
vectores que hemos implementado. El método de cambiarEstado no sólo se utilizará en la
inicialización del juego sino también al reiniciar, pausar o jugar.
El funcionamiento consiste en primero limpiar el estado actual y posteriormente guardar e
iniciar el nuevo estado. Todo ello como hemos dicho usando push y pop.
- GameManager::pushEstado(EstadoJuego* estado)
- GameManager::popEstado()
Métodos que permiten guardar o extraer de una pila o vector el estado que interese en cada
momento. Una vez realizada la operación se llama al método entrar (estado destino) y salir
(estado antiguo). Estas dos funciones pertenecen a la clase EstadoJuego que a continuación
veremos.
- Por último la clase GameManager contiene otros métodos que OGRE requiere que estén
definidos en la misma clase como funciones de eventos sobre frames necesarios para
renderizar y saber la situación de la escena y actuar en cada momento (frameStarted &
frameEnded) y todas las funciones de las 3 interfícies de entrada y salida (teclaPulsada,
teclaLiberada, ratónMovido, etc).
A continuación debemos hablar de la clase EstadoJuego, otro objeto importante en nuestro
proyecto. De aquí derivarán los 3 posibles estados de juego (intro, pausa y juego) cada uno
con su código y utilizando el esqueleto definido en esta clase para adaptarlo a sus
necesidades.
La estructura de esta clase es la siguiente:
- Métodos entrar, salir, pausar y reanudar: son necesarios para el correcto cambio de estado
como antes hemos explicado. Las posibles transiciones son:
1 – Entrar
2 – De entrar a salir o pausar
3 – De pausar a reanudar o salir
4 – Salir
Hay que controlar los punteros en cada uno de estos 4 métodos según el estado, debido a que
se pueden crear objetos ya existentes y en ese caso el motor gráfico devolvería excepción.
- 30 -
PFC
LOST IN DARKNESS
- Esqueleto de los métodos de las 3 interfícies de entrada y salida, las cuales adaptará cada
estado a su conveniencia.
- Esqueleto de las funciones de eventos sobre frames.
- Métodos de cambiar estado, push estado y pop estado (que realmente llaman al
GameManager con la función de getSingleton puesto que es el que lo gestiona).
La siguiente clase que nos ha aparecido comentando la estructura es la de InputManager.
Esta gestiona la entrada y salida de la aplicación, seleccionando e inicializando las
interfícies deseadas para su control.
En nuestro caso: ratón, movimiento de ratón y teclado.
Esta clase contiene constructor y destructor,
- Constructor: inicializa el procesador de eventos de OGRE sobre la render
window y las
2 últimas instrucciones dejan al motor listo para la entrada y
salida sobre cualquiera de
las 3 interfícies establecidas.
mEventProcessor = new Ogre::EventProcessor();
mEventProcessor->initialise(window);
mEventProcessor->startProcessingEvents();
mInputDevice = mEventProcessor->getInputReader();
- Destructor: destruye el procesador de eventos anteriormente creado.
Este objeto también es de tipo singleton. Solamente una instancia para él en toda la
aplicación. Por consiguiente disponemos del método para obtener el puntero a su acceso.
InputManager*
InputManager::getSingletonPtr()
A continuación vamos a describir las entidades que formarán parte de nuestro juego así como
los estados.
ENTIDADES JUEGO
En esta clase disponemos de 5 entidades:
- Clase jugador: variables y métodos relacionados con todo lo que hace referencia al player
(posición, vida, balas, modelos, acciones).
- Clase enemigo: variables y métodos para el control de un enemigo (posición,
animaciones, modelos, acciones, gestión de estados).
- 31 -
vida,
PFC
LOST IN DARKNESS
Las siguientes 2 entidades heredan de la clase anterior y se han creado con la finalidad de
facilitar el manejo de las entidades, cada una con sus características propias:
- Clase zombie: es un enemigo y lo que le diferencia del resto de enemigos es el particular
modelo gráfico, particulares acciones, la velocidad, la vida, la física, los sonidos, etc.
- Clase monstruako: también es un enemigo de nuestro juego y la diferencia
características y habilidades del monstruo.
radica en las
- Clase horda: contiene a todas las entidades del juego. Los enemigos en un vector
clasificados, el jugador y el escenario.
Para nuestros enemigos disponemos de una serie de constantes y enumerados de control:
#define maxEnemies
20
-máximo de enemigos en tiempo de ejecución, modificable
enum states {IDLE, MOVING, ATTACKING, PREPARING_ATTACK,
ATTACKED, ANGRY, DEAD};
-estados posibles para nuestros enemigos: parado,
atacando, preparando ataque, atacado, enfadado y muerto.
movimiento,
Vamos a explicar con más detalle el desarrollo y contenido de estas clases.
Clase Jugador
- Variables:
int vida, balasCargador, maxBalasCargador,
totalBalas;
Real reactionTime, timeOfAttack;
bool shooting, moving, jumping, underAttack;
Real shotTime;
Camera* mCamera;
Entity *gun;
SceneNode *gunNode, *mCamNode;
Sound* mSound;
OgreOde::Body* cameraBody;
El jugador posee vida, balas en el cargador de su arma (con un máximo para darle mayor
realismo y dificultad), un tiempo de reacción (reactionTime) para reaccionar al ser atacado,
un tiempo de ataque por la misma razón y para darle realismo, variables booleanas para saber
- 32 -
PFC
LOST IN DARKNESS
en el estado en que se encuentra, tiempo de disparo, la cámara en primera persona (importante
puesto que es un FPS: First Person Shooter), el modelo de la pistola/s, los nodos con la
ubicación en el escenario de la cámara y arma (jugador), un puntero a una variable sonido
para reproducir efectos realistas y por último el cuerpo de la cámara (jugador), para simular la
física mediante OgreODE (adaptación a OGRE del Open Dynamics Engine).
- Métodos:
*Constructor:
Inicializa todas las variables antes comentadas con valores pasados por
parámetro y factibles e imprescindibles para la simulación de un juego.
Primero crea las entidades (modelos 3D) y los nodos en el escenario para
la cámara y pistola (recordemos que todo ello será el nodo jugador en
primera persona) y las sitúa en el escenario.
Luego le asigna un cuerpo físico al nodo del jugador para simular
realismo en el movimiento. Más adelante se explicará detalladamente la
implementación de la física.
*Métodos get y set:
Típicos en cualquier clase de un lenguaje orientado a objetos, nos
devuelven o establecen el valor de todas las variables de la clase.
*Métodos de estado:
Consultan el estado en el que se encuentra el jugador: atacado, saltando,
moviéndose.
*Métodos de acción:
Realizan acciones para el jugador: moverse, saltar, disparar, recargar
arma, reaccionar a un ataque, reaccionar a un disparo. Todo ello usando
funciones básicas de escenario y nodos del motor OGRE.
Clase Enemigo
- Variables:
Real tiempoBicho, animationSpeed, mDistance,
mDistanceToPlayer, knowledgeDistance, attackDistance,
reactionTime, attackTime, fuerza;
tiempoBicho: cuenta el tiempo que el enemigo realiza una determinada acción, por ejemplo
nos sirve para cuando golpean al enemigo contamos cuanto tiempo ha de permanecer en
estado atacado, para mayor realismo.
- 33 -
PFC
LOST IN DARKNESS
animationSpeed: velocidad de reproducción de la animación para el enemigo (los enemigos
están animados, tanto el modelo como el esqueleto se diseñaron con el software de modelado
en 3D)
mDistance: distancia a la que se encuentra el enemigo del siguiente nodo de la lista
(WalkList). Se ha implementado una lista de nodos para que los enemigos caminen por un
path establecido cuando no tengan nada más que hacer.
mDistanceToPlayer: distancia a la que se encuentra el enemigo del jugador, esto nos sirve
para implementar una IA (inteligencia artificial) sencilla. A partir de cierta distancia o del
ruido, el enemigo se acercará a nosotros para atacarnos.
knowledgeDistance: distancia máxima a la que el enemigo detecta al jugador (IA sencilla)
attackDistance: distancia máxima de acercamiento de un enemigo para atacar al jugador
reactionTime: tiempo de reacción a una determinada acción, para mayor realismo.
Es interesante comentar la utilidad de las variables y métodos para comprender el desarrollo y
posterior funcionamiento de nuestro juego.
Ogre::SceneManager* mSceneMgr;
Ogre::String nombre, walk, run;
int vida;
enum states state;
// STATE : Estado en que se encuentra el enemigo
// 0 : Idle
// 1 : Moving
// 2 : Attacking
// 3 : Attacked
Ogre::Camera* mCamera;
AnimationState* animState;
SceneNode *nodeEnemigo;
OgreOde_Prefab::Ragdoll *ragdollEnemigo;
bool golpeado, aLaVista, changeAnimation;
Vector3 mDirection, mDirectionP1, mDestination;
OgreOde::Body* dollTorsoBody, *dollFeetBody;
OgreOde::TransformGeometry* feetTrans, *torsoTrans;
OgreOde::SphereGeometry* feetGeom;
OgreOde::CapsuleGeometry* torsoGeom;
OgreOde::Space* space, *dollSpace;
OgreOde::HingeJoint* joint;
Sound* enemySound;
std::deque<Vector3> mWalkList, mWalkList2;
//Lista de
puntos a los que caminamos
mSceneMgr: gestor del escenario, necesario para el movimiento y actualización de toda la
escena.
- 34 -
PFC
LOST IN DARKNESS
También disponemos de nombre y vida del enemigo, enumerado con los posibles estados ya
comentados, el nodo para su ubicación en el escenario, booleanos para transiciones de estado,
el estado actual de animación, vectores con la dirección necesaria, dirección destino y el
sonido característico para cada acción.
Por último dos elementos muy importantes, la tabla de vectores de posiciones de escenario
(WalkList) que nos permite mover a los enemigos por un determinado path cuando están
inactivos y todas las variables pertenecientes a la física. Son necesarias porque debemos
asignar al nodo del enemigo un cuerpo físico para simular las colisiones, el movimiento, etc.
Imagen 2 : Esquema para el movimiento de caracteres con OgreODE
El sistema con el que queríamos que los enemigos se desplazaran por el mundo del juego
estaba basado en la física del wrapper OgreODE aplicando fuerzas y velocidades angulares.
Para realizar esto, cada entidad está formada (aparte del mesh y el nodo padre) por dos
OgreOde::Body o cuerpos, una esfera para los pies y una capsula para el torso.
Estos dos cuerpos están enlazados o unidos por una OgreODE::Joint de modo que si
aplicamos una fuerza a los pies el torso se verá afectado también.
- Métodos:
*Métodos get y set:
Constructores y consultores para las variables de la clase enemigo, muy
útiles.
*Métodos para walklist:
Contiene métodos para obtener la siguiente localización de la walklist
(tabla de vectores de posiciones) y para iniciarla/recuperarla.
*Métodos de acción:
Contiene métodos para actualizar posición, orientación, distancia.
- 35 -
PFC
LOST IN DARKNESS
*resolveState(time, player1)
Este método determina el estado en el que se encuentra el
enemigo de manera que si el jugador no está a su alcance continua moviéndose
pero siguiendo una lista de puntos prefijados, si el jugador le dispara pasa al
estado ATTACKED durante un tiempo determinado, si el jugador está dentro
de la distancia en la que puede ser visto u oído el monstruo empieza a dirigirse
hacia él, en el caso que el enemigo está a la distancia suficiente comienza a
atacar al jugador y, finalmente, cuando el jugador muere el enemigo entra en
estado IDLE.
*updateShot
Nos permite saber si hemos alcanzado a un enemigo con todo lo que ello
implica: cambio en el estado, animación, vida, etc.
Para ello usamos un objeto OgreOde::Ray del motor de física, que no es
más que un rayo que “lanzamos” de la posición del jugador (pistola)
hasta el apuntador (crosshair) y debemos detectar la colisión. En función
de la colisión realizamos los cambios adecuados en el enemigo.
Un detalle importante a destacar es la forma en la que trabaja este método: en
el momento que se proyecta el Ray al apuntador (crosshair) esté recorre el
escenario en línea recta y recupera un listado de todos los objetos movibles que
encuentre a su paso, que en nuestro caso serán enemigos.
*updateRagdoll
Nos permite actualizar todos los ragdolls (muñecos de trapo). Son
entidades que nos permiten interactuar con los enemigos cuando estos
están muertos, estando la física de su cuerpo a nuestro placer para
rematarlos.
*deleteEnemy
Elimina el enemigo de la escena (entidad y nodo)
Como se puede comprobar hemos ido implementando métodos para ayudarnos a facilitar el
tratamiento de cualquier objeto o clase, aspecto que es muy lógico pero que hay que tener
muy en cuenta e implementarlo correctamente.
Clase Zombie y Clase Monstruako
Ambas clases las comentaremos al mismo nivel puesto que heredan de la clase enemigo con
todas sus variables y métodos.
Lo único que las diferencia es la secuencia de inicialización: los modelos son diferentes, los
nombres también, las habilidades, la posición y orientación iniciales, la fuerza, el cuerpo
- 36 -
PFC
LOST IN DARKNESS
físico asignado para la simulación, la walklist, etc. En resumen las variables (características)
de la clase enemigo lógicamente. Ésta era la finalidad de la creación de clases y herencia.
La secuencia de configuración tiene el mismo esquema en ambos tipos.
El método que realmente las diferencia es updateMov (acciones, sonido y animaciones) que
permite que el enemigo actúe conforme al estado en que se encuentra.
Clase Horda
Esta clase contiene el vector de enemigos participantes en el juego, el jugador y el número
total de enemigos actual en tiempo de ejecución.
Enemigo* enemies[maxEnemies];
int totalEnemies;
Jugador* player1;
- Métodos:
*Contructor:
Inicializa las variables de la clase
*Destructor:
Elimina a todos los enemigos (borra toda la tabla)
*AñadirBicho:
Añade un enemigo a nuestra colección
*Métodos de consulta:
Obtiene información de un enemigo de la colección y del número total de
enemigos
*UpdateBichosShot, UpdateBichosMov, UpdateBichosRagdoll
Recorre toda la colección y aplica los métodos antes comentados para
cada enemigo de la tabla (disparo, movimiento y ragdoll)
Seguidamente vamos a explicar las clases que hacen referencia a los estados de nuestro juego.
Eston son EstadoIntro, EstadoJugar, EstadoPausa y EstadoVideo (incluido en EstadoIntro
para reproducir video).
- 37 -
PFC
LOST IN DARKNESS
Como ya se comentó al principio del apartado, estas clases derivan de EstadoJuego, por lo
que contiene ya el esqueleto básico que implementamos para cualquier estado de una
aplicación tipo juego. Recordemos: esqueleto de los métodos para el control de las 3
interfícies de entrada y salida, métodos de entrar-salir-pausar-reanudar para el cambio de
estados y los métodos para el manejo de la pila de estados (cambiar, push y pop) que ejecutan
los métodos anteriores correspondientes según el estado destino (entrar-reanudar) y estado
origen (pausar-salir).
Las variables comunes a los estados son:
Ogre::RenderWindow* mWindow;
Ogre::Root *mRoot;
Ogre::SceneManager* mSceneMgr;
Ogre::Viewport* mViewport;
Ogre::InputReader* mInputDevice;
Ogre::Camera* mCamera;
Todos los tipos de objetos son conocidos excepto el InputReader que es el objeto del motor
gráfico OGRE que hace referencia al dispositivo que obtiene la entrada según la interfície.
Como se puede observar esta estructura es bastante lógica puesto que abarca todos los campos
necesarios para que un estado de juego pueda manejarse dentro de la aplicación: escenario
(que gestiona la mayoría de elementos), cámara, interacción exterior, sistemas de renderizado,
etc.)
EstadoIntro
A parte de los métodos ya descritos heredados de la clase EstadoJuego, cabe comentar la
interfície CEGUI, también presente en los otros estados. CEGUI es una interfície gráfica para
OGRE de fácil uso pero no así integración.
Así pues esta clase será una interfície gráfica (videos, gráficos, imágenes y botones) para
interactuar con el gestor de entrada y salida (ratón, teclado, etc).
- Interfície gráfica:
void
bool
bool
void
EventosCEGUI(void);
tratarQuitar(const CEGUI::EventArgs& e);
tratarJugar(const CEGUI::EventArgs& e);
configurarCEGUI(void);
Como ya veremos estos métodos también están presentes en los otros estados.
- 38 -
PFC
LOST IN DARKNESS
Primero hablamos del método configurarCEGUI que, como su propio nombre indica,
inicializa y crea toda la interfície gráfica (botones, gráficos, imágenes, etc.) para poder
posteriormente interactuar con ellos. Todo con instrucciones CEGUI adaptadas a OGRE.
La manera de interactuar es mediante el método EventosCEGUI() en el cual se definen tantos
eventos como botones (u otro tipo de elemento gráfico) haya en la interfície. Por ejemplo
nosotros tenemos 2 botones tratados (jugar y salir) a los cuales se les asocia una función. Por
ejemplo para salir usariamos la interfície ya creada de cambiarEstado.
Para reproducir los videos posteriormente conoceremos EstadoVideo.
EstadoPausa
Estado de juego idéntico al de intro excepto que no contiene videos, los botones de la
interficie son diferentes y contiene booleanos para saber a que estado cambiar (intro o jugar)
en función de los métodos definidos en EventosCEGUI().
EstadoJugar
Sin duda este es el estado más importante del juego. El que cargará el escenario en memoria,
los modelos, efectos, luces, la física, etc.
Como métodos principales para comentar su desarrollo y estructura tenemos:
- Método entrar heredado de la clase estado de juego -> crea un escenario o lo carga
memoria según el tipo de escenario que sea, crea las entidades en memoria a partir
modelos, crea cámaras para visualizar, crea el mundo físico (OgreODE::World), etc.
de
de
- Los métodos de control de las interfícies de entrada y salida.
• Controlamos la entrada de teclado y ratón prestando atención a las teclas y
botones:
o W, A, S, D y cursores para el movimiento
o ESC para pasar al menú de pausa
o Botón izquierdo ratón para disparo
o Botón derecho ratón para recarga
-Métodos de control de eventos sobre frames.
• frameStarted:
o Comprobamos que si el usuario ha pulsado la tecla ESCAPE, en cuyo caso
deberemos saltar al EstadoPausa.
o Redibujamos el overlay para la vida, munición y avisador de ataque.
o Actualizamos la posición del jugador y los enemigos.
o Actualizamos sonido de los pasos del jugador
• frameEnded:
o Sincronizamos el mundo y el stepper de OgreODE
o Si el jugador dispara actualizamos los enemigos para comprobar si alguno de
ellos ha sido impactado o matado
- 39 -
PFC
LOST IN DARKNESS
o Actualizamos los ragdoll deteniendo su movimiento pasado un cierto tiempo.
A continuación se hace referencia a todos los plugins utilizados (código también modificado
para nuestro proyecto) para incorporar mejoras en nuestro juego: vídeo, música y sonidos,
física y carga de escenarios. Cabe decir que su integración ha sido costosa y dedicada. Y en
este caso también su utilización. Los resultados son realismo y eficacia.
- 40 -
PFC
LOST IN DARKNESS
5. EVALUACIÓN (Juegos de pruebas)
Detallaremos a continuación los diferentes juegos de pruebas que hemos realizado para
comprobar el correcto funcionamiento de cada uno de los módulos:
•
Cambio de estados Arreglar para que funcione bien!!!
Se han realizado pequeñas pruebas para comprobar que el GameManager puede pasar
por todos los estados del juego habiendo un pequeño problema en el momento de salir
de una partida y querer comenzar una nueva…
A pesar de todos los esfuerzos realizados es imposible subsanar este error ya que al
intentar arreglarlo se desarreglan otras estados del GameManager.
•
Física Ragdoll y movimiento!!!
Comprobado el correcto funcionamiento del sistema de ragdolls, dando un fallo en el
caso concreto del enemigo del tipo “monstruako” para el cuál aún no hemos creado el
correcto fichero que determina cómo ha de ser su ragdoll.
En cuanto al movimiento, se ha procedido a crear un sistema de movimiento
basado un fuerzas y velocidades angulares pero que no funciona debido a un
error interno de OgreODE que todavía no hemos podido/sabido arreglar.
•
CEGUI Funcionamiento de la GUI
Hemos comprobado las GUI’s creadas con CEGUI y presentes en EstadoIntro y
EstadoPausa mostrando una interfície atractiva y sencilla por pantalla.
Los únicos problemas detectados son los relacionados con resoluciones de pantalla
muy pequeña (como 640 x 480) provocando que la interfície se vea mal y
descolocada.
•
Theora Carga de vídeos en formato .OGG
- 41 -
PFC
LOST IN DARKNESS
Para la carga de vídeos se han utilizado tres diferentes en tamaño y calidad de imagen
obteniendo resultados aceptables aunque en ocasiones el plugin Theora se comporte de
forma inestable sufriendo un bajón en el framerate provocando así que el vídeo vaya a
saltos.
•
“IA” Comportamiento de las entidades enemigas (Seguimiento de PATH,
Detección, seguimiento y ataque al jugador)
Se ha comprobado el correcto comportamiento de las entidades enemigas. El
procedimiento es el siguiente:
o Al iniciarse la partida los enemigos siguen un recorrido prefijado por la
walklist asociada a cada uno de ellos.
o En el momento que el enemigo llegue al último punto de su recorrido éste
volverá a empezar desplazándose de nuevo al punto inicial repitiendo éste
proceso un número indefinido de veces.
o En cuanto el jugador entra en el campo de visión o “audición” del enemigo,
éste deja de recorrer su walklist y se dirige hacia la posición del protagonista
empezando a atacar cuando se encuentre a la distancia adecuada de él. Si el
protagonista se aleja lo suficiente de el y sale de su campo de visión o audición
el enemigo retomará su recorrido hacia el último punto al que se dirigía antes
de ser interrumpido.
•
Escenario Comprobar que el mundo encaja con el resto de entidades y viceversa
•
Animaciones y sonido “sincronizadas”
•
Sistema de vida y munición
El protagonista comienza el juego con un cargador de 2 balas y otras 40 balas en la
cartuchera. Conforme va disparando el cargador se va vaciando. En el momento en
que el número de balas del cargador es 0 el jugador no puede disparar avisándole de
ello mediante del típico sonido que emite la escopeta cuando se acciona el gatillo de la
misma.
- 42 -
PFC
LOST IN DARKNESS
El jugador recibe también un aviso visual en el que se le indica que ha de recargar la
escopeta mediante la pulsación del botón derecho del ratón, en el caso de que le
queden balas en la cartuchera.
•
Fluidez del juego (comprobar rendimiento (FPS con Fraps) de las diferentes
configuraciones en varios PC’s)
- 43 -
PFC
LOST IN DARKNESS
6. CONCLUSIONES
6.1 Conceptos que hemos aprendido
•
Uso del entorno de desarrollo Visual Studio .NET 2003.
•
Modelar escenarios y entidades en 3ds MAX.
•
Uso del editor CEGUI para crear interfícies gráficas bajo Ogre3D.
•
Uso de Ogre3D para crear un entorno tridimensional.
•
Uso de Adobe Photoshop 7 para la edición y creación de imágenes.
6.2 Objetivos que no se han podido cumplir
•
No se ha podido implementar un sistema de carga y guardado de partidas.
•
No se ha podido implementar un método para poder cambiar las opciones de
configuración al vuelo, es decir, sin tener que salir de la aplicación.
•
No se ha conseguido adaptar (del todo) la física OgreODE al proyecto teniendo que
funciona correctamente para la creación de ragdolls pero sin poder mover a las
entidades por el escenario mediante fuerzas debido a un error inexplicable que
aún no hemos podido subsanar (aunque estamos en ello).
6.3 Conocimientos de la carrera aplicados al videojuego
•
Programación modular (PR y ED).
•
Programación orientada a objetos (PRII).
•
Cambios de contexto en los estados de juego (SOP).
•
Creación de entornos tridimensionales interactivos (GEO y GC).
•
Seguimiento de fragmentos de lenguaje ensamblador para debugar el código (EC1)
•
Entrada y salida (EC1).
•
Estructuración en clases (PI).
- 44 -
PFC
LOST IN DARKNESS
7. RECURSOS UTILIZADOS
7.1 Software utilizado
o Microsoft Visual Studio .NET 2003
En palabras de Microsoft:
“Visual Studio .NET 2003 proporciona a los programadores herramientas completas
para diseñar y generar aplicaciones distribuidas para Microsoft Windows®, Web y
dispositivos móviles. Visual Studio .NET 2003 Enterprise Architect (VSEA) tiene la
capacidad de Visual Studio .NET 2003 Enterprise Developer e incluye funciones
adicionales para diseñar, especificar y comunicar arquitectura de aplicaciones,
procedimientos de desarrollo recomendados y funcionalidad de aplicaciones.”
Es decir, hemos implementado nuestro proyecto programado bajo Visual C++ utilizando
las librerías de Ogre3D para el motor gráfico, OgreODE para el motor físico, FMOD para
el soporte de sonido y Theora para el plugin de vídeo entre otras.
Software concedido bajo licencia de acuerdo con el programa MSDNAA.
URL :
http://msdn30.e-academy.com/uriv_eim/index.cfm?loc=main
o Ogre3D
Ogre3D (Object-Oriented Graphics Rendering Engine) es un motor de videjuegos en 3D.
La principal ventaja de Ogre sobre otros engines 3D es que es un proyecto open source
bajo licencia LGPL. Esto significa que su uso es gratuito y solo existen unas pocas
exigencias para su uso. Tiene un interfaz para Python muy interesante y completo, soporte
para GLSL shader, bezier y un gran nivel de detalle. Es compatible con varios sistemas de
edición en 3D como Blender o 3DSMax.
- 45 -
PFC
LOST IN DARKNESS
Ogre está teniendo últimamente bastante popularidad debido a su potencia y la buena
documentación que trae, por lo que numerosos proyectos comerciales y libres se han
decidido por él. Con Ogre podemos hacer juegos o cualquier tipo de aplicación que
requiera gráficos tridimensionales que no tengan nada que envidiarle a lo más moderno
del mercado.
Algo que hay que destacar es el hecho de que Ogre no es un engine diseñado solo con los
juegos en mente, es un engine de gráficos 3D general. Debido a esto, Ogre no trae soporte
nativo para sonido ni física, lo que no es un problema, ya que gracias a la enorme
comunidad existente en Internet, existen módulos especialmente diseñados para Ogre, que
permiten tener estas facilidades. A continuación detallaremos algunos de los módulos que
hemos usado para implementar nuestro videojuego.
Para la realización del proyecto nos hemos basado en la versión 1.0.7 (nombre en código
Azathoth) de Ogre3D pero actualmente se encuentra disponible la 1.2.1 (nombre en
código Dagon). No creímos necesaria la adaptación de nuestro código a la nueva versión
debido a que no íbamos a utilizar las nuevas características que incorpora.
Para probar la valía de este motor gráfico diremos que hace algunos meses se lanzó en
Europa el primer juego realizado en Ogre con miras comerciales. Su nombre es Ankh y es
una aventura gráfica en el estilo de Monkey Island.
URL’s :
Página principal: http://ogre3d.org/
Lugar desde el cuál podemos acceder a todo lo que rodea al mundo de la programación de
videojuegos (o entornos interactivos) bajo el motor gráfico Ogre3D.
Foro:
http://www.ogre3d.org/phpBB2/
Lugar al que dirigirse en el momento de las dudas. Puedes postear planteando un
problema o buscar algún tema que presente la solución al mismo. No siempre se encuentra
solución al problema.
- 46 -
PFC
OgreWiki:
LOST IN DARKNESS
http://www.ogre3d.org/wiki/index.php/Main_Page
Lugar donde podemos encontrar Tutoriales, FAQ’s, artículos y código para comenzar a
programar para Ogre3D.
Ankh:
http://www.ankh-game.de/
Página Web del primer juego comercial basado en Ogre3D.
o OgreODE
Ogre Ode es un wrapper del motor de física libre ODE (Open Dynamics Engine) para el
motor gráfico Ogre3D. Da soporte para todas las primitivas de ODE, y añade algunos
objetos preparados como vehículos (coches) y soporte para ragdolls.
URL’s:
ODE:
http://ode.org/
OgreODE:
OgreODE se puede encontrar en el repositorio CVS, en el módulo
OgreAddons.
o Theora Plugin
Ogre3D no puede reproducir directamente vídeo. Sin embargo, existe un plugin escrito
para Ogre que nos permite realizar esta tarea. Este plugin se puede encontrar en el
repositorio CVS, en el módulo OgreAddons/videoplugin. Dentro de este mismo módulo
podemos encontrar dos ejemplos de reproductores de vídeo (uno basado en Overlay’s y el
otro basado en CEGUI). Nosotros nos hemos inspirado en el basado en CEGUI para crear
nuestro reproductor de vídeo.
El Theora plugin usa el códec de vídeo Theora y el códec de audio Vorbis. Los dos son
libres. El sistema de audio permite un alto grado de abstracción, lo que permite que no sea
necesario un sistema de audio específico para reproducir el sonido. Nosotros nos hemos
- 47 -
PFC
LOST IN DARKNESS
decantado por la utilización de las librerías FMOD explicando, más adelante, el por qué
de esta decisión.
El Theora plugin está mantenido regularmente por lo que podemos decir que se actualiza
conforme las nuevas versiones de Ogre3D van apareciendo.
Trabajaremos con los ficheros de extensión .ogg que contendrán la información del vídeo
que queremos reproducir.
El Theora plugin necesita de los siguientes módulos o librerías para su correcto
funcionamiento:
•
TheoraSoundManager (.cpp y .h) se encarga de la reproducción del clip de audio
•
MovieLogic (.cpp y .h) se encarga de la reproducción del clip de video (imagen y
sonido) como conjunto.
•
La .dll Plugin_TheoraVideoSystem.
URL’s:
Theora:
http://www.theora.org/
TheoraPlugin:
http://www.wreckedgames.com/wiki/index.php/WreckedLibs:Plugin_TheoraVideoSyste
m
o FMOD
FMOD es una librería de audio multiplataforma y un conjunto de herramientas que
permiten implementar las más modernas tecnologías de audio en una aplicación.
Los creadores de FMOD se vanaglorian de poder dar soporte con sus librerías a 13
plataformas:
•
Windows 32bit
- 48 -
PFC
LOST IN DARKNESS
•
Windows 64bit (AMD64)
•
Linux
•
Linux 64bit (AMD64)
•
Macintosh (os8/9/10/x86)
•
Windows CE (Pocket PC / Smart phone)
•
Playstation 2
•
Xbox
•
GameCube
•
Xbox 360
•
Playstation Portable
•
PLAYSTATION®3
•
Wii
Una de las características de FMOD es que no se trata de un producto gratuito al contrario
que OpenAL otra librería de sonido completamente libre.
Debido a problemas de integración de OpenAL en nuestro proyecto nos decantamos por la
utilización de FMOD para las tareas de sonido.
No se tiene que pagar ninguna licencia por el uso de esta API si no tienes intención de
lucrarte con el producto resultante por lo que para la realización de nuestro proyecto no
representa ningún problema su utilización.
En el caso de que realices una aplicación comercial tienes que elegir entre dos tipos de
licencias por producto (copias del software) o por sitio (una empresa puede tener dos
compañías hijas que requerirían 2 licencias).
También se contempla el caso del programador aficionado que crea aplicaciones
shareware. Para este tipo de usuario se ha previsto un precio menor de licencia ($100) más
un proceso de verificación para saber si el producto se ajusta a la tipificación shareware y
el programador es un individuo realmente no profesional.
- 49 -
PFC
LOST IN DARKNESS
Otro punto importante se refiere al uso de clips de audio en formato MP3. Desde la página
web de FMOD se nos indica que para poder utilizar MP3 se ha de tratar directamente con
Thompson Multimedia, poseedores de los derechos del formato, sólo en el supuesto de
que el producto vaya a vender más de 5000 copias. En caso contrario no se requiere
licencia.
Hemos usado la versión 3.74 de la API de FMOD aunque ya se encuentran disponibles las
versiones 3.75 y 4.04 EX. Las diferencias entre estas dos versiones radican en una mayor
portabilidad y número de efectos/mezclas de la etiquetada EX respecto a la otra.
Para gestionar el sonido del juego (músicas y efectos) hemos utilizado el SoundManager
disponible en una aplicación de código abierto “Stunt Playground 2.0”.
URL:
http://www.fmod.org/
Imagen 3 : Logotipo de las librerías fmod
o CEGUI
Crazy Eddie's GUI es una librería abierta que proporciona soporte para creación de menús
para API’s/motores gráficos donde dicha funcionalidad no esta soportada nativamente o
es bastante deficiente. La librería está orientada a objetos, escrita en C++, recomendada
para desarrolladores de juegos que prefieran dedicar su tiempo en crear grandes juegos y
no en implementar subsistemas de GUI.
Hemos utilizado CEGUI para la creación de los menús de EstadoIntro (menú principal) y
EstadoPausa. La versión utilizada ha sido la 0.4.1. Para esto tenemos que explicar que la
versión que hemos usado de Ogre3D (la 1.0.7) estaba compilada para trabajar con la
CEGUI 0.3.0 pero como usamos el Theora Plugin y éste estaba diseñado para trabajar con
- 50 -
PFC
LOST IN DARKNESS
la versión 0.4.0 de CEGUI debimos recompilar el OgreGUIRenderer para poder usar esa
nueva versión.
Actualmente CEGUI está a punto de llegar a su versión 0.5.0
URL:
http://www.cegui.org.uk
o CELayout Editor
CELayoutEditor es el editor oficial de la maquetación para CEGUI.
Éste editor gráfico nos permite diseñar el aspecto que queremos que tenga nuestra GUI. El
programa nos crea un fichero en .XML que cargaremos en Ogre3D para visualizar el
aspecto que tendrá nuestra GUI. De esta manera no será necesario recompilar el código
cada vez que queramos cambiar el diseño, simplemente retocaremos el fichero .XML en
el editor y podremos apreciar las diferencias ejecutando de nuevo la aplicación Ogre3D.
Para poder compilar necesitamos las librerías TinyXML ya que necesitamos un parser
para los ficheros .XML.
URL:
http://www.cegui.org.uk
Imagen 4 : Entorno de edición del CELayout Editor
- 51 -
PFC
LOST IN DARKNESS
o Ogre GUI Mesh Utility
Pequeña utilidad para visualizar las mallas o modelos (mesh’s) construidas con 3ds Max y
comprobar la correcta creación, aplicación de texturas y transiciones en las animaciones.
URL: La aplicación se puede encontrar en el repositorio CVS, en el módulo
OgreAddons/meshviewer.
Imagen 5 : Entorno de trabajo del OgreGUI Mesh Utility
o OgreXMLConverter
Pequeño programa de línea de comandos para convertir los modelos creados/exportados
de 3ds Max en .mesh.xml al formato .mesh que reconoce el motro gráfico Ogre3D.
Este programa está incluído en un paquete de herramientas entre las que destacan
OgreMeshUpgrade y OgreMaterialUpgrade para actualizar modelos y materiales
exportados para versiones anteriores de Ogre3D.
URL:
http://prdownloads.sourceforge.net/ogre/OgreCommandLineTools_1.2.1.msi
o Adobe Photoshop 7
Según Adobe:
- 52 -
PFC
LOST IN DARKNESS
“Adobe Photoshop CS2 es el software estándar de edición de imágenes profesional y el
líder de la gama de productos de edición de imágenes digitales que aporta más de lo que
usted se espera. Las innovadoras herramientas creativas le ayudan a conseguir
resultados excepcionales. Una adaptabilidad sin precedentes le permite personalizar
Photoshop de acuerdo con su método de trabajo. Además, gracias a unos procesos de
edición, tratamiento y gestión de archivos más eficaces podrá trabajar con mayor
rapidez.”
En pocas palabras, hemos usado esta conocida aplicación en su versión número 7 para la
edición y retoque de imágenes como el logo del videojuego, el fondo de la pantalla de
intro, algunas texturas, etc.
Actualmente se encuentra disponible la versión CS2 (la que vendría a ser la versión
número 9).
URL:
http://www.adobe.com/es/products/photoshop/
Imagen 6 : Entorno de trabajo de Adobe Photoshop 7
o 3ds Max 7 + Plugins
- 53 -
PFC
URL:
LOST IN DARKNESS
http://www.autodesk.com/
Imagen 7 : Entorno de trabajo de 3ds MAX 7
- 54 -
PFC
LOST IN DARKNESS
o ffmpeg2theora
Esta pequeña aplicación de línea de comandos nos sirve para convertir vídeos en formato
mpeg al formato ogg Theora, que es el que usamos para la reproducción de vídeo.
URL:
http://www.v2v.cc/~j/ffmpeg2theora/
o SWISH MAX
Según sus creadores, SWISHZone:
“¡Con SWiSH Max podrás crear contenidos Flash sin límite! SWiSH Max posee todas las
herramientas que necesitas para crear animaciones en Flash totalmente interactivas.”
En pocas palabras, hemos utilizado este programa para diseñar una animación atractiva
para la introducción del videojuego. SWISH nos permite exportar una animación Flash al
formato .AVI.
Posteriormente hemos convertido el fichero .AVI al formato .MPEG con la aplicación
TMPGEnc y, finalmente, hemos pasado al formato utilizado por nuestro videojuego, el
ogg Theora, con la aplicación que hemos comentado en el punto anterior.
URL :
http://www.swishzone.com/
- 55 -
PFC
LOST IN DARKNESS
Imagen 6 : Entorno de trabajo de SWISHMax
o TMPGEnc
Esta aplicación convierte los ficheros .AVI a MPEG1, el formato que se usa para los
VideoCD. Usando una amplia variedad de opciones con TMPGenc se puede comprimir
un vídeo con alta calidad.
Este programa permite ajustar el bitrate, la estructura GOP, imagen entrelazada (interlace)
y otros muchos parámetros para poder crear el clip de vídeo que mejor se ajuste a tus
necesidades.
URL:
http://www.tmpgenc.net/
- 56 -
PFC
LOST IN DARKNESS
Imagen 8 : Entorno de trabajo de TMPGenc
o Modelos, sonidos e imágenes prestados
Para la ambientación y caracterización de los enemigos y el mundo del juego hemos usado
algunos sonidos y piezas de música con copyright como pueden ser los correspondientes a
juegos como Resident Evil o Splinter Cell.
Pensamos que al no ser una aplicación comercial (no existe ánimo de lucro) no hay
problema alguno en usarlos. Hay que tener en cuenta que no somos expertos en edición de
sonido y nos habría ocupado más tiempo empezar de cero creando sonidos propios.
- 57 -
PFC
LOST IN DARKNESS
7.2 Hardware utilizado:
•
PC Sobremesa 1:
o AMD ATHLON 2600+ @ 2100 GHz
o 1GB de Memoria RAM
o Tarjeta gráfica Sapphire Radeon ATI con 128 MB de Memoria RAM
o SO: Windows XP Professional
•
PC Sobremesa 2:
o AMD Athlon(tm) XP 2000+ @ 1.67 GHz
o 256 MB de Memoria RAM
o Nvidia GeForce4 MX 440SE con AGP8x y 64 MB de Memoria RAM
o SO: Windows XP Professional
•
PC Sobremesa 3:
o Intel Pentium III @ 800 MHz
o 256 MB de Memoria RAM
o Nvidia GeForce4 MX 440SE con AGP8x y 64 MB de Memoria RAM
o SO: Windows XP Professional
•
PC Portátil:
o INTEL CENTRINO @ 1,76 GHz
o 1GB de Memoria RAM
o Tarjeta gráfica integrada INTEL 915GM con 128 MB de Memoria RAM
(compartida)
o SO: Windows XP Home
- 58 -
PFC
LOST IN DARKNESS
8. MANUALES
8.1 Instalación
La carpeta LostInDarkness proporcionada incluye todas las librerías, modelos, texturas, etc.
necesarias para su ejecución.
Por lo tanto, la instalación es bastante sencilla, tan sólo hay que copiar esta carpeta al disco
duro del PC.
8.2 Uso
Para ejecutar el videojuego hay que dirigirse a la carpeta XXXXXXXXXXXX y seleccionar
el .exe. La primera vez que se ejecute aparecerá la pantalla de configuración del juego. Los
valores que puedan tomar las opciones disponibles dependerán de las características de la
tarjeta gráfica instalada en el sistema.
Imagen 9 : Pantalla de configuración del videojuego
La primera de las opciones nos obliga a elegir el subsistema de render de tres posibles que en
nuestro caso son:
•
Direct3D 7
- 59 -
PFC
LOST IN DARKNESS
•
Direct3D 9
•
OpenGL
El resto de opciones depende del sistema de render elegido y destacamos las siguientes:
•
Nivel de 6
•
Modo de coma flotante
•
Pantalla Completa
•
Dispositivo de visualización (puede darse el caso de tener más de uno en el sistema)
•
Sincronización Vertical
•
Resolución y Profundidad de Color
Una vez hayamos seleccionado la configuración que mejor se adapte a nuestro sistema
pulsaremos aceptar y se cargará el juego. En el caso de que queramos cambiar alguna de las
opciones de configuración deberemos borrar el fichero ogre.cfg de la carpeta.
Una vez dentro del programa nos aparecerá un corto vídeo de introducción que podemos
saltar apretando cualquier tecla o botón del ratón.
Después de una pantalla de carga aparece la pantalla o menú principal en la que las opciones
disponibles son “Nueva Partida”, “Cargar”, “Opciones” y “Salir” estando operativas sólo la
primera y la última.
Seleccionando “Nueva Partida” entraremos en el juego, propiamente dicho y las teclas y
botones de función serán los siguientes:
TECLAS MOVIMIENTO
•
W
El jugador se desplaza hacia delante.
•
S
El jugador se desplaza hacia atrás.
•
A

El jugador se desplaza lateralmente hacia la izquierda.
•
D
El jugador se desplaza lateralmente hacia la derecha.
•
ESPACIO
El jugador efectúa un salto vertical.
6
Esta técnica revisa los polígonos y difuminará las bordes y vértices, para que los bordes no se vean
como dentados.
- 60 -
PFC
•
LOST IN DARKNESS
RATÓN
El jugador se orienta con el movimiento del ratón.
BOTONES DE ACCIÓN
•
Botón izquierdo del ratón
El jugador efectúa un disparo de su arma.
•
Botón derecho del ratón
El jugador recarga su arma.
TECLAS MISC.
•
ESCAPE
Se entra al menú de pausa
Desde el menú de pausa podemos salir de la partida y volver al menú principal.
8.3 Requerimientos
•
De compilación
Cualquier sistema que pueda ejecutar el entorno de desarrollo Visual Studio .NET
2003 podrá compilar y linkar nuestra aplicación.
Por tanto, veamos los requisitos mínimos marcados por la propia Microsoft:
Procesador: Pentium II a 450 MHz, se recomienda Pentium III a 600 MHz
Sistema operativo:
Visual Studio .NET 2003 se puede instalar en cualquiera de los siguientes sistemas:
o Microsoft Windows® Server 2003
o Windows XP Professional
o Windows XP Home Edition
o Windows 2000 Professional
o Windows 2000 Server
Las aplicaciones se pueden implementar en los siguientes sistemas:
o Windows Server 2003
o Windows XP Professional
- 61 -
PFC
LOST IN DARKNESS
o Windows XP Home Edition
o Windows 2000 (se recomienda Service Pack 2)
o Windows Millennium Edition (Windows Me)
o Windows 98
o Microsoft Windows NT® 4.0 (se precisa Service Pack 6a)
o Windows 95 (utilizando Microsoft Visual C++® .NET)
Memoria:
Windows Server 2003: 160 MB de memoria RAM
Windows XP Professional: 160 MB de memoria RAM
Windows XP Home Edition: 96 MB de memoria RAM
Windows 2000 Professional: 96 MB de memoria RAM
Windows 2000 Server: 192 MB de memoria RAM
Disco duro:
o 900 MB de espacio disponible en la unidad del sistema
o 3,3 GB de espacio disponible en la unidad de instalación
o 1,9 GB de espacio adicional disponible para la documentación de MSDN
Library opcional
Unidad de disco:
•
Unidad de CD-ROM o DVD-ROM
Monitor:
Resolución Super VGA (1024 x 768) o superior con 256 colores
Mouse:
Microsoft Mouse o compatible
De ejecución
o La configuración mínima sobre la que hemos probado el juego es la siguiente:
PC Sobremesa 2
AMD Athlon(tm) XP 2000+ @ 1.67 GHz
- 62 -
PFC
LOST IN DARKNESS
256 MB de Memoria RAM
Nvidia GeForce4 MX 440SE con AGP8x y 64 MB de Memoria RAM
SO: Windows XP Professional
Sin ningún problema, a pesar que la tarjeta gráfica 3D ya tiene sus años.
El PC ha de disponer de 300 MB libres en el disco duro.
Asumimos que ordenadores con prestaciones menores podrían ejecutar nuestra
aplicación pero sólo en el caso de que dispongan de una tarjeta gráfica con
capacidades 3D.
- 63 -
PFC
LOST IN DARKNESS
ANEXO I : CONCEPTOS RELACIONADOS
(Definiciones extraídas de http://es.wikipedia.org/)
Píxel: El píxel (del inglés picture element, o sea, "elemento de la imagen") es la menor
unidad en la que se descompone una imagen digital, ya sea una fotografía, un fotograma
de video o un gráfico.
Shader: Tipo de lenguaje de programación destinado a programar el procesado de
elementos de cualquier interfaz 3D o tarjeta gráfica (píxeles, polígonos, texels, etc.).
Los programas generados tomarán como entrada estos elementos y los procesarán, de tal
manera que modifique la forma con la que lo perciba el ojo humano.
Game Engine o Motor de Juego hace referencia a una serie de rutinas de programación
que permiten el diseño, la creación y la representación del juego.
La analogía con el motor de un automóvil es ilustrativa: el motor debajo del capó no es
visible pero le da la funcionalidad al automóvil que es la de transportar. La misma
analogía permite explicar algunos de los aspectos que generalmente maneja un motor de
juego: las texturas y los modelos 3D serían la carrocería, pintura e interiores.
Del mismo modo en que carrocería, pintura y exteriores no andan sin un motor, el arte y
los guiones del juego no funcionan sin un motor de juego.
Assets (activos): Son los modelos, animaciones, sonidos, AI, físicas. Son los elementos
que forman el juego en sí, el código hace funcionar los assets.
API: Application Programming Interface (Interfaz de Programación de Aplicaciones), es
un sistema de rutinas, de protocolos, y de herramientas para desarrollar programas de
aplicación. Un buen API hace más fácil desarrollar un programa proporcionando todos los
bloques del desarrollo del programa. El programador pone los bloques juntos.
Entre estos los más importantes son el DirectX (de Microsoft) y el OpenGL (que trabaja
con la mayoría de los sistemas operativos).
- 64 -
PFC
LOST IN DARKNESS
Objetos 3D: los objetos se almacenan por puntos en un mundo 3D, llamados vértices. Los
vértices van formando polígonos; entre más polígonos posea un objeto, más complicado
se hace, lleva más tiempo de procesamiento pero es más detallado. El juego no necesita
saber cuantos objetos hay en memoria o como el Render va a mostrarlos, solo le interesa
que el render los despliegue de la forma correcta, y que el modelo este en el cuadro
correcto de la animación.
Higher-order surfaces (superficies de alto orden): Renderizado matemáticamente, usado
en las tarjetas más recientes y poderosas. También llamado: Patches (parches).
Patches: son perfectos para describir geometrías más cuando se trata de curvas, pues
expresan la geometría con formulas matemáticas en logra de solo colocar puntos en el
mundo del juego.
Three-point polygon (polígonos de 3 puntos-Triángulos): el más usado por las tarjetas
aceleradoras 3D.
Culling: codificado que logra que los objetos que no se ven en determinado cuadro de la
animación por causa de objetos que los obstaculizan (Como una pared) no tomen tiempo
de renderizado. Así se reduce la cantidad de trabajo del motor. El Culling es más fácil de
implementar en juegos en donde la visión es controlada como los RTS en comparación
con lo FPS. Un método de Culling puede ser por “Árboles BSP”
BSP Tree Hierarchy (BSP Árbol de Jerarquía): Es un método para determinar qué
superficies de un mundo, y qué objetos, están realmente en la escena en momento dado,
dada su localización en el mundo. Esto se utiliza a menudo para los objetos del desecho, y
también para entresacarlos para reducir el proceso del AI (Inteligencia Artificial) y de la
animación. Retesselation: técnica usada por la característica de TruForm de ATI que
consiste en tomar un modelo basado en triángulos y transformarlo en uno de High-Order
Surfaces para alisarlo y de nuevo pasarlo a un modelo de Triángulos.
Iluminación (lighting): distintos APIs proveen diferentes tipos de iluminación
•
Vertex Lighting: se determinan cuantos polígonos cruzan el vértice, se toma el total
de todas las orientaciones de los polígonos (Normal) y se asigna la normal al vértice.
- 65 -
PFC
LOST IN DARKNESS
Para cada vértice, un polígono dado reflejará la iluminación en una forma levemente
distinta. La ventaja es que le hardware le toma menos tiempo de procesar pero este
tipo de iluminación no produce sombras.
•
Flat Shading Lighting (Iluminación de Sombreado Plano): consiste en que cada
polígono represente un valor leve que se pase al polígono completo que genere una
imagen plana del mismo, a esta imagen también se le asigna un color determinado.
•
Vertex Shading (Sombreado de Vértice, Gouraud shading): solicita al motor de
renderizado un color para cada vértice, luego por medio de interpolación se renderea
cada píxel por la distancia en relación con su respectivo vértice.
•
Phong Shading: es similar al Gouraud Shading, trabajan con la textura, solo que el
Phong Shading usa a los píxeles en lugar de lo vértices.
El Phong Shading toma más tiempo de procesamiento que el Vertex Shading pero su
resultados son mucho mejores en cuestión de suavizado de texturas.
Light Map Generation (Generación del mapa de luz): se usa una segunda capa de textura
(mapa de luz) que dará el efecto de iluminación a los modelos, es un efecto excelente pero
debe tomarse antes del renderizado pero si se tienen Luces Dinámicas (o sea luces que se
mueven, encienden o apagan sin intervención de programa) se debe estar regenerando los
mapas en cada Frame de animación lo que toma mucha cantidad de memoria (pero son de
render rápido).
Textura: es esencial para que las escenas 3D se vean reales, en si las texturas son
imágenes que se rompen en los distintos polígonos del modelo, muchas imágenes tomarán
mucho espacio en la memoria por eso se debe usar técnicas de compresión:
•
Mapeo MIP: consiste en preprocesar las texturas creando múltiples copias del mismo
cada una la mitad del anterior, esto porque si la textura solo es pegada al polígono
cada textura es a cada píxel y tomara más tiempo de render; así cada Texel (elemento
de Textura) toma menos espacio.
•
Texturas Múltiples: requiere múltiples renderizados por lo que para obtener buen
resultado se necesita una tarjeta con Acelerador de Gráficos, provee mejor calidad que
el simple mapeo. Se puede colocar una imagen sobre otra (más transparente) para dar
el sentido de movimiento pulso o hasta sombra.
- 66 -
PFC
•
LOST IN DARKNESS
Bump Mapping: técnica vieja de texturas que tratan de mostrar como la luz se refleja
en el objeto. Solo hasta hace poco se vuelto a retomar.
•
Antialiasing: El anti-aliasing revisa los polígonos y difuminará las bordes y vértices,
para que los bordes no se vean como dentados. Esta técnica se puede hacer de dos
maneras. La primera se realiza de modo individual, entremezclando polígonos para
sobreponerlos unos delante de otros.
La segunda manera se hace por medio de tomar todo el marco y quitarle los bordes
dentados, pero esto requiere de mucha memoria.
•
Vertex and Pixel Shaders (Vértices y Sombreo de Pixeles): Con este método se
pueden extraer y utilizar directamente las características y facilidades de la tarjeta de
video, sin tener que utilizar mucho la API. Pero no es utilizable en todas las tarjetas.
Stencil Shadowing (Plantilla de Sombreado): la idea es renderizar una vista de un modelo
desde la perspectiva de la fuente de luz y después utilizar esto para crear o para generar un
polígono con la forma de esta textura sobre las superficies afectadas por el modelo. Así se
obtiene una iluminación que parece real. Pero es costosa, porque usted está creando
texturas “en vuelo”, y hace múltiple render de la misma escena.
El manejo del caché de textura es imprescindible para que el juego se desarrolle rápido (y
para cualquier motor), ya que si se presenta un constante swapping de las texturas en la
tarjeta el juego se vera lento y tedioso, algunos APIs descargan cada textura cuando esto
pasa, pero eso haría que en cada cuadro se refresquen las texturas dando más lentitud.
Todo se trata de cargar la menor cantidad de veces una misma textura, pero eso también
depende del API que se utilice. Otra técnica es la compresión de texturas, comprimir
texturas es como comprimir MP3, los algoritmos de compresión logran una relación 4:1
que no es mucho pero ayuda.
LOD (Nivel de Detalle): el sistema de nivel de detalle esta relacionada con la complejidad
geométrica de los modelos. Algunos sistemas necesitan que se hagan múltiples versiones
del modelo, para que dependiendo de cuan cerca se este del modelo así será su cantidad de
polígonos. Otros sistemas ajustan dinámicamente esta característica pero en este caso da
más carga al CPU.
- 67 -
PFC
LOST IN DARKNESS
Depth Testing (prueba de profundidad): Con esto se empieza a eliminar los píxeles
ocluidos y se pone en práctica el concepto de sobre dibujado. La prueba de profundidad es
una técnica utilizada para determinar que objetos están delante de otros en la misma
localización del píxel.
Sobre Dibujado: es la cantidad de veces que se ha dibujado un píxel en un frame. Se basa
en la cantidad de elementos existentes en la tercera dimensión (profundidad).
Scripting Systems (Sistemas de Guionaje):
•
Pre-scripted Cinematics: usada normalmente en una situación que necesita la
explicación en una manera controlada. Para presentar las escenas de la historia, ahora
se utilizada el cortar-escenas que presenta la historia en video digital y luego por
medio de transiciones se pasa a las graficas reales del juego.
El Guionaje le permite al diseñador tomar mando de la escena y manipularla, como
colocar objetos o eventos que el jugador no controla. En muy complicado, se necesita de
una mente muy metódica y lógica, la mayoría de estos scripts se basan en lenguaje C.
•
Visual Scripting Systems: como lo dice su nombre, permite manejar el script en un
ambiente grafico en lugar de un código escrito, se maneja un carácter real en un
ambiente del juego real.
Sonido: Creative Labs ahora ha proporcionado sus extensiones manejadores de sonido
EAX para DirectX, y la nueva iniciativa de OpenAL (biblioteca audio abierta). OpenAL,
como suena, es un API para los sistemas de los sonidos de la misma manera que OpenGL
es un API.
Para el procesado de sonido es muy similar al procesado de los modelos, muchas veces un
software los procesa antes de pasar al hardware respectivo, por ejemplo DirectSound hace
al sonido para la Tarjeta de sonido lo que Direct3D hace al modelado antes de llegar al la
Tarjeta 3D. Esto es llamado “premezcla” en el software.
Music Tracks in Games (pistas de audio): Hay dos formas de manejar el sonido. Uno es
por medio de archivos .wav (o similares), lo cual emite un muy buen sonido, pero se
- 68 -
PFC
LOST IN DARKNESS
requiere de mucha memoria. Por otro lado se pude utilizar archivos midi, esto reduce la
necesidad de memoria, pero los sonidos no son tan buenos.
Inteligencia Artificial: es la característica más importante que se le atribuye a un motor al
lado de la representación de modelos o Render. AI provee de estimulo al juego, es critico
en la parte de la Forma de juego (game play).
La inteligencia artificial de determinado juego puede tornarse muy compleja, primero se
debe definir la línea base del comportamiento de los NPC (Non Player Characters Personajes que no son el Jugador), primero debe definirse que hace el NPC (patrulla,
guarda, etc.), luego se delimita su “visión de mundo”, que es lo es el NPC puede ver del
mundo del juego; se debe tomar en cuenta que el personaje no solo estará en medio del
mundo del juego sino que también interactuara con él, después vienen las rutinas de Toma
de Decisión: si el NPC está patrullando, y hay un sonido, ¿debe tomarle importancia o
no?, ¿investiga su origen o no?, etc.
Es un sistema de reglas para las acciones que responden (o inician) y que el jugador debe
responder, esto a un concepto más general de AI.
Emergent game play (Forma de Juego Emergente): consiste en programar al AI con un
conjunto de reglas que le permitan al programa adherir situaciones que el programador no
previera.
- 69 -