3 ms·
Unless cast is an ability unlocked by the wand, then you'd only have "use main/offhand" on the person, and the cast would be on the wand. It's really not as cu
by 411111111111111 4y ago
Unless cast is an ability unlocked by the wand, then you'd only have "use main/offhand" on the person, and the cast would be on the wand.
It's really not as cut and dry as you said.
- yxhuvud 4y agoAnother way to phrase it is to note that the question is answered by the question of what happens when the wand is dropped and the goblin picks up the wand. Can it cast the spell? Then it belongs to the wand. If not then it belongs to the wizard. In this case it just mean you have to match your game semantics to the decision of where to put the ability. That doesn't mean it would be a good idea to perform fighting by simple method calls on the objects though. It is very likely one would want to extract the abilities granted by skills and object to a separate entity that change seldom enough. That doesn't mean I see what problems a schema solves here. That mostly seems like unecessary indirection.. Also note I don't try to refute the problem in general, just this specific example. Maths have lots of examples that doesn't have the semantic baggage that makes the question solvable.
- 411111111111111 4y agoYou haven't convinced me with that at all, honestly. You can also have the spell on the wand and require n mana to be put into it for activation (argument), now warrior type goblins won't be able to use it either. There is no "correct way" with OOP: There are as many ways as you've got the energy to think about and all of them are leaky somewhere. You can still write maintainable code with it, but making it sound clear and obvious where what should go is just wrong. It heavily depends on a multitude of factors and can get nauseatingly complex at times
- rawoke083600 4y agoThis ! Each answer here as to where to put it is different or breaks down in different scenarios. While none of the OOP solutions are outright wrong, neither one are "obviously right".
- zasdffaa 4y agoMultiple dispatch solves that question. I wish it was better known. Dispatch is on both wizard (or generally, user) and wand (or generally, item used)
- zwkrt 4y agoRight but now it’s also raining and a full moon and the goblin is a werewolf and wands also have AOE spells that hit multiple opponents, except when those opponents are blocking… Sure, the code kinda sucks either way, but the data oriented approach works exponentially better as the object interactions become more complicated. A “cast” function called as part of the event loop can look up all the game state in the state DB as it needs to. wand.cast(…) is a lot more brittle, ESPECIALLY once one wants to start reusing some of the code in sword.swing(), etc.
- zasdffaa 4y ago> wand.cast(…) is a lot more brittle That's not how it works. Multiple dispatch looks like a normal procedure call, it would look like cast(item, user) or if you need to know it was raining cast(item, user, worldstate)
- mattarm 4y ago…and thus code is no longer sending _a_ message to _an_ object but using argument types to pick which function/procedure to call. The “cast” function is no longer coupled with any single class, so in effect this problem with OOP has been fixed by not using OOP concepts to solve the problem. Or, as I sometimes think of it, it can be an OOP design if multiple dispatch is actually a set of messages supported by an implicit, singleton, and usually hidden, “multiple dispatch“ object that handles the dispatch logic. You don’t have to write “dispatcher.cast(a, b, c)” but that is because the language provides the syntactic sugar (and often, an efficient implementation).
- zasdffaa 4y ago> …and thus code is no longer sending _a_ message to _an_ object but using argument types to pick which function/procedure to call I dunno. From https://en.wikipedia.org/wiki/Multiple_dispatch https://en.wikipedia.org/wiki/Multiple_dispatch "Multiple dispatch or multimethods is a feature of some programming languages in which a function or method can be dynamically dispatched based on the run-time (dynamic) type or, in the more general case, some other attribute of more than one of its arguments.[1] This is a generalization of single-dispatch polymorphism [...]" It's just a nicer OOP to me. *shrug* But thanks.