0.14 Bevy Jam

[unreal narwhal]

lgtm

[slender belfry]

🎉

We did it! Good job team!

[bitter sparrow]

now #crates post :)

[slender belfry]

I think you can just remove the "Hello Bevy Jammers! ✨" and it will be good otherwise

[bitter sparrow]

k done

[slender belfry]

thanks!

[bitter sparrow]

now i can prepare for bevy jam 5 myself :)

[slender belfry]

Hehe

[unreal narwhal]

nice job y'all

[slender belfry]

I'm so happy with how it turned out 😄

[bitter sparrow]

i think we ended up with a pretty nice template. and it'll be even better for bevy jam 6

[unreal narwhal]

I'm planning to record a video for the template tonight, which I'll put up tomorrow as long as it doesn't drag on for some reason

[slender belfry]

Thanks a bunch 🙂

@unreal narwhal dunno if you've seen this, but you might be interested in it: https://github.com/TheBevyFlock/bevy_quickstart/blob/main/docs/design.md

[unreal narwhal]

definitely, thanks for the link

[slender belfry]

@bitter sparrow I found a typo: https://github.com/TheBevyFlock/bevy_quickstart/pull/167

[bitter sparrow]

not a typo

the twist is the player was the monster all along

[unreal narwhal]

200iq'ing the theme voting

[slender belfry]

Is that for the "You are not the main character" theme?

[bitter sparrow]

it is now

[unreal narwhal]

I think there's two chain reaction themes suggested in the list 😆

[bitter sparrow]

there's a few uncaught dupes

i definitely got deja vu a few times

[slender belfry]

I'm kinda surprised how few votes AutoCAD got

That sounds so intriguing as a jam theme 😄

[unreal narwhal]

I feel like autocad is suggested in every jam

[slender belfry]

Oh, really? I guess I never noticed until now

[unreal narwhal]

bevy editor almost made it to the final lol

[unreal narwhal]

maybe just the last two after a search

[slender belfry]

3/5 counts as almost every jam tbf

[unreal narwhal]

lotta votes last time though

[slender belfry]

hehehe

Come joint us at Bevy Engine! We have

• Birds (3)
• Some people mining rocks
• CAD software
• No text input

[unreal narwhal]

3 birds and the people with rocks aren't even trying to hit them

[slender belfry]

smh my head

[unreal narwhal]

what is the purpose of Spawn? https://github.com/TheBevyFlock/bevy_quickstart/blob/f0bbb01a862ee8261c92ad30d7937deecca96abf/src/ui/widgets.rs#L157-L161

child_builder already has spawn: https://docs.rs/bevy/latest/bevy/hierarchy/struct.ChildBuilder.html#method.spawn

I don't think this is in the design doc

[bitter sparrow]

it's so that the widgets work on both Commands and ChildBuilder

[slender belfry]

To implement Widgets easily on multiple types

[bitter sparrow]

ideally it'd be implemented for World and WorldChildBuilder as well, but we didn't use that in the template

even more ideally this would be done upstream, and there is an issue for that

[slender belfry]

You could also manually implement Widgets for all these types, but using Spawn as an intermediate requires less boilerplate / duplication

[bitter sparrow]

this scared me

funnily enough the game i ended up making could have fit that theme

kinda

[slender belfry]

It’s an implementation detail, that’s why I didn’t include it. But what we just wrote on Discord should be a doc comment on Spawn instead.

[bitter sparrow]

i mostly didn't want to play and vote on 100 AutoCAD-themed games

[slender belfry]

I'm going to bed now, but I’ll add it tomorrow if no one else did in the meantime

[agile dirge]

Great job getting the template released, sorry for not helping out till the end. Had some last minute vacation plans :/

[slender belfry]

All good, you already did a ton 😄
Enjoy!

[lunar sail]

Huh, why does it show as Bevy 0.13 when it uses 0.14?

[slender belfry]

Because that was before we submitted it to the site, so we just edited the Foxtrot entry locally using the browser dev tools to see how the description looks on the site 😄

[lunar sail]

Oh that makes sense lol

[unreal narwhal]

uploaded, scheduled for about 4 hours from now (my usual release time)

[bitter sparrow]

https://github.com/TheBevyFlock/bevy_quickstart/pull/169

(this was gonna be a bug fix pr but i ended up doing some refactoring too)

if we don't like it i can revert and just do the bug fix

[slender belfry]

Just randomly woke up and decided to give a review on my phone 👍

[bitter sparrow]

gonna go to sleep and leave the pr hanging for now

[hidden pond]

FWIW I'm rather happy that I managed to get cargo generate support implemented, I'm also going to spend a bit of time looking into that new issue that was assigned to me.

[slender belfry]

Need a quick review on https://github.com/TheBevyFlock/bevy_quickstart/pull/173

[slender belfry]

Actually, I went ahead and added a whole bunch of PRs: https://github.com/TheBevyFlock/bevy_quickstart/pulls?q=sort%3Aupdated-desc+is%3Apr+is%3Aopen

[dawn crag]

looking at all_loaded, shouldn't we be using something like https://docs.rs/bevy/latest/bevy/asset/struct.AssetServer.html#method.is_loaded_with_dependencies ?

[slender belfry]

Yep: https://github.com/TheBevyFlock/bevy_quickstart/pull/169/files#diff-bdf8f2864749dd2b4823868900a52eec7ad79ffd2f09a9e187c9fe618d59e365R125

[dawn crag]

Oh cool, will take a closer look when I can

[slender belfry]

I'd be cool if you could chime in on these two comments since I'd like a third opinion:

• https://github.com/TheBevyFlock/bevy_quickstart/pull/169#discussion_r1682587698
• https://github.com/TheBevyFlock/bevy_quickstart/pull/169#discussion_r1682598477

Also, I linked your crate for the pipeline loading in https://github.com/TheBevyFlock/bevy_quickstart/pull/176

[dawn crag]

Played around with this and a few other patterns I was curious about. Without bringing in any other crates, I feel like that PR landed in a pretty good spot. I tried removing the AssetKey trait and it seemed a bit uglier.

Threw my thumbs-up on the HandleMap proposal, which seems better. I feel like AssetKey and HandleMap should probably get docs comments.

[slender belfry]

Would you leave AssetKey::load in?

[dawn crag]

I like FromWorld just fine, personally.

Actually, I wonder if you could do a reflect-powered

struct SfxHandles {
   step1: Handle<AudioSource>,
   ...
}

[slender belfry]

Probably, but that would be very intimidating for a template imo

[dawn crag]

Yeah, you're right. I think it's probably not possible to do in the scope of the template.

Re: FromWorld, I don't fully understand / haven't hit this bug myself, but this may be relevant: https://github.com/bevyengine/bevy/issues/11473

[slender belfry]

Huh, that looks very relevant to our case. Have you run the current code in the PR @bitter sparrow ?

[bitter sparrow]

in my pr? yea

it's because app.init_resource calls FromWorld right away

so you need AssetPlugin already built

which in this case it is

[bitter sparrow]

updated asset PR

[lunar sail]

Not to derail the Jam conversation (again), but I think I'll try to adopt the save-if option for cargo-cache after my vacation.
I think François requested that the Bevy cache is only saved on the main branch, so maybe that could also move @obsidian ravine's PR forward
https://github.com/bevyengine/bevy/pull/13040

[slender belfry]

@bitter sparrow I approved your PR and updated all of my PRs according to your comments 🙂

[slender belfry]

@bitter sparrow could I still get a word on https://github.com/TheBevyFlock/bevy_quickstart/pull/173 ?

[bitter sparrow]

yea commented just now

[slender belfry]

reverted stuffs

[bitter sparrow]

approved

https://github.com/TheBevyFlock/bevy_quickstart/pull/177

not fixing a bug or anything, just an editing pass

[slender belfry]

Nice PR, left some minor comments

[bitter sparrow]

ok i'll think about TryFrom, it might address all of the comments at once anyways

is it allowed for TryFrom to potentially return a different value each time you call it? like the random_step

alternatively it could be a raw impl PlaySfx { fn key() -> Option<SfxKey> { ... } } instead of a trait impl

@slender belfry pushed a particular design. lmk how it looks now

TryFrom impl is still possible, but the code may be simplified enough already that it would be overkill

[prisma delta]

Technically but that's pretty surprising

[obsidian ravine]

Yup, a cache made on the main branch can be used on another branch foo, but a cache made on branch foo cannot be used by main

It's strange, but just how Github caching works

[normal idol]

Noob failing in public here. Sharing my embarrassing triage & solution so other don't have to.

Update from future me: cargo clean and a complete re-build of all packages seems to have cleared it up. No changes were needed to the provided config.toml. No idea where this came from or really how it was fixed...

If you are on Windows getting the following error

❯ cargo build
error: expected a table, but found a array for `target.x86_64-pc-windows-msvc.rustdocflags` in E:\path\to\repo\.cargo\config.toml

Make sure you switch to Nightly rustup default nightly and uncomment the rustflags options under the windows target.

rustflags = [
  # Nightly
  "-Zshare-generics=n", # This needs to be off if you use dynamic linking on Windows.
  "-Zthreads=0",
]

If you don't use nightly or you leave the example config toml unedited from what is given, it won't build with the config.toml.

Unfortunately for me, switching to nightly broke builds inside and outside this project because the proc-macro crate was trying to use an unstable feature. I could build successfully again by switching back to stable rustup default stable albeit without LLD. 🤷

If this is not the right way to do it, please help 🙃

[bitter sparrow]

i don't use windows, but this is surprising to me

the error is complaining about rustdocflags, not rustflags

[unreal narwhal]

I tried compiling on windows just now but didn't hit the issue unfortunately

[bitter sparrow]

was this the line in your config.toml?

[target.x86_64-pc-windows-msvc]
rustdocflags = ["-Clinker=rust-lld.exe"]

[normal idol]

Yes. Should I change it to curly brackets or something? (isn't that what a table is? square brackets is an array)

[bitter sparrow]

it kinda seems like that's what the error message is suggesting (not exactly curly brackets cause that's not the syntax in toml)

but that seems wrong

mmm

is your file stored as config.toml instead of .cargo/config.toml?

[normal idol]

I'll commit my broken branch and share it in a moment

For the record, rust docs claim that the type of build.rustdocflags is a string or array of strings, not a table. 🥴

[bitter sparrow]

i suspect there are two different types of config files here that use rustdocflags differently

from some discussions on github about the error message

[bitter sparrow]

actually i mightve been wrong about this, i think toml supports this as either section = { ... } or [section] syntax :p

[normal idol]

Here's what I did just now, and it looks like LLD isn't being used because the compilation is taking >5m

• rustup default stable && rustup update to get back on 1.79.0
• cargo clean just in case
• commented out rustdocflags = ["-Clinker=rust-lld.exe"]
• deleted ~/.rustup/tmp
• started another cargo build
• waited 10m, it wasnt done
• uncommented rustdocflags = ["-Clinker=rust-lld.exe"]
• cargo build yet again. It's about halfway done. Let's see what happens.
  link to the broken config.toml

[bitter sparrow]

if it's building all dependencies from scratch, >5 minutes is reasonable. future builds should be like 5-20 seconds

[normal idol]

There must have been a poison pill artifact in the target directory or something because after the above steps the build completed without error. And the second build was instant!

So yeah no changes to the config.toml from the template and now it works for some reason. Thanks for the rubber ducking

[bitter sparrow]

yeah the .cargo/config.toml and Cargo.toml both look good to me so that must've been it

[normal idol]

Updated my original post so people don't get confused

[slender belfry]

Glad to hear it worked in the end 😅

@bitter sparrow I approved the audio thingy

[inland wyvern]

I've joined a team and edited my post in #jam-find-a-team but now I'm wondering should we try to get everyone who has joined a team to remove their post so it's more of a current list of people actively looking?

[slender belfry]

Don't think there is much hope in getting much order in when the jam starts in less than 24 hours tbh

But something to consider for next time 🙂

[bitter sparrow]

see: #1258521739395203174 message

[hidden pond]

Also for the template...would we want to make a post-Jam survey or something people can fill out so we can get feedback about the template and information regarding it? It would be nice to see, and could help us make things a bit better in the future. 😛

[slender belfry]

Definitely!

[hidden pond]

Cool! I'll work on something when I get a chance. I'm kinda surprised there was less immediate pushback ngl

NGL I'm definitely interested in how people went about setting it up.

[lunar sail]

If you do, please include a CI section, I'm always looking for ways to improve it 👀

[hidden pond]

Probably should setup a hackMD or something so we can collaborate on what we would like to see in it, and all that. And so I can get feedback on questions and the like.

[slender belfry]

I think the design.md helped. Some people even pointed out they liked reading it, which was nice 🙂

[hidden pond]

definitely.

https://hackmd.io/@chanku/Sy9SwmudA/edit

Not sure if that worked or not, but

[bitter sparrow]

403 forbidden

set reader permission to Everyone and then writer permission to "must be logged in" prob

i can see it now

[hidden pond]

Yeah.

(BTW feel free to adjust the formatting and stuff as necessary. I just put something together quickly)

[slender belfry]

@inland comet have you opened a rustc issue for https://github.com/bevyengine/bevy/issues/14246 yet? I have thought about opening one for you, but I think you know way more context here and are better able to describe how you found out what you did.

[slender belfry]

@bitter sparrow I just discovered this: https://github.com/bevyengine/bevy/blob/main/crates/bevy_dylib/src/lib.rs#L37-L54

If I understand it correctly (and I may not), this would enable us to kill off the dev and dev_native features 👀

[bitter sparrow]

maybe. we also enable bevy/bevy_dev_tools and bevy/file_watcher and bevy/embedded_watcher in those features tho

and in theory a user could put other things there like dep:bevy-inspector-egui

if cargo supported different default features depending on the profile.. that would be nice

[slender belfry]

ah, true

too bad

[slender belfry]

Remember the issue with --release from earlier?

We are investigating the rustc bug

turns out it only happens specifically on lto = "thin", which I find interesting

[bitter sparrow]

yeah that repro is tiny

[hidden pond]

Ah rustc bugs and bevy...name a better couple /jk

[bitter sparrow]

hm there are a few other open issues mentioning this PR: https://github.com/rust-lang/rust/pull/103353

[slender belfry]

Funny thing is, that example they add is nearly one for one the repro. Only difference is that the example uses static linking and the repro uses dynamic linking

[bitter sparrow]

i have a clippy.toml with avoid-breaking-exported-api = false in it in my template, and i have no idea where i got that from

i was only able to find this issue with no responses https://github.com/rust-lang/rust-clippy/issues/10689

it seems that avoid-breaking-exported-api is true by default, which suppresses certain clippy lints for pub fn... which makes no sense in a binary crate

[inland comet]

I haven't done it yet, I ended up being too busy before going on vacation. Feel free to report it if you'd like, otherwise I'll do it around next Thursday when I get back.

[slender belfry]

I'll wait then, thanks 🙂

[gilded lance]

So I've tried out the template and got this when cargo run-ing it:

no idea what the template is doing, normal bevy projects dont do this

I'm running on Linux with X.Org

Ah... it's just the wayland feature being enabled

RE: licensing assets, I'm no expert, but it might've been more convenient if there was appropriate license files in the assets/ folders, which document which assets are from the template and have the appropriate license

because the template just tells me to delete the license files... so I'll have to add in something in this vein later

[bitter sparrow]

yeah that was added recently to support wayland

but it does require some additional deps on linux to build, which it seems some systems may not already have installed

not sure what the best solution is then... ^\_(``/)_/^

[bitter sparrow]

yeah the LICENSE files currently in the template don't apply to anything in assets anyways so it's correct to delete them for the user

including asset licenses in assets kinda makes sense, but then you'd want the release workflow to know to delete them, which is awkward

we could put a small README.md in the cargo-generate branch that only includes the # Credit section from the main branch README.md

[bitter sparrow]

created an issue for this: https://github.com/TheBevyFlock/bevy_quickstart/issues/182

[bitter sparrow]

issue for this as well: https://github.com/TheBevyFlock/bevy_quickstart/issues/183

[lunar sail]

Created a PR for the save-if option, but it's not tested yet so I have no idea if it actually works
https://github.com/Leafwing-Studios/cargo-cache/pull/21

[slender belfry]

Why delete them?

But also: why not keep them as-is only in the credits? I don’t really see the benefit of having them in two places

If the user deletes the credits, they can still access the original information in their git history or on our repo

[slender belfry]

If they don’t delete the credits however, should they also keep both lists in sync?

[hidden pond]

I just submitted a PR btw: https://github.com/TheBevyFlock/bevy_quickstart/pull/184

It's nothing major so it's not needed right this second, but.

[prisma delta]

Prototype announcement post:

Hi @everyone: looking for an excuse to mess around with Bevy? Bevy Jam #5 is starting now! Come hang out in #jam.

The theme is: THEME.

[slender belfry]

Quick, to the point and friendly. I like!

[bleak grail]

that is a hard theme 😱

[slender belfry]

It’s meta 🤓

[bleak grail]

||well facebook fits a lot of the potential themes:

• Nothing is permanent, like how it destroys our attention span
• Chain reaction, you have to post something to trigger reposts
• You are not the main character, everyone is...
• Cycles, every trends work in cycles
• Too many friends, that one is easy 😄
  ||

[bitter sparrow]

the credits don't contain actual license text, which may be required for some asset licenses

[slender belfry]

Brilliant 😄

[bitter sparrow]

just filesize ig

[slender belfry]

Teeeeeechnically, wouldn’t all the dependencies' MIT licenses also have to be included as well anyways?

[bleak grail]

on that topic, and no I didn't check, you did build a BOM with the licenses of all the dependencies and included a screen showing them? 😄

[slender belfry]

Not for the assets in our case, but for our transient crate dependencies

[prisma delta]

Oh right, Embark had a nice tool for this IIRC 🙂

[slender belfry]

Oh, do you have a link?

[bleak grail]

https://github.com/EmbarkStudios/cargo-about

[bitter sparrow]

board of medicine?

[bleak grail]

there's also https://crates.io/crates/cargo-bom

[prisma delta]

And an alternative: https://github.com/sensorfu/cargo-bom

[bleak grail]

bill of materials

[hidden pond]

Bill of Materials

[bitter sparrow]

yeah. does cargo download license text?

our template doesn't actually include a copy of all of our dependencies. just xyz = "version" in Cargo.toml

it only includes the dependencies after you compile

[bleak grail]

yup, the bom is needed in the file built

also, I would probably recommend freezing the template for the duration of the jam. or at least versionning it

[slender belfry]

byte-order mark /s

[bitter sparrow]

hm technically we do have a version but we keep releasing to the same version 😄

[bitter sparrow]

what's the benefit of doing this?

it sounds reasonable but i'm not sure

[slender belfry]

When someone uses the template, they already have a frozen version right there in their own repo

[bleak grail]

not confusing your users that see an update and will try to use it on their existing jam project

[slender belfry]

Thanks for the link!

[bleak grail]

also you do the jam so less time to work on the template

jam is mandatory for everyone in this work group right?

[prisma delta]

Yep, strongly agreed here 🙂

[prisma delta]

😭 I wanna do engine dev

[slender belfry]

Engine dev simulator

[inner mauve]

when itch.io crashes from too many submissions, does that make it a game jam jam?

[slender belfry]

Yeah at least for me the jam means a de-facto freeze on anything else anyways 😄

[bitter sparrow]

would "freezing the template" be something specific you do on the github repo?

or just not merging anything

[bleak grail]

not merging pr 🤷‍♂️

[bitter sparrow]

bet

[dawn crag]

jam is coinciding with a crunchy work week this time 😦

[slender belfry]

That's fair enough.

[lunar sail]

The save-if PR is ready now: https://github.com/Leafwing-Studios/cargo-cache/pull/21
@bitter sparrow @obsidian ravine @slender belfry if one of you has the time for a quick review, it would be highly appreciated :)

We could also think about using this pattern for the quickstart template, but it's probably not worth it.
For small jam projects you probably want a separate cache for each branch to speed up CI even when changing dependencies etc

[slender belfry]

I can check it later or tomorrow 🙂

[obsidian ravine]

Approved!

[lunar sail]

Thanks! Turns out I need @prisma delta's approval as well due to the merge policies

[obsidian ravine]

Yeah no worries :)

[lunar sail]

Merged and released, we can now adopt it in the Bevy CI PR :)

[agile dirge]

i was a bit worried this pointed to my design pattern repo, which is outdated, but thankfuly both take you to best practices? :D

This is also an interesting ending, we do have a pattern, it's just not very user friendly

[obsidian ravine]

Done!

[slender belfry]

whoops 😄 I was indeed intending to link to your repo, haha

[slender belfry]

Yeah, that is true

[agile dirge]

Lets keep it this way for now 😅

[slender belfry]

https://github.com/TheBevyFlock/bevy_quickstart/pull/185

Is it alright if I merge this during the jam? It’s trivial typos.

[slender belfry]

(merged)

[hidden pond]

Did you have anything in particular you wanted me to include or get feedback for when it comes to CI/CD for the survey thing I'm working on?

[lunar sail]

Hmm good question.
I guess for CI the most important question would be if it feels fast enough or if it slows down development.

For CD I wasn't really involved, maybe @bitter sparrow or @slender belfry have some questions to ask

[bitter sparrow]

made an issue to remember to do a reflection / post-mortem https://github.com/TheBevyFlock/bevy_quickstart/issues/192

[bitter sparrow]

..btw i can see Dependi in VS Code now, and for some reason it says install count = 3 lol

[bitter sparrow]

wondering if the workflows.md doc would be a bit more readable with all images in a click-to-expand

(it's already very readable though)

so you can see the full picture of all the steps required before looking at example images of each step. which some users may not need to see to know what to do anyways

[unreal narwhal]

for template feedback (or maybe not idk if it applies), I saw someone yesterday trying to order plugins to control when systems ran so that resources, etc were available when systems were running.

Might be useful to have a brief piece of documentation introducing plugins?

[slender belfry]

I remember!

[slender belfry]

Hmm, fair enough. Do you think adding that to the design doc would make sense?

[unreal narwhal]

yeah that seems like a good place, since "Plugins as project organization" is a design doc thing

[slender belfry]

👍

[bitter sparrow]

introducing plugin-per-module as a design pattern is reasonable, but something like "what are plugins / how do they work" would be out of scope

[slender belfry]

https://github.com/TheBevyFlock/bevy_quickstart/issues/195

[bitter sparrow]

since we say "We assume that you know how to use Bevy already and have seen the official Quick Start Guide."

otherwise it's a whole can of worms to teach the user bevy

[slender belfry]

I think a sentence or two won't hurt, since Bevy's examples and the quick start never really talk about custom plugins

it's a bit of a "secret knowledge" pattern for newcommers imo

[bitter sparrow]

that'd be the responsibility of bevy's docs to explain better then

[slender belfry]

Agreed, but I'm personally too lazy to add good docs for that, but I'm ready to mention "Hey, plugins do this and don't to ordering" in just two sentences in the design docs.

[bitter sparrow]

https://bevyengine.org/learn/quick-start/getting-started/plugins/

seems it's already done

[unreal narwhal]

The doc point isn't "plugins exist" but "plugins as the unit every file should use

and the consequences of that

[bitter sparrow]

sure in that case i'm agreeing

[unreal narwhal]

also not against seeing a PR to the bevy docs, but I'm not sure where "design pattern" fits, and it does fit in the template

[tidal widget]

do I need anything extra to make git deps work over ssh?
Getting this in CI

Caused by:
  failed to load source for dependency `bevy_tweening`

Caused by:
  Unable to update ssh://[email protected]/SecretPocketCat/bevy_tweening?rev=8dca8643b50d6ec23ece65158c56f81c0e111f86#8dca8643

Caused by:
  failed to clone into: /Users/runner/.cargo/git/db/bevy_tweening-b49fbf88cd6d4eb7

Caused by:
  failed to authenticate when downloading repository

  * attempted ssh-agent authentication, but no usernames succeeded: `git`

[dawn crag]

use https instead of ssh

unless it's a private repo, then you need to set up ssh keys or whatever

[tidal widget]

good call
I don't remember why I actually used ssh for this in the first place 😅

[slender belfry]

Could someone look into this? https://github.com/TheBevyFlock/bevy_quickstart/issues/199

I'm getting a little bit worried that we might not actually be building release builds for itch. I don't think that's the case, but this behavior makes me nervous 👀

Okay, this trunk log from a release build clearly shows we are using the release profile. That's good.

Still weird why the info logs are still there. If this is not working, this means that we may be losing quite a bit of perfomance at runtime by filtering out wgpu trace messages instead of compiling them out.

little sanity check: this works as expected with trunk serve --release

#[cfg(not(debug_assertions))]
compile_error!("We are running in release mode!");

[bitter sparrow]

weird

the CD command is trunk build --release --dist xyz

do we have two different versions of log in our deps with different features enabled?

[slender belfry]

This is my cargo tree output. It shows up twice, but it's the same version

One of them is just for build dependencies, I think

My Cargo.lock only contains one entry:

[[package]]
name = "log"
version = "0.4.22"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a7a70ba024b9dc04c27ea2f0c0548feb474ec5c54bba33a7f72f873a39d07b24"

[bleak grail]

you're setting the feature on the log crate, but I'm pretty sure Bevy doesn't use it as a backend on the web to be able to log on the console. you should set the log level features on the tracing crate instead

[slender belfry]

Thanks a bunch!

I'll see if that fixes things as soon as my release build hits itch.io 🙂

[slender belfry]

Can confirm this fixes it for my jam entry. Thank you so much for swooping in and telling us this, I'm pretty sure I would have taken ages to figure that out otherwise ❤️

[bitter sparrow]

so we should set the features on log and tracing?

[slender belfry]

Yep

Technically, you could set the features only on one or the other depending on the target, but since all targets pull in both dependencies anyways AFAIK it doesn’t matter

(Maybe someone could confirm that this is indeed the case)

[bitter sparrow]

so regarding macros for unwrapping options / results: https://github.com/benfrankel/blobo_party/blob/main/src/util/macros.rs

i made single-character macros that work on both option and result (could be extended to other types), and log a warning with a link to the code that i can Ctrl+Click in vs code

super super useful

r!(expr) will unwrap expr (whether it's option or result), or if it's a failure case, it'll log the warning and return

c! is the same but continue, rq! is the same but "quiet" (no warning), and then cq! is continue quiet

oh and they support an optional first expr as the value to return

r!(true, expr)

so you can still use them in run conditions / helper functions that return a value

[bitter sparrow]

i should probably add the actual error value to the warning though

[slender belfry]

That is some good stuff. Don't mind if I yoink it 👀

[slender belfry]

@prisma delta we are definitely still going to be passing around a feedback form later, but so far the vibes are pretty good regarding bevy_quickstart.
I've seen quite a few people use it during the jam and asked them about it. The majority is pretty happy and appreciates the "best practices showcase", as some put it.
We've got a couple of issues about some stuff we can improve open on GitHub, but honestly, it's pretty much all just minor polish.
Considering this, how are the chances of officially linking it in jam number 6? I know, it's still at least 7 months from now, but I'd like to know if there's anything I can do to make this happen.

Also, could we rename the working group to just Bevy Jam in general?

[prisma delta]

I like retiring working groups, rather than keeping them around indefinitely 🙂

But we can make a new one as it draws close

[prisma delta]

Convince Francois, myself and Cart that the quality / patterns are idiomatic and clear I suspect

I'll take a look at some point when I need a more chill day 🙂

[slender belfry]

Works for me

[slender belfry]

That... sounds hard. Patterns are notoriously easy to bikeshed for hours.

[prisma delta]

I think my standard is "nothing egregious"

Definitely have to pick some patterns though, and not everyone will like them

[slender belfry]

Alright, that seems reasonable. Thanks for clarifying 🙂

[nova trail]

Could I get a copy of that feedback form when you send it out? My team had a great experience working off of the template once we got over the initial hump of unfamiliarity.

[slender belfry]

Sure 🙂 thanks!

[hidden pond]

BTW speaking of the feedback form, anyone have any good platforms for feedback forms and the like? I only really know of Google Forms, but that's probably not the best choice.

[slender belfry]

Google forms is alright imo

[hidden pond]

I'm definitely willing to use it, just wanted to see if any other suggestions exist that might be better or provide better solutions for getting data out to do additional analyasis on if wanted/necessary. Also some people might be hesitant to use google forms, because google.

[prisma delta]

Okay, notes on the template as I go through it. Anything blocking will get bolded. Like always, feel free to ask for clarification / argue why I'm wrong 😉

• love the Known Issues page: that's a really nice compromise
• screen is kind of a weird name for that module 🤔 Totally just a nit though, and I don't really have better suggestions
• "We hold no patent rights to anything presented in this repository." This should be clearer or probably just removed.
• "Alice - Foo" in credits screen will be clearer with a made up job title instead of Foo
• ** I don't think InteractionQuery is worth the cognitive complexity cost**
• InteractionPalette's naming / docs aren't clear enough (I like the pattern, but it needs to be taught better)
• MovementController needs docs
• WrapWithinWindow is probably clearer as ScreenWrap
• audio should be data-driven, rather than using enums, and needs a generalized abstraction for "random within this group"
• I don't like the layout of the game module: IMO trying to further separate out gameplay logic from things like sound effects is important
• I'm not convinced that spawning things like the player should be an observer; that seems like a pointless layer of indirection over just using a custom command
• man we really need an actual 2D animation API
• handle_title_action should be done using observers, rather than a TitleAction component
• exit_playing and friends should be renamed to reflect a smaller scope: state transition schedules should contain multiple systems by convention
• you should be able to make AppSet more robust to refactors by using the PartialOrd trait

@slender belfry @bitter sparrow let me know if you'd like me to open issues for each of those, or if you're fine to tackle that 🙂

Nothing critical / particularly hard to fix IMO

The audio stuff is definitely the most challenging; let me know if you'd like more hands-on guidance there

[bitter sparrow]

• screen weird name: it helps if you think "title screen", "loading screen", "splash screen", etc. but i do agree, and i also don't have a better idea for a name
• patent rights: maybe. this is included specifically because CC0 explicitly does not relinquish patent rights, which is pretty much the only major issue with CC0 in this use case
• spawning as observers: i 100% agree personally
• 2D animation api: yuuup
• enter_playing split into systems: in principle i agree, but in practice it's so convenient, especially during a game jam. and all of the "on enter or exit XYZ screen" logic should be controlled within that file anyways (potentially calling into code written in other files, but no other files should be doing OnEnter(Screen::Xyz) etc. themselves)

agree / no comments on the other points

[bitter sparrow]

i think i'll just copy/paste the whole thing into an issue, since a lot of the points can be fixed easily

[prisma delta]

patent rights: maybe. this is included specifically because CC0 explicitly does not relinquish patent rights, which is pretty much the only major issue with CC0 in this use case
I think that for people who are nervous about patents the Apache license is fine as reassurance

[limber dragon]

The template worked pretty well for our game (partially thanks to Jan being one of the people who made it :D) but starting out it was very unfamiliar to me in terms of its patterns and module structure.

A part of this is certainly just me not being used to it, but I did feel like the module structure was a bit weird, and I had some difficulty figuring out where to put things since there wasn't a clear enough separation of concerns. It's probably fine for small games, but might not scale well.

My notes on the template:

• spawn is weird to me. The description is "Handles spawning of entities", which implies that it should handle spawning for everything in the game, but that would be a bad pattern imo. If I have an enemy module for enemy logic, reusable logic for spawning enemies should be in that module, not some completely separate spawn module. I find it weird that spawn::player is also where the Player component is defined in the template.
• I'm also not sure about using observers for spawning things like the player. It can be a neat pattern for some things, but I wouldn't reach for it as my first option, and I'm not sure if Bevy should be encouraging it as a good general pattern, especially considering it's not present in any official examples afaik.
• ui should probably be split into widgets and theming or similar, or otherwise renamed, to make it clearer that it has reusable UI widgets and theming, and isn't where you actually define your game's UI, like the title screen, HUD, and so on.
• I don't personally love the function plugin API even after using it for the jam, and would rather use normal struct plugins and group them using plugin groups, but that's a matter of personal preference.

Overall I feel like the structure leans a bit too much on organizing modules by groups, like "handle all spawning logic here, UI here, and screens here" instead of by logical concerns, like "handle player logic here, level logic here, HUD here, and then have some general reusable widgets here". For jam games, it can be fine (and that is probably the main purpose for the template), but larger projects will likely need a clearer separation of concerns.

[prisma delta]

Strongly agreed on this one 🙂

ui should probably be split into widgets and theming or similar, or otherwise renamed, to make it clearer that it has reusable UI widgets and theming, and isn't where you actually define your game's UI, like the title screen, HUD, and so on.
This is a great idea

[bitter sparrow]

could rename ui to theme honestly

since that's what the widgets are as well effectively

[limber dragon]

It also has interaction logic atm

[bitter sparrow]

yeah that might be better in a util/ but as of now that would mean only containing one submodule

[prisma delta]

Might be better to just upstream making this good with #1236111180624297984 ;P

[limber dragon]

I don't like util modules in general but idk

[bitter sparrow]

my util folder has a lot of stuff in it

[limber dragon]

util feels like a throw-away place when you don't know where to put things, which often implies that there is an issue with the structure of the app. Of course sometimes it can have valid uses, but interactivity for widgets isn't it imo

[bitter sparrow]

for reference, in the util/ for my jam game i have: config, late_despawn, macros, patch, selection, texture_atlas_grid, time

i can't think of a better place to put this type of module than a top-level util/

patch is extension traits for bevy types, macros is "return if None" type helpers

[bitter sparrow]

we're pretty limited in terms of demonstrating the split by logical concerns in the template itself because there's no real game code (we could suggest it in the README, if the user happens to read it). agreed on spawning and UI, but IMO screen/ is pretty necessary and could be considered a logical concern

[prisma delta]

Yeah, I like screen

[inland wyvern]

screen is weird but similar (better?) words are overloaded like scene, stage, state..

[bitter sparrow]

route was suggested by @tidal widget

[inland wyvern]

yeah, I saw that. I primarily associate that with a web server.. it's a similar purpose here but is that a common name for that in gamedev?

[bitter sparrow]

game devs all need to come together and invent a new unambiguous, commonly-used word for this

[inland wyvern]

wait, is stage overloaded?

[bitter sparrow]

in bevy itself, not since stageless afaik

but in english it can mean either "each stage of the game" or "life is a stage"

which isn't necessarily a bad thing in this context

[inland wyvern]

I think either of those interpretations isn't bad

[bleak grail]

it's now also used in front end, route being the path to a particular screen

[inland wyvern]

stage could be appropriate if you think of all video games as performances and you need to setup and tear down the stage. everyone else thinks of games that way, right? 🤔

[bitter sparrow]

also i was thinking we could rename .cargo/config_fast_builds.toml to .cargo/config.toml, but with everything commented out (it's already .gitignored)

so user can just uncomment what they want locally, no rename step required, and since it's .gitignored they don't have to worry about their changes being checked in accidentally

[prisma delta]

Would screens be clearer to anyone else?

Part of my confusion with the existing name is that maybe it's like... rendering or windowing related?

I call this menus in my project, but that's not technically right

[bitter sparrow]

so normally i try to avoid plurals like this because screen::title sounds better than screens::title, but that seems like a good tradeoff for the disambiguation

[prisma delta]

Yeah, that's kinda my thinking too

I think route will just be confusing to most people

[tidal widget]

honestly, I agree - the more I think about it, the weirder actually sounds

[lavish robin]

I liked screen personally because the name was memorable, so it was easy to remember it /search for it

[agile dirge]

i had the same issue initially, but it's the best name we could get, when it clicked it clicked

[prisma delta]

Yeah, that bikeshed is very much nonblocking lol

I would call it screens if it was my project, but ultimately it's fine

[slender belfry]

Thanks for the detailed feedback. I think I either agree or have no strong feeling for all of these 🙂
I find it interesting that you say a custom command is less abstraction than an observer. I'm fine with replacing the spawning code with whatever at this point because my conclusion is that imp everything is equally dissatisfying, I'm just curious why these two have a difference in abstraction in your mind.
For me, both require a new struct, both require a funky call on commands (observer(foo) and spawn_foo()), and both don’t get executed in the same function call but "pretty mich immediately after" from a user’s perspective (I know there are technical nuances).
I suppose observers feel a bit more "built-in" for me than custom commands since they require no extension traits. I know you don’t need the extension and can just let the user add the command manually, bit that feels a bit too raw.
Again, not trying to bikeshed this, I'm happy to change it. Just want to hear more about your perspective and maybe learn something 🙂

[bitter sparrow]

the observer doesn't really do anything. ultimately it becomes a command anyways when you commands.spawn inside the observer

the ergo diff might be a thing though

[prisma delta]

Yep, it's more about "pointless indirection"

I like commands.add(RawCommand) quite a bit for these use cases IMO

[slender belfry]

I would personally love some more guidance for the audio stuff, as that is the area in the template I'm most unfamiliar with and would like to learn more about how to do this better.
@agile dirge did the audio for the template, so I also want to hear their opinion on this

[prisma delta]

Good balance of clarity and boilerplate

[bitter sparrow]

only issue with that is you don't get the Entity id back right away

which is why i went for EntityCommand instead of Command, but then there are some gaps in bevy api that extension traits help fill

[prisma delta]

Yeah, that's valid

[slender belfry]

Interessant! Would you recommend showing that to a potential beginner through the template?

[bitter sparrow]

since we're planning for bevy 0.16 though, we can wait for bsn-related stuff anyways

[prisma delta]

Yeah, the Command trait is a good intermediate-level API IMO

Not too magic

[slender belfry]

That is my number one issue for anything spawning related

I miss something non-boilerplate in Bevy itself that calls an arbitrary system for spawning stuff and returns either Entity or EntityCommands

[bitter sparrow]

if EntityCommand functions could take systemparams instead of World that would be your answer

like how observers do it

they get a Trigger as the first arg (would be Entity in this case) and then can use system params

even though they run exclusively

which is why observers currently have the ergo edge over entity commands despite the extra indirection

[prisma delta]

So, I found a clever Rust trick that might help us here

[prisma delta]

The core problem here IMO is that sometimes you want &mut World, and sometimes you want to pass in a system-ish thing 🤔

The trick is:

trait MyTrait {
   fn approach_a() {
       approach_b()
   }

   fn approach_b() {
       approach_a()
   }
}

Then users must impl one xor the other method

Although I still need to think about how you actually write the SystemParam method for commands / entity commands 🤔

[bitter sparrow]

do we have an API like world.run_system(|foo: Res<Foo>, ...| { /* stuff */ })?

[prisma delta]

world.run_system_once

[agile dirge]

you need to register the system in the world though

[prisma delta]

Not for run_system_once

It's uncached

[agile dirge]

ah ok

[prisma delta]

SystemState is the other approach of course

But that gets gnarly IME

[bitter sparrow]

SystemState is pretty ugly from the start

and you get lifetime errors unless you clone everything you need out of it

before you start interacting with world

[tidal widget]

there so many options in bevy I either totally forgot about or haven't even heard about 😅

[bitter sparrow]

me when i learned about Annulus::sample_interior 😍

[tidal widget]

I found about about the rng sampling only after the jam 😁

[bitter sparrow]

it's as cool as rand's choose_multiple_weighted api

[tidal widget]

I'm slightly confused as to why the .14 blogpost mentions

gated behind the rand feature
but I don't see a rand feature
https://docs.rs/crate/bevy/latest/features

[bitter sparrow]

bevy_math/rand maybe?

that seems to be the case, and it's a default feature

[tidal widget]

I have not considered it could a feature of a workspace crate feature, my bad

[bitter sparrow]

well the blogpost should specify

[tidal widget]

btw. are any additions planned for the template for .16 besides the above-mentioned?

[bitter sparrow]

yeah there are a lot. they're all in the github issues (https://github.com/TheBevyFlock/bevy_quickstart/issues)

[tidal widget]

I think I'd welcome resseting the play & possibly pausing

[bitter sparrow]

i implemented pausing in my jam game as a separate Pause state, and it's cross-cutting

so every module is aware of Pause and has to decide how / whether it's affected by the state

[hoary flower]

Could you implement pause via stepping (cursed probably 🤔)

[bitter sparrow]

so it's kinda nice to have the pause feature around from the beginning, so you don't have to go back and do all of that

[tidal widget]

just a thought 🙂

[bitter sparrow]

restarting the playing screen sure, but IMO not worth with current bevy_state

hopefully bevy_state 0.16 will be better

[tidal widget]

restart/reset is more of an issue due to identity state resetting

[bitter sparrow]

yes it ought to be a one-liner

[tidal widget]

I just added an extra reset state cause I was feeling lazy 😁

[bitter sparrow]

i'll make an issue for pause/restart anyways, whether or not it will be implemented

[limber dragon]

I used the sampling for a custom particle system for the jam since existing libs didn't support enough shapes 😛 the sampling stuff is lovely

[tidal widget]

as in emitter shapes?

[limber dragon]

yeah

[tidal widget]

I landed on bevy_enoki, but that only has point and circle (and technically an annulus I guess), so I feel ya

[limber dragon]

Ah, didn't know that one! It's 2D-only though, so it wouldn't have worked for our game. Specifically I was sampling Extrusion<Annulus> (extrusions are also amazing)

(anyways this is getting off-topic)

[tidal widget]

I had the opposite problem where most crates either didn't support webgl or 2D 🤷‍♂️

[bitter sparrow]

made these issues :)

[tidal widget]

Intersted to see how this get handled btw.
https://github.com/TheBevyFlock/bevy_quickstart/issues/104

[bitter sparrow]

i have screen fade in/out implemented in my jam game / my personal template

[slender belfry]

I low-key think most people never test their crates for webgl2 👀

[tidal widget]

in the jam I landed on creating a TransitionedNextState which sets next state after the fadeout part has occurred so I can still use StateScoped

[prisma delta]

Yeah, I think these are both good to implement

I'll work on a good audio API design for y'all tomorrow I think: dogfood it a bit in my side project and then PR it to the template

[slender belfry]

Thanks a bunch, I'm excited for that 😄

[bitter sparrow]

btw another issue related to spawning is that in a real game, you probably want to defer the spawning until after your game's logic has completed for the frame

otherwise you could spawn something halfway through your game logic and end up with a 1-frame flicker or invalid state

probably fine to not worry about this in the template but figured i'd mention it

[slender belfry]

I agree, it’s just hard to find the right buckets while still allowing the template user to yeet the entire gameplay code in favor of their own. But we probably can do better than how it is right now.

Also agree with your other notes, except for plugin syntax. That’s a hill I’ll die on 😄

[tidal widget]

I like the local fn plugin
Having the regular impl is just extra boilerplate

also agree that yeetability is an important part of a template - it should be fairly easy to throw some stuff away

[bitter sparrow]

we could rename game to demo to make that explicit

[slender belfry]

@prisma delta when you eventually close this working group, could you add a bevy_quickstart channel in #1034543904478998539 where we can continue discussions until the next jam?

[rigid geyser]

When it comes to officially linking templates, I personally think this is worth bikeshedding for hours (from experienced leadership), as the cost of encouraging bad things on this scale is high.

Given how in sync the <@&1064695155975803020>s are in general on patterns, I think reaching consensus is achievable

[slender belfry]

Alright, if you say so, I'll believe you 🙂

[rigid geyser]

Especially on the current time scale

(between now and the next jam)

[prisma delta]

I think it's honestly pretty close: the addition of the BSN work should solve the last big question mark (how to solve entity spawning)

[slender belfry]

I guess I am a bit traumatized by how unproductive bikeshedding like this used to be at my last job.
My main concern is that such a thing could potentially devolve from "let's figure cool stuff out together", which I enjoy, to "I need to defend my creation in front of a gremium of people who try to find flaws", which is extremely emotionally draining for me. Not saying that's you, that was just my experience in the past with these sorts of things.

But the maintainers have so far shown so much kindness in discussions that I will trust you 🙂

[rigid geyser]

I totally understand where you're coming from. From my perspective, sadly, that is the job of anyone wanting to work on an "officially recommended Bevy template". Sadly as project lead theres no way I'm not going to micro-manage / hyper-analyze anything related to "defining official best practices"

We've invested thousands of hours across four years in API design. Compromising that in any way at the "last mile" would be wasteful I think

[slender belfry]

Agreed!

[slender belfry]

The original plan was to intentionally phrase this as Bevy-external / semi-official / "this is what the Jam working group recommends, not necessarily what the Bevy foundation recommends". Is that no longer the case?

Because this phrasing makes it sound like something that would be included in the Bevy org, which is possible of course, but maybe not a good first step.

[rigid geyser]

In practice I think that phrasing, in the context of top level link placement in an official bevy jam, is close enough to "this is an official high-visibility recommendation" to be essentially the same

[slender belfry]

Hmm, fair enough

Would a concensus on patterns also imply upstreaming it to the Bevy org in that case?

[rigid geyser]

I think thats the right path forward for the next jam. I'm convinced of the value and reasonably confident we can get it finalized by then

Or alternatively, we could do it under the flock umbrella / let it own that, but I would want much stricter definition and enforcement of patterns if we go that route with regular sync-ups with bevy leadership to ensure its aligned

[slender belfry]

Alright, that changes the reservations I had. A template inside the org should definitely be hyper-analyzed. Although consider that having "pretty good but not quite perfect patterns that can be iterated upon" may be better than "we have no recommendation, here's a link to a bunch of templates random people made, pick one". And I say this as the person maintaining the second-most used community template 😄

[rigid geyser]

Another option: have an "officially recommended" template as the strict / conservative high-design-confidence repo, then let the flock have a less strict extension of it with more experimentation freedom

[bleak grail]

upstreaming patterns rather than the template as a whole?

[rigid geyser]

Official recommendations would link to the high-design-confidence repo. But the high-design-confidence repo could then link to the flock-extended template (with some text explaining that it is more experimental)

[slender belfry]

I think this setup would very naturally evolve into "the official repo uses only Bevy, the one in Bevy flock uses third party crates"

[rigid geyser]

Yeah this seems reasonable, provided the more experimental template still generally holds to the patterns established upstream

[slender belfry]

Which sounds completely legit to me btw

[rigid geyser]

That is definitely worth discussing. We could also have a 3rd version (that adds more third party crates), although introduces even more overhead and confusion

[slender belfry]

I would strongly prefer having a template upstream than a design doc or just examples. Showing things in the context of an actual game project (even when just a small one) changes things dramatically imo

[rigid geyser]

agreed

[slender belfry]

Alright, in-depth bikeshedding for upstreaming sounds good to me then, if that’s cool with the other maintainers and the other people in the working group 🙂

I guess a good next step would be to implement @prisma delta's feedback and iterate on that?

[rigid geyser]

Lazy question: where is that feedback?

[slender belfry]

Pinging @bitter sparrow, @agile dirge and @hidden pond

[slender belfry]

Sec

https://github.com/TheBevyFlock/bevy_quickstart/issues/203

Bold is high priority / strong opinion

[rigid geyser]

Yup I buy most of these. Anything resembling "new abstraction building" is going to receive serious and dubious scrutiny from me

[prisma delta]

FWIW, in my own projects I build random little abstractions like this constantly

But that's a different kettle of fish

[slender belfry]

None of us had any real issues with Alices issues either, just a bit of bikeshedding around enter_playing, so that’s good 🙂

[rigid geyser]

Same. Generally in the category of "feature gap filling"

[prisma delta]

And there's definitely real problems in Bevy where abstractions are missing (audio, UI, 2D animation)

Shocking I know

[slender belfry]

Yeah, the Widgets stuff is imo an abstraction that the template needs

[prisma delta]

Yeah, I didn't push back on it because writing UI in Bevy 110% needs something, and this was a relatively straightforward pattern

Well, fingers crossed that in 6 months there's a blessed solution

[slender belfry]

We did it like this because #ui-dev recommended it, which we took as a good indicator of consensus / quality

[prisma delta]

Yeah, it didn't raise any "oh god what are you doing" flags for me or anything 😛

[slender belfry]

But I'm also not married to the specifics as long as there’s something there for convenience

I’m very curious as to what you come up with for audio 🙂

[prisma delta]

Yeah, I'm getting happy with the example I ended up making: I suspect I'll spend a bit of time tomorrow polishing that

[slender belfry]

Do you know anyone who has thoughts on how to best do 2D animation abstractions in pure Bevy?

I’d be nice to get some feedback in that regard

[prisma delta]

@ivory gust's work with Seldom state, but also @dapper sail/ @fallow ledge's work on The Seeker

[agile dirge]

no strong opinions about most of those
one thing about game and splitting it up
we had it split up, then merged it, clearly we're missing a point here

the problem is where do we split it

that scales well

looking at game now, the entire audio module can be separated

[slender belfry]

While allowing people to still know where they can yeet demo code

[agile dirge]

so can animation

assets are on the edge, it's not core game logic, but it also very game specific

the rest is mostly core game logic

(spawning is technically an universal pattern but we specialize it for the game)

about spawning with observers, it's been thoroughly discussed with @bitter sparrow, if we're going to add command boilerplate we might as well benefit by retaining EntityCommands after the call

[hidden pond]

That is fine by me, although I mostly only really touched the Cargo Generate side of things.

Also I do think it would be helpful to create some sort of "second party" category, which is kinda how I see the template atm. Not exactly official or "blessed", but not exactly 100% unofficial/third party.

[slender belfry]

Yeah, having something like rust-lang-nursery in the long term that can pick up extremely widely used community crates without much bureaucracy would be nice. But setting that up is a whole other can of worms that will consume horsepower.

[hidden pond]

Yeah. Although it doesn't necessarily need to be as formal as that.

[bitter sparrow]

what's the suggestion? to split bevy_quickstart into an official version and an unofficial version?

while there is an "official template" gap, there's also a "semi-official template" gap which bevy_quickstart fills

i don't think i'd be interested in working on the unofficial half of bevy_quickstart because i already have my own template and there are several others

and working on the official half sounds like more of a pain

is it really not possible for the jam page to link to a "vetted" semi-official template? that would be ideal imo

[prisma delta]

https://github.com/bevyengine/bevy/pull/14554 is ready for review, and demonstrates a relatively simple but robust sound effect API

[slender belfry]

I personally think that pattern recommendations are extremely needed right now in Bevy, as beginners are often left entirely clueless as to how to actually build a game out of the individual puzzle pieces they were given. Bevy's docs and examples for individual things are great imo, what we need is something that puts it all together. And I don't think the example games fill that gap right now.
Because of this, I think an official template as a showcase of commonly agreed upon standards would benefit the ecosystem more than a vetted template. But yeah, that is indeed more of a pain.
I'd really appreciate it if you could continue offering your support if we go that route, as your contributions have been invaluable so far. Certainly made me rethink some of the patterns that I've been using 🙂

[slender belfry]

After some reflection I also agree that I personally don't have that much interest in using a second, completely unofficial version of bevy_quickstart for experiments since I also already do those in my own projects.

I see the point that having the template split into a heavily vetted half and a more freestyle experimental half may be conducive to creativity and such, but I would not want to invest the time in maintaining both.

[bitter sparrow]

what would be the difference between bevy_quickstart as an official template vs. as a vetted semi-official template?

stricter PR process / scope? updated in tandem with bevy releases / bevy main?

[slender belfry]

The way I understand @rigid geyser:

• Having a strict PR process with the maintainers involved. This means more bikeshed, but also an opportunity to figure out better ways of doing Bevy.
• Placing it under the Bevy org, which implies that more people than just us have an interest in maintaining it.
• Officially linking it in multiple channels, as it is no longer just about a jam, but about agreed-on patterns in general.
• In a broad sense, giving it an official answer to the question "how should I structure my game?" and "what are Bevy's best practices?"

I heavily assume that placing it under the org would mean that a new Bevy release would be blocked until it works with the template

[bitter sparrow]

well i do think it would be good to go that route at some point

maybe after the template is feature complete? that's not too far off

[slender belfry]

Given that the proposed time frame is until the next jam, which means 6-8 months, I think we have plenty of time.

[slender belfry]

What would you consider feature complete? Imo it already is, we just got some interesting suggestions adding more stuff.

(I really really like the idea of adding pause to it)

This one probably as well: https://github.com/TheBevyFlock/bevy_quickstart/issues/211

[bitter sparrow]

mostly the more-recent issues opened under enhancement

some of the older ones are more controversial or blocked

[slender belfry]

Yeah a bunch of these are very good, you're right

I already know the official answer to this one though: https://github.com/TheBevyFlock/bevy_quickstart/issues/204

[bitter sparrow]

is the official answer no? :p

[slender belfry]

https://github.com/bevyengine/bevy/issues/14275

Based on the wording, I'm pretty sure this is one of these things that could be totally fine as a semi-official thing but not as an official best practice

[bitter sparrow]

right. that makes sense to me, plus a link to the 3rd-party crate in the template docs

[slender belfry]

Are you planning on doing a crate for all of your macros? Because I want that 😛

[bitter sparrow]

sure, should be easy enough

i was thinking of splitting a few things from my template into little crates

[slender belfry]

I think the only thing I would change from https://github.com/benfrankel/blobo_party/blob/main/src/util/macros.rs is to change return; into return default(); to work in more cases.

[bitter sparrow]

that's interesting. () impls default surely then

[slender belfry]

Exactly 😉

[bitter sparrow]

we could even use a custom trait for that if default is considered not a perfect fit, but it does sound reasonable

that does raise the question

what would become of the tooling recommendations doc if bevy_quickstart becomes an official template?

[prisma delta]

Correct 😄

[slender belfry]

that is a very good point 👀

I think that's for the maintainers to decide?

I personally like it, as the current assets page offers no real distinction between "This is LWIM, one of the most beloved and widely used crates in all of Bevy's history that should probably be part of Bevy itself" and "This is spew, a random library Jan made a while ago that is now superseded by observers"

But I also see that the foundation probably doesn't want to play favorites and leave this kind of ranking to the community (correct me if I'm wrong)

[prisma delta]

This is my position too

We're also going to want to semi-officially endorse showcase game projects too for marketing reasons at some point

Which has actual financial implications

[slender belfry]

That's a good point

[prisma delta]

There's no escaping it: declaring "this community stuff is high-quality" is too useful, even if it's good not to declare winners too strongly or too soon

(we ran into this with linking to the Cheatbook extra prominently in the past too)

[slender belfry]

So either:

• we leave the tooling recommendations in the template (easiest solution)
• we create a dedicated repo for that and link it (pretty easy solution)
• we overhaul the assets page to include this information (probably best long-term solution, but very tangential from the point of view of wanting to create a template)

[prisma delta]

Yep, I like 1 -> 3

[bitter sparrow]

i found some existing rust crates regarding bailing on Option / Result, but they're not quite the same

skip_error does basically the same thing as c!, but with no return / quiet variants and only working on Result, not Option (and the macro's name is long)

bail_macros is another take, with short macro names this time, but a ton of separate macros instead of a few that handle many cases, and no logging

early_returns is another one, with long names and no logging, and Result / Option split into separate macros again

so i think this could be useful in the rust ecosystem more generally

[prisma delta]

Agreed, I like your implementation better than any of these

(I would personally consider using it in my own projects if you had long-name variants)

[bitter sparrow]

should be no problem to add long-name variants

[prisma delta]

Yeah 🙂 It's a salt-to-taste situation

[inland wyvern]

for what it's worth, I did really enjoy using those macros and am using them in my projects now

[bitter sparrow]

done: https://github.com/benfrankel/tiny_bail

supports configuring the logger via feature flags (println vs log vs tracing + log level); includes long-form aliases; and supports bool in addition to Option and Result

[bitter sparrow]

so this is pretty terrible, but it allows you to use system params without lifetime errors in a custom EntityCommand:

struct Projectile {
    lifetime: f32,
    // ...
}

impl EntityCommand for Projectile {
    fn apply(self, id: Entity, world: &mut World) {
        let mut this = Some(self);

        // Specify system params here:
        world.run_system_once(move |mut commands: Commands, assets: Res<ProjectileAssets>| {
            let this = this.take().unwrap();

            // Spawn entity here:
            commands.entity(id).insert(/* ... */).with_children(/* ... */);
        });
    }
}

let mut this = Some(self); is required so that the closure is a FnMut instead of a FnOnce, so that it implements IntoSystem

macro or vs code snippet could help generate this boilerplate, but it still sucks

[bitter sparrow]

better version:

struct Projectile {
    lifetime: f32,
    // ...
}

impl EntityCommand for Projectile {
    fn apply(self, id: Entity, world: &mut World) {
        world.run_system_once_with((id, self), projectile);
    }
}

fn projectile(In((id, this)): In<(Entity, Projectile)>, mut commands: Commands, assets: Res<ProjectileAssets>) {
    commands.entity(id).insert(/* ... */).with_children(/* ... */);
}

[bitter sparrow]

ok i've ended up with an entity spawning abstraction that i'm satisfied with pre-bsn

example: https://github.com/benfrankel/bevy_jam_template/blob/main/src/screen/title.rs

• you get EntityCommands back immediately
• you can access system params ergonomically (because the entity spawning functions are actual non-exclusive systems now)
• you can pass in extra data (like struct Projectile in the snippet above)
• it's very easy to convert a pure entity spawning system to one with data passed in

the main downside is the impl EntityCommand for Projectile boilerplate in the snippet above, which is pretty minimal and only required if you want to pass in data to the entity spawning system, and it can be generated using VS Code snippets

[bitter sparrow]

lol cargo-binstall github action is broken rn: https://github.com/cargo-bins/cargo-binstall/issues/1864

i just merged a cargo-binstall related PR, then ran a release workflow and it failed on that step. and the bug is not due to the PR lol it's just bad timing

it seems they're in the middle of a release (https://github.com/cargo-bins/cargo-binstall/pull/1863)

[bitter sparrow]

little PR https://github.com/TheBevyFlock/bevy_quickstart/pull/215

[bleak grail]

well the more components you add to your CI, the more likely it is one is broken at a given moment 😄

[bitter sparrow]

true, but they shouldn't be breaking their action for 30 minutes on every release, idk what they're doing over there :p

[slender belfry]

Approved

[bitter sparrow]

another little PR https://github.com/TheBevyFlock/bevy_quickstart/pull/217

[slender belfry]

approved

I'll get a couple of small suggestions from Alice's list done now

[bitter sparrow]

made another small pr https://github.com/TheBevyFlock/bevy_quickstart/pull/218

we have a lot of low hanging fruit accrued

[slender belfry]

Could you group this with the log stuff?

It currently looks to a user as if that comment was accidentally duplicated imo

[bitter sparrow]

oh like position-wise

[slender belfry]

yep

[bitter sparrow]

sure, i usually do alphabetical order which is why i did it like this

[slender belfry]

And maybe let one say "on native" and the other "on Wasm"?

[bitter sparrow]

oh is that the difference

tracing is the wasm one then?

[slender belfry]

Exactly!

[bitter sparrow]

so should i have 1 comment or 2?

[slender belfry]

I got very very confused as to why my jam entry was spamming the console until @bleak grail came to the rescue 😄

[slender belfry]

2 imo

[bitter sparrow]

ok

[bitter sparrow]

done

[slender belfry]

The world "release" is maybe a bit misleading

[bitter sparrow]

hm

it's based on "no debug_assertions" internally right?

which is meant to target the release profile

[slender belfry]

it also helps with dev builds (the main perm issue is trace! calls)

[bitter sparrow]

okay i guess it is extraneous

you can look at the exact features for the details

[slender belfry]

Yes, but on debug_assertions enabled, we have max_level_debug

Why disabled wgpu's trace! calls

which results in a staggering 5-10% performance increase

[bitter sparrow]

changed word

[slender belfry]

which is frankly a ridiculous price to pay for trace! calls

approved

[bitter sparrow]

yup...

[slender belfry]

https://github.com/TheBevyFlock/bevy_quickstart/pull/219

I removed the name Alice from the credits to avoid confusion with a certain prominent Bevy contributor

@bitter sparrow what does this mean?

you should be able to make AppSet more robust to refactors by using the PartialOrd trait

[bitter sparrow]

i'm not sure exactly

[slender belfry]

I mean, I know I can derive it, but I don't know how that helps in this case

[bitter sparrow]

@prisma delta ?

[prisma delta]

I'm not sure exactly how we ended up doing it, but the basic idea is to define an ordering for the enum variants, and then programatically configure all of the sets to chain, one after another

MainSchedule did something to this effect IIRC

[slender belfry]

There's this

But that's not using PartialOrd but an ordered Vec

@bitter sparrow I also added this to the PR https://github.com/TheBevyFlock/bevy_quickstart/pull/219/commits/dff1d5770f0424b9377a45944e7ded4e42a52626

[bitter sparrow]

👍

[slender belfry]

https://github.com/TheBevyFlock/bevy_quickstart/pull/221

@bitter sparrow

[slender belfry]

Are you sure this is a thing? I can't find any reference to it in the Bevy source code

I mean, I could of course implement iter and then order that, but that does not seem like much of a gain over specifying the order while configuring the set

[bitter sparrow]

maybe it's using strum::EnumIter instead of PartialOrd or something?

[slender belfry]

@dawn crag 😄

[slender belfry]

Pretty sure bevy does not use strum

It takes ages to compile

[slender belfry]

That's clever

I like it 🙂

I'd approve a PR replacing our observers with this for spawning

[slender belfry]

Maybe add a little justification for the maintainers that will question it

[bitter sparrow]

the controversial part would be the extension traits it requires

[slender belfry]

Yep

Agreed

[bitter sparrow]

i can make an issue for it though so it doesn't get lost

[slender belfry]

But given all of the context we generated around spawning, I don't think we get around introducing an extension trait as an additional abstraction

@bitter sparrow https://github.com/TheBevyFlock/bevy_quickstart/pull/222

[bitter sparrow]

created the issue https://github.com/TheBevyFlock/bevy_quickstart/issues/223

[slender belfry]

commented

[prisma delta]

Yeah maybe that's what I had in mind. Probably not worth it otherwise

[slender belfry]

I would not add a dependency on strum just for that imo.

[prisma delta]

Agreed!

[slender belfry]

@prisma delta would you mind weighing in here? https://github.com/TheBevyFlock/bevy_quickstart/issues/223

[slender belfry]

@prisma delta for the data-driven sound effects: would you only replace the SFX with your pattern or also the soundtrack?

If the latter, do I just leave the images with the HandleMap pattern?

Also: should we leave the 2D animation API stuff as-is or try to recruit people to brainstorm patterns?

[slender belfry]

@bitter sparrow https://github.com/TheBevyFlock/bevy_quickstart/pull/224

[prisma delta]

Only the former

It's really rare to need a huge number of sound tracks

And they're rarely tied to anything else

[slender belfry]

Usually, CI failures are more informative 😄

[prisma delta]

As is IMO

[bitter sparrow]

oopsie doopsies! something went wrong :(

i'd try rerunning the CI lol

[slender belfry]

Implemented data-driven sound effects according to Alice's example: https://github.com/TheBevyFlock/bevy_quickstart/pull/225

@bitter sparrow @prisma delta could you both take a look at it when you have time?

@bitter sparrow if you have any improvement suggestions for the comments, you should probably post those on https://github.com/bevyengine/bevy/pull/14554 directly, as they are directly copy-pasted into my PR.

I'd also like some input on whether we should have a settings menu.
In my opinion, we should have that at some point, since one of Bevy's often stated ambitions is "accessibility by default", which often will require a menu for tweaking accessibility features.
If we implement this now, we might need an entire stack state abstraction as detailed by @lusty barn in the pausing implementation issue.
Alternatively, we could just say this is blocked until a preferences API as outlined by cart is implemented and then expose that.

[bitter sparrow]

we don't actually need a state stack for this. it can be implemented as a separate Screen same as Screen::Credits

state stack is nice if you have a nested menu and want to easily implement "go back"

[slender belfry]

I was kinda assuming that any decent menu would require that, but you're right, a minimal menu would work without that.

[bitter sparrow]

you can still get "go back" without a state stack if you have a fixed tree of state transitions, like if the previous menu before menu B is always menu A

but i'm working on a settings menu in bevy_jam_template rn and using the state stack feature in pyri_state and it's definitely convenient

[slender belfry]

That's a good point. The question then is whether this is something worth having, which is probably more of an opinion thing, and how high you prioritize accessibility.

[bitter sparrow]

if we're ok with a single settings screen that you can only enter from the title screen (not from the to-be-implemented pause menu in the playing screen), then it's easy

btw would we even have any settings implemented? like volume?

[slender belfry]

Agreed, but that's a bit half-baked though. You need to be in the game to know how to set the volumes, whether you need high contrast, what your gamma should be, what your HUD size should be, etc.

[slender belfry]

Volume as a minimum, yeah

Ideally some colorblind settings, but idk how builtin that is in Bevy rn

[bitter sparrow]

also settings comes with the question of persistence

[slender belfry]

But it would be neat to live in a world where every jam game is colorblind friendly

[slender belfry]

I think a minimum implementation is fine without persistence

[bitter sparrow]

persistence can be considered a separate feature though, it's not strictly required

[bitter sparrow]

fwiw auto color blind settings technically don't quite accomplish this

they don't hurt, but for true accessibility it takes more than that

[slender belfry]

Sure, you could setup your title screen so that it is representative of the game. But that is far from "accessibility by default"

[bitter sparrow]

player can use pause menu to quit back to title screen, then change settings, then start a new game 🤪

[slender belfry]

Fair. A monochrome filter that is toggleable through the settings would help a dev develop an actually good colorblind version, but I suspect that would be out of scope

[bitter sparrow]

monochrome filter would be more of a dev tool than a user-exposed setting

[slender belfry]

Yeah, that's what I meant

[bitter sparrow]

if we can add that as a dev tool with a toggle that would be cool though

[slender belfry]

I think dev tools in general should just be in the settings menu if we have that

[bitter sparrow]

i can see that.. i like F3 toggle though

can support both anyways

[slender belfry]

Otherwise we quickly reach WoW levels of keybindings

[slender belfry]

Ah, Minecraft

[bitter sparrow]

i have F3 toggle everything hehe (debug physics, UI, picking)

and F4 toggles my separate editor window

[slender belfry]

Toggling debug physics AND monochrome at the same time might not be the best dev experience 😉

[bitter sparrow]

i mean you wouldn't want to lump monochrome filter in with these

the quickstart template won't have many dev tools anyways since there's no physics and no picking

so just UI and maybe monochrome filter

[slender belfry]

Found relevant accessibility issues:

• colorblindness
• photosensitivity

[bitter sparrow]

yeah the comments in there express what i was thinking in better detail

funnily enough, exposing color adjustment options to the user also means supporting it for the dev, which is very handy :p

but it's non-trivial

[bitter sparrow]

Due to the use of [Shopify's Liquid], cargo-generate special cases files with the file-ending
.liquid, by simply removing the file-ending when processing the files. If you, as a template
author, truly want the .liquid file-ending, you need to repeat it twice!

An Example: the file main.rs.liquid will be renamed after templating to main.rs

may be able to use this in the cargo-generate branch so that release.yaml.liquid doesn't trigger a failed workflow for the parse error on every commit

also may be able to use it to eliminate the need for the cargo-generate branch at all? but that might be too messy or just not possible, haven't thought about it

also it seems like cargo-generate supports full-on scripting via Rhai, which we could use for things like removing the LICENSE files etc.

example: https://github.com/cargo-generate/cargo-generate/blob/a8ed4fdcc14c69d146e54596e6cea434368517ad/example-templates/hooks/ask-license.rhai

i'll create an issue to look into the more advanced features of cargo-generate for potential improvements

pr fixing cargo-generate branch: https://github.com/TheBevyFlock/bevy_quickstart/pull/227

not yet tested. i'm thinking i could merge it unreviewed to test, since it's not targetting main

[bitter sparrow]

did this. workflow fixed, index.html not fixed

[bitter sparrow]

ok all good now. had to add index.html to include = [...] in cargo-generate.toml

[hidden pond]

I thought it was in the include already, but I guess I was mistaken. Although you did need the raw blocks as well, as it will cause a similar issue if it's excluded.

As for the full-on scripting. Yeah I've been meaning to do that just haven't really had the time due to IRL stuff.

[hidden pond]

I'm not sure how that would work though. We have the branch separate so that you can use the branch as a Github template, as there were some concerns about having cargo-generate be required for this. As if we didn't have the branch, then we would have to have cargo-generate stuff in the main branch.

[slender belfry]

Agreed, I'm not seeing this happening unless we make cargo-generate necessary. Which is not completely off the table mind you, but imo controversial enough to warrant discussion with the Bevy maintainers.

Or @bitter sparrow is talking about manually scripting a string replacement for the instances of bevy_quickstart and friends

Which, granted, could work, but feels a bit whacky

Btw @hidden pond do you think you could take a look at the cargo-generate solution proposed for https://github.com/TheBevyFlock/bevy_quickstart/issues/212 ?

[hidden pond]

I mean that should work, the main issue is just you would probably need some scripting, and I'm not sure it's a great idea though.

As for requiring cargo-generate, I would say that we might want to wait on that until after we get that survey out.

[slender belfry]

I can try creating it later today

[hidden pond]

Thank-you. Feel free to reword the questions as necessary as well. I've added a few things to the hackmd doc since we all were on it, but I just haven't had much time to actually put the survey together.

We also do need to discuss distribution of the survey and how we are going to get responses, but that can be as simple as doing an announcement related to the template or something IG.

Also probably going to want to take things from this issue too: https://github.com/TheBevyFlock/bevy_quickstart/issues/192 (and a link to the hackmd doc https://hackmd.io/@chanku/Sy9SwmudA/edit for convience)

[agile dirge]

I added ready for implementation tag
I can't tell at first glance which issues are "fresh" and which were a result of discussion and can have a PR submitted

That said, I'm not going to add it to anything, I'm not up to date at all

perhaps there is a more fitting name, feel free to change it

[slender belfry]

Good idea, I like it

[slender belfry]

I'm tackling this feedback now:

handle_title_action should be done using observers, rather than a TitleAction component

I'm not quite sure how

What exactly should trigger an observer for what? I assume TitleAction should be the Event being triggered, alright. But it still needs to be triggered on Interaction::Pressed, which needs to differentiate between the buttons to know which TitleAction to fire

[bitter sparrow]

could have a generic OnPress(E) component

so OnPress(TitleAction::Play) or w/e on the button

[slender belfry]

I suppose

[bitter sparrow]

and then you'd need a generic system trigger_on_press::<E>

[slender belfry]

One trick I learned from @bright ledge is to just directly add a SystemId from a one-shot system to a button and call that on presses

[bitter sparrow]

yeah OnPress(SystemId) would be the type-erased version

[bright ledge]

I would only recommend that when you either have a lot of systems that would be painful to do events for or when you want people to be able to use custom systems

[slender belfry]

I feel like using observers in this case is kind of shoe-horning them in :/

[slender belfry]

The code we are talking about is just this little function

[bitter sparrow]

well it's that function + the other versions of it for the other menus

[bright ledge]

ah

I would recommend having separate structs for each action

[slender belfry]

yeah fair enough

[slender belfry]

Could you elaborate?

[bright ledge]

as in split up the enum for the title action into three structs

[slender belfry]

What benefit does that bring?

off-topic, how come no lint is telling us about unused mut here

[slender belfry]

I mean, I know why, but still

[bitter sparrow]

clippy knows we may want to mutate it in the future 👍

[bitter sparrow]

well this is another example of "on press, trigger an event". plus "on hover"

[bright ledge]

it's not that useful here but for places where you have more buttons it means you can just handle them seperately which can be useful for keeping functions simple

[slender belfry]

Ah, I see.

[bright ledge]

otherwise I tend to find I get very cluttered parameteres

[bitter sparrow]

yeah handle_title_action has to pull in every system param it will need for every action

[slender belfry]

At that point, isn't just using pub struct OnPress(pub SystemId) nearly the same but a bit more powerful?

You can still register an observer trigger if you want

[bright ledge]

apparently using a SystemId is slightly slower

but I'm not sure by how much

[bitter sparrow]

https://docs.rs/bevy/latest/bevy/prelude/struct.Commands.html#method.register_one_shot_system

i didn't know this existed. why is it named like that instead of register_system like it is on World

[bright ledge]

and it probably doesn't matter considering that the buttons won't be being pressed that much

[slender belfry]

Yeah that is precisely what I learned from @bright ledge 😄

[slender belfry]

yep, agreed

[bitter sparrow]

yeah no the buttons will be pressed like once every few minutes at most

[bright ledge]

I think in this case using an SystemId is a good idea if you plan to add more buttons

[bitter sparrow]

SystemId is more similar to how it works in bevy_mod_picking

[slender belfry]

Now remind me again how I run the one-shot system from a SystemId...

[bitter sparrow]

On::<Press>::run(|| system)

[bright ledge]

either through commands or world

[slender belfry]

thanks

[bright ledge]

just type system and it should come up

[bitter sparrow]

https://docs.rs/bevy/latest/bevy/prelude/struct.Commands.html#method.run_system 😄

[bright ledge]

(I would recommend commands if you don't need the return type)

[slender belfry]

huh, SystemId is not Reflect

[bitter sparrow]

#[reflect(ignore)] ig

plus upstream issue

[slender belfry]

does that work on a newtype?

[bitter sparrow]

yup

[bitter sparrow]

#[reflect(from_reflect = false)] i think

[slender belfry]

TIL

[slender belfry]

expected one of: `@`, `ignore`, `skip_serializing`, `default`

[bitter sparrow]

oh uhh "false"? i'll check

[bright ledge]

ignore maybe?

[slender belfry]

That results in the first error I posted

[bitter sparrow]

nah should be good with no quotes

[bright ledge]

heh

[slender belfry]

aaah

[bitter sparrow]

oh did you put quotes on something

[slender belfry]

No quotes in here

[bitter sparrow]

maybe it changed recently

[bright ledge]

if you're doing a general on press struct I'd also recommend adding the generics for the SystemId

[slender belfry]

I mean I could just not make it reflect, it's not going to be too helpful in a debugged anyways

[bitter sparrow]

oh no

that should be an attribute on the struct, not the field

[bright ledge]

in case you want it to have an output or input

[slender belfry]

"Okay, let's use quotes then!"

What do you want?! 😄

[bitter sparrow]

#[reflect(from_reflect = false)]
struct OnPress(#[reflect(ignore)] pub SystemId);

[slender belfry]

Oooooh I need both

Okay, thanks 😄

Yeah that works, thanks a bunch!

https://github.com/bevyengine/bevy/issues/14496

Well there's the relevant issue

Any of you feel like doing a quick PR on Bevy? The code's already there

I would, if I wasn't doing the quickstart stuff rn

[slender belfry]

Supporting that would require actually handling input or output to such a system

Which I don't really see happening in this case

[bitter sparrow]

huh that issue mentions "Bevy Snippets for vs code"

i found this: https://marketplace.visualstudio.com/items?itemName=pixl.bevy-snippets

[slender belfry]

TIL

[bitter sparrow]

so i suppose some people have already done this

[bright ledge]

I was just thinking of future usage

in case you decide to use it more

[bitter sparrow]

the github repo for this is archived

[slender belfry]

The thing is, I don't see how passing input or getting output would make sense for an OnPress callback

Okay, maybe In

[bright ledge]

fair

[slender belfry]

smh my head

[slender belfry]

I'll do the simpler OnPress variant for now, is that fine?

[bright ledge]

I've found output useful for returning the next bit of dialogue

but that only really works in a dialogue heavy game

[bitter sparrow]

with a SystemId<(), ()>? sure

[slender belfry]

Yeah that makes sense

[slender belfry]

exactly

hrmm dual borrow of mut Commands

With a little bit of syntax sugar, I think this would be neat, if it weren't for the multiple borrow.

That's an argument of doing OnPress<T: Event>

[bright ledge]

can you move the system registering to the top and add it later

so it's not borrowed multiple times

[bitter sparrow]

when i overhaul the entity spawning pattern

the buttons will each be their own function with their own Commands

[slender belfry]

Sure, but that's real ugly for three actions

[bright ledge]

fair

[slender belfry]

huh, that's true

I'll do the version with OnPress<T: Event> now then, after your overhaul it should be easy to generalize it.

[bitter sparrow]

sure, either way

[slender belfry]

Wait no, that requires you to register your variant somewhere so that the right system for handling that specific variant is added

Which adds yet another abstraction and extra non-bevy API

I'll instead wait until your overhaul

[bitter sparrow]

you could pre-register the oneshots before the overhaul?

should be easy to cut/paste them to the new functions after

but yeah i can make a PR for that sooner if that helps

[slender belfry]

fair enough

It just looks so darn ugly

thoughts on one vs the other?

[bitter sparrow]

i'd do the first

[slender belfry]

We are on the same page then

[bright ledge]

you could also extract them into functions which would make sure it stays on one line

[bitter sparrow]

the second would be good if we wanted to have multiple effects as a result

[slender belfry]

yeah that's neat

[bitter sparrow]

so i need to decide which extension traits to keep and which to remove for simplicity

[slender belfry]

@bright ledge @bitter sparrow here's the PR, it's ready now: https://github.com/TheBevyFlock/bevy_quickstart/pull/229

[bitter sparrow]

what i'm unsure about is the ones that add {Commands,EntityWorldMut}::run_system_once{,_with}

which are used internally in the other extension traits

i could inline that instead

[slender belfry]

Would also like some feedback from @prisma delta

[bitter sparrow]

i think i'll just opt to inline it for now

[slender belfry]

Hmm? I think I'm missing some context

[bitter sparrow]

i'll just make the pr first ig

[slender belfry]

Got another PR ready: https://github.com/TheBevyFlock/bevy_quickstart/pull/230

I like how this one turned out

[bitter sparrow]

i think Vec2 is better than Dir2 here since it's not necessarily going to be normalized

for example, a joystick might not be pressed all the way

[slender belfry]

But we explicitly normalize it

[bitter sparrow]

only because we only support keyboard

AI may also want to do non-fully-pressed movement for example

[slender belfry]

Hmm, I see your point

Fair enough, I'll revert that portion

Done @bitter sparrow

Also https://github.com/TheBevyFlock/bevy_quickstart/pull/229 is alright for Alice, so I'm waiting on your review for it

[bitter sparrow]

reviewed

should we really be using clone_weak for the player entity's image handle?

seems like we do want the existence of that entity to keep the asset alive?

i mean not that it really matters since we're keeping all the strong handles in a resource

so, are we keeping widgets as extension traits or are they becoming systems?

as extension traits they can't pull in system params, though we currently aren't doing that anyways.

i mean they can be extension traits that use spawn_fn internally in theory

for reference this is what the widgets would look like as systems: https://github.com/benfrankel/bevy_jam_template/blob/main/src/theme/widget.rs

and e.g. commands.ui_root() would become commands.spawn_fn(widgets::ui_root)

another thing that "as systems" would enable would be "inheritance" / flattening, like

commands.entity(id).add_fn(widgets::ui_root) in an entity spawning function means i want the entity that i'm currently spawning to "inherit from" widgets::ui_root basically

but commands.ui_root() always spawns a new entity no matter what

[slender belfry]

Yeah, I agree. But since, as you said, it does not matter, I see the point of using a weak handle. Imo it's a bit of a micro-optimization at that point, but I guess it has educational value?

[slender belfry]

I'm ambivalent and will accept both variants

[slender belfry]

That sounds kinda exciting. We get to remove an abstraction 👀

[slender belfry]

We could pull in UI icons that way

[bitter sparrow]

yeah true, or sound effects, or BG image / 9-slice

[slender belfry]

Or config like theming

[bitter sparrow]

i'll take that as a go-ahead then

[slender belfry]

How do you pass the label text?

[bitter sparrow]

yeah so in that case it would become a non-pure entity spawning system

taking In<(Entity, MenuButton)> or w/e instead of In<Entity>

and you spawn it with commands.spawn_with(widgets::MenuButton::new("text"))

[slender belfry]

Sounds good to me.

@bitter sparrow I changed the docs on https://github.com/TheBevyFlock/bevy_quickstart/pull/230 according to feedback

@bitter sparrow I also reacted to everything in https://github.com/TheBevyFlock/bevy_quickstart/pull/229

[bitter sparrow]

responded

[bitter sparrow]

approved with ignorable nit

[slender belfry]

applied it and set to auto-merge

Any thoughts on https://github.com/TheBevyFlock/bevy_quickstart/pull/225 ?

[bitter sparrow]

i haven't checked it out yet

oh mb i put the & in the wrong place 😄

[bitter sparrow]

should be &OnPress(system_id)

[slender belfry]

Hehe

on it

Thoughts on merging CharacterController and Movement?

Real world character controllers would have these as one as well

[bitter sparrow]

we have a CharacterController component?

[slender belfry]

Sorry, MovementController

[bitter sparrow]

o

[slender belfry]

With speed being a max_speed

[bitter sparrow]

hm, is there any benefit to them being split?

maybe systems that mutate only one or the other running in parallel?

that probably doesn't matter

[slender belfry]

Theoretically you could set Movement for NPCs and keep MovementController player-only

I'd consider that an anti-pattern though

[bitter sparrow]

nah npcs need both too

[slender belfry]

Oh yeah right

I'll merge them then

[bitter sparrow]

okay sure

if we find out later they must be split for some reason it's easy to split

combined is a smaller surface area

[slender belfry]

👍

[bitter sparrow]

why is our header widget a NodeBundle with a TextBundle child

surely it should just be a TextBundle

or is there a layouting reason?

anyways i'll leave it alone for this PR :p

[slender belfry]

@agile dirge would know

[agile dirge]

I couldn't figure out how to center text with a single node

so i repeated what was in button

[bitter sparrow]

ah okay ic

in that case maybe JustifyText::Center would be sufficient, will have to test it out later

[slender belfry]

(deleted my messages because I realized I was wrong)

https://github.com/TheBevyFlock/bevy_quickstart/pull/230 is ready for another review

[slender belfry]

@agile dirge and @bitter sparrow, my main question is whether I should use the String-as-key approach for all assets or only the sound effects.

[agile dirge]

if sfx is string then probably all string

[slender belfry]

I'm tending towards the same, since it feels wrong to special-case them

[agile dirge]

struct ImageAssets;

impl ImageAssets {
  const Ducky: &str = "ducky";
}

can we have something like this instead of enum?

or can we not use &'static str for get in HasMap<String, T>?

[slender belfry]

Oh, I didn't consider that and instead created a dedicated mod for the consts. Good idea, I like that better.

[agile dirge]

hmm, one big plus is

you can impl anywhere in the project

and add more consts 🤔

that is nice

[slender belfry]

Would you want to do that outside of the assets loading?

[agile dirge]

you can define assets where they are used

saddly, we can't iterate over all constants, so we still need a place where we list all assets

ideally, we'd request asset preloading locally too

but that's what iyes' asset crate does

[slender belfry]

Well, goodbye HandleMap. You were a nice pattern

[agile dirge]

hm

okay, you may not like this for the template but

if we're storing all assets of one type together

then we have a countable ahead of time list of collections

that we can access to decide whether loading stage is done

those collections could store an additional state per asset

enum AssetState {
  Requested,
  Loaded
}

then you can add a request locally

and test for all assets loaded

[bitter sparrow]

commented

fn credits_screen(In(id): In<Entity>, mut commands: Commands) {
    commands.entity(id).add_fn(widget::ui_root)
        .insert((Name::new("Credits screen"), StateScoped(Screen::Credits)))
        .with_children(|children| {
            children.spawn_with(widget::Header::new("Made by"));
            children.spawn_with(widget::Label::new("Joe Shmoe - Implemented aligator wrestling AI"));
            children.spawn_with(widget::Label::new("Jane Doe - Made the music for the alien invasion"));

            children.spawn_with(widget::Header::new("Assets"));
            children.spawn_with(widget::Label::new("Bevy logo - All rights reserved by the Bevy Foundation. Permission granted for splash screen use when unmodified."));
            children.spawn_with(widget::Label::new("Ducky sprite - CC0 by Caz Creates Games"));
            children.spawn_with(widget::Label::new("Music - CC BY 3.0 by Kevin MacLeod"));

            children.spawn_with(widget::Button::new("Back")).insert(CreditsAction::Back);
        });
}

more verbose than the extension trait but probably fine

it might not be too crazy to still have the extension trait on top of this for the ergo

[slender belfry]

@agile dirge I updated the PR to use strings everywhere. There's a few ugly to_strings now.

[slender belfry]

Sheesh, that is way more verbose

[bitter sparrow]

yeah

[slender belfry]

I'd push for that

This is... too low-level

At least the extension trait is supremely simple

[bitter sparrow]

yep, it can even reuse the SpawnExt and WorldSpawnExt traits added in this PR to abstract over Commands vs ChildBuilder and World vs EntityWorldMut

well it may need to be two extension traits to support World actually, since it'd be returning EntityWorldMut instead of EntityCommands. so ig i will skip that

[slender belfry]

https://github.com/rust-lang/rust/issues/67792 is blocking const foo: String unfortunately. I could probably do a hack with once_cell::sync::Lazy, but I don't think that's very approachable.

[slender belfry]

Truly a moment

[bitter sparrow]

/// An extension trait to improve the ergonomics of spawning UI widgets.
pub trait Widgets {
    /// Spawn a [`Button`].
    fn button(&mut self, text: impl Into<String>) -> EntityCommands;

    /// Spawn a [`Header`].
    fn header(&mut self, text: impl Into<String>) -> EntityCommands;

    /// Spawn a [`Label`].
    fn label(&mut self, text: impl Into<String>) -> EntityCommands;
}

impl<T: SpawnExt> Widgets for T {
    fn button(&mut self, text: impl Into<String>) -> EntityCommands {
        self.spawn_with(Button::new(text))
    }

    fn header(&mut self, text: impl Into<String>) -> EntityCommands {
        self.spawn_with(Header::new(text))
    }

    fn label(&mut self, text: impl Into<String>) -> EntityCommands {
        self.spawn_with(Label::new(text))
    }
}

not too bad