Introducing a Development Blog about my Online Persistent-Universe Game

Hello. AGS9 is a game I'm developing. It will be online, single player or cooperative private games with a persistent universe that keeps on running even when you are logged out. The theme will be space exploration and survival, with stars to colonize and space dragons to defend against. The intention is to create a 4X/resource-balancing game that takes inspiration from the gameplay of Frostpunk and Master of Orion (of course), with the anticipation of classic web games like Tribal Wars for something that will happen in a few hours or days from now.

AGS9 is not intended to be PVP at all, at least not in my original design. I want to create a game that people with a full-time job can play and excel at, without 14 year old kids farming them all the time.

I decided to write down a development blog about my progress and the challenges I encounter and overcome. These writings come not from the first line of code I write, but after several iterations of different game and server architectures I played around with and learned what suits best for the game at this stage of development.

For example, I decided against running multiple microservices deployed with Kubernetes, either with a Stateful Set of game servers that host multiple games, or a crazy idea of a Pod per game instance. I examined a solution of a Godot client/server architecture, but having HTML5 as a target platform and reading in Godot's official documentation that HTML5 support is not that great, I dropped that project too. That idea included either multiple games per a Godot server instance, or a Pod for a single Godot server that runs a single game for a player. The latter case is interesting because it lets me develop the game regardless of infrastructure or any authentication logic, multiple games on a single server, etc, and I only need some API Gateway Server for Kubernetes to have my players authenticated and directed to the individual game Pods.

But I don't do any of that. It's an overkill in this early stage of the game development.

Did I mention there's no game yet? Only infrastructure? :)

Today, at the time of this writing, I understood that as a developer I tend towards building things with cool technologies instead of actually making a Product, in this case a game. I do know however, that I want to have a working end-to-end system, with login, user management, and a "skeleton game" online and running, before I iterate on the game itself.

When I know everything "works" from the client side login, up to the server which communicates with the client through WebSockets with pushes of "space dragons attack you" or "your ship is ready after 7 hours of building", I could start focus on the game design itself, and inviting users slowly so I can get early feedback and develop with the community accordingly.

It's worth mentioning that I intend to run the game under a very cheap subscription plan, just to keep the servers running and not to get rich or something like that.

Trying to make these posts not too long, I will write about the current "early development architecture" I chose in the next part of this blog.

Introducing a Development Blog about my Online Persistent-Universe Game

Comments (1)

My Single Player/co-op Online Persistent Universe 4X Space Game

Early Heroku and App Platform infrastructure, with some thoughts about letting you know when your colony ship has been built

More from this blog

Serverless.com project with Lerna and NPM workspaces

My Qwik app that authenticates with Spotify

Mytimer.cloud for the Appwrite hackathon, June 2023

A POC for a Go game server hosting long-running Lua games

Adding touch pan and zoom controls to a Phaser game

Command Palette

Comments (1)

My Single Player/co-op Online Persistent Universe 4X Space Game

Early Heroku and App Platform infrastructure, with some thoughts about letting you know when your colony ship has been built

More from this blog