Player consent
Permissions
Every SDK capability maps to a permission scope. Games should request only what they actually need.
Permission matrix
Qubiz evaluates SDK calls against the saved SDK permission policy. Some low-risk data, such as display name, can be allowed by default. Higher-risk data and writes can require player consent.
- profile:username - read the player's public display name.
- profile:avatar - read the player's public avatar URL.
- profile:email - read the player's email address; high-risk and should rarely be needed.
- assets:read - read reviewed project and marketplace assets.
- scripts:run - request creator script execution from the host.
- debug:console - open the SDK debug overlay and forward developer logs.
- storage:save - write local/cloud save data for the current game.
- storage:read - read game-specific cloud save data.
- leaderboard:submit - submit scores to public leaderboards.
- multiplayer:rooms - create, join, leave, and send realtime room events.
- achievements:write - unlock player achievements for the current game.
- quests:write - update quest objective and completion state.
- economy:read - read wallet balances and inventory summaries.
- economy:write - write currency, item, and economy transactions.
- payments:purchase - reserved for future purchase flows.
- analytics:events - send creator analytics events to Qubiz.
- sandbox:execute - execute isolated project code with bounded host capabilities.
requestPermissions
Call requestPermissions before using features that need consent. The result tells you which scopes are granted, denied, or still require a prompt.
Do not block the whole game if a non-essential permission is denied. Good games degrade gracefully.
const result = await QubizSDK.requestPermissions([
"storage:save",
"analytics:events"
]);
if (result.status === "granted") {
await QubizSDK.saveData("slot-1", { level: 4 });
}