Integrar un sistema de recompensas basado en tokens fungibles dentro de un juego blockchain es una de las mecánicas más potentes del modelo play to earn. A continuación se explica paso a paso cómo emitir monedas al jugador que gana una partida, cómo resolver el desafío de logros por casillas disponibles y qué diferencias clave existen entre los estándares ERC-20 y ERC-721.
¿Cómo se resuelve el desafío de otorgar un logro con casillas disponibles?
Antes de implementar las monedas, es necesario resolver el desafío pendiente: emitir un logro al jugador que gana cuando todavía quedan casillas libres en el tablero [01:00].
El enfoque reutiliza el algoritmo que comprueba si la partida está terminada, pero en lugar de retornar falso directamente, se modela el resultado con una variable booleana:
- Se define una variable
casillasDisponibles, que por defecto es false.
- Durante el recorrido del tablero, si se encuentra al menos una casilla libre, se cambia su valor a
true.
- Al finalizar la comprobación, si hay casillas disponibles y el jugador ganó, se le otorga un nuevo logro.
¿Qué mejoras se pueden aplicar al código del desafío?
Existen dos optimizaciones recomendadas [02:17]:
- Reemplazar los ciclos
for por ciclos while.
- Extraer la lógica repetida en una función reutilizable, ya que el código es muy similar al de la verificación de partida terminada.
¿Qué es el estándar ERC-20 y en qué se diferencia del ERC-721?
Los tokens fungibles son intercambiables entre sí, igual que las monedas tradicionales o las criptomonedas. Se representan con el estándar ERC-20 [02:54]. En cambio, los tokens no fungibles (NFTs) utilizan el estándar ERC-721, donde cada token es único y se identifica con un ID individual.
La diferencia fundamental en la emisión es:
- ERC-721: se emite de a uno, con un ID específico por usuario.
- ERC-20: se emite por cantidad. Si se solicitan cien monedas, el usuario recibe cien.
¿Cómo se estructura el contrato del token fungible?
El contrato que representa la moneda del juego es muy parecido al del logro (ERC-721) [03:24]. Comparte varios elementos:
- Se importa la implementación de OpenZeppelin, que ofrece contratos auditados y confiables.
- Se utiliza control de acceso para restringir qué cuentas pueden emitir monedas.
- El token tiene un nombre y un símbolo, igual que un NFT.
La función de emisión se completa con mint, que es una función interna. Recibe dos parámetros: el destino (la dirección del jugador) y la cantidad de monedas a emitir [04:20].
¿Cómo se integra la emisión de monedas en la lógica del juego?
Para conectar el contrato de la moneda con el contrato principal del juego, se siguen tres pasos [04:50]:
- Agregar la referencia al archivo local del contrato de la moneda, utilizando siempre una ruta relativa (incluyendo subcarpetas si existen).
- Declarar una variable del tipo del contrato para almacenar la referencia al smart contract ya desplegado en la red.
- Inicializar la dirección del contrato en el constructor, de modo que la variable quede lista para usarse sin necesidad de instanciar el contrato cada vez.
¿Dónde se ejecuta la emisión dentro del flujo de la partida?
La emisión ocurre dentro de la función que guarda al ganador [05:38]. Cuando se determina que un usuario ganó, no se requiere ninguna verificación adicional: ganar ya es motivo suficiente para emitir la recompensa.
La llamada es directa:
solidity
moneda.emitir(direccionGanador, 1);
Se emite una sola moneda por partida ganada, tomando la dirección del ganador como destino.
El modelo play to earn cobra vida con esta mecánica: cada victoria suma una moneda a las arcas del jugador. Como desafío adicional, se propone que si el jugador ya posee un achievement previo, la cantidad emitida se duplique [06:22]. ¿Te animás a implementarlo? Compartí tu solución en los comentarios.
