Re: Audio Games with Rust?
Re: Audio Games with Rust? Nolan just bound Synthizer. I can't speak to the rest of the ecosystem other than to say it's absolutely huge when it comes to gaming stuff, so just find one you like with a Google, they're a dime a dozen. Only downside is there's no accessible UI option that I know of, so it'll all be self voicing and stuff, but that's not necessarily a problem. URL: https://forum.audiogames.net/post/572532/#p572532 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? Thanks Camlorn. I'll have a look. And ooh, Synthizer in Rust? Yes plase. URL: https://forum.audiogames.net/post/572534/#p572534 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? It may not be ready for people other than Nolan to get it working, but it does exist and I'll probably help to maintain it down the road and/or if Nolan moves on. I may end up using Rust myself for future projects; we'll see. URL: https://forum.audiogames.net/post/572536/#p572536 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? I'd recommend looking into Bevy for an engine. Maybe I'm biased, but the ECS pattern of composition is so much easier to reason about. Plus, if we add accessibility to Bevy's UI, it's easier to do by just adding an Accessibility component to all widgets and a screen reader system, than it'd be asking engine developers for permission to add a11y properties directly to classes.Also, to promote another project, tts-rs provides a decent TTS interface to Linux, Windows (Tolk/RT), the web via wasm, and MacOS AppKit and AVFoundation, which theoretically covers iOS as well. Basically everything except Android, which doesn't expose a TTS interface via the NDK, and creating a JVM via JNI on Android looked like a mess of fragile hacks. URL: https://forum.audiogames.net/post/572549/#p572549 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? Adding a proper accessibility component to Bevy would require global understanding of keyboard focus handling and the ability to hook the message loop. If they don't have at least a global understanding of keyboard focus, it's a lost cause, though at least on Windows, there are sufficiently clever ways around the message loop problem if one can otherwise get a native window handle.I've looked at bevy myself and it seems like overkill. Maybe it's not and I don't yet understand the ECS problem space, and also using it rather than writing your own is probably worth it. But what you want is some basic for loops over arrays possibly with some rayon magic, maybe a bitset that tracks changes, and maybe a tiny observer/event system. But what bevy seems to give you is something that's massively, massively overengineered for the problem space. What am I missing? It feels a lot like I could grab rayon (parallel execution), roaring (compressed bitsets), and maybe a couple other things, and code up my own bevy in a Saturday. URL: https://forum.audiogames.net/post/572551/#p572551 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? I mean, maybe you could code it up in a Saturday. All I know is that smarter folks than me are optimizing the hell out of ECS', and I've done this for long enough to be allergic to the "what's the big deal about X? I could do it in a weekend" mentality. If it could be, someone would have, and the folks who have are probably content with solutions that aren't terribly performant. Currently there are like 3-4 ECS contenders all healthily cooperating and sharing ideas. If this was a dead space with no room for innovation, we wouldn't see that.And I'm not entirely clear on your accessible GUI pessimism. They're going to need keyboard focus for gamepad support at least, and right now they're still hashing out whether they're modeling on flexbox or Flutter layout conventions. You're not going to get bindings to native accessibility APIs unless you come up with people to do it and the funding to support them. In the meantime, I've committed to work on Bevy accessibility alongside my Godot work, and at least 1-2 other folks have expressed an interest in helping out, so I think we've got a decent shot at coming up with something compelling. URL: https://forum.audiogames.net/post/572556/#p572556 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? I'm not being negative about accessibility. I'm just saying you need those two things to do it. If they have those two things or are willing to get them, cool, more power to you and everyone else working on it. But I have looked at these libraries before and would say that it's very much more common for them to just be like "keyboard? What keyboard?" and retrofitting focus isn't the easiest thing at all. I tried once, it turns into the sort of thing where you rewrite half the library. But if they're actually doing that up front, it's a reasonable approach. At the end of the day UIA isn't actually impossibly difficult for one thing, but you need an internal model to feed it from that's sufficient. I can't speak to the other platforms but OS X shouldn't be significantly harder and you'd know more about Linux than me.We do see lots of people writing entity component systems in a weekend. The internet is littered with them. 99% of the libraries I've looked at it are "I wrote this thing for one game and put it up on GitHub". I'm not saying that I would opt not to use Bevy, just that I don't see the point going as far out as they seem to have with abstractions and layers of indirection, and that reading docs beyond their tutorial, it seems as though I will spend as much time figuring out their APIs than if I just threw something together myself really quickly. So either I don't understand the eCS problem space or I don't understand what Bevy's goal actually is, I'm not sure which. I don't think it's a bad library, I just don't get the philosophy that they're aiming for at all. URL: https://forum.audiogames.net/post/572560/#p572560 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? For audio libraries, there's of course synthizer, as well as Alto for OpenAL and Cpal/Rodio. For loading audio samples there's Audrey, which can load all of the common audio formats, as well as some less-known ones (re: ALAC/CAF). URL: https://forum.audiogames.net/post/572563/#p572563 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? I hear you re: keyboard focus. Again, remember this is all super early, so I don't think it's entirely accurate to assume that no keyboard support now means no support ever. They barely have buttons right now, to put things into perspective. The APIs are actually pretty easy to work with. I'm hacking on a roguelike concept I've had for a while. Systems are essentially independent functions that accept either component types which filter the entities on which they're called, or query parameters to further filter the entity list with more complex conditions. So I can write a function that accepts an input map, a player, and its transform, then updates the transform based on which actions are active. I wanted a system that announced and described new rooms of the map when they're entered. That function accepted a TTS resource which pulled a global TTS instance from a resource pool, and a query that ensures that the complex bit of the function only runs when the player's transform mutates. It then tracks the previous room in a resource local to that function only, and speaks a generated room description when the player's new room differs from the previous one. Other engines including Godot would require more and more complex hooks into the global process loop. ECS basically contain all of these requirements to single functions/systems, then ensures that these functions are parallelized and can update and access the global component/resource pools without conflicting. If it isn't how you think, that's fine. Games can certainly be built using a number of design patterns. For my part, I'm finding that Onslaught is starting to get a bit sloppy as players keep finding late-stage balance issues, and I'm having to touch code in 3-4 places to implement new features. I wish I could have built this functionality out in systems, then had new systems work with the features exposed by the older ones. Obviously I could have done things more like that if I'd planned it from the beginning, but it'd have been easier if my engine forced that from the start. URL: https://forum.audiogames.net/post/572567/#p572567 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @10, what I struggle with, myself, regarding ECSs, is taking data with me when I transition. (I also found Amethyst -- the best game engine that uses ECS in Rust at the moment to my knowledge -- quite confusing; its documentation was very difficult to navigate sometimes.) Say, for example, that I want to load all the sounds for the game at startup. How would I then take these sounds with me? Or even load them, for that matter? I had an idea -- using something like lazy_static to hold a HashSet of sounds, or even a HashMap as a static -- but that doesn't seem like it would work very well. URL: https://forum.audiogames.net/post/572576/#p572576 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @10, what I struggle with, myself, regarding ECSs, is taking data with me when I transition. (I also found Amethyst -- the best game engine that uses ECS in Rust at the moment to my knowledge -- quite confusing; its documentation was very difficult to navigate sometimes.) Say, for example, that I want to load all the sounds for the game at startup. How would I then take these sounds with me? Or even load them, for that matter? I had an idea -- using something like lazy_static to hold a HashSet of sounds, or even a HashMap as a static -- but that doesn't seem like it would work very well. The idea of each "state" receiving data -- all the data -- makes me think of a lot of copying. URL: https://forum.audiogames.net/post/572576/#p572576 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? Update: So looking at Bevy, or the rustdocs at least, it looks like a lot of magic and very little explanation. For example, the example has this line: App::build() .add_system(hello_world_system.system()) .run();That hello_world_system thing is defined as:fn hello_world_system() { println!("hello world"); }Yet the .add_system() function looks like:pub fn add_system(&mut self, system: Box) -> &mut SelfThis makes no sense to me. The hello_world_system() function returns unit. Therefore, what magic is exactly going on? Because according to the example, the function has no annotations, proc-macros, derivations... nothing. Its just an ordinary rust function, indistinguishable from main(). To add to that, the .system() function is called on the function as though it were an initialized structure. And rust syntax does not allow you to do calls like that on functions -- you have to do that on their return values (I don't know a language that treats functions as objects like this seems to do). So, I'm utterly baffled what exactly is going on? URL: https://forum.audiogames.net/post/572581/#p572581 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? Update: So looking at Bevy, or the rustdocs at least, it looks like a lot of magic and very little explanation. For example, the example has this line: App::build() .add_system(hello_world_system.system()) .run();That hello_world_system thing is defined as:fn hello_world_system() { println!("hello world"); }Yet the .add_system() function looks like:pub fn add_system(&mut self, system: Box) -> &mut SelfThis makes no sense to me. The hello_world_system() function returns unit. Therefore, what magic is exactly going on? Because according to the example, the function has no annotations, proc-macros, derivations... nothing. Its just an ordinary rust function, indistinguishable from main(). To add to that, the .system() function is called on the function as though it were an initialized structure. And rust syntax does not allow you to do calls like that on functions -- you have to do that on their return values (I don't know a language that treats functions as objects like this seems to do). So, I'm utterly baffled what exactly is going on?Edit: OK, so the book explains it... sort of. Its apparently a trait extension type, which I've never seen until now (I don't think). Interesting paradigm, if I might say so myself, and an interesting use of the type system. URL: https://forum.audiogames.net/post/572581/#p572581 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @10if they have complex query stuff that's different, but I couldn't find such things on a cursory skim of the docs. Their tutorial isn't showing me something more complicated than what I could accomplish with a for loop and indeed their section on queries seems to be saying "well you chose not to write the loop yourself, here's how you deal with the fact that you needed to" , but maybe there's more stuff in there somewhere. You could ideally take this as far as sql-like _expression_ indexes without overly much work.I don't need to be sold on an ECS and, since my goal is an MMO or at least an MMO engine, it's also kind of the only way. They also naturally solve networking. I'm just really still not getting what bevy specifically brings to the table that I couldn't get by just writing normal for loops and bringing in rayon and calling them systems. perhaps this time in 6 months it's going to offer a bunch of stuff it doesn't now, or perhaps their docs are just very meh, but at the moment the parts I'd care about for an audiogame are documented in a "we offer the minimum set of features possible, isn't that amazing?" way and if there's more it's not immediately obvious to me.@11To offer a concrete example that I will probably use, suppose you want to maintain a relationship like muds do, where things can be inside other things. I might do the following component:struct parent { pub id: EntityId, pub index: usize, }Then the purpose of the Relationship system would be to observe changes and maintain the tree with whatever you want to use to maintain the tree, and it would/could offer an API to anything else that wants to reach out to it and ask "what are all the children of the town square". Put another way, the components are authoritative: if you change the component that change has to propagate promptly to everything else. But nothing stops you from letting systems have backchannels to each other for readonly access, and any system that wants can store secondary data like Synthizer handles to reflect components onto the external universe.So for example the relationship system might offer a sort function, which takes an entity and sorts its children, but what this is actually doing under the hood is using the relationship system's internal state to find the entities that need to be sorted, then reaching out to the actual component store and changing them there and letting the changes reflect back in via whatever your observer API is after the fact.Nothing stops you from sticking handles to external resources in components either, i.e. the component might be the instantiated physics thing from your physics library, and if it's something like a huge map array, nothing stops you from having another level of indirection to something else that holds the 10 megabyte tilemap for whenever you need to grab a pointer to it.Mind you the above is predicated on having a good observer story, which you can get from most ECS libraries and which isn't overly hard to write yourself, but if you don't have it then what I proposed is that the relationship does a for loop over 10m entities every frame. Which isn't what I'm saying at all, to be clear. URL: https://forum.audiogames.net/post/572583/#p572583 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @13, ah, makes sense. URL: https://forum.audiogames.net/post/572584/#p572584 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @12Should have held off on posting and I could have gotten all the answers in both, but I'm 99.99% sure that all that is is they implemented their traits in terms of Fn, FnMut, and FnOnce from the ops module. You can do:impl MyTrait for T { }And then MyTrait is on everything that impls YourTrait. You can't impl the Fn traits yourself without being on nightly but as far as I know absolutely nothing stops you implementing other traits in terms of them.Dyn is just Rust 2018 syntax for trait objects. I'm pretty sure that those two features get you as far as bevy, I don't think it needs anything more than that.The last trick, though, is that with some macro magic you can define macros that call macros, and one of those macros can call another macro like M!(a) m!(a, b) m!(a, b, c), etc. up to a specified number of parameters. This lets you then get around Rust's lack of variadic generics to impl your traits that want to use tuples and/or callables and/or whatever for up to however many arguments. Most libraries that do this stop at 32. You can then go one step further and make the trait your implementing for the tuple know how to return a runtime description of it using std::TypeId, which with not that much more cleverness lets you build HashMap and do type-safe runtime dynamic access to it, and if your original trait that let you bridge this far contains the logic for manipulating the Any it can just be asked nicely to unpack the Any and do whatever, without the piece driving all of this ever even knowing what the types were, and you've just safely abstracted this out to an interface that is basically "please hold these two opaque values for me and give them back when I ask" as your driver. it's even sufficient to do scheduling based off dependencies: TypeId is Eq, Ord, etc., so you can compare them and sort them and such.Obviously in practice it's like HashMap, Any> or whatever, and there's libraries to make it much easier, but this is the idea. URL: https://forum.audiogames.net/post/572585/#p572585 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @15, yeah, definitely interesting. I probably won't use this, unfortunately, for some time, as its documentation is seriously lacking. Its a really, really nice implementation of a game engine, but its documentation needs some serious work (e.g.: pretty much nothing is documented in the rustdocs). URL: https://forum.audiogames.net/post/572587/#p572587 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @11 I think the piece you're missing are resources. If you need some global, whether it's an asset or TTS server or whatever, you add it as a resource to the world, and can then retrieve resources by type in specific systems. I haven't investigated Bevy's asset story yet, but I imagine it operates that way or similarly enough.Anyhow, use whatever works to make great games. The more tools in our toolboxes, the better we are as developers. And the more great games we have, the better off we are as a whole. URL: https://forum.audiogames.net/post/572592/#p572592 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? What’s rust? URL: https://forum.audiogames.net/post/572655/#p572655 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @18A [programming language], fairly good for working with hardware from what i've heard. URL: https://forum.audiogames.net/post/572657/#p572657 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? If you have to ask what Rust is, you will likely find it a frustrating experience, but it's a native-level language which nonetheless manages to offer a lot of higher level features, and unlike C/C++ you basically can't shoot yourself in the foot if you get it wrong because the compiler will be all "this would crash your program". Lots of places are adopting it for web backend and things like that even, because it manages to be (almost) as nice as Python but with like 20 times the performance.However you have to change how you program for it some (i.e. no classes) and if you've never worked without a garbage collector before lifeteims and the borrow checker are a brick to the brain, etc. It's a good language, good for games definitely, just a very advanced one that solves particular problems well and doesn't try to be anything other than what it says on the tin. URL: https://forum.audiogames.net/post/572705/#p572705 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? Not to start a nerd war, but in response to "what am I missing by not just doing this myself?" I found this interesting bit from the Bevy 0.2 release announcement:Bevy uses multi-threading throughout the engine: ECS scheduling, asset loading, rendering, etc. Before this release it used Rayon for almost all of these tasks. Rayon is nice because it is generally as simple as calling some_list.par_iter().for_each(|x| do_something(x)). Rayon then automatically breaks the for_each into tasks and runs them on as many cores as it can. Rayon is a great choice if you want to easily parallelize code, but it has the downside of being pretty cpu-hungry.Bevy (and a number of other rust game engines and ecs frameworks using rayon) have received feedback that they were overly cpu hungry / usage was not proportional to "real" work done.We decided to resolve this problem by building a custom async-friendly task system, which enables the creation of context-specific task pools. For example, you might have separate pools for compute, IO, networking, etc. This also gives us the flexibility to load balance work appropriately according to work type and/or priority. The cpu usage wins have been huge: Maybe there's some .dont_be_cpu_hungry() call hidden in Rayon, but if there were, I'd expect one member of the ecosystem to just use it and get on with their day. Yet Bevy built a new task scheduler to meet actual need.So maybe the answer to what you get is: you get a set of abstractions that folks who are smart and have spent lots of time in the space created and tuned, so you can get on with your day and tell stories or express ideas without player complaints that Rayon is gobbling CPU, or probably bunches of other issues you haven't anticipated. Then, if you *do* have an issue, you get a community of folks who support you in solving it, and your solution may be generally applicable to more people than just you.Maybe I'm getting lazy as I get older, but if I have a destination in mind, I'd rather just get there and not get bogged down in details along the way. When I was 20, I was all over patching my kernel to squeeze out every last bit of audio latency and performance. Now, at 40, I just want the damned optimized kernel so I can make music. Same with game dev. If you can give me a performant, ergonomic way of organizing my idea so I can focus on that rather than the nerdy implementation details, I want that. And if I have to dive into the nerdy implementation details, I hope I can do that work once and help someone else, not just do it and have that be that.Anyhow, hope the documentation situation improves. For my part, even with the basic docs and a few answered questions on Discord, I've made a decent amount of progress on my little roguelike. Plus I'm having lots of fun, which is nice in today's sucky world. That's good enough for me. URL: https://forum.audiogames.net/post/572733/#p572733 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @nolanI feel like you think I'm trying to shoot Bevy down or something. I'm not. If their answer to unique features is "now we have better scheduling" etc, that's cool. But there's a difference between a library I can implement in a Saturday and something that has things like that. Just because you can implement a thing in a Saturday doesn't mean that you should, but Bevy has done a pretty bad job exposing the things that you can't implement in a Saturday and spends all their time on "this is a basic ECS library, here is an explanation of what an ECS is" in the documentation and stops there. I know what an ECS is, if someone wants to sell me their library they should be spending a lot more time explaining why someone who knows the problem domain wants to use it, not explaining the problem domain. URL: https://forum.audiogames.net/post/572737/#p572737 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? Ok, the thing that explains the feature set for those who don't need to have an ECS explained is apparently this blog post. For instance Commands, which I don't thinka re even mentioned in the book, the reflection subcrate, etc. It looks like there's stuff but 90% of it is just undocumented right now. URL: https://forum.audiogames.net/post/572739/#p572739 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? I do have a question. I'm using winit, erupt, etc. and creating my window, possible drawing surfaces, etc., manually, just so I can say I went through the experience (not to mention its fun, though a lot of code). Winit has a .run() method on its event loop:pub fn run(self, event_handler: F) -> !where F: 'static + FnMut(Event, &EventLoopWindowTarget, &mut ControlFlow)This is something I've ran into a lot, and am curious on an ergonomic way of solving it. I want to do something like C++'s lambda capture specifier [&]. One way I know of, that works, is to make all the things I'm going to need static, but I really, really don't like doing that. I can use a move, at the cost of having all of this inaccessible after the .run() method exits (though that's not a problem here). So what, specifically, are my options? I want my game loop to run somewhere, but is the window event loop a good place for all of that work to go? URL: https://forum.audiogames.net/post/572741/#p572741 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? I don't necessarily think you're trying to shoot it down, but I also don't think it's fair to expect a fully-baked project from a solo developer. I'm kind of in the same boat with godot-accessibility. To document it would involve me figuring lots of stuff out, like how to create polished audio and video of the game development process, which is a distraction from getting things done. It's fair to note that it doesn't sell itself well right now, but it just came out of stealth a month ago and now has a bunch of eyes on it, meaning it'll probably be refactored, meaning any huge investment on docs right now is probably not wise. So it definitely isn't ready for someone expecting to write code and not touch it for months, but that's why it's 0.2, and saying it doesn't sell itself well is like saying that an infant can't competitively run a 100-yard-dash. I wish commands were documented in the book too, but the book itself admits that it isn't done and there's a lot more. And they just changed their transform system for the better in a way that resolves an issue I myself hit with it recently, so had they documented how transforms used to work, those docs would be outdated now. URL: https://forum.audiogames.net/post/572744/#p572744 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @24In general things are already 'static, unless you're using some sort of complicated reference setup. If the app just starts and immediately goes into the UI loop then move it into the closure. I'm not immediately thinking of cases where that can't work unless the API of that is limiting in a couple ways that probably shouldn't be the case.For the more complex cases, you can either use interior utability on the type holding your state, wrap in one of the cell types, wrap in arc, wrap in mutex, etc. and move that into the closure, while also storing it other places. For the multi-threaded scenario you probably want Arc>, which can be treated like a Mutex because Rust is smart enough to auto-deref through multiple levels of indirection, and can be handed out to multiple places that aren't the loop because Arc.@25If it comes to it I'll go read code. I'm not asking for "explain how to use everything". But just making the above-linked blog post the homepage would have gone a long way toward telling me why I want to use it.Have you solved scripting? I'm curious. That's the one thing I don't see an easy way to do in Rust. You can easily get scripts that run after the fact and respond to events, but if you want to i.e. intercept death and do something else instead, that seems hard. For single player stuff, implementing it all in Rust is probably fine, but for the kinds of projects I'm considering I'd need the ability to give out untrusted access for other builders without handing them the source code. URL: https://forum.audiogames.net/post/572748/#p572748 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @26, thanks. There are scripting languages like Rhai available for Rust already(you can also make your games a WASM host). URL: https://forum.audiogames.net/post/572749/#p572749 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? Yeah, but you can't necessarily run it where you need to with something like Bevy because mutable borrows in immutable, parallel contexts. You effectively need a synchronous event system where the script can return something out for a lot of cases, i.e. wants_death, script says yes, then die. if that happens across multiple ticks some of the state management and the model for potential builders starts getting tricky. URL: https://forum.audiogames.net/post/572751/#p572751 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @28, yes, but its potentially doable. URL: https://forum.audiogames.net/post/572766/#p572766 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? Bevy's author has stated that he considers in-engine scripting to be an anti-pattern. That said, most engines I'm familiar with support plugins, so I'd not be surprised if someone binds one of the existing Rust scripting languages to a number of existing engines.I myself am not terribly interested in untrusted code, but I am thinking long-term about handling mods or DLC via something like wasmtime. Basically iterate through a directory of .wasm files, call an exported function on each with an AppBuilder, and modules can register their own components/systems. There are obvious issues with that, but I've got more interesting problems at the top of my stack at the moment. URL: https://forum.audiogames.net/post/572782/#p572782 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? It's an anti-pattern until you're in a situation where you don't want to hand the entire source code of the game to your level design team and/or want to get volunteers/contractors/whatever involved in level design. If I could trust whoever would help me in the future not to just walk with the entire game I would just do it in Rust, but I can't, and I suspect Bevy's stance on that isn't going to last because a whole lot of other people can't, either.But also, for any game where you've got truly one-off behavior for puzzles and stuff, to implement that in Rust--to require whoever is building it to learn Rust, even--is kind of...not ideal. Maybe Bevy just isn't for that sort of thing and I should consider something else, but it's a shame, because the rest of the ECS stuff would be useful and is what I'd need anyway whenever I get that far. URL: https://forum.audiogames.net/post/572817/#p572817 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @31 *sigh* Geez. That's why they're doing an editor, and a human-readable and human-writable scene format, so you can build your behaviors out as components/systems. Then your designers, level editors, unicorns, smurfs, whatever, use the editor and chain together those components and systems to realize their designs. And that's why I'll be working on the editor UI to make it accessible, like I am with Godot, so blind and sighted folks can collaborate on games rather than the mostly clusterfucky situation we have today where sighted developers make games they think we want and usually (but not always) flounder. And you can always easily use the ECS elsewhere, but yesterday you didn't even see what it had to offer you, so I don't know why today it's a shame you can't and yesterday it was something you didn't seem to understand the need for.At the end of the day, it's no skin off my nose which engine you prefer, and maybe I should just let it slide when you seem to immediately write something off or come down against it. I'm just trying to talk about things I think are neat, and it bugs me a bit to always have to do so from the perspective that the idea is wrong, or not good enough, or fundamentally broken, or not far enough along, or whatever. I'd like to talk about this stuff, it's just exhausting feeling like I'm perpetually doing so from the bottom of the hill.I don't mean to seem harsh, and I'm not upset at you. But I don't think you have the full picture either. If you don't want to get it because the homepage or documentation isn't exactly what you wish it was, that's fine. But please at least don't assume you have the full picture if you haven't actively seeked it out, please don't expect me to hand out the full picture in my responses, and please don't expect a 0.2 project to have all its ducks in a row when it looks for community help precisely to accomplish such a massive amount of duck-arranging that one developer can't on his own.FWIW, I'm curious how this editor approach will work. I, like you (or at least, how I *perceive* you) want some sort of separate editor, because I want to be able to work with story creators/sound designers/maybe even artists if I try doing some sort of accessible indie game. And I don't necessarily want to hand them all the source code. I'd rather give them some behaviors they can work with, and build out those behaviors where necessary. It remains to be seen whether Bevy can achieve that. But Godot can actually do quite a lot of stuff that looks scriptable without scripting, so I have some confidence that the Bevy team can come up with a similar set of abstractions. Or, at least, I'm willing to assume they're heading in that direction unless shown otherwise. URL: https://forum.audiogames.net/post/572837/#p572837 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? Erg. Please, please tell me how I came down against it? I simply said that I didn't see the features it had to offer? And then when you showed me some and I found some more, I changed my mind about it. I went so far as to research it further on my own, even, and when I said it was something that I thought could be implemented in a Saturday I initially even followed that up by saying it's probably still better to use a library. And all I said on the accessibility front is that if it didn't have a couple things it would be hard to add them, and you said it had them or was at least interested plus also it's early days and that'll make it easier, and I said great and that I hope it happens, even that I thought UIA wouldn't be that hard.So all that's left is "They should document better, because it would have stopped me from overlooking it, why isn't the blog post I had to go digging for their homepage" and "they don't have scripting which is something I really need, but I think they'll change their mind". how is this coming down against it? Lots of things can work fine without scripting, but it's a shame *I* can't use it because the things I'm contemplating doing need that is basically my entire criticism of it at the moment. I'm not even saying it can't do scripting, either, just that it can't do a very particular kind of scripting that's important to a very particular kind of game developed in a very particular kind of style and with a very particular team dynamic which happens to be my end goal, and now I'm even disappointed that it probably can't solve my specific problem because it otherwise looks amazing to use.I really don't get why you're mad at me right now. We transitioned from "I don't get it" to "I get it, how do I solve a concrete problem" a while ago, and not getting something isn't coming down against something, either. URL: https://forum.audiogames.net/post/572859/#p572859 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? So I haven't looked into how Bevy can or can't handle this, but I think the solution to scripting is a continuation. Possibly in general for all of Rust, if I'm being honest. To use death as an example, split it like this:fn do_death(args) { enqueue_script("script", death_after_script); } fn death_after_script(arg: ScriptResult) { // do we die or not? }You can use interior mutability to enqueue the script and the system can avoid enqueueing the script and do whatever inline if there's not one. Then at the end of the current tick, you exhaust the script queue. The downside of this is that scripts don't technically execute at the very instant they should, but they don't execute some random number of ticks later and they get the ability to intercept actions which is what you need for the sorts of game where there's weird one-off objects all over (I guess we call that an adventure game, but it applies to lots of other things). I don't know for sure but I don't think it would be very difficult to deal with not knowing *exactly* when your script would execute, especially since you kind of don't know that anyway.Not sure if this can be done in parallel: I can think of ways to do it, but likely not ways that play nice with Rust libraries as written. And if Bevy doesn't give you the ability to do one-off entity access by id it's dead in the water with Bevy specifically. But it does solve the problem for anything single player (you absolutely don't need parallel script execution for single player) and offhand I don't see why Bevy wouldn't give you the feature you need for it, I just don't know how to find out if it does quickly. URL: https://forum.audiogames.net/post/573047/#p573047 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? I took a day to think things over.First, I'm not mad at you, which I explicitly stated:I don't mean to seem harsh, and I'm not upset at you.Second, maybe I've just had a shitty week, and that colors how I'm reading text. I turned 40 last Monday, and instead of having a celebration for this once-in-a-lifetime event, I'm hunkered down trying not to catch COVID and telling folks that over-the-hill death-themed motifs can fuck right off. Then RBG leaves us. That's not an excuse to do whatever I want, but my head is in a kind of "the world is kind of shitty right now, so let's try harder to be more positive, or at least ambivolent" headspace.That said, I read lots of your word choice as dismissive, not really curious, but like you've already made up your mind about something and are just trying to tell other people how things are. If I misread, I apologize. It also felt a bit like every time I tried to help or share a different perspective, you popped right back up with another negative thing or criticism.If Bevy or Godot or whatever don't work for you, that's fine. I guess I don't pop into BGT or Python or PureBasic threads and tell folks there how they'll rethink their decisions or how their languages and frameworks don't work for me. It just doesn't seem to contribute to the discussion. FWIW, I think BGT is a bit of a dead end, and don't recommend it to folks. But I don't share that perspective with them because what would that serve?Anyhow, I'm not going to continue the thread in this direction. I just wanted to talk about Rust and game dev, not how Bevy seemed "massively, massively" over-engineered or how it was poorly documented or how they were making wrong choices that weren't what you wanted. Not saying I'm right and you're wrong. Just explaining why the exchange tired me and made me disinclined to continue.Thanks for reading. Enough prattle from me, back to work. URL: https://forum.audiogames.net/post/573160/#p573160 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? @35Maybe I was also negative and am not seeing how, I'm not sure. I've been literally in a room alone for 6 months. So maybe things are coming out harsher than I intended on my side as well.All I was really looking for from the discussion was something that they do that's not easy to implement myself, which they have, it's just stupidly hard to find and it took you a while to give it to me. If I open a restaurant and I sell amazing food and then I go way out of my way to stick the menu on the north pole or something, it's kind of the same thing as what they've done--and if I go telling my friends about the hamburger at this amazing menuless restaurant, then getting back "but outback steakhouse" isn't unreasonable. I should be telling them about the 10-layer chocolate cake and also it's on fire. Bevy's command/event stuff, custom scheduler, I'm not sure what else but just those two are actually enough to put it in the realm of no I probably can't just throw a thing together.I'd have not tried to get info out of you on it if I didn't think there was info to have gotten; in so far as I know about your work, I don't think you make bad technology choices. I'd have disengaged a lot earlier if I did.In either case, I do think you can get it to do parallel scripting without modification, to bring this back on topic. Looks like they've got direct, unsafe component access that's safe as long as you don't have to concurrent mutators, so if you define "roots" in the object graph and mandate that a script can only see what's below the root and figure out a way to get a system to run that has no concurrent updaters, I think you can make it work. Combine it with their property thing and maybe some custom derive and it's probably not very hard at all to get a reasonable thing going on. URL: https://forum.audiogames.net/post/573173/#p573173 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? Sorry you've been that isolated. I know that sounds kind of trite, but I do mean it.Anyway, I don't doubt you can add scripting as a plugin, and Cart fully expects folks will. He just won't be shipping it like Godot does GDScript. And I can't blame him TBH, because GDScript is currently going through a huge refactor, and C# Godot support has only recently come to mobile and still isn't on UWP. So in the sense of providing a good engine, I'm finding the choice of building a core that works everywhere and encouraging others to build scripting plugins refreshing. URL: https://forum.audiogames.net/post/573190/#p573190 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Audio Games with Rust?
Re: Audio Games with Rust? If I was contemplating single player stuff, I'd just not bother with scripting and implement it all in rust. I agree with that part. it's just: what do you do about the weird one-offs? ECS never seems to have a good answer to that. I don't think you should ever write a lua system or something, you might as well not take the perf hit. And yeah editors. But if you give something to a builder and the builder needs something you don't want it to be "can you add a component that will be added to 1 entity which..." every. Single. Time.Then again I guess there's lots of muds that always just went with "bring x item to point y then kill z". And I know a lot of World of Warcraft is that way. But really I should just stop thinking "First I'll do Synthizer then I'll do physics thing then MMO happens" and answer these questions later, I guess. 6 months is practically an eternity in Rust game dev land anyway. URL: https://forum.audiogames.net/post/573233/#p573233 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector