Printable View
OK this is a theoretical question. Say that I am creating a game that has a Hero() class, Monster(), and Fight() class. Say that the fight class takes hp/str/defense from the monster and hero class and has a fight with the two. Would you have the fight class inherent from both the Monster and Hero class? Also would you have Hero() and Monster() inherent from a base class as well?
Is Fight an object? That's the first question you have to ask yourself.
Secondly, you must ask yourself is what the class another derives from is of that type.
Say, is a Monster a Hero (in case Monster would inherit from Hero)? If not, then you should not derive Monster from Hero. The same applies to all classes.
And if Hero and Monster shares properties, they can indeed derive from a base class. It's a good thing, actually, and probably a good choice, along with some virtual functions for polymorphism.
I guess that the Fight class would not be of that type but it would be using the attributes from both the Monster and Hero class. So i guess it would not need to inherent from these classes. Would you just set the attributes needed from these two classes to public and let the Fight class use it from there?
I think the point Elysia was making is that Fight() sounds like it should be a function, not a class; it might even be a function inside your Hero class, on the assumption that your player is the Hero and can choose who to fight. But the Hero and the Monster would get passed into the function, and then the function takes over and decides the outcome. If you pass things by reference, you can change the state of Hero and Monster inside the function.
Something like this...
Entity
Hero : Entity
Monster : Entity
Fight
Fight.processFight(Hero& h, Monster& m)
Have accessors and setters in Hero and Monster (the common ones can be defined in Entity) to adjust the attribute values.
Or:
IEntity
- public: virtual void Fight(IEntity *pEntity) = 0;
- public: virtual void Fight(unsigned int EntityID) = 0;
Hero : IEntity
Monster : IEntity
Fighting seems to be an action that an IEntity would perform against another IEntity object.
The second Fight() would fit nicely into a paradigm where IEntity objects were managed by a central resource manager. To get the IEntity pointer you would ask the resource manager for it.
Nay, nay, nay. Absolutely not.Quote:
Originally Posted by Perspective
Fight is not an object. It is not a thing, thus it should not be a class.
It is an action, which should be implemented as a function.
Bubba has the right idea of implementing it in the base class, so both Monster and Hero can fight.
That's an even worse design.Quote:
Originally Posted by chadmandoo
Never expose attributes from your classes. It breaks encapsulation (very important).
If anything, for such a situation, you would declare a function or class a friend to access the class internals, and even this should be avoided because it creates dependencies and breaks encapsulation if you're not careful.
Typically, the best designs avoids the need of friends and does absolutely not expose internals publically.
That said, in more complex situation, we may model a family of actions or behaviours as a (parallel) hierarchy of classes (e.g., an instance of the Strategy pattern).Quote:
Originally Posted by Elysia
Never heard of that one, though.
Strategy pattern
I've never used it in code I've written myself, but it does make sense that if you have a rather complex set of combined actions, it would be a good thing to put the actions into a class of their own, and interfacing through a base-class representing the object(s) that the actions correspond to.
Whether that is the right or wrong solution in this particular case is a different matter - I can't say for sure.
--
Mats
Edit: I'm just dropping my logic into the kettle. The questions, all of them, are offered to give the OP better ideas about how to model this situation. I'm just playing off of what has already been presented. This being here to save time and trouble later.
Is the fight a monster? *Quote:
Would you have the fight class inherent from both the Monster and Hero class?
Is the fight a hero? *
Do they both eat? *Quote:
Also would you have Hero() and Monster() inherent from a base class as well?
Do they both sleep? *
Do they both die? *
Do they share the same race? *
Do they have a common heritage? *
Is "Dance" an object? *Quote:
Is Fight an object?
Is "Waltz" an object? *
Is "Waltz" a noun? *
Is "Dance" a noun? *
Is "Fight" a noun? *
Does "Fight" know the nature of the hero? *Quote:
Would you just set the attributes needed from these two classes to public and let the Fight class use it from there?
Does "Fight" know the nature of the monster? *
Does "Fight" know the nature of every hero? *
Does "Fight" know the nature of every monster? *
Does "Fight" know the nature of "Flee"? *Quote:
Fight.processFight(Hero& h, Monster& m)
Does "Fight" know the nature of "Terrain"? *
Does "Fight" know the nature of "Inventory"? *
Do all "IEntity" "Fight"? *Quote:
virtual void Fight(IEntity *pEntity) = 0;
virtual void Fight(unsigned int EntityID) = 0;
Do all "IEntity" "Fight" the same way"? *
Is "Fighting" an action to be taken? *Quote:
Fighting seems to be an action that an IEntity would perform against another IEntity object.
Is "Fight" an action to be taken? *
If there is "Fighting", is there not also "NotFighting"? *
Isn't there also "Sleeping" and "Eating"? *
Are "Sleeping" and "Eating" not simply words used to describe our current status? *
Despite my best efforts I couldn't think of a series of questions that might reveal my intent here. Instead I offer the Webster definition of "Action": The event or connected series of events, either real or imaginary, forming the subject of a play, poem, or other composition; the unfolding of the drama of events.".Quote:
It is an action, which should be implemented as a function.
Soma
* Rhetoric... I don't care about the answers. (Yep, I'm still doing that.)
Btw, for this...Quote:
Originally Posted by phantomotap
If it would be a virtual function, child classes could override the behavior of the basic "Fight", so that different entities could fight different ways.
The only real problem would be if a Hero would fight a Monster differently than other Entities.
But this could be solved by making it a template function and specializing for the types where it might fight differently.
It's a good question and indeed and to be asked to oneself, but I believe that this approach might be a good one.
I'm actually about to watch a movie with my parents so I've no time for cute. You'll have to forgive me.
No. This is a problem. This is not a solution. Actually, this is the worst possible model for any simulation involving abstractions of actors, actions, and environment. (Without the specifics of what you envisioned, it also requires coupling of sickening levels for adding a new actor, action, or environment means recoding every class that might benefit from specific handling of the new actor, action, or environment.)Quote:
If it would be a virtual function, child classes could override the behavior of the basic "Fight", so that different entities could fight different ways.
Consider only four types of actors: 'entity::hero::warrior', 'entity::hero::wizard', 'entity::monster::lion, and 'entity::monster::bat':
It is safe to say that 'warrior' and 'wizard' will fight 'lion' differently.
It is safe to say that 'warrior' and 'wizard' will fight 'bat' differently.
It is safe to say that 'lion' and 'bat' will fight 'warrior' differently.
It is safe to say that 'lion' and 'bat' will fight 'wizard' differently.
You have four different match possibilities. Specifically, you have four different match possibilities that require absolute knowledge about both actors.
What you have is a multiple dispatch problem.
You can't solve the problem with templates: templates are only a means by which to implement the required multiple dispatch.
You can't solve the problem with inheritance: inheritance is only a means by which to implement the required multiple dispatch.
You can join templates and inheritance, but you'll still only be implementing the mechanic for multiple dispatch. Feel free to add RTTI, but at the end of the day you'll still be implementing the required multiple dispatch. Add the strategy pattern as well--which was a good hint regardless, but the requirements don't change.
(There is the obvious way of using only compile time polymorphism, but that is a greater issue.)
This suggestion means, regardless of your skill or intelligence, you will still have to write code dealing with each possible beneficial pairing. (Obviously, not every pairing will be beneficial. One kind of environment probably doesn't need to know about another kind of environment.) I'm ignoring the actual "Fight" code as it is obvious. Ignoring the implementation and maintenance overhead of the multiple dispatch mechanic itself is not an option. Even my version, and my version is extremely good, requires considerable maintenance overhead in the face of a new pairing tree.
We are only talking about a simulation. Let's pretend the language naturally supported dynamic multiple dispatch, is this level of precision really required? Ask yourself the most important question of all: how exact does the simulation need be? This is important because there is nothing wrong with any suggestion made so far. Really. Whether or not the individual suggestions have value depend on what one hopes to achieve with the model. With this scenario, if you sacrifice some precision, there are much better ways to model the simulation.
A bonus question: how important is it that actor A to know the exact details of actor B if actor A knows that actor B is a familiar entity?
Soma
phantomotap, what's your point?
EDIT:
Is this your main point? Frankly, all that rambling about multiple dispatch makes it hard to see what exactly is the point that you are trying to get across.
Not that that rambling is necessarily bad, but I daresay that we need to keep chadmandoo a little more focussed.Quote:
Originally Posted by phantomotap
I see a single dispatch:
Overloading and static polymorphism works well since you would have to have overloaded functions for every enemy or a common one when there aren't any special animations.Code:template<typename Hero, typename Monster> void Fight(Hero& hero, Monster& monster)
{
// Let's just assume the hero attacks first
monster.SetHP( monster.GetCurrentHP() - (hero.BaseAttack() - monster.Defense()) );
hero.ShowAnimation(monster);
if (monster.GetCurrentHP() <= 0)
{
monster.DeathAnimaton();
return;
}
hero.SetHP( hero.GetCurrentHP() - (monster.BaseAttack() - hero.Defense()) );
monster.ShowAnimation(hero);
if (hero.GetCurrentHP() <= 0)
{
hero.DeathAnimaton();
return;
}
}
class Warrior
{
public:
void ShowAnimation(Lion& lion);
void ShowAnimation(Bat& bat);
// ...
};
// etc
There is no use in arguing about the low-level design of the fight system if the high-level design of the game is unknown. For example, in the typical JRPG style game, you have several game modes. You have the map mode, where you walk around. You have the menu mode, where you browse your inventory and stuff. And finally you have the fight (actually, you'd probably call it battle) mode that you enter when you stumble upon a monster.
In such a design, Battle is very much a class, implementing the GameMode interface. It is passed two arrays of FightingCharacter (as opposed to non-fighting characters like shopkeepers) pointers, which denote the two teams involved in the battle. The Battle will query those characters for actions in turn. This will probably return a pointer to an Action object. The Battle will then tell the Action to execute itself, deducting or adding HPs and MPs as appropriate. The Battle will then query the characters for their status and decide if the battle is finished or goes on.
Or you could have a completely different design.
Warming leftovers takes much longer than I expected. ;_;
The forth sentence was my point: a model where every action requires absolute knowledge of every actor is almost always the worst possible model.Quote:
Is this your main point?
That wasn't rambling, that was exposition. ^_^Quote:
Frankly, all that rambling [...] trying to get across.
O_oQuote:
Overloading and static [...] aren't any special animations.
You have got to be joking. That doesn't even approximate the conceptual situation in my response to Bubba. (Though, it is an example of compile time polymorphism I noted as a possibility, and one that I also implied has many problems. You've managed to introduce every problem with a surprisingly simple bit of code.) That doesn't model a situation where each "IEntity" fights differently. That is a perfect model of where every "IEntity" fights exactly the same. (Worse than that, every fight is a series of repeated actions of every other fight.) The only thing that is different: what is shown when they do the same actions! Does that make any sense to you? Anyone?
Oh, and if you really intend to ignore the true "kind" of "IEntity", you don't need a template.
Soma
It makes big sense to me.Quote:
Originally Posted by phantomotap
Those are the basic requirements for a battle. If you don't like them, then specialize the template.
It then calls animations for each. All the classes would need to do is derive from a common base class for the "basic" fighting animation. If it needs special animations, it could overload functions for the special animations.
It makes perfect sense to me, so please, if you can, point out the problems and how to address them.
Actually, that sounds like a very nice abstraction, provided you need such a flexible design.Quote:
Originally Posted by CornedBee
Who is talking about the design?Quote:
There is no use in arguing about the low-level design of the fight system if the high-level design of the game is unknown.
Personally, I'm talking about the conceptual model of "Fight".
Granted, I've made references to C++ to do it, but still...
Soma
Where's the difference between design and conceptual model?Quote:
Who is talking about the design?
Personally, I'm talking about the conceptual model of "Fight".
That's kind of sad, but not strictly relevant.Quote:
It makes big sense to me.
Indeed.Quote:
Those are the basic requirements for a battle.
This is actually an implementation detail and not part of your model. (I originally addressed it because you offered it as a way to implement a model very different from yours.)Quote:
If you don't like them, then specialize the template.
Using compile time polymorphism as an implementation mechanism buys you all the problems of compile time polymorphism. Do you not know those problems? I'll give you an example, your save file loader function functions as a factory to load the player state: what type does that function return? Use some base you say? Which base should you return? Return "Hero" you say? How do you get '*player_hero' to work with a template? Use a reference to "Hero" you say? How do you specialize the template so that my "Wizard" "Fights" differently than your "Warrior" in the context of your source? Don't use a factory you say? How do you load the save state? Examine it and selectively load it into the correct type you say? How do you choose which execution path to take? Use templates to implement all of it you say? That is an option, but you had better have a very limited number of actors... like two.
Indeed. He needs a few points for that...Quote:
Actually, that sounds like a very nice abstraction, provided you need such a flexible design.
O_oQuote:
Where's the difference between design and conceptual model?
If you have a flawed conceptual model you have no chance to design a reasonable model ready for implementation.
I don't know much about chemistry, and if I start off with this flawed conceptual model than any simulation I make will be poor and any implementation probably worthless. How I choose to model the interactions between elements is one thing, but if I model the transition elements the same as the others, because I was working from this flawed conceptual model, you can bet my code will be virtually useless regardless of how perfect I modeled the interactions in my implementation.
Soma
If the design is what CornedBee is alluding to then I would agree that Fight would then need to be a class since it actually represents a larger object than just a simple action and probably opens up a whole set of new actions. But if the characters just fight one another in real time then I cannot see how making Fight a class makes any sense. Are you going to make walk, talk, and eat a class too?
But without knowing the design it's impossible to say which is the best approach. It really depends on the circumstances.
I don't like the template idea b/c it will only allow a hero and a monster to fight. It won't allow two monsters to fight or two heroes to fight. It also does not account for other 'interested' parties to get involved in the fight. But again I'm coming from a real-time non Final Fantasy style of fighting. Oblivion style fighting would be a good example of what I'm talking about. Fallout 3 or the Final Fantasy series would be an example of the type of fighting CornedBee is talking about.
If you don't know the high-level design of the application, you don't even know what Fight is referring to. How can you make a reasonable conceptual model of it?Quote:
Originally Posted by phantomotap