Physical minigames
Physical minigames replace progress bars for hands-on job steps on Freedom Roleplay, a Dutch FiveM server on Qbox. You drill, cut, reel, tape and lift for real, and the server checks every gesture before it pays.
- 01Used by jobs, crime, police, the gym and repairs through one shared engine
- 02The hidden layout lives on the server and is revealed one step at a time
- 03Rewards only after the server confirms a solved result, consumed once
Every hands-on step on Freedom Roleplay is a small physical game: 46 of them on the live server, all in one engine, all checked by the server.
Why not a progress bar
Most FiveM jobs end the same way: hold E, watch a bar fill, get paid. It is cheap to build, and it is also the part a cheater skips first, because the client simply reports that it finished. Freedom Roleplay has one rule for every job, crime and craft step: the player performs the physical action, with the right tool, in the right order, and it can go wrong in a way that makes sense.
Picking a lock means setting pins under tension. Removing a car's GPS tracker means prying three clips off the dash panel, pushing the cable looms aside and cutting the red power lead; cut the wrong wire and it shorts out. Bagging a bullet casing means gripping it in the middle with tweezers and carrying it to the bag slowly enough that it does not slip. An ATM deposit means inserting the card, typing the PIN from the sticky note, feeding the notes and smoothing out the crumpled bill the machine spits back.
One engine, 46 games
All of them run in one shared engine inside the server's UI resource. The live server has 46 registered kinds, including a gunsmith workbench with nine kinds of steps (drill, file, fit, pins, torque, saw, wrap, press and a function test), fishing, refuse loading, parcel handling, engine repair, gym training, prison work, evidence bagging, a ballistics test-fire, the ATM deposit, the bank heist's magnetic drill, borescope, slide hammer and camera loop, the ATM blast's crowbar and gas fill, the XTC pill press, the wheel clamp, opening a locked car with an air wedge, and fitting tuning parts, paint and wraps in the workshop. Five cooking games for a fast-food side job are in development and not counted. A job never builds its own minigame screen. It calls the engine with a kind and options, and keeps ownership of its own world rules, items, animation and reward.
Each game aims for 10 to 40 seconds: shorter than the bar it replaced and still fun on the twentieth run. Long tasks are split into physical stages with movement in between. Mistakes have a visible consequence, like a casing that drops or a spark from the wrong wire, instead of a generic reset. Difficulty changes the number of pins, turns or zones, never a random fail after a good run.
What the server checks
This is the part that took the most work. The layout of every game is generated on the server and revealed one step at a time, so the client does not know where the tracker sits until the right cable loom has been pushed aside. Every step travels through the job's own server callback first, which checks distance, zone and inventory again, and then to the puzzle on the server, which replays the submitted drag samples against the hidden geometry and its own clock.
When the client says it is done, that only ends the animation. Rewards, stage changes and unlocks happen only after the server confirms a solved result, and that result is consumed once so it cannot be replayed. Lag, a slow hand or a cancelled attempt is logged and rejected without consequence. Only data no human can produce, such as a step that does not exist or input faster than possible, writes a security log entry before a ban.
Original art and sound
Every game is built from raster image layers made for it: the base, the removable parts, the tools and the before and after states, all with the same camera and light, mapped against a manifest of contact points and pivots so the clickable area matches what you see at every resolution. Text, counters and hints are real HTML on top, never baked into the image. Each game has its own sound effects, which fire on actual contact or on a result the server confirmed, never ahead of it. A few of the oldest games still use line art and are being moved to the same standard.
How a new game is tested
Each game runs in a browser harness that executes the real server Lua through a Lua runtime compiled for JavaScript, with simulated latency, at 720p, 1080p, 1440p and ultrawide. That catches the bugs a quick JavaScript copy hides, like a press that never releases under lag. Exit paths are checked as well: ESC, death, a lost contract or a resource restart must close the game, release focus, stop the sounds and clear the animation. The performance target for the engine is 0.00 ms idle and at most 0.10 ms while a game is open.
More views
Want this on your server?



