I’m just starting out with this pattern, inspired by Type Object · Behavioral Patterns · Game Programming Patterns
Was hoping to get feedback or hear from someone who has used it, or if someone else is interested in learning it…
I will go over:
- learning basics
- design method I don’t agree with.
- what I am going with.
- Current setup
- Vision for an item system.
Basics
I’m starting pretty simple:
Some data for what “breed” a character is. For now it’s just Breed <- Shape <- Cube / Sphere / Cone etc.
Each shape will have different values. Maybe I will go more specific like Cube will have a ravenous Cube or smelly Cube.
Design that doesn’t really help?
Something I reacted to is, the author writes a bit about having to adjust the health of dozens of classes which is tedious.
Then there’s examples of how Health is retrieved as well as set in some classes:
int Breed::getHealth()
{ // Override. if (health_ != 0 || parent_ == NULL) return health_;
// Inherit. return parent_->getHealth();
}
{
"Troll": {
"health": 25,
"attack": "The troll hits you!"
},
"Troll Archer": {
"parent": "Troll",
"health": 0,
"attack": "The troll archer fires an arrow!" },
"Troll Wizard": {
"parent": "Troll",
"health": 0,
"attack": "The troll wizard casts a spell on you!"
}
}
So - if I have understood this logic - Getting the Troll Archer Health will return 25, because it is set to 0. But that’s not tuning dozens of characters. That would be the Troll archer having 26 health and the Troll Wizard 24 health. Now again, if those values are to be adjusted, you still have to adjust dozens of classes.
So I don’t agree with how static the values are set.
What I am going with
It will be similar but I will have the properties be associated with a level. (though that could be applied to the authors method too).
So the very base breed will be the norm value. In the case of Health, it will be 10. So a breed will by default have 10 max health for each level that the mob is.
The values in the sub classes is not to override that value, but to manipulate it.
So the Shape breed will modify health by 3. That becomes 13 health per level.
And the Cube shape modifies it by 2. That becomes 15 health per level.
Maybe the Cone shape modifies it by -1. That’s 12 health per level.
Now, if I want to adjust the properies, I just need to go to the class that is shared by those who needs adjusting.
Maybe all breeds needs adjusting, so we adjust the base breed.
Maybe Shape breeds needs adjusting, but "Light breeds"™ are just fine. So we adjust the shape class.
That will be my design philosophy.
This is the inheritence setup:
An asset inheriting from Primary Data Asset. (breed)
Now there are two ways to inherit from this breed class. One is to create a child blueprint class. The other is to make a Data asset from the breed class. These two methods creates different kinds of assets and I’m not going to pretend to understand it. But in order to set the value of a Breed Reference, it has to be created through the data asset.
The Breed class has the health property as well as a parent. When getting the health of a breed, the breed checks if it has a parent breed. If not, it just returns its health. If it does, Get that breeds health and modify the result. I think that this way, not everything has to be related. There could be the standard Health per level cubes but then also a dragon that completely disobeys the Health per level rule and has no relationship with the other breeds.
Edit, actually I think I designed this wrong. There shouldn’t really need to be an object inheritance, just the parent property. Like so:
But really this is just to learn the practices of the pattern, to be able to design a robust Item system.
Item vision
I’ve tried making Items (the kind that a player character picks up or wears) before, using inheritance.
But what is an Item? It can be something that the player picks up but is just junk in the inventory. Or it can be equipment that modifies some attributes. Or a usable item,
But what about spells? I don’t want spells to drop or be put in the inventory - they should belong in the spell book.
Or what about Perks? Those don’t drop. Yet, equipment and perks, spells and weapons, they are very similar to each other. Just different acquisition methods.
Here’s a draft:
Some Items should be usable. health pot, mana pot. Spells are usable. maybe Perks are?
But what does Usable mean? They give some kind of effect. Is effect an Item?
Sometimes equipment, or items, can react to things. Like reflecting damage.
What is this reaction? An effect?
Can an effect be reactive?
It looks a lot like a hierarchy tree with some interfaces and decorators. I have yet to decipher how to set this up in a Type Object fashion.