If you want this in plain PHP 8.4 with no framework, that is workable for an MVP, but you need stricter structure than typical “raw PHP” projects. The main risk is not writing the games, it is keeping wallet logic, fairness, and concurrency correct without Laravel-style guardrails. On shared hosting with Plesk, I would still keep the scope focused on Cases, Mines, and Plinko first, then add Case Battles once the core transaction engine is stable.
The right plan is to build a small, framework-free application with a clean internal architecture:
public/ for the web root and front controller
src/Core/ for router, request, response, database, session, csrf, validation
src/Modules/Auth/
src/Modules/Wallet/
src/Modules/Fairness/
src/Modules/Cases/
src/Modules/Mines/
src/Modules/Plinko/
src/Modules/Battles/
src/Modules/Admin/
src/Support/ for helpers, config loading, security utilities
storage/logs/ and storage/cache/
templates/ for PHP views
bootstrap/ for config and startup wiring
Even in core PHP, do not mix SQL, HTML, and game logic in one file. Use this pattern:
controller: receives request and returns response
service: contains business logic
repository: contains SQL
entity/dto: carries structured data
view: renders HTML only
For your stack, I would use:
PHP 8.4
PDO with prepared statements
MySQL or MariaDB
Composer only for small libraries if needed, even if the app is “core PHP”
Plesk cron for scheduled jobs
polling or short AJAX refresh for battles, not WebSockets on shared hosting
The build order should be this:
Core bootstrap
Auth and sessions
Wallet ledger
Provably fair engine
Cases
Mines
Plinko
Case Battles
Admin and balancing tools
Payments and withdrawals only after the above are proven stable
The most important decision is the wallet design. Do not store only users.balance and keep updating it directly as the source of truth. Instead:
keep an append-only wallet_transactions table
optionally cache current balance on users.balance
every bet, payout, refund, bonus, deposit, withdrawal becomes one or more ledger entries
all game resolution must happen inside SQL transactions
For example, a game round flow should always be:
validate request
start SQL transaction
verify current balance
insert debit transaction
generate result from provably fair inputs
insert payout transaction if needed
insert game history row
commit
That matters more than the choice of framework.
For the game systems, I would plan them like this.
Cases
This is the easiest first game and the best place to validate your fairness engine.
Needed tables:
cases
case_items
items
case_openings
Needed backend logic:
weighted reward selection
case versioning so old openings remain auditable
single open and multi-open
expected value calculator for admin
Rule:
backend resolves the result first
frontend only animates the already-final result
Mines
This is your first stateful game, so it tests race-condition handling.
Needed tables:
mine_games
mine_reveals
Needed logic:
board generated once at game start from seed
board state persisted or reproducible from stored seed+nonce
each click validated server-side
game locks after mine hit or cashout
cashout and click endpoints must reject duplicate/late requests
This is where plain PHP can go wrong if you do not enforce transaction boundaries and per-game status checks carefully.
Plinko
Do not do server-side physics. It is unnecessary and expensive.
Needed tables:
plinko_games
plinko_configs
Needed logic:
risk level + row count define payout table
result maps to a final slot deterministically
optional path array stored for animation replay
admin RTP simulator for balancing
Again:
backend chooses result
frontend draws animation that lands on that result
Case Battles
This is the hardest part, especially on shared hosting.
For v1, do not build “live multiplayer” in the true sense. Build a replay-driven system:
player creates battle
another player joins
server locks participants and cases
server resolves full battle safely
frontend reveals rounds with timed animation
clients poll battle state every 1-2 seconds
Needed tables:
battles
battle_players
battle_rounds
battle_round_results
This approach avoids needing WebSockets and queue workers at the start.
For core PHP 8.4, you also need a small internal framework of your own. Minimum components:
Router class with GET/POST route maps
Request object wrapping $_GET, $_POST, $_SERVER
Response helper for JSON, redirects, views
CSRF token utility
Auth/session manager
Database wrapper around PDO
Transaction helper
Validation helper
Error handler and logger
Config loader from .env or config PHP files
A minimal routing pattern is enough:
<?php$router->get('/cases', [CaseController::class, 'index']);$router->post('/api/cases/open', [CaseController::class, 'open']);$router->post('/api/mines/start', [MinesController::class, 'start']);$router->post('/api/mines/reveal', [MinesController::class, 'reveal']);$router->post('/api/mines/cashout', [MinesController::class, 'cashout']);
For security, plain PHP means you must be explicit about everything:
PDO prepared statements only
hashed passwords with password_hash()
password_verify()
CSRF tokens on every state-changing form
strict session settings
server-side validation only
output escaping in templates
rate limits on login, game start, withdrawal actions
idempotency tokens on sensitive actions
For shared hosting with Plesk, design around these constraints:
no long-running daemons
no guaranteed Redis
no WebSocket server
cron jobs instead of workers
avoid high-frequency background tasks
use AJAX polling for state refresh
That means your battle engine should be stateless enough that any request can reconstruct the current state from MySQL.
A practical 8-week MVP plan in core PHP would be:
Week 1: bootstrap, router, config, PDO layer, auth, templates
Week 2: wallet ledger, transaction engine, admin user tools
Week 3: provably fair engine and verification pages
Week 4: Cases game and case admin management
Week 5: Mines game with safe cashout/state handling
Week 6: Plinko with payout tables and replay animation
Week 7: Case Battles v1 with polling and replayed rounds
Week 8: audit logs, anti-abuse rules, balancing tools, deployment hardening
If this is real-money gambling, the technical build is only half the work. You would also need licensing, KYC/AML, payment provider support for gambling, audit logging, geo-restrictions, and provably fair verification pages. If this is social/demo only, you can defer that and focus on game correctness.
My recommendation in your exact constraints is:
core PHP 8.4
Composer allowed for a few utility packages, but no framework
MySQL via PDO
server-rendered PHP templates
JS only for game animation and polling
Cases, Mines, Plinko first
Case Battles only after the ledger and fairness engine are proven stable
If you want, I can make this but I will want to host it for this price.
This is my hosting company:
https://talkbuildhost.comthis is some of site powered by TalkBuildHost and made by me:
https://forums.talkbuildhost.comhttps://superhubber.com
