Hypermaze: Cheryl Engine 4 Port
The Cheryl Engine 4 version follows graph connections through sight rays, resolves overlapping terrain placements, and retains explored tiles as the player moves.
- Version
- Cheryl Engine 4 port
- Status
- Completed
- Built with
- C++, Cheryl Engine 4
- My work
- World-model, visibility and runtime integration
Project overview
Hypermaze’s rooms are connected by a graph, but the player sees a tile map. This Cheryl Engine 4 port keeps that distinction and adds another question: what should be visible through a doorway when two graph paths can occupy the same screen coordinates?
A conventional lookup from tile position to terrain is insufficient here. Looking through one door must follow that door’s connection, even if a different room was previously drawn at the same position. Movement, sight, and remembered exploration need related rules without becoming the same piece of state.
Knowing which space a coordinate belongs to
The world stores nodes and links in owned containers. Rooms and corridors are generated when needed, and their dimensions and door positions come from the graph. A location includes the active room or corridor and its placed origin, alongside the player’s signed tile coordinates. Moving left or down can therefore continue into negative coordinates.
Doorway traversal calculates the destination’s origin from the entrance being used. Visibility reuses that boundary-crossing logic. Each sight ray carries its own room-or-corridor placement as it advances, so it follows the relevant graph path and retains that connection’s terrain when placements overlap.
Revealing neighbors without revealing everything
The display deliberately shows the current room and immediately connected rooms and corridors. More distant terrain is revealed by rays from the player. Automatically revealing a neighboring room does not turn that room into another source of sight: a branch around its corner stays hidden until the player can see into it.
The ray traversal checks every tile it enters, including shallow angles. At diagonal corners it considers both neighboring cells, so two touching walls block sight between them. Walls at the end of a ray remain visible; terrain beyond them does not. Where placements overlap, the player’s actual sight takes precedence over the automatically revealed neighbors.
Keeping a record of exploration
Current visibility is recalculated after movement, regeneration, or a viewport change. Seen terrain is also written into an exploration map. Moving away can remove a room from current sight while leaving its tiles on the remembered map. Shrinking the viewport does not erase that history, and remembered tiles do not reveal an unseen branch.
Exploration is stored as a tile-based memory. When a newly visible path conflicts with remembered terrain at the same coordinate, the current view updates those tiles. That precedence rule lets the current graph placement update the remembered map.
A repeatable world and a separate presentation
A supplied seed selects the generated maze. Growth has node and link limits, and model tests exercise connectivity, doorway round trips, negative coordinates, corners, loops, overlapping placements, and remembered terrain. Those checks target world behavior separately from Cheryl’s rendering and input integration.
Use WASD, the arrow keys, or a gamepad D-pad to move. R generates another maze and clears exploration; F3 toggles the debug display. The port is complete. It retains Dungeon Tileset artwork; the historical prototype’s animation is not a demonstration of this version.
