Novedades
Finalmente me he decidido a cambiar de aires. He hecho balance y, aunque el sector de los móviles y smartphones es un campo genial y, sobre todo, entretenido, he decidido aflojar un poco el estres natural que lleva este sector.
Me atraía mucho incorporarme al equipo de Blaut pero por otro lado me invadia la inseguridad logica que conlleva llegar a un proyecto en un estado tan avanzado. Durante las conversaciones con Reni, el CEO de Reinherdt, surgió casualmente la conversación sobre el proyecto paralelo a Blaut. Se trata, en términos generales (entre clausulas de confidencialidad y NDA no hay quien escriba un blog del sector), de un motor muy completo de RTS.
Aunque, en apariencia, cumple todos los campos formales de un RTS, su objetivo no es un juego. Será, en suma, un simulador de situaciones abierto que, obteniendo una plantilla de entrada con el resumen de la situacion, podrá generar multiples simulaciones cubriendo todos los aspectos y circunstancias posibles dentro de un esquema de posibilidades. El analisis del proceso de toma de decisiones es el objetivo ultimo de esta aplicacion. No puedo dar mas datos, por desgracia, sobre en que ambitos se usara y sobre todo, cuales son los patrones aplicables. En fin.
Este proyecto, al cual casi exigi unirme, esta aun en fase de planificacion y diseño. Nos hemos organizado en cuatro grupos de trabajo, cada uno con un miembro coordinador y nos reunimos cada dos o tres dias para poner en comun las conclusiones y avances. La composicion es la normal en este tipo de cosas: un equipo de programacion pura, un equipo de diseño general, un minusculo equipo de grafistas (pues la aplicacion no requiere grandes alardes) y un equipo de diseño especifico.
Obviamente es un proyecto bajo pedido, parcialmente ya financiado y la presion es menor que, por ejemplo, en un desarrollo comercial de juego. Esto me ha dejado tiempo para reflexionar profundamente sobre el tema del RTS y me he decido a escribir los proximos post al respecto.
Para empezar me gustaria desmitificar un poco el objeto central de discusion. ¿Que es un RTS?
Cuando hablamos de Real Time Strategy (estrategia en tiempo real), el concepto rapido es del clasico juego de B&B (build and battle), es decir, acumular recursos, construir instalaciones que generar unidades, descubrimientos o mejoras y, por supuesto, luchar.
En realidad, el concepto RTS es mucho mas complejo. No se trata de un elemento para diferenciar los juegos “por turnos” de aquellos que no lo son.
De entrada, aunque el concepto RTS nacio en la industria de los juegos, ha estado previamente en el mundo fisico. Tenemos juegos de mesa como el Monopoly que son TBS, es decir, estrategia por turnos en el que un jugador tiene un turno de juego con una tirada y unos efectos derivados de la misma y pasa el turno al siguiente jugador. En mi propio concepto de “tiempo”, denomino a este tipo de juegos con el la frase “de expectativa”. No existe una estrategia como tal (salvo la idea o las ganas que tengamos), sino un elemento tactico pues siempre dependemos de la jugada del jugador anterior (y de su tirada y de las cartas que saque, etc.).
Existen, en cambio, otros juegos de mesa que, a pesar de contar formalmente con turnos, si caen bajo el concepto de la estrategia puesto que nuestro guion a seguir no depende, exclusivamente, del movimiento del otro jugador. Aunque parezca extraño, coloco al ajedrez como el primero de estos juegos.
El jugador novel de ajedrez juega segun los movimientos del contrario o por medio de prueba y error. En cambio, el jugador avanzado de ajedrez elige una estrategia general. Esta, se complementa con las jugadas tacticas de su eleccion (aperturas, etc) y este conjunto de movimientos se desarrolla en un proceso mental que no depende de los movimientos del contrario. Cierto es que hay que considerarlos, pero el hecho mismo de la eleccion de la estrategia y de sus elementos tacticos conlleva la prevision de las posibles movimientos del contrario. Por tanto, el elemento estrategico se realiza a priori (mediante la eleccion despues de la apertura o incluso antes) y se perfecciona a tiempo real segun los movimientos del contrario (elemento tactico).
El concepto de juego estrategico, derivado de la practica militar, cambia con el tiempo. El mismo origen del juego por turnos se basa en el proceso de toma de decisiones que se realizaba desde la antiguedad hasta, incluso, la segunda guerra mundial. Estrategia, ejecucion, accion y reaccion. Evidentemente, en la mayoria de los casos la niebla de guerra era la culpable de este tipo de enfrentamiento. Con los avances en la tecnologia belica se minimiza el impacto de la niebla de guerra formal (es decir, la vision tactica a nivel de campo de batalla) aunque se mantenga la niebla de guerra informativa (el proceso de captacion, analisis y utlizacion de informacion; inteligencia y espionaje, vamos).
Esta transformacion de conceptos es la que desemboca en el RTS, casi por accidente. Es decir, el encuadre de un juego estrategico en tiempo real viene por la necesidad de establacer elementos uniformes que afecten a los jugadores por parte de un jugador “que no juega”. Es decir, el elemento Gaia.
En este sentido, se puede considerar que se paso del TBS al RTS porque un equipo de programacion no encontro otro metodo mejor de lidiar con un problema. Por ejemplo, tenemos el caso de Dune 2. La necesidad de tener un elemento relativamente aleatorio que afecta en mayor o menor medida al jugador (los gusanos) obliga a que el planteamiento de un juego por turnos sea, cuando menos, ridiculo.
No digo que esta fuera la razon unica o principal del modelo de diseño de Dune 2 pero tuvo bastante que ver. Asi, podemos analizar otros modelos de Gaia en diferentes juegos con resultados muy distintos. Los desastres en Populus, los animales en Age of Empires… hay un sinfin de ejemplos.
Termino aqui esta entrada esperando haber despertado la inquietud acerca del concepto excesivamente simplista que tenemos de los RTS.
Stay tuned!
De vuelta
Estas vacaciones, mientras el mercado se movia por si mismo, me han resultado demasiado cortas. Cierto es que mientras esta el tema de la edicion/publicacion/marketing en marcha, poco podemos hacer puesto que, al igual que la moda textil, estamos a la espera de un informe final sobre ventas que influenciara sobre manera las decisiones sobre los proyectos que se aprueban ahora.
Sin embargo, mientras espero los resultados (que siempre tardan un poco porque hay mucho filtrado que hacer), he recibido dos ofertas interesantes. Una es de Reinherdt Studios para colaborar en la modificacion de su motor Blaut. Se trata de un engine 3D enfocado hacia RTS que ha tenido una oferta mejor del campo de los documentales, Muchos recordaran el exito que le motor de Rome: Total War tuvo en su momento en este campo. Pues bien, parece que Blaut va a dominar un amplio campo del mismo sector en un futuro proximo. Mi labor va a ser muy limitada en este proyecto, puesto que el motor 3D esta terminado y el modulo de fisicas esta de camino.
Por otro lado, el otro encargo que he recibido es la supervision de un proyecto que pretende revitalizar la industria de RTS de bajo coste aqui en Alemania dado que, junto con las aventuras graficas, es el sector que parece mas en alza.
Todo eso sin contar el enorme esfuerzo que supone seguir en la linea de produccion de productos para plataformas moviles. Asi que puede ser que me mantenga en silencio un tiempo.
Como suele decirse, stay tuned!
Navidad
Ya estamos en esas fechas en las que la industria se ralentiza porque lo que no se ha hecho ya, no se puede solucionar. Estas fechas de publicacion de rankings de los mejores, peores, caros, etc, juegos de 2008. Los publireportajes sobre los lanzamientos de navidad. Las ofertas de juego + consola para intentar pillar mas publico. Y, como no, los anuncios de ultima hora que retrasan algun lanzamiento hasta 2009, despues de la campaña.
Vamos, lo de cada año. Sin embargo, las cosas estan cambiando. Si hasta hace un mes pensabamos que 2008 seria otro año mas sin el tan cacareado disco de Guns’n'Roses, Axrl Rose se ha empeñado en llevarnos la contraria. Y eso le ha salido caro a Dr. Pepper, el refresco que prometio que si lo sacaba antes de terminar el año serviria su producto gratis. Bueno, mas o menos.
Pero por mucho que hayamos avanzado con este pequeño paso que nos acerca mas al limbo de los productos de lanzamiento largamente aplazados, podemos estar seguros de algo: cerramos otro año mas sin Duke Nukem.
Respondiendo
Un amable lector me escribe un correo pidiendo consejo sobre su iniciativa empresarial en el sector de los videojuegos. En realidad, poco puedo aportar en concreto pues no me encuentro en España y, la verdad, desconozco bastante el panorama alli.
Sin embargo, intentare responder las cuestiones lo mejor que pueda.
En primer lugar, no importa si el grupo de desarrollo es pequeño o grande. Para hacer muestras de nuestro trabajo y buscar productora o editora hace falta solo lo que hace falta: hacerlo. La redundancia viene a lo siguiente: todo depende del objetivo.
Si nuestro proyecto se dirige a una plataforma grande (es decir, PC, Wii, PS2, PS3, Xbox) o incluso a una mediana (PSP, DS), sobra decir que rara vez un grupo de desarrollo sin contrato podra cumplir las expectativas de una produccion completa (tal y como anda la cosa). Hay excepciones, por supuesto, dependiendo del tipo de juego.
En este caso conviene realizar una demo lo mas perfecta posible, registrar el asunto, e ir en busca de una productora. Otra opcion es hacer una beta y presentarse a concursos (aunque hay que estar atento a las bases porque en mas de una ocasion nos podemos llevar una sorpresa).
Si nuestro objetivo es una plataforma pequeña (moviles, pda, flash) lo normal es presentar un buen paquete de juegos finalizados como muestra de nuestro trabajo.
En cualquier caso, meterse en el sector no es dificil. Lo dificil es meterse en el sector de la manera que tienes en mente.
Como dije antes, todo depende del tipo de juego. Los juegos llamados “casuales” y todos los generos y variantes de “puzzles” no requieren un gran esfuerzo en produccion pero si requieren un planteamiento eficaz y un trabajo depurado para poder destacar. La idea, como siempre, es lo mas importante.
En el resto de los generos, o en su mayoria, como puedes ver en el mercado se abusa de la super produccion, en plan pelicula. Competir en igualdad es imposible debido al costo de produccion. Sin embargo hay que tener claro algo. En la mayoria de los juegos estilo super produccion de los que se cacarea tanto (GTA y similares) el presupuesto es desorbitado, si, pero se hace una pesima gestion del mismo. Por tanto, cuando se dice que tal juego ha costado tal cantidad de dinero, podemos estar casi seguros que un buen tajo del mismo ha sido desperdiciado vilmente o, simplemente, mal empleado.
El asunto de la sobre produccion grafica es algo que ya cansa aunque todavia vende. Es un fenomeno que ha alcanzado ya hace un tiempo incluso a la PSP. Es una mala vara de medir que nos indica que a mejores graficos, mejor juego. Mi experiencia (y seguro que la tuya tambien) dicta que eso es falso la mayoria de las veces.
Por tanto, todo depende en principio de la idea en si. En la cuestion comercial, es cosa de intentar hacerlo. Si se preve no poder cumplir las expectativas de mercado, entonces se hace un modelo, un prototipo, una propuesta, y se busca financiacion. Pero para que te tomen en serio, procura abultar un poco el curriculum con mas muestras de otros proyectos.
En cuanto a la autoedicion, pues si, es una salida viable. Aunque, comercialmente, no funciona siempre. En principio, la autoedicion es una buena via para, por ejemplo, los juegos flash y los puzzlers. Hay bastantes paginas que se dedican a la comercializacion y distribucion de los mismos. Los plataformas antes tambien vendian lo suyo, pero la cosa parece haber decaido. Los juegos incrustados, es decir, juegos online para jugar desde el navegador tambien tienen su mercado pero hay que traer propuestas originales y bien depuradas para hacerse un hueco.
Respecto a los juegos para moviles tienes mejores opciones. Con un catalogo decente de juegos puedes satarte el paso de buscar productora o editora y acudir directamente a los portales de contenidos para moviles. Hay muchos, es cuestion de comparar. Eso si, el problema de los juegos para moviles es la compatibilidad, asi que hay que tener cuidado al usar librerias o frameworks de terceras partes y, sobre todo, estudiar la cuestion grafica (los tamaños de pantalla, resoluciones, etc, varian tanto que puede ser un verdadero problema).
Al respecto del mercado en si, es algo que no puedo responder. Sinceramente, que yo sepa practicamente nadie del sector admite entenderlo. El mercado de los videojuegos crece constantemente a pesar de la crisis, la pirateria y todas las excusas que se puedan inventar. La cosa avanza.
El problema es que avanza de manera desigual. No existe un mercado de videojuegos, sin muchos a la vez solapandose. Por ejemplo, en un pais no existe un mercado unitario nacional. Se descompone en plataformas, por ejemplo. Y la cosa varia mucho de un pais a otro.
Por poner un ejemplo, la aventura grafica es un genero que se consider practicamente muerto en USA. Sin embargo en Alemania es uno de los mas apreciados. Y eso dentro de la plataforma PC. En Japon la cosa se complica muchisimo mas. Por tanto hay que tener en cuenta todos esos detalles.
En fin, seguro que se me queda algo en el tintero, pero ya es algo.
Diseño
Mi compañero Werner se ocupa del asunto de recursos humanos en la empresa. Siempre esta revisando curriculums y analizando todas las propuestas que nos llegan. Alrededor del 10% de lo que recibe son muestras de gente que o bien ya esta o ha estado en el sector o ha colaborado en el mismo de paso (por ejemplo, grafistas para concept-art o diseños arquitectonicos, musicos, etc). El resto de los remitentes de informacion son aspirantes a entrar en el sector, algunos con trayectoria amateur o indie y la mayoria sin ninguna experiencia previa.
El examina todas las propuestas pues a veces sucede que alguien sin ninguna idea del asunto viene con una buena idea. Es el caso, por ejemplo, de dos chavales. Uno fue contratado el año pasado y otro este verano. No tenian ni idea del sector y su experiencia era nula. Como programadores eran unos autenticos desastres. Sin embargo sus ideas eran buenas. Realmente buenas. Despues de un apropiado curso introductorio para ponerles los pies en la tierra, ahora son dos de nuestros seis Game Designers.
Habitualmente a la gente del sector nos preguntan que como se entra o que hay que estudiar para poder entrar. Son las mismas preguntas que se hacen en los foros de desarrollo y llega un punto que cansa el asunto. Las respuestas son muy sencillas. Si eres programador, pues programa. Cuando tengas algo hecho, mandas muestras de tu trabajo y listo. Lo mismo se aplica a los grafistas y los musicos. Evidentemente, lo ideal es hacer un minimo estudio de mercado y ver que empresas hay, que tipo de productos lanzan, etc, para ver si uno puede encajar ahi.
Sin embargo, la cosa se pone complicada cuando hablamos de los diseñadores. No hay nada, absolutamente nada que puedas hacer para “convertirte” en diseñador de juegos. Y la razon es clara: no existe tal cosa. Una persona no “diseña” juegos. Si, el puesto laboral existe. Pero no es un oficio per se, sino una ocupacion. Y es diferente. Todo esto viene al clasico “he tenido una idea para un juego que es maravillosa y sera genial”. A continuacion el que lo dice suele pedir a alguien que lo programe. Gratis. Y si algun programador accede, la cosa suele irse al garete en breve.
El diseño de juegos se realiza por un equipo de personas. Si tienes una idea para un juego no puedes pedirle sin mas al programador que te haga tal o cual cosa o al grafista que haga tal o cual escenario. Hay una serie de pasos previos que no se pueden evitar: tipo de desarrollo, herramientas a usar, presupuesto, requisitos de hardware, etc, etc.
Por eso digo que no existe tal puesto. El diseño de un juego se realiza en equipo y, normalmente, bajo la supervision de una persona que pueda aglutinar los diferentes aspectos y dirigir al equipo. Se suele designar como “lead designer” o cualquier otro nomber que se te ocurra como “team manager” o cosas asi.
Asi que volvamos al punto de interes. Se te ha ocurrido una idea. Una idea para un juego. Bien, en la mayoria de los generos la idea es una historia. Asi que desarrolla esa historia. Debes ser capaz de comunicar correctamente que es lo que tienes en la cabeza de una manera clara y organizada. Si no sabes escribir con cierta correccion, expresarte, etc, es probable que estes perdiendo el tiempo con este proyecto. Proporcionar una idea para un juego es igual que escribir una novela.
En este negocio nadie confia en el mito de que hay un modelo de documento de diseño. Crea el tuyo propio con una estructura que de sentido al documento. Cuando lo tengas terminado, daselo a leer a cualquier amigo o conocido que no este en la industria y preguntale si lo ha entendido perfectamente. En caso afirmativo, ya tienes tu documento de diseño.
El unico consejo que sale de la experiencia del sector de videojuegos es exactamente el mismo que se le da a los escritores cuando presentan una obra para una propuesta comercial a un editor. Ante todo, haz un resumen breve y claro y adjuntalo al documento de diseño. Despues de todo, es lo que la mayoria lee antes de decidir. Salvo Werner, claro.
Devkits
La preparacion de la campaña navideña se ha cobrado su tasa. Pocas horas de sueño, mucho estress… Pero la cosa ya ha acabado. Todo lo que se podia hacer se ha hecho ya.
El resultado: una campaña en tres etapas para el lanzamiento escalonado de 96 productos. Tambien casi una docena de contratos de sponsor y otro cantidad similar de adaptaciones. Diez conversiones, cinco adaptaciones, como unas treinta licencias, varios portings… En fin, lo de siempre, poco mas o menos.
Ahora viene un periodo casi de calma chicha mientras se termina el testing, el marketing y se preparan los canales de distribucion. Aprovechando este paron pude darme un salto a una pequeña feria de ocio que se celebraba relativamente cerca de aqui y darme un chapuzon de informacion.
En el sector de videojuegos la representacion era mas bien escasa ya que por lo general la gente del sector se reserva para las grandes reuniones. Aun asi habia mucho desarrollador minoritario o independiente y alguna compañia mediana. Hable con mucha gente y hubo un detalle que estuvo presente todo el rato: el problema de los devkits.
El devkit, para entendernos, es un paquete completo para desarrollar para una plataforma especifica (vamos, las consolas) que no solo incluye hardware y software, sino que tambien incluye un monton de cuestiones relativas a la imagen del producto, el control de calidad y unos documentos de condiciones, clausulas y estipulaciones kilometricos. Ademas, por supuesto, de los precios de los devkits, que se consiguen en una especie de alquiler (la definicion legal varia segun el pais).
La primera cuestion en si es la base hardware del devkit. Incluye una consola (aunque normalmente te “sugieren” que sean dos) casi igual a la de produccion pero con diferencias para desarrollo. Estas diferencias varian segun el fabricante, desde “test modes”, “debug modes” o “engineering mode” por software hasta esas mismas funcionalidades por hardware (amen de alguna proteccion quitada, como el RSA, la validacion de cartuchos, CD o DVD originales y cosas asi). Ademas suele ocurrir que se necesita tambien algun accesorio extra (ademas de los propios de la consola), como algun grabador de cartuchos o similar y dispositivos de memoria virgen.
La segunda cuestion, del software, es, contradictoriamente, mas precaria. Por lo general el sistema de desarrollo se realiza en un 80% sobre PC y el resto hay que terminarlo (a menudo mediante prueba y error) en la consola. Esto supone en ocasiones elevar el numero de iteraciones del producto hasta niveles absurdos. Hay que contar con que en diversas plataformas hay cierto libre albedrio, es decir, que puedes hacer gran parte del desarrollo con las herramientas que prefieras para despues encajonarlo en un paquete que encaje con el sistema de desarrollo. Cada cual escoge la opcion que le sea mas util. Los paquetes “extras” de software que ofrece la compañia no suelen ser ninguna maravilla, por lo que me comentan.
El tercer aspecto viene a ser el peor. Una vez tienes un producto presentable (no final) hay que pasar el filtro de aprobacion de la compañia. Examinan la colocacion correcta de los elementos de marketing corporativo (el logo de ellos, vamos), hacen una analisis y te dan sus “sugerencias” hasta volverte loco y una buena tonelada de problemas mas. Pasar el filtro a la primera, incluso con experiencia previa de productos aprobados, suele considerarse suerte en ese sector.
Sin embargo, respecto a este ultimo punto hay dos excepciones. Si eres un desarrollador independiente y la consola tiene un programa de licencias para este tipo de desarrollos, el filtro es mas suave. Asi de memoria me viene a la mente el asunto del Wiiware de Nintendo. La otra excepcion es la situacion contraria. Me comentan muchos que si perteneces a una compañia de las de “high budget” el filtro tambien es muy suave. Eso explicaria como pasan el “control de calidad” muchas aberraciones que encontramos en el mercado.
En definitiva, el asunto se compone de dos partes: por un lado el dinero (no solo respecto al costo del devkit) y por otro lado el curriculum. Conoci a varios desarrolladores de bajo presupuesto que son tratados muy bien por algunas compañias debido al curriculum que tenian: cientos de desarrollos para diferentes plataformas en una trayectoria larga. Asi que el principante, o bien acude al canal de desarrollo independiente o bien consigue colocarse en un sello, estudio o empresa que tenga ya su experiencia y trayectoria. Tambien cabe otra posibilidad, ofrecer un proyecto avanzado a un publisher y que con su apoyo se consiga introducirse en el meollo. Por supuesto hay compañias mas receptivas a los desarrolladores independientes que otras. En esta feria se hablaba bien de Microsoft a la hora de prestar ayuda a los desarrolladores pequeños que vienen con un proyecto bajo el brazo. Aunque, claro, habria que analizar cada caso por separado.
Viendo este asunto desde todos los lados, la cosa cuadra. Es la explicacion perfecta de las estadisticas que vi hace unos meses sobre desarrollos. Las dos plataformas con mayor numero de productos desarrollados y mayor numero de lanzamientos son el PC y el movil. La causa es clara: en ambas el coste del “devkit” depende de lo que queramos gastar. Existen compiladores estupendos y gratuitos en PC y, a la hora de la verdad, para desarrollar en j2me solo tienes que gastar dinero si quieres ahorrar tiempo (por ejemplo, comprando liberias o recopilaciones de snippets, por poner dos casos). Esto baja los costes de desarrollo permitiendo, incluso, que en el caso de los desarrolladores independientes sea “cero” a nivel de software.
Obviedades aparte, algo me preocupa. Creo que los fabricantes de consolas estan ignorando una cuestion que les va a pasar factura. El desarrollo de “homebrew” o software casero para consolas avanza muy rapido. Cierto es que va, para ellos, de la mano de la pirateria por el uso de modchips, flashcards o firmwares parcheados, pero es un problema de concepto.
Llevo varios meses probando muchisimos juegos en la DS y ninguno ha llegado a engancharme o a producirme esa sensacion de “¡que bueno!” hasta que hace una semana pille una flashcard y probe el SCUMMVM para DS. Jugar a “The Secret of Monkey Island” en la DS ha sido la mejor experiencia de juego que he tenido en mucho tiempo. Y eso, para alguien que esta en el sector del desarrollo, es un asunto del que preocuparse. Y mucho.
Metodologias
Hace unos dias tuve un almuerzo con Erik Musse, desarrollador independiente mas conocido en la parte oriental de europa que en la occidental. Lleva años en el sector, de una manera u otra. Suyas son muchas de las adaptaciones y conversiones de maquinas recreativas y de videojuegos de bolera de los primeros y timidos pasos de la industria en el antiguo bloque oriental del pacto de Varsovia. Despues de varios años trabajando en la distribuidora KeyCo, decidio dedicarse otra vez al desarrollo, esta vez en el sector de los moviles.
Ademas de mil y una anecdotas jugosas, estuvimos comparando las metodologias de trabajo y, como ya mencione en el anterior post, escribo al respecto.
En primer lugar, Erik es un programador experimentado y un desarrollador prolifico. Tiene una docena de libretas llenas de apuntes para ideas sobre juegos y tira de ese catalogo. El proceso completo que abarca desde el desarrollo del documento de diseño hasta la presentacion del producto acabado a la distribuidora le lleva 21 dias. Suele emplear dos dias para el guion, el documento de diseño y al menos tres versiones del proyecto por si tiene que realizar cambios sobre la marcha. En programacion unas dos semanas y el resto del tiempo lo emplea en testear el producto y la compatibilidad de terminales. Normalmente Erik desarrolla en Java aunque alguna vez ha tenido que trabajar para Symbian y ahi, me comenta, el tiempo de desarrollo se puede alargar sine die.
Hay que mencionar tres aspectos fundamentales en la metodologia de Erik. En primer lugar, lleva años trabajando en generos que se distinguen por la inmediatez del tipo de juego, es decir, arcades, fps y todo clase de juegos que puedan meterse en una recreativa. Esta experiencia le hace estar especialmente preparado para un tipo de juego que funciona bien comercialmente sobre una plataforma tan limitada como los moviles. Y, sobre todo, el tener su baul de ideas apuntadas a lo largo de los años.
El segundo aspecto a mencionar es que Erik cree firmemente en la reutilizacion de codigo. Cuando desarrolla siempre documenta el codigo y cualquier codigo desarrollado especificamente para una funcion que antes no habia necesitado, es impreso aparte, documentado y ordenado en sus archivadores. De esta manera, afirma, en ocasiones puedo hacer un producto terminado y solo he programado una o dos horas. El resto es todo copiar y pegar de mis archivadores.
El tercer aspecto es que, a lo largo de los años ha reunido una vasta coleccion de graficos y matrices de graficos que, la mayoria de las veces, son desechados de un desarrollo por alguna razon. “Nunca borro nada, nunca se sabe cuando lo vas a necesitar”. Por tanto, el desarrollo del grafismo para sus juegos es una labor relativamente sencilla para el. “Normalmente, nunca parto de cero. A veces da la casualidad que una idea que desechaste para un producto le sirve perfectamente a otro proyecto nuevo. La mayoria de las veces, sin embargo, partes de un concepto de diseño. Lo que en un juego es una casa, con poca modificacion puede ser una nave espacial en otro”.
Estos tres aspectos posibilitan que Erik este produciendo, el solo, la friolera de quince juegos al año. Es mas, el año pasado lanzo veintitres juegos gracias a que recibio numerosos encargos del mismo tipo de juego.
Su metodologia, gracias a la experiencia, se ha vuelto rapida, eficaz y, sobre todo, simple. Un buen control teorico sobre el proceso de desarrollo y el añadido de documentar cada paso le proporcionan una ventaja adicional de mercado: cada desarrollo que termina le coloca en una posicion mejor y mas rapida para el siguiente desarrollo.
Comparando esto con la metodologia de nuestra empresa, es evidente que Erik nos gana por goleada a escala relativa. Plantee esta cuestion a mis compañeros despues de la reunion con Erik y, tras un sesudo analisis tenemos un resultado.
Es imposible, para nosotros, mejorar nuestra metodologia actual. No es, por supuesto, mejor o peor que otras. Para nuestro tamaño funciona muy bien. Y es que, lo mas importante a tener en cuenta, es que al crecer el numero de personas relacionadas en un desarrollo tambien aumenta la complejidad del mismo.
En definitiva, a la hora de la verdad, es mas importante la gestion eficaz del grupo de trabajo que el producto de dicho grupo.
Avalancha
Pues nada, aqui estoy nuevamente. Llevo demasiado tiempo en silencio pero ha sido por la sobrecarga de trabajo que tenemos.
Hemos estado a tope para la campaña de verano y, una vez terminada, hemos estado al cien por cien esperando las reviews, la acogida de los productos y ofreciendo soporte. Por fortuna, apenas han habido incidencias.
Ahora viene un periodo de relativa paz hasta octubre, cuando ya se sienta que la campaña de navidad se nos echa encima y volvamos a estar con jornadas de mas de diez horas.
Hay bastantes cosas positivas. En primer lugar, la decision del gobierno aleman de incluir al GAME, el colectivo profesional de videojuegos, en el consejo cultural. Es un gran avance aunque tambien implica ciertos cambios en el sector. Esperemos que para mejor.
En segundo lugar, ha sido una experiencia unica todo este lote de trabajo. He llegado a estar involucrado en mas de veinte proyectos al mismo tiempo y se aprende mucho trabajando bajo presion.
En tercer lugar, tener la oportunidad de seguir todo el ciclo de vida del proyecto desde la creacion misma de la idea original es increible.
Como en general me ha parecido muy interesante los metodos de trabajo que tenemos en esta empresa, voy a escribir un par de posts al respecto.
Sin embargo, tambien hay algo negativo. El hecho mismo de desarrollar juegos para telefonos moviles es algo absolutamente decepcionante.
Cuando terminamos el proyecto “Run Devil Run”, un FPS de la segunda guerra mundial, para PC, quedamos muy satisfechos. Era un FPS pero mas arcade que otra cosa y resultaba bastante entrenido. Lo mejor, era muy agil y rapido de jugar y sus requisitos de equipo no eran muy elevados. Unas semanas despues, otro equipo de la empresa empezaba la tarea de “reciclado” de graficos y codigo para hacer la version PSP (que, por cierto, ya salio a la venta en Asia y ha tenido buena acogida).
Evidentemente, al no empezar desde cero, la cosa iba con bastante rapidez. Las conversiones pueden ser un infierno, pero si tienes todas las fuentes originales y trabajas y archivas de manera ordenada, la cosa puede ser muy llevadera. El caso es que me uni a los betatesters para echar un vistazo y la cosa prometia. He jugado a la version final y es una gozada, igual que en PC, mas arcade aun, y sacando partido de los mandos de la PSP. Prefiero jugar en PC, siempre lo he dicho, pero el juego esta bien adaptado para no preocuparse de la falta de raton.
Por ultimo acabo de ver la version para moviles. Al principio pense que era problema del terminal que estaba usando asi que me di una vuelta por el estudio probandolo en todos los terminales (diferentes marcas, symbian, no symbian, pantallas mas grandes) y el resultado es el mismo. A los betatesters les gusta pero claro, ellos no han jugado a la version PC o a la version PSP.
En definitiva, por mucho que nos vendan la moto, a la industria de la telefonia movile le faltan años para que en los terminales se pueda jugar con comodidad (he dicho comodidad, no me vale el accesorio ese de sonyericsson). La intencion de aunar una consola con telefono parece lejos de conseguirse.
Al final tendrian mas suerte si incorporasen el modulo de telefonia a una DS o una PSP, visto lo visto. Hay juegos que por su genero y funcionamiento si encaja en un movil, y son divertidos de jugar. Pero la mayoria de las conversiones y adaptaciones fracasan. Es un hecho. Habra que estudiar a fondo el asunto.
Por cierto, ya habreis visto el anuncio, tendremos PSP 3000 en breve. Espero impaciente.
David vs. Goliat
El lunes varias empresas de desarrollo de juegos para plataformas moviles tuvimos que reunirnos con un gigante del sector de las consolas para ser informados de las nuevas reglas sobre las licencias.
La reunion fue amena y, rapidamente, poco mas de dos horas, nos explicaron todos los cambios. Eramos unos cincuenta alli reunidos de los cuales solo 4 eran de la empresa de consolas.
Como es habitual en este tipo de cosas, cuando termino la reunion hubo un “desayuno” informal. Es decir, a tomar cafe de pie y hablar con los demas. Asi me entere que, en realidad, alli solo habian tres empresas presentes.
Por nuestra parte fuimos cinco. Eso significaba que habian alli cuarenta y una personas de otras dos empresas de desarrollo. Me senti claramente intimidado.
La empresa en la que trabajo es pequeña y nos organizamos en pequeños grupos de trabajo para todo. Pregunte a mi jefe dias despues sobre el asunto y me explico algo fascinante.
Una de esas empresas presento en el primer trimestre de este año 17 lanzamientos (un numero escaso si se consideran sus dimensiones). Tienen un margen de beneficios sobre facturacion cercano al 11%.
Nuestra empresa, en el mismo periodo, presento 14 lanzamientos con un margen del 32%.
A veces, en el mundo real, David gana a Goliat. Por lo menos esta vez.
Cuestion de tamaño
Ahora que estoy ya plenamente incorporado a mi nuevo trabajo me permito un tiempo para escribir. Estoy, otra vez, en Alemania, incorporado a Global Worm, empresa en la que nos dedicamos, sobre todo, a portings de juegos para moviles asi que me encuentro inmerso, nuevamente, en el mundo del J2ME.
Dado que mi puesto actual es de responsable de diseño, tengo que visualizar todos los proyectos desde un punto de vista bastante global y ello supone estar presente en muchas partes del proceso de produccion.
Nada mas incorporarme, tuve que estar presente en el proceso final de produccion de un juego que la compañia tenia ya casi listo para lanzar y, como es logico, tuve que ponerme al dia rapidamente.
Conversando hace unos dias con Janus Weissman, mi homologo en Cirkus Produktiv ( hoy por hoy, la tercera empresa del sector de juegos “rapidos” y conversiones mas rentables del pais), hablamos de las diferentes metodologias que nos imponemos a la hora de trabajar con diferentes plataformas. Por descontado surgio el asunto del tamaño.
El usuario, que para eso es el consumidor final, solo ve el resultado de un desarrollo. La pregunta clave es: ¿podemos cuantificar el trabajo de un desarrollo por el tamaño de sus fuentes?
Espero que no se me interprete mal. Conozco empresas donde el proceso de documentacion es tan importante que para lanzar un proyecto de escasa envergadura se generan varios gigas de informacion. No es el caso. Weissman y yo hablabamos de la parte esencial, es decir: diseño basico, guion, diseño extendido, codificacion, programacion, grafismo y compilacion.
Asi que, animados por la incertidumbre (no encontramos ningun articulo hablando de este tema en particular en los sitios habituales, lease gamsutra y demas), iniciamos una especie de “medicion de penes” en cuanto al desarrollo de juegos.
Me quedo con el resultado mas impactante (al menos para mi). Global Worm desarrollo hace seis meses ( evidentemente yo no estaba ) un porting para moviles de Razor Blade, el antiquisimo juego de spectrum, dandole un aspecto muy a lo Prince of Persia. Al final de su desarrollo se habian generado 205 paginas utiles de informacion (es decir, eliminando indices, esquemas y paginas intencionalmente en blanco). Y todo para un juego que ocupo 649 Kb en Java.
Weissman, por su parte, aporto que el desarrollo de Final Blade (al fin y al cabo, un porting del mismo Razor Blade pero con distinto nombre por cuestiones de licencia) necesito, al final de su desarrollo para Nintendo DS, 731 paginas de informacion para un tamaño de 34Mb en formato NDS.
La conclusion, aunque de escaso valor cientifico, es que el tamaño no importa. La diferencia, por cuestiones evidentes, se deben mas a las diferencias de la aproximacion al diseño que al diseño en si.
Nada nuevo bajo el sol, por supuesto, pero por lo menos esta vez contamos con datos suficientes para la proxima vez que un jefe nos comente eso de que “hay poca documentacion” en el desarrollo.
Asi que ya, para la proxima vez, tenemos un argumento que no se si sera de peso, pero seguro nos dara algo de manga ancha para poder estirarnos un poco en los estrictos plazos que nos meten.
¡Esperemos que no haga falta tirar de estadisticas!
