Read on Twitter
I& #39;m regularly asked what a typical day looks like for an engine programmer. Sometimes it& #39;s six hours of reading code to ultimately click a checkbox. 1/16
One of my current tasks is upgrading the version of Unreal used by VALORANT. Taking the latest changes from Epic touches tens of thousands of source files. Many opportunities for new, surprising behaviors. Today I found a fun one. 2/16
VALORANT& #39;s practice range has a bunch of shootable switches players can hit to adjust settings like sensitivity or spawn bots. With the latest version of the engine, hit registration on these switches got wild. Any shot remotely near a switch triggered it. 3/16
Hit registration and the shootable switches are all defined at the game layer. There were no interesting changes to their implementation as part of the engine integration. So what happened? 4/16
To start, I reviewed our code that determines whether a target gets hit by a shot. Hitscan weapons use a handful of line traces, and it& #39;s straightforward to inspect what& #39;s hit in the debugger. 5/16
Shootable switches are composed of a mesh, a widget for optionally displaying text, and a few simple components that allow them to be shot. When hit each switch executes logic for what it controls (ex. triggering bots to spawn). 6/16
The shot was registering due to a collision on the text widget, which shouldn& #39;t be shootable. The widget was using our UI collision preset. Huh? 7/16
Sure enough, the UI collision preset was incorrectly configured to receive collision from weapons. Why doesn& #39;t the same behavior reproduce on the previous version of the engine? The investigation must identify what changed before we make a fix. 8/16
Next I added a debug script to draw the bounds around the switch whenever it was successfully shot. It showed that the bounds (red) aren& #39;t close to where my bullet went (yellow). Now I& #39;m getting scared. Are physics fundamentally broken? 9/16
I went through a bunch of physics code and the logic that invalidates physics state. Nothing stood out. I remained haunted by this shot incorrectly triggering the switch. Next I added logging with the bounds every time it was hit. 10/16
This logging showed the server and the client disagreed about the widget& #39;s bounds. My previous debug script only drew the client& #39;s view. Shooting is server authoritative. The bounds difference explains the behavior, but why do the client and server disagree? 11/16
I reread all the relevant widget code. Widget bounds are based on a "CurrentDrawSize" variable. In the previous version of the engine "CurrentDrawSize" defaulted to zero and was updated as part of UI layout. The server never runs UI layout, so it stayed zero on the server. 12/16
In the new version of the engine widget initialization sets "CurrentDrawSize" to a configurable "DesiredSize" value. "DesiredSize" defaults to a nonzero value. The server still never runs UI layout, so the server now used "DesiredSize" for hit registration purposes. 13/16
The previous engine behavior masked a years-old latent game bug. UI being incorrectly flagged for weapon collision was irrelevant because the hitbox didn& #39;t exist. I checked the checkbox to remove collision with weapons, and now the switches work with the new engine. 14/16
In summary, a value went from zero to nonzero and had the side effect of creating an incorrect hitbox. Fixing the collision configuration restored the original intended behavior. 15/16
Many days game development is incredibly exciting. Other days you get to go on a journey of discovery that culminates in toggling a checkbox. :) 16/16
