Why GameBus

A platform for behavior change campaigns

GameBus is a web framework for teams that build apps to support behavior change. These apps can help people move more, learn new habits, take part in a study, or follow a guided program over time.

The framework grew from living-lab research on gamified digital health interventions. Its purpose is not to prescribe one behavior change strategy, but to make strategies configurable, measurable, and comparable without rebuilding a separate app for every experiment or campaign.

GameBus does not start from a blank page. It gives you a working core with campaigns, groups, missions, activities, and progress rules. You configure these parts for your own program.

Configuration over custom code

Most campaign work in GameBus is done by configuring the model: who can join, which groups exist, when waves run, which missions are active, and how activities count toward progress.

Why teams use GameBus

Behavior change apps often need the same building blocks:

a way to enroll people in a campaign;
a way to split people into groups or study arms;
time periods for onboarding, intervention, and follow-up;
missions that guide users through actions;
activities that record what users did;
progress rules that decide what becomes available next.

GameBus Core brings these parts together in one system.

The result is a system-of-systems approach. Core keeps the campaign model, participant access rules, activity data, progress calculations, and consent records together. Other apps and services can then contribute activity data, embedded experiences, stories, dashboards, or support flows around that shared model.

For campaigns

Run a program on its own domain and show users content that matches their group and wave.

For studies

Assign participants to study arms and compare behavior across different paths.

For interventions

Use missions, milestones, and skills to guide users from simple tasks to harder goals.

For integrations

Accept activity data from connected providers, such as trackers or partner systems.

What makes GameBus different

GameBus is built for programs where users do not all follow the same path. A participant may belong to one group, join during a specific wave, and see missions that are only meant for that combination.

This makes GameBus useful for research and practice. Researchers can model study arms. Campaign organizers can manage content over time. Developers can connect external activity sources without rebuilding the whole campaign model.

GameBus is also designed around privacy-by-default. Activities and their structured properties are not automatically public to other participants. Campaign organizers must deliberately decide which groups, roles, tasks, and integrations need access to which data, and participants can be asked to approve required or optional consent items.

Research rationale

GameBus supports empirical comparison of behavior change designs by encoding intervention structure as configuration: groups, study arms, waves, missions, task rules, activity templates, property templates, and provider integrations.

Design principles

Configuration over custom code: common campaign structure is modeled as data, so many variants can be prepared without rebuilding the app.
Experimental control: study arms, waves, mission enrollments, and progress rules make differences between participant paths explicit.
Input interoperability: providers can bring activities from external systems into Core using API key or OAuth 2 based authorization flows.
Output interoperability: activities, properties, engagement records, and campaign configuration are structured so they can be exported or analyzed outside GameBus.
Privacy preservation: group membership, consent, property visibility, and trusted embed origins constrain what is shared and who can contribute data.
Extensibility: custom tasks, pages, menu widgets, stories, assistants, and integrations can extend the experience while Core remains the source of truth.

The main idea

GameBus links three questions:

Who is the user? Their group memberships and roles define where they belong.
When are they active? Waves define which period applies.
What have they done? Activities and skills define progress.

The answer to these questions decides which missions, milestones, and pages are available.