Aravid

Tutoriales, Gamer Sense, opinión y más

Archivos por Etiqueta: videojuegos

Gamer sense: Wild Arms

Hace no mucho fui recriminado por no haber visto el anime de Great Teacher Onizuka (GTO en adelante). El caso es que un día o dos antes había empezado a jugar al Wild Arms. Lo más gracioso es que tras unos pocos capítulos, descubro que Onizuka estaba jugando al Wild Arms también, lo que me pareció una señal divina de que tenía que seguir jugándolo y terminarlo.

No hace mucho que lo terminé y no me ha costado precisamente poco. Varias son las razones que han hecho que tardara bastante, algunas llegaron acompañadas de una activación de mi Gamer Sense, y otras no. Voy a hacer un breve repaso de las que lo activaron para justificar el nombre de este artículo, y la serie de artículos que se llaman igual que éste.

Correr es horrible. Y es algo habitual en los RPGs, en los que uno no se mueve precisamente poco. Innumerables mazmorras, ciudades, el mapa del mundo, etc. Además de que hay mucho que recorrer, también deberemos de investigar bastante y hablar con mucha gente (detalle que será ampliamente explicado en otro apartado).

Voy a explicar cómo funciona el correr para que se entienda mi frustración. Con la cruceta uno se mueve caminando, como es habitual, y se queda mirando en la dirección en la que hizo el último movimiento. Normal hasta aquí. Para empezar a correr pulsamos X y lo mantenemos presionado, pero en vez de correr directamente, empieza a mover los pies cómicamente mientras está quieto, como en los dibujos animados para unos momentos después, empezar a correr en la dirección en la que estaba encarado.

El hecho de que tarde bastante en empezar a correr ya es bastante malo de por sí, si no fuera porque viene acompañado de más cosas. El personaje corre en la dirección en la que estaba encarado y no puedes cambiar de dirección a menos que sueltes X, con la cruceta selecciones otra dirección y vuelvas a mantener X. El caso es que al soltar X la inercia te lleva un rato más en la dirección, así que si haces un cambio de dirección, tienes que contar con ese deslizamiento a la hora de hacer los giros.

Wild Arms Correr

Aquí podemos ver como corriendo, nos golpeamos contra el caballo y rebotamos.

Por último, pero no por ello menos importante, el remate total a la hora de correr. Si mientras corres te pegas contra un objeto sólido, ¡te estampas! Te detienes en seco, rebotas contra la pared y hay una animación para dramatizar tu fallo a la hora de manejar a tu personaje. Algo que no es difícil porque a la hora de hacer los giros, como he comentado antes, tienes que contar con la inercia que llevas. Por lo menos, no te haces daño, lo que sería el remate total, ¿verdad LBA?

Después de tanto odio por mi parte al asunto de correr, que no me negaréis que tiene su miga, viene algo que no sabría cómo catalogar. Mi Gamer Sense me dijo que había algo, pero no soy capaz de catalogarlo, y es el funcionamiento de la magia.

Explicación de la magia para que cada uno pueda sacar sus conclusiones. La primera división de magia es en blanca y negra. Una vez hemos seleccionado si es blanca o negra, tendremos una tabla de 4×4 en los que se cruzan los distintos elementos que se disponen, por lo que cada hechizo está formado por dos elementos (el orden es importante) por lo que tenemos 16 hechizos blancos y 16 hechizos negros.

WAmagic

Escaneo del manual de instrucciones con la magia de nivel básico

Para almacenar cada hechizo, debemos de disponer de un emblema sin utilizar, que se encuentra a lo largo de la aventura. Una vez disponemos de emblemas (empezamos el juego con dos) debemos ir a una ciudad del gremio de magia, donde un mago nos dice si queremos crear magia, renombrar un hechizo o disolver un hechizo.

Lo que me desconcierta un poco es, que directamente desde el principio, tenemos acceso a 32 hechizos distintos, y en ningún caso son permanentes, porque al disolver un hechizo recuperamos el emblema utilizado y todo esto por coste 0. No nos cuesta nada crear un hechizo o disolverlo.

No sé exactamente qué pensar. Desde el comienzo tenemos acceso a la mitad de todos los conjuros del juego, porque más adelante, se llegan a los gremios avanzados, que usando los mismos emblemas (por lo que nada te impide disolver todos los conjuros que llevas encima para crear magia avanzada) y el mismo sistema de creación de hechizos, tenemos versiones más potentes de los mismos hechizos y otros que cambian.

Quizá es que siempre que he jugado a RPGs, me han acostumbrado a obtener los conjuros poco a poco, incitando a probar ese nuevo conjuro, probándolos todos, buscando una utilidad y la mejor manera de aprovecharlos. Eso sin mencionar que al principio, nunca se dispone del conjuro que reanima a un compañero caído en combate, pero aquí lo tienes desde el inicio. ¿Qué será de los mercaderes que viven de las colas / plumas de fénix? Yo os digo, que morirán de hambre. Pero en un RPG ese problema nunca es permanente.

Lo que me lleva a otras preguntas más rocambolescas: con el poco uso que tienen los objetos recuperativos, ¿saldría más barato esperar a morir por inanición y luego utilizar un objeto de éstos? Con el poco mercado que tienen, seguro que sus precios están por los suelos. ¿O quizá los PV que aparecen representan el aguante, y realmente uno no muere, simplemente están exhaustos de forma temporal? En ese caso, los objetos no resucitarían, y la idea anterior carecería de valor. Pero de rebote explicaría por qué Aerith puede recuperarse en combates, pero morir en cutscenes. Cambio de tema que esto se me va de las manos.

Recogida de información aleatoria. Bajo este nombre tan chulo está una premisa de los RPGs de antes. No de todos, pero lo he visto en juegos antiguos principalmente, en casi ninguno moderno. Es el caso de la recogida de información que no se te suministra explícitamente para el avance del juego.

Es una norma no escrita el hecho de que al llegar una ciudad, siempre se de una vuelta completa y se hable con todos los PNJs que en ella habitan para obtener información. El problema es que esto no es obligatorio y podría llevar a ciertos problemas si esta información que nos debe de ser transmitida es vital para continuar.

Wild Arms Gemini

Aquí tenemos las imágenes que ilustran el ejemplo de abajo.

Voy a poner un ejemplo real para intentar explicar mi punto de vista. En un punto del juego, se deben de conseguir dos objetos, por lo que se hacen dos grupos, el del jugador, y uno controlado por PNJs para la recogida de objetos. Cuando volvemos con nuestro objeto, descubrimos que el barco en el que viajaba el otro grupo naufragó y se perdió irremediablemente el objeto. Es ahora cuando la persona que había solicitado los objetos dice que si no están los dos, no puede hacer las modificaciones necesarias en la nave, y que hay que buscar otra manera de avanzar, en ese instante recuperas el control y… nada más. Ahí estás, sin objetivo, sin información, sin ayuda. Nada.

¡Y lo peor es que te dice que hay que encontrar otra manera de avanzar! Desconcierto total.

Entonces es cuando uno se tiene que acordar (si es que hemos hablado con el aldeano que comparte esa información) que la ciudad que se llama Cementerio de barcos se llama así porque todos los restos de los barcos que naufragan en el mar interior, terminan en las costas de esta ciudad.

Wild Arms Yard

Aquí observamos como el aldeano en cuestión nos informa del sobrenombre de la ciudad y el porqué del mismo

Ccomo esta situación, se dan varias a lo largo del juego. Yo entiendo que este juego tiene un tiempo, el diseño de los RPGs ha cambiado y antes se podría llevar ese factor exploración de hablar con todos para obtener pistas para seguir en el juego. Tampoco quiero decir que los juegos que te llevan de la manita a todos los sitios son el camino a seguir, pero seguro que existe un punto intermedio a estos dos extremos.

Y por último, que la cosa se está haciendo larga, la traducción del juego. La traducción tiene bichos, y esas son las palabras más suaves que puedo dedicarle, porque entre frases inconexas y las que no se pueden entender, hacen que sea imposible comprender el juego (yo después de recuperar el arquetípico objeto que lleva la princesa que quiere buscar aventuras por los malos, que quieren utilizarlo para resucitar un mal antiguo no entendí casi nada más). Me fastidia porque no pude conectar con la historia ni con los personajes y, acabar el juego, se convirtió en una obligación, porque no tenía interés al no haber podido conectar como he comentado antes.

Como pequeño detalle, las mayúsculas no tienen tilde y en su lugar aparece un cuadrado blanco donde debería aparecer el carácter con tilde. Varios ejemplos son el reino de ‘Ártica’ o el objeto ‘Ánimo total’. Imperdonable.


Como bonus, pongo el video de introducción del remake del juego para PS2

Anuncios

Los precios de los videojuegos

Después de navidad, fecha en la que se aprovecha para la compra y regalo de videojuegos, ofertas locas en plataformas digitales y anécdotas divertidas por parte de los dependientes de tiendas de juegos, creo que es un buen momento para hablar un poco de historia sobre el precio de nuestro entretenimiento favorito.

En la actualidad, el precio de los juegos es extremadamente voluble, de hecho, se podría llegar a pensar que el baile de números es contraproducente para la industria. Los juegos de rigurosa actualidad salen a unos precios totalmente desorbitados a mi parecer que hace que sea realmente difícil su compra (entre unos 60 y unos 70 euros), pero que pierden vigencia muy poco tiempo después, medio año o incluso antes desde el momento de su salida, sus precios suelen desplomarse.

Y eso si no hablamos de los precios de las tiendas digitales, que están ganando relevancia día a día con unos precios y unas ofertas realmente interesantes, pero que dan una falsa impresión de que los juegos no valen lo que nos piden por ellos, si desde estos lugares se pueden vender a los precios que son vendidos.

Steam, una de las primeras tiendas digitales con unos precios de escándalo

Steam, una de las primeras tiendas digitales con unas ofertas de escándalo

Un juego que sale a un precio, que medio año, su versión física cuesta alrededor de la mitad y poco después (o incluso antes) en una de las tiendas digitales a las que tenemos acceso tienen unos descuentos que podría ser la mitad de la mitad, por poner un ejemplo. ¿Realmente el juego vale esos 60 ó 70 euros si muy poco tiempo después podemos conseguirlo casi por una la mitad o una cuarta parte?

Hay explicaciones para estas actuaciones, como por ejemplo conseguir que las ventas se mantengan o remonten de un juego que ya no vende a su precio original y baja su precio para seguir vendiendo, pero esto es la pescadilla que se muerde la cola. La gente conoce estas técnicas y en estos tiempos en los que la cantidad y calidad de los juegos que hay te permite esperar a que los juegos bajen porque ya no venden a su precio original.

Para las tiendas digitales, conseguir que la gente visite su tienda y hacer una compra. A partir de ahí conseguir más compras ya será más fácil. De hecho, es tan fácil y son tan buenos los precios que en mi caso, tengo más juegos comprados en Steam que ni siquiera he instalado, que juegos que me he pasado.

Como en el comienzo del artículo he dicho que quería hacer un poco de historia, creo que es el momento de mirar un poco hacia atrás.

No entendiendo mucho cómo se calcula la inflación para poder hacer una comparativa del incremento de precios, pero yo no recuerdo los juegos de antes tan caros. La mayoría de mis juegos de Master System rondaban las 3.995 pesetas. Tampoco quiero hacer una relación directa desde aquel momento al actual, porque hay razones a lo largo de la historia que alteraban los precios.

Chips como el Super FX de Nintendo o el Sega Virtua Processor que eran añadidos a algunos cartuchos incrementaban su coste en la saga de los 16 bits. En la Nintendo 64, que aún utilizaba cartuchos, había algún ejemplo de mayor precio debido a tecnología incluida, pero son casos muy concretos y no la norma.

Chips Super FX 1 que estaba en varios juegos de SNES, como Starfox

Chips Super FX 1 que estaba en varios juegos de SNES, como Starfox

Para entrar en otro campo, hablar un poco de los juegos indies y los Humble Bundle, a estas alturas a nadie debe de sorprender la gran difusión de los juegos independientes y la indiscutible calidad que pueden alcanzar, además que suelen tener unos precios más bajos, pero que tampoco escapan de las ofertas de las tiendas digitales.

La iniciativa de Humble Bundle Inc. es hacer paquetes de juegos independientes en sus inicios, ahora haciendo de música, incluso ha llegado a hacerse un pack de THQ (cosa ligeramente sospechosa, e imagino que relacionada con el estado de la compañía. Os diré un secreto, no va muy bien).

La particularidad es que cada uno puede dar la cantidad de dinero que desea por los juegos, y generalmente, si pagas más de la media de los aportes, suelen otorgar algún extra, como más juegos. Todo DRM free, y el dinero recaudado se divide entre los desarrolladores, la plataforma que nos brinda estos packs y caridad en la medida que nosotros deseemos.

Bueno, yo creo que ya se ha hablado un poco de mi opinión sobre los precios actuales, sin entrar en temas escabrosos como la segunda mano. Mi recomendación es, que con la cantidad de juegos buenos que hay, a menos que el juego de novedad sea realmente muy esperado, darle tiempo a que baje o esté de oferta en alguna de las plataformas digitales como Steam, Origin o GOG si utilizáis la mejor plataforma de juegos del mundo, como es el PC.

Beginning Android Games I

Desde que terminé el curso de Diseño y creación de videojuegos, no he tenido claro a qué quería dedicarme profesionalmente, así que para no perder la oportunidad de seguir mejorando y aprendiendo, busqué y encontré este libro que habla sobre el desarrollo de juegos para android y que había sido traducido recientemente. Con una búsqueda rápida de opiniones, observé que había algunas quejas, uno de los ejemplos era que unsigned number había sido traducido por número sin firmar, haciéndome pensar que no había sido traducido por alguien con conocimientos sobre este tema, así que me decanté por la versión original.

Portada del libro

No puedo hacer un análisis completo del libro porque aún no lo he terminado, pero si quiero plasmar mis primeras impresiones sobre el libro y algunas consideraciones sobre el desarrollo de juegos para android.

Primero hablaré del libro, que hasta el momento (llevo más de un tercio), me ha gustado cómo está estructurado y su metodología de aprendizaje. Otro detalle interesante es que no entra a programar a saco sin tocar nada más. Comienza explicando un poco el proceso previo o preproducción de un videojuego y cómo enfocarlo. Una vez ha pasado ese paso previo, te enseña mediante ejemplos, las capacidades que ofrece android, aún sin entrar en el mundo de juegos, son cosas básicas que hará falta entender y comprender para más adelante, como el uso de la pantalla táctil, acelerómetros, etc.

Ya tenemos las cosas básicas para empezar a hacer nuestro juego, que es lo que más nos apetece, pero hay otro paso más y que, personalmente, me parece un gran acierto. Realizar un framework propio para luego utilizarlo en nuestro juego, o en todos los que queramos, porque será totalmente funcional y realizará casi todo lo que podamos querer (tendrá limitaciones, en la primera versión no usará openGL ES, por ejemplo, pero a lo largo del libro, este framework también evolucionará).

Con todos los pasos previos cumplidos, con una idea general de qué se puede hacer en android, cómo hacerlo, y un framework funcional, lo siguiente es crear un juego de ejemplo, y el libro propone un Snake de toda la vida, así que durante algunas páginas más, nos explica cómo hacerlo, acompañado del código completo y unos assets que son de un estilo por el que siento predilección, y es dibujado a mano en libreta.

Menú principal del juego de ejemplo, Mr. Nom

Al terminar el juego, probarlo en nuestro dispositivo y emocionarnos al ver que hemos hecho un juego, nos emplaza a juguetear con el framework antes de seguir y ese es el punto en el que me encuentro. Pensé en un juego fácil de implementar para simplemente probar que había adquirido los conocimientos creando algo por mi cuenta, y pensé en hacer un shooter vertical, que es otro de esos géneros por los que tengo predilección, así que ahora me encuentro inmerso en ese proceso de creación de una demo (no quiero hacer un juego completo, simplemente es para probar el framework volando en solitario).

Más o menos he ido hablando de lo que hace el libro y cómo lo hace, en general estoy muy contento con él, pero con android no tanto, así que ahora hablaré un poco de él:

  • Demasiados dispositivos: Este es un problema grave, porque hay miles de millones de dispositivos distintos, cada uno con unas características propias (android especifica unos mínimos a cumplir por todas, por lo general, eso permite saber que al menos, pantalla tácil, acelerómetros y algunas cosas más van a estar presentes en todos) pero no sabemos si tendrá teclado, o qué resolución usará, por ejemplo. Tampoco hay seguridad de que dispongan de la última versión de android, aunque de eso hablaremos más en otro punto. Yo diría que este es un mal escenario para la creación de un juego o de una aplicación. Afortunadamente hay maneras para solventar algunos de estos problemas y el libro los aborda. Punto para él.
  • Java: No es especialmente malo, pero a mi Java no me gusta. No hay una razón lógica para decir que no me guste, qué le vamos a hacer. Pero en este lenguaje hay que tener en cuenta que no tenemos control sobre el recolector de basura. Es un problema que salte a mitad del juego porque, como se comenta en el libro, puede detener nuestro juego durante una cantidad de tiempo significativa, pero una vez más, disponemos de técnicas para evitar en la medida de lo posible esto.
  • Empresas malvadas: Estas malditas lanzan un producto con una versión determinada de android con una capa propietaria que lo envuelve. Suele ser bueno porque, generalmente, añade funcionalidades propias que no son implementadas de serie, pero tiene un lado malo, y es que no permiten actualizar android, porque se debe de añadir a cada nueva versión la capa propietaria. En el mejor de los casos, las actualizaciones se realizarán con retraso, y en el peor, que la empresa  decida que van a dejar de crear actualizaciones. Esto limita la cantidad de dispositivos a los que podemos dirigirnos a menos que al programar, tengamos este detalle en cuenta.

Captura del juego Mr.Nom

Para finalizar el artículo, quiero compartir el juego de Mr.Nom que he realizado con la ayuda del libro, quizá a la gente le sirva como incentivo después de verlo para entrar en este mundo, así que os dejo un enlace a él para probarlo en vuestros dispositivos android, está preparado para funcionar con versiones muy bajas de android, por lo que es factible probarlo en casi cualquier aparato.

https://www.dropbox.com/s/lwok0hcyljc6v6m/Mr.Nom.apk

Documentos de diseño

Aunque en la etapa de preproducción se realizan muchos documentos de diseño, voy a hablar de los tres que son más relevantes en esta fase y que sirven para describir la evolución de la idea del juego, por llamarlo de alguna manera.

Si alguien tiene dudas sobre el proceso de creación de un videojuego, les remito a Game Over, el primer programa satírico sobre videojuegos, programa de radio y podcast en el que fanatiko tiene una sección llamada “Destripando la industria” donde habló sobre Las fases de desarrollo de un videojuego.

Su artículo es especialmente interesante porque la mejor visión posible es la de alguien que trabaja ya en la industria, porque aunque yo intentara hablar sobre ello, no sería más que un enfoque teórico, porque aún no he participado en ningún desarrollo.

Comenzando con el meollo, los tres documentos a tratar son el

  1. Game Design Overview o One-sheet
  2. Ten-Pager
  3. Game Design Document o GDD
Todos tienen una serie de características comunes y es bueno tenerlas en cuenta a la hora de redactarlos:
  • Concreción. Sobre todo en las versiones “técnicas” de los mismos, es decir, los que van orientados a tu grupo de trabajo.
  • Precisión. Los documentos serán la información base con la que la gente trabajará y creará los contenidos. Cuanto más exacto mejor porque evitarás interpretaciones erróneas y eso ahorrará tiempo.
  • Ameno. Mucha gente va a leer el documento, y si es un ladrillo, será pesado para los que lo tienen que consultar. Intenta organizarlo lo mejor posible y utiliza las herramientas disponibles, como índices, enlaces y listas.
  • Bien escrito. Al igual que por la razón que el punto anterior, mucha gente terminará consultando tus documentos, y los fallos gramaticales o tipográficos pueden dar una sensación de dejadez o de falta de interés a la hora de redactar los documentos, así que revísalos.

One-Sheet

Como su nombre indica, es un documento que idealmente debe de ocupar una cara y tener la capacidad de ser atractivo, porque va a ser la carta de presentación de tu idea. ¡Y vas a tener solo una cara para expresar lo maravilloso que va a ser! Siempre va a ser insuficiente y hay una serie de datos que es más que recomendable que aparezcan, reduciendo aún más tu espacio. Tampoco es obligatorio hablar sobre los datos que comentaré a continuación, pero es una plantilla bastante buena.

  • Título del juego
  • Plataformas en las que estará disponible
  • Edad objetivo
  • Calificación por edades (PEGI y ESRB)
  • Resumen de la historia
  • Jugabilidad
  • Unique Selling Points o USP. Es decir, qué hace especial a tu juego
  • Competencia

Otra cosa importante sobre este documento es que, por lo general, no va a estar dirigido a una persona que juega habitualmente. Este documento, con el que pretender vender tu idea, estará leído por gente que tiene que invertir o por jefazos, así que intentar hacerlo lo más ameno posible será buena idea.

Ten-Pager

El Ten-Pager es la evolución del One-Sheet, si la cosa funciona como es debido, la idea debe de desarrollarse, en este caso, hasta que ocupe unas diez páginas, pero al igual que el documento anterior, si es posible que sea más escueto, es incluso beneficioso.

Como detalle y para posibles contingencias, no está de más que este documento tenga forma de presentación de diapositivas, porque si la idea gustó, probablemente la siguiente fase sea enseñar, en forma de pequeña presentación, por qué tu juego es el mejor en este momento prematuro y deben de invertir su dinero a lo loco en tí.

Pero un Ten-Pager más técnico para que tu grupo pueda comenzar a trabajar tampoco está de más, por lo que mi recomendación es hacer dos documentos (por suerte no son extensos) siendo uno más centrado a la venta de tu producto y otro más centrado a las características del juego.

Los apartados recomendados para este documento, y con una longitud de aproximadamente una página por cada uno son:

  • Página del título
  • Resumen del juego
  • Personajes
  • Jugabilidad
  • Mundo
  • Experiencia de juego
  • Mecánicas
  • Enemigos
  • Cutscenes
  • Material extra
Una regla que se aplica en este documento y en el siguiente es la regla de los tres ejemplos, porque los ejemplos son un gran aliado. Permiten explicar situaciones con todo lujo de detalles y la resolución de las mismas, permitiéndonos aclarar posibles puntos oscuros. Siguiendo con la regla de los ejemplos:
  • El primer ejemplo da una idea al lector sobre la situación, pero puede que no quede claro.
  • El segundo ejemplo nos permite comparar con el primer ejemplo.
  • El tercero anula el efecto binario, y complementa los ejemplos anteriores.

¿Quiere esto decir que cada vez que hay que poner un ejemplo, debemos de invertir el espacio y la capacidad de atención del lector con tres? Evidentemente no, hay que saber cuándo utilizar esta técnica.

Game Design Document

Este ladrillo de innumerables páginas será vuestra peor pesadilla por varias razones, pero para desarrollos grandes, mi opinión es que hace falta, ya que en él TODO debe de estar especificado, explicado y detallado para que cualquier desarrollador, en un momento dado, si tiene que consultarlo para saber cómo realizar algo, lo encuentre y no tenga que molestar a las personas que han dedicado su tiempo a la creación de este documento.

Por desgracia todos conocemos a la gente y lo vaga que es, y en más de una ocasión pasarán de buscar en el documento y preguntarán directamente. Esto es inevitable a menos que dispongas de un elemento disuasorio en una posición privilegiada y visible (como por ejemplo, un trofeo de caza con la cabeza del último desarrollador que preguntó demasiado), pero se puede mitigar siendo un documento ordenado, fácil de entender y ameno (cosa imposible para este documento).

Otro de los grandes problemas que traerá este documento, es que el proceso de desarrollo de un juego es un proceso vivo, y a lo largo del tiempo, ciertas cosas ya especificadas serán modificadas por alguna razón, y todos esos cambios deben de figurar en este documento, así que mantenerlo al día debería ser imperativo.

Nota: Si os habéis dado cuenta, estos documentos están enfocados a la entrega a un publisher y un desarrollo para un grupo grande. Esto no quiere decir que no os pueda servir para un desarrollo individual o para grupos pequeños. Mi experiencia es que estos documentos habrían sido de gran ayuda en el caso de haberlos realizado correctamente y habernos ceñido a ellos.

Aprovecho para agradecer a Victor Cerezo por la clase sobre Documentación, sin la que éste artículo no habría sido posible.

UDK: Estructura de carpetas

El siguiente paso, una vez tenemos las herramientas instaladas y correctamente configuradas es entender cómo gestiona UDK un proyecto y dónde debemos colocar las cosas para que sean visibles desde UDK. También es importante conocer ciertos archivos que se esconden en la estructura de carpetas de la instalación, así que la comentaré, haciendo hincapié en los ficheros que utilizaremos, y las carpetas que debemos crear para nuestro proyecto.

En la instalación limpia, disponemos de las siguientes carpetas:

  • Binaries
  • Development
  • Engine
  • UDKGame

Ahora comentaré una a una las carpetas, y la importancia detrás de cada una de ellas.

Binaries

UnrealFrontend.exe será nuestro centro de operaciones, desde él tenemos acceso a todo lo que nos permite UDK.

Captura de pantalla del UnrealFrontend, con el proyecto que estoy realizando, DCleaner

No voy a entrar en muchos detalles, porque el UnrealFrontend merece un artículo para él solo. Sí que os digo que en el menú de la izquierda salen los distintos proyectos que están disponibles para trabajar, pero ya comenté que no es recomendable trabajar con más de un proyecto por instalación de UDK, por eso sólo tengo uno.

UnrealFrontend.Profiles

Es una carpeta donde, en formato xml, se almacenan los datos de los proyectos, que son leídos por el UnrealFrontend. Aquí no es necesario hacer nada, porque los cambios realizados se guardan automáticamente, pero es importante conocer la existencia de la carpeta, por si utilizáis algún sistema de control de versiones para añadir el fichero de información del proyecto.

Recomendación: Para conseguir un proyecto propio, lo mejor es clonar uno ya existente, renombrarlo y eliminar todos los mapas que están añadidos. Una vez hecho esto, ya podemos comenzar a utilizarlo.

Development

Dentro de Development, tenemos la carpeta de Src, y dentro de ella, debemos de crear una carpeta para nuestro trabajo. Si nuestro proyecto se llama DCleaner, lo recomendable sería mantener ese nombre para las carpetas.

  1. Development
    1. Flash
    2. Src
      1. DCleaner
        1. Classes

Como se ve en el esquema de arriba, la carpeta DCleaner tiene que ser creada en Src, y dentro de la carpeta que hemos creado, tenemos que crear una llamada Classes. En esta carpeta, se guardarán todos nuestros ficheros en UDKScript, con extensión .uc, pero no es suficiente para que UDK lo encuentre. Tenemos que especificarlo en un fichero de configuración. En el siguiente apartado, se comentará la ubicación del fichero.

Engine

Nada importante para nosotros.

UDKGame

En este fichero es donde estará casi todo nuestro juego, a excepción de los ficheros de UDKScript. Vamos poco a poco:

Config

Lo que voy a decir suena raro, pero la lógica utilizada aquí a veces lo es. Si observáis la carpeta, veréis que la mayoría de los ficheros están duplicados con un nombre ligeramente distinto, por ejemplo, DefaultInput.ini y UDKInput.ini. El sentido común podría dictarnos que el fichero DefaultInput.ini no debería de ser tocado, ya que son los valores por defecto, y tendremos que trabajar con el otro. Pues no.

El fichero con el que debemos trabajar es con el Default, porque los otros ficheros, cada ejecución de Unreal, son borrados y creados de cero, para asegurar que los valores se mantienen. Una vez comentada esta curiosidad, hablaré de los ficheros que debemos cambiar, y lo importante dentro de cada uno de ellos:

DefaultEngine.ini Aquí es donde especificamos la carpeta creada arriba, donde están nuestros ficheros de UDKScript, para que sea tenida en cuenta por el motor. Tenemos que buscar el bloque [UnrealEd.EditorEngine] y al finalizar el mismo, añadir la línea +ModEditPackages=DCleaner (siendo DCleaner el nombre de vuestra carpeta). Debería de quedar así:

[UnrealEd.EditorEngine]
+EditPackages=UTGame
+EditPackages=UTGameContent
+ModEditPackages=DCleaner

Hay más bloques que podrían modificarse, pero tienen menos importancia, como el bloque de [FullScreenMovie] donde se especifican las películas de carga. El necesario es el de arriba para que nuestros ficheros de UDKScript sean compilados.

DefaultGame.ini Aquí hay que especificar algunos ficheros de UDKScript, pero que aún no hemos creado. Os diré qué serán esos ficheros, y la convención de nombres utilizada. Primero, os copio el bloque concreto que hay que modificar, y las primeras seis líneas:

[Engine.GameInfo]
DefaultGame=DCleaner.DCleanerGI
DefaultServerGame=DCleaner.DCleanerGI
PlayerControllerClassName=DCleaner.DCleanerPC
GameDifficulty=+1.0
MaxPlayers=32
DefaultGameType=”DCleaner.DCleanerGI”;

De todo el bloque, tenemos que modificar las primeras tres líneas, y la sexta. El primer DCleaner, que antecede al punto, es la carpeta de nuestros ficheros, que se llama DCleaner, y después es el nombre del fichero de UDKScript.

El fichero DCleanerGI es el Dungeon Cleaner Game Info, en él se especifican las clases que definen aspectos del juego, como la clase que controlará al jugador, la clase que definirá al jugador o la clase que especificará el HUD utilizado.

El fichero DCleanerPC es el Dungeon Cleaner Player Controller, en este fichero está programado el comportamiento del personaje.

Aviso: Estos ficheros los crearemos más adelante, pero lo importante ahora es saber dónde hay que colocarlos, y qué hace cada uno.

DefaultInput.ini Las asignaciones de teclas a las acciones se realizan aquí. Decir que UDK utiliza un sistema que hace de capa intermedia entre el código y la pulsación de una tecla, que es la GBA o Game Bindable Action. El funcionamiento es que a un método que realiza algo, se le asigna una GBA, y luego, a un botón concreto, se le asigna esta GBA en vez del método. La utilidad es que el reasignar teclas dentro del juego, y los botones de las distintas plataformas es más cómodo.

Content

En esta carpeta va todo nuestro contenido del juego, pero para tenerlo todo organizado, hay que crear una carpeta dentro de Content con el nombre de siempre, DCleaner.

  1. UDKGame
    1. Content
      1. DCleaner

Dentro de esta carpeta, guardaremos nuestros ficheros de mapa que crearemos con el UnrealEditor, y los paquetes de Assets que son unos ficheros que encapsulan todos nuestros contenidos, como mallas estáticas, materiales, animaciones, etc.

Flash

La última carpeta, es la de Flash. En ella se guardan las películas creadas en flash para ser introducidas en el juego. El motor implementa ScaleForms, que es un middleware que nos permite utilizar una película en flash dentro del juego, ejecutar código de ActionScript y comunicarnos en los dos sentidos con dicha película, es decir, desde UDKScript con ActionScript, y viceversa.

Para que los ficheros se añadan correctamente, deben de estar dentro de una carpeta, dentro de Flash. Por alguna razón, en la versión en la que trabajo, no puedo especificar el paquete al que quiero importarlo, lo importa directamente en un paquete con el nombre de la carpeta, por ello, crearemos una carpeta con el nombre del paquete de Assets con el que trabajaremos, para que al importar un fichero, lo añada donde queremos. Sabiendo que nuestro paquete de assets se llamará DCleanerAssets, crearemos la siguiente estructura de carpetas:

  1. UDKGame
    1. Flash
      1. DCleanerAssets

Aviso: Los ficheros de Flash deben de tener ciertas características para que funcionen correctamente, al igual que una versión concreta de ActionScript. Estos detalles se comentarán en el tutorial de integración de elementos de Flash con UDK Script.

Presentación

Como primera entrada que se precie del recién estrenado blog, voy a contar quién soy yo y para qué lo quiero.

En la actualidad, con la carrera de Ingeniería Técnica en Informática de Sistemas a punto de caramelo, aproveché el tiempo para entrar en el curso de Especialista universitario en Diseño y Creación de Videojuegos para aprender sobre una de las cosas que más me gusta en la vida, y me encantaría dedicarme a ella.

Una de las grandes ventajas del curso es que incorpora un proceso guiado para la realización de un pequeño proyecto utilizando un motor ampliamente extendido y gratuito, como es UDK. Los alumnos del curso se unen para formar grupos multidisciplinares (ya que no está enfocado al lado técnico del desarrollo de videojuegos) y trabajar para la culminación de esta demo, por llamarla de alguna manera.

Una vez dicho esto, y ya con la idea de hacer un blog, pensé que lo mejor sería el unir mi interés por los videojuegos y el desarrollo de estos junto con la experiencia del aprendizaje con un blog de desarrollo, en el que contaré los avances que voy realizando en el proyecto (más centrado en mi parte, por eso de ser un blog personal) y los explicaré en forma de tutoriales, para que todos los que quieran aprender, puedan utilizar este blog como una página de referencia.

También destacar que no sólo hablaré del desarrollo, también me permitiré alguna licencia como hablar de algún juego que me haya gustado, alguna idea que me ronde la cabeza o ahondar en algunos de los temas relacionados con los videojuegos pero que no siempre son de dominio público.

Espero que os guste la idea y que en última instancia, os sirva de algo todo lo que ponga aquí.