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