17 agosto, 2006

Sufridos diseñadores

Una vez que la fase de documentación ha recedido un poco, el día a día de un diseñador varía mucho dependiendo del estudio en que trabaje.

En términos generales, el diseñador tendrá que empezar a construir el juego "de verdad", escribiendo scripts, rellenando ficheros de datos, colocando enemigos. Lo que varía es la forma de hacerlo.

Cuando llega a trabajar por las mañanas, Alice lo primero que hace es arrancar su editor de texto. Lo tiene preparado para colorear la sintaxis y ayudarle un poco a editar una pila de ficheros de script (escritos en lua) que usa para definir el funcionamiento de las misiones. Los scripts son relativamente sencillos, y el juego los carga directamente, aunque siempre se cuela ese error ocasional y en vez de escribir AttackEnemy(enemy01) la pobre Alice escribe AttackEnemy(enmey01) y pierde quince minutos discutiendo consigo misma sobre porqué el NPC no se mueve para atacar.

De vez en cuando, Alice también tiene que introducir nuevos tipos de enemigos y armas en el juego. Para ello, tras conseguir de los grafistas un modelo exportado y preparado para que el juego lo cargue, y sin separarse de su viejo editor de texto, se pone a escribir un fichero de definición, en XML, donde asigna un nombre al nuevo personaje, define sus características y el fichero gráfico asociado. Desde el editor coloca una instancia en el mapa, y carga el juego para verlo en acción. Esta vez funciona a la primera, aunque la otra vez había un problema en la carga y tuvo que llamar a un programador para que lo mirara.

En el edificio de enfrente, Bob mira con celos por la ventana mientras espera a que la herramienta que compila los datos para que el juego los cargue (que llaman El Señor Lobo) termine de procesar. Bob también escribe ficheros con un editor de texto pero, en vez de cargarlos directamente, tiene que hablar con El Señor Lobo para que los convierta a un formato binario especial, casi místico, que el juego necesita para funcionar eficientemente. La ventaja es que, cuando detecta un error, El Señor Lobo no se lo calla, e incluso le da a Bob alguna pista sobre cómo solucionarlo. El clásico problema de que falta un fichero, y no sabes cual, queda ya como un mal recuerdo.

De todos modos, lo que despierta angustiado a Bob por las noches es pensar en la fase de equilibrado. Ajustar el daño de las armas, la vida de los enemigos y la velocidad con que se mueven va a ser un infierno si necesita que El Señor Lobo trabaje entre 30 segundos y un minuto cada vez que quiere probar un cambio en el juego. Y es que El Señor Lobo es eficiente y siempre produce resultados, pero se toma su tiempo.

Mientras tanto, en la otra punta de la ciudad, Charlie se recuesta en la silla pensando en su fin de semana. Ha terminado ya de trabajar hoy, en buena parte gracias al nuevo editor que los programadores terminaron hace unas semanas. Cuando lo arranca, en una ventana aparece el juego, que se puede controlar igual que siempre: W,A,S,D o el joystick para moverte, botones para disparar, etc. En el resto tiene todo tipo de controles para modificar las definiciones de los objetos de juego, aunque Charlie ha descubierto que con su formación de programador (siempre le ha gustado enredar con ordenadores) le resulta más práctico editar directamente el fichero de texto y dejar que el editor descubra que ha cambiado y lo recargue. Lo bueno de este editor es que los cambios se reflejan inmediatamente en el juego. Cambia el gráfico de una silla y puedes ver al instante que tal queda la nueva decoración del salón. Si hay algún procesado que el juego necesita, Charlie ni lo sabe ni le interesa.

El editor no tiene nada especial para escribir scripts, Charlie lo hace igual que Alice y Bob, pero también está atento para cuando un script ha cambiado, y permite recargarlo y probarlo sin perder tiempo. Charlie está ahora muy contento, pero todavía se acuerda de la semana pasada, cuando por un bug en el motor del juego el editor se colgó y perdió el trabajo de una hora, que no había grabado. Luego estuvo toda esa tarde sin poder trabajar hasta que el bug se solucionó, y tuvo que quedarse el día siguiente. Pero bueno, ha valido la pena esperar a que todo funcione, piensa satisfecho mientras apaga el ordenador para irse a casa, y de fin de semana.


Mostrar/ocultar resto...

20 Comments:

At 17/8/06 15:17, Anonymous Jare said...

Y lo bueno es que Charlie no tiene que discutir con programadores, porque todos se han ido suicidando a las pocas semanas de haber sido asignados a trabajar en el editor. Pero, hey, qué son ocho años de trabajo y 35 programadores difuntos o de baja por depresión crónica, si ahora Charlie puede trabajar a gusto?

Oh, lo mejor todavía es que Charlie se ha negado a trabajar con la herramienta hasta que estuviera terminada, y por tanto ha estado esos ocho años jugando al Everquest en la oficina.

Una mención especial a los 5 jefes de proyecto que han sido despedidos durante el proceso por ser incapaces de presentar a los directivos / inversores nada más que un "edi...quee? No me cuentes milongas, ¿¡¡DONDE ESTA MI JUEGO!!?"

:)

 
At 17/8/06 17:53, Blogger Cesc said...

Parece que Charlie no os cae demasiado bien a ninguno de los dos, e imagino que la experiencia os habrá dado razones para ello, pero me sorprende esta desconfianza tan grande en el uso de un editor como herramienta de trabajo principal de un diseñador.

Entiendo que supone mucho trabajo crear un editor sólido y cómodo de trabajar, y que según el tipo de proyecto quizás es mejor atajar un poco. Pero a la vez, la utilización de un editor me parece interesante a medio plazo, porque, en teoría, debería acelerar el trabajo en producción, una vez la herramienta esté consolidada y el equipo aprenda a utilizarla eficazmente.

Por vuestros comentarios, deduzco que esta teoría no acaba de funcionar en la práctica.

¿Podriáis profundizar un poco más en las razones por las que os parece una mala metodología de trabajo para un diseñador? ¿Os parecen mucho mejores métodos los que utilizan Bob o Alice?

 
At 17/8/06 19:20, Blogger sgarces said...

Protesto, señoria! A mi no me desagrada Charlie, mas al contrario, se puede ir de vacaciones "una vez terminado su trabajo", mientras que los otros sufren un poco mas, porque las herramientas no se lo facilitan tanto.

Como siempre, el problema esta en los excesos. Si pones a 4 programadores a trabajar durante 6 meses para ahorrarle al diseñador 1 hora a la semana, entonces es muy dificil de justificar. Por otro lado, si exiges al diseñador usar una herramienta que se cae con solo mirarla, y escribir los scripts en sanscrito, porque uno de los programadores lo esta estudiando y le gusta como suena, pues tampoco vas a sacar el juego en la vida.

 
At 17/8/06 22:52, Anonymous PrayForMojo said...

No es por nada, pero...¿Charlie existe de verdad? ¿Alguien lo ha visto con sus ojos? ¿Y dónde trabaja Charlie?...Lo digo porque yo sólo conozco Bobs, Alices, y algún que otro Alicebob o Bobalice, a todo tirar.

De todas formas, trabajar EN el editor y trabajar CON el editor (a medio hacer, claro) perjudican seriamente la salud de diseñadores y programadores.

 
At 18/8/06 11:01, Anonymous Jare said...

Al contrario Cesc, me parece que Charlie es un tipo con suerte. Logicamente mi descripción está exagerada para contrastar con la beatífica visión ofrecida por Sergio, y para enfatizar la idea de que ese tipo de herramientas no son ni mucho menos gratuitas.

Y en el precio a pagar es en donde está el quid de la cuestión. Un estudio que va evolucionando sus toolsets y amortizandolos en sucesivos proyectos durante ese proceso es un estudio que terminará con una herramienta así de maravillosa, y la experiencia de cómo usarla y exprimirla. Un estudio (o equipo) que pretende crear desde cero el Ultimate Design Toolset (tm), y cuyos diseñadores no quieren (o lo que es peor, se niegan) a mancharse las manos para ir sacando trabajo adelante, o a ir usando iteraciones de los toolsets a medida que estos van mejorando, está condenado al fracaso, o en el mejor de los casos, a tardar 4 y 5 años en hacer un juego mediocre.

Lo peor de esos esfuerzos utópicos por hacer el toolset rrrrefinitivo, es no solo el coste que tienen, sino que mientras tanto no haya caminos más toscos (pero a la postre tambien viables) para ir creando contenido de juego. Los diseñadores podrían tirarse 2 años creando documentos completamente teóricos y que no están apoyados en ninguna realidad de juego ni de tecnología, lo que habitualmente significa que en esos documentos no se abordarán los problemas reales (como mucho, se mencionarán), y la mayor parte serán paja inservible e incluso entorpecedora.

"There is no silver bullet" - no hay ninguna solución mágica. Hacer algo mejor que los demás cuesta mucho, es muy difícil, y requiere de esfuerzo, dedicación y sacrificio. Charlie tiene suerte, pero lo verdaderamente interesante es la historia de lo que ha ocurrido los años anteriores a lo que cuenta Sergio. :)

 
At 18/8/06 12:50, Blogger Grihan said...

jejeje, lo mejor de la descripción de Jare es lo "real" que suena todo lo que dice...cuánta rabia acumulada! :)

bueno, la verdad es que a todos los diseñadores les gustaría tener editores como los del Neverwinter Nights, pero está claro, que es muy difícil justificar algo así, en parte por la imperiosa necesidad que suele haber por parte de los directivos de ver el "juego" en cuanto comienza el desarrollo, y en parte porque poner a trabajar durante muchos meses a varios programadores conlleva el "convencerles" de que ahorrará el trabajo y simplificará las cosas no solo a los diseñadores, sino también a ellos.
Esto es más fácil de justificar si las herramientas en las que se quiere trabajar están pensadas para ser reutilizadas en varios proyectos, con lo cual el esfuerzo inicial merece la pena, y la sensación en el equipo siempre es más positiva.

 
At 18/8/06 13:43, Blogger Saül said...

Cómo apuntáis varios de vosotros, creo que la clave está, como siempre, en lo adecuado que sea, en cada proyecto, realizar el toolset de una forma u otra: tiempo disponible, recursos humanos, objetivos del proyecto, posible reutilización en siguientes juegos, etc. Y eso es aplicable tanto a diseño como a animación, arte, etc.

Del ejemplo de Sergio, creo que los 3 diseñadores deberían ser capaces de producir un resultado igualmente satisfactorio, entendiendo individualmente las limitaciones de cada uno de sus proyectos y adaptando a ello el nivel de pretensiones final suyo y de su productor/lead.

El buen diseñador, bajo mi punto de vista, tiene que "apechugar" con lo que hay e intentar sacarle a ello el máximo partido. Debería aprender a utilizar las herramientas disponibles y entender que si existe esa limitación en el toolset es por questiones de tiempo y recursos. O porque no se ha especificado bien de inicio desde diseño (mea culpa y ya lo sabemos para el próximo).

Diseñar es en gran parte concretar ideas, y está claro que el tipo de toolset forzará al diseñador a concretarlas de una forma u otra, a "bajar a la tierra" y descubrir como representar los features del juego con esas nuevas herramientas. En un caso dramático, muchas de sus ideas no podrán ser realizadas y deberá buscar otra forma de representar lo que estaba buscando con ellas... pero eso es excitante, ¿no?

Eso no significa que el diseñador no pueda pedir cuando lo crea conveniente, la comunicación es clave, pero creo que tampoco es bueno pasar a hacer las típicas "cartas a los reyes magos". O, si se hace alguna vez, al menos entendiendo que esa carta va a ser recortada con una "katana".

Tampoco veo bueno hacer los míticos "cheques en blanco" del estilo... "hazme un editor de misiones"... y el pobre programador tiene que inventárselo todo. Si el diseño se ha trabajado bien, cuando se vaya a crear la herramienta debería haber una lista de especificaciones necesarias (mínimas y "extras") para esos toolsets. Aunque, como siempre... todo depende del proyecto y el equipo...

 
At 18/8/06 15:04, Anonymous Jare said...

"lo mejor de la descripción de Jare es lo "real" que suena todo lo que dice...cuánta rabia acumulada! :)"

Hm... no, yo no he tenido la mala suerte de sufrir nunca ningún proyecto así. Bueno, el Bronx de Spectrum en los viejos tiempos tuvo bastante de sobreesfuerzo en tools (en la parte gráfica - por entonces no habia "diseñadores"), pero se mezclaba con muchos otros factores.

La parte que sí puede llevar algo de rabia dentro es la de que un proceso como el descrito implica una tremenda descomunicación y falta de equilibrio entre los diferentes grupos del proyecto. No es rabia en el sentido de haberlo tenido que sufrir, pero sí de saber que ocurre con relativa frecuencia. Se crean especificaciones o requisitos sin tener la información suficiente para discriminar lo que es importante y lo que no; en algunas áreas se ponen detalles irrelevantes o elegidos según suena la flauta, mientras que en otras se dejan tremendos agujeros de ambiguedad o vacío.

Es normal que haya ese tipo de errores tanto en los diseños y documentaciones, como en los propios programas y aplicaciones (bugs, crashes, etc). Lo que es realmente importante es que los diferentes grupos sientan la responsabilidad y la confianza de trabajar juntos para identificarlos y solucionarlos rápidamente, en lugar de "poner la pelota en el tejado del otro" cuando el jefe pregunta por qué las cosas no están terminadas.

Desde luego, una de las peores formas de especificar algo, es creando una lista de las cosas que "no quiero," dinámica terrible que también ocurre con demasiada frecuencia. Como mecanismo para establecer una discusión más detallada vale, pero nada más.

En Praetorians una de las dinámicas que funcionó bien cuando los grafistas pedían features en el editor, era responder "no, no me digas qué es lo que quieres que haga el editor, dime qué es lo que quieres hacer tú"; después les proponíamos una solucion de conjunta, que muchas veces implicaba añadir alguna feature al editor, pero una feature orientada a realizar una parte mecánica de un proceso de trabajo. Julián o yo nos sentabamos a veces a mirar cómo trabajaban con el editor, y luego comentabamos alguna tarea concreta que veiamos que podrían agradecer. Así llegaron cosas como el Cut & Paste de trozos de escenario entre dos copias del editor corriendo simultaneamente, y alguna otra virguería similar.

De igual forma, los diseñadores querían "una forma rápida de hacer escenarios para probarlos". Yo me negué a hacer eso, hasta que Jorge Sanchez vino con una idea completa, sencilla y directa de cómo se podría hacer e integrar en el editor, resolviendo las necesidades importantes de diseño sin generar trabajo innecesario.

Por supuesto, no quiero idealizar el desarrollo de Praetorians, que también tuvo sus épocas pesadilla, pero sí comunicar cosas que sí resultaron útiles y prácticas.

Lo que cuenta Saul tiene todo el sentido del mundo. :)

 
At 18/8/06 21:02, Blogger Cesc said...

Estoy de acuerdo en todo lo que comentas, Jare, pero no me negarás que por tus comentarios puede entenderse que estás cargando en Charlie muchos de los problemas de los que hablas.

Especialmente significativo es el siguiente fragmento: "Oh, lo mejor todavía es que Charlie se ha negado a trabajar con la herramienta hasta que estuviera terminada, y por tanto ha estado esos ocho años jugando al Everquest en la oficina." que me parece un pelín injusto para quellos Charlies, y puedo asegurar que los hay, que se pelean a diario con una herramienta a medio hacer y que no rechistan cuando tienen que adaptarse a lo que haya para sacar el trabajo adelante.

Es cierto que muchas veces es dificil encontrar el punto a partir del cual añadir una feature determinada a la tool dejará de ser eficiente a nivel global, aunque facilite en cierto modo el trabajo del diseñador, pero por mi experiencia, puedo asegurar que el caso contrario también se produce, y que en ocasiones, Charlie se pasará cuatro días de trabajo repitiendo un proceso mecánico que un par de horas de trabajo del programador de tools hubiera simplificado en gran medida, mejorando claramente la eficiencia global.

Como dice Jare, la clave está en no pasarse marrones de un departemento a otro, entendiendo que hay que encontrar la metodología más eficaz para el proyecto, no para el propio departamento.

Y yo sólo añadiría un último punto: El tiempo de trabajo de Charlie, cuando éste entiende que los programadores no son ni adivinos ni reyes magos, y cuando no se apalanca esperando recibir la tool perfecta que haga juegos como si fueran churros, es igual de valioso que el del programador de tools.

No se trata de ponerse a la defensiva, pero en algunas charlas con programadores, y no hablo de Jare y Sergio :), uno tiene la sensación que el diseñador se percibe como un mal menor que entorpece más que ayuda.

Y esto puede llevar a que, volviendo al tema de las tools, se le pase un marrón a Charlie asumiendo que es más eficiente que Charlie apechugue con él y programación pueda dedicarse a cosas más importantes.

 
At 19/8/06 08:28, Blogger sgarces said...

Cuando se habla de tools, siempre es complicado encontrar el santo grial que satisface a todo el mundo, muy probablemente porque no existe.

De ahi que en el equipo de Alice, han puesto enfasis en simplicidad y transparencia, a costa de rendimiento, para organizar una pipeline sencilla y barata, pero que requiere a Alice batirse con un editor de texto.

Los programadores que trabajan con Bob, por contra, valoran el rendimiento y quieren ver mas personajes en el juego simultaneamente, por eso hace un procesado para optimizar (y de paso, si pueden, detectar errores) los datos que diseño produce.

Donde Charlie trabaja, y no porque lo haya pedido el, sino porque es en lo que creen, la velocidad de iteracion es lo mas importante. Por eso se han preocupado de hacer una herramienta que carga datos en caliente. A lo mejor no hace nada mas, o a lo mejor si. A lo mejor tiene un sistema de deteccion de errores bombastico y optimiza los datos segun los va cargando, o a lo mejor hace exactamente lo mismo que la pipeline de Alice, y carga directamente un fichero de texto. Lo importante es que lo hace sin tener que salir del juego, y se pierde menos tiempo.

No se trata de ver quien la tiene mas larga, si diseñadores o programadores, o de resolver el nudo gordiano. Se trata de ver que es lo mas importante y de priorizar. Si el rendimiento es lo mas importante, lo siento, Bob, pero es lo que hay. Si experimentar rapida y facilmente esta por encima de todo, entonces los programadores tendran que preparar el juego para que los diseñadores iteren facilmente. No se puede tener todo. ¿Que es lo que mas te gustaria tener, si solo pudieras tener una cosa?

 
At 21/8/06 01:29, Anonymous Jare said...

"El tiempo de trabajo de Charlie [...] es igual de valioso que el del programador de tools.
[...]
en algunas charlas con programadores, y no hablo de Jare y Sergio :), uno tiene la sensación que el diseñador se percibe como un mal menor que entorpece más que ayuda"

Ufff Cesc, qué razón tienes, y al mismo tiempo qué tema de conversación tan "peligroso" es ése. :) Uno de los problemas más interesantes en la relacion entre diseñadores y programadores es que, de media, un programador recien contratado en un estudio de desarrollo tiene MUCHA más experiencia y competencia realizando su trabajo concreto (programar) que un diseñador recien contratado realizando el suyo. Ese desequilibrio en general (por mi experiencia) se mantiene según se sube el escalafón.

Hale, lo he dicho. Mañana alguno me envenenará el agua. :)

Las razones que creo que existen para que ocurra eso son muchas y variopintas, y desde luego no tienen que ver con que los diseñadores sean tontos y los programadores muy listos.

- Un programador suele haber recibido una formación académica mucho más completa que un diseñador.

- La verificación de la tarea realizada por un programador es mucho más obvia que la de un diseñador, en cuanto que en general esa verificación se puede empezar en cuanto el programador ha terminado de implementar lo que estaba haciendo. Un diseño apenas se puede probar sin haber sido implementado por programadores.

- Un programador tiene la posibilidad de alterar o completar el diseño mientras lo implementa. El diseñador lo tiene mucho más difícil para hacer lo propio.

- Un programador lo tiene más fácil para hablar de diseño que un diseñador para hablar de programación. El valor de un diseño suele resultar más "opinable" por cualquiera que el de un troncho de código.

- Un programador puede él solo HACER un juego que funcione. Posiblemente no pase de ser un clon poco interesante, pero es un juego y se puede jugar. Los diseñadores por sí solos en general apenas pueden pasar de producir una colección de documentos, unos niveles en un editor de escenarios, o unas variantes de unidades y bichos ya existentes. Para hacer algo mínimamente más completo, necesitan unas capacidades técnicas (por ejemplo, programar scripts) que muchos diseñadores rechazan como parte de su tarea.

- La programación de juegos tiene mucho más que ver con otras tareas externas a la industria de los juegos (programar bases de datos, etc), que el diseño de juegos.

Todo eso (y otras ideas que seguro se me olvidan o no sé como escribir) se puede resumir en que la tarea de programación de un programador es mucho más concreta, precisa y está más formalizada que la tarea de un diseñador. Por tanto, el programador medio percibe que su valía profesional es mayor que la del diseñador medio.

 
At 21/8/06 14:47, Blogger Felip said...

Visto que mucho no puedo añadir, por desconocimiento, sólo puedo decir que.. "No os desaniméis, diseñadores!" :)

 
At 21/8/06 20:57, Blogger cherno said...

Este comentario ha sido eliminado por un administrador del blog.

 
At 21/8/06 21:31, Blogger cherno said...

Buen thread, si señor...

Yo por mi parte no puedo sino estar de acuerdo con Jare (aunque negaré haber dicho esto mañana en la oficina).

De todos modos, yo creo que contratamos diseñadores sin ningún tipo de experiencia y les exigimos que concreten cosas que a uno que lleve 10 años le costaría escribir.

Dicho esto, cada vez que me llega el documento de diseño standard (nada concreto y lleno de flipadas, digo... ideas que no encajan entre sí) se me olvida que lo ha escrito alguien que probablemente no ha recibido adecuada formación y me quiero comer su hígado.

Una cuestión a pensar es si deberíamos tener jefes de proyecto que hayan sido primero jefes de programación para dirigir la creación tanto de los documentos de diseño como del desarrollo de los sistemas / tools hacia lo que realmente necesita el juego, en lugar de los "vendedores" que tenemos que sufrir habitualmene.

 
At 22/8/06 11:13, Blogger Truman said...

Bueno, a ver:

En general estoy de acuerdo en la mayoría de las afirmaciones que hace Jare, aunque el tono (entiendo que deliberadamente) polemista es lo que puede exaltar más pasiones.

Lo sin duda irrebatible es que el tema es una pequeña caja de pandora llena de pasiones y potenciales trincheras dialécticas. Es por ello que (por dios) yo no voy a entrar en ella de ningún modo.

Yo jamás le respondería que todas esas afirmaciones destilan un cierto aire… digamos clásico, heredero de cuando hace 20 años los juegos eran cocinados únicamente por programadores. A día de hoy hacer un AAA es tan complejo que creo los programadores están sinceramente aliviados de que haya una especialización profesional que les libre de engorrosas tareas (pese a que en su fuero interno piensen ‘pero si quisiera podría hacerlo todo’).

Nunca, nunca respondería que el perfil personal de los programadores tiene cierta tendencia a ser ‘romo’. En otras palabras, en un concurso de creatividad yo apostaría por cualquiera NO sea programador, o al menos que cuando lea ‘C++’ piense que se te ha caído la taza sobre el teclado. Esta afirmación es algo injusta, porque de hecho la historia del videojuego durante sus primeros años (y todavía hoy) la hacen muchos programadores, pero supongo que yo también me tengo que ganar el derecho a que me envenen el agua.

Nada estaría más fuera de mi intención que decir que por mi experiencia los programadores son felices si una mecánica funciona, mientras que los diseñadores lo son si esta es excitante. Y en la industria actual el que funcionen sencillamente no es suficiente.

Como resumen, yo jamás concluiría diciendo que los aires de superioridad son tanto más acusados cuando más vienen de la (por otra parte gloriosa) época de los 8 bits, cuando los programadores eran el alfa y el omega. Esto provoca problemas (que yo he sufrido) de programadores que interpretan los diseños como más les gusta y los hacen a su manera, sin encomendarse ni a dios ni al diablo, lo cual crea problemas realmente importantes. Mi impresión es que los programadores más jóvenes están más acostumbrados a trabajar en equipo y a respetar al resto de departamentos.

Dado que afortunadamente he conseguido evitar entrar en la polémica, eso nos deja tiempo a los diseñadores para pensar en nuestros propios problemas, como es el hecho de que compartimos desgracia con los entrenadores de fútbol: todo el mundo entiende de diseño, y todos se sienten licitados a opinar. De hecho probablemente lo estén, pero en demasiadas ocasiones hay tantas voces a nuestro alrededor (aparte de esa que me repite insistentemente que me traiga la UZI a la oficina y haga justicia) que siente uno ganas de hacer lo que Luis Aragonés hace recurrentemente: mandarlos a todos a tomar por el C+++.

 
At 22/8/06 15:08, Anonymous JuanD said...

A mi me gusta decir "Esto lo ha diseñado un programador". Pero cualquier programador que eche un vistazo al código script de un juego tendría todos los motivos del mundo para decir "Esto lo ha programado un diseñador".

Pero estoy descarrilando la discusión, así que me callo, que he llegado tarde a ésta.

 
At 1/9/06 13:02, Blogger fclaros said...

¿Por qué nadie le dice a Alice que utilice el LuaEdit? Se evitaría grandes problemas :P

 
At 6/9/06 17:42, Anonymous Norvin said...

Hola buenas,
Quizá estoy un poco perdido en todo este mundo de 8 bits de yo llevo 10 años etc. Pero me parece que se nos olvida la profesionalidad de unos u otros. Un programador puede mirarse el codigo ensamblador que genera su visual-compiler y descubir que hay un bug del compilador que estaba dando problemas. Así mismo, un diseñador puede darse cuenta de que una mecánica que se creía fundamental en el juego deja de ser utilizable debido a que el conjunto global del juego la deja aislada.

Así mismo, si yo tuviese que especificar a un programador cómo hacer algo, desde luego debería tener la formación "programantistica" (al loro al palabro. para poder decirle en cierto modo qué es lo que quiero, qué quiero que interprete a su manera y qué quiero que se haga como digo. Porque amigos, ¿todos hemos hecho prácticas de la universidad no? y cuando te decían que el programa tenía que hacer A y tu lo interpretabas como B te suspendían no? pues en el trabajo es igual.
Si un "Equipo de Diseño" ha decidido que algo tiene que ser de una manera, qué menos que respetar la profesionalidad de ese equipo, así mismo, si los programadores deciden implementar algo con una lista enlazada en vez de un vector, ¿por algo será no?.

Después de haber soltado todo esto, decir, que el trabajo del diseñador es diseñar, y el del programador programar las especificaciones dadas, si están mal o no se entienden o se da lugar a la imaginación y a interpretar, deberían existir los canales de comunicación para poder aclarar con Diseño las dudas.

Así pues, igual que en programación hay especialización en diseño también, y no es lo mismo un Technical tools designers que un level designer que ... etc. Lógicamente un diseñador que esté codo con codo con programación deberá cuando menos ser programador. Pero un diseñador que lo que va a hacer es construir el mundo para que quede bonito, sinceramente prefiero que sea un poco más grafista que programador.

Diseño, es un area, en el que todo el mundo pone mucho "peso". pues se nos exíge que sepamos de todo, que sepamos grafismo para comunicarnos con los grafistas, que sepamos programación para hacer lo propio con programación, etc.

Sinceramente, un editor cojonudo ayuda mucho ^^.

 
At 4/2/07 12:21, Anonymous Anónimo said...

http://tramadol-sqllt.blogspot.com/
Good Luck!

 
At 23/2/07 20:28, Anonymous Anónimo said...

http://ambien-free.blogspot.com/
Dont forget!

 

Publicar un comentario en la entrada

Links to this post:

Crear un enlace

<< Home