MonoGame loop and states
Keeps gameplay updates separate from drawing so rendering frequency does not change the rules. It defines entry, exit and pause behavior for menu, play and game-over states.
monogame-game-loop-states
See how it helpsWhen is it useful?
Use when MonoGame behavior changes with frame rate or repeated updates cause duplicate actions.
What does it help you do?
- Checks fixed-step settings and elapsed-time units.
- Keeps movement and scoring in updates rather than rendering.
- Defines entry, exit and pause rules for game states.
Try asking this
Create menu, race, pause and results states for our kart game. Resize the window and vary drawing frequency during a lap. Lap timing and scoring must advance from simulation updates, pause must freeze the intended systems and a new race must reset only round-specific data.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
MonoGame — game loop states
Use when implementing MonoGame Update/Draw, game states, pause or timing.
Version and project gate
Inspect Project and .NET target, MonoGame package/backend, Game loop settings, MGCB files/tool versions, content root, GraphicsProfile, platform libraries and existing screen/state architecture. Never turn a task into an engine upgrade without the user’s intent. Read the version-matching official reference when an API decision depends on it.
Work
Read IsFixedTimeStep and TargetElapsedTime. Keep simulation changes in Update and presentation in Draw; account for multiple updates between draws. Define state entry/exit and pause behavior, and use the appropriate elapsed time units consistently.
Deliver
A timing/state contract and complete menu-play-pause-restart slice. Keep the change in the existing project structure; separate actual observations from the proposed acceptance scenario below.
Failure to prevent
Do not mutate score or movement in Draw or assume each Update has a matching Draw.
Acceptance scenario
Simulate a slow update, pause/resume and replay the same timed inputs without frame-dependent duplicate actions. Follow the project’s execution and verification permissions. If execution or a target device is unavailable, provide the reproduction steps and name the remaining uncertainty; do not mark it passed.
Scope and sources
This skill belongs to Mox. Agent selection is restricted by Orqestria’s assigned-agent policy, including forced skill selection; instruction text alone is not an access control. These are original task workflows researched from official documentation, not a copied or endorsed vendor skill.
Included files 1
SKILL.md