Sobre el proyecto

World Engine se describe como un motor de juego onchain y un SDK de Gamechain construido sobre la arquitectura de rollup fragmentado de Argus Labs. El README indica que el proyecto está en desarrollo y se está reescribiendo desde cero, por lo que el repositorio actual es principalmente un andamiaje de desarrollo más que un motor terminado. La configuración de desarrollo se centra en proto y moon. Tras instalar proto, ejecutar `proto install` desde la raíz del repositorio instala las versiones de Go y moon fijadas en `.prototools`; los shims de proto deben permanecer en PATH para que `go` y `moon` resuelvan a esas versiones. Las tareas comunes se exponen a través de moon: - `moon tasks` lista las tareas del proyecto. - `moon run world-engine:build` compila los paquetes de Go. - `moon run world-engine:lint` ejecuta el linter e instala el linter fijado. - `moon run world-engine:lint-fix` aplica correcciones de lint. - `moon run world-engine:test` ejecuta todas las pruebas de Go. - `moon run world-engine:test-ci` escribe coverage.out y junit.xml. - `TEST_SEED=123 moon run world-engine:test` reproduce una semilla de prueba. golangci-lint se instala en el directorio ignorado `bin/tools`, y gotestsum se ejecuta mediante `go tool`. Las pruebas que fallan registran una semilla para su reproducción. El almacenamiento en caché de tareas de Moon está deshabilitado para que las pruebas aleatorizadas se ejecuten cada vez, mientras que las cachés de compilación y pruebas propias de Go permanecen habilitadas. Los clientes generados son proyectos separados. `moon run proto-csharp:build` o `proto-csharp:pack` compila o empaqueta el cliente de C# y requiere el SDK de .NET; las variantes de depuración usan `build-debug` y `pack-debug`. `moon run proto-ts:build` verifica tipos del cliente de TypeScript y requiere Node/npm además de un `npm install` previo en `proto/gen/ts`. Moon reemplaza a los Taskfiles anteriores. Los nombres de tareas usan guiones, por lo que `test:ci` pasa a ser `world-engine:test-ci`. La tarea `rebuild` de C# limpia antes de compilar, y `update` informa dependencias desactualizadas sin cambiarlas. Los fallos de formato y análisis se propagan al llamador. CI ejecuta las mismas tareas de Go que el desarrollo local. El flujo de trabajo de Box2D mantiene su propia matriz de arquitecturas y objetivos explícitos `determinism-*`. Los flujos de trabajo seleccionan objetivos explícitos en lugar de `moon ci`, manteniendo las costosas comprobaciones de determinismo en una matriz dedicada. Los clientes generados pueden seleccionarse explícitamente en runners con sus SDK instalados, y la limpieza y el formato nunca se ejecutan automáticamente.