Agent Skills: Gamedev Expert

Gamedev Expert

When reviewing or writing code, apply these guidelines:

• Use exceptions for exceptional cases, not for control flow.
• Implement proper error logging and user-friendly messages.

dragonruby general ruby rules

When reviewing or writing code, apply these guidelines:

• Write concise, idiomatic Ruby code with accurate examples.
• Follow Ruby and DragonRuby conventions and best practices.
• Use object-oriented and functional programming patterns as appropriate.
• Prefer iteration and modularization over code duplication.
• Structure files according to DragonRuby conventions.

dragonruby naming conventions

When reviewing or writing code, apply these guidelines:

• Use snake_case for file names, method names, and variables.
• Use CamelCase for class and module names.
• Follow DragonRuby naming conventions.

dragonruby syntax and formatting

When reviewing or writing code, apply these guidelines:

• Follow the Ruby Style Guide (https://rubystyle.guide/)
• Use Ruby's expressive syntax (e.g., unless, ||=, &.)
• Prefer single quotes for strings unless interpolation is needed.

Iron Laws

1. ALWAYS use object pooling for frequently instantiated game objects (bullets, particles, enemies) — creating and destroying objects every frame triggers garbage collection pauses that cause visible frame drops.
2. NEVER perform physics calculations or heavy logic in the render/draw tick — separate update logic from rendering; mixing them causes non-deterministic simulation behavior and frame-rate-dependent bugs.
3. ALWAYS use state machines (or behavior trees) for game entity AI and game mode transitions — ad-hoc if/else chains for game state become unmaintainable and produce impossible-to-reproduce edge case bugs.
4. NEVER store raw input state in entity objects — centralize input handling in a dedicated input manager; scattered input checks make remapping, multiplayer, and replay impossible.
5. ALWAYS profile before optimizing — premature optimization targets the wrong bottleneck; measure draw calls, GC pressure, and physics budget first with platform profiler tools.

Anti-Patterns

| Anti-Pattern | Why It Fails | Correct Approach | | -------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------- | | Instantiating/destroying objects every frame | GC pressure causes frame hitches; performance degrades with entity count | Use object pools; reuse pre-allocated instances by resetting and re-enabling | | Game logic in the render step | Frame-rate-dependent behavior; desync between logic and display | Separate fixed-rate update loop from variable-rate render loop | | Ad-hoc if/else for entity states | Impossible edge cases; transitions undefined for unexpected state combos | Use explicit state machine with defined transitions and entry/exit hooks | | Direct input polling in entity update | Breaks remapping, replay, and multiplayer input sync | Route all input through centralized input manager updated once per frame | | Optimizing without profiling | Wrong bottleneck targeted; CPU/GPU budget guesses are often wrong | Profile with Unity Profiler or platform tools; optimize measured hot paths only |

Consolidated Skills

This expert skill consolidates 4 individual skills:

• dragonruby-error-handling
• dragonruby-general-ruby-rules
• dragonruby-naming-conventions
• dragonruby-syntax-and-formatting

Memory Protocol (MANDATORY)

Before starting:

cat .claude/context/memory/learnings.md

After completing: Record any new patterns or exceptions discovered.

ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.