Accounts and authentication
Registration stored the player's email address and unique in-game identifier. Players could register only with a one-time token generated from inside the game. Submitted values were validated and written to the same MySQL database used by the server.
Authentication used PHP sessions and password hashing with password_verify. Idle sessions expired after 30 minutes. I also invalidated a session if the account's observed IP address changed.
Operational views
The dashboard reported online players, faction membership, registered and banned accounts, VIP players and online staff through optimized database queries.
The staff, factions and banned-player pages used server-side PHP loops to render database records. Faction requests were submitted through a form and could be accepted by administrators, faction leaders or co-leaders.
Live player matching
The most involved page was the online-player view. The database did not contain a reliable live-presence field, so the panel queried the game server's HTTP information endpoint, collected each active player's game licence, matched it against the database and combined both sources into one view.
Search and moderation
The player search updated results as the user typed and used a constrained database query with validated input. Logged-in players could file reports and unban requests. Staff received a separate moderation interface where they could accept, reject or delete submissions.
Caching
Some views required expensive aggregation over a large existing database. I added an hourly database-backed cache for those results. When a cached page was requested after expiry, the application recomputed the data and refreshed the stored result; otherwise it served the cached value immediately.