# JavaScript Game Development Guidelines
Follow these rules to ensure clean, efficient, and scalable JavaScript game development:
## 1. Modular Code Structure
- Break code into modules (e.g., input handling, physics, rendering).
- Use ES6 modules or bundlers (like Webpack) for clean separation.
- Avoid global variables; use scoped imports/exports.
- Group related functionality in reusable classes or objects.
## 2. Game Loop Design
- Use `requestAnimationFrame()` for optimal rendering.
- Separate update and render logic.
- Maintain a consistent delta time (`dt`) for frame-independent movement.
- Avoid heavy computations in the render loop; offload to workers if needed.
## 3. Entity-Component-System (ECS) Pattern
- Favor composition over inheritance for game objects.
- Define components as data containers (e.g., position, velocity).
- Implement systems to operate on entities with specific components.
- Use ECS for scalability and maintainability in complex games.
## 4. Input Handling
- Use event listeners for keyboard/mouse/gamepad input.
- Maintain an input state object updated by events.
- Decouple input from game logic; translate input to commands/actions.
- Allow customizable key bindings for accessibility.
## 5. Asset Management
- Preload assets (images, audio, spritesheets) before gameplay.
- Use loading screens and progress indicators.
- Organize assets by type and usage (e.g., UI, enemies, backgrounds).
- Release unused assets and nullify references to help garbage collection.
## 6. Performance Optimization
- Use object pooling to reuse frequently created/destroyed objects.
- Minimize DOM manipulation; prefer canvas/WebGL for rendering.
- Profile with DevTools; optimize bottlenecks in update/render cycles.
- Reduce memory leaks by cleaning up intervals, listeners, and unused objects.
## 7. Rendering Best Practices
- Use `CanvasRenderingContext2D` or `WebGL` depending on visual complexity.
- Clear and redraw each frame; do not rely on overlapping draw calls.
- Batch draw calls where possible to improve rendering performance.
- Optimize sprite sheet usage to minimize draw calls.
## 8. State Management
- Define clear game states (e.g., menu, playing, paused, game over).
- Use a state machine pattern to manage transitions and logic.
- Isolate logic by state to avoid conditional sprawl.
- Allow easy state resetting or switching for reusability.
## 9. Debugging and Logging
- Use structured logging and meaningful error messages.
- Include developer toggles (e.g., show FPS, hitboxes, debug overlays).
- Create a debug mode with keyboard shortcuts for testing.
- Remove or disable verbose logging in production builds.
## 10. Testing and Version Control
- Write unit tests for game logic where possible.
- Use Git with descriptive commits and branches for features/bugs.
- Regularly back up game progress and development branches.
- Perform playtesting to identify usability and performance issues.
## Bonus: User Experience (UX)
- Provide audio/visual feedback for player actions.
- Implement responsive UI that scales with screen/device.
- Save user preferences (e.g., volume, controls) in local storage.
- Include a tutorial or help screen to ease player onboarding.

# SOLID Design Principles - Coding Assistant Guidelines

When generating, reviewing, or modifying code, follow these guidelines to ensure adherence to SOLID principles:

## 1. Single Responsibility Principle (SRP)

- Each class must have only one reason to change.
- Limit class scope to a single functional area or abstraction level.
- When a class exceeds 100-150 lines, consider if it has multiple responsibilities.
- Separate cross-cutting concerns (logging, validation, error handling) from business logic.
- Create dedicated classes for distinct operations like data access, business rules, and UI.
- Method names should clearly indicate their singular purpose.
- If a method description requires "and" or "or", it likely violates SRP.
- Prioritize composition over inheritance when combining behaviors.

## 2. Open/Closed Principle (OCP)

- Design classes to be extended without modification.
- Use abstract classes and interfaces to define stable contracts.
- Implement extension points for anticipated variations.
- Favor strategy patterns over conditional logic.
- Use configuration and dependency injection to support behavior changes.
- Avoid switch/if-else chains based on type checking.
- Provide hooks for customization in frameworks and libraries.
- Design with polymorphism as the primary mechanism for extending functionality.

## 3. Liskov Substitution Principle (LSP)

- Ensure derived classes are fully substitutable for their base classes.
- Maintain all invariants of the base class in derived classes.
- Never throw exceptions from methods that don't specify them in base classes.
- Don't strengthen preconditions in subclasses.
- Don't weaken postconditions in subclasses.
- Never override methods with implementations that do nothing or throw exceptions.
- Avoid type checking or downcasting, which may indicate LSP violations.
- Prefer composition over inheritance when complete substitutability can't be achieved.

## 4. Interface Segregation Principle (ISP)

- Create focused, minimal interfaces with cohesive methods.
- Split large interfaces into smaller, more specific ones.
- Design interfaces around client needs, not implementation convenience.
- Avoid "fat" interfaces that force clients to depend on methods they don't use.
- Use role interfaces that represent behaviors rather than object types.
- Implement multiple small interfaces rather than a single general-purpose one.
- Consider interface composition to build up complex behaviors.
- Remove any methods from interfaces that are only used by a subset of implementing classes.

## 5. Dependency Inversion Principle (DIP)

- High-level modules should depend on abstractions, not details.
- Make all dependencies explicit, ideally through constructor parameters.
- Use dependency injection to provide implementations.
- Program to interfaces, not concrete classes.
- Place abstractions in a separate package/namespace from implementations.
- Avoid direct instantiation of service classes with 'new' in business logic.
- Create abstraction boundaries at architectural layer transitions.
- Define interfaces owned by the client, not the implementation.

## Implementation Guidelines

- When starting a new class, explicitly identify its single responsibility.
- Document extension points and expected subclassing behavior.
- Write interface contracts with clear expectations and invariants.
- Question any class that depends on many concrete implementations.
- Use factories, dependency injection, or service locators to manage dependencies.
- Review inheritance hierarchies to ensure LSP compliance.
- Regularly refactor toward SOLID, especially when extending functionality.
- Use design patterns (Strategy, Decorator, Factory, Observer, etc.) to facilitate SOLID adherence.

## Warning Signs

- God classes that do "everything"
- Methods with boolean parameters that radically change behavior
- Deep inheritance hierarchies
- Classes that need to know about implementation details of their dependencies
- Circular dependencies between modules
- High coupling between unrelated components
- Classes that grow rapidly in size with new features
- Methods with many parameters