Generators SMP

Most Minecraft servers monetize badly. Vanilla SMPs and minigame servers sell cosmetics and soft perks — nice-to-haves bolted onto gameplay that doesn’t really want you to spend. A small genre solved this: the economy SMP, with DonutSMP as the benchmark. There, money isn’t a side-shop — it’s woven into the core loop, and the result is a category that monetizes a Minecraft server like a free-to-play game.

GenSMP is built to occupy that proven model at early-DonutSMP scale (low hundreds of concurrent players). The thesis is simple: the same loop that makes the game compelling — grind passive income, climb tiers, defend your wealth, show it off — is also the loop that sells. The job is to design that loop honestly and let the monetization fall out of it.

The flywheel

The engine is the crate — a randomized, lootbox-style draw. A subscription’s recurring value is the keys it grants; the rank itself only adds cosmetics and minor convenience. A free loop feeds the same prestige engine — vote or refer a friend → earn keys → unbox → rare pulls broadcast to everyone — so free players power the population and the social proof. Critically, the store sells draws and vanity, never raw power: the game stays fair, which is what keeps the free majority playing. The cost side stays lean — a cheap Hetzner box bridges today’s scale, escalating to a dedicated OVH machine only once player numbers justify it.

Three subscription tiers, sold through a Tebex store that auto-grants the permission group on purchase. The deliberate choice: a subscription buys you a crate to open and some cosmetic flair — never an edge in the game itself. Extra home slots and a few seconds off a teleport warmup don’t move the needle on fairness; the lootbox draw and the chat tag are what people actually pay for.

* Free players still earn Voting-crate keys by voting. Each paid tier claims its crate on a recurring cooldown — that repeat draw is the subscription’s real value.

The monetization only works if people keep coming back — so the core loop is paced with mechanics lifted straight from free-to-play mobile and idle games. A generator doesn’t earn forever: it fills a capped store over a few hours and then idles. Sitting full means leaving money on the table, so the optimal play is to return on a schedule and empty it.

That single rule — a ceiling plus a refill timer — is the same trick behind energy systems and crop timers in mobile games. It sets a natural session rhythm (log in roughly twice a day to keep everything productive), and it doubles as a balance lever: nobody banks runaway wealth by going AFK for a week.

None of this is incidental. Caps and timers turn a passive-income game into a scheduled habit, and daily-active players are the substrate everything else runs on: more sessions → more votes and social proof → more crate openings → more reasons to subscribe. The retention loop is what makes the monetization loop work.

Today it runs as a single tuned box — enough for launch. The scaling target is a proxy-fronted, multi-server topology built around Folia, the multithreaded Minecraft server. The whole architecture is shaped by one hard constraint, explained below.

Why Folia — the one constraint

Standard Paper ticks each world on a single thread. Add 15 more CPU cores and the world still advances on one of them — so a busy SMP hits a wall around 100–200 players no matter the hardware. Folia breaks the world into regions that each tick on their own thread, so a 16-core box finally does 16 cores of work. That’s why the target hardware (OVH 9950X) and the software (Folia) are a single decision: the cores only pay off if the tick parallelizes.

The leverage is in Phase 0: doing the scheduler migration now, while the plugin still runs on Paper, turns the eventual Folia switch into a jar swap instead of a rewrite. Front-loading the hard part is the whole strategy.

Every generator, sale, raid and listing is persisted. The data layer is small but was hardened by a real outage — and it’s where the most interesting performance work lives.

What’s stored

CREATE TABLE generators (
  id              TEXT PRIMARY KEY,   -- generator instance UUID
  type            TEXT NOT NULL,      -- dirt … netherite
  owner           TEXT NOT NULL,
  world, x, y, z,                     -- block location
  tier            INTEGER,            -- 1–10
  stack           INTEGER,            -- 1–16
  stored          INTEGER,            -- items waiting to be claimed
  lifetime        DOUBLE,             -- $ earned since placement
  protected_until BIGINT,            -- raid grace window
  post_raid_cd    BIGINT
);
-- indexes by (world,x,y,z), owner, type → O(1) lookups
-- writes are batched every 30s via flushDirty() → one commit, not N

The performance win — ticking only what matters

A passive-income server can accumulate tens of thousands of placed generators. The naïve loop ticks all of them every second — and it did, until it didn’t scale. Now generators are indexed by chunk, and each tick only touches the chunks that are actually loaded:

Same idea throughout: O(1) lookups by id and location, an auction purchase that claims a row atomically (UPDATE … WHERE status = 0) so a crash can’t double-spend, and a 30-second batch flush that collapses thousands of tiny writes into one transaction. Capacity knobs (max-players, simulation-distance) are tuned against spark profiles, not guesses.

All of the above exists to serve one loop: