Godot Engine: ¿Cómo crear una Máquina de Estados? II

¡Buenas noches! O mañana. Hoy terminaremos de crear nuestra Máquina de Estados.. sí, quizás sea incluso más trabajo que en la primera parte.

Antes de continuar, quiero avisar que ya hay dos repositorios publicados: el primero fue, como dije en mi artículo pasado, la Máquina de Estados. Por último esta el proyecto de plataformas completo. Dejaré los respectivos enlaces:

Oh, casi lo olvido: la primera parte de este tutorial se encuentra aquí.

Scripts importantes, y los estados de la máquina.

Vuelvan sobre su jugador. Es hora de que añadan un nodo llamado “Node”, y lo nombren «StateMachinePlayer» o algo por el estilo. El nodo «Node» es de las mejores opciones, ya que no utiliza otras funciones de nodos que puedan retrasar el rendimiento de nuestra Máquina de Estados.

El nodo principal de la máquina, tendrá como hijos directos otros nodos del mismo tipo, con el nombre de su respectivo estado. Por ejemplo: (Walk, Idle, Jump). Después les colocaremos un Script que se encargue de cada comportamiento, pero eso después.

Ahora que tenemos los nodos, los dejaremos ahí. Es necesario que hagamos un Script que se pueda usar en cualquier otro personaje que posea una Máquina de Estados. Un Script que sea la máquina de estados en sí. Con eso, simplemente tendremos que usar un “controlador” dentro de cada nodo que tenga la máquina de estados. Si no lo hacemos así, tenderemos a escribir más código del necesario, al momento de añadir una Máquina de Estados a cualquier otro personaje del mismo proyecto.

Ese Script lo crearemos de la siguiente forma:

Les mostraré lo que deben colocar dentro, y explicaré cada parte:

El diccionario “states_map” se encarga de guardar la dirección de todos los nodos que sean “estados” de la máquina. Ahora la dejamos vacía, pero en el “controlador” que se encuentra dentro de cada personaje, cuando llegue el momento, le daremos un valor. Por otro lado, “current_state” recibe el estado actual, y la “_active” es para el encendido y apagado de la máquina.

Para las funciones sí enumeraré una lista, vamos por ello:

  1. _ready(): Esta es muy simple. Todos los estados de la máquina van a disponer de una señal llamada “finished”. Es necesario que estén conectados a nuestra función de “change_state”, para que cada vez que termine un estado (“finished”) la máquina reciba la llamada y cambie al nuevo estado. Nota: los “hijos” son los nodos que creamos arriba, pronto les asignaremos un script con la señal “finished”.
  2. _input(event) and _physics_process(delta): Llegando a esta parte se darán cuenta de que usamos “current_state”. Sepan que esa variable guarda un nodo (cuando no es null). Ese nodo es uno de los estados, y todos los estados cuentan con una función llamada “handle_input(event)” y “update(delta)”. Sí… son un reemplazo de la función _input() y _ physics_process. No usamos las funciones “originales” dentro de los estados, porque crearía conflictos al manejar diferentes modos del parámetro “Event” y el tiempo “Delta”. Así como lo tenemos ahora, estamos usando un único valor que sale desde la Máquina de Estados.
  3. change_state(state_name): En esta función cambiamos los estados. Lo primero que se hace es comprobar que la máquina esta activa. Después, el estado actual se actualiza por la búsqueda que se realice en nuestro diccionario de mapas. Por ejemplo, sabiendo como funcionan los diccionarios en GDScript, para buscar el nodo “Idle”, tenemos que colocar la clave con la que guardamos ese estado. Esa clave es el “state_name” y cada vez que se emite la señal “finished”, se pasa un valor con el nombre del nuevo estado de la máquina. Tal que así: “emit_signal(‘finished’,”Idle”)”. Para finalizar, lo último es activar la función “enter” del estado actual. Seguro lo adivinas: “enter” es el reemplazo de los estados para “ready”.
  4. set_active: Otra papaya. Simplemente se encarga de activar o desactivar las funciones cuando llamemos a la función “set_active(true or false)”.

Perfecto, o casi perfecto. Puede que falten cosas por mejorar, pero ahí vamos aprendiendo. Por ahora nuestro código para la Máquina de Estados esta listo. Así como tenemos un script principal para la máquina, necesitamos uno para los estados. Cada estado independiente podrá heredar las funciones principales sin necesidad de repetir código.

Crearemos el script de la misma manera que el primero. Miren ahora, este es el código que tengo yo:

Muy corto. Primero creamos la señal “finished”. Recuerden que la invocamos en todos los estados, dentro del script de la máquina. Cuando usamos unos paréntesis para la señal, estaremos indicando que es necesario mandar un valor, cada vez que emitimos la señal. Nosotros generalmente haremos esto: “emit_signal(“finished”, “State_Idle”)”.

De resto, se darán cuenta que son las funciones que llamamos en el otro script. En el nodo principal no tienen importancia, sólo las colocamos para que estén creadas por defecto cada vez que añadamos un estado en nuestra máquina.

Controlador de la máquina dentro del jugador

Ya estamos terminando con nuestro trabajo. Vamos a crear el script del “controlador” de la máquina, en el nodo “StateMachinePlayer” que creamos al principio de este artículo. Aquí el código:

Fíjense que en donde dice “extends” he borrado la palabra “Node” y lo he reemplazado por la ruta que tiene el script de la Máquina de Estados principal dentro del proyecto. Eso hará que el código del otro script, forme parte del controlador, sin tener que escribirlo.

Ya que tenemos esto, pasemos a la función _ready(). Aprovechando que sólo se ejecuta una vez, pasaremos el nombre de cada estado (la clave), y su respectiva dirección dentro del jugador. Como son hijos del controlador, sólo hay que usar el signo “$” y escribir el nombre del estado, que generalmente es el mismo que la clave. Por último en esa función, usamos la función change_state(“Idle”) para decir que el primer estado en que se encontrará el jugador será el “Idle”.

Repetiremos una vez más la función change_state(state_name), y en su primera línea colocaremos un “.” y repetiremos el nombre. Con el “.” estamos accediendo a la función “change_state” que se encuentra arriba del script del controlador, osea en el script principal de la máquina, que se extiende sobre el controlador… haciendo eso, podremos procesar el estado con el código principal, que escribimos hace un rato. Nota: las últimas dos líneas no tienen importancia, son otra cosa.

Los estados independientes

Para esta parte necesitamos aplicar algo de lógica. Primero: el estado inicial es “Idle”. Por lo tanto, a partir de él deben salir otros estados: como el salto, el movimiento y el ataque. Sólo vamos a poder ejecutar un sólo estado a la vez. Un ejemplo sería que, cuando entremos en el estado del movimiento, sólo podremos salir cuando, dentro de su mismo código, demos instrucciones para que pasemos a otro estado, por ejemplo, el salto.

Empecemos pues, añadiendo el script del estado “Idle”:

¿Recuerdan cuando les dije que añadieran una animación para cada estado? Ya en la función _ready podemos decir (aunque esto es opcional y ustedes pueden hacer lo que quieran) que la animación “Idle” se reproduzca. Cuando usamos la palabra “owner”, estamos accediendo al nodo principal de la escena. En este caso el nodo principal es el KinematicBody2D del jugador, y uno de sus hijos, es el “Anim” que creamos en el artículo pasado.

Dentro de la función handle_input indicaremos que cuando se presione la flecha de arriba, compruebe que el “owner” osea el script del jugador, se encuentre en el piso. Si es así, puedes decir que el “estado a finalizado” y puedes “pasar al salto” (emit_signal(“finished”,”Jump”)). Desde ese momento, ya el script del Idle deja de ejecutarse, porque ahora el nuevo estado que estará ejecutándose será el salto.

Lo mismo pasaría si presionamos “Espace” y realizamos un ataque. Estaríamos cancelando el estado “Idle”, para pasar al “Attack”.

En la función update(delta) que se ejecuta en cada segundo, comprobaremos que la dirección del jugador no ha cambiado. De ser así significaría que queremos movernos, y emitimos la señal que llama al estado de movimiento.

Para los que quieran refrescar la memoria con respecto al código del “owner” o jugador, miren esta imagen del artículo pasado:

Esto, amigos míos, es todo lo que necesitan saber. Sólo falta que añadan el código de los otros estados y aprendan a salir de ellos para volver al “Idle”.

Continuemos, por ejemplo, con el código del “move_state”. Recuerden que casi todos los estados inician igual, y se extienden con la ruta del script de estados principal. Pasemos ahora al código que les quiero mostrar:

Todo igual ¿no?. Cuando el jugador tenga la dirección en 0 es porque ya esta quieto, y puede volver al estado “Idle”. Cuando saltas, cambias, etc. No veo complicaciones mayores. Igual si alguien tiene otra duda que no pueda resolver descargando el repositorio de la Máquina de Estados desde el enlace que dejé al inicio del capítulo, puede escribir un comentario. Con gusto lo ayudaré y actualizaré el artículo si es necesario.

Si te ha gustado el contenido, podrías ayudarme a seguir produciendo con una donación a PayPal o Patreon: https://www.paypal.me/joseleon1971?locale.x=es_XC&fbclid=IwAR2fl6Hg5ImDIBBv34BirPpfa7vL3QzZyEKN6E3LJibPYldSl9HO9yDGU-k

https://www.patreon.com/indielibre

Las donaciones me ayudan a estar conectado en Internet, en mi país es costoso. Cualquier cantidad, es aceptable :’).

Godot Engine: ¿Cómo crear una Máquina de Estados? I

¡Hola compañeros! Hace ya muchas noches de insomnio que empecé con el nuevo proyecto de plataformas. Quiero anunciar que ya se encuentra casi terminado, pero hoy me gustaría mostrarles algo diferente…

He dividido cada funcionalidad del juego en un paquete, como un Asset independiente, para que ustedes puedan tomar la parte que más les interese y puedan adaptarla a sus proyectos con facilidad. El primer Asset de estos que publicaré, será la Máquina de Estados que pueden usar para los personajes jugables, ya que la implementada en los NPC será diferente, incluyendo cosas relacionadas con la IA (Inteligencia Artificial)…

Esta noche les enseñaré a elaborar una máquina de estados en Godot Engine, así estarán preparados para el momento de descargar el Asset o, simplemente, sabrán los pasos para desarrollar su propia máquina. Sin embargo, puede que esto sea algo extenso, dividiré el tutorial en dos partes.

La escena del Jugador y los Nodos necesarios

¿Ya tienen identificado a su jugador? ¿Todas las animaciones de las que dispondrá? De ser así, podemos empezar a añadir los nodos que formarán parte de la Máquina de Estados. Miren este árbol de nodos, es mi jugador:

Ustedes deben decidir que tipo de nodo será la raíz de su jugador, el mio es un KinematicBody2D, por lo tanto también hago uso de un CollisionShape2D. Para controlar las imágenes del personaje uso unas hojas de sprites, divididas de la siguiente forma, que coloco en el nodo Sprite (llamado: Images):

Para animar las hojas de Sprites es necesario que también añadan un nodo AnimationPlayer, como ven en la imagen de arriba. El nodo de “BodyPivot” es un Position2D y después de crearlo, dentro de él añado el Sprite, ya que al momento de elegir la dirección del personaje (izquierda o derecha) parece más ordenado alterar un Position2D que el Sprite (Sin embargo, pueden prescindir del Position2D y usar únicamente el Sprite).

Antes de empezar con la máquina de estados…

Supongamos que todavía no crearemos la máquina de estados. Primero “prepararemos el terreno”: vayan al AnimationPlayer y empiecen a añadir una animación para cada “Estado” de la máquina.

Esta es mi animación de “Idle”. Algo que tienen en común todas las otras animaciones, es que tienen que cambiar la Textura (Asignando la hoja indicada para el estado Idle), los Hframes (El numero de frames horizontales) y la propiedad Frame (Esta cambiara cada microsegundo, y representa la imagen actual). Cuando ya cada Frame de la hoja ocupe un microsegundo, marquen el tiempo final y coloquen que esa será la duración total de la animación. Además activen las flechas que están a la derecha del tiempo total, (como yo, que las tengo en azul) para que la animación se repita. Sólo la tienen que desactivar en animaciones de un disparo, como la de Ataque.

Ahora les dejaré una imagen con todas las animaciones que voy a usar para mi máquina de estados:

Si no sabes usar el AnimationPlayer, puedes ver este tutorial de aquí, donde enseño sobre la animación de personajes usando hojas de sprites (Estoy por actualizar el Tutorial).

Llegamos al último paso antes de crear la máquina de estados. Vamos a añadir un Script para nuestro nodo principal. Aquí el mío:

Como ahora sólo tenemos a un personaje que salta, se mueve y ataca, no necesitamos muchas líneas. Sin embargo explicaré cada sección de mi Script:

  1. Variables: ahí se definen las variables que se encargaran de representar la física y las aceleraciones, tanto para el salto como para el movimiento. Estos últimos se expresan en “float” (números con decimales), o también en números enteros. La velocidad (velocity) es la variable que representa los cálculos del M.R.U (Física: Movimiento Rectilíneo Uniforme), es Vector2 porque necesita un valor para el eje horizontal y otro para el vertical.
  2. _physics_process(delta): como sabrán, esta función se ejecuta en cada frame del juego (hay como 30 frames por segundo). Dentro de ella llamo a una función que he creado para aplicar una gravedad constante todo el tiempo. Es más fácil aplicar desde el jugador la gravedad, que crear la misma función en los estados que necesiten hacer uso de ella.
  3. _input(event): esta función se ejecuta cada vez que el jugador presiona una tecla o, en caso de los teléfonos, toca la pantalla. Recibe un parámetro llamado event, que representa el botón exacto que fue presionado o el gesto que se realizó en la pantalla. Dentro de esta función estoy comprobando que flecha fue presionada, entre la izquierda y la derecha (como esta el código ahora, cuando se presiona la “izquierda” la variable vale -1, y cuando se presiona “derecha” vale 1). Según el resultado, la dirección de la imagen cambiará (Nunca debe valer 0, por eso uso esa condición en el if. De lo contrario, la imagen desaparecería). Nota: cuando cambias por números negativos la escala de un nodo, este se voltea. Osea que en mi código lo que hago es voltear la imagen. Ustedes pueden lograr un resultado similar si usan el método “flip_h = true” de los nodos Sprite2D.
  4. apply_gravity(delta): cada vez que inicia esta función se le suma al valor anterior de la variable que controla la velocidad vertical (velocity.y) el producto de multiplicar la gravedad por el tiempo físico (delta). Esto se sumará hasta que el jugador toque el suelo (if is_on_floor()), donde la velocidad vertical vuelve a ser 0. La función move_and_slide() se usa para mover al jugador según una fórmula física que haga uso de la Velocidad. Pero también hay una alternativa que permite usar unicamente el resultado de la Distancia… Sin embargo esos son otros temas, y creo que ya sabían bien que es el move_and_slide(). Cuando el get_slide_count() no sea 0, significará que el jugador esta colisionando con algo. Entonces comprobaremos que este chocando por debajo del cuerpo para decir que la velocidad vertical vuelva a 0. Si no hacen eso, notaran que cuando chocan debajo de un bloque, el jugador se queda en el aire un tiempo.

Muy bien. Después de esto ya el siguiente paso sería añadir los nodos de la máquina, junto con el código que necesitan para funcionar. Por hoy hemos finalizado la primera etapa. ¿Qué les ha parecido? Me estaban reprochando hacer siempre un enfoque básico, redundando en muchos temas… ahora quiero ver que tal queda este “nivel” de dificultad, donde doy por hecho que ya saben de algunas cosas para seguir el artículo.

Avanzando con el desarrollo de un juego de plataformas

¡Buenas noches compañer@s! Ayer se empezó el desarrollo del nuevo proyecto de plataformas que planeo publicar en Itch.io, GitHub y Godot Assets Library, como Software Libre. El desarrollo del mismo es radicalmente diferente a mi «juego» de plataformas pasado: tratando de suprimir la mayoría de problemas lógicos mientras se trabaja con mejores mecanismos para proyectos generales.

Sin más, dejaré las publicaciones que forman una especie de «camino», durante el desarrollo de los Assets y el proyecto:

¿Por qué hago un artículo para hablar sobre una fase tan temprana?… supongo que en esto se basa el DevLog, y aunque esto sea mi primer paso, la máquina de estados es un tema muy interesante e importante. Además, aprovecho para hablar un poco más sobre esos Assets que puse arriba:

PD: Este artículo se escribió cuatro días atrás, pero perdí la electricidad desde ese momento y vuelvo hoy para publicarlo.

¿Qué es ese paquete de Assets?

Muy bien, desde el principio: seguro algunos ya saben que estoy muy emocionado con practicar Pixel Art y hacer mis propios gráficos. Ese pasatiempo se complementó perfectamente con mi entusiasmo dentro de la programación de juegos, y desde entonces he buscando la forma de dibujar, programar y escribir, para ser feliz y útil dentro de mi trabajo. Ese «pack» es la primera fase del proyecto que he ideado para este mes (y parte del siguiente).

¿Cuáles son esas fases?

La primera fase corresponde al dibujo/Pixel Art: se elaboran todos los recursos importantes que podrán usarse para formar juegos más adelante.

Después, la segunda fase es la programación de una «plantilla» o «demo», que haga uso de los Assets para desarrollar un prototipo jugable que pueda ser difundido por todos como material educativo; permitiendo su lectura, cambio y distribución por parte de cualquier usuario (Software Libre).

Por último, seguro una de las cosas mas interesantes, es tomar ese demo desarrollado y explicar, paso por paso, sobre el desarrollo del mismo… sí, esto toma el nombre de «Curso» y «Tutoriales».

¿Qué generará ingresos?

Estuve dándole vueltas a la publicación de contenido pago, pero no creo que sea necesario. Es probable que pueda alcanzar al público anglosajón y reciba donaciones que me permitan continuar con el desarrollo de nuevos proyectos. Teniendo en cuenta que los Assets y proyectos de código abierto son algo que les beneficia, sin importar que sea hispano.

¿Cuáles son las mecánicas que se introducirán?

Unos días atrás pregunté por algunos temas que puedan resultar de interés para ustedes. Tengo entendido que debería abarcar la inteligencia artificial de enemigos y «jefes», además de introducir mecánicas para el uso de inventario, o recolección de objetos (Para este punto estoy desarrollando un Asset aparte, un inventario que podrán añadir en cualquier proyecto 😉 ). También me hablaron sobre las cuerdas y el balanceo, como de los ataques con espadas o cuerpo a cuerpo… todo eso lo tengo en cuenta. Todo se introducirá poco a poco, y algunas cosas que me parecen importantes, como por ejemplo el inventario, serán desarrolladas con la intención de que, a futuro, puedan ser útiles en cualquier tipo de proyecto, desarrollándolas con un punto de vista general.

SI tienes una idea para introducir, puedes decírmelo en los comentarios. Cuando termine una buena parte y me parezca un buen resultado, abriré el repositorio para que puedan ir descargando el código, sin embargo, las imágenes y el curso pueden salir después… o quizás antes, vamos a ver como me trata el tiempo.

☝ La importancia del GDD (Game Design Document) 📚

Si tienes la idea para un gran videojuego, no basta con decir la historia y hablar un poco de las mecánicas que vas a implementar. Es importarte que toda la información referente al proyecto quede estructurada de una forma donde no se deje nada para la improvisación.

Una buena practica es elaborar un documento de diseño. En vídeojuegos, se conoce mejor como GDD o Game Design Document. Ahí abordarás todas las mecánicas, herramientas, estadísticas e información general que tengas planeada para tu juego, y la organización que alcances te permitirá trabajar con seguridad y, en caso de querer formar un equipo de desarrollo, desenvolverte correctamente.

Si bien la organización o los cronogramas que debes preparar para controlar la eficiencia de tu trabajo son documentos aparte, el GDD englobará todo el grueso de tu proyecto, guardando cada detalle que quieras implementar.

Cada documento de diseño puede alcanzar una estructura diferente, quizás más largo o más corto, dependiendo de cada proyecto. Pasaré a explicar cómo podemos crear uno de estos documentos, además de la estructura básica para que tengan una idea y puedan empezar a escribir algunas cosas.

¿Qué es un documento de diseño?

Como dije arriba: un documento de diseño o GDD (Game Design Document), es el archivo con toda la información referente al proyecto: desde sus estrategias de marketing hasta el gameplay que se implementará. Cabe resaltar que el documento de diseño no es obligatorio para empezar un proyecto, es más como una ayuda que puede ser muy útil para organizar al equipo.

¿Qué debemos escribir ahí?

Los temas que se van a tratar dentro de un documento de diseño son variados. Les dejaré una lista con algunos puntos importantes:

  1. Introducción. En esta sección podemos desarrollar los aspectos generales del proyecto: el nombre, género, plataformas y público al que va dirigido. Además, estaría bien hacer un resumen sobre las mecánicas principales que van a formar parte del proyecto.
  • Cuando nos referimos a la “introducción” de un documento de diseño, es importante señalar que en ella sólo se redactarán los conceptos más importantes de la jugabilidad, la interfaz, los gráficos, y otros elementos del juego. También se le conoce como High Concept, y su objetivo es presentar el juego a cualquier lector sin que este tenga que leer muchas páginas diferentes para hacer su propio resumen.
  1. Mecánicas. Quizás sea una de las partes más extensas del documento. Aquí van a estructurar cada detalle dentro del juego. Desde el movimiento de los jugadores, a las funciones que active, por ejemplo, una palanca. Dentro de esta sección suelen añadir un apartado para los objetos, la interacción del jugador con ellos, los controles, etc, llamado “Jugabilidad”. Ahí se debe desarrollar claramente como el jugador realiza acciones dentro del mundo. También hay una subsección para el “Flujo de Juego”, donde se explica con detalle qué cosas pasan desde que el jugador abre el juego. En esta parte pueden valerse de elementos gráficos para diferenciar cada acción del jugador. Un ejemplo sería: “El jugador entra en el selector de personajes y toma al guerrero, el juego activará los enemigos, después de luchar se abre una puerta”, o cosas así.
  2. Primeros minutos: Este es un apartado menos extenso que el “Flujo de Juego”, escribiremos unicamente de las primeras mecánicas, personajes u elementos que se presentarán durante los primeros minutos de juego. Es importante que el inicio sea emocionante, muchos jugadores no pasan más de cinco minutos hasta que ya eliminan el juego de su teléfono o computador.
  3. Interfaz. Aquí se explicará el funcionamiento de cada “pantalla”. Son los diferentes estados gráficos dentro del juego, como puede ser la pantalla de juego, la pantalla de título, o la pantalla de pausa. Además, también se debería hablar sobre GUI (Game User Interface) y cómo el jugador interactúa con ella.
  4. Arte. Para esta sección van a redactar todo sobre el arte y estilo dentro del juego. Se deciden temas como la perspectiva (2D,3D,2.5D) y los colores. Esta es una información que generalmente puede mostrarse al público general, ya que explica como se verá el juego.
  5. Sonido. Acá se resolverán las dudas que se tengan respecto a los efectos de sonido, doblaje, y música.

¿Cómo crear un GDD? 🚀

Primero que todo, necesitaremos tener instalado algún Software de oficina. En Windows seguramente tendrán el Microsoft Word, pero también hay una alternativa que se puede usar en todos los sistemas operativos: LibreOffice. Para esta labor no tiene nada que envidiarle a Word, es gratuito y su interfaz es bastante parecida (las líneas de este artículo se escriben en LibreOffice).

Cuando tengan instalado el programa que quieran usar, sólo van a tener que empezar a escribir el índice de contenido. Por aquí abajo les mostraré unas plantillas básicas que pueden copiar y pegar.

Cosas que debemos considerar ☝

1️⃣ El documento de diseño será un material que seguramente más de una persona ojeará. El/los encargados de escribir sobre él deben mantener un lenguaje estándar y fácil de entender para todos. La organización es muy importante.

2️⃣ Mientras están escribiendo sobre su proyecto, no eviten un tema que parezca «obvio», seguramente para otra persona no quede claro, y necesitará una explicación.

3️⃣ Mientras más información tengan, más sólido será su documento. Traten de desarrollar bien cada mecánica o hueco de la historia (en caso de que su juego tenga historia). Una opción sería escribir todo dentro del documento de diseño y después sacar las páginas de cada tema para dividirlas en otros documentos, como: «Mecánicas» e «Historia»; dentro de una carpeta llamada: «GDD »Proyecto IX’ «.

Estructura básica para un GDD 📈

Aquí me gustaría destacar esta plantilla que encontré en Internet: https://docs.google.com/document/d/1-I08qX76DgSFyN1ByIGtPuqXh7bVKraHcNIA25tpAzE/edit, me parece un buen ejemplo.

Además, podemos considerar lo siguiente:

  1. Introducción
    • Concepto del juego
    • Características principales
    • Género
    • Publico dirigido
    • Alcance
  2. Mecánicas de juego
    • Jugabilidad
    • Flujo de juego
      • Diagrama de flujo
      • Introducción al juego
      • Jugando
      • Fin de partida
    • Personajes
      • Protagonista
      • Compañero del protagonista
      • Antagonista
    • Control de jugador
      • Interacción con el personaje
      • Interacción con el entorno
      • Interacción con la interfaz
    • Interacción del entorno con el jugador
  3. Interfaz
    • Diagrama de flujo de pantallas
    • Menú principal
    • Menú de pausa
    • Menú de guardado/cargar partida
    • Interfaz de usuario durante partida
    • Interfaz de fin de partida
    • Creditos
  4. Arte
    • Estilo
    • Concepts
    • 2D
    • 3D
  5. Sonido
    • Música
    • FX
    • Diálogos

Si lo necesitas, puedes añadir o quitar alguna sección. Esa estructura la he encontrado aquí.

Beneficios de un GDD 🏆

Como les dije arriba, tener un documento de diseño puede resultar muy útil para mantener organizado un equipo de trabajo. Para finalizar este artículo, colocaré una lista de beneficios por usar un GDD.

  1. Se establecen los límites y las posibilidades del equipo.
  2. Al tener una base documentada, aumenta la seguridad de éxito tras la publicación del juego, se supone que han evaluado y preparado un plan para muchos posibles riegos.
  3. Con toda la información del proyecto, el trabajo en equipo será más fluido: no hay necesidad de que un diseñador o programador tenga que preguntar por cada detalle al administrador del proyecto.

¿Antes de empezar tus proyectos trabajas un documento de diseño? Comparte tu experiencia. Si tienes alguna duda, puedes dejarla en los comentarios.

☝ 🖍 ¿Conoces Lospec? 🏆

Cada programa de software, tema o corriente, tiene su propia comunidad en alguna red social. Algunos llegan más lejos, hasta el punto de formar su propia plataforma digital enfocada exclusivamente al tema de interés.

Mientras estudiaba sobre las páginas dedicadas al Pixel Art para tener antecedentes en mi proyecto PIndie, encontré Lospec: un lugar maravilloso donde ya se hacen algunas cosas que para mí parecían innovadoras. Cambiando entonces mi enfoque inicial, tal vez no sea necesario publicar una nueva plataforma con características para los artistas, un proyecto así puede mantenerse en Lospec, uniendo a la comunidad.

¿Qué es Lospec?

La respuesta es sencilla: una plataforma web. En Lospec se recopilan tutoriales, paletas de colores, artículos para la venta y un editor web con el que puedes editar Pixel Art.

Espero ayudar a los nuevos artistas a encontrar fácilmente el mejor software y recursos de aprendizaje, así como crear herramientas invaluables de las que incluso los expertos pueden beneficiarse.

Sam Keddy en la sección de información de Lospec.

📚Tutoriales… ¿Cómo funciona?

Busque por tema, autor o medio para encontrar el artículo, vídeo, imagen o libro perfecto para usted. ¡Deja un comentario o haz clic en recomendar para que otros sepan qué tutoriales te resultan más útiles!

Lospec en Pixel Art Tutorials.

Cuando entramos en la sección Tutorials podemos aplicar filtros para aprender sobre algo específico. Hay más de un centenar, sin embargo deben tener en cuenta que la mayoría son infografías que se publican en redes sociales como Twitter. La cantidad de artículos o libros escasea.

Si haces clic sobre alguna publicación, se abrirá una ventana con la información referente a la imagen y las redes sociales del creador de la misma, en caso de que quieras más datos sobre él.

Paletas de colores 🖌

Aquí se repite la forma de aplicar filtros, pero no para tutoriales, sino con paletas.

Vamos a encontrar una gran cantidad de paletas, es el sueño de una persona que no quiere liarse con los colores en proyectos sencillos. Lo mejor es que puedes descargar en muchos formatos. Los botones de descarga están en la parte superior derecha de cada paleta:

Si tienes ganas de colaborar y publicar tu propia paleta, sólo tienes que seguir la guía de Lospec: https://lospec.com/palette-list/submissions.

Los recursos 📂

En la sección de Resources tenemos una lista de programas para la creación de Pixel Art, guías y hasta una herramienta de generación procedural experimental. Son muchas cosas de las que podría escribir, así que dejo para que ustedes mismos naveguen.

La tienda 🛍

Una característica reciente es la tienda de arte. Aquí pueden comprar imágenes o camisetas muy buenas con Pixel Art. Ignoro si las ventas están dando buenos resultados, pero la tienda esta bien surtida con mucho arte variado.

Hablando un poco con Sam Keddy 🎙

Para hacer más interesante el artículo sobre Lospec, he contactado con Sam Keddy, la persona detrás del proyecto, y resolví algunas dudas. Voy a dejarles esta pequeña entrevista.

1. ¿Puedes presentarte?

Mi nombre es Sam Keddy, básicamente un niño de Internet autodidacta. Puede que me conozcan como skeddles.

2. ¿Eres un Pixel Artista? ¿Tienes experiencia en otras áreas?

He estado haciendo pixel art desde el año 2006 como pasatiempo, pero tengo un carácter experimental con muchos medios digitales diferentes, pero ninguno se atascó tanto como el pixel art o la programación (aparte de hacer música en algún momento).

3. ¿Ha creado y/o participado en el desarrollo de un vídeojuego?

Hice algunos juegos realmente pequeños, y he hecho arte en algunos juegos, pero nunca lo he hecho a tiempo completo. Sin embargo, no planeo morir sin hacer algunos grandes juegos.

4. ¿Por qué empezaste con Lospec?

Originalmente comencé con Lospec porque sentí que el estado de los sitios web para pixel art se estaba estancando. Creo que Pixel Art es genial (al igual que otras formas artísticas digitales restrictivas, que son similares en muchos sentidos), y quería hacer lo que pueda para ayudar a que la comunidad crezca y luego preservarla. También sentí que había muchas oportunidades perdidas para herramientas fácilmente accesibles. Quería hacer cosas grandes, pero decidí hacerlo lentamente, agregando herramientas más pequeñas para que la gente se familiarice y pueda aprender más.

5. ¿Qué significa «Lospec»?

El nombre Lospec se basa en el término «baja especificación», que a veces se usa para denotar formas de arte digital con límites autoimpuestos en sus «especificaciones».

Dado que el arte digital se almacena como 1s y 0s, puede ver fácilmente las medidas exactas sobre él, como la altura y el ancho de las imágenes, o la cantidad de colores que contiene, que puede llamar sus especificaciones. El tipo de arte con el que tratamos es en el que el artista intenta minimizar estos números y trabajar dentro de esa restricción.

6. ¿Fue beneficioso para la comunidad el proyecto?

Creo que mucha gente valora nuestra Lista de paletas, ya que en realidad no hay otras páginas para las paletas de pixel art en Internet. Nuestra página de Tutoriales de Pixel Art no es tan única, pero creo que el hecho de que sea fácil de buscar y probablemente la mayor colección de tutoriales de Pixel Art, también lo hace valioso.

7. ¿Tiene alguna mejora para agregar a Lospec en mente?

Desde el principio he tenido muchas ideas para Lospec, y solo sigo agregando más.

8. ¿Está satisfecho con el estado actual del proyecto?

Sí, solo desearía tener tiempo para todas mis ideas.

9. ¿Crees que en estos años la atención de los usuarios de Pixel Art ha disminuido?

Es difícil saberlo realmente. Para ciertos artistas de píxeles, se han alejado de los sitios individuales a las plataformas de redes sociales para un mayor alcance. Espero que Lospec pueda hacer que vuelvan a ser una comunidad más pequeña y unida, mientras les sigue brindando las herramientas para llegar a un público más amplio.

10. ¿Cómo proyectas el futuro de Lospec?

2019 será grande para Lospec. Espero agregar cuentas de usuario pronto y luego comenzar a trabajar en una galería donde los usuarios pueden publicar sus trabajos. Después de eso, planeo simplemente agregar continuamente nuevas características que ayuden a las personas a promover y compartir su arte o proyectos, crear, colaborar y convertirse en mejores artistas.

Las preguntas y respuestas originales están en inglés, espero haber realizado una buena traducción. Si quieren saber un poco más sobre las «artes restrictivas»; recomiendo que pasen por aquí: https://lospec.com/about

Después de leer todo esto te pregunto: ¿Qué te parece la idea de Lospec? formar una comunidad de artistas con herramientas que faciliten su trabajo, acercar el Pixel Art y las artes digitales a más usuarios, sin hacer enfoque a las redes sociales… a mi me gusta mucho y trataré de apoyar a Keddy con todo lo que pueda. Anímate a dar tu opinión.

Asfódelo

Generalmente no dispongo de mucho tiempo para navegar entre las publicaciones de otras comunidades diferentes a Godot Engine, sin embargo, en el grupo Desafío Pixel Art conocí al artista Marco González. Dentro de su página de Facebook, Asfódelo, comparte muchos de sus trabajos, obras verdaderamente maravillosas.

Portada de Asfódelo

Puede que algunos estén al tanto de mi proyecto Pindie: Una plataforma para la recopilación de experiencias entre artistas y aficionados. Como es natural, fue un fracaso inicial por mi falta de previsión, y, para tratar de adaptarla, he hablado con Marco para iniciar una entrevista y tocar algunos temas. Para mi sorpresa, la propuesta fue de agrado y tenemos hoy un material bastante útil para aquellas personas que están estudiando, son aficionados de arte o simplemente disfrutan de leer.

Antes de empezar, les dejo el portafolio de Marco

1. ¿Cuándo empezaste a dibujar?

Como muchos de los que están en esto, partí de muy niño. No sé si aprendí primero a hablar o dibujar. Eso sí, empecé a hacelo más formalmente cerca de los 20 años, cuando entré a la universidad. Antes de eso era un hábito diario de todas formas.

Imagen de Asfódelo.

2. ¿Tu familia también se relaciona con las artes?

No sé si mi familia como tal, pero mi abuelo materno era profesor de artes plásticas y trabajaba también por encargos. Muchas veces los vi haciendo cosas (cuadros, repujados en cobre y estandartes, sobre todo) y aprendí mucho de él. El resto de mi familia no es muy aficionada a las artes en general, aunque sí de más de alguno he recibido apoyo por lo que hago.

3. ¿Qué despertó en ti la pasión por el arte?

Habiendo estudiado artes visuales, no diría que tengo pasión por el arte. Si bien me gusta, lo que más me llama es la ilustración (que sí, en un sentido amplio puede considerarse dentro de las artes). A la ilustración llegué casi por casualidad, las cosas se fueron dando de a poco y sin forzarlas mucho, así que tampoco hubo momento clave. Al menos nada que recuerde. Lo que siempre quise era dibujar, diría que mi pasión va más por ese lado, pero como es algo que siempre he hecho, que es prácticamente una necesidad, no viene de un momento en específico, sino más bien es un proceso de constante desarrollo.

Imagen de Asfódelo.

4. ¿Alguna vez te viste mal en cuanto a recursos para plasmar una obra?

Muchas veces, sobretodo en la universidad. No sólo en cuanto a no poder adquirir los materiales que quería o necesitaba, sino también por no saber qué materiales usar. Gran parte de la carrera consistía en experimentar, ya fuera para desechar, combinar o perfeccionar. El primer obstáculo eran las ideas, pero incluso cuando éstas sí acompañaban, a veces los proyectos se caían por falta de recursos y había que pasar a otra cosa. Lo bueno de eso es que se aprende a utilizar lo que está a la mano, a improvisar. Ahora uso más que nada recursos digitales, por lo que ya no tengo ese problema.

5. ¿Limitaste el aprendizaje en alguna ciencia para tener más tiempo de dibujo?

Quizá inconscientemente lo hice, ya que para hacer una cosa siempre hay que dejar de lado otra. Pero no fue algo que haya planeado y que me pese, ya que el dibujo siempre fue una prioridad para mi.

Boceto de Asfódelo

6. ¿Tienes alguna obra favorita?

No realmente, hay muchas obras que disfruto y mantengo como una especie de referencia al fondo de mi memoria. Aveces aparecen de vuelta, pero no tengo nada puesto en un altar. Ni siquiera puedo decir que tengo un artista favorito permanente, la lista es bastante larga y sigue creciendo.

7. ¿Recibiste clases especiales para perfeccionar tu técnica?

Si con especiales la pregunta se refiere a particulares, entonces no. Sí tuve las clases regulares dentro de la universidad, tales como dibujo, pintura, color, fotografía, grabado y otros más. No diría que ahí perfeccioné mi técnica, ni que lo haya hecho hasta ahora (o que lo haga alguna vez), pero sí me sirvió mucho para aprender y reforzar fundamentos que no conocía.

Foot Soldiers – Covert Art Triptych © Foot Soldiers, 2016 – Extraído de Asfódelo.

8. ¿De qué te graduaste en la universidad?

De Licenciado en Artes Visuales, primero, y luego de Licenciado en Educación con mención en Inglés.

9. ¿Eres bilingüe? ¿Crees necesario dominar el inglés para el desarrollo personal de una persona?

Depende de a quién le preguntes, pero en términos prácticos diría que lo soy o al menos me acerco a serlo. No creo que dominar el inglés sea estrictamente necesario, pero definitivamente puede ser una gran ayuda. A pesar que finalmente no seguí esa área, uso el inglés casi a diario, ya sea para seguir aprendiendo más cosas o para comunicarme con clientes. En todo caso, creo que aprender un idioma, cualquiera que sea, siempre es positivo, ya que ayuda a entender más sobre otras culturas y abre percepciones sobre la propia.

Imagen de Asfódelo.

10. ¿Dónde trabajas actualmente?

Físicamente, trabajo desde mi casa, pero los clientes son de distintas partes. De donde recibo encargos más frecuentemente es de EEUU, por medio de Onyx Path, una editorial que publica juegos de rol (RPG). También suelo trabajar para el juego de cartas intercambiables (TCG) Mitos y Leyendas, que son locales. Ya el resto son clientes particulares de distintas partes, una de las ventajas del Internet.

11. ¿Es posible vivir del arte?

Qué tan posible es depende, en gran parte, de cuánto cada persona esté dispuesta a moverse, sobre todo al principio. Depende también de poder organizarse y de saber qué es lo que se quiere hacer. Mucha gente parte con las ganas de vivir de esto, pero sin saber qué lugar ocupar dentro del rubro. También es importante nunca dejar de aprender, aceptar criticas para mejorar, desafiarse para no estancarse, y sobre todo disfrutar de lo que se hace, que si no ya pierde todo el sentido.

Imagen de Asfódelo.

12. ¿Se te hace difícil empezar una nueva obra?

Casi nunca. Cuando es por encargo es como resolver un problema: te dan los elementos a trabajar y tienes que ver cómo los haces dialogar de forma atractiva. A la larga es como cualquier disciplina, mientras más prácticas, más fácil se te hace. Y cuando son piezas personales o bien las llevo pensando un rato mientras trabajo en otras cosas, o simplemente dejo que salga algo naturalmente. Lo importante es no hacerse expectativas demasiado específicas, así siempre se pueden ir cambiado cosas en el camino y llegar a resultados más naturales y variados.

13. ¿Has pensado en dejar de dibujar para hacer otra cosa?

Nunca. Sí he pensado en dejar menos tiempo para dibujar, como cuando estudié pedagogía en inglés, pero nunca dejarlo del todo.

Imagen de Asfódelo.

14. ¿Trabajaste como diseñador en algún vídeojuego?

No, no sé casi nada de diseño y nunca intenté hacer algo así. Diseñar videojuegos conlleva muchas cosas que no conozco, así que probablemente quedaría entrampado nada más empezar. Sí colaboré con un amigo en un par de proyectos de vídeojuegos, en los que él se encargaba de la programación y el diseño, y yo de los gráficos, siempre trabajados en pixel art.

Pixel Art de Asfódelo.

15. ¿Tienes otro pasatiempo del que quieras hablar?

Mis pasatiempos suelen ser casi lo mismo que mi trabajo. Aveces bromeo con que para descansar después de trabajar dibujando, dibujo alguna cosa. Como ahora casi todo mi trabajo es pintura digital, hago cosas distintas a lo que me encargan, como dibujar en papel, pintar con óleos, hacer pixel art o dibujar tiras. A cuál le doy más tiempo depende de qué tenga más ganas de hacer. Muchas de esas cosas terminan convirtiéndose en proyectos a largo plazo, algunos más abandonados que otros. También me gusta leer, suelo comprar libros de segunda mano, de distintos temas y estilos para leer por la noche o en los trayectos. Ahora mismo estoy leyendo la Casa de las Bellas Durmientes, de Yasunari Kawabata, y releyendo por enésima vez el Silmarillion de Tolkien.

Boceto de Asfódelo.

16. ¿Qué opinas de las comunidades digitales? ¿Son buenas para aprender?

Creo que toda comunidad tiene, en principio, mucho potencial para el aprendizaje. En el caso de las digitales está la ventaja de que funcionan independientemente de un espacio físico o de un momento específico. No hace falta que todos los miembros se conecten a la misma hora para debatir un tema, para compartir herramientas o para darse critica. Soy muy creyente de las bondades de Internet como espacio de aprendizaje y retroalimentación, y así como a mi me ayudaron (y me ayudan), también trato de dar una mano cada vez que puedo. Creo más en la colaboración que en la competencia. Eso sí, no todas las comunidades digitales funcionan igual de bien, y mucho depende del propósito. Hay casos en los que chocan los egos y sencillamente no funciona, pero hay otros espacios en los que hay predisposición generalizada a aprender del otro, ayudar con lo que cada uno sabe y a debatir activamente sobre los temas que nos competen como creativos, y ahí hay una gran labor.


Espero que hayan disfrutado la entrevista tanto como yo. Para no dañar la experiencia, cierro ahora el artículo. Recuerden que pueden visitar la página Asfódelo, del maestro Marco Gonzáles.

Nota: Tolkien es el escritor de El Señor los Anillos, si están dibujando cosas medievales o fantásticas, deben leer sus libros.

🌖 Elementary OS y sus aplicaciones ¿Por qué es mi sistema principal? 🏅

Quizás lo más desagradable del sistema Elementary es la propaganda para desarrollar software sólo para su tienda de aplicaciones. Defender esta postura me es complicado, he descargado mucho software de su tienda y al momento de probar otra distribución, no pude compilar esos programas. Lo que hacen para Elementary, sólo funciona ahí, y eso no me gusta.

Unos meses atrás compartí mis primeras experiencias con Elementary, hoy en día sigo usándolo como sistema principal. No puedo editar vídeos en él porque se tarda demasiado en producirlos, así que al momento de usar Kdenlive simplemente cambio el sistema por Debian Estable. Sin embargo hay un par de cosas que me molestaron y hacen imposible recomendar Elementary a nuevos usuarios de GNU/Linux, pero no hablaré de eso ahora. Dejaré mis recomendaciones para otro artículo adaptado al inglés.

Si todavía sigo usando Elementary es porque cubre la mayoría de mis necesidades, pero no llegué a esto sin antes ajustar el sistema e instalar algún programa. Hablaré un poco de las aplicaciones que me hicieron quedar, sean o no, oficiales de esta distribución.

1️⃣ LibreOffice 📝 (No oficial)

Aunque esto sea una de las cosas más superficiales, creo que me es imposible trabajar en un sistema donde LibreOffice se vea mal. Por lo menos tan horrible como se ve en la versión de Debian Estable con Plasma (Degradado blanco/negro con tipografía extraña). Tengan en cuenta que además de escribir artículos manejo muchos documentos, y una mala apariencia en Elementary, cuando en todas las otras distros se ve fenomenal, me causa depresión.

Por defecto LibreOffice se ve horrible en esta distribución, puedes solucionarlo copiando una línea en la Terminal:

sudo apt install libreoffice-gtk2 libreoffice-style-elementary

2️⃣ Notes-Up 🚀 (Oficial)

Notes-Up con tema oscuro.

Sin duda, la filosofía del proyecto Elementary es la elegancia. Ya desde su guía para publicación de aplicaciones, nos explican lo importante que es una buena interfaz de usuario, tanto bonita como funcional.

La aplicación Notes-Up es una libreta/organizador. Lo mejor que he probado en GNU/Linux para tomar notas (Nótese que no cuento Windows 10, porque hasta Gnote lo superaba). Tiene muchas opciones, es estable y bonita. Durante un tiempo, mientras no sabía como arreglar el estilo de LibreOffice, usé esta aplicación como procesador para todos los textos y artículos, sin problemas.

3️⃣ ColorPicker & Paleta & Ideogram 📢 (Oficiales)

Estos tres programas no pueden contar como una aplicación individual, son relativamente sencillos, pero cumplen su labor y me ayudan mucho. Los explicaré en una lista:

  • ColorPicker: como su nombre lo indica, este programa nos permitirá tomar un color de la pantalla. Su diseño es sencillo y muy bueno.
  • Paleta: relacionada con los colores, nos presenta una selección de temas que se pueden usar para el diseño de interfaces de usuario. Si no me equivoco, se encuentra traducida a muchos idiomas.
  • Ideogram: si notan muchos «Emojis» en los artículos, es porque encontré esta aplicación. Ideogram te presenta todos los emojis que puedes colocar en texto, cada vez que presionas la tecla de Windows+E. Bastante útil, los emojis le dan aire fresco a estas entradas jaja.

Notas finales 💡

En esa pequeña lista enumeré algunas de las aplicaciones que considero importantes para mi trabajo. Faltaría agregar lo bien que ellas se complementan con Elementary: es un aire de productividad. Por lo menos para las cosas que hago (escribir, programar y diseñar), este sistema es excelente (aunque hay algunos problemas de los que hablaré en otro artículo).

¿Personalizar Elementary OS 🤔

Seguro notaron que tengo un tema diferente y el botón de reducir. Podría extenderme explicando como personalizar un poco de Elementary, pero mejor les dejo el artículo que seguí: https://maslinux.es/personaliza-elementary-os-con-el-combo-le-capitaine/.

Espero que les resulte entretenido el artículo. Si tienen una duda u opinión, pueden comentar.

Preparando desafíos para los desarrolladores de Godot

Con el objetivo de mantener activa la comunidad hispana de Godot, se implementarán los retos o desafíos semanales. Los desarrolladores interesados en participar podrán desviarse un poco de su trabajo habitual para probar sus habilidades en la programación de una mecánica común (o no tan común).

Los proyectos que se desarrollen para un desafío tienen la opción de añadirse a un repositorio de GitHub donde puedan ser re-utilizados en caso de que alguien lo necesite. Ese repositorio se llama «RetosParaGodot» y es cuestión del programador compartir su código o no.

La idea principal no es formar una competencia, sino comprometer un poco de nuestro tiempo para encontrar la solución de una mecánica que le puede servir a otro compañero. Con la diversidad de formas desarrollando algo en común, quizás podamos perfeccionar nuestras ideas y optimizar nuestros proyectos.

Sin embargo, todos los domingos, además de anunciar el inicio de un nuevo desafío, también se hará una mención para aquella persona que haya destacado con el desafío anterior y tenga el código liberado para toda la comunidad.

¿Cómo puedo participar? 📃

Todos los domingos se realizará una publicación con el tema del desafío y las reglas que se deben seguir, en la comunidad de Facebook y ForoGodot.org. No es necesario que comentes algo como «Participaré», mientras hagas una publicación añadiendo «#DGodot» y un vídeo o gif con tu trabajo relacionado al tema del desafío, ya estarás participando. La publicación se puede realizar en Twitter o Facebook y sólo en los días de la semana hasta el próximo domingo, ya que después el desafío será diferente.

Reglas

Si tienes ganas de publicar tu proyecto en el repositorio de GitHub, te recomiendo que sigas el estilo de GDScript, así tu código será elegante y fácil de comprender.

  • Mientras un desafío esta activo no puedes enviar una publicación con el desafío de la semana pasada.
  • Es necesario que compartas un GIF o vídeo, con puras imágenes no sabremos si de verdad tienes algo programado.
  • Sólo puedes hacer una publicación con el #DGodot cada semana. Si en una semana tienes dos, sólo se tomará en cuenta la primera publicación. Por lo tanto, trata de tener la mecánica lista cuando grabes el vídeo.
  • Los assets que uses deben tener una licencia pública, libres de copyright.

¿Cómo publico mi proyecto en el repositorio? 💡

Para llegar al repositorio, puedes hacer clic aquí. Si tienes conocimiento de Git puedes clonar el repositorio y hacer un Pull. En caso de que no sepas usar Git, puedes enviar un archivo .zip con el proyecto, a uno de los moderadores del grupo y ellos lo añadirán al repositorio.

¿Premios? 🤔

Como dije arriba: la persona que destaque con su proyecto será mencionado y, en caso de que tenga un vídeojuego o algo para contar, recibirá la oportunidad de publicar un artículo en este sitio web.

Contexto para la publicación del proyecto Pindie

Las comunidades digitales son un escape para muchas personas. Es una forma de compartir lo que nos gusta con gente igual a nosotros, que pueden apreciar esa cosa donde invertimos nuestra dedicación y tiempo.

Dentro de la plataforma Facebook se encuentran muchas comunidades relacionadas con el arte digital, la programación, vídeojuegos (tanto jugadores como desarrolladores), PixelArts o retoque fotográfico. Prácticamente cualquier software que sea usado por muchas personas alrededor del mundo, tiene su propia comunidad en Facebook, con miembros que buscan aprendizaje u opinión sobre sus avances en algún tema. Incluso todo eso se podría juntar para resumir la necesidad del ser humano en socializar.

La interacción entre los miembros de una comunidad tiende a ser respetuosa y solidaria, las personas dan por sentado que sólo se comunicarán con compañeros que comparten sus mismos intereses. El racismo, machismo o necedad, prácticamente están ausentes, cada quien nota el talento y los avances del otro, y eso lo respetan, porque lo han vivido. Los usuarios más experimentados pueden recurrir a una publicación novicia y ofrecer consejos, así como los mismos novatos tratarán de explicar algún concepto acorde a su nivel de conocimiento, ayudando a alguien que lo necesite y aprendiendo, porque no hay mejor forma de comprender algo, que intentar enseñarlo a alguien más.

Antes, las comunidades digitales se formaban en torno a los foros, plataformas donde los recursos se catalogan hasta formar como una gran biblioteca, basada en el conocimiento de cada miembro. Hoy en día se ha tomado el sendero más efímero, además de Facebook también se podrían mencionar las comunidades de Reddit, Amino, o cualquier red social similar.

Hasta ahora todo esta bien, o eso parece para nosotros. Las redes sociales generan una actividad diaria muy elevada. Si María comparte algo, por ejemplo una entrevista de algún artista, después de 48 horas es muy probable que aunque bajemos y bajemos en la bandeja de publicaciones, no encontremos el enlace de María. El mismo caso se puede aplicar en los miembros que buscan aprendizaje: si hacen una pregunta sencilla o complicada, después de una semana o incluso algunos meses, llegará otra persona y preguntará lo mismo, generando que los mismos usuarios participes en aquel primer momento, u otros nuevos, tengan que repetir una respuesta, perdiendo tiempo que podrían invertir en otra cosa.

El concepto de los foros esta hoy muriendo, podemos tomarlo y adaptarlo a los intereses actuales si cambiamos su enfoque: tomar lo mejor de una red social, un sitio web especializado y la vieja biblioteca. Así conseguiremos, quizás, una comunidad próspera y muy productiva, que puede servir como fuente de conocimiento, colaboración y amistad, entre todos nosotros.

Mi Proyecto para la SuperMegaJam

Esta semana he estado trabajando en la idea que presentaré por la SuperMegaJam, un concurso organizado por FuryGames dentro de la plataforma itch.io/.

Al momento de escribir esto, queda poco más de un mes para terminar y enviar mi proyecto. Todavía no he programado nada. Me limité a diseñar y probar las imágenes desde Godot, puede que siga así otros diez días más.

El proyecto lo enfocaré a dispositivos móviles, es una buena forma de practicar el diseño de interfaces. Ya que además de esto, el que siga mi actividad en las redes sociales notará que hago muchas pruebas con herramientas gráficas para facilitar el trabajo en alguna área… lamentablemente termino con una mecánica aceptable y un diseño de aplicación sumamente horrible, pero sigamos con el asunto de hoy.

Desde que inicié con Pixel Art me mantengo dibujando cosas naturales: los tiles de piedra, tierra y árboles, porque parecen más fáciles. Después de todo, la naturaleza es un «azar» y me podía permitir poner líneas y cuadros donde quisiera… pues no, con cada dibujo noté un progreso: menos pixeles locos, descubrí que hasta poner puntos en cualquier parte del lienzo necesita una lógica, un estilo.

Cansado así de destinar mi tiempo libre en dibujos naturales, experimenté con la textura de la madera, no como árbol, sino para «tablones». El resultado no fue de mi agrado, así que decidí suprimir los detalles y hacer un diseño más plano, cargado de líneas de contorno.

Me parece que ahora resulta más placentero para la vista. Sin embargo, las velas y los botones necesitan mejorar. Lo primero porque las líneas disparejas no encajan con toda la rectitud del resto, y lo segundo, porque no me parecen tan llamativos. El siguiente paso será terminar todos los elementos gráficos de la interfaz, después de eso, podré pasar con el diseño de nodos y escenas, entrando así en el área de Godot.

Estimo que la programación del proyecto no será tan complicada. Quizás sólo una cosa se me escapa completamente: el uso de Shaders para efectos especiales.

Hace relativamente poco, FuryCode publicó el siguiente vídeo, experimentado con shaders en Godot

Eso aumentó mi curiosidad por dichos efectos. Son muchas las cosas que se pueden llegar a hacer, mediante un lenguaje particular. Mi meta con este proyecto es hacer agua y su reflejo, algo así como el efecto del siguiente vídeo:

Pero no me adelanto. Prefiero tener primero un diseño aceptable que me permita introducir alguna mecánica innovadora, por lo menos para mi.

Me despido ahora. Antes de finalizar, les aviso que estoy por publicar 5 tutoriales más para la serie básica de Godot, después de eso no sé que continuare.

Juegos Indie y Software Libre