This describes how minigames are implemented, along with security, events, and rules.

This is sub-layout for documentation pages


1 Definition

Minigame is an in-game activity. Consists of a lobby, and actual minigame instnce. Players can connect to a lobby, and when enough players are in lobby, the lobby is cleared, and a minigame instance is created.
Mingames can defy or override traditional game rules.
Point of a minigame is a competition bettween players / player teams.
Minigame lasts some time \(T\), which can be defined by time constant, or is dependent of game status / score.

2 Lobby

Minigame lobby is located in any map, and player may enter the lobby by clicking on door / barrier.
Different lobbys can have different rules and setup, which is dependent of the minigame they belong to.
Regardless the lobby / minigame, all lobbys always do have some properties, which never change. I call them axioms of lobbys, and are explained below:

2.1 The axioms of lobby

Let \(L\) be a minigame lobby.
Let \(R\) be a set of rules for a minigame lobby. (in human language, imagine is as rules when you can enter. For exmple, you can not have any items with you and your level must be atleast 2)
Let \(P\) be a player in the same map as L, and is alive.
\(P\) satisfies \(R\) only and only if he does not violate any rule in \(R\)

Then all following applies:

3 Minigame

In order to make minigame working, it must be correctly setup.
The minigame setup can be described (but is not limited only to) following points:

3.1 The rules / setting / overrides

Each minigame has some rules / settings, which are described by a class.
If no rules are specified within the code manually, the default ones are used.
The idea is, that if player is in a pvp minigame, and if he would die, then, by the rules of the game system, he would respawn in basic map, without any items, at all.
This is unwanted, as we need the player to respawn within the minigame map, and maybe we do not even want him to drop any item at all, because of the specific minigame.
For that, we use setup, and that will override general game engine behavior for all payers inside the minigame. When a player leaves the minigame, the Minigame orchestrator will revert these flags to default for that player, restoring the default rules of the game.

If you miss, forget to call the rule revert in the minigame orchestrator, or you forget to call the event on a minigame orchestrator, when player disconnects, THEN SECURITY IS COMPROMISED, behavior is undefined, and you can throw all the game to trash because you made serious unrecoverable mistake!

3.1.1 Example

Here is an example of rule / settings setup in code:

    new MinigameSetup().
The effect on he game rues is following (considering only players in the minigame): Ofcourse, there are more overrides and settings...

3.2 Internal representation

This describes the internal representation of a minigame
We start off with a diagram, which depicts the nested structure for a map:

It is worth saying, that normally, no minigame instance exists, but it can be created, once player connects to a lobby.
It is only possible to connect to a minigame lobby, only if there exists an item in the map (door / barrier), that allows that.

3.2.1 The infinite recursion paradox exploit
There might be a posibility how to cause infinite cycle, and here is how. Later, I will explain how I patched it and why it is never ever possible to happen.
Requirements: Exploit: Now, this is only a theory, and you can see, it is insanely complicated. The problem is, that the behavior depends on user input.
Countermeasurement: Now, it is literally impossible to exploit the recursive structure in any way