Sample questions
Game Input AudioDifficulty 1
In game input handling, what does 'polling' an input device mean?
- aThe device firmware compresses the raw signal before sending it
- bThe operating system replays previously recorded inputs for testing
- cThe game loop asks the device for its current state each frame✓
- dThe device sends a single interrupt only once, at power-on
Explanation:Polling means the game loop actively reads the current state of an input device (e.g. which keys are held) on every update tick, rather than waiting to be told about changes.
Game Input AudioDifficulty 2
What best describes 'event-driven' input handling?
- aThe engine checks every input device's full state on a fixed timer regardless of change
- bInput is read directly from a save file at level load time
- cAll input is buffered for one full second before being read
- dThe system notifies the game only when a specific input state actually changes✓
Explanation:Event-driven input relies on the OS or input layer pushing a notification (key down, button released, etc.) only when a change occurs, instead of the game repeatedly asking for the full state.
Game Input AudioDifficulty 2
A player says a game 'feels sluggish' even though the frame rate is smooth at 60 FPS. What is most likely being described?
- aHigh input latency between pressing a button and its effect✓
- bThe game's color palette uses too many desaturated tones
- cThe audio mix has too much reverb applied to footsteps
- dThe main menu font size is too small to read comfortably
Explanation:'Feel' complaints at a stable frame rate almost always point to input latency: the time from physical button press to the resulting visible/audible response being too long, even if frames render smoothly.
Game Input AudioDifficulty 2
What is the basic idea behind 'input buffering' in a game?
- aSaving the player's entire input history permanently to disk for replays
- bRecording input briefly so it can be honored a bit later✓
- cRandomly discarding some inputs to simulate network jitter
- dCompressing audio samples before they are mixed
Explanation:Input buffering keeps a short window of recent input intentions (e.g. 'jump was pressed') so the game can still honor it a few frames later, even if the exact frame it was pressed on wasn't the 'correct' one to act on it.
Game Input AudioDifficulty 1
Conceptually, what distinguishes 3D (positional/spatial) audio from plain 2D audio in a game?
- a3D audio can only play music tracks, never sound effects
- b2D audio requires more CPU because it simulates air pressure
- c3D audio is always recorded with a higher sample rate
- dVolume/pan change with the listener's distance and direction✓
Explanation:2D (non-positional) audio, typically used for UI sounds or music, plays at a fixed volume/pan regardless of where anything is in the world. 3D/positional audio attenuates and pans based on the relative position of the sound source to a listener.
Game Input AudioDifficulty 2
A game creates a brand-new sound-playing object every time a bullet fires, and destroys it when the sound finishes. Under heavy gunfire, audio starts stuttering. What concept addresses this?
- aIncreasing the game's target frame rate
- bAudio pooling: reusing pre-created sound objects✓
- cSwitching all sound effects to 3D positional audio
- dRecording the gunfire sound at a lower sample rate
Explanation:Audio pooling keeps a reusable pool of sound-emitting objects (voices) that are borrowed and returned instead of constantly created/destroyed, avoiding allocation overhead and voice-limit exhaustion under bursts of sound events.