A persistent multiplayer world
Virtual hardware, player progression, missions, clans, simulated hacking, and an in-game economy share durable player and world state.
HackerForever.
Maintaining and extending an existing browser-based multiplayer hacking RPG, with a focus on persistent game state, data integrity, feature-controlled releases, and dependable background processing.
PHPMySQL / MariaDBApacheLinuxJavaScriptGitCloudflare
ACTUAL GAME INTERFACE / STOCK MARKETActual game interface: the stock market. Values shown are fictional in-game currency.
01 / CONTEXT & CONTRIBUTION
Build on what is already there.
HackerForever is a browser-based multiplayer hacking RPG with persistent player data and a shared fictional world. My work centers on maintaining and extending the existing PHP application, connecting gameplay changes with the database and scheduled processes behind them.
FOCUSMaintaining and extending an existing PHP game
Backend gameplay · data integrity · controlled releases · application operations
The engineering challenge is keeping those pieces coherent as the application evolves. A new game mechanic can affect a page, a request handler, a background task, and the data each of them depends on.
Stateful gameplay systems
Botnet gameplay includes onboarding, contracts, node reservations, defensive counterplay, cooldowns, and recovery of stranded operations. All activity is a game simulation.
Economy and market lifecycles
Economy policy, sources-and-sinks tracking, stock-market phases, company liquidity, and scheduled settlement connect game rules with persistent balances.
Staff operations
Feature rollouts, audit records, player snapshots and restore tools give administrative changes a defined workflow.
Responsive interfaces
A modular page/layout structure and dedicated CSS support the dashboard, jobs, market, communications, and other game screens.
The codebase contains feature-controlled functionality; availability can differ between player cohorts.
02 / APPLICATION ARCHITECTURE
Requests, state, and scheduled work.
SERVER-RENDERED PHP / PERSISTENT GAME STATE
Browser · HTML / CSS / JavaScript
PHP entry point · session checks · page routing
Gameplay modules · staff controls · MySQL / MariaDB
PARALLEL PROCESSING PATHScheduled PHP jobs → game modules → stored world stateMissions · simulated infections · botnet operations · market updates · settlement
The main entry point composes routing, authentication checks, request restrictions, and layout includes. Game modules hold domain behavior, while AJAX handlers support individual interactions. Scheduled PHP jobs advance time-dependent systems independently of a player’s page view.
Database migrations and rollout guides accompany changes that introduce new persistent state.
03 / IMPLEMENTATION DECISIONS
Where the complexity lives.
01 / ENGINEERING EXAMPLE
Release across every entry point
A hidden menu item does not disable a feature. Direct requests and scheduled jobs can still reach its behavior.
Feature checks are applied to navigation, page handlers, POST actions, and background work. Staff and tester cohorts, deterministic percentage rollout, and full/off modes provide controlled access. Request-method, CSRF, ownership, and role checks remain separate.
The same principle applies to releasing new functionality in an existing business application.
02 / ENGINEERING EXAMPLE
Keep a shared world consistent
Player requests and scheduled work can touch the same balances, reservations, and game state.
The botnet and market modules use database transactions and row locks around state changes. Live roulette settlement locks pending wagers, commits related ledger updates together, and treats an already-settled round as complete.
Transactions and explicit completion states make retries and concurrent work easier to reason about.
03 / ENGINEERING EXAMPLE
Recover work that does not finish
A queued or staging operation can be interrupted, leaving reservations or scheduled work behind.
Recovery logic distinguishes recent, overdue, missing-dependency, and terminal operations. Scheduled processing can resume eligible work or cancel stale operations rather than treating every incomplete record the same way.
Background processing needs a recovery path as well as a happy path.
04 / ENGINEERING EXAMPLE
Evolve the schema deliberately
New features introduce tables and state that existing deployment and rollback procedures must account for.
Dated migrations accompany gameplay and operations changes. Economy and stock-market rollout guides specify backup, migration, deployment, scheduled initialization, and verification order, with rollback guidance.
A maintainable feature includes the steps needed to put it into service.
04 / VERIFICATION
Check behavior at its boundaries.
Three database-free PHP test scripts passed during the portfolio review. They cover game-state helpers, protective entry-point assertions, and a focused regression scenario.
Botnet state checks
Game-state transitions, operation recovery decisions, cooldowns, rollout boundaries, and migration invariants.
Botnet entry-point checks
Source assertions covering feature gates, POST-only handlers, CSRF protection, onboarding, scheduled actions, and ownership checks.
Gateway fee regression checks
Rounding, repeated deductions, insufficient balances, and error handling when a transfer fails.
The gateway regression checks verify that repeated offline fees exhaust a balance without leaving an immortal remainder, and that a failed transfer does not incorrectly delete a clan.
A separate boundary for database tests
The integration suite requires an explicitly enabled, dedicated fixture database. Its scenarios include migrations, rollout modes, reservations, recovery, and a two-connection race. Those database-backed scenarios were not executed as part of this portfolio review.
05 / INSIDE THE INTERFACE
The application in use.
Game screenshots from HackerForever’s own project assets, also used on its public site. Open an image to inspect the full view.
06 / ENGINEERING TAKEAWAYS
Useful software keeps evolving.
Understand the existing contracts
Changes have to fit the page handlers, scheduled jobs, stored state, and operating assumptions already in the application.
Make transitions explicit
State machines, terminal states, and transaction boundaries make long-running gameplay easier to inspect and recover.
Treat operations as part of engineering
Feature controls, audit records, migrations, and verification steps are part of the implementation, rather than tasks left until release.
This is the kind of work I enjoy: understand an existing system, make a focused change, and check the behavior that change depends on.
Discuss an Engineering Opportunity↗ / KEEP EXPLORING
Related work.
LET’S BUILD SOMETHING USEFUL
Have a problem
worth solving?
Whether you're hiring an engineer or exploring a custom software solution, I'd love to hear what you're working on.