1 de diciembre de 2015

Historia de los videojuegos (4/10)

Segunda generación de consolas (1976-1984)

Esta generación (también conocida como la era de los 8 bits) se inicia a finales de los años 70. Durante la primera parte, se vio el lanzamiento de varias consolas, ya que muchas empresas decidieron entrar al mercado. En la parte final de la generación, algunas consolas fueron lanzadas como respuesta directa a las consolas anteriores.
La consola dominante de la generación fue el Atari 2600, en 1976. Alcanzando un gran éxito, la originalmente llamada Atari VCS, hizo que la marca Atari fuera sinónimo de videojuegos durante la primera mitad de la década de los 80. El dominio de Atari que venía desde la anterior generación. Como competencia surgió Coleco, con su ColecoVision, el cual tiene el doble de colores. Y por parte de Mattel, el Intellivision que llevaba el primer procesador de 16 bits de la historia de las consolas. Era con diferencia lo más realistas en gráficos y sobre todo sonido que se podía conseguir en las computadoras caseras.
No mucho tiempo después sale al mercado Atari 5200, intentando no quedarse rezagada ante Coleco y Mattel, pero la crisis de los videojuegos de principios de los 80 y la llegada de los microordenadores a las casas, hundió las ventas de todos los sistemas, con la única salvedad de Atari 2600 que siguió teniendo cierta demanda hasta la década de 1990.
Otras videoconsolas aparecieron también en esta generación, tales como: Odyssey 2 de Magnavox, TV-Game 6 de Nintendo, y la SG-1000 de Sega. Estas no fueron muy populares en aquel entonces, el éxito lo tenía Atari. Aunque tiempo después, estas 2 últimas (TV-Game 6 y SG-1000) tendrían un gran éxito con la llegada de la tercera y cuarta generación.

1 de noviembre de 2015

Historia de los videojuegos (3/10)

Primera generación de consolas (1972-1977)

La primera consola de videojuegos fue la Magnavox Odyssey, de la mano de Ralph Baer basándose en su anterior prototipo Brown Box y su patente de concepto de videojuego. Tenía 2 mandos, un mando en forma de arma de fuego y 16 interruptores en la consola que permitían seleccionar distintos juegos. Fue construida usando una combinación de circuito analógico (para el control del juego y la salida) y digitales. No contenía ninguna unidad central de procesamiento o memoria de acceso aleatorio. La máquina se componía de transistores, resistencias y condensadores. Dado su reducido hardware, carecían de sonido y los jugadores debían memorizar sus puntuaciones. En ocasiones eran necesarios algunos dispositivos adicionales para poder ejecutar determinados videojuegos de la plataforma. Sus juegos (28 títulos diferentes en total) eran de una sencillez extrema: ping-pong, “tenis de mesa”, voleibol, etc.
Sin embargo, no fue un gran éxito debido a que fue vendida solamente en los almacenes de Magnavox, diciendo además a los clientes que la Odyssey trabajaría solamente en televisores de su marca. Una mentira que contribuyó a la cantidad de unidades vendidas. Aún así, la Odyssey generó un caso severo de la “locura de Pong”, y compañías por todo el mundo comenzaron a desarrollar sus propias máquinas copiando la idea de Baer.
Por ejemplo, el Colecto Telstar, se empezó a vender a partir de junio de 1976 y se convirtió en un éxito por derecho propio, con alrededor de una docena de modelos. Aunque originalmente esta consola era un clon del Atari Pong. Esta última, surgió luego de que Nolan Bushnell asistiera a una demostración de la Odyssey, y tomando la misma idea con algunas mejoras (rutina de movimientos mejorada, puntuación en pantalla, efectos de sonido, entre otras), consiguiera tener más éxito. Las compañías con productos similares (incluida Atari) tuvieron que pagar una licencia durante algún tiempo.

1 de octubre de 2015

Historia de los videojuegos (2/10)

Durante la década del 1960, un grupo de estudiantes del MIT (Massachusetts Institute of Technology) liderados por Steve Russell, programaron un juego para computadora llamado Spacewar! El mismo se trata de un duelo espacial para 2 jugadores, donde cada uno controla una nave espacial capaz de lanzar misiles. El juego fue muy popular en el MIT, sin embargo, no llegó a comercializarse debido a los costos del hardware. Aun así, el juego fue una de las ideas más copiadas en la historia de los videojuegos, influencia que se vio plasmada a partir de la aparición de las primeras consolas domesticas.
Algunos años más tarde, Ralph Baer finaliza el primer prototipo de su Brown Box, un dispositivo que podía conectarse al televisor y que incluía una serie de juegos, entre los que se encontraban uno de ping-pong y uno de disparo con un rifle diseñado especialmente para su dispositivo.

Entrando en la década de 1970, aparece la primera maquina arcade de la historia: Galaxy Game. Bill Pitts, fascinado por Spacewar! decide cambiarle el nombre al juego y lo adapta para que funcione a base de monedas. Al año siguiente, tomando la misma idea, Nolan Bushnell junto a Ted Dabney presentaban: Computer Space. Sin embargo, no tuvieron el éxito deseado y a partir de entonces finalizan el contrato que tenían con Nutting Associates para fundar la empresa Atari y realizar su siguiente juego: Pong.
Pong fue el mayor suceso en los arcades hasta la aparición del Space Invaders desarrollado por Taito, dando comienzo a la era dorada de los arcades. A estos le sucedieron otros titulos como: Asteroids y Pac-Man. Así fue como las maquinas arcades comenzaron a tener éxito en centros comerciales, restaurantes y tiendas.

1 de septiembre de 2015

Historia de los videojuegos (1/10)

Cuando se trata de historia de inventos es difícil atribuir quien lo hizo primero, dado que en la mayoría de los casos, se le atribuye la primicia a quien fue el más popular. En este caso, muchos afirman que los videojuegos tuvieron su origen a finales de la década de 1940. Durante ese tiempo, Thomas Goldsmith y Estle Mann patentaron su Tubo de Rayos Catódicos, un aparato basado en un simple circuito eléctrico que permitía al usuario, por medio de unas perillas y botones, manipular el Tubo de Rayos Catódicos simulando disparos de un aeroplano sobre sus objetivos. También, Alan Turing escribe un programa de ajedrez que simula los movimientos de la computadora, sentando las bases prácticas de los programas de ajedrez modernos. Posteriormente en 1951, John Bennet presenta un enorme computador capaz de jugar al nim (un juego matemático de estrategia).
Mientras tanto, el técnico de televisión e inventor Ralph Baer comienza a idear algo para manipular la imagen del televisor en forma interactiva. Al año siguiente, Alexander Douglas presenta OXO, un juego de tres en raya para computadora.
En 1958, William Higinbotham valiéndose de un osciloscopio y una computadora análoga, crea el juego Tennis for Two, un juego de tenis con vista lateral.
Hasta entonces los videojuegos no consiguieron establecerse como algo formal, sino que más bien quedó limitado a un hobby de unos pocos o algo que quedaba dentro del ámbito académico. Todo esto debido a los costos de la tecnología y al limitado acceso a las computadoras.

1 de agosto de 2015

Ninja-kun Majou no Bouken

Título: Ninja-kun Majou no Bouken / Ninja-Kid

Sistemas:
1984 – Arcade, Famicom, MSX
No todos lo saben, pero Ninja Jajamaru-kun fue una de las más proliferadas sagas en los días del Famicom. El pequeño ninja rojo hace su aparición en 1985 en un titulo de Famicom, eventualmente protagonizaría cuatro títulos más. La mayoría de ellos son juegos de plataformas side-scrolling de acción, aunque algunos mezclan algo de RPG también. A lo largo de la serie, fueron mejorando la calidad de los juegos desde los 8-bit hasta los 32-bit y consolas portables.
La serie comienza con el arcade llamado Ninja-kun, realizado en 1984 por UPL. La compañía Jaleco sería la responsable de portar el título a Famicom, quienes terminarían usando nuevamente al personaje en un titulo propio realizado para consolas, llamado Ninja Jajamaru-kun. UPL continúa con su propia línea de juegos Ninja-kun, mientras que Jaleco terminaría prácticamente adoptando el personaje como mascota de la compañía.
Como la mayoría de los juegos arcade de la época, el objetivo en Ninja-kun es simplemente acabar con todos los enemigos de la escena. Valiendose de shurikens y habilidades de salto, el héroe conseguirá su objetivo, eludiendo también los proyectiles del enemigo. Es posible atontar al oponente saltando sobre su cabeza, algo que requiere practica, ya que si no se realiza bien, puede ser uno mismo el que resulte atontado. Básicamente hay 3 escenas que se repiten una y otra vez, agregando más dificultad y nuevos enemigos. Cada cierto tiempo cae una bola flotante. Si obtienes 3 de ellas podrás habilitar la escena de bonus, que consiste en recolectar más bolas flotantes durante un periodo limitado de tiempo.
Aunque los sprites son pequeños, son detallados y coloridos. Resulta gracioso ver los ojos de los personajes al ser atontados. Algo que puede resultar negativo, es el hecho de no poder dar un salto en vertical sin desplazarse a los lados.

1 de julio de 2015

Colisiones 2D (2/2)

Ya vimos como determinar colisiones entre 2 rectángulos. Ahora veamos como podemos aplicarlo en los videojuegos. Lo primero que tenemos que entender es que el área o caja de colisión (hitboxes en inglés), si bien está referida a las coordenadas del sprite, no tiene porque tener sus mismas dimensiones.
La imagen anterior corresponde a la página 48 del documento de diseño del videojuego Downtown Nekketsu Koushinkyoku Soreyuke Daiundoukai donde nos muestra las hitboxes de Kunio. Si bien no podemos contar con los documentos de diseño de todos los videojuegos, hoy en día existen herramientas que nos permiten visualizar las hitboxes de algunos.
Veamos un ejemplo simple:
En Super Mario Bros, podemos notar que las hitboxes, como ya mencionamos, no tienen el mismo tamaño del sprite, e incluso en algunos casos hasta exceden del mismo. ¿Por qué? Bueno, la razón es simple: para mejorar la jugabilidad. En la imagen notamos que la hitbox de Mario se excede en la parte baja. Esto se debe a que el principal ataque de Mario es saltar encima del enemigo, y si para esto contamos con un margen de error, nos resultará más fácil ejecutar dicha acción.
Veamos otro ejemplo:
En Final Fight utilizan 2 hitboxes por personaje: una para el área de vulnerabilidad (color azul) y otra para el área de ataque (color rojo).
Observamos que el área de ataque de algunos personajes está a la altura de las piernas. ¿Por qué? Para que sea más fácil contrarrestarlos con un ataque aéreo. También notamos que los personajes que se levantan luego de ser derribados, no cuentan con área de vulnerabilidad, lo que les permite reincorporarse sin problemas.
Por otro lado, aquellos enemigos que atacan barriéndose cuentan con un área de vulnerabilidad que está por encima del cuerpo. ¿Por qué? También, para poder contrarrestar mejor su ataque con una acción aérea. Notamos además, que los objetos que contienen ítems, como los barriles, cuentan con su propia área de vulnerabilidad.

Un ejemplo más complejo es el de Street Fighter 2. Es un videojuego bastante exitoso, y parte de su éxito se debe a la variedad y precisión con la que conectamos los golpes. Analicemos un ejemplo típico: Blanka caminando por debajo de los Tatsumakis de Ryu y Ken. ¿Cómo es posible?
5 hitboxes: presión (color verde), vulnerabilidad en la cabeza (color azul), vulnerabilidad en el cuerpo (color azul), vulnerabilidad en piernas (color azul) y área de ataque (color rojo). Habría una 6ta para los agarres, pero no la vamos a tomar en cuenta en esta ocasión.
Las áreas de vulnerabilidad y ataque están claras, pero ¿el área de presión? Las hitboxes de presión son aquellas que impiden que un personaje ocupe la posición del otro, dando la sensación de que ocupan un espacio físico en el juego. En la imagen notamos como las hitboxes de vulnerabilidad de Blanka están por debajo del ataque de Ken. En la serie The King of Fighters utilizan un método similar, pero en vez de 3 hitboxes de vulnerabilidad utilizan solo 2. Además, utilizan otro tipo de hitboxes: las de neutralización de proyectiles (color amarillo). En la siguiente imagen podemos ver el alcance del Kohoken de Takuma en The King of Fighters 2002, el cual no tiene un proyectil visible, así como sus demás hitboxes.
Ahora bien, ¿qué sucede si nuestro sprite es demasiado grande e irregular? Lo mejor es utilizar cuantas hitboxes sean necesarias, dividiendo el sprite por secciones y así lograr una mayor precisión.
Notamos como en el juego The Punisher, el enemigo de la imagen cuenta con varias hitboxes, logrando una buena precisión en las conexiones de golpes. Analizar estos ejemplos nos ayudan a determinar la forma en que podemos realizar las colisiones de nuestros proyectos.

1 de junio de 2015

Colisiones 2D (1/2)

Una de las claves para que un videojuego sea exitoso es la buena interacción de los objetos que lo componen. Muchos que han fracasado en este aspecto han llegado a estar catalogados en rankings de “los peores videojuegos”. ¿Cómo se logra una buena interacción de los objetos? Mucho depende del tipo de videojuego que estemos diseñando. En este caso voy a referirme a las colisiones de objetos en 2 dimensiones (colisiones 2D). Desde luego, este principio que voy a analizar puede ser ampliado y aplicado a proyectos más complejos. La forma más común de definir colisiones 2D es por medio de áreas rectangulares. Por ejemplo: supongamos que tenemos 2 áreas rectangulares. Por propiedad del rectángulo sabemos que cada uno consta de 2 lados paralelos, por lo cual, para dibujar cada uno, solo necesitamos 4 valores (2 en el eje x, 2 en el eje y). A los valores del primer rectángulo le llamaremos: h1, h2, b1 y b2, y los del segundo rectángulo: x1, x2, y1 e y2.
Con los datos que tenemos, ¿cómo podemos saber si los rectángulos están colisionando? Tan solo debemos comparar los valores de cada eje en ambos rectángulos. Como vemos en la imagen, el primer rectángulo comienza en h1 en el eje x, y finaliza en h2. Si el primer rectángulo finaliza antes de que comience el segundo rectángulo, no está colisionando y viceversa; si el segundo rectángulo finaliza antes de que comience el primero, tampoco colisiona. Esto sucede de igual manera en el eje y. De forma que, podríamos resumir, que ambos rectángulos colisionan cuando ninguna de las siguientes condiciones se cumple:
h2 < x1
x2 < h1
b2 < y1
y2 < b1
Ahora bien, aunque sepamos como determinar la colisión de 2 rectángulos, en videojuegos, es importante saber también cómo y cuándo aplicar esta técnica. En la siguiente parte, analizaremos algunos videojuegos que hacen buen uso de este método.

1 de mayo de 2015

Inteligencia Artificial (2/2)

Habíamos planteado el siguiente problema: ¿cómo puede la computadora guiar al corredor a través de la pista?

Si el lector es programador comprenderá que hay infinidad de formas de hacerlo. Ante todo hay que tener un equilibrio. En proyectos anteriores utilizaba demasiadas variables, mucha información que se le daba a la computadora para que la procesará y devolviera una respuesta o solución lo más acertada posible. Esto consumía muchos recursos, ahora un cambio radical, la poca utilización de variables, un mínimo de información para ser procesado por la computadora.

¿Cuáles son las ventajas y desventajas?

Si utilizamos demasiada información, la decisión tomada por la computadora será más cercana a la óptima, pero consumirá más recursos, por lo que el resultado de la decisión tomará más tiempo. Además, darle demasiada información puede resultar inútil en situaciones de simple resolución.

Por otro lado, el empleo de poca información da como resultado decisiones menos precisas, con un mayor porcentaje de errores, pero menor consumo de recursos y por lo tanto mayor velocidad de respuesta.

En este caso en particular, no hubo equilibrio en la utilización de la información, ya que la computadora no contaba con la información suficiente para que los corredores siguieran el rumbo establecido.

Si lo aplicáramos a la vida real, podríamos imaginar que el corredor tuviera limitada su visión a unos cuantos metros de su automóvil (como si de niebla se tratara) y ninguna señal que le indicara las curvas de la pista.

Hay muchas maneras de solucionar este problema. Una de ellas sería establecer variables que contuvieran datos de las áreas en las que debe corregir la dirección del corredor. La computadora podría verificar dichas áreas y establecer el giro del corredor para que pueda mantenerse dentro de la pista. Esto se pude efectuar con algunas variables numéricas de posición que cambiarían según la sección de la pista donde se encuentren.

Afortunadamente, el diseño de las pistas de este juego se había realizado con pequeñas secciones de 16x16 pixeles, y cada pantalla cuenta con 18x11 secciones o tiles. De esa forma, podríamos almacenar la información de la pantalla en una variable de tipo matriz de 18x11 elementos. En cada uno de esos elementos, estableceríamos la dirección que debe tomar el corredor. Para entenderlo mejor, veamos la siguiente imagen:
La computadora solo tendría que verificar dentro de qué sección de la pista se encuentra y compararla con la información de la variable matricial. De esa forma podría efectuar el giro hasta la posición indicada por la variable.

¿Cuál es el resultado?
En el siguiente video tenemos la respuesta:

Este comportamiento todavía puede ser mejorado, pero el ejemplo es a modo de ilustración. Como hemos visto, si ajustamos la cantidad de información equilibradamente al problema planteado, obtendremos mejores resultados.

1 de abril de 2015

Inteligencia Artificial (1/2)

Se denomina inteligencia artificial (IA) a la rama de las Ciencias de la Computación dedicada al desarrollo de agentes racionales no vivos. El termino agentes se refiere a cualquier cosa capaz de percibir su entorno (recibir entradas), procesar tales percepciones y actuar en consecuencia (proporcionar salidas). Cuando nos referimos a racionalidad se entiende como la característica que posee una elección de ser correcta, que la decisión tomada sea la más cercana a la óptima. Una de las claves para que un videojuego sea entretenido es la IA de los elementos controlados por la computadora. Para programar una buena IA hay varios recursos (ejecución de una respuesta predeterminada por cada entrada, búsqueda del estado requerido en el conjunto de los estados producidos por las acciones posibles, algoritmos genéticos, etc.) y habría mucha información para analizar al respecto. Por eso, en esta ocasión tan solo vamos a analizar un ejemplo sencillo. Hace varios años, estaba desarrollando un juego de carreras en Basic. El juego fue cancelado ante la incapacidad de programar una buena IA. Aquí una imagen del juego:
Cuando un humano observa la imagen podría deducir que se trata de una carrera de pequeños automóviles, que por la disposición de los vehículos, los corredores deberán transitar por la pista hacía la derecha de la imagen. También podría percibir, que antes de llegar al límite, deberán realizar un giro de dirección para mantenerse dentro de la pista. El ser humano entiende, razona, deduce y puede tomar decisiones que le permiten seguir las reglas del videojuego.

Cuando la computadora observa” esa imagen, ¿qué percibe? Tan solo son unos cuantos bytes, en este caso 64.000 bytes que varían su valor entre 0 y 3, nada más. (Resolución CGA: 320x200 a 4 colores). ¿No reconoce que se tratan de pequeños automóviles en una pista? No, a menos que lo especifiquemos en una variable. ¿No reconoce que debe transitar dentro de la pista? No, a menos que lo determinemos por medio de condiciones.

En el momento en que se estaba desarrollando el juego, debido a la poca experiencia en programación y debido a que en proyectos anteriores se habían utilizado demasiadas variables, se optó por usar la menor cantidad variables posibles. Hacer que la IA de los corredores se adaptara a todo tipo de pista. Los únicos datos que la computadora tendría serían algunos puntos de verificación y la coordenada de la salida de la pista.

¿Cómo sabría la computadora hacía donde girar para guiar al corredor a la salida? Para hacerlo se utilizaron los datos de colores del escenario. El área transitable de la pista siempre sería de color azul. Por lo tanto, la computadora "entendería" que mientras el corredor se encontrara sobre una superficie de color azul, iba en la posición correcta. Luego, por medio de otros puntos de verificación en torno al corredor, determinaría hacia donde girar para seguir dentro de la pista. Esto parece razonable, y el uso de variables es mínimo. Pero, ¿qué resultado tendría? Lo vemos en el siguiente video:


A grandes razgos, la computadora determina la mayoría de las veces hacia donde girar para dirigir al corredor a la salida. Sin embargo, ocurren varias imprecisiones en ciertas partes complejas de la pista. Por lo que, en ocasiones resulta prácticamente imposible para la computadora determinar el giro correcto. Esto intentó ser arreglado provisoriamente por medio de algunas acciones al azar. Pero, no fue suficiente, el resultado no es el esperado. Entonces, ¿cómo solucionar este problema? Recientemente, se decidió hacer algunas modificaciones en el código que controla los corredores. ¿Cuál fue el resultado? Lo veremos en la siguiente entrada.

1 de marzo de 2015

¿Cómo se hace un videojuego? (7/7)

Ahora que nuestro personaje se mueve por el mapa es necesario no perderlo de vista. Para esto tenemos que establecer lo que se llama movimiento de scroll. Inicialmente es algo sencillo establecer un movimiento de scroll o seguimiento de cámara. Lo difícil puede ser generar el fondo a partir de los tiles dentro del área visible del screen. La posición del scroll la guardaremos en un par de coordenadas x e y, lo que determinará que cada objeto (incluido el mapa entero) estará sujeto a dichas coordenadas. Para entenderlo, veamos el siguiente caso:
Como vemos en la imagen, el mapa (y personaje) tuvo que ser desplazado 43 pixeles a la izquierda y 32 pixeles hacia arriba (del área visible) para poder seguir al personaje. Esa diferencia de pixeles es la que se registra en las variables del scroll. El desplazamiento del scroll se puede hacer de varias maneras según el tipo de juego, por ejemplo, se puede hacer que suavemente vayan cambiando los valores hasta acercarse al personaje. En este videojuego, se impone que el scroll esté desplazado 159 pixeles a la izquierda de las coordenadas del personaje y 159 pixeles por encima. Cada vez que colocamos el personaje, el mapa o cualquier objeto del entorno, debemos sumarle las variables de diferencia de scroll. Los únicos elementos no sujetos al scroll son aquellos que deben permanecer fijos en cierta sección del screen o ventana, como por ejemplo los marcadores de: número de vidas, puntuación, tiempo, etc. Finalmente, al momento de generar el mapa a partir de los tiles se puede hacer de dos maneras. Una forma es generar todo el mapa completo, lo cual gasta recursos innecesarios, ya que no todo el mapa es visible dentro del screen. Otra manera es determinar cuáles son los tiles que caben dentro del área visible del screen, y solo presentar esos. En el ejemplo de la imagen anterior notamos que, los tiles visibles surgen a partir de la 3er fila y 3er columna. Sabemos que el tamaño visible del screen es de 20x15 tiles. Así que, generamos los tiles comprendidos entre la 3er fila y 3er columna en adelante hasta completar los 20x15 tiles. Pero, debemos tomar en cuenta la diferencia del tile con el screen (marcada en la imagen anterior).

Conclusión
Hasta aquí se han presentado las bases para comenzar con el diseño de un videojuego de plataformas. Posiblemente más adelante se aborden otros temas puntuales y más profundos del desarrollo de videojuegos, pero se considera que con la información presentada, el lector será capaz de darle los elementos faltantes a este ejemplo (enemigos, ítems, movimientos, etc.).

1 de febrero de 2015

¿Cómo se hace un videojuego? (6/7)

Como ya mencionamos anteriormente, el personaje tiene variables de posición x e y. Pero, ¿en qué parte del sprite se aplica la coordenada? Se aplica en un punto que normalmente es llamado hot spot o pivot. En este caso sería el punto (rojo) que nos muestra la siguiente imagen:
Es un punto que (para este juego) determina que el sprite se imprime 12 pixeles a la izquierda y 31 arriba de la coordenada dada. Es decir que si el sprite se encuentra en la coordenada (0,0) se vería en la siguiente posición:
Ahora bien, ¿cómo sabemos dónde puede pararse el personaje o hasta donde puede desplazarse? Por medio de las colisiones. Se verifican puntos arbitrarios del personaje y se comparan con los datos del mapa. Recordemos que nuestro mapa se compone de tiles, y que los tiles distintos de cero (tile color cielo), son tiles solidos que no pueden ser atravesados. Aunque esto se ha establecido para este ejemplo, puede ser ampliado y establecerse otros tiles que puedan ser atravesados. Los puntos que se verifican en este caso son los siguientes:
AS: Apoyo superior.  
LDA: Apoyo Lateral-Derecho-Alto
LIA: Apoyo Lateral-Izquierdo-Alto  
LDB: Apoyo Lateral-Derecho-Bajo  
LIB: Apoyo Lateral-Izquierdo-Bajo
AD: Apoyo Derecho  
AI: Apoyo Izquierdo
H: Hot Spot, o sea punto de referencia del sprite (x, y).

El punto AS es verificado cuando va hacia arriba, si el punto se encuentra dentro de un tile solido, se limita el movimiento del personaje. Los puntos LIA y LDA son verificados cuando va a la izquierda o derecha, e impiden que el personaje continúe si se encuentra con un tile solido "a la altura de la cabeza" (es decir, en el área superior del personaje). Los puntos LIB y LDB son verificados cuando va a la izquierda o derecha, e impiden que el personaje continúe si se encuentra con un tile solido "a la altura de las piernas" (es decir, en el área inferior del personaje). Los puntos AI y AD son verificados para determinar cuándo el personaje debe caer. Si ambos puntos se encuentran en áreas vacías, entonces el personaje deberá caer. En cada caso lo que se hace es convertir la coordenada del punto a verificar, en coordenada de tile. Luego, se consulta (en la variable de mapa) el tipo de tile que existe en esa coordenada convertida. Para este ejemplo se utilizaron estos puntos de verificación, pero dichos puntos pueden variar según el tipo de juego, dimensiones y características de cada personaje.

1 de enero de 2015

¿Cómo se hace un videojuego? (5/7)

Ahora que ya hemos definido la animación de las acciones del personaje, ya estamos listos para programar sus movimientos. Anteriormente habíamos definido las coordenadas del personaje en la pantalla por medio de un par de variables x e y. Entonces, para darle movimiento al personaje lo haremos modificando los valores de dichas variables. En la física los movimientos de los cuerpos se pueden descomponer de la siguiente manera:
Posición = Posición + Velocidad
Velocidad = Velocidad + Aceleración
Así que, utilizaremos variables de velocidad y aceleración para cada eje.

Nota: en este juego omitiremos la aceleración en el eje x, ya que el movimiento de desplazamiento del personaje en dicho eje, es lineal.

A la variable de aceleración en el eje y le asignaremos el nombre "gravedad", ya que es la que provoca la caída libre del personaje. Para entender cómo funcionan las variables en el transcurso del juego, veamos el siguiente ejemplo:

Supongamos que el personaje se encuentra en la coordenada (300, 200). La variable de velocidad en el eje y (llamada vy) del personaje, al momento de efectuar un salto, toma el valor -7 y la variable de aceleración (a la que llamamos gravedad) es 0.5. Así que, cuando transcurren 0.028 segundos, la posición en el eje y se suma a la variable de velocidad, es decir que se le restan 7 pixeles (posición = 200 + (-7)) y a la velocidad se le suma la aceleración (gravedad), es decir se le suman 0.5 pixeles (velocidad = -7 + 0.5). El resultado es que la posición cambia a 193 y la velocidad a -6.5. Esto sucede sucesivamente tal como lo muestra la siguiente imagen:
Los valores que presenta la imagen son enteros, ya que los pixeles no se pueden dividirse en números racionales. Por eso, los valores reales que toman las variables son los de la siguiente tabla:

Segundos Posición Y Velocidad Y
0.028 200 -7
0.056 193 -6,5
0.084 186,5 -6
0.112 180,5 -5,5
0.140 175 -5
0.168 170 -4,5
0.196 165,5 -4
0.224 161,5 -3,5
0.252 158 -3
0.280 155 -2,5
0.308 152,5 -2
0.336 150,5 -1,5
0.364 149 -1
0.392 148 -0,5
0.420 147,5 0
0.448 147,5 0,5
0.476 148 1
0.504 149 1,5
0.532 150,5 2
0.560 152,5 2,5
0.588 155 3
0.616 158 3,5
0.644 161,5 4
0.672 165,5 4,5
0.700 170 5
0.728 175 5,5
0.756 180,5 6
0.784 186,5 6,5
0.812 193 7
0.840 200 7,5

Si quisiéramos ver la trayectoria del personaje, podríamos graficar los valores de la tabla de la siguiente manera:
Ahora, nos resta determinar cuándo debe detenerse el desplazamiento. Para eso, debemos detectar la colisión del personaje con los elementos del mapa.