I am running everything off of DigitalOcean's Kubernetes stack. It is not the cheapest, but I am very familiar with it and it is reliable. Here are the costs, broken down into each part I need:

For the initial launch a lot of services have free tiers that keep the cost down. As the game grows I can increase the spend on these $0 line items without changing how anything runs.

There are other bills that don't appear monthly but do impact the cost of running this game. Setting up a business, accounting, and taxes are all real costs too. I also need to hire an artist to create all of the in-game assets I need as well as a lawyer for everything legal. These haven't been priced out yet but when they are each will easily run into the thousands. The biggest cost is my time, which is difficult to put a real number on. Hundreds of hours put into developing this, all for $0, at least until the game is a success.

What does this look like for the break-even math? Well, a season's subscription is $12. After Stripe takes its cut, that works out to slightly less than $2 a month per player. Which is why I have targeted about 80 players on seasonal servers as what I need to cover the game's expenses.

The point of talking about this is to show that running a game like this doesn't have to be expensive. An 80-player goal is achievable and means I can keep the game running without adding microtransactions or relying on whales. A subscription-only MMO is possible at this scale.

The first is abuse prevention. Browser-based games have a well-known multi-account problem. Creating a free account costs nothing, which means creating ten of them costs nothing. Players will do it to grief others, spy on enemies, or even field an entire fake guild to compete against real ones. This can lead to real players quitting, which makes servers smaller and worse. Having a subscription doesn't eliminate the abuse, but it does raise the cost of doing it, which reduces the number of multi-accounts.

The second reason is simpler. The game needs to pay for itself. There are server and service costs that need to be paid, and I have no external funding. My estimates say that at launch, roughly 80 paying players cover the cost. That's an achievable number.

The third reason is that I'm opposed to pay-to-win mechanics. Mixing free-to-play accounts with paid accounts effectively means the paid players are paying to win. A subscription that everyone has to pay keeps all players on equal footing.

Charging upfront limits my audience, so here's what I've done about that. The training server is free. It's designed to give potential players a feel for the game before they commit to paying anything.

I am also building a referral system where a current player can give a one-week trial on a live server to someone they want to recruit. This helps the community recruit new players, and recruits brought in this way are likely to stick around longer than someone who signed up cold.

I'd rather run a smaller game that respects its players than chase numbers and watch the design fall apart.

Food is not a usual resource in these kinds of games. Resource management systems can get tedious fast. Adding another number for players to worry about doesn't make a more interesting game. So I needed a good reason to add food to Nebula Control.

Food is there to remind players that empires need more than the best production astros to function. It shouldn't be something players are constantly thinking about.

Here's how it works. Every astro has a fertility value that varies by type and orbital position. An astro may be rich in credits or production capacity but have poor or no food production. Others won't be as rich but can produce a large amount of food. Targeting only high-production astros will cause a player to run into food deficits as they grow their empire. They will need a high food-producing astro at some point.

Food is stockpiled as an empire-wide resource. All consumption is pulled from that stockpile. This keeps the resource something that sits in the background most of the time.

That changes if you expand too fast, or your breadbasket astro gets attacked and you run out of food.

When you run out of food you enter a Shortage, which cuts construction, production, and research capabilities by 25%. If the Shortage lasts for 24 hours then your empire enters a Famine and those penalties increase to 50%. After another 48 hours of Famine, your empire enters a Crisis and those penalties increase to 75%.

These tiers give players a warning and a chance to correct the issue before the huge penalties hit.

Right now this is how food works. If testing shows food still isn't important enough, I have a backup plan: fleets would consume food.

That would both limit fleet sizes and tie food directly into combat. Players would need to plan their food production around the fleets they want to maintain, not just their empire size.

If food has to matter more, I'd rather it matter in combat.

How Occupation Works in Other Games

In the same browser game I wrote about in my first post, you can have your bases occupied by other players. Being occupied reduces the base's income by 30%, slows fleet, building, and research production by 30%, and cancels any incoming trade routes.

This can hurt, but isn't game-ending. The real issue is that the 30% income lost is transferred to the player occupying your base. On top of that, they can pillage the base every 24 hours, earning extra credits and pulling some of that directly from your reserves.

This creates a real incentive for players to permanently occupy other players' bases. Being permanently occupied is a huge driver of players quitting the game.

Why Fighting Back Doesn't Fix It

Now you can fight back with your own fleet, get guild members to help, or wait for the occupier to leave. But they can come back at any time and reoccupy the base, regaining the hourly income and ability to re-pillage the base every 24 hours. It doesn't help that the base's defenses recover slowly, so retaking the base is easier than the first time.

If you do manage to get them off your base, it doesn't instantly recover. Fleet, building, and research speeds all jump back up right away, but the base's income trickles back so slowly that full recovery can take over a week. Trade routes are locked out for 24 hours after the initial hit, and defenses take days to recover fully.

What I Changed

The system I built to replace occupation is called Disruption. The attacker no longer gets any ongoing income from the base, but they still get a one-time credit pillage. Afterwards, instead of being occupied, the base enters a Disrupted state. The base is disrupted for 8 hours, not weeks. When that time runs out, your base comes back to full function immediately.

After disruption is over, your base enters a 24-hour immunity period where it cannot be attacked again. This gives the defender a chance to build up more defenses or station defending fleets, but most importantly, some breathing room.

Eight hours is the starting number. Alpha will tell me whether it should be longer or shorter.

The Goal

The idea isn't to make being attacked painless. It should still hurt, and attackers should be rewarded for well-timed, well-planned attacks. The idea is to give defenders certainty: a clear timer on when their base recovers, and the knowledge that the damage is temporary.

The mechanics of that game were ok, building a base and watching your numbers go up was a nice dopamine hit. Combat in the game was well balanced and felt satisfying. But when you play a game for this long you start to notice issues and gaps. Servers that stagnate as players quit. Combat losses that turn into weeks-long income drains. Coalitions that grow until nobody wants to fight anymore. I dive into each of these in later posts, but seeing them is what pushed me to build.

Through these tools, especially the rank history and server stats, I could see trends in the game. As servers got older, players would quit. Most servers lost 40%-45% of their players in the first six months. Then coalitions would grow until the server stagnated. Players would happily grow their empires until the next server started or if they had already quit, wait until the next server to start again. The game itself received very minimal updates, sometimes years apart. None of them did anything to address the decreasing population or issues with the game.

Over this time I had been slowly collecting notes and ideas on ways to improve this game. Most ideas got tossed once I really thought them through, but the ones I kept felt good. The player population kept declining. The game developer's updates were not bringing enough players back. So it was time to take a chance and make my version of this game.

I took these loose ideas and started building. The goal: create the game I want to play and avoid the issues I had noted over the years.

Sixteen years of notes finally became a design doc. The rest of these posts are what's in it.