0xFA99/IvyRPG

IvyRPG has the feel of a small but serious C/Raylib engine project hiding behind a deliberately casual README. The structure is stronger than the docs let on: src and include/ivy are split into understandable engine areas like arena allocation, audio, core game loop, graphics, scene management, inventory, item/profile/locale managers, and player entities. The CMake setup is also more mature than I expected for a 2-star project, with C11, Debug/Release handling, platform-specific Raylib linking for Linux/Windows, warning flags, sanitizer support on Linux debug builds, and an optimized unity/LTO-style release path. That suggests the maintainer is thinking about build performance and low-level correctness, not just getting pixels on screen.

The project would be easier to trust and adopt if the public-facing pieces were tightened up. The README is useful enough to build and run, but its self-deprecating tone and “auto-generated” disclaimer undersell the work and leave out screenshots, current gameplay status, asset format details, and a short architecture explanation. Since the repo includes large binary assets and bundled Raylib/static dependencies, it would help to explain why those are committed, what platforms are actually tested, and whether contributors should use the bundled libraries or install their own.

The biggest technical gap is verification. I did not see GitHub Actions workflows, a test directory, or obvious automated regression coverage. For a C game engine with custom inventory indexing, collision, asset loading, audio buffers, and arena memory behavior, even a small set of headless unit tests or smoke builds would pay off quickly. The currently open PR about unload/memory leaks is a good example: memory lifetime is clearly becoming important, so adding CI builds plus an AddressSanitizer run for core modules would make future changes much safer.

Overall, IvyRPG is an active, compact engine with real low-level work behind it: C/Raylib, custom allocation, scene systems, tilemaps, audio, inventory, and profile/localization pieces are all present. The next jump in quality is less about adding features and more about making the project legible to outsiders: clearer README, screenshots, contribution notes, CI, and a few tests around the systems most likely to break.