OG-E is purely a UI overlay — it doesn't automate the game, it isn't a bot, it doesn't monitor your fleet and it won't notify you when you're under attack.
UI overlay, not a bot
Zero requests of its own
Open source
Mobile-first
It also sends no requests to the game server. Every click remains a deliberate click by the player, with OG-E acting only as an intermediary: it presses the game's native UI element — even when it has hidden that element and replaced it with a clearer one of its own. OG-E never creates or modifies game requests; it only records and analyses the responses the game returns, and reads what is already displayed on the page.
The project is fully open source and entirely generated by AI.
Below, every feature is described one after another: what it does, how it works, what edge it builds and why it plays fair. Documented: 19 features. Work in progress — more are coming.
The OG-E Button6 features
OG-E's flagship hub: one floating button that fires every fleet action with a single tap — expeditions, colony hunting, discoveries, daily routes, reminders.
One floating button under your thumb that fires every fleet action — designed first and foremost for the phone.
The floating button: one active module in the centre, the rest as orbs around it.
mockup / screenshot: dragging
Dragging the button under your thumb — position remembered per device.The module bar in settings — tiles enable/disable commands.
How it works
The FAB is a single floating button that hosts your fleet-action modules — expeditions, colonisation, discovery, daily routes, reminders. You always see one active module in the centre and a few smaller "orbs" around it; tapping an orb switches the active module, and tapping the centre runs its action on the current page.
You drag the button anywhere you like (its position is remembered), and each module knows which game page it makes sense on.
Why it exists
It is built mobile-first: on a phone OGame scales the page so its native buttons become tiny and hard to hit. The FAB gives you one big, comfortable target under your thumb and gathers scattered fleet actions in one place — it works on desktop too, but the phone is the main scenario.
More details
You turn modules on and off with tiles in settings; the button size is a live slider.
Position and the selected module are remembered per device; after a reload the button returns to the same spot (clamped to the visible screen).
Long-press has a separate, module-dependent meaning (e.g. "skip this planet").
Fair play
The FAB sends the game no requests. It clicks the same native UI element for you that you would press yourself — if the game contacts the server in response, it does so itself, after your tap, exactly as with a manual click.
It only acts on what you already have open: it reads what the game already displays and does nothing in the background — it does not refresh the page, scan, or track the game.
Daily expeditions from many planets as a series of taps on one big button, with an automatic jump to the next planet.
The "Expeditions" module — label depends on the page (Exped / Send).
mockup / screenshot: auto-next
Automatic jump to the next planet with a free slot after a dispatch.
How it works
The Expeditions module turns your daily expedition round into a series of taps on one big button. The fleet composition, target and mission type are decided by the AGR routine you run anyway — OG-E merely presses the right native game button at the right moment.
Once you have sent as many expeditions from a planet as you want, the button moves on to the next planet with a free slot by itself — until the limits are exhausted.
Why it exists
Without it, sending expeditions from a dozen-odd planets is dozens of precise clicks on a tiny native button. Here you do the whole round with your thumb, without even remembering which planets you have already covered.
Fair play
OG-E sends the game no requests: it clicks the AGR routine and the native "send" button — the same elements you would press yourself. The dispatch is done by the game, after your tap. The composition and target of the expedition are set by AGR, not OG-E.
The automatic jump to the next planet only hints to the game which page to show after a dispatch — it generates no traffic of its own to the server. The button never moves anyone else's fleet, nor a manually armed one.
One button points to the next-best free slot on the whole server and sends a colony ship — a second helps you abandon colonies that came out too small.
The "Colonisation" module with an "N free" counter — how many chosen positions are still open.The "Abandon colony" module on the overview of a too-small, fresh colony.
How it works
The Colonisation module points to the next-best free slot across the whole universe (per your position and galaxy preferences) and sends a colony ship there — skipping spots the game has just flagged as occupied. An "N free" counter shows live how many of your chosen positions are still open.
It comes with an Abandon colony module: it catches a freshly settled planet that is too small and walks you through abandoning it, so you can try elsewhere. A slot once abandoned never returns as a suggestion on any of your devices.
Why it exists
Hunting for big colonies otherwise means combing galaxies by hand, watching the gaps between landings and abandoning the misses. This duo runs the whole cycle: find a free spot → send → if too small, abandon and keep trying.
More details
Free spots come from OGame's public API (the server's map of occupied planets) — candidate data, confirmed against the live galaxy view before a colony ship flies.
The button watches the minimum gap between landings — if the next one would fall too close, it shows "Wait Ns".
The landing countdown runs on server time and offers a refresh itself once the new colony is there.
Fair play
OG-E sends the game no requests — it clicks the native send and abandon elements, exactly the ones you would press yourself. The planet size for the abandon decision is read from the already displayed overview, with no extra query.
The free-spot data comes from a public, statistical API (the same one community tools use) — that is, the server occupancy map, not any background mass scanning. Without that data the button only works on what you have scanned yourself by playing normally.
One button that knows where the nearest undiscovered system is and lets you discover it with a single tap, so you can easily gather lifeform artifacts.
The "Lifeforms" button in the galaxy view — ready to discover the current system.The signal for 8 discovery missions sent.
How it works
The Lifeforms button walks you through discovering systems: it points to the nearest undiscovered system, moves the view there and lets you discover it with a single tap. It skips recently discovered systems so you do not waste an action — and comes back to them once they are available again.
On top of that, when you visit the lifeform research page, it reads how many artifacts you currently have, and if you have not been there in a while it suggests going there. All to remind you that you already have 3600 of them or more.
Why it exists
By hand it is a tedious sweep of the galaxy looking for what is still undiscovered — the button takes that navigation off your hands and keeps you from clicking systems you have already discovered. It is also convenient on mobile.
Fair play
OG-E does not initiate a discovery itself — it clicks the native "discover system" button, only when you tap it, and the game sends the fleet, exactly as with your own manual click.
The artifact counter is read only from what the game already displays, during your natural visit to the research page — with no background queries.
A daily send-off of the same ships on the same routes from one button: it sends fixed ships to the same targets and pulls everything back to one chosen body.
The Daily Run button with two zones: top "deploy", bottom "collect".Route configuration in the OG-E Dashboard.
How it works
The Daily Run button runs your daily fleet moves. You define a route once (from where, to where, with which fleet and which mission), and then the button walks you through sending the defined routes. The top zone dispatches the defined missions to all targets defined for the active planet that is the starting point — you can pick multiple targets from one planet, different missions, multiple ships, and multiple routes.
The bottom zone sends everything to the chosen planet and moves on to the next one (Collect); holding it changes the target to the active planet. It sends ships and resources according to the options chosen in the Dashboard.
Targets a fleet is already flying to are skipped, so you will not accidentally send to the same place twice. This also enables farming inactive players.
Why it exists
The daily routine is a tedious ritual: picking ships, missions, targets, and collecting the daily income by going through every body while keeping track of what is already done. Daily Run walks you through the whole round step by step, and you just tap one button. Great on mobile.
Fair play
This is player guidance, not a bot: OG-E does not send the fleet itself — it presses the native dispatch button, and the game performs the dispatch, after your tap.
The button reads from the flight list which missions you sent yourself — not from any background tracking.
An in-tab button reminding you that your fleet-save is back and sitting exposed, so you send it out again right away.
The "Fleet Reminder" button in the Fleet1 panel — the fleet is waiting to be re-dispatched.The "Fleet Reminder" orb lit up next to another active button — a signal that the fleet is still waiting.
How it works
When your fleet-save returns and is available on the planet, a prominent, new button appears reminding you about your fleet. You can turn it on manually from the Fleet1 panel, or it turns itself on when the FS lands.
You turn it off by re-sending the fleet with this button — it then uses your AGR fleet-save configuration — or manually: from the Fleet1 panel, or by long-pressing the button. Tapping it takes you to the right planet and lets you send the fleet out again immediately; after a longer idle spell the button starts pulsing to catch your eye.
It only works on the tab you are on — if you are on another tab, you will not be notified there. It plays no sounds.
Why it exists
A returned fleet sitting idle is easy prey, and it is easy to forget even while you are online, just busy doing something else. This button makes sure you send the FS before you go offline — so it does not slip by.
Fair play
It works only while the tab is open and does nothing in the background: when the tab is hidden it does not even pulse. It knows about the returned fleet from the event list the game displays anyway — not from any server tracking.
This is the in-tab layer; the optional push notification while you are offline is a separate feature, described honestly alongside the alarm clock.
Spyglass — intelligence8 features
A large intelligence module: peek and spy, opponent dossiers, a threat model, enemy-routine analysis with offline windows, and a "who is spying on you" panel. All built from data you gathered by playing normally.
Full intelligence on the players of your server: who is dangerous, who is worth hitting, where the loot sits and when the owner is away from the keyboard.
The Spyglass tab: watch list, scan settings, the "who is spying on you" panel and the player ranking.
How it works
Spyglass has two sources of knowledge and one backbone. The galaxy channel (galaxy) is an ordinary visit to a system — free, invisible to the target, and it yields activity markers plus moon information. The probe channel (probes) is a normal spy report — it costs probes and the target sees it, but it shows fleet, defence and resources. The backbone is the watch list (Watchlist): whoever you put there is what the in-game button works on, and that is the player whose dossier grows.
The feature lives in two places. The floating button in the game proposes one next intelligence action. The Spyglass tab in the OG-E dashboard is a reading room: server ranking, dossiers, map and the "who is spying on you" panel — without a single send button. The danger ranking works from the very first run, off the public server statistics; scanning only deepens it.
Why it exists
Intelligence in OGame is normally manual labour: a hundred reports in your inbox, a notepad of coordinates, and memory of who was dangerous half a year ago. Spyglass turns that into six questions with ready answers — and that is all you need to know to use it. The rest of this chapter is detail for the curious, not a manual.
More details
Who to avoid and who can be touched? — the danger ranking (Danger).
What to look at next? — the Look / Spy / Strike button.
Is he worth hitting and where is the loot? — the player dossier.
When is he away? — routine and offline windows.
Who can reach me? — the position map and range.
Who is sniffing around me? — the "who is spying on you" panel.
Fair play
Everything Spyglass knows comes from three places: the public server statistics files (the same ones community tools use), game pages you opened yourself (reports, the galaxy view, alliance highscore) and what you sent yourself. There is no background scanning: with no game tab open OG-E does nothing, and the statistics files have a freshness deadline rather than being polled on a cycle.
The Spyglass tab is a reading room with no trigger — there is no sending in it at all. A probe can only be launched from the game, by a deliberate tap on a single body, through the native two-step fleet dispatch form. There is no "scan everything" button and no action that covers multiple targets.
The whole server in one table, sorted from the most dangerous down: a 0–100 number and a one-word archetype tell you who not to poke and who you can hit.
The player ranking sorted by the Danger column — the archetype next to the number, then the fleet ceiling, military points and hull class.The score breakdown inside the dossier: where the number came from and which signals raised it.
How it works
The Players table is the entire server ordered by the Danger column. That number does not measure "how many points someone has" but how many of those points can fly at you: military points include defence, and defence does not attack — so OG-E splits them into a mobile and an immobile part, judges hull quality (the cost of a single ship) and compares the result against the whole server. On top of that it adds predator signals: destruction percentage, bandit tier, colony spread (how much of the server he actually reaches) and alliance class.
Next to the number stands an archetype — one word instead of a table: Apex hunter, Bandit raider, Fleeter, Cargo swarm, Fortress, Turtle, Economist, Declawed bandit, Friendly. The Fleet column shows ≤, because it is a ceiling, not a measurement — only a complete set of your own reports brings it down to an exact number and the ≤ sign disappears.
Why it exists
The highscore lies in both directions: a turtle with a mountain of defence points looks scarier than a fleeter who would actually wipe you out, and a vault with no fleet looks like a predator. One column separates those cases, so picking a target and judging risk is a glance rather than an investigation — and you have it for the whole server before sending your first probe.
More details
Zero ships is always Danger 0; your own alliance and buddies are 0 as well. Anyone with something to fly has at least 8.
The cost of a single hull splits the fleet into classes: below ~20k resources — civilian (cargos, probes), 20–100k — combat, above that — capitals, or defence? if your scans have not confirmed it yet.
Aggressor bonuses (bandit, range, warrior class) do not stack without limit — they fill up the headroom to 100. That way a peaceful giant never becomes an "apex".
Apex hunter requires at least two of six signals, including at least one aggressive one (destruction, range, colony placement) — fleet size alone is not enough.
Filters: hide inactive, watch list only, a military-points range, top 50 / 100 / 200 / all. Searching by name also finds filtered-out players and shows why they were hidden.
Fair play
The whole table is arithmetic over the public server statistics files — the same ones community tools use. Nothing here is stolen: these are numbers everyone sees in the highscore, only arranged into an answer to "who is dangerous". The files have a freshness deadline and are read while you happen to be visiting the game, not on a cycle.
The table sends nothing and contains no in-game action — the + watch star only adds a player to your own note. Data from alliance mates (if you enable sharing) is view-only: by design it feeds neither the Danger number nor the scan plan.
The Spyglass button in the game offers one next intelligence action: a free look, a probe or a moon opportunity — always exactly that one.
The "Look" face: a free visit to system [galaxy:system], one visit refreshing two watched bodies.The "Spy" face once armed: you see who you are flying at — a second tap sends the probe.Scan settings: probe count, planets/moons, launch point, refresh deadlines, moon-hunting mode.
How it works
The button shows one proposal at a time, picked from the scan plan for the players you watch. Look is a visit to a system in the galaxy view — free and undetectable; the label carries the target [galaxy:system] and ×N, i.e. how many watched bodies that single visit refreshes. Spy is a probe on one body: the first tap arms it and shows who you are flying at, the second sends. Strike lights up when the looks alone suggest a fleet may be parked on a moon. N left tells you how many bodies in the plan are still waiting.
The plan order is danger × staleness × good moment: never-scanned and overdue bodies first, and if the local hour falls inside an observed activity window of the target, the proposal is promoted. You set the deadlines yourself (Re-scan, Re-look), and likewise the number of probes per scan, whether to scan planets, moons or both, and whether probes launch from the nearest planet or from the one you are standing on.
Why it exists
Running intelligence by hand is bookkeeping: who was scanned, what went stale, where a look is enough instead of burning probes, which planet you skipped. The button keeps that ledger for you and leaves you one decision — tap or not. It works especially well on a phone, where clicking through the galaxy is the most tedious.
More details
galaxy and probes on a watched player's card are two independent channels — you can run a player on looks only, in which case the target sees absolutely nothing.
Looks are always recorded for watched players while you browse the galaxy; the toggles only mute the *proposals*, not the recording.
Moon strike: off, lone (only the moon glows, the rest reads as quiet), newest (the freshest interaction on the account is on the moon), any. Before a strike the button asks you to complete the picture of the whole account first.
↻ on a card marks all of a player's bodies as "due for a re-scan"; never means "never spied on".
Bodies sent this session drop out of the plan, and bodies still within their deadline never enter it — you cannot accidentally double a probe.
A configured patrol radius adds the neighbourhood of your colonies to the look plan (see "Patrol").
Fair play
One tap is one action. OG-E does not send a probe by itself: it fills in the native, two-step fleet dispatch form and presses the game's own button — the one you would press by hand — and only for one body. There is no "scan everything" and no multi-target action. Look is simply a move into a system in the galaxy view, exactly what a player does with the arrows.
The scan plan is a queue of proposals, not a queue of jobs: there are no timers, no background sends, nothing starts without your tap, and with no game tab open the button does not exist at all. All the knowledge the ordering rests on is your own reports and your own browsing of the galaxy.
The expanded row of a player: a one-sentence verdict, the danger-score breakdown and a table of all his bodies with scan age, defence, fleet and loot history.
The full dossier: verdict, danger breakdown and the player's rhythm on the left, the table of all his bodies on the right.The body table: scan age, last interaction, defence, visible fleet and average plus peak loot — moons under their planets.
How it works
The left column is judgement. A header like loaded · heavily defended · loot ~16.27B · scan 25h old sums up the situation, and one sentence below it says what to do about it. Then comes the danger-score breakdown and the most interesting arithmetic: public military points minus the defence and fleet your reports have seen leaves a remainder nobody can see — that is the fleet in the air, usually on a fleet-save. Until you have the complete set of bodies, that number is marked as provisional.
The right column is evidence: one row per body (moons indented under their planet) with the age of your scan, the last interaction, defence, visible fleet, and the average and peak loot you have ever found there. A star marks the body with the largest visible fleet, a vault marker the home planet. Chips in the header say how many planets and moons you already have scanned and what is missing for a complete picture.
Why it exists
This is where you make the call: hit or pass, and if hit, which body. Instead of clicking through twenty reports from different weeks and doing the maths in your head, you get one table with history — you see not only what sits there today but also what *usually* sits there and where this player really keeps his wealth.
More details
Loot is the single best planet from the freshest report, run through the plunder percentage — never the sum of a whole empire, because a single raid takes from one body anyway.
The verdicts it can reach: RAID NOW, loaded · fleet risk, loaded · heavily defended, skip — empty, scan first, can't hit, friendly.
Civil baseline compares the player against the server median of "how many ships a builder with this economy has"; the surplus is a combat-fleet ceiling. It deliberately does not feed the danger score — it is a separate, more cautious hint.
A complete set of scans (planets and moons) turns the fleet estimate into an exact number and drops the ≤ sign in the ranking.
The Watch via galaxy | probes toggle and the per-body toggle let you cut out of the scan plan whatever you do not want to touch with probes.
Fair play
Every hard number — defence, fleet, resources, loot — comes exclusively from spy reports you opened yourself. The dossier does not acquire them: it remembers and organises them so you do not have to keep a notepad. The rest is arithmetic over public points and over your own browsing of the galaxy.
The dossier is a reading room: it holds no send button. The only thing you can "fire" from it is marking a body as due for a refresh — the probe itself you send deliberately, from the game.
From activity markers you see anyway, Spyglass reconstructs an opponent's day and weeks: when he is usually at the game, and when he is reliably away.
Routine and presence: the player's day with its activity peak, the coverage verdict and the week grid with offline windows.
How it works
The galaxy view and a spy report show one thing: how long ago something happened on that body. OG-E converts that age into a point in time and, after a few dozen such points, draws the player's day and names his peak — for example evenings 19–23. Markers caused by your own probes are subtracted, and several looks at the same session count as one.
The second block looks for silence, not movement: a quiet look with good coverage is strong evidence of absence. An offline window is only declared once three consecutive hours have both enough looks and consistent silence — otherwise the page says plainly "look more often". The same data can be viewed as weeks, as a day, as day×hour or as a monthly cycle, and a separate detector checks whether the player rotates shifts.
Why it exists
This is the difference between "I know he has a fleet" and "I know when he is not watching it" — and that difference is exactly what decides whether a raid pays off. Instead of guessing from a single report you get the opponent's rhythm, and when the sample is too small, honest information that nothing follows from it yet.
More details
The peak of the day is the best five consecutive hours; its name (nights, mornings, afternoons, evenings) comes from its middle. Below three observations there is nothing, and on a small sample only a "hint" without a label.
An offline window requires at least three consecutive hours, each with real coverage and practically no traces of activity. A one-off blip in the middle does not invalidate the window, but it is listed separately.
The shift detector needs at least five weeks with a recognised phase — on a smaller sample it says plainly "too thin". Weekends are judged separately (some people are only at the game every other Saturday).
The analysis range switches between 30d, 90d, 6mo and All, and days can be narrowed to Mon–Fri so the weekend does not blur a work rhythm.
In the grid a lighter cell means "few looks", not "quiet" — coverage and result are kept apart so missing data never looks like a conclusion.
Fair play
This block is purely passive and purely computational: it counts only the markers the game itself drew on pages you opened anyway. Zero probes, zero extra requests, zero timers — nothing "watches" for you in the background, and without your browsing of the galaxy the history simply does not grow.
Markers caused by your own probes are subtracted, so you do not measure your own rhythm. The page also does not pretend to knowledge it lacks: "activity" is the last interaction with a body, not an "online" status — and it is labelled that way. As long as the sample is too small, OG-E refuses to state a conclusion instead of drawing a chart anyway.
History is kept as an hourly "present / quiet" mask per day — no coordinates, no report contents. That makes it mergeable across your own devices and (if you enable it) with alliance mates, and the merged material is view-only: it affects neither the danger score nor the scan plan.
Watches the systems you live in: it tells you who has just moved in next door, and which neighbour already keeps a fleet inside several of your systems at once.
Home watch1 new
Moved in (1)NEW clears itself a day after you read it
NEW2:143:4WrenD 0.31seen 8m ago
KestrelNOVA×32:117·2:119·3:301
NEWWrenNOVA2:143
BoroKRAB2:117
Tanhil2:117
IlexKRAB6:104
Together — NOVA reaches ×4 of your systems, ×3 for its best member alone.
16 own systems · 11 with no neighbour · 1 look stale
edge colour = Danger · ×N = in N of your systems · lit tag = their alliance reaches further together than alone
The real OG-E component, rendered over invented data (nicknames, tags and coordinates belong to nobody). Row edge colour = Danger, ×N = how many of your systems that player sits in, a lit tag = an alliance that reaches further together than any of its members alone.
mockup / screenshot: card
The Home watch card on the Spyglass tab — a fresh arrival, one row per neighbour, and the alliance-coalition line.
How it works
Every look you take at the galaxy is compared with the previous one — and if somebody new has appeared in a system where you keep a planet or a moon, you are told once. Your own systems join the Spy button's "Look" plan on their own cadence (24 h by default, 0 = off): a neighbour does not move, somebody has to colonise first, so checking hourly buys nothing.
The card lists actors, not addresses. One row per neighbour: colour = their Danger, ×N = how many of your systems they already sit in. That second number is the escalation it is easy to miss — an account with a fleet in three of your systems can run a moon destruction on its own, in three places, with no travel time to plan around. Listed separately: alliances whose members together reach further than any of them does alone. Two people with the same tag in one of your systems is not an escalation (the reach is the same as one of them); four of your systems covered between them is.
Why it exists
Your neighbourhood is the one thing the highscore never shows: a hunter one system from your moon has no travel time at all, and sees your bodies in the galaxy view every time they open it. Home watch turns that into one sentence at the right moment — "the fleet-save you have been flying for months is no longer safe" — instead of something you learn from a combat report.
More details
The Home field in the Spyglass settings is hours (0 = off). 24 h by default — separate from Re-look, which is about watched players.
The first look at a system produces no arrivals — it only seeds the baseline. Otherwise day one would report a dozen "new" neighbours and teach you to ignore the alert.
Departures are not reported: a neighbour who left is good news, and the galaxy view cannot tell "abandoned" from "I looked at the wrong moment".
The same player in another of your systems is fresh news (their ×N grows). A second planet in a system they already occupy is not — they were already inside.
The Spy button points you at the dashboard only once the sweep of all your own systems is complete, and only when there is something to read. One tap, and the nudge retires itself.
Fair play
The observation is your own visit to the galaxy view — nothing is initiated in the background, there is no timer and no polling. The whole feature is a comparison of what OG-E already recorded from your browsing: who was in the system then, who is there now. It holds no in-game action and never proposes an attack — this card answers a defensive question only.
Nothing watches for you: if you do not open the game, you are told nothing, and that is by design. There is no phone notification, no sound, and no reading of hostile fleets outside the game tab. The baseline (the memory of "who lived here") is device-local and is never uploaded or shared.
Your own alliance and your buddy list are excluded by definition — they are company, not exposure. The NEW flag clears itself a day after you read it; there is nothing to click and nothing to acknowledge.
Every body of every watched player plus your own on a single galaxy grid — with rings around those who can reach you in under eight hours.
The position map: galaxy rows, a dot per body, size growing with danger, your planets in white.Player chips under the map and the "who can reach you in ≤8 h" toggle — colour, hiding, entry to the dossier.
How it works
The grid is the server seen from above: rows are galaxies, systems run horizontally, and vertically within a row — the position inside a system. A dot is a body; it grows with the player's danger, and you assign the colour yourself so you can recognise your regulars. Your planets are white. Hovering (on touch, the first tap) gives the name, coordinates and estimated flight time to your nearest planet.
The who can reach you chip computes, for every foreign body, the shortest distance to any of your planets — with map wrap-around per the server rules — and converts it into flight time for the slowest possible attacker. So a ring means: this player reaches you within eight hours even with his heaviest, slowest fleet. The threshold is deliberately pessimistic, because a faster fleet arrives sooner.
Why it exists
"Who is dangerous" and "who is dangerous to me" are two different questions. A player at the far end of the server with a monstrous fleet is a theoretical problem; an average one three systems away is a practical problem. The map answers that with geometry you read in a second — useful for planning a fleet-save, for picking a target, and for deciding where to put your next colony.
More details
The map holds only your bodies and players from the watch list — not the whole server, so the drawing stays readable.
The eye next to a chip hides a player from the map without unwatching him; the cross ends the watch entirely.
The colour chip is the one place where you set a player's colour — the same one then shows up on his watch-list card.
On touch, the first tap describes the body, the second opens the owner's dossier.
Fair play
Body positions come from the public server map — the same file community tools use. The map is therefore complete from the first run and needs not a single scan. Flight times are arithmetic over the game's published rules.
The map sends nothing and pokes nobody — it is a drawing over data that is public anyway, plus your own coordinates from the game. There is no in-game action here, not even an indirect one.
A table on the messages page showing who has recently probed your planets — the freshest and closest at the top.
mockup / screenshot: panel
The "Who is spying on you" panel at the top of the Spy tab, above the AGR overview.
mockup / screenshot: same-system
A row flagged as a threat from your own system — at the top of the list.
How it works
On the messages page OG-E gathers "hostile fleet near your planet" alerts into one table: one row per spy, with who, how long ago, how often and from where they poke you. The freshest and closest threats are at the top, and a spy with a fleet in your own system is flagged separately (they reach you the fastest).
Why it exists
OGame scatters "who probed you" across individual messages that are easy to miss. The table answers one defensive question — is someone interested in me, and how close are they? — before it turns into an attack.
Fair play
The panel is purely presentational: it shows alerts you opened yourself during normal play. It initiates no click in the game, sends no requests, and has no timer or notification outside the tab.
It is the same knowledge OGame already showed you — just gathered into one readable table instead of scattered across messages.
Alarm clock & fleet-save1 feature
A fleet-return alarm you set yourself. The only knowingly borderline feature — we say so openly in its fair-play section.
A reminder you set yourself for a fleet return — it rings on your phone at the time your own send-off determines.
mockup / screenshot: badge
The clickable alarm badge in a row's arrival-time cell on the event list.
mockup / screenshot: wave
A wave of returning expeditions controlled as a single series.
How it works
On the game's event list every fleet row gets a small, clickable badge in its arrival-time cell. You tap it to arm a reminder relative to that flight (e.g. the moment a fleet-save returns), and a second tap removes it. Waves of returning expeditions are detected and controlled as a whole — one badge for the whole series.
The push is queued on ntfy.sh (a notification service you configure yourself with a token in Settings) with a delivery time computed from your send-off. ntfy holds and delivers the message at the appointed hour — after you set the reminder OG-E keeps no watch.
Why it exists
A fleet return or the end of a fleet-save often lands in the middle of the night or the middle of a workday. Instead of doing the math in your head and coming back over and over, you set one reminder and your phone speaks up exactly when the fleet lands.
More details
A fleet-save is detected and scheduled automatically; a slot can only be cancelled inside its cancel window just before delivery.
Configuration and tokens live in the OG-E Settings panel; without an ntfy token the alarm sends nothing outward.
Fair play
Honestly: this is a borderline feature. We treat it with care and say so openly — below is why we still consider it defensible.
We say it plainly: this is our one knowingly borderline feature. That is why we keep it on the safe side and constrain it harder than the rules require.
It is a player-set reminder for one specific send-off — not an automaton reacting to in-game events. The ring time follows from your own action (your send-off), not from monitoring the server.
It is presence-gated: only ever armed while you are present in the game. OG-E does not watch the game on your behalf while you are away — no page reload, no reading the event list for hostile fleets, no audio, no blinking tab title, no system notifications.
OG-E reads the arrival time passively from the event list the game already renders — with no traffic to the game server. The push itself travels through ntfy.sh, a service you configured, off the game's channel.
Dashboard & analytics3 features
OG-E's own panel: best colony spots, patrol, routes, statistics and a view of the data collected during normal play.
A card on the Spy tab watching your grounds: what is catchable to strike right now, and whether your observation coverage is healthy.
mockup / screenshot: card
The Patrol card on the Spy tab with the strike list and coverage summary.
mockup / screenshot: watch
Promoting a neighbour onto the watch-list with a single "star" tap.
How it works
Patrol treats your colonies as a coverage lattice and looks at every system within ±a few systems of your bodies (same galaxy, honouring the map wrap). The card answers two questions: what is catchable right now in the grounds (the strike list — the same signals the Spy OG-E button flags) and whether coverage is healthy (how many systems have a fresh, stale, or no look).
A neighbour on the strike list is promoted onto the watch-list with one tap (patrol → star → snipe). The card only shows while a patrol radius is set — at zero there is no UI at all.
Why it exists
The watch-list is the sniper's tool — one player, worked over. Patrol is the territorial predator's: the prey is whoever nearby slips (a returning fleet-save on a forgetful neighbour's moon), not a name hunted for months. The card shows whether the grounds are actually being walked.
More details
The patrol radius (in systems) is one knob, set on the Spy tab; 0 = patrol off.
Noise filters strip out self, vacation/banned/admin, buddies, your own alliance, and noob-protected players.
Fair play
Everything stays passive and propose-only. Patrol looks are your own galaxy browsing (undetectable), and a strike is still one deliberate tap per probe — OG-E sends nothing itself, it initiates a native click in the game's galaxy view.
The card is computed from data OG-E already holds — your scans and the public API read while a game tab is open. The grounds are a finite set of systems, so recording is bounded by nature. The card sends nothing; it only shows intel and has no "send-all" control.
A Dashboard editor for daily micro-fleet routes — define once where from, where to and with what, and Daily Run walks you through them in-game.
mockup / screenshot: editor
The routes editor in the Dashboard: sources, target list, fleet and mission.
mockup / screenshot: stale
A target flagged as "stale", removable in one click.
How it works
In the Dashboard you build transport routes per universe. A route is one or more source bodies (planets and/or moons) sharing one ordered target list, one fleet (ship + count) and a mission. A route can be paused with a toggle without deleting it.
Own-body sources and targets are picked from the list of your planets and moons (captured in-game), so a coordinate can never be mistyped; external targets are typed by hand. The same per-universe keys are consumed in-game by Daily Run, which then walks you along the route.
Why it exists
A daily fleet-save across many bodies is a tedious round. Defining the routes once in a readable editor turns the daily ritual into clicking through a ready-made plan instead of retyping coordinates from scratch every day.
More details
Own-body endpoints missing from the captured inventory are flagged "stale" and removable in one click; external targets never go stale.
Saving is debounced and flushed on universe switch and tab close, so your last edit is never lost.
Fair play
It is a pure configuration editor — it saves your routes to the extension's local storage. It does not contact the game server, sends nothing, and schedules no background send-off.
Own-body targets come from the list of your planets the game already shows. The actual send-off happens later, in the Daily Run feature, and always through a native click after your tap.
Save the selected universe's whole dataset to a JSON file, load it back by merging, and dump the colony history to CSV.
mockup / screenshot: buttons
The Export / Import / CSV buttons in the OG-E Dashboard.
mockup / screenshot: summary
The import summary: how many entries were added in each dataset after merging.
How it works
From the Dashboard you export the selected universe's data to a single JSON file and import it back. Import does not overwrite wholesale — each dataset is merged with the same reconciler as gist sync: additive, local-first. An Export → Import round-trip behaves exactly like a gist download.
Separately you dump the colony history to CSV to open it in a spreadsheet. Everything goes through local files (Blob) — the module never touches the network.
Why it exists
A backup, a transfer of your data to a new device without configuring a gist, or working the colony history in a spreadsheet — with no cloud and no account. You hold the file, you decide where it goes.
More details
The watch-list import rides its own LWW+tombstone merge: an un-star in a newer file propagates, exactly like sync.
The file carries only extension-storage data; per-universe settings stored in the game's localStorage remain gist-sync-only.
Fair play
Import/export is local only: no fetch, no contact with the game server or any other. Downloads go through a Blob, and loading reads the file you point at yourself.
The file is safe to hand over: secrets (the GitHub token, the ntfy token) and sync bookkeeping never enter it. It is your own data, gathered by normal play, packed into one file.
Sync & community1 feature
Your data across devices, plus sharing and joining shared activity — with no background game tracking.
Your collected data (galaxy scans, colony history) travels between your computer and phone through your own private GitHub gist.
mockup / screenshot: settings
The GitHub token field in OG-E Settings — sync is opt-in.
mockup / screenshot: merge
Two devices see the same current data picture after merging.
How it works
In Settings you connect your own GitHub token (a classic PAT with the single gist permission), and OG-E keeps your locally-collected data in a private gist that belongs to you. Every device pushes and pulls through api.github.com — nowhere else.
Merging the two sides is additive and local-first: on a pull, remote entries are added to local (the newer scan wins), nothing is wholesale overwritten. Uploads are debounced by a 15-second window, so a burst of scans while scrolling the galaxy coalesces into one upload instead of a dozen.
Why it exists
You play on several devices, and the knowledge gathered by normal play — scan classifications, colony observations — drifts apart between them. Sync means every device sees the same merged, current picture after boot, with no manual transfer.
More details
Secrets (the GitHub token, the ntfy token) never enter the synced file or an export.
On GitHub rate-limit errors (403/429) the module backs off and does not hammer the API pointlessly — it stays inside GitHub's 5000 req/h budget.
Fair play
Sync never contacts the game server. All traffic goes to a service you control (your GitHub gist), off the game's channel. That is OG-E's position in the terms of service: we only read game pages rendered in your own browser, and your data syncs through a separate channel.
It is entirely opt-in: with no token pasted by you, nothing leaves your machine. The token holds the smallest possible permission (gist) and lives locally. Only your own data, gathered by playing, is synced — there is no background game tracking.