ENGINEERING A PERSISTENT WORLD ON SHARED HOSTING: THE SPIRIT FORGE BACKEND

When designing a browser-based progression engine, the standard modern approach is to spin up a Node.js environment, open a WebSocket connection, and let Redis handle the state. But what happens when your deployment environment is a strictly locked-down shared server with zero background process allowances and no WebSocket support?

You build a state engine out of PHP, SQLite, and time.

Spirit Forge is an interactive discipleship platform where users read the Bible, build up spiritual stats, form congregations, and tackle global community goals. It achieves the feel of a persistent, living world through clever backend architecture rather than brute-force server power.

You can join the journey and read the Word with us right here: https://oxaus.com/spiritforge

Here is a technical breakdown of how the core loops are engineered to run seamlessly on a restricted environment.

THE LAZY-EVALUATION TICK SYSTEM

Most browser experiences with regenerating resources (like Energy or Stamina) rely on CRON jobs ticking every minute to update the database. On shared hosting, CRON execution limits are strict.

To bypass this, Spirit Forge uses a Lazy Evaluation model. The database never updates resources on its own. Instead, it stores a UNIX timestamp of the last time the user's state was requested. When the user interacts with the API, the backend calculates the elapsed seconds, determines how much Energy should have regenerated, updates the database in a single transaction, and returns the new state.

Formula: New Energy = Min(Current Energy + Floor(Elapsed Seconds / 120), Max Energy)

This creates the illusion of real-time regeneration without a single background process running on the server.

COORDINATE-BASED NARRATIVE TRAVERSAL

The journey aspect of the platform is handled by a 2D grid system. User state stores X and Y integers representing their current location.

When a user moves North, the backend decrements the Y axis and queries a flat JSON file to load the new environment. Crucially, the quest engine relies on a hierarchical dependency tree.

A tile may have four sequential goals. The backend checks the quest_progress table to see if the previous goal (requires: q_valley_1) has its claimed flag set to 1. If not, the subsequent goals are invisible to the user. This allows for deep, multi-stage narrative chains without hardcoding the logic into the application layer.

ASYNCHRONOUS MULTIPLAYER SYNCHRONIZATION

Without WebSockets, real-time multiplayer interactions like global chat, congregational projects, and world boss encounters must be handled via short polling.

To prevent the server from melting under constant database reads, the client uses interval-based polling (every 3 to 10 seconds) only for active UI components. If the user is not viewing the chat tab, the polling stops.

For the global boss encounters, preventing race conditions is critical. If fifty users attack a boss at the exact same millisecond, the HP deduction must not be lost. Because we are using SQLite, we rely on WAL (Write-Ahead Logging) mode. This allows concurrent readers and serializes the writers safely. When a user attacks, the backend executes an atomic decrement operation directly in the SQL query (UPDATE world_boss SET hp = hp - damage), ensuring no overlap occurs.

THE ECONOMY SINK AND TREASURY POOLING

In any progression system, currency inflation is the ultimate enemy. Spirit Forge utilizes an internal currency called Grace Points.

To prevent hyperinflation, the system relies on heavy state sinks. Upgrading core stats (Faith, Wisdom, Endurance, Zeal) costs Grace. The end-game equipment (The Armor of God) costs 20,000 Grace per piece.

But the most interesting mechanic is the Congregation Treasury. Users can pool their Grace into a shared guild account to fund massive community projects (like building an orphanage). This acts as a massive, permanent currency sink that removes Grace from the individual economy while providing a shared, cooperative reward (like permanent Max Energy increases for the whole group).

By treating the limitations of a flat-file, shared-hosting environment as an architectural puzzle rather than a roadblock, we engineered a deep, stat-driven world. It proves that you don't need a massive infrastructure to build a living, breathing community. You just need smart data modeling.

Come see how the systems tie together. Read a chapter, add it to your Codex, and see how long your spiritual stats can carry you.

Play the game here: https://oxaus.com/spiritforge