It was an interesting experience to deal with “FOV” as an option on how / why it’s utilized in video games to make better playable experiences. But it’s also important for us to realize the power it possibly has to alter the “intended” gameplay experience (if done wrong).

So I’ll be taking a look at how we achieved the implementation of this option in Starlink, while explaining potential pitfalls we faced while doing so.

Why are different FOVs made accessible to players in video games?

“Field of View” as an option exist in video games to avoid motion sickness caused by screen distortions applicable, depending on the player viewing distance to the monitor.

If the field of view of your game is significantly different to what the eye/brain expects to see, it can result in motion sickness. This can be extreme, resulting in nausea and disorientation strong enough that play duration in excess of a few minutes can become impossible.

The option is not intended to be used by all players, but only a minority who are prone to motion sickness. The end result might leave the players feeling:

• Fish-eye viewed, dictated mainly in high field of view visions.

• Or a claustrophobic feeling, applicable in low field of view visions.

PC games by standard operate around ~90° camera FOV, compared to the ~60° in consoles.

These issues mainly occur because we as developers don’t exactly know the seating positions of our players towards their monitors. And although it’s better to follow industry estimates, I think it’s also very important that we provide the option to let the players decide the best visual experience for themselves.

How did we adapt the FOV option?

Starlink features dynamic FOV values while switching between different camera states (movement / action). For example:

• By default while on ground, we have a base of 60° FOV, but it shifts to a max. of ~100° FOV depending on camera modifiers triggered (like boosting).

• By default while in flight, we have a base of 80° FOV, and it shifts to a max. of ~110° FOV depending on modifiers triggered.

In such cases mentioned, values higher than ~110° might become unplayable to most of the general audience (due to fish-eye motion sickness kicking-in).

By keeping all of the points mentioned in mind, we balanced the values in-terms of an adjustable FOV option for PC (by a preset range method).

FOV options in different video games are usually showcased by their direct ° angle values (by sliders), but in our case since we can’t exactly provide an accurate number (as we have dynamic FOV values), we chose to display the option through contextual words:

• Normal (Default Console)
• High (+10 FOV)
• Maximum (+20 FOV)

But how did we choose the values?

As an industry estimate, although few players depend on ~100° FOV, anything above that is considered to be a personal choice.

In most cases, FOV as an option entails the nearing seating position towards your monitor, instigating the FOV to be always be increased (AKA claustrophobic isn’t much of an high concern as compared to fish-eye view).

• There is no need to provide highly decreased FOV values, and therefore we chose the console default value of 60° as the lowest.

• We adjusted the max. FOV modifier values to have it capped to a max. of 120° FOV value (all of them, even on max. FOV setting, to avoid breach in motion sickness).

By this process, we can only get a max. of 20° camera FOV value due to the fish-eye nature kicking-in thereafter (Because anything more than that would breach the 120° value).

• This manly occurs due to the modifier values expanding upon the base values, which enables the max. of ~100° & ~110° on ground & flight to reach above the limits.

CONSOLE DEFAULT:

FOV MAX. VALUES:

Consequences of FOV implementation

Starlink’s dynamic FOV camera state system might’ve become a tool to cause unintended accessibility concerns / camera experiences.

In some cases we felt the end result might compromise how different levels of speeds “feel” as intended.

• Because we have to cap the max. FOV possible (to stop 120° value breach) to avoid motion sickness.

And it can also be argued that we would only be getting a slight increment of either 10°-20°, because anything above that can compromise other sections in design.

I think an argument could also be had on the way we designed to derive the end results as well, but we still went ahead with the implementation, as we saw more benefits to it rather than potential pitfalls we might’ve faced.

As long as our options were providing avenues to avoid fish-eye / claustrophobia, we achieve our goals.

I think we achieved a rather desirable end result, while maintaining freedom to enable accessibility for more players to enjoy the experience, while retaining the camera intentions already existing in-game.

This approach should encourage more developers to provide with such options no matter how they plan to use FOV for gameplay effect.

I believe It’s really important we let the players choose an FOV value to their personal convenience for accessibility concerns.

Random Info

I believe it’s really important for video game designers to understand how human eye works in correlation to building good gameplay experiences.

For example:

Starlink understanding the importance of focal vision puts threat markers inside it (as GOW below), but sub-objective markers are placed in peripheral view (corners of the screen), as the game understands the passive nature of the element in comparison to active combat threats.