viernes, 21 de diciembre de 2012

GameMaker: Acciones básicas III

Main actions, set 2

Acciones relacionadas con el tiempo, dar mensajes al usuario y tratar con el juego.

Set Alarm: Con esta acción puedes configurar una de las doce alarmas para la instancia. Selecciona el número de pasos y el reloj de alarma. Despues de indicar el número de pasos (fotogramas), la instancia recibirá el evento de alarma correspondiente. Puedes ademas incrementar o decrementar el valor marcando la casilla relative. Si defines el reloj de alarma a un valor menor o igual que cero lo apagaras, por lo que el evento no será ejecutado. Una vez configures una alarma podrás usar el evento Alarm para ejecutar acciones dentro del mismo.

Sleep: Con esta accion puedes congelar la escena por un tiempo. Esto se usa al inicio o al final del nivel o cuando le muestras al jugador algun mensaje. Puedes especificar el número de milisegundos de congelación. Ademas puedes indicar cuando la pantalla debería ser dibujada primero para reflejar la situación más reciente.

Display Message: Con esta accion puedes mostrar un mensaje en una ventana de dialogo. Simplemente escribe el mensaje. Si usas el simbolo # en la caja de texto, será interpretado como el carácter de nueva linea. (Usa \# para escapar el simbolo). El juego será pausado mientras se muestra el mensaje.

Show Info: Con esta acción puedes lanzar una ventana con la información del juego.

Restart Game: Con esta acción se reinicia el juego desde el principio.

End Game: Con esta acción termina el juego.

Save Game: Con esta accion puedes salvar estado de juego actual. Especificas un archivo de salvado (El archivo se crea en el directorio de trabajo del juego). Mas tarde el puedes cargarlo usando Load game. Solo el estado básico de juego es salvado. Cosas como por ejemplo el sonido actual que suena o aspectos avanzados como contenidos de estructuras de datos o particulas no se guardan.

No suele ocurrir ninguna acción durante el uso de save Game, por lo que puede que el jugador no se este dando cuenta de que ha salvado el juego, por lo que recomiendo mostrarle algun mensaje confirmando que todo hay ido bien.

Load Game: Carga el estado de un juego de un fichero. Especificas el nombre de archivo y ya está. Asegurate que el juego salvado es el mismo juego y que se ha creado con la misma versión de GameMaker. De lo contrario un dará error.



(Recordemos que todo esto se explica (en inglés) en la ayuda de GameMaker, pero lo estoy probando para ver como funciona todo, así que se podría decir que este “manual intensivo” es una traducción adaptada.)
 

jueves, 20 de diciembre de 2012

GameMaker: Acciones básicas II

Main Actions: Set 1

Relacionadas con crear cambiar y destruir instancias de objetos, con sonidos y con habitaciones.

Create Instante: Con esta acción puedes crear una instancia de un objeto. Especificas que objeto crear y la posición de la nueva instancia. Si marcas relative, la posición es relativa a la posición de la instancia actual. Crear instancias durante el juego es extremadamente útil. Una nave espacial disparar un láser, una bomba puede crear una explosión, etc. En muchos juegos puedes tener algunos objetos controladores que de vez en cuando crean monstruos u otros objetos. Para la nueva instancia creada, el evento de create será ejecutado.

Create Moving: Esta acción trabaja igual que la anterior pero con dos campos adicionales. Puedes especificar la velocidad y dirección de la nueva instancia. Destacar que si marcas la casilla relative, solamente la posición será relativa, no la velocidad ni la dirección. Por ejemplo, para hacer una bala en movimiento en la dirección del objeto que esta disparando, como posición usa x=0 e y=0 marcando relativo. Como dirección necesitamos la dirección actual de la instancia. Puedes obtenerla escribiendo la palabra “direction” (es una variable que indica la dirección actual en la que la instancia se esta moviendo).

Create Random: Esta acción te permite crear una instancia aleatoria entre cuatro objetos. Tú especificas los cuatro objetos y la posición, y una instancia de uno de estos objetos es creada en la posición dada. Si marcas la casilla relativa, la posición es relativa a la posición de la instancia actual. Si necesitas una elección de menos de cuatro objetos puedes usar “No Object” para alguno de ellos. Esto es útil, por ejemplo, para generar enemigos aleatorios en una posición.

Change Instance: Con esta acción puedes cambiar la actual instancia en una instancia de otro objeto. Por ejemplo, puedes cambiar una instancia de una bomba en una explosión. Todos los parámetros, como el movimiento y el valor de las variables son las del otro objeto. Además puedes indicar si se lanzará el evento destroy cuando el actual objeto desaparezca y el evento create para el nuevo objeto.

Destroy Instance: Con esta acción puedes destruir la instancia actual. El evento destroy será ejecutado en la misma.

Destroy at Position: Con esta acción destruyes todas las instancias que estén dentro de un rectángulo que contiene la posición dada. Es útil, por ejemplo, cuando usas una explosión que quieres que afecte un espacio determinado de la pantalla. Si marcas la casilla relative, la posición es tomada como relativa a la posición de la instancia actual.

Change Sprite: Usa esta acción para cambiar el sprite de la instancia. Puedes indicar cual es el nuevo sprite y, además, los fotogramas que deben mostrarse. Normalmente puedes usar 0 (para el primer fotograma) a no ser que quieras ver un fotograma particular. Usa -1 si no quieres cambiar el fotograma actual a mostrar. Finalmente puedes cambiar la velocidad de la animación de los fotogramas. Si solo quieres ver un fotograma particular, configura su velocidad a 0. Si la velocidad es mayor que uno, algunos fotogramas pueden saltarse. Si es menor que 1, pueden mostrarse varias veces. Es mejor que no uses velocidades negativas.

Esta es una acción importante. Por ejemplo, cuando quieres cambiar un sprite de un personaje dependiendo de la dirección en la que anda. Puedes usar esta acción con sprites para cada una de las direcciones posibles. Con los eventos de keyboard para las teclas puedes definir la dirección de movimiento del sprite. También es el útil para controlar las animaciones.

Transform Sprite: Usa esta acción para cambiar el tamaño y orientación del sprite de la instancia. Usa los factores de escala para hacerlos mayores o mas pequeños. El Angulo se cuenta en sentido contrario a las agujas del reloj. Por ejemplo, para poner el sprite orientado a la dirección del movimiento usa como valor “direction”. Por ejemplo, esto es útil para un coche. Puedes además indicar cuando el sprite debería espejarse horizontalmente o verticalmente. Esta acción esta solo disponible en la versión Standard.

Color Sprite: Normalmente el sprite es dibujado como esta definido. Usando esta acción puedes cambiar el color del sprite. Este color se fusionará con el del sprite, es decir, será combinado con los colores del sprite. Gracias a esto podrías pintar un sprite en blanco y negro y usar la fusión de color para definir el color actual. Puedes además indicar un canal alpha de transparencia. Con este valor a 1 el sprite es opaco. Con este valor a 0 es completamente transparente. Con este valor en un número intermedio es, evidentemente, semitransparente. Es genial para hacer explosiones. Esta acción esta solo disponible en la edición Standard.

Play sound: Con esta acción puedes ejecutar uno de los sonidos que añadiste a los recursos de tu juego. Puedes seleccionar el sonido que quieres ejecutar y elegir si debería sonar solo una vez (por defecto) o continuamente. Aunque pueden ejecutarse varios sonidos a la vez, en el caso del midi, solo puede haber uno sonando. Por ello si inicias un midi el que tenías sondando se parará.

Stop Sound: Esta acción para el sonido indicado. Si las múltiples instancias de este sonido están sonando se paran todas.

Check Sound: Si el sonido indicado esta sonando la próxima acción se ejecuta. En otro caso se salta. Puedes seleccionar Not para indicar que la próxima acción debería ejecutarse si el sonido indicado no esta sonando. Por ejemplo, puedes comprobar si hay música de fondo sonando.

Previous Room: Salta al nivel habitación. Puedes indicar si el tipo de transición entre las habitaciones. Cuando las habitaciones no tienen el mismo tamaño, no es recomendable usar transiciones. Si estas en la primera habitación obtendrás un error.

Next Room: Te mueve a la siguiente habitación. Puedes indicar la transición.

Restart Room: La habitación actual se reinicia. Puedes indicar el efecto de transición.

Different Room: Con esta acción puedes ir a una habitación concreta, indicando la habitación y el efecto de transición.

Check Previous: Con esta acción comprobamos si la próxima habitación existe. Si es así. La próxima acción es ejecutada. Normalmente necesitas esta acción de tipo test antes de moverte a la habitación anterior.

Check Next: Esta acción testea si la próxima habitación existe. Si es así, la próxima acción es ejecutada. Igual que con la acción anterior deberías testear si existe antes de ir a la próxima habitación.

De nuevo la información sale del manual del software, yo solo me dedico a probarlo, aprender y explicar. (Y en la sombra pensar en mi juego para el concurso del Blog de Toodaim, muahahahahaha).

miércoles, 19 de diciembre de 2012

GameMaker: Acciones básicas I

Continuando con el repaso de GameMaker vamos a hablar ahora de las acciones básicas del programa e ir profundizando en ellas poco a poco. Recordemos, eso si, antes, que las acciones son la respuesta a los eventos que mencionaba en el post anterior. Primero hay un evento (ocurre algo en el juego) y como consecuencia se ejecutan una o varias acciones.


Move Actions   

Move Fixed: Usa esta accion para iniciar el movimiento de una instancia en una direccion particular. Puedes indicar la direccion usando los botones con las flechas. Usa el boton central para detener el movimiento. Necesitas especificar la velocidad del movimiento que se mide en pixels por fotograma, y preferiblemente usar valores positivos. Puedes especificar direcciones múltiples. En este caso se realiza una elección aleatoria. De esta forma puedes hacer que un enemigo se empiece a mover a la derecha o a la izquierda, por poner un ejemplo.

Move Free: Segunda forma de especificar movimiento. Puedes indicar una dirección precisa con un angulo entre 0 y 360, siempre teniendo en cuenta que el 0 apunta a la derecha y aa direccion gira en sentido contrario de las agujas del reloj. Por ejemplo 90 es arriba. Si quieres una direcció arbitraria puedes escribir “random(360)”, por que la funcion random devuelve un número aleatorio menor que el valor indicado.

Hay un checkbox Relative. Si lo marcas, el nuevo movimiento se añade al que había. Por ejemplo, si la instancia se mueve hacia arriba y añades movimiento a la derecha el nuevo movimiento es arriba a la derecha.

Move Towards: Esta accion nos proporciona un tercer modo de movimiento. Indica la posicion y una velocidad y la instancia empieza a moverse con la velocidad hacia la posición, teniendo en cuenta que no parará en la posición. Por eemplo, si quieres que una bala vaya hacia la posicion de una nave puedes usar spaceship.x, spaceship.y. Si chequeas la casilla Relative, especificas una posicion relativa a la posicion de la instancia actual. (La velocidad no es tomada como relativa).

Speed Horizontal: La velocidad de una instancia consiste en una parte horizontal y una vertical. Con esta accion puedes cambiar su parte horizontal. Un valor positivo significa movimiento a la derecha mientras que negativo es a la izquierda. Usa relativo para incrementar o decrementar la velocidad cada vez en vez de usar una fija.

Speed Vertical: Similar al horizontal pero en vertical.

Set Gravity: Con esta accion puedes especificar gravedad para un objeto particular. Especificas la direccion (angulo entre 0 y 360) y velocidad. En cada fotograma es añadida al movimiento actual de la instancia, esta cantidad de velocidad en la direccion dada. Normalmente necesitas un valor pequeño como 0.1 en una dirección hacia abajo (270 grados). Si marcas la casilla relativa se incremente la gravedad y la dirección. Notese que contrario a la vida real, se pueden poner diferentes direcciones y fuerzas de gravedad a diferentes objetos.

Reverse Horizontal: Con esta accion inviertes el movimiento horizontal de la instancia. Esto puede por ejemplo usarse cuando el objeto choca con una pared vertical.

Reverse Vertical: Con esto inviertes el movimiento vertical de la instancia.

Set Friction: La fricción decrementa la velocidad de una instancia cuando se mueve. Especificando la cantidad de friccion, en cada salto esta cantidad se resta de la velocidad, hasta que la velocidad se convierta en 0. Normalmente queremos valores muy pequeños como 0.01.

Jump to position: Usa esta accion si quieres situar una instancia en una posicion particular. Simplemente especificas las coordenadas x e y para que la instancia se coloque con su punto de referencia en esa posicion. Si marcas Relative, la posicion es relativa a la posicion actual de la instancia. Esta opción es a menudo usada para mover continuamente una instanca en cada salto, incrementando su posicion un poco.

Jump to Start: Esta accion hace que la instancia vuelva a la posición donde fue creada.

Jump to Random: Esta acción mueve la instancia a una posición aleatoria de la habitación. Solo se eligen posiciones donde la instancia no interseca con otra instancia solida. Puedes especificar ademas, el ajuste usado. Puedes especificar un valor horizontal de ajuste separado del vertical.

Align to Grid: Con esta accion puedes redondear a la posición de la instancia en una rejilla. Puedes indicar ambos, el ajuste vertical y el horizontal (El tamaño de las celdas de la rejilla). Esto puede ser util para asegurarte de que las instancias se desplazan en casillas de una medida concreta.

Wrap Screen: Con esta accion puedes hacer que una instancia reaparezca por el otro lado de la habitación si sale por uno de los lados. Esta acción se usa normalmente con el evento Outside. Notese que la instancia debe tener una velocidad para trasladarse y asi funcionar, por que la direccion del “teletransporte” depende de la del movimiento. Puedes indicar si transportarse solo horizontalmente, solo vertical o en ambas direcciones.

Hay que destacar que si estamos desplazando nuestra instancia de objeto con el metodo Jump to position, no funcionará el wrap, ya que este debe llevar alguna velocidad.

Move to Contact: Con esta accion puedes mover la instancia en una dirección dada, mientras entre en contacto con un objeto. Si hay una colision en la posición actual la instancia no se moverá. Sin embargo, la instancia es colocada justo antes de que la colisión ocurra. Puedes especificar la direccion y además, una distancia maxima a mover. Por ejemplo cuando la instancia esta cayendo puedes moverla una distancia maxima mientras un objeto se encuente. Puedes ademas indicar si consideras objetos solidos o todos los objetos. Tipicamente pon esta accion en un evento de colision para asegurarte de que la instancia se para en contacto con la otra instancia envuelta en la colisión. El problema de esta acción es que la instancia solo para si va en la dirección indicada. (En otras ocasiones a mi me hace una especie de wrap y no lo acabo de entender).

Bounce: Cuando pones esta acción en el evento de colision con otro objeto, la instancia rebota desde este objeto de modo natural. Si defines el parámetro preciso como false, solo los muros verticales y horizontales son tradados correctamente. Cuando marcas precise a true, además muros ladeados (incluso curvados) son tratados correctamente. Esto sin embargo es más lento, evidentemente. Además, puedes indicar cuando el bote solo se haga sobre objetos solidos o sobre todos los objetos. Notese que el bote no es completamente real por que depende de muchas propiedades, pero en la mayoría de situaciones el efecto da el pego.

(Por cierto, que estoy sacando todos estos datos de la ayuda del programa y probandolo personalmente a ver si voy aprendiendo :P)

domingo, 16 de diciembre de 2012

Aprendizaje: GameMaker

Estos días, con motivo del concurso de videojuegos organizado por el Blog de Toodaim, estoy repasando el funcionamiento de GameMaker, por lo que he pensasdo en hacerme un mini-manual de lo más importante de programa, sus eventos y sus acciones. Podría haber hecho un manual completo, pero el software ya viene con un par de tutoriales con los que aprender la parte más básica, así que me voy directo al grano.

Cosas importantes en GameMaker:

(objects): Objetos que se instanciaran en los juegos y tendrán unas propiedades y comportamientos.

(rooms): Habitaciones, es decir los niveles o pantallas donde colocaremos los objetos.

(sprites): Imágenes o animaciones que representan visualmente los objetos.

(sounds): sonidos que se usan en el juego, ya sean música o efectos de sonido.

(backgounds): fondos o imágenes que sse usan como fondos para nuestras habitaciones o pantallas.


Eventos:

El sistema comprueba un monton de eventos según interactuamos con él y Gamemaker recoge unos cuantos para poder reaccionar ante ellos. Un evento puede ser pulsar una tecla, pero también sera otro soltarla y otro más mantenerla pulsada (son 3 eventos distintos). Veamos algunos eventos de GameMaker:

Create: Sucede cuando la instancia de un objeto es creada. Es decir, cuando se crea una copia del objeto. Puede usarse, por ejemplo, para preparar variables de juego que deben definirse cuando aparece un objeto o se está iniciando algo en nuestro proyecto.

Destroy: Sucede cuando la instancia es destruida. La instancia del objeto ya no existira cuando este evento sea llamado. Se puede usar, por ejemplo para actualizar puntuaciones al destruir (matar) algún enemigo.

Alarm: Cada instancia tiene 12 alarmas de reloj. Se pueden configurar estas para realizar acciones cada cierto tiempo. Por ejemplo, que un enemigo cambie su estado cada 20 segundos.

Step: Ocurre cada salto en el juego (o fotograma). Aquí se pueden poner acciones que necesites que se ejecuten constantemente. Es un evento con el que hay que tener cuidado por que si ponemos demasiadas cosas en él afectará al rendimiento y se producirán ralentizaciones. Hay 3 eventos step difetentes: begin step, end step y simplemente step, que se ejecutan al inicio del fotograma actual, durante el mismo y cuando termina.

Collision: Ocurre siempre que dos instancias chocan, o más bien cuando se superponen. En este caso dos eventos de colisión se activan, uno para cada instancia. Podemos seleccionar cual nos interesa y añadirle acciones.

Hay diferencias entre colisiones con objetos solidos y no-solidos. Cuando el otro objeto es solido, la instancia vuelve a su posición previa (la que tenía antes de que la colisión sucediera), y luego se ejecuta el evento.

Si el otro objeto no es solido, la instancia no se coloca donde estaba. El evento simplemente se ejecuta en su actual posición. Puedes moverte sobre el objeto si lo deseas y el evento solo te indica una vez que ha habido “choque”.

Keyboard: Cuando el jugador mantiene pulsada una tecla. Puedes elegir para que tecla se capturará el evento o elegir para cosas que ocurran si no se pulsa ninguna tecla, o que comprueba la pulsación de cualquier tecla. Si se pulsan varias teclas a la vez, se activan los eventos para todas las teclas pulsadas.

Mouse: Se puede activar cuando ocurren eventos de raton como que el cursor se situe sobre el sprite que represente la instancia de un objeto, que se pulse uno de los botones del ratón, o no se pulse ninguno, se mantenga pulsado, se suelte, etc.

Dentro de esta sección de eventos se incluyen también eventos para joysticks, por si tenemos conectado alguno.

Otros: Que suelen ser eventos específicos para juegos como por ejemplo

- Ourside room: Que la instancia se salga por completo del nivel actual

- Intersect boundary: Cuando la instancia sale parcialmente de los límites de la habitación.

- Views: Para el uso de vistas en las habitaciones.

- Game start: Inicio del juego.

- Game end: Termina el juego.

- Room start: Se inicia el nivel actual.

- Room end: El nivel termina.

- No more lives: Se han acabado las vidas del jugador.

- No more health: La resistencia del jugador se agotó.

- Animation end: Una animación ha finalizado su ciclo.

- End of path: Si una instancia ha seguido un camino y este ha llegado al final del mismo.

- Close button: Cuando el jugador pulsa el botón cerrar de la ventana de juego.

User defined: Tenemos 16 eventos para personalizar algo que se nos ocurra. Pero para esto hay que saber programar en el lenguaje que usa GameMaker.

Draw: Cuando una instancia es visible, dibuja su sprite cada fotograma en la pantalla. Cuando especificas acciones en el evento de dibujo, el sprite no se dibuja (no lo he comprobado, pero es lo que dice el manual) pero pueden ejecutarse acciones en su lugar. Puede usarse esto para dibujar algo en vez del sprite, o hacer algunos cambios en los parámetros del sprite. Hay un número de acciones de dibujo, pero estas solo se ejecutan si el objeto esta definido como visible. Independientemente de se si dibuja o no, los eventos de colisión se asocian al sprite asociado a la instancia.

Key Press: Suceden cuando se presiona una tecla, pero no de forma continua, es decir, solo se activan una vez aunque después mantengamos pulsado.

Key Release:
Cuando dejamos de pulsar la tecla.

Orden de ejecución de eventos en Gamemaker.

Es importante conocer el orden en el que el programa interpreta los eventos para decidir que acciones colocar en cada uno. El orden es el siguiente:

Begin step 

Alarm 
Keyboard, Key press y Key release 
Mouse 
Step 
Collision
End Step 
Draw

Ahora que ya sabeis como lo hace GameMaker, si os gusta programar o quereis aprender, podeis imaginar como hacerlo vosotros mismos de forma similar. En la programación de un juego hay que tomar distintos eventos que no son otra cosa que acciones del sistema o interacciones del usuario con el mismo o con el ordenador, ante los que hay que decidir que hacer. Solo nos falta hablar de las consecuencias a los eventos o que hacer cuando suceden, es decir, las acciones. Pero eso, por espacio, lo dejamos para la próxima.

jueves, 13 de diciembre de 2012

Código y aprendizaje

Actualmente sigo cursando el Ciclo Formativo de Desarrollo de Aplicaciones Web (voy por el segundo año) y, aunque todavia no soy buen programador, parece que con el tiempo voy mejorando en muchas cosas en las que fallaba antes o que simplemente no sabía como funcionaban. El hecho de crearme juegos muy sencillos o simplemente resolver retos de programación, me irá ayudando a conseguir el hábito que necesito de enfrentarme a la resolución de problemas, a lo que por otro lado, le estoy cogiendo el gustillo y a veces me divierte. (Y eso que nunca he sido muy amigo de esta parte del desarrollo).

En cuanto a los lenguajes, ya he probado muchos y a veces se mezclan en mi cabeza, pero en el fondo todos funcionan de un modo muy similar y basta con tener claro la sintaxis correspondiente en el momento de ponerse a escribir código.

Desde mis inicios con DIV, he escrito programas en BASIC, C, Fenix, PHP, SQL (para bases de datos, las cuales odio), Java, JavaScript (el cual estoy aprendiendo ahora y va muy bien para HTML5 y Unity 3D), ActionScript (Al que no pienso perder la pista ahora que empiezo a dominarlo un poco) y… no se, quizás me deje alguno más. La Programación Orientada a Objetos poco a poco me va quedando más clara y, algunos problemillas que tengo a la hora de planear mis programas, paso previo a enfrentarme al código definitivo, lo iré solucionando con la práctica y el tiempo.

Además, aunque no sean lenguajes de programación en el mismo sentido que los anteriores (son lenguajes de marcas), otros como HTML, CSS o XML orientados a la Web, también me van a ayudar en la parte online, tanto del desarrollo de juegos como su presentación al mundo a través de la red. Me gusta además el “efecto Matrix” que se produce cuando empiezas a tener conocimientos y la curiosidad te lleva a leer código de otras personas para tratar de entenderlo. Por fin veo como funcionan algunas cosas en mis páginas favoritas.

Por cierto, los examenes del curso son el motivo por el que he estado algunos días sin publicar.

domingo, 2 de diciembre de 2012

Concurso GameMaker: Por amor al arte

Después de la iniciativa del Blog de Toodaim, donde dos amiguetes se jugaban quien hacia el mejor juego, con una invitación del perdedor al ganador, de un bocadillo y una Coca Cola (Parece que Asensio va a merendar gratis, por que fue el ganador), la nueva idea, es un concurso abierto a todo el mundo y por eso lo pongo en mi Blog.

Si alguien quiere participar, las bases se pueden leer en el Blog de Toodaim, en el post dedicado a este concurso. ¿El premio? El honor de derrotar al resto de participantes. No hay nada de pasta, ni medallas, ni yates, ni viajes al Caribe (no seais materialistas), solo el orgullo de hacer un juego interesante con las limitaciones que imponen las normas y, sobretodo, aunque no ganemos, tener un minijuego terminado por nosotros, que eso si que es un logro para cualquiera.

Por mi parte, la participación al concurso depende del factor estudio. Intentaré hacer un juego que me pueda gustar, pero tal vez no lo acabe, dado que tengo mucho que estudiar últimamente, y volver ahora a GameMaker me supone reaprender muchas cosas que he olvidado. Si las ideas que me surgen son buenas, quizá esto se pueda convertir en un proyecto o aplicarselas a algo que ya tenga entre manos.

En fin, ahora vuelvo a PHP, JavaScript, HTML y Java que es lo que tengo que estudiar estos dias para seguir con el Curso de Desarrollo de Aplicaciones Web que estoy realizando durante este año. A ver si termino los examenes y tengo algo de tiempo libre.

Participad, disfrutad de crear un juego sencillo en poco tiempo. Aprended mucho de la experiencia, pero eso si, intentemos llevarnos bien, no vale machacar a este pobre Blogger, ni siquiera por amor al arte.


jueves, 29 de noviembre de 2012

Postmortem: Nowadays Parte 2


Ahora es cuando toca analizar los fallos y ponerse mal a uno mismo. Voy a reflexionar sobre que cosas hice mal, sin meterme mucho en que podría haber añadido (por que eso es tema de tiempo y de capacidad de implementación más que de no haberlo pensado).

Errores

Falta de documentación

Para empezar no hubo un documento de diseño. Este se suplió con un monton de papeles llenos de bocetos, ideas, trozos de código… y lo iba escribiendo sobre la marcha, por lo que no hubo una planificación y una preproducción y eso se notó en las fases avanzadas del proyecto que cada vez se ponía más cuesta arriba.

Falta de experiencia

Tanto en la parte gráfica, donde los gráficos (que no eran ninguna maravilla, visto ahora) tenían texturas mal hechas con mapeados simples del tipo esfera, cubo o plano, como en la programación, donde acabé teniendo un monton de código duplicado y mal estructurado que, a la hora de corregir errores, lo hacia bastante complicado.


Falta de coherencia

Los enemigos no mantenian algo en común entre si, y lo mismo pasaba con items, menus, y todo el arte en general. Lo ideal hubiera sido usar los colores para diferenciar los disparos enemigos de los del jugador y lo mismo para las naves. Si un item es una caja, todos deberían haber sido cajas (aunque con distintos dibujos), y si el marcador de energía del usuario era una barra, también debería haberlo sido para el enemigo de final de fase.

Perspectiva

Los fondos estan en perspectiva isométrica, pero no ocurre lo mismo con las naves, lo que le da un aspecto extraño al movimiento. Esto fue debido a que no sabía renderizar en pespectiva isometrica en mi software 3D y aprendí en una fase del proyecto en la que tocaba incorporar los fondos pero ya tenía el resto de cosas programadas con sus respectivos gráficos que no volví a renderizar.

Velocidad de juego

El juego es lento y no conseguía lo que yo pretendí desde el principio, que hubiera que esquivar un montón de disparos en cada nivel. Esto se debió sobretodo a un código caotico y poco eficiente que hacía que demasiados elementos en pantalla ralentizaran el juego, por lo que no pude incorporar toda la acción que hubiera deseado.


Copias de seguridad

Importante para no perder el juego, ya que cuando estaba terminado en un 50% aproximadamente, mi disco duro se estropeó y perdí gran parte del trabajo y sobretodo la posibilidad de terminar el juego al 100%.

Música y sonido

Nunca he sido excesivamente bueno haciendo música, pero me propuse hacer esta parte del juego, asi que esta parte, tambien se puede considerar negativa. Hice lo que pude y no lo que convenía a cada situación o escena de juego. Lo ideal es que la música y el sonido transmita lo que se esta viendo en la pantalla, pero se requiere una gran habilidad para crear distintos estilos músicales para conseguir esto.

Menu de opciones

El juego no tiene un menu de opciones que permita configurar la musica, el sonido, tamaño de pantalla o ese tipo de cosas. Habría ganado bastante con ello aunque no fuera lo más importante del mundo.


Selección de naves, pero era la misma

Aunque podíamos elegir entre distintas naves con las que jugar todas se comportaban de forma identica y tenían las mismas armas y forma de moverse, solo varíaba el gráfico que las representaba. Lo ideal habría sido que cada una hubiera tenido velocidad o peso distintos, o disparara sus armas exclusivas, lo que habría hecho el juego más interesante.

Lo positivo

Trabajar duro por mi primer proyecto, ponerle ilusión y ganas, aprender muchisimo y disfrutar jugando mi propio juego incluso años después de crearlo. Las 25000 (o 20000, no recuerdo) pesetas que me pagaron por mi trabajo, el intento de innovar usando perspectiva isométrica para un tipo de juego que normalmente se movia horizontal o verticalmente (aunque ya estaba inventado) y, por último, la incorporación de detalles como items, trucos, selección de naves, etc.

El recuerdo y la sensación de dar un gran primer paso es lo mejor de todo. Iremos mejorando.

Fin de mi primer PostMortem.

- Para descargar y jugar la Beta de Nowadays, recordamos el post: http://creadorvj.blogspot.com.es/2012/08/descarga-de-proyectos-nowadays-beta.html -
 

lunes, 26 de noviembre de 2012

Amigos y rivales

Una iniciativa del Blog de un amigo me ha traido a este tema al que le doy vueltas a menudo. Como mucha gente sabe, soy seguidor de algunos animes como Bakuman, donde se le da gran importancia a la amistad, pero también a la rivalidad. Esto me ha hecho plantearme muchas veces que me gustaría tener un rival con el que competir en esta carrera por llegar a ser creador de videojuegos, pero eso si, un rival con ilusión e iniciativa, que haga cosas constantemente para que yo piense “no puedo perder contra él” y consiga que yo mismo trabaje más. Sin embargo, por otro lado no estoy muy a favor de la cultura de la competencia que se nos enseña hoy en día, donde hay que pisar a los demás para ser el mejor y donde no todo el mundo puede triunfar, si no que para que unos pocos consigan sus metas otros muchos deben fracasar en la consecucion de las suyas. Esto me lleva a pensar en los aliados, por que tener un amigo con el que se compite pero también se colabora aporta mucho más que tener solo un rival que nos esconde sus cartas y evita que podamos aprender de él mientras trata de aprender de nosotros. He pensado muchas veces en asociarme con gente para trabajar juntos, enviarnos modelos en 3D o dibujos para que el otro corrija los fallos y opine devolviendole luego el favor con sus propios modelos. (También se puede hacer con minijuegos, juegos completos, canciones, programas, o lo que sea).

¿Cuál sería la mejor opción?

Supongo que depende de cada uno, pero en el Blog de mi amigo donde se han jugado un bocadillo y una Coca Cola por ver quien hacía el mejor juego me han dado mi respuesta. El tiempo de desarrollo disminuye y la ilusión aumentan cuando hay una competencia sana, con un colega, una competencia de la que podemos aprender, por que nadie esconde sus armas y esta dispuesto a ayudar, a apoyar y a compartir conocimientos (aunque sea despues de ganar el bocadillo y la Coca Cola). Ambos se impulsan mutuamente para llevar a cabo sus tareas. La pena que siempre he tenido sobre esto es no haber encontrado nadie de mi ciudad o muy cercano con el que emprender juntos el camino para ser desarrolladores de juegos (online no es lo mismo), o tal vez a un rival con el que competir y que haga que me rechinen los dientes cada vez que escuche su nombre o sus logros. Hay gente por aquí, pero no tiene puestos todos sus sentidos en lo mismo que yo (aunque actualmente con los estudios yo tpc puedo invertir tanto tiempo como me gustaría en juegos).


Mi consejo es este. Si teneis un rival, ayudaos de la competición que se genera y tratar de superarle, pero sobretodo de superaos a vosotros mismos. Si por el contrario teneis un aliado en vuestro camino, trabajad juntos, generad competición sana y aprended el uno del otro. Llegareis más lejos y en menos tiempo. Eso si, hay que tener en cuenta que la ilusión se desvanece con el tiempo y hay que realimentarla. Iniciativas como la del bocadillo y la Coca Cola del Blog de Todaim, pueden conseguirlo.

domingo, 25 de noviembre de 2012

Postmortem: Nowadays Parte 1

Introducción

El postmortem es el analisis de un proyecto una vez ha finalizado y ha salido a la luz, en el caso de los videojuegos, cuando ya ha podido ser jugado y visto por todos. Hay que mirar cosas positivas y negativas, donde estuvieron los fallos y de que forma podían haberse hecho las cosas mejor, pero sobretodo, el objetivo es aprender, tanto de los errores como de las cosas bien hechas y cargarse de la ilusión que se tenía al inicio del proyecto para mantenerla en el siguiente. Empiezo así mi serie de postmortem de los proyectos que hice a lo largo de mi vida y los que seguiré haciendo, para tomar nota de todo y seguir mejorando.

Nowadays

Año 1998 (Que ya hace), después de hacer unos cuantos ejemplos de código escrito en Div, me planteo llevar a buen puerto mi sueño de crear un videojuego y me pongo a programar. ¿Qué juego puedo hacer? Con lo que se hasta ahora solo puedo meterme en matamarcianos, por que no llevaría físicas, la IA de los enemigos es sencilla, y el tipo de control basado solo en moverse en todas direcciones y disparar es simple. ¿Voy a hacer un matamarcianos de toda la vida? ¡Ni pensarlo! Quiero que se vea bien gráficamente y no sea lo típico, asi que huyendo de lo horizontal o lo vertical en el desplazamiento del scroll, me quedo en un término medio, la isometrica.


Una vez tenía decicido mi primer proyecto, que plantee como juego comercial que trataría de vender a alguna distribuidora, me puse a modelar y pintar gráficos, a crear texturas, hacer la música y el sonido y a programar.

Pasos a seguir

Lo primero, tener una nave que se movía por la pantalla modelada en 3D para que pudiera verse en isométrica y fuera facil de animar. Después los menús, donde ver los créditos, jugar o salir del juego (Decidí no poner opciones).


Historia

Para la parte de la historia no me compliqué demasiado a nivel texto, fue todo improvisado, pues un juego de naves no requieré de una excusa para dar al jugador el poder de acabar con todo lo que aparezca por la pantalla pero, por otro lado, si trabajé la trama en la parte gráfica, con modelado de los personajes que serían pilotos de las naves protagonistas o enemigas, ciudades y una portada para el juego.

Diseño gráfico

Al diseño gráfico le invertí una gran parte del tiempo, creando un logotipo del proyecto y un diseño de interfaz, que elegí por eficacia. Dado que la acción se desarrollaba en perspectiva isométrica, me venía bien que la pantalla de juego fuera cuadrada, por lo que la parte sobrante sería para el HUD donde guardar mostrar al jugador las bombas que le quedaban, los puntos, su energía o la de su enemigo, junto con una foto del piloto de su nave.


Items y selección de protagonista

Quise que el jugador pudiera elegir su nave preferida entre 6 posibles, por lo que tuve que crearlas, hacer un menú para elegirlas y hacer que el juego funcionara con cada una de ellas. Por otro lado, los items, empezaron siendo bastantes, pero el tiempo de desarrollo los fue reduciendo. Aunque tenía muchas ideas que iba apuntando en un papel que tenía en un tablón de corcho, había demasiadas cosas que implementar en el juego y poco tiempo, experiencia y habilidad para llevarlas a cabo.

Enemigos

Algo curioso que ocurrio con este tema fue que los enemigos, en principio, iban a ser protagonistas. La elección que hice de un gráfico para un proposito u otro acabo siendo por cuestiones de gustos personales. Las naves que me parecían más interesantes acabaron siendo controladas por el usuario y las que me gustaban menos se convirtieron en los enemigos.



Armas

Quería lasers brillanes, fuegos que iluminaran, bolas de energía con destellos y misiles que provocaran explosiones gigantescas para limpiar la pantalla, pero sobretodo quería escudos de energía y disparos múltiples para que hubiese muchas “balas” moviendose por toda la zona de juego y hubiera que esquivar bastante.

Escenarios

Los escenarios consistian en gigantescas imágenes que se moverían en el eje x y también en el eje y gracias al scroll. No había varios planos, sino solo uno, y la decisión de que tipo de fondos había en cada fase los decidí escribiendo en un papel las ideas que me surgieron, ya que al principio solo tenía claro que el primer nivel sería una ciudad en ruinas y el último un superordenador que representaba la inteligencia artificial que había desencadenado la historia.

Código fuente

El código fuente iba creciendo cada día y haciendose más complicado de manejar, por lo que desde el principio trate de que no hubiera errores en la parte que tenía antes de avanzar a la siguiente. Así, intentaba no arrastrar fallos de un fragmento del juego a otro. En caso de no saber resolver un problema de código con lo que sabía de programación en Div, trataba de hacerlo de otro modo que si conociera, aunque fuera menos eficiente. Desde el menu, el movimiento de la nave, el comportamiento de los enemigos, los trucos… Todo salió de ejemplos de los que había aprendido antes o de ideas felices, aunque caoticas en muchas ocasiones.

Manuales y trucos

Mi sueño se estaba cumpliendo poco a poco, y empezaba a tener mi gran proyecto como algo jugable, asi que tenía impaciencia por verlo metido en una caja y con su manual, como los juegos que se vendían en las tiendas. Me puse a trabajar en ello, haciendo uso de lo que sabía de programas de retoque o maquetación. Además realicé un manual de instrucciones en formato de página web, pensando después en los trucos, los cuales surgieron como idea tras leer en una revista que, para presentar juegos a distribuidoras, muchos desarrolladores añadian trucos para poder saltar rápido de nivel o enseñar todos los items funcionando y que la persona que les iba a dar la pasta pudiera verlo todo en poco tiempo.

Dado que no hacía nunca copias de seguridad, al final, cuando tenía un 50% del juego aproximadamente, mi disco duro murió y no pude recuperar nada de lo que había en él, lo que me lleva a hablar de los errores del proyecto.

Fin de la primera parte, pronto la segunda.

- Para jugar a la Beta de Nowadays, recordamos el post: http://creadorvj.blogspot.com.es/2012/08/descarga-de-proyectos-nowadays-beta.html -

miércoles, 21 de noviembre de 2012

Diseño de juegos - Generos: Plataformas

El personaje de un juego de plataformas, como su propio nombre indica, suele correr y saltar de plataforma en plataforma de manera que se enfrenta a unos enemigos y avanza hacia su objetivo final.

Este tipo de juegos se fueron complicando cada vez más, de modo que, además de correr y saltar, actualmente también se camina, se escala, se superan obstáculos cada vez más variados…

Generalmente a los plataformas se les suele añadir un gameplay extra que haga más variadas las acciones y que, de paso, les permita diferenciarse de la competencia. Por ejemplo, suele ser clásica la búsqueda de items ocultos o la necesidad de recoger un número concreto de ellos repartidos por todo el nivel para poder seguir avanzando. Y es que además, este género utiliza mucho el concepto de nivel tal y como lo hemos conocido siempre, es decir, superar uno para avanzar hasta el siguiente, en ocasiones con posibilidad de elegir entre varias opciones para que no se haga excesivamente lineal.


Los enemigos de final de fase también son muy comunes en este tipo de juegos. En ellos se nos plantea un reto que superar usando los recursos y acciones obtenidas y aprendidas durante el resto de la partida. Si al principio aprendimos un salto especial para matar a cierto tipo de enemigos, suele ser comun que haya que usarlo de alguna forma u otra para superar al boss de final de fase. Una vez superado este, se suele recomendar premiar al jugador y, si la intensidad ha subido demasiado, calmarla con un nivel sencillo y tranquilo bajo el agua o similar.


¿Cómo podemos premiar al jugador? Una tienda o una fase de bonus donde conseguir vidas extra o items suele ser habitual. Lo que nos lleva a otra cosa típica: El jugador suele fallar habitualmente durante su aventura y matar a su personaje en muchas ocasiones, por lo que es común proporcionarle varias vidas o una cantidad de energía disponible que le ayude a cumplir los objetivos del prota, cuya historia, puede ser muy variable, pero casi siempre sucede en mundos de fantasía alejados de la realidad que conocemos.

Otra cosa a destacar de este género es que a día de hoy se puede diferenciar entre plataformas 2D, cuyo avance es lateral y se nos permite movernos solo arriba o abajo (eje x o eje y); plataformas 3D, donde nos movemos en 3 dimensiones y en los cuales el avance es hacia la profundidad de la pantalla; y los plataformas 2.5D, donde se mezclan los dos anteriores, permitiéndonos movimientos limitados, normalmente a dos dimensiones, pero en una vista tridimensional.



Ejemplos de juegos de plataformas son los clásicos juegos de Super Mario, Sonic, o, por nombrar uno actual y que me encanta, Mutant Mudds.

sábado, 17 de noviembre de 2012

Diseño de juegos: El Prototipo

Si se me ocurre una idea para el gameplay de un juego mega-revolucionaria, o simplemente voy a usar un género de los de toda la vida, pero voy a añadirle alguna cosilla de cosecha propia, o a probar una nueva historia ¿Cómo puedo saber si el juego funcionará y será divertido? ¡Pues desarrollandolo! Pero claro, si vamos a estar meses e incluso años dedicando tiempo a un juego que luego nos parezca aburrido y no nos guste, no parece una buena idea . ¿Cuál es la solución? Hacer un prototipo.

Un prototipo de juego necesita menos tiempo y recursos, pero trata de ser todo lo funcional que podría ser el proyecto final o al menos partes concretas del mismo, de las que queramos probar el gameplay. Para hacer esto no hacen falta grafistas, podemos usar cuadrados de colores que representen a los personajes o si va a ser en 3D, texturas y objetos de sustitución. Tampoco hacen falta sonidos o músicas, podemos prescindir de ellos o usar cualquiera que bajemos de la red. En muchos casos ni siquiera necesitaremos programar si podemos hacer el prototipo de forma visual, con formas animadas y obtener de ello una idea de cómo va a funcionar (aunque es mejor si lo programamos).


Una vez tenemos nuestro prototipo listo para ser jugado y/o visualizado, nos podemos echar unas partiditas para comprobar su buen funcionamiento, ajustar variables de juego para hacerlo más facil, dificil y mejorar cosas, plantear como solucionar futuros problemas en la programación o el diseño, y aprovechar para corregir en la documentación errores de diseño que nos vayamos encontrando. Con todo, seremos capaces de elaborar un buen documento de diseño y de planear todo el proceso de producción. Así, no solo comprobamos que estamos haciendo un juego con el que podemos quedar relativamente contentos (un desarrollador nunca esta contento al 100% con su juego, igual que a un músico nunca le gustan el 100% de las canciones de su disco), sino que también aceleraremos después el desarrollo y afrontaremos problemas con la solución practicamente pensada. Aunque parezca mentira, esto puede acelerar el trabajo y darnos mejores resultados en el proyecto final.

Para ver de lo que hablo dejo un mini-prototipo de lo que podrían ser un proyecto para un juego de preguntas y respuestas sobre juegos. A ver si las acertais todas :P

jueves, 15 de noviembre de 2012

Aumentando el realismo: Envejecer texturas

Ya he comentado en varias entradas del Blog que, para aumentar el realismo de nuestras escenas, objetos o personajes, un buen modo de hacerlo es envejecer las texturas. Esto es así por que todo lo que nos rodea esta manchado, arañado, roto o sucio. Que ahora dira alguien: “no, por que acabo de pasar la aspiradora, ya no hay pelusas debajo de la cama” ¡pues mañana miras otra vez y veras!

Los objetos nuevos, pulidos y brillantes duran muy poco y lo mismo ocurre con lo que acabamos de limpiar con todo nuestro empeño y, puesto queremos reflejar una realidad (que no tiene por que ser la nuestra) en nuestro videojuego, tenemos que tener en cuenta esto cuando hacemos texturas, e incluso a veces es mejor pasarnos que quedarnos cortos.

La historia de las cosas

Una buena forma de envejecer texturas es pensar en la historia de las cosas, por que aunque situemos al jugador en una escena, se supone que ese mundo virtual antes de llegar a ese punto en el tiempo, lleva existiendo años. Han pasado muchas cosas antes de llegar al día donde comenzamos a contar nuestra historia, por esto, nos interesa pensar en ese coche que ya hace 10 años que el protagonista compró y necesita ruedas nuevas y una mano de pintura, en esa televisión a la que hace días que nadie le pasa un plumero, tiene la pantalla arañada y le faltan tres botones, o en los pantalones que lleva nuestro personaje y que estan un poco gastados, rotos y con alguna mancha de café que no hay forma de quitar, por que una vez se le derramó encima estando en la oficina.



Combinar texturas

Una forma rápida de conseguir envejecer texturas consiste en tener en nuestro catálogo texturas de arañazos, grietas, manchas o roturas. Gracias a ellas podremos ajustarles un poco el color y combinarlas con la textura original gracias a la opacidad o los modos de capa que tienen practicamente todos los programas de retoque fotográfico del mercado (incluso muchos gratuitos). A veces, es mejor que estas imágenes estén en escala de grises para poder sacar de ellas mapas de normales o que la combinación sea más realista y facil de conseguir.





Pintar el paso del tiempo

Aunque lo más rápido sea la combinación, si estamos pintando materiales por que nuestro juego es de tipo cartoon o necesitamos añadir más suciedad y defectos por que aun no tenemos suficientes, a veces habrá que pintar a mano las manchas, quemaduras, pegatinas medio borradas o todo aquello que necesitemos. Para esta parte suele ser bueno borrar algunas partes (en caso de las pegatinas o imágenes), desenfocar otras y suavizar la intensidad de las capas que pintemos. Hay que pensar en que zonas tenemos que marcar las imperfecciones. Por ejemplo la pintura suele levantarse en los bordes y esquinas y la ropa se rompe mucho más por donde tiene costuras.

Observad en algunas de las imágenes que adjunto como una textura envejecida aumenta en realismo y si aun teneis dudas, también esta el ejemplo de la nave de carreras. Claramente mejora bastante si añadimos las suficientes quemaduras, manchas y rascaduras para que parezca que lleva ya unas cuantas competiciones a sus “espaldas”.

sábado, 10 de noviembre de 2012

Webs recomendadas: Eresgamer.com

Me gusta mucho la iniciativa de los responsables de este sitio, que se han unido para recopilar información sobre tutoriales para el desarrollo de videojuegos y, han organizado un curso de Unity 3D a base de videotutoriales y cuestionarios. Yo mismo había pesado hacer tutoriales de Unity, pero el manejo del mismo me parecía demasiado sencillo y quería centrarme más en la parte de la programación de scripts. Ahora, el manejo de la interfaz del motor parece que quedará cubierta con los tutoriales de esta Web que recomiendo hoy.

Cosas buenas y malas

Una parte que no me gusta de Eresgamer es que no aconsejan empezar desde abajo ni recomiendan a los que empiezan en esto no meterse en proyectos demasiado grades. Al contrario, parece que se sigue fomentando el ansia de muchos novatos de hacer la competencia a empresas grandes con cientos de trabajadores creando un nuevo World of Warcraft, Crysis 3, etc. En lugar de esto quizás se debería recomendar a la gente empezar con pequeños trabajos para aprender y guardarse sus obras maestras para cuando reunan la capacidad, conocimientos y medios para poder llevarlas a buen puerto.

Por otro lado, aunque los videotutoriales de Unity, que ya han empezado a publicar, son algo improvisados, también son útiles y se puede aprender de ellos. Parecen ser una prometedora forma de introducirse en el motor y aprender a hacer nuestros primeros juegos en el futuro, así que habrá que seguirlos.

También, este sitio Web, puede nacer un punto de encuentro para desarrolladores, donde encontrar colaboradores, socios y consejos. Aunque recordemos que, para eso, en España ya tenemos stratos-ad.com, la cual es dificil de superar en este aspecto.

domingo, 28 de octubre de 2012

Cosas que debería saber un diseñador de videojuegos

¿Debería saber dibujar?

Si y no, es decir, no necesita saber dibujar, incluso no pasaría nada si no tuviera ni idea de hacer un simple garabato, pero si necesita saber expresarse. El miedo al papel (o la pantalla) en blanco es un enemigo muy grande para un diseñador de videojuegos y debe superarlo cuanto antes. Debe saber explicar sus ideas y hacer que los demás las comprendan, por que no sirve de nada idear el gameplay más innovador del mundo si no puedes hacer que el equipo que te va a ayudar a desarrollarlo comprenda en que consiste.

Si eres el peor dibujante del mundo, asegurate de tener siempre cerca a alguien que pueda dibujar tus ideas o, al menos, de aprender a usar el google para encontrar imágenes que te sirvan de apoyo a la hora de mostrar tus ideas al resto de colaboradores.




¿Debería saber programar?

Después de un tiempo observando como funciona esto del desarrollo de juegos he llegado a la conclusión de que, aunque a lo mejor no es imprescindible que un diseñador de juegos sepa programar, si que ayuda mucho a ser mejor diseñador. El hecho de que una persona conozca los límites de su equipo hace que pueda plantear cosas posibles en tiempos razonables. Por otro lado el saber programar o al menos manejar algún tipo de motor que te permita hacer algo sin picar código, ayuda a la hora de realizar un prototipo y comprobar que la jugabilidad que ha pensado el diseñador puede ser divertida y beneficiosa para el usuario.

¿Debería saber 3d?

Bajo mi punto de vista no es necesario, pero si util. Si diseñamos niveles o algún tipo de esquema que ilustré las ideas del gameplay que se nos ha ocurrido para un juego 3D, a veces el poder realizarlo en las mismas dimensiones en que se desarrollará dicho juego nos va a facilitar mucho las cosas. Modelando cajas, cilindros y sabiendo como movernos por un entorno 3D seremos capaces de enseñar a nuestro equipo que en la habitación del fondo hay un secreto al que se accede de tal forma y que en la de encima, si rompemos la pared con el puzzle que se nos ha ocurrido, se continua la aventura.



¿Debería saber escribir?

¡Esto es esencial! Escribir historias, describir situaciones, documentar, anotar ideas, transmitir las de otros compañeros del équipo… Hay que saber crear documentos de diseño y expresarse lo suficientemente bien sobre el papel para que nuestras creaciones no se olviden y sean comprendidas por todos. Además, en este caso también viene bien un poquito de inglés, sobretodo leido y escrito, por si nuestra empresa o grupo es un poco internacional.

¿Debería saber hacer Música?

En este caso mi opinión es que no es necesario. Quizá es bueno tener claro que tipo de música o sonido aproximado se quiere para cada situación y orientar a los profesionales para que hagan aquello que puede irle bien a nuestra idea, pero… vamos a dejar a los que saben que hagan su trabajo, que seguro que tienen mejor oido y más experiencia.

¿Debería saber diseñar niveles?

Siempre se ha dicho que aprender a diseñar niveles era un buen modo de convertirse con el tiempo en diseñador de juegos por lo que es evidente que hay que saber de ello. Aunque haya un rol especifico para esto, cuando se piensa en un gameplay, en una historia, estilo gráfico y demás, se tendrá algunas ideas sobre que tipo de enemigos, en que número y en que lugar pueden aparecer. Luego el diseñador de niveles (si lo hay) se puede encargar de mejorar eso más detalladamente.

¿Debería saber diseñar interfaces?

También hay un rol para esto, pero no en todos los proyectos y, cuando se piensa en la idea para un videojuego, también conviene darle vueltas a como vamos a presentarle la información al usuario y facilitarle las acciones que tenga que realizar.

¿Debería saber escribir un guión?

Un diseñador que sabe pensar buenas historias diseña mucho mejor, ya que en muchas ocasiones, es la propia trama la que te indica que tipo de gameplay le va bien. Quizás no hace falta conocer todas las técnicas o tener la habilidad escribiendo de un novelista de éxito, pero ya que hemos dicho antes que hay que saber escribir, vamos a añadirle que hay que saber QUE escribir.

¿Y qué más?

Curvas de dificultad, añadidos que puedan alargar la vida del juego, equilibrar… pero sobretodo ¡jugar y analizar! Por que un diseñador de juegos es alguien que disfruta jugando y analizando cada detalle para idear cosas que sorprendan al usuario, el mismo debe pensar como un usuario más. Vamos a hacer juegos divertidos, atractivos, interesantes y sorprendentes, por que eso es lo que cualquiera de nosotros/a reclamaría como jugador/a.

martes, 23 de octubre de 2012

Juegos que me influyeron como desarrollador: Day Of The Tentacle

Volvemos de nuevo al pasado, a aquella maravillosa época en que las aventuras gráficas empezaban a manternos horas y horas delante de la pantalla pensando en como resolver los puzzles que nos planteaban. La segunda parte de Maniac Mansion llegó a mis manos y, después de pensar en lo horrible que me resultó la primera, me dispuse a probarla quedando gratamente sorprendido. Tres personajes con los que jugar en distintas épocas gracias a una máquina del tiempo (que a mi me gustan bastante), personajes geniales como el tentáculo púrpura que quería dominar el mundo y de nuevo el sistema SCUMM para controlar nuestras acciones a traves de verbos como “ir a” o “coger”.


Este juego tenía puzzles geniales, y fue entonces cuando empecé a plantearme como se diseñaba un proyecto como aquel y, otra cosa que no me habia planeado antes, como crear una interfaz para un videojuego.

Como no soy la única persona a la que este juego ha influido, también me encontré un pequeño homenaje al mismo en Pangea (la aparición de Bernard, el protagonista de Day of the Tentacle), que tuve oportunidad de testear “trabajando” para su creador Leandro José García. (Por cierto que en el juego también aparece Larry).



Después de Maniac Mansion 2 y también de los dos primeros Monkey Island, mi afición por las aventuras gráficas me llevo a escribir historias y diseñar puzzles para decenas de ellas, todas de temática humoristica. Así fue como en más de una ocasión traté de participar en proyectos de este tipo, los cuales debido a la enorme carga de trabajo artístico y de animación que conllevan, siempre se quedaban a medias.

Algún día, tal vez si reuno un buen équipo de personas en el que pueda confiar. :P

Por cierto, os cuento un poco de que va Day of the Tentacle:

Comienza un tiempo después de los eventos transcurridos en Maniac Mansion. Bernard, el típico tipo con gafas, regresa, pero en esta ocasion acompañado de sus amigos Hoagie y Laverne.

Una de las dos creaciones del Dr. Fred Edison, el Tentáculo Púrpura, toma un residuo radioactivo del exterior de la Mansión, que hace que le crezcan brazos y sea dominado por el deseo de conquistar el mundo. Bernard y sus amigos planean volver atrás en el tiempo, usando el invento de las Cron-O-Letrinas del Dr. Fred, para detener al Tentáculo Púrpura y evitar el incidente del tentaculo con los residuos.

Para el uso de la maquina del tiempo recurren a un diamante de imitación provocando que falle y transporte a Hoagie doscientos años al pasado y a Laverne doscientos años al futuro (un futuro dominado por tentáculos, por cierto). Bernard, sin embargo, se queda en el presente y, con la ayuda del tentáculo verde, debe encontrar un diamante para hacer que la máquina del tiempo funcione de nuevo, y Hoagie y Laverne puedan volver a sus Cron-O-Letrinas, conectarlas a una fuente de energía, y regresar para vencer al tentáculo púrpura.










sábado, 20 de octubre de 2012

Creando entornos


Me temo que no voy a dar un curso de modelado de entornos 3D, ya que sería muy largo y necesitaría años de tutoriales en el Blog (y tiempo para hacerlos), pero para no dejar totalmente de lado el lado “poligonal” de mi página, hoy he decidido repasar algunas ideas a tener en cuenta a la hora de traer a la vida escenarios para videojuegos. Ya sabeis, a la gente le resulta muy atractivo crear el protagonista de la historia, pero si no tiene un mundo por el que moverse no sirve de nada su existencia, por lo que se necesitan modeladores de entornos o creadores de texturas para los mismos y, aunque no lo creamos, es una tarea dificil y larga pero con resultados muy agradecidos. ¡Sentios orgullosos de vuestra creación final!

Medidas:

Es importante tener en cuenta tamaños y medidas a la hora de crear ciudades, paisajes o lo que sea, pero no hay que confiar del todo en la realidad. A veces, las puertas necesitan un tamaño más grande para que puedan pasar decentemente las cámaras o el personaje con su arma de tamaño “vamosadarlesunsustocuandonosveanaparecerconesto”. Los edificios, igualmente podriamos tener que modelarlos en un tamaño reducido (aunque puede exagerarse el tamaño de la escena usando después trucos de cámara) y luego dedicarnos a la parte interior de los mismos con mucho más detalle y extensión, ya que podría cargarse esta como una escena distinta.


Para saber que medidas tomar se recomienda la elaboración de prototipos, sobretodo si vamos a trabajar con “piezas” o tiles, es decir, haciendo nuestro escenario por trozos, para que un diseñador de niveles los junte a su gusto.

Props:

Hablamos de elementos como puede ser una señal de tráfico, un semáforo, una piedra, una planta… Esos objetos pequeños que forman parte de nuestro entorno y le dan vida. Necesitamos muchos para hacer todo más realista, pero es evidente que hay que tener en cuenta los polígonos que consumen y no hacerlos muy repetitivos. Si necesitamos 100 arboles no vale con hacer uno y copiarlo 100 veces, vamos a darles ciertas variaciones y en vez de eso, copiemos 5 distintos veinte veces para que el truco pase más desapercibido.


Iluminación y texturas:

¡Muy importante las dos cosas! Nuestro entorno en muchas ocasiones tendrá que ser sencillo y los edificios van a ser simples cajas para que podamos usar esos recursos en otras cosas necesarias para el proyecto. Vamos a recurrir, por lo tanto, a las texturas y luces para darle un acabado mucho más realista a ese monton de polígonos planos.


Simplificar lo que el usuario no ve:

Si pensamos en un juego en el que nos movemos por una ciudad y, en el que no se pueden usar helicopteros ni subir a la parte alta de los edificios, a la hora de modelar, vamos a centrarnos en dar detalle a la parte inferior de las calles de la ciudad. La parte superior de los edificios tendrá poco trabajo para poner todo lo interesante en lo que el usuario va a ver de cerca. Esto es un truco muy usado en los juegos actuales donde se nos presenta una escena aparentemente enorme y muy realista que en realidad esconde en la distancia el vacío más absoluto tapado por algun plano con textura o formás muy básicas con escasos polígonos. (Esos juegos lineales de pasillo fijo que hay ahora, cuanto truquillo tienen).



Ensuciar y destruir:

Mirad a vuestro alrededor un momento y fijaos en que, por muy limpios, ordenados o cuidadosos que podais ser con vuestras cosas, el uso hace que aparezcan arañazos, manchas, algun fragmento que se ha roto, etc. Eso se hace aun más evidente si se mira en la calle. Esas manchas de aceite en el asfalto, ladrillos o ventanas rotas, etc. Bien, pues deberíamos seguir esta norma a la hora de modelar un entorno. Lo nuevo dura poco por lo que un elemento pulido y limpio, que refleja que acaba de salir de la fabrica donde lo hicieron no nos parece realista, mucho menos si aparece en un mundo en el que, aunque el usuario va a entrar en ese momento, tiene que dar la sensación de que lleva existiendo años y que en él han ocurrido ya muchas cosas.

Y por último se me olvidaba. Hay que eliminar los polígonos que nunca se van a ver. Por ejemplo el suelo de una casa en la que no se va a poder entrar.




martes, 16 de octubre de 2012

HTML5 vs Flash


Justo ahora que me estaba poniendo las pilas con ActionScript, la gente me empieza a decir que hay que renovarse y pasarse a HTML5, que es la leche y que va a mandar la tecnología Flash al olvido más absoluto. (Y la verdad que ya hace tiempo que había oido eso, pero no me lo tomé muy en serio).

El caso es que, para convencerme, tuve que mirarme un poco de HTML5 y comparar observando un poco de código y de todo eso tan mágico que había detrás del proximo HTML, que realmente aun no está en su versión definitiva.

HTML5 se sirve de una nueva etiqueta, el canvas, para usar la tecnología JavaScript y, gracias a ella, hacer cosas bastante parecidas a las que se hacían con Flash, pero con la ventaja de que no necesitamos instalar ningún plug-in (Nuestros navegadores suelen venir con un interprete Javascript). En este sentido, el no necesitar descargar ningún software extra (ni actualizarlo, que Flash Player se pone un poco pesado) es la razón definitiva por la cual anticipan la derrota de Adobe ante la nueva tecnología para la Web que esta por venir.

Asi que ya veis, muy bonito todo, pero mi investigación debería centrarse en si va a darnos ventaja a los creadores de juegos, y para ello me fui a la Web "adictos al trabajo" y miré este artículo.

Os hago un resumen de lo que, por otro lado ya he comprobado:

Flash recopila todo en un solo archivo (a veces pone alguno más para fuentes, sonidos, etc.) mientras que HTML5 necesita además los archivos .js de JavaScript. Además parece que el 3D poligonal, solo existe medio decente hasta ahora en Flash (Aunque no me pregunteis como se hace) y, por último, otra cosa a la que le doy mucha importancia es que si tenemos una Web y le damos al boton derecho del ratón, encontraremos una opción para ver el código fuente, mientras que si creamos nuestro juego con Flash+ActionScript hay que currarselo un poco más para desencriptar el fichero .swf.

¿Quiere todo esto decir que soy pro-Flash?

De todos modos, por estudios, tengo que aprender lo nuevo de HTML, así que al final acabaré sabiendo las dos cosas y, seguramente, haciendo juegos para las dos propuestas (Aunque solo por pensarme si dejar ActionScript he perdido tiempo con proyectos). El caso es que algunas de las cosas por las que la tecnología de Adobe echaba para atrás a muchos desarrolladores (Que era de pago), quedaron solucionadas gracias a Flex y a algunas librerías para el desarrollo de juegos, asi que quedan pocas cosas en las que HTML5 se lleva el gato al agua en cuanto a videojuegos se refiere.

No se, tendré que investigar un poco más y ver que posibilidades tiene toda esta historia. De momento, gracias a la página de desarrolloweb ya voy aprendiendo un poco el funcionamiento del Canvas+JavaScript.

(No, la imagen no da fallo, era un monton de código para hacer que salieran cuadraditos con colores aleatorios en el navegador).


sábado, 13 de octubre de 2012

Descarga de proyectos: Pixfrogger para Android


El proyecto que hicimos hace años en Pixjuegos ha seguido adelante gracias al amigo Pablo Navarro (Pixel), que ha usado los gráficos que realicé para el original, para lanzar una versión Android.

Esta es la primera vez que vivo algo como esto, es decir, que un juego desarrollado hace tiempo siga existiendo y expandiendose sin la necesidad de que yo haga practicamente nada. ¡Es como si se hubiera independizado! ¡Se ha ido de casa y vuela libre!

Bueno, la verdad es que este fue un minijuego muy sencillo (aunque adictivo) con el que no vamos a ganar ni para comer, pero es interesante ver que siguen adelante los antigüos grupos de desarrollo en los que trabajé y les va bien (y sobretodo que siguen trabajando y teniendo ilusión).

Me gustaría dar mi impresión sobre el resultado final de Pixfrogger, pero como no tengo Smartphone por que soy pobre, no he podido probarlo y solo puedo hacerme una ligera idea de en que ha quedado la conversión de la versión para PC por los videos e imágenes que circulan por la red y que, nisiquiera se si son de la versión definitiva.

Quien lo pruebe si quiere contarme… :P

Se puede descargar desde Google Play o en Amazon y en versión gratuita o con donación.





lunes, 8 de octubre de 2012

Diseño de Videojuegos: Azar vs Habilidad del jugador


Las funciones de tipo random se usan mucho en la programación de videojuegos (es decir, el azar) y cuando se usan de manera que tienen poco en cuenta al jugador, a personas como a mi, que nos gusta confiar en nuestra habilidad a los mandos, nos resulta verdaderamente frustrante. Hablo de esos juegos donde inviertes horas en matar a un monstruo que necesitas para obtener un item que necesitas, y después, el conseguirlo o no, depende solo de la suerte de que te salga ese item y no otro. En caso de que la suerte no te acompañe, vuelve a hacer la misma operación de exterminio de bicho gigante una y otra vez hasta que te den el item que estabas buscando.

Este es un ejemplo de un juego que seguro que muchos conoceis, pero el azar esta presente en otros muchos de una manera que no permite al jugador confiar en su manejo, si no que le obliga a intentar las mismas acciones una y otra vez hasta que la combinación sea la que necesita.

Vamos a ver un caso sencillo y conocido, la programación de un juego de tragaperras. Imaginemos la funcion random que hay detrás, en el código, que hará que cada vez que bajemos la palanquita, las figuras empiecen a pasar y salgan tres al azar. Si el jugador se convierte en un experto tal vez pueda desarrollar alguna estrategía que le de alguna posibilidad de ganar, pero en principio ninguna de las habilidades que tenga o que adquiera jugando le garantiza la victoria.

Por otro lado tenemos juegos en los que cuanto más jugamos más experiencia y habilidades podemos conseguir, lo que nos da mayor posibilidad de derrotar a nuestros enemigos. El ejemplo más claro de esto podría ser un RPG en el que obtenemos experiencia, subimos de nivel y obtenemos nuevas armaduras o armas con las que somos más fuertes, rápidos, etc.

Como jugadores esta claro que cualquiera prefiere evitar eso de “coleccionar cromos” y tener que estar probando y probando hasta que te salga ese cromo que deseas, por eso como desarrolladores no es muy recomendable recurrir a un azar de este tipo, aunque sea lo más sencillo en muchos casos. El hecho es que los randoms actuan en muchas ocasiones en combinación con otros eventos para crear el mundo de juego y deberíamos controlar que no interrumpan la experiencia del usuario. Pongo un ejemplo de lo que quiero decir:

Imaginemos un matamarcianos en el que cada vez que acabamos con un tipo de enemigo aparece un power-up de un tipo que el programa elige al azar. Podemos tener un control de las habilidades del jugador (puntuación, daño recibido, vidas perdidas, ect) para inclinar la balanza hacia ponerle las cosas más dificiles o más sencillas dependiendo de lo experto que este usuario sea. Si se trata de un jugador que necesita retos, demosle un simple item que suba un poco su puntuación aunque no le quede demasiada vida. Si es alguien que ha perdido casi todas sus vidas en un momento podemos hacer el random solo entre items de vida extra o aumento de energía para que pueda jugar más tiempo y mejore su manejo del mando.

Cuando desarrollemos nuestros juegos seguramente usemos mucho la aletoriedad para colocar objetos, poner enemigos en pantalla, proporcionar items, lanzar preguntas al jugador… ¡Mil cosas! Pero aconsejo que se condicione esa aletoriedad y no se use para obligar a que las personas tengan que probar y probar siempre lo mismo hasta conseguir sus objetivos. Dejemos que aquel que echa horas en nuestro proyecto y consigue dominarlo pueda demostrar que va a ganar por que ha entrenado para merecerlo. :P


martes, 2 de octubre de 2012

Técnicas de guión aplicadas a videojuegos: El Falso Fracaso del Heroe


No se exactamente cual es el nombre “oficial” de esta técnica, por eso la he llamado de este modo. El caso es que esto lo vais a ver mucho en los comics y series de animación japonesas.

Nos encontramos con un personaje que tiene muy buena fama sobre su fuerza, rapidez o lo que sea. Sin embargo, cuando llega la hora de demostrar sus habilidades es derrotado o se ve en una situación en la que parece que no puede hacer nada. ¿Nuestro heroe ha tenido fracasado? ¡No puede ser! De pronto, con toda la naturalidad del mundo, da a entender que todo era algún tipo de juego y es ahora cuando se va a tomar las cosas en serio. Despues de casi habernos decepcionado, el protagonista es justo lo que se esperaba de él y acaba ganando.

Para que entendamos mejor a lo que me refiero podeis ver muchos ejemplos de esto en la serie Dragon Ball del maestro Akira Toriyama. Muchas veces, Goku se presenta como un guerrero rapidisimo y muy agil, pero pronto su rival le supera y parece perdido. De pronto, nuestro querido heroe tira su muñequeras, tobilleras y la parte superior del traje al suelo y podemos comprobar que la ropa esta diseñada para pesar mucho y que, al llevarla todo el día, permite entrenar a Goku. La batalla vuelve a empezar y se demuestra que el prota era lo que esperabamos, rápido y agil. Se le ha dado la vuelta a la trama y ahora si que parece que pueda ganar al rival.

¿Cómo lo aplicamos a videojuegos?

¿Y si nuestro protagonista dispusiera de unas habilidades increibles y pudieramos contarselo al jugador desde el principio? Dejemos que espere mucho del personaje que está apunto de controlar. Sin embargo, a la hora de tomar los mandos, algo hace que se vea un poco limitado en sus poderes (Hay que tener cuidado de no frustrar mucho al jugador). Cuando parezca que derrotar al enemigo es imposible, demosle todo el poder al usuario que le habiamos prometido desde el principio. Es el momento de que la barra de vida se llene y todo empiece de cero. Ahora si puede ganar. Antes solo estaba bromeando.

La dificultad como siempre es encontrar una historia que nos de buenos motivos para que suceda esto durante el juego. Normalmente todo esto funciona con un personaje un poco chulo o que ve con ingenua naturalidad el ser extraordinario.