Diseño y programación – Mochila del concursante

Introducción

En este post contaré cómo hemos diseñado y programado la mochila del concursante a alto nivel, desde un punto de vista conceptual, hasta un nivel más técnico viendo algo del código.

El juego cuenta con múltiples objetos, pero para crear un ecosistema que funcione hay que etiquetarlos y diseñarlos pensando en conceptos reales.

backpack-schema

 

Objetos inventariables (artículos)

La mochila solo permite almacenar objetos inventariables.

Este tipo de objetos tienen un peso y una propiedad que indica si pueden apilarse. Por ejemplo, las flechas pueden apilarse en el inventario, pero los arcos no.

Las propiedades que se configuran para un objeto inventariable son:

  • Tipo: tipo de objeto inventariable, que lo identifica de forma única en el ámbito de los inventariables.
  • Peso: el peso que tiene el objeto en el juego expresado en gramos.
  • Apilable: indica si este objeto puede apilarse en las ranuras de inventario.
/// <summary>
/// <para>Cualquier objeto que puede formar parte de un inventario o que puede inventariarse.</para>
/// <para>En la mayoría de casos, serán cosas que podrán llevarse en el cuerpo o en algo 
/// que permita almacenar, como una mochila o saco.</para>
/// </summary>
public interface IInventariable
{
    /// <summary>
    /// Tipo de objeto invnetariable. Actua como identificador único.
    /// </summary>
    InventariableType InventariableType { get; }
 
    /// <summary>
    /// Peso de este objeto (en gramos).
    /// </summary>
    float Weight { get; }
 
    /// <summary>
    /// <para>Indica si el objeto se puede apilar en las ranuras de un contenedor de inventario.</para>
    /// <para>Por ejemplo, las armas por norma general no se pueden apilar en una misma ranura.</para>
    /// </summary>
    bool Stackable { get; }
}

Contenedor de inventario

El contenedor de inventario es el recipiente donde se pueden guardar los objetos inventariables.

La característica más particular de estos contenedores es que están formados por ranuras de inventario. En estas ranuras es donde se almacenan los artículos u objetos inventariables. Pueden contener un número ilimitado de artículos o un tope a partir del cual no deja apilar más objetos.

backpack-slot-schema

Las propiedades que se pueden configurar para un contenedor son:

  • Capacidad: cantidad de ranuras de las que dispone.
  • Límite de ranura: indica la cantidad máxima de artículos por ranura.
  • Peso: peso máximo que puede soportar.

Por ejemplo, un contenedor que tiene 10 ranuras y un límite de 5 artículos por ranura tiene una capacidad máxima de 10×5, es decir, como máximo podrá contener 50 artículos.

Además dispone de varias propiedades y métodos de utilidad, que permiten consultar el estado del contenedor y gestionarlo. Estos son los más relevantes:

Métodos de extracción

  • Coger X: permite coger una cantidad específica de un tipo de artículo. Se da prioridad a las ranuras con menos artículos, con el fin de intentar liberarlas.
  • Coger X no rotos: hay artículos que se rompen con el uso, este método solo coge artículos que aún no están rotos.
  • Coger todos: saca todos los artículos de la mochila. Queda vacía.

Métodos de inserción

  • Poner pila de artículos en ranura con espacio: añade al contenedor una pila de artículos del mismo tipo. Busca una ranura con espacio suficiente, dando prioridad a ranuras que ya contengan artículos del mismo tipo. Solo realiza la inserción si puede colocarlos todos en una sola ranura. Tiene en cuenta el peso, impidiendo la inserción si se sobrepasa.
  • Poner lista de artículos: añade al contenedor una lista de artículos que pueden ser de tipos diferentes. Se añadirán al contenedor tantos como quepan en el orden en que vienen en la lista.
  • Poner un artículo: añade el artículo al contenedor (si cabe). Tiene en cuenta el peso, impidiendo la inserción si se sobrepasa.

Métodos de utilidad

  • Peso actual: suma del peso de todos los artículos que contiene.
  • Reforzar: aumenta el peso máximo que puede soportar el contenedor.
  • Comprobar artículo: indica si un artículo cabe en el contenedor.
  • Comprobar artículos: indica si una lista de artículos cabe completa en el contenedor.
  • Contar artículos: cuenta los artículos de un tipo concreto que hay en el contenedor.
  • Contar artículos no rotos: cuenta los artículos no rotos de un tipo concreto que hay en el contenedor.
    /// <summary>
    /// <para>Contenedor de inventario que permite transportar o guardar cosas.</para>
    /// <para>Tiene una capacidad y peso máximos que puede soportar.</para>
    /// <para>Permite ser reforzado para aumentar el peso máximo que soporta.</para>
    /// </summary>
    public abstract class InventoryContainer GameObject
    {
        #region Constructor
        protected InventoryContainer() : base()
        {
            InitSlots();
            MaxWeightSupported BaseWeightSupported;
        }
        #endregion
 
        #region Properties
        /// <summary>
        /// Indica si el contenedor es un clon, es decir, se ha creado
        /// a partir del método "Clone()'.
        /// </summary>
        private bool IsClone { get; set; } = false;
 
        /// <summary>
        /// <para>Número máximo o límite de artículos que caben en las ranuras del contenedor.</para>
        /// <para>El valor '0' significa ilimitado.</para>
        /// </summary>
        public abstract uint SlotLimit { get; }
 
        /// <summary>
        /// <para>Capacidad base del container, equivale al número de ranuras de las que dispone inicialmente.</para>
        /// </summary>
        public abstract uint Capacity { get; }
 
        /// <summary>
        /// <para>Peso base máximo que puede cargar (en gramos).</para>
        /// </summary>
        public abstract float BaseWeightSupported { get; }
 
        /// <summary>
        /// Acción que se lanza cuando el contenedor de inventario sufre alguna modificación
        /// que cambie su contenido, normalmente cuando se añaden o quitan artículos.
        /// </summary>
        public ActionEvent OnInventoryModified { get; set; }
 
        /// <summary>
        /// <para>Peso máximo que puede cargar.</para>
        /// <para>Se puede reforzar aumentando su limite de peso.</para>
        /// <para>Si no ha sido reforzado coincidirá con el peso base máximo soportado.</para>
        /// </summary>
        public float MaxWeightSupported { get; protected set; }
 
        /// <summary>
        /// Ranuras de inventario del contenedor (las ranuras pueden apilar objetos u artículos del mismo tipo).
        /// </summary>
        public List<InventorySlot> Slots { get; protected set; }
 
        /// <summary>
        /// Peso total del contenedor en base a la suma de pesos de todos los artículos que contiene.
        /// </summary>
        public float CurrentWeight
        {
            get
            {
                float totalWeight = 0f;
 
                if (Slots != null)
                {
                    totalWeight = Slots.Sum(slot => slot.Weight);
                }
 
                return totalWeight;
            }
        }
        #endregion
 
        #region Extraction
        public Stack<IInventariable> Take(InventariableType type, uint amount)
            ...
 
        public IInventariable TakeUnbroken(InventariableType type)
            ...
 
        public Stack<IInventariable> TakeUnbroken(InventariableType type, uint amount)
            ...
 
        public Stack<IInventariable> Take(int slotIndex, uint quantity)
            ...
 
        public Stack<IInventariable> TakeAll(int slotIndex)
            ...
        #endregion
 
        #region Insertion
        public bool Put(Stack<IInventariable> articles)
            ...
 
        public List<IInventariable> Put(List<IInventariable> articles)
            ...
 
        public bool Put(IInventariable article)
            ...
 
        public Stack<IInventariable> Put(Stack<IInventariable> newArticles, int slotIndex)
            ...
 
        public Stack<IInventariable> Put(IInventariable article, int slotIndex)
            ...
        #endregion
 
        #region Information & Utils
        public void Reinforce(float weightIncrement)
            ...
 
        public bool CheckSpace(IInventariable article)
            ...
 
        public bool CheckSpace(InventariableType articleType)
            ...
 
        public bool ContainsAllUnbrokenIngredientsAndTools(CraftingRecipe recipe)
            ...
 
        public bool CanFit(List<IInventariable> articles)
            ...
 
        public List<ICraftingTool> GetAllUnbrokenTools()
            ...
 
        public HashSet<ICraftingTool> GetUnbrokenTools(HashSet<CraftingToolType> toolTypes)
            ...
 
        public bool IsFull()
            ...
 
        public InventoryContainer Clone()
            ...
 
        public uint CountProjectiles(Type projectileType)
            ...
 
        public uint CountArticles(InventariableType type)
            ...
 
        public uint CountUnbrokenArticles(InventariableType type)
            ...
 
        public List<DrinkContainer> GetAllDrinkCotnainers()
            ...
 
        public List<DrinkContainer> GetDrinkCotnainers(Type drinkType)
            ...
        #endregion
 
        ...
    }

Mochila del concursante

En definitiva la mochila del concursante es un contenedor de inventario, que tiene una capacidad de 16 ranuras y un límite de 5 artículos por ranura. Puede soportar un peso máximo de 8 kilos.

public class BasicBackpack Backpack
{
    #region Constructor
    protected BasicBackpack() : base() { }
    #endregion
 
    #region Game Object
    public override string Name { get; } = "Basic backpack";
 
    public override string FlavorText { get; } = "The simplest and free backpack provided by the show.";
    #endregion
 
    #region Backpack
    public override uint SlotLimit { get; } = 5;
 
    public override uint Capacity { get; } = 16;
 
    public override float BaseWeightSupported { get; } = 8000;
    #endregion
}

Eso es todo (a alto nivel) en cuanto a diseño y programación de la mochila del concursante.

Si tienes dudas o curiosidad por saber el detalle de alguna cosa ¡espero tus comentarios!

 

 

Cómo empezó todo

El 29 del pasado Septiembre se cumplieron 4 meses desde que empezamos con Sticks & Stones a tiempo completo y 7 desde que tuviéramos kick-off oficial. Esta es más o menos la historia de lo que significó llegar a este punto.

BaseTIS es una empresa de consultoría de tecnologías de información con 7 años de experiencia, bien establecida en su modelo de negocio. También es, sin embargo, una empresa que se esfuerza seriamente porque sus empleados nos sentamos apreciados bajo una atmósfera de trabajo en equipo y familiaridad, entendiendo que antes de ser empleados—fuentes de ingresos y egresos—son personas, con intereses e inquietudes propias que en ocasiones pueden resultar incongruentes con el objeto de la empresa, pero en otras no tanto…

Sticks & Stones sale del no tanto. Habían ganas y talento, ¿sería posible? Una empresa de servicios, adentrándose en el universo de los videojuegos… ¿Desarrollar un producto? ¿Un vi-de-o-jue-go?  ¿Definir una estrategia de marketing? ¿Hacer pruebas de usuario? ¿Cómo manejar el soporte al usuario? ¿La distribución? ¿Cómo manejar el QA? ¿Pruebas automatizadas? ¿Tiempo…, o evidentemente, coste?  Tantas preguntas, tantas disciplinas que BaseTIS no conoce, tanta incertidumbre…

De acuerdo. El proyecto debía presentarse a BaseTIS buscando reducir tanta incertidumbre como fuese posible. La empresa estaba abierta a escuchar propuestas (porque es importante que los empleados puedan crecer y que sepan que pueden crecer dentro de la empresa), pero había que ser preciso.

1er Intento. Septiembre 2015.

PPT – 40 diapositivas.

Preámbulo, Status Quo del Desarrollo IndieOportunidades de Negocio, Retos, El Juego: Propuesta de Mecánicas, Equipo necesario, Plan de Marketing con Notas de Prensa, Diario de Desarrollo, Demos internas, Redes Sociales… Publicación (Steam Greenlight, Steamworks…) Planificación, Fechas, fechas, Diagramas de Gantt, Metodologías (Cascada, Scrum, Agile), Herramientas (Software, Hardware), Hitos, Riesgos, Beneficios, Tiempo total: 10 meses (!), Coste total del proyecto, ventas mínimas a alcanzar para no quedar en pérdidas..

Qué interesante, ¿no? Si están debidamente desarrolladas las diapositivas, parece ser un pitch bastante completo, ¿cierto?

¡FALSO!

¿De qué trataba el juego?

Habían las ganas, había el talento: no había juego. Teníamos un esbozo de historia y algo que tenía intenciones de ser un personaje,  inspirados por Ori and the Blind Forest, Shadow of the Colossus, y los perversos trailers de Below

En fin, nuestra propuesta de proyecto estaba muy concentrada en lo práctico, sin haber prestado casi atención a lo fundamental, y nuestro fundamental apuntaba hacia un juego de plataformas con alto contenido emocional, estéticamente pulido, y un plan sólido sólido para entregarlo en 10 meses.

Sí.

10 meses. Obviamente, con menor alcance pero igual… 10 meses.

Ah. Qué tiempos aquellos. Qué simple era todo… No teníamos historia y lo podíamos tener listo en 10 meses.

Para ese primer intento, no teníamos más que una idea de una aventura. Un personaje principal y su fiel compañero. ¿Qué tendrían que decir? ¿Qué podría hacer el jugador? ¿Qué queríamos hacer sentir al jugador? Éramos tres jugadores asiduos, cada uno con una opinión sobre la clase de juegos que nos gustaba jugar.  ¿Journey? ¿Ori? ¿Metal Gear? ¿Earthworm Jim? ¿Diablo? ¿Myst? Cada uno de nosotros con no más argumentos para convencer a los demás aparte de “a mi me gusta”. Problema.

Y estaba por supuesto la preocupación del tiempo. Quitemos los 10 meses; si 10 meses no fuesen una limitación ¿qué haríamos? Vamos, algo emocional a lo Ori-Miyazaki-El Gigante de Hierro (de nuevo, qué tiempos aquellos…) no podría hacerse en 10 meses. Ori fue hecho por profesionales experimentados en 4 años. Braid, otra de nuestras referencias, en 3 años. Super Meat Boy, que es un caso excepcional, de poca profundidad, y de mecánicas mucho más simples a las que ofrecen Ori  y Braid, 1 año y 6 meses. Mientras más tiempo tardáramos en obtener un resultado, más costoso iba a ser para BaseTIS, más difícil sería convencerla de que hacer un videojuego era una oportunidad de negocio, y mayor iba a ser el riesgo de que si todo fallara, no se volviera a hablar más nunca de esa idea, y los tres regresaríamos a nuestros formularios, Spring-data, Spring-boot, Spring-batch, Spring, Spring, Spring… Si queríamos hacer algo Ori-Miyazaki-El Gigante de Hierro, e íbamos a ser nosotros tres nada más (como se suponía), pues, tendríamos que hacerlo… Las animaciones, los colores, las transiciones, los escenarios, el sonido, la música, la programación… Sí. Teníamos talento, pero no tanto. ¿10 meses? No lo creo…

Fuimos a pensarlo mejor.

¿Podíamos hacer un videojuego valioso en un tiempo razonable? No. El enfoque más sensato, más terrenal, era Poco a Poco. Hagamos una mecánica, luego otra, luego otra. Hagámoslo por hitos. Hitos de tres semanas. Hito tras hito llegaríamos a un milestone, un MVP, algo que podía llamarse un videojuego, pero que podía darse el privilegio de no ser vistoso, ni elegante, ni llamativo, pero que, si BaseTIS lo permitía, podía ir mejorando. Como capas en un pastel.

¿De acuerdo, pero cómo haces un Ori-Miyazaki-El Gigante de Hierro así?  ¿Cómo le quitas pedazos a una historia, la reduces a su mínima expresión y luego la recompones? ¿Cómo la recompones? ¿Qué fragmento puedes agregar al MVP sin hacerlo que quede incompleto de nuevo? Es que si pongo esto, tengo que poner aquello, y si pongo aquello, pues lo otro no puede faltar, y si está lo otro, pues es imprescindible esta mecánica, y de nuevo tienes una fecha de entrega en 3, 4 años.

Generación procedural. Esa era la clave. Podíamos tener un juego, un MVP, en poco tiempo. Podríamos ir adentrándonos en la experiencia. BaseTIS podría cancelarlo todo si iba muy mal. Podríamos detectar en meses si teníamos una idea acertada, si las mecánicas eran coherentes entre ellas, si nuestro juego, en su versión más primordial, era jugable. Tendríamos luego que hacer arte, mucho arte, pero podría hacerse en capas, iterativamente. No sería fácil, sin embargo. Cada hito significaría decidir grados de prioridad. Qué calificaba como pirotecnia, qué como core. Todo era esencial para el juego final, pero, ¿acaso la música o el sistema de partículas o la animación pulida de un enemigo también? Cuántas cosas que teníamos ilusión de hacer desde el inicio del proyecto, quedarían postergadas, quizás para siempre…

2do Intento. Febrero 2016.

PPT – 60 diapositivas.

20 más que las 40 anteriores, dedicadas a explicar un videojuego de generación procedural, un roguelike, con un contexto que lo justificara y lo aprovechara, personajes tentativos, niveles, forma de progresar, habilidades, sistema de supervivencia, sistema de crafting, y luego, nuevas diapositivas explicando los Hitos. Los objetivos bien acotados. De nuevo, 3 semanas cada uno. Fecha de entrega. Fecha de demo interna para los empleados de BaseTIS.  Pruebas, pruebas, pruebas. Debía ser estable. Un prototipo, sin duda un pequeño monstruo, pero no un esperpento. Válido que fuera delicado, pero no cojo ya que a partir de él vendría todo lo demás… 10 meses para un release final podía ser una fecha, como podía no serlo. Dependía de las iteraciones anteriores, del cómo había sido el progreso, del ambiente, ya veríamos…

Ahora sí.

Después de que cada uno terminara sus compromisos en sus propios proyectos, logramos converger. Tiempo parcial, poco a  poco, hasta un día, casi milagrosamente, a tiempo completo. Manos a la obra: teníamos tareas definidas y objetivos claros. Todo podía cambiar (hacer un videojuego es al final un esfuerzo creativo), pero había que saber justificarlo. ¿Sería entretenido? ¿Sería impresionante visualmente? ¿Sería un juego de verdad? No, esas preguntas pasaban a otro plano. Ahora teníamos que preocuparnos por lo terrenal, lo inmediato. Teníamos tareas, teníamos horas…

Ese 29 de Septiembre ya teníamos un MVP. No el MVP pero un MVP. Es un juego que, aunque se aleja de nuestra visión original (y que incluye un Time Attack y una araña gigante), es un juego. Habíamos logrado algo que podíamos mostrar, dentro y fuera de BaseTIS, y a partir del que podríamos recibir feedback. Nos habíamos conocido entre nosotros, nuestras habilidades y debilidades, las herramientas, las virtudes y limitaciones del motor, podíamos ver oportunidades para colaboraciones, debilidades, definir tareas para más adelante, podíamos ver cómo funcionaban las mecánicas y dónde fallaban, cómo aparecen variables no consideradas, cómo el juego resuelve condiciones inesperadas, cómo se comporta en casos que ninguno de los tres había imaginado… Ah, era un monstruo, y estaba vivo.

Ya para hoy hemos entrado en otro de esos ciclos. Hitos de tres semanas. Tareas. Horas. Definiendo qué pasa en los próximos 4 meses. Todavía, de vez en cuando, la creatividad se dispara y nos explayamos por horas sobre alguna fruslería invisible que sin duda es esencial; pero cada hito, cada fecha, nos regresa al camino que, aunque no luce especialmente orlado, ya nos ha empujado hacia un logro… Quién sabe si seguirá siendo así…

 

¿Qué valor tiene la coherencia en un videojuego?

Introducción

Nota: Este post contiene referencias a Sticks & Stones, es recomendable leer el resumen sobre nuestro videojuego antes de continuar.

El tema que voy a explicar es recurrente y de carácter filosófico. Se trata del valor que tiene darle coherencia al videojuego y cómo impacta eso en su diseño.

En Super Mario Bros controlas a un fontanero en un mundo de fantasía ¿Por qué hay tortugas con alas o plantas carnívoras que salen de tubos?

En Prince of Persia (2008) han decidido que no puedes morir y han implantado una mecánica en la que Elika te salva siempre de la muerte. ¿Por qué no tienes vidas infinitas como en Call of Duty? ¿Por  qué se han molestado en darle sentido?

Analizando Super Mario Bros

En mi opinión, el fuerte de Super Mario Bros está en la jugabilidad. Que una tortuga tenga alas no supone un problema desde el punto de vista de la coherencia, porque desde el inicio se plantea un mundo de fantasía con sus propias reglas. Sin embargo no me siento identificado con el protagonista, no comparto sus objetivos de rescatar la princesa. Lo que me gusta del juego es dominar sus mecánicas, eliminar enemigos y recorrer escenarios.

Mario Bros

En un juego como este hay más libertad para tomarse ciertas licencias, como setas que caminan o monedas que flotan, pero funciona, porque es poderoso en sus mecánicas y coherente en sus reglas.

Analizando Prince Of Persia (2008)

Mi experiencia con este juego fue mucho más próxima a los personajes, me sentí más inmerso en sus escenarios y en cierta medida podía creerme que yo era el Príncipe de Persia.

Principe de Persia 2008

¿Que impacto tiene en el juego que el personaje no pueda morir? Es un aspecto que me llamó bastante la atención, y analizándolo llegué a la conclusión de que está para reforzar la relación entre los dos personajes y para sentir que tienes una sola vida. Fortalece la sensación de ser tu el protagonista y estar viviendo la aventura. No es la única razón para alcanzar esa sensación, hay otros factores, pero en definitiva ayuda crear una experiencia positiva.

Prince Of Persia 2008

En muchos videojuegos se utilizan puntos de auto-guardadoPrice Of Persia (2008) también lo hace, pero en esos juegos no le dan sentido a la muerte, simplemente es la forma fácil de conseguir que avances en el juego sin tener que repetirlo todo. Prince Of Persia (2008) consigue ese plus, evitando que el jugador tenga la sensación de que muere, y por lo tanto experimentando una aventura continúa.

Un caso particular de Sticks & Stones

En lo que respecta a nuestro juego, el concursante puede participar varias veces en el Show, entonces me pregunto. ¿Tiene sentido que si el concursante muere pueda volver a participar? ¿Vale la pena invertir tiempo y darle sentido a la muerte del concursante? Algo que puede parecer tan simple puede provocar muchos dolores de cabeza y debates interesantes.

Este es un ejemplo de muchos, de como pueden afectar las decisiones que se toman si se tiene en cuenta la coherencia. Es un buen ejemplo de partida, así que vamos a entrar al detalle.

¿Por qué la palabra muerte está marcada en cursiva? Porque es el quid de la cuestión. Si se trata de un concurso de televisión, en el que puedes participar reiteradamente, no es coherente que el concursante muera. En este caso hemos decidido darle sentido, como ocurre en Prince of Persia (2008).

Por supuesto, esto ha tenido consecuencias a nivel de diseño:

  • El Show no puede ser de carácter macabro,  no se lucra de la muerte de los concursantes (como en Los Juegos del Hambre).
  • La fauna no puede ser hostil, porque no pueden dañar o matar al concursante.
  • Los enemigos no pueden ser letales, por lo que hemos decidido que son robots controlados por el Show llamados Holoballs, que incorporan un sistema holográfico e interaccionan con el concursante mediante un traje especial.
  • No se pueden craftear armaduras y escudos normales, porque los enemigos no pueden causar daño al concursante y no tendría sentido defenderse de ataques físicos. En su lugar podrían haber escudos especiales suministrados por el Show para poder interaccionar con los hologramas.

En este punto, tenemos suficiente información para reflexionar y hacernos las siguientes preguntas:

  • ¿Ha valido la pena impedir que el concursante muera? La respuesta es sí, porque nos ha obligado a ser creativos al tener que darle sentido y coherencia. Ha enriquecido el contexto, dándole más profundidad. Han surgido buenas ideas, como de las Holoballs, que tendrán un papel importante en el juego.
  • ¿Lo van a apreciar los jugadores? Esto es más difícil de responder. Hasta que no tengamos mucho feedback no lo sabremos, pero creemos que sí y por eso hemos apostado por ello.
    Hay diferentes perfiles de jugador, algunos no se fijan en los detalles, pero otros sí y es en este grupo dónde cogerá más peso la decisión que hemos tomado.
    Personalmente creo que conseguir ese plus, como ocurre en Prince of Persia (2008), será positivo porque el jugador podrá sentir esa continuidad de ser un concursante de verdad, que puede perder y volver a intentarlo.
  • ¿Como hubiera afectado si hubiéramos tomado otra decisión? Entendiendo otra decisión como: no preocuparse por el hecho de que el concursante muera, volver a participar en el Show es, simplemente, otra partida.
    En este caso, solo puedo responder con suposiciones. Probablemente el contexto sería diferente y algunas mecánicas habrían cambiado, como por ejemplo poder craftear armaduras o escudos.
    Si no le das sentido a la muerte del concursante y muere al ser atacado por un lobo, pero puede volver a jugar otra partida, seguramente no sería un problema grave. Estaríamos ante un caso similar a Call Of Duty o el nuevo Doom. Si te matan, simplemente continúas desde el último punto de guardado, la muerte se convierte en algo sin importancia, pero que resta credibilidad a la aventura.

Conclusiones

Darle coherencia a los diferentes aspectos del juego es importante porque aumenta la credibilidad, pero tiene un coste asociado que afecta a las mecánicas, contexto y al diseño.

En ocasiones será necesario omitir la coherencia en favor de la jugabiliad, pero es bueno tener presente que es positivo invertir tiempo en darle sentido a las cosas, porque los detalles marcan la diferencia.

Espero vuestros comentarios y opiniones al respecto 🙂