¿Qué fue antes, la tecnología o el diseño?
En un McDonalds…
– Quería un menú BigMac, por favor
– ¿Lo quiere con patatas y bebida grandes?
– Sí, gracias.
– ¿Desea coca-cola, fanta o agua para beber?
– Coca-cola, gracias.
– Son 10,95€, por favor.
– Aquí tiene.
(el empleado reúne los elementos y los pone juntos en una bandeja que entrega al cliente)
En la consultoría de un programador de Visual Basic…
– Quería una aplicación de gestión de clientes, por favor.
– ¿La quiere con gestión de usuarios y panel de control basado en web?
– Sí, gracias.
– ¿Desea SQL Server, Access o MySQL para gestionar su base de datos?
– SQL Server, gracias.
– Son 2.000 €, por favor.
– Aquí tiene.
(El programador reúne los elementos y los pone juntos en un proyecto de VB que entrega al cliente).
Conclusión
Trabajar apoyándonos en una tecnología ayuda a desarrollar las cosas rápidamente y con bajo coste. Pero ¿es una buena solución para hacer juegos?
Si querías una hamburguesa has hecho bien yendo a MacDonalds, pero si no sabías bien qué querías, y has descubierto que querías comida china por el camino, vas a tener que aguantarte.
Aplicándolo a nuestro entorno de trabajo, ¿sabes perfectamente qué juego quieres hacer antes de ponerte a hacerlo?
Hasta ahora, prácticamente todos los proyectos en los que he participado han seguido un mismo patrón: primero se ha decidido la tecnología y luego hemos planificado y estimado lo que necesitábamos hacer para hacer realidad nuestro proyecto.
Esta aproximación – llamémosla “aproximación tecnológica” – tiene beneficios: plantea un campo de juego claro y definido, donde cada funcionalidad tiene un coste estimable. En función de la tecnología, habrá cosas que resulten mucho más fáciles que si partieras desde cero y otras que te resultarán dificilísimas, porque quien diseñó la tecnología no las tuvo en cuenta o no las necesitó.
Desde mi punto de vista, la aproximación tecnológica es más útil cuando vas a hacer algo que ya sabes qué es, o cuando sabes que hay restricciones ineludibles. Por ejemplo, si vas a hacer un juego para XBox, no parece mala idea utilizar un motor basado en XBox y si vas a hacer un FPS para PC, probablemente comprar Unreal te ahorre muchos problemas.
De acuerdo, esto es cierto, pero los juegos frecuentemente son proyectos demasiado complejos como para que haya balas de plata. ¿Vas a hacer una versión para PC o para Playstation de tu juego de XBox? Quizá tu tecnología actual te imponga limitaciones en esas plataformas. En el postmortem de Deus Ex se explica cómo comprar Unreal ayudó en muchos aspectos, pero impuso muchísimas limitaciones:
Technology forced design changes, too. It took time to become familiar with the Unreal engine. I wish I could say we uncovered all its potentials and limitations quickly, but we didn’t. Months of experimentation were necessary to reveal how best to do things in Unreal and what things not to do at all. When we stopped playing with Unreal and actually started working with it (roughly six to nine months after we got our hands on it), lots of ideas we’d come up with in the abstract didn’t work quite as well in reality.
Multiple solutions falling out of our simulation didn’t happen as often as we’d hoped. We just didn’t have a deep enough simulation nor did we have the time or personnel to create one. We found ourselves in the position of having to brute-force the multiple-path idea, as developers on Ultima games, for example, have done for years — though I think we do more of it, more consciously and more effectively, than anyone else has to date. Designers have had to plan a “skill” path past problems, an “action” path and a “character interaction” path. It works, but it’s not what we originally intended.
Our original plan to build large, outdoor areas — whole sections of New York, Area 51, lovingly recreated in excruciating detail gleaned from maps and satellite photos and, most notably, my dream of allowing players to explore the entire White House — just proved to be unfeasible. There was no way any then-current renderer was going to allow us to do all that. The design had to change.
En nuestro proyecto actual se eligió un motor potente y versátil (o eso nos pareció al comprarlo), pero nuestro proyecto es algo nuevo, extraño; nadie ha hecho nada igual hasta la fecha, así que no sabíamos qué queríamos hacer. Ahora, que ya estamos bien avanzados en el desarrollo, nos damos cuenta de qué necesitamos de nuestra tecnología (queríamos comida china, no una hamburguesa). Algunas de estas cosas nos las da nuestro motor actual, pero hay un buen montón de limitaciones que vamos a tener que aceptar. Algunas de ellas no son limitaciones estrictas, pero la dificultad impuesta por cómo está pensado el motor hace que que el desarrollo de algunas funcionalidades que queremos sea inviable por tiempo y coste.
En el futuro intentaré tener esto en cuenta: cuando el proyecto sea algo novedoso, algo que no sepamos bien qué es, pre-imponer una tecnología puede abaratar el coste, pero salvo que tengamos mucha suerte, seguramente irá muy en contra de la innovación que puede proveer nuestro producto. Si no puedo evitar que me pre-impongan una tecnología, intentaré escoger una que me imponga las mínimas restricciones en las áreas en las que preveo que nuestro producto vaya a innovar.
Parece obvio dicho así, ¿verdad? Pero al parecer no muchos lo tienen en cuenta.
Ludosofía 
Tengo un buen doc, traducido de un articulo extenso de gamasutra y añadidas ciertas consideraciones que siempre estoy deseando copiar / pegar en mi blog que habla justo de esto y lo tengo hace meses y meses. Habla sobre una encuesta anónima a 100 empresas sobre el uso de motores o la creación de tecnología propia. Si preguntas a los productores comprar el motor es lo mejor aunque entienden que puede haber incomodidades si preguntas a los trabajadores de la empresa que jerárquicamente están por debajo (no me gusta nada decirlo así pero es para que se me entienda) ven fatal y les da muchos problemas utilizar tecnologías cerradas aunque comprenden el uso de estos motores, otra cosa es que lo pasen bien cuando un productor exige y un game designer diseña, el programador se tira de los pelos y el artista no puede conseguir el resultado que le piden.
Ya sabes que yo siempre he sido pro-creación de tecnología por muchísimas e innumerables razones que no pienso discutir. Para mi estar en una empresa donde no se hace o no se invierte en este apartado es, a parte de aburrido y problemático, es necesario y es sobre todo en las empresas donde quiero estar.
Para mi una empresa que licencia un motor para un desarrollo concreto, lo usa, lo exprime y logra su objetivo comercial el siguiente paso es “todos a la calle” / “a otra cosa”. Para mi es muy importante la actitud y valores de las empresas. Creo que la inmensa mayoría de las empresas que licencian es porque su objetivo nº1 es ganar dinero (como todas, está claro si no haber de que se come, debe ser así) su objetivo nº2 es ahorrar para quedarse primas de dinero los 4 ejecutivos que decidieron licenciar y el 3º podría ser para que sobre dinero y me pague otro desarrollo o algo similar. 3 razones monetarias que convierten al arte del desarrollo de videojuego en algo insípido o al menos para mi.
Yo y mi utopía? antes no era así y aun quedan empresas en donde afortunadamente aun persisten estos valores! 🙂
Aunque parezca mentira esto se puede extender a muchos proyectos informáticos, por algo son proyectos y no producción en serie.
Tener una tecnología o arquitectura de desarrollo ayuda en gran medida en lo que comentas, estimar costes (de recursos y temporales). Pero todo proyectos por prototípico que sea tiene sus pequeños matices que aporta el cliente, bien por que los exige o bien por que ya que se gasta el dinero hay que darle algo más para diferenciarse de la competencia.
Por lo tanto, los puntos innovadores son los que determinan el gasto extra si se quieren llevar a cabo. Y por extensión los quebraderos de cabeza.
La tendencia a la estandarización, piedra angular actual de la industria en general y no solo de los videojuegos tiende a mejorar lo igual y penaliza lo diferente.
Soy de la opinión que los videojuegos deben innovar para crear nuevas experiencias. Las ataduras limitan la creatividad pero crean productos que es lo que buscan las empresas. Es una balanza que por suerte en algunas ocasiones se equilibra.
“Por lo tanto, los puntos innovadores son los que determinan el gasto extra si se quieren llevar a cabo. Y por extensión los quebraderos de cabeza”
100% de acuerdo. Esa es mi conclusión también.
“La tendencia a la estandarización, piedra angular actual de la industria en general y no solo de los videojuegos tiende a mejorar lo igual y penaliza lo diferente”
Muy buen apunte el del que esta tendencia no se limita a los juegos. Es algo que subyace al hecho de sacar cosas adelante con menor coste.
“Soy de la opinión que los videojuegos deben innovar para crear nuevas experiencias. Las ataduras limitan la creatividad pero crean productos que es lo que buscan las empresas. Es una balanza que por suerte en algunas ocasiones se equilibra”
Eso es lo difícil. En fin, el tiempo dirá si somos capaces de hallar ese equilibrio.
Un desarrollo es una continua evolución de una idea, constantemente surgen nuevos retos a los que se aplican nuevas soluciones, herramientas o limitaciones que no conocías, o se descubren ideas novedosas que modifican el diseño original. Atar el mayor número de cabos durante la fase inicial de cualquier proyecto es tan importante como difícil, no ya solo para una decisión tan crítica, extremadamente crítica, como el motor a usar sino para cualquier punto en el diseño. ¿Cuantas veces durante un proyecto uno juega con la idea de borrar todo el proyecto y partir de cero sabiendo lo que sabes ahora?
Borrar todo y volver a empezar es una gran idea que tiene un pero los plazos, malditos pero necesarios.
Si tod@s pudieramos hacer eso, como, por ejemplo, los desarrolladores de Duke Nukem Forever… XD
Y siguiendo por el camino de extender las conclusiones a otros campos, ¿quién no ha deseado encontrarse con 20 años menos y sabiendo lo mismo que ahora? (aparte de alguien que tenga menos de 21 años).
Buen apunte el de atar cabos al principio. Es un resumen excelente de los problemas y las necesidades iniciales de cualquier proyecto.
Ains Isilion, ¡cómo te comprendo!
Este artículo lo escribo en tu honor, Gyakoo, que estás teniendo que capear todos nuestros problemas 🙂
Personalmente creo que la mejor solución es la que abordas en el articulo, elegir la tecnología y luego en función de ella evaluar que se puede y que no se puede hacer, de lo contrario pasa lo que paso con Duke Nukem Forever como lo mencionan en otro comentario, DNF me parece el mejor ejemplo porque cuando George Broussard trato de hacer un juego “perfecto” cometio un grave error, debido a la naturaleza cambiante de la tecnologia y sobretodo en esta industria.
Recomiendo el articulo “Aprender a dejar ir: Como el exito mato a Duke Nukem” (Learn to Let Go: How Success Killed Duke Nukem) donde se puede ver lo que no se debe hacer.
http://www.wired.com/magazine/2009/12/fail_duke_nukem/
Creo que es al revés la solución. 1º evaluas y luego eliges la tecnología que pueda hacer lo que necesitas o la mayoría de las cosas.
El error viene de fliparse y elegir un motor super chulo ! y luego venga! no se que quiero hacer pero este motor mola!
Así siempre luego vienen los problemas…
Me refería a evaluar lo que puede hacer la tecnología en la etapa de desarrollo en la que se elige dicha tecnología
+1
+1. Y anda que no duelen las consecuencias cuando no se hace así… ¿Verdad, Isi?
Muy bueno, el artículo del Duke Nukem. Me surgen algunos comentarios que escribiré cuando lo termine de leer. Gracias 🙂
Yo no estoy de acuerdo con que la mejor solución sea elegir la tecnología. Si te fijas, ellos lo hicieron: primero licenciaron Quake II, luego Unreal y luego la nueva versión de Unreal. ¿Les evitó el problema? No, porque no estaban dispuestos a ceñirse a lo que esa tecnología podía hacer. Quizá les hubiera ido mejor si hubieran pasado los 12 años de desarrollo creando su propio motor de juego. Al menos podrían haberlo ido licenciando a otras empresas y sacando más fondos para seguir el desarrollo.
De todos modos, el problema del Duke Nukem, por lo que dicen ahí, fue el no saber cuándo parar.
Yo no creo que haya una respuesta única y válida para todos los problemas. No creo que la solución sea elegir la tecnología o no hacerlo. Creo que cada proyecto tiene su problemática y que la solución depende de ella. Si quieres hacer un FPS, compra un motor de FPSs, que te ahorrará tiempo, pero sé consciente de que eso te va a imponer un límite: el resultado será lo que te permita el motor y un poco más (lo que puedas desarrollar tú). Por eso, elegir una tecnología sin saber qué quieres y luego encontrarte con que necesitas otra cosa puede ser francamente desastroso.
Como con todo en la vida, depende del caso 🙂
Primero te flipas; siempre te flipas. Piensas en el juegazo que quieres hacer, “sin límites” (ojo a las comillas). Luego tienes restricciones de todo tipo: tiempo, tecnología, presupuesto, etc. Y como diseñador, parte de la gracia de este trabajo es conseguir transmitir una misma sensación bajo estas restricciones, adaptándote a ellas en lugar de peleándote. ¿Que tus tecnología no da para tener miles de personajes pegando tiros y recrear una batalla con 2000 unidades por bando? No pasa nada, utiliza lo que tienes e intenta que el jugador tenga esa sensación de otra manera.
Por lo menos a nivel de diseño (de juego), tiene su gracia intentar solventar estas limitaciones con un poco de buena mano y habilidad. Lo malo viene cuando no se sabe qué se quiere, la dirección del producto no está clara, “no hay límites” y además careces de personal técnico capaz de evaluar la tecnología, como nos pasó a nosotros, con la suficiente profundidad que requiere un proyecto tan monstruoso. Ahí ya, vas de camino al McDonalds, pero intuyes que realmente no te apetece hamburguesa incluso antes de ponerte las zapatillas y salir de casa.
Si se sabe lo que se quiere hacer y está acotado (aquí juega un papel esencial la tecnología), es mucho más fácil abordar el problema de otras maneras por lo menos a nivel de diseño de juego.
Hola family !
Esto lo llamo yo.. la teoria de las restricciones.
Normalmente, desde una función a una clase, a una arquitectura, cuenta con un interfaz.
Este interfaz, comprender, tanto lo que puede hacer, como, lo que no puede hacer ! 🙂
Eso a nivel de diseño, si nos movemos a nivel de implementación, las restricciones de lo que el interfaz no hace, normalmente, por imperiosa ley de murphy, tienden a incrementarse.
Así, que efectivamente, cada vez que se toma una decisión de diseño, te esta CASANDO con esa decisión, y eso normalmente, implica que NO PUEDES hacer ciertas cosas.
Moraleja, hay que ver con quien te casas y para qué, y ser conscientes de estas limitaciones.
Lo ideal, como siempre, para MANTENER LA LIBERTAD, es plantearse USAR LO MEJOR de cada una para cuando lo necesites, pero en lo posible, SIN CASARSE con nadie…
El arte, está en hacer que puedas USAR lo mejor de cada tecnologia, sin casarte con ninguna y que se lleven bien entre si.
Pero esto es complicado, y a veces es una utopia, o un harem 🙂 Pero tampoco me creo que no haya problemas en un haremtecnologico… lo mejor usar las menos posibles tecnologías, con el rol mas especifico.
gracias al que haya llegado leyendo hasta aqui : )
Proyectos, lo mas pequeños posibles con roles concretos y al grano, filosofia kaizen, fuera desperdicio !!
Al final hacer juegos es como ser ingeniero:
“Ingeniero no es quien hace las mejores cosas, sino quien hace las cosas de la mejor forma posible con las herramientas de que dispone”.
Pues yo conozco algún “ingeniero”, y tú Juampalf también, que se autoproclama como tal, que no parece ver esa idea (Querer una aventura gráfica 3D, en 4 meses, sin recursos, con gente sin experiencia y querer vender miles de copias através de distribución propia es de las cosas más graciosas que he visto) y es la que realmente debe estar presente en todo proyecto.
Yo siempre digo que con tiempo y recursos lo que se quiera, pero nunca hay tiempo y ni recursos, por que los milagros no existen.
Hacer un juego triple A como lo hace Blizzard de puertas del estudio hacia fuera es fácil (seguramente algún empleado habrá muerto por estres), hasta que no tienen lo que quieren retrasan las fechas lo que haga falta pero garantizan un producto en las mejores condiciones. Eso trasladado a cualquier otro proyecto, de videojuegos o no, es la principal premisa pero con las limitaciones comentadas, obtener el mejor resultado con las condiciones dadas.
Un buen estudio previo es fundamental si se quiere hacer algo profesional y este estudio es el que debe determinar las futuras decisiones.
Promiscuidad tecnológica, ¿eh? 😛 Desde el diseño también se puede intentar algo parecido: mezclar las partes del diseño que más te interesen de distintos proyectos para conseguir una nueva criatura.
En esos casos nuestros problemas (como diseñadores) son distintos de los tecnológicos. Si quieres utilizar una parte de un diseño tienes que tener en cuenta cómo funciona dentro de su “todo”. Si sacas el corazón de una mecánica de juego, tienes que sustituir ese corazón con una pieza (otra mecánica o elemento de diseño) que haga las funciones de corazón. Digamos que se trata de encontrar mecánicas que hagan la función de un riñón en un juego y que puedan ser corazón en otro. Al final acabas con un pequeño Frankenstein que tienes que vestir y maquillar bien para presentarlo al mundo como algo novedoso (porque posiblemente lo sea).
Aquí, como en tu caso, utilizas lo mejor de cada lugar casándote “lo mínimo” con cada parte.
Muy Interesante.
Creo que para proyectos independientes es mejor escoger la tecnologia primero porque aqui tambien esta la cuestion del tiempo y el conocimiento pongo un ejemplo 3 personas se unen a hacer un proyecto creo que si
cuentan con conocimientos limitados por el momento a por ejemplo game maker entoces tienen que escoger la tecnologia primero en este caso el game maker despues piensan en que juego hacer y por supuesto pensando en las limitaciones del motor y asi todo sera mas sencillo y facil y te ahorras el problema de frustrarse el equipo disolverse y no hacer nada ojo lo digo para grupos que estan empezando y no tienen muchos conocimientos.
Muchas gracias por el articulo.
Saludos.