Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FoV rebalancing #344

Open
Fabizocker456 opened this issue Jun 22, 2024 · 4 comments
Open

FoV rebalancing #344

Fabizocker456 opened this issue Jun 22, 2024 · 4 comments

Comments

@Fabizocker456
Copy link

Fabizocker456 commented Jun 22, 2024

Is your feature request related to a problem? Please describe.
It is generally not a nice feeling to get shot at by an enemy outside of your FoV. This can happen if they have a scope greater than yours, but as someone who plays on a widescreen monitor (of course, horizontally oriented) in fullscreen mode, more often than not, that enemy is below me, and can see me because my window is too 'flat', even with the same 'scope level'.

The game currently calculates the scale of the "actual game window" as follows:

const minDimension = Math.min(this.width, this.height);
const maxDimension = Math.max(this.width, this.height);
const maxScreenDim = Math.max(minDimension * (16 / 9), maxDimension);
const scale = (maxScreenDim * 0.5) / (this._zoom * PIXI_SCALE);

(https://github.com/HasangerGames/suroi/blob/master/client/src/scripts/rendering/camera.ts#L51)

(note that a lower scale is generally better, since you can see more.)

We can see the two cases here:

  • if the window is 'flatter' than 16:9 or 9:16, the camera rectangle so that the in-world length of the long side is 'fixed' to a maximum value
  • otherwise, the canvas scales so that the short side is fixed to its maximum value <ca. 0.56x the maximum value of the long side>

Note that this prioritizes people who play on an aspect ratio close to 16:9 (in either orientation), as well as allowing people who play in 'vertical mode' (something that few, if any, people have ever thought of doing) to see things that other players cannot.
As some players can also theorhetically switch between the two easily, e.g. via a hotkey that resizes the browser window, this makes the game unfair for those who cannot, e.g. due to operating system limitations.

Describe the solution you'd like

Tweak scaling as follows:

  • There is a square area centered on the player (or whatever else the camera is supposed to be focused on), let's call it the 'field of vision', outside of which the player can never see, and which scales with the equipped scope scale.
  • The 'effective camera' is a rectangle also centered on the player, touching the sides of the square (from the inside) with its short sides (=> as big as possible) and with the same aspect ratio as the game window.
  • Add an option somewhere in the settings to override this behaviour, so that field of vision is centered in the game window, touches the edges with 2 sides, and everything outside of the field of vision is hidden by a black border (so that every player who has it enabled sees everything they could ever see, and two players with the same scope scale and the feature enabled can see each other at exactly the same moments).

Describe alternatives you've considered

  • Inform the player that the game is meant to be player at 16:9 resolution, and give them a way to easily resize their "game window" (or, at least, show the aspect ratio)
  • Use any other 'aspect ratio' for the field of vision as described above, e.g. 16:9 (to give players playing at 16:9 a maximum FoV, but effectively allowing every other player to play at 16:9)

Additional context
image
The graph of 'visible world height' (green) and 'visible world width' (blue) at aspect ratio [x value]:1.
Note that a value of '1' means the maximum length any side of the screen can ever reach (in-world).
The graphs start at 1:1 (square screen), and the 'corner' is at 16:9 (or 9:16)

@ei-pi
Copy link
Collaborator

ei-pi commented Jun 22, 2024

some diagrams/drawings to illustrate your proposed solution would be appreciated
i'm pretty sure i get it but just to be sure (and for anyone else who doesn't wanna spend 10 minutes re-reading 3 bullet points)

@Fabizocker456
Copy link
Author

Fabizocker456 commented Jun 23, 2024

some diagrams/drawings to illustrate your proposed solution would be appreciated i'm pretty sure i get it but just to be sure (and for anyone else who doesn't wanna spend 10 minutes re-reading 3 bullet points)

image
image

I hope these are enough, sorry for the low quality.
I can try implementing these ideas in a fork, if you wish.

@ei-pi
Copy link
Collaborator

ei-pi commented Jun 24, 2024

ok, that's pretty much what I thought it was
to note is that black borders aren't an adequate security measure because it will take someone about 5 minutes to remove them

@Fabizocker456
Copy link
Author

Fabizocker456 commented Jun 30, 2024

ok, that's pretty much what I thought it was
to note is that black borders aren't an adequate security measure because it will take someone about 5 minutes to remove them

Once we have a fixed 'block that cannot be seen outside of', we should make the server only send entities within that block to the client.
(otherwise, of course, this feature has little use: we can't stop a client from rendering what it receives)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants