Un juego web3 no es «un juego con NFTs»: es un juego normal cuya economía —ítems, moneda interna, propiedad de activos— vive parcialmente en una blockchain. La decisión que separa los proyectos que funcionan de los que se abandonan es exactamente esa: qué va on-chain y qué no. Esta guía explica la arquitectura habitual, dónde se va el presupuesto y qué preguntar antes de contratar.
Qué va on-chain y qué no
On-chain van los activos que el jugador debe poseer de verdad: skins, personajes, terrenos o coleccionables como NFT, y la moneda del juego como token fungible. Todo lo demás —físicas, partidas, matchmaking, ranking, lógica de combate— se queda en el servidor de juego de toda la vida. Meter la lógica de juego en la cadena es el error más caro y frecuente: la blockchain es lenta y cara para eso, y no aporta nada al jugador. Los conceptos base están en nuestra ficha de gaming blockchain.
Arquitectura habitual en cuatro capas
1. Motor y servidor de juego (Unity, Unreal, Godot o motor propio): el juego en sí. 2. Capa blockchain: los smart contracts de los activos (ERC-721/1155 para ítems, ERC-20 para la moneda), el marketplace y el puente de entrada y salida de activos. 3. Capa de cuenta: cómo el jugador tiene una wallet sin saber que la tiene — hoy lo normal es account abstraction o wallets embebidas, con inicio de sesión social y gas pagado por el juego, porque pedir a un jugador que instale MetaMask mata la conversión. 4. Backend indexador: lee la cadena y sirve al juego el estado de los activos en milisegundos, que es lo que la cadena por sí sola no puede.
Elegir la cadena
La cadena se elige por coste por transacción, latencia y ecosistema, no por moda. Para juegos con miles de operaciones diarias, las capas 2 de Ethereum y las cadenas especializadas en gaming (con gas patrocinado y transacciones baratas) son la opción por defecto; Ethereum mainnet solo tiene sentido para el activo de máximo valor. Cambiar de cadena a mitad de proyecto es posible, pero migrar activos ya vendidos a jugadores es delicado: mejor decidirlo con la economía del juego encima de la mesa.
Dónde se va el presupuesto
La capa blockchain suele ser la parte más barata de un juego web3 y la que más miedo da. Los contratos de ítems y moneda son estándar y están bien documentados: el coste real está en la auditoría (imprescindible si los activos tienen valor económico), en la capa de cuenta y en el indexador. El motor y el arte del juego siguen siendo, como en cualquier juego, el grueso del gasto. Tenemos las cifras de referencia de la parte de contratos en cuánto cuesta desarrollar un smart contract.
Los errores que vemos repetirse
Diseñar la economía del token antes que el juego (y acabar con un juego que nadie quiere jugar sin recompensa). Sacar el token a mercado antes de tener jugadores. Meter lógica de juego en la cadena. Exigir wallet externa en el onboarding. Y no auditar «porque es un juego»: si un ítem vale dinero, su contrato es un objetivo.
Qué preguntar a una empresa de desarrollo
Qué han construido antes con activos en producción, cómo resuelven la cuenta del jugador, qué cadena proponen y por qué, quién audita, y qué pasa con los activos si el estudio cierra. Hemos reunido a los estudios de referencia en la guía de empresas de desarrollo de juegos blockchain. Nosotros construimos la capa blockchain, la capa de cuenta y el indexador y nos integramos con el motor que ya tenga el estudio: es el terreno de nuestro desarrollo web3 y de las aplicaciones descentralizadas. ¿Tienes un juego y quieres saber qué debería ir on-chain? Hablemos.