domingo, 6 de mayo de 2018

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

miércoles, 18 de abril de 2018

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

martes, 20 de febrero de 2018

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

domingo, 11 de febrero de 2018

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

lunes, 29 de enero de 2018

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