Jump to content
  • Advertisement
Sign in to follow this  
lodoss118

general class design?

This topic is 4161 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

how should i model this game using a simple class design In the game there are various types of people – players, staff (manager/coaches etc), board members (owner/chairman etc) and officials. Some people have multiple roles, such as player-managers.

Share this post


Link to post
Share on other sites
Advertisement
is this ok for the above design.


person
{
person(String name, TCHAR *type);

String getName();
TCHAR *getType();

private:
String _name;
Sring _address;
TCHAR *_type;
int id;
String currentClub;
String status;
String value;
};

player:person
{
Player(String name, TCHAR *type);

private:
int goals
String position
bool available;
};

staff: person
{
staff(String name, TCHAR *type);
};

boardMember : person
{
Boardmember(String name, TCHAR *type);
}

owner:boardMember
{
owner(String name, TCHAR *type);

}

manager: staff
{
manager(String name, TCHAR *type);
}

Roger: manager
{
roger()::Manager("ROGGY", "MANAGER");
}

Steve: Player : Manager // how do i say steve can be player and manager?
{
Steve::Player("STEVE", "PLAYER")
{
isManager("STEVE", "PLAYER");
}

private:
Manager *isManager; //do i need this
}

or should steve be

Steve
{
Player *isPlayer;
Manager *isManager

Steve()
{
isPlayer("Steve", "Player");
isManager("Steve", "Player");
}
};




[Edited by - lodoss118 on February 1, 2007 6:36:43 AM]

Share this post


Link to post
Share on other sites
Where's the game? You just listed different types of people. Without knowing more about what these people do I doubt anyone can tell you how to design your game. It sounds like some type of sport management game though. Try to describe what the gameplay is in much more detail, that might help some.

Share this post


Link to post
Share on other sites
While I am not sure of the language you are using from the code you posted (C++?), one comment I would make is that you would be ill-advised to derive new class types for Roger and Steve.

Roger and Steve would be specific instances of a particular class, say Player or PlayerManager. Their name is a property of that class.

A simpler example might look like:


class Person
{
public:
Person(std::string N) : Name(N) { }

std::string Name;
};

class Player : public Person
{
public:
Player(std::string N) : Person(N) { }
};

class Manager : public Person
{
public:
Manager(std::string N) : Person(N) { }
};

std::vector<Person*> People;

void f()
{
People.push_back(new Manager("Steve"));
People.push_back(new Player("Roger"));
}



With regard to the question in your code about how to make someone a Player and a Manager, I don't have a sufficient understanding of virtual inheritance to comment really.

The basic syntax would be, as far as I know:


class PlayerManager : public Player, public Manager
{
};


But multiple inheritance is a big and complex topic with a lot of potential gotchas so I'd get some better advice from someone who really understands it.

HTH

Share this post


Link to post
Share on other sites
I'd probably have a Person class, with a collection of Role objects. Role would be an empty/abstract interface, with various implementations, eg. Player, Manager, Chairman, Coach, etc. This also makes it easier for a Person to be promoted and gain/loose additional Roles from the one they were initially created with.

Share this post


Link to post
Share on other sites
It'd be the right approach to use an interface to model the different roles.
Speaking in C++, this would be a pure-virtual class, for those unaware that
interfaces _are_ indeed possible with C++.

It might be a good idea to apply the composite pattern to the role model,
so you can use a decorator to change object roles at runtime, which might save
you a lot of headaches.

Afterwards, you will have a Person class, a RolePerson class derived from Person
and implementing the IRole interface as an aggregation of an IRole instance,
offering the same interface as the distinct roles you derive from IRole;
using this approach, you can pass a pointer/instance/reference to RolePerson to
everything expecting an IRole type transparently, eliminating the need to keep
track of your role instances outside of RolePerson.
Additionally, you'll have a static Decorator class that will decorate your
RolePersons with the roles you want apllied to them and without having this
functionality inside of RolePerson, where it doesn't belong.

In Java or C# this will work almost completely the same way, in case you don't
use C++, as a FP guessed and which I took as given for my reply.

Hope I could help.
In case you have any questions you can always mail me ;)

Share this post


Link to post
Share on other sites
hi its a management game but i wanted to know how to best design it first, well roguhly as i the above classes i wanted to know say if i how should i do that each player could be a manager aswell etc?

Share this post


Link to post
Share on other sites
In your initial design, as already mentioned, you seem to be mixing up the ideas of classes and instances into 1 idea - classes.

OK, so here's a very little helper:

Create classes for "classes" or objects, sets of 1 or more object that have a certain set of data or behavior. Consider making a new class for 1 of 2 reasons, when there is some different data to track (people have names, cars have VIN numbers), when there are different rules for the data (employees names, birthdate and SSN must ALL be known, for customers some set of that data is optional), when there are different functions supported (a VisualControl can draw itself on a window - a Person cannot), or when there are different behaviors / algorithms to use for the interface (a Button draws itself on screen very differently than a DropDownList).

Create instances for existing objects. The OK and Cancel button are 2 buttons on a form. Steve and I are 2 people instances - perhaps of the same class, perhaps not.

If you now exactly what set of features an instance supports at the time you create it, and its never going to change than you do something like:

Manager steve = new Manager("Steve", other data here);

if you do not know what things are with the line of code that creates them, then you make a more complicated system that manages these roles using internal pointers or lists ...

something like:

Person p = LoadPerson(name);

where LoadPerson has more complicate code that figures out the type or interfaces from the data it finds ... such as perhaps a Type = "Manager" or a IsManager = true type value.

[Edited by - Xai on February 1, 2007 4:57:46 PM]

Share this post


Link to post
Share on other sites
I don't see a benefit of using overly complex multiple inheritence for such a simple idea.

It's a valid method of representing the hiearchial nature of what you are trying to do, but it results in harder to use code that is likely to be littered with bugs.

You might want to think up a simpler way of representing the people's roles even though multiple inheritence is generally how'd we'd view the data in real life.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!