Sample questions
Game State ManagementDifficulty 1
In game engineering, what does a "state machine" for game flow (menu, gameplay, pause, game-over) fundamentally represent?
- aA cache that keeps every asset the game has ever loaded
- bA log that records every input event since the game launched
- cA model where the game is always in one mode that governs behavior✓
- dA scheduler that decides exactly how many frames the renderer draws every single second
Explanation:A state machine models the game as being in one well-defined mode at a time (menu, gameplay, pause, etc.), and what code runs and what input means depends on which mode is currently active.
Game State ManagementDifficulty 1
A character in a platformer typically has states like idle, walking, jumping, and attacking. Which of the following is NOT normally treated as a character state on its own?
- aThe jumping behavior the character switches into mid-air
- bThe current rendering frame rate the game happens to run at✓
- cThe attacking behavior triggered by an input
- dThe idle behavior the character defaults to
Explanation:Frame rate is a performance/rendering metric, not a mode of character behavior; idle, walking, jumping, and attacking are behavioral states because they change what animations play and what inputs are valid.
Game State ManagementDifficulty 1
Conceptually, what is a "scene" or "level" in the context of scene/level management?
- aA distinct unit of content the engine can load and later unload✓
- bA single texture file used only for background art
- cA fixed-size memory buffer reserved only for storing save-game data
- dThe precise button sequence needed to finish an area
Explanation:A scene/level is a unit of content — geometry, entities, and logic — that the engine can load into memory and later unload, which is the basis for organizing a game into separate areas.
Game State ManagementDifficulty 1
Why is a "loading" screen usually modeled as its own explicit game state rather than just a visual overlay on top of gameplay?
- aBecause loading screens are required to show a progress bar
- bBecause it lets the art team reuse the exact same background image everywhere
- cBecause it reduces the size of the game's install package
- dBecause gameplay logic should not run while loading✓
Explanation:Treating loading as its own state ensures gameplay systems (physics, AI, input) simply do not execute until loading finishes, avoiding crashes or invalid behavior on incomplete data.
Game State ManagementDifficulty 1
Why is "paused" usually modeled as a distinct game state instead of just freezing the render loop?
- aBecause the logic and timers must also be stopped, not just the visuals✓
- bBecause pausing always requires writing a save file to disk
- cBecause the operating system automatically halts all running code the moment a window loses focus
- dBecause it lowers the number of art assets the level requires
Explanation:Freezing only the visuals would leave timers, physics, and AI still updating in the background; modeling pause as a real state ensures the whole simulation (not just rendering) stops consistently.
Game State ManagementDifficulty 1
What is the basic conceptual difference between a full "save" and a "checkpoint"?
- aA checkpoint is defined as storing strictly more data than a full save
- bA save persists the whole session across restarts; a checkpoint restores progress mid-attempt✓
- cA save can be created only once during an entire game
- dCheckpoints exist only in graphics-card memory, never elsewhere
Explanation:A full save is designed so the player can quit and resume later with the whole session state restored, while a checkpoint is usually a lighter-weight recovery point used within a level or run, not necessarily a full persistent save.