martes, 23 de abril de 2013

Colaboraciones: Mess! - Nuevo juego en Google Play

Hoy escribo mi post 250 y pensaba aprovecharlo para ordenar un poco toda la información y “cursos” que tengo en el Blog, pero me ha surgido otra cosa que tengo que comentar, así que lo dejo para más adelante, que además ya estoy trabajando en algo para tener más a mano todo lo escrito aquí.

Bien, como ya he comentado muchas veces siempre intento estar colaborando con alguien en pequeños proyectos en los que pueda aprender cosas y últimamente, que esta esto de las aplicaciones móviles de moda, me metí en un sencillo proyecto con un programador llamado Juan Iñiguez para conocer más sobre la forma en que se trabaja y se publica en un dispositivo móvil Android, tamaños y resoluciones de pantalla, etc.

El juego se llama “Mess!” (Messi no, Mess que significa desorden) y es de los más sencillos del género puzle y fue diseñado por el programador (Asi que se trata de una colaboración, no estoy metido en ningún grupo de desarrollo). Según me contó iba a probar la distribución gratuita para monetizar a través de la publicidad, así todos debéis saber que se puede descargar GRATIS en la siguiente dirección Web:

https://play.google.com/store/apps/details?id=com.movidev.mess#?t=W251bGwsMSwyLDIxMiwiY29tLm1vdmlkZXYubWVzcyJd

(Si me queréis bajarlo).

Terminada esta pequeña colaboración llega el momento de seguir con otro proyecto, también para plataformas móviles en el que estoy colaborando y, publicar de una vez, en cuanto pueda, el que estaba haciendo por mi cuenta en ActionScript para que se pueda jugar online. A ver si saco algún ratillo libre, que con las practicas en la empresa y un proyecto que tengo que hacer para mis estudios voy un poco atareado.

Bueno, dejo algunas capturas. Si os gustan los juegos de puzles, simplemente queréis echar un rato o sentís lastima de mí y habéis decidido apoyar mi causa de, pasito a pasito, convertirme en desarrollador de juegos, bajaros el juego a vuestro móvil Android, a ver si céntimo a céntimo me puedo financiar un proyecto grande en el futuro. :P

  



Por cierto, conviene recordar que también en google play y también gratis se puede descargar otro de los proyectos en los que he participado como grafista: Pixfrogger, en colaboración con Pixjuegos.

jueves, 18 de abril de 2013

Toodaim Blog: Cursos y concursos

Siempre estoy pensando para mis adentros que a ver si hablo un poco de la última iniciativa que mi colega Asensio está teniendo en su Blog (Toodaim Blog) y el canal de Youtube de Zarcort Gamer y a la que he dado mi apoyo de manera muyyyyyy distante (por falta de tiempo). Se trata del desarrollo de un videojuego de plataformas de forma social.(más info aquí)

¿Cómo funciona?

Se desarrollarán una serie de cursos y también concursos. Es decir, enseño a los usuarios como se tienen que hacer las cosas y organizo una competición para elegir a los mejores. Así, al final quedarían unos gráficos, una historia y un código fuente hechos entre una comunidad de personas y puestos en común para el desarrollo de un juego en GameMaker, junto, eso si, con todo lo que quede descartado para dicho juego que quedaría como una librería que se pueda usar en otros proyectos de forma gratuita. ¡Una gran idea!

Ya se ha puesto en marcha esta idea comenzando con unos videos dedicados a un pequeño curso de guión que han dado paso a la a un concurso de la misma temática. Así, la gente que lo desee, ya puede tomar nota de los consejos sobre cómo escribir una historia y crear su propuesta para el videojuego que será desarrollado posteriormente entre toda la comunidad formada. Incluso si luego se obtienen beneficios se podría llevar algo, así que hay que animarse.

Os dejo un enlace las bases del concurso: http://toodaim.blogspot.com.es/2013/04/videojuego-realizado-socialmente-bases.html

Pero antes de nada, pasad por la sección del Blog de este proyecto social dedicada al guión, donde por cierto, encontrareis enlaces a todos los artículos sobre técnicas de guión aplicadas a videojuegos que he escrito en estas páginas.

http://toodaim.blogspot.com.es/p/articulos-sobre-guion-de-videojuegos.html

Trabajad duro y mucha suerte.

(Si, hay muchos enlaces en este post, no os perdais entre ellos, que debeis volver a visitarme :P)


martes, 16 de abril de 2013

Adaptarse a otros lenguajes de programación

¿Qué pasa cuando alguien aprende un lenguaje concreto, como por ejemplo Java, y de pronto le toca tener que enfrentarse con otro? Pues que tiene que aprender, pero por suerte no es necesario que empiece de cero. Prácticamente todos los lenguajes tienen cosas en común, como bucles, condiciones, variables, etc. Sin embargo, es necesario conocer la sintaxis del nuevo lenguaje que vamos a utilizar y, siendo esto lo que más complica las cosas a veces, también nos tocará estudiarnos el nuevo entorno de trabajo que usaremos para programar, con los nuevos añadidos que ponen a este tipo de herramientas, para que cada vez parezca todo más sencillo por eso de que genera automáticamente gran parte del código.

Migrar a otro lenguaje es lo que me ha tocado estos días que estoy haciendo prácticas en una empresa de desarrollo Web (no, por desgracia no hago videojuegos). Y es que, habiendo aprendido PHP, Javascript, un poco de Java y un largo etc, en la ya mencionada empresa se trabaja con C# (Que me viene genial porque es el lenguaje recomendado para el motor Unity) y ASP.Net. Así que estoy pegándome con los nuevos conceptos del lenguaje que no conocía, la sintaxis (Que es muy parecida a otros lenguajes y tiene programación orientada a objetos) y, lo peor de todo, los nuevos componentes que usa Visual Studio de Microsoft para ponernos las cosas más fáciles a todos (aunque a veces lo que hace es fastidiar).

Es por esto de tener que tratar con distintos lenguajes y herramientas a lo largo de nuestra vida como programadores por lo que se nos dice que para aprender a programar se aprende metodología y no un lenguaje concreto, por lo que es bueno saber pensar en pseudocódigo y plantear los problemas antes de atacarlos y por lo que si uno aprende que algo se hace de una manera en un lenguaje tiene bastante menos trabajo para hacer eso mismo en otro diferente.

Así que ya sabéis, si vais a empezar a aprender programación de videojuegos quedaros con cómo se hace un scroll, se detectan colisiones o se pintan polígonos en pantalla más que como se programa en C, porque puede que tengáis que trabajar en Java y hacer las mismas cosas y, si conocéis el modo de resolver el problema, solo tenéis que traducir lo mismo al nuevo lenguaje (Al principio puede costar, pero con un buen manual de referencia pronto estaréis en marcha).

miércoles, 10 de abril de 2013

Juegos que me influyeron como desarrollador: Captain Tsubasa y juegos Galge

En realidad, en este caso estoy hablando de un estilo de juego concreto, muy japonés, que se basa en ir seleccionando opciones y observando cómo se desarrolla la historia dependiendo de nuestras elecciones. Se parece un poco a los libros de elige tu propia aventura.

Eran tiempos donde muchos íbamos al videoclub a alquilar videojuegos con los que disfrutar durante el fin de semana y donde los juegos de importación, con sus textos en japonés y todo, nos hacían descubrir aventuras que en aquel entonces no se publicaban en nuestro país. “Captain Tsubasa”, o como se conocía aquí (por la serie de dibujos) “Oliver y Benji” nos permitía jugar al futbol al más puro estilo Manga, con tiros a puerta y regates especiales y una narración en forma de viñetas animadas junto a un menú de opciones para elegir lo próximo que queriamos hacer. Una peculiaridad de este juego podría decirse que se parece bastante a los QuickTime Events que actualmente solemos ver, es decir, hay un enfrentamiento en la pantalla y nuestra única misión como jugadores dentro de la historia, es apretar el botón del mando lo más rápido que podamos para derrotar al adversario. En esa época, este tipo de gameplay en un juego donde nos movíamos prácticamente a base de menús, me parecía que tenía bastante sentido, pues sabíamos que la interactividad del producto se limitaba a un estilo concreto.




El tipo de juego en el que decidimos lo que va a ocurrir en la historia seleccionando acciones en forma de texto es bastante común en Japón, donde existe la narración de historias eróticas o con personajes Manga y/o Anime recurriendo a este tipo de género de videojuegos. Si hablamos de juegos eróticos, estos se conocen como Eroge, pero por otro lado, en cambio, los hay que se limitan a las conquistas amorosas o sexuales sin mostrar contenido demasiado explicito (Los llamados galges).
 



Es muy recomendable para todo equipo de desarrollo que empieza y dónde hay muchos grafistas pero pocos animadores y/o programadores, desarrollar un juego de las características de los mencionados en este post para lucir sus habilidades en la ilustración, ya que se trata de juegos muy estáticos. Lo difícil en este caso es que además de buenas imágenes, quien se embarque en el desarrollo de un juego donde la narración es casi todo texto, debe contar con habilidades para escribir una buena historia que enganche y que haga que al jugador no le importe tener poca interactividad y poder de decisión, sintiendo ganas de usar su imaginación para entrar a fondo en la trama.

Más información sobre este tipo de juegos pronto, en mi sección de diseño, cuando hable de este género en particular. :P


 

martes, 2 de abril de 2013

Más consejos para colaboraciones y proyectos en grupo

Después de un merecido descanso vacacional y de charlar con los implicados en un par de proyectillos (pequeños) en los que ando metido ahora, para aclarar que debemos hacer para terminarlos, he ido dándole vueltas a algunos consejillos más que se me quedaron sin comentar sobre cómo trabajar mejor en equipo cuando se trata de colaboraciones, y es que aunque ya escribí un post llamado “Experiencia en fracasos: Consejos para terminar proyectos en grupo” con el tiempo he aprendido nuevas cosas (y también he fracasado en muchos más proyectos)

Colaboraciones

A veces no se puede hablar de un proyecto en grupo, sino simplemente de una petición de alguien que ha planteado un juego, necesita ayuda para una parte del mismo, y nos pide participar para resolverla. Por ejemplo un programador que necesita un grafista para los gráficos de su actual idea, que ha oído que nosotros dibujamos bien, y nos pide que nos ocupemos de lo visual.

Respetar el proyecto original: En estos casos es muy importante ir a lo que nos piden y no meternos excesivamente en el trabajo del creador. Cada uno tiene la imagen final de su juego en la cabeza (aunque sabemos que luego no quedará exactamente como lo imaginamos) y no conviene que tratemos de “insertar” la imagen que nosotros tenemos del juego en la cabeza del otro. No es malo hacer sugerencias, pero si nos gusta por ejemplo el estilo Manga pero la persona que nos pidió la colaboración ya tenía claro un estilo realista y no lo acepta, no es buena idea insistir por que empezaran las discusiones y todo puede acabar con el juego a medias (Aquí somo unos "mandados", no nos pasemos de creativos).

Conocer el trabajo del otro: Primero, en el sentido de informarnos bien de la seriedad y forma de trabajar de la persona que nos ha pedido ayuda, para saber que nos va a exigir y que vamos a obtener de él/ella. Por ejemplo si sabemos que es una persona que tiene prisa por acabar el proyecto y le dedica todo su tiempo, pero nosotros solo podemos colaborar a tiempo parcial en nuestros ratos libres, es mejor dejarlo claro o no hacer la colaboración, porque no podremos dar todo lo que se nos vaya exigir.

Segundo también es bueno, aunque no imprescindible, conocer por ejemplo, si somos grafistas, la forma en que trabaja un programador para ver que va a necesitar y poder proporcionárselo con rapidez. No hablo de saberlo todo pero ahorra tiempo si, por ejemplo, nos hemos mirado un poco tanto unos como otros que motor usaremos para el juego y como funciona, los formatos que maneja, etc. También tenemos que saber en qué dispositivo o dispositivos finales se va a ejecutar y que limitaciones nos va a imponer de tamaño de archivos, colores, resolución...

Archivos temporales: Para acelerar el proceso, ayuda tener archivos temporales de lo que va a ser el proyecto final, tanto en documentos de diseño, como gráficos o incluso versiones del código. Con archivos temporales me refiero a algo así como prototipos. Por ejemplo el programador hace una versión del juego con cuadraditos para calcular donde tiene que situar cada cosa y, cuando tenga los gráficos definitivos hechos por el grafista, solo tiene que sustituir los cuadraditos por dichos gráficos.

Esto es aplicable también a otras tareas como la música, escenarios, etc.


Proyectos en grupo

Normas: Establecer normas de cara al grupo es muy importante para que ninguno meta la pata. Por ejemplo suele ser buena idea advertir a la gente que no comente o publique información del proyecto hasta que no haya terminado para no recibir presiones o influencias externas al equipo. Igualmente resulta útil dejar claro que ocurrirá con el material creador por las personas que dejen el juego en mitad de desarrollo.

Jefes: Esto ya lo comenté en el otro post, pero es importante dejarlo claro. Si hay una persona todoterreno (que domine varios roles como desarrollador) es el ideal para llevar el liderazgo del equipo, ya que va a entender que tareas están haciendo los grafistas, va a poder elegir con los programadores que motor usar (o trabajar desde cero) o incluso asesorar y organizar a músicos, guionistas, betatesters… Por otro lado si la idea de juego la ha tenido otra persona distinta a este “diseñador nato” conviene que compartan esa tarea para que haya buena organización, pero el proyecto no se aparte demasiado de la idea inicial. Suele ser un poco difícil trabajar en estos casos por que, si por ejemplo la idea original viene de un guionista sin muchos conocimientos técnicos, no le va a gustar nada cualquier limitación impuesta por parte del equipo de desarrollo.

Preproducción: Muy importante dedicar un tiempo a organizarse y decidir cómo se va a trabajar y con qué objetivos. Al contrario de lo que pueda parecer, una buena planificación acelera el proceso de desarrollo y nos evita problemas como podrían ser: Que un modelador use un programa y formato diferentes a otro, que haya dos guiones distintos moviéndose entre los miembros del grupo o que no estén claras algunas partes del gameplay y los programadores acaben teniendo que rehacer código.

Reuniones: Tampoco es ninguna pérdida de tiempo reunirse de vez en cuando, a través del medio que sea, para discutir cómo va el desarrollo, posibles cambios, ideas, problemas, etc. Como en los equipos a distancia entra y sale gente constantemente es muy probable que haya que reasignar tareas cada poco tiempo. Es, además, un buen momento para plantearse recortes si el tiempo requerido para finalizar el juego se está alargando demasiado y parece no tener fin. Es mejor tener un juego con menos niveles, armas o vehículos pero terminado, que uno con 500 armas, 90 niveles y 70 vehículos diferentes pero al que no se puede jugar porque está incompleto.

Paso a paso: Desde que la descubrí siempre voy a recomendar esta forma de trabajo. ¿Para qué vamos a pensar en un juego de 70 niveles, con una historia larga y un montón de características definidas desde un principio si no sabemos si vamos a terminar el primer nivel? Lo mejor suele ser dividir los objetivos e ir cumpliéndolos poco a poco, es decir: Vamos a hacer un juego de un nivel, con muy pocos personajes y unas acciones base, cuando esté terminado, nos reunimos y vemos como está el ánimo para añadir un segundo nivel. Algo así como hacer un juego por capítulos con su historia y detalles cerrados e ir cumpliendo metas. Ya veremos si al terminar fuimos capaces de hacer un minijuego, un megaproyecto o tres pequeños pero diferentes.