Ya actualizando los artículos publicados aquí, luego de mejorarlos y traducirlos.

Los espero entonces por allá.

Hace tiempo les comenté sobre mi forma de ver el Global Game Jam y les recomiendo la lean si aun no lo han hecho. Esta vez quiero compartir sobre cómo sobrevivir un game jam pero en la parte logística de todo el evento y de cómo encarar ese fin de semana entre Enero y Febrero donde nos reunimos a hacer un juego por las simples ganas de hacerlo.

Esta entrada va enfocada en la parte física de nosotros mismos: comida, refugio, transporte, servicios básicos, etc. Saber de antemano las condiciones en la que estaremos nos ayudará a planificar mejor el fin de semana, lo que al final trae como consecuencia un mayor disfrute del evento por cuanto estaremos enfocados en lo que más nos interesa: trabajar en nuestro juego.

Duerme bien y descansa suficiente durante la semana

Se comienza el último Viernes de Enero. Si aun estás destruido cansado de las fiestas de Diciembre, más vale que cojas mínimo tomes un respiro. Hay que sacarle el mayor provecho a esas 48 horas, aunque tampoco la idea es dejar de dormir y estar en vela; pero lo común es entre tres y cinco horas de sueño.

Quiero aclarar que esto depende de cada participante y no hay nada obligatorio, todos somos solidarios; pero es normal dormir poco con la fecha límite tan cerca (cualquier estudiante universitario que trabaje en base a proyectos lo sabe).

Revisa, con antelación, la ubicación del evento

Con la finalidad de estar allá de forma puntual. Esto también nos ayuda a evaluar las opciones de transporte disponible durante el fin de semana y, de ese modo, planificar la forma de ir y regresar del evento. Por ser un evento que se hace por amor al arte, no es común que los organizadores aseguren el transporte; por lo que aconsejo tomar previsiones y manifestar inquietudes a los organizadores si lo consideran necesario. Así mismo, siempre es bueno que investigues de las comodidades que hay a los alrededores (locales de comida, supermercados, farmacias, etc.).

Se estila que los participantes lleguemos al menos una hora antes de dar inicio al evento para que nos vayamos conociendo, formalizar la inscripción (de ser necesario), y manifestar cualquier tipo de inquietud a los organizadores con el tiempo suficiente para que nos puedan colaborar en lo que pueda estar en sus manos. Es importante ir conociendo qué asistentes pueden aportar valor a tu equipo (si necesitas arte, sonido, programación) y con cuales sientes mayor empatía al comunicarte. Al final, siempre es bueno conocerlos a todos para tener una mayor red de desarrolladores para colaboraciones/reuniones futuras.

Pregunta sobre las comodidades de la locación

La gente del Global Game Jam pide a sus sedes que como mínimo aseguren un sitio espacioso para trabajar y descansar, acceso a Internet de forma gratuita y preferiblemente puedan estar abiertas durante todo el fin de semana. Más allá de eso, hay que revisar lo que los organizadores locales nos pueden ofrecer. ¿Por qué? Para saber si es necesario llevar nuestros equipos o si, de llegar a ofrecerse, los equipos que nos puedan prestar están en la capacidad legal y técnica de tener las herramientas de desarrollo con las cuales tenemos pensado trabajar.

Lo común es que cada quien lleve sus equipos, pero siempre es bueno preguntar porque puede que en nuestro caso no se requiera tal cosa.

Si eres alguien exigente/cuidadoso con lo que trabaja, entonces siempre es bueno llevarnos el juego de ratón y teclado, mousepad, monitor, puff o lo que sea que podamos llevar y nos ayude a estar cómodos. Asegúrate primero de que en efecto puedes llevarlo .

Para el caso de la gente que necesita trabajar con música de fondo y quienes van a colaborar en la parte de sonido: lleven sus propios audífonos. Recomiendo altamente usar headphones en vez de earphones por cuanto serán sesiones prolongadas (es mi responsabilidad aconsejarlos en salud jaja).

Demás está decir que no necesariamente hay servicio telefónico, entonces lleva un teléfono móvil/celular con línea activa y saldo si lo crees conveniente.

Planifica la estadía

Teniendo claro si hay acceso para “alojarte” en las instalaciones sabrás aprovechar mejor el tiempo para desarrollar el juego. En el caso de existir alojamiento, tomar en cuenta bolsas de dormir, colchones inflables, ropa adicional, cepillo/pasta dental, y demás objetos de uso personal. Si vas a ir y venir, es bueno que lo comentes con prudencia a tus compañeros de equipo y estés consciente que tu participación siempre es importante.

Digo “alojamiento” porque son condiciones especiales. Los organizadores tienen este punto como segunda o tercera prioridad; pero si tienes inquietudes, pregunta. Usualmente las sedes del Global Game Jam son universidades o instituciones educativas, por lo que se duerme en el mismo salón o en un salón espacioso cercano al área de desarrollo.

Planifica las comidas

Dependiendo de la ubicación del evento, será sencillo o complicado conseguir alimento durante el fin de semana. Los organizadores suelen tener este punto con una prioridad bastante alta, pero siempre es bueno que los participantes mostremos interés; tanto con inquietudes como con colaboración, si se presentan dificultades. No obstante, el gasto corre por nuestra cuenta.

Si eres alguien ansioso, recomiendo llevar tus propias chucherís, café, etc. y llevar para compartir .

Crea un presupuesto

Con todo lo anterior ya tomado en cuenta, crea cierto presupuesto a partir de la información recolectada en base a nuestra investigación y de las inquietudes respondidas por los organizadores. Dejo una chuleta para tomar en cuenta:

• Transporte.
• Alimentación (cena del Viernes, tres comidas del Sábado, dos comidas del Domingo) y cualquier otro snack.
• Un 10% del total para cualquier emergencia.

Eso es, a mi modo de ver, lo necesario para sobrevivir un game jam. La entrada tiene cierta extensión, pero al llevarla a la práctica es mucho más sencillo y lo que busco es tener un punto de referencia lo más completo posible para que el fin de semana esté dedicado, en su totalidad, a pasar un buen rato haciendo juegos y compartiendo con personas con los mismos intereses.

Crédito de las imágenes: Nintendo (The Legend of Zelda, The New Super Mario Bros. y Pokémon son propiedad de su autor).

Tiempo sin aparecer por el blog. Como nuevo USBista aun me estoy adaptando al ritmo de la universidad tal y como lo pueden ver aquí. A partir de las clases con Monascal, me he percatado que es de suma importancia para cualquier programador, en nuestro caso programador de juegos, conocer las herramientas que tenemos a nuestra disposición para resolver problemas. Luego de nuestra mente, la siguiente herramienta no son los motores gráficos, ni los lenguajes de desarrollo… ¡son los algoritmos!

Lo que nos ayuda a ser mejores programadores es tener el mayor conocimiento posible de algoritmos. De este modo, podremos atacar un mayor rango de problemas y enfrentarlos de forma eficiente. Bien sea porque necesitamos de la solución correcta o de la más rápida (usualmente es ésta última en nuestro campo). Todo problema puede ser descompuesto en sub-problemas más pequeños hasta llevarlo a un problema trivial sencillo de resolver. Algunas veces nos interesa, y otras no (ahí es cuando entra en escena el uso de motores, frameworks, APIs, etc.). Bien sea que Halo 38479 tenga efectos visuales que te hagan decir que en HD se ve mejor que en la vida misma, pasando por el efecto del balón en FIFA 2100pre (chiste interno Venezolano), hasta llegar a los zombies de Left 4 Dead. Los unas con principios matemáticos, estadísticos, físicos, etc… todo se resume en eso; al-go-rit-mos.

Los que tienen ya cierto conocimiento del tema probablemente estén familiarizados con las competencias o maratones de programación. Participar en ellos, como un medio para lograr nuestro fin, es sencillamente invaluable. Todo el que pueda debería hacerlo al menos un par de veces. Participar, y entrenar, para los maratones es bien positivo por dos razones; 1) te ayuda a elevar tu nivel de abstracción para re-plantear los problemas a fin de que puedas resolverlos de forma eficiente y 2) lograr hacerlo en un lapso bien restringido.

¿Resultados? Un mejor desempeño en el producto final y personal. Cualquiera que haya participado en un Game Jam, o está en la industria, lo sabe. Un juego que está desarrollado con algoritmos eficientes tiene mejor respuesta ante el jugador, corre en una mayor cantidad de equipos (en el caso de computadoras personales) y esto se traduce en éxito del juego que, a su vez, es beneficio monetario para la casa. Por otra parte, tener habilidad para resolver problemas de manera rápida nos ayudará  pasar menos horas extra frente al trabajo y más tiempo con el ocio/entretenimiento (así éste último sea seguir programando cualquier otra cosa).

Sin embargo, estudiar algo de forma purista puede tornarse un poco aburrido y para ellos hay soluciones interesantes. Recordemos que nosotros queremos programar juegos, por lo que tenemos una herramienta a nuestro favor. Algunos algoritmos nos pueden ayudar a crear juegos tipo puzzle; tal el es el caso de BFS (o búsqueda en anchura). Este algoritmo para recorrer grafos es el idóneo a aplicar al desarrollar el juego Buscaminas. Así como ése, hay otros ejemplos con áreas de interés bien definida; Inteligencia Artificial, Computación Gráfica, etc. A fin de adquirir experiencia, tanto en algoritmia como programación de juegos es recomendable hacer pequeños demos o “juguetes” en la medida de lo posible.

Ok troll Jorge, estoy convencido; ¿y por dónde comienzo? Mi actual profesor de algoritmia ya tiene un blog dedicado al tema de los maratones. Mi recomendación es que lo lean y le hagan preguntas sobre lo que va escribiendo, o le pidan abordar algún tema de interés. Estoy convencido que, dentro de sus posibilidades, hará todo lo posible para atender sus inquietudes. Para quien tenga muy poca o ninguna experiencia, ésta es la entrada que deben leer en su blog para comenzar.

Sólo me resta decirles que disfruten sus sesiones de estudio, programación y me digan luego cómo les resultó el experimento.

Luego de haber participado en los dos Caracas Game Jam (parte del Global Game Jam), considero que tengo cierta experiencia adquirida y que, desde luego, vale la pena compartir. Esta entrada refleja mi percepción de lo que es el Global Game Jam, por lo que te invito a participar en uno para que tengas la propia.

En pocas palabras, el Global Game Jam es un evento social donde varias personas se reúnen el último fin de semana de Enero con la excusa/reto de hacer un juego en 48 horas. Digo esto porque desde fuera, e incluso desde dentro, puede llegar a ser visto como una competencia donde hay ganadores y perdedores. Realmente eso no es así, o afortunadamente en Venezuela no lo he percibido. Todos ganan por dos sencillas razones: diversión y aprendizaje. Quien entre en un Game Jam por aquello de que “yo soy el chivo que más mea mejor que tú y te lo quiero lanzar en cara”, considero está meando fuera del perol desubicado en la vida.

El principal beneficio de todo esto, sobretodo en países donde la industria de los juegos se encuentra en desarrollo, es la oportunidad de conocer personas con tus propios intereses; gente creativa y talentosa y, desde luego, es lo que más disfruto. He podido formar lazos de amistad, con buena parte de los participantes, que va más allá de la computación y los juegos. Por otra parte, es una excelente oportunidad para poner tus habilidades a prueba y, sobre todo, aprender de los otros participantes.

Cada año, el Global Game Jam tiene una temática distinta a la cual se le agregan requerimientos adicionales obligatorios y otros requerimientos especiales de valor agregado. Contrariamente a los que muchos podrían pensar, estas limitantes ayudan a crear un juego de manera, si se quiere, más rápida. ¿Cómo? Al estar nuestra imaginación enfocada en la temática y requerimientos, es más sencillo buscar la forma de explotar todos los recursos a fin de lograr el objetivo. Esto no es algo que digo yo, sino toda la comunidad; por ejemplo la gente del Experimental Gameplay Project en su publicación de Cómo hacer un prototipo de juego en 7 dís (artículo en Inglés):

Nuestros juegos más exitosos nacieron de temas o juguetes específicos, como “gravedad” o “enjambre” o “haz un juego destinado a un público predominantemente femenino”. De alguna forma, fue más sencillo ser creativo cuando hubo restricciones.

Adicionalmente, con un equipo donde todos están generando prototipos acerca de un mismo tema, y de forma simultánea, había cierta garantía que evitaríamos atacar la misma mecánica. De este modo, nos retamos a explorar y realmente sacarle todo el jugo al tema a fin de obtener todas las mecánicas posibles.

Dada la temática, es hora de comenzar a reunirse en equipos si aun no posees ninguno. Dependiendo de la magnitud del evento, hay una presentación de cada uno de los participantes previo al inicio oficial del jam. Por otra parte, usualmente la lista de participantes tiene un campo destinado a colocar la especialidad de cada uno para ubicar de forma más sencilla a ese recurso que te hace falta (programación, arte, sonido); así como también distintivos para colocarte en un sitio visible con tu nombre y especialidades.

Mi distintivo del Caracas Game Jam 2009

La idea de reunirse en equipos es por la sencilla razón de que un trabajo en equipo, dada las condiciones, puede resultar más provechoso que el trabajo en soledad. Eso es así y punto (ejm: empresas, matrimonios, sociedades, estudios). Se asemeja a la división por grupos de trabajo para entregar en un proyecto académico y no a la división por equipos en una liga de fútbol (donde se lucha por una copa), por ejemplo. Digo esto porque hay gente que deja de participar porque “su equipo” no está completo. Insisto, es un evento social; por lo que es muy positivo que nuevos equipos y amistades se formen a partir del mismo.

Todo el evento, como lo indiqué en un principio, dura 48 horas. Estas 48 horas engloban todo el proceso de desarrollo de un juego (origen de la idea, planificación, desarrollo -código, arte, música- y lanzamiento). ¿Lanzamiento? Sí, hay que subir los fuentes y ejecutable del juego al servidor del Global Game Jam. No tendrá los bombos y platillos de Halo 3, pero es un lanzamiento y tienes alrededor de 60 minutos para subir los fuentes y luego se presentan los juegos a todo el público asistente. La oportunidad se presta para la recomendación de oro: a pesar de la presión del tiempo, invierte algunos minutos en planificar la organización de los archivos con tu equipo, ya que existe un estándar a cumplir para subir el juego desarrollado.

El lanzamiento de los juegos del Caracas Game Jam 2010 contó con el lente de Ciro Durán para dejar el recuerdo y compartirlo con la comunidad.

• Normal.
• Mousing Around.
• Rally^3.
• Sym-0 (en el cual participó su troll favorito servidor).

Dependiendo de la sede y la organización, puede haber invitados especiales de los cuales recibir feedback e incluso ofertas de empleo (buscar “Deception Wars”). Ciertamente son casos bien puntuales, pero es un ejemplo de lo que se puede alcanzar al decir “sí” a un fin de semana diferente.

Imagen: Global Game Jam.

Estamos en el momento “sé verde” y, como programador, considero que es una buena oportunidad de tomar en consideración los aspectos “verdes” del área.

El compilador ignora los comentarios, mas no significa que deban ser ignorados por el programador. Sé parte de la ola documentando tu código; recordarás mejor tu trabajo, tendrás más amigos y estarás ayudando a crear código más verde, literalmente.

Hay un dicho en Inglés que dice “Always write and document your code as if the person who is going to maintain it is a serial killer and knows where you live“ que se puede traducir a algo como “Siempre escribe y documenta tu código como si la persona que lo va a mantener es un asesino en serie y sabe dónde vives”. Efectivamente, es una ladilla piedra en el zapato meterle mano mantener un código pobremente documentado y es probable que termines mentando madre teniendo una mala impresión de quien lo hizo.

Antes de un discurso moral y pintar escenarios utópicos de programación, quiero dejar algo bien claro a todo aquel que comienza en el área, y a quien ya tiene experiencia pues sirve para recordarlo:  leer código poco documentado es la forma de aprender en el mundo real. Al cliente le importa que el código funcione y punto. Los estándares de desarrollo son iniciativa propia de cada programador y es nuestra responsabilidad como profesionales aplicarlo (bien sea luego de cada entrega o en cada nuevo ciclo de refactorización). Tener el entregable a tiempo es prioridad número uno. Entender y documentar un código que no escribiste, mejora tus aptitudes puesto que debes ejercer las funciones de compilador y correr en frío el código que quieres entender.

Hecha la aclaratoria de lo que es el mundo real, conocido también como calle mercado laboral; vamos a despotricar y dar lecciones de moral.

Algunas personas creen en el dicho “If it was hard writing it, it must be hard reading it“ (Si fue difícil escribirlo, debería ser difícil leerlo). Esto es  reflejo de incompetencia y mediocridad. No se está considerando que en un futuro, es bastante probable que  seas tú el que deba volver a leer ese código. Puede que pierdas tiempo valioso tratando de recordar lo que hace, en vez de concentrarte en mejorarlo/arreglarlo. Acción y reacción; así de sencillo y así de complicado.

Así de sencillo; porque documentar el código te hace ir a una capa de abstracción superior para definir de forma clara y concisa el proceso que realiza un bloque de código, y sirve de referencia en el futuro. Así de complicado; porque puede resultar fastidioso debido a que muchas veces es tomado a la ligera, porque hay otras cosas “más importantes” que hacer.

Así como existen normas de cortesía para la sociedad en general; documentar el código es, ciertamente, una de las mejores normas de cortesía en esta sociedad de programadores por cuanto ayuda a ubicar en contexto a quien lo lee por primera vez o, en todo caso, tener una referencia rápida sobre el bloque de código en cuestión.

Como nota adicional, hazte un favor y documenta el código a medida que vayas programando. Como dice Todd Hoff “Escribe los comentarios a medida que programas. No regresarás más tarde a documentar tu código. Simplemente no lo harás. No te mientas a ti mismo, al mundo ni a tu madre diciendo que lo harás”. Doy fe de ello. Mucho código “viejo” está en mi disco esperando ser documentado, y creo que así se quedará.

Es importante destacar lo significativo de ser auto explicativo. Documentar código comienza colocando nombres adecuados a las funciones y variables; nombres que sean de cierta forma naturales, evitando los acrónimos y contracciones. Esto puede ser todo un arte, pero el esfuerzo vale la pena.

Creo que las razones para documentar quedaron bien claras. Ahora queda hablar un poco del cómo. Pues sencillo, siguiendo patrones y estándares. Ni se te ocurra reinventar la rueda en este aspecto. Sé productivo y usa lo que ya está hecho y es ampliamente utilizado. Ejemplos (enlances en Inglés):

• Convenciones para C++ (por Todd Hoff).
• Convenciones para C++ en Google.
• Convenciones para Java.

En mi experiencia, existen tres herramientas relevantes en la generación de documentación que siguen patrones ya establecidos y aceptados por la comunidad:

• Javadoc. Está basado en los estándares de documentación del API de Java y orientado a dicha tecnología, pero también es utilizado con otros lenguajes y herramientas.
• NDoc. Desarrollo en C# y .Net.
  
• Doxygen. Es un generador bien flexible que incluso acepta las convenciones utilizadas para Javadoc.

En este sentido, considero que es importante conocer y tener nociones básicas de las convenciones Javadoc; por ser, a juicio personal, las más utilizadas. Para respaldar esta aseveración, Eclipse, NetBeans y FlashDevelop son Editores/IDEs que manejan estas convenciones de manera bien amigable.

En conclusión; siempre habrá excusas para pasar por alto los comentarios, pero queda de nuestra parte el ser profesionales. Documenta el código a medida que lo echas escribes, haz lo humanamente posible por aprender y aplicar estándares y por último, recuerda que el escribir buena documentación comienza por ser auto explicativo.

/**
 * @author    pctroll
 *
 * THE blog IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
 * Technorati token: NKVVWDWTSBAC
 */

Extracto, modificado, de la Licencia MIT.

Fotografía: Flavio Takemoto.

Para aprender un poco sobre OpenGL en vacaciones, decidí arrancar con un juego basado en Pong llamado Troll-o-Paddles; algo así como Troll-o-Raquetas, en Español.

Hace dos semanas comencé el proyecto haciendo un sencillo documento de diseño en Español y en Inglés para definir, de alguna forma, el alcance y esquema general del juego. Realmente no tomé ninguna plantilla ni referencia bibliográfica para este asunto; siento que me hubiese entorpecido el proceso. Puedo comenzar a leer y a leer del tema, comparar ideas y terminar aprendiendo mucha teoría; dejando la práctica (terminar el juego) de lado.

Algo que me quedó de trabajar 6 meses en Accenture, es la organización para tener una idea de cómo manejar una lista de cosas por hacer (TO-DO list); y no me tomó mucho tiempo realizarla, porque justamente ya tení el esquema del juego suficientemente definido. Para estos documentos utilicé Google docs y así compartirlos de la manera más sencilla posible.

Como quiero aprender a partir de las reseñas del público en general y otros programadores, decidí crear un repositorio en Bitbucket. Esto, según yo, va a ayudar a crear un mejor código y mejor organización como programador. ¿Cómo? La presión de que mi código va a ser visto por otras personas, tanto experimentadas como no experimentadas, me obliga a tener mi código documentado y lo más limpio posible, así como crear un “producto final” estable.

Si se fijan de nuevo en el TO-DO, para el momento en que termino de agregar los elementos de sonido, deberí tener un juego estable pero agregué elementos extra. Esto está hecho así para realizar el ejercicio de hacer un juego verdaderamente completo. Cuando comencé a indagar en aprender a realizar juegos, leí que esta es la parte más importante; terminar el juego como Dios manda tener el juego presentable. No importa cuantos prototipos tengas, si no están completos.

Geoff Howland en “How do I make games? A path to Game Development” (artículo destacado en GameDev.net) opina que:

Terminar un juego no significa apenas llevarlo a un punto donde se pueda jugar, y luego continuar con otro, esto no es un juego completo. Un juego terminado tiene una pantalla de presentación, pantalla de cierra, menú de opciones (si aplica, por lo menos instrucciones de cómo jugar y comenzar), pantalla de introducción al juego, pantalla de recompensas y tabla de puntuación (cuando aplique).

La meta es tener el juego listo para el 5 de Septiembre del 2010. Aun queda mucho por programar y por hacer; así que, apenas termine de traducir esta entrada, regreso a echar código un rato. Les estoy avisando sobre el avance del mismo vía Tumblr y Twitter; espero sus comentarios.

Fotografía: Far-away brothers.

La forma de empezar a adquirir experiencia, y portafolio, es haciendo juegos. Es importante comenzar por proyectos pequeños que nos permitan entender bien de qué va el ciclo de juego (o game loop), el manejo de entradas y salidas, así como conocer y experimentar con la herramienta de desarrollo, pero lo más importante de todo: terminarlos. Aquí, una lista de juegos por los cuales comenzar.

Mi amigo Ciro Durán en su blog, El Chigüire Literario, comenzó a publicar una serie de artículos a manera de Guía sensata al desarrollo de videojuegos (en sus propias palabras); y eso me motivó para compartir con ustedes la siguiente lista que elaboré de 10 juegos que todo programador debería atreverse a desarrollar.

Busqué crear una lista y mantener un orden relativamente lógico con respecto a la dificultad de los mismos. Los puntos clave en cada uno de los juegos son pistas sobre qué investigar o qué tomar en consideración. Puede extenderse e incluso combinarse los puntos de un juego con otro, tu imaginación es el límite.

1 Simón / Simón dice.

Referencia: Neave Games.

Puntos clave:

• Familiarizarte con la herramienta de desarrollo; biblioteca/framework/API/motor/etc.
• Acercamiento al ciclo de juegos orientado a turnos.

2 Tic-Tac-Toe / La vieja.

Referencia: Neave games.

Puntos clave:

• Familiarizarte con la herramienta de desarrollo; biblioteca/framework/API/motor/etc.
• Acercamiento al ciclo de juego orientado a turnos.
• Acercamiento a la inteligencia artificial a través del algoritmo minimax.

3 Snake.

Referencia: Kongregate.

Puntos clave:

• Arreglos multidimensionales (matrices).
• Acercamiento al ciclo de juego orientado al movimiento en relación al tiempo.
• Detección de colisiones sencillas.

4 Pong.

Referencia: 2FlashGames

Puntos clave:

• Acercamiento al ciclo de juego orientado al movimiento en relación al tiempo.
• Detección de colisiones bounding box o caja de restricción.
• Acercamiento a juegos multijugador.

5 Tron.

Referencia: Baromon.

Puntos clave:

• Reutilización de código de proyectos anteriores.
• Acercamiento a inteligencia artificial con algoritmos de camino más corto.

6 Tetris.

Referencia: FreeTetris.

Puntos clave:

• Arreglos multidimensionales.
• Detección de colisiones.
• Algoritmo de incremento de dificultad.

7 Breakout / Arkanoid.

Referencia: 2dFlashGames.

Puntos clave:

• Manejo de powerups y polimorfismo.
• Creación y manejo de niveles.

8 Asteroids.

Referencia: Goriya.

Puntos clave:

• Detección de colisiones por circunferencia.
• Aplicación de la física dentro del ciclo de juego.

9 Pac-Man.

Referencia: The PCMan site.

Puntos clave:

• Inteligencia artificial por medio del algoritmo A*.
• Creación y manejo de niveles.
• Creatividad para hacer un remake con elementos adicionales o distintos.

10 Dance Dance Revolution / Guitar Hero / Rock Band.

Referencia: Videogame Critic.

Puntos clave:

• Creación y manejo de niveles acorde a grados de dificultad.
• Sincronización de audio y video.
• Sistema complejo de animaciones.

Puntos adicionales a experimentar por cada juego una vez que esté terminado o suficientemente avanzado:

• Tabla de puntuaciones.
• Puntos de carga (especialmente para los juegos en web).
• Interacción con redes sociales (Kongregate, Facebook, Twitter, etc.).
• Instalador, en caso de ser un juego stand-alone para PC.
• Gráficos y sonido atractivos (formar un equipo de desarrollo).

Existen otros juegos que también vale la pena revisar, pero quise hacer una lista variada y con distintos temas. Ciertamente la mayoría son puzzles o contienen muchos elementos de este género; pero considero que ningún juego debe ser subestimado, por más sencillo que parezca. En mi experiencia, es muy distinto tener la idea teórica de cómo funciona un juego y realmente sentarse a terminarlo; te das cuentas que hay pequeños detalles que cuentan, cosas que probablemente no tomaste en cuenta y debas refactorizar mucho código (o en su defecto cortar esquinas).

Con esta entrada me queda la emoción por investigar más sobre cada género y elaborar otras listas especializadas, así como una nueva entrega con una segunda ronda de juegos igual o más variada que ésta.

¿Cuesta un poco terminarlos? Nos pasa a todos. Ciro, del Chigüire Literario, ya dio una charla sobre eso y aquí las láminas. Espero sus sugerencias de esta entrada.

Créditos fotografía: Daniel Wildman

Esta fue una semana de cambios y aprendizajes que van un poco más allá de la programación y los juegos. La reflexión de esta semana comenzó con un simple problema de programación y se extiende hasta mi objetivo de vida.

En mis estudios de pre-grado no tuve la necesidad de implementar el algoritmo de búsqueda binaria; fue simplemente teoría. Sin embargo, actualmente estoy recibiendo clases para refinar mis habilidades matemáticas y de programación para pulirme; por lo que naturalmente me tocó divertirme un poco con dicho algoritmo.

Primera implementación

int trollSearch(int n, int *arr, int arraySize)
{
	int index = 0;
	while(arraySize > 1)
	{
		index += (arraySize/2);
		arraySize -= (arraySize/2);
		if(*(arr+index) == n)
			return index;
		else if(*(arr+index) > n)
			index -= arraySize;
	}
	if(*(arr+index) == n)
		return index;
	else
		return -1;
}

Esta primera implementación, a pesar de no ser directamente búsqueda binaria, funciona relativamente bien. Contiene bugs reparables, y por eso el nombre de la función es “trollSearch”. Repararla queda en la lista de cosas pendientes, el caso es continuar con el cuento.

Segunda implementación

int binarySearch(int n, int *arr, int arraySize)
{
	int	minLim = 0, maxLim = arraySize-1, middle = 0;
	while(maxLim > minLim)
	{
		// punto medio según yo
		middle = ((maxLim-minLim+1)/2 + minLim);
		if(n == arr[middle])
			return middle;
		else if(n > arr[middle])
		{
			minLim = middle;
		}
		else
		{
			maxLim = middle;
		}
	}
	if(n == arr[middle])
		return middle;
	else
		return -1;
}

Esta segunda forma sí­ es búsqueda binaria. En un principio pensé que la utilización de variables adicionales no era muy efectivo y por eso fue que salió trollSearch. Quiero hacer énfasis en las líneas 6 y 7. El “punto medio según yo” hace el cálculo, aunque un poco ofuscado. Es entonces donde un amigo, que participó en maratones, hace la observación y me refresca la memoria en matemáticas para hacer un cambio en las lí­neas antes mencionadas:

Segunda implementación refinada

    // punto medio con repaso en matemáticas
    middle = (maxLim + minLim)/2;

Luego de una pequeña conversación vía gtalk, mi amigo me hizo referencia al Problema del Barómetro o La Anécdota de Bohr.

Este es un ejemplo, si se quiere trivial, de que hay distintas formas de alcanzar el mismo objetivo (tal como lo expuso Bohr). Hay maneras más eficientes que otras, sencillas y ofuscadas, pero no por eso tienen menos crédito. El valor de conocer las distintas vías en las que un objetivo se puede alcanzar es, a opinión personal, una de las claves del éxito. El conocimiento es poder y no siempre la forma más efectiva de hacer algo, para una circunstancia en particular, aplica para todas las demás; por eso es bueno estar en constante aprendizaje.

Si lo llevamos al contexto de este blog, la industria de los videojuegos es extensa. Hay distintas formas de llegar a ella (nuestro objetivo). Detrás de los publishers hay una cantidad de empresas de desarrollo con muy buenas iniciativas, muy buenas ideas, talentos como tú y yo, y especializaciones en áreas en las que somos muy buenos y no sabíamos que existían.

El algoritmo de vida es único para cada uno de nosotros, vivimos en base a un lenguaje interpretado con la opción de mejorar, en tiempo de ejecución, las líneas por procesar; pero también aprendiendo de aquellas instrucciones que causaron inestabilidades en la ejecución de nuestro programa.

Créditos fotografí­a: Juan Vasquez

Pues sí, la nueva etapa del blog dice “¡Hola, mundo!”; como la célebre frase en el mundo de la programación.

Si les soy honesto, quise arrancar de una vez buscando una entrada que fuese tanto funcional para mí­, como informativa para ustedes. ¿Qué quiero decir con esto? Sigan leyendo

{pctroll studios}

Es sencillamente el nombre del blog porque pctroll.com ya estaba tomado y por lo pronto no poseo el recurso monetario para pagar más de lo que vale un dominio sin registrar. Quiero un blog sin las limitantes de WordPress.com, pero con el motor que lo impulsa (visita el blog original aquí­). Estaré actualizando éste con las entradas antiguas, pero paciencia; que me toca traducirlos.

Objetivo

Hablar del desarrollo de videojuegos desde el punto de vista de un programador que pensaba que para hacer juegos se necesitaba estudiar en una universidad o instituto especializado en el área; y que quiere compartir sus experiencias con otras personas.

Temas

• Desarrollo de juegos a nivel general.
• Programación.
• Eventos relacionados.
• Tecnología enfocada en el ramo.
• Cualquier otra cosa que se me ocurra (al final del día a, es mi blog).

¿Por qué lo hago?

1. Porque quiero.
2. Porque hay gente que en mi país (Venezuela) se gana la vida haciendo juegos, pero noto poca interacción de su parte hacia la comunidad entusiasta del país que quiere aprender un poco más.
3. Porque compartiendo lo que aprendo, y recibiendo comentarios, aprendo más.
4. Porque puedo.

¿Qué esperar en las entradas además de texto?

Código fuente

#include "iostream"
using namespace std;
int main() {
 cout << "­¡Hola, mundo!" << endl;
 return 0;
}

Videos

Referencias bibliográficas o de fuentes digitales de información

Tablas

[table id=1 /]

Para finalizar la entrada, les comento que el blog tiene su cuenta en twitter (@pctrollstudios), la cual difiere de mi cuenta personal (@pctroll) por cuanto el tipo de tweets. Les recomiendo sigan a ambas y se queden con la que más les guste al final del día. Así mismo, el link de RSS está adaptado a los idiomas; por lo que la suscripción en Español y en Inglés son distintas.

Eso es todo por lo pronto… hay un mod de Tetris que quiero terminar y, si se fijaron, la entrada tiene distintos elementos/plug-ins/etc. que quería probar.

Créditos fotografí­a: Geekcesorios