4 ms·
Gameplay logic inherently leans more towards composition, with a little hint of inheritance. You can have players and monsters, which are all types of "charact
by Razengan 1y ago
Gameplay logic inherently leans more towards composition, with a little hint of inheritance.
You can have players and monsters, which are all types of "characters" or "units", which is inheritance, but instead of having a separate FlyingPlayer and a separate FlyingMonster, which use the same code for flight, you could have a FlyingComponent, which is composition.
I've been going all in on composition and it's amazing for quickly implementing new gameplay ideas. For example, instead of a monolithic `Player` class you could have a `PlayerControlComponent` then you can move that between different characters to let the player control monsters, drones, etc.
Imagine instead of only Pac-Man being able to eat the pills, you could also give the ghosts the `PillEaterComponent` in some crazy special game modes :)
I've also been fantasizing about a hypothetical language that is built from the ground up for coding gameplay, that doesn't use the word "class" at all but something else that could be a hybrid of inheritance+composition.
- baklazan 1y agoYou can do the very same with inheritance, where `Player` and `Monster` inherit `Flying`
- Razengan 1y agoWhat about walking monsters? Another inheritance branch for those? And other subtrees for other effects? What about making those effects temporary?
- DonHopkins 1y agoEntity Component System: https://en.wikipedia.org/wiki/Entity_component_system https://en.wikipedia.org/wiki/Entity_component_system
- Razengan 1y agoYeah, but all current languages still have to wrangle ECS into an inheritance-first architecture: `class` etc. Would be nice if something like Swift's "Protocols" could be used in a more dynamic way, at the code level.