- Project number
- Project / 016
- Year
- 2026
- Category
- Product
- Status
- Active · Live
Balang
A Malaysian probability party game. Everyone can see what is in the jar; nobody knows the order it comes out in. Read the odds, bet on secret predictions, and play friends in rooms that need no server.
- Origin
- Social experience → Game
- Inspired by
- Bag of Chips (board game)
- Type
- Multiplayer party game · web / PWA
- Tagline
- Agak. Risiko. Menang.
- Stack
- React 19 · TypeScript · Vite · PeerJS (WebRTC) · Vitest
- Live
- balang.madebyrazeen.com
01 /Overview
The balang is the game.
A simple social game enjoyed with friends became the starting point for designing a Malaysian digital probability and prediction game.
Balang is built around one shared jar of familiar Malaysian kuih. Players know exactly what goes in. As tokens are drawn, they keep reassessing the odds, drop predictions that are becoming unlikely, lock their final choices, and decide whether to risk KAW-KAW.
The goal was a game that is easy to understand in the first round, strategic without needing advanced maths, and fast enough that people want another match straight away.
02 /The rules
One round, six steps.
- Read the jar
- Get 6 cards
- Shake and draw
- Discard
- Place 3: one negative (KAW-KAW?)
- Score
01Read the jar
25 tokens of five kuih, chosen at random from a pool of ten each round. The counts are public; the order is secret.
02Predict
Each player gets six secret prediction cards, such as “more onde-onde than dodol” or “muruku exactly 3”. Harder predictions are worth more.
03Draw
Players take turns to shake the jar. 14 tokens come out and 11 stay in.
04Discard and lock
After draw 5 you drop two cards and after draw 9 one more. After draw 12 all three remaining cards count: you place one on the negative side, where it costs you its value if it comes true.
05KAW-KAW
You may go KAW-KAW on one positive card: double its value if it comes true, lose its value if it does not.
06Win
Positive cards that come true score their value; a negative card that comes true loses it. Three rounds; the highest total is JUARA.
03 /Gameplay
A real round, start to finish.
Captured from a real game on a local build, played against the built-in computer players.
01Observe: everyone sees what is in the jar; each player gets six secret prediction cards.
Real product
02The table: players take turns to draw, and the jar count updates after every token.
Real product
03Reassess and discard: predictions that are becoming unlikely are dropped.
Real product
04KAW-KAW: double one positive card's value, at the risk of losing it, or play safe.
Real product
05Result: each placed prediction is checked against the fourteen tokens drawn.
Real product
After twelve draws: one of the last three cards goes on the negative side.
Real product
The same table on a phone.
Real product04 /System architecture
No backend, on purpose.
Step 1: SOURCE
Host creates room
Buat Bilik: the host browser becomes the game authority.
Step 2: PROCESS
Game engine
Pure TypeScript state machine: draw order, hands, scoring, bots.
Step 3: PROCESS
Pricing
Card rewards priced from probability at deal time (Monte Carlo).
Step 4: PROCESS
WebRTC
Guests join by code, link or QR over PeerJS.
Step 5: OUTPUT
Filtered views
Each guest sees only their own cards and the public jar.
05 /Build
Built to be fair and to survive dropouts.
01Engine separate from UI
src/engine holds the game logic, prediction types, probability pricing, bots and statistics; the React UI only renders state.
0212 prediction types
Each card type has its own evaluation and an “already decided” check, so cards can be stamped DAH PASTI or DAH GAGAL as soon as the outcome is certain.
03Probability-priced rewards
Rewards come from the card’s chance of success at deal time, estimated with Monte Carlo simulation, and all balancing values live in one config file.
04Bots
Bots play empty seats, and take over a guest’s turns if they disconnect until they rejoin from the same browser.
05Turn timer
If the host sets a time limit and it runs out, a token is drawn or a card chosen automatically.
06Assets pipeline
Sprites are sliced from the concept sheets by a Python script, so the art can be regenerated.
06 /Balance
Letting bots test the maths.
A reward table that looks fair on paper can still be broken in play. Because the engine runs without the UI, bots can play whole matches on their own and report how the rewards behave. The first report showed the game was too forgiving: about three in four locked cards came true, so the final choice carried little risk. That led to the final rules, borrowed from the board game Bag of Chips: every final card counts and one must go on the negative side. In the same bot matches, that negative card now costs its owner points in about a third of rounds.
07 /What I learned
Small game, same lessons.
01Put the rules in one place
A pure engine with tests made every UI change safe and makes balance testing possible.
02Trust boundaries matter even in games
Keeping secrets on the host and sending filtered views stopped the easiest way to cheat.
03Numbers should feel honest
Each card is priced from its real chance of coming true, so a risky prediction pays more because it is genuinely less likely.
08 /Next project
LeadSightzCursor × Anthropic Hackathon 2025: sales automation with Claude for intelligent lead management and insights.