Mostrando las entradas con la etiqueta Pirates Tycoon. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Pirates Tycoon. Mostrar todas las entradas

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

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