Cheryl Engine 4

An engine becomes a different kind of project when another application has to use it. The game needs a clear way to start, create resources, receive input, advance its world and submit a frame. The engine has to provide those facilities without making the game depend on every implementation detail behind them.

Cheryl Engine 4 is the ongoing development of that boundary. The work covers the runtime, resource lifetime, rendering interfaces and the build and documentation facilities needed to use the engine from a separate project.

Who owns the running application?

The runtime context owns the adapters for display, presentation, rendering and resources. The game works through that context and its lifecycle hooks. Startup, platform initialization, simulation and frame preparation therefore have explicit places in the application.

The runtime supports sequential and concurrent execution modes. Choosing a mode selects the corresponding execution loop; it does not change the game into a collection of unrelated threads. The ownership problem remains the same in either case: application state, resources and frame data need defined lifetimes as work moves through the runtime.

Resource management makes that problem particularly concrete. Retained byte-release bookkeeping is separated from the memory-manager facade, so returning a retained allocation has a contract of its own. The release context validates returns and detects an invalid final release. Those checks concern the lifetime of retained data, rather than treating the manager object as the lifetime of everything it has handed out.

Choosing the facilities a game needs

The project layout separates the neutral Engine target from optional native, graphics, UI and audio facilities. A consumer selects the integrations it needs instead of acquiring them implicitly through one large application target.

The same concern appears in the SDK work. Installation support and a first-game example give an external application a route through package discovery, linking and startup. Documentation generation and support tools are part of that route too: an interface needs to be understandable from outside the engine repository.

Text layout is another substantial system in this development. HarfBuzz handles shaping and ICU supplies bidirectional ordering. The layout retains source ranges for glyphs and can break an oversized word at grapheme boundaries. That preserves information needed by later text operations instead of reducing a paragraph immediately to an untraceable list of glyph positions.

Using and checking the boundaries

The college ports provide separate consumers with different requirements: Space Invaders, Hypermaze, Rover, and Word Search. Their project pages describe their own game and algorithm work; here they provide context for the engine interfaces those applications use.

At the October 2026 revision 966b594, 465 headless checks passed and two real-font checks were skipped for missing prerequisites. Separate Python support suites passed 80 checks. These results apply to that revision; native graphics, hardware input, audio, and interactive play need separate checks.

Cheryl remains in development. Runtime contracts and consumer integration are useful implemented work already, while backend behavior and broader application use continue to determine which boundaries need further revision.