ABOUT THE GAME

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

Current system was designed with the following basic setup

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.

 Player should be a OnetoOne profile to an auth.User

 A ‘Team’ has a m2m of players as multiple players can be on different randomized teams, and a
team could be of different game types.
 Teams need to be able to have extra fields related to a Match such as ‘team_number’
 Team’s will need to have static items that don’t change such as Team Logo, Team Name
 Players need to be able to have extra fields related to a Match such as ‘slot_number’
 Design must be friendly to be able to get win/loss/draw statistics. There is a custom point
system based on match outcome.
 Statistics will need to be able to be put out on occurrences of matchups of “lanes” between two
players. (Laned most often, most wins with lane etc).
 Statistic rollups will be done on a Player level, as well as a Team level.
 Reverse relationships where possible. `Player.matches`, `Team.matches` etc.

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:

And that is where I am currently. I like my old setup that was Team centric, with winning_team etc, but I
do not know how to be able to easily incorporate Player Slot numbers in that model, even if I use a
Through Model. Looking for advice on overall structure given the above requirements.