Design basics for Unity game: sport management type

Question

I am planning the classes for my game; and I am having problems to figure out the best way to connect them.

In my game I do not have the classic structure of say a FPS; where you have the player class; with stats, and AI class with enemy AI. my game is more like a sport simulation manager type; so there are various entities:

• The player; which take over a team (or play in a team)
• The NPC: other players, managers, people that work in the club.
• The team (club) itself; where either the player take control of it, so NPC will join it, or will play in it, so the team will have both player and NPCs.
• Competitions: self explanatory; team participate in it.

I was thinking to make different base classes, one for team, NPC, player and competitions, but then I need to establish relations between them.

This look more like a DB with relation between tables, compared to a standard FPS game, where everything is strictly divided and you don't get class that "belong" to some other class.

I am using Unity BTW, so far I ahve the GameManager class; which initialize the main menu, the scene manager and UI manager.

Then I have 4 different class (player, NPC, competition and team), and this is where I am stuck. Should I create references to other classes, so when I instantiate for example a team class; then I will put in it a dataset to represent the NPC classes and the player class?

Or should they not know about each other at all, and all the interaction and logic should go in the gamemanager class?

Answer 1

The relations of your data-model (club has players, competition has participants...) are part of the model. Trying to represent these connections between entities in the controller will likely lead to a complete duplication of them.

It is often a good idea to try to keep the connection one-sided (either the club has a list of players or the player has a reference to a club).

First, this makes it far easier to enforce the separation of concerns. When a player switches clubs, which class is responsible for making sure the transfer is consistent: Player or Club? Do you call player.ChangeClub(club) which then internally calls club.AddPlayer(this) or the other way around? With bi-direction references this can be muddy. But when you only have one-sided references it is clear that the class which holds the reference has full responsibility.

Second, this protects you from creating bugs which cause the references from becoming inconsistent. To avoid the problem of the last paragraph, you could decide that references must only be updated by the controllers. But with bi-directional references it is possible that a bug in a controller causes inconsistent references: Club A says they own Player X, but Player X says they are owned by Club B. Because you have two ways to get player-club relations, that bug might not manifest immediately but only far later in execution. When that happens, you often can not easily find out how that inconsistency was created. Happy debugging!

This being said, enforcing strict one-sidedness of references can become difficult and inconvenient in the long-run. Depending on what operations you want to perform on your data-model, there might be cases where either direction is far superior. So sooner or later you might end up creating back-references even when you promised to yourself you won't. When that happens, remind yourself of the separation of concerns principle and which class you decided to be "the boss in the relationship".