# Design basics for Unity game: sport management type

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?

• Are you familiar with the model-view-controller pattern? – Philipp Jan 30 '16 at 11:56
• 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? – rataplan Jan 30 '16 at 12:12
• I just wanted to know if I can assume you are familiar with the terminology when I write an answer. – Philipp Jan 30 '16 at 12:20
• Yes, thanks. I did write apps for iOS, but not games – rataplan Jan 30 '16 at 12:25

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.