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?

  • \$\begingroup\$ Are you familiar with the model-view-controller pattern? \$\endgroup\$
    – Philipp
    Jan 30, 2016 at 11:56
  • \$\begingroup\$ Yep, I did the view as UI manager; which get events from the button clicks; and send them to the controller. The model hold the various names for the NPC, clubs and competitions as simple db object. Are you suggesting to make the classes beside the player class, as part of the model itself, while the controller will put together the relations between NPC, clubs and competitions? \$\endgroup\$
    – rataplan
    Jan 30, 2016 at 12:12
  • \$\begingroup\$ I just wanted to know if I can assume you are familiar with the terminology when I write an answer. \$\endgroup\$
    – Philipp
    Jan 30, 2016 at 12:20
  • \$\begingroup\$ Yes, thanks. I did write apps for iOS, but not games \$\endgroup\$
    – rataplan
    Jan 30, 2016 at 12:25

1 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".

  • \$\begingroup\$ Thanks for the reply. At this point make sense to have clubs holding reference to players, so only clubs can add players; while players has no context of the club, only a reference to it. The model though, it is not straight forward, since a player may start as free agent; or be created when a new season start (a youth promoted); and in that case it won't be linked to any club. I will have to think this further, but it is a good start. Thanks! \$\endgroup\$
    – rataplan
    Jan 31, 2016 at 7:10
  • 1
    \$\begingroup\$ @newbiez You could solve this by having a placeholder club "clubless" which participates in no competitions and only has the purpose to hold any players and NPCs with no affiliation. \$\endgroup\$
    – Philipp
    Jan 31, 2016 at 11:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .