Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth @19I don't know how bevy deals with that, but since they have an entire custom UI layer they almost certainly have something for it.  As I recall from my look at it, you actually run the main loop yourself.

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth @CamlornIrregardless is a double negative. URL: https://forum.audiogames.net/post/602217/#p602217 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth I'm using Sound RTS 1.2A10.Also, I wonder how Bevy would handle menues. Does it let me remove and add systems whenever I want? I don't want to end up with the player being able to run left and right whil

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth Interesting that SoundRTS is slow.  I'd make sure you're not on an old copy.  Some friends and I updated it to not be slow anymore some years ago, after which we were handling a thousand units fine.  I

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth I think much of the reason that I wanted to use Rust is because how nice it could be to work with. I made a little network thing where you tell it what kind of data you want, it uses serde_bincode to send and

Re: Is there a good way to handle multiple enemies who can effect each oth

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 typica

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth Just in defense of closed unions, or algebraic data types as they are commonly reffered to in FP circles. I think the idea that although I am not saying inheritance is an inherently bad method of data modelling, it

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth Just in defense of closed unions, or algebraic data types as they are commonly reffered to in FP circles. I think the idea that although I am not saying inheritance is an inherently bad method of data modelling, it

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth I didn't realize non_exhaustive had finally stabilized.  That is useful, but doesn't solve the problem.  I'm not actually making a judgement call on open unions one way or the other, but irregard

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth @12, Rust sort-of has open unions via enums (I wouldn't use Unions unless you were desperate and had no other option). Enums have the non_exhaustive attribute so you can match those values you support, and the

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth The reason I'm not proposing a queue of messages is because Rust doesn't have open unions.  That is, you have to define all of your messages in the same file, and then have a big match arm that matches o

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth @10, An interesting idea. Another option is MPMC channels. URL: https://forum.audiogames.net/post/601889/#p601889 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth hello, I am not familiar with Rust, but have done a fair amount of functional programming over the last year and a half. is not being able to have multiple mutable references to a container really a problem? that

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth @8, yeah, true. I don't really think the way Rhai's way of doing it is necessarily sub-optimal; I actually kind of like it. There are Lua bindings for Rust, though I don't know how well-developed

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth Yeah, it honestly seemed odd that you would be making that claim, but your primary thing as far as I know is kernel level stuff, so at the same time I could conceive of a world where you didn't context s

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth @6, I know that. Was pointing that out as a form of comparison to other low-level languages -- I should've clarified. URL: https://forum.audiogames.net/post/601694/#p601694 -- Audiogames-reflector mailing

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth Er, the entirety of Rust mitigates any safety issues with passing functions around whatsoever unless you're doing low enough level stuff that you're playing with raw pointers, which if you're doing

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth You can store functions within queues or containers. However, if your using them to pass callbacks that take data around, your going to need to use Box, because as soon as those callbacks want to pull something in

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth You can store functions within queues or containers. However, if your using them to pass callbacks that take data around, your going to need to use Box, because as soon as those callbacks want to pull something in

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth No, you can't make a queue of closures.  You can make a queue of Box.  This is because closures are actually structs implementing the Fn traits, and each closure is a different size and with a different v

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth Do I need a Box? Can't I just make a queue of closures or would that allocate a lot on the heap too? URL: https://forum.audiogames.net/post/601587/#p601587 -- Audiogames-reflector mailing list Audio

Re: Is there a good way to handle multiple enemies who can effect each oth

Re: Is there a good way to handle multiple enemies who can effect each oth You're having trouble because Rust all but forces you to use an entity component system.  You probably want to look into Bevy or Amethyst unless you're familiar enough with the ideas to write your own.Un

Is there a good way to handle multiple enemies who can effect each oth

Is there a good way to handle multiple enemies who can effect each oth I haven't actually tried this, but say you were writing an audiogame in Rust and you want to have enemies that can kill or heal each other.How would you do this though?It seems the only way to keep track of every