#Getting started

Indigauge helps you collect the signals that are hardest to reconstruct after a playtest: when sessions start, what players did, where errors happened, and what players wanted to tell you in the moment.

The fastest path is:

1. Create or open your game in the Indigauge dashboard.
2. Create a public key for that game.
3. Install the SDK for your engine.
4. Start a session when your game boots.
5. Send a few stable namespace.event events with useful metadata.
6. Open the dashboard and verify sessions, events, and feedback.

#Pick your engine

Both SDKs follow the same core model: start one session per game launch, queue events while the player is active, flush in batches, and attach optional feedback to the current session.

#Get a public key

Each game should use its own Indigauge public key. The SDK sends this key when it starts a session so the ingest API knows which game the data belongs to.

#Start in development mode

Use the SDK development mode while you are wiring the integration. Development mode lets you confirm that sessions, events, metadata, and feedback calls are working without filling production analytics with local test data.

• Bevy: set .mode(IndigaugeMode::Dev) while testing locally.
• Godot: leave mode as AUTO; editor and debug builds resolve to DEV.

Switch to live telemetry for release builds or live QA once the event names and metadata shape are stable.

#Name events deliberately

Event names must use the strict namespace.event format. Examples:

game.start
player.jump
level.clear
ui.open

Use metadata for values that change:

{
  "level": 3,
  "difficulty": "hard",
  "score": 1250
}

Avoid encoding IDs, timestamps, level numbers, or player choices into the event name itself. That keeps your dashboard easier to filter and compare across builds. See the Event Naming guide for the full rules.

#Suggested first events

Start with a small event set that answers real questions. You can always add more once you know what you want to inspect.

For games without levels, use names that match your structure: run.start, match.end, quest.complete, or round.loss.

#Add session metadata

Session metadata is best for state that describes the whole play session or the current run, such as score, selected character, region, difficulty, matchmaking mode, active level, or experiment assignment.

Prefer session metadata when the value should be visible across many events. Prefer event metadata when the value only matters for a single action.

#Enable feedback

Player feedback is most useful when it can be opened from inside the game, close to the moment of frustration or delight. Both engine integrations include a feedback flow you can trigger from your own UI.

Good places to expose feedback:

• Pause menu
• Bug report button
• End-of-run screen
• Playtest overlay
• Keyboard shortcut during QA builds

#Production checklist

• Use a real public key for the correct game.
• Use a stable game name and version.
• Keep event names stable across releases.
• Send dynamic values as metadata, not as event names.
• Avoid sending personally identifiable information unless you have a clear reason and consent.
• Verify a release-like build in live mode before shipping.
• Confirm the feedback panel fits your input map and UI layer stack.

#Next steps

• Install the Bevy SDK.
• Install the Godot addon.
• Review event naming.