shapez.io

shapez.io copied to clipboard

Anyone else think the belts appear to run in reverse? The arrows on the belts showing direction appear to move in the opposite direction they're pointing and the shapes appear to move backwards. This seems like the opposite of what's intended and desired.

I don't want to disable the belts showing the direction and shape, but, perhaps tone it down a bit so it ensures it's showing the correct direction?

I know it's a trick of our eyes based on the speed they're moving, but, it seems like something which could be handled.

iirc belt arrows move at the same speed as shapes, so...

and?

so belt arrows and shapes would not be in sync if things were changed; I think that the arrows on the belts are enough of a visual cue, and if they are blocked with shapes, there isn't a good way to make the movement of shapes in sync.

Personally, I feel like this could be better addressed by lowering the belt speeds in general.

I've had this also whilst playing. It occasionally does the "tyres look like they're moving in reverse" visual trick. I've also definitely seen the belt animation move at a different rate to the items on top of it, so there may be some difference between the two animations.

from some testing, it seems that, past a certain speed, the belt animation stops getting faster and so the items move faster (starting from tier 6).

https://github.com/tobspr/shapez.io/blob/09c2320f5572f149068dfb431cc8e33aa64fadf7/src/js/game/systems/belt.js#L497-L498 also found code for that, max item speed belt will follow is 10 / s, which checks out with the 8 -> 12 speed increase

we can do some math to find how fast the arrows cycle:

https://github.com/tobspr/shapez.io/blob/09c2320f5572f149068dfb431cc8e33aa64fadf7/src/js/core/config.js#L66 the arrows move at a max rate of 10 "item widths" per second, with each item taking up 0.63 of a belt; that means they move at 10 * 0.63 = 6.3 tiles per second

there are 3 arrows per belt; thus, each cycle is 1/3 of a tile long. that means a cycle happens in 1/3 / 6.3 = 10/189 (about 0.053 seconds

at a framerate of 30 fps, that means that one cycle takes 30 * 10/189 = 100/63 frames, or one frame causes 1 / (100/63) = 0.63 of a cycle to pass

oh no, over half of a cycle passes in a single frame at 30fps - that's not good

(I'll also have to retract my original comments; they don't make sense here)

This is a known issue (except possibly the speed discrepancy just mentioned). It's caused by framerate, tick rate, animation speed and at least one other factor that isn't coming to mind right now. Yes, it's normal. No, you can't overclock your eyes. Sorry.

could you clarify what you mean?

If you are referring to "overclocking your eyes", that was a joke. You can overclock your monitor and the game framerate so that it shows the belts running forward, but your eyes "reset" many times per second (I don't remember the actual figure), which is just long enough between each reset that you would need to "overclock" your eyes (and possibly brain) to actually see the belts going forward on-screen, if that makes sense.

I meant what what you said means to the conversation

I know it's a trick of our eyes based on the speed they're moving, but, it seems like something which could be handled.

What I'm saying is that your eyes can only see so many frames per second. At some point, making the display and the game faster is only going to serve using up lots of resources, because your eyes can't get any faster. That's what I was trying to say. Apologies if that wasn't clear.

...but things are fine on (display) 60fps? this is about 30fps being too slow

I posted this issue so the devs could consider how the UI design/implementation is failing to achieve its goal of showing the direction the shapes are moving in and consider alternative designs to achieve that goal.

Human eyesight is only relevant as a problem to solve thru good design. Saying our eyes can't be overclocked makes it sound like you're saying nothing can be done because it's impossible to create a solution to this problem. I'm sure you mean something more like trying to use the current design to solve the problem won't work and a new solution is needed.

The framrerate is only relevant to the implementation of the solution. Saying it's only a problem at 30 fps makes it sound like you don't care about those who can only play the game at 30 fps. I'm sure you actually care about the player's experience.

So, does anyone have some suggestions about what can be done? I'm sure this problem is encountered in many games, so, what solutions do other games use?

A few thoughts of my own:

1. what if the density of shapes lessened as the speed increases so shapes are farther apart and there's less on screen? That would make it easier on the computer to display them, fewer+faster. Would it make it so what we see is shapes going in the correct direction?

I believe the game's current implementation makes this solution difficult because it tracks each shape individually so instead of being able to just change how the numbers/stats are visually represented (drawn) it'd have to "hide" some shapes which would still be part of the looping. So, not as helpful as it could be with a different implementation.

2. could the arrows on the belt become stationary so they don't ever seem to move backwards (or move at all) so they'd be a definitive representation of direction, and the shapes moved farther apart, in my suggestion above, would make room for those arrows to be easily seen, also, making them stationary would ease up the computer resources needed to display them which would help overall.

I don't know why the arrows move in the first place or why they are placed where the shapes cover them up so they can't be seen when the belt is full. If that wasn't done for any particular reason, perhaps they could be moved to the edge of the belt where the shapes can't cover them up. It doesn't solve the shapes looking like they're moving backwards, but, it's a start.

3. Affect the visual of the actual shapes to indicate direction when they get up to a speed high enough where the "backwards illusion" occurs. For example, alter the graphic of the shapes so they seem to be leaning into their forward motion by becoming a slightly diagonal oval so the forward direction is clearly seen. Or, add a kind of shadow on the "behind edge" of the shape so the forward direction is opposite of that shadow.

This seems like a matter of changing the icon for the shapes based on their current speed. Seems doable, would require considering shapes traveling in all 4 directions. Maybe shapeshifting to represent higher speed would be better on performance than actually increasing the speed of the shapes. Not to say don't speed up the shapes at all ever.

So, I don't know the solution, but, I bet there are plenty of ideas out there to have an open discussion on.

*edited to fix typos

On 11/1/21 5:47 PM, Emerald Block wrote:

...but things are fine on 60fps? this is about 30fps being too slow

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/tobspr/shapez.io/issues/1146#issuecomment-956674989, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABFC44J4DOGW6MURXBFAD3UJ4DH3ANCNFSM43DV6JNA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

this isn't a commit message lol, no need to newline so much

although I'm not sure who you are directing this too, let me affirm that I agree that accounting for the 30fps experience matters.

1. hm, I only considered the belt arrows, not the shapes themselves... but no matter how shapes are implemented, density determines how much a belt can hold, which would affect gameplay.
2. that actually sounds like a really nice idea
3. An oval wouldn't distinguish direction, and I think both relativistic effects and motion blur might feel a bit out-of-place for shapez

For a while I've been thinking about how to fix this, but the main problem I've run into is this: I think it'd be nice to keep the animation speed the same at 60 FPS, so how do I distinguish 30 FPS (or other framerates in general)?

• It could just calculate FPS like in the debug info, but that value could vary and lead to back-and-forth changes.
  • It could average out the values, but that'd still have some variance.
  • It could figure out if you're 30 FPS or 60 FPS, but what about other framerates or crossing back and forth?
• It could be a setting, but people would have to be made aware of the setting, and it'd be annoying to change.

I'm no expert in this, though; maybe there's a better way to do things