#0.14 Bevy Jam

1 messages · Page 2 of 1

bitter sparrow
#

with the old bg color

prisma delta
#

Ikea themed?

#

I like this

agile dirge
#

looks good

slender belfry
#

Theme: IKEA

agile dirge
#

build the engine yourself

bitter sparrow
#

it's not giving bevy. but there is contrast

prisma delta
#

Bevy has no accent colors T_T

slender belfry
slender belfry
#

It's kinda janky

#

But in a friendly way

#

:>

bitter sparrow
#

bevy website colors

2024-07-07_1720381491_1369x417.png
prisma delta
#

I think that's too somber

slender belfry
agile dirge
#

where are the web designers when you need them

slender belfry
#

@night saddle help

prisma delta
#

Literally bikeshedding me here :p

bitter sparrow
#

this is how i did it in bevy jam simulator

prisma delta
#

Going to launch it in 15

bitter sparrow
#

which was imitating the bevy jam page

slender belfry
bitter sparrow
#

i don't like it 🤐

slender belfry
#

But it looks so happy and joyful!

night saddle
slender belfry
#

✨

night saddle
bitter sparrow
night saddle
#

it's a jar of jam because ... jam :)

#

I generally associate red with jam

slender belfry
#

Oh esteemed coding wizard, do you have a palette that will fit?

night saddle
prisma delta
bitter sparrow
#

the yellow makes me think under construction

slender belfry
bitter sparrow
#

but anyways w/e the colors are i will cope ofc

prisma delta
#

More refined gold to compare

image.png
agile dirge
#

how about white font on dark bg?

image.png
night saddle
slender belfry
bitter sparrow
agile dirge
#

bg2: #5b83c2
text: #ffffff
link: #dfbf43

prisma delta
bitter sparrow
#

#ececec would be bevy white

agile dirge
#

it looks better cause the letters in banner are the same color

#

now i noticed

prisma delta
slender belfry
bitter sparrow
prisma delta
#

Pure white is trash-tier 😉

#

Okay, minor snack, then announcing

night saddle
#

graphic design is my passion

image.png
prisma delta
night saddle
#

@slender belfry says that he unironically loves it and will stop contributing to bevy if this doesn't become the offical bevy jam color 🙃

prisma delta
#

I do kinda like the logo: good choice of red

slender belfry
night saddle
bitter sparrow
#

i ironically love it if that helps

prisma delta
#

Alright, time to spam thousands of people

slender belfry
prisma delta
bitter sparrow
#

yes, mention 4000+ users individually instead

prisma delta
#

Thanks y'all 😄 Very pleased to have this set up so quickly after the release

#

And the feedback was really helpful

slender belfry
# night saddle graphic design is my passion

Hi people who arrived by clicking on the announcement post! Please note that the comment I'm replying to contains the real theming of the jam. Make sure your submissions are strawberry jam themed!

agile dirge
#

the #jam-theme-voting is a red herring, Alice will veto all themes

bitter sparrow
#

@prisma delta description of #jam channel is outdated

prisma delta
#

Good call

#

Maybe we should ship the winner Bevy merch from an experimental merch provider lol

#

They can alpha test it for us!

#

Perfect theming for the engine really

slender belfry
#

I'll also accept merch from an experimental merch provider

prisma delta
#

I mean it can't be worse than TeeSpring TBH

slender belfry
#

for testing reasons

slender belfry
prisma delta
#

Quality was just terrible

#

We sold one (1) water bottle to me though, and it's frickin' great

inland wyvern
#

I still have my sticker on my water bottle and my hoodie although it is pretty peeled 😦

slender belfry
#

@bitter sparrow @agile dirge I addressed your comments check_accept

agile dirge
#

seen it, ready for rereview?

#

and then merge i suppose

slender belfry
bitter sparrow
#

i'll just consider it approved by me, i don't want to reread and create infinite code review loop

slender belfry
#

I'll do more refactoring, but I want to have individual PRs so you two don't have to read through hundreds of lines at a time 😅

bitter sparrow
#

yep

agile dirge
#

at least give approve cause you requested changes

bitter sparrow
#

ok

slender belfry
agile dirge
#

what's your next refactor target?

slender belfry
#

Naming

agile dirge
#

we should group all state transition logs into debug

slender belfry
#

Ah, I see

#

good idea!

bitter sparrow
#

yeah those lines should move into the dev plugin

agile dirge
#

and if we are in a cfg feature dev, we can just import dependencies that are dev, no need to address them fully

#

also, chaining those log systems is a good idea

#

from root order

bitter sparrow
#

huh. came across https://goodfirstissues.com/, which links to some of our issues lol. probably not what we want, i'll rename the tag to uncontroversial

hoary flower
#

hype 😄 ; a link to #jam-theme-voting on the announcement would be welcome

slender belfry
#

I've never actually worked with sub-states before, so thanks @agile dirge for teaching me this pattern 🙂

agile dirge
#

im still figuring out how to lay it out

#

i started by dumping the whole hierarchy in a single file...

slender belfry
agile dirge
#

appr

slender belfry
#

@bitter sparrow would you mind doing a pass on the states and substates? I feel like I'm not knowledgeable enough in that regard to critically evaluate them.

agile dirge
#

(the structure not the names 😅 )

bitter sparrow
#

so rather do it after the prs are in

bitter sparrow
slender belfry
#

Obligatory pyri_state handles this better 🙂
Hehehe

bitter sparrow
#

in pyri_state i enable logging for a state type with #[state(log_flush)] on the enum itself, and i have a state debug settings resource that allows globally toggling certain transition messages

#

including on-exit, on-enter, on-transition (because those happen at different points in the schedule, so it's useful to separate them)

agile dirge
#

I wouldn't call more macro usage as strictly better

bitter sparrow
#

the point is you're localizing the configuration

slender belfry
bitter sparrow
prisma delta
bitter sparrow
slender belfry
#

#jam message this cracked me up lol

bitter sparrow
#

ok so before i do this refactor, gonna ask opinions

#

the way i have things split up in my template:

  1. core: cross-cutting things like audio, camera, config, debug, physics, theme, window plugins
  2. game: game mechanics / content / logic
  3. util: self-contained re-usable utilities like ui, despawn queue, some animation stuff
  4. screen (can rename this): the "main" app state flow, boot -> splash -> title -> loading -> playing -> end, with each state having its own module
#

imo having the main app state flow as a single state type is nice. that was before substates were added ofc

slender belfry
bitter sparrow
#

it doesn't contain stuff like "the game HUD"

agile dirge
#

it's ui util

slender belfry
bitter sparrow
#

it's font utils, tooltip, button interaction utils

slender belfry
#

then that sounds good 👍

bitter sparrow
slender belfry
#

core and game is also good for me

slender belfry
#

main_app_state?

bitter sparrow
#

i also had it named "sequence state" previously

slender belfry
bitter sparrow
#

"game state" would be the name commonly used in tutorials etc. because they're not real games imo so it's obvious in context

slender belfry
bitter sparrow
#

i'm fine with going with a different name though, the structure is the bigger thing

slender belfry
#

Structure-wise it sounds good to me 🙂

agile dirge
#

i feel like anything that isn't util is core

#

especially game mechanics

slender belfry
agile dirge
#

i can see the point of separating out gameplay from menu navigation

#

better question, do we have enough content in the template to fill all the spots in the template

bitter sparrow
#

game would be small

slender belfry
#

I'd put the character movement code in game

agile dirge
#

i feel like if the name isn't clear and there is no example, there is no point

bitter sparrow
#

in my own template, game is tiny

agile dirge
#

what's example content in game

bitter sparrow
agile dirge
#

game struct definitions?

#

or game logic

bitter sparrow
#

let me get some examples from an actual game im writing

slender belfry
agile dirge
#

then what does core have

bitter sparrow
#

game: actor, combat, fog, projectile, weapon, resource, world_gen

#

and actor splits into a bunch of stuff

#

core: audio, camera, config, debug, freeze (aka pause), input, physics, theme, window

slender belfry
agile dirge
#

hm

bitter sparrow
#

yeah that would go there if it needs something cross-cutting

agile dirge
#

i don't like the name

bitter sparrow
#

common better?

slender belfry
agile dirge
#

core sounds weird

#

it's more of a wrapper around the engine

slender belfry
#

boilerplate /s

agile dirge
#

would

#

honestly

#

design pattern-wise it's adapters and bridges

#

engine

#

i think this fits

slender belfry
#

It's not perfect, but better than core

bitter sparrow
#

im happy to delegate the naming since im kinda dictating structure :p

slender belfry
#

Oh yeah sure

#

I won't block the PR on naming

#

we can change that whenever

bitter sparrow
#

ok

slender belfry
#

structure is good tho 👍

agile dirge
#

yeah now that things are cleared up I'm alright

slender belfry
#

I was ready to start an essay over that one

agile dirge
#

it's annoying to name every little plugin when the module has a name

#

lol

bitter sparrow
slender belfry
#

no need 😄

bitter sparrow
#

fsfs

agile dirge
#

okay, so we each make our own template and then we fight and the winner's PR gets merged

slender belfry
bitter sparrow
slender belfry
agile dirge
#

use jam to decide the next template xD

bitter sparrow
agile dirge
#

frfr

slender belfry
#

rea, as @fresh drift would say

agile dirge
#

og

#

i dont think it sends a notification if you edit in the mention

bitter sparrow
#

i'll test that @agile dirge @slender belfry

slender belfry
#

test @bitter sparrow

agile dirge
#

i was looking at this channel

bitter sparrow
#

ope

#

i was also looking at the channel

agile dirge
#

do it on me again

slender belfry
#

We are geniuses

bitter sparrow
#

ok @agile dirge @slender belfry

agile dirge
#

nope

bitter sparrow
#

good to know

agile dirge
#

normal new stuff

slender belfry
#

Welp, good to know

agile dirge
#

so you edit in a mention and then complain they don't read mentions

bitter sparrow
#

definitely not doing this as part of this PR but

#

quick thoughts on foo.rs + foo/ vs foo/mod.rs?

agile dirge
#

mod always

slender belfry
bitter sparrow
#

i use the former

#

so there are 2 options and we do 3 different things

#

lovely

slender belfry
#

But honestly, I'm fine with all options

bitter sparrow
#

oh wait no

#

what you do is the latter nvm

agile dirge
#

foo.rs or foo/mod.rs + other stuff

bitter sparrow
#

ok i'll keep it as the latter

agile dirge
#

it's weird to separate the module core from the rest of the files

bitter sparrow
#

i just got confused during code review with dangling mod.rs files in the nav bar

agile dirge
#

i didn't find a use case so far

slender belfry
# bitter sparrow i use the former

I usually do the former as well for libraries, but have found it to be rather hard on my organization when working on big crates like a game.

bitter sparrow
#

because they aren't even sorted to the top in github

bitter sparrow
#

which helps a lot

agile dirge
#

right

bitter sparrow
#

having everything in one folder is definitely a + for mod.rs

agile dirge
#

that was why they added it

slender belfry
bitter sparrow
agile dirge
#

no, but it's next to eachother

slender belfry
#

aaah

#

Woah, how do you do that?

bitter sparrow
#

what i long for is foo/foo.rs and IDE knows to sort it at the top 😄

bitter sparrow
agile dirge
#

idea: allow .mod.rs

slender belfry
agile dirge
#

__mod__.rs

#

gtg for a bit, ill try to at least peek at the pr when its here

bitter sparrow
#

btw my template loads config during boot, before the window is visible

#

this is useful because config may include window settings like fullscreen etc.

#

we're not doing config rn because bsn, but in the future some code there may change

#

also regarding system naming

#

i like to make it just explicit enough that you can understand what the system is if you were reading its name in an editor

#

outside the context of the code where it's defined

#

so enter_title instead of setup or enter

bitter sparrow
agile dirge
#

K

#

Sounds good

bitter sparrow
#

will edit the PR description with an overview of changes, but wanted to link the PR asap first

slender belfry
#

In fact, I'm very happy with the structure you propose 🙂

agile dirge
#

@bitter sparrow if you're gonna rework the template rework the template

#

not paste your template here

#

cause now i gotta go around and catch what you missed

slender belfry
#

Hmm? What do you mean?

bitter sparrow
#

yeah idk what you mean

agile dirge
#

Window plugin is missing comment and visibility property

bitter sparrow
#

nah

#

i moved that to boot state

slender belfry
#

It's still all there

agile dirge
#

why there? it's window plugin configuration

bitter sparrow
#

mm i'd argue otherwise

slender belfry
#

It's more of a boot logic than a real windowing configuration

#

I'm personally fine with leaving it in either, but I definitely see the reasoning here

#

Although instantiating the Window with visible = true to instantly set it to false in the boot system is a bit ugly

agile dirge
#

i jumped the gun on that a bit

#

sry

#

but

#

i'd still put it elsewhere

#

😛

bitter sparrow
#

if it helps the pr get merged i'll move it back

agile dirge
#

if you managed to get all of that together I'd say it's plugin worthy

slender belfry
#

I suppose setting it to cfg!(target_os = "windows"); in the windowing plugin and then having the boot system change it would be splitting that behavior too far appart, right?

#

After @bitter sparrow's PR is merged, I'll do one more refactoring pass, ask you for feedback / bikeshed and then implement the character movement stuff. Does that sound alright?

bitter sparrow
#

sounds good to me. you can rename modules to w/e you two prefer as well

slender belfry
#

But it's also fine if you disagree; I'm okay with having everything in window.rs or boot.rs

bitter sparrow
#

it's a small thing in the larger PR so i'm willing to defer

slender belfry
#

@bitter sparrow I'm curious about this, didn't notice it before

image.png
bitter sparrow
#

ah yeah, that's because those plugins add the bevy AssetPlugin / WindowPlugin themselves

agile dirge
#

I asked for description to that, still working on the review

slender belfry
agile dirge
#

I know what it does, but it's not a common pattern

slender belfry
#

Would be good to have a comment there at least

bitter sparrow
#

explanatory comments is fair

agile dirge
#

then we don't need to explain it 3 times and it won't mix with actual boot code, like asset loading

slender belfry
bitter sparrow
#

oh, sure

slender belfry
bitter sparrow
#

i did that before the discussion on the comment continued

slender belfry
#

Maybe add them as a comment?

bitter sparrow
#

will do

slender belfry
#

It's also good that it has a nice descriptive name like that

agile dirge
#

Okay, so the deflicker and total flattening of state is my main feedback here

#

everything else looks good

#

(will want to change core to engine in future PR)

#

and maybe screen to navigation?

bitter sparrow
#

yeah i was feeling the boot state being separate = reasonable

agile dirge
#

very subjective

bitter sparrow
#

but i flattened it so i could get the pr working faster

agile dirge
#

we can leave it and add it later

bitter sparrow
#

ok. that can go together with the deflicker pr

agile dirge
#

sure

#

so just document the default asset swapping in this one ig

#

personally I like to group my states based on valid transitions

slender belfry
agile dirge
#

but now that i think about it i broke this one rule myself so eh

bitter sparrow
#

yeah title -> credits is understandable as well

slender belfry
#

I'm pretty happy how the template is shaping up btw 🙂

#

It looks like it will be hella useful 😄

#

Good job everyone so far!

#

I'd also like to get some feedback from @prisma delta at some point, but that can still wait

agile dirge
#

yeah, the game <-> credits doesn't really make sense, but thinking about the 5/6-deep hierarchy I had, this is probably better

slender belfry
agile dirge
#

yeahh

slender belfry
#

See how Death Stranding has its credits right there in the game while you're playing

#

I think these state transitions can be left to the user. The only one that is pure nonsense is going back to Boot

agile dirge
#

yup, that would make no sense no matter what game

#

EXCEPT

#

noita

#

hahahhahasdasd

slender belfry
#

😄

agile dirge
#

there is a world where you want to perform the whole startup sequence again, without restarting the application

#

but that's too niche

slender belfry
bitter sparrow
#

love noita

agile dirge
#

I watched the talk about Noita physics

bitter sparrow
#

the only thing noita is missing is online co-op

agile dirge
#

it's stupidly simple but also very complex

bitter sparrow
#

but that would be crazy if it had that

agile dirge
#

it's also partially written in rust

bitter sparrow
#

well that's sick but base game then :p

#

but i have mods installed anyways

agile dirge
#

Noita Entangled Worlds if you wanna look it up

#

there is also the one for PvP arenas

slender belfry
#

PR LGTM now

bitter sparrow
#

thank you for reviews

slender belfry
#

I assume the follow-up will take a few minutes to be ready, so I'll go give my pet rats some play time in the living room in the meantime. Ping me when I should come back, I'll leave the speakers on loud 🐀

agile dirge
#

Sure, do you want me to do it Pyrious?

#

deflicker plugin and boot state

bitter sparrow
#

sure

agile dirge
#

just waiting for the merge then

bitter sparrow
#

CI 🥱

agile dirge
#

damn version control getting in the way of agile development

bitter sparrow
#

honestly utils could be a separate crate in the same workspace, then "self-contained" would be enforced and #![allow(dead_code, unused_imports)] would not be needed

#

^\_(``/)_/^

agile dirge
#

where would sprite animation go

#

screen or game

#

or core?

bitter sparrow
#

the logic for it? probably in utils

agile dirge
#

doesn't sounds right

bitter sparrow
#

wdym exactly by sprite animation?

agile dirge
#

component + system to increment sprinte index

#
  • plugin that adds it
bitter sparrow
#

if you could see the same code being copy/pasted into another game and being useful there, it would go in utils imo

#

ok maybe that's not the best criterium considering we're writing a template

agile dirge
#

😂

#

i thought screen at first, cause it's graphics

#

but that's not the criterium for screen

#

(the name started to make sense)

bitter sparrow
#

yep which i will admit is mildly confusing

agile dirge
#

the only other name that came to mind would be view

#

but its worse than screens

bitter sparrow
#

shorter tho i might steal that

#

actually nah

#

mmm all four top level modules being 4 letters long

#

so tempting

agile dirge
#

no cause core is getting renamed 😈

bitter sparrow
#

rea

agile dirge
#

engi

#

i feel like animation should go to core/engi

bitter sparrow
#

well i'll agree that it should go in bevy

agile dirge
#

how do we define separation between util and core/engi

bitter sparrow
#

"this could be published as a 3rd-party crate"

#

is one way to think of it

agile dirge
#

both are "below" game and screens, so technically both fit that

#

we can argue about the viability of such crate, but thats a fuzzy condition

#

okay, CI passed

#

so like

#

i do the deflicker plugin

#

where does it go 😂

bitter sparrow
#

mm i'd put it in core tbh

agile dirge
#

it would be a decent 3rd party crate

bitter sparrow
#

true, but it's like intrusive

#

it does stuff to your app when you add the plugin

#

whereas util plugins just set up plumbing so their components will function

agile dirge
#

that's what plugins do..

#

so is the separation

#

plugins vs no plugins?

bitter sparrow
#

well utils have plugins but it's like

#

app.add_systems(Update, update_font_size)

#

er

#

like the systems won't do anything if you don't use the util's components / resources

agile dirge
#

okay i can see that as a condition

#

so say

#

i have a health component

#

i want a display healthbar functionality

#

i add it to utility

bitter sparrow
#

if the separation seems somewhat arbitrary, that's because it is, i originally made the split in my own game code because i just had too many top-level modules

agile dirge
#

and only make it work on Health + DoHealthbar marker

#

yeah, I'd rather make the separation clear for myself and users

bitter sparrow
#

yep agreed

agile dirge
#

if i can't tell what goes where, there's no way a new user will be able to

#

we can iterate on that intrusiveness idea

#

it seems reasonable

bitter sparrow
#

because each game will handle health / healthbar differently

#

would probably put them in the same module, game/health.rs

agile dirge
#

but what if the healthbar is non intrusive

bitter sparrow
#

most of the stuff in game/ is non intrusive

#

in my own game code

agile dirge
#

god dammit

bitter sparrow
#

lol

#

ok so

#
  • core: intrusive, may or may not be game-specific
  • game: may or may not be intrusive, game-specific
  • util: non-intrusive, not game-specific
agile dirge
#

we're in a game engine, everything is game specific

bitter sparrow
#

oh i mean specific to this game

agile dirge
#

just less or more generic

#

even if this is this game specific

#

a healthbar mechanic can be shared between games

#

pretty easily

bitter sparrow
#

yeah but with modifications most likely

#

mm if you can make it fully generic and not depend on a Health component

#

then yes i agree it would fit in util

agile dirge
#

i don't like "ready to ship" as a condition ngl

#

the difference is very small

#

and the practice should be to make everything loosely coupled

bitter sparrow
#

understandable

#

would merging all of util into game/ be reasonable?

agile dirge
#

That's what I'm tempted to do

#

But I don't wanna rush it

#

wait, game?

#

i meant util into core

bitter sparrow
#

util is non-intrusive and core is intrusive tho

#

merging util into game would mean that "healthbar" is unambiguously in that category

agile dirge
#

hm

#

i wanna ship a venn diagram in the template

bitter sparrow
#

i like the "util = generic, can copy/paste it into other projects np" for my own projects

#

but i can see an argument for it being unnecessary in this template

agile dirge
#

minor problem in deflicker

#

we don't want it to modify state

#

probably?

#

it's a weird place to go from boot to title

slender belfry
#

Came back for a second to read up on the discussion.

bitter sparrow
#

i agree with that atp, may change my own template to do that

agile dirge
#

no no, like

#

if i move it out of screen

#

it shouldn't set state

slender belfry
agile dirge
#

epsecially as a small disconneted plugin

bitter sparrow
#

since it's moving to core that's fair game

agile dirge
#

not the problem here

slender belfry
bitter sparrow
#

oh. well Screen should default to Title, if that's the issue?

agile dirge
#

alright, you'll see when i submit the PR

slender belfry
agile dirge
#

the problem is, Boot is good for asset loading, yet the progression is controlled by a frame counter in a small plugin

bitter sparrow
#

yes therefore iyes_progress lol

agile dirge
#

sadly we do not have barriers yet

bitter sparrow
#

agreed that there will be an issue later on

#

personally i don't block in the boot state for all asset loading, just for the config (which includes window config like Fullscreen)

#

i have a loading screen after title screen that is only entered if asset loading is not fully complete at that point

slender belfry
#

You could also go from Boot to AssetLoading

agile dirge
#

wait

#

i can just define a new state

#

within that plugin

bitter sparrow
#

that's what i was trying to say

bitter sparrow
agile dirge
#

but it can be a root state

#

it's disjoint from boot

#

if you have no assets and boot changes on frame 1, then you will never see the window

slender belfry
#

(I'm back to the rats ratshakeR )

bitter sparrow
#

yeah i was saying like enum Screen { ... } substate of enum BootState { Booting, Ready }

#

unless you still mean something different

#

tbh

#

enum WindowState { Booting, Ready } and put it in core/window.rs, then later we can load window config in there as well as waiting at least 3 frames to deflicker

#

is the real answer imo

agile dirge
bitter sparrow
#

one sec

#

what will boot state be used for then?

agile dirge
#

loading assets

bitter sparrow
#

currently i only use a boot state for window config and deflicker in my own stuff

agile dirge
#

or we can remove it

#

until we need it

bitter sparrow
#

loading assets should prob not block the window from coming up

agile dirge
#

yeah

#

it doesn't

bitter sparrow
#

so imo remove it

bitter sparrow
#

would be a small refactor from your pr anyways if wanted

agile dirge
#

i don't wanna bind random visual thing to any asset loading/game logic

#

the deflicker is always 3 frames, everything else can run just fine during that

bitter sparrow
#

you mean no substating Screen?

agile dirge
#

yeah, it's a separate root state

#

on it's own

bitter sparrow
#

i can see being a substate of WindowState::Ready reading as more reasonable

#

but for deflicker yeah fair enough

agile dirge
#

i wanna introduce substate but agh

#

we don't have an excuse

#

so boot is out the window

#

unless we add title screen graphics hmmhhmm?

#

games have fancy title screen graphics

bitter sparrow
#

i load that during splash screen

#

and i embed splash screen in app

#

if it's not loaded before splash screen is done i extend splash screen until it is :p

agile dirge
#

we can do splash screen

bitter sparrow
#

this kind of asset loading management will probably be rough without iyes_progress and bevy_asset_loader though

agile dirge
#

yeah..

#

i was working on a barrier primitive for that, but it's not ready

#

something generic enough to get upstreamed in a week

bitter sparrow
agile dirge
#

i don't wanna add substates for the sake of adding substates

bitter sparrow
#

it isn't

#

it only seems that way because we don't have window config yet

#

will make more sense once that's added

#

but we probably won't add that before the upcoming jam anyways ig :p

agile dirge
#

i don't see how substates would work with that

#

it still need some sort of barrier

bitter sparrow
#

WindowState::Booting is the initial state, hides the window and loads the window config, then switches to WindowState::Ready once that's done
Screen is a substate of WindowState::Ready, and defaults to Screen::Title or splash or w/e

agile dirge
#

but flicker doesn't block anything

bitter sparrow
#

suppose there's a splash screen and it's an animation

#

and you don't want to miss the first 3 frames of the animation :p

#

something like that

agile dirge
#

but we don't have a splash screen ;-;

bitter sparrow
#

or more if loading window config takes longer

#

yeah this is all speculative about future features, fair enough

#

it's not adding substates "for no reason" though

agile dirge
#

it makes some sense

slender belfry
#

Better to not have too much in there for future features imo, because we'd need people to understand how, where and why they would have to put them there

bitter sparrow
#

my argument is moreso that waiting for the deflicker before entering the initial screen is "more correct"

slender belfry
agile dirge
#

if we have a splash screen

#

are we going for a splash screen?

#

wouldn't hurt

bitter sparrow
#

there was an issue that i thought was about a splash screen, but it was closed as dupe so maybe not

agile dirge
#

no jammer is gonna bother doing it

#

so we could

bitter sparrow
agile dirge
#

that's for web

#

while app is downloading/loading

bitter sparrow
#

ok in that case yeah dupe

slender belfry
#

I'd have nothing against a splash screen

agile dirge
#

aight, splash screen it is then

bitter sparrow
#

hooray

slender belfry
#

Nothing too important, but if someone implements it, I'd be happy 🙂

bitter sparrow
#

i have it in my template but i'd prob have to re-implement it to not use any 3rd-party crates etc

slender belfry
agile dirge
#

ouch

slender belfry
#

I wasn't here for most of the discussion, I'm maybe missing context 😉

agile dirge
#

i don't see it as a valid argument without a splash screen

bitter sparrow
#

well, i can just implement splash screen next

slender belfry
#

Alright, fair

bitter sparrow
#

after this pr

slender belfry
#

I'll approve it like this then

agile dirge
#

no no

#

ill do the hierarchy since we agreed on splash screen

slender belfry
#

Alright 😄

#

Also fine to leave it like this and change it in a PR that actually adds a splash screen

#

Your choice

agile dirge
#

might as well make a splash screen >.>

#

Pyrious, start figuring out how to await for both, splash screen image to load and deflicker to finish

prisma delta
#

Man I'm going to steal so much of this for the examples :p

bitter sparrow
#

im gonna steal some of this for my own template before the jam too hehe

agile dirge
#

please don't it's bloated 😭

slender belfry
#

@agile dirge here's a cool splash screen for inspiration: #general message

bitter sparrow
#

it's very cool but video splash screen in bevy 😨

slender belfry
bitter sparrow
#

ah

agile dirge
#

do we know what font is used in bevy logo?

slender belfry
slender belfry
bitter sparrow
agile dirge
#

unfortunate

#

ready for review

bitter sparrow
agile dirge
#

not

prisma delta
agile dirge
#

ehh, plugin order is important ._.

#

can't add state in window, needs to be after states

bitter sparrow
#

interesting

#

bevy issue probably tbh

#

we can try to work around it for now

agile dirge
#

i know exactly why it's an issue

#

i made the god damn thing

#

xD

bitter sparrow
#

since "states" are more closely tied to the ECS itself, the plugin should probably be added early

agile dirge
#

yeah

#

the schedule has to be initialized properly

bitter sparrow
#

for now.. maybe provide two plugins in core/window.rs

#

and add them separately in core/mod.rs, with a comment pointing to an upstream bevy issue

agile dirge
#

since we plan to load assets in the booting state

#

it's not strictly bound to window

#

so i just made a new module

bitter sparrow
#

well the way it works with bevy_asset_loader at least is you can app.init_collection anywhere, and it'll start loading the assets asap

agile dirge
#

there

bitter sparrow
#

so the window plugin wouldn't have to know about it

#

idk if it's possible to decouple like that with raw bevy_asset

agile dirge
#

aand fixed

#

i added the suggestion by hand, was slightly faster :p

#

5 min break while CI finishes

slender belfry
#

Great!

#

I'll do a fairly small refactor now on top of your PR

agile dirge
#

will you touch widgets?

#

i'm gonna do the closure thingy

slender belfry
#

Nope

agile dirge
#

👌

slender belfry
bitter sparrow
#

im just gonna be adding screen/splash.rs

dawn crag
agile dirge
#

Pyrious want me to add the component for hover colors?

#

i ended up doing that in my template anyways

bitter sparrow
bitter sparrow
#

i name it InteractionPalette in my code but you may have a better name

agile dirge
#

i can work with that

#

less bikeshedding for me 😛

#

im not a big fan of Pressed since for buttons the screen usually changes and you don't really see it

bitter sparrow
#

some buttons are act-on-release

agile dirge
#

I made the state transition on button releases in my case

#

yea

#

don't think it's worth adding here

#

oh, im gonna readjust palette to fit our jam page

#

@prisma delta would you mind sharing the exact colors?

bitter sparrow
#

i use xcolor on linux for this 😄

#

gets the color of a pixel on-screen

prisma delta
agile dirge
#

thanks

prisma delta
#

Much easier to just ask itch.io what the colors are 😉

bitter sparrow
#

true

agile dirge
#

i have windows powertools but not on this pc

#

they have a color picker

bitter sparrow
#

convenient that we have linux, windows, and mac between us

agile dirge
#

indeed

#

heck, all 3 have wasm 😎

bitter sparrow
#

crazy coincidence

#

merged deflicker pr

slender belfry
#

there we go

#

(idk why I replied to a specific comment there, whoops)

slender belfry
#

There are some pub modifiers that should be pub(crate) in the widget stuff, but I didn't want to cause you merge conflicts @agile dirge

agile dirge
#

thanks, lmk which ones when i get a PR out :)

slender belfry
agile dirge
#

everything that is pub should be pub(crate)?

bitter sparrow
#

technically if an item and its module are not re-exported in lib.rs, there's no difference between pub(crate) and pub iiuc

slender belfry
#

In general, there are a lot of false negatives for unused code that can be avoided when restricting visibility IME

slender belfry
#

It's not that big of a deal, but it makes other tools work nicer

bitter sparrow
slender belfry
agile dirge
#

i think app. should be before each statement, im sorry 😂

bitter sparrow
#

oh no

slender belfry
bitter sparrow
#

when i said willing to compromise i didn't mean like this 😭

agile dirge
#

Aaaaliceee

#

i still split logicaly though

#

so that one

bitter sparrow
#

i mean i don't hate that

slender belfry
#

I'll undo that change then 🙂

bitter sparrow
#

tbh no app. chains probably means better autoformat indentation

#

because the chain adds 1 level of indentation, then if you have to split a method call into multiple lines that's a second level

#

so i can see the vision

agile dirge
#

also everything is in one neat line

#

otherwise the first call is offset

bitter sparrow
#

and we're already reducing 1 level of indentation by using a fn instead of a struct

#

oh and you can delete or move a line without affecting other lines / git diff

#

genius mini

agile dirge
#

i had no clue, i just have ocd

slender belfry
#

there ya go

#

My own face in the Discord preview just low-key jumpscared me 👀

bitter sparrow
#

moving lines between groups becomes easy too

#

btw this is why i don't like rust's use foo::{ ... } syntax

#

all the same issues

#

plus hurting greppability

slender belfry
#

No please don't make remove the app chains entirely, I love them too much 😢

bitter sparrow
#

app.remove_chains

agile dirge
#

(my log transitions will be out of order)

#

eh its late

#

i should finish this pr

bitter sparrow
#

btw the "screen" name came out of the fact that i was using that as a suffix for like everything

#

"title screen", "end screen", "credits screen", "splash screen"

#

just remembered

agile dirge
#

yeah, that's when it clicked for me

bitter sparrow
#

the problem with increasing the documentation coverage in the project as a whole is that my new prs will have to include more documentation to be consistent 😡

slender belfry
prisma delta
#

Just deny missing docs

bitter sparrow
#

100% doc coverage in my bevy jam game 😨

prisma delta
#

Oh and document internal items too so you can't cheat

agile dirge
#

["i hate lifetimes"].iter().repeat(usize::MAX)

#

all i have to say

bitter sparrow
#

btw we'll probably want to add Name component to every spawned entity :)

#

we haven't been doing that so.. not now but a later PR

slender belfry
#

thanks for the reminder

bitter sparrow
#

thanks

agile dirge
#

the amount of issues is increasing at a dangerous rate

bitter sparrow
#

eh the new ones tend to be easy

#

we should avoid scope creep

agile dirge
#

yeah yeah, right after we're done with the animated splash screen 😆

bitter sparrow
#

hehe that one's important!

slender belfry
#

I'm doing character movement now 👍

bitter sparrow
#

btw the first splash screen pr will not be animated or even have fade in/out

slender belfry
#

I'll try to keep the changes in the game folder so that others don't have merge conflicts

agile dirge
#

we should have made a folder for each developer involved

#

no merge conflicts

bitter sparrow
#

rea

#

merge it all at the very end

agile dirge
#

it sounds like a fun jam challenge

bitter sparrow
#

fun for the first 8 days for sure

agile dirge
#

no no

#

without merge

bitter sparrow
#

ah

#

you'd add each dev's plugin to the app in a random order determined at startup

#

so the last plugin can't just override w/e it wants and you have to try to stay decoupled

#

next bevy jam fs

agile dirge
#

something is not right

image.png
#

okay, had to use srgba

bitter sparrow
#

name for AssetServer arg?

#

asset_server? asset? ||ass?||

agile dirge
#

if i absolutely have to shorten, then initials

#

but do you really have to?

bitter sparrow
#

i don't have to

agile dirge
#

are you at gunpoint? 😏

#

thought so

#

I'm very happy with the refactor

#

i split the ui traits to RootContainers (only for Commands) and Widgets (anything with spawn, so commands/child builder)

bitter sparrow
#

not in love with the way embedded asset paths work:

asset_server.load("embedded://bevy_template/screen/splash/splash.png"),
#

but ok ig

agile dirge
#

and there is space for Conainers too

#

why can't you just use assets folder

bitter sparrow
#

embedded asset still supports hot reloading for example

#

good to have a demonstration of how embedded assets work too, tbh

agile dirge
#

how are embedded different from 'normal' assets, i've never used them

bitter sparrow
#

they're embedded in the binary directly

#

like how string literals are as well

agile dirge
#

don't you need macros to do that?

bitter sparrow
#

embedded_asset! is the macro, provided by bevy

# 
embedded_asset!(app, "splash.png");
agile dirge
#

ohh, that's how you reference it?

bitter sparrow
#

yup

agile dirge
#

that weird path

#

uh

#

doesn't the macro return the full path?

bitter sparrow
#

the splash.png file goes in the src/ directory. which makes sense because we don't want it copied into the package, because then it'd be present 2x (in assets/ and in the binary)

agile dirge
#

so you can just assign it to a const or something

bitter sparrow
#

and wouldn't be able to assign to a const anyways because it requires app, but a resource would be possible

slender belfry
bitter sparrow
#

i dont like childbuilder personally because it leads to JS-like indentation/closure hell

slender belfry
#

Seriously this pattern is so much better than vanilla bevy_ui

bitter sparrow
#

but it's fine, the other way is weird too

agile dirge
#

you can still use set_parent

#

both are supported

bitter sparrow
#

thats good

agile dirge
#

actually, root doesn't even need to accept a closure, we can just use with_children

#

gonna do that

slender belfry
#

good job with the palette as well 🙂

agile dirge
#

getting it from Alice was the most stressful part 😰

bitter sparrow
#

removing my_. thank you

#

i wanted that

#

i'd put the .insert(StateScoped) before the .with_children?

#

pretend that's a comment on the PR, i just had discord open

agile dirge
#

oh yeah, i can do that now

bitter sparrow
#

it all falls into place

agile dirge
#

hm

#

workflow is not being cancelled

#

4 commits have workflow running when only 1 should

image.png
slender belfry
#

Approved check_accept

#

Alright, it's getting pretty late here, I'll do the finish the player movement thing tomorrow. Good night everyone 🙂

bitter sparrow
agile dirge
#

same here 🫡

#

ill just get this merged

#

replied to the comment

#

cause i need appr

bitter sparrow
#

splash screen and maybe css spinner PRs will be up tomorrow

bitter sparrow
#

btw something i just noticed in the logs (that pyri_state again does better 💅):

2024-07-08T02:14:40.050794Z  INFO bevy_dev_tools::states: bevy_template::core::booting::Booting transition: None => Some(Pending)
2024-07-08T02:14:40.050813Z  INFO bevy_dev_tools::states: bevy_template::screen::Screen transition: None => Some(Splash)
2024-07-08T02:14:40.115567Z  INFO bevy_dev_tools::states: bevy_template::core::booting::Booting transition: Some(Pending) => Some(Done)
#

the substate's transition is logged before its parent state's transition. which is confusing because that's not the order that the transitions happen

#

moving the actual logging into the respective transition schedules instead of Update would resolve this

#

unrelated, i see target/rust-analyzer taking up 448M on my pc. that's honestly not bad compared to the 7.6G in target/debug

bitter sparrow
#

our git history is a mess lol. i assume there are some repo settings that other bevy projects use

#

not a big deal but yea

#

is this better? (previously: all 3 checkboxes ticked and set to Default message)

2024-07-07_1720408482_826x451.png
agile dirge
#

I usually squash all

prisma delta
bitter sparrow
#

imo, at least like 5 days before the jam starts, we should wrap up the template in an mvp / usable state and announce that it's ready in #jam

#

so people have time to check it out, clone it / set it up, learn how it's structured etc

#

that's in 8 days and we're already almost there, so we've got plenty of time ofc

bitter sparrow
mortal merlin
#

Haven't read all of this chat- is TheBevyFlock/bevy-template become (or is becoming) the blessed GH template for bevy jams?
iirc there were several template repos floating about

#

Ah, reading the itch.io post now, it's even linked there. So blessed then 🙏

agile dirge
slender belfry
#

Also feel free to take a look and bikeshed if anything stylistically rubs you the wrong way. We already discussed a whole bunch of things, but feedback is still very welcome.

agile dirge
#

For practical usage, this is more of a template for templates/example of bevy project structure and code conventions

#

Because we do not use any 3rd party Bevy crates, we are pretty limited in what we can do, going for a more opinionated template with a ui crate would help

mortal merlin
#

a project like this is automatically pretty opinionated

It would be nice to have in the project README how exactly it's opinionated

slender belfry
mortal merlin
#

Ah ok 🙂

agile dirge
#

Yeah, readme is the last thing to update

slender belfry
#

The current readme is just the one from the Bevy CI template

agile dirge
#

We should split readme into few files

slender belfry
#

As we used that as a starting point

mortal merlin
#

last thing
Before? The jam?

agile dirge
#

After we get all the features in

slender belfry
agile dirge
#

The template is very volatile right now so external docs like readme get outdated too fast, not worth updating

slender belfry
#

For example, I want to add a feature for controlling a sprite with WASD so that users know where to put their actual game code

mortal merlin
#

I see you have issues for impl reflect and Name for entities etc. and I was like huh?? I thought this was a CI template only.
But I see you have interesting goals like a splash screen and credits etc., this is very interesting! Will monitor repo

mortal merlin
slender belfry
bitter sparrow
agile dirge
#

We agreed a 2d base for a jam game is better, 3d isnt doing too hot on wasm

#

And basic logic is pretty light and localized

slender belfry
mortal merlin
#

Ok, I'm typically only interested in 3D, but it's not a problem.

slender belfry
agile dirge
#

I like 3d but that was also the worst experience on last jam

bitter sparrow
#

the idea is the user is expected to fully delete the example "gameplay" code and replace it with their own 😄

mortal merlin
#

that code should be named fn blender_cube then

agile dirge
#

I dont delete my blender cubes

#

Would be pretty funny to leave a default cube inside of every 3d model

#

I can review the spinner and splash pr when im home in 2-3h but if Jan reviews them you can merge too, there isn't much to argue about those

bitter sparrow
#

it's crazy that no 3rd-party crates => we need to write our own Velocity component btw, lmao

agile dirge
#

Lmao

slender belfry
#

Update: I want the movement code to demonstrate how to correctly use a fixed timestep, as a lot of jam submissions would benefit from doing this the right way.
There was an open issue on Bevy about having an official example showing how to do this, but I can't find it anymore. In any case, I'll be upstreaming the movement code to Bevy first in order to get feedback on it and then use that same example code in the template. Good thing about that is that I won't need to add a ton of comments to the template and can just refer to the example.

agile dirge
#

merged splash screen because it has 2 approves

agile dirge
#

tbh, there isn't much left

#

the game logic that Jan is doing, then few tweaks to the code (Serde, Reflect, Name components, app. convention)

#

then readme

#

readme is gonna be big

slender belfry
#

Since "audio" is explicitly a criteria this time around, it would be good to play a sound somewhere as well imo

agile dirge
#

Good point

#

let's do music and stepping sound

slender belfry
slender belfry
#

here we go

#

@dapper sail I know that you know how to do this properly. Would you mind taking a critical look at my PR?

slender belfry
agile dirge
#

I can confirm that adding review comments one by one does in fact save a button press

#

Gonna answer the level/player comment here, I have a wall of text and I don't think it's reasonable to post it 😅

#

So, I do think there is value in providing a spawn_level, but we don't really have a level

#

Giving users the idea that player is a hardcoded part of the level is bad imo

#

The best solution for spawning non-static level elements (that I'm aware of) is through events, but now that we have observers that's even better

#

so a spawn_player would be reusable piece of logic

#

and enemies and pickups can follow that convention

#

then spawn_level can still use those

slender belfry
#

I see your point

#

How about a spawn_level that triggers a spawn_player?

agile dirge
#

sounds perfect

#

could you add a comment about how spawn_player can also be used for enemies/pickups etc.?

#

i think spawning player is special enough that people may just miss the possibilities

slender belfry
agile dirge
#

the convention of adding spawn_X that has an associated event

#

do you think it's obvious from spawn_level and spawn_player that you should use it for enemies and pickups?

#

maybe i'm overly cautious

slender belfry
#

I think it's obvious when I also split the files 🙂

agile dirge
#

okay, level + player is actually better because it goes a step further and shows composition

#

thanks for rubber ducking my dumb ideas

slender belfry
#

Thanks for the good ideas 😄

#

I think you'll like that commit

agile dirge
#

Jan jumpscare

slender belfry
#

Same ;-;

agile dirge
#

github embeds been weird last few days

#

oh neat

#

yeah that's a good idea

#

the spawn module

slender belfry
#

I think that makes it really really obvious how to structure things like enemies 🙂

agile dirge
#

yup

bitter sparrow
#

my thought is: why observers when this could instead be more similar to the util/ui stuff

#

like probably not an extension trait on commands

agile dirge
#

assets

#

assets are a pain when spawning stuff

bitter sparrow
#

but a spawn_player helper function or struct Player.spawn

agile dirge
#

this way you can skip providing asset-related arguments and focus on the values that actually interest you

#

the asset logic is all localized

bitter sparrow
#

okay that is true

#

passing args through is annoying

#

bsn pls

#

idk what bsn even does at this point i'm just gonna assume it would fix this

agile dirge
#

you'd load the entire game from bsn if they let you

#

😄

slender belfry
bitter sparrow
#

and EventWriter type event would not be suitable for this because you don't want to wait until the next time a spawn_player system runs.. or have that system check a run condition every frame

#

custom command would also be an option though?

slender belfry
agile dirge
#

yeah, observers do the same thing though

bitter sparrow
#

okay but what's the difference then

#

how are we choosing between the two here

agile dirge
#

observers are easier to setup

#

no impl blocks

bitter sparrow
#

you don't need impl blocks for commands

#

functions impl command

agile dirge
#

🤔

slender belfry
#

Commands are more for "plz change something in the ECS", e.g. how reparent is implemented.

agile dirge
#

but then you'd need an extension trait for nice calls

#

yeah true

#

observers don't do structual changes

slender belfry
bitter sparrow
#

commands.add(spawn_player)

agile dirge
#

god forbid user uses raw api

#

(jk)

bitter sparrow
#

lol

slender belfry
#

Also observers were made with recursion support in mind, idk if commands do that as well

bitter sparrow
agile dirge
#

we made it back 🎉

#

okay, now without sarcasm
commands would be just fine here

bitter sparrow
agile dirge
#

but i think observers work and are easy to setup

#

the fact that we can have a struct containing all relevant spawning data is nice

#

you can serialize that

slender belfry
#

Me with observers

bitter sparrow
#

tbh i feel like observers are more worth if there's an entity target

agile dirge
#

the target is ZA WARUDO

bitter sparrow
#

i'm not opposed to observers i'm just wondering how you're even supposed to choose between observers, commands, one-shot systems, events, etc. at this point

agile dirge
#

that's what the name implies ig 🤔

#

good point

#

we entered a teritory of multiple solutions with observers

#

Events vs observers too

slender belfry
bitter sparrow
#

true and you can pass around a type-erased SystemId

slender belfry
#

Events can run in specified schedules and have more ability to parallelize

agile dirge
#

I think it's just a matter of taste and convenience now

bitter sparrow
#

oh schedules are another thing too

slender belfry
#

Observers are just hella neat

bitter sparrow
#

ok so i guess one thing about observers

slender belfry
#

Hooks give you the ability to change something so quickly that there is no in-between state

bitter sparrow
#

you can add more systems (observers) to the same commands.trigger(SpawnPlayer) event

#

in different parts of your code

#

i don't think we want that in this case.. but yea

slender belfry
#

You want that for a third-party crate so that the user has the ability to also do something on an event. Note that there is no way to order how the two observers will run though.

agile dirge
#

Spawning is happening rarely so we don't need the parallelization ability of Events<E>
Commands are a teeny tiny bit more annoying to setup, especially if you want to store all spawn data in a struct

slender belfry
bitter sparrow
#

commands.add(SpawnPlayer { ... }) vs commands.trigger(SpawnPlayer { ... }) no?

agile dirge
#

assets

#

wait no

#

reading comprehansion is not my strong point

#

you need to impl Command for SpawnPlayer

#

that's inconvenient

bitter sparrow
#

i feel like observers is just like a suite of commands for the same commands. call

bitter sparrow
#

it's in the type system instead

#

so either way you gotta do something

agile dirge
#

true

slender belfry
#

You'll have to ask #ecs-dev for the exact technical differences

bitter sparrow
#

sure i'll put the question there

agile dirge
#

i do think this is a question of the same nature of "do i put it in core, game or util"

slender belfry
agile dirge
#

so i don't think you'll get a clear answer

slender belfry
#

I think it doesn't matter too much and the user can easily switch if they prefer something else

agile dirge
#

it's a mix of personal preference and convenience, whatever you do will probably work

#

we can add a comment about it if you want

bitter sparrow
#

ok SpawnPlayer as a command and SpawnLevel as an observer 🤪

agile dirge
#

sir

slender belfry
#

One thing I like right now is that the template shows different ways of doing things. It's kinda neat to see how Commands, Observers and ComponentHooks can be used hand-in-hand

agile dirge
#

clearly we need a 3rd spawn for Events<E>

bitter sparrow
#

for projectiles