Last week in the forum, members focused on several technical challenges and innovations in game development. The community engaged in discussions about optimizing user interfaces for new hardware setups, with a particular focus on readability and responsiveness. There was also a lively debate on the impact of eye-tracking technology in gameplay, especially concerning its unintended consequences during stealth missions. Performance optimization for consoles continues to be a hot topic, as developers shared strategies to maintain smooth UI experiences.
This Week’s Hot Topics
Readable HUDs at 10-foot distance
This discussion centers on optimizing HUD designs for larger screens where players are seated far away. It’s a crucial consideration for developers aiming to improve accessibility and user experience.
Eye tracking betrayed my stealth run
Here, users share experiences and solutions for the challenges posed by eye-tracking technology, particularly when it inadvertently disrupts gameplay mechanics in stealth games.
Keeping UI snappy at 60 fps on console
This thread provides practical advice and techniques for maintaining UI performance on consoles, an essential aspect for developers looking to ensure a seamless gaming experience.
In our stealth prototype, using eye-tracking to auto-select targets got players caught just for glancing; switching to gaze-to-highlight with a button confirm fixed it. Add a tiny deadzone and saccade smoothing or it feels twitchy; Tobii’s guidelines helped: https://developer.tobii.com/ — treat gaze like a laser pointer, not the trigger.
Ran into this last week: only accept targets when gaze is in fixation (about 150 ms) and camera velocity is near zero, plus a 2–3° hysteresis so micro-glances don’t flip selection. We also ramp suspicion based on dwell — “gaze is not intent” — so looking at a guard doesn’t instantly blow stealth. If you’re on Tobii, their fixation events make this easy: https://developer.tobii.com/.
One tweak that helped us: after any quick camera move or UI popup, we ignore gaze-driven target changes for about 200–250 ms to let the eyes settle, which killed the “got caught while scanning” issue — go past 300 ms and it starts to feel sluggish. @dlawrence91 your fixation rule pairs well with a small angular deadband here.
But @dlawrence91 we had good results gating gaze updates on tracker confidence — when the SDK flags low confidence (blink/saccade), we hold the last valid target for about 200 ms and dim the highlight, which preserved intent without feeling sluggish. Small caveat: glasses users dip more often, so we expose a slider for the hold window.
We cut stealth false-positives by detecting the dominant eye during calibration and driving gaze selection from that eye only. On glasses users this killed left/right oscillation better than extending the hold; we also bind R3 to swap eyes if dominance flips, @dlawrence91.
We finally stopped stealth blowups by decoupling gaze from commitment — gaze only hovers, and we require a 120–150 ms dwell plus a quick trigger tap to ‘lock’ the target; @dlawrence91, confidence gating helped, but this sealed it. To keep readability/responsiveness, we show a faint pre-highlight on gaze and only snap after the confirm. , pure gaze kept flipping at the worst moments, and in no-hands modes we drop dwell to about 80 ms on 200 Hz trackers, but it slightly raises misses.