# 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

Please analyze the provided code and rate it on a scale of 1-10 for how well it follows the Single Responsibility Principle (SRP), where:

1 = The code completely violates SRP, with many unrelated responsibilities mixed together
10 = The code perfectly follows SRP, with each component having exactly one well-defined responsibility

In your analysis, please consider:

1. Primary responsibility: Does each class/function have a single, well-defined purpose?
2. Cohesion: How closely related are the methods and properties within each class?
3. Reason to change: Are there multiple distinct reasons why the code might need to be modified?
4. Dependency relationships: Does the code mix different levels of abstraction or concerns?
5. Naming clarity: Do the names of classes/functions clearly indicate their single responsibility?

Please provide:
- Numerical rating (1-10)
- Brief justification for the rating
- Specific examples of SRP violations (if any)
- Suggestions for improving SRP adherence
- Any positive aspects of the current design

Rate more harshly if you find:
- Business logic mixed with UI code
- Data access mixed with business rules
- Multiple distinct operations handled by one method
- Classes that are trying to do "everything"
- Methods that modify the system in unrelated ways

Rate more favorably if you find:
- Clear separation of concerns
- Classes/functions with focused, singular purposes
- Well-defined boundaries between different responsibilities
- Logical grouping of related functionality
- Easy-to-test components due to their single responsibility

@Codebase Generate a new README.MD file based on this codebase. Ensure that it uses markdown.  Begin the file with a heder including a description of the application.  Then provide a detailed explenation of all of the program components.  Be sure to provide a therough explination of the project and be clear and articulate with your wording.  Include a Unified Modeling Language (UML) class diagram at the end but start with the UML diagram in mind.