HasangerGames / suroi

An open-source 2D battle royale game inspired by surviv.io. Work in progress.
https://suroi.io
GNU General Public License v3.0
279 stars 149 forks source link

FoV rebalancing #344

Open Fabizocker456 opened 4 months ago

Fabizocker456 commented 4 months ago

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:

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:

Describe alternatives you've considered

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 commented 4 months ago

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 commented 4 months ago

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 commented 3 months ago

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 commented 3 months ago

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)