How can I make my game look good?

[late canyon]

So, i’m working on a tile based inventory management roguelike, and since I’m on bevy 0.12 and there are no official tilemap crates available I made my own.

When I look at the videos I’ve made of my game I personally really dislike how it looks. I’m not sure if it’s just because of the tile sprites I made being too busy or if it’s something about bevy’s rendering.

I’d love to know if there are ways to improve my game visually as currently it looks very jittery

[azure void]

So, there's a few challenges here:

1. Your tiles are too zoomed out: the set you're using is designed to be used much larger
2. Your pixel size is inconsistent
3. The jitter that you see is due to your camera interpolating between pixels (possibly with anti-aliasing)

bevy_smooth_pixel_camera by @remote dew might be a good fix to your problem

[remote dew]

The primary thing here is that you are too zoomed out and that your pixel size is inconsistent.

There are 2 primary methods of zooming into pixel art:

1. Zooming in/Upscaling sprites individually: This is a easy way to create a pixel artstyle thats also very flexible as you can insert anything you want. The problem is you need to make sure everything has the same scale or it will look bad. You can zoom in via your Camera's OrthographicProjection component, which contains the scaling_mode property.

2. Rendering at a low resolution then upscaling: This achieves a very retro artstyle. Everything snaps to a grid of pixels. with the downside that you can't really have any high resolution assets inside your game (apart from UI). You can achieve this with bevy_smooth_pixel_camera.

Theres a hybrid approach too but probably won't need it.

More things you can add:

1. Shader effects (lighting, water, anything magic related, etc)
2. Particles
3. Animations

[late canyon]

Working on those! But first I wanted to fix the tile rendering

[late canyon]

Made them myself actually! Didn’t necessarily design it that way on purpose. Also what do you mean inconsistent pixel size?

I’ll look into your package then

[late canyon]

You say it won’t affect UI, but I’m using my own UI system for the inventory, would that be affected?

[remote dew]

probably not, depends on the ui system i guess

[remote dew]

some sprite pixels are larger than the "pixels" on other sprites

[late canyon]

I mean I basically have a higher layer with some simple sprites

[remote dew]

if its a higher layer it shouldn't be affected

you can customize it

[late canyon]

Ah alright, good to know! I’ll look into it then

[remote dew]

You can use PixelCamera::viewport_layer to customize in which render layer the viewport is in.

And you can add RenderLayers to the camera itself to change what it renders

[late canyon]

@remote dew uhm...

this happened when I imported 0.2

[remote dew]

Thats not supposed to happen

hmm

[late canyon]

Yeah that's what I suspected ;P

[remote dew]

hold on

does it compile with cargo?

sometimes rust-analyzer is weird

[late canyon]

cargo run gives the same errors

here's my toml file

[remote dew]

oh

[late canyon]

do I have an incorrect setting?

[remote dew]

no

[late canyon]

oh ok

[remote dew]

that isn't supposed to happen

that systems module the smooth_camera system is in is private

does bevy_smooth_pixel_camera 0.1.1 work?

@late canyon what version of rustc are you using? (Check with rustc -V)

[late canyon]

rustc 1.73.0 (cc66ad468 2023-10-03)

0.1.1 seems to work but then the pixelcamera is different ofc

so I can't really test if the package itself works, I don't get those errors at least

[remote dew]

huh

so it appears on your version of rustc it doesnt compile

but on latest stable it does compile

i'll push out a fix

[late canyon]

alright sick

thanks!

[remote dew]

in the meantime you can just update your rust version

with rustup update

[late canyon]

hm, so it adds multiple cameras to the world?

i had some single_muts for camera movement and such, which broke when I added it ;P

[remote dew]

you have to use PixelCamera::subpixel_position instead

[late canyon]

So I set the subpixel position to the players position? (Or lerp)

[remote dew]

ye

[late canyon]

Ahhh alright, good to know!

[remote dew]

the reason for why is because I set the transform of the camera to a rounded version of subpixel position

[late canyon]

And if I wanna make something a child of the camera, how do I do that?

[remote dew]

commands.spawn(...).with_children(|commands| { commands.spawn(...) })

[remote dew]

here is that system btw:

/// Set the camera transform the rounded down version of the subpixel position
pub(crate) fn set_camera_position(mut cameras: Query<(&PixelCamera, &mut Transform)>) {
    for (PixelCamera { subpixel_pos, .. }, mut transform) in &mut cameras {
        transform.translation.x = subpixel_pos.x.trunc();
        transform.translation.y = subpixel_pos.y.trunc();
    }
}

[remote dew]

It makes the camera you attach the PixelCamera to into a camera that renders to a viewport. then it creates another camera that looks at the viewport and draws that to the window

[remote dew]

btw @late canyon bevy_smooth_pixel_camera 0.2.1 is out

[late canyon]

ah alright! thank you so much

[late canyon]

Hmm, it’s kinda funny seeing how packages like this interact

I had a perfectly working inventory system, and as soon as I added this package, all my calculations suddenly worked different, probably due to the scaling

[late canyon]

like.. what?

[remote dew]

is your inventory system a part of the world? or is it UI?

[late canyon]

part of the world but on a separate layer

or at least they should be, i have no idea what's happening rn tbh

ah, so I only had 1 layer on the cameras which made it do weird things, so I changed it and now the UI is gone entirely, this is going great ;P

now it only renders the old camera with this error:

The render layers of the world intersect with the render layers of the viewport camera

Laptop died so I can’t continue, but clearly I have no idea how the camera system in bevy works

[remote dew]

what did you change it to

[late canyon]

Renderlayers 0,1 on the pixel cam and 1,2 for the UI cam, which is like, exactly what they do in the bevy guide example

[remote dew]

you are using your own UI solution?

[late canyon]

Yeah, I thought I mentioned that

[remote dew]

oh

[late canyon]

I severely dislike bevy UI and needed a smooth feeling inventory as a central part of the game

[remote dew]

so the problem is you have both the pixel camera and the world camera on the same render layer

[late canyon]

So the renderlayers just shouldn’t overlap? Or do I need to actually change something on the pixel camera, cause currently I’m just adding render layers

[remote dew]

do you want the ui to be pixellated?

[late canyon]

I mean it most likely will be to fit the style, but I don’t want it locked to the grid because that looks odd when dragging items

[remote dew]

so thats a no

[late canyon]

And if I make it pixelated that makes using screen locations harder as the size and image on screen no longer line up with your package

[remote dew]

so you probably want something like this:

World: RenderLayers::single(0) (default)
Camera2dBundle Entity: RenderLayers::single(0) (default)
Camera2dBundle's PixelCamera::viewport_layer: RenderLayers::single(1) (default)
UI: RenderLayers::single(2)
UI Camera: RenderLayers::single(2)

[late canyon]

So basically just add renderlayer 2 to the UI camera and UI elements

[remote dew]

yes

or you could set PixelCamera::viewport_layer to layer 2

[late canyon]

Alright, that seems simpler than I thought ;P

I was severely struggling

[remote dew]

yeah just gonna make sure nothing intersects

[late canyon]

When I had a single layer before it also struggled cause I didn’t know I had to do RenderLayers::single, I think I just copied it and did RenderLayers::from_layers(&[1]) which it did not like

[late canyon]

It works now! Thanks so much!

[remote dew]

how does it look?

[late canyon]

I’m going to look further into your package and see exactly how I can use it best, since currently it’s set to 2, which is then zoomed in which gives a bit too little overview at the moment, but it works great ;P

[remote dew]

its still too zoomed out

i'd set it to a 4 or something

[late canyon]

i had it at 4, but it's at 2 just so I can see what's happening, 4 zooms it in so much I have no idea what I'm shooting at

looks great, feels horrible to play

i can only see the skeletons around me when they're already in attacking range. which when you're using something like the bow feels horrible

[remote dew]

this is personal preference but i think the size of the skeletons is too large

they are absolutely huge compared to the tiny tiles

[late canyon]

The tiles are actually less than they seem, it’s sort of a weird tile…, one tile is made up of 8 tiles

Bad design on my part

[late canyon]

Oh! I had one more question. Since the characters aren't moving around on the same grid as the camera, they seem to still shift around a bit when they are moving. What would be the best way to resolve that?

[remote dew]

shift around?

can you show me an example of this?

[late canyon]

it happens mostly to the skeletons which could be due to them just not being consistent still, but I'm specifically talking about the floor which still seems to shift around despite it being the correct size

my texture atlas size and my tilemap

[remote dew]

i cant really tell if the floor is actually shifting around or its just the low frame rate

you should use OBS studio instead of bandicam

[late canyon]

i mean this is what it looks like for me too

idk the refresh rate of my screen though and how much that would affect it

[remote dew]

probably 60

[late canyon]

but like if that's what it looks like on my screen too, then why would it be doing that?

[remote dew]

i've looked at it several times and i cant see the floor shifting

it looks fine

[late canyon]

Oh huh? Maybe it’s just my eyes? Looking at it on my screen it feels like the light line shift over, but maybe it’s just some weird illusion