Patrón de diseño para el desarrollo de juegos.

Estoy desarrollando un juego que actualmente usa un contrato de GameFactory para crear instancias de un contrato de Juego. El patrón Factory permitiría a cualquier número de jugadores jugar su propio juego de un solo jugador y los datos del juego almacenados en instancias de juego separadas.

Sin embargo, idealmente necesito que los contratos del juego interactúen con los contratos de GameFactory para actualizar las puntuaciones y estadísticas globales sobre todos los juegos que se están jugando actualmente.

¿Cuál sería una buena manera de lograr esto? ¿Hay algún ejemplo existente de patrones para juegos descentralizados como este?

¿Ha considerado almacenar todos sus datos en un contrato inteligente? Los patrones orientados a objetos a menudo no se traducen bien en contratos de Solidity. Por lo general, no debe pensar en los contratos como pensaría, por ejemplo, en las clases de Java.
Tengo alrededor de 20 variables, incluidas matrices y asignaciones, de las que necesito hacer un seguimiento para cada 'instancia' del juego. En su lugar, ¿debería crear una gran estructura de todas esas variables y crear una asignación a la dirección del jugador y la estructura de datos del juego? ¿Luego acceder a ese mapeo cada vez que necesito llamar a una función para actualizar?
Para contradecir a @JesseBusman, desde el punto de vista de un auditor de seguridad, tiendo a preferir las fábricas y las instancias de contrato único. En mi experiencia, ese modelo es más fácil de acertar que uno en el que cada llamada de función toma una identificación y tiene que hacer una verificación de permisos más compleja.
En cuanto a la pregunta original, no entiendo el problema. Simplemente haga que el Juego llame a GameFactory. GameFactory debe mantener un mapeo de juegos para que sepa que los datos que recibe son válidos (provienen de un contrato que implementó).

Respuestas (1)

Un arreglo hub and Spoke tiene ventajas, al igual que un contrato monolítico.

Hub y habló

  • Estructura interna más simple, posiblemente más legible
  • Puede acomodar una ruta de "actualización gradual" si eso es deseable.

Monolítico

  • Cuesta considerablemente menos inicializar algunas variables que implementar un nuevo contrato para cada juego.

Trabajar sobre la base de Hub and Spoke lleva naturalmente a algunas preocupaciones genéricas. Como mencionó, probablemente los Spokes necesiten actualizar los globales en el Hub, el Hub necesita limitar el acceso a ciertas funciones para que solo un Spoke esté autorizado para hacerlo, etc.

Mis exploraciones me llevaron a crear contratos generalizados, más o menos:

contract Hub is Deployer { ...

contract Spoke is Deployed { ...

Considere que Deployer realiza un seguimiento de Spokes desplegados y hace cosas como:

modifier onlyDeployed { // only trust contracts made by this Hub

... y Deployed hace cosas como recordar el Hub que lo generó.

Si desea poder actualizar la lógica del juego, puede considerar una mayor separación de los datos del concentrador y la lógica de fábrica. Es decir, desea poder mantener los datos globales en un contrato que no se espera que cambie, mientras reemplaza periódicamente el contrato que implementa nuevos juegos.

El costo de gasolina más bajo y el enfoque más simple es un contrato monolítico con datos del juego agrupados en estructuras y sin posibilidad de actualización.

Espero eso ayude.

Patrón de diseño para el desarrollo de juegos.
RespuestasAquíPolítica de privacidad1y, 0v