DEV Community: Jorge Rubiano

🎲 Dice Merge - ReactJS - English Version

Jorge Rubiano — Fri, 09 Jun 2023 17:57:46 +0000

This is the english version of this post

🎲 Dice Merge - ReactJS

Jorge Rubiano ・ Jun 9 ・ 6 min read

#react #games #drag #recursion

In this article, I would like to share the latest game I have developed in ReactJS called "Dice Merge".

Game URL: https://dice-puzzle.vercel.app/

Rules.

Drag the dice onto a 5x5 grid: The objective of Dice Merge is to place the dice on a grid with 5 rows and 5 columns. To do so, simply drag the dice to the desired position on the grid.

Merge dice of the same type: When a dice is placed near two or more dice with the same value, they will merge to form the next value. For example, if you have multiple dice with a value of 4 nearby, they will combine to form dice with a value of 5.

Merge dice until reaching the value six: When dice with a value of six are merged, a special dice is created that combines all the nearby dice. This can open up new strategic opportunities for you.

Merged dice disappear: Once you make a successful combination, the merged dice will disappear from the grid. This frees up space for you to place more dice and continue searching for more combinations.

Draggable Dice

Random dice: Each turn, you will be randomly given one or two dice to drag and place on the grid. These dice can have different values.
Adjustable orientation: If you are provided with two dice, you have the option to rotate them to change their orientation before placing them on the grid. This allows you to plan your moves strategically and search for the best possible combinations.

Scoring.

The score is based on the combinations you make. For example, if you combine three dice with a value of 2, you will score six points.

However, if you make multiple combinations in the same turn, the score doubles. For example, if you combine three dice with a value of 1 (3 points) and then combine additional dice, the score doubles. If you achieve three combinations, it triples, and so on.

When a merged dice is created, you earn 100 points.

Power-ups.

The game also includes four power-ups that you can use to improve your chances of success. These power-ups refresh daily, and you can use them according to your strategic needs.

Undo: This power-up allows you to undo the last move you made. You can use it up to a maximum of 5 times. Use it wisely to correct mistakes or try different strategies.

Trash: With this power-up, you can discard the dice you have been given and get new dice in return. This can be useful if you don't find a good location for the current dice. Just like with the "Undo" power-up, you can use it up to 5 times.

Bomb: The bomb power-up allows you to destroy a dice that is already on the grid. This can be useful if you need to free up space or get rid of an unwanted dice. However, keep in mind that you can only use the bomb power-up up to 3 times.

Star Die: This special power-up provides you with a dice that can be merged with any other dice on the grid. This gives you more strategic options and flexibility for making combinations. Just like with the bomb power-up, you can use the Star Die up to 3 times.

Development Challenges:

The development of Dice Merge presented several interesting challenges that were successfully overcome. These challenges include:

Implementation of drag and drop: To allow players to drag the dice onto the grid, the dnd-kit library was used. This library facilitates the implementation of drag and drop in ReactJS and ensures an intuitive and smooth interaction.
Combination validation: A validation system based on recursion was implemented to determine if neighboring dice or newly placed dice on the grid could be merged. This ensures that only valid combinations are made and prevents incorrect moves.
State management and animations: To animate the dice and reflect changes on the grid, efficient state management was necessary. Different states were implemented for the dice, allowing for smooth animations and clear visual representation of the made combinations.
Multiple combinations: Dice Merge allows for multiple combinations in a single turn if new combinations are created after a successful combination. A listening event was implemented to check for changes on the grid and determine if there are new possible combinations after each merge. This adds excitement and additional strategy to the game.
Interrupts in animations: Although React automatically updates the user interface after a state change, interrupts were necessary for CSS animations to ensure a smooth and pleasant visual experience (a library was not used for this process). These interrupts were carefully applied to ensure that the animations run correctly and smoothly.

Conclusion:

In conclusion, the development of Dice Merge was an exciting and rewarding challenge. One of the highlights was handling recursion, which proved to be a complex but crucial topic for implementing the validation of dice combinations on the grid.

Recursion is a powerful technique in programming, but it can also be difficult to understand and apply correctly. In the case of Dice Merge, it was necessary to use recursion to check if neighboring dice or newly placed dice on the grid could be merged. This process involved exploring all possible combinations and evaluating if they met the game's rules.

Overcoming this challenge of handling recursion in the development of Dice Merge was an enriching experience. It allowed me to improve my problem-solving skills and expand my knowledge in the field of programming.

In summary, the development of Dice Merge presented a significant challenge, particularly in handling recursion. However, thanks to careful approach and deep understanding of the concept, it was possible to successfully implement the validation of dice combinations. The result is an exciting and challenging game that provides players with a unique and satisfying gaming experience.

Would you like to learn how to develop a game like Dice Merge? Leave us your comment!

If you are interested in learning to create games using ReactJS, you're in luck! I have prepared the course "Learn to Develop a Yatzy Game with ReactJS/NodeJS and Typescript" in which I teach how to develop this game from scratch.

If you are passionate about programming and games, this course will provide you with the skills and knowledge necessary to create exciting games like Dice Merge. From state management and animations to event handling and game logic implementation, you will explore all the key aspects of game development in ReactJS.

Even though the course is currently in Spanish, don't let that deter you! The concepts and techniques you'll learn are universal and applicable to any language. And who knows? It might even be an opportunity for you to brush up on your Spanish while enhancing your game development skills.

Feel free to leave a comment if you would like to learn how to make this game or if you have any questions about the course. I'm excited to hear your feedback and provide you with more information on how you can dive into the fascinating world of game development with ReactJS!

You can check out my other games on my page: https://bio.link/jorgerub

🎲 Dice Merge - ReactJS

Jorge Rubiano — Fri, 09 Jun 2023 15:26:18 +0000

Juego de combinación de dados desarrollado con ReactJS

Si quieres aprender cómo desarrollar juegos con ReactJS, he preparado un curso en el cual enseño cómo desarrollar un Yatzy desde cero con está tecnología.

Juego en ReactJS - Yatzy

Jorge Rubiano ・ May 15 ・ 2 min read

#react #typescript #node

En este artículo, deseo compartir el último juego que he desarrollado en ReactJS llamado "Dice Merge".

URL del Juego: https://dice-puzzle.vercel.app/

Reglas.

Arrastra los dados a una grilla de 5x5: El objetivo de Dice Merge es colocar los dados en una grilla de 5 filas por 5 columnas. Para hacerlo, simplemente arrastra los dados a la posición deseada en la grilla.

Combina dados del mismo tipo: Cuando un dado se coloca cerca de dos o más dados del mismo valor, se unirán para formar el siguiente valor. Por ejemplo, si tienes varios dados con el valor 4 cerca, se combinarán para formar dados con el valor 5.

Combina dados hasta alcanzar el valor seis: Cuando los dados con el valor seis se combinan, se crea un dado especial que combina todos los dados cercanos. Esto puede abrir nuevas oportunidades estratégicas para ti.

Dados combinados desaparecen: Una vez que realizas una combinación exitosa, el Dado combinado desaparece de la grilla. Esto libera espacio para que coloques mas dados y sigas buscando más combinaciones.

Dados de arrastre

Dados aleatorios: En cada turno, se te entregará al azar uno o dos dados para arrastrar y colocar en la grilla. Estos dados pueden tener diferentes valores.
Orientación ajustable: Si se te proporcionan dos dados, tienes la opción de girarlos para cambiar su orientación antes de colocarlos en la grilla. Esto te permite planificar tus movimientos estratégicamente y buscar las mejores combinaciones posibles.

Puntuación.

La puntuación se basa en las combinaciones que realizas. Por ejemplo, si combinas tres dados con el valor 2, obtendrás una puntuación de seis.

Sin embargo, si realizas múltiples combinaciones en el mismo turno, la puntuación se duplica. Por ejemplo, si combinas tres dados con el valor 1 (3 puntos) y luego combinas otros dados la puntuación se duplica, si logras tres combinaciones se triplica y así sucesivamente.

Cuando se hace merge de un dado combinado, obtienes 100 puntos.

Ayudas.

El juego también incluye cuatro ayudas que puedes utilizar para mejorar tus posibilidades de éxito. Estas ayudas se renuevan diariamente y puedes usarlas según tus necesidades estratégicas.

Deshacer (Undo): Esta ayuda te permite deshacer el último movimiento realizado. Puedes usarla hasta un máximo de 5 veces. Utilízala sabiamente para corregir errores o probar diferentes estrategias.

Descartar (Trash): Con esta ayuda, puedes descartar los dados que se te han entregado y obtener nuevos dados en su lugar. Esto puede ser útil si no encuentras una buena ubicación para los dados actuales. Al igual que con la ayuda de "Deshacer", puedes usarla hasta 5 veces.

Bomba (Bomb): La ayuda de la bomba te permite destruir un dado que ya se encuentra en la grilla. Esto puede ser útil si necesitas liberar espacio o deshacerte de un dado no deseado. Sin embargo, ten en cuenta que solo puedes usar la ayuda de la bomba hasta 3 veces.

Dado Estrella (Star Die): Esta ayuda especial te proporciona un dado que se puede combinar con cualquier otro dado en la grilla. Esto te brinda más opciones estratégicas y flexibilidad para realizar combinaciones. Al igual que con la ayuda de la bomba, puedes usar el Dado Estrella hasta 3 veces.

Desafíos del desarrollo:

El desarrollo de Dice Merge presentó varios desafíos interesantes que se superaron con éxito. Estos desafíos incluyen:

Implementación del arrastrar y soltar (drag and drop): Para permitir a los jugadores arrastrar los dados a la grilla, se utilizó la biblioteca dnd-kit. Esta biblioteca facilita la implementación del arrastrar y soltar en ReactJS y garantiza una interacción intuitiva y sin problemas.
Validación de combinaciones: Se implementó un sistema de validación basado en recursión para determinar si los dados vecinos o los dados recién colocados en la grilla pueden combinarse. Esto asegura que solo se realicen combinaciones válidas y evita movimientos incorrectos.
Manejo del estado y animaciones: Para animar los dados y reflejar los cambios en la grilla, fue necesario gestionar el estado de manera eficiente. Se implementaron diferentes estados para los dados, lo que permitió animaciones suaves y una representación visual clara de las combinaciones realizadas.
Múltiples combinaciones: Dice Merge permite realizar múltiples combinaciones en un solo turno si se crean nuevas combinaciones después de una combinación exitosa. Se implementó un evento de escucha que verifica los cambios en la grilla y determina si hay nuevas combinaciones posibles después de cada merge. Esto añade emoción y estrategia adicional al juego.
Interrupciones en las animaciones: Aunque React actualiza automáticamente la interfaz de usuario después de un cambio de estado, en el caso de las animaciones CSS fue necesario establecer interrupciones para garantizar una experiencia visual fluida y agradable (no se hizo uso de librería para este proceso). Estas interrupciones se aplicaron cuidadosamente para que las animaciones se ejecuten correctamente y sin problemas.

Conclusión:

En conclusión, el desarrollo de Dice Merge fue un desafío emocionante y gratificante. Uno de los aspectos más destacados fue el manejo de la recursividad, que resultó ser un tema complejo pero crucial para implementar la validación de las combinaciones de dados en la grilla.

La recursividad es una técnica poderosa en la programación, pero también puede ser complicada de entender y aplicar correctamente. En el caso de Dice Merge, fue necesario utilizar la recursividad para verificar si los dados vecinos o los dados recién colocados en la grilla podían combinarse. Este proceso implicaba explorar todas las posibles combinaciones y evaluar si cumplían con las reglas del juego.

Superar este desafío de manejo de recursividad en el desarrollo de Dice Merge fue una experiencia enriquecedora. Me permitió mejorar mis habilidades de resolución de problemas y ampliar mi conocimiento en el campo de la programación.

En resumen, el desarrollo de Dice Merge presentó un gran reto, particularmente en el manejo de la recursividad. Sin embargo, gracias a un enfoque cuidadoso y una comprensión profunda del concepto, fue posible implementar con éxito la validación de las combinaciones de dados. El resultado es un juego emocionante y desafiante que brinda a los jugadores una experiencia de juego única y satisfactoria.

¿Te gustaría aprender a desarrollar un juego como Dice Merge? ¡Déjanos tu comentario!

Si estás interesado en aprender a crear juegos utilizando ReactJS, estás de suerte, he preparado el curso "Aprende a desarrollar un juego de Yatzy con ReactJS/NodeJS y Typescript". en el cual enseño a desarrollar este juego desde cero.

Si te apasiona la programación y los juegos, este curso te brindará las habilidades y conocimientos necesarios para crear juegos emocionantes como Dice Merge. Desde el manejo del estado y las animaciones hasta el uso de eventos y la implementación de lógica de juego, explorarás todos los aspectos clave para desarrollar juegos en ReactJS.

No dudes en agregar un comentario si te gustaría aprender a hacer este juego o si tienes alguna pregunta sobre el curso. ¡Estoy emocionado de escuchar tus opiniones y brindarte más información sobre cómo puedes sumergirte en el fascinante mundo del desarrollo de juegos con ReactJS!

Puedes ver mis otros juegos en mi página: https://bio.link/jorgerub

Juego en ReactJS - Yatzy

Jorge Rubiano — Mon, 15 May 2023 17:34:25 +0000

Desde ya varios años he estado trabajando con ReactJS, para aprender está librería he desarrollado varios juegos, en cada uno aprendí algo nuevo.

Recreando el Parqués/Parchis en ReactJS - Primera Parte

Jorge Rubiano ・ Mar 7 '20 ・ 5 min read

#react #pwa #serviceworkers #websockets

Y ahora deseo compartir con ustedes un nuevo juego desarrollado en React, en este caso el Yatzy.

Yatzy es un juego de dados, cuyo objetivo es obtener la mayor puntuación posible tras sumar los puntos de las 13 combinaciones disponibles en la tabla de puntuaciones. Puede jugar cualquier número de jugadores; incluso se puede jugar en solitario. Tiene una mecánica similar a la de Yahtzee, Yams, Kismet, Balut, la generala y los dados de póquer, y es muy popular en los países escandinavos.

🎮 Yatzy ReactJS

Esta versión de Yatzy, está compuesta por dos proyectos: frontend con ReactJS/Typescript y el backend con Nodejs/Typescript, tiene 4 modalidades de juego como son:

URL del Juego: https://yatzy-react-game.herokuapp.com/

Solo
Online
Vs a Friend
Vs a Bot.

🚀 Curso de Udemy.

He preparado el curso "Aprende a desarrollar un juego de Yatzy con ReactJS/NodeJS y Typescript". en el cual enseño a desarrollar este juego desde cero.

Este proyecto nació de una inspiradora experiencia en la pasada JSconf Chile, donde tuve la oportunidad de compartir mi conocimiento sobre el desarrollo de juegos con React (ver conferencia).

Quedé encantado al ver la respuesta entusiasta de los participantes. Desde entonces, al día de hoy he desarrollado más de 13 Juegos utilizando ReactJS, no solo con el objetivo de aprender, sino también con el deseo de compartir mis conocimientos.

El resultado de esa pasión y dedicación es este curso, que contiene más de 27 horas de videos. Durante el curso, te guiaré en la creación de dos proyectos, uno en el front-end y otro en el back-end, ambos utilizando Typescript.

Preview

Part 2/2 - Game in ReactJS - Cuzzle

Jorge Rubiano — Tue, 21 Dec 2021 15:09:58 +0000

In these articles I would like to share with you the process of development of the latest game that I developed called Cuzzle (cube + puzzle = Cuzzle) ReactJS, this game was inspired by the original game called cuzzle developed by Redline Games

In the first part, we discuss the game and its options, in this part we are going to talk about the technical aspects.

You can play the game online here: https://cuzzle-react.vercel.app/

1. Stack.

As you know the game is developed in ReactJS, other main libraries that I used were:

Create React App (CRA): This is a library that I have used previously for other games/projects, this is an easy starting point for a react project because we have all our environment configured, for example, we have webpack, hot reloading, service workers (via workbox) and other features ready to be used, for this type of project I think is the best way to learn React.
React Spring: Another library in my toolbox of favorite libraries, this library allows us to create animations, in my case I use this library for cubes movements, I like how we can use a hook to indicate movement, for this project I used useSpring hook, in this hook we can indicate the type of animation that we need, also we have an event (onRest) that indicates when the animation ends.
Nuka Carousel: This is a good library to manage carousels, I like the simplicity that this library has. I have used this library in the list of levels.
Reach Router: This is a library from the same developers of react-router, as the name implies it’s possible to set different routers/pages, in the case of the game we have five routes.
qrcode-decoder and qrcode.react: The first library helps to read the information of our QR code, with the second we can create the QR, in this QR we save our level (actually the information we save is the URL, as mentioned in the first part the level created in the editor is saved in the URL).
howler: Is an audio library. It defaults to Web Audio API and falls back to HTML5 Audio. This makes working with audio in JavaScript easy and reliable across all platforms.
react-keyboard-event-handler: A React component for handling keyboard events (keyup, keydown and keypress), it's only available in the desktop version.
sweetalert: A beautiful, responsive, customizable, accessible replacement for Javascript's popup boxes (alert, confirm and prompt).
share-api-polyfill: This is a polyfill for Web Share API which can also be used on the desktop, it is very useful because if the browser does not support the Web Share API, the user can still share the information without problems.

Also I used other packages like prop-types and lodash.clonedeep

Other devDependencies used were:

Vercel: This package help to publish the game in the service with the same name, this service is very good, it’s simple to publish a project, I’m using this service for several years (even when the name of the service was now)
Serve: Sometimes was necessary to test the game on real devices, in that case, I used this package to create an URL that I can use on my local (when I needed to share the URL with other people I used ngrok)
CodeSpaces This is a great tool, because this allows us to have a complete development environment in the cloud, I had the option to open the project on different devices through the browser or open it in VS code, this was very useful for me, because I had the option to develop the game on different computers (even on an iPad).

2. CSS.

Most of the interface of the game was developed in CSS, sometimes I use SVGs in this case for the icons, I know there are a lot of good libraries to use with CSS, in my case I used “regular CSS” In this case, each component has their CSS file (if it’s necessary) sometimes when I need to change something in the interface I used the style property or using the className method, but also I used the option to share variables between CSS and JS, in this case with the setProperty (create a CSS variable o modify its value).

In games like this it is possible to use canvas, sometimes it's the best option, for this particular game (actually almost all the games I have developed in react don't use canvas) I only use CSS, for me CSS is enough, yes, the performance is sometimes not the best, but for me the idea is to learn, not just ReactJS but CSS as well.

3. Technical challenges.

This is the second isometric game that I have developed (I previously developed a game with isometric style Hocus). My previous games/projects were mostly 2D, the challenges in this project were mainly related to the depth of the cubes.

Component creation

With ReactJS (and other libraries/frameworks based on components) it's "easy" to create new components (and reuse them), in this game we have several components, but it was a special challenge creating visual components like:

Floors: As we saw in the first part we have different types of floors, but at the end of the day it is just one component that changes its behavior based on its props

import "./styles.css";
import { SIZE_FLOOR } from "../../../utils/constants";
import PropTypes from "prop-types";
import React from "react";
import Variants from "./variants";

const Floor = React.memo(
  ({
    style = {},
    size = SIZE_FLOOR,
    type = "",
    animated = true,
    shake = false,
    up = false,
  }) => (
    <div
      className={`floor-wrapper ${shake ? "shake" : ""} ${up ? "up" : ""}`}
      style={{ ...style, width: size, height: size + 20 }}
    >
      {type && <Variants type={type} animated={animated} />}
      <div className="floor-base" />
      <div className="floor" />
    </div>
  )
);

Floor.propTypes = {
  style: PropTypes.object,
  size: PropTypes.number,
  type: PropTypes.string,
  animated: PropTypes.bool,
  shake: PropTypes.bool,
  up: PropTypes.bool,
};

export default Floor;

In this example we can see the <Floor /> component, but also we can see the <Variants /> component.

import { SUFIX_ARRIVAL_POINT } from "../../../../utils/constants";
import ArrivalPoint from "./arrivalPoint";
import Portal from "./portal";
import Switch from "./switch";

const Variants = (props) => {
  let finalType = props.type || "";
  const extendprops = {
    ...props,
  };

  if (props.type.includes(SUFIX_ARRIVAL_POINT)) {
    finalType = SUFIX_ARRIVAL_POINT;
    extendprops.color = props.type.split("-")[2] || "white";
  }

  const variants = {
    switch: <Switch />,
    "arrival-point": <ArrivalPoint {...extendprops} />,
    portal: <Portal {...extendprops} />,
  };

  return variants[finalType] || null;
};

export default Variants;

Cube: This component is simpler compare to floors, but only when it's a static cube.

import "./styles.css";
import { SIZE_FLOOR } from "../../../utils/constants";
import PropTypes from "prop-types";
import React from "react";

const Cube = React.memo(
  ({ style = {}, size = SIZE_FLOOR - 25, color = "", opacity = false }) => {
    return (
      <div
        className={`cube ${color}${opacity ? " opacity" : ""}`}
        style={{ ...style, width: size, height: size + 20 }}
      />
    );
  }
);

Cube.propTypes = {
  style: PropTypes.object,
  color: PropTypes.string,
  opacity: PropTypes.bool,
  size: PropTypes.number,
};

export default Cube;

As you can see it's just one div, I like to use just one div when possible, sometimes it's possible to do a lot of things with just one div and I think it's good, because as you know when we use less DOM elements it's good for performance.

Who creates the "magic" to show a cube is CSS, in this case using the transform and linear-gradient properties with the before pseudo-element

Cube depth

In a 2D game, the elements are at the same level, but in games like this, depth is an important aspect to take into consideration.

As you know in CSS we have the concept of stacking context, when we have two elements with absolute positions the element that is in the right position and/or below by default will be on top of the other element, if we want to change that behavior it is necessary to use the z-index property, but for it to work all elements need to be in the same stacking context.

I use the z-index only in the component where the user can move the cubes, in the editor wasn’t necessary because all the elements are static at that point, all the floors render from left to right and top to down, in this case, all the floors have an absolute position (the positions were calculated by a helper) due to behavior of rendering by default a floor have the right position and depth with respect to the other floors, I mean the next floor will have a greater depth than the previous one, the same strategy was applied for the cubes with one exception, in this case, the cubes have a z-index (the same z-index), the reason is, it was necessary to make sure the cubes are located above the floors, I don’t use another container for the cubes, the floors and the cubes are in the same container.

Movement of the cubes

This was one of the most challenging parts of the game because I needed to move the cube or cubes (sometimes the player can move two cubes at the same time), to do that I used the react-spring library, with this library and its useSpring hook I can indicate the move I need (left, top), the move only happens if it passes some validations

A cube only can move if:

There is a floor:, if the player wants to move a cube to a new position, that position needs to have a floor, it sounds fun to say that, but a level code was necessary to have such validation.

In front, there is another cube and there is a floor: In this case, the validation of the floor is made for the second cube, this means when the main cube has in front of another cube, it’s necessary to know if the new position of the second cube has a floor.

In front, there is another cube and in front of that cube, there is no other cube: This scenario is when we have three cubes, the main cube wants to move to a position where there is another cube, now it’s necessary to know if the new poison the second cube is available, if in that position there is another cube, there will be no movement.

Portal validation.

Validate this type of cube was also challenging, some considerations that were necessary to have:

Not accepting movement input while teleporting a cube: when the user indicates the movement, it is possible to maintain a sustained movement, this means that the user does not need to leave the cursor finger (or keyboard in desktop) to indicate a new movement, wit portals it’s a little different because when a cube enters to a portal, this cube change to a new position, at that moment we have an animation that shows the change, to prevent a strange behavior, the input from the user is ignored, when the teleportation animation ends, the inputs are enabled again.

Validate that the portal exit point is available: All the cubes in the game can be teleport, if a regular cube is teleported the exit of the portal is blocked for that cube, in that case when a cube enters a portal the cube moves normally, this means that the portal behaves like a regular floor, this is convenient sometimes for some levels.

Undo validation.

The game has the option to restart a level, but the undo action is different because it needs to show the level in the previous state, to achieve this action was necessary to create a new state, in this state we save the previous state of the level, but no all the complete state, this means, that it only saves the things that change at that moment, for example, if the user only moves a cube, it’s not necessary to save the state of the floors or the state of the other cubes.

For example when a cube or cubes move, in that case, we save in an object called floors, the previous position where the cube was, always we have at least a cube moving.

But when it’s necessary to validate undo option for floors we have to take into consideration the type of the floor, for example, if the floor is a shaking floor, when the undo option is applied it’s necessary to show the floor again in the same position that we have before, other case is when we have a switch floor, it’s necessary to save the floors that were related with the switch and hide that floors again.

For portals the logic was different, in this case, we don’t have the teleportation animation because it’s possible to press the undo button many times, in that case, we only save the previous position of the cube and when the user press the undo button, the cube returns to the previous position, in that case, we see an animation of the cube from the current position to its previous position.

Save level solution

The state that was used for the undo option also was utilized for the solution option, in this case, only it saves this data when we are in the editor, the same state was utilized because when the user uses the undo option, at the same time is removing that movement from the solution.

The solution is saved in an array, this array contains the valid moves (if a user made a movement and the cube doesn’t move that movement isn’t saved) to prevent a big solution the editor has a limit of 250 movements, but a potential array of 250 movements continues to be a big value, that’s why the solution has a special treatment to save, in this case, the array is converted to a string, eliminating the repeated values and saving the number of times a value is repeated (when it is consecutive), when a level is loaded there is a conversion to the array again.

For example 37,27,12,42,32,44,23 is the solution for the level in the gif, in this case 37 means that it's necessary move the cube seven times to the position 3 (right-top)

Run solution.

The user can play many times a particular level, can restart it, and also can use the undo option the times that are necessary, but there are moments that a level is very complex, that is why the game has the option to show the solution of the level, that is the reason why in the editor to play the level and validate that the level has a solution, that solution is saved and later is executed to show the solution.

In other game that I developed Mr. Square, we have the same option to show the solution of the level, but in that case, the user needs to follow the movements to complete the level, but this game is different because the user doesn’t need to make any movement, all the movements are automatically executed, in this case the player only is a viewer, because of that, was necessary to disable all the inputs for the user, also if the user had made movements before, was necessary to restart el level before to start executing the solution.

Conclusions.

This game was a good challenge for me, this is the ninth game that I develop in ReactJS, with each game I learn something new, I do not consider myself a game developer, I do this type of project because it is fun and at the same time I learn new concepts of this library.

In these articles I wanted to share on a high level how I developed this game, the game code at the moment is private, just like the other games, my idea is maybe to create a course where I can show you how you can develop these games.

I'm not a native english speaker, actually this is my first articule in English, to be honest was more complex to me write these articules that develop the game 😅, but was a good experience, the next game (I have a new game in my head right now 😅) that I develop the idea is to write another articles in English, I know that I can improve day by day.

Thanks for reading these articles, you can find me at:

Part 1/2 - Game in ReactJS - Cuzzle

Jorge Rubiano — Mon, 13 Dec 2021 20:39:19 +0000

In this first part, I'm going to show you about the game and the different options it has.

In the second part, we are going to talk about the technical aspects and challenges in the development of this game.

The game

You can play the game online here: https://cuzzle-react.vercel.app/

Cuzzle ReactJS is an isometric puzzle game, inspired by Sokoban, the 1981 transport puzzle game in which the player has to push boxes around a warehouse to get them into different locations. Cuzzle ReactJS add collapsing floors, switches, and some nice graphics.

The idea behind the development of this game was to learn more about ReactJS, as you know ReactJS is a library that allows us to develop rich user interfaces with encapsulated components that manage their own state.

Actually, this is the ninth game that I developed in ReactJS and with every new game I learn something new, also this gives me the opportunity to test new features and/or strategies using this library.

In cuzzle ReactJS the user has 85 levels, divided into 4 sections, each section has a different level of difficulty.

On desktop, you can use the movement arrows and swipe events on mobile.

Game options

In this screen the user can access to the different sections of the game:

1. List of levels.

On this page, users can access the different levels of the game, in this case, we have four sections, by default the first level of each section is enabled (also has a different background color), to play the other levels it's necessary to complete the previous one.

2. Editor.

On this page users can create new levels (the 85 levels were created with this editor), the editor is divided into four steps:

Fist step - Add floors: the first step is to add the floors of the level, we have five types of floors:

Regular: This is a normal floor, depending on other validation a regular floor can change its behavior, a regular floor could be:

Shake floor: this is a temporal floor, if the main cube passes over a shaking floor the floor will fall.
Switch floors: When a switch is activated this kind of floor will appear, by default when the level load these floors aren’t visible.

Arrival points: These are the places where the cubes must be located to finish a level, at the same time we have two types of arrival points.

Regular: This is represented by the white rectangles, it’s possible to add a maximum of 8 of this type and at least one.
Main: As the name implies, this is the position where we need to locate the main cube, we have the option to change the color to red, yellow, or green, in this case, it’s only possible to add only one floor of this type.

Switch: this floor has the trigger that will activate the floors that will appear. When we add a switch to the board we have an option to indicate which floor will be visible when we activate the switch, we only can add one switch for level. If we remove a switch and previously we have floors related to it, those floors will return to their original state.

Portals: this is a special floor, that allows the cubes to “teleport” between two points because that condition we only have the option to add two floors of this type (entrance point and exit point respectively).

In this step we have other options, such as:

Change background color: It is possible to change the background of the level for four predefined colors.
Load preloaded levels: If we want to create/fork a level from an existing level, this is very useful because we don't need to start from scratch.
Load a level from a QR: As I mentioned before, the game doesn't have a backend, instead, the levels are saved in a QR, if we create a level previously we can load the QR and create a new one from this.
Remove all items: Sometimes we start to create a new level but we aren't very happy with the result, if we want to start over, it's not necessary to remove each element one by one, with this option we can remove all the elements and start again.
Relocate level positions: Sometimes we finish a level, but the level isn't in a good position (it's not centered for example), instead of removing the cubes and starting over, we can use this option to move all elements of the level at the same time.

Second Step - Add cubes: When we have already add the floors that we need for our level, it’s possible to add the cubes, the number of cubes depends on the number of arrival points that we add in the first step, the minimum value is two (one regular and main) or the maximum value is nine (8 regular one main).

The color of the main cube depends on the option that we choose in the first step (it’s possible to return to the previous step and change the color).

It’s possible to add the cubes on the following floors:

Regular.
Shake cubes.
Arrival points.

On the other hand, isn’t possible to add the cubes on the following floors:

Switch.
Switch floors.
Portals.

If we add the cube on a switch the other floors will be active immediately, in the case of the switch floors, these aren’t visible when the level loads, and finally on portals the cube will be “teleport” to another position.

If all the cubes are in the arrival points the editor will show a message because in that case the level is resolved, that doesn’t mean that isn’t possible to add cubes on arrival points, but at least one cube should be outside of an arrival point.

Third step - Play/Test Level: In this step we test that our level has a solution, this is very important, because that solution is saved, to prevent having an infinite solution or a solution with too many movements, the editor has a restriction of maximum 250 movements.

Fourth step - Publish level: in this step, we can download our level in a QR code, or share our level through a URL, the game hasn’t a backend infrastructure, the levels that we created in the editor are saved in the URL.

For example, this is the QR for the level in the gif and this is the corresponding URL

In this screen we have a copy button as well, this saves in the clipboard the structure of the level that is utilized to save the preloaded levels, at the end of the day is a string, this string has all the necessary information to recreate the level.

3. Other options:

On the lobby page it is possible to change other game options:

Enable/disabled sounds.
Upload QR code: We can "upload" (actually it’s not a real upload, because the game doesn’t have a backend, in this case, we read the content of the QR, but it’s necessary to have the option to select it, this is the reason we use a file input to do this action) the QR that we create in the editor if the QR is valid the user can play the level.
Share option: As the name implies, with this option we can share the game (also we have de option to share a level and a custom level), on mobile, it's used the native navigator.share and on desktop (or browsers that don't support share) it's used the share-api-polyfill package.

In this first part, we talked about the game, we saw its options, in the second part, we are going to discuss the technical aspect of the game and the challenges to develop it.

You can continue with the second part

Zeek The Geek en ReactJS - Cuarta Parte

Jorge Rubiano — Sun, 17 Jan 2021 01:14:28 +0000

En la primera parte de esta serie de artículos, hablamos de la historia del juego original, la motivación del desarrollo de esta nueva versión, sus opciones así como el stack de tecnología utilizada.

En la segunda parte se mostró cada uno de los bloques que componen el juego, así como la interacción que pueden tener éstos con el personaje.

En la tercera parte se abordó algunos retos técnicos que tuvo el desarrollo del juego, así como se entregó una solución a los mismos.

URL del juego: https://zeek.jorge-rubiano.vercel.app/

En esta cuarta y última parte deseo compartir algunas funcionalidades extras que posee el juego, así como el ambiente de desarrollo utilizado para el mismo.

Creación de nuevos niveles.

El juego como tal posee 220 niveles precargados, pero en este caso deseaba dar la posibilidad a los usuarios de crear sus propios niveles, como tal el editor fue de gran ayuda en el momento de crear los niveles del juego, pero deseaba que está herramienta no sólo quedará para el momento de desarrollo, sino que fuera parte del juego, a diferencia de Mr. Square que si tiene una base de datos donde se pueden almacenar lo niveles, Zeek no cuenta con está opción, entonces para "almacenar" lo nivles se hace uso de la URL o de códigos QR, tuve la inspiración para realizar está acción en una coferencia de la Chrome Dev Summit del año 2019, en la cual mostraban un ejemplo de como se podía compartir un juego y sus niveles a través de estás opciones.

Un ejemplo de un nivel es el siguiente:

El mismo nivel se puede acceder a través de este link

Esto permite que se pueda compartir fácilmente cualquier nivel creado, además se ahorra la necesidad de tener esta información almacenada en una base de datos.

Ambiente de desarrollo.

Inicialmente empecé a desarrollar el juego en codesandbox este permite protopiar aplicaciones de forma rápida, en juegos anteriores ya había utilizado este ambiente para la fase inicial de desarrollo, posteriormente finalizaba el juego en mi ambiente local, pero perdía lo que codesandbox me daba que era la opción de poder escribir código en cualquier momento y en cualquier equipo, deseaba tener lo mismo y es así que empecé a utilizar codespaces este es un servicio de Github (actualmente aún está en fase de prueba), el cual permite tener todo un ambiente de desarrollo en la nube, es posible utilizarlo directamente en el navegador o a través de VS Code a través de una extensión

Jorge Rubiano

@ostjh

#CodeSpaces from @github is great, it is possible to have a programming environment in the cloud, even to program from the iPad 🤯🤯 #reactjs #js

18:32 PM - 02 Jan 2021

Fue incluso posible hacer pruebas en el iPad, aunque a decir verdad no es lo mejor, no por codespaces sino por el iPad en sí, ya que acciones como utilizar el scroll fue difícil, cabe anotar que en las pruebas hice uso de un mouse y teclado, ya que sin ellos no sería una buena experiencia.

El uso de codespaces fue genial y me permitió que el código estuviera siempre disponible, sin la necesidad de estar en un sólo dispositivo, codespaces tiene una integración muy buena con github, por lo que me parece una buena opción para futuros proyectos.

Despliegue de la aplicación

A diferencia de otros juegos en este caso hice uso del servicio conocido como vercel, ya que el juego es estático y no requiere de backend, en juegos pasados había utilizado Heroku, aún sigue siendo mi servicio favorito, pero en este caso no era necesario, ya que como lo mencionaba el juego es 100% estático, vercel en este caso fue muy bueno para mí, ya anteriormente lo había utilizado cuando se denominaba ZEIT, y desde ese entonces me gustaba mucho.

Cuando desplegué la aplicación por primera vez, tuve un inconveniente con las rutas, el juego al ser una SPA, todo lo relacionado a la rutas se maneja en el front, lo cual presentaba un problema, ya que al ingresar directamente a un ruta por ejemplo: https://zeek.jorge-rubiano.vercel.app/levels vercel me indicaba que esa ruta no existía, en la documentación se explicaba como solucionarlo y en este caso era agregando un archivo de configuración indicando ese caso.

vercel.json

{
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}

Muchas gracias por leer estos artículos, estas son algunas conclusiones.

Conclusiones

Realizar este juego presentó un gran desafío y muchos aprendizajes, los cuales sé que podré usar en mi vida profesional y además en la creación de nuevos juegos.
Fue divertido rehacer un juego después de 13 años, en tecnologías diferentes, ahora con la posibilidad de ser jugado en cualquier dispositivo que cuente con una navegador web.
ReactJS es una librería que tiene muchas posibilidades, no sólo para crear interfaces sino también en la creación de juegos, la comunidad así lo ha demostrado e iniciativas como react-three-fiber demuestran lo que es posible hacer, espero en un futuro cercano poder hacer uso de esta librería para desarrollar un nuevo juego.
Juegos de este tipo entregan un gran reto, ya que es necesario tener en cuenta muchas validaciones y variaciones, es sorprendente que el juego original tenga más de 25 años, considero que es un gran juego y además fue un gran reto.
Este juego me permitió explorar más acerca de como aprovechar más lo que nos entrega la web, en este caso el poder de una URL, a decir verdad es algo que ha estado desde el inicio de la internet, poder compartir a través de una URL y eso es lo que nos entrega la web, sin necesidad de descargar nada podemos acceder directamente a lo que necesitamos y en este caso ser utilizada como un medio de almacenamiento.
Hacer uso de codespaces me pareció genial, en este caso lo utilicé para un proyecto 100% estático, pero es posible incluso hacer uso de funcionalidades de backend, seguiré explorando este ambiente y espero que pronto salga de la fase de pruebas y esté disponible para todos.

Jorge Rubiano.

Me pueden encontrar en:

Zeek The Geek en ReactJS - Tercera Parte

Jorge Rubiano — Sun, 17 Jan 2021 01:14:23 +0000

En la segunda parte se mostró cada uno de los bloques que componen el juego, así como la interacción que pueden tener éstos con el personaje.

URL del juego: https://zeek.jorge-rubiano.vercel.app/

En esta tercera parte me gustaría hablar acerca de los retos técnicos del juego.

Movimiento del personaje.

El personaje puede moverse de tres formas como son:

Haciendo uso del teclado, a través de las teclas de movimiento.
A través del control integrado en el juego.
Indicando el punto de destino al cual deberá dirigirse Zeek.

Los tres tipos pueden ser usados en desktop, mientras en dispositivos móviles se puede hacer uso de las opciones 2 y 3.

Para mover el personaje y por consiguiente a los bloques que Zeek puede mover, se hizo uso de la librería conocida como react-spring, está librería permite indicar el punto de origen del movimiento así como su punto de destino, una vez se ha completado la animación, se entrega un evento.

Una vez se tiene este evento se puede evaluar el entorno del personaje, esto también aplica a elementos como los dinos, es decir, para los dinos se utilizó la misma lógica, con la diferencia que el movimiento es indicado por el sistema y no por el usuario.

Uno de los retos en el movimiento del personaje fue validar si el personaje se podría mover o no, por lo que se debía validar el tipo de bloque que existía antes de moverse, pero si el bloque que existía a la posición a la que se quería mover el personaje se podía mover, se debía validar si la posición de ese elemento estaría libre.

Para garantizar que el personaje y el elemento que se esté moviendo finalizan al mismo tiempo, se validó que no se acepta eventos de movimiento antes que finalice el movimiento, esto permitió que sí se hace un cambio de movimiento rápido, Zeek sólo responderá una vez que haya finalizado de moverse.

Movimiento Zeek indicando el punto de destino.

Como lo indicaba anteriormente uno de los métodos para mover a Zeek, es indicando su punto de destino, para ello se busca la ruta más corta (más no la más segura) a seguir, para lograr este objetivo, se hizo uso de la librería pathfinding, está librería utiliza una gran variedad de algoritmos para lograrlo, para el juego hice uso de A* Finder.

La librería en este caso solicita una matriz, en la cual se indica que posiciones son disponibles/vacías y cuáles no, una vez realizado este proceso, la librería entregará un array de posiciones indicando la ruta más corta encontrada.

Un ejemplo de ello es el siguiente escenario, a pesar de tener varios caminos, se ha ido por la ruta más corta encontrada por A* Finder.

Gráficamente está búsqueda se puede visualizar de esta forma.

Se puede probar los demás algoritmos de esta librería en esta url: http://qiao.github.io/PathFinding.js/visual/

Como lo comentaba la librería espera una matriz para así entregar la ruta más óptima, más no la más segura, ya que no se valida si en la ruta encontrada existan peligros que puedan eliminar a zeek, aún así hay validaciones que buscan minimizar este peligro, por ejemplo no se puede indicar que el punto de destino sea una flor púrpura o azul.

Una vez que se tiene la ruta se debe indicarle a Zeek los movimientos, como tal zeek sólo recibe direcciones (right, left, down, up), por lo que se debe hacer una conversión de las coordenadas a direcciones, esta acción se realizó a través de la siguiente función.

Es posible cambiar la dirección del personaje en cualquier momento, es decir, si se le ha indicado la ruta al personaje y se presiona alguna tecla del teclado, esta ruta se cancelará aceptando la última entrada dada.

Creación de muros

Como tal el juego cuenta con una gran variedad de bloques que son interactivos, bien sea por que desaparecen al contacto con otro bloque (flores amarillas, tesoros, etc) o que el personaje puede mover en el escenario (dinamita, manzanas, cristales mágicos, etc), pero los muros como tal son elementos estáticos, cada elemento en el escenario es un componente como tal por lo que se debe renderizar, en el caso de los muros se debe igualmente renderizar, pero en este caso no hacen acción alguna, más que bloquear.

Por ello los muros no se renderizan, sino que se crea una imagen, para ello existe un función que recibe el escenario y busca en éste los elementos de tipo muro, a partir de esto crean una imagen haciendo uso de canvas.

Esto permitió liberar el render del juego de elementos innecesarios, ya que los muros se renderizan como un sólo background, aún así dentro del estado si se valida si existe un muro en una posición, más no se renderizan.

Animaciones de los bloques.

Como lo había indicado anteriormente los movimientos del personaje y de otros elementos del escenario, se realizaron a través de react-spring, pero para las demás animaciones, como pasos, explosiones y demás se hizo uso de las animaciones de CSS.

La animación proviene de un sprite que contiene todos los movimientos necesarios para el juego.

Por ejemplo para indicar que el personaje estaba caminando hacía la derecha, se pasaba una clase la cual iniciaba la animación de los pasos, de la misma manera si se deseaba indicar si el personaje estaba durmiendo.

Como se puede apreciar se hizo uso de variables en CSS, las cuales cambian dinámicamente dependiendo del tipo de estado que tenga el personaje.

Haciendo uso de animaciones en CSS, ayudó a liberar al render del juego.

Temporizador de bloques.

En el juego existen varios bloques que una vez activados tienen un tiempo para realizar una acción, por ejemplo:

Al activar una dinamita.
Al colisionar dos cristales mágicos.
Al comer una manzana la flor púrpura.
Al digerir una manzana.

Para manejar estos tiempos, se hizo uso de un custom hook, denominado useInterval, este permitió indicar los tiempos que cada acción debían esperar, este hook sólo se activa sólo cuando se requiere una animación, es decir, si no existe algún elemento que requiera un temporizador useInterval no estará en ejecución.

Validación explosión dinamita.

El bloque de tipo dinamita, es un bloque interesante, ya que puede eliminar una gran variedad de otros bloques, incluido a Zeek, pero igualmente puede activar otra dinamita, existen escenarios donde esta característica le entrega un tiempo límite para terminar el escenario.

Pero para que la dinamita sepa que debe eliminar una vez explote, debe conocer su entorno, además debe estar en reposo, es decir si el personaje está moviendo la dinamita y el tiempo de explosión ha acabado, sólo cuando la animación de movimiento haya acabado explotará y por consiguiente eliminará a Zeek.

Validación del Láser.

El láser es un elemento estático, que sólo puede ser eliminado por una dinamita, el láser siempre estará observando a Zeek, si éste se encuentra en su vista lo eliminará, si existe algún elemento entre Zeek y el láser no podrá eliminarlo, para ello desde el editor fue necesario realizar esa acción

En el juego se tuvo que realizar la misma acción, en este caso revisar si la nueva posición del personaje estaba a la "vista" del láser y si no había algún elemento que lo bloqueará, fue necesario hacer una validación especial cuando el elemento de bloqueo es un dino, por la misma naturaleza del mismo, es decir a diferencia de los demás bloques, este está en constante movimiento, por lo que se debía validar no sólo en que posición estaba sino además en qué posición estaría después.

Validación movimiento Dino (Piclasops)

A diferencia de los demás bloques el Dino, se mueve automáticamente, además de existir la posibilidad de existir varios dinos al mismo tiempo, era necesario validar que un dino no quedará en la misma posición de otro, por lo que se válido que una vez un dino haya seleccionado su próxima posición, los demás dinos tomarían esa posición como bloqueante

Otra validación fue relacionada a los elementos que mueve Zeek, un dino puede ser bloqueado y pasar a un estado estático, no era posible establecer la lógica de establecer una posición bloqueante a un movimiento futuro de un dino, si el elemento que iba a tomar esa posición era un bloque que estaba moviendo Zeek (más no Zeek, por que en este caso moriría), por lo cual fue necesario saber si un bloque futuro estaría en esa posición.

En esta tercera entrega quería compartir algunos retos técnicos en el desarrollo del juego, como tal es un juego que tiene muchas "partes movibles", fue desafiantes ponerlas en conjunto y que funcionarán como un todo, la validación de movimiento así como las acciones de bloques como los láseres representó un gran reto.

En la cuarta y última entrega hablaremos acerca del ambiente de desarrollo utilizado y otras características que tiene el juego.

Zeek The Geek en ReactJS - Segunda Parte

Jorge Rubiano — Sun, 17 Jan 2021 01:14:17 +0000

URL del juego: https://zeek.jorge-rubiano.vercel.app/

En esta parte se abordará los bloques que componen el juego.

Bloques del juego.

El juego cuenta con una variedad de tipos de bloques como son:

1. Zeek

Es el personaje principal, Zeek debe moverse a través del escenario, su objetivo es el de recoger tantas flores amarillas y tesoros pueda, su objetivo final será recoger el hongo que le permitirá finalizar el escenario.

Si no se mueve Zeek por un buen tiempo, se dormirá, se despertará cuando se indique que se debe mover de nuevo o si algo externo lo despierta (un láser o Piclasops)

Si llegase a comerse una flor azul o un hongo malvado (Toadstools), será envenenado, si se encuentra con un Piclasops (dino), morirá o si se encuentra en la vista de un láser será eliminado 😞

2. Piclasops (Dino).

Piclasops (o dino) eliminará algunos bloques en el escenario

Flores amarillas, azules, púrpura
Huevos
Manzanas/Manzanas con hongos
Hongos (tanto buenos como malos)
Píldoras de invisibilidad.
Y a Zeek

Si un dino se come a un hongo bueno y es el único en el escenario, Zeek morirá. 💀

Reglas que rigen al dino.

Pueden existir varios dinos en el escenario, cuando un dino se encuentra con otro colisionará,
Un dino buscará girar siempre hacia la izquierda si no está disponible, buscará la dirección que esté disponible (en el sentido de las manecillas del reloj), si no existe ninguna regresará por el mismo camino en venía
Un dino puede estar inicialmente bloqueado y haciendo uso de otro bloque se puede desbloquear.
Se puede eliminar un dino a través de una dinamita

Dino como ayuda de Zeek.

El dino también puede servir como ayuda para Zeek, ya que puede eliminar bloques malos para Zeek, como las flores azules y el hongo malo, además de servir como elemento de bloqueo en movimiento contra los láseres.

3. Manzanas.

Las manzanas son un bloque que Zeek puede mover en el escenario, son útiles para:

Bloquear un láser.
Alimentar a las flores púrpura.

Una manzana con un gusano, hará que la digestión de la flor púrpura dure más.

4. Flores púrpura.

Estás flores son uno de los principales enemigos de Zeek esta tiene tres estados:

Cerrada: En este estado es inofensiva para Zeek, pero si éste se acerca a la flor cuando está en este estado, se abrirá, si Zeek permanece quieto la flor se lo comerá.
Abierta: Si Zeek pasa cerca se lo comerá.
Digiriendo: Si a la flor se le da una manzana, comenzará digerir, lo cual hará que sea inofensiva, una vez termine de digerir pasará a un estado cerrado.

5. Puerta.

Actúa como un bloque de bloqueo, no se puede pasar quitar una puerta si no se cuenta con una llave, o si se elimina con una dinamita

6. Llave.

Permite abrir las puertas que se describieron anteriormente, Zeek sólo puede tener una llave al mismo tiempo, es decir si ya ha recogido una llave, no podrá recoger otra.

7. Tesoros.

Zeek podrá tomar estos tesoros, otorgándole 1000 puntos por cada tesoro que recoja.

8. Dinamita.

Es un elemento que Zeek puede mover, al moverla la activará, es por ello que Zeek debe ser cuidadoso, si Zeek está cerca cuando al dinamita explota eliminará a Zeek también, la dinamita tiene la habilidad de eliminar la mayoría de los elementos a su alrededor, si uno de los bloques que elimina es el "hongo bueno", y si es el único hongo en el escenario, Zeek morirá

Si se encuentra otra dinamita cerca se activará, creando una reacción en cadena.

9. Píldora de invisibilidad.

Permite que Zeek zea invisible a los láseres y las flores púrpura, durante el tiempo que es invisible podrá pasar cerca de estos bloques y no será eliminado, pero no es invisible a los dinos o a los bloques como flores azules y dinamita

10. Láser.

Los láseres siempre estarán mirando a Zeek, si no existe ningún elemento entre Zeek y el láser lo eliminará.

11. Cristales Mágicos.

Son elementos que puede mover Zeek, pueden servir para bloquear a un láser, pero si un cristal mágico colisiona contra otra u otros, se eliminará.

12. Hongo.

Hongos que Zeek recolecta para el suministro de su energía, una vez que Zeek se ha comido un hongo, podrá pasar al siguiente escenario, otros elementos pueden destruir un hongo como son el dino o la dinamita, si esto llegase a pasar Zeek morirá (siempre y cuando sólo exista un hongo en el escenario)

13. Toadstools (Hongo malo)

Toadstools que son fatales si se comen, la idea es engañar a Zeek, ya que son muy parecidos.

14. Flores Amarillas.

Estás flores le darán a Zeek 50 puntos cada vez que las recoge, además sirven como elementos de bloqueo contra un láser.

15. Flores Azules.

Son flores malvadas, si Zeek llegase a tomar una morirá.

16. Huevo Azul.

Cuando Zeek toma un huevo azul, todas las flores amarillas se convierten en flores azules, del mismo modo las flores azules se convierten en flores amarillas.

17. Bola Amarilla.

Es un bloque que Zeek puede mover en el escenario, sirve para bloquear láser e incluso bloquear a los dinos, no es un elemento que se pueda destruir con una dinamita.

18. Barriles amarillos.

Son elementos que no se pueden mover o eliminar, se pueden clasificar como muros.

19. Muros.

Son elementos que no se pueden mover, pero si actúan como elementos bloqueantes, en total existen 10 tipos de muros, los cuales se pueden combinar de diferentes formas.

En esta segunda parte quise ahondar en cada uno de los bloques del juego, así como mostrar como se comportan estos con el personaje o con otros bloques.

En la tercera parte mostraré más acerca de los retos técnicos que tuvo el desarrollo de este juego haciendo uso de ReactJS

Zeek The Geek en ReactJS - Primera Parte

Jorge Rubiano — Sun, 17 Jan 2021 01:14:10 +0000

URL del juego: https://zeek.jorge-rubiano.vercel.app/

En esta serie de cuatro artículos, me gustaría compartir la experiencia de desarrollo de un nuevo juego desarrollado en ReactJS, en este caso un juego clásico como es Zeek The Geek.

El Juego

Zeek the Geek es un juego similar al Sokoban. El objetivo es guiar a Zeek, un geek del otro lado de la galaxia (donde los geeks no son tan diferentes de los de la Tierra) alrededor de un nivel similar a un laberinto en busca de deliciosos hongos. En el camino puede recoger flores amarillas, cofres del tesoro y cristales mágicos.

Recoger el hongo mueve a Zeek al siguiente nivel. Pero cuidado, porque también hay trampas y monstruos en cada laberinto: las flores rosadas lo devorarán si camina cerca de ellas, hongos mortales envenerará a nuestro héroe si decide meter uno en su garganta, y la dinamita, aunque útil, puede ser peligrosa en las manos equivocadas. O pies.

El juego fue desarrollado originalmente por Sidewalk Software y lanzado en 1995 para Windows

Motivación.

He venido desarrollando juegos haciendo uso de ReactJS, con el objetivo de afianzar los conocimientos de está librería, así como aprender nuevos conceptos que la misma tiene.

Este es el sexto juego que he desarrollado en ReactJS, otros juegos son:

En este sexto juego deseaba poner en práctica lo aprendido en Mr. Square, puntualmente el uso de react-srping para las acciones de movimiento, éste juego me presentaba la oportunidad de hacerlo, algo curioso es que ya había hecho una versión de este juego hace más de 13 años haciendo uso de Visual Basic 6.0 y Flash (usaba flash para el manejo de sprites, cada fotograma representaba la posición de movimiento de cada elemento, tiempos aquellos)

Zeek en VB6/Flash

El mismo nivel en la nueva versión web:

Pero a diferencia de esa versión, está cuenta con la posibilidad de ser multiplataforma y multidispositivo gracias a que es web, además de contar con muchos más niveles (220) que la versión anterior que sólo contaba con 20 niveles.

Opciones del Juego.

El juego cuenta con las siguientes opciones:

Start

Esta opción mostrará los niveles precargados del juego, en total existen 220 niveles, cada uno con un nivel de dificultad diferente, a su vez este tiene las siguientes opciones:

Seleccionar nivel: El usuario podrá seleccionar el nivel que desee jugar, em este caso no hay dependencia de niveles

Nivel aleatorio: A través de está opción se mostrará un nivel aleatorio de los 220 existentes.

Cargar nivel a través de QR: En está opción se podrá cargar un nivel que previamente se haya creado a través de editor.

Editor

Permite la creación de nuevo niveles, a su vez tiene las sigientes opciones:

Barra de bloques: Muestra todos los bloques disponibles para crear un escenario, en total existen 18 tipos de bloques que a su vez tienen diferentes tipos, por ejemplo un tipo muro, tiene a su vez 11 tipos, un tipo flor púrpura tiene dos tipos (flor abierta y cerrada), el tipo manzana tiene dos tipos (manzana normal y manzana con gusano)
Play: Permite probar el nivel creado, un nivel es válido si al menos tiene a Zeek y al hongo.
Outline: Opción que permite crear un contorno en el escenario con un bloque de tipo muro, puerta, flor amarilla y flor azul, está opción estará bloqueada a no ser que el bloque seleccionado se de los tipos anteriormente mencionados.

Leveles: Muestra los niveles precargados del juego, a partir de estos niveles se pueden crear nuevos niveles (está opción, no modificará los niveles existentes)

Load QR: Cargará algún nivel que previamente se haya creado, al igual que la opción anterior sólo se podrá crear un nuevo nivel a partir de éste y no modificará el nivel cargado.

Permite compartir el juego en redes sociales, si el navegador no soporta la opción nativa de share, se hace uso del paquete share-api-polyfill

Sounds

Habilita/deshabilita los sonidos del juego.

Stack

Como lo he mencionado el juego ha sido desarrollado en ReactJS, en este caso haciendo uso del paquete conocido Create React App, a diferencia de otros juegos como el parchís y Mr. Square éste juego no cuenta con un componente de backend

Otros paquetes utilizados son:

nuka-carousel

Esta librería permite el uso de un carousel de forma muy fácil, en este caso fue utilizado para mostrar el listado de niveles que componen el juego.

qrcode.react

Librería que permite la creación de códigos QR, está ha sido utilizada para "almacenar" los niveles creados en el editor.

qrcode-decoder

Está librería permite leer un QR, en este caso sólo se hizo uso de la opción de leer un QR desde una imagen, aunque la librería tiene la opción de leer un QR desde la cámara.

En este caso la librería se utilizó para leer el QR generado en el editor.

react-keyboard-event-handler

Permite capturar de forma sencilla los eventos del teclado, en este caso fue utilizada para capturar las teclas de movimiento para así mover al personaje en el escenario.

share-api-polyfill

Si el navegador donde se está jugando el juego no cuenta con la opción de compartir nativa, se ejecutará está librería, la cual presenta la misma interfaz de la api nativa.

sweetalert

Está librería reemplaza los mensajes nativos del navegador, como alert(), prompt(), en este caso fue utilizada para mostrar mensajes de error o informativos en el juego.

pathfinding

Librería que ayuda a encontrar la ruta más corta/óptima dado dos puntos, en este caso fue utilizada para indicar el camino que puede tomar el personaje cuando el usuario se lo indica en el escenario.

howler

Librería para el manejo de sonidos, una característica especial que tiene está librería es la capacidad de manejar "sprites de sonidos", lo que permite al igual que los sprites de imágenes, descargar un sólo archivo, en vez de varios, lo cual ayuda a la carga del juego.

En esta primera parte quería compartir acerca del juego original, las motivaciones, las opciones de está versión del juego que he desarrollado en ReactJS, así como el stack de tecnología utilizada.

En la segunda parte veremos más acerca del juego, así como los bloques que lo componen.

Mr. Square en ReactJS - Primera Parte

Jorge Rubiano — Sat, 08 Aug 2020 01:02:33 +0000

En este artículo deseo compartir la experiencia de desarrollo de juego llamado Mr. Square ReactJS, el juego está desarrollado haciendo uso de #ReactJS entre otras tecnologías, que iré ampliando durante el resto del artículo.

Enlace del juego: https://mrsquare.herokuapp.com/

Jorge Rubiano

@ostjh

Mr. Square #reactjs ⚛ mrsquare.herokuapp.com #PWA #shortcuts #games

18:08 PM - 07 Aug 2020

Algunas cifras:

El juego cuenta con 245 niveles, repartidos en 16 capítulos.
Cuenta con 10 personajes.
Esta disponibles en 8 idiomas (gracias a Google Translate, lamento algún error en ese aspecto)
Cuenta con un editor para la creación de nuevos niveles (requiere autenticación a través de redes sociales)
Jugabilidad a través del teclado (desktop) o a través de eventos swipe (deslizar) en desktop y en móvil.
Cuenta con tema oscuro (dark mode).

El desarrollo de este juego tomó en gran parte las experiencias adquiridas durante el desarrollo del Juego El Parchís, el cual igualmente fue desarrollado en ReactJS

El juego

Mr. Square es un juego originalmente desarrollado por el estudio de desarrollo Ludic Side, desde el primer momento en que lo jugué, me pareció un juego con una dinámica única la cual deseaba emular haciendo uso de ReactJS.

Objetivo del juego.

Jorge Rubiano

@ostjh

@dan_abramov Hi, I used react-spring react-spring.io for this game mrsquare.herokuapp.com and I had good results to make the animation of the character 👍

21:02 PM - 23 Jul 2020

El objetivo del juego es mover un personaje (a través de deslizar el personaje en dispositivos móviles o desktop o a través del teclado en desktop), cada vez que el/los personajes se mueven, deja un bloque por donde ha pasado (en aquellas posiciones donde sea posible, existen posiciones donde no se dejan bloques, como es el caso de los portales, las flechas y los magnetos), la idea es completar todo el escenario con dichos bloques.

Desarrollo del juego.

El juego está desarrollado haciendo uso de ReactJS y de las últimas tecnologías que está librería ofrece, como es el caso de los hooks.

Inicialmente cree un "styleguide" con los elementos que harían parte del juego, estos elementos (bloques) fueron creados en su mayoría en CSS, cuando no me fue posible hacerlo en css (caso de los portales y magnetos) se utilizó svgs.

Como se puede apreciar, en este "styleguide" están todos los bloques que se usan en el juego, así como las animaciones que tendrán, como es bien sabido el uso de componentes facilita en gran medida el desarrollo de aplicaciones, y para este juego no es la excepción, cada bloque es un componente el cual recibe los props necesarios para ser renderizados, por ejemplo para indicar si será o no animados (como es el caso de las flechas), las dimensiones (ancho y alto) la posición, entre otras opciones.

Inicialmente el juego lo inicie desarrollando en codesandbox, esta es una gran herramienta que ayuda a iniciar un rápido prototipado sin la necesidad de instalar nada localmente, debido a que el juego tiene un componente en backend, no me fue posible desarrollar completamente el juego en este ambiente.

Tecnologías:

El juego cuenta con dos proyectos, uno relacionado al frontend y otro para la funcionalidad del backend.

Front-end.

ReactJS

https://es.reactjs.org/

Es una librería que ayuda a crear interfaces de usuario interactivas de forma sencilla.

Permite diseñar vistas simples para cada estado de nuestra aplicación y React se encargará de actualizar y renderizar de manera eficiente los componentes correctos cuando los datos cambien.

Para una fácil configuración del proyecto, se utilizó el paquete conocido como Create React APP o CRA, este paquete entrega muchos beneficios, como por ejemplo configurar por nosotros webpack, además de dar soporte a service workers a través de workbox permitiendo que el juego sea una PWA.

react-spring

https://www.react-spring.io/

Es una librería de animación basada la física denominada spring-physic que cubre la mayoría de las necesidades de animación relacionadas con la interfaz de usuario.

Esta librería brinda herramientas lo suficientemente flexibles para realizar animaciones complejas.

En el caso del juego esta librería fue usada para manejar la animación de movimiento del/los personajes en el escenario.

reach/router

https://reach.tech/router/

Esta librería permite un fácil manejo de las diferentes pantallas que componente el juego, ya había tenido una experiencia de usarla en el juego del parchís, por lo que su inclusión para este juego fue relativamente fácil.

nuka-carousel

https://github.com/FormidableLabs/nuka-carousel

Paquete para el manejo de un carousel, esta librería fue ampliamente utilizada en todo el juego, en secciones como: Listado de capítulos, listado de niveles y en listado de personajes.

nuka-carousel, entrega una fácil configuración y permite ser extendido en sus estilos de forma sencilla.

react-swipeable

https://www.npmjs.com/package/react-swipeable

Paquete que entrega la funcionalidad para establecer eventos de tipo swipe de forma sencilla a través del uso de hooks.

Este paquete fue utilizado para establecer los eventos de movimiento del personaje, tanto para dispositivos móviles, así como para desktop.

Back-end.

El componente del servidor fue ampliamente reutilizado del proyecto del parchís (pero sin la capa de websockets), en este caso se hace uso de la misma lógica utilizada para la autenticación de usuarios a través de redes sociales.

También es posible almacenar los niveles creados por lo usuarios, lo cual amplía la cantidad de niveles existentes en el juego.

En el backend se hace uso de NodeJS y de las siguientes paquetes:

ExpressJS

https://expressjs.com/

Paquete que permite manejar las rutas a nivel de backend, en este caso son las rutas relacionadas al API del juego, como la autenticación, obtención de niveles y creación de los mismos, además de servir los assets del juego.

PassportJS

http://www.passportjs.org/

Paquete que permite realizar la autenticación con redes sociales, este paquete permite serializar la respuesta de cada uno de los servicios, a través de un API unificada, lo que facilita manejar múltiples tipos de autenticación a través de las denominadas "estrategias" que posee.

Para el caso puntual del juego se utilizaron tres estrategias como son:

Redis

https://redis.io/

En este caso se hizo uso de redis para el almacenamiento de sesión de usuarios, cuando se realiza la autenticación, esto previene que la sesión de usuario caduque.

MySql

Como persistencia de datos se optó el uso de una base de datos relacional como es el caso de Mysql.

La base de datos es relativamente pequeña, ya que cuenta con 4 tablas como es:

usuarios
Listado de redes sociales
Listado de likes por usuarios
Listado de niveles creados por los usuarios.

Continuará...

En la segunda parte de este artículo hablaré de los retos de desarrollo del juego.
En la tercera parte de este artículo compartiré algunas de las funcionalidades que tiene el juego.

Mr. Square en ReactJS - Segunda Parte

Jorge Rubiano — Sat, 08 Aug 2020 01:00:38 +0000

En la primera parte del artículo, se habló acerca del juego Mr. Square, las reglas que lo rigen, así como las tecnologías que se utilizaron para su desarrollo.

En esta segunda parte hablaré de los retos de desarrollo del juego.

Enlace del juego: https://mrsquare.herokuapp.com/

Movimiento del personaje.

Este fue uno de los temas más complejos para manejar en el juego, uno de los primeros acercamientos que hizo fue intentar mover el personaje a través de css, pero en este caso es necesario tener un evento que indique cuando la animación ha finalizado, y esto se debía hacer cada vez que el personaje completaba una celda, es por ello que que se hizo uso del paquete react-spring, el cual otorga el hook conocido como useSpring dando la capacidad de establecer la posición del elemento, además tiene un evento llamado onRest, este evento se "dispara" cada vez que la animación ha finalizado, es en este punto donde se realizan las evaluaciones del personaje.

Validación movimiento del personaje contra otro personaje

Cada vez que el personaje se ha movido una celda, debe evaluar su entorno, además de evaluar la celda donde se encuentra.

Cada vez que el personaje inicia un movimiento debe validar:

Choca por que ha llegado al límite del escenario.
Choca por que existe un bloque.
Choca por que existe un bloque que ha dejado.
Choca contra otra personaje

Los tres primeros tipos de choque, no representa mucha dificultad ya que se puede validar el siguiente movimiento antes de que el personaje lo haga.

No sucede lo mismo cuando existen dos personajes en el escenario, ya que son elementos que están en movimiento, por lo cual cada uno de los personajes debe estar "consciente" de la posición del otro, cuando dos personajes van en sentido contrario, cada uno evalúa en qué posición estará el otro

En este caso se aplicó la siguiente regla:

Si os personajes se encuentran de forma horizontal, se dará prioridad al personaje que esté a la izquierda.
Del mismo modo si se encuentran de forma vertical, se le da prioridad al personaje que se encuentra arriba.

Con estas reglas se evitó que los personajes quedarán uno sobre otro, lo cual sucedió en muchas ocasiones en el tiempo del desarrollo.

Otro caso es cuando dos personajes llevan la misma dirección, ya que se debe evaluar si el personaje que está al frente ha dejado un bloque, si es así deberá chocar, pero si la posición donde estaba un personaje no deja bloque, deberá permitirle moverse de forma normal.

Validación del entorno del personaje.

El juego cuenta con diferentes tipos de bloques, los cuales cambian el comportamiento del personaje, como son:

Portales

Permite que el personaje se "teletransporte" de un punto a otro, cuando el personaje entra a un portal será enviado al portal de salida, si en esa posición ya hay otro personaje, no se podrá "teletransportar", cuando un personaje deja un portal, no dejará bloque, permitiendo que sea reutilizado.

Flechas

Cuando un personaje se encuentra sobre una flecha, la dirección del personaje es igual al de la flecha sobre la cual está ubicado, es por que ello que cuando un personaje termina cada celda, requiere saber sobre qué tipo de celda se encuentra, en el caso de las flechas no sólo conocer qué es una flecha, sino que además saber la dirección que tiene, cuando un personaje deja una celda de tipo flecha, no dejará bloque alguno.

Puentes

Este tipo de bloques, sólo permite que el personaje vaya en una sola dirección, cuando un personaje detecta que al frente de él hay un puente debe evaluar si tiene la misma dirección que lleva el personaje, igualmente si está encima de un puente sólo podrá moverse en la dirección que el puente tiene, cuando un personaje deja este tipo de celda deja un bloque, por lo que no se podrá pasar dos veces por el mismo puente.

Magnetos

Cuando un personaje pasa cerca de un magneto, el personaje se verá "atraído" al magneto, haciendo que el personaje se detenga, desde el editor está validado que no pueden existir magnetos cercanos al personaje y a otros magnetos, cuando un personaje deja un magento no dejará bloque, por lo que es posible pasar por un magneto más de una vez.

Personajes.

Para darle variedad al juego, éste cuenta con 10 personajes, cada uno con su propia "personalidad" y color, esto permite que cada vez que se seleccione un personaje, el color de los bloques que dejará en el escenario serán iguales al color que representa el personaje.

Cada personaje se basa en el mismo bloque, pero a través de envío de props, de define que tipo de personaje será y se aplicará los accesorios que tendrá cada uno, estos "accesorios" son en su mayoría SVGs.

Internacionalización (i11n)

El juego cuenta con 8 idiomas, en este caso no se utilizó alguna librería y/o paquete para realizar está acción, debido a que el juego no cuenta con demasiadas pantallas, en este caso se creo un archivo (json) que contiene cada uno de los textos que se usan en el juego y dependiendo del idioma que esté seleccionado se seleccionará los textos.

Se hizo uso de Google translate para realizar la traducción, algunos de los textos pueden no ser los adecuados, si llegase a ser el caso en este link es posible documentar el issue

Workshop (Taller).

Es la única sección del juego que requiere autenticación y conexión a internet ya que las opciones requieren comunicación con el servidor, desde guardar/eliminar un nivel, hasta jugar el nivel de otros usuarios.

Crear niveles.

El juego cuenta con 245 niveles ya precargados, los cuales se pueden jugar con o sin conexión, pero existe la posibilidad de crear nuevos niveles, esto a través del editor integrado con el que cuenta el juego, esto permite que los usuarios puedan crear sus niveles y compartirlos con los demás usuarios.

Un ejemplo de cómo se ve una url de un nivel compartido es:
https://mrsquare.herokuapp.com/level/11852

Top 10

Es posible que los usuarios califiquen un nivel, a través de botones me gusta/no me gusta, con este valor en la sección de Top 10 se entregan los niveles mejores calificados entre los niveles que han creado los usuarios.

Es una lista que va variando dependiendo de lo que los usuarios califican, cada vez que el usuario ingresa a esta sección se realiza una query la cual entrega está información.

Nivel aleatorio

Como su no nombre lo indica cada vez que el usuario selecciona está opción se le entrega un nivel aleatorio entre los niveles creados por lo usuarios, esto posibilita que aquellos niveles que no aparezcan por ejemplo en el Top 10, puedan ser jugados.

Buscar nivel.

Opción que permite jugar un nivel determinado, el usuario deberá ingresar el código del mismo, esto es útil cuando se desea que un nivel que se ha creado pueda ser jugado directamente por otros usuarios y no depender que el nivel salga en la sección de niveles aleatorios.

En la tercera parte de este artículo compartiré algunas de las funcionalidades que tiene el juego.

Mr. Square en ReactJS - Tercera Parte

Jorge Rubiano — Sat, 08 Aug 2020 00:58:16 +0000

En la primera parte de esta serie de artículos se habló acerca del juego Mr. Square, las reglas que lo rigen, así como las tecnologías que se utilizaron para su desarrollo.

En la segunda parte de compartí algunos de los retos de desarrollo de este juego.

En esta tercera y última parte compartiré algunas de las funcionalidades que tiene el juego.

Enlace del juego: https://mrsquare.herokuapp.com/

Jugabilidad offline:

Gracias al uso de workbox que viene incluido en CRA el juego es posible jugarlo sin conexión a internet, con excepción de workshop, ya que los assets del juego son almacenados a nivel local, esto también ayuda a que la carga del juego sea rápida, debido a que no tiene que hacer la descarga de los assets cada vez que se ingresa al juego.

Instalación del juego.

Gracias a que el juego es una PWA el juego es posible ser "instalado", lo cual permite que el usuario pueda acceder a este directamente desde su pantalla, como si de una aplicación nativa se tratase.

En el caso de Android, Windows y MacOs, la "instalación" del juego es posible hacerla a través de navegadores basados en Chromium/webkit, como es el caso por ejemplo de Chrome y Edge.

En el caso de iOS, safari otorga la opción de "instalación" también, pero no soporta el denominado manifest.json el cual permite indicar el comportamiento que tendrá el juego una vez haya sido "instalado"

Compartir.

Jorge Rubiano

@ostjh

Mr. Square #reactjs share level mrsquare.herokuapp.com

00:21 AM - 08 Aug 2020

Esta es una funcionalidad que permite en navegadores que la soporta mostrar la función de share nativa, esto otorgar una gran flexibilidad ya que el usuario podrá compartir sin la necesidad de acudir a otro servicio y utilizará la misma funcionalidad que utiliza en aplicaciones nativas.

En el caso que el navegador no soporte está acción, se redirigirá a Twitter directamente (no se desarrolló un fallback que permita otras redes sociales)

Shortcuts.

Shortcuts como su nombre lo indica permite establecer acceso directos a opciones de la aplicación, en este caso a opciones del juego.

Al momento de escribir este artículo Shortcuts está disponible en Android a través de Google Chrome (o navegadores basados en Chromium).

Jorge Rubiano

@ostjh

Mr. Square ReactJS uses new features like #shortcuts #pwa mrsquare.herokuapp.com @jungkees @slightlylate 😀

17:44 PM - 22 Jul 2020

Igualmente en Windows.

Jorge Rubiano

@ostjh

#shortcuts on windows #pwa -> Mr. Square #reactjs ⚛️mrsquare.herokuapp.com

19:21 PM - 31 Jul 2020

En el momento macOS no soporta esta funcionalidad y en iOS como se comentó anteriormente no es soportado el manifest.json que es donde se establece esta opción (como es bien sabido en iOS el único navegador que es permitido es safari, incluso navegadores como Chrome en iOS están basado en safari)

Gracias por llegar a esta parte del artículo, en este intenté recopilar todo acerca del proyecto, ha sido un proyecto que busca aprender más sobre React y el ecosistema que éste tiene, así como aprovechar las nuevas funcionalidades que los navegadores nos entrega

Conclusiones.

El desarrollo de este juego fue muy desafiante, no sólo por la parte gráfica, sino por las validaciones necesarias para el personaje.
El desarrollo de este juego no es exclusivo para ReactJS, otras librerías o frameworks podrían ser utilizadas, incluso librerías especializadas en el desarrollo de juegos, por ejemplo PhaserJS, en este caso no se hizo uso de canvas, que en muchos casos es la mejor opción para el desarrollo de juegos de este tipo.
Esta experiencia de desarrollo de este juego, ha ayudado a tener un mejor conocimiento de ReactJS, las fortalezas que esta librería nos ofrece, en este caso para el desarrollo de un juego.
El desarrollo basado en componentes, ayuda en gran medida a una rápido desarrollo, en el caso de este juego se pudo evidenciar, una vez creados los componentes base, se facilitó la creación de los demás elementos que compone el juego.
Aprender una librería y/o tecnología a través de juegos presenta una gran oportunidad, ya que nos encontramos con casos que tal vez no veamos en otros tipos de proyectos.