Warning: Use of undefined constant administer_template_action - assumed 'administer_template_action' (this will throw an Error in a future version of PHP) in /home/lab10924/public_html/jorge/wp-content/plugins/wp-ad-manager/ad-minister.php on line 33

Warning: Cannot modify header information - headers already sent by (output started at /home/lab10924/public_html/jorge/wp-content/plugins/wp-ad-manager/ad-minister.php:33) in /home/lab10924/public_html/jorge/wp-includes/feed-rss2.php on line 8
Jorge Ordaz http://jorge.lab109.net Videojuegos Artesanales Wed, 24 May 2017 19:52:03 +0000 es hourly 1 https://wordpress.org/?v=5.3.2 ¿Qué es «Spec Work»? http://jorge.lab109.net/index.php/2017/05/24/que-es-spec-work/ http://jorge.lab109.net/index.php/2017/05/24/que-es-spec-work/#respond Wed, 24 May 2017 19:31:35 +0000 http://jorge.lab109.net/?p=146 Cualquiera puede ser víctima del Spec Work y, sin embargo, pocos son los que saben siquiera que existe. Quienes se inician en el sector de los videojuegos o del diseño gráfico están particularmente expuestos. Veamos en qué consiste.

Spec Work es «Trabajo Especulativo» (Speculative Work).
A grandes rasgos: «trabajar gratis».

Cuando alguien con poca (o ninguna) experiencia se postula para un puesto de trabajo es normal que la empresa contratante le someta a pruebas para comprobar sus capacidades. Lo que no es tan normal pero sí cada vez más frecuente es que entre esas pruebas haya Spec Work disfrazado de oportunidad de contratación. Por ejemplo, hay compañías que dicen requerir diseñadores de juegos y tienen preparada una tanda de preguntas de varias páginas que culmina en un ejercicio de redacción libre: Diseña un juego nuevo. El candidato se encuentra con que tras responder a una larga serie de preguntas más o menos complicadas, técnicas y opinables resulta que debe tener una idea original y atractiva, estructurarla, desarrollarla… y regalársela a una empresa que puede que le contrate y puede que no. Muchos son los llamados, pocos los elegidos. La mayoría de los candidatos nunca sabrá si esas ideas suyas son convertidas en juegos por alguna de las empresas que usan ese sistema. Sin embargo he visto con mis propios ojos cómo empresas sin escrúpulos abusaban de esa práctica, llegando a publicar juegos ideados y diseñados por candidatos que nunca fueron contratados.

Este es un ejemplo delicado. Alguien que busca un trabajo, y en particular si está empezando en el sector, suele estar deseoso de demostrar sus habilidades. Cuando llega a esa parte de la prueba de trabajo, ¿qué debe hacer? ¿Responder «contrátame y te diseño lo que quieras»? Eso podría cerrarle varias puertas, incluso si la empresa es seria y no canibaliza ideas de otros. ¿Debe entonces volcar toda su habilidad en
diseñar un juego «por la cara» sin garantía ninguna de ser contratado?
En un mundo ideal este problema no existiría.
Pero este no es un mundo ideal…

En el mundo del diseño gráfico los ejemplos son incluso peores, y lo cuento en primera persona. He ganado varios concursos de diseño, sobre todo de logos e imagen corporativa; pensándolo fríamente, no sólo no debería haber participado en esos concursos sino que no deberían haber existido para empezar.

El proceso es el siguiente: Una empresa necesita un logo nuevo, escribe un párrafo con lo que quiere transmitir con ese logo y organiza un concurso. Decenas o cientos de personas en todo el mundo dedican tiempo y esfuerzo para diseñar el logo. Comprueban resoluciones, escalados, combinaciones de color, patrones de impresión, impacto visual, de todo. Hacen sus diseños y los presentan al concurso. Algunas
personas con pocos escrúpulos plagian el trabajo de otros, bien copiando cosas de Internet, bien modificando lo que otros participantes presentan. Cuando el plazo del concurso termina, la empresa elige uno de los diseños y su autor recibe un premio. El resto de los participantes no reciben nada, ni un triste «gracias por participar». El premio no suele ser nada espectacular, a veces es una licencia de software, un portátil o una tarjeta gráfica. Cuando es dinero, suele ser escaso. Así que quien gana normalmente no ve recompensados sus esfuerzos. Pero quienes no ganan no obtienen ninguna recompensa y se han esforzado igual, o quizá incluso más que quien ganó.
Pero además la empresa también sale perdiendo y puede que esto no sea evidente al principio…

Por un lado, la empresa está dando unas guías generales a los concursantes, y los concursantes las interpretan libremente y a menudo sin contexto. Los diseños que presentan se basan en conocimientos superficiales de las necesidades de la empresa. Luego la empresa selecciona un diseño que les gusta y a veces descubren que ese diseño no es escalable, o no queda bien en impresión, o sus colores no encajan con el esquema de su web corporativa. O descubren que las formas o colores transmiten algún valor negativo o indeseado tiempo después de haber seleccionado el diseño ganador. Por ejemplo, el logo tiene un árbol que visto al revés parece un pene. Eso pasa.
Cuando una empresa contrata a un diseñador para hacer este tipo de trabajo, lo primero que hace el diseñador es preguntar mogollón de cosas. Preguntas sobre la empresa, el producto, el mercado, los clientes, la competencia, los valores de la empresa y el producto y lo que les distingue del resto. Con toda esa información el diseñador empieza a trabajar, aplicando lo que sabe a colores, formas, contrastes, lenguaje visual. El resultado es un «traje a medida» para el cliente, que además puede refinarse a base de comunicación entre el cliente y el diseñador.
Resumiendo: así es como debería hacerse.

El mensaje que transmiten al mundo las empresas que usan Spec Work es:

«El esfuerzo y el trabajo de otros no vale nada.»

Vamos a ponerlo de otra manera. Supongamos que vamos a varias cafeterías, les pedimos que nos sirvan sus mejores desayunos pero una vez probados todos seleccionamos el que más nos gusta y sólo pagamos por ese. El mundo no funciona así, ¿verdad? Pues tanto el sector de los videojuegos como el del diseño grafico tampoco deberían funcionar así, caramba.
Digo «caramba» por no decir algo más bruto y malsonante, pero igualmente apropiado.

Pero que conste que no estoy en contra de todos los concursos y competiciones del mundo. Creo que cosas como Ludum Dare, por poner un ejemplo fácil, ayudan tanto a los participantes (que desarrollan sus habilidades y reciben opiniones valiosas) como al sector (se descubren nuevos talentos, se exploran conceptos que proyectos comerciales no se arriesgan a explorar). Y nadie gana dinero a costa del trabajo de otros. Creo que eso es lo que mejor resume mi opinión sobre el Spec Work:

Que nadie trabaje gratis para que otros ganen dinero a su costa.

Para quienes tengan interés y sepan algo de inglés, ahí va un par de enlaces:
NO!SPEC
(Vídeo) Spec Work en fotografía

Dicho lo cual voy a descargarme Cubism 3. Me apetece probarlo y han organizado un concurso…

]]>
http://jorge.lab109.net/index.php/2017/05/24/que-es-spec-work/feed/ 0
El diseño, los jugadores y la diversión http://jorge.lab109.net/index.php/2015/07/14/el-diseno-los-jugadores-y-la-diversion/ http://jorge.lab109.net/index.php/2015/07/14/el-diseno-los-jugadores-y-la-diversion/#respond Tue, 14 Jul 2015 12:37:39 +0000 http://jorge.lab109.net/?p=99 Me han dicho muchas veces que pienso de una forma peculiar, más sintética que analítica, y eso no es habitual en una persona occidental. Me cuesta muy poco esfuerzo combinar varias ideas en una más completa o compleja, aún cuando no parecen tener relación entre sí.

En esta entrada voy a contaros tres teorías sobre el diseño de videojuegos; una vez explicadas os contaré cómo las combino para conseguir un resultado mejor que la suma de sus partes. Las tres provienen de experiencias y profesionales de habla inglesa, así que otra vez estaré adaptando más que traduciendo los puntos más conflictivos de estas ideas.

 

MDA

Estas tres letras se refieren a Mechanichs, Dynamics y Aesthetics. Traducir las dos primeras es fácil: Mecánicas y Dinámicas, con mayúsculas para que sepáis claramente cuándo me refierro a ellas. La tercera significa «estética» pero el significado que tiene en este contexto es: «Respuestas emocionales evocadas en el jugador». Así que voy a referirme a Respuestas al tratar de Aesthetics.

Las siglas MDA representan una aproximación formal a la comprensión y el diseño de los videojuegos. Se ha explicado varias veces en la GDC y su objetivo es analizar los juegos para unificar criterios tanto al diseñarlos como al valorarlos. La idea detrás de este proceso es que los diseñadores crean Mecánicas que se combinan entre sí y con las acciones del jugador formando Dinámicas, y estas Dinámicas crean Respuestas (emocionales) en el jugador. Según esto, la percepción del juego desde la perspectiva de los diseñadores es inversa a la que tienen los jugadores:

Los diseñadores definen las Mecánicas, observan las Dinámicas y esperan conseguir ciertas Respuestas. Los jugadores experimentan las Respuestas, pueden percibir las Dinámicas y quizá lleguen a deducir las Mecánicas. Atentos a esto, lo revisaremos más adelante al hablar de dominación.

Vistas con más detalle, las Mecánicas son las reglas formales del juego, definidas por los diseñadores. Las acciones que puede realizar el personaje del jugador, los comportamientos de la inteligencia artificial, la manera de acumular puntos o perder salud, las condiciones de victoria… Todo eso son Mecánicas.

Las Dinámicas son las diferentes maneras en que las distintas Mecánicas se combinan entre sí y también con las acciones del jugador. Por ejemplo, la Mecánica de control del jugador (WASD) y la Mecánica de persecución de la IA pueden ser impecables por separado, pero todos conocemos juegos en los que podemos dejar bloqueados a los monstruos en ciertas zonas de los mapas, si nos movemos de ciertas formas y nos colocamos en algunos lugares concretos. En este ejemplo, aunque las Mecánicas de fondo sean correctas la Dinámica resultante no lo es; para corregir un problema así, los diseñadores tendrían que modificar las Mecánicas, incluyendo excepciones o casos adicionales, o modificando los niveles.

Las Respuestas son las emociones que experimenta el jugador: la frustración, la satisfacción, la sensación de descubrir cosas nuevas… Idealmente las Respuestas son lo que hace que el juego sea divertido, disfrutable. Y como las Respuestas dependen de las Dinámicas, si los diseñadores quieren cambiar las Respuestas que consigue el juego su único medio es modificar las Mecánicas y observar su impacto en las Dinámicas…

Al describir las Respuestas que provoca un juego, la teoría MDA intenta alejarse de términos generales como «divertido» o «interesante» y propone un vocabulario específico para definir las diferentes formas de diversión. Concretamente las siguientes:

Sensación (Sensation): El juego como un placer para los sentidos. La belleza de los gráficos o la música, la fluidez de los controles… Cabe destacar que este punto no se ciñe a que el juego sea «bonito». Por ejemplo, las pinturas negras de Goya pueden no ser «bonitas» en el mismo sentido que las pinturas de Sorolla, pero ambas tienen un sentido de belleza artística que encaja bien en esta categoría.

Fantasía (Fantasy): El juego como un mundo imaginario en el que escapar del mundo real. Esto suele complementarse poniendo al jugador en el papel del héroe que salva al mundo o el villano que lo conquista, o bien mediante entornos sandbox que ofrecen al jugador libertades que no tiene en su vida cotidiana.

Narrativa (Narrative): El juego como una historia de la que el jugador es protagonista o al menos una pieza clave. Las «películas interactivas» y las tramas con diferentes finales basados en las decisiones que toma el jugador durante el juego encajan en este tipo de diversión

Reto (Challenge): El juego como un desafío que hay que superar. Puede consistir en «pasarse el juego» o en derrotar a un villano, o también en ser el líder de las tablas de puntuación.

Compañerismo (Fellowship): El juego como un entorno social en el que establecer relaciones. Esto no sólo se aplica a juegos online sino que también pueden darse casos en los que el jugador desarrolle sentimientos hacia algunos NPCs, como por ejemplo sentido de la responsabilidad y de protección.

Descubrimiento (Discovery): El juego como un mundo desconocido, sin cartografiar, cuyos secretos hay que descubrir y desentrañar. Se puede aplicar también a juegos en los que hay que combinar objetos entre sí para conseguir otros y seguir avanzando, o juegos cuyas Dinámicas no son evidentes pero la intención de los diseñadores es que los jugadores las descubran.

Expresión (Expression): El juego como un medio de autodescubrimiento, de comunicación y de creación por parte de los jugadores. Esto abarca desde la creación de avatares en MMOs hasta entornos abiertos que permitan a los jugadores crear sus propias experiencias de juego (¿os suena Minecraft?).

Sumisión (Submission): El juego como un hábito, un hobby, una afición que impone sus propias costumbres, en vez de como un suceso ocasional y aislado. El jugador «se somete al juego», lo antepone a otras cosas. Como reservar un día a la semana para jugar y hacer actividades de clan, por ejemplo.

Estas ocho «formas de diversión» no son excluyentes, ni son definitivas. Con el tiempo se han propuesto otras formas, o puntualizaciones sobre estas, pero las que os he mostrado son las ocho originales. Sobre el ser excluyentes, veamos un par de ejemplos:

Minecraft: Descubrimiento + Expresión + Fantasía; algunos jugadores añadirán Sumisión y otros Sensación, si los gráficos o las construcciones les gustan particularmente.
Mass Effect: Narrativa + Fantasía + Descubrimiento + Reto; algunos jugadores añadirán Compañerismo (los NPCs están muy logrados y las relaciones con ellos son complejas), mientras que otros jugadores añadirán Sumisión y Expresión.

Como podéis observar, este sistema puede ayudar a los críticos de videojuegos y medios relacionados con este sector a explicar cómo es un juego y qué valores aporta (o de cuáles carece). También puede ayudar a los diseñadores de juegos, sobre todo al marcarse objetivos de diseño: ¿Qué debe conseguir este juego? ¿Por qué es «divertido»?

Curiosamente, el humor no está incluido en los ocho tipos «clásicos» de diversión…

 

Los cuatro tipos de jugadores

Ya que hemos visto lo que de forma ortodoxa se considera «diversión», veamos ahora los cuatro tipos o clases de jugadores según el test de Bartle. Para quienes no lo sepan, Richard Bartle fue uno de los (dos) desarrolladores del abuelo de todos los MMOs: el primer MUD. Bartle se percató de que los jugadores se comportaban de maneras diferentes pero, a grandes rasgos, todos pertenecían a un determinado perfil más que a los otros tres que difinió, y publicó esta información en 1996. En base a esto, Erwin Andreasen y Brandon Downey crearon el test, formulando una serie de preguntas y en base a las respuestas de los jugadores era posible identificarlos como pertenecientes a uno u otro tipo, si bien es más prudente la clasificación compuesta que distribuye 200 puntos entre las cuatro clases.

Aunque esta clasificación está pensada desde la perspectiva de juegos online es fácilmente aplicable a juegos para un solo jugador. En cualquier caso vale la pena conocerla y saber aplicarla.

Para definir los cuatro tipos de jugadores primero se definen dos ejes, uno vertical y otro horizontal. En el horizontal (x) se establece una escala cuyos extremos son  «otros jugadores» y «el mundo de juego». En el eje vertical (y) la escala va desde «acción unilateral» hasta «interacción». Estos ejes quedarían así:

bartle_1

Lo siguiente es rellenar los cuatro cuadrantes según la combinación de atributos de los ejes, definiendo en el proceso los cuatro perfiles de jugadores:

Asesinos (acción unilateral + otros jugadores): Les encanta competir con otros jugadores y prefieren entornos PvP a luchar contra la inteligencia artificial.

Triunfadores (acción unilateral + el mundo de juego): También llamados «coleccionistas de logros» (achievers), su motivación es superar los objetivos marcados por el juego, acumular experiencia, títulos, dinero y el mejor equipamiento.

Socializadores (interacción + otros jugadores): Además de para jugar, usan el juego como una herramienta social. Conversan con otros jugadores, interpretan papeles (roleplay) y las relaciones que mantienen con sus compañeros de juego son lo que les impulsa a seguir jugando.

Exploradores (interacción + el mundo de juego): Su motivación es descubrir los entornos y las mecánicas del juego, averiguar cómo funciona todo y llegar donde ningún jugador ha llegado antes.

El resultado es el siguiente:

bartle

Además se suele identificar cada tipo de jugador con uno de los palos de la baraja francesa (picas, diamantes, corazones y tréboles), según el documento original de Bartle. Antes había varias versiones online del test, por ejemplo en gamerdna, pero no consigo que el enlace me funcione. Sí conozco una versión del test para dispositivos iOS, que además es gratis pero está en inglés. Quizá debería hacer mi propia versión en español, aún tengo las preguntas originales por algún lado…

Bueno, el caso es que una vez respondidas las preguntas del test se obtiene un perfil en porcentajes en el que la suma de los cuatro campos es 200%. Mi perfil, para que tengáis un ejemplo, es el siguiente:

80% Explorador
67% Triunfador
40% Socializador
13% Asesino

Un perfil basado en este test se suele resumir mencionando los dos campos más relevantes, en mi caso sería Explorador-Triunfador. Sin embargo yo prefiero tener toda la información; ese 40% de Socializador es también información relevante, vaya, y el 13% de Asesino también puede merecer una explicación y algo de atención. En cualquier caso, todos los sistemas de clasificación de los jugadores que han aparecido después se han basado en este, el clásico, el original, el primero.

 

Dominación

Normalmente decimos que una persona «domina» algo cuando lo controla, cuando se le da excepcionalmente bien. Tengo entendido que hay un tal Marc Márquez que domina la conducción de motocicletas a alta velocidad, ¿correcto?

En ocasiones los diseñadores de juegos nos podemos obcecar con el control: lo que puede y no puede hacer el jugador, lo que debe ocurrir en un momento dado. Pero ojo, a los jugadores les sucede esto mismo: conseguir el mejor equipamiento y armas, derrotar a todos los enemigos, liderar las tablas de puntuación…

Visto fríamente, podría ser una batalla por el control del juego. El diseñador quiere que el juego funcione como lo ha previsto, y que el jugador no haga cosas inesperadas y «rompa» su juego. El jugador quiere salirse con la suya, ganar, conseguir objetos y botín, hacer lo que él quiera porque al fin y al cabo es su juego. En un sentido y en el otro, cada uno tiene que «dominar su juego».

Así que, antes de empezar a diseñar o jugar un juego nuevo, preguntémonos por un momento: «¿De quién y para quién es el juego?». Es una pregunta con trampa, claro está. Salvo que el diseñador tenga un ego del tamaño del Everest, se dará cuenta de que hay que satisfacer a los jugadores. Y el jugador también sabrá que ese juego en concreto no lo han diseñado pensando específicamente en él (o ella).

La trampa de esta pregunta y la conclusión de los puntos anteriores es que hay que diseñar el juego con un «jugador objetivo» (target) en mente desde el primer momento, y que a los jugadores que no se correspondan con ese target puede que el juego no les guste tanto, ni se diviertan igual. Parece evidente, pero no siempre lo es.

Particularmente en los juegos independientes que se hacen últimamente es habitual que el diseñador no se pare a pensar en esto y diseñe el juego que a él (o ella) le gustaría jugar. Y esto sin plantearse qué tipo de jugador es el diseñador mismo ni qué elementos debe incluir para que el juego le resulte divertido. Por eso hay muchos juegos independientes o desarrollados por estudios pequeños que, simplemente, no son divertidos. No tienen mercado, no satisfacen a un grupo de jugadores, ni a otro, ni a otro…

Dejo para otro momento las implicaciones que el esquema y tipo de juego inherentes a la dominación (por parte del jugador) tienen en el modelo de diseño «composition vs. execution«, que es un tema que requeriría un post entero.

 

La síntesis

Empecé esta entrada explicando que pienso de forma sintética, y es el momento de juntar las cosas que os he ido contando, teorías e ideas, en un todo coherente que creo que es mejor que la suma de sus partes. Si también os parece lógico y coherente es que lo estoy haciendo bien ;)

Lo primero que tiene que hacer el diseñador es entender qué tipo de jugador es. A todos nos cuesta menos diseñar cosas que nos gustan, y a menudo es fácil contaminar Mecánicas con preferencias personales que no les corresponden, así que hay que estar alerta y conocerse a uno mismo.

Lo segundo es entender a qué tipo de jugador está destinado el juego, cuál es su perfil y sus preferencias. De esta manera el diseñador podrá fijarse objetivos, empezando por las Respuestas que el juego debe provocar en los jugadores del tipo objetivo.

Lo tercero es añadir características específicas, además de las Mecánicas, que encajen con el perfil del jugador objetivo. Os pongo algunos ejemplos:

– Los jugadores del tipo Asesino son ambiciosos y a menudo impacientes. Usad tablas de puntuación, clasificaciones, un número de ranking que puedan ver en su ficha personal y que puedan mostrar a otros jugadores.
– Los jugadores del tipo Triunfador disfrutarán si reconocéis sus avances con un sistema de títulos o logros. Si pueden seleccionar uno de estos títulos para mostrarlo junto a su nombre también podemos apelar a su vanidad.
– Los jugadores del tipo Socializador necesitan poder comunicarse con otros jugadores; para ellos las listas de amigos, los canales de chat y los mensajes dentro del juego no son opcionales, sino obligatorios.
– Los jugadores del tipo Explorador disfrutan con entornos amplios y con zonas recónditas, pasajes secretos y enigmas lógicos que les permitan llegar donde otros no han llegado. Recompensar estas hazañas con tesoros y acceso a información no disponible de otro modo (los diarios de algún NPC, por ejemplo) es una buena opción.

Insisto en un detalle: Es mejor considerar estas características específicas como algo adicional a las Mecánicas. Son como una póliza de seguro sobre la satisfacción mínima del jugador objetivo, pero a pesar de ellas hay que seguir diseñando e integrando Mecánicas coherentes orientadas al tipo de jugador que queremos que disfrute con nuestro juego.

En cuarto lugar, hay que aplicar la importancia de la relación Mecánicas/tipo de jugador al proceso de diseño y desarrollo. Os voy a poner mi propio perfil de ejemplo; supongamos que estamos haciendo un juego orientado (principalmente) a jugadores con mi perfil:

80% Explorador
67% Triunfador
40% Socializador
13% Asesino

Por esto, lo primero y más importante es definir las características y Mecánicas del juego que han de satisfacer a ese 80% de Explorador: mapas grandes, zonas secretas, puzles lógicos, sistemas de transporte (vehículos, monturas, teletransporte, lo que sea). Una vez definida la parte orientada a los Exploradores, vemos cómo integrarla con el siguiente perfil: 67% de Triunfador. Por recorrer cada mapa el jugador obtiene un logro y su correspondiente título; por recorrer todos los mapas de una región, un logro superior y otro título. Por recorrer todos los mapas, el logro máximo y un título legendario. Lo mismo para las zonas secretas, los puzles y demás actividades del juego… pero primero definimos las relacionadas con el perfil de Explorador.

Para el perfil de Socializador añadimos chat, mensajes, listas de amigos… y un sistema automático que notifique a nuestros amigos que hemos conseguido un logro; de esta forma enlazamos Socializador+Triunfador+Explorador. Lo rematamos con un perfil público del jugador en la web del juego, que además podremos aprovechar para satisfacer el componente asociado al perfil de Asesino.

Para la parte competitiva propia del Asesino (13%) añadimos un sistema de duelos y arenas aleatorias; como el objetivo es sólo un 13%, con poner un par de modos tanto en arenas en solitario como en arenas por equipos debería bastar. Enlazamos esto con tablas de puntuación en el juego y en la web del mismo, un botón para enviar un tweet con las puntuaciones que queramos compartir y un apatado específico para el PvP en el perfil de jugador que comenté en la parte del Socializador.

Definimos estos elementos, apuntamos cada uno en una tarjeta y los reservamos. Según vayamos diseñando el juego, la historia, la trama y las Mecánicas, vamos revisando las tarjetas e insertándolas en el diseño. Y al implementar las características y Mecánicas de las tarjetas, su prioridad inicial se corresponde con el porcentaje de relevancia del perfil al que corresponden, modificándolo con la relevancia que tengan en el juego y las dependencias que tengan o generen. De esta forma, si hay que eliminar o modificar estas «features» o Mecánicas es más fácil priorizar el trabajo y anticipar el resultado de los cambios.
¡Y esto siempre ayuda a mejorar la calidad del desarollo!

En fin, creo que con ejemplo y todo algo bueno queda aquí. Espero que os haya gustado ;)

]]>
http://jorge.lab109.net/index.php/2015/07/14/el-diseno-los-jugadores-y-la-diversion/feed/ 0
PBR – ¿Qué es? http://jorge.lab109.net/index.php/2015/07/12/pbr-que-es/ http://jorge.lab109.net/index.php/2015/07/12/pbr-que-es/#comments Sun, 12 Jul 2015 00:56:22 +0000 http://jorge.lab109.net/?p=80 En las décadas de 1960 y 70 en el mundo del arte (sobre todo en pintura) había, entre otras, dos tendencias opuestas: el minimalismo y el fotorrealismo.

Desde hace unos años ambos estilos han vuelto con fuerza, especialmente en los videojuegos. Aunque el minimalismo suele atribuirse a juegos para iOS o Mac y el fotorrealismo se ve más en juegos de consolas modernas y PC, lo cierto es que hay muchos ejemplos de ambas tendencias en todas las plataformas.

El principal problema del «fotorrealismo clásico» en los videojuegos consiste en que, básicamente, es hacer trampa. Lo importante es que el resultado final «parezca de verdad» y las técnicas empleadas para conseguirlo pasan a un discreto segundo plano. A menudo las luces usadas en las escenas fotorrealistas de hace unos años tienen valores que no tienen nada que ver con las luces reales, y los materiales se comportan de forma (técnicamente) poco realista para conseguir engañar a los ojos del jugador. En general, un escenario fotorrealista hecho de esta manera sólo funciona con la configuración de luces y materiales específica para esa ocasión, y esto es un problema porque no puede haber cambios dinámicos ni se puede reutilizar un escenario o un material si cambia la hora del día o la cantidad de luz del entorno.

El PBR (Physically Based Rendering) es una técnica pensada para eliminar este problema, ofreciendo resultados realistas en base a las propiedades físicas de los materiales y de la luz. Gracias a los materiales definidos mediante PBR es posible tener cambios dinámicos de iluminación y que los materiales se muestren tal y como lo deben, sin tener que reconfigurarlos, sin hacer trampas. Para quienes llevamos años haciendo videojuegos, los materiales PBR suponen un tremendo cambio de paradigma; venimos acostumbrados a componer materiales en base a los canales difuso, especular y desplazamiento y en el modelo PBR hay más canales y resulta que son diferentes. No sólo eso, sino que hay dos configuraciones básicas y diferentes de PBR, una basada en el componente metálico y otra en el especular.

Para quienes ya saben algo sobre materiales, leer esto puede ser muy interesante y sobre todo al estar en español; para quienes no saben mucho (o nada) del asunto puede ser un galimatías confuso, así que voy a exponer un poco del vocabulario del curso que estoy preparando sobre PBR.
Espero que os guste y os ayude a entender un poco mejor esta técnica

 

Reflectividad

Los conceptos de reflectividad y reflectancia derivan de «reflejar» y causan un conflicto bastante serio con la documentación técnica en inglés. Hay traducciones que intercambian los nombres y los significados, así que por puro sentido práctico voy a seguir el estándar inglés; todas las aplicaciones y motores de juegos que usan PBR están en inglés y es más fácil entenderlos si nos ceñimos a ellos, incluso si las traducciones fueran más correctas cambiando los términos.

La reflectancia (reflectance) de una superficie es su eficacia para reflejar la luz que incide sobre ella. Es una propiedad direccional (el reflejo de la luz depende del ángulo en el que incida sobre la superficie) y su valor se representa siempre mediante un número real positivo. Para nuestros propósitos consideraremos que la reflectividad (reflectivity) es el valor límite de reflectancia sobre superficies gruesas. Parece un poco lioso, así que voy a poneros un dibujo:

luz_superficie

Supongamos que las flechas representan rayos de luz que inciden sobre un material grueso. Ese material refleja la luz, pero no la refleja de manera perfecta; si lo hiciera, todos los rayos rebotarían en su superficie, pero no es así. El valor de la reflectividad de este material indica cuánta luz rebota en su superficie, y la reflectancia indica cómo de brillante es ese reflejo. Pero lo realmente importante viene a continuación.

Los rayos de luz pintados en verde en este dibujo representan la luz reflejada, que tradicionalmente se considera «especular» (de «espejo»). Los rayos naranjas penetran en el material y algunos de ellos salen de él, modificados o «contaminados». Básicamente, el valor de reflectividad determina la cantidad de reflexión y de difusión del material en cuestión…

 

Difusión y Reflexión

En la imagen anterior, los rayos verdes representan la luz reflejada, la reflexión. Los rayos naranjas, que penetran en el material pero vuelven a salir representan la difusión. En el modelo PBR ambas son mutuamente excluyentes, por el principio de conservación de energía: la luz reflejada en un objeto (de una forma u otra) no puede ser más intensa que la luz que recibe originalmente. Así que si un objeto tiene mucho brillo difuso no puede tener mucho brillo especular. Para quienes vengáis con costumbres de modelar en 3D: el difuso es Lambert y el especular es Blinn. Por si acaso y para todos, otra imagen de ejemplo:

difusion-reflexion

La esfera de la izquierda tiene más componente difuso que las de su derecha; la esfera de la derecha tiene más componente especular que las de su izquierda. Cuando la reflexión aumenta, la difusión baja. Cuando la difusión aumenta, la reflexión baja.
Eso es la conservación de la energía: todas brillan igual, pero de maneras diferentes.

 

Conductores y Aislantes

Las propiedades físicas de los materiales que conducen la electricidad (principalmente los metales) y los que no la conducen suelen reflejarse en su apariencia. De hecho el modelo PBR más utilizado se basa en las propiedades metálicas de las superficies y se llama «metallic«.

Por norma general los materiales conductores suelen tener más reflectividad que los aislantes, por lo es normal que exhiban más reflexión que difusión; los metales pulidos no muestran difusión en absoluto. La reflectividad de los metales suele estar entre el 60 y el 90% de la luz que reciben, mientras que la de los aislantes raramente excede el 25%. Además hay algunos materiales conductores como el oro y el cobre que tiñen la luz que reflejan con su propio color, mientras que los materiales aislantes no suelen hacerlo y la luz que reflejan es del mismo color que la original.

Como un objeto puede estar compuesto por diferentes materiales se suele usar una textura especial que defina qué tipo de superficie corresponde a cada zona, y ese «mapa metálico» especifica el comportamiento de cada texel de la superficie del objeto. La información del material base del objeto se combina con la información de rugosidad del material para conseguir brillos realistas y coherentes.

 

Rugosidad

Si observamos una plancha de metal o una tabla de madera, la superficie es plana pero generalmente no es lisa: tiene poros, imperfecciones, estrías y arañazos. Estas características suelen ser propias del material del objeto y las percibimos con claridad porque la luz rebota en ellas de manera diferente, según su orientación:

rugosidad

Al definir un material PBR podemos incluir esta información de las «microsuperficies» de un objeto a través de imágenes, como un mapa de rugosidad, de brillos o de suavidad, que suelen identificarse con los nombres «roughness«, «glossiness» y «smoothness«. El resultado de aplicar la rugosidad del material es que los brillos se difuminan o se adaptan a esta rugosidad, consiguiendo un resultado más realista que con las técnicas tradicionales.

Aunque en la generación de materiales PBR no es extraño usar dos imágenes (metallic + roughness) es habitual que los motores de juegos sólo usen una imagen para definir la rugosidad o el tipo de material y un valor de suavidad de la superficie, que se aplica a todo el material. Por ejemplo, Unity usa una imagen (metallic) y un valor de cero a uno (smoothness), y el resultado es tan bueno como bien definido esté el material.

 

Bueno, creo que es bastante información, sobre todo para abrir boca. Os pondré un enlace cuando publique el curso, que será mucho más práctico que esta «introducción»  ;)

]]>
http://jorge.lab109.net/index.php/2015/07/12/pbr-que-es/feed/ 3
Diseño y Diseñadores http://jorge.lab109.net/index.php/2015/07/11/diseno-y-disenadores/ http://jorge.lab109.net/index.php/2015/07/11/diseno-y-disenadores/#respond Fri, 10 Jul 2015 22:36:46 +0000 http://jorge.lab109.net/?p=63 Al principio de los tiempos sólo había programadores. Luego llegaron los artistas, dibujando portadas y haciendo sprites e imágenes de fondo. Y luego todo empezó a complicarse…

Los ordenadores se hicieron más potentes y los juegos más complejos. Ya no bastaba que el protagonista fuera un cuadrado rojo que disparase rayos blancos a cuadrados amarillos. O que el juego consistiera en pegar y recibir tiros hasta el inevitable final. La evolución de los ordenadores aumentó el nivel de exigencia de los jugadores, y no sólo en el apartado gráfico. Los jugadores de rol y de wargames de mesa empezaban a pedir videojuegos más sofisticados y los equipos de desarrollo crecieron. Los juegos necesitaban más y mejores gráficos, pues se contrataba a más artistas. Los juegos eran más complejos, se contrataba a más programadores. Y en el proceso se definió una nueva categoría de desarrollador: los diseñadores de juegos.

El primer y más grave error que comete la gente que no sabe cómo se hacen los juegos consiste en pensar que un diseñador de juegos es como un diseñador gráfico. Hay diseñadores gráficos muy buenos en su campo, pero no tienen por qué ser buenos diseñando videojuegos (y al revés). Los diseñadores gráficos hacen dibujos, fotos, composiciones, iconos, logotipos… Todo lo que necesita una página web, y más. Sus herramientas suelen ser Photoshop/GIMP o Illustrator/Inkscape, por ejemplo.

En general los diseñadores de videojuegos tienen que definir ambientaciones, personajes, diálogos, entornos, historias, acciones, objetivos, reglas y limitaciones. También tienen que editar niveles, colocando correctamente los objetos importantes para que el juego funcione; a veces incluso tienen que programar la interactividad de estos objetos. En muchas ocasiones los diseñadores tienen que explicar cómo funciona la interfaz del juego, qué información se ofrece al jugador y de qué manera.
Y en según qué estudios, puede que aún más cosas que estas.

Como diseñador yo he tenido que hacer esas cosas, pero raras veces las he hecho todas a la vez. En los estudios más grandes hay diseñadores especializados en cada una de estas tareas y estructurados en una jerarquía según su experiencia y habilidad. Según se dediquen a una u otra cosa, los diseñadores usarán más unas herramientas que otras: excel, procesadores de texto, mind maps o editores de niveles. Voy a hacer un resumen de los diferentes tipos de diseñadores, en base a mi experiencia; no es una lista completa y los nombres y tareas serán diferentes de estudio en estudio, pero al menos os haréis una idea.

 

Lead Designer/Lead Game Designer

Es el jefe (o la jefa) del equipo de diseñadores, quien tiene que comunicarse con los departamentos de arte, programación, sonido, recursos humanos y demás. Es una persona capaz y experimentada, que ha desarrollado varios juegos de cabo a rabo, y es habitual que tenga experiencia previa en programación, arte o producción. No es la autoridad definitiva en qué características se incluyen o descartan en un juego; ese rol suele ser el del productor, jefe de proyecto o product manager, que a veces viene dado por otra empresa, como puede ser un publisher o un responsable de marca cuando se trabaja con IPs de terceros.

Sí es responsable de unificar todo el trabajo de diseño, desde los diálogos hasta los niveles del juego, en un todo coherente. También suele estar a cargo de la formación de diseñadores novatos y de becarios. La principal tarea del Lead Designer es apagar fuegos: ayudar donde haga falta, corregir errores, mejorar resultados y contenidos, y conseguir que se cumplan las fechas de la planificación. Para lograrlo, además de saber bastante de cada apartado del diseño, tiene que poder comunicarse de una forma eficaz y clara.
La principal herramienta del Lead Designer es la palabra, hablada y escrita.

 

Content Designer – Diseñador de Contenido

Esta es una categoría bastante genérica y sé de estudios que la fraccionan en varias. Incluye a quienes escriben la historia del juego, los diálogos, las misiones y las descripciones, y también a quienes definen los objetos, sus atributos y sus usos.

Es habitual que trabajen con procesadores de textos, tablas y mind maps, como también es frecuente que editen archivos XML y usen las herramientas del motor para incorporar su trabajo al juego.

 

System Designer – Diseñador de Sistemas

En proyectos realmente grandes hay personas que se encargan de sistemas diferentes, y podemos encontrar (por ejemplo) a un Diseñador de Sistemas de Combate, un Diseñador de Sistemas de Comercio y así sucesivamente. En general los diseñadores de sistemas son buenos tanto con las palabras como con los números y definen los conjuntos de reglas que gobiernan el juego, equilibrando valores y atributos para que la experiencia de juego sea óptima. Tras muchas pruebas y sesiones de control de calidad (QA) es habitual que ajusten parámetros una y otra vez, añadan casos excepcionales a las reglas o definan nuevas relaciones entre los elementos que han de controlar.

Los diseñadores de sistemas suelen usar procesadores de texto, tablas y muchos, muchos mind maps con numerosas anotaciones y relaciones. A veces también usan bases de datos y gráficas circulares, sobre todo durante las pruebas beta para analizar el funcionamiento de los sistemas que han diseñado y descubrir posibles fallos o abusos.

 

Level Designer – Diseñador de Niveles

El diseñador de niveles toma los requisitos de un entorno de juego y los convierte en un nivel funcional y jugable. Esos requisitos están plasmados en «la biblia del juego», su documento de diseño, y no siempre incluyen un boceto de mapa sobre cómo debería ser cada zona. A veces el diseñador de niveles recibe unas indicaciones por escrito, por ejemplo:

El nivel es el patio cerrado de una fortaleza en ruinas. El jugador entra en el nivel por una puerta gigante que se cierra tras él. Hay varios monstruos poco poderosos y un jefe muy fuerte que custodia la salida. Hay dos cofres con tesoros y varias trampas de pinchos. La salida está cerrada con una llave que tiene el jefe del nivel, hay que derrotarle para pasar al siguiente…

He visto documentos de diseño tan detallados que explican incluso cuánto y por dónde crece el musgo sobre las rocas, y también he visto otros en los que el nivel de detalle era inferior al del ejemplo sobre estas líneas. En cualquier caso, el diseñador de niveles recibe esta información, pregunta al Lead Designer cualquier duda y planifica cómo será el nivel. Solicita modelos y texturas al departamento de arte (a través del Lead Designer) y crea un nivel de prueba con modelos básicos, normalmente primitivas con colores planos. Si las entidades que requiere el nivel ya están implementadas, las incorpora y ajusta sus atributos para probar la jugabilidad del nivel. Cuando recibe los modelos y texturas necesarios, sustituye los modelos básicos por los definitivos, ajusta la iluminación y somete el nivel a aprobación.

Hay diseñadores de niveles que se especializan en entornos PvE y otros en PvP. Es habitual que los especialistas en creación de niveles para PvE desarrollen o posean habilidades de programación, como mínimo las suficientes para crear y gestionar la aparición de monstruos (spawning), los triggers y las intercciones con NPCs. También suelen percibir los niveles de forma lineal o como un árbol de nodos: «El jugador puede realizar tales acciones en este sitio y tales otras en este otro«. Los diseñadores de niveles que se especializan en PvP suelen percibir los niveles de manera concurrente: «Si el jugador se coloca en esta posición puede atacar a las zonas A y B pero puede ser atacado desde las zonas C y D, así que necesita que le cubran desde la zona D o un compañero que se coloque en la zona C…»
El diseñador de niveles para PvP tiene que mantener el equilibrio entre las zonas de despliegue de los jugadores o equipos enemigos, de forma que no haya un punto inexpugnable desde el que dominar la partida, entre otras cosas.

Además, el diseño de niveles puede variar mucho en base a requisitos de percepción y visibilidad; si el juego es en primera o en tercera persona el diseño del nivel tiene que ocluir o tapar las zonas que no interesa que el jugador vea, o desde las que pueda ser visto.

La herramienta principal del diseñador de niveles es el mismo editor de niveles del motor de juego. A menudo tiene que saber también manejar mind maps con soltura, y con menor frecuencia tiene que poder lidiar con generadores de terrenos como World Machine o herramientas como SpeedTree.

 

Sé que hay estudios con diseñadores de interfaces, directores de diseño e incluso diseñadores técnicos, pero estos roles han sido cubiertos por los que os he contado en los estudios en los que he trabajado. En general todos los diseñadores tienen una base común: buena capacidad de comunicación, soltura con las matemáticas, amplios conocimientos generales de historia y arte, facilidad para trabajar en equipo y capacidad para analizar y sintetizar conjuntos complejos de información.

¡Ser diseñador de juegos es un trabajo duro, pero alguien tiene que hacerlo!

]]>
http://jorge.lab109.net/index.php/2015/07/11/diseno-y-disenadores/feed/ 0
Más sabe el diablo por viejo… http://jorge.lab109.net/index.php/2015/07/10/mas-sabe-el-diablo-por-viejo/ http://jorge.lab109.net/index.php/2015/07/10/mas-sabe-el-diablo-por-viejo/#respond Fri, 10 Jul 2015 14:14:18 +0000 http://jorge.lab109.net/?p=47 Dice el refrán que el saber viene con la edad, a través de la experiencia. A lo largo de los años que llevo haciendo videojuegos he tenido que lidiar con bastantes motores y en esta entrada voy a comentaros algunas de mis experiencias y opiniones sobre varios de ellos.

Bueno, no me voy a remontar a los tiempos de cintas y cartuchos, no creo que eso sirviera de mucho y tampoco estaríamos hablando de «motores» tal y como los entendemos actualmente. Sin embargo es cierto que han pasado unos cuantos años desde que trabajé en serio con Vision Engine, Source, C4 o Multiverse. Por ejemplo, la compañía que desarrollaba Multiverse cerró y el motor es ahora open source, Havok compró Trinigy y ahora son los propietarios de Vision Engine, y no se puede comprar una licencia de C4 en el momento en el que estoy escribiendo esto (creo que es algo temporal, es un motor excelente).

Source es el motor de Valve y con él se han hecho Half-Life, Left 4 Dead, Portal y DOTA 2. Es muy modular, con las ventajas e inconvenientes que eso conlleva. La versión con la que trabajé tenía el código plagado de comentarios tipo «//hack, do NOT touch this«, lo que significa que había cosas metidas con calzador y sujetas con pinzas. No era estable, fallaba de formas caprichosas y costaba un ojo de la cara. Para rematar la faena estaba pensado para hacer juegos en primera persona y el nuestro era en tercera. Un auténtico Cristo de los Dolores. El jefe del estudio quería usar Source por la publicidad que le daría al proyecto usar un motor conocido, famoso. Me costó mucho convencerle para que cambiásemos de motor, pero cuando lo conseguí el desarrollo mejoró mucho. Como pasar de la noche al día. Cambiamos Source por C4, en cuyo código no había trampa ni cartón, era muy estable y potente, tenía un modelo de iluminación extraordinario y materiales modernos con parallax mapping y todo. Y si os fijáis en la web de C4, veréis que el tipo que ha diseñado ese motor es toda una eminencia en la programación de gráficos, 3D, iluminación y materiales. Sin embargo, para aprovechar un código tan bueno hay que estar a la altura; cualquier modificación del código fuente del motor requiere un nivel excelente en programación, y es C++. Así que por estupendo que sea el motor tampoco es para todos los públicos. Eso sí, si queréis un ejemplo de buenas prácticas y programación eficiente en C++, echad un vistazo al código de C4.

Años después el modelo de negocio de Source cambió, añadieron nuevas versiones de las herramientas del motor (más modernas y estables) y actualmente podéis usar la versión más moderna de Source para hacer vuestros juegos. Ha mejorado mucho, la verdad, y hay mogollón de ejemplos en Internet. No os olvidéis de que Valve es propietaria de Steam: usar su motor puede ayudaros a publicar en su plataforma.

Sobre Trinigy’s Vision Engine lo que puedo contar son historias de terror. Hace ya unos años que Havok se hizo cargo de este motor, así que las versiones más modernas son mucho mejores que la que tuve que usar yo, que conste. El proyecto que usaba Vision consistía en mostrar un monasterio medieval de tres formas distintas: con una «visita virtual interactiva», en un vuelo controlado de la cámara mostrando los detalles más importantes, y en un modo «caza del tesoro». Como podéis ver no era precisamente un videojuego; años después se empezó a llamar «Serious Games» a este tipo de aplicaciones que usan tecnologías de los videojuegos, pero esa es otra historia…

El caso es que el monasterio en cuestión era real y lo habían escaneado con laser para generar un modelo 3D con una brutalidad de detalle. Los artistas se pasaron meses limpiando la geometría escaneada, generando texturas y materiales, sudando tinta china. Cuando su parte estuvo lista le tocó el turno a los programadores; la teoría era sencilla: crear un nivel de juego con el monasterio escaneado, poner «hot spots» en las zonas de interés y que cuando el jugador/visitante apuntase a esos puntos aparecieran ventanitas con fotos e información de cada cosa. Además estaba el modo de vuelo controlado, en el que la cámara seguiría un camino definido por waypoints, y ahí empezó la broma. Al empezar a desarrollar este modo, cuando cargábamos el nivel con la cámara que iba a ir volando, el mundo salía al revés. Parecía que estuviera rotado 180º, con el suelo arriba y el cielo abajo, pero no. Resulta que el mundo estaba invertido en el eje vertical y en un eje horizontal. O sea, escalado a -1 en dos ejes. Como el nivel era básicamente el modelo escaneado en 3D podía ser un problema del modelo o sus transformaciones, o bien un problema de la cámara. Pero aparentemente (y según el mismo Vision Engine) todo era correcto. Y eso es un problema de los gordos, aunque bastante común. Cuando todo es correcto y no hay ningún error pero el resultado es diferente de lo esperado hay que encontrar la lógica del problema, y nunca es evidente. En este caso podíamos modificar la posición y rotación de la cámara, transformar el modelo, cambiar los atributos del nivel… La solución más sencilla fue modificar la matriz de proyección de la cámara. En realidad el mundo estaba al revés (en tiempo de ejecución) pero la cámara lo mostraba del derecho, así que arreando.

El siguiente problema apareció cuando quisimos hacer que la cámara volase de un punto a otro, siguiendo una lista de puntos de ruta sin saltos bruscos, pero que además la cámara apuntase a ciertas zonas en el proceso. La primera opción sería hacer una lista de estructuras de datos que almacenasen las posiciones y orientaciones de la cámara. Lógico, coherente. No funcionó, la cámara no se orientaba correctamente hacia donde debía. Con el tiempo muy justo para entregar el proyecto, en vez de pelearnos con ese sistema lo que hicimos fue crear dos rutas: una para las posiciones de la cámara y otra para un objeto invisible (un «dummy» o «helper«) al que la cámara debía apuntar en todo momento. Así que en vez de pelearnos por programación para resolver el problema, hicimos un sistema más sencillo y ajustamos en el editor de niveles las posiciones de los waypoints de la cámara y su invisible objetivo. Desde la perspectiva de un programador no fue lo más elegante, pero sí lo más sencillo, rápido y fácil de modificar.

Ahora toca hablar de Multiverse, y los recuerdos me llegan en tropel. El proyecto en cuestión era «un MMO para aprender y enseñar español». Dicho finamente, una plataforma online de e-learning integrada en un mundo 3D. Empezamos usando Multiverse porque la decisión sobre el motor a utilizar «vino de arriba»; era gratis cuando yo llegué al estudio, ya tenían firmado un convenio de colaboración. La principal ventaja de Multiverse era su portabilidad, porque estaba hecho en Java y Python, pero precisamente por eso el rendimiento del cliente en aquellas versiones era bastante pobre. Añadir al cliente capas de interfaces y sistemas de inventario para que alumnos y profesores pudieran compartir documentos (lecciones, deberes, fotos…) no ayudaba precisamente a mejorar el rendimiento. Pero lo hicimos, vaya, y a quienes lo hicimos nos concedieron el premio FICOD 08 «por desarrollar mejoras en las tecnologías que permiten crear mundos virtuales».

Mi principal preocupación con Multiverse era la visibilidad del código. Los scripts de Python tenían que estar en el cliente, a la vista de cualquiera, así que era muy fácil modificarlos y «hacer trampas». Ese fue el principal motivo por el que al final dejamos Multiverse; probamos BigWorld y HeroEngine, y al final el proyecto se completó con este último y se convirtió en «HiHOLA!«.

La idea detrás de Multiverse era muy buena: un sistema de servidores, cada uno con su mundo o juego, y cualquiera con el cliente de Multiverse en su ordenador podría acceder a todos ellos (si tenía permiso, claro). Si os interesa echarle un vistazo a esta plataforma podéis descargarla completa y gratis desde su web; tened en cuenta que para generar contenidos 3D hace falta 3ds Max 2011 32 bit (no versiones más modernas), y que el servidor está hecho para correr en Ubuntu. Puede ser interesante para proyectos de fin de carrera, para trastear o para aprender cómo funciona un sistema así, pero yo no lo usaría para hacer juegos comerciales según está. Hay alternativas menos… dolorosas para hacer juegos online, ahora os comento un par: BigWorld y HeroEngine.

En dos ocasiones distintas separadas por unos años he tenido que probar BigWorld. Es un motor excelente, el único con particionamiento dinámico del mundo de juego para equilibrar las cargas de proceso y red. BigWorld permite tener mundos gigantescos con mogollón de usuarios a la vez y es bastante fácil hacer todo tipo de vehículos, incluso tripulados por varios jugadores. Técnicamente es fantástico y el cliente tiene buena potencia gráfica. Las dos veces que lo evalué el único problema fue el precio de licenciarlo: DEMASIADO CARO, con mayúsculas. Con el tiempo intentaron abrirse mercado entre los desarrolladores independientes sacando una versión limitada por $300 pero la reputación estaba ganada y el daño estaba hecho. En las horas bajas de BigWorld la compañía Wargaming, cuyos famosos juegos «World of Tanks» y «World of Warplanes» usan este motor… bueno, pues compró la compañía que desarrolla el motor, y nunca más se supo de las versiones indie. Si tenéis un cerro de dinero y queréis hacer el juego online más supermasivo de la historia, mi consejo es que pidáis una versión de evaluación de BigWorld. Para desarrolladores independientes y estudios pequeños puede quedar bastante fuera de presupuesto, pero si lo podéis pagar y el proyecto lo vale, merece la pena.

HeroEngine lo conocí cuando trabajaba en Salamanca, así que con Anmynor han sido dos los proyectos en los que lo he usado. Del primero al segundo las condiciones de la licencia cambiaron bastante, y hoy en día es bastante más económico que hace unos años. Hay dos precios disponibles: $75.000 más un 7% de los beneficios o bien $99 al año más un 30% de los beneficios. La versión más barata no incluye acceso al código fuente, que conste: el juego se desarrolla mediante scripts y herramientas precompiladas, usando las características que el motor trae por defecto, que son suficientes para la mayoría de juegos online que queráis hacer. Tiene una arquitectura peculiar, y el lenguaje de los scripts es suyo propio. Echad un vistazo a su wiki de referencia para ver a qué me refiero.

En cualquier caso, si queréis hacer un juego online o MMO os recomiendo que echéis un buen vistazo a ambos. Si vuestro presupuesto es ajustado, la opción más evidente es HeroEngine/HeroCloud.

Sé que habrá gente que opinará que con Unreal o Unity se puede hacer un MMO, y no es mentira pero tampoco es totalmente cierto. Con ambos se puede hacer el cliente del juego, pero la parte del servidor ya es otro asunto. Quienes han hecho juegos así (online/MMO con clientes hechos en Unity o Unreal) han usado software de terceros para hacer los servidores y gestionar todo el tema de redes y conexiones. Uno de estos es SmartFoxServer, compatible con muchos motores de juegos y tecnologías. Pero por un lado hay que integrar el sistema de red en el cliente de juego, algo que ya traen de serie BigWorld y HeroEngine, y por otro lado están los costes de licencia (3.500€ por juego y servidor con SmartFox X2) y el precio, mantenimiento y conexiones de los servidores, que van aparte. Así que por precio y dificultad, mi consejo es el siguiente:

Si quieres hacer un juego online/MMO que puede hacerse en BigWorld/HeroEngine,
no te compliques y usa uno de estos dos.

Ahora bien, si el juego no es online/MMO podemos entrar en «la guerra de los fanboys» y no estoy por la labor. Hay gente que defiende Unity o Unreal a capa y espada, y le sacan faltas al otro sin reconocer los defectos que pueda tener el que más les gusta. No me parece que sea una actitud productiva, la verdad, y ambos motores son muy buenos. Hace poco tiempo que ambos han cambiado sus modelos de licencia y pueden conseguirse gratis. Como ya expliqué en otra entrada, no creo que un motor sea universalmente mejor que el resto, y en el caso de Unreal y Unity lo mantengo con más firmeza si cabe. Para muestra, un botón:
El Marketplace de Unreal tiene menos contenido que el Asset Store de Unity, cierto es, pero también es cierto que muchos de los extras que hay para Unity son incompatibles entre sí y combinarlos trae más problemas que soluciones. Podríamos revisar las características de cada uno y encontrar ventajas e inconvenientes, pero al final veríamos que están bastante igualados. Por ejemplo, estoy preparando un curso sobre PBR (Physically-Based Rendering) y los ejemplos de integración los hago en Unity simplemente porque a día de hoy tiene más cantidad de usuarios. Sin embargo me costaría lo mismo hacerlo en Unreal, y si hay demanda haré una versión del mismo curso para Unreal. Con los juegos es lo mismo: si el proyecto encaja en el motor, adelante con ello.

Me ha quedado un poco largo pero espero que os haya gustado y que a algunos os sea útil la parrafada :D

]]>
http://jorge.lab109.net/index.php/2015/07/10/mas-sabe-el-diablo-por-viejo/feed/ 0
Cuál es el mejor motor de juegos (game engine) http://jorge.lab109.net/index.php/2015/07/09/cual-es-el-mejor-motor-de-juegos-game-engine/ http://jorge.lab109.net/index.php/2015/07/09/cual-es-el-mejor-motor-de-juegos-game-engine/#respond Thu, 09 Jul 2015 18:00:03 +0000 http://jorge.lab109.net/?p=25 Un motor es una máquina diseñada para convertir energía en movimiento. El motor de un coche es la pieza fundamental que lo mueve y genera electricidad para el resto de sistemas. La analogía entre el coche y los videojuegos es clara: los motores de videojuegos (game engines) son las máquinas que hacen que los juegos funcionen. Son máquinas complejas compuestas por muchas piezas diferentes, y algunos motores de juegos tienen mejor rendimiento que otros en escenarios diferentes. Igual que el motor de un coche de carreras rinde muy bien en el chasis de un deportivo, pero no hará muy buen papel montado en un camión.

Me han preguntado muchas veces cuál es el mejor motor de juegos que conozco, y conozco unos cuantos.
Mi respuesta siempre es la misma: depende de tres factores…

Primero, ¿qué juego quieres hacer? No es lo mismo hacer un tres-en-raya para Android que hacer un MMO para PC. Hay motores capaces de hacer ambas cosas, cierto, pero unas las hacen mejor que otras. Sin saber cómo será el juego o qué características técnicas necesita… pues es muy difícil decir cuál es el mejor motor para hacerlo.

En segundo lugar, ¿para qué plataforma es? Igual que antes, no es lo mismo hacer un juego RPG para portátiles de Nintendo que un FPS online para Mac. Las plataformas que correrán el juego pueden tener requisitos especiales y ninguno de los motores que existen los satisface todos a la vez. Separo este punto del anterior por la cuestión de las «dependencias adicionales», tanto a nivel de hardware objetivo como de licencias legales, acuerdos de distribución y sistemas de control de calidad.

En tercer lugar hay que considerar la habilidad y experiencia de quien va a usar el motor para hacer el juego. Hay motores muy potentes que pueden ser aptos para el juego que quieres hacer pero si hay varios donde elegir, mejor selecciona el más fácil de usar o aquel en el que tengas más experiencia. Esto es por puro sentido práctico, ya que los motores de juegos son herramientas con las que trabajar. Casi siempre es mejor trabajar con herramientas cómodas de usar y fáciles de entender, ¿no es cierto?

Toda esta explicación la puedo resumir diciendo que no creo que haya un motor de juegos universalmente mejor que el resto. Si lo hubiera, todos usaríamos el mismo. En todos los estudios de videojuegos en los que he trabajado se ha seguido este criterio en la fase de «selección de tecnologías»; una vez definidos los requisitos, las dependencias adicionales y la usabilidad o experiencia previa, para cada proyecto se han valorado varios motores y al final uno resulta ser el ideal… para ese proyecto concreto. De acuerdo, también había que tener en cuenta el flujo de trabajo y los costes asociados (licencias, programas de terceros…) pero lo realmente importante está en esos tres puntos.
Así que en realidad la pregunta «¿cuál es el mejor motor de juegos?» debería ser:

«¿Cuál es el mejor motor para hacer mi juego?«

Para responder correctamente tendría que saber cómo es el juego, en qué plataforma se jugará y quiénes lo van a desarrollar; si tú, estimado lector o lectora, te planteas esta pregunta seguramente conozcas tu proyecto lo bastante bien como para tomar una buena decisión. Y ya que las mejores decisiones son las que se toman con la mejor información voy a comentar algunas cosas de varios de los motores con los que he trabajado, pero en otra entrada del blog. Espero que esta información sea útil para cualquier desarrollador independiente que lea esto, así que pasad la voz (y el enlace) a quienes creáis que puedan sacarle partido ;)

]]>
http://jorge.lab109.net/index.php/2015/07/09/cual-es-el-mejor-motor-de-juegos-game-engine/feed/ 0