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. Any serious gaming framework in Rust will have to have a solution for that problem.@20yeah, I will keep making that mistake until the day I die. URL: https://forum.audiogames.net/post/60/#p60 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 while theey're in the middle of the menu because the system that handles player movement is still running. URL: https://forum.audiogames.net/post/602214/#p602214 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 wonder if someone went in there and started using lists everywhere again.Also, it's not exactly that Rust isn't nice to work with. It's just that in order to use it you're going to have to start by fundamentally rethinking all of how you do programming.I'm not saying run to Python, just something to the effect of if this is a problem and you don't know how to solve it and what you care about is a game and not learning how to solve it, maybe Rust isn't for you for right now. It does have some very strong stuff going for it: serde, as you've discovered, a very good ORM, a very good story around HTTP and networking services, and so on. I use it at work and we all like it, in fact two of us credit it for increased reliability at least a little bit (though it is too early to tell if that's true in practice).But if you're not ready to use an ECS for everything...well, you'll have problems. ECS is actually very effective, just, again, rethinking much of how you do programming is required. URL: https://forum.audiogames.net/post/602198/#p602198 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 receive data, then you just iterate over all your connections every game loop to see if there's anything new.I think the thing that bothers me about Python is the huge amount of junk that can get dragged along with your games like NumPy and WX. Some PyInstaller games are over 100 MB uncompressed and take 10+ seconds to start on my machine. Sound RTS is slow for me once you start cramming a hundred units on the map as well. URL: https://forum.audiogames.net/post/602192/#p602192 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 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.
URL: https://forum.audiogames.net/post/602071/#p602071
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 certainly is unnecessary. and anything can be modelled using composition and ADTs instead.also, personally I wouldn't consider having a lot of stuff needed to be defined in a single file to be a bad thing. I think the idea that having large files and having a lot of smaller files is good has come from Java and C#, where there it perhaps applies due to the everything is OOP paradigm, but it certainly doesn't generalize o programming. also personally I really dont mind pattern matching a union type and having a large branching function for each case, since I can still navigate through it using indentNav easily and in my eperience it isn't difficult to work with. right now, I am primarily working with Elm and this is essentially how updates are handled inan Elm application. You have one big ADT representing all the messages that might be triggered in the application and then you have an update function that branches on that message union type and defines what happenes for each message variant. the code actually ends up being quite neat and organized.although not to say that the Elm architecture necessarily would work well here. it is essentially an instance of functional reactive programming, which works well performance-wise really well for user-driven IO apps like most web apps or games that aren't heavily CPU intensive like high-end games. but just wanted to defend the value that ADTs (closed union types) can bring to the table. URL: https://forum.audiogames.net/post/602026/#p602026 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 certainly is unnecessary. and anything can be modelled using composition and ADTs instead.also, personally I wouldn't consider having a lot of stuff needed to be defined in a single file to be a bad thing. I think the idea that having large files and having a lot of smaller files is good has come from Java and C#, where there it perhaps applies due to the everything is OOP paradigm, but it certainly doesn't generalize o programming. also personally I really dont mind pattern matching a union type and having a large branching function for each case, since I can still navigate through it using indentNav easily and in my eperience it isn't difficult to work with. right now, I am primarily working with Elm and this is essentially how updates are handled inan Elm application. You have one big ADT representing all the messages that might be triggered in the application and then you have an update function that branches on that message union type and defines what happenes for each message variant. the code actually ends up being quite neat and organized. URL: https://forum.audiogames.net/post/602026/#p602026 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 irregardless of how you slice it Rust has a very poor story around representing inheritance-like relationships, and open unions solves that problem. Mind you, there's almost no good way to implement them that doesn't end with them allocated on the heap.Synthizer just solved this problem in C++. I hide the actual concrete implementation of the type behind function pointers paerameterized over the type itself, place a block of inline storage in a generic command struct, allocate the command type in that storage, use the aforementioned callbacks to erase the type from the external interface, put them in a MPSC ringbuffer that allocates as one contiguous block, and fail compilation with compile-time asserts if the size limit would be exceeded.Keep in mind: audio is a weird special snowflake where even at very low CPU utilization you still can't actually go around allocating and deallocating. There were actually something like 10 other ways to do what Synthizer needed, they just all unfortunately meant interacting with malloc from the audio threads in some way. For a game the throughput of just allocating them will be fine until some threshold. But at the end of the day I don't think messages for everything is an answer, getting into the details of how to do it is beside the point I was trying to make originally, and you really have to code how Rust wants you to. URL: https://forum.audiogames.net/post/601980/#p601980 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 then can create a match arm that matches everything else. In a way I like how Rust doesn't have truly "open" unions -- it makes code easier to follow and you can make an authoritative assertion that, when Discriminant x is matched, y will happen, instead of saying that when discriminant's x, y, and z match, a, b, and c happen, otherwise d happens. URL: https://forum.audiogames.net/post/601976/#p601976 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 over all of them. This doesn't necessarily end modularity or anything like that, but it doesn't help.In Scala, Java, etc. a lot of stuff is implicitly on the heap. For queues of messages you run up against the JVM's lack of value types. In Haskell, everything is on the heap in the "here is our completely custom allocator that doesn't work like a heap" way. It's not necessarily worse to use Box in Rust, it's just explicitly showing an implicit thing that other functional languages do behind the scenes. Whether it's a problem or not depends a lot on what you're doing, but if what you're doing isn't high volume enough that it matters, I'm not sure why you wouldn't go use one of the other fp languages unless this topic is for learning. URL: https://forum.audiogames.net/post/601893/#p601893 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 seems like a problem is trying to be solved using OOp thinking in an environment where OOP doesn't apply.How about creating a message everytime something needs to happen like an enemy should be healed or harmed or whatever, store those messages in a queue, and handle those messages in the scope where the mutable reference to the game state is? not sure if this is directly related to the queue of closures, but if you cant store closures in a queue, why not defunctionalize and have a union type that represents the different closures that could be needed and store those simple data values in the queue instead. then you would have a evaluation function that matches on the variants of the union type and effectively translates it to the closure you would have had if before defunctionalizing. URL: https://forum.audiogames.net/post/601775/#p601775 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 they are. URL: https://forum.audiogames.net/post/601700/#p601700 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 switch out.Anyway, w.r.t. scripting my point isn't that there aren't options to embed a language, it's more that, like, in C++ you've got sol and you can just start binding objects one or two lines at a time. In Python you've got the ability to just bind everything everywhere all at once with a tiny bit of reflection. Despite having really good procedural macros and things like Serde, however, Rust's answers to bindings tend to be really suboptimal, so much so that if we get as far as me doing the thing I'll probably end up starting with a crate to finally get something going on top of rlua or hlua (whichever is by the amethyst people, I always mix them up). It's a solvable problem, and I find it kind of baffling that Rust people have just kind of shrugged, especially since the lifetime stuff around doing things like that makes doing it by hand rather interesting at times. URL: https://forum.audiogames.net/post/601697/#p601697 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 that for a game you entirely missed the point of Rust. The only real concern with doing it is performance. Rust doesn't allow dangling pointers etc etc etc. unless you are doing very special, niche things like OS work. URL: https://forum.audiogames.net/post/601691/#p601691 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 from outside the environment the borrow checker is going to complain that the item doesn't live long enough. Typically you'd declare functions like that in this way:pub type InterruptHandler = Box;As Camlorn said, doing this is not an easy task, and for good reason. Passing functions around without knowing what your doing is dangerous, especially because compilers can move things around in the heap and suddenly that function you were pointing to isn't there anymore and you've just caused undefined behavior. Box mitigates this, but its the danger of passing raw, non-heap-allocated function pointers around: a pointer is just that, and you can't guarantee that what its pointing to actually exists. I use Boxed functions in my kernel for interrupt handlers, but it was not a decision I made lightly; I knew that, sooner or later, I needed to handle interrupts from hardware, but I didn't want my interrupt code riddled with thousands of lines of code that didn't need to be there, so I created a function pointer table. The borrow checker ensures that my functions are static, but I'm certainly not going to use them indiscriminately.As for scripting, there are some scripting languages in Rust. I'd say Rust has that down pretty well; you can for example use WASM if you like via wasmtime, or you can use Rhai, which is rust-ish in nature. There's Mun, too, though I could never figure out how to "embed" that since it was a statically compiled language.As for the initial question, another way to handle this is via a static with a mutexed container containing all your enemies (either a reader-writer lock, Seq Lock, or classic Mutex), but this undoubtedly isn't a solution you should go for just because you'll be introducing locking overhead, which is definitely going to slow down your game just a little. Not much, but if your using a constant FPS rate the locking might be slower than -- say -- the 16.66ms that your given per frame. Use an ECS wherever possible. URL: https://forum.audiogames.net/post/601688/#p601688 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 from outside the environment the borrow checker is going to complain that the item doesn't live long enough. Typically you'd declare functions like that in this way:pub type InterruptHandler = Box;As Camlorn said, doing this is not an easy task, and for good reason. Passing functions around without knowing what your doing is dangerous, especially because compilers can move things around in the heap and suddenly that function you were pointing to isn't there anymore and you've just caused undefined behavior. Box mitigates this, but its the danger of passing raw, non-heap-allocated function pointers around: a pointer is just that, and you can't guarantee that what its pointing to actually exists. I use Boxed functions in my kernel for interrupt handlers, but it was not a decision I made lightly; I knew that, sooner or later, I needed to handle interrupts from hardware, but I didn't want my interrupt code riddled with thousands of lines of code that didn't need to be there, so I created a function pointer table. The borrow checker ensures that my functions are static, but I'm certainly not going to use them indiscriminately.As for scripting, there are some scripting languages in Rust. I'd say Rust has that down pretty well; you can for example use WASM if you like via wasmtime, or you can use Rhai, which is rust-ish in nature. There's Mun, too, though I could never figure out how to "embed" that since it was a statically compiled language. URL: https://forum.audiogames.net/post/601688/#p601688 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 vtable pointer if you use it as a trait object. It's roughly the same as my trait, but may work on more things (e.g. naked functions).The allocation stuff isn't necessarily the end of the world, as long as rust's default allocator is still Jemalloc or your game is only doing something on the order of thousands of these or less per second. I thought they were talking about changing the default allocator and, if they did, you can get Jemalloc back, which can handle the volume by introducing some of the optimizations languages like JS and Python use to make allocating cheap enough to just have at it all day.There are more advanced tricks, though I don't know whether or not Rust game stuff does them. A lot of your difficulty here with Rust goes away if you start pivoting to think about Rust how Rust wants you to. In the standard object oriented languages, C++, etc, you're taught to think about your data from "inside" it: class Car gets implemented in terms of what the driver would do. In Rust, you're supposed to reach in from outside/above. The entity component system libraries solve this through things like typemap, in order to allow you to say that you want to find a specific entity's specific component without having to know in advance the full list of components (or, put another way, it's a hack to implement open tagged unions).If this is confusing you and your goal is a finished game, I'd just not use Rust. Obviously if your goal is learning that's different, but if you're jumping onto the bandwaggon we've got going around lately of "but anything but a native language is slw", don't make that mistake. Game dev in Rust is actually harder, it's not just you, but for people who do actually need that performance it's worth it.In the interest of full disclosure as to where I actually stand, my endgame is basically World of Warcraft for the blind, though that's very hypothetical for the moment, and I'm thinking that with a social media campaign it may be possible to get 100-200 simultaneous users, each of which might be in a different area. I intend to use Rust for that because it's an actually hard problem and because I've got a very strong Rust background. Something like Wayfar 1444 might also warrant Rust just because of the sheer amount of realtime simulation it wants to do all at once--most of why that failed was the guy behind it had never even heard of a tree, but some of it was Moo. But if you're considering this from what I think of as the product management/software engineering side where what matters is a working product, you should consider carefully. URL: https://forum.audiogames.net/post/601611/#p601611 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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 Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
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.Until you're used to the ideas that Rust wants you to do here, which are kind of hard to articulate, you can use something like RefCell to allow for runtime-checked interior mutability.There are some special case ways to deal with multiple mutable references to a container, for example I believe there are ways to split mutable slices into two non-overlapping slices.Ask me about this in 6 months and I'll have better answers, so the following is just thoughts for now. But basically for this kind of thing, the effective way to do it is probably as follows. First, cleanly split your game into things that decide to do stuff, and things that execute actions. naively, you can:trait Action {
fn execute(self, world: &mut World);
}Which can then be put behind a Box, to give you a way to implement a bunch of different action types. You can throw these on a queue and drain the queue after every tick.Entities themselves become an integer id, which avoids the borrow checker entirely. You just look them up when you need them.Then, you view the rest like database indexes. If you use something like bevy you get change tracking, which means that you can write things that compute different views on your data, for example what's close to what. To figure out actions to execute, then, you can have immutable references to everything, consult your different views on the data, and just queue the actions.This is, basically, an ECS minus a lot of stuff. If you go down this road, use one of the aforementioned crates because, in particular, Box is going to allocate all day long.The reason I don't tell everyone here to use Rust is that trying to use Rust for a game if you've not done a lot of programming already is kind of a mindfuck. A lot of the modern sighted games do what I'm describing because it's the only way to get reasonable graphics performance for complicated reasons, but it is harder in a lot of ways. Also, one of your questions in the near future is going to be "what about scripting" and the answer is that the Rust people don't seem to have solved that one cleanly yet.
URL: https://forum.audiogames.net/post/600825/#p600825
--
Audiogames-reflector mailing list
Audiogames-reflector@sabahattin-gucukoglu.com
https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
