Me alegra comentaros que hace poco terminé el desarrollo de Alice in Bomberland, disponible para iPhone e iPod Touch. Mediante el desarrollo de videojuegos puedo permitirme cubrir los costes de estas lecciones para poder seguir ofreciéndolas gratuitamente. Por favor echa un vistazo al trailer del juego, donde tendrás más información, y ¡puntúa / comenta / comparte!



Lecciones gratuitas de GameDevLessons.com, por Chris DeLeon

Vol 7 - Octubre 10, 2009


¡Hola!


Soy Chris DeLeon (acerca de mi), y gracias por acompañarme en mi boletín mensual y gratuito de desarrollo de videojuegos, vol. 7. Estos boletines son una de las formas en las que espero ayudar a empezar a nuevos desarrolladores, mientras ayudo a los que ya están en ello para llevar su trabajo en nuevas direcciones.



I.) Ediciones anteriores, suscripción

II.) Principiante - La primera vez que se trabaja en equipo

Tener ámplios conocimientos es útil...

...pero no sustituye al trabajo en equipo

Desafíos al formar un equipo

Equipo mínimo

Asistencia gratuita en formación de equipos

Solicita emparejamiento y consejos de expertos


III.) Nivel medio - Estableciendo un club de desarrollo de videojuegos

Sociedad de creación de juegos en Carnegie Mellon

Esto es lo que nos resultó útil

Lecciones aprendidas

Si lo construyes, vendrán (y si no lo haces, no)

Mantén el plazo de desarrollo del proyecto en un semestre

Enfatiza el completar todos los juegos

Examina a los líderes de proyecto

Está bien perder a la gente que no quiere trabajar

Los líderes lanzan proyectos, deja que los miembros elijan que proyectos se harán

Los creditos de asignatura en la Universidad amenazan la agilidad

Consigue conferenciantes invitados

Proporciona recursos opcionales para la organización de equipos

Ofrece a los creadores de contenidos oportunidades para mostrar su creatividad

Establece metas semanales para todo el mundo

Permite a los mejores miembros que apliquen sus roles en múltiples proyectos

Comparte progresos semanalmente, en forma de videojuegos jugables

Recluta a una gran variedad de personas

Sé un agnóstico de la tecnología y las herramientas

Minimiza los cuellos de botella del contenido

Un lider de proyecto debería ser capaz de finalizarlo por si mismo

La demo es el juego

Céntrate en videojuegos, no juegos

Prepárate a adaptarte


IV.) Advanzado - Debate: ¿Un Videojuego es su código fuente?

Un breve debate con Jesper Juul


V.) Entrevista a Warren Robinett


VI.) Ofrezco mis servicios de tutoría gratuitamente


VII.) Donaciones



I.) Ediciones anteriores, suscripción


Para leer anteriores ediciones o suscribirse: http://gamedevlessons.com/?page=free


Si quieres que te avise cuando salga la próxima edición, puedes unirte a la lista de correo. Sólo te llevará un minuto, nunca te enviaré más que un correo al mes (sólo para anunciar estas lecciones gratuitas), y es fácil borrarse de la lista cuando quieras.


Aunque estas lecciones no están pensadas para ser acumulativas, todos los temas tratados pueden ser muy útiles. Si eres nuevo, recomiendo que leas el primer boletín por su introducción conceptual, no técnica, a la programación, y los enlaces de material y recursos gratuitos para edición de imágenes, trabajo con audio, modelado 3D y otras creaciones de recursos.


II.) Principiante - La primera vez que se trabaja en equipo


Tener ámplios conocimientos es útil...


Soy un entusiasta del desarrollo de videojuegos en solitario. Recomiendo desarrollar un amplio abanico de habilidades. Creo que es útil para todos los desarrolladores tener al menos un poco de comodidad y fluidez en las herramientas que se usan para arte, sonido y programación. Esto mejora la comunicación. esto crea respeto entre gente con diferentes fuertes. Esto aumenta la libertad para crear tus propias ideas. Esto acelera los equipos de desarrollo eliminando cuellos de botella.

...pero no sustituyen al trabajo en equipo


Una vez dicho esto, esta "fuerza" varía de un caso a otro.

Saber como usar el Photoshop o el 3D Studio no significa que alguien sea un buen artista. Conocer un lenguaje de programación no hace que alguien sea un programador muy capaz. Saber como usar el Fruity Loops no hace de alguien un músico excepcional.

Incluso si tu puedes hacer todas estas cosas bién, aún hay ventajas al trabajar con otros. Diferentes artistas hacen diferentes tipos de arte, y aprendiendo a trabajar con otros artistas podrás desarrollar juegos con cualquier tipo de arte, dependiendo del artista con el que trabajes. Diferentes programadores disfrutan de forma distinta cada problema a resolver, tanto si es inteligencia artificial o multijugador online, o trucos para obtener efectos gráficos distintivos. Aprender a trabajar con alguien significa que la persona con la que trabajes puede afectar con mucho el tipo de juegos que haces, evitando un bache creativo.

Los miembros del equipo pueden ayudarse para seguir centrados. Es como tener un compañero de gimnasio, de estudio o unirse a un club.

El trabajo de equipo también construye tu futura red. Hacer red con novatos puede que no parezca una estrategia para conseguir éxito en el futuro, pero el día de mañana ellos serán desarrolladores experimentados.

Las conexiones son muy importantes y pueden suponer una gran diferencia.

Desafíos al formar un equipo


Encontrar un equipo puede ser difícil. Cuando tu pasión excede tu experiencia, es difícil conseguir la atención de un equipo bien establecido.

Para hacer el problema más complicado, sin experiencia previa, es difícil diferenciar entre la pasión dirigida al éxito y la pasión dirigida al desastre. Todo el mundo tiene ideas, y todo el mundo tiene buenas intenciones.

Con sólo unos minutos de opinión de un amigo experimentado podrías evitar meses de problemas, o mantener a tu equipo fuera de las causas conocidas de disolución de proyectos.

Equipo mínimo

  • Un programador. Más programadores podrían enlentecer las cosas para un proyecto principiante, debido a la complejidad de la integración de código, y la sobrecarga añadida de la comunicación entre miembros del equipo.

  • Uno o más artistas digitales. Es más fácil que se mezclen los recursos artísticos de principiantes que mezclar la programación de principiantes.

  • Una persona para audio. Normalmente suele ser tarea del programador o del artista, que ejecuta dos roles, buscando sonidos y músicas de dominio público o creative commons.

  • Uno de los anteriores, con un interés adicional en el diseño de videojuegos, o posiblemente un diseñador de niveles/puzzles si el género necesita muchos contenidos de ese tipo.

  • Alguien que tenga al menos un par de proyectos finalizados, con el que os podais reunir de vez en cuando durante la vida del proyecto, para ayudaros a evitar posibles problemas.

En resumen: 2-3 personas. Siendo esa tercera persona la que ofrezca soporte para audio, arte adicional, o diseños adicionales de niveles o puzzles puede ser de gran ayuda. Y sería muy útil el poder encontrar un consejero experimentado con quien contactar varias veces a lo largo del proyecto.

Asistencia gratuita en formación de equipos


Si ya hay un club de desarrollo de videojuegos en tu área y tienes acceso a él, sugiero que te unas. Si estás en la situación de fundar algo así, mira la
siguiente sección de este boletín para obtener algunas pistas y consejos de cara a tener un mayor éxito. Si eres como la mayoría de personas, y no tienes acceso fácil a clubs de desarrollo de videojuegos o no estás en la situación de crear uno, me gustaría ayudarte.

Estás leyendo esta sección, probablemente porque tienes alguna experiencia en al menos una de las áreas que se necesitan para hacer juegos (programación, arte, audio) y estás listo para trasladar esas habilidades a la realización de videojuegos sin empezar desde cero en las otras áreas. Hace poco hice una petición a algunos de los jefes de proyecto que han terminado con éxito varios proyectos en mi club de desarrollo de videojuegos (Sociedad de Creación de Juegos), para ver si no les importaría ser voluntarios para ejercer de consejeros. Tengo cinco personas dispuestas, con lo que podemos dar soporte hasta seis proyectos, ya que yo también me ofrezco voluntario.

Solicita emparejamiento (con otros de tu nivel para formar un equipo) y soporte experimentado (¡sólo para gente que pueda escribir en inglés!)


Por favor, envíame un correo a
cdgdl.free@gmail.com (este es un correo diferente del que utilizo en mis sitios web) indicando la siguiente información, un máximo de dos frases para cada caso.

  1. De las siguientes habilidades, indica en cuales tienes experiencia y querrías compartirla para el proyecto: programación, arte, audio (sfx/música), diseño de puzzles/niveles

  2. ¿En qué géneros estás más interesado para trabajar?

  3. ¿Hay algún género en el que NO querrías trabajar

  4. ¿Estas decidido a trabajar con tus compañeros de equipo gratuitamente, para crear un videojuego que se comparta públicamente y gratis, en el interes de aumentar tu portafolio y que todos en el equipo ganeis experiencia? (responde sólo con una palabra, y no vale otra que no sea sí)

  5. ¿Querrías que un consejero experimentado te ofreciese su opinión al principio, mitad y últimas etapas de las fases de tu proyecto? (una palabra, sí/no)

  6. ¿Cuales son tus experiencia previas o habilidades en el desarrollo de videojuegos?

  7. Enlaces a cualquier sitio web con tu trabajo en programación o creativo, pasado o presente. Por favor no envíes archivos adjuntos. Si no tienes nada no hay problema, está bien.

Estas preguntas no son para juzgarte. Estas preguntas no están porque quiera probarte (aunque la práctica que dá el someterse a pruebas siempre es una buena experiencia). Estas preguntas están aquí estrictamente porque las respuestas cortas me permitirán emparejaros con eficacia con colegas de equipo que tengan los mismos intereses, experiencia similar, y, sólo si estais interesados, con un consejero que tenga experiencia relevante.

Para que quede claro, esta asistencia voluntaria no realiza ningún tipo de gestión, dirección o rol autoritativo. Estamos ahí para ofrecer consejo desde la experiencia, en ocasiones limitadas, y podríais ignorar estos consejos o interpretarlos como mejor os convengan.

Ofrezco esto completamente gratis. No hay trucos, no quiero venderte nada o vender tus datos a nadie, y no hay ninguna "promoción" ni cosas del estilo. Me gusta ayudar a la gente - una clara extensión de lo que estoy haciendo en GameDevLessons.com y Lecciones gratuitas. Si tienes amigos a los que les puede interesar esta asistencia, por favor, ¡házselo saber!

Llevará un tiempo recoger las respuestas, emparejarlas y encontrarles un consejero voluntario. Haré todo lo que pueda para contestar cada petición. Si no puedo emparejaros con un consejero, al menos intentaré emparejaros con otros que tengan los mismos intereses y vuestro nivel de experiencia tan pronto como me sea posible.

Si puedes, aprovecha esta oportunidad, siempre te será de ayuda. Envíame un correo a cdgdl.free@gmail.com (por favor, sólo aquellos que podais mantener correspondencia en inglés).


III.) Nivel medio - Estableciendo un club de desarrollo de videojuegos


Sociedad de creación de juegos en Carnegie Mellon


Mientras estaba en la facultad, ayudé a un club de desarrollo de videojuegos a despegar, estructurar sus procesos, establecer unos niveles de trabajo, y asegurar que los proyectos comenzasen de forma que sus equipos pudieran terminarlos. Ese club es la Sociedad de creación de juegos en Carnegie Mellon, y puedes encontrar sus videojuegos en GameCreation.org.

A pesar de que el club de desarrollo de juegos fue creado en una universidad, muchas de las lecciones aprendidas son igualmente aplicables a fundar o hacer crecer cualquier comunidad de desarrolladores, tanto si es local u online, si es en un instituto o entre gente ya a punto de terminar una carrera.


Esto es lo nos resultó útil


Cada año comienzan muchos clubs de desarrollo de videojuegos. Muchos de ellos inician un buen montón de proyectos enormes, aguantan con equipos que caen a medida que sus miembros se van dispersando, y después de un par de años de aplazar agendas, o bien cierran o se transforman en un club de juego/cultura sobre juegos, en vez de un club de desarrollo de juegos.

Por supuesto, aunque lo que hicimos nos funcionó no es la única forma de hacer las cosas. De hecho, hay otras organizaciones que han tenido éxito, haciendo las cosas de muy diferente forma y permitiendo reglas muy distintas. Lo que puedo decir con seguridad es que estas reglas funcionaron muy bien para nosotros durante los primeros años. Espero que también otra gente con experiencias drásticamente distintas puedan ayudar compartiendo lo que aprendieron en sus organizaciones.


Lecciones aprendidas


Si lo construyes, vendrán (y si no lo haces, no)

Aunque desarrollé el proceso para los grupos, y dirigí el club durante dos años, yo no lo inicié. Curt Bererton, entonces un estudiante de Robótica y ahora el fundador/CEO de
PlayCrafter y Cat's Cove, fundó la organización, escribiendo su carta de presentación, pegando carteles, uniendo a los primeros miembros, y realizando reuniones semanales antes de que nos encontrara por el campus para ayudarle a poner en marcha el grupo. El no pudo montar la organización con toda la gente y recursos que necesitaba - la montó parcialmente como un medio para encontrar a esa gente y esos recursos. (y lo que yo hice no hubiera ido a ninguna parte si no hubiera aparecido gente como John Nesky y Greg Peng - pero tampoco podríamos habernos encontrado si el club no existiese.)

Mantén el plazo de desarrollo del proyecto en un semestre

Cada semestre, los tiempos que cada uno puede aportar cambian. Cuanto más tiempo lleve un proyecto, más cantidad de incertidumbre se acumula entre su comienzo y su terminación. Por estas razones, nosotros intentamos organizar cada proyecto para que se ajuste al semestre en el que se comienza. Hacer un proyecto más complicado sólo es posible trabajando más rápido, dedicando más horas, y siendo perspicaz para evitar esfuerzos innecesarios. Para los proyectos especialmente ambiciosos dejamos ocasionalmente a desarrolladores veteranos planificar un lanzamiento del proyecto al final de un semestre, y luego un segundo lanzamiento con características/contenido adicional en el siguiente semestre.

Enfatiza el completar todos los juegos

Finalizar cada proyecto iniciado es crucial. Esto es cierto incluso si significa descartar proyectos por ser muy ambiciosos, tiempos más cortos hacen el proyecto más predecible, y evitan algunas ideas entusiastas del tipo "Quiero hacer el siguiente MMO de éxito". Nada es peor para un nuevo miembro que partir de una lista de proyectos incompletos, y nada es peor para la retención del nuevo miembro que haber hecho arte, audio y niveles para luego tirarlos a la basura. Los nuevos miembros son atraidos por la idea de trabajar con un equipo fiable, usando un proceso conocido, con un alto grado de confianza en que su trabajo acabará dentro de un juego finalizado.

Examina a los líderes de proyecto

Cada lider de proyecto tiene que cubrir una simple propuesta (una hoja), describiendo el nombre del juego, cuanto se supone que llevará desarrollarlo (de nuevo: un semestre como máximo), de que vá (en resumen), y cuanta gente en cada puesto serán necesarios. Luego nos reunimos uno por uno durante una hora más o menos, charlando acerca de las metas del proyecto y la agenda. Esto no era algo muy estricto ni era un filtro, se trataba de añadir una capa de protección para ayudar a minimizar las oportunidades de que algunos miembros muy motivados terminasen en proyectos sin salida, a pesar de arrancar con proyectos bien intencionados pero con lideres de proyecto poco preparados.

Está bien perder a la gente que no quiere trabajar

Hacer videojuegos consume un montón de tiempo, energía, trabajo y aprendizaje adicional. Cada año conseguíamos tantos miembros como nos era posible durante las actividades y ferias de primavera - con casi 100-150 personas asistiendo a nuestras reuniones - intentando centrarnos en la importancia de tener a todo tipo de personas (artistas, escritores, programadores, modeladores, músicos, testeadores...) involucrados en hacer videojuegos. En las dos primeras reuniones explicamos el proceso y algunos se iban cuando entendían que esto les llevaría más tiempo semanal que simplemente acudir a las reuniones de 1 o 2 horas, y que no era algo tan simple como jugar a videojuegos. Prescindir de esta gente es algo bueno para todos (ellos inclusive), no es un problema.

Los líderes lanzan proyectos, deja que los miembros elijan que proyectos se harán

La presentación de cada proyecto es sólo un powerpoint de 15 minutos (mostrando arte conceptual, e información de contacto del lider del proyecto) y una charla acerca de la visión inicial del lider del proyecto. La última parte de la presentación del proyecto es el nombre del lider, su correo electrónico, y una lista mínima de los roles que necesita para que se haga el proyecto: dos artistas 2D, una persona para el sonido, etc... Cualquiera interesado en esos roles podría hablar con el lider del proyecto después de la reunión, o contactar con el por correo electrónico. Si el lider del proyecto no conseguía suficientes miembros en las 2 semanas siguientes, o ajustaba su proyecto para reflejar los miembros que se le unieron, entonces su proyecto no pasaría al estado "activo". Cuando la gente no cobra, y no recibe credito, es importante que sientan que trabajan en algo que les guste y les llame la atención.

Los creditos de asignatura en la Universidad amenazan la agilidad

Una de las ventajas de ser una organización "fuera de clase/fuera del trabajo" es que la gente que no está interesada puede irse, en vez de estar atrapados por su necesidad de un salario, creditos de asignatura, etc... Al principio investigamos la oportunidad de que estudiantes en activo consiguieran créditos u otro tipo de reconocimiento académico por su trabajo en el grupo, pero después de un par de semestres dimos gracias a la agilidad que nos otorgó el que los propios miembros escogieran quedarse por su propio interés en hacer juegos.

Consigue conferenciantes invitados

Hay un conjunto de gente en la organización que están ansiosos de escuchar temas acerca de la industria del videojuego, desde charlas de reclutamiento en empresas, a desarrolladores experimentados compartiendo sus puntos de vista. Mientras tanto, las compañías tienen gente que dedica su atención a encontrar una audiencia de donde poder reclutar, y los desarrolladores experimentados a menudo disfrutan con la oportunidad de compartir sus historias. Establece contaco por correo electrónico con cualquiera que creas que puede involucrarse - obtendrás más "no" que "sí", pero incluso un sí al año puede traducirse en miembros más felices, nuevos miembros (los conferenciantes son material de primera para eventos a los que invitar a nueva gente a que pase por la organización), y mejorar las oportunidades de "red social" de todos. Incluso puede llegar a fomentar prácticas o trabajos para los miembros de la organización, lo que se traduce en nuevas conexiones dentro de la industria.

Proporciona rescursos opcionales para la organización de equipos

Damos a cada equipo activo una carpeta en un servidor FTP con un usuario/clave dedicado, para que los miembros del equipo compartan archivos, así como una sección en un foro para que se lleve un historial de cada charla en el proyecto. Todo esto lo hemos configurado como cuentas secundarias en un hosting de bajo coste (
StartLogic.com) utilizando ezBoard y phpBB para el sistema de foros. Estos recursos mínimos ayudan a facilitar agendas de trabajo asíncronas para equipos de estudiantes.

Ofrece a los creadores de contenidos oportunidades para mostrar su creatividad

A la gente le gusta mostrar lo que hace, y aprender de ello, independientemente del estilo o asunto que mejor sepan hacer. Los proyectos que puedan ajustarse a esto saldrán mejor, obteniendo no sólo mejores juegos, sino miembros más felices.

Establece metas semanales para todo el mundo

Tener mucho trabajo no es una cosa buena, pero la gente se involucra en proyectos como hobby en parte por un interes en contribuir, ganar experiencia, y tener algo que mostrar orgullosamente cuando esté acabado. Si alguien en el proyecto tiene un periodo de tres semanas sin nada que hacer, puede que tengan la sensación de que no son necesarios en el equipo y pierdan interés.

Permite a los mejores miembros que apliquen sus roles en múltiples proyectos

Esto soluciona parcialmente el problema anterior - mientras en un proyecto disminuye la necesidad de un artista o músico, en otro proyecto puede hacer falta. Esto permite crear una gran variedad de experiencia en el mismo tiempo, y ayuda a completar los proyectos.

Comparte progresos semanalmente, en forma de videojuegos jugables

Dando a cada lider de proyecto una oportunidad para presentar el progreso del grupo da a todo el mundo algo por lo que trabajar semanalmente. Disminuye la probabilidad de que se trabaje una semana entera sin progresos, o que alguien pase más de una semana trabajando sin tener claro su próxima tarea. Esto también asegura que todo el mundo se centre en cambios visibles, un tema importante tanto si intentas impresionar a jugadores, nuevos desarrolladores o productores.

Recluta a una gran variedad de personas

Una habitación llena de gente experta en ______ es una habitación donde todo el mundo asumirá incorrectamente ______, o se centrará demasiado en ______ y va a pasar por alto la importancia de ______. Cada tipo de experto tiene diferentes palabras en esos espacios en blanco.

Incluso si es una habitación llena de informáticos que saben como programar (ese fue uno de nuestros primeros grupos en la Sociedad de creación de juegos), es mejor el encontrar programadores con variedad de intereses en composición musical, animación de sprites, diseño de interfases, etc...

El reclutamiento activo es además una parte muy importante. Las octavillas son importantes, pero evangelizar por la causa es un largo camino, como dar charlas en ferias o reuniones y otras oportunidades de reclutamiento.

Sé un agnóstico de la tecnología y las herramientas

Algunos artistas 3D prefieren Maya en vez del 3D Studio, o al revés, mientras otros son más productivos en Blender (o quizás no tienen 3500$ por ahí para gastar en su hobby). Algunos programadores prefieren el C#, otros prefieren ActionScript 3, mientras otros están felices con poder hacer scripts en Unity o Game Maker.

Da igual las herramientas y las plataformas tecnológicas que la gente use y conozca, acepta cordialmente a todos para que usen esas herramientas a su máximo potencial. Al final del día tendrás gente contenta y se habrá avanzado en la generación de buen contenido. Dar a la gente libertad para que aprendan cosas nuevas es asombroso - pero el forzarlos a aprender nuevas cosas es algo reservado para las clases a las que asisten (si es el caso, aquí vienen a desarrollar juegos en equipo).

Minimiza los cuellos de botella del contenido Los juegos de rol y los de aventuras dan miedo. No importa lo simple que parezcan, requieren (como poco) docenas de recursos en dibujos de enemigos, diseño de niveles para docenas de ciudades, áreas exteriores, y mazmorras, datos/precios/arte balanceados para una ámplia variedad de items, varias canciones intensas y emotivas, y un incontable número de páginas de diálogo escrito para docenas de personajes. Probablemente también necesita, como poco, un motor mínimo de reproducción de scripts para las secuencias de historia. Después de hacer videojuegos durante siete años, he podido liderar un pequeño equipo para hacer un RPG limitado y sencillo. No cuento esto para que sirva de estímulo, sino como una advertencia.

Los juegos de lucha con scroll lateral (tipo Final Fight, llamados Beat-em up) y los juegos de plataformas también requieren un buen montón de arte animado. Una gran variedad de tipos malos, jefes, y fondos es lo que hace que la gente adore seguir jugando a ellos.

Algunos tipos de videojueos se escalan mucho mejor, y no requieren montañas de arte diferente - especialmente los juegos de puzzle o de acción que ocurren en niveles sin scroll o de una pantalla. Cuando los equipos principiantes presenten sus primeros proyectos, es mejor favorecer los juegos que serán capaz de reutilizar contenido eficiéntemente en diferentes combinaciones, y conseguir salir adelante con un contenido mínimo. No solo mejora la oportunidad de que un proyecto particular tenga éxito y se finalice, sino que evita que proyectos demasiado ambiciosos y épicos acaparen la mayor parte de los creadores de contenido del club en un agujero negro que con seguridad no se transformará en un juego finalizado.

Un lider de proyecto debería ser capaz de finalizarlo por si mismo

La gente abandonará la organización. La gente abandonará los equipos. Da igual la intención que tengan, y da igual lo amable que se les trate, las cosas cambian, y las prioridades cambian. En el mundo exterior es muy importante que el club mantenga una reputación por la terminación de sus juegos. Internamente, significa que es muy importante para el club que los líderes de proyecto se aseguren de que el juego que comienzan se terminará. Esto requiere que los líderes de proyecto tengan al menos una mínima habilidad en arte digital, programación y encontrar/editar/hacer audio para usar en el juego, para el supuesto en el que si todo el mundo deja el equipo, el juego pueda terminarse, aunque no tenga el aspecto ni suene como fue pensado inicialmente. Esta predisposición a terminar lo que se comienza consigue motivar a los líderes de proyecto para mantener a los miembros de sus equipos contentos, y buscar sustitutos cada vez que algún miembro deje el equipo, ya que ellos tendrán que hacer el trabajo que no pueda hacer otro.

La demo es el juego

Como una idea para reducir el trabajo a realizar, surgió durante la reuniones previas a la selección de proyectos el preguntar al lider del proyecto cual era la cantidad mínima de funcionalidad y contenido que deberían tener para crear una demo del juego

Ya que el objetivo es obtener experiencia y material para el portafolio de cada uno de los miembros del proyecto, el tamaño de la demo viene a ser en cuanto a contenido, lo que la mayoría de la gente, fuera de la organización, en el mundo exterior, llegará a ver. Hacer una versión más larga del juego no ayudaría a aprender más cosas, aparte de incrementar las posibilidades de que el juego no llegue a completarse. Y un videojuego que no está completo no es un videojuego para el mundo exterior.

Teniendo esto en consideración, ajustamos planes, contenido, tamaño del equipo, y la historia para que las "demos", con su tamaño, sean el juego terminado. Antes de que el proyecto sea seleccionado o comenzado.

(Esto tiene el desintencionado efecto de incrementar la credibilidad y el atractivo de miembros para la selección de proyectos. Cuando alguien intenta convencer a los miembros para que se unan a su proyecto que tendrá 20 mundos, 30 armas y 16 personajes principales, nadie quiere seleccionar algo tan serio.)

Céntrate en videojuegos, no juegos

Un club que intenta ser para todo el mundo es un club que no le sirve a nadie. Un juego de tablero, un juego de dados, un juego de dragones y mazmorras, un juego de casino, uno de deportes, uno de espectáculos, uno sobre teoría, o el juego de la vida de Conway... no son juegos para un club de desarrollo de videojuegos. Incluso si alguno de ellos entra dentro de alguna categoría de diseño de videojuegos, es difícil que resulten atractivos para diseñadores 3D, ingenieros de software, escritores de diálogos, testeadores, animadores, compositores de música, especialistas en sonido, y el resto de habilidades que entran dentro de un equipo de desarrollo de videojuegos (profesional o por hobby).

Dá la bienvenida a gente con intereses en estas cosas, igual que con cualquiera interesado en otras cosas como programación de sistemas operativos, películas de animación y escritura de novelas. Pero deja claro que la organización no está dispuesta a seleccionar, producir y trabajar en juegos que no sean videojuegos, igual que no se trabajará en realización de películas o novelas, de esta forma se favorece la definición de un nucleo fuerte.

Prepárate a adaptarte

Dependiendo de quienes sean los líderes de la organización, y lo que los líderes de los proyectos quieran hacer, las reglas de funcionamiento deberán ser distintas. También afectará lo establecido que esté el club en cuanto a cambios en necesidades organizativas - un club joven estará muy centrado en su crecimiento, su credibilidad y su claridad, mientras que un club más establecido hará bien en centrarse en retención, visibilidad y estabilidad. Soy bueno en esos tres primeros puntos y me resultan complicados los otros 3, motivo por el cual supe cuando era el momento adecuado para dejar paso a un nuevo lider.

IV.) Avanzado - Debate: ¿Un videojuego ES su código fuente?


Un breve debate con Jesper Juul


Los juegos están hechos a base de reglas. Los videojuegos no.

Este es el nucleo del debate que tuve con el reconocido profesor de videojuegos
Jesper Juul, que tuvo lugar en un viejo artículo en su blog (en inglés, y mediante google, su traducción) al que llegué a través de la conferencia de Ian Bogost en DiGRA 2009 (en inglés, y de nuevo, su traducción).

Empezó en su blog: Mi opinión inicial sobre la pregunta.

El punto principal de mi argumento está aquí: Mis argumentos sobre el tema..


V.) Warren Robinett - Atari Adventure - Entrevista


En el prólogo de The Video Game Theory Reader, Warren Robinett, el hombre que inventó el género de acción-aventura a sus veintipocos años, mencionó que la gente que construyó los fundamentos conceptuales de nuestra industria - las versiones de Bach, Platón y Shakespeare en nuestro medio - todavía siguen vivos. Dado que nos hubiera gustado hacerles muchas preguntas a la gente responsable de tantas innovaciones en otros campos, no tenemos porqué asumir que nos quedaremos igual en nuestro caso, se lo debemos a las generaciones futuras, debemos entrevistar a esta gente, ¡y eso he hecho!

Puedes leer la entrevista aquí: entrevista con Warren Robinett, creador de Adventure (el primer juego de acción-aventura) and Rocky's Boots (uno de los primeros juegos educacionales de éxito).


VI.) Mis tutorías ahora son gratuitas


A partir de ahora, ya no cobro por mis servicios de enseñanza y consejo. Quiero ayudar a la gente mientras mi tiempo me lo permita, y me he dado cuenta de que este hecho no tiene correlación (o si la tiene es con efecto negativo) con el dinero. Hay seis preguntas en el formulario de petición de asistencia, cada una no requieren más que una respuesta de un par de líneas. Sólo puedo atender estas peticiones y ofrecer mi consejo a aquellos que puedan mantener correspondencia en inglés.

Si nadie me solicita, nadie obtiene asistencia gratuita aparte del material que ofrezco en estas lecciones. Si eres la única persona que me lo pide, desde luego obtendrás mi asistencia. Si eres uno de los muchos que podrían solicitar mi ayuda, intentaré echar una mano en lo que pueda, o al menos ver si puedo ponerte en contacto con otros de tu mismo nivel. Por supuesto cuanto más me cuentes en el formulario de petición más fácil será para mi el ofrecerte ayuda.


VII.) Donaciones


Estas lecciones gratuitas están desarrolladas como un regalo a la comunidad, y me gustaría continuar desarrollándolas, pero me lleva bastante tiempo prepararlas. Si crees que estas lecciones te resultan valiosas, y puedes permitirte hacer una pequeña donación de 10$ (el precio de un libro pequeño), 30$ (el precio de una sesión de asesoramiento en grupo), o incluso unos pocos dólares (para mostrar tu apoyo, y motivarme), lo apreciaría muchísimo y me ayudaría a continuar dedicando el tiempo necesario para mantener la calidad como una prioridad en estas lecciones. PayPal hace que las transacciones sean seguras y sencillas - ni siquiera necesitas tener una cuenta en PayPal si tienes acceso a una tarjeta de credito:






Chris DeLeon

chris@gamedevlessons.com


PD Estoy escribiendo estos boletines para ayudar a la gente, y quiero que su contenido llegue al máximo número de personas posible. Por favor pasa este enlace si sabes de alguien al que le podría ser útil; http://gamedevlessons.com/lessons/carta7.html Enviar el enlace es mejor que copiar el texto entero y enviarlo, ya que de esta forma siempre verán la última versión con preguntas y respuestas o correcciones.








Nota sobre la traducción: este boletín ha sido creado originalmente en inglés y para una audiencia anglosajona por Chris DeLeon. He procurado adaptar, en la medida de lo posible, el texto a una audiencia hispano parlante, y en particular, Española. En sus comentarios Chris habla de la industria del videojuego en el mundo anglosajón, aunque no se apliquen por igual en nuestro caso creo que son bastante útiles.


Aparte del sitio web de Gamedevlessons también podrás encontrar estas traducciones en mi propia página web, en http://www.proyecto-iris.com, donde siempre mantendré una sección dedicada a estos boletines para ayudar en su difusión.


Andrés de Pedro

Por cierto, si ves alguna errata o enlace mal escrito, no dudes en ponerte en contacto conmigo para poder corregirlo.