Boletín GameDevLessons.com
Vol 1 - 2 de Abril, 2009
¡Hola!
Bienvenido al primer Boletín mensual de GameDevLesson.com.
Soy Chris DeLeon (acerca de mi), y esta serie de boletines es una de las formas con las que espero ayudar a nuevos desarrolladores de juegos a dar sus primeros pasos, y a los que ya están en ello espero ayudarles a llevar su trabajo en nuevas direcciones.
Como habrá lectores de diversos niveles de experiencia, he divido este boletín en secciones:
Este primer boletín será largo. Intentaré establecer las bases sobre las que seguirán el resto de boletines. Además, ten en cuenta que está dirigido a una audiencia múltiple, de forma que según tu nivel podrás saltarte algunas secciones o leerlas por encima, pero no hay ningún problema si quieres leerlo entero.
Podrás encontrar la última versión de este boletín (con correcciones de ortografía, algunas notas a mayores y preguntas/respuestas) en la siguiente dirección web:
http://gamedevlessons.com/lessons/carta1.html
¡Por favor comparte este enlace!
¿De que está hecho un videojuego?
Los videojuegos se componen basicamente de dos cosas: datos (imagenes, sonidos, canciones, niveles) y código (instrucciones de ordenador).
Las imágenes y los sonidos están hechos con programas de edición de imagen y audio. Los niveles están normalmente hechos en algo parecido a un editor de imágenes - pero en vez de pintar formas, el programa pinta muros, objetos y personajes. Cuando se hacen videojuegos, parte del proceso conlleva crear el editor de niveles. Aunque muchos videojuegos comerciales no distribuyen sus editores de niveles, unos cuantos si lo hacen.
El código es como un guión de cine. Sin embargo, un guión de cine se puede seguir sin interrupciones, y precisamente lo que hace un jugador es interrumpir cualquier secuencia posible con su interacción. Por este motivo, el código es un guión contextual, de situación. En vez de:
Jenny entra en la habitación.
JOHN: ¿Qué tal tu día?
...el código debería tener en cuenta los cambios que el jugador podría haber hecho, y tendríamos:
Si la puerta no está cerrada, Jenny entra en la habitación.
(si lo está, llama a la puerta.)
JOHN (si Jenny está en la habitación): ¿Qué tal tu día?
JOHN (si no está): ¡Un momento, ahora voy!.
La programación no es exactamente como escribir un guión. Te darás cuenta de que intento utilizar un formato similar en los dos casos, y siempre hay varias formas de escribirlo. La programación hace un uso especial de los signos de puntuación y palabras clave para identificar modelos como estos, que suceden a menudo - este tipo de bloque es llamado un enunciado condicional. Nuestro ejemplo tendría esta pinta como código:
if( puerta.cerrada == false ) {
Jenny.entrar( laHabitacion );
} else {
Jenny.llamar( laPuerta );
}
if( laHabitacion.contiene( Jenny ) ) {
John.decir( "¿Qué tal tu día?" );
} else {
John.decir( "¡Un momento, ahora voy!." );
}
Si puedes ver la conexión entre este código y el trozo de guión al que se corresponde, entonces estás listo para sumergirte en los conceptos básicos de programación. Un programa llamado compilador traduce este lenguage comprensible en un conjunto de numeros y letras indescifrables, que actuan como instrucciones detalladas para el procesador del ordenador. Todos los videojuegos y programas que tienes, ya sea en un ordenador, una consola o un teléfono movil, existen en algún sitio en un formato legible como el código que acabamos de ver, pero normalmente sólo se distribuye la versión generada para que lo entienda la máquina, para proteger secretos de la compañia.
Programar es sólo un poquito de memorización, un poco de construir cosas y relacionarlas entre si de forma coherente, y sobretodo, el uso de unos cuantos patrones básicos. Es imposible escribir un poema Alemán sin conocer el lenguaje, es dificil componer música sin saber como tocar un instrumento; para los videojuegos, programar es el lenguaje y el instrumento. Si buscas aprender más hay muchísimos recursos gratuitos en internet y libros para aprender a programar muy asequibles. Yo recomendaría empezar con lenguaje C, el lenguaje de programación que es la base del C++ (el moderno lenguaje de programación usado por los programas más descargados/instalados), o ActionScript 3 (un lenguaje muy cercano al C++, diseñado para hacer programas web).
Comenzando
Empieza con cosas pequeñas. Muy pequeñas. Más pequeñas. He visto a muchos desarrolladores dar por perdido su sueño después de comenzar un proyecto fuera de su alcance, incluso comenzar en proyectos tan modestos como un plataformas tipo Mario, un pequeño RPG (role play game, juego de rol), o un simple FPS (first person shooter, juego de acción en primera persona). Si tu meta es jugar algún día a tu juego de ensueño, es más fácil que ocurra si comienzas con modificaciones de juegos (llamados mods) y haciendo juegos arcade clásicos. Tu primer intento si escribieras novelas no sería El quijote de la mancha, ¿Verdad?
Modificar un videojuego comercial es más fácil de lo que parece. Muchos juegos modernos para ordenador vienen con editores de niveles, editores de misiones o simples archivos de texto con los que puedes experimentar alterando el contenido del juego. Trabajar con herramientas y entornos profesionales te permitirá absorber lecciones de décadas de experiencia de desarrollo en la industria. Esta es también una buena forma para conseguir la atención de tus compañeros, ya que un nuevo nivel en un juego FPS popular o una nueva unidad en un RTS (real time strategy, juego de estrategia en tiempo real) de éxito tiene más calado en la comunidad. Estas son buenas prácticas trabajando en la escala y tipo de juegos que son desarrollados por enormes equipos de profesionales, aprendiendo acerca de los desafíos del flujo de trabajo y la especialización. También ayuda el que si haces un nivel para el juego Unreal, y es malo, puedes identificar con seguridad que es el nivel el que necesita más trabajo, ya que el resto del juego no necesita retoques.
Tal y como explicó mi colega John Nesky (un desarrollador de videojuegos independientes) a un amigo común, "Es más facil empezar con algo que funciona, y cambiarlo en algo distinto, que empezar con algo sin terminar y hacerse una idea de lo que no funciona o le falta." Encuentra algun código fuente de ejemplo para un juego retro - Pong, Breakout, Asteroids, etc.. - entonces intenta reformarlo pieza por pieza en un juego ligeramente distinto. A diferencia de modificar un enorme juego moderno con herramientas de edición, cuando estás trabajando con el código fuente de un proyecto pequeño, eres libre para modificar cada parte del juego. Incluso mejor, puedes hacer esos grandes cambios sin tirar miles de horas de trabajo en diseño de niveles, código de armas o comportamiento de enemigos que reaccionen a las decisiones del jugador.
¿Qué camino recomiendo?, en primer lugar, experimentar con la creación de niveles o gráficos para modificar un juego comercial y así aprender algo acerca de las herramientas y los problemas de diseño que conllevan. Una vez que te sientas cómodo, comienza a editar código fuente de juegos pequeños. Con confianza en como las imágenes individuales, el audio y los niveles encajan entre sí, estarás libre para centrar tu atención en como funciona la programación. A través de la experimentación podrás ganar un conocimiento más orgánico acerca de cómo todas las piezas encajan.
Normalmente desaconsejo usar entornos de desarrollo de juegos como Game Maker o lenguajes como DarkBasic si uno tiene un interés a largo plazo en el desarrollo de juegos. Estas alternativas fuerzan grandes limitaciones y se escalan muy mal a los métodos reales que usan los lenguajes de programación tradicionales. Por otra parte, apoyo PlayCrafter.com como una sólida introducción, a través de un entorno de aprendizaje, al diseño de videojuegos, precisamente porque se centra en el diseño de niveles y en el refinamiento y ajuste de la jugabilidad, mientras no intenta enmascarar, simular o simplificar la programación. Es una forma gratuita y online para practicar el diseño de videojuegos con un motor basado en físicas que soporta múltiples géneros. (Declaración abierta: trabajé durante un año con PlayCrafter.com y colaboré en la construcción de la herramienta de creación de juegos para el sitio web. No es por eso por lo que lo recomiendo, lo hago porque la creación de juegos en el sitio web funciona bien de la forma en la que lo hace.).
Si ya empezaste a trastear haciendo niveles, o modificando juegos, y te gustaría disponer de código fuente para juguetear, hay cientos de ejemplos disponibles en la red. También daré algunos ejemplos en código fuente de videojuegos en ActionScript 3, que preparé recientemente para unos estudiantes:
http://gamedevlessons.com/lessons/GameDevLessons-src-as3basics.zip (en inglés)
La parte más importante que debes hacer es: ¡EMPEZAR!. Puedes aprender la mayoría de lo que querrías aprender de forma gratuita a través de la experimentación, y usando recursos en Internet. Internet está llena de programadores open-source (open-source: programas que disponen su código fuente de forma abierta). Aprender ingeniera aeronáutica o arquitectura por experimentación es una receta para el desastre, pero aprender programación de videojuegos experimentando es completamente seguro.
Recursos gratuitos
Para creación de imágenes y manipulación:
http://gimp.org GNU Image Manipulation Program, conocido programa para edición de imágenes y alternativa gratuita al photoshop. (N. del T. bajo Windows recomendaría también Paint.net, mucho más fácil de utilizar que el gimp, aunque no tan potente).
Para la creación de efectos de sonido y su edición:
http://audacity.sourceforge.net Audacity
Para modelado en 3D:
http://www.blender.org/ Blender. (N. del T. otra alternativa gratuita podría ser Caligari Truespace, sólo para PC).
Compilador de ActionScript3, usado para la programación de juegos web:
http://opensource.adobe.com/wiki/display/flexsdk/ Incluye mxmlc, un compilador de AS3
Compilador de C++, usado en la programación de juegos descargables:
http://www.bloodshed.net/devcpp.html Dev-C++ 5 (sólo PC; usa XCode para Mac)
Música con licencia Creative Commons (gratuita y libre de royalties) (¡no olvides dar crédito a Kevin MacLeod si usas su música!):
http://incompetech.com/m/c/royalty-free/
Haz compromisos para terminar
Conozco un montón de desarrolladores de juegos independientes "parciales". Digo parciales porque tanto si son estudiantes en un proyecto como hobby, o profesionales especializados en una corporación gigante con su propio juego en marcha, o un experto en otro área explorando la creación de juegos como hobby, ellos no han terminado lo que han empezado. Por desgracia, el mundo exterior no está interesado en conducir coches casi terminados, vivir en casas medio terminadas, o jugar un juego parcialmente terminado.
Hay dos casusas de muerte en los proyectos independientes: (1.) falta de interés en acabar las pequeñas cosas que quedan cerca del final, como menús (y 2.) desesperación porque terminar el juego "como se supone que tiene que ser" llevará demasiado.
Para el primer punto, aunque hacer los menus y atar los cabos sueltos no es tan divertido como construir niveles y programar enemigos, nada acerca de hacer un juego es más excitante que ver a la gente jugándolo. Es emocionante saber que gente alrededor del mundo está alucinada (o pensativos, o tienen pesadillas) gracias a tu trabajo. La única forma de que esto ocurra es después de que el juego esté terminado. Así que apura ese tramo final, e ignora las tentaciones para añadir más características chulas que requerirán más trabajo sin planificar antés de que esté acabado.
Para el segundo punto, los juegos que salen como se supone que "tenían que ser" a menudo no son buenos. Lo que funciona en papel o suena bien en conversaciones luego no es lo que funciona bien en un juego en tiempo real, y viceversa. Un juego puede hacerse mejor si enfocas tus esfuerzos e ideas durante el proceso de desarrollo para ajustarse a tu talento, herramientas y tiempo. Echale un ojo a esta transcripción del diseño original que Id Software preparó para Doom, un juego que definió un genero. Piensa por un momento en cuanto habría perdido el juego en inmersión si tuviera 4 personajes principales, y alguna otra de las otras propuestas basura:
http://5years.doomworld.com/doombible/ (en inglés)
Incluso un juego decente y modesto, completado, es más valioso para la gente que el juego más grande jamás comenzado.
Imagina lo poco excitante que serían tus recuerdos hoy si Mario, Zelda, Final Fantasy, Sonic, Twisted Metal, Myst, MechWarrior, Doom, Chrono Trigger, Okami u otros juegos que adoras se hubieran quedado atascados para siempre en el 98%, porque las opciones de menú no estaban acabadas, o fueran cancelados porque (date cuenta de lo obvio que es esta trampa cuando la comentamos) los desarrolladores hablaron de más ideas de las que tenían tiempo para programar y crear. Sería como si alguien estuviera robando algo de tu infancia.
Y en conclusión, no robes a los niños.
Encuentra a alguien con el que trabajar
Primero, un gran AVISO: para la gente nueva en la programación, tener varios programadores en un proyecto puede hacer que vaya mucho más lento que tener 1. Muchísimo tiempo se pierde intentando encontrar sentido al codigo de otro, reescribiendo características que se solapan, y resolviendo errores por malentendidos acerca de la implementación de cada uno. 5 programadores principantes trabajando en un juego no harán el trabajo 5 veces más rápido que 1, pero juntos será unas 5 veces más fácil que no se termine nunca.
Cuando digo que encuentres alguien con el que trabajar, quiero decir de la misma forma en la que dos amigos tienen éxito cuando van juntos al gimnasio para estar en forma. ¿Tienes problema en hacer que el desarrollo de juegos sea una prioridad semanal, entre las demandas de los estudios/trabajo/vida social en tu vida?. Consigue a alguien con el mismo problema para que te ayude a seguir en la pista, y devuélvele el favor. Tener a alguien más interesado en el desarrollo de videojuegos con el que compartir historias, quejas, pedir opinión y compartir el resto de la aventura, lo cual es más seguro que ocurra en un margen razonable de tiempo que intentar nadar sólo en el océano. Pero hasta que al menos uno de vosotros tenga experiencia en unos pocos juegos completos, yo recomendaría que no trabajeis aún en el mismo juego.
¿No sabes donde encontrar alguien interesado en el desarrollo de juegos? Internet está lleno de ellos. Lanza el cebo en un foro comentando lo que quieres hacer o busca a otros que ya estén buscando.
O, si eres muy impaciente para usar ese método, o lo has intentado antes y no tuviste suerte con los compañeros, considera coger un entrenador/guia/maestro en el desarrollo de juegos. Gran parte de lo que hago es la asistencia a proyectos, y lo he hecho durante años (empezando con 2 años como cabeza visible de la sociedad de creación de juegos en la universidad Carnegie Mellon, http://www.gamecreation.org, en inglés), y si te interesa en serio esto, tanto si necesitas una sola charla para dirigirte en la buena dirección, ayuda periódica para cruzar algunas barreras, o guía semanal en tus progresos, ponte en contacto conmigo vía www.GameDevLessons.com (en inglés) hazme saber tu situación y trabajaremos una solución. Los precios no están en el sitio web porque las necesidades de asistencia pueden variar caso por caso, pero prometo que podremos encontrar un equilibrio muy razonable. Sólo quiero ayudar a nuevos desarrolladores a empezar; no cobraría nada si puediera, pero si tuviera que mantener un trabajo a tiempo completo para poder comer, entonces tendría mucho menos tiempo para ayudar a nuevos desarrolladores en su comienzo. (N. del T., Chris DeLeon sólo puede ofrecer sus servicios a gente que pueda comunicarse con el fluidamente en inglés escrito)
Comenzar con un nuevo lenguaje/herramienta
¿Te sientes atascado, porque conoces un lenguaje de programación, pero te es dificil hacer juegos eficientes en él (Ensamblador, Basic, ML...) o es imposible distribuir el juego sin que los usuarios tengan que descargar enormes actualizaciones (.NET, Java...)? Por lo que más quieras, aprende un nuevo lenguaje de programación. Si ya ha pasado mucho tiempo desde que aprendiste un lenguaje de programación, estarás encantado al comprobar como las habilidades con un lenguaje se trasladan al otro fácilmente. No es como aprender Latin, Chino o Ruso - alrededor de un 80% lo dedicarías aprendiendo que sintaxis se utiliza en ese lenguaje para declarar variables, y para bucles básicos, condicionales y funciones. El otro 20% consiste en aprender la lista de trucos y que estructuras u opciones te permiten hacer en este lenguaje lo que en otro sería redundante, desorganizado o muy inconveniente. Si aún no estás formado en C++ podrías empezar, ya que es casi un lenguaje universal en entornos de programación; si te desenvuelves bien con C++ y estás detrás de la curva de aprendizaje del diseño web, te asombrará lo que puedes hacer con ActionScript 3. Si conoces todos estos entonros, ¿has trabajado mucho en Objective-C? (y si los conoces todos... ¿que haces leyendo la sección "nivel medio" de este boletín?).
Recursos adicionales
En el sitio web de mi hobby, donde tengo en marcha mi experimento "un juego diário". hay una sección de recursos (http://interactionartist.com/index.php?page=resources en inglés) con presentaciones que he creado para ponencias en la facultad y proyectos de juegos independientes, así como una lista de enlaces a sitios relativos a formar una carrera en la industria del videojuego.
¿Intentas introducirte en la ola de desarrollo para iPhone? Es barato, fácil y más rápido de lo que crees.
Desarrollar para consolas tradicionalmente suponía un coste de decenas de miles de dólares por cada consola. En el caso de los equipos de desarrollo más baratos, que sólo costaban un par de miles por unidad, el fabricante de la consola aún exigía que tuvieses una oficina, un plan de negocio, y una prueba funcional de concepto antes de que te tomaran en serio como para dejarte uno de sus bebés.
Cuando el editor ngmoco, Inc. me contactó para hacer Topple para el iPhone, no tenía experiencia previa en Objective-C, nunca había programado en un Mac, y no tenía un iPhone, ni siquiera un iPod (ni táctil ni de otro tipo). Así que fui de compras y cogí un Mac Mini (600$), un iPod touch (250$), un pack teclado/ratón y un monitor de PC usado (100$). Pagué otros 100$ por una licencia de desarrollo de Apple, que me fue entregada una semana o dos después de pedirla. Más o menos por 1000$ (algo menos de 1000€) tenía todo lo que necesitaba. Sin contratar plan telefónico, sin un portatil ultra potente y caro, y no necesité ningún permiso de Apple, aparte de la licencia de desarrollo (100$), la cual funciona como un filtro para evitar que cualquiera que no esté realmente interesado en ofrecer productos terminados envíe basura, y este es el único paso necesario.
Este sí que es un movimiento inteligente. Apple tradicionalmente representa el trozo pequeño del pastel porque los desarrolladores están haciendo aplicaciones para PC - en un esquema de pescadilla que se muerde la cola debido a que la mayoría de la gente tiene un PC porque es el que tiene más aplicaciones - y de este modo Apple de una forma ingeniosa encuentra una vía para conseguir desarrolladores para el hardware de Apple, en Objective-C (también de Apple). Con desarrolladores en la plataforma produciendo un montón de nuevas aplicaciones, eso supone un gran volantazo en la dirección predominante del desarrollo general, donde siempre se veía beneficiado el entorno PC. Yo mismo estoy escribiendo esto desde mi reluciente segundo Mac.
Volviendo a lo que íbamos, no voy a decir mucho más en detalle acerca del desarrollo para iPhone, ya que estoy inmerso en varios NDAs acerca del tema, pero ya que estás en la sección avanzada de este boletín creo que no necesitas que te diga mucho más. Apple tiene toneladas de códigos de ejemplo disponibles para la plataforma, una vez que eres un desarrollador registrado. En una semanas e invirtiendo sobre 1000$ en tu propio entorno de desarrollo (suponiendo que no tengas ya un Mac, un monitor y ratón y teclado o un iPhone/iTouch), puedes tener un prototipo funcional ejecutándose sobre la máquina real. Enviarlo al App Store (la tienda online de Apple) es un proceso igual de rápido y (sorprendentemente) fácil.
Si eres como muchos de los desarrolladores de juegos y te estás pensando dar el salto, pero prefieres seguir con tu asentada situación, se lo que estás pensando - el App Store pronto estará saturado, y es sólo una fiebre pasajera que terminará pronto. (1.) Las aplicaciones creativas, inteligentes y bien acabadas van a destacar por encima de todas las demás (2.) cuando alguien tiene un teléfono normal, puedes suponer que conocen a otra gente y quieren comunicarse con ellos; cuando alguien tiene un iPhone, puedes suponer que además están dispuestos a pagar un poco más en entretenimiento y extras (3.) gracias a la mano invisible de Adam Smith, muchas otras compañías están apurándose a comercializar terminales competitivos en un intento para cazar el exceso de desarrolladores y consumidores, emulando el éxito de Apple, así que estas nuevas habilidades podrán ser aprovechadas.
Desde luego no intento dar consejos de negocios (seguramente no sería buena idea que abandonases tu trabajo diário o comenzases a visitar inversores), y por supuesto no estoy sugiriendo que esta es una forma de hacer dinero (los mercados de entretenimiento son, como mínimo, volubles e impredecibles). Pero te diré que creo que es la forma más fácil y barata para conseguir experiencia desarrollando en una plataforma comercialmente activa que no sea ordenador/web. Esto puede ser un hobby divertido, una experiencia de aprendizaje valiosa, y si los planetas y las estrellas se alinean correctamente, incluso puede que saques algo de dinero.
"Imitar el papel en la pantalla del ordenador es como cortar las alas de un 747 y usarlo como un autobus en la autopista."
-Ted Nelson
Hay una idea incesante en los cursos de diseño de videojuegos, en ponencias, libros, talleres de conferencias y foros online acerca de que la mejor forma de entender y planear un videojuego es a través de un profundo análisis de dados, ruletas, cartas, juegos de tableros y similares.
Si trabajas a diario con Milton Bradley (MB juegos) o los hermanos Parker (otro fabricante de juegos de mesa), sería una forma útil de emplear tu tiempo, para el resto de mortales trabajando en videojuegos en tiempo real, creo que emplear la mayor parte del análisis en el mundo "analógico" es una forma ineficiente de destacar o resaltar elementos comunes (en el mejor de los casos), y generalmente una grandísima pérdida de tiempo.
Esta opinión dice que si los videojuegos son juegos, y esas otras cosas son juegos, entonces su estudio debe ser relevante. El problema es que los videojuegos no son un subconjunto de los juegos de papel y tablero, es al revés. Con cientos de millones de cálculos por segundo, podemos simular por completo los juegos de papel y tablero en el ordenador; con un conjunto de estados visibles y algunos cambios de estado cada pocos segundos, por contra, podemos asegurar sin duda alguna que no es posible simular videojuegos sin un ordenador.
Nada de lo que hay en el mundo del papel y el tablero tiene que ver con lo que funcionó en el Pong, Warlords, Asteroids, Pac-Man, Tetris, Bubble Bobble, Donkey Kong, Castlevania, Blaster Master, Paperboy, Mega Man, Ninja Gaiden, F-Zero, Goldeneye 64, Quake, Resident Evil, Wipeout XL, Street Fighter 2, Snood, Soul Calibur, Smash Brothers, o Metal Gear Solid. En los juegos de dragones y mazmorras, o versiones electrónicos del ajedrez o poker, obviamente esos modelos en papel y esos temas se aplican, ya que hablamos de material emulado directamente.
El que se manejen números aleatorios no significa que los dados y las ruletas sean útiles, la potencia de cálculo de las máquinas y sus posibilidades deja estos primitivos mecanismos obsoletos. Y a no ser que estés jugando un juego por turnos en multijugador, donde todos los jugadores están en la misma habitación, el factor dominante en juegos tipo poker u otros prototipos en papel (estudiar la reacción de los otros jugadores) no vale para nada.
Podemos aprender algunas cosas de otros medios, por supuesto. Podemos comparar algunos aspectos de los juegos de tablero, o del baloncesto, con lo que hay en un videojuego. También puedo hacer una comparación con otras actividades, como lavar los platos, cortar el pelo, bajar a rolos una colina, administrar una compañia, escoger una película en el cine... Eso no significa que debamos dedicar cada página de cada libro sobre diseño de juegos, cada hora de cada ponencia o clase, o cada taller en cada conferencia a estas cosas, que tienen pocos paralelismos con el diseño de videojuegos y como se juegan.
No me mal interpreteis - el papel es útil. También las pizarras. Hacer bocetos es útil. Un programador es inteligente como para hacerse una idea sobre ciertas cosas en papel antes de escribir código, y un diseñador a su vez es inteligente como para realizar unos bocetos antes de meterse de lleno con el editor de niveles. Hay un mundo de diferencia entre usar papel para bocetar espacios, mientras consideras las líneas de visión y la navegabilidad, a usar el papel para establecer conjuntos de reglas en la búsqueda del entendimiento de como debe funcionar el nucleo de un videojuego.
Como se comporta en funcionamiento, como todo encaja a la vez, es lo importante. Y de igual forma que portar un videojuego de consola de TV a una consola portatil o viceversa puede necesitar un rediseño total para adecuar la forma de entrada y las limitaciones del hardware para cumplir las expectaciones de esa plataforma, puedes apostar que hay una inmensa cantidad de rediseño para portar desde/hacia un "hardware" sin procesador, con espacio de "pantalla" ilimitado, manejo con el cuerpo entero o con voz, y "RAM" que está limitada a la posición de unos dados o ruleta, fichas sobre un tablero y una pequeña pila de cartas. Estarías portando una jugabilidad que ha sido diseñada para unas limitaciones estrictas en una "consola" con 500 años de antigüedad.
He oido argumentos de académicos conforme esto es lo que explican en sus clases de diseño de juegos porque los diseñadores no pueden programar. Esto tiene solución: en primer lugar, ayudaría mucho que los futuros diseñadores pudieran realizar simples programaciones, incluso si escriben código malo, sólo para conseguir entender conceptualmente como hay que trabajar desgranando las instrucciones que una máquina maneja para comunicar conceptos interactivos. En segundo lugar, si hay posibilidades de que realicen sus tareas de diseño en un entorno libre de programación, que lo hagan:
|
¡Tachán!. Resultado: diseño de videojuegos. Ejercicios como estos hacen poco para preparar a la gente para diseñar juegos de tablero, ¿pero acaso hay una industria con gente dispuesta a destronar al ajedrez, el parchís o el monopoly? ¿Es esto a lo que se refiere la gente cuando dice que aspiran a ser diseñadores de videojuegos, o es el motivo para que alguien acuda a un master en diseño de videojuegos?
He visto enormes proyectos comerciales y proyectos independientes de estudiantes muy similares entre sí perder el tiempo tontamente en inútiles prototipos en papel durante meses, casi un año en uno de los casos, diseñando juegos de cartas y tablero para "descubrir los mecanismos", para al final tener que empezar de nuevo cuando cambian al mundo digital, porque nada de lo aprendido fue relevante. Las compañías pierden dinero por esto. La gente pierde su trabajo por esto. Los estudiantes pierden la esperanza en sus sueños por esto. Si hablásemos de perspectivas académicas acerca de filosofías pasadas de moda sería otra cosa, pero hablamos de algo que puede estropear los juegos futuros, y que hace daño a las compañías presentes. Aprovechando el ejemplo anterior, es robar a los niños, y eso no está bien.
No quiero decir que los videojuegos en tiempo real no puedan ser diseñados partiendo de prototipos en papel y principios derivados del análisis de juegos de mesa. Digo que hacerlo es como intentar diseñar un avión militar basándose en como vuelan los mosquitos. Digo que los videojuegos que resulten de este proceso serán, generalmente, malísimos, excepto que en algún punto tengan un rediseño completo para ser adaptados a una plataforma de juego electrónico.
¿Tienes una pregunta acerca de alguna cosa en este boletín? ¿O algo que me querrías comentar? Envíame un correo electrónico a chris@gamedevlessons.com (sólo en inglés, por favor), y te contestaré tan pronto como pueda. Las respuestas a preguntas comunes irán en esta sección:
(Aún no hay preguntas)
Muchas gracias por leerme,
Chris DeLeon
PD estoy escribiendo estos boletines para ayudar a la gente, y quiero que los contenidos lleguen al mayor número de personas posible. Por favor, comparte este enlace si sabes de alguien al que le pueda resultar útil esta información: http://gamedevlessons.com/lessons/carta1.html. Enviar el enlace es mejor que copiar/pegar el texto entero, ya que podrán ver siempre la última versión de los textos con preguntas y respuestas o correcciones. Si quieres estar al día con este boletín mensual, no tienes más que suscribirte en GameDevLesson.com Boletín mensual.
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.