Game Analytics and Events in Summer Engine

You shipped your game. People are playing it. Now you want to know where they stop, which level is too hard and which mode they pick. That is what game analytics is for, and most indie games never get it because wiring up a tracking stack takes a week you do not have.

Summer Engine is the game engine built for AI. Any agent can build a full multiplayer game in it and publish it on Summer Games. Analytics is part of that path. The basic numbers arrive with zero code, and your own game events take one line.

This guide covers what Summer counts for you, how to track your own events, how multiplayer events work, and how to read the numbers in Summer Studio or through your agent.

What does Summer count for every game

Every game on Summer Games gets four numbers by itself. There is no code to write and no setting to turn on.

• Store page views. Someone opens your game's page on summer.games.
• Launches. The game starts in the Summer Games desktop app or in the browser.
• Play sessions. A session ends, because the game quits or the player leaves the browser game.
• Play time. The length of each finished session, added up.

A few details make these numbers honest. On the summer.games website, one page load counts as one page view, and bots that do not run JavaScript do not count. Browser play reports a launch and the length of the session. These reports are sent without a cookie or a sign-in token. If a report is retried, it still counts once.

The Summer Games desktop app counts launches, play time and your game's own events. Days are in UTC, and the history of these four numbers does not expire. They also do not count against your custom events.

Why do indie games need analytics

Small teams make decisions by feel. Feel is useful, but it does not tell you that most players quit on tutorial step three, or that nobody finishes level four.

Good game analytics answers a short list of real questions:

• Where do players stop? See which tutorial step most players never get past.
• Which level is too hard? Compare how many players start and finish each level.
• Which mode do players pick? Count matches and players per mode.

You do not need hundreds of events for this. A handful of well-named events beats a firehose. Summer adds who, which game and which version to every event, so your game only says what happened.

How do you track game events step by step

Here is the full path from an empty project to numbers in your dashboard. Do this before you export, because events are only in the builds that include them.

1. Ask your agent to plan the events. Paste this prompt:

   Plan analytics for my game.
   

   Your agent reads your project and proposes a small set of events. It writes no code at this step.

2. Pick your setup. For moments on the player's screen, such as menus and tutorial steps, use:

   Track my tutorial and menus.
   

   For facts your server decides, such as wins and pickups, use:

   Track gameplay on my server.
   

3. Or let the agent do it right before you publish. This prompt adds a few events that answer your questions:

   Add analytics before I publish.
   

4. Check the code. The smallest version is one line of GDScript:

   Summer.client.analytics.capture("level_completed", {"level": 3})
   

   The docs recommend a small helper so a failure warns once and gameplay never waits:

   var _analytics_warned := false
   
   ## Fire and forget: never await this, never retry it.
   func _track(event: String, properties: Dictionary = {}) -> void:
       var capture := Summer.client.analytics.capture(event, properties)
       var result: SummerResult = await capture.get_result_or_completed_signal()
       if not result.ok and not _analytics_warned:
           _analytics_warned = true
           push_warning("analytics unavailable: %s" % result.code)
   
   func _on_level_completed(level: int, seconds: float) -> void:
       _track("level_completed", {"level": level, "seconds": int(seconds)})
   

5. Test locally. Press Play. Under Local Play the game runs normally while events report unavailable. Have your game print each event to its log so you can check names and properties.

6. Publish, then check. After the first published build, open Grow → Analytics in Summer Studio and check that your events appear. A short delay is normal.

7. Ask how it is going. A few days later, paste this:

   How is my game doing?
   

   Your agent reads your Grow numbers and tells you what they mean. It changes nothing.

The full guide, with every prompt, is on the see what players do docs page. The publishing checklist is in analytics for published games.

How should you name your events

Event names are the part people get wrong most often. Summer has a few clear rules.

Use fixed names in the past tense

Name the thing that happened, such as level_completed, boss_defeated or tutorial_step_completed. A name is 1 to 64 characters. It starts with a letter, and then uses letters, numbers, underscores, dots, colons or hyphens. Never start a name with summer..

Put values in properties

Send level_completed with {"level": 3}, not level_3_completed. One event then covers every level, and you can compare them side by side. Properties can hold at most 64 values, nested at most 4 deep.

Keep personal data out

Do not send emails, ids, tokens or text the player typed. Summer already adds the player, the game and the build to each event.

Never wait and never retry

Recording an event happens in the background. Call your helper without await so gameplay never waits. If a send fails, do not send it again, because the first call may already be stored.

How do multiplayer game analytics work

Multiplayer games have two places where things happen: each player's game and the server that owns the rules. Summer lets both record events.

Events from the player's game

Use Summer.client.analytics for what happens in menus and the interface: a tutorial step shown, the settings opened, a mode picked. These come from each player's own game.

Events from your server

Use Summer.authority.analytics.capture for what the server decides: a match won, a coin collected, an item bought. These are the numbers to trust, because they come from the server and not from a player's device.

The multiplayer journey, recorded for you

Summer records the main steps of every match without any code. A player starts searching, is matched, joins a World and finishes a match. That gives you a funnel from "looked for a game" to "played to the end" out of the box.

Match endings feed into this too. Your server decides the outcome for every player, and Summer records that result once, even if the server sends it twice after a network hiccup. The match results docs explain how endings, draws and early leavers work.

If you have not built the multiplayer part yet, start with how to make a multiplayer game with AI and the multiplayer overview in the docs.

Where do you read your numbers

There are two ways in, and they show the same data.

In Summer Studio

Open Grow → Analytics, pick your game and choose 7, 28 or 90 days. You see four tiles for store page views, launches, play sessions and play time, each with a daily line. You also see the average play session and the custom events your game sent, with counts.

Grow also lists the event names your game sends, which is a quick way to catch a typo before it splits your data in two. For the wider picture of Grow, read grow your game in Summer Studio.

With your agent

Your agent can read the same numbers through the Summer Engine MCP, then suggest one next step. Two tools do the reading:

• summer_grow_analytics returns one game's totals, every day of the window and the game's top custom events.
• summer_grow_overview returns store page views, launches, play sessions and play time per game and in total, across all your games.

Both are read-only, use 7, 28 or 90 days in UTC, and need your Summer account. A call looks like this:

{
  "name": "summer_grow_analytics",
  "arguments": { "gameId": "<gameId>" }
}

The Grow MCP tools reference lists every input. If you want ready-made prompts for this and other jobs, see the Summer Engine MCP prompt templates.

Why does this fit an AI game engine

Most analytics setups assume a person reads a dashboard every morning. In Summer, your agent can read it for you. It plans the events, adds them to your code, and later reads the results and tells you what to try next.

The agent reads your project to plan events, and reads your Grow numbers to judge them. We wrote more about that design in how Summer's engine-native agent harness works and in what an AI game engine is.

If you come from Godot, this will feel familiar. Summer Engine is compatible with Godot 4 projects, and the code is plain GDScript.

What are the limits today

We would rather tell you now than have you find out after launch.

• Your own events do not record in the browser yet. In the summer.games web player, capture reports unavailable. The four built-in numbers still count there.
• Local Play does not store events. Under Local Play and in the editor, capture reports unavailable and nothing is stored. Use your log to check events while you test.
• Events only exist in builds that include them. Add your events before you export.
• Custom event counts are approximate. The top events list is good for trends, not for accounting. Use server events for numbers you need to trust.
• There is a short delay. Events in a hosted game show up in your Analytics tab after a short delay, not instantly.

What should you do next

Start small. Pick three questions you want answered about your game, and let your agent turn them into events.

1. Open your project and paste Plan analytics for my game.
2. Review the events it proposes and keep the ones that answer your questions.
3. Publish on Summer Games and watch Grow → Analytics fill up.

New to Summer Engine? Tell your agent "Install Summer Engine and let's make a game." It sets everything up and starts your first project. Find out more at summerengine.com.