#bevy_new_2d

4613 messages · Page 5 of 5 (latest)

finite depot
#

I personally think that it currently eclipses bevy_audio in so many ways that we should

#

plus, I can set it up so that mutithreaded audio in wasm works out of the box

unkempt drift
#

if there's anything i can do to help, lmk!

tacit verge
#

i don't think we should migrate to it in bevy_new_2d before it's upstreamed

#

good time for other templates to migrate, though

#

the tooling doc needs a little update for a few other things too

#
  • probably not as valuable to recommend inline_tweak now that hotpatching is better integrated
  • leafwing-input-manager -> bevy_enhanced_input (or both for now?)
  • should we still be recommending bevy_egui and bevy_cobweb_ui with the improvements to bevy ui? (i think the answer is yes, i just don't know how much we're getting yet)
finite depot
#

@tacit verge this is using feathers

image.png
#

Spawning a button looks like this:

bevy::feathers::controls::button(
    ButtonProps {
        on_click: Callback::System(commands.register_system(on_play_clicked)),
        ..default()
    },
    (),
    Spawn((Text::new("Play"), TextFont::from_font_size(24.0))),
)
#

Or, for convenience:

let button = |text: &str, cb: SystemId<In<Activate>>| {
    bevy::feathers::controls::button(
        ButtonProps {
            on_click: Callback::System(cb),
            ..default()
        },
        (),
        Spawn((Text::new(text), TextFont::from_font_size(24.0))),
    )
};
tacit verge
finite depot
#

Big issue: it's hard to change the height of the buttons

finite depot
finite depot
#

whenever I change anything they become small again haha

#

Talin says changing the height will be trivial with BSN, but right now requires a marker component to patch it up post-spawn

#

this is the "regular" height and width

image.png
#

with my font size override

#

it's just pretty tiny 👀

tacit verge
tacit verge
finite depot
#

And I don't feel particularly like adding a PatchHeight component

tacit verge
#

we can delay feathers to 0.18

finite depot
#

but the builtin core widgets are also not usable right now

#

see this

#

We cannot show this to a beginner xD

#

So yeah, I'm also for keeping our current abstraction

tacit verge
#

sounds good

finite depot
#

oh nvm I know it

#

sec

#

PR ready now

#

@tacit verge the feathers API without BSN is a bit clumsy, isn't it?

#

Done check_accept

tacit verge
#

oh woah we have Val2 now

#

just came across it while looking at px in the dev docs

finite depot
tacit verge
#

ohh okay i see the function versions were added instead of use Val::* for the number-type generics

#

so you can do px(5) instead of Px(5.0)

finite depot
tacit verge
#

i was gonna complain if there wasn't a good reason

finite depot
#

I would personally just have put Val::* in the prelude tbh

#

but this is fine too

tacit verge
tacit verge
finite depot
finite depot
tacit verge
#

EventWriter -> MessageWriter is interesting, a rebranding i guess

finite depot
#

Message is for buffered stuff

tacit verge
#

ah, okay

finite depot
#

yay merged!

tacit verge
#

oh and we'll want a tag for 0.16

#

pushed tag bevy-0.16

finite depot
trim zealot
#

there's currently no way to access the 0.16 template, right?

#

since 0.17 merged into main and there's no branch, and bevy new doesn't support tags

finite depot
#

heck

finite depot
#

oh wait that's my fork

#

sec

#

Thanks for mentioning it 🙂

trim zealot
finite depot
#

thanks again for doing that video btw

#

I hugely appreciate it 🙂

trim zealot
tacit verge
tranquil breach
hidden moss
#

Hey @tacit verge - I noticed the release pipeline doesn’t have the fix for wasm_js that the ci pipeline does. Cool if I open a PR to fix once I sort locally?

#

This one 🙂

tacit verge
tranquil breach
#

Just a heads up: if the Bevy CLI and linter get upstreamed, there's a decent chance that bevy_new_2d and bevy_new_minimal will be as well

#

Don't bother reading anything else, though! I'm still working on the rest :)

finite depot
#

With the CLI still pointing to them

#

Has that changed?

rain solar
tranquil breach
#

It hasn’t, but the TheBevyFlock/bevy_new_* syntax in the CLI will make the templates seem official, even if they aren’t

finite depot
#

If we go with variant 1, I would wish to start the discussion with what the current maintainers believe is negotiable (we can easily cut the splash screen for example, or asset preloading once bevy_seedling is upstreamed) and what is non-negotiable (for me, having any way of accessing a settings menu while the game is paused is a must-have for accessibility. Don’t care about the exact implementation)

#

Simply to make the discussion a bit more productive than last time, where I felt it was a bit of a back-and-forth between "the template is overengineered and has too many LOC" and "bevy lacks key features that necessitate the users coming up with their own abstractions"

#

Hope this doesn’t sound too jaded, I just finished a hike and I'm really exhausted haha
So if this sounds harsh or anything it’s because I didn’t put as much thought into my messages as usual, sorry!

#

I'm sure we can find common ground 🙂 heart_lime

finite depot
#

Also: hike pic!

rain solar
# finite depot

the new rendering features really shine here! super_bevy (r/SwitzerlandIsFake)

finite depot
tranquil breach
#

I’ll expand on the third option, see if there’s a way a to emphasize that the templates are unofficial

fierce jewel
#

Yeah, I do think that the third option would be the best IMHO, especially given that Flock, and these templates as a whole, have always been in a weird semi-official but not really kind of space.

finite depot
#

Ping @foggy relic in case you want to weigh in 🙂

#

This is not timely though, feel free to ignore this ping

foggy relic
#

My general take is that we should have a number of possible community templates, with some good way to discover and sort them by popularity

#

And only ship quite simple ones as "official" templates, at least for quite a while

#

I think that trying to upstream these is going to add a lot of pain relative to the benefit to users

#

I prefer solution 2 unfortunately

#

Maybe with a way for users to define aliases?

finite depot
# foggy relic I prefer solution 2 unfortunately

I find it a bit disheartening how the status of the template in that case went historically from "we should have this upstream" to "this is second party" to "this is third party", but I can live with it as long as there’s some way of saying "if I don’t specify anything, I search for the bevy flock".
Maybe a file that lists sources (ie GitHub orgs / profiles) and goes through them sequentially?

#

That way users can just add their own profile there to have the CLI search for their own templates implicitly

foggy relic
#

My preferred vision of what an official 2D template should be, at least initially, is dramatically simpler than what you've built

#

The existing form is extremely useful, especially to experienced Bevy users

#

But it's not what I think we should be introducing complete beginners to

finite depot
foggy relic
#

I don't want to butcher what you have built, which is why I don't think that we should be trying to upstream it

#

Can we rename it to something short and memorable but not literally "2d", and then have a way to have trusted template sources, with bevy_flock preloaded?

finite depot
finite depot
foggy relic
#

Something like complete_2d, and then you can go aggressive with complexity budget and really target this at "experienced Bevy users who want to get a flying start for game jams"

#

(or new Bevy users who want to peek at interesting patterns)

#

@fierce jewel @tranquil breach does this sound good to you too?

trim zealot
finite depot
tranquil breach
tranquil breach
foggy relic
tacit verge
#

i'm curious what the difference would be between bevy_new_minimal and a hypothetical simple bevy_new_2d

tacit verge
#

which might mean removing the spritesheet animation stuff because it's 2d-specific

finite depot
steady palm
# foggy relic But it's not what I think we should be introducing complete beginners to

huh, my first thought would be the opposite - I think minimal templates are more suitable for experienced users and more featured templates are more suitable for beginners. Unreal Engine for example ships with extremely featured templates for a variety of 3d game systems (first person, third person, top down, vr, etc) and I think having something significant to play with and iterate on was way more motivating to me as a beginner than something closer to a blank slate

#

I see minimal templates as being the "power user" option that experienced users reach for when they know they'll be rebuilding everything anyway

foggy relic
#

I think it depends on the beginner? We get a lot of folks who insist on understanding how everything works, and will drown in complexity

steady palm
#

fair, I wonder how much of that is Bevy currently attracting more experienced programmers rather than beginner programmers

hidden moss
tacit verge
finite depot
#

Hey, back from my mini vacation!

#

Is there anything left to do to fix the release workflow?

#

We can also change the CLI stuff to use the latest release now, I believe

tranquil breach
finite depot
#

If not, that’s also fine, I can do it over the next few days

tacit verge
#

which adds like 2 minutes to the web release

#

we'll be able to simplify the CI Check web job if/when a bevy check subcommand is added, but for now we need to keep the manual RUSTFLAGS workaround there

#

release doesn't need the manual workaround because it uses bevy build

finite depot
#

Nice!

finite depot
#

Just found out something neat: rustc +nightly -Zhelp shows you the default for nightly flags

#

I'm using it right now to see if my memory is correct in that the parallel compiler frontend is nowadays enabled by default in nightly

#

nvm it doesn't show the default for that one specifically 😬

tranquil breach
tranquil breach
finite depot
tacit verge
#

and then we can replace it with bevy check web in the future hypothetically

finite depot
tacit verge
#

that's in a separate job i believe

finite depot
#

so we could cache it, right?

tacit verge
#

oh um yes if the jobs share a cache, idr

finite depot
#

Or run bevy lint and bevy lint web right after each other

tacit verge
#

yeah that would work as well, but we don't want one job to take much longer than the others

#

but yeah i think there's a few valid approaches

finite depot
tranquil breach
tacit verge
#

currently the Bevy lints job uses the ci cache key and the Check web job uses the web-ci cache key

#

they could use the same cache key if there's significant overlap in build artifacts after switching to bevy lint web

#

but i'm not sure that would be the case

tranquil breach
#

The cache gets populated once the action is run on main, and shouldn't expire as long as it is used enough

tacit verge
#

ah okay i see, great

tranquil breach
#

I was hitting a weird CI error in my PR: turns out bevy lint web doesn't enable the getrandom backend bavy

normal shale
tranquil breach
rain solar
trim zealot
#

it prevents new users from getting rc.2, for example

#

so they run, get an old version, and have to debug

finite depot
#

Or is that outdated? hmm

trim zealot
#

dunno, but the install for the template being different than what you'd get if you did it yourself is weird anyway tbh

tacit verge
#

so effectively we distribute a Cargo.lock currently

#

if we don't distribute a lock file, the initial commit will fail CI due to --locked

#

so we have to choose between shipping Cargo.lock, asking the user to run cargo update on generate, having the initial commit fail CI, or having no --locked in CI

#

unless there's a 5th option we haven't thought of yet :)

tacit verge
#

it's not ideal over a longer period of time as releases and fixes come in

finite depot
#

oooooh I see

#

hmmm I don't like any of these options

trim zealot
#

honestly having no --locked in ci, and not distributing the .lock makes the most sense. Then "Bevy works as expected" when using the template. In the other cases you need to allow the template to run commands on your computer, or somehow just know that there's an out of date lockfile, etc

#

the lockfile feels like its introducing the problem

#

people who know how to edit a lockfile to make changes have a higher level of knowledge to actually be able to go check if --locked is being used in ci; compared to a beginner who doesn't even know what a lockfile is or why it would be causing failures

tacit verge
#

yeah, i can see "no --locked in ci" being the least bad option. i'm not sure exactly what the pros/cons of --locked in ci are

trim zealot
#

transitive dependency updates would be the biggest risk

#

but for a game jam the cycle is short, so if you hit a transitive dependency update that breaks you, everyone breaks at the same time

finite depot
tacit verge
#

iiuc, without --locked, if a user updates a dependency in their Cargo.toml and pushes a commit without running cargo update or cargo build first to also update Cargo.lock, then whether or not they have committed a Cargo.lock file, their CI will always update to the latest dependencies (compatible with the Cargo.toml)

#

because the cargo build in CI will see that the Cargo.lock is outdated and try to update it before building

#

which means inconsistent builds

tacit verge
trim zealot
#

why would you need that situation to be an error in a game jam environment?

tacit verge
#

you probably wouldn't

#

if we're unofficially optimizing for game jams (which we kinda are) then that's probably the least bad option

#

with the behavior documented somewhere in case someone cares to change it

trim zealot
#

I think we're optimizing for new projects, even in the case where its not "game jams"

#

and new projects get dependency churn more often than established projects

#

(I do agree that the game jams are the primary promoter of the templates though)

tacit verge
#

least friction for users is the most important imo

trim zealot
#

docs seem like a good alternative nod

tacit verge
steady palm
# tacit verge unless there's a 5th option we haven't thought of yet :)

in javascript land, the usual approach for CLI project scaffolding is to have the CLI run package manager commands during the process, especially if the user selected extra add-ons to the template - given that bevy_new_2d's readme already instructs people to use it via the Bevy CLI, is "make the bevy CLI run cargo update during project creation" a 5th option?

trim zealot
#

worth noting that this is generally because scaffolding clis in javascript land don't actually perform the scaffolding themselves because every individual project has their own tool, so scaffolding a react app has to call out to create-react-app, or create-vue-app, etc, installing arbitrary other packages and executing them.

steady palm
#

my assumption is the reason it's common in javascript land is because node_modules has to be installed for the project to run, so the only way to generate from a template and leave it runnable is to run npm install at minimum. unlike cargo which will always grab dependencies before running without you having to do it separately

#

but still, CLIs automating package manager actions is pretty common more broadly too, and the bevy cli already calls out to cargo for several things

trim zealot
steady palm
#

right, that just seems like an implementation detail to me i guess

#

you can install any of these clis manually (npm i -g create-react-app etc) and run them that way, npx is just a proxy for that to make it easier. it's like having a command that does cargo install bevy_cli && bevy new -t 2d

trim zealot
#

as long as the solution doesn't result in users being confused as to why their application or template doesn't work, I'm cool with it. auto-running update does away with most of the benefits of shipping a lockfile.

tacit verge
#

we should update the hot-patching section in the README now that bevy 0.17 is released with built in support

fierce jewel
#

Hey so I was going through some stuff and wanted to bring it up for discussion here:

I was looking at the recommended to 3rd-party tools section of: https://github.com/TheBevyFlock/bevy_new_2d/blob/main/docs/tooling.md

and noticed that it has leafwing-input-manager and mentions that it is likely to be upstreamed, but does not mention bevy-enhanced-input. Given the change is circumstances here, should this be changed or otherwise updated?

Also wanted to ask if we should include: bevy_link_window_to_monitor and bevy_simple_screen_boxing as well, given that they fill rather useful API gaps, especially for pixel art based 2d games.

Related issue for bevy_enhanced_input and as a note it seems that things in bei have stablized a bit as well it seems: https://github.com/TheBevyFlock/bevy_new_2d/issues/351

GitHub
Replace LWIM recommendation with bevy_enhanced_input · Issue #351 ...

Very out of the loop for this one, but it looks like bevy_enhanced_input is more likely to be upstreamed?

foggy relic
#

We should probably update it

hidden moss
#

hey guys! i'm working on a custom experimental editor which integrates with the bevy_new_2d template (ie, creating a project just calls bevy new --template 2d and i'm getting a sneaky terminal prompt behind the scenes: Enter your itch.io username. Leave blank to disable itch.io upload. []:

is there a way to disable this?

hidden moss
#

ah! found an env var i can use to skip:

let status = Command::new("bevy")
        .args(&["new", project_name, "--template", "2d"])
        .env("CARGO_GENERATE_VALUE_ITCH_USERNAME", "")  // Skip itch.io username prompt
        .current_dir(parent_dir)
        .status()
        .map_err(|e| format!("Failed to run 'bevy new': {}. Is bevy CLI installed?", e))?;
rain solar
#

You should be able to pass —silent to cargo generate iirc

#

So something like bevy new -t 2d — —silent

hidden moss
#

ah interesting, i'll have to test that - for now i'll just hack in an empty username 🙂

tacit verge
#

can confirm these commands work: bevy new foo -t 2d -- --silent to skip all prompts or bevy new foo -t 2d -- --define itch_username= to explicitly skip the itch username prompt, which also allows you to set a non-blank value programmatically

tranquil breach
#

There's been some conversation in the CLI wg about bevy_new_2d. Forwarding this here so y'all can take a peek :)

#

I also noticed that cargo generate --test is a thing

# 
Options:
      --test
          Expand $CWD as a template, then run `cargo test` on the expansion (set $CARGO_GENERATE_TEST_CMD to override test command).
          implies --verbose
          
          Any arguments given after the `--test` argument, will be used as arguments for the test command.
tacit verge
# tranquil breach

yeah we could do that. the contributor UX would be about the same*, but it would be better for code review

finite depot
tacit verge
#

* because:

  1. contributors could edit the .template files directly, but in order to try their changes out they'll have to either duplicate them anyways or generate a temporary project
  • this is better UX for trivial changes, but not really better for non-trivial changes
  1. we'd need a script to generate local copies of all the .template files, and new contributors would likely not know about it
  2. contributors would have to rerun the script after git pull if they want to keep their local copies in sync with the .template files
#

so sometimes better UX, sometimes worse UX

#

regardless of the approach, we should have a docs/contributing.md to link to

#

(because this shouldn't go in docs/design.md, which is for users who don't care about this, not template contributors)

tacit verge
finite depot
#

Is there some way to tell GitHub pages to enable SharedArrayBuffer, I wonder

#

for the multithreaded audio

#

On itch there's a neat lil checkbox

tacit verge
finite depot
robust fog
finite depot
finite depot
#

For example, the Bevy CLI lints can take longer to finish than the tests, but wouldn’t include the full test compilation needed to actually run them

robust fog
#

Another thing that I'm trying to understand (from the tests job):

- name: Restore Rust cache
  uses: Swatinem/rust-cache@v2
  with:
    shared-key: test
    cache-directories: ${{ env.LD_LIBRARY_PATH }}
    save-if: ${{ github.ref == 'refs/heads/main' }}

- name: Install build dependencies
  run: sudo apt-get update; sudo apt-get install --no-install-recommends libasound2-dev libudev-dev libwayland-dev

Why is LD_LIBRARY_PATH cached specifically in the tests job?
Also the dependency step is guarded by if: steps.cache.outputs.cache-hit != 'true' in the other jobs but not in this one. Is there a reason for this?

tacit verge
#

if there's a cache hit, those crates will be downloaded from cache instead of compiled fresh so the build dependencies won't be needed

#

as for why the cargo test job doesn't do this too, i'm not sure. i assume it failed without the build dependencies even on a cache hit, but i don't remember why

tacit verge
#

in the ci group we have lints that enable all features to get as much code coverage as possible, in the test group we only enable default features (because enabling e.g. web and native features at the same time doesn't make sense if you're actually running the code, it only makes sense for lints), and in the web-ci group we compile for the wasm target

#

so that's 3 incompatible cache groups

robust fog
#

But I don't think it's needed anymore right?

tacit verge
#

yeah that might be it, i couldn't remember what that was for

#

i might have missed that part of the workaround

robust fog
tacit verge
#

so it can be removed now

robust fog
#

Is the simultaneous *.rs + *.rs.template approach typical to cargo-generate projects? 🤔
Looking to make my own template but template files are a pain from an IDE perspective.

finite depot
#

we do it like this in order to be able to open the template in an IDE

#

but we are thinking of removing it since contributors found it unexpected / confusing

robust fog
finite depot
#

sounds crappy, and it is

#

but right now you also need to copy-paste stuff. Namely from the .rs to the .rs.template

robust fog
finite depot
robust fog
finite depot
#

Which we would also have to install in that workflow

robust fog
finite depot
finite depot
robust fog
#

Hmm I don't really like the duplicated *.template files, but I think the current approach is probably the most straightforward for now 🤔

robust fog
# finite depot oh, is it?

Idk, I tried running it in the past but it just took so long that I got impatient and gave up. Not sure how well it'd behave inside GitHub's runners.

finite depot
#

And tbh we could really use a way to automatically test that the actual template initialization works haha

#

we get regular PRs that are just "fix the template"

robust fog
finite depot
#

that wasn't there when I last checked

#

ah yep

#

added it a year ago

robust fog
#

Yeah it's nice, but the workflow thing is still an issue since workflow files have to be in the root 😔

robust fog
finite depot
tacit verge
#

tbh i think our approach is already ahead of the curve here but ^\_(``/)_/^

finite depot
robust fog
#

Btw, is there a way to re-generate the *.rs file in the template repo itself (to ensure they're synced)? Or is that manual too?

finite depot
#

Guess that would be easier with the ratatui setup

#

Since I think they just generate the entire shebang every now and then

robust fog
robust fog
finite depot
robust fog
#

I think I'll just go with the good old sed for now since it's a personal project anyways. cargo-generate is still to much friction 😔

finite depot
tacit verge
#

i wonder if template directives could be put entirely in comments

#

depending on the format of course, but every file we might want to template has syntax for comments

#

like something like this:

[package]
# {{remove next line}}
name = "bevy_new_2d"
# {{insert line: name = "{{project-name}}"}}
# {{insert line: authors = ["{{authors}}"]}}
version = "0.1.0"
edition = "2024"
# {{remove next line}}
license = "MIT OR Apache-2.0 OR CC0-1.0"
tacit verge
#

a little confusing to read, but it would give "single source of truth" + "language tooling works"

sharp igloo
#

Quick question regarding the pause solution in this crate: I see this is how systems that are "pausable" are disabled when in a paused state:

app.configure_sets(Update, PausableSystems.run_if(in_state(Pause(false))));

But I don't see any check for the active screen to determine pause state. To me it seems like the game defaults to Pause(false) so I'm wondering whats stopping the systems in demo from running on the splash screen, while loading, etc...

tacit verge
#

for example, maybe you want to add a little controllable ducky entity to the main menu and have the player select an option by moving the ducky

#

if there's no ducky entity in the world during a particular screen, then the systems that manage its movement, spritesheet animation, etc. still run but have nothing to operate on

#

the performance cost is very low until you get into huge numbers of systems (i couldn't tell you specifics, but i'm sure there have been benchmarks)

#

and in terms of correctness it's reasonable for most systems to run in any screen

sharp igloo
#

Yeah I guess that makes sense thanks for the explanation. You do end up having to make sure certain resources exists where it is necessary like bevy_new_2d does here:

(
  update_animation_movement,
  update_animation_atlas,
  trigger_step_sound_effect,
)
 .chain()
 .run_if(resource_exists::<PlayerAssets>)
 .in_set(AppSystems::Update),

As a project grows in scale working around "these systems need X resources loaded" with these specific run conditions can get tiresome so just saying "dont run any in game systems until loading is done" seems easier. But I get what you're saying too!

tacit verge
#

instead of requesting Res<PlayerAssets> in the system's arguments, we can request If<Res<PlayerAssets>>, which is equivalent to adding that run condition (skip the system if the resource is not available)

#

i forgot that this was added recently. we should migrate to it

sharp igloo
#

Ooo that’s sweet!!

tranquil breach
#

Hi people! @rain solar and I were discussing the lint idea for the linter, and we wanted to get your input. The idea is a lint that warns against println!() and print!(), recommending info!() and other logging functions instead

#

This can be done with Clippy's disallowed_macros lint, however, so it seems kind of silly re-implementing it

#

Is this something bevy_new_2d might be interested in configuring? How much friction is this bound to create, since println!() is a popular debugging macro? Is this worth checking for at all?

finite depot
#

not only is info! "backwards compatile" with println!, it allows the vastly superiour debug sigil printing, AKA

info!(attack_damage=?enemy.attacks.attacks[0].dmg);
#

Which when using using the alternative debug logger (which I intend to PR later to be default-enabled), even gives you pretty-printed output!

502793849-ed4c327e-12ab-46cd-b698-1d911a2d762e.png
rain solar
#

{?:} <- you made it unhappy

rain solar
tranquil breach
#

We can provide a better UX and finer control over the output level through the Bevy linter, but would that be useful?

finite depot
#

hehe

rain solar
finite depot
#

well, about that, it seems less invasive than something else we already do, namely nonstandard_macro_braces = "warn" + a clippy.toml file that says standard-macro-braces = [{ name = "children", brace = "[" }]

#

so in that vein, I'm more than happy to configure info! > println! over clippy lints too

#

I just didn't know that lint existed haha

rain solar
#

the main downside with that is just that we cannot enforce that the lint is active

#

and the target audience for this lint would maybe more be beginners and not sure if they then have this enabled

finite depot
#

fair

#

can you lint that the clippy lint is enabled? 😛

ionic condor
#

Hi, a couple questions here: 1) did the template change much since bevy jam 6, what changed/improved/fixed in the "infrastructure" and helpers part in particular? The minimal game example does not worry me since it's striped out in our project.

#
  1. how would you go about updating an existing project that used this template back when it was created?
ionic condor
tacit verge
#

the template was updated to bevy 0.17, that's the biggest change

tacit verge
#

you can't update a template the same way you would update a library unfortunately

#

if you want to though, you could go through the commits between when you used the template and today, and manually repeat the same changes to your project

ionic condor
#

I see

tacit verge
#

we use tags as "releases" instead

#

currently we create a tag for the previous bevy version whenever we update to a new bevy version

#

so the bevy-0.16 tag is the most up-to-date version of the template for bevy 0.16

ionic condor
#

good, thanks)

spare yew
#

Since the ditching the Interaction is on the way, I ported the ui interactability from bevy_new_2d ui to a picking backend.
I can adjust it to bevy_new_2d with a PR if you want

GitHub
bevy_new_3d_rpg/src/ui/interaction.rs at main · olekspickle/bevy_n...

Solid bevy game template for 3d RPG/shooter games. Contribute to olekspickle/bevy_new_3d_rpg development by creating an account on GitHub.

foggy relic
spare yew
#

I'll try to do it for official examples as well where I'll see it 🙂

trim zealot
#

(asking because I'm using PickingInteraction in some educational material and wondering if that's part of Interaction removal, since you seem to have used the more verbose observer approach in the link)

foggy relic
foggy relic
trim zealot
#

haha ok, I'll stick with PickingInteraction for now and rethink it if something lands this cycle

finite depot
#

@tacit verge anything to be done for the jam?

#

We didn't switch to continuous deployment yet, right?

tacit verge
#

i'm going to be busy this time around because i'm looking for a job, so i'm skipping this jam unfortunately

#

i'll probably be able to review some prs, but i can't guarantee

tacit verge
finite depot
tacit verge
finite depot
#

I'll do that and ping you for a review

#

no worries if you don't have time 🙂

trim zealot
normal shale
finite depot
#

that would entail removing bevy_lint, right?

rain solar
finite depot
rain solar
#

i will merge BD's pr today and hopefully he has time to reveiw mine so we support bevy 0.18

finite depot
#

I'll wait then 🙂

tranquil breach
#

Yup, that’s my hope as well!

finite depot
#

@tacit verge for CD, which version do we use? Just what we find in the Cargo.toml, I suppose?

#

In which case, I think itch.io is fine with uploading the same version multiple times, right?

#

could also do the good old ⁨+some_hash⁩

tacit verge
tacit verge
#

it works as you'd hope

finite depot
#

i.e. instantly deploy main on every PR merge

finite depot
tacit verge
# finite depot No, I meant for actual continuous deployment

ah, right. in my template i have this snippet:

  # Determine the version number for this workflow.
  get-version:
    runs-on: ubuntu-latest
    steps:
      - name: Determine version number
        id: ref
        run: echo "ref=${GITHUB_REF#refs/*/}" >> "${GITHUB_OUTPUT}"
    outputs:
      # Use the input from workflow dispatch, or fall back to the git ref.
      version: ${{ inputs.version || steps.ref.outputs.ref }}
#

i see the same snippet in bevy_new_2d already

#

because it used to also trigger a release when you pushed a tag in the format v1.2.3, but that was removed

#

so it's kinda dead code in bevy_new_2d atm, but will be useful again with CD

finite depot
tacit verge
finite depot
#

Wouldn’t it maybe make more sense to use that version as a fallback instead of the tag?

tacit verge
#

i'm not sure

#

there may be like branches too

#

i don't know if i've thought through the tradeoffs, or where this fallback originally came from

finite depot
#

@tacit verge should we have an ⁨⁨env⁩⁩ flag for enabling CD?

#

also: what do we do about the options like ⁨build_for_linux⁩?

#

asking because the defaults used for the manual dispatch are ignored for the ⁨push⁩ trigger

#

so everything is ⁨false⁩ in those cases

#

do we duplicate all dispatch options as ⁨env⁩s for the CD?

#

Also, should each push to ⁨main⁩ create a new GitHub release? Probably not, right?

finite depot
tacit verge
finite depot
tacit verge
finite depot
# tacit verge CD can just build for web

so just these?
⁨```yml

Whether to deploy the newest version of the app on every push to main.

continuous_deployment: true

if continuous_deployment: true and itch_page is configured, whether to upload the build to itch.io

cd_upload_to_itch: true

if continuous_deployment: true, whether to deploy to GitHub Pages

cd_upload_to_github_pages: false

if continuous_deployment: true, whether to abort the workflow if there are warnings

cd_deny_warnings: true

tacit verge
#

you can edit an existing github release though, if you reuse the tag

finite depot
#

I like immutable releases

tacit verge
#

that's fair

finite depot
tacit verge
#

i think we can simplify it to just continuous_deployment and specify in a comment that it only builds for web, and that it pushes to itch.io if you have the itch.io username and page variables set

#

and deny warnings false

finite depot
tacit verge
#

if users want more knobs we can add them

#

i'm not sure what other people will want

tacit verge
finite depot
#

was just wondering whether to mirror them 🙂

tacit verge
#

i have this addition to this snippet:

          # Check if building for this platform is enabled.
          echo 'is_platform_enabled=${{
            (matrix.platform == 'web' && (inputs.build_for_web || github.event_name == 'push')) ||
            (matrix.platform == 'linux' && inputs.build_for_linux) ||
            (matrix.platform == 'windows' && inputs.build_for_windows) ||
            (matrix.platform == 'macos' && inputs.build_for_macos)
          }}' >> "${GITHUB_ENV}"
#

so that the web build is enabled if the release was triggered by a push

finite depot
finite depot
#

@tacit verge any objections to merging it? I'm testing it with a new project rn just to make sure

finite depot
#

update: yep works

tacit verge
finite depot
foggy relic
finite depot
#

@tacit verge mind checking again? 🙂

finite depot
finite depot
#

@tacit verge lil' issue: doing itch.io + GH Pages deployments on CD will mean that people who have not configured GH Pages will get a big ol' red X on every single commit to ⁨main⁩

#

there's ⁨⁨continue-on-error⁩⁩, yes, but that still gives you that ugly X, looking as if something went wrong

#

I'm failing to script a neat version that stays green on CD but does the red X on manual releases where GitHub Pages is enabled

#

so: is it fine if I split it into a CD env for itch and another for GH Pages?

#

⁨continuous_deployment_to_itch⁩ and ⁨continuous_deployment_to_github_pages⁩

tacit verge
finite depot
austere shale
austere shale
finite depot
#

You need kebab-case instead of snake_case

#

Try generating with t=https://github.com/janhohenheim/bevy_new_2d

#

That way you also get continuous deployment on top 🙂

austere shale
#

I just noticed that. That's an easy fix (I still used different chars for the repo last time - snake_case vs kebab-case).
Doesn't explain the extra control character tho

finite depot
#

Huh

#

Weird

austere shale
#

must be some nonsense in my setup

tacit verge
finite depot
#

@tacit verge I think I have addressed everything broovy

#

I'll check if the CD still works before merging

#

@tacit verge

image.png
tacit verge
finite depot
#

is if [ -n '' ]; then not working but if [ -n "" ]; then is?

#

that sounds wrong

tacit verge
#

yeah i would expect those are the same

finite depot
#

OOOOH

#

I accidentally removed the fi

tacit verge
#

oh ok that explains the error message

#

reapproved

finite depot
#

alright, works 🙂

#

ah, I should also check the manual releases

spare yew
#

hey! even when I straight copied ci workflow to my project and all the jobs are ending with

error: "/home/runner/.rustup/toolchains/nightly-2026-01-22-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/Cargo.lock" does not exist, unable to build with the standard library, try:
        rustup component add rust-src --toolchain nightly-2026-01-22-x86_64-unknown-linux-gnu

even though I see this step before
nightly-2026-01-22-x86_64-unknown-linux-gnu installed - rustc 1.95.0-nightly (eda76d9d1 2026-01-21)

Anyone has idea why? I don't think there is anything needed to setup in GH actions, right? I do not use custom runner and to me it looks like the memory between steps is not shared, which is not making sense to me

finite depot
#

but why would that act up hmm

finite depot
finite depot
spare yew
spare yew
#

I think bevy_new_2d might be building now only because it has cache, I think I figured it out, testing now

finite depot
#

but if it's a copy, then you have to have those hmm

finite depot
spare yew
#

exactly, my clue was - Format is the only job that succeeds

#

other jobs succeed (somewhat - cranelift one fails with Defining variadic functions is not yet supported by Cranelift not related to the repo at all something in rustlib/src/rust/library/core/src/ffi/va_list.rs:222)

finite depot
#

doing a new repo with bevy new -t=2d, followed by cargo update works

#

cannot reproduce, sorry :/

spare yew
#

that's something. Thank you!

trim zealot
#

heads up: it looks like the ci and release workflows are running in parallel. so a push to main runs CI and Release, with the release happening regardless of whether CI fails

trim zealot
#

There's a number of jam entries failing with this error, which I believe is due to something the bevy_new_2d actions are doing in CI. Since this also happened to me I was able to debug a bit, and right now I think the most likely candidate is that the release action doesn't lock the nightly toolchain version, and something flipped this weekend-ish.

Uncaught TypeError: Failed to resolve module specifier "env". Relative references must start with either "/", "./", or "../".

buoyant cedar
tacit verge
#

and the release workflow doesn't pin the nightly version

#

pinning the nightly version would prevent this kind of failure, but it also means building releases with older versions of the compiler/toolchain

#

which is a tradeoff

#

until manually updated ofc

trim zealot
#

so its hard to get worse than that 😅

tacit verge
#

yeah i guess so, but it's some % chance for that to happen. pinning to an older version means guaranteed more maintenance work to bump the pin every once in a while, or new language features failing to build

#

and anyone who uses the template will have to know to bump the nightly version themselves in their own project

trim zealot
tacit verge
#

yeah that's true

#

there are inevitable differences between debug and release builds so technically you should test your release builds too

#

but

#

it does increase the differences

#

plus the release workflow auto-deploys the build

trim zealot
#

nightly is known to break, so this is a foreseeable issue that users don't opt-in to

#

its not clear if anyone even knows the ci script is using nightly, much less the release script. and local development is happening on stable almost guaranteed

tacit verge
#

idr why release uses nightly, maybe some unstable optimizations

trim zealot
#

same, I was surprised to see nightly in the release tbh

#

especially unpinned, which is not something I see people using nightly in production doing

tacit verge
#

ic

trim zealot
#

I do think if nightly is desired that's fine, but it does need to be pinned to something so it works during the whole jam and isn't subject to the nightly releases breaking

tacit verge
#

i think that's reasonable, especially considering the majority of usage comes from the bevy jam

#

as for users who start from the template for a longer-running project

#

i guess the CI already pins to a nightly version so they already need to be aware of that

#

we can pin both ci and release to the same version i guess. and add a note about it to the workflows doc, for the benefit of any users who come across and read that

trim zealot
#

or was that already ruled out for some reason

tacit verge
trim zealot
#

personally I would want to develop with the same version being used in ci, for releases, etc. So its more likely that I would run into this kind of thing in development

tacit verge
#

how does rust-toolchain.toml interact with CI which has to install the toolchain from a github action?

#

i guess it would depend on the action

trim zealot
#

I would argue that a ci action that installed rust and didn't respect rust-toolchain would be buggy tbh

tacit verge
#

dtolnay disagrees 😭

trim zealot
tacit verge
#

one caveat to using rust-toolchain.toml here is that bevy_lint requires a specific nightly version, so if you edit that file for your local builds, it'll break CI

#

i think that's the only issue though

trim zealot
tacit verge
#

bevy_lint is awkward for CI right now for sure

#

there is value in dogfooding it for feedback

#

an easy or auto opt-out might be nice

trim zealot
#

enters feedback about it being hard to use in ci

#

😆

tacit verge
#

yeah for sure, i don't actually know why it requires a specific nightly version. apparently there's some important unstable feature being used

tacit verge
#

that would mean mostly-silently not running bevy_lint anymore, but only for users who edit rust-toolchain.toml. which could include an inline comment explaining that this will happen

#

i'll write up an issue summarizing

trim zealot
#

yeah, it already broke and the jam is over so I would assume that the next major inflection point would be 6 months from now for the next jam

tacit verge
#

also i've been out of the loop on the current bevy jam

#

how was the caching + continuous deployment to itch.io with every push to main working out?

#

i'm wondering if there were any issues or confusion, or if users found it helpful

#

or if no one knew about it since it's opt in

trim zealot
#

I found it strange that the ci and release actions ran in parallel, and not in sequence.

#

didn't notice anyone saying anything either way about it though, so not sure people in #jam noticed it existed

finite depot
finite depot
tacit verge
#

like branch prediction

#

more resources used too

trim zealot
tacit verge
#

all the CI jobs run in parallel too for example

#

like bevy_lint still runs if cargo check fails or w/e

tacit verge
finite depot
tacit verge
#

i think it would be possible to move the CD into the ci.yaml file as another parallel job

#

and then only do the deployment if the entire CI passes

#

but the build runs in parallel either way

#

probably by the time the release build is done, the rest of the CI is done anyways so no time lost

trim zealot
#

I guess, what is the purpose of the ci scripts if they don't block a release?

tacit verge
#

it would just make the yaml more complicated

trim zealot
#

should they even exist?

tacit verge
#

that's already valuable to me at least

trim zealot
tacit verge
#

i think both ways are valid

#

blocking the deployment might be a better default

#

deploying despite failing CI can still be nice if you want to fix the CI failures later but check that the release is working now

#

for example

#

but that's pretty niche, you can also just fix CI first or trigger a manual release (although that's not cached so it's slow)

trim zealot
#

imo its not "integrated" if the build doesn't pass, because it doesn't "work"

#

but I'll leave that up to y'all.

tacit verge
#

yeah i guess i just view the continuous deployment aspect as a dev-time feature

#

but i suppose it doesn't have to be

trim zealot
#

it is inherently going "to production" if its going to itch

tacit verge
#

not if the page is still private

#

(i think? or maybe that's technically still to production?)

trim zealot
#

that's absolutely the production environment. The environment doesn't change when you flip the visibility flag

tacit verge
#

well i'll make an issue for it anyways since i think it would be a reasonable default

trim zealot
#

I know Jan's team had 11 or so people. So if any of them wanted to check the current build, that's where they would go

#

assuming, of course, that the release works

tacit verge
#

yeah and you might want to see the most recent commit even if some style lints caused CI to fail

#

like it's a valid option during development

trim zealot
#

well no. if you don't care about the lints, then you don't care about the lints. Why are you running the cpu cycles to check if you don't action them

#

the implication here being that the lints and tests, etc are doing useful things

tacit verge
#

i'll have to agree to disagree at least for my preferences for my own dev workflow

trim zealot
#

yeah, that's up to y'all. I will say "ship the build with failing tests" is not a production philosophy that I've seen intentionally adopted anywhere.

tacit verge
normal shale
wary cobalt
#

Hello, is backporting the itch.io deploy to my project as simple as copying the release.yaml into my project and editing it ? Or are there additional steps or a better way to do it ?

finite depot
wary cobalt
#

Thanks, it might be cool to have CI/CD setup included in the CLI as a command, but maybe I'm just lazy

tacit verge