Hosteando nuestra propia Game Jam - Parte 2

Pre-evento: Buscar socios y Sponsors

Hola!

Les traigo la primera parte de esta serie de artículos sobre cómo fue que organizamos lo que fue la ITBA Game Jam.

Lo primero que hicimos fue buscar socios y Sponsors.

¿Por qué necesitamos socios?  DINERO + DIFUSIÓN.

Cualquier evento de este estilo va a requerir plata, por más que no se de comida a los participantes, siempre va a haber algún gasto como algún banner o flyers para difundir el evento.

Una vez que definimos cómo iba a ser el evento a grandes rasgos y cuantos participantes íbamos a poder recibir, lo siguiente era buscar quienes estarían interesados en participar del evento.

Nuestros socios finalmente fueron Etermax y Fundav, además de tener algunos regalos de parte de Razer. Gracias a todos estos socios, el evento fue posible y fue tan grande como fue.

Si bien ellos fueron los que estuvieron finalmente, no fueron los únicos a los que recurrimos.

En la primera etapa del evento, uno de mis trabajos era encontrar empresas que quieran participar del evento. Algunas respondieron con mucho ánimo y otras ni respondieron los mails, esto es muy común por eso, creo que un primer consejo sería:

No tengas miedo en intentar

Nuestro contacto con Razer surgió porque les escribí personalmente por la página de Facebook y ellos justo últimamente están soportando este tipo de eventos, por eso, al escuchar la idea comenzaron las conversaciones por mails. No tengan miedo en enviar mails o mensajes a empresas grandes!

Sin embargo, hay que tener en cuenta que siempre va a ser mejor tener algún contacto dentro de la empresa que se busca. Siempre es mejor mandar un mail a alguien dentro de la empresa que a una casilla de correo genérica.

Entre las empresas a las envié mail, también incluí a las instituciones que tienen carreras o cursos con orientación en videojuegos más conocidas de Buenos Aires. Es una lástima que no hayan respondido los mails ya que el evento tal vez hubiera sido incluso más grande de lo que fue, esperemos que para la próxima estén más atentos a su bandeja de entrada de los mails y no tanto a enviar mails sobre sus cursos y promociones.

Aunque algunos podrían, para estos casos, decir que mientras más socios, mejor, siempre hay que tener en cuenta el alcance del evento y las cuestiones "políticas".

Con cuestiones políticas me refiero a las negociaciones con las empresas que potencialmente quieran involucrarse su nivel de participación en el evento. Un tira y afloje sobre qué logo aparece primero, en qué tamaño, quién se queda con los derechos de autor de lo producido en el evento, quién lo difunde, etc.

Este tire y afloje es muy variable. Podríamos catalogar las empresas en "Reservadas" y "Colaborativas".

Para dar ejemplo de una empresa "Reservadas", podemos hablar de empresas a las que le tengamos que pedir permiso para solamente mostrar  su logo junto al nuestro en caso de que quieran participar o  empresas que tengan su departamento de comunicaciones tercerizado, por lo cual uno no habla con la empresa en sí hasta que ya se hayan definido algunas cosas. Si bien esto pueden parecer detalles menores, estas pequeñas trabas se acumulan y dificultan la interacción con la empresa. En estas, el tire y afloje suele ser bastante más delicado.

Para dar ejemplo de empresas "Colaborativas" (Etermax y Fundav en nuestro caso), tenemos empresas que persiguen el mismo objetivo que el evento. Estas empresas facilitan la organización porque ambas partes están altamente beneficiadas con la realización del evento. Por lo tanto, estas empresas si bien pueden tener sus demandas, las compensan con las acciones que realizan. En estas, el tire y afloje es mucho más relajado.

En nuestro caso, un detalle no menor para mi fue que Etermax además de ser sponsor del evento económicamente, nos dio cajas de sus figuras de silicona de su juego "Preguntados" para que les regalemos a cada participante además de unos regalos de la empresa para que hagamos sorteos. Razer (sin ser sponsor) también utilizó este principio, nos regaló tazas para que les regalemos a cada participante. Estos son gestos que mejoran el evento para ambas partes ya que ellos promocionan sus empresas mientras nosotros podemos regalarle algo a cada participante.

Por nuestra suerte, pudimos alcanzar nuestras necesidades teniendo solamente socios colaborativos. Cuando detectamos que una empresa era la que tiraba, tratábamos de, en lo posible, no involucrarnos. De nuevo, esto fue por la suerte que tuvimos de poder arreglarnos con los socios que ya teníamos, de haber sido otra la situación, nos tendríamos que haber conformado con otras empresas (algunas reservadas) y aceptar sus demandas.

Para resumir, a menos que el equipo organizador sea auto-suficiente, es un vital conseguir socios para realizar el evento. En lo ideal, socios que tengan el mismo objetivo en mente, que compartan las mismas motivaciones. Hay que pensar que nosotros como organizadores tenemos recursos finitos para entregarles a los socios, tenemos que saber cómo distribuir estos recursos y saber manejar el tira y afloje dependiendo de estos.

Espero que les haya gustado esta primera parte.

Hasta la próxima.

-L

Hosteando nuestra propia Game Jam - Parte 1

Introducción

 

Hola!

Sé que hace mucho que no escribo por acá.

Entre exámenes y falta de tiempo no pude dedicarme a hacerme tiempo a realizar algo nuevo.

Aunque por otro lado, es muy probable que vuelva a retomar el proyecto de Pirate's Tycoon, me parece un muy buen concepto a explotar. Tal vez lo arranque desde cero y solo me enfoque en la parte Tycoon, quitando la parte de batallas navales para mucho más adelante.

Por otro lado, les quería comentar otra de las razones por la cual estuve tan ocupado: estuve organizando (junto con otra gente de mi facultad) la primer Game Jam de la universidad.

El evento tuvo el formato "default": 1 tarde en donde dimos talleres, charlas y se armaron los equipos y luego 72hs de puro desarrollo.

Pueden ver los juegos que hicieron acá: https://itch.io/jam/itba-game-jam

No hubo ganador ni más votado, queríamos incentivar a los equipos a que se ayuden entre ellos, que fue lo que ocurrió.

Quería dividir mis comentarios sobre la organización de este evento (tips y cosas que aprendimos) en varios artículos, dividiendo la organización antes del evento, durante el evento y después del evento.

Así que estén atentos que tanto si quieres armar un evento con un formato similar o solo te interesa saber cómo fue que organizamos esto, estos consejos tal vez les puedan servir.

Hasta la próxima.

-L

Pirates Tycoon - Shipwrecked

Proyecto Suspendido

En este Post voy a hablar de este proyecto y de mis proyectos en general, de por qué creo yo que muchos terminan de esta manera.

En pocas palabras la respuesta a por qué suspendo este proyecto es: Es una idea muy grande. Si bien traté de reducirlo a una demo simple, no tengo la buena costumbre de reducirlo lo suficiente como para que sea hecho por una sola persona.

Tengo 2 juegos completos lanzados al mercado y un clon del Snake. Si bien con esto ya tengo un poco de experiencia sobre cómo manejarse en Unity, no es suficiente. De nuevo el problema (que suele surgir en los indies) de querer hacer juegos muy grandes.

Si bien el proyecto anterior a este último (Rock Climber) tenía potencial, no supe encontrarle la manera de que sea divertido y tardé mucho en hacer lo que hice, lo que me desanimó a seguir desarrollándolo.

Por eso siento que tengo que volver a lo básico, recrear los "clásicos" juegos en Unity (para ganar experiencia y aprender algunos trucos del motor) según tutoriales. De esta manera, voy a aprender a hacer juegos que ya funcionan de forma rápida. Encima de eso, voy a agregarles alguna modificación, desde tratar de optimizarlo hasta cambiar un poco las mecánicas del juego para hacer mi versión de este.

Lo primero que hice hasta ahora fue un Tetris. Siguiendo un par de tutoriales, en aproximadamente 2 semanas pude tener este resultado:

Es completamente funcional. Todavía me faltan agregarles detalles como una tabla de puntuaciones y música y sonidos entre otras cosas pero el progreso es mucho mayor al que tengo normalmente con un juego 100% propio.

Actualmente este juego corre a 60-70 FPS en mi computadora. Mi objetivo de optimización es elevar eso a 70-80 o idealmente, más de 90 FPS. Acá es donde me sirven los "trucos" de Unity que pueden mejorar el rendimiento.

Como posible modificación, se me ocurre hacer un "Tetris Doble" en donde hayan dos tableros y el jugador tenga que jugar en simultáneo. 

Personalmente siento que esto me sirve mejor como práctica para estar listo para cuando quiera desarrollar completamente mis juegos.

Una lista de los juegos 2D que voy a hacer serían:

• Tetris.
• Pacman.
• Pong.
• Mario (simplificado).

Espero poder traerles más y mejores progresos de estos juegos .

Hasta la próxima.

-L

Pirates Tycoon - Part 3

Batalla Naval

Como habrán notado, estuve mucho tiempo ausente.

Principalmente por temas de estudio pero también porque quise probar algo nuevo para mi, quería incorporarle al juego la posibilidad de tener batallas navales.

Pero estas van a ser de una forma muy peculiar, no quería que el barco sea totalmente controlado por el jugador moviendo directamente al barco con el teclado. Quería que sea un combate táctico.

Para hacer esta demo de batalla naval necesito reunir tres elementos que creo que son esenciales:

1. Un océano con olas variables.
2. Un barco que se pueda mover y sea influenciado por el viento.
3. Inteligencia Artificial para los barcos enemigos.

De los 3 elementos que busco, el primero lo encontré en la Asset Store de Unity. Si bien no es el tipo de agua ideal para lo que quiero, cumple lo que necesito (aunque sin olas). Por lo que decidí quedarme con él.

Sobre el segundo elemento es en lo que estuve trabajando últimamente.

En definitiva, buscaba cómo hacer un controlador para simular la mecánica de un barco a vela. En Internet suelen haber varios tutoriales pero estos son de otro tipo de embarcación (como yates u otros barcos a motor), en donde la mecánica del movimiento es distinto.

Sobre esto voy a entrar más en detalle en otro Post pero para resolver este problema se me ocurrían varias formas:

1. Tener un barco como un "bloque", crear una "fuerza" que represente el viento y que este empuje constantemente al barco, con algunos cálculos vectoriales para que la dirección del viento afecte la velocidad del barco
2. Un tutorial en Internet indicaba como hacer un bote realista en donde el objeto "flotaba". Decidí no hacer esto ya que, en el caso de tener varios barcos y más mecánicas en juego, siento que esta forma iba a gastar un gran porcentaje del procesador para calcular "como hacer que el barco flote" constantemente.

Así que arranqué con la primer idea que tenía.

Primero con un cubo, le agregamos el componente de "RigidBody" de Unity y agregamos un "campo" en donde esa fuerza iba a actuar. La fuerza no era más que la fuerza que ofrece el mismo componente RigidBody de Unity, con el modo de fuerza en constante.

Claramente esto no iba a dar buenos resultados. Mi idea era "empujar" constantemente al barco y si esta flotaba por su propia cuenta, entonces se podría decir que estamos simulando la navegación del barco. Pero yo no tenía bien en claro qué reacción iba a conseguir utilizando este método.

Así que descarté la primer idea y la segunda ya sin siquiera probarla.

¿Entonces?

Después de mirar en muchos videos de juegos como el Sid Meier's Pirates (uno de mis favoritos) y similares para ver como estos resolvían este problema, me iba surgiendo una idea...

Si lo pensamos desde un punto de vista mecánico y minimalista, ignorando toda la interacción con el agua y el viento, un barco es "empujado" de la siguiente manera:

Si al barco "lo empujan" de atrás (el viento), el barco avanza y gira hacia la dirección contraria. Entonces de esto vi una similitud en algo más cotidiano, un auto.

Entonces... por qué no hacer un auto? Si descontamos el hecho de que lo "empujan" con el viento y hacemos que este constantemente en movimiento, es igual que un auto.

Estaba tratando de no utilizar este método ya que no me parecía muy "técnico" y pensaba que la solución era el método 1 o 2. Pero después, encontré en Internet algunos ejemplos de juegos que aprovechaban el componente "WheelCollider", hecho especialmente para las ruedas de los vehículos en Unity, para realizar esta idea.

Por lo tanto mi problema pasó de cómo crear un barco a cómo crear un auto.

En conclusión, a menos que valga la pena el detalle y se pueda alcanzar la producción (como en el juego "Sea of Thieves"), un barco en los juegos indies es un auto.

Todo parecería estar listo entonces, crear un auto utilizando un modelo 3D de un barco como "chasis" de este y listo, un barco que se puede manejar en Unity! (sin contar la influencia del viento).

Si tan solo hubiera sido tan fácil...

Hasta la próxima.

-L

XCOM Enemy Unknown as a Tycoon

XCOM (EU) desde un punto de vista Empresarial

Si uno le va a presentar el juego XCOM: Enemy Unknown a alguien más por primera vez, seguramente no sea con la imagen de arriba, seguro sería con una imagen en la que se pueda ver el combate por turnos, lo que define de alguna forma al juego. Pero el juego es más que 4-6 soldados luchando por turnos contra aliens. Firaxis se las rebuscó para poder dar más niveles de complejidad y profundidad al juego.

Después de hacer el tutorial, tenemos un cuartel que es parecido a la imagen del post. En este cuartel, tenemos científicos para descubrir nuevas tecnología para los soldados e ingenieros para construir esas tecnologías. También podemos construir otro tipo de instalaciones para acelerar la producción o investigación de lo mencionado anteriormente.

Ahora una pequeña pregunta: ¿Cómo sería el juego si el jugador no luchara las batallas? Si en vez de resolver las misiones, hubiera un botón de "auto-resolver" en donde el jugador elije los soldados y su equipo y por medio de algunos cálculos, la computadora decide el éxito de la misión y cuantos soldados vuelven de esta.

Sobre esto es este pequeño artículo.

¿Qué rol cumpliríamos nosotros entonces?

Seríamos una especie de "gerente" del proyecto XCOM. Nuestro trabajo sería administrar los pocos recursos que nos dan para asegurarnos que nuestras tropas tengan el mejor equipo posible para tener un mayor porcentaje de éxito en sus misiones. Además de administrar otras cosas como las investigaciones de nuevas tecnologías, la contratación de soldados, la distribución de satélites en los distintos países, etc.

¿Suena familiar? Podríamos decir que ese cambio haría que el juego se convierta en "Alien Death Squad Tycoon". Este aspecto es el complemento perfecto al sistema de combate del juego, para evitar que el juego sea muy repetitivo enviándote de misión a misión simplemente luchando los mismos aliens.

Por supuesto que el juego no tendría la misma emoción ni la misma conectividad con el jugador. La posibilidad de que el jugador pueda participar en las batallas agrega una nueva variable al sistema del juego. Las misiones no se desarrollan por cálculos de probabilidades sino que dependen, además de muchas cosas, de las decisiones del jugador. Haciendo que el jugador sea responsable de la misión, de su éxito, de los soldados, del equipo, etc. En otras palabras, los "Activos" de la empresa que maneja, esto crea una mayor sensación de control sobre el juego.

Entonces, ¿Podemos clasificar a XCOM como un juego de Tycoon militar con un sistema de combate de fondo?

No. El juego de género "Táctico por turnos" ganador del GOTY 2012 según algunos medios centra su jugabilidad en el combate, teniendo este "Tycoon" como funcionalidad secundaria para complementar y agregar mucha variedad al juego.

La conexión entre estos sistemas agrega una gran cantidad de variaciones a la historia del jugador, además de ser de vital importancia. El jugador no puede saltar de misión a misión sin utilizar los recursos de investigación o de ingeniería para las nuevas misiones. Como tampoco puede desarrollar dichos recursos si no posee los recursos que obtiene de las misiones.

De todas formas, es interesante ver cómo un "simple" cambio puede alterar totalmente el sentido del juego. El hecho de que el jugador pueda o no combatir las batallas cambia el rol de nuestro personaje en el juego.

En conclusión, quería demostrar cómo pueden haber sistemas ocultos en los juegos si se "tapan" algunas funcionalidades. Puede que el sistema en cuestión sea evidente para algunos, pero lo que no se puede negar es que puede llegar a transformar un juego en otro completamente distinto.

Hasta la próxima.

-L

Pirates Tycoon - Part 2 (The Tycoon Formula)

The Tycoon Formula

En este Post voy a de-construir un poco a los clásicos juegos de Tycoon que jugué (también conocido del género "business simulator") para ver qué es lo que los convertía en grandes juegos de sus épocas.

Comenzando con uno de los más famosos lanzado inicialmente en 1999:

RollerCoaster Tycoon

Haciendo una excepción al arrancar, este juego no lo jugué (aunque si la 3era iteración de la saga), pero si jugué varios juegos muy similares como "Theme Park" para PS1.

La idea de este juego es construir tu propio parque de diversiones. Arrancando con un terreno muy grande y con mucha plata, debemos construir diferentes atracciones para la gente.

Lo que hace especial al juego son las montañas rusas, ya que el jugador tiene la posibilidad de crear su propia montaña rusa, la cual debe estar bien hecha para que no ocurran accidentes.

Analicemos entonces las funciones del juego:

• Construir atracciones.
• Manejar el balance de cuentas del parque de diversiones.
• Manejar eventos inesperados (hechos aleatoriamente por el sistema).

De estas 3 funcionalidades, podríamos reducirlas todas a una: construir.

Qué construir? Cuando? Por qué? Cuando hay que de-construir?

Son simples preguntas pero modifican la jugabilidad. Como por ejemplo, un jugador con un poco de experiencia en estos juegos sabe que lo mejor (en la mayoría de los casos) no es construir una montaña rusa demasiado grande como primer atracción del parque, ya que es muy costosa y si no es muy visitada, puede que resulte dando más pérdidas que ganancias.

Si pensamos en las acciones que hace el jugador en estos juegos es construir y de-construir (aunque también se contaba con la capacidad de modificar los precios de las atracciones) dependiendo de sus estadísticas o los objetivos que tenga el juego.

------------------------------------------

Como segundo juego traigo uno al que le he dedicado bastantes horas:

Hospital Tycoon

En este, la temática (como podrán adivinar) es manejar tu propio hospital.

En esta generación de juegos Tycoon empezaron a haber un poco de variedades, no solo construir el hospital a partir de un edificio vacío sino que, por ejemplo, te deja elegir a que doctores contratar.

Este último detalle parece pequeño pero introduce un nuevo sistema al juego, las relaciones humanas. Si bien justo este caso particular no era tan profunda, estaba presente. Al contratar un médico, este puede que se lleve muy mal o muy bien con otro que ya había, lo que le introduce al jugador otro aspecto a tener en cuenta.

En estos juegos, el jugador ya deja de ser solo un arquitecto y diseñador de interior para también introducir el oficio de gerente, midiendo el desempeño de la gente que contrata y tomando decisiones que tienen consecuencias.

------------------------------------------

Como tercer juego, uno desarrollado un año después al anterior y también con nuevas funcionalidades:

Prison Tycoon 4

En este caso, construir una cárcel y manejarla.

Ya desde el HUD podemos ver que hay muchas nuevas funcionalidades, la construcción de la cárcel es solo una opción al costado.

Como en el juego anterior, este juego no es solo de construir una cárcel que sea segura. Sino que también había que manejar varios aspectos de la gente que trabajaba allí, como por ejemplo, indicar los niveles de agresión de la policía, lo que influía en los presos.

Si había poca presencia policial, se forman bandas delictivas y se atacan entre ellas, si hay mucha presencia policial, puede que estalle un motín. 

Estas cosas mueven al jugador a que tenga en cuenta aspectos mucho más importantes para el juego que, simplemente, la construcción del establecimiento.

------------------------------------------

Como último juego, uno de mis favoritos:

Game Dev Tycoon

Nos toca armar nuestra propia empresa de juegos.

Este juego es un ejemplo inverso del primero. En este, no podemos elegir cómo construir nuestro estudio, el juego se dedica exclusivamente en la tarea de ser el "Desarrollador Jefe" y CEO de tu empresa.

En este juego, debemos crear juegos eligiendo entre varios factores como él o los géneros que lo van a componer, la proporción de gráficos/sonido/historia que le queremos dedicar a ese juego particular, la plataforma de salida, etc.

Podemos notar que el oficio de arquitecto o diseñador de interiores es simplemente estético y para nosotros, no afecta la jugabilidad. Algo que es correcto para el juego, ya que la arquitectura de la oficina no influencia en nada el producto final (podría influencia a las personas que trabajan en ella).

Que este juego no tenga la funcionalidad de construir el entorno de trabajo no le quita "profundidad" en complejidad, en el fondo, responde a las mismas preguntas que el primer juego.

Qué juego hacer? Cuando? Por qué? Cuando dar de baja un juego?

Las mismas preguntas (adaptadas a la temática del juego) pero respondidas desde otro ángulo, desde el manejo puro de la empresa y el desarrollo de los juegos.

------------------------------------------

Como podemos ver, desde distintos ángulos se trajo la temática de administración en los juegos y en varios casos, las mecánicas eran simples, lo que no es simple es saber cuando aplicar cada funcionalidad. Por ejemplo, saber cuanto tiempo esperar o cuanta plata ahorrar para comprar esa nueva atracción para nuestro parque de diversiones.

A lo largo de los años, lo que se fue agregando fueron las "capas de complejidad" que hacía que los juegos tengan resultados más interesantes. Como por ejemplo, introduciendo a la competencia. En el último juego presentado, debemos saber cuando lanzar un juego en X plataforma ya que tiene una gran parte del mercado debido a los juegos de la competencia.

Para el primer juego, por ejemplo, podríamos agregar la funcionalidad "vencimiento de la comida". Si el parque vende comida vencida porque el jugador no se dio cuenta de tirarla, la gente puede enfermarse y eso va a hacer que menos gente vaya al parque. Este agregado es un nuevo aspecto que el jugador tiene que tener en cuenta, que agrega dificultad al juego.

Esto hace que los juegos tengan más "profundidad". Que el jugador pueda tener una consecuencia visible de sus acciones.

Para concluir, podemos ver que un juego de género Tycoon no se basa en sus mecánicas sino en saber cuando aplicarlas.

Hasta la próxima.

-L

Pirates Tycoon - Introduction

Introducción al concepto del juego

Como mencioné antes, hace mucho que tenía las ganas de hacer un juego del estilo "Tycoon".

Si bien muchas variantes me vinieron a la cabeza, decidí por mezclar una de mis temáticas preferidas, piratas. Después pensé... ¿Cómo hubiera sido administrar todo el "imperio" pirata en su época de oro?

Pero a diferencia de mi manera usual de hacer juegos, esta vez no voy a hacer el juego completo sino una "demo". El jugador va a tener completa libertad de lo que puede hacer pero el tiempo de juego va a estar limitado a varios días (o meses) en el tiempo del juego. Esto es para que el jugador pueda sentir el "medio juego" y el concepto general se pueda expresar de mejor manera.

Las posibilidades hasta ahora van a ser desde construir edificios y poder mejorarlos hasta organizar saqueos a flotas extranjeras para ganar recursos. También tengo en mente poder desarrollar relaciones con piratas famosos al estilo de Civilization pero esto último esta por verse.

Esto es lo que pude hacer hasta ahora:

Como siempre, prefiero dedicarme primero a las mecánicas generales y después ir a los detalles artísticos como los modelos del terreno y de los objetos en escena, además de las interfaces.

El mapa fue cargado directamente de una imagen de 10x10 px, fue una idea que vi de un tutorial del Youtuber "Quill18" (https://www.youtube.com/watch?v=5RzziXSwSsg&t=1s) que después también implementó el otro Youtuber "Brackeys" (https://www.youtube.com/watch?v=B_Xp9pt8nRY).

Lo siguiente en lo que voy a trabajar es en las ventanas que deben mostrar cada edificio si se hace click en él, mostrando la información que corresponda.

//Detalles técnicos

En el caso de la implementación de Brackeys, hice un cambio en la forma de verificar qué color corresponde con cada tipo de suelo. Utilicé un diccionario, ya que su orden de Búsqueda es O(1) en vez de verificar en toda la lista de colores cual color corresponde con el tipo de suelo, que tiene un orden O(n).

Hasta la próxima.

-L

C++ Snake Dev Guide Part 3

Tercera parte: movimiento en el mapa y Game Over

Última parte! Como mencioné antes, voy a dedicar esta parte para explicar en más detalle la lógica de cómo saber si el jugador perdió y además, cómo hacer para que la serpiente pueda salir por un borde del mapa y aparecer por otro.

Primero voy a explicar lo último que es más simple.

Si tenemos un tablero de 10 lugares, sabemos que podemos ir desde la posición 0 hasta la 9. Pero sabemos que en el juego Snake si pasamos la casilla 9, volvemos a estar en la casilla 0, como si hubiera un portal para la serpiente.

Esto se hace simplemente forzando la posición de la serpiente. Si la posición de la parte de la serpiente es mayor o igual a 9, que ahora sea 0. Esto va a obligar a el juego a mandar a la serpiente a un extremo si la serpiente se pasó por otro.

Para los bordes izquierdo y el inferior es el mismo truco, si la posición de la serpiente es menor o igual a cero, que se modifique a la posición (TAMAÑO_DE_MAPA - 1) para ir al extremo derecho o superior de la pantalla.

Hay que tener en cuenta que estas verificaciones debemos hacerlas después de que cada parte de la serpiente avanza. Es decir, primero una parte de la serpiente se mueve y luego se verifica si esta tiene que ir hacia otro extremo o no.

Ahora, el Game Over.

Podemos ignorar lo de más arriba y tener como otra condición que la serpiente no pueda tocar las paredes del mapa. 

En ambos casos, deberíamos tener un flag (una variable de tipo boolean) que nos indique si el jugador perdió o no. 

Para no tocar los bordes, tendríamos que verificar que si el jugador tocó alguno de los bordes, se active el flag (flag = true) y que se muestre la pantalla de Game Over.

El hecho de verificar si la serpiente se mordió a si misma son 3 líneas de código. Pero estas líneas puede que requieran un poquito de explicación.

Así es como se mueve la serpiente en todo momento:

Donde "H" es para la cabeza y "B" para el cuerpo. Podemos ver en la segunda imagen como se va armando el camino de la serpiente.

Ahora, lo más importante a notar es que las casillas que no están ocupadas por el cuerpo de la serpiente no tienen ninguna dirección. Osea que si una casilla tiene una dirección, es porque esta ocupada por una parte del cuerpo de la serpiente.

Entonces, si la cabeza de la serpiente entra en una casilla que ya tiene una dirección, esta se esta mordiendo a si misma. Esto nos va a servir como condición para activar nuestro flag y mandar al jugador a la pantalla de Game Over.

Desde acá hay todavía cosas que se pueden agregar. Como por ejemplo, un menú para jugar, un contador del puntaje, tiempo si es que queremos agregar esa funcionalidad, etc.

Yo no quise agregar más cosas para no complicar de más el proyecto. Pero si quieren, les recomiendo probar por su cuenta.

Acá termina esta guía para crear un clon del Snake. Espero que le haya servido a alguien para darse una idea de cómo arrancar a desarrollarlo o haber podido resolver alguna pregunta que alguien se haya hecho durante el desarrollo del juego.

Un saludo y hasta la próxima.

-L

C++ Snake Dev Guide Part 2

Segunda parte: Movimiento y Comida

Ya teniendo una idea de como armar la serpiente y el tablero, nos falta pensar como va a ser el movimiento de la serpiente y como esta va a crecer cada vez que come.

Lo que primero hice fue dibujar el tablero en pantalla, dibujando cuadrados y luego llenar la pantalla con los cuadrados, cambiando los colores de los cuadrados del borde para que se distingan y sean el borde del mapa.

Para la serpiente, lo que hice fue simplemente recorrer la estructura que la contenía (una lista, un array, etc) y por cada eslabón de la serpiente, dibujar en la pantalla un cuadrado (de color verde) en la posición x e y en donde estaba esa parte de la serpiente.

El movimiento de la serpiente es simplemente recorrer de nuevo el array que contiene la serpiente y por cada eslabón avanzar hacia una casilla correspondiente dependiendo la dirección indica la casilla actual. Esto se puede hacer fácilmente con un switch y aprovechando el enum que mencioné en la parte 1.

Entonces por ejemplo, si la casilla [1][1] tiene dirección arriba, indicamos que este eslabón de la serpiente ahora está en la casilla [2][1] (contando de arriba para abajo en filas) haciendo algo del estilo "eslabón->posiciónY++". No debemos olvidarnos de dos cosas importantes: 

• La cabeza tiene que marcar de nuevo la dirección nueva.
• Hay que borrar la dirección de la casilla de la última parte de la serpiente.

Lo primero es porque, una vez que toda la serpiente se mueve, la cabeza tiene que seguir indicando la dirección que tiene que seguir el cuerpo. Si no, sería el equivalente a que en un tren en marcha, la locomotora se desenganche y frene, sabemos que si esto pasa, los vagones van a chocar y apilarse con la locomotora.

Para la comida podemos hacer algo muy simple. Declarar 2 variables de tipo int indicando la posición x e y de la comida. Darle un valor aleatorio a estas posiciones y luego, mostrarlo en el mapa con un color distinto.

Para saber si la serpiente comió o no la comida lo que podemos hacer es que en cada movimiento que pase, la cabeza de la serpiente pregunte "¿mi casilla siguiente es la posición x y la posición y de la comida?" si la respuesta es si, agregamos un eslabón a la serpiente (agregar un elemento al array o a la lista) y ahora le decimos que la cabeza esta en donde estaba la comida. De esta forma, la serpiente se "agrandó".

De esta forma ya tenemos una serpiente que se puede mover y crecer al comer.

En la tercer parte voy a explicar los detalles finales como cómo hacer para que se pueda mover de un borde de la pantalla a otra o saber si se mordió a si misma.

Hasta la próxima.

-L

C++ Snake Dev Guide Part 1

Primera parte: Estructura de la serpiente

Lo primero que vamos a hacer es pensar cómo va a ser la estructura que va a representar a la serpiente y que funcionalidad va a tener, eso nos va a dar una idea de como deberían funcionar las demás cosas:

El juego de Snake tiene una mecánica simple que se puede reducir en 3 reglas:

• Para agrandar la serpiente hay que comer la comida del mapa.
• El cuerpo debe seguir la trayectoria de la cabeza
• Hay que evitar que la serpiente muerda su propio cuerpo

Esto ya nos da una idea general de como armar la serpiente. Por un lado, tenemos que el cuerpo tiene que "seguir" a la cabeza siguiendo la trayectoria que el jugador le indique. Esto nos da un indicio de que podemos subdividir el cuerpo de la serpiente en Cabeza y Cuerpo.

La pregunta ahora sería: ¿Cómo hacer para que el cuerpo pueda seguir la trayectoria?

Podemos pensarlo de la siguiente manera:

Podríamos dejar en el tablero "direcciones" que tiene que seguir el cuerpo, por ejemplo que en la casilla [2][3] del tablero haya algo que diga "ARRIBA" así el cuerpo sabe hacia donde tiene que ir.

Si queremos hacerlo de esta manera, nuestro tablero tiene que poder guardar las direcciones que el jugador le va asignando.

Por lo tanto, podemos crear una estructura auxiliar para las casillas del tablero. Una estructura que guarde la posición x e y de la casilla y la dirección que puede tener. Luego, el tablero va a estar compuesto de casillas. Para las distintas direcciones es recomendable utilizar un enum, ya que facilita el uso general.

Lo último que falta es borrar las direcciones cuando la última parte del cuerpo (la cola de la serpiente) ya pasó por ella. Para esto podríamos distinguir la serpiente entre Cabeza-Cuerpo-Cola o dejarlo como Cabeza-Cuerpo.

La gran ventaja que tiene esta forma es que podemos también saber cuando la serpiente se muerde a sí misma! Como la cabeza es la que marca las direcciones, siempre debería entrar a casillas que no tengan dirección (o tengan dirección "NONE"). Por lo tanto, si la cabeza entra en una casilla que ya tenía asignada una dirección, significa que la cola todavía no pasó por ahí y no borró esa dirección. Entonces, significa que la serpiente se mordió a si misma.

Así que de esta manera podemos hacer que el cuerpo siga una trayectoria y tenemos también una forma de saber si el jugador perdió o no.

En la próxima parte vamos a ver cómo hacer el movimiento y cómo crear la comida y hacer que la serpiente crezca.

Hasta la próxima.

-L

C++ Snake

De nuevo al proyecto de Snake!

Debido a que el artista que trabaja conmigo en Rock Climber esta de vacaciones, no pude avanzar más en ese proyecto, por lo que decidí volver a esta idea que tenía de hacer un Snake en C++ para enseñarme a mi mismo como usar el lenguaje.

Así que borré todo lo que había hecho (muy poco) y decidí comenzar de nuevo. Primero definí como estructurar a la serpiente, sabiendo que lo más importante es que el cuerpo tiene que seguir la trayectoria que el jugador hace y luego, dedicarme en el tablero.

A mi sorpresa, si bien hubieron algunas partes en las que me atasqué, el juego esta terminado! Pueden ver el código en Github así también como una rápida guía de como ejecutarlo (Para S.O. Linux, no fue probado en Windows).

Es un juego simple y cumplió su propósito, aprendí a como utilizar una librería gráfica (OpenGL) para crear una ventana y para dibujar en ella, aunque esto lo hice mediante a un framework llamado "Glut" que facilita mucho el trabajo.

En lo que más me atasqué fueron errores de sintaxis del lenguaje o de relación entre los archivos, como por ejemplo cómo hacer para que el archivo que tiene la mecánica de la serpiente pueda acceder al tablero que esta en otro archivo. Por suerte muchos foros en internet sobre Glut o directamente sobre C++ tenían las respuestas, así que no fueron graves problemas.

Próximamente voy a estar subiendo unos posts explicando una par de decisiones que tomé para el diseño del juego. Que también le pueden servir de guía para quien quiera armar el juego también!

Hasta la próxima.

-L