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
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!
Here is an example of rule / settings setup in code:
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.
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\)
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.
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