Re: Is there a good way to handle multiple enemies who can effect each oth
Again, I'm not making a judgement call one way or another. It's fine, in the sense that you just end up with giant match arms. But what you really want to say in such cases, at least for the typical game, is:
MovePlayer(payload) => { payload.execute(world); }A billion times. And then as soon as you start saying that you want to do different sorts of behaviors on your commands or what have you, sure you can, but it becomes yet more giant match arms somewhere else. Then suddenly your instructions to someone who wants to extend this is "write your behavior, then register it in these 5 places". That's not so great. It's not the end of the world, and for something like frontend where it's for sure always going to be one thing and also you have dynamic typing escape hatches and etc, yeah, sure.
But you can just skip to the ECS version of this, which is where you'll end up anyway given that it's Rust, and use Box for the leftover bits, and you're done.
I don't defend OOP as such, but the inheritance point is an important one, however. For something like Synthizer, it's not about the fact that things happen to be objects, it's that inheritance-style OOP is very valuable for having a big set of "things" where you don't know what they are, but you want common behavior. What Rust doesn't have is the ability to easily default common behavior for things. You can kind of work around it and once you pivot into a Rust-style thinking it's not really the end of the world or anything, but for some applications--games, I'm looking at you--it quickly becomes a valuable thing that Rust doesn't have. You can say big match arms or whatever, but then you want to do something like snakes eat frogs and suddenly your match arm starts becoming O(N^2) on variants and you can't just do something in the snake and frog UI or something as easily. Again, yes, you can. It's just not as easily. ANd then you say "now builders can script a new enemy type" and instead of "I'll just inherit" it's "oops, all my match arms of doom".
What the FP proponents like to promote is that you can use reactive programming or whatever, and you can, but it's worse than good old OOP for the sorts of special casing that OOP lets you do. I know you're going to say "but you can just", and you can definitely just, but what you can just do turns out to be very language specific. The knowledge doesn't transfer around like it does in OOP land, where you can pick up most languages with classes, spend 5 minutes with it, and all the things you know apply. You end up with threads like this one, where people have to ask what you can just do to solve this problem in Rust, or Haskell, or Scala, or whatever else. And as soon as you say "but monads", or "but open unions", or "but functional reactive programming", or whatever else it turns into things like "haha sorry, Scala is bad at higher-kinded types because" or "actually in Haskell you can do deep updates without going insane, but first go understand lenses" and so on.
I know that the Servo people had to solve this somehow because the DOM is one of those perfect examples where you really need to simulate inheritance, but I don't know what they did for it. And again, this thread already contains workarounds. But let's not get into "FP is great". There's always a caveat on "FP is great", namely "for what I happen to be using it for right now as I'm defending it". FP ends up being great for frontend and I can list lots of other things it's great for. But it doesn't generalize well. A lot of that is because the people promoting it tend to just experiment in their languages, and maybe if they stopped doing that and worked on converging it would generalize, but today is not that day.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
