ogame-vue-ts: an OGame-inspired space strategy game that runs entirely in the browser

A single-player remake of the classic OGame loop

ogame-vue-ts is described as a single-player, browser-based space strategy game inspired by the classic OGame game. The pitch is straightforward: build an empire in a galaxy, research technology, construct ships, and fight space battles, with everything running in the browser and every piece of data kept locally.

The README is explicit that this is a fan project with no affiliation to Gameforge AG or the official OGame game, created for educational and personal entertainment purposes, and that all game mechanics and design elements were reimplemented for those purposes. That disclaimer is also the scope statement. This is not a multiplayer client, it is not a server for a shared universe, and there is no leaderboard or alliance layer described anywhere.

The feature list is the part that shows the fidelity of the reimplementation. It covers building and upgrading structures on planets and moons, technology research, fleet management with missions and tactical space combat, defensive structures, an officer system for strategic bonuses, a battle simulator for testing a scenario before committing resources, a galaxy view for exploring and interacting with other planets, queue management for parallel construction and research, dark and light themes, and a probability based moon generation mechanic where moons appear in debris fields.

For a player, that is the OGame design reproduced at a level where the interesting decisions are resource timing and target selection rather than account management.

Progress lives in the browser, encrypted before it is written

The data story is the defining architectural choice. The README states that all game data is automatically encrypted with AES before being stored in the browser's local storage, and describes the result as private and secure progress.

The encryption is not decoration in the dependency list. The package.json includes crypto-js and the matching @types/crypto-js dev dependency, so the AES step is a real client-side transformation applied to the save before it is persisted, not a claim about transport security.

The persistence layer on top of it is Pinia with the persistedstate plugin, which is the standard Vue way to have store state survive a reload. Together they mean the entire game state, resources, fleets, research and settings, lives in one browser profile.

That has consequences worth weighing before you adopt it. State does not follow the player to another machine or another browser, and there is no account system to log into. The README does not document an export, import or backup command, so the only copy of a long-running campaign is what sits in that browser profile. For a casual player that is a fair trade for a game that needs no account. For anyone caring about a long campaign, the missing export path is the gap to think about.

Vue 3 with Pinia, Tailwind variables and a hand written i18n layer

The stack is conventional and worth naming precisely, because it tells you what you would be maintaining.

The front end is Vue 3 with the Composition API and the script setup syntax, written in TypeScript with strict type checking enabled. State is Pinia with the persistedstate plugin, routing is Vue Router 4, and the UI components come from shadcn-vue in the New York style. Styling is Tailwind CSS v4 driven by CSS variables, which is also the theming mechanism: the README says the application supports full theme customisation through Tailwind CSS variables defined in src/style.css, and that switching between light and dark mode is built in. Icons are Lucide Vue Next, animation comes from tw-animate-css, and tables use @tanstack/vue-table.

Internationalisation is described as a custom i18n implementation rather than a library, and the README links a translation set covering traditional and simplified Chinese, English, German, Russian, Spanish, Korean and Japanese, with the game also listed on TapTap. A hand written i18n layer is less machinery than a full library, but it also means translation coverage is maintained by hand and new strings need a translator rather than a plugin change.

A few other dependencies hint at what the game does under the hood: marked for rendering text, file-saver for exports, motion-v for motion, and @vueuse/core for composables.

One repository, four distribution targets

This is where the project goes beyond a typical web game demo, and it is also where the repository layout stops making sense until you see the build scripts.

The package.json scripts define the targets. The dev script runs vite on port 25121, the build script runs vue-tsc -b followed by vite build and then node update-build-date.js, and preview serves the production build. Beyond those sit build:server, which builds and then runs go build, build:electron, which sets ELECTRON_BUILD=1 and runs electron-builder, and build:android and build:apk, which go through Capacitor and finish with gradlew assembleRelease.

The Go part is a real component, not a leftover. The repository has main.go and go.mod, and the module declares go 1.25.4. The Go dependency list in package.json includes serve-static and finalhandler, which is the shape of a small static file server, so the Go binary is the self-hosted web server variant of the same game.

The desktop build is Electron, with an electron/ directory in the tree and the main entry point declared as dist-electron/main.js. The Android build uses Capacitor 8 with an android/ directory and capacitor.config.ts.

And there is a Dockerfile that builds the web app in a node:20-alpine stage and serves the result from nginx:alpine. The lines that matter:

FROM node:20-alpine AS builder
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN npm install -g pnpm
RUN pnpm install --frozen-lockfile
COPY . .
RUN pnpm run build
FROM nginx:alpine
COPY nginx.conf /etc/nginx/conf.d/default.conf
COPY --from=builder /app/docs /usr/share/nginx/html
EXPOSE 80

Note the source directory in that copy instruction is /app/docs, not /app/dist. The build output directory is named docs, which is unusual and worth confirming against your own build before you rely on the image.

Getting it running takes pnpm and one dev command

The documented environment requirements are Node.js, with version 18 or higher recommended, pnpm at version 10.13.1 or higher, and Go at version 1.21 or higher listed as optional. The optional part is Go, which only matters for the server build.

Installation is the usual three steps.

git clone https://github.com/setube/ogame-vue-ts.git
cd ogame-vue-ts
pnpm install

Then the development server:

pnpm dev

The README states that this runs on port 25121, and that you open http://localhost:25121 in a browser. That port also appears in the dev script itself, which runs vite with the port flag, so the README and the build configuration agree.

For a production build and a local preview of it, the README gives:

pnpm build
pnpm preview

The build script is worth reading closely because it does three things in order. It runs vue-tsc -b, so type errors fail the build, then vite build, and then node update-build-date.js, which stamps the build date into the bundle. The package.json records that same value in a buildDate field, currently 2026/1/23 02:22:24 for version 1.6.5.

Two rough edges in the dependency files. The repository contains both package-lock.json and pnpm-lock.yaml, while the documented workflow is pnpm and the Dockerfile copies pnpm-lock.yaml with the frozen lockfile flag. And the package.json sets private to true, so the project is not published to the npm registry and cannot be consumed as a dependency by another project.

Where this project stops being a good fit

Three boundaries are concrete.

The first is the licence. The README states that the work is licensed under the Creative Commons Attribution-NonCommercial 4.0 International licence, with the two permissions being share and adapt, and the two conditions being attribution and non-commercial use. GitHub cannot classify it automatically, which is why the licence shows up as a custom one. The practical effect is narrow but real: you may modify the game and redistribute it with credit, and you may not use it commercially. For a fan project that is the intent, and for anything you intend to monetise it is a stopper.

The second is that the game is single-player and local. There is no multiplayer, no account, no server-side state and no cross-device sync. If the goal is a shared universe, a persistent world or a game with other players in it, this project cannot be the basis, because the architecture has no place to put shared state.

The third is the release cadence. The last push was on 2026-07-03, and the recent releases are v1.6.5 from 2026-01-22, v1.6.0 from 2026-01-05 and v1.5.6 from 2025-12-26. The tag numbering moves in the sixth decimal place and the pushes keep coming, which is fine for a game people play on their own machine, but it means there is no stability promise if you were planning to pin a version in an image you maintain.

How a fan reimplementation differs from the browser game it imitates

The obvious alternative is the original OGame browser game that the README links and that this project is modelled on. The difference in approach is not cosmetic.

The original runs in a browser tab against a live server, with an account, a persistent universe and other players in the same galaxy. Progress is bound to that account and to the service. This project runs the same shape of loop entirely in the browser, with the save encrypted in local storage and no server in the path, so it works offline, it cannot be shut down from the outside, and the data is readable by whoever has the browser profile.

The second difference is licence and reach. The original is a commercial service. This is CC BY-NC 4.0 source code that anyone can read, fork and extend, provided the use is non-commercial and the author is credited. The trade is that the fan version has no support, no moderation, no economy maintained by a company, and no guarantee that the mechanics match the original exactly.

For learning, for modding and for playing without a subscription, the local implementation is the better fit. For a stable, social, always-on universe, the service it imitates remains the only real answer, and this project is a study of its design rather than a replacement for it.

Editorial conclusion

ogame-vue-ts fits a solo player or a learner who wants the OGame loop in an open codebase they can read, modify and run offline, and it does not fit a commercial product because the licence is CC BY-NC 4.0 and forbids commercial use. Verify first that your toolchain matches the documented Node.js 18 and pnpm 10.13.1 minimums, that the Docker image still copies the build output from the docs directory, and that the version in package.json matches the tag you intend to pin before you distribute a build.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. setube/ogame-vue-ts on GitHub