TeamKind
A Minecraft Bedrock server project: survival and mini-games on one instance, a shared account and economy across instances, and a heavily modified server core.
Stack
- PHP
- PocketMine-MP
- Guzzle
- Slim
- MySQL
- SQLite
- Redis
- WebSocket
- nginx
- JavaScript
Problem
Before TeamKind I ran the community of a large Minecraft Bedrock Edition project. I could see which complaints kept coming back and what players were missing, but I had no way to act on any of it. I wanted a project where development follows that feedback, where paid privileges add options without turning into pay-to-win, and where survival, SkyWars and FastBuilders behave as one system rather than three separate products. The technical side did not come for free: on our configuration and core version plain survival started losing TPS at around 70–80 players, and the project had to hold several worlds and the mini-games at once. Abuse through crafted network packets was a problem of its own.
Solution
Players always come in through a lobby, which checks for a live session and sends them to their pinned instance, or a newcomer to the least loaded one. Each instance runs survival, SkyWars and FastBuilders together. Moving into a mini-game happens inside it: the inventory is saved, prepared for the mode and restored afterwards, and the player is never handed off to another server. Account, privileges, currency and cases are shared across instances, while homes, claims and anything else tied to a map stay local to it. To support this, I developed and reworked my own version of the server core, adapting it to handle high load, run several game modes and close vulnerabilities.
Architecture
Key technical decisions
- A core fork of our own. Upstream PocketMine-MP was no longer officially maintained by then, and the base core did not cover what the project needed, so I reworked it substantially for the load, the stability and the game mechanics the project required.
- Mini-games inside the survival instance rather than on separate servers: the inventory is saved and restored, there is no reconnect, and SkyWars never feels like a different product.
- Account, privileges, currency and cases shared across instances while map-bound data stays local: what you bought works everywhere, but homes and claims stay bound to one map.
- One account, one live session: it cannot be in play on two instances at once. Moving to another instance means ending the current one first.
- Controlled restarts: before an update the server winds activity down properly instead of cutting players off mid-game.
The media below comes from the product itself, so interface text and any audio are in Russian.
A Minecraft Bedrock Edition server project that combined full survival with SkyWars and FastBuilders.
The core
Individual instances held 180+ players at once. The core was substantially reworked for the load the project carried.
TeamCore is a heavily modified fork of the server core, with substantial changes to performance, network security, world and chunk handling, and game logic. After that work the core held up better under load and matched what the project needed. Those changes made TeamKind one of the first Minecraft Bedrock Edition 1.1.X servers in the CIS to run full survival and SkyWars on one server, at a player count that was high for that core. It also allowed a long list of custom commands and mechanics to be added without losing stability. One stable version of this core is available here.
Overview
Account and authentication
Players used a single account across all of the project’s servers. Passwords were first hashed with SHA-512, using a per-password salt and an additional server-side secret that was never stored in the database. After several months that scheme was replaced with bcrypt, which is slow by design and so better suited to passwords. Once a player signed in, the session was kept, so moving between servers didn’t mean entering the password again.
The donation store and payments
The donation store was tied into the project’s shared account system: the buyer entered their in-game nickname, the store checked for a registered account with that name and linked the purchase to it. Payments went through integrations with several external payment providers, covering bank cards, e-wallets and other methods. Items, currency and privileges were tied to the account rather than to a server, so they worked on any server and in any mode. The store had product categories and order tracking.
Paid perks without pay-to-win
Paying was never meant to give anyone an edge over other players or a way to harm them. That is why, for example, items and resources could not be carried from creative into survival, alongside other limits that kept a balance between paid and free features.
Bonus questions
Bonus questions tied the game to the project’s VKontakte group. The question, its posting time and the reward were set on the server, and five minutes before the start the server automatically created a scheduled post with the question in the group. Players answered with /bonus on any server; the server checked the time and the answer and paid out if both were right.
Controlled restarts
Before an update, the server wound down running processes and mini-games properly, handed players their rewards and paused the related game scenarios. The restart only began once players had been warned and their current actions had finished, to avoid losing data.
Moderation
Moderators had tools for different kinds of rule-breaking: bans, temporary restrictions, disabling individual features and removing a player from the server. Moderator permissions were configurable.
Trading
Players bought and sold items to each other through built-in trading. The mechanics closed off the usual scams from both the seller’s and the buyer’s side. Particularly valuable items could not be listed at all, and the server took a 10% commission on each trade.
Game mechanics
Levels
Levels went up with time actually spent playing; idling did not count. They earned in-game currency, magic cases, privileges and access to particular features. Some of those rewards overlapped with paid privileges and bonuses, so active players earned them for free; a player who already held a higher privilege got currency instead of a duplicate.
FastBuilders
A mode for practising speed building: platforms were generated automatically, and the result was recorded and rewarded. Survival features stayed available as long as they didn’t get in the way of the drill.
Magic drops
Rare and valuable items appeared from time to time in designated areas of the spawn.
Vanish
Unlike the standard effect, vanish removed not just the character model but every other sign of presence: effect particles, footstep sounds, visible armour and interaction prompts. The /vanish list command showed moderators everyone currently vanished.
Other mechanics
The video shows a random task system with rewards and a disguise feature that let players change their nickname, prefix and skin in game.
Results
- A single instance held 180+ players at once.
- Survival, SkyWars and FastBuilders all ran inside one instance, without moving the player to another server.
- Account, privileges, currency and cases stayed shared across instances.
- The reworked core removed the original performance limit: before that, the configuration in use started losing TPS at just 70–80 players.
Metrics
- players online on a single instance
- 180+
Facts
- The project's most active player,
Wauder, spent 1,339.3 hours in game over TeamKind's final year; second wasSaid_123with 797.5 hours. - One stable build of the project’s own core fork, TeamCore, is still public on GitHub.