Hi everyone,
I've built a small userscript and I'd like to offer it to the community as shared infrastructure — not as a finished product, more as an experiment I'd like your feedback on.
Repository: https://github.com/Rivenscryr/origin-exporter (MIT)
The problem it tries to solve
If you want to write a calculator or simulator, you don't need toleration — as long as it works on manually entered data or the public API. But the moment you want it to work with real account data, you end up writing your own userscript to scrape or export it. And that script needs toleration, which means your otherwise review-free tool is suddenly sitting in the review queue waiting on me.
That cost gets paid over and over again, by every developer, for essentially the same piece of code.
So: one exporter, reviewed once, with a documented output format. You consume the JSON, you skip the scraping entirely.
What it does
The player installs the userscript, clicks the Empire icon in the game menu, and clicks Export account data. The script fetches the account snapshot and the lifeform bonus breakdown from the game, merges in planet/moon name, diameter, fields and temperature from the page, and hands the player a single JSON object to copy or download. They paste it into your tool.
Contents, roughly: player identity, class, officers, research levels; per planet and moon the resources, production, buildings, ships, defences, lifeform buildings and researches, active buffs; the full lifeform bonus breakdown plus a flattened bonusByType aggregate for convenience.
The output format is documented in docs/schema.md, and there's a JSON Schema in docs/schema.json you can validate incoming exports against. schemaVersion tracks changes to my transformations — check it and reject versions you don't handle.
What it deliberately does not do
This exports your own account and empire state — nothing else. It is not a source of live gameplay data about the universe or other players, and it isn't intended to grow into one.
One scope note for consumers
This exporter removes your need to write your own scraper. It does not change what your own tool may do with the data afterwards.
Whether your tool needs toleration is unchanged by where the data came from — check the submission guidelines and if you're unsure which side of the line you're on, ask before you build rather than after.
The actual condition: bring your own bugfixes
This is the part I want to be blunt about, because it decides whether this is worth doing at all.
OGame will break this. A DOM change, a renamed field, a changed endpoint — it's a matter of when. When it happens, every tool consuming the export breaks at the same moment, and you will all be looking at the same repository.
If this gets used, I would be maintaining this in my spare time, on best effort, with no response time promised. If you build something on top of it, please be willing to fix it yourself. Open an issue with the actual error and the relevant response snippet, or better, open a pull request.
Realistically this only works as shared infrastructure if two or three people other than me are willing to touch it.
On my own role here
I wrote this as a developer, not in my Origin admin capacity. Treat it as one developer's offer, not an officially blessed pipeline — I'm not making any promises here about how the game's endpoints will behave in future or how long this approach stays viable.
If it turns out nobody wants it, that's a perfectly good result for an experiment.
Feedback, criticism and "this is solving the wrong problem" replies all welcome.
