Dave-he/cocos4-rust

Cocos4-Rust is an ambitious Rust port of the Cocos4 engine, and the repository already has a surprisingly broad module map: math primitives, scene graph, renderer layers, 2D/3D components, audio, input, storage, terrain, tiled maps, Spine/DragonBones, and bootstrap/runtime compatibility pieces are all represented under src/. The strongest part is the organization around engine subsystems, especially the renderer split into gfx-base, gfx-empty, gfx-validator, gfx-agent, gfx-wgpu, frame graph, and pipeline modules. The README also does a good job making the scope immediately legible, and the CI workflow is more serious than many early engine projects: fmt, clippy, all-features build/tests, doctests, coverage, benchmarks, and audit are all wired up.

The biggest adoption issue is that the repository currently overstates its readiness. The README says the Cocos4 conversion is “fully completed” with 1,700 passing tests, but a new maintainer or user has no release notes, no examples, no screenshots, no demo project, and no documented API path for building even a minimal scene. Some modules also read more like compatibility scaffolding than production backends; for example gfx-wgpu is named as a WebGPU backend, but Cargo.toml does not depend on wgpu, and the device implementation delegates to internal gfx_base resource objects rather than actual GPU resources. That may be fine for a staged port, but the documentation should distinguish implemented runtime behavior from structural API coverage.

A few polish items would make the project much easier to trust: add the missing MIT LICENSE file, update the repository field in Cargo.toml to the actual GitHub URL, remove committed .bak files, fix the mojibake in ENGINE_APP_BOUNDARY.md, and add a small “hello scene” or renderer smoke-test example. A short architecture page explaining what is genuinely executable today versus stubbed for future parity would help a lot. The foundation is interesting and unusually broad, but the next leap is proving the engine can run real content, not just compile many subsystem-shaped modules.