Ravensight
A small studio ships a game and, within a week, is drowning in evidence. There are sessions in a dashboard somewhere, a handful of bug reports in a chat channel, a spreadsheet of wishlist numbers, a streamer's two hour video that contains the single most useful observation anyone will make about the tutorial, and a long thread of your own notes about what you would do differently. All of it is real. Almost none of it gets read.
Then the studio starts the next game, and every one of those things is gone. Not deleted, just unreachable: in a tool that was cancelled, a channel nobody scrolls back through, a spreadsheet whose column headers no longer mean anything. The second game begins on an empty dashboard, and the team relearns what it already knew.
Ravensight is built around the belief that both halves of that are solvable, and that the second half is the more valuable one.
The base layer is ordinary analytics, done properly
None of this works without a boring foundation, so the foundation comes first. You add an SDK, send named events, and get the things you would expect: daily players, sessions, retention cohorts, level progress, conversion funnels over any events in the order you choose, breakdowns of any event property by value, and player lists you can segment by those properties. Funnels report per step counts, drop-off against the previous step, and how long each step actually takes, because a step people complete slowly is a different problem from a step people abandon. Journey graphs are available when you want to see the paths rather than the totals.
Two details matter more than the feature list. The first is that every one of those questions can be asked of your whole studio at once, not just one title, and the answer is still computed per game underneath so nothing bleeds between projects. The second is that projects separate the production, staging and development builds of one title, each with its own ingest key and its own stream, so your own testing never contaminates the numbers you make decisions from.
An analyst that answers in plain language, and shows its work
On top of the data sits an AI analyst with read-only access to your own events. You ask a question the way you would ask a colleague, and it answers by actually querying, not by guessing from a summary. It can run SQL against your event table, and every query it writes passes through a guard that rewrites the query to your game before it executes. That guard is the most carefully built piece of the codebase, because the alternative is asking a language model politely not to read someone else's data.
What makes the analyst more than a convenience is what happens after the answer. Each conversation is distilled into dated findings, held for the studio rather than for one game, and each one can be confirmed, archived or traced back to the conversation that produced it. Over time that becomes a body of things your studio knows, with dates attached, that a later question can cite. Cross-game patterns are proposed from it weekly, and they stay marked as proposed until a person agrees.
Personas that play the build, and a fix loop that closes
Analytics tell you what players did. They cannot tell you what a player would have done in the build sitting on your machine right now, which has not shipped yet.
Ravensight Playtest sends AI personas through your own build from a CLI on your own machine. They play through the real SDK, so their sessions land in your event stream like any other, tagged synthetic, and every reader in the product excludes them by default until you ask for them. What comes back is a report: where the persona got stuck, what it tried, screenshots, and findings you can promote into the same studio memory the analyst writes to.
Then the loop closes. A fix attempt takes one promoted finding and tries the smallest change that removes it. The editing happens on your machine, in your own checkout, on a branch, through a metered proxy. The persona is replayed afterwards to check the failure is actually gone, and you are handed a changeset, the text for a pull request and the command to open it. Ravensight never commits and never pushes. The GitHub App it uses to read source is read-only on contents, by design, and the server has no write path to a repository at all. The reason is simple: a tool that edits your code without your review is a tool you have to supervise constantly, which is worse than doing the work yourself.
Memory, which is the actual point
The rest of the product exists so that a studio accumulates something.
Findings are the first layer. Marketing memory is the second: you record your own touchpoints, the trailers, streams, posts, press, launches, sales and updates, by hand or from a CSV, and the platform measures the lift in new players around each one. It states its method rather than implying magic. Lift counts new devices whose first event for a game falls within seventy two hours of the touchpoint, against a baseline built from the previous week. When two touchpoints land in the same window, both report the whole lift, and the product says so instead of splitting credit it cannot observe. That is a correlation with a stated method, not attribution, and calling it anything else would be the most confidently wrong number the feature could produce.
Everything above is also readable by your own agents. The MCP server exposes the same read-only, game-scoped toolset the analyst uses, authenticated with a personal access token, so the coding agent in your editor can ask what your players actually did before it suggests a change.
Why Godot first, and why prepaid usage instead of seats
Godot first, because that is where the studios this is built for actually are, and because a drop-in GDScript autoload is a genuinely small ask: batching, session handling, offline queuing and backoff are already inside it. Other engines are supported, and the ingestion API is plain HTTP, but the Godot path is the one that gets designed first rather than ported last.
Prepaid usage instead of seats, because per-seat pricing punishes exactly the thing a small studio needs to do. A two person team that wants a contractor, an artist and a community manager looking at the same funnel should not be charged three more times for the privilege. So teammates are uncapped, games are uncapped, every analytics surface is included, and what you pay for is work the platform performs on your behalf. A million events and ten AI units arrive every month for free. Past that, events cost five cents per hundred thousand and an AI unit costs twenty cents. A playtest persona run is a dollar, a game profile is four, a fix attempt is five, and a source scan is priced by how much code it actually reads. You see what a priced action costs before you buy it, and work that produced nothing usable is refunded.
What this looks like for two people
A tutorial that loses players. Before: you read a forum thread, form a theory, and rebuild the third room. After: a funnel over your first five named events tells you which step loses people and how long the survivors spend on it, and the analyst tells you in a sentence, with the query it ran underneath.
The week before a demo event. Before: you ask three friends to play, and get two replies. After: personas play the build overnight from your own machine and file findings, a fix attempt puts the smallest candidate change on a branch, the persona is replayed to confirm the failure is gone, and you review a diff in the morning. Nothing was pushed.
Starting the second game. Before: an empty dashboard and a vague memory that something about the second boss was wrong. After: the findings your first game produced are still there, dated, held for the studio rather than the title, and your own touchpoint record tells you which launch week activity moved new players and which one did not.
What it does not do
There are no ad platform integrations and no storefront integrations. Nothing reaches into an ad account or a store dashboard to pull numbers, which is why marketing memory asks you to record the touchpoint yourself and only computes the part it can observe from your own telemetry. Reference documents are read as text, with no OCR, so an image-only PDF is refused rather than half understood. There are no customer provider keys to manage. And the server never writes to your repository.
Each of those is a deliberate absence. A product that quietly guesses is worse than a product that tells you what it does not know.
Where this goes next
The memory is the part that keeps growing, but the more interesting work now is how you use it. A brainstorm session is a place to think out loud with the whole of your studio's history in the room, patterns, findings, touchpoints, sales and reference documents, instead of starting from a blank page, and the cards you end up keeping become a design brief. Today that session is a board of columns. A freeform canvas is what it wants to be, so a studio can lay its own thinking out spatially rather than in a list, and that is the next thing being built. No date on it, and this blog will say plainly which parts are shipped when it describes them.
The shorter version: a game you shipped should make the next one easier. Right now, for most small studios, it does not. That is the problem worth solving.