http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/0465067107/ref=sr_1_1?ie=UTF8&s=books&qid=1271336515&sr=8-1
Este libro está bastante bien, no solo para interfaces, sino para diseño de juegos en general.

Trata temas cómo crear interfaces (o situaciones u objetos...) que inviten a usarse de una manera y no de otra. Habla sobre las diferencias entre los modelos mentales que tiene la gente de cómo funciona algo y cómo funciona en realidad.. el feedback que se da al usuario sobre el estado del sistema... Como evitar que el usuario cometa errores o haga acciones indeseadas...


http://www.amazon.com/dp/1592530079/ref=oss_product
Este otro va muy directo al grano y presenta patrones y casos específicos, leyes o dierctrices útiles para el diseño de interfaces... Cosas bastante prácticas que conviene tener en cuenta. También me parece bastante útil.


http://www.amazon.com/dp/0596008031/ref=oss_product
Y este otro no te puedo decir si está bien o no porque no lo he leído aún. Pero me lo han recomendado y me parece que es muy similar a este último.


Edit: Bueno, no había leido que ponías webs así que no se si te interesan libros. De todos modos ahí están por si te sirve a ti o a alquien.

Buen artículo. Y con buenos enlaces. ¡Gracias!

En la misma linea está la charla de Jesse Schell en el DICE:
http://g4tv.com/videos/44277/DICE-2010-Design-Outside-the-Box-Presentation/

Y este blog también suele tener artículos sobre truquillos psicológicos utilizados en diseño de juegos:
http://www.psychologyofgames.com

[Producer]

Igual es que me cuesta distinguir entre lo que es broma y lo que no, pero hay algunas definiciones que me suenan un poco raras. Corregidme si me equivoco, pero voy a ver si puedo matizar:


Producer: "anima y habla con la gente"
No es que esté mal la definición, pero dicho así puede dar una idea equivocada o incompleta de este trabajo.

Los productores hacen muchas cosas y posiblemente sea el trabajo más poco definido y heterogéneo del desarrollo de juegos. Para añadir confusión además hay varios tipos de productores, pudiendo ser el productor simplemente el que ha puesto la pasta o el que es responsable de la parte administrativa a más alto nivel del proyecto (financiación, outsourcing, aspectos legales...).

Pero normalmente, en desarrollo de juegos, cuando hablamos de productor nos referimos a un puesto cuyo cometido es que el desarrollo no se detenga y que todo el mundo tenga trabajo y lo necesario para realizarlo. Si alguien está parado ya sea porque no tiene tareas o porque no tiene lo necesario para poder desarrollarlas, el productor debe darse cuenta y buscar las maneras de solventarlo hablando con jefes de departamento, comprando material, cambiando prioridades en las tareas de otras personas, etc. Si hay retrasos, se van a fallar milestones, los departamentos están desbalanceados, o si hay cualquier incidencia que pueda afectar al desarrollo debe ser capaz de detectarlo y buscar las soluciones para proponerlas al director del proyecto y tomar una decisión.

En función de la empresa también puede atender a tareas de recursos humanos procurando contratar a personas que encajen bien en el equipo y ayudando a mantener a la gente motivada, pero no se si son tareas inherentemente ligadas a este puesto.

Un articulo en gamasutra que lo explica mejor que yo:
http://www.gamasutra.com/blogs/KainShin/20090531/1605/WTF_Do_Producers_Do_All_Day.php


Procedural: "que se puede proceder con el desarrollo porque hay suficiente dinero para acabarlo"
Igual es que yo soy programador y mi idea es distinta. Puede que en jerga de negocios o de producción sea esa la definición, pero si en una desarrolladora hablas de algo "procedural" normalmente se entenderá que es algo "generado proceduralmente". Es decir que no es de esa manera porque alguien lo ha creado precisamente así, sino que sus características se han definido mediante algoritmos.

Por ejemplo, las mazmorras de Diablo se generan de forma procedural, cada partida son diferentes porque se crean mediante unas reglas y unas elecciones con un componente aleatorio (lo mismo pasa con el equipo e incluso con algunos enemigos).

En la wikipedia (en inglés, en castellano no lo encuentro) lo explican mas o menos.
http://en.wikipedia.org/wiki/Procedural_generation


Escalable: "que es asumible por el equipo hardware de desarrollo software"
No se si he entendido bien esta definición. Normalmente, cuando he escuchado hablar sobre escalabilidad ha sido en el sentido de la capacidad de aumentar la dimensión de algo y que siga funcionando adecuadamente.

En la wikipedia hay una definición bastante maja:
http://es.wikipedia.org/wiki/Escalabilidad


Ermanake, en gamasutra.com tienes miles de artículos y blogs de desarrolladores que te pueden ayudar a comprender de qué va todo esto de hacer juegos. Ya comentas que todo el mundo te dice que empieces por algo pequeño, pero yo te lo repito, eso que estás haciendo es como ver "Al Filo de lo Imposible" y decidir escalar el K-2. A ti te puede parecer posible, pero los que sabemos lo que hay detrás de eso te diremos que te marques objetivos mucho más asequibles. Aprende flash, o XNA y haz cositas pequeñas como un pong o un tetris. Diseña juegos de tablero o de cartas y pruébalos con tu familia o tus colegas, verás que cosas aparentemente tan básicas como esas son muy difíciles de hacer bien.

De todos modos, te doy ánimos para que aprendas y disfrutes de esta afición (o profesión), que yo creo que merece la pena el esfuerzo.

Claro, es que hay puestos en los que saber un poco de todo es esencial para ser maestro en esa disciplina concreta, por ejemplo en producción o en dirección. Y en la mayoría de los puestos saber un poco de las demás partes tambien es una gran ayuda para ser experto en tu disciplina.

Lo bueno es no pensar en términos de - "¿A qué disciplina pertenezco?" - sino más en plan de - "¿Qué tengo que saber para hacer bien mi trabajo?"

Hubo una charla en la GDC de 2007 sobre documentos de diseño con información muy buena y muy práctica:

http://www.zenofdesign.com/Writing_Design_Docs_2008.ppt
http://store.cmpgame.com/product.php?id=1879&cat=51

El audio hay que comprarlo. Yo lo tengo pero colgarlo aquí sería ilegal...

También tenéis un resumen de la charla en la Game Developer de Diciembre 2008.

¿como se puede objetivamente determinar que una historia/guión es bueno y cual no lo es?

Depende de cómo definas bueno y malo. ¿Que se ha vendido mucho, que es muy conocido, que provoca reacciónes intensas, que mucha gente lo disfruta, que la gente que lo disfruta lo disfruta mucho...?

Lo cierto es que si le preguntas a un pintor porqué el Cristo de Velazquez es un buen cuadro no te dirá "porque mola", te dará razones sobre la técnica del artista, la composición, el uso de la perspectiva, el significado de la iluminación, la corrección de las proporciones y mil más. Pero siempre quedará la parte que no es medible y que sigue unas reglas que están enterradas en las mentes del autor y de los espectadores, en el mundo de las connotaciones, el inconsciente colectivo, las experiencias personales, etc.

Lo mismo ocurre con los guiones. Si yo, sin saber, escribo un guión y se lo doy a un guionista profesional para que opine, me hablará de arcos, estructura, ritmo, conflicto y mil cosas más que yo desconozco y que él domina, y por esa razón la gente que lee mis guiones se cansa a los dos párrafos y los suyos te enganchan hasta el final. Por lo tanto, la gente que sabe, sí que te puede señalar muchas cosas que hacen que un guión sea malo o bueno, aunque, como digo, una parte esté fuera del alcance de los estudios y las valoraciones.

asi que creo que el problema es más de elaborar buenos guiones que de que el medio no lo permita.

Igual no me he expresado muy claramente, no digo que el medio no permita usar la narrativa tradicional, lo que digo es que algunas técnicas se adaptan bien (incluso ganan) y otras mal, y sobre todo digo que, gracias a las características particulares de los juegos, existen otras técnicas a las que no estamos prestando atención y que posiblemente sean nuestra mayor ventaja a la hora de contar historias.

Es como un saltador de pértiga que se entrena con métodos de velocista, está bien que lo haga porque tienen características en común, pero si solo hace eso y no usa técnicas especiales para su disciplina no lo veremos realizar saltos espectaculares.

Un juego sin guión seria un sandbox, o los juegos que se basan solo en su jugabilidad, tipo tetris, fifas, etc.

No me parece que eso sea cierto... Un juego sin guión no tiene por qué ser un sandbox, un juego sin objetivos establecidos si que es un sandbox, incluso algunos dicen que eso ya no es un juego sino un juguete...

El ico no deja de ser otro juego de puzzles totalmente lineal y predefinido

Lo que intento señalar es que ese juego, igual que shadow of the colossus, metal gear solid, o incluso juegos antiguos como Choplifter (¿no os daba pena cuando mataban a un "hostage"? A mi si  :'() crean relaciones, desarrollan personajes y te presentan situaciones dramáticas de una manera que no es posible sin las virtudes de los videojuegos. Que sean predefinidos o no... es otra historia.

A veces pienso que el mundo de los juegos está demasiado obsesionado con hacer guiones estilo película. Si ya es muy difícil crear una buena historia o un buen guión en cine o en literatura, en juegos todos sabemos que lo es aún más.

Quizás la razón por la que nos resulta tan difícil introducir una buena narrativa en un videojuego es porque intentamos hacerlo aplicando u adaptando las técnicas narrativas tradicionales. Usamos diálogos sostenidos, desarrollo de personajes, escenas preparadas, líneas argumentales, etc. Normalmente, a lo más que se llega es a adaptarlas para tener en cuenta algunos factores como la interactividad, la impredictibilidad o la identificación del jugador con el personaje que maneja. Pero haciendo esto estamos estrechando nuestra visión al subconjunto de elementos del cine/literatura que podemos aplicar a los juegos. No digo que sea malo usar los recursos narrativos de otros medios, son métodos que se han estudiado y se ha escrito mucho sobre ellos, así que es un conocimiento que está ahí para que lo cojamos, lo adaptemos y lo apliquemos a los juegos, eso me parece genial.

Lo que quiero decir es que deberíamos esforzarnos por salir de los moldes que esas técnicas nos imponen, y ver todo el espacio que queda fuera de ellos cuando los aplicamos a los videojuegos. Hay muchas posibilidades narrativas en los juegos que no existen en otros medios. La interactividad es una dimensión apenas usada hasta ahora para contar historias y se da el caso de que es el punto fuerte de los juegos, tenemos el medio para explorar esa nueva dimensión y descubrir técnicas desconocidas hasta ahora.

Algunos ya han empezado a dar buenos pasos en ese nuevo territorio. Por ejemplo, en ICO, la relación entre los personajes se desarrolla mientras jugamos. Las mecánicas, la situación en la que nos ponen,  el control, las reacciones de la IA... son elementos que hacen que desarrollemos sentimientos hacia Yorda a la vez que nos transmiten los suyos y nos hacen comprender la situación. En mi opinión, estos elementos nos narran la historia de una manera que solo en los juegos es posible, y por ahí es por donde podemos encontrar el camino que nos saque de la mediocridad de los guiones y nos lleve a una dimensión a la que ningún otro medio puede llegar.

¿Estáis de acuerdo? ¿No lo estáis? ¿Se os ocurren técnicas narrativas solo posibles en un juego? ¿Es esto un offtopic y debería pasarse a otro hilo?

Jo, eso de que The Longest Journey le da mil patadas a Monkey Island me ha dolido... Es como que te digan que tu papá es mil veces más listo que tu mamá   :'(

Tendrán mil fallos los dos, y yo seré el primero que los señale y critique, pero despreciar a cualquiera de los dos es un sacrilegio en mi religión y por lo tanto, Gorkin, irás al infierno, donde Uwe Boll dará buena cuenta de ti.

El guión es un elemento de los juegos. Es prescindible como lo son los demás elementos (sonido, imagen, socialización, expresión, competición, etc.) excepto los inherentes a la definición de juego (mecánicas que interaccionan con jugador y objetivos). Siempre he dado por hecho que eso es así, ¿No? A no ser que haya por aquí algún narrativista de esos que ven narrativa en el tetris...

Si, a mí también me parece que los guiones y diálogos de las viejas aventuras de Lucas no han sido superados a día de hoy (aunque como dice fjfnaranjo ha habido algunos bastante decentes). Pero la verdad es que teniendo en cuenta la gente que participó y dónde y cómo se hicieron no me extraña en absoluto.

- Implicados en esos juegos te puedes encontrar, además de los consabidos Grossman, Shaffer y Gilbert, a gente como Steve Purcell, Peter Chan, Hal Barwood, Orson Scott Card... Todos ellos experimentados en literatura, cine, guion, etc. Vamos, que si tu productor es escritor, tu grafista también, tus amigos también, y cada vez que bajas al bar a tomar algo te juntas con más escritores, editores o directores que trabajan en la oficina de al lado en películas multimillonarias, estás sumergido en el caldo de cultivo de un gran guión.

- Los diseñadores/guionistas eran los mismos que programaban el juego por lo que sabían lo que era posible hacer, los truquitos que podían emplear o podían modificar el motor para adecuarlo a una nueva necesidad. Evitaban los problemas de comunicación entre programadores y diseñadores y optimizaban esta parte del desarrollo.

- El sistema que emplearon en el desarrollo fue altamente iterativo. Podían montar o cambiar escenas del juego muy rápidamente, probarlas, enseñárselas a un par de personas para ver sus reacciones y opiniones y volver a modificarlas, todo esto varias veces al día. De hecho, cada poco tiempo, los jefes, con un grupo de gente, iban pasando de ordenador en ordenador para ver las nuevas escenas y, en función de las risas que se echaban, la escena se quedaba así, se modificaba o se quitaba.

Por mi parte te recomiendo Flash por varias razones:

- Si las mecánicas son sencillas se puede prototipar muy rápido.
- Los gráficos vectoriales quedan resultones incluso si no eres grafista.
- Funcionan en cualquier equipo, sin instalación ni problemas de compatibilidad por lo que son perfectos para currículums.
- Cuando trabajes de diseñador de juego tendrás una buena herramienta para probar tus ideas antes de proponerlas; y un prototipo funcional es una forma genial de comunicar a los demás tu diseño, de evaluar las necesidades y de detectar posibles problemas.

Nosotros tenemos un diseñador que controla bastante de Flash y la verdad es que da gusto cuando lo ves programarse sus mecánicas, probarlas, cambiarlas y luego llevar a programación el prototipo con el concepto ya mascado y listo para plasmarlo en el juego. No siempre es posible hacer esto a causa de la complejidad de las mecánicas o del tiempo del que disponen en diseño, pero cuando sucede es una gran ventaja.

Probar un juego en DS o en Wii, es un poco incómodo y las probabilidades de que prueben lo que les mandas disminuyen, y con ellas tus posibilidades de impresionar al que te va a contratar. Pero el haber hecho juegos para esas plataformas te da el plus de que conoces sus posibilidades y sus limitaciones y tus diseños serán más concretos y realistas. Cuando mandes curri di esto en tu carta de presentación o en algún apartado, creo que puede ayudar.

Bueno, y ya que estoy en plan de dar consejos como si fuera un entendido  :-[ (no soy más que un programador con interes creciente en el diseño) te diría que para prepararte te leas unos cuantos libros de diseño como el "Rules of Play", "Game Design Patterns" o el "The Art of Game Design: A book of lenses" (este es genial, leetelo el primero si no lo has hecho, muy inspirador) y uses los conocimientos que adquieras para analizar algún juego comercial. Hace ya algún tiempo que lo hago de vez en cuando y me parece una buena manera de aprender. Además, puedes sintetizar las partes más interesantes de tu análisis y adjuntarlas como muestras en tu curriculum en forma de ensayo cortito (muy cortito y directo, una hoja o menos, que si no no lo van a leer).

[/modo yoda off]

Tras el post de Seryu me he puesto a mirar por vgchartz a ver como andaba la proporcion consolas/juegos entre la PS3 y la 360. Si la PS3 no puede ser pirateada debería vender más juegos en proporción al número de consolas instaladas.

Hay 28 millones de 360 frenta a 20 millones de PS3.
Es decir, hay un 40% más 360's que PS3's.

Las proporciones que observamos en las ventas de juegos (que se me han ido ocurriendo buscar) son estas:

Código [Seleccionar] Expand

                            360                  PS3                ventaja 360 sobre PS3
Rock Band                    2.33                0.92                 +153%
Guitar Hero 3                3.98                1.87                 +113%
Call of Duty 4               7                   4                     +75%
Star Wars: Force Unleashed   1.61                1.09                  +48%
Dead Space                   0.88                0.61                  +44%
Assassin's Creed             4.51                3.30                  +36%
Civilization Revolution      0.62                0.46                  +34%
GTA IV                       6.77                5.37                  +26%
Mirror's Edge                0.61                0.5                   +22%
Prince of Persia             0.86                0.76                  +13%
Devil May Cry 4              1,3                 1,19                   +9%
Tomb Raider: Uderworld       0.61                0.74                  -17%

Como veis, las cifras son muy dispares, cada uno que las interprete como quiera. Es una muestra pequeña, y estas cifras pueden estár influenciadas por mil cosas, como gente que tiene las dos consolas y se compra en PS3 solo las exclusivas y los que salen en los dos sistemas los piratea en 360, o mil cosas más que lleven los números para un lado o para otro. Esto es un estudio rápido y chapucero así que no será muy fiable. La media dá un 46% más de juegos vendidos en 360 que en PS3, pese a que "solo" hay un 40% más de 360, parece que la 360 vende los mismos o más juegos en proporción a consolas instaladas que la PS3. Si, a mí también me ha sorprendido, puede que al ser una muestra tan pequeña el dato no refleje muy bien la realidad, pero bueno, la media de los 8 datos centrales (para quitarnos datos extremos) es 37.25% así que podemos decir que no se desvía mucho del 40%.

Mi conclusión es que el hecho de que una consola sea imposible de piratear no le da una ventaja en ventas de juegos, o al menos no se la da en juegos no exclusivos.

zunou, también puedes entrar como programador de scripts, que no hace falta un nivel de programación tan alto como para otros puestos y te vendrá muy bien como formación para ser diseñador. O como QA, que se parece un poco a ser tester pero sobre procesos internos del desarrollo, y que también es un buen puesto para luego ser diseñador.

Supongo que pasa como en la vida real. Lo mejor es no engañar, pero si lo haces porque crees que merece la pena... ¡Que no te pillen!

Como soy un paperítico agudo :P no puedo dejar de señalar que sobre este tema hay prácticamente un capítulo entero en el libro "Rules of Play". Pego una reflexión que hacen sobre lo de "hacer trampas" con la dificultad por si resulta interesante:

Chapter 18: Games as Cybernetic Systems
"[...]Are you then playing the game, or is it playing you? Is a game "cheating" if it constantly adjusts its own rules? Could such a scheme be designed into a multiplayer experience and still feel "fair" for everyone involved? These questions have no definitive answers, as there are always many solutions for any given game design problem. Dynamic Difficulty Adjustment could be considered a heavy-handed design tool that takes agency away from the player, or it could be considered an elegant way of invisibly shaping game play so that every player has an optimal experience. Regardless of your opinion on the matter, DDA is an important tool, and as digital games rely more and more on their ability to automate complex processes, this kind of design strategy will become more common."

De todos modos no hace falta engañar al jugador para regular el juego, puedes hacerlo con reglas totalmente visibles y aceptadas por el jugador. En el Mario Kart si que es un poco engaño porque al cambiar los iconos aleatoriamente al pillar una caja parece que debería ser perfectamente aleatorio y en realidad no lo es, aunque supongo que tras jugar unas cuantas veces, esto se hace tan obvio que los jugadores lo asumen como una regla más. Pero si en un juego de coches usas el rebufo para pillar más velocidad, o incluso para aumentar una barra de turbo, esa regla es perfectamente conocida, visible y limpia, y del mismo modo está regulando que el jugador que va detrás pueda correr un poquito más que el de delante y así igualar un poco la carrera.

y en que consiste un programador de gameplay? es programar lo que te dice el diseñador?, o en decirle los cojones voy a poner eso que necesito 2 años para hacerlo.. y entoces el diseñador piensa otra cosa, como cuando el guionista dice, " y salen 4 tanques 10 harriers, 5 portaviones, explota una planta petrolifera y sale un cracken y se come todos los portaviones entoces... y viene el productor y dice si hijo 100 millones de dolares para eso, deja 1 avion 1 tanque 2 portaviones y el craken lo paga tu puta madre.

Esas ideas imposibles o demasiado costosas deberían ser cribadas o refinadas en reuniones entre los jefes de departamento, gente de producción y el equipo de diseño, al estilo de los desgloses de guión que se hacen en cine. Pero eso solo sucede en el país de las hadas y las piruletas, en el mundo real ocurre que  muchas de las cosas que debe implementar un programador de gameplay se generan mientras se escriben documentos, en reuniones sin presencia de alguien que pueda supervisar su viabilidad, o mutan desde dicha reunión, o quizás hubo un problema de comunicación... Así que al final si, entre las tareas diarias de los programadores de gameplay está la de bajar de las nubes a los diseñadores  >:D. Bueno, y entre las tareas de los de IA, tecnología, animadores, de las de la gente de mapas ¡y de todo el mundo!  ^_^

Así que si quieres ser diseñador, te puede interesar aprender un poco sobre el funcionamiento del resto de departamentos para tener una idea aproximada de qué cosas son muy costosas de hacer, qué cosas son muy sencillas, qué atajos se pueden usar, etc. Aunque claro, al final siempre tendran que supervisar tus diseños los que de verdad saben lo que va a costar hacer eso, pero te ahorrarás unas cuantas "bajadas de las nubes"  ;)