So, this is it, the introduction page to "federation", a game based on Federated social networks. This means that everyone can host an own instance of the "federation" game server, connected to other game servers forming a big, distributed mesh in which the game takes place.

In order to get this running, a few things are needed: the actual game server consisting of an API. This is used by the game servers to communicate with each other. Another critical component is the client. This can be a simple command line program or more traditional like ui as used in almost all games. This is used by the players to interact with the game server.

My goal for this game is to provide a minimal prototype demonstrating the feasability of such a game. This might include some super simple mechanics, so that possible design flaws may be become visible.

Without futer ado, let's get into the mechanics of the game:


The mechanics of this game are fairly simple. Let's start by defining a setting, because this means that we can imagine stuff without actually needing to implement stuff: You are located in a tiny vesel floating throug space. There are only a few aspects that define you: Your position, your energy level and the money you own.

Using these three aspects, a fairly simple game can be built up. The goal of the game is to get as much money as possible. In order to do so, you must travel the galaxies, but this consumes energy, a limited resource. You can by new energy in every galaxy, but to increase the amount of money you own, you can "mine" energy from the star forming the galaxy (A bit weird, yes, but it keeps things failry simple).

Now in order to make money, you...

  1. Travel into a new galaxy
  2. Mine the star
  3. Go to the galaxies shop
  4. Buy Energy
  5. GOTO 1

The Galaxy

We've defined the galaxy a bit now, so lets harden the stuff a bit: A galaxy consists of a star, a market and a jump post.


The star can be mined. The result of mining is more energy in one's inventory (this might be limited). The amount of energy mined depends on the star and can be anything inbetween n energy / second and m energy / second (This still needs to be determined). A star has MAXINT Energy, so mining it until there is no energy left is unlikely.


The market can be used to sell energy. The price that the energy can be sold for depends on the star, so if mining the star is simple, the energy money exchange rate is low. On the other hand, if it is not so profitable to mine the star (low e/s), the profit of the market is high.

Jump post

The jump post can be used to jump to other systems. The owner of the system can connect the system to another one, by supplying the location of the other game server.

Game server

The game server has a few purposes, it provides a way to store the spaceships information. A spaceship is always stored on the server it is on and the "home" server, by default the server the player connects to the first creating a ship OR a server selected by the user. This makes it possible to make a feature out of the federated system: In federation, your ship might be on a server, that while the ship is on it, crashes or for some reason doesn't exist anymore. This could be because the other server might be shut down by it's owner, or because one of the owners decided to delete the link inbetween the server. The ship then resides in the galaxy that was "destoyed", but the player can still connect to the "home" server and start from new.

This all means that there must be trust that the servers exist, so the servers (or galaxies, used interchangable from here on) have a score, also knonw as their "uptime" determinig the stability of the system. When jumping to a system with a low or somehow degraded uptime, the player might be warned that "this galaxy seems unstable because of ..., do you really jump?".


The api is defines on the server side to allow one server to contact another server and so on. This means that the server gathers information on the other servers and does periodic healthchecks. The player using that server as a home server can use the information provided by the server in oder to, for example, find out where to jumps can be performed.


The client interacts mainly with the home servers api, and with the other servers apis. If a user mines something on a server other than the home server, the other server sends that information to the home server, so that the client can keep track of, for example, how much energy the ship still has.


In order to authenticate using the client, the client can login and export the login token, so that not every request must be authenticated.