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

This is sub-layout for documentation pages

Top

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.

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:

• \(P\) can enter \(L\) only and only if he satisfies \(R\), and if he is not in \(L\), and other game rules allow the connection to the lobby
• If \(P\) is in \(L\) then he can not teleport
• If \(P\) is in \(L\) and he disconnects, then he is removed from \(L\) immediatelly
• If \(P\) is in \(L\) and he dies, then he is removed from \(L\) immediatelly

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:

• String identifier of minigame must de defined. That is used to reffer to minigame from code and from map file.
  Note: Why not ENUM? Because if you waant to reffer to a enum from map file, you must write a number, which is not telling much once you look on the map file as a human...
• ID of map, to which will the player returned upon leaving the minigame
• Position within the map, to which will the player returned upon leaving the minigame
• Set of rules (and overrides) \(R\) (or will be used default)

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().
        noItemsAllowed().
        noTeleport().
        minPlayers(3).
        hookPlayerDeath().
        setForbidEquipUnequip(true).
        setDropAllItems(false)
  

The effect on he game rues is following (considering only players in the minigame):

• If player dies, then he will respawn at map of ID relevant to the minigame
• Player can not teleport (as user input), but game core can teleport user, if neeed
• Player can not manipulate any of his equipment (as user input)
• When player dies, the minigame class is notified of that event
• When will not drop any items upon death. He will keep all of his items. Any skull or general game item drop count modifier is ignored
• If player wants to join the lobby, he can do so, only and only if he has no items in any of his inventory / equipped

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:

• Map \(A\) has object that allows to connect to minigame \(L\)
• Minigame has map \(B\) as a map instance
• By creator error, there is object that allows to connect to minigame \(L\), in map \(B\)

Exploit:

• Player \(P\) in map \(A\) connects to minigame \(L\)
• Player \(P\) in map \(B\) connects to minigame \(L2\)
• Minigame creates instance of map \(A\), as it is configured
• Now, map \(A\) updates, and child \(L\) updates. That updates child \(B\), and that updates child \(L2\). And \(L2\) updates map \(A\), theoretically causing a infinite cycle

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:

• We define, that any map, which is a child of any minigame, will have minigame manager disabled
• Disabled minigame manager never updates, nor allows anyone to connect

Now, it is literally impossible to exploit the recursive structure in any way