SINO y la Global Game Jam

capturePasó otra GGJ y con esta, según me han dicho, son 7 años seguidos participando. En esas furiosas 48 horas de código, ninguna hora de descanso y de ideas alocadas, siempre termina saliendo algún juego que nos divierte, a nosotros como programadores, y colateralmente, a los usuarios del mismo.

Después de 7 años, la evolución en los juegos que hacemos se nota. De tomarnos las 48 horas para hacer un runner, a tomarme 2 horas en hacer otro en la actualidad. De intentar agregar gráficos para suplir la falencia técnica, a enfocarnos en la mecánica del juego como elemento principal, incluso si este análisis nos consume la mayoría del tiempo.

Llegué tarde, no pude escuchar la consigna ni ver los videos introductorios, pero la cosa decía algo como: Ondas u olas (Waves).

Como siempre, corrieron muchas ideas, intercambiando con todos las diferentes posibilidades. Y como siempre, muy entrada la noche del primer día, no teníamos mucho. Aparecieron arduinos, gamepads, frameworks, motores de física. Probamos algunas ideas con Phaser, pero como en otras oportunidades, el framework y las diferentes implementaciones de los motores de física nos defraudaron. Era hora de arremangarse y codear todo (O casi todo).

wp_20170123_001 wp_20170123_002 wp_20170123_003

Muchas horas de ecuaciones más tarde… llegamos a lo que necesitábamos y por fin teníamos el núcleo del juego andando.

Sino parece simple, pero es un juego sustentado por la matemática. No solo para dibujar una onda en la pantalla sino por poder modificar esa onda y desplazarse por la misma. Entender como el tiempo, frecuencias, amplitudes y fases impactan en el cálculo y el estado de la onda. Un juego que, de alguna forma, nos recordó a RouteLoop, otro resultado de una GameJam donde las matemáticas eran la columna que lo sostenía todo.

Y como ya estábamos con el cerebro en funcionamiento, este juego también se llevó de premio un creador de mapas mediante imágenes.

map1 map2 map3 map4

 

 

Cada mapa, en vez de ser escrito en el código, es tomado desde una pequeña imagen y reconstruido en el juego. Si bien es una técnica bastante conocida, se suele pasar por alto. En mi caso fue un momento de nirvana cuando mi compañero de equipo me dijo: Leamos el mapa desde una imagen!

Simplemente mi cabeza explotó y se puso a trabajar en el código para que eso fuera realidad.

El resultado de todo esto se encuentra en GitHub: https://github.com/MatiasIac/Sino

Una Jam extraña, o diferente a otras, tal vez reflejo de esos 6 años de participación.


El semi juego de la Iaconus Jam

cobraEl fin de semana se hizo la “Iaconus Jam“. Una micro jam para aprender a desarrollar videojuegos. La consigna era simple: Hacer un videojuego solo con código y en un lenguaje que jamás hayas usado. O sea, aprenderlo en el momento y tratar de hacer un videojuego con lo que pudieras aprender en 8 horas.
En mi caso opté por entrar a Wikipedia y elegir de forma pseudo aleatoria un lenguaje de la lista (https://en.wikipedia.org/wiki/List_of_programming_languages). Si bien había evaluado opciones como Go, hubo uno que me llamó la atención (Por su nombre): COBRA. (http://cobra-language.com/)

La experiencia fue rara. Si bien así arranqué con Python hace mucho tiempo atrás, en este caso, hubo algunos sinsabores. El concepto de Cobra es interesante: Una combinación entre Python, Ruby y Visual Basic, algo de funcional, algo de tipado, algo de dinámico, todo esto pudiendo compilarse para MacOS, Linux y Windows, más poder usar assemblies de .Net.

Lo malo es que el lenguaje parece haber sido abandonado en 2013. Originalmente soportaba diferentes frameworks para el desarrollo de videojuegos, entre ellos el viejo XNA. Muerto como posiblemente lo está Cobra.

En resumen, es un interesante lenguaje para experimentar, con una idea interesante por detrás, pero que como muchos, si no son víctimas del hype generado en la comunidad técnica, tienden a desaparecer y olvidarse.

Si quieren descargar el código y el juego (Necesitarán, posiblemente, Cobra en sus máquinas): https://dl.dropboxusercontent.com/u/20372392/Cobra/CobraGame.zip

¿Que lenguaje han usado recientemente que no esté en la lista de los convencionales?

 


Evento en Córdoba – Iaconus Game Jam

Eso… que la muchachada se compó y quiere hacer una Jam de 8 horas para hacer videojuegos. La idea es ir a aprender y hacer un juego con lenguajes y herramientas que no sepas. Nada de ir con el juego de herramientas que te sabes de memoria. Es ir y aprender ahí… y que salga lo que salga.

Los espero.


Aprendiendo Python

13716004_10154359822774314_7376618903244361115_nAyer participé de la Millennial Game Jam en Córdoba. Como en todas las Game Jams, el objetivo era crear algún juego en un lapso corto de tiempo. En esta oportunidad, menos de 6 horas (Muy corto lapso de tiempo).

Pero mi objetivo era ligeramente diferente al de la Jam. Si bien sí iba a crear un videojuego, lo principal era hacerlo en algún lenguaje de programación que no conociera y en algún framework que tampoco supiera nada de él.

Hacía un tiempo que quería aprender algo de Python pero no había encontrado la oportunidad ni la motivación para hacerlo. Así que esta Jam era esa oportunidad.

En menos de 6 horas, con el equipo que decidió sumarse a esta loca idea, hicimos un prototipo de juego usando Python 2.7 y Pygame.

Por supuesto, el código creado no fue de lo mejor, pero fue suficiente para justificar el tiempo.

Si quieres ver un poco el código: https://github.com/MatiasIac/millenialGJ


Ya en librerías

Programación de videojuegosFinalmente el libro de desarrollo de videojuegos con HTML5 y JavaScript ha salido a la luz.

En Argentina, puedes conseguirlo en librerías y kioskos, así cómo desde la página de la editorial.

http://www.redusers.com/noticias/publicaciones/programacion-de-videojuegos/


El indie no profesional

El año pasado escribía una nota para la revista digital Metropía sobre el mundo indie del desarrollo de videojuegos. Lamentablemente la revista aparentemente dejó de publicarse y la nota nunca llegó a hacerse visible.

Dejo a continuación esta nota que no pudo ver la luz.

El indie no profesional

En el anterior artículo hacía referencia a que todo lo que hacemos, aunque hagamos videojuegos, se refiere a código y que podemos gestionar el desarrollo de nuestra criatura mediante las prácticas que han sido implementadas por esta profesión; la del desarrollo de software.

Y que si bien podemos tener una gran carga de componentes visuales, o que el peso de nuestro videojuego esté sobre el arte y no el código, no quita que no podamos manejarnos de forma ordenada y gestionar correctamente el proceso. Concluíamos en ese momento, entonces, que todo era software.

Ahora, podemos haber seguido el manual, tener nuestras herramientas de software listas, pretender usarlas, pero así y todo fracasar. Aunque aquí es necesario hacer un pequeño paréntesis, ya que no hay una fórmula del éxito (Aunque algunos quieran hacernos creer que sí existe) ya que aquello que le sirvió a uno para alcanzar ese éxito, puede ser totalmente irrelevante o contraria al mismo para otros; por lo que en lo que se refiere al fracaso, podemos hacerlo de tantas formas como podamos imaginar, aunque hay una que es una garantía: La falta de profesionalismo.

 

La manada indie

Y es que cuando hablamos de indies, por lo menos en estas zonas, es normal encontrarnos con un grupo de personas (2 o 3) que optaron por juntarse para hacer un videojuego. Muchas veces, sin experiencia en la producción de una cosa, más allá del haber trabajado de forma independiente sobre proyectos personales donde los tiempos no fueron medidos, las relaciones interpersonales no se ejercitaron, las costumbres no se afianzaron y así una larga lista de atributos que se requieren desde lo profesional y que nunca se pusieron en práctica. No somos más que un grupo de felinos que se juntaron momentáneamente para darle caza a un animal grande, pero que ninguno de los gatos involucrados ha cazado más que pequeños ratones.

Nos juntamos como una manda de individuos queriendo hacer que nuestras personalidades sean las que estén por arriba de las otras. Pretendiendo liderar al grupo cuando todos estamos pretendiendo lo mismo porque, en definitiva, el ratón que cazamos alguna vez nos pareció el más terrible adversario que jamás alguien haya cazado.

Por supuesto, esto es un camino al fracaso por obvias razones: Cada miembro del grupo pretendiendo que las cosas se hagan a su manera, desoyendo al resto.

Pero hay un fracaso aún peor: Que el proyecto salga relativamente bien.

Y es que, como decíamos al principio, puede que lo que funcione para unos no lo haga para otros y de igual forma en sentido opuesto. Tal vez el peor escenario, entonces, sea que un grupo sin experiencia alguna y con condiciones como las descritas tenga un relativo éxito. Al hacerlo, las malas prácticas se instaurarán y serán el patrón a seguir para futuros proyectos.

Imaginemos a un niño que mete sus dedos en el enchufe, pero en ese momento no había electricidad. Luego, toca un cable pelado, pero tampoco había electricidad. Este niño ha aprendido que tanto meter los dedos en el enchufe como tocar cables pelados no representan peligro alguno. Un día, decide tocar una línea de alta tensión sin fallas: El resultado es evidente.

 

El profesional

Tratando de no generar una fórmula sobre el “cómo ser profesional”, vamos a generar una lista de actitudes que podríamos considerar profesionales a la hora de encarar un proyecto, en especial, sobre las conductas. Pero como la idea es no tomarlas como LA FORMULA, todas son objetables y pueden ser tiradas a la basura con total tranquilidad.

1) Comunicar.

¿No compartes tus ideas y planes del proyecto con el resto del equipo? ¿Consideras que es más fácil hablar contigo que con los que te rodean? ¿Prefieres tomar las riendas con el cliente y luego avisarles al resto del equipo lo que hayas decidido (Sin consultar antes)?

Si respondes con un sí, o con un “a veces”, entonces estás en problemas. Si eres parte de un equipo, y el equipo también debe trabajar en el proyecto, pretender dejarlo de lado en decisiones en las que ellos también estarán involucrados, entonces no estás siendo profesional.

Imagina una situación en la cual estás muy tranquilo en tu casa, jugando a ese juego que tanto amas y repentinamente te desconectan tu consola o computadora y se la llevan. Cuando preguntas, resulta que tu compañero/a, amigo/a, esposo/a (Bueno, se entiende), decidió vender ese aparato porqué necesitaba el espacio para colocar la foto del perro (Vale aclarar que el marco de la foto es hermoso).

En un paralelismo, no te sentirías muy a gusto si alguien en tu equipo te avisara que estás atrasado en el proyecto simplemente porque él decidió, junto al cliente, que era mejor adelantar la fecha de entrega dos semanas. O, que tu decidiste, el último día, cuando había que entregar todo, que necesitas dos semanas más porqué te diste cuenta que no llegabas con los tiempos pactados.

2) Compromisos.

Así como una buena comunicación es parte del compromiso como profesionales, existen cientos de forma de faltar a los compromisos. Desde no cumplir con una fecha de entrega hasta no llegar a tiempo a una reunión.

Puedes poner a prueba que tan comprometido estás con el proyecto analizando cuantas veces has llegado a una reunión en el horario que se había estipulado. Aquí no hablamos de salidas nocturnas, casamientos o cumpleaños, donde no queremos ser los primeros en llegar y por lo tanto tendemos a aparecernos 30 minutos (O más, mucho más) más tarde que la hora pactada. El tiempo cuesta dinero, tanto dentro de nuestro equipo como para un cliente, por lo que esperarnos es un problema, así como lo es esperar a alguien.

Es común en la gestión de proyectos (Y dependiendo del marco de gestión utilizado) realizar reuniones diarias para sincronizar el equipo, el no asistir o necesitar que tu jefe, administrador, compañero, etc., deba buscarte para que asistas, es otra demostración de falta de profesionalismo.

3) Estimaciones.

Sumado a la idea anterior de compromiso, la ausencia de profesionalismo se denota en aquellos que al recibir una tarea comienzan desenfrenadamente a realizarla sin agotar dudas y peor aún, sin haber estimado el tiempo necesario para realizarla.

Parte de la gestión de un proyecto se centra en conocer el tiempo necesario para desarrollar parte o la totalidad de la cosa a producir. El tiempo es traducido a dinero. Si necesitamos mucho tiempo para producir algo, este tiempo requerirá de un volumen de dinero diferente a si tardamos poco. También, tardar mucho puede impactar en la salida al mercado donde competidores podrían obtener un producto similar antes y ganar clientes primero, lo que nos impactaría en nuestro bolsillo. Por último (Aunque hay más variantes), mucho tiempo estimado de producción pero una necesidad de salir antes al mercado con el producto, hace que se analicen las posibilidades de recortar el producto o de gastar más dinero por medio de más gente produciendo la cosa y que esta esté lista antes.

En definitiva: Saber estimar el trabajo es vital.

4) Calidad.

La calidad no se resume en que tan bien sabemos dibujar y pintar, o si nuestras líneas de código se ven armónicas. La calidad incluye otros factores más allá de las habilidades adquiridas con la práctica.

Si somos artistas, no realizar una revisión de lo pedido, si cumple con todos los puntos que el cliente espera; nombres de archivos, orden de capas en un PSD, haber entendido y aplicado todo lo descrito en los requerimientos. Es sinónimo de falta de profesionalismo.

De igual forma, en el código, el entregar funcionalidades incompletas o con errores, incurre en problemas similares. Por supuesto somos falibles y el cansancio después de horas de trabajo, distracciones cotidianas y demás hace que cometamos errores, y son esperables. De cualquier manera, existen límites dentro de esos errores.

5) No aprender.

Tal vez todo lo anterior es subsanable ya que con el error, con la equivocación aprendemos. El problema mayúsculo está cuando no aprendemos. Repetir una y otra vez las mismas acciones esperando que haya un cambio es una locura, pero también es clara señal de que no estamos aprendiendo de nuestros errores. Si no podemos aprender, no podremos cambiar nada de lo anterior.

Pero no siempre se debe a nosotros sino a ambientes que impiden equivocarse. Mejor dicho, que prohíben equivocarse. Si bien no es lo mismo equivocarse en algo que pueda causar una catástrofe a equivocarse en la cantidad de balas que salen de un enemigo en un videojuego. De cualquier manera, existen lugares, tanto en los que podemos estar como en los que podemos estar promoviendo, donde la equivocación se castiga de forma severa. Tan severa que genera estancamiento en las personas: Al tener un miedo terrible a equivocarse, nunca tomarán una decisión esperando que el castigador las tome por él.

Lo anterior impacta en prácticamente todo; no estimaré mi trabajo porque si me comprometo y me equivoco me castigarán; no comunicaré que estoy atrasándome debido a que tengo muchas distracciones porque me castigarán.

Dejar equivocarse es importante y al mismo tiempo entender en qué nos hemos equivocado es más importante aún.

En resumen

Por supuesto, hay muchos otros elementos que nos acercan al profesionalismo. Por otro lado, ser profesional no quita que nos podamos divertir y pasarla bien haciendo videojuegos, pero es necesario que nos tomemos seriamente el desarrollo de nuestro videojuego. No importa si somos un único individuo o si somos 10, mientras nos comportemos y actuemos profesionalmente. No hagamos que esa idea creativa sea manejada por una manada que se asocia casualmente, si no en un equipo que quiere conseguir un videojuego de verdad.


Nuevo libro sobre desarrollo de videojuegos

Mtapaucho tiempo sin publicar nada en el blog. El motivo: Estar escribiendo un nuevo libro durante los últimos 6 meses.

Este nuevo libro es sobre desarrollo de videojuegos con HTML5 y JavaScript. En este podremos aprender a crear nuestros propios frameworks, usar otros como Phaser, entender los conceptos detrás del desarrollo de videojuegos y mucho más.

El libro está pronto a salir (Mediados de Abril) y estará disponible en todas las librerías del país, así como en la mayoría de los países de habla hispana. Por supuesto, se podrá comprar online.