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.

Generación Procedural o cómo generar escenarios sexys

Querido lector. Si tienes curiosidad de ver cómo las matemáticas pueden ayudar a generar mapas aleatorios tan hermosos como el siguiente, ¡este es tu articulo! Agárrate que vienen curvas.

central-zone-2

En cada partida de Sticks & Stones, los mapas son diferentes, para que el jugador no pueda memorizarlos y haga uso de la habilidad y su experiencia para superarlos. Además, es un juego difícil, donde se repite una y otra vez lo mismo. Por lo tanto, la variedad es una característica esencial en la generación de mapas.

Crear pantallas lo más mutables, bonitas y orgánicas posibles, es una muy buena manera de conseguir esta variedad ¿Pero cómo se puede lograr esto? Con algo llamado generación procedural:

En computación generación procedural es el método de creación de datos con algoritmos en lugar de forma manual

Es decir, que para generar las pantallas es necesario recurrir a las matemáticas y a sus fórmulas. ¡Ah! Las matemáticas… yo siempre me preguntaba de pequeño que para qué diablos sirven las matemáticas en la vida… 😛

Volviendo al tema, para nuestra generación de mapas, hemos usado un algoritmo llamado Perlin Noise. Para entender su funcionamiento, vamos a imaginarnos una onda de radio. Y que mediante 3 parámetros (frecuencia, amplitud y octavas), podemos llegar a cambiar su apariencia. En el siguiente gráfico hay algunos ejemplos visuales:

perlinnoise

  • La frecuencia determina el número de ondas
  • La amplitud determina la altura de las ondas
  • Las octavas determina la suavidad de las ondas

Una vez explicado esto, vayamos a cómo implementar esta onda a nuestra generación de mapas. Para ello, primero vamos a crear celdas con texturas totalmente planas. En nuestro ejemplo vamos a usar un mapa de 3×3.

1

A continuación se genera un Perlin Noise de 3 dimensiones XYZ para cada una de las celdas. Donde la XY son las coordenadas del píxel, y la Z es la ALTURA.

En la siguiente animación tenéis 3 muestras de 3 generaciones distintas de Perlin Noise. Fijaos en lo diferentes que pueden llegar a ser unos mapas de otros. Para facilitar su visualización, se ha establecido una franja de color distinto a cada una de las ALTURAs.

5-7-6

Ahora solo falta establecer una relación entre ALTURATEXTURA. En este caso usamos la misma que utilizan los mapas topográficos,

world_map

Para nuestro ejemplo vamos a usar la siguiente relación:

[∞ .. 300] = Hierba
[0 .. -200] = Tierra
[-500 .. -700] = Tierra con piedras
[-900 .. ∞] = Agua (transparencia del 10%) 

Y estas son las texturas que vamos a usar para la generación:

texturas

Si metemos en una coctelera el Perlin Noise, las franjas de terreno y las texturas, obtenemos este resultado:

5-7-6

Si este proceso lo repetimos, variando únicamente uno de los valores base como puede ser la frecuencia, la amplitud o las octavas, el resultado puede llegar a cambiar bastante.

Amplitud = 1 (menos diferencia entre altura mínima y máxima)

5-1-6

5-1-6

Frecuencia = 1 (espacio entre cambios de altura más espaciados)

1-7-6

1-7-6

Octavas = 1 (transición entre alturas mucho más suavizada)

5-7-1

5-7-1

Mediante este sencillo proceso de configurar un Perlin Noise, estableciendo las franjas de terreno y texturas,  podemos obtener resultados como estos:

magma

meadowsnowedswampdesertwater

Llegados a este punto, lo único que falta por hacer es colocar objetos en el terreno, y para ello volveremos a usar la ALTURA y vincular en este caso OBJETOS (usando un % de aparición).

Veamos un ejemplo:

[∞ .. 500] = Árboles
[500..0] = Plantas, flores
[0 .. -200] = Rocas
[-500 .. -700] = Piedras, árboles secos
[-900 .. ∞] = Juncos

¡¡Y aquí tenéis el resultado!! forest

¿No es fascinante lo natural que parecen los objetos una vez colocados?

La ventaja de configurar todo el escenario en base al concepto de la ALTURA, es que si se desplaza la base de esta ALTURA, el escenario cambia:

forest

Si ahora le aplicamos un efecto de desenfoque en la parte superior e inferior, además de unos bonitos rayos de luz, obtenemos el aspecto que tiene en la actualidad el juego:

central-zone-2

Si te ha gustado el artículo: comenta y comparte.

¡Gracias!

¡Sticks & Stones en GreenLight! ¡Vótanos!

Estamos enormemente emocionados de compartir con vosotros que Sticks & Stones está ya en GreenLight.

greenlight

¿Qué es GreenLight?

Es el sistema que usa Steam para determinar qué juegos pueden venderse en su tienda online. Lo característico de este sistema es que es la propia comunidad la que elige esto. Publicas una campaña con imágenes, vídeo y una descripción de tu juego, y Steam propone una sencilla pregunta a los consumidores:

¿Comprarías este juego si estuviera disponible en Steam?

  • SI
  • No gracias / No me interesa
  • Preguntarme luego

Si disponéis de una cuenta de Steam, ayúdanos a conseguir el GreenLight y ¡VOTADNOS!

sticksstonesgreenlightpee

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!

El Motor del Videojuego – III

Contexto

Si acabas de aterrizar en el Blog, te recomiendo que antes de continuar que te dejes caer por aquí:

Así mismo recomiendo leer también las 2 entradas que hablan sobre YokaiEngine – el motor que estamos creando para desarrollar Sticks & Stones:

Auto-cast de objetos

El artículo de hoy se va a centrar en lo que llamo auto-cast de objetos de Flash a C#.

Para que me sea más sencillo de explicar en qué consiste el auto-cast, voy a recurrir de nuevo a nuestro personaje de ejemplo Sigfrid – El Paladín.

Imaginemos que hemos creado una animación en Flash y la llamamos paladin:

paladin_instance

Tal y como hemos hablado en anteriores artículos, el motor es capaz de replicar todos los objetos Flash y sus animaciones de forma recursiva, y reconstruirlos tal cual en C#.

Sólo basta con definir en la Screen de juego una variable del tipo CustomSprite (propia del motor) con el mismo nombre que hemos usado en el Flash:

public class Screen PlayableScreen
{
      public CustomSprite paladin; 
}

Y obtenemos lo siguiente:

paladin

Imaginemos por un momento que queremos acceder a cualquier parte de la animación, por ejemplo a la espada. Para ello deberemos realizar los siguientes pasos:

  1. Dar un nombre identificativo al objeto Flash
  2. Crear jerarquía de clases C# para definir padres-hijos

Vamos a asignar un nombre al objeto de la espada, en este caso le llamaremos weapon.

weapon_instance

Clases tipadas

Sigfrid, nuestro paladin, va a dejar de ser una clase del tipo CustomSprite (que es genérica) para pasar a tener su propia clase – PaladinCharacter. Lo que nos va a permitir poder definir dentro contenido propio:

public class Screen PlayableScreen
{
      public PaladinCharacter paladin; 
}
public class PaladinCharacter CustomSprite
{
      public CustomSprite weapon;
}

De esta manera ya podríamos tener acceso al arma a través del objeto paladin, y por ejemplo hacerla desaparecer:

public class Screen PlayableScreen
{
    public void RemoveWeapon()
    {
        paladin.weapon.Visible = false;
    }

no_weapon

Cuando el motor recrea los objetos del Flash, lo que hace es crear instancias automáticamente al tipo indicado en la definición de la variable. En nuestro caso:

  • paladin lo castea al tipo PaladinCharacter
  • sword lo castea al tipo CustomSprite

Recursividad

Esta técnica de auto-cast es recursiva y puede comprender todos los niveles que se necesiten. Profundizando más en el mismo ejemplo, podríamos tener la siguiente estructura:

public class PaladinCharacter CustomSprite
{
      public Weapon weapon;
      public Helmet helmet;
      public Shield shield;
}
public class Weapon CustomSprite
{
      public Blade blade;
      public Grid grip;    
      public CrossGuard crossGuard;
}
public class GripCustomSprite
{
      public Handle handle;
      public Jewel jewel;    
}

Listas

El auto-cast también funciona con listas. En el caso que tengamos más de un objeto del mismo tipo, por ejemplo los brazos (en este caso 2), en el Flash los identificamos con el mismo nombre acabado en número  (arm0 y arm1):

instance_arm

Ahora solo basta con tiparlo como una lista y ya:

public class PaladinCharacter CustomSprite
{
      public Weapon weapon;
      public Helmet helmet;
      public Shield shield;
      public List<Arm> arm;
}

Generar cualquier estructura jerarquizada de objetos es muy útil para poder realizar animaciones complejas y aún así tener el control total de acceso a cualquier objeto (para poder realizar la transformación).

 

¡Si te ha gustado compártelo! :]

Screenshots – II

No hace apenas ni un mes que adjuntamos algunas capturas del aspecto que tenía el juego en ese momento. Como ya avanzamos, ese aspecto era totalmente temporal, ya sea por que aún faltan incorporar muchos de los elementos que queremos o bien por que algunos son temporales.

screenshot_2

Desde entonces, hemos estado trabajando muy duro para impregnar a las pantallas de un aspecto más orgánico y natural.

Creemos que estamos un paso más cerca del resultado final que buscamos. En otro artículo ya os explicaremos en qué consiste este nuevo sistema de generación procedural, pero para abrir boca os dejo algunas capturas del resultado conseguido hasta el día de hoy.

– Bosque –
screenshot_forest

– Pantano – screenshot_swamp

¿Qué opinas del cambio? ¡Deja tus comentarios! 😀

El Motor del Videojuego – II

Hace unas semanas publiqué el artículo – El Motor del Videojuego – I, en el que explicaba:

  • El uso de un motor propio para el desarrollo de Sticks & Stones
  • Y la facilidad para ajustar el arte en cualquier etapa de desarrollo

El artículo de hoy pretende profundizar un poco más sobre las virtudes del motor, y más concretamente, lo que yo llamo: Transformación de objetos en tiempo real.

Vamos allá.

Una de las grandes aportaciones del motor, es la capacidad de replicar las animaciones de Flash al videojuego, sin que se requiera añadir una sola linea de código.

paladin

FLASH

Cuando realizamos animaciones en Adobe Flash, es altamente recomendable usar siempre objetos separados, tanto para dibujar como para animar. En nuestro caso, y continuando el ejemplo del anterior artículo, vamos a usar el Paladín, asignando a cada parte un nombre distinto.

paladin

paladin2

JUEGO

Ahora, desde cualquier punto del código, podríamos acceder a estos objetos mediante su nombre, y poder transformarlos como queramos.

Para que podáis ver cómo se aplican estas transformaciones en tiempo real, he grabado unos vídeos con la ejecución del juego, dónde voy aplicando transformaciones mediante accesos rápidos:

INTERCAMBIO

Permite poder sustituir un objeto por cualquier otro.

intercambio

 

TRANSPARENCIA

Se le puede asignar un % de transparencia a cualquier objeto.

transparencia

 

ROTACIÓN

Podemos rotar cada una de las partes 360º.

rotation

ESCALA

Se puede aumentar o reducir la escala de cualquiera de los objetos.

escala

VELOCIDAD ANIMACIÓN

Podemos indicar mediante un % la velocidad de reproducción de las animaciones.

velocidad

COLOR

Se puede tintar el color original de las texturas.

color

Como podéis ver, estas transformaciones nos abren las puertas a casi cualquier posibilidad y combinación que nos imaginemos…

Espero vuestros comentarios, y en futuros artículos iré detallando otras funcionalidades del motor.

¡No nos dejéis de recomendar! 😀

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!