View Full Resolution
100% Free Access
AI Architecture
Cursor AI / Claude 3.5
Category
AI Agents
Best Use Case
Commercial & Cinematic
AI Agents
Verified Blueprint
Gamemaker Gml Agent Rule
GameMaker Language (GML) rules for scripts, objects, events, rooms, data structures, and performance-minded game code
Ready-to-Run Prompt
100% Free Copy
# GameMaker GML Rules
## Code Organization
- Keep object event code short and move reusable behavior into scripts or functions.
- Use clear prefixes or naming conventions for scripts, objects, sprites, rooms, and globals.
- Prefer functions over copy-pasted event blocks.
- Keep create-step-draw responsibilities separate.
- Put initialization in Create, simulation in Step, and rendering-only work in Draw.
## GML Style
- Use descriptive variable names and avoid one-letter names outside small loops.
- Prefer local variables with `var` or function-scoped declarations over unnecessary instance variables.
- Use constants, enums, and macros for repeated identifiers, layer names, states, and collision groups.
- Guard optional instance references with `instance_exists`.
- Keep global state minimal and document it.
## Gameplay Architecture
- Use finite state machines for player, enemy, UI, and game-flow states.
- Keep collision logic explicit and deterministic.
- Separate input collection from action execution.
- Use alarms, timelines, or explicit timers consistently; do not mix patterns without reason.
- Store save data through structured maps/structs and version the save format.
## Performance
- Avoid expensive searches such as broad `instance_find` or repeated collision scans in every Step event.
- Cache frequently used asset IDs, layer IDs, and object references when safe.
- Destroy data structures when no longer needed.
- Use object pooling for frequent projectiles, particles, or short-lived effects when allocation becomes costly.
- Profile before optimizing and keep hot-path code simple.
## Debugging and Testing
- Add debug overlays for collision boxes, state, velocity, and AI decisions when useful.
- Use assertions or explicit guard clauses for impossible states.
- Test room transitions, pause/resume, save/load, and controller/keyboard input separately.
- Keep reproducible test rooms for complex mechanics.
## Common Mistakes
- Do not put game logic in Draw events.
- Do not create data structures without destroying them.
- Do not rely on room editor instance order for critical behavior.
- Do not hardcode magic numeric state IDs.
## Code Organization
- Keep object event code short and move reusable behavior into scripts or functions.
- Use clear prefixes or naming conventions for scripts, objects, sprites, rooms, and globals.
- Prefer functions over copy-pasted event blocks.
- Keep create-step-draw responsibilities separate.
- Put initialization in Create, simulation in Step, and rendering-only work in Draw.
## GML Style
- Use descriptive variable names and avoid one-letter names outside small loops.
- Prefer local variables with `var` or function-scoped declarations over unnecessary instance variables.
- Use constants, enums, and macros for repeated identifiers, layer names, states, and collision groups.
- Guard optional instance references with `instance_exists`.
- Keep global state minimal and document it.
## Gameplay Architecture
- Use finite state machines for player, enemy, UI, and game-flow states.
- Keep collision logic explicit and deterministic.
- Separate input collection from action execution.
- Use alarms, timelines, or explicit timers consistently; do not mix patterns without reason.
- Store save data through structured maps/structs and version the save format.
## Performance
- Avoid expensive searches such as broad `instance_find` or repeated collision scans in every Step event.
- Cache frequently used asset IDs, layer IDs, and object references when safe.
- Destroy data structures when no longer needed.
- Use object pooling for frequent projectiles, particles, or short-lived effects when allocation becomes costly.
- Profile before optimizing and keep hot-path code simple.
## Debugging and Testing
- Add debug overlays for collision boxes, state, velocity, and AI decisions when useful.
- Use assertions or explicit guard clauses for impossible states.
- Test room transitions, pause/resume, save/load, and controller/keyboard input separately.
- Keep reproducible test rooms for complex mechanics.
## Common Mistakes
- Do not put game logic in Draw events.
- Do not create data structures without destroying them.
- Do not rely on room editor instance order for critical behavior.
- Do not hardcode magic numeric state IDs.
Structured JSON Schema
Use with automated API pipelines, LangChain, or custom image generators
{
"system_prompt": "# GameMaker GML Rules\n\n## Code Organization\n\n- Keep object event code short and move reusable behavior into scripts or functions.\n- Use clear prefixes or naming conventions for scripts, objects, sprites, rooms, and globals.\n- Prefer functions over copy-pasted event blocks.\n- Keep create-step-draw responsibilities separate.\n- Put initialization in Create, simulation in Step, and rendering-only work in Draw.\n\n## GML Style\n\n- Use descriptive variable names and avoid one-letter names outside small loops.\n- Prefer local variables with `var` or function-scoped declarations over unnecessary instance variables.\n- Use constants, enums, and macros for repeated identifiers, layer names, states, and collision groups.\n- Guard optional instance references with `instance_exists`.\n- Keep global state minimal and document it.\n\n## Gameplay Architecture\n\n- Use finite state machines for player, enemy, UI, and game-flow states.\n- Keep collision logic explicit and deterministic.\n- Separate input collection from action execution.\n- Use alarms, timelines, or explicit timers consistently; do not mix patterns without reason.\n- Store save data through structured maps/structs and version the save format.\n\n## Performance\n\n- Avoid expensive searches such as broad `instance_find` or repeated collision scans in every Step event.\n- Cache frequently used asset IDs, layer IDs, and object references when safe.\n- Destroy data structures when no longer needed.\n- Use object pooling for frequent projectiles, particles, or short-lived effects when allocation becomes costly.\n- Profile before optimizing and keep hot-path code simple.\n\n## Debugging and Testing\n\n- Add debug overlays for collision boxes, state, velocity, and AI decisions when useful.\n- Use assertions or explicit guard clauses for impossible states.\n- Test room transitions, pause/resume, save/load, and controller/keyboard input separately.\n- Keep reproducible test rooms for complex mechanics.\n\n## Common Mistakes\n\n- Do not put game logic in Draw events.\n- Do not create data structures without destroying them.\n- Do not rely on room editor instance order for critical behavior.\n- Do not hardcode magic numeric state IDs.",
"prompt_type": "agent_rule",
"framework": "cursor",
"globs": "[\"**/*.gml\", \"**/*.yy\", \"**/*.yyp\"]",
"compatible_models": [
"Claude 3.5 Sonnet",
"GPT-4o",
"Cursor AI",
"Gemini 2.5 Flash"
],
"download_filename": "gamemaker-gml.cursorrules",
"tags": [
"cursor",
"cursorrules",
"agent",
"coding",
"gamemaker"
]
}
Internal Discovery
View All →