Professional Documents
Culture Documents
The game is a Free For All (FFA) style game that can feature up to 8 players max, although it
could be less. Standard configurations are 1v1, 1v1v1v1, 2v2, 2v2v2, 2v2v2v2, 3v3, 4v4. Each team
number corresponds to a spawn position on the corner of a map. Each player’s slot position corresponds
if they are the north or south spawn in that corner.
Game dynamics, while an FFA, do have some baseline rules. Players have what are referred to as “lanes”
which is the opponent across from them directly. For this reason, even if its an FFA, you can almost view
this meta as a 1v1 between those two players.
CURRENT SYSTEM
Learnings:
Easy to query by team. Easy way to track winners and provide statistics without holding
win/loss/draw numbers in the db directly
Cannot rely on ordering of Team’s when queried. No ability to see team number.
Cannot get spawn position of Player. Hard to query players directly for matches. No
reverse relations.
Tying Player as an AbstractUser mixes too much with game logic and authentication.
REVISED SYSTEM
As part of these learnings, I’m looking at redoing some of the database structure. Below are the
following requirements.
My approach was to use an intermediate through model. An approach was taken such as:
The only issue is I’m not able to get easy reverse relationships here. The concept of a Team is only really
in the Roster class so Team stats for statistics would need to be calculated. I am running into issues with
on how to easily do this with minimum queries (matching on a m2m exactly). My plan is to enforce a
constraint that only one “Team” object exists in the database with the same amount of players and
enforce that in the admin/save logic. This worked for the previous attempt, but I am not sure if that
complicates things here.
Here was an approach I took on the Match class and Team class
The issue I see from this is the number of queries. Given the following:
So that will not work. I’ve then gone back and tried a redundant solution to putting both Player and
Team m2m fields on Match. This solves quite a bit, but it just doesn’t feel right. Players should be able to
be inferred from Teams, but the overlying question is how to then track both team_number for Team
and slot_number for Player on a Match by Match basis.
While this does seem to work, it creates complexity for creating matches and causes more chances of
some type of input error.