JBKR ARCADEGame development: from the web mini-game to the competitive platform

In 2026 JBKR Web built a competitive skill mini-game platform with cash prizes paid through PIX for a client under NDA: seven 2D web games in TypeScript, a web portal, an admin panel and a serverless back-end with NoSQL and relational databases (179 endpoints), anti-cheat, ranking, infrastructure as code, 253 test files and 67 recorded architecture decisions. The same method serves a casual game, a platform or the gamification of your product.

What we deliver in a game project

A game ready to operate, not just an executable. In the 2026 project that meant four applications: the game client on a 2D web engine with TypeScript, assembled in a visual scene editor, with seven reflex, memory, rhythm and reasoning mini-games, WebP texture atlases and per-game asset packs so a phone loads only what it is about to play; the player portal, installable as a PWA and in several languages; the admin panel; and the serverless Node back-end with a real-time NoSQL database and a relational database.

The art came from the client; JBKR designed and built everything that turns art into a game: mechanics, physics, audio, progression, economy, anti-cheat, payments, infrastructure and operations. Source code, architecture decisions and tests stay with the client, as in every JBKR project.

How a game project runs at JBKR

First the playable core loop, in two weeks, ugly and functional: that is where you find out whether the game is fun and what the rest will cost. Then the vertical slice, one complete slice with real art, sound, interface and back-end. Only then production in sprints, each with architecture decisions recorded in short documents (67 in the 2026 project), automated tests (154 files on the back-end and 99 on the front-end and the game) and continuous integration running against service emulators and a test relational database.

Launch is gradual: a staging environment identical to production, an assisted launch with telemetry and fixes on the same business day. Then comes live-ops, which is where a competitive game really lives: new mini-games, events, seasons, balancing and anti-cheat evolving with player behaviour.

Anti-cheat and fairness: the problem that decides whether the platform survives

In a game with prizes, the score that arrives from the browser is a claim, not a fact. JBKR treats every match as a transaction to be verified: the score is signed with HMAC and tied to the session; the server generates the seed and the layout of the match, so two players in the same room face exactly the same challenge; the clock is synchronised to detect impossible matches; a honeypot catches automation; a replay tool allows move-by-move auditing; and the production build is obfuscated.

Fairness goes beyond cheating. To prove the game is one of skill rather than luck, the platform has a statistical simulation engine with bots that measures the influence of luck in each mini-game, the basis of the client's legal report. When a three-player room does not fill, bots take the empty seats and the player is compared later with real opponents, so no match is lost for lack of people.

Economy, payments and compliance

Real money comes in and goes out through PIX, and that changes the engineering. Each player's balance lives in a dual-write ledger (NoSQL database for real time, relational database for reconciliation), with idempotent processing so a repeated message never credits twice, append-only audit tables and a circuit breaker on the payment gateway to fail safely when the bank does not respond.

Around the money, the account protections: managed authentication with custom tokens, MFA and roles for administrators, anti-bot verification and app attestation against automation, identity verification before withdrawals and two currencies (one with real value, one promotional) with separate rules. The security and privacy page describes how JBKR handles access and data as a processor under the LGPD.

Scale and infrastructure

The infrastructure is code: modules for network, edge protection (WAF), permissions, secrets, anti-bot verification, database and runtime, with separate production and staging environments. Managed queues absorb spikes in sign-ups and match settlements; a data warehouse receives the events for analysis; the continuous-integration pipelines run lint and tests for the four applications in parallel before any deployment.

The result is a small team operating a system with 179 back-end endpoints without improvisation. The cloud and infrastructure page describes the platforms; the point here is that a competitive game is, first of all, a financial system with a fun layer on top.

Multiplayer, ranking and retention

Matches happen in three-player rooms with real-time database updates; the server compares the results and pays the winner, minus the platform fee. Training, daily challenge, one-on-one duel, challenge-a-friend, tournaments and a gauntlet mode share the same base.

Retention comes from a complete progression system: skill scores per player, tiered MMR ranking, experience, missions, streaks, shields and boosts, leaderboards, an avatar builder with frames and a store. All of it is reusable back-end: the same progression engine can gamify a product that already exists.

Audio, AI and generated content

The rhythm game needs a note map for every song; instead of marking it by hand, JBKR generates the map automatically from the audio with signal analysis, and the designer only fine-tunes. Layouts and seeds for every match are generated on the server, which guarantees identical matches within a room and prevents the client from predicting the challenge.

Generative AI went into two places with a clear return: a paid "coach" that analyses the player's matches and suggests what to train, and a read-only query assistant for the admin team. JBKR's responsible-AI principles apply here as in any project: declared use, anonymised data and human review.

Real proof, not promises

7 mini-games in production

Seven 2D web games in TypeScript on a competitive platform with cash prizes, in assisted operation since 2026.

179 back-end endpoints

Serverless Node functions with a real-time NoSQL database and a relational database, a dual-write ledger and versioned migrations.

253 test files

154 on the back-end (integration against emulators, coverage enforced in CI) and 99 on the front-end and the game.

67 recorded architecture decisions

Every relevant choice (anti-cheat, ledger, rooms, bots, AI) documented in short records that stay with the client.

Updated on November 5, 2026