Case study / Solo product engineer
Wahala.
Reimagining Nigerian Whot as a live multiplayer strategy game with character classes and active abilities.
Playable beta · Two-player walkthrough verified
My contribution
Solo product engineer — game and interface design, architecture, frontend, backend logic, deployment, and real-time gameplay.
Built with
- React/Next.js
- Node.js/Express
- WebSockets
Outcome
Playable beta. Two separate accounts joined a private room, selected classes, entered a live match, and exchanged card plays. A class action and its shared suit change were observed across both sessions. This was a focused functional walkthrough, not a full match-completion or load test.
Visit live product ↗The context
Wahala started with a familiar Nigerian game and a different question: what would Whot look like if it were designed as a modern multiplayer game? I owned the project end to end, including the visual design, game logic, architecture, implementation, and deployment. The core gameplay, class selection, and abilities are playable today.
The problem
I wanted to reimagine Whot rather than simply reproduce a physical deck on screen. Character classes and abilities create a tactical layer around familiar shapes, numbers, and turn-taking, giving players another way to influence a round without losing the game's identity.
From familiar rules to tactical choices
Classes are part of the game design rather than a cosmetic choice. The selection screen introduces each character's passive and active power before the match, while the board keeps class actions close to the current hand and turn information. The goal is to make the extra layer understandable at the moment a player can use it. In the walkthrough, The Joker and The Wall produced distinct action sets for the two players.
Evidence / Product walkthrough
What the current build demonstrates
- 01
Private room → two seated players
Created a private Progression room and joined the second account using its invite code. The lobby reflected both players and readiness state.
- 02
Class choice → distinct action sets
Selected and locked The Joker on desktop and The Wall on mobile. Both sessions moved into the same match.
- 03
Ability → shared rule change
Activated Rule Twist. Both boards displayed the same demanded suit, and the host's ability state changed to spent.
- 04
Card play → synchronized turn change
Played a valid card from the host's hand. Both boards showed the new active card, the host's reduced card count, and the second player's turn.
A closer look
Tap any image to enlarge and explore the details.
Key features
- Private room setup, invite-code joining, and player readiness
- Character selection with passive traits and active abilities
- Live card play with separate player hands and shared table state
- Class powers that can affect active suit conditions and other gameplay rules
- Classic and Progression room modes
Keeping a changing game coherent
Live multiplayer state, abilities, gameplay, and spectating were the most difficult parts of the build. A card play affects the shared discard and turn owner, while a class action can change what counts as a valid next move. Each player still needs a private hand. That makes consistency between the local controls and the shared table central to the experience. In a two-account test, activating Rule Twist changed the demanded suit on both boards; a subsequent valid card play reduced the host's hand and passed the turn to the other player. Spectating and reconnect behavior were not independently exercised in this walkthrough.