Si recordáis mi entrada sobre "La Edad de Oro del Software Español", ésta acababa con una pequeña reflexión personal de cómo había perdido mi oportunidad (al ser demasiado joven entonces además de por falta de conocimientos globales) de crear juegos profesionales tanto para Spectrum como para los primeros PCs. Ahora que estoy muy cerca de tener los conocimientos necesarios (los tengo en algunas áreas, y tengo la base necesaria para otras), lo que no tengo es tiempo (obligaciones, casa, trabajo, hijos)...
Pues bien, buscando información sobre programación en Android / JAVA, me encuentro con un blog interesantísimo (Obviam.net) con geniales artículos sobre desarrollo de videojuegos para Android. Entre ellos, hay un artículo que intenta justificar el porqué del nacimiento del blog.
Este artículo me ha encantado, porque veo a esta persona con un pasado muy parecido a mi situación personal, y muestra que no soy el único que pasado por perder el tren pasado de hacer ciertas cosas en las que le hubiera gustado continuar.
El autor del artículo no renuncia a su sueño de crear juegos y además lo hace como escape a la vida "corporativa" de trabajo para multinacional desarrollando en Java y el mantenimiento de las obligaciones derivadas de esta vida "estándar" (casa, pareja, hijos). Y precisamente eso es lo que cuenta, que utiliza ese blog para automotivarse:
I’m talking about the 80s.
Many took the classes, went through all that necessary crap that comes with getting a degree one would not care about in the future and here they are. Some graduated and have decent paying “software engineer” positions working for a multinational corporation doing who knows what. But a percentage of these so called engineers dream of games. They own the latest gadgets but they do not have the one thing that would enable them to make games: Time.Working 9-5 sucks and many have families or other obligations but they still think of doing projects on the side. Unfortunately many never even get started.
How many thought: man…I’ll be building the greatest game of all, I’ll be rich and famous. Then they meet someone, have to get a job to pay for “settling” down and pay the bills for a place where they go in the evenings to crash just to start it over the next day. All this by doing boring web stuff or working on a small part of a monstrous multi-threaded distributed enterprise application architected by an inexperienced halfwit architect wannabe who got the job by sticking with the company since he was an intern.
Where is the game you dreamed of doing 10 years ago?
To be precise I am in a similar situation and while I had a short gig with a game company I am well in the rat race leading nowhere. I have decided to try one more time and I will give it a go. Why? Just for the hell of it, to demonstrate that games are simple to build and you can sit at your computer and have some fun too. Actually this is why I ended up a coder, to make games not to configure some frameworks (yes, that is not programming, it is mostly configuration).
There are several reasons I set myself up for this journey and I will document it.
And most importantly, don't let anything stop you. Finishing what you start no matter what obstacles you face or how exhausted you feel is the most important thing. It's not worth anything unless you finish.
Hubo hace unos años un hilo en el foro de Meristation que trataba de crear "escenas de videojuegos" con el Paint.
La idea era dibujar una imagen con primitivas gráficas (pincel, rellenado, texto...) y colores puros, en apenas 1 ó 2 minutos de trabajo, pero que captara la esencia del juego. Y qué mejor programa para reivindicar la "cutrez" que el Paint de Microsoft Windows ...
Ayer encontré haciendo limpieza de mi disco duro algunas de las imágenes que publiqué en ese hilo, así que he pensado que antes de que se pierdan, me gustaría compartirlas en el blog.
La Aventura Original (parte 2)
Alone In The Dark
Another World
The Secret of Monkey Island
R-Type
Day Of The Tentacle
No están hechas exáctamente con el Paint (ya sabéis a estas alturas que soy Linuxero) sino con el "krita" o el "xpaint" (no recuerdo exáctamente cuál usé), pero la cosa resulta bastante entretenida :P. Además no tienen ni 2 minutos de trabajo en cada imagen, por lo que cualquiera puede intentar aportar las suyas propias sin dedicar demasiado tiempo :)
¿Os animáis con alguna? Sólo hay que abrir un lienzo en blanco de 640x480, rellenarlo con un color de fondo plano y soltar 4 primitivas gráficas rellenas y algún texto.
Hoy quiero compartir con vosotros un videodocumental sobre la demoscene: “Demoscene: The Art of the Algorithms” (2012).
Para quien no sepa lo que son las demos e intros (no confundir las demostraciones de juegos comerciales con menos niveles que el juego completo), como veréis en el vídeo se trata de programas similares a videoclips (con efectos gráficos espectaculares, música, y algunos de ellos con cierto mensaje detrás) pero que no están “montados” sino programados. Ese modelo 3D rotando, ese fuego, ese agua tan realista, ese efecto de rotación, están programados realizando operaciones matemáticas sobre los puntos y las texturas, en tiempo real.
Antes de ver el documental, creo que debéis poneros en disposición de ver una maravilla como Second Reality, de Future Crew. Pensad por favor que el vídeo que podéis ver a continuación se corresponde con una demo que se ejecuta en 1993 en PCs 386 y 486 a 25 y 33Mhz y que todo está renderizado en tiempo real:
Second Reality, de Future Crew (1993)
Impresionante, tanto la música (no digitalizada, sino compuesta en un tracker musical), como el montaje, como el impresionante nivel de programación que había detrás de esos efectos para que se ejecutaran fluídos en tiempo real en un simple 486 a 33 Mhz. Y PROGRAMADA EN ENSAMBLADOR.
Os dejo el documental:
Este videodocumental se centra en lo que es la demoscene húngara, y “entrevista” a programadores, músicos y grafistas de intros (de 4KB y 64KB) y demos. El documental es bastante curioso porque se vé una cultura de gente brillante a muchos niveles y que se dedican al tema de la demoscene por simple hobby.
Reconozco que he echado de menos ver a grupos no Húngaros, como por ejemplo Future Crew. Es más, hasta creo que el documental debería haber incluído demos como “Second Reality” para disfrutarla desde su principio a su fin.
Lo que más me ha sorprendido del documental es que existan las “demotools”. En la época de las demos que viví yo (Intel 286-386-486), todo se hacía “a mano”. Las demos se programaban desde cero, un efecto detrás de otro. En este vídeo podemos ver cómo algunos demosceners, cansados de programarlo todo desde cero, se crean herramientas para componer las demos como si fuera un editor de vídeo no lineal, generando esta herramienta después el código (ver el documental a partir del minuto 55m:40s). Con esta herramienta, el programador “diseña” los modelos 3D, importa texturas, las “inserta”, les aplica efectos, y puede mover todos los efectos y modelos por el “timeline”, definiendo cómo será la demo, cuándo entra cada efecto y con qué parámetros, etc.
Aspecto de la demotool de Conspiracy
(captura del videodocumental)
Detalle del timeline
Esto, que podría parecer que choca contra el espíritu de “superación” de las demos (programar para superar a otras personas, otros retros o mejorar algo), se produce porque las máquinas modernas ya no tienen las limitaciones de las antiguas.
Antes (por ejemplo, en C64, Amiga o PCs antiguos sin GPU), teníamos unas limitaciones de hardware especificas que obligaban a que la “carrera” del demoscener fuera la de superar estas limitaciones. A optimizar para llegar más allá de lo que alguien pensara que se podía llegar. Cuando veías un efecto espectacular en un C64, un Amiga, o un PC antiguo, sabías que lo que estabas viendo era en tiempo real, creado desde cero, sin usar ningún tipo de aceleración ni bibliotecas de terceros, y sentías cómo explotaba la máquina más allá incluso de lo que mostraban los juegos comerciales.
En esa época la clave la marcaba la limitación del hardware, como he dicho, y la superación era técnica: exprimir la máquina un poco más de lo que se hacía hasta el momento, para dejar con la boca abierta a quien pensara que ese sistema no era capaz de eso.
Actualmente el hardware está a tal nivel que la “carrera” ya no es la técnica sino la de diseño. Las demos deben de ser bonitas, la música espectacular, los efectos ser “plásticos”...
Las únicas limitaciones que te puedes imponer para poner coto a los resultados son artificiales: por ejemplo, el tamaño. Intentar que la demo no supere 4KB ó 64KB implica forzar al programador a utilizar gráficos procedurales (nada de incluír imágenes), a generar el sonido él mismo (nada de incluír audio digitalizado), etc. También a devanarse los sesos para hacer efectos con las texturas y los sistemas de partículas, las cámaras y las fuentes para que el resultado sea espectacular, largo, y de reducido tamaño de ejecutable. Aparte de estas limitaciones artificiales de tamaño, podemos forzarnos a programar sobre máquinas antiguas, que todavía tiene mucho tirón.
En cualquier caso, como he dicho, algunos demosceners, ya no teniendo “barrera técnica” que superar, se centran en la parte artística y plástica, el diseño y el “montaje”, y para eso las demotools ayudan, porque lo espectacular ya no es “programar los efectos” sino usarlos correctamente y no tiene sentido reprogramar el mismo efecto gráfico desde cero. Así que las demotools permiten abstraerse de la “pérdida de tiempo” de reprogramar algo que no supone un reto, que se presupone ya sabido, para centrarse en el montaje en sí.
Si recordáis la anterior entrega (la de la Edad de Oro del Videojuego Español), acabé hablando de la frustación que supuso entrar en un mundo concreto y ver que está ya todo realizado y que no puedes ponerte al nivel de lo que ya hay. Me pasó con el Spectrum y después con el PC. Incluso a día de hoy pasa con los juegos para móviles, ya que hace unos años podías desarrollar cualquier cosa para móvil pero hoy hay juegos HD que tienen detrás equipos más gandes que juegos de PC o de consola.
Pues en el mundo de las demos, al final del vídeo puede verse como sucede lo mismo. Después de 30 años de demos, ¿qué ocurre con aquellos que les pica el gusanillo y quieren meterse en esto?
Pues que no pueden competir a ningún nivel con lo que ya hay. Viendo demos de 1993 (Second Reality) que son ya casi insuperables, y demos de estos últimos años que tienen efectos dignos de Pixar, supongamos que entras tú y empiezas con tu pequeño cubo rotando. Necesitarás DECADAS para ponerte al nivel de lo que hay AHORA. Sólo si lo haces por diversión puedes dedicar el tiempo necesario y no sentir tal frustración inicial que abandones.
De nuevo, alguien (por más brillante que sea) que quiera entrar este mundillo, llega muchos años tarde. Quien podría haber sido la estrella hace 30 años, cuando un rotozoom o rotar modelos 3D en un C64 era impresionante, ahora se pierde entre el mar de genialidades pasadas.
Casi que me queda una conclusión que se merece un artículo aparte.
¿Debería existir un hueco para los relevos generacionales? ¿Deberían haber “categorías de demoscene” para novatos, y verse y valorarse dentro de lo que representan y no en un marco general? ¿Acaso se hace ya esto? ¿Deberían existir canales de distribución de juegos amateurs (aparte de las Store)?
Finalizo el artículo dejándoos algunos vídeos que no os podéis perder:
Música: "Elysium" de Jester/Sanity, reproducida en el Impulse Tracker
Intro (64KB!!!): "Heaven Seven" de Exceed. Repito: 64KB.
En apenas 3 días, en los ratos muertos (a veces a base de quitarme alguna hora de sueño) me he leído los 2 volúmenes de “Ocho Quilates”, la obra de Jaume Esteve sobre “La Edad de Oro” del software Español.
La edición física de "Ocho Quilates"
Si os gusta mi reflexión / resumen, os recomiendo comprar el libro y leer esta historia de una forma más detallada:
Yo, sin dudarlo, me hice tanto con la edición física como con la edición digital.
El libro relata la historia del software de Español desde sus inicios en 1984 hasta el ocaso de las grandes compañías en 1992. Por el camino, el autor nos presenta la historia de Dinamic, Made In Spain /Zigurat, Opera Soft, Topo Soft, etc. y lo hace en base a una labor de documentación sobre revistas de la época y con jugosas entrevistas con los autores materiales de las obras. Os recomiendo su lectura, la verdad es que es un libro bastante ameno y “concentra” (entre entrevistas y referencias a revistas de la época) mucha información que estaba dispersa. No voy a hacer un resumen del libro como tal pero sí que voy a hacer breves comentarios sobre las distintas etapas que pasó nuestra “industria“ de los 8 bits, y en algún caso reflexiones personales sobre ello, en la parte que me toca, la del “programador de videojuegos frustrado”. Como única pega al libro, diré que peca de lo mismo que pecaron las revistas originales y muchos círculos actuales retro, de exagerar un poco la calidad de algunos juegos que, realmente, no serían tan alabados si no fuera productos de casas españolas. Quiero decir que sin desmerecer a la Edad de Oro del Soft Español, muchos juegos de UK eran superiores en cuanto a calidad (especialmente las conversiones), siempre dejando de lado ciertos títulos españoles que estaban a un nivel casi insuperable; enseguida me viene a la mente "La Abadía del Crimen", "Sir Fred", "París Dakar", "Livingstone, Supongo", las aventuras míticas de AD como "La Aventura Original" o "Cozumel", etc. Pero bueno, se lo perdonamos porque, al fin y al cabo, existe ese pequeño plus patrio-nostálgico que por otra parte los ingleses también aplicaban sobre sus juegos y contra los juegos españoles.
Los inicios: jóvenes "de garaje"
Esta parte del libro narra cómo son los inicios de Dinamic o de Made In Spain, entre otros. En resumen: jóvenes en cuyas manos caen microordenadores como el ZX81, y que después descubren un universo de posibilidades con el ZX Spectrum. Jóvenes que compatibilizan sus estudios con la creación de juegos simplemente por hobby.
Los propios autores nos hablan de inversiones iniciales “mínimas” (al menos, abordables por unos estudiantes). De incontables horas de trabajo en su propia casa programando. De juegos sacados adelante por una única persona que realiza tanto código como gráficos como sonido, o bien a lo sumo equipos de 2 ó 3 amigos repartiéndose los roles de programador, grafista o músico. De tardes y noches programando juegos mientras durante el día se estudia. Vamos, chavales que empezaron, como en el caso de Apple, “en un garaje” (o en su habitación, o en una buhardilla en el caso de Dinamic).
(Equipo de Made In Spain - de las páginas del Vol. 1)
Todo el proceso de producción, aquí, es “artesanal”, desde la codificación (ya sea en BASIC o incluso ensamblando a mano, sin programas ensambladores) a los gráficos. También el soporte físico y la “publicidad”: folletos dibujados a mano, carátulas fotocopiadas y duplicación de cintas en casa con cassettes de doble pletina o con “copiones”. Y venta local, dejando copias del juego en alguna tienda cercana, o bien a nivel nacional por correo (sí, por carta).
Yength y Artist, las primeras creaciones de DINAMIC
(por 1000 pts cada uno)
Es la época donde nada está hecho y todo es nuevo. Los chavales, programando juegos “por hobby”, sin esperar “nada a cambio”, empiezan a recibir dinero y reconocimiento por sus productos. Es el momento en el que se da un paso adelante y equipos como Dinamic (que no dejaban de ser 3 hermanos, Pablo, Víctor y Nacho Ruíz) empiezan a pensar en profesionalizar su trabajo. Y otros equipos les siguen en este movimiento.
Por otro lado, Paco Pastor, en ERBE, realiza distribución en España del software de UK, comprando el producto final y traduciendo sus instrucciones, vendiendo productos de calidad (acabado de UK). De nuevo hablamos de un proceso “artesanal”, que aunque tiene resultados profesionales, finaliza con un precio de producto superior a las 2000 pesetas, una enorme cantidad para la época.
En esta etapa, hay tímidos intentos de exportar nuestro software a otros países (fundamentalmente UK), con resultados muy variopintos: se obtienen pocas ventas, malas distribuciones, pocos royalties o directamente no reciben nada. Básicamente, el trabajo de los equipos españoles en general no estaba bien considerado y los juegos distribuídos siempre eran criticados por su elevada dificultad.
La profesionalización del hobby
Cuando hablo de “profesionalización”, no quiero que se confunda con “industrialización”. Me refiero a que el proceso de producción se profesionaliza, es decir, se mejora en general tanto la metodología y el ambiente de trabajo, como la calidad final de los productos.
Duplicación de cintas en empresas destinadas a ello, portadas y anuncios creados por ilustradores de prestigio, cajas formato estuche, canales de distribución como El Corte Inglés, cambio de la habitación o buhardilla por unas oficinas, publicidad en revistas, etc.
El aspecto de un bonito estuche de DINAMIC
(foto extraída de images.google.es)
Pese al gran parqué de Spectrum en España, apenas se vendían unas miles de copias de cada juego, a precios de aprox. 2000 a 2500 pesetas (unos 12 a 15 EUR) los juegos importados, y 1000 a 1200 pesetas (de 6 a 8 EUR) los nacionales, pero daba el suficiente rédito para que esos jóvenes pudieran vivir de lo que les gustaba: la creación de juegos.
Los juegos se creaban como obras artesanales y no estaban sujetos a plazos estrictos o campañas/fechas concretas, ni se buscaba un mercado específico u otro. Simplemente, seguían haciendo los juegos que tenían en su mente, a veces simplemente “homenajes” a las recreativas del momento. Pero lo importante es que los juegos se intentaban hacer lo mejor posible y se distribuían cuando estaban listos y no en base a un calendario o a acciones meramente comerciales.
En esta ocasión, por fin, las casas españolas comienzan a distribuir en UK primero con compañías pequeñas y luego con algunas de las grandes, y comienzan a recibir dinero de verdad con las ventas fuera de España (algunas compañías con más fortuna que otras).
En esta profesionalización nos encontramos con que las casas de software se centran en el desarrollo y salvo alguna excepción, pasan a confiar en ERBE para la distribución. ERBE hace duplicaciones profesionales de cintas en una discográfica, y tiene contactos con grandes canales de distribución y revistas, por lo que los estudios pueden dejar de invertir su tiempo en duplicación de cintas, de carátulas, de instrucciones, distribución, etc.
La piratería y la bajada de precios
Centrados en el mercado Español, los desarrolladores comienzan a preguntarse cómo es posible que en UK se vendan decenas de miles de copias de los juegos y en España apenas se vendan unidades (1000, 2000 copias algunos juegos).
No podía ser por escaso parqué de hardware porque el Spectrum arrasaba en España. Además, se vendían 100.000 revistas Microhobby semanales, signo de que había una enorme base de usuarios.
Paco Pastor (de ERBE), cuyo sector es la distribución, estudia el caso y llega a la conclusión de que sólo el 2% de los juegos en casa de los usuarios son copias legales, siendo el resto copias piratas que podías comprar por correo o en los mismos rastros. Incluso las tiendas hacían pedidos de juegos originales y los usaban para vender copias.
Las copias, que las había desde 350 pesetas (poco más de 2 EUR de los de ahora), costaban mucho menos que los originales (que podían llegar a 2500 pesetas, unos 15 EUR).
Pastor se pone en contacto con los mayores grupos de desarrollo (a los que distribuye) y les convence para dar un golpe de efecto: bajada de precio de los juegos hasta las 875 pesetas (unos 5 EUR), que es, según un estudio de mercado realizado con los propios usuarios, la cantidad para la cual el usuario compraría un original en vez de una copia.
"Ser original cuesta muy poco" - El slogan de ERBE para convencer
a los jugadores de comprar originales con el nuevo precio rebajado.
Esta bajada de precio resulta un éxito, comenzando por fin a venderse cantidades de cintas lógicas (10.000, 40.000 e incluso juegos de DINAMIC llegaron a las 100.000 copias), pero tiene varias pegas.
Por un lado, queda menos margen en cada venta por lo que es necesario vender 3 veces más que antes para ganar lo mismo. Este mismo “menor margen” no deja lugar al error en el desarrollo: si un juego no es un éxito, es difícil recuperar la inversión. Esto produce mella en algunas casas de software, que no distribuyen con ERBE pero se ven obligadas a bajar el precio para poder competir, y no les queda margen de fallo: o el juego triunfa, o se hunden.
Por otro lado, se comienza a generar un producto de peor acabado, las típicas cintas de ERBE de cajetín simple. Adiós a las cajas de cartón o estuches, a las cajas dobles, o a los libros de instrucciones. Salvo recopilatorios y algún otro trabajo de DINAMIC, los juegos aparecen en cajas con menos personalidad que las anteriores distribuciones.
El aspecto de las cajas "clónicas" (lomo rosa) de ERBE
(foto extraída de images.google.es)
Para mí este cambio es similar al que sufrieron las preciosas cajas de cartón de los juegos para convertirse a las cajas de CD/DVD totalmente impersonales que se venden ahora.
La industrialización : de afición a negocio
Ahora sí que llega el momento en se produce la industrialización del hobby, a cuando la afición se convierte en negocio.
La bajada de precios no sólo acarreará la pérdida de las bonitas ediciones en caja a cambio de cassettes todos iguales con el lomo rosa o blanco... como ya dicho, también trae detrás de sí la necesidad de vender muchas unidades para que los desarrollos salgan rentables.
Eso implica un número mínimo de lanzamientos anuales para ser rentables, con plazos estrictos de lanzamiento. Ponerle plazos a un proyecto de software basado en la creatividad, en este caso, sirvió para que muchos dejaran de disfrutar de su trabajo, tuvieran una gran presión y se lanzaran juegos con menos calidad de la deseada. Ojo, no digo que no salieran productos de enorme calidad, sino que había mucho más producto de relleno.
Programadores como Paco Menéndez, autor de La Abadía del Crimen, dejaron la industria del videojuego en este punto ya que, como decía el propio Menéndez en Microhobby, "Antes programar era un arte, ahora es todo Marketing."
Paco Menendez (La Abadía del Crimen)
Se editaban recopilatorios con “fondo de armario” (productos que ya no tenían vida comercial) y se hacía uso de las licencias (famosos) para promocionar los juegos, siendo a veces esto más importante que la calidad del propio juego.
Lo que eran grupos de amigos, se convirtieron en organizaciones empresariales con jefes que no eran informáticos sino “coordinadores” (como el caso de Topo y Gabriel Nieto). El videojuego era ahora negocio y había que rentabilizarlo: segundas partes, juegos de licencias y plazos estrictos, así como la obligación de hacer el mayor número de versiones posible (Spectrum, Amstrad, MSX, C64, PCW, PC...). Para realizar estas versiones, las empresas más grandes compran hardware especializado de desarrollo que permiten programar sobre un PC y portarlo a diferentes hardwares. Esto queda fuera del alcance de empresas más pequeñas y la brecha se hace más grande entre ellas.
En resumen: muchos más juegos, pero ya no de producción artesanal sino industrial. Todavía se puede ver el mimo de los creadores, porque siguen siendo sus productos, pero ya no hay la misma sensación de que se está en algo más grande que uno mismo, como al principio.
Los que realmente aquí hacen de dinero de verdad, son los distribuidores como ERBE, que además se hace con el monopolio absoluto de la distribución en España.
La caída
Y aquí, a partir de 1990 en adelante (y en algunas compañías, ya desde 1989), es cuando empieza el fin de la Edad de Oro del Software Español.
En Europa hace ya meses (si no más) que las ventas de software de 8 bits han caído y que triunfan las máquinas de 16 bits como Atari ST y Commodore Amiga. Así, UK deja de convertirse en un importador de nuestro software, porque allí ya no vende, y a las desarrolladores españolas sólo le queda nuestro mercado, que tiene precios bajos y está saturado.
La empresa de software española se encuentra entonces con la duda de que si desarrolla para 8 bits, no puede exportar a UK y sólo tiene el mercado español, pero si se pasa a los 16 bits, entonces no vendería nada en España y dependería de la exportación. No sólo había apenas Amiga y Atari ST en España (por su precio) sino que además el coste de producir para esas máquinas era muy elevado y el resultado (el diskette) muy fácilmente pirateable.
Algunas compañías se ciñeron a los 8 bits asumiendo que no podía entrar en los 16 bits (inversión impensable) y otras, como Topo, se lanzaron (Viaje al Centro de la Tierra), “quemando” enormes cantidades de dinero en el desarrollo. Ya no podía hacer un juego un único desarrollador o un pequeño equipo y en un corto espacio de tiempo. Así que las versiones que se hacían para 16 bits eran conversiones casi directas de los títulos de 8 bits, que no aprovechaban las capacidades de las nuevas máquinas y por tanto no podían competir con las empresas que sí las explotaban, por lo que la inversión en su desarrollo no se podía rentabilizar.
Los pequeños equipos españoles ya no podían crear los juegos que compitieran con lo que llegaba, que eran verdaderas superproducciones con decenas de personas en plantilla, localización a múltiples idiomas.
Voy a poner el ejemplo de Aventuras AD, sección de DINAMIC dedicada a crear aventuras conversacionales con varios empleados a cargo de Andrés Samudio. Tenían que sacar una decena de aventuras al año para ser rentables, y apenas sacaban un par, y en pleno proceso de creación, aparece LucasArts con sus aventuras gráficas, creadas por decenas de personas, con animaciones, diálogos, música, bellos gráficos a color y en formato point-n-click. Imposible competir con eso. España estaba anclada en el pasado, el resto de la industria europea y norteamericana habían superado los 8 bits hacía mucho y nosotros no sólo no lo habíamos hecho si no que estábamos en disposición de hacerlo.
"La aventura Original (Spectrum)" VS "Indiana Jones (PC)"
Y aquí comenzó el fin de muchos estudios, manteniéndose algunos todavía gracias a que el mercado español no pasaba aún de los 8 bits, cosa que duró poco, hasta que Megadrive, Gameboy y SuperNintendo, así como el PC, barrieron cualquier atisbo de negocio con los 8 bits.
Cabe pensar que podría haber sido incluso peor si en este impás los estudios españoles hubieran hecho la inversión de meterse en los 16 bits. No hay más que ver el caso de Topo y Viaje al Centro de la Tierra. Pero imaginamos que todos los demás estudios lo hacen e invierten en desarrollo de Atari ST y Amiga: en apenas unos meses/años, las consolas NES, SNES, Master System y Megadrive enterrarían a los ordenadores de 16 bits.
He intentado resumir el libro en la medida de lo posible, pero los 2 volúmenes son bastante densos y probablemente preferiréis su lectura completa para no perder ni un sólo detalle.
A continuación viene mi reflexión personal sobre los cambios que ha habido en el ciclo de desarrollo y cómo se ha perdido el sueño del "desarrollador de garaje".
Frustración (reflexión personal)
Conforme leía el segundo volumen iba sintiendo (igual que supongo en su momento sus protagonistas) frustración. Por un lado por lo que pudo ser y no fue, y por otro frustración que ya viví en su momento como desarrollador, y por duplicado.
Yo llegué bastante tarde a la época del Spectrum (con un +2A, la última etapa del Spectrum cuando era la marca era ya propiedad de Amstrad) y en muy poco tiempo aprendí a programar sacándole partido a la Microhobby y a la tabla de nmemónicos en ensamblador del manual del +2A pero ya llegaba tarde a desarrollar nada para Spectrum. El mercado estaba saturado, no quedaba nada por “inventar” y la época de los “desarrolladores de garaje” ya había pasado, pero aún así podías soñar con desarrollar algo y que se viera publicado. No obstante, muy pronto llegó la muerte comercial del Spectrum y me ví abocado a continuar el desarrollo en PC.
Cuando hablo de PC hablo de la época de 286, 386 y 486, donde se repiten un poco las premisas iniciales de la edad de oro: tenías ante tí todo el universo de creación por delante, con una máquina con mucho mejores recursos que un Spectrum y una sóla persona o un equipo muy pequeño podía prácticamente desarrollar cualquier cosa. Esto era así porque la programación estaba casi acotada a MCGA (320x200x256 colores) y esa limitación (para los grandes equipos gráficos) te permitía poder ponerte a su altura aunque no contaras con recursos, de igual forma que 3 chavales en su buhardilla pudieron crear juegos de Spectrum de calidad comercial.
Desarrollé todo tipo de bibliotecas de programación para modo 13h (fuentes, scroll, tilemaps, editores de mapeados, sprites, animación, etc) y mientras estaba en ello, y madurando pequeños juegos y demos (para aprender a programar efectos gráficos), llegó el boom del multimedia, el momento en que se abandonaron los diskettes y llegó el CD. Y se abandonó el 486 y llegó la escalada de los Pentium. Y se abandonó 320x200 y llegó SVGA (VESA). Vamos, que desapareció ese momento en que tú, en tu casa, podías hacer un producto del mismo nivel que los comerciales que existían, y llegó ese momento en que un producto comercial venía en CD, estaba en varios idiomas, tenía voces digitalizadas, banda sonora orquestada, gráficos diseñados por decenas de profesionales, animadores, equipos completos de programadores... llegó el momento en que tu juego ya no podía ni siquiera mostrarse al lado de esos monstruos que iban apareciendo.
Hoy en día, gracias a Internet, tenemos la suerte de que podemos volver a aportar algo a este mundillo: vía web (HTML5/JS), en móviles (iOS, Android), en consolas (XBLA, WiiWare) o en PC, pero sigue siendo una competición muy complicada donde, ahora sí, casi está ya todo inventado.
No obstante, no pierdo la esperanza de que algún día podré quitarme la espinita de sacar algo (para Spectrum o para cualquier otro sistema) aunque sea por puro hobby o entretenimiento. Sólo falta conseguir el tiempo para hacerlo. El tiempo, el eterno problema... cuando teníamos tiempo no teníamos ni dinero ni conocimientos, y ahora que tenemos dinero y conocimientos no tenemos tiempo... pero esto da para otro artículo / reflexión en sí mismo :-)
Se dice que el primer paso para solucionar algo es aceptar que lo padeces.
Pues bien, ahora mismo hay una epidemia que padecen muchos integrantes de la sociedad (y especialmente de la sociedad de la información), y reconozco que no me había planteado que tuviera nombre o que existieran formas de combatirla.
Estoy hablando de la procrastinación (procrastination en inglés).
¿QUE ES LA PROCRASTINACION?
Procrastinación es el acto de aplazar tareas que tienes que hacer y reemplazarlas por tareas más sencillas o más apetecibles en ese momento.
Este problema afecta tanto a las personas que no tienen ningún tipo de planificación como a las que se organizan con agendas, listas de tareas, blocks de notas...
Simplemente, cuando llega el momento de enfrentarse a la tarea que debemos hacer (escribir un informe, colgar un cuadro, fregar los platos, ir al gimnasio, hacer dieta, organizar los papeles de la casa...), nos ocurre que la sentimos titánica, enorme, extenuante, tediosa, poco motivadora, o imposible de realizar. Realmente nos damos cuenta de que no nos apatece siquiera empezarla y además parece tan larga que no nos va a dar tiempo a finalizarla.
No importa que la tarea nos llegue porque nos hayamos acordado o percatado de que tenemos que hacerla, o porque venga de un detallado planning en una aplicación de tareas (es decir, que no importa que seamos organizados o no). El asunto es tenemos que realizar esa tarea, y no nos apetece.
Y entonces decidimos retrasar esa tarea para que la realice un "Yo Futuro" (por ejemplo, nuestro yo del mañana, o el yo de la semana que viene), porque pensamos que ese yo estará en una situación mucho mejor para tratarla. Pero la realidad es que nuestro "Yo Futuro", cuando se convierta en "Yo Presente", volverá a sufrir la misma sensación de imposibilidad de ejecución de la tarea y la tentación de postergarla.
Así que en lugar de realizar la tarea que debemos hacer, acabamos realizando tareas más sencillas que queremos hacer: revisamos nuestro correo, vemos una película, echamos una siesta, realizamos otras cosas intranscendentes o más sencillas, damos un vistazo a las redes sociales, etc. A veces incluso realizamos otras tareas menores que teníamos planificadas para realizar (tareas reales pendientes), pero no la que estamos considerando, la que debemos hacer.
El resultado es que las tareas realmente importantes son postergadas una y otra vez. Es el motivo por el que nunca aprendemos a hablar ese segundo lenguaje, a tocar ese instrumento, acabamos no yendo al gimnasio, ni siquiera empezamos la dieta, o retrasamos ese informe y finalmente tenemos que hacerlo en el último minuto.
La procrastinación es muy grave. Es un problema real, que puede producir insatisfacción personal al no conseguir metas que realmente te has planteado alguna vez en tu vida.
Es también grave en el mundo laboral, donde cualquier distracción (correo, tareas menores, etc) aplaza una y otra vez acciones o proyectos complejos pero que normalmente son los más importantes.
Cuando hablo de aplazar tareas no estoy diciendo que no hagamos nada a lo largo del día. No. La procrastinación se da especialmente cuando tienes muchas tareas, y tienes que cambiar entre ellas. Me considero una persona con mucha productividad laboral, que intenta abarcar muchas áreas de aplicación y mucho trabajo de forma simultánea, y este es precisamente el problema, que tengo muchas tareas donde elegir y muchos problemas que atacar. Esto no le sucede en la misma medida a personas más especializadas o personas con trabajos "físicos" (como el fontanero que viene a tu casa a cambiar una tubería, y que no tiene más opciones o elecciones que hacer ese cambio).
Así pues, soy una persona muy activa laboralmente, productiva y trabajadora, y sin embargo "procrastino", tanto personal como laboralmente. Tengo pendiente mejorar mi inglés. Tengo pendiente salir más a hacer deporte, como hacía antes. Tengo pediente terminar unos programas que tenía en desarrollo. Tengo pendientes muchos libros interesantes por leer. Tengo pendientes muchas cosas...
El problema de la procrastinación se basa en que nuestro cerebro nos engaña, y lo hace de diferentes formas:
ENGAÑO 1.- PLANIFICACION OPTIMISTA
A la hora de decidir que queremos abarcar un nuevo proyecto o tarea, y de añadirla a nuestro "calendario" o "nuestra lista de tareas", nuestro cerebro planifica la tarea de forma optimista, es decir: es incapaz de planificar los problemas que surgirán, las partes de la misma que son complejas, su duración real. En lugar de hacer una planificación real, estima que es una tarea muy sencilla y que nos va a dar mucha recompensa ejecutarla.
Por ejemplo, supongamos que tenemos un cuadro por colgar. Bien, lo haremos hoy mismo, total, sólo hay que hacer un agujero y colgar el cuadro, son apenas 2 minutos y quedará muy bien en nuestra parted.
ENGAÑO 2.- PRE-EJECUCION PESIMISTA
Cuando llega el momento de enfrentarse a la tarea o mientras lo estamos haciendo, nuestro cerebro hace todo lo contrario, la afronta de forma realista o incluso pesimista: detecta las partes problemáticas de la tarea y nos hace ver que ni era tan sencillo como pensábamos, ni vamos a tardar tan poco. Y además, deja de percibir la recompensa que sí que anticipamos cuando planificamos por primera vez la tarea.
En ese momento, nuestro cerebro libra una guerra interna entre el DEBO y el QUIERO. La procrastinación se produce cuando elegimos el QUIERO sobre el DEBO.
En nuestro ejemplo anterior, cuando cogemos el cuadro en la mano nos damos cuenta de que para colgarlo, tenemos que coger el metro y medir tanto el cuadro como la pared, y calcular la posición y altura a la que lo queremos. Además hay que ir a por el taladro y las brocas. Y un alargador, porque no hay un enchufe cerca. Vaya, esto ya no son 2 minutos, me va a costar más tiempo del que pensaba, y no sé si tengo ese tiempo. Ahora mismo es que además, tampoco me apetece. Creo que lo colgaré este sábado que viene, que tengo más tiempo libre; en cambio, me echaré un rato en el sofá y veo mi correo nuevo.
DEBO colgar el cuadro, pero no QUIERO ahora mismo. Además, DEBO, me suena internamente a obligación, lo que hace que la tarea que me iba a proporcionar una recompensa (un bonito cuadro en la pared) se convierta en una obligación que se me impone.
Pero no pasa nada, porque nuestro Yo Futuro del sábado que viene lo colgará, y entonces seré feliz.
ENGAÑO 3.- CONFIANZA EN EL YO FUTURO (FUTURO ERRONEO)
Nuestro cerebro nos engaña entonces haciéndonos pensar que nuestro "Yo Futuro" sí que va a estar en disposición de afrontar esa tarea, y además lo hará encantado, con tiempo de sobra y con éxito en la misma.
Volvemos a caer en la PLANIFICACION OPTIMISTA, y para la misma tarea, olvidando la PRE-EJECUCION PESIMISTA que nos acaba de hacer postergarla.
Pero cuando nuestro "Yo Futuro" se vuelve a convertir en "Yo Presente", nos encontramos de nuevo en la misma situación inicial. Nos encontramos en la realidad. Una tarea que nuestro cerebro nos dice que será tediosa y larga, y que no nos apetece realizar. Entonces, volvemos a postegarla a cambio de una tarea menor (ver la TV, leer el correo, ver redes sociales) y que hace que pasado un tiempo sintamos internamente "vergüenza" y "fracaso".
La tarea no se realizará nunca, o en el mejor de los casos, se demorará.
El sábado que viene, no colgaremos el cuadro. Mañana, no iremos al gimnasio. El lunes, no empezaremos la dieta. Este año, no aprenderemos ese segundo idioma. No nos sacaremos esa certificación. No haremos el informe hoy (en el mejor de los casos, y por obligación, a última hora).
Nuestra sensación será entonces que no acabamos nada. A nivel personal, que la vida pasa y no estamos finalizando nuestras metas, nuestros hitos y nuestros sueños. A nivel laboral, que los proyectos se enquistan y que se nos acumula el trabajo que realmente es importante a cambio de trabajo "menor" que sí hemos abordado porque era más fácil de realizar.
Este engaño se basa en que la percepción que tenemos ahora de cómo será el futuro es errónea.
No hay más que darse cuenta de que nuestra mente hizo una planificación ideal de la resolución del problema a la hora de "aceptar la tarea" basándose en un futuro irreal donde no se presenta ningún problema ni dificultad para realizarla. Se basa en que nuestro "Yo Idealizado" resolverá la tarea sin problemas en nuestro "Futuro Idealizado". Sin embargo, cuando ese "Futuro Idealizado" se convierta en "Presente", la realidad será la misma que cuando hemos retrasado la tarea.
¿TIENE SOLUCION?
La procrastinación no tiene solución total, porque está arraigada en la mente humana. Pero podemos aprender a vivir con ella y reducirla a la mínima expresión.
Como dicen algunos análisis al respecto, no es que seamos malos gestores del tiempo, sino que nuestro cerebro nos engaña, que perdemos la batalla mental entre el debo y el quiero.
Y saber qué es la procrastinación y cómo se manifiesta (es decir, lo que hemos hablado hasta ahora) es la forma de detectarla y de no caer en sus trampas. Esto nos permite tomar medidas contra ella.
Aunque lo que voy a decir a continuación pueda parecer evidente, darnos cuenta de por qué se produce este proceso es un enorme paso: sabemos que tenemos ese problema y sabemos que en realidad no es real (es un engaño de la mente) y por lo tanto tenemos la llave de la realización personal, simplemente atacando a las causas:
Estimación realista: A la hora de plantearse realizar una tarea, detenerse a realizar mentalmente una estimación correcta de su dificultad y su duración. Es decir, no dejar que nuestro cerebro nos engañe con planificaciones optimistas. Ser realista y plantearse si somos capaces de llevar a cabo esa tarea y en cuánto tiempo podemos hacerlo.
Planificación y diseño: Para abordar una tarea, separarla en subtareas individuales y atómicas y atacar una detrás de otra, de forma que podamos considerar la satisfacción de ir acabando cosas y además tener claro qué falta por hacer (% de cumplimiento). Esto tiene la ventaja de que tenemos la tarea totalmente identificada y que no pueden surgir "sorpresas" que nos tienten a abandonarla. Si la procrastinación nos vence en algún momento en una subtarea, por lo menos cuando volvamos a ella sabremos por dónde íbamos y qué queda pendiente.
Visualizar la recompensa: Apuntar junto a la tarea cuál es la recompensa que obtenemos por realizarla, para que cuando vayamos a procesarla tengamos claro cuál era nuestra motivación cuando nos la propusimos.
Visualizar el fracaso: Pensar en cómo nos sentiremos si postergamos la tarea y nuestro Yo del Futuro la vuelve a postergar. Es decir, ponernos en la situación de que la tarea nunca va a ser ejecutada, y darnos cuenta de la sensación de irrealización personal y laboral que supone eso.
Quiero vs Debo: Convertir mentalmente el DEBO en QUIERO. DEBO implica "obligación" y QUIERO implica "interés personal". No "DEBO" aprender Inglés. QUIERO aprender Inglés.
Ejecutar sin evaluar: Cuando seleccionemos una tarea para empezarla, no dar tiempo a nuestro cerebro a que comience a mostrarnos la visión pesimista de la ejecución. Nada más "leamos" la tarea, lanzarse a ejecutarla (por ej. la primera subtarea de la misma) sin pararse a evaluarla. Una vez hemos comenzado a ejecutarla, nuestro cerebro queda ocupado por la tarea y desaparece el efecto pesimista.
Visión real del futuro: Cuando nos tiente la posibilidad de abandonar algo, plantearse que nuestro "Yo Futuro" se encontrará en la misma situación y que probablemente volverá a postergarla, con lo que nunca la realizaremos. Plantearse de nuevo la satisfacción de hacerla, y pensar en qué nos va a reportar realmente dejar esa tarea y qué nos reporta realmente la tarea sencilla con la que pretendemos sustituirla.
Tal y como he abierto este artículo, la solución a un problema implica aceptar que se padece el problema. Y aceptar que somos procrastinadores por naturaleza es el primer paso para solucionarlo.
En cuanto te das cuenta de que realmente nuestra mente nos "pinta" futuros ideales para realizar las tareas y "pasajes desoladores" cuando las vas a abordar, estás en disposición de no caer de nuevo en la tentación. Si a esta detección de las trampas del cerebro sumamos tareas correctamente planificadas y estructuradas (subdivididas) y una visión clara de la recompensa de su finalización y el perjuicio que nos supone el no realizarla, estamos ante la forma de acercarnos a nuestra realización personal y laboral.
Finalmente, hay una teoría interesante sobre realización personal y procrastinación que invita a embarcarse en proyectos paralelos para evitar la procrastinación "en casa". Para sacar provecho de nuestro tiempo, vamos, sin perderlo "procrastinando". El artículo en cuestión es "Deja ya de procrastinar e inicia proyectos paralelos".
Os dejo un vídeo sobre procrastinación (en inglés). El vídeo es un trailer del libro "You are not so smart" (No eres tan inteligente), que trata este problema entre otras cosas relacionadas con la psicología humana:
Recordad que el refranero español, que es tan sabio, ya nos hablaba cuando éramos pequeños, e incluso a nuestros padres, sobre procrastinación:
Me ronda por la cabeza una pregunta sobre la programación de juegos 2D en entornos modernos con un problema que no se sufre en los juegos 3D (ni en el Spectrum, claro). Se me dió hace uno o dos años cuando me planteé la posibilidad de acabar mi PCMaziacs y hacerlo multiplataforma e incluso de hacer algún otro remake de juego de Spectrum. La he planteado en los foros de Speccy.org, por curiosidad (sección de desarrollo) en la siguiente URL:
Hago la versión resumida de la pregunta, y luego la exposición. Ojo, es posible que la pregunta no tenga una respuesta directa o fácil. Yo tengo mi propia idea de cómo atacar el problema, pero lo que quiero saber no es cómo se puede hacer sino cómo se debe hacer o cómo se hace normalmente a día de hoy.
--- Pregunta versión resumida: ---
¿Cómo se tiene que diseñar o programar un juego 2D en cuanto a los gráficos y el GUI para que pueda funcionar en diferentes resoluciones y aspects ratios, es decir, poder llegar tanto a PC, como a iOS, Android, etc? Me estoy refiriendo a soportar:
Diferentes resoluciones (sin perder calidad gráfica).
Diferentes aspects-ratios (4:3, 16:9, 16:10...) (e incluso orientación vertical/horizontal!)
Y me refiero a soportarlo en estos aspectos:
Gráficos de fondos y personajes (calidad de los mismos, ¿varios sets?, ¿gráficos vectoriales? ¿2.5D?, ¿renderizar escena+zoom?).
Elementos del GUI (fuentes, menúes, inventarios, puntuación) : posicionamiento en pantalla, etc.
Velocidades y posiciones de los personajes proporcionales a la resolución .
La duda puede ser tan simple como elegir en qué resolución hacer un remake, y que el usuario no lo vea en una ventanita de tamaño ridículo o en un fullscreen de píxeles del tamaño de un puño porque la resolución nativa del monitor es FullHD. De elegir entre varias resoluciones, o de cuál elegir. --Fin pregunta resumida--------------------------------
Ahora viene el contexto histórico y el torrente de dudas e ideas.
Personalmente, siempre que he programado aplicaciones gráficas (demos, juegos, lo que sea) ha sido con una resolución fija.
En el Spectrum no tenías ninguna duda con la resolución: 256x192 y a trabajar. En el PC, en la época del 486 y Pentium MMX, lo habitual era tanto en MSDOS como en Windows elegir una resolución fija (320x200, 320x240, 640x480...) y lanzar el juego en fullscreen. Tampoco había muchas resoluciones a elegir: 320x200, 640x480, 800x600 y 1024x768 en 4:3 eran los "estándares".
La selección fija de resolución te permitía utilizar un único set de gráficos, y (erróneamente) mover todo el entorno de juego (personajes, etc) con "coordenadas de pantalla" en lugar de utilizar "coordenadas de mundo" y después transformarlas (ej: la bala se mueve 2 píxeles por segundo, la nave 3 píxeles por segundo, etc). Incluso se fijaba el número de cuadros por segundo y se asumía que no variaba.
Si querías soportar más de una resolución en un PC, como eran "conocidas" (desde 320x200 a 1024x768), podías optar por 2 sets gráficos a diferentes resoluciones y "hardcodear" (también error) en cierta manera todo (GUI, movimientos, etc) según si estabas en una resolución u otra.
Cuando entraron en juego hardwares más potentes, tenías la posibilidad de alcanzar más cuadros por segundo y los podías aprovechar bien especificando una tasa de FPS fija superior (normalmente la máxima del refresco 50-60Hz, y asumiendo que el juego no iría bien en sistemas más antiguos) o basando el movimiento de los personajes en el tiempo transcurrido desde el anterior fotograma, lo que adaptaba los frames a la velocidad de la máquina de forma "automática" (más fluído en hw potente, más "choppy" en hardware antiguo). Esto solucionaba el problema del "posicionamiento" y "movimiento", en cierta medida.
Los problemas aparecen por la parte de las resoluciones y los gráficos, cuando:
Entran en juego diferentes resoluciones.
El jugador puede tener monitor panorámico 16:9, 16:10, o un monitor 4:3.
Entran en juego tablets, móviles, etc, con resoluciones variadas o desconocidas a priori y con 2 posibles orientaciones.
Entra en juego permitir al usuario CAMBIAR de resolución (en ordenadores).
Los LCDs/TFTs tienen una resolución nativa y forzar una resolución en FULL SCREEN queda horroroso.
Concretamente:
Caso Monitor panoramico 16:9/16:10 vs 4:3:
Si eliges una única resolución "base" (por ej 800x600) y fuerzas ese modo de pantalla en fullscreen, puede darse el caso de que el usuario tenga un monitor panorámico (aparte de que se vea horrible en un LCD/TFT por la diferencia con la resolución nativa). En ese caso se me ocurre que tienes que detectar la resolución y elegir entre dos opciones:
a.- El juego transcurre en 4:3 a todos los efectos, tanto internamente como visualmente -> Si el monitor es 4:3 no se cambia nada al renderizar la escena y si el monitor es 16:9 se selecciona el modo equivalente en 16:9 y o bien se centra la imagen en pantalla (con bandas negras) o bien se pone algún tipo de marco decorativo, o bien se aprovecha el área para mejorar los marcadores / inventario / etc. Lo ideal supongo que sería asumir que el juego sea 16:9 y hacer la "adaptación" para 4:3, por eso de que casi todos los monitores hoy en día son panorámicos, pero ... el iPAD es 4:3 y no se puede despreciar su público en número de usuarios.
b.- El juego se adapta a la resolución adicional -> Se diseña para "jugar" 4:3 pero según el tipo de juego, puede ser factible o no mostrar más área de pantalla. Por ejemplo en un juego con vista superior tipo Advance Wars o Zelda, podemos elegir mostrar más área de juego pero en otros puede no serlo. Por ejemplo, en un Bubble Bobble o un FinalFight ver más cantidad de pantalla no es lo adecuado.
Con lo que la primera duda es: ¿programas pensando en 4:3 y desaprovechando panorámicos (cuando todos los monitores de PC son panorámicos)? ¿Se puede o debe hacer la inversa? (para panorámicos y recortar de alguna forma a 4:3).
Caso diferentes resoluciones:
Vas a diseñar un remake de un juego... ¿qué resolución eliges?
a.- Si eliges una resolución baja y fuerzas FULLSCREEN, en monitores grandes se ven píxeles como puños.
b.- Si eliges una resolución alta, puede haber equipos incapaces de moverlo.
Además, si no es la nativa del monitor y es LCD/TFT el resultado es difuso.
c- Si eliges soportar varias resoluciones, tienes 2 opciones:
c.1. Dar soporte a varias resoluciones preseleccionadas, con lo que tienes el problema de que necesitas varios sets de gráficos si quieres que el área de juego sea la misma en las diferentes resoluciones (y no que en cada resolución sea vea mayor área de juego con los gráficos más pequeños).
c.2. Dar soporte a todas las posibles resoluciones eligiendo una resolución base contra un buffer y escalando el volcado de ese buffer a la resolución de pantalla. De nuevo tienes que tener en cuenta además el aspect ratio para esto. Es decir, si queremos dar soporte no sólo al PC y a varias resoluciones concretas en 4:3 y 16:9, y queremos añadir iOS, Android, etc, la cantidad de resoluciones destino disponibles es enorme. Y puede que el dispositivo no sea lo bastante potente (y esto es CPU) para el escalado en tiempo real de todo el área de trabajo a la resolución destino.
Más posibilidades y problemas:
¿Escalar los personajes? -> definir los gráficos para la mayor de las resoluciones y escalar para las menores o viceversa.
¿Diferentes sets gráficos? -> requiere un enorme trabajo gráfico para juegos 2D.
¿Gráficos vectoriales tipo svg? -> ¿Realmente se usa esta técnica?
La solución pueden ser los 2.5D (2D hecho con opengl renderizado con una cámara "lateral" o "superior").
Las múltiples resoluciones y aspect ratios también te obligan a adaptar la "velocidad" de los personajes según la resolución y los widgets del gui (menúes, marcadores, fuentes, etc). Esto no debería ser problema si las velocidades no se definen en "pixeles por segundo" sino en "unidades de movimiento del mundo virtual por segundo" (ej: metros por segundo) y después se escala lo que es "un metro" a las dimensiones en píxeles de los gráficos en la pantalla (según la resolución). Pero ya no es la facilidad de decir "esta nave se mueve 2 pixeles por segundo y esta mas rapido, a 3", hay que andar haciendo conversiones para todo lo que se va a trazar en pantalla.
¿Cuál es la mejor opción entonces para este problema?
Sets de gráficos -> "formatos gráficos pequeños + escalar hacia arriba" (entiendo que horrible a menos que quieras zoom de tipo 2x, 3x puro estilo retro), "formatos gráficos grandes + escalar hacia abajo" (entiendo que mejor, aunque el resultado del escalado sea "fuzzy"), "varios formatos (pequeño, mediano, grande) y escalar el más cercano", "2.5D y utilizar opengl"?.
16:9 vs 4:3 -> ¿Marco? ¿centrar? ¿y si el juego no permite "dar más área visible?"
Menúes, fuentes, pantallas intermedias y de fin de fase -> ¿tenerlas en diferentes resoluciones? ¿de resolución fija y escalar?
PD: Veo que no soy el único que se plantea o se ha planteado estas preguntas:
Por desgracia, no veo muchas soluciones más allá de "ceñirse al dispositivo mayoritario al que apunta el juego y escalar al vuelo el buffer resultante para el resto, en cada fotograma"... o "hacer diferentes versiones (ipad, pc, android) centrando cada una en una resolución estándar".
Ya ni siquiera considerando Android, sino simplemente el PC, si tuviera que hacer un remake y tuviera que elegir una o varias resoluciones, me veo en un dilema por la existencia de 4:3/16:9/16:10 o de gente con monitores de portátil de 1280x800 y gente con monitores FullHD donde cualquier tamaño tipo 640x480 se vería horrible.
