2 ms·
This does read nicely in most cases. There are minor issues when you venture off and decide that it would be cool if a monsters could damage your weapon. Somet
by arriu 8y ago
This does read nicely in most cases.
There are minor issues when you venture off and decide that it would be cool if a monsters could damage your weapon. Something like Monster.hits(Weapon).with(Weapon). You'll start wondering if Weapon should inherit from the player base class. If not, you'll spend time wondering how to share the code to keep things dry. Obviously there are many solutions even within OOP, but one might consider looking to ECS to remove code duplication and decouple things.
Lots of good examples in the game programming patterns book: http://gameprogrammingpatterns.com/component.html http://gameprogrammingpatterns.com/component.html
- jryan49 8y agoI think damage to the weapon could still be handled in the Hit class, because Hit has a reference to Player and Monster and Weapon. You could even create different types of Hit classes that could execute different kinds of Hit behavior like this. In that case it may be better to rename it to HitStrategy?
- alasdair_ 8y ago>You'll start wondering if Weapon should inherit from the player base class. Probably not. If you want to do that, they should both implement an interface (and perhaps share some code through composition) but code inheritance is likely not the right approach here.