BrightGame. ADD Strategy · a no-code creator for serious learning games
A trainer with no game-design background builds a learning game around their own process. The software checks the game against ADD Strategy's rules for what makes one play well, and explains a rule while the author is still writing.
No-code creator for trainers Design rules the software checks Three development agreements
What BrightGame lets a trainer build.
ADD Strategy design serious learning games: training built around a real workplace process, where people learn by playing through the decisions rather than sitting in front of slides. They have designed enough of them to know what makes one work and what makes one fall flat.
BrightGame is the product OpenKit built for them, a guided authoring flow where somebody without a game-design background defines their process as stages, then writes the actions, scenarios, characters and wildcards that make it playable. ADD Strategy's design judgements are in there as rules the system checks, with a chatbot that explains a rule before the author runs into it.
- 01
A multi-step creator covering stages, actions, scenarios, characters, wildcards and clusters.
- 02
A validation layer that will not let an author move on from a stage that will not play well.
- 03
A chatbot carrying the same expertise into the creator, as standing guidance while an author writes and as a warning when the game is heading somewhere that plays badly.
Design judgement that lived in people's heads.
Hand a subject expert a blank game creator and they will write fourteen stages with four actions in each, because nothing in front of them says that is a bad idea. Hand them a forty-page design guide instead and it goes unread, which is fair enough when their job is the training rather than the game design.
So the judgement went into the software, where an author meets it as a consequence of what they are writing rather than as a chapter they were meant to have read. That turned the work into a run of decisions with ADD Strategy about what their expertise actually says, threshold by threshold.
The thresholds the system enforces.
-
Stages per game
5–7
Five plays best. Choosing seven triggers a warning about the card-writing it commits the author to.
-
Actions per stage
8–12
Tightening to 9–10 at seven stages, so a longer game does not become an unplayable one.
-
Optional cards
20 / 25 / 35
A minimum that scales with stage count, and a hard ceiling of 35 whatever the author would prefer.
-
Scenarios
3–8
Enough situations for the game to vary between plays without diluting any of them.
-
Characters
5–20
One role each. A character holding two roles breaks the decisions the game is asking players to make.
-
Wildcards
10–20%
Of total actions, capped at three per stage, and never drawn from the cluster cards.
-
Action cost tiers
3 · 5 · 7 · 10 · 15 · 20
Six tiers of effort, so cost is a considered choice from a fixed set rather than a free number.
-
Impact balance
−20 to +20
Negative saves time and effort, positive adds it, and the whole set has to sum inside ±15.
These are the system's design constraints: what the software will and will not let an author ship.
Guidance at the point of the decision.
A rules engine on its own only ever says no. The chatbot carries the same expertise into the moment the author is deciding, so somebody approaching a limit hears about it before they reach it, and gets the reasoning behind the rule rather than a refusal.
- 01
Standing guidance that sits with the step, explaining what a good answer at this point looks like before the author starts writing.
- 02
Explanations on hover for each column of the action grid, so the difference between what a player must do and what they should never do is available at the moment it matters.
- 03
Situational messages fired by thresholds and by trying to move on, which is where an author finds out their game will play badly while it is still cheap to change.
The creator screen does the same work in miniature, with a running card count the author can read at a glance and a warning state as a limit gets close. Picking seven stages is the clearest case: it is allowed, and the author is told what the extra stages commit them to writing before they choose.
Publishing, billing and running the platform.
A library that keeps every version
Games are kept as versions rather than files, so an author can change what learners struggled with and publish when they are ready. The history is there without anyone having to manage it.
Billing inside the product
Tiered subscriptions, team plans and invoicing run on Stripe inside the product, so a new customer picks a plan, pays and starts without a conversation with the BrightGame team first.
One screen for the operator
Notifications, the latest edit made to every game and the games someone owns sit on one screen, so seeing what has changed across the platform does not mean opening three tools.
Games that run inside the training site
The finished game drops into the WordPress site the training team is already operating. Learners stay where they were, and shipping a new game does not mean asking anyone to move platforms.
Signed development agreements, one after another.
ADD Strategy signed a development agreement with us, then a second, then a third, each one funded after they had seen what the last had produced. They took BrightGame public in 2023, with a pre-seed round of more than £100,000 closing as the platform went live. Nobody measured what the finished games did for the people playing them.
The build
- Drag-and-drop game creator UI
- WordPress plugin integration
- Stripe billing
- Custom serious-learning-game runtime
OpenKit certifications
- ISO 27001
- ISO 9001, UKAS-accredited
- Cyber Essentials
Controls on this project
- UK GDPR
- UK data residency
More of the work.
Find your first workflow.
We start with a conversation, audit where AI actually pays back, and build the first automation into how your team already works. We reply within one working day.
Get in touch AI Engineering