How correct this little game design without removing its design pattern?

Question

Given is a design of a video game in which a player has several possibilities to adjust his character:

Game designers realized it's senseless to be a fire-elemental and water-elemental at the same time. Is it possible to create such a character with the current design? If yes, is it possible to avoid that without removing/destroying the current design pattern? Or maybe that will not work at all?

---

I think it's possible to create a character which is fire-elemental and water-elemental at the same time without removing its pattern because if I see it correctly we only have the design pattern 'composite' here.

But I'm not sure how it should be changed because the word senseless mentioned above confuses me, does it mean it's unnecessary to be a fire-elemental and water-elemental at the same time because they both waste mana as an attacking ressource? Or is it rather that it's illogical and thus should be prevented to be a fire and water elemental simultaneously? Maybe you know it better because this confuses me a lot? : /

Answer 1

Your internal program structure should not reflect your game rules. They should reflect how your program works.

Your game rules should be encoded elsewhere, probably in data files.

Why? Because your game rules will not comply with programming logic. While it seems simple at first, the more complex it gets the less happy you will be that you have bound game logic and program logic together.

Example: You have a Character class. Wizard and Warrior derive from that. A character can wield an IWeapon. But warriors can wield any weapon, wizards only Daggers. Whoops, violated the Liskov substitution principle right there and you are only on rule #2 of a very complex game.

Required reading on this topic: Wizards and Warriors (all five parts).

Answer 2

This diagram, assuming UML, shows both aggregation and generalization/specialization.

With the generalization/specialization, it says that each of sourcerer, fire-elemental, water-elemental, and berserker are specializations of a more general notion of character.  This is the "is-a" relationship: a sourcerer is-a character and so on for the others, too.

In addition, it says that any kind of character aggregates with each of sourcerer character, fire-elemental character, water-elemental character, and berserker character.

It is almost like there is a group of characters, a team, if they are working together, or set of opponents if they are working against.

This may be exactly what is intended by the particular game; however, without knowing anything else, I am suspicious.  The aggregation is unusually specific — simply aggregating character with character would have allowed creation of a team.  (Not to mention a team or set of opponents could be created any number of other ways, as well.)

Is it possible to create such a character (fire-elemental & water-elemental) with the current design?

If the programming language has multiple inheritance, and the classes are not final, then a programmer can add a class the specializes both fire-elemental character and water-elemental character, this new class would allow a single instance to be both a fire-elemental character and a water-elemental character.

If you're asking if it is possible to have a fire-elemental character and water-elemental character in aggregation with each other, then yes this is allowed by the diagram.

If you're thinking that fire-elemental and water-elemental are somehow merely attributes, properties, or qualities of character that are allowed to be aggregated, they aren't: they are each themselves their own (kind of) character.

Answer 3

Berserk, sorcerer, fire elemental and water elemental are too specific.

Indeed, a Mage, MagicEntity and Warrior would be a lot easier to reuse. Also it adds a lot of sense to using this pattern, as you could be a warrior and a mage and an elemental (and be a bit overpowered !). That’s the reason why being a fire elemental as well as a water elemental is senseless, because in the end the character is just an elemental, thus not gaining anymore power.

Also, attack looks like an action doing something, but it’s merely changing state of the current object which is deceiving. Shouldn’t it accept a parameter Character to attack it ? As it is now, it looks a lot more like a getAttackPoints method.