Daños y resistencias

En Sticks & Stones hemos optado por un sistema de daños y resistencias, lo que significa que un arma que puede ser poderosa contra un enemigo pero débil contra otro. Lo mismo ocurre con los enemigos, que pueden ser vulnerables o resistentes a los diferentes tipos de daño.

Tipos de daño

Los objetos que causan daño, como las armas, definen uno o varios tipos de daño.

  • Perforante
  • Aplastante
  • Cortante
  • Hendidor
  • Fuego
  • Disparo
  • Virtual

En nuestro código, utilizamos un enum para catalogarlos.

public enum DamageType
{
    Piercing,
    Crushing,
    Slashing,
    Cleaving,
    Fire,
    Shoot,
    Virtual
}

Un arma podría combinar varios tipos de daño, por ejemplo un garrote con pinchos combinaría daño aplastante y perforante. Además para cada tipo de daño se define la cantidad de daño, pero eso lo veremos más adelante.

Armas

Las armas tienen varias propiedades en común. En nuestro código las agrupamos con 3 interfaces: IInventariable, IEquippable y IDamageDealer.

public abstract class Weapon : Wearable,
    IInventariable,
    IEquippable,
    IDamageDealer
{
    ...
}

Inventariable: indica que las armas pueden colocarse en un inventario, como por ejemplo la mochila.

public interface IInventariable
{
    InventariableType InventariableType { get; }
 
    float Weight { get; }
 
    bool Stackable { get; }
 
    short InventoryValue { get; }
}

Equipable: indica que las armas pueden equiparse en el cuerpo de un personaje.

public interface IEquippable
{
    List<BodyPart> AllowedEquippableAreas { get; }
 
    bool TwoHandsUse { get; }
}

Dañino: cualquier objeto que puede causar daños.

/// <summary>
/// Cualquier cosa susceptible de causar daño.
/// </summary>
public interface IDamageDealer
{
    /// <summary>
    /// Objeto con la configuración e información sobre el daño.
    /// </summary>
    DamageSource DamageSource { get; }
 
    /// <summary>
    /// Indica si puede ser lanzado o arrojado.
    /// </summary>
    bool CanBeHurled { get; }
}

La parte más interesante es IDamageDealer que es la interface que indica que un objeto puede causar daño mediante la propiedad DamageSource, que habla de la cantidad y tipos de daño.

DamageSource básicamente contiene un diccionario donde la clave es el tipo de daño y el valor es un entero que indica la cantidad de daño.

public class DamageSource
{
    public readonly Dictionary<DamageTypeint> DamageByType;
 
    #region Constructor
    public DamageSource(Dictionary<DamageTypeint> types)
    {
        DamageByType = types;
    }
    #endregion
}

Inicialmente DamageSource tenía propiedades adicionales relacionadas con efectos negativos (debuff) que se aplicaban al atacar. Pero es una mecánica que por ahora vamos a omitir del videojuego.

Estos son ejemplos de objetos dañinos (armas principalmente) que tenemos configurados en Sticks & Stones.

stone-axe-icon  Hacha de piedra
Hendidor = 13
wooden-bow-icon  Arco de madera
Disparo = 5
wooden-club-icon  Mazo de madera
Aplastante = 25
bone-knife  Cuchillo de hueso
Perforante = 4
Cortante = 2
*Daño potencial = 6
wooden-arrows  Flecha de madera
Perforante = 8

En el caso de las armas de proyectil, cómo los arcos, el daño que acaban causando depende también del proyectil que lanzan. Simplificando, se puede decir que un arma de proyectil causa un daño equivalente al suyo más el del proyectil que lanza. Según los ejemplos anteriores, un arco de madera que lanza flechas de madera, tendría un daño potencial de 13 (5 de disparo y 8 de perforante).

Resistencia y vulnerabilidad al daño

La resistencia o vulnerabilidad al daño es una propiedad que se configura en los personajes, pero también afecta al entorno, como por ejemplo un árbol.

Similar a cómo ocurre en las armas, en el código utilizamos una interface que indica si un objeto puede recibir daño.

Esta interface se llama IVulnerable.

public interface IVulnerable
    {
        uint BaseHitPoints { get; }
 
        int CurrentHitPoints { getset; }
 
        Dictionary<DamageTypeint> ResistencesByDamageType { get; }
 
        DamageInfo GettingDamage(
            CharacterBase owner,
            IDamageDealer damageDealer,
            ProjectileWeapon projectileWeapon,
            float damageMultiplier,
            AttackProperties attackProperties);
    }

La propiedad interesante es ResistencesByDamageType, que consiste en un diccionario donde la clave es el tipo de daño y el valor es el porcentaje de resistencia o vulnerabilidad a ese tipo de daño. Un valor negativo indica que es vulnerable y un valor positivo que es resistente. La omisión de un tipo de daño indica que no le afectará ni positivamente ni negativamente, es decir, un objeto que no tiene configuradas resistencias o vulnerabilidades recibirá el daño potencial del arma (13 siguiendo el ejemplo del arco y flecha u 6 del cuchillo de hueso).

Como dije, no solo los personajes son vulnerables al daño, hay objetos del entorno que también lo son, como por ejemplo los árboles.

forest-tree
Hendidor = -50%
Aplastante = 99%
Perforante = 80%
Disparo = 90%
Cortante = 80%
Fuego = -80%

Se puede observar que los árboles son especialmente vulnerables al daño hendidor (el que producen las hachas) y al fuego, y muy resistentes al resto de daños.

Los principales enemigos de Sticks & Stones, la míticas Holo-Balls, configuran sus propias resistencias y vulnerabilidades. La finalidad es crear estrategias y elecciones de armas específicas para cada enfrentamiento. No queremos que exista una sola arma poderosa, queremos que cualquier arma pueda ser útil.

En definitiva, en Sticks & Stones hay que experimentar para conocer y aprender sobre los enemigos y las armas.

¿Crees que este nivel de profundidad en el sistema de daños le sienta bien al videojuego?

Las 300 recetas de crafting

Una de las mecánicas que ofrece el videojuego es el Crafting, combinar elementos para crear nuevos.

En los inicios—empieza a quedar lejos—hablábamos de poder elaborar 300 elementos—que no espartanos—.  Hoy tenemos una visión muy distinta, creemos que habrá menos de 100. No por un tema de tiempo o coste—que podría ser un motivo totalmente válido—, sino por un tema de diseño. Creemos que le sienta mejor al videojuego, es más, es él quien lo pide.

Se trata de un videojuego difícil en el que hay que jugar varias partidas para ganar. Es necesario adquirir conocimiento y habilidad para superar el reto. Eso implica repetir, repetir y repetir.

El motivo inicial de pensar en 300 recetas—¡This is Sparta!—era en pro de la variedad, porque creemos que ayuda a que el factor de repetición no sea un lastre. Sin embargo, cuando nos hemos puesto a pensar qué puede construirse en un bosque, nos hemos dado cuenta de que estamos limitados. Esto sumado al echo de que no es un videojuego puramente de supervivencia, está más orientado a la acción y combate y por consiguiente el crafting está orientado a las armas, dejando en segundo plano los elementos de supervivencia.

Teniendo en cuenta esto, ¿Qué cosas podemos construir con lo que encontramos en un bosque?—Por supuesto, estamos abiertos a sugerencias—.

En cuanto a armas pensamos en: hacha, escudo, lanza, garrote, mazo, arco, flecha, honda, tirachinas, boomerang, cuchillo, ballesta, virote, cerbatana, dardo… En algunos casos en sus versiones de madera, bambú o hueso.

En cuanto elementos de supervivencia: bolsa de agua, saco para llevar cosas extras, carcaj y poco más. Descartamos muchas opciones porque no aportan a la jugabilidad, sobretodo por no tratarse de un videojuego puro de supervivencia, dónde tendría sentido construir huertos, refugios, muros, espantapájaros, para-rayos, sombreros, vendajes… En Sticks & Stones solo tenemos que preocuparnos por el hambre, la hidratación y el espacio en la mochila. No existen factores que puedan dañar al concursante, pues la fauna no es hostil y los enemigos son robots diseñados por el show con una IA incapaz de dañar al concursante.

Todo esto no anula el echo de que la variedad sigue siendo necesaria para lidiar con el factor repetitivo, pero debemos buscar otras formas de conseguirla. En este sentido estamos diseñado algunas mecánicas nuevas, que no solo encajan en el contexto del juego, sino que lo potencian. Se trata del crafting tecnológico, pero no voy a hacer spoiler, lo dejo para otro post 🙂

 

Coqueteando con los cambios climáticos

Sticks & Stones – juego difícil e iterativo, donde prima nuestra habilidad y aprendizaje versus la memorización.

Bajo esta sencilla premisa, siempre hemos tenido en el horizonte a un Goliat con su mirada intimidante e inquietante, advirtiéndonos: variedad, variedad, variedad.

En un juego en el que perder está a la orden del día, y avanzar se hace duro pero muy satisfactorio, se presentan retos a nivel de diseño. Y la palabra variedad es de las que mejor definen muchas de las soluciones.

No es la primera vez que os hablamos sobre esto en el Blog:

Y volvemos a la carga del barco variedad coqueteando con los cambios climáticos… a ver qué os parecen:

¿Qué os parecen?

Si os gusta, compartid entre vuestros amigos.

El diseño de los alijos de supervivencia

deathSticks & Stones es un Rogue-like, y como tal, la elevada dificultad y la permadeath (muerte permanente) forman parte de sus características principales. Vamos a tener que jugar una y otra vez para conseguir ganar este reality show.

A nivel de diseño esto nos pone en un aprieto, pues tenemos que conseguir que la experiencia de juego no se haga pesada o aburrida.

A grandes rasgos, la estructura del videojuego se puede resumir en planificación+combate. La parte de combate no es problema, es pura acción y la diversión está asegurada. Sin embargo, en la parte de planificación, que incluye: exploración, supervivencia, recolección y crafting, es donde debemos andar con más cuidado, porque son mecánicas lentas. Es aquí donde entran en juego los alijos de supervivencia.game-structure

Los alijos de supervivencia serán una de las mecánicas, entre otras tantas, que ayudarán a que la parte de planificación sea más entretenida. Lo que se pretende con los alijos, es potenciar la exploración añadiendo un pequeño componente aleatorio que otorgará ventajas al concursante entre partidas.

karmaA un nivel contextual, los alijos de supervivencia son creados por los mismos concursantes, como una forma para ayudarse entre ellos. Aquí jugamos un poco con el Karma, pues la idea es que si escondes algo bueno en un alijo para que otro se lo encuentre, tu Karma será positivo y es posible que alguien te devuelva ese favor. Aterrizando este concepto en el juego, la idea es que si en una partida escondes algo de valor, en tu siguiente partida encontrarás algo de valor equivalente.

Esta mecánica es una de las pocas que transciende entre partidas, ofreciendo al jugador una manera de comunicarse entre ellas y otorgandole ventajas que le permitan avanzar cada vez más lejos. Además está perfectamente integrada en el contexto, para que el jugador pueda sentir lo duro que es el reto que propone el reality show y decida si quiere ayudar a otros—o a sí mismo-—a obtener el premio.

Hasta aquí el concepto, pero ahora explico como resolvemos esta mecánica y que se va a encontrar el jugador durante la partida.

En la zona central, especialmente diseñada para planificarse y donde comienza la partida, el concursante tendrá que explorar, recolectar y construir cosas. En definitiva, preparase para la supervivencia y el combate. Durante la exploración, si se presta la suficiente atención al entorno, podremos encontrar el alijo, que se descubrirá por emitir un sutil brillo intermitente. Al situarnos en el origen del brillo se habilitará una opción para cavar en el suelo. No será necesario ninguna herramienta, el concursante cavará con sus propias manos poniendo al descubierto el botín, del que podremos coger todo lo que queramos y/o dejar cosas para que el próximo concursante las encuentre.

Internamente los objetos del juego tienen un valor, que se utiliza para calcular el valor total del alijo.

Por ejemplo, un alijo de valor 18 podría contener objetos que sumen hasta un total de 18:

1 × Lanza de madera (8) 1*8 = 8  wooden-spear
1 × Cuchillo de hueso (10)  1*10 = 10  bone-knife
wooden-spearbone-knife = 18

4 × Flecha de madera (3)  4*3 = 12  wooden-arrowswooden-arrowswooden-arrowswooden-arrows
1 × Cuerda (4) 1*4 = 4  rope
wooden-arrowswooden-arrowswooden-arrowswooden-arrows rope = 16

Este factor aleatorio, permitirá que el jugador pueda encontrar y utilizar objetos que no conoce, incentivando la experimentación con el crafting y añadiendo un punto de emoción al encontrar el alijo.

Esto es todo por ahora en cuanto los alijos de supervivencia, pero tenemos varios puntos abiertos, como por ejemplo si hay límite máximo en el valor de un alijo o si hay un número máximo de objetos que puede contener. También nos preguntamos: ¿se debe enterrar el alijo para considerase válido?

Te animo a que opines sobre está mecánica y nos ayudes a decidirnos por las dudas pendientes que nos quedan.

¡Muchas gracias!

 

El reto de combinar ciertas mecánicas – Solución

En la entrada de hoy, vamos a explicar cómo hemos afrontado el mayor (por lo menos, hasta la fecha) de los problemas de diseño de Sticks & Stones.

Allá por noviembre publicamos una entrada en la que hablábamos del reto de combinar ciertas mecánicas, y de cómo el hecho de aventurarnos a experimentar con ellas nos ocasionó ciertos problemas:

Rogue-like – Empezar desde cero – VS – Crafting – Construcción progresiva

El problema aquí es que puede llegar a cansar el tener que pasar siempre por las mismas fases del crafting, recolectar ingredientes, craftear, recolectar ingredientes, craftear, …

Rogue-like– Zonas pequeñas – VS – Supervivencia – Sensación de exploración

El problema aquí casi casi se lee solo. El juego tendrá zonas más bien pequeñas, pero la sensación de supervivencia se consigue con ambientes muy grandes para potenciar la necesidad de explorar.

En el artículo actual, desarrollaremos la solución que diseñamos para paliar estos problemas, que aunque, si bien no los elimina por completo, los minimiza bastante.

– ANTES –

Para poder explicar esto,  volvamos al  esquema de juego que teníamos hasta entonces:

gamerunold

 

El desarrollo del juego era muy sencillo, el jugador aparecía en la Zona A y tenía que pasar por todas las demás zonas hasta llegar a la última. Todas y cada una de las zonas tenía partes de exploración, recolección de recursos y combate.

– ACTUAL –

En la actualidad hemos apostado por el siguiente esquema :

gamerunnew

 

El desarrollo aquí se concentra en  empezar en la zona central y recorrer las zonas A, B, C y D en el orden que se quiera, para finalmente ir a la zona final. Con la peculiaridad que la zona central es exclusivamente de exploración y recolección, mientras que las zonas A, B, C y D se centran, casi en exclusiva, en combate. Así, para acceder a la zona final, antes habrá que finalizar las zonas de la A a la D.

ANALISIS

A priori parece una solución bastante sencilla – solo se mueven 4 cajitas y flechitas entre ambos esquemas. Pero este nuevo enfoque aporta un montón de ventajas, mejoras y mitiga bastante los problemas descritos anteriormente.

Vayamos a ver punto por punto lo que nos aporta este nuevo enfoque:

 

PLANIFICACIÓN

Empezamos el juego en la zona central, llena de recursos y sin ninguna amenaza. Somos nosotros los que decidimos el tiempo que invertimos para recolectar recursos y construir nuestras propias armas. Cuando nos sintamos preparados para entrar en combate, solo será necesario coger uno de los 4 ascensores disponibles (A, B, C o D).

¿Qué nos aporta este cambio de enfoque y el nuevo esquema? Pues que el juego ya NO marca el camino ni el ritmo de jugador, sino que cada uno escogerá el suyo propio, haciendo el juego más estratégico, más frenético o más conservador, dependiendo del momento y las necesidades.

Aparte de eso, la construcción está basada de tal modo que, esta primera zona sea la que concentre la mayoría de recursos en todo el juego, lo que hace que tengamos que medir muy bien su uso.

En el anterior esquema, el hecho de que era necesario avanzar de forma obligatoria por las zonas (sin poder volver atrás), hacía que la recolección y la exploración fuera más necesaria e incierta. Ya que no sabías nunca qué recursos ibas a encontrarte en las futuras zonas, y muchas veces acababas con el síndrome de Diógenes recogiendo todo lo que podías cargar en la mochila.

REPETICIÓN MÁS VARIADA

La posibilidad de afrontar cualquiera de las 4 zonas desde el minuto 1, permite que las partidas sean más variadas, ya que cada zona tiene sus propios enemigos, retos, peculiaridades y dificultades que hacen que se tengan que afrontar de forma muy distinta, y llegar a ellas con recursos diversos.

En el anterior esquema, el orden de las zonas era prefijado y las partidas, al conocerse el camino a seguir, podían convertirse en una repetición de acciones de forma sistemática. Adicionalmente nos enfrentábamos a una limitación a nivel de diseño, que consistía en desarrollar el entorno de tal modo que todas las zonas tuvieran recursos suficientes para poder ir avanzando en el juego.

RUN NO LINEAL

El talón de Aquiles de cualquier diseño Rogue-like es la linealidad y puede crear frustración. Los que estén familiarizados con el concepto de juego rogue-like saben que la base siempre es la misma: jugar-morir-aprender, jugar-morir-aprender, jugar-morir-aprender… Así hasta acabar el juego (o no).

Por lo que el empezar cada partida siempre desde el principio, puede convertirse en un camino de frustración, que, en consecuencia, lleva a la triste verdad: el juego cae en el olvido a la primera de cambio.

Creemos que este nuevo esquema de orden no-lineal que se traduce en poder finalizar las 4 zonas en el orden que se quiera, debería ayudar mucho a afrontar de forma más amena el desarrollo del juego. Además, claro está, de toda la variedad que se le pueda dar a nivel de contenido (selector de concursantes, sponsors, ventajas, etc…)

¿Qué os parece esta solución? ¿Creéis que es un esquema y una vuelta de tuerca que podría  funcionar?

Nos encantaría saber vuestras impresiones y leer cualquier comentario al respecto, tanto si creéis que es buen enfoque como no.

Muchas gracias por leernos.

 

¡Cómo molan las Holoballs!

El concepto de Holoball nos ha acompañado desde muy temprano, nació en los inicios del proyecto Sticks & Stones. Ha ido tomado varias formas, colores y comportamientos, pero su esencia se ha mantenido.

La idea es tan simple como atractiva:

Holoball – bola que proyecta un holograma sobre si misma.

Partiendo de esta base tan sencilla, las Holoballs se presentan como los enemigos de los concursantes, impidiéndoles que alcancen su objetivo – finalizar el show.

Centrémonos en qué son exactamente las Holoballs. Por una parte, su exterior está recubierto de un material parecido al caucho que le otorga omniresistencia (resistencia a prácticamente todo). Y por otra banda, las tripas de estas bolas albergan un sistema de engranajes que les permiten coger tracción sobre cualquier superficie conocida.

A nivel técnico, la superficie de las Holoballs está llena de micro-cámaras, que tienen la capacidad de proyectar hologramas representando cualquier forma y color. Y en el caso de necesidad, es posible proyectar hologramas a distancia, aunque siempre hasta cierto límite.

Cada una de las Holoballs puede ser programada para tener un aspecto y un comportamiento totalmente distinto. Y aunque técnicamente son casi indestructibles, están preparadas para recibir y procesar cualquier tipo de daño, tanto físico como holográfico.

Aquí tenéis un pequeño esquema de las tripas de las astutas Holoballs:

holoball

Una vez explicado esto, os dejamos un pequeño avance de algunas Holoballs que tenemos desarrolladas hasta ahora.

El pistolero (Gunslinger)

gunslinger

Esta Holoball centra su ataque a distancia (range). Siempre lleva consigo su revólver con 6 disparos en la recámara. Su mecánica es perseguir al concursante y rodearlo mientras le dispara sin parar.

El Carnero Salvaje (Wild Ram)

wildram

El carnero ataca cuerpo a cuerpo (melee) con su embestida. Tiene poca tracción y sus movimientos son un poco impredecibles a la vez que ágiles. Es crítico calcular sus movimientos y estudiarlos para saber cuando se le puede atacar.

 

En la medida que vayamos desarrollando más Holoballs, os las mostraremos aquí.

Y como siempre, si os ha gustado el artículo: ¡compartidlo!

Diseño y programación – Supervivencia y consumibles

En este post contaré cómo hemos diseñado y programado el sistema de supervivencia y consumibles, que afectan directamente a la mecánica de supervivencia.

El post se divide en 3 apartados:

  1. Supervivencia: la mecánica relacionada con los consumibles.
  2. Consumibles: los objetos que representan el concepto de consumibles.
  3. Colores: los colores que identifican los diferentes indicadores de supervivencia.

 

Supervivencia

Es una de las mecánicas del videojuego que sirve para hacer más difícil el reto al jugador. Durante la partida, sufrirá de hambre, deshidratación y sueño. Para lidiar con ello, tendrá que buscarse la vida, sobre todo utilizando el entorno natural en el que se encuentra. Podrá cazar animales, beber agua, dormir, recoger frutos silvestres, fruta, setas y otras tantas cosas.

Por tanto, la supervivencia mide tres factores:

  • Hambre hunger-icon
  • Deshidratación dehydration-icon
  • Sueño sleep-icon

Cada uno de estos factores tiene su indicador y se dividen en varias propiedades, que permite tener el control del estado de supervivencia de los personajes.

survival-status

Propiedades de supervivencia

La supervivencia está vinculada a los personajes orgánicos, como los concursantes, de manera que cada personaje define dos métricas importantes para cada uno de los factores de supervivencia (hambre, deshidratación y sueño):

  • El tiempo que tarda en desmayarse
  • La cantidad de puntos que necesita para quedar saciado

El código que verás a continuación, es parte del script de un personaje orgánico, donde definimos las propiedades de supervivencia.

  • Tiempo desmayo por hambre: indica el tiempo para desmayarse por hambre o desnutrición, expresado en segundos.
  • Tiempo desmayo por deshidratación: indica el tiempo para desmayarse por deshidratación, expresado en segundos.
  • Tiempo desmayo por sueño: indica el tiempo para desmayarse por sueño, expresado en segundos.
  • Puntos para saciar el hambre: puntos necesarios para saciar completamente el hambre.
  • Puntos para hidratarse: puntos necesarios para hidratarse completamente.
  • Puntos para aliviar sueño: puntos necesarios para aliviar el sueño completamente.
  • Tiempo durmiendo para recuperar sueño: tiempo necesario que se necesita dormir para recuperar completamente el sueño, expresado en segundos.
/// <summary>
/// Cualquier personaje del juego que sea orgánico, por ejemplo un concursante o un animal de la fauna.
/// </summary>
public abstract class OrganicCharacter : CharacterBase
{

...

  /// <summary>
  /// Tiempo para desmayarse por hambre o desnutrición (en segundos).
  /// </summary>
  public abstract float TimeToFaintFromHunger { get; protected set; }

  /// <summary>
  /// Tiempo para desmayarse por deshidratación (en segundos).
  /// </summary>
  public abstract float TimeToFaintFromDehydration { get; protected set; }

  /// <summary>
  /// Tiempo para desmayarse por sueño (en segundos).
  /// </summary>
  public abstract float TimeToFaintFromSleep { get; protected set; }

  /// <summary>
  /// Puntos necesarios para nutrirse al completo y saciar el hambre.
  /// </summary>
  public abstract ushort PointsToSatiateHunger { get; protected set; }

  /// <summary>
  /// Puntos necesarios para hidratarse al completo y saciar la sed.
  /// </summary>
  public abstract ushort PointsToHydrate { get; protected set; }

  /// <summary>
  /// Puntos necesarios para aliviar el sueño.
  /// </summary>
  public abstract ushort PointsToAlleviateSleep { get; protected set; }

  /// <summary>
  /// Tiempo necesario para recuperarse por completo del sueño,
  /// desde un estado completamente agotado o cansado por sueño (en segundos).
  /// </summary>
  public abstract float SleepTimeForFullRecovery { get; protected set; }

...

}

Métodos de consumo de los personajes

El código que añado a continuación, muestra algunos de los métodos de los personajes orgánicos, que permiten interactuar con los consumibles o consultar el estado de supervivencia.

  • Comprobar desmayo: indica si el personaje se ha desmayado por alguna de las propiedades de supervivencia.
  • Consumir: actualiza los indicadores de supervivencia del personaje para un consumible.
  • Beber una bebida: actualiza los indicadores de supervivencia de un personaje para una bebida.
  • Beber de un contenedor: da un sorbo a la bebida contenida en el contenedor de bebidas.
  • Dormir: actualiza el indicador de supervivencia que corresponde con el sueño aumentando los puntos correspondientes al tiempo dormido.
/// <summary>
/// Cualquier personaje del juego que sea orgánico, por ejemplo un concursante o un animal de la fauna.
/// </summary>
public abstract class OrganicCharacter : CharacterBase
{
 
...

 /// <summary>
 /// Indica si el personaje se ha desmayado por falta de comida, hidratación o cansancio.
 /// </summary>
 /// <returns>'Verdadero' si se ha desmayado, 'Falso' en caso contrario.</returns>
 public bool IsFaint()
 {
   return (CurrentFeedingPoints <= 0 || CurrentHydrationPoints <= 0 || CurrentStimulationPoints <= 0);
 }

 /// <summary>
 /// Consumir algún alimento, bebida o estimulante.
 /// Modificará el estado de supervivencia del individuo.
 /// </summary>
 /// <param name="consumable">Objeto a consumir.</param>
 public void Consume(Consumable consumable)
 {
   if (consumable != null)
   {
     // Alimentación
     float estimatedFeedingPoints = (consumable.FeedingPoints + CurrentFeedingPoints);

     if (estimatedFeedingPoints > PointsToSatiateHunger)
     {
       estimatedFeedingPoints = PointsToSatiateHunger;
     }

     CurrentFeedingPoints = estimatedFeedingPoints;

    // Hidratación
    float estimatedHydrationPoints = (consumable.HydrationPoints + CurrentHydrationPoints);

    if (estimatedHydrationPoints > PointsToHydrate)
    {
      estimatedHydrationPoints = PointsToHydrate;
    }

    CurrentHydrationPoints = estimatedHydrationPoints;

    // Estimulante
    float estimatedStimulationPoints = (consumable.StimulationPoints + CurrentStimulationPoints);

    if (estimatedStimulationPoints > PointsToAlleviateSleep)
    {
      estimatedStimulationPoints = PointsToAlleviateSleep;
    }

    CurrentStimulationPoints = estimatedStimulationPoints;
  }
 }

 /// <summary>
 /// Consumir una bebida.
 /// Modificará el estado de supervivencia del individuo, normalmente afectando a su hidratación.
 /// </summary>
 /// <param name="drinkSource">Fuente o surtidor de bebida.</param>
 public void Drink(IDrinkSource drinkSource)
 {
   if (drinkSource != null)
   {
     GameObject drinkCandidate = GameObjectFactory.GetSample(drinkSource.DrinkType);

     if (drinkCandidate is Drink)
     {
       Drink drink = (Drink)drinkCandidate;
       Consume(drink);
     }
   }
 }

 /// <summary>
 /// Beber o dar un sorbo de un contenedor de bedida, por ejemplo, una cantimplora.
 /// </summary>
 /// <param name="drinkContainer">Contenedor de bedida del que se va a dar un sorbo.</param>
 public void Drink(DrinkContainer drinkContainer)
 {
   if (drinkContainer != null)
   {
     if (!drinkContainer.IsEmpty())
     {
       drinkContainer.Use();
       Drink(drinkContainer as IDrinkSource);
     }
   }
 }

 /// <summary>
 /// Dormir un tiempo limitado.
 /// Modificará el indicador de sueño del individuo.
 /// </summary>
 /// <param name="sleepTime">Tiempo de descanso o sueño (en segundos).</param>
 public void Sleep(float sleepTime)
 {
   float calculatedPointsBySecond = sleepTime * SurvivalStatusEngine.GetRecoveryPointsWhenSleep(this);
   float estimatedStimulationPoints = (CurrentStimulationPoints + calculatedPointsBySecond);

   if (estimatedStimulationPoints > PointsToAlleviateSleep)
   {
     estimatedStimulationPoints = PointsToAlleviateSleep;
   }

   CurrentStimulationPoints = estimatedStimulationPoints;
 }

...

}

Los tres indicadores de supervivencia (hambre, deshidratación y sueño) tienen un valor que va disminuyendo con el tiempo, cuando cualquiera de estos llega a 0, el concursante se desmaya y pierde la partida. Para impedir que eso ocurra, el concursante debe consumir ciertas cosas para aumentar dicho valor. Estas cosas son las que antes he llamado consumibles.

 

Consumibles

En el videojuego, un elemento consumible es cualquier cosa que se puede consumir, como por ejemplo carne, agua, setas, fruta… Todos los consumibles tienen lo que llamamos puntos de supervivencia.

Puntos de supervivencia

Los consumibles otorgan puntos de supervivencia al consumirlos, aumentando el tiempo que el personaje puede aguantar sin desmayarse. Cuando hablamos de puntos usamos la siguiente nomenclatura:

  • Para saciar el hambre: puntos de alimento
  • Para hidratarse: puntos de hidratación
  • Para aliviar el sueño: puntos de estimulación

Por ejemplo, consumir moras añade 7 puntos de alimento a los indicadores de supervivencia del personaje. Esto aumentará el tiempo que tiene el concursante antes de desmayarse por hambre.

survival-stats-example

Es posible que un consumible pueda dar puntos a más de un indicador de supervivencia. Por ejemplo una naranja, otorga puntos de alimentación e hidratación.

Caducidad

Los consumibles pueden caducar, lo que significa que transcurrido su tiempo de caducidad se echan a perder y no se pueden consumir.

Actualmente tenemos deshabilitada esta opción por temas de jugabilidad. Creemos que es una mecánica más pesada que divertida y por el momento no la utilizamos.

Esto abre la puerta a otras mecánicas interesantes, como por ejemplo: si un consumible caducado se encuentra en un contenedor con otros consumibles, podría contagiar al resto y acelerar el tiempo que tardan en echarse a perder… Pero como he dicho, es una mecánica que de momento no vamos a utilizar 😛

El código de los consumibles

En nuestro código disponemos de una clase que representa este concepto de objeto consumible, a la que llamamos Consumable.

Las propiedades más relevantes son:

  • Puntos de alimentación: cantidad de puntos de alimentación que se obtiene al consumirlo.
  • Puntos de hidratación: cantidad de puntos de hidratación que se obtienen al consumirlo.
  • Puntos de estimulante: cantidad de puntos de estimulante que se obtienen al consumirlo.
  • Tiempo de caducidad: tiempo total que tarda en caducar.

Los métodos más relevantes son:

  • Comprobar estado de caducidad: indica si el consumible ha caducado.
  • Comprobar si caduca: indica si el consumible caduca. Hay consumibles a los que no aplica la caducidad en el videojuego, como por ejemplo el agua.
/// <summary>
/// Cualquier elemento que se puede consumir, como por ejemplo bebida, comida, estimulantes, etc.
/// </summary>
public abstract class Consumable : GameObject
{
 #region Constructor
 protected Consumable() : base()
 {
   if (BaseExpirationTime > 0)
   {
     float minExpirationTime = BaseExpirationTime * ((100f - ExpirationTimeMargin) / 100f);
     float maxExpirationTime = BaseExpirationTime * ((100f + ExpirationTimeMargin) / 100f);
     float expirationTime = CustomConstants.Random.Next((int)minExpirationTime, (int)maxExpirationTime);
     ExpirationTime = expirationTime;
     RemainingExpirationTime = expirationTime;
   }
 }
 #endregion

 #region Properties
 /// <summary>
 /// Margen en el que el tiempo de caducidad definido puede variar (en porcentaje).
 /// </summary>
 protected const float ExpirationTimeMargin = 10;

 /// <summary>
 /// Puntos de alimento que se obtienen al consumir esto.
 /// Sirven para saciar el hambre y mitigar la desnutrición.
 /// </summary>
 public abstract ushort FeedingPoints { get; }

 /// <summary>
 /// Puntos de hidratación que se obtienen al consumir esto.
 /// Sirven para saciar la sed y mitigar la deshidratación.
 /// </summary>
 public abstract ushort HydrationPoints { get; }

 /// <summary>
 /// Puntos de estimulación contra el sueño que se obtienen al consumir esto.
 /// Sirven para combatir el sueño, como la cafeína.
 /// </summary>
 public abstract ushort StimulationPoints { get; }

 /// <summary>
 /// <para>Tiempo base que tarda esto en echarse a perder, con el tiempo
 /// expirado no se puede consumir (en segundos).
 /// </para>
 /// <para>El tiempo real de caducidad queda definido por un margen pequeño
 /// que puede acortar o alargar la duración total.</para>
 /// <para>El valor 0 indica que no caduca.</para>
 /// </summary>
 public abstract float BaseExpirationTime { get; }

 /// <summary>
 /// Tiempo restante, que le queda al consumible para caducar o echarse a perder (en segundos).
 /// </summary>
 public float RemainingExpirationTime { get; set; } = 0;

 /// <summary>
 /// <para>Tiempo real que tarda esto en echarse a perder.</para>
 /// <para>Este tiempo no es constante, depende de un pequeño margen definido
 /// internamente que puede acortar o alargar la caducidad.</para>
 /// <para>Ver 'ExpirationTimeMargin'</para>
 /// </summary>
 public float ExpirationTime { get; protected set; } = 0;
 #endregion

 /// <summary>
 /// Obtiene el porcentaje actual de caducidad del consumible.
 /// Representa porcentualmente cuanto tiempo le queda para caducarse.
 /// </summary>
 /// <returns>Porcentaje restante antes de caducar.</returns>
 public float GeCurrentExpirationPercent()
 {
   return (RemainingExpirationTime / ExpirationTime) * 100f;
 }

 /// <summary>
 /// Indica si el consumible ha caducado.
 /// </summary>
 /// <returns>'Verdadero' si ha caducado, 'Falso' en caso contrario.</returns>
 public bool IsExpired()
 {
   return (IsExpirable() && RemainingExpirationTime <= 0);
 }

 /// <summary>
 /// <para>Indica si el consumible tiene tiempo de caducidad.</para>
 /// <para>Nota: Un consumible con una tiempo base de caducidad de 0 se considera no-caduco.</para>
 /// </summary>
 /// <returns>'Verdadero' si puede caducar, 'Falso' en caso contrario.</returns>
 public bool IsExpirable()
 {
   return (BaseExpirationTime > 0);
 }
}

La naranja sería un ejemplo de implementación de un consumible:

/// <summary>
/// <para>Naranja natural. Se obtiene del naranjo.</para>
/// <para>Datos orientativos del fruto: Calorías: 47; Agua: 87%</para>
/// </summary>
public class Orange : Consumable, IInventariable, IDamageDealer
{

...

 #region Inventariable
 public InventariableType InventariableType { get; } = InventariableType.Orange;

 public bool Stackable { get; } = true;

 public float Weight { get; } = 0.2f;
 #endregion

 #region Consumable
 public override float BaseExpirationTime { get; } = 0f;

 public override ushort FeedingPoints { get; } = 28;

 public override ushort HydrationPoints { get; } = 10;

 public override ushort StimulationPoints { get; } = 0;
 #endregion

 #region Damage Dealer
 public DamageSource DamageSource { get; } = new DamageSource(
 new Dictionary<DamageType, int>()
   {
     { DamageType.Crushing, 1 }
   },
   null);

 public bool CanBeHurled { get; } = true;
 #endregion
}

 

Colores

A cada factor de supervivencia le hemos asociado un color que permita identificarlo.

hunger-icon                        dehydration-icon                     sleep-icon
Hambre        
Deshidratación        Sueño

Utilizamos una clase que centraliza estos valores en forma de constantes, de manera que podamos cambiar estos valores de forma fácil si lo necesitamos.

Para elegir los colores hemos utilizado Adobe Kuler, una herramienta muy útil e interesante para buscar sintonía entre colores.

/// <summary>
/// Color base relacionado con el hambre.
/// </summary>
public static Color HungerColor new Color(139, 127, 89);
 
/// <summary>
/// Color base relacionado con la deshidratación.
/// </summary>
public static Color HydrationColor new Color(140, 190, 178);
 
/// <summary>
/// Color base relacionado con el sueño.
/// </summary>
public static Color SleepColor new Color(198, 168, 201);

Eso es todo (a alto nivel) en cuanto a diseño y programación sobre el sistema de supervivencia y los consumibles.

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

 

 

La Música – Primera aproximación

Hoy vamos a hablar de uno de los temas más interesantes y complejos de resolver al desarrollar un videojuego: la música.

Si te pidieran que tararearas una de las canciones de Star Wars, ¿podrías hacerlo? ¿Qué tal una de Indiana Jones? ¿Harry Potter? ¿Súperman (de las de Cristopher Reeves)? ¿James Bond? ¿Misión Imposible…? Ahora, ¿qué tal si te pidiesen tararear la canción de Tomb Raider? ¿Mass Effect, Halo? ¿Qué tal Sonic? ¿Qué tal Chronno Trigger? ¿Zelda? Seguramente te habrá resultado más fácil recordar los temas de las películas que los de los videojuegos, no sólo porque tendrán más tiempo desde que fueron introducidas a la cultura, sino porque también fueron utilizados con un propósito mucho más deliberado e íntimamente relacionado con la narrativa y con el impacto emocional de una secuencia de escenas desplegadas en la pantalla.

En los videojuegos, la metodología es fundamentalmente diferente. Existe una variable enorme con la que ningún otro medio debe ni ha debido lidiar antes: el jugador; aleatoriedad, opciones para que la persona haga. Si la música permite permite provocar cambios en las emociones y estado anímico de las personas, ¿cómo puede un videojuego incorporarla efectivamente cuando hay un sinnúmero de secuencias lineales que seguir? Tal vez esa condición es la que ha hecho que, a pesar de como dice Jack Wall (el compositor de los primeros Mass Effect) “la música es el personaje invisible. Es la emoción detrás de las acciones del jugador.”, la música sea considerada no fundamental, accesoria, y en algunos casos hasta decorativa en un videojuego. ¿Cómo la haces parte de la historia si no tienes certeza de cómo se va desplegar esa historia?

Por supuesto, mientras más control tengas sobre la linearidad, más efectivamente podrás usar la música, como una película. Red Dead Redemption, por ejemplo, cuyo soundtrack es aún alabado por la crítica y jugadores por igual, tiene una historia bastante lineal en la que la música puede planificarse casi como si fuera un evento cinemático. Cuando el jugador llegue a el punto P, ejecutar tema T. Journey (cuya creadora Kellee Santiago ha dicho que los videojuegos serán, como medio expresivo, más poderosos en el siglo XXI que la radio, el cine y la televisión juntos) en cambio, utiliza la música (así como su ausencia) no sólo de manera muy efectiva para la narración, sino como aspecto fundamental de la experiencia: es el mejor ejemplo de lo que se denomina Música Adaptativa. Ella responde a las acciones del jugador,  al ambiente, a la existencia de otros jugadores on-line y a los “mensajes” con los que el jugador se comunica; sin embargo, al igual que Red Dead Redemption sigue siendo una historia lineal donde puedes, con sus innumerables sutilezas, guiar al jugador hacia un estado emocional.  La pregunta que se me ocurre es, ¿cómo puedes utilizar la música de forma creativa y a la vez efectiva, en un juego como Sticks & Stones, donde la generación aleatoria y el re-juego son esenciales, donde no hay forma de saber cómo avanzará el juego? Es fácil poner una canción encima, con suficiente variedad y longitud para que no se fatigue el jugador, pero ¿podríamos hacer algo más interesante que eso?

¿Qué alternativas tenemos?

Música pre-renderizada.

En la música pre-renderizada, secciones musicales, grabadas a partir de instrumentos musicales reales o virtualizados a través de DAWs (Digital Audio Workstations) son invocadas desde el motor del juego directamente, a través de una interfaz especialmente diseñada para la reproducción de música. En XNA, si quisieramos que sonara cierta canción cuando el jugador crafteara algo interesante, o si quisiéramos que sonara siempre de fondo, haríamos algo como:

protected Song song;
song = Content.Load<Song>("crafting_success");
MediaPlayer.Play(song); 

Simple, ¿no? Sí, pero demasiado simple. Es una manera de incorporar música en XNA, pero no necesariamente la mejor. Por ejemplo, MediaPlayer.Play() permite sólo una instancia a la vez, de modo que cualquier técnica de música adaptativa, (como horizontal re-sequencingvertical re-orchestration, ya hablaremos más adelante de ellas…)  se hace imposible de implementar. Es decir, siempre podremos cambiar una canción por otra (un momento de tensión pasando a uno de relajación) pero no podremos hacerlo sin cambios abruptos ni interrupciones que saquen al jugador de su estado inmersivo. De hecho, una de las consideraciones que surge de aquí es que hace falta pensar en el audio en general en más que sólo su reproducción o como una lista de assets. Hay que pensar en cómo el todo el audio (efectos de sonidos + música) funcionan juntos dentro del juego, no como items discretos, sino continuos, que son ejecutados y modificados de acuerdo a ciertas condiciones.

Por ejemplo: si en Sticks & Stones, Ferguson pudiera conducir un automóvil y acelerara y redujera la velocidad, habría falta de mucho más que sólo un MediaPlayer.Play(engine): habría necesidad de una interfaz que modificara el sonido para cuando aumentaran y descendieran las revoluciones del motor:

Estas interfaces, o middleware, son asociados generalmente con la implementación de efectos de sonidos y de ambiente, pero en realidad están preparadas para resolver por completo las necesidades de audio de un videojuego. Existen tres especialmente populares:

  • XACT (de Microsoft, gratis para uso comercial, relativamente simple de usar pero compatible sólo con plataforms  Windows y Xbox).
  • FMOD (de Firelight Technologies, gratis para uso no comercial).
  • Wwise (de Audikinetic, gratis para uso no comercial).

Para el caso de la música, se podría alternar entre el estado natural del personaje (como cuando Mario explora en Super Mario Bros) y un estado excepcional (cuando agarra una Estrella) sin tener que interrumpir una canción y sustituirla por otra. En cambio, podría aprovecharse uno de los tiempos débiles o un silencio en la canción para hacerle fade-out a una y fade-in a la otra transparentemente.(no es que así se haga en Super Mario Bros., ahí todo se interrumpe, pero por ejemplo…)

Música a partir de Datos Musicales.

MIDI (Musical Instrument Digital Interface) es un protocolo de comunicación a través del cual se pueden enlazar instrumentos musicales electrónicos entre sí y con ordenadores y otros dispositivos, transmitiendo información sobre tono, velocidad, volumen, dinámicas y vibratto de un sonido.  La manera más simple de entender MIDI es como una pianola: la música que es reproducida está limitada por la cantidad de información que puede codificarse en un rollo de papel, y la habilidad del piano para reproducirla.

Un ejemplo inevitable del uso de MIDI en videojuegos es el de iMUSE de LucasArts: utilizado por primera vez en Monkey Island 2: LeChuck’s Revenge, el sistema permitía manipular el contenido de la música directamente dado el estado actual del videojuego. Podía introducir melodías, modificar el tempo, cambiar la instrumentación, transponer claves. Sin embargo, para la última versión del 2013, iMUSE manipulaba la manera en la que música pre-renderizada era utilizada por el motor del videojuego: MIDI, con todas sus ventajas, aún posee inconvenientes considerables: requiere de grandes espacios de memoria para una librería de efectos si se quiere que la música sea suficientemente sofisticada y expresiva, y no puede compararse con la flexibilidad de un entorno completo de mezclado para la obtención y  de resultados de calidad.

¿Y Sticks & Stones entonces?

¡No sabemos! O no lo hemos decidido aún… El contexto habla de un programa de televisión superpuesto sobre entornos naturales. Existe la opción de un sonido ambiental natural, con aves y animales en la distancia rugiendo y cantando cada cierto tiempo, mezclados con el crujir de las hojas de árboles en el viento o bajo los pies de los personajes, o con la aparición imprevisible de elementos de alta tecnología como hologramas, Holo-balls, el cercado eléctrico… También podría diseñarse en los términos estruendosos y sobresaturados de un programa de concursos de televisión, apareciendo para recordarle al jugador del contexto, con un presentador, el Tema del concurso, las señales auditivas diegéticas para los personajes… O más interesante (o peligrosamente), podríamos explorar el concepto de Música Generativa, aprovechando la creación aleatoria del entorno (Perlin Noise + Poisson Disk) para también generar la música que acompaña al jugador. Se ha hecho antes, pero de nuevo, el problema, como con todo lo procedural, recae en la misma pregunta de siempre: de acuerdo, esto es música, pero ¿es acaso música interesante?

Ya iremos avanzando…

Mientras tanto, les dejo con esta versión del que debe ser el tema más intrusivo en la historia de los videojuegos, y que sin embargo, tal vez por nostalgia, todos apreciamos:

 

Sistema de Crafting

En este artículo hablaré sobre el sistema de crafting que hemos diseñado para Sticks & Stones, pero antes de entrar al detalle, analizaré a alto nivel un par de videojuegos con modelos de crafting distintos.

 

minecraft-icon Minecraft

El rey del crafting, su nombre ya lleva escrita la mecánica que forma el pilar central del juego.

Su sistema consiste en combinar objetos en una cuadrícula de NxN, dónde la posición en la que se colocan los objetos dentro de la cuadrícula es importante. Además tiene cientos de combinaciones distintas.

minecraft-crafting

Para descubrir una receta –un ítem u objeto– debes imaginarte de que materiales está compuesto y que forma tiene.

El jugador puede llegar al resultado aplicando la lógica, así que podemos decir que todas las combinaciones que nos permite el juego son lógicas, pero no todas las combinaciones lógicas que se le ocurran al jugador tienen un resultado. Es decir, el jugador podría llegar a sentir frustración si cree haber encontrado una combinación razonable y no consigue nada, pero por otro lado, descubrir una nueva receta puede ser muy gratificante.

En definitiva, nos encontramos ante una original y difícil mecánica de crafting, con un catálogo de recetas muy amplio (más de 100) y con un alto grado de satisfacción y frustración.

 

how-to-survive-icon  How To Survive

En How To Survive el crafting no tiene tanto peso como en Minecraft. Ofrece un sistema de elaboración de recetas diferente, por lo que es un buen ejemplo para contrastar.

Nos encontramos ante una mecánica basada en combinaciones binarias, es decir, combinar objetos de dos en dos.

Durante el proceso de crafting, es posible crear recetas sin utilidad directa en el juego, pero que combinando con otros objetos puede llegar a obtenerse una receta útil.

howtosurvive-crafting-chainsaw

Una detalle particular de su sistema, es que una misma receta puede elaborarse con diferentes combinaciones. Por ejemplo, la cuchilla de hueso puede obtenerse de un hueso + cualquier cosa que sea cortante.

howtosurvive-crafting-bone-blade

Cuando se quiere combinar un objeto, el juego te marca en el inventario aquellos que son compatibles, por lo que reduce la frustración del jugador al crear combinaciones que no funcionan.

howtosurvive-craft-arrow

Además, conforme se avanza en el juego se van desbloqueando algunas recetas que quedan guardadas en un diario de supervivencia para poder consultarlas.

How To Survive tiene una mecánica de crafting sencilla, con tendencia a simular combinaciones reales de materiales y herramientas para elaborar las objetos. Dispone de un catálogo de recetas inferior a 100 elementos y tiene un equilibrado grado de satisfacción y frustración.

 

Comparativa: Minecraft vs How To Survive

Como resumen al análisis de ambos sistemas de crafting, añado una tabla comparativa de algunas de sus características:

minecraft-vs-howtosurvive

Esta comparativa no quiere indicar que un juego tiene mejor sistema que otro, simplemente pone sobre la mesa información para ver que existen diferentes modelos de crafting que pueden funcionar.

Lo importante es saber encajar el modelo adecuado con el tipo de juego.

 

Modelo de Sticks & Stones

Lo primero que hicimos fue analizar el sistema de crafting de otros juegos, como por ejemplo los explicados en el artículo. Y luego analizamos las características del nuestro, para ver qué modelos encajaban mejor.

Sticks & Stones, como buen Rogue-Like que es, necesita potenciar la dificultad así como alargar la curva de aprendizaje. El objetivo es que el jugador deba repetirlo varias veces y en cada partida aprenda algo nuevo.

Pero también es un juego de acción, lo que implica que el sistema de crafting debe ser ágil.

El enfoque

Para cubrir el aspecto de la dificultad, creemos que las recetas deben ser descubiertas por el jugador a medida que prueba combinaciones. Como no tendrá disponible el catálogo de todo lo que se puede hacer, hemos pensado en la posibilidad de que existan recetas básicas aprendidas desde el inicio. Esto ayudará a que el primer contacto con el videojuego sea más asequible.

Para hacer ágil el crafting, las recetas que se descubran quedarán guardadas. De esta forma, es el jugador el que va creando su propio catálogo.

Pero… ¡Basta ya de cháchara! ¡Vamos a ver algo!

sticksandstones-crafting

En nuestro modelo de crafting distinguimos entre dos elementos: ingredientes y herramientas. Lo mas importante es entender la diferencia:

  • Ingredientes: son los elementos que al combinarse producen el nuevo objeto. Desaparecerán del inventario del concursante tras la elaboración.
  • Herramienta: es el elemento necesario para poder elaborar la receta, pero no se consume tras la elaboración, y por tanto, permanecerá en el inventario del concursante.

Una receta puede elaborarse a partir de la combinación de 1, 2 o 3 ingredientes y 1 herramienta.

En algunos casos, con una misma combinación de ingredientes y herramienta pueden obtenerse hasta tres recetas distintas. Lo que distingue una de otra, es el proceso de elaboración. Por ejemplo, para hacer flechas de madera se requiere lo mismo que para hacer una lanza de madera: una rama dura y una herramienta cortante.

Queremos recetas intuitivas, para que el jugador pueda deducirlas, pero tenemos un espacio limitado, un máximo de cuatro elementos entre ingredientes y herramienta. Esta decisión la tomamos pensado en que fuera ágil, así que en ocasiones tenemos que diseñar recetas simplificadas.

 

Conclusiones

Diseñar un buen modelo de crafting es difícil. Si además hay que encajarlo con las características del videojuego, aún lo complica más… Y si aún así se quiere innovar, la tarea se vuelve titánica.

Para finalizar, comparto algunas de las preguntas más críticas que nos han ido acompañando a lo largo del proyecto:

  • ¿Es compatible unir acción y crafting?
  • ¿Es arriesgado innovar en un nuevo sistema de crafting?

Estaré encantado de recibir tus comentarios y discutir sobre el tema.

 

 

 

El reto de combinar ciertas mecánicas

Desde el primer día en que la idea de juego afloró en nuestras cabezas y el juego empezó a ser “el juego”, Stick and Stones nos supuso un GRAN reto. Este reto no era nada más que hacer funcionar las mecánicas core que habíamos planteado.

Para ponerte en contexto, voy a explicar a muy alto nivel en qué consisten. Empecemos:

CRAFTING
El crafting es una mecánica que nos permite obtener objetos complejos a partir de unos más primarios – Un ejemplo básico sería combinar una rama con una cuerda y un sílex, para obtener un arco.

crafting

SUPERVIVENCIA
El hambre, la sed y el cansancio son indicadores en los que habrá que cuidar durante toda la partida, ya sea comiendo, bebiendo o descansando.

survivor

ROGUE-LIKE
Este es el más complejo de explicar y de entender, ya que se trata de una suma de conceptos y no una mecánica per se. Voy a describir los más importantes:

  • Alta dificultad – El juego es difícil. Requiere de una pericia importante para poder progresar, con lo que el GameOver será nuestro compañero inseparable en esta aventura.
  • Muerte permanente – Significa que cuando nos aparece el GameOver, deberemos empezar desde el principio del juego y perderemos cualquier avance obtenido. En resumidas cuentas no hay punto intermedio de guardado.
  • Generación procedural – Tanto la composición de las pantallas, como la localización de los objetos, enemigos y demás, son totalmente distintas en cada partida. El objetivo de esto es que el jugador nunca gane por memorizar las cosas sino por que realmente ha aprendido a jugar.

Estos 3 conceptos (alta difultad, muerte permanente y generación procedural), provocan que el juego se convierta en mucha prueba-error o lo que es lo mismo – un juego de repetición.

repeticion

Una vez que tengamos claro lo que implican estas 3 mecánicas, podemos sacar las siguientes conclusiones:

  • Rogue-like (juego de repetición)
    • Empezar de cero – Esto lo convierte automáticamente en un juego en el que tenemos que repetir una y otra vez lo mismo, y siempre empezando desde cero (y con las manos vacías).
    • Zonas pequeñas – Asimismo, si tenemos que repetir una y otra vez lo mismo, es altamente recomendable que las zonas de juego sean pequeñas y que se puedan recorrer en no mucho tiempo, para que estas no se hagan pesadas.
  • Crafting
    • Construcción progresiva – Para poder construir los objetos más avanzados habrá que pasar siempre primero por los primarios. Eso se traduce en que cada vez que se empiece a jugar, se deberá recolectar la rama, la cuerda y el sílex para poder construir el arco.
  • Supervivencia
    • Sensación de exploración – La clave para una buena supervivencia es la sensación de que los recursos para paliar la sed, el hambre y el cansancio, están por ahí y hay que buscarse la vida para dar con ellos.

Como si fuera una operación matemática, hemos ido abstrayendo más y más la esencia de cada mecánica, obteniendo la siguiente contradicción:

Rogue-likeEmpezar desde cero – VS – CraftingConstrucción progresiva
El problema aquí es que puede llegar a cansar el tener que pasar siempre por las mismas fases del crafting, recolectar ingredientes, craftear, recolectar ingredientes, craftear, …

Rogue-likeZonas pequeñas – VS – Supervivencia – Sensación de exploración
El problema aquí casi casi se lee solo. El juego tendrá zonas más bien pequeñas, pero la sensación de supervivencia se consigue con ambientes muy grandes para potenciar la necesidad de explorar.

Como puedes ver, cualquier decisión en el desarrollo de un videojuego, puede tener muchas afectaciones y futuros dolores de cabeza. En nuestro caso, tuvimos que estrujarnos bien los sesos para encontrar una solución que hiciera compatible estas, a priori, contradicciones… Pero eso te lo explicaré en otro artículo 😀

Muchas gracias por leernos, ¡y no dudes en compartir nuestro blog!