Haven't played "Tiny Glade" since it's unreleased and I missed out on the demo, but it looks very well done and potentially fun for creative types.
Linking this article because it aggregates some cool tidbits like the procedural wall generation https://80.lv/articles/exclusive-tiny-glade-developers-discuss-bevy-proceduralism-publishers-cozy-games/
With such a complex system like that it would probably be beneficial to actually build the parts you care about and take advantage of libraries handling the querying of Data like ECS and rendering with bevy. Otherwise you'll run into the risk of being limited by the library in one way or another.
Define a bunch of structs that you can use compositionally in bevy's ECS. Create specific systems that react to components being added, removed, or changed. Set conditions like Burnability, Durability, Temperature.. etc. React to those conditions or thresholds being met. Your reaction could even be a component. Damage(5), IgnoreArmorDamage(3), CurrencyUpdate(-5), GiveItem(Item::Sword(Stats {..}))
It basically gives you a foundation that feels like scripting but with the power of compile time safety for virtually everything. You get to "model" the data how you want instead of being limited or overwhelmed. And with ECS it really helps make things feel like Lego blocks that you can easily reuse across the entire project.
I haven't watched yet but I tossed the transcript into claude and chat gpt
ChatGPT:
Claude:
The key is to know your game and audience, start marketing early, leverage Steam's tools, and continue nurturing your community after release. Authenticity and active engagement are crucial for success on Steam.
I want to say I think they are talking about how great it would be if we could kick JavaScript to the curb and just use WASM for everything. I'm kind of in the same boat.
However, WASM currently doesn't have direct access to things like the DOM, if I recall correctly (this might be the guardrails the OP was referring to?). So, it's only really good for things that are heavy on the CPU. But, as a counterpoint, I don't think it's from a lack of effort from anyone's point. The last thing I remember reading was that there were still a lot of things being worked on to make it happen.
Quick Perplexity search:
There are proposals and efforts underway to allow WASM to eventually call DOM APIs directly, without going through JavaScript. The main one is the "Interface Types" proposal which would allow WASM to bind to Web IDL interfaces.
Another related proposal is WASM GC (garbage collection) which was announced at Google IO 2023. This will allow WASM to share the same managed heap as JavaScript.
As a wise person once told the Internet, don't worry about picking the best one. But if you really had to pick one just start with the rust book. https://doc.rust-lang.org/book/ I would suggest to just dive in with a specific need you want to solve and instead of using your language of choice just use rust and look up stuff as you go. Hands on learning is usually the best learning. The only thing you need to "learn" is how to follow the ownership/borrowing paradigm that rust brings to the table.