1
\$\begingroup\$

I'm not quite sure right how I should create my "Team System". Lets say I have 2 teams with 4 players in there. The teams are Team Blue and Team Red. A team knows the amount of its members, the amount of its points (each team will have points which the players gain for the team) and maybe some details for the HUD.

My solution right know would be to create parent class Team with the childs TeamRed and TeamBlue and add the players to the teams. (it would be also great to get a player's team through the player -> Example: Player.GetTeam() == TeamBlue?

But since Team red and blue are actually quit similiar and only have different HUD settings, I'm not quite sure about this design. Another possibility would be to just have a class Team and create the objects Team teamRed; & Team teamBlue;

what do you think guys? any better solutions?

\$\endgroup\$
4
\$\begingroup\$

Take the following relations into account

  • A team has players
  • Team Red is a team
  • A player is associated with a team

So, the following approach should give you a good hint.

Team Red and Team Blue are instances of a team, with the same attributes but they just differ in values. Unless you need to implement different behaviors (member functions) for each team, you just need one Team class with an array/list for storing players.

Each player could have its team assigned as an enum, number, or pointer variable. It's up to you.


Why do I suggest this approach? Imagine you have spells. Each one has probably different attribute values (and maybe they have different number of attributes), and they also behave completely different from each other (unless one derive from another). That way you could have parent abstract class Spell and then specific attributes and behaviors for each one (imagine a virtual member function called cast, for example).

\$\endgroup\$
  • \$\begingroup\$ Tha was my first solution, hower with the Engine I'm using atm,everything was a bit confusing to me, but that's the right "design" for my problem :) thanks for your advice! \$\endgroup\$ – jeromintus Aug 17 '14 at 18:15
2
\$\begingroup\$

You should not mix the view which defines how things look, like the teams' HUDs with the teams' model, their data structure or class instance.

Like @pctroll said, the teams could be instances of a Team class. In my opinion, the Team class should simply be a glorified array of players and some methods that tally up score. The player class should have a pointer to it's team.

Warning this is pseudo code:

//so the function of adding a player could be like this:

class Team
{
  .
  .
  .
  vector<Player> players;
  addMember(p : Player){
    p.team = this;
    players.push(p);
  }
}

The view styling could be an instance of class HUD that is handed to the Team constructor.

\$\endgroup\$
  • \$\begingroup\$ I've also realized mixing it with HUD is a bad idea. haven't thought about setting the players team like this, that's actually a good way to do so. thanks! \$\endgroup\$ – jeromintus Aug 17 '14 at 18:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.