📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
+22
-19
@@ -1,6 +1,9 @@
|
||||
---
|
||||
name: 2d-games
|
||||
description: "2D game development principles. Sprites, tilemaps, physics, camera."
|
||||
description: >-
|
||||
2D game development principles. Sprites, atlases, tilemaps, physics, cameras,
|
||||
and genre patterns (platformer, top-down). Use for canvas/Phaser/Kaplay/Pixi
|
||||
2D games or guest viewports inside hybrid web apps.
|
||||
risk: none
|
||||
source: community
|
||||
date_added: "2026-02-27"
|
||||
@@ -8,24 +11,30 @@ date_added: "2026-02-27"
|
||||
|
||||
# 2D Game Development
|
||||
|
||||
> Principles for 2D game systems.
|
||||
> Principles for 2D game systems. Pair with `game-development/web-games` / `game-development/engine-selection` for framework choice.
|
||||
|
||||
---
|
||||
|
||||
## Shell vs guest (web)
|
||||
|
||||
| Setup | 2D systems live… |
|
||||
|-------|------------------|
|
||||
| Full-screen 2D game | Entire app (Phaser/Kaplay/Pixi/Canvas) |
|
||||
| Hybrid DOM + challenges | Only inside guest viewports; tear down when done |
|
||||
|
||||
---
|
||||
|
||||
## 1. Sprite Systems
|
||||
|
||||
### Sprite Organization
|
||||
|
||||
| Component | Purpose |
|
||||
|-----------|---------|
|
||||
| **Atlas** | Combine textures, reduce draw calls |
|
||||
| **Animation** | Frame sequences |
|
||||
| **Animation** | Frame sequences (often 8-24 FPS) |
|
||||
| **Pivot** | Rotation/scale origin |
|
||||
| **Layering** | Z-order control |
|
||||
|
||||
### Animation Principles
|
||||
|
||||
- Frame rate: 8-24 FPS typical
|
||||
- Squash and stretch for impact
|
||||
- Anticipation before action
|
||||
- Follow-through after action
|
||||
@@ -34,16 +43,12 @@ date_added: "2026-02-27"
|
||||
|
||||
## 2. Tilemap Design
|
||||
|
||||
### Tile Considerations
|
||||
|
||||
| Factor | Recommendation |
|
||||
|--------|----------------|
|
||||
| **Size** | 16x16, 32x32, 64x64 |
|
||||
| **Auto-tiling** | Use for terrain |
|
||||
| **Collision** | Simplified shapes |
|
||||
|
||||
### Layers
|
||||
|
||||
| Layer | Content |
|
||||
|-------|---------|
|
||||
| Background | Non-interactive scenery |
|
||||
@@ -55,8 +60,6 @@ date_added: "2026-02-27"
|
||||
|
||||
## 3. 2D Physics
|
||||
|
||||
### Collision Shapes
|
||||
|
||||
| Shape | Use Case |
|
||||
|-------|----------|
|
||||
| Box | Rectangular objects |
|
||||
@@ -64,9 +67,7 @@ date_added: "2026-02-27"
|
||||
| Capsule | Characters |
|
||||
| Polygon | Complex shapes |
|
||||
|
||||
### Physics Considerations
|
||||
|
||||
- Pixel-perfect vs physics-based
|
||||
- Pixel-perfect vs physics-based: pick one approach per game
|
||||
- Fixed timestep for consistency
|
||||
- Layers for filtering
|
||||
|
||||
@@ -74,14 +75,13 @@ date_added: "2026-02-27"
|
||||
|
||||
## 4. Camera Systems
|
||||
|
||||
### Camera Types
|
||||
|
||||
| Type | Use |
|
||||
|------|-----|
|
||||
| **Follow** | Track player |
|
||||
| **Look-ahead** | Anticipate movement |
|
||||
| **Multi-target** | Two-player |
|
||||
| **Room-based** | Metroidvania |
|
||||
| **Static** | Board games, modal skill-checks |
|
||||
|
||||
### Screen Shake
|
||||
|
||||
@@ -103,7 +103,7 @@ date_added: "2026-02-27"
|
||||
|
||||
- 8-directional or free movement
|
||||
- Aim-based or auto-aim
|
||||
- Consider rotation or not
|
||||
- Decide whether rotation matters
|
||||
|
||||
---
|
||||
|
||||
@@ -115,15 +115,18 @@ date_added: "2026-02-27"
|
||||
| Complex collision shapes | Simplified collision |
|
||||
| Jittery camera | Smooth following |
|
||||
| Pixel-perfect on physics | Choose one approach |
|
||||
| Orphaned RAF/listeners after a guest closes | Full teardown |
|
||||
|
||||
---
|
||||
|
||||
> **Remember:** 2D is about clarity. Every pixel should communicate.
|
||||
|
||||
## When to Use
|
||||
This skill is applicable to execute the workflow or actions described in the overview.
|
||||
|
||||
Use for canvas/Phaser/Kaplay/Pixi 2D systems, or guest viewports inside hybrid web apps.
|
||||
|
||||
## Limitations
|
||||
|
||||
- Use this skill only when the task clearly matches the scope described above.
|
||||
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
|
||||
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
|
||||
|
||||
+27
-35
@@ -1,6 +1,10 @@
|
||||
---
|
||||
name: game-development
|
||||
description: "Game development orchestrator. Routes to platform-specific skills based on project needs."
|
||||
description: >-
|
||||
Game development orchestrator. Routes by platform, dimension, and engine fit
|
||||
(web 2D/3D, hybrid DOM+canvas, narrative tools). Use when starting or
|
||||
structuring a game project, choosing frameworks, or picking among Phaser,
|
||||
PixiJS, Kaplay, Canvas/WebGL, Three.js, Babylon.js, Godot, Unity, or Ink/Twine.
|
||||
risk: unknown
|
||||
source: community
|
||||
date_added: "2026-02-27"
|
||||
@@ -8,13 +12,13 @@ date_added: "2026-02-27"
|
||||
|
||||
# Game Development
|
||||
|
||||
> **Orchestrator skill** that provides core principles and routes to specialized sub-skills.
|
||||
> **Orchestrator skill** — principles plus routing to specialized sub-skills.
|
||||
|
||||
---
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
You are working on a game development project. This skill teaches the PRINCIPLES of game development and directs you to the right sub-skill based on context.
|
||||
You are working on a game development project. This skill teaches PRINCIPLES and directs you to the right sub-skill based on context.
|
||||
|
||||
---
|
||||
|
||||
@@ -24,7 +28,7 @@ You are working on a game development project. This skill teaches the PRINCIPLES
|
||||
|
||||
| If the game targets... | Use Sub-Skill |
|
||||
|------------------------|---------------|
|
||||
| Web browsers (HTML5, WebGL) | `game-development/web-games` |
|
||||
| Web browsers (HTML5, WebGL, WebGPU) | `game-development/web-games` |
|
||||
| Mobile (iOS, Android) | `game-development/mobile-games` |
|
||||
| PC (Steam, Desktop) | `game-development/pc-games` |
|
||||
| VR/AR headsets | `game-development/vr-ar` |
|
||||
@@ -36,10 +40,11 @@ You are working on a game development project. This skill teaches the PRINCIPLES
|
||||
| 2D (sprites, tilemaps) | `game-development/2d-games` |
|
||||
| 3D (meshes, shaders) | `game-development/3d-games` |
|
||||
|
||||
### Specialty Areas
|
||||
### Architecture / tooling
|
||||
|
||||
| If you need... | Use Sub-Skill |
|
||||
|----------------|---------------|
|
||||
| Engine / framework choice, shell vs guest, fit tiers | `game-development/engine-selection` |
|
||||
| GDD, balancing, player psychology | `game-development/game-design` |
|
||||
| Multiplayer, networking | `game-development/multiplayer` |
|
||||
| Visual style, asset pipeline, animation | `game-development/game-art` |
|
||||
@@ -51,8 +56,6 @@ You are working on a game development project. This skill teaches the PRINCIPLES
|
||||
|
||||
### 1. The Game Loop
|
||||
|
||||
Every game, regardless of platform, follows this pattern:
|
||||
|
||||
```
|
||||
INPUT → Read player actions
|
||||
UPDATE → Process game logic (fixed timestep)
|
||||
@@ -64,7 +67,7 @@ RENDER → Draw the frame (interpolated)
|
||||
- Rendering: As fast as possible
|
||||
- Interpolate between states for smooth visuals
|
||||
|
||||
---
|
||||
**Hybrid / UI-heavy games:** the outer app may be DOM/event-driven; use a classic game loop only in canvas/WebGL viewports (or wherever simulation ticks).
|
||||
|
||||
### 2. Pattern Selection Matrix
|
||||
|
||||
@@ -76,11 +79,10 @@ RENDER → Draw the frame (interpolated)
|
||||
| **ECS** | Thousands of similar entities | RTS units, particles |
|
||||
| **Command** | Undo, replay, networking | Input recording |
|
||||
| **Behavior Tree** | Complex AI decisions | Enemy AI |
|
||||
| **Content-as-data** | Designers ship levels/events without code | JSON/YAML packs |
|
||||
|
||||
**Decision Rule:** Start with State Machine. Add ECS only when performance demands.
|
||||
|
||||
---
|
||||
|
||||
### 3. Input Abstraction
|
||||
|
||||
Abstract input into ACTIONS, not raw keys:
|
||||
@@ -90,10 +92,6 @@ Abstract input into ACTIONS, not raw keys:
|
||||
"move" → WASD, Left stick, Virtual joystick
|
||||
```
|
||||
|
||||
**Why:** Enables multi-platform, rebindable controls.
|
||||
|
||||
---
|
||||
|
||||
### 4. Performance Budget (60 FPS = 16.67ms)
|
||||
|
||||
| System | Budget |
|
||||
@@ -105,14 +103,7 @@ Abstract input into ACTIONS, not raw keys:
|
||||
| Rendering | 5ms |
|
||||
| Buffer | 1.67ms |
|
||||
|
||||
**Optimization Priority:**
|
||||
1. Algorithm (O(n²) → O(n log n))
|
||||
2. Batching (reduce draw calls)
|
||||
3. Pooling (avoid GC spikes)
|
||||
4. LOD (detail by distance)
|
||||
5. Culling (skip invisible)
|
||||
|
||||
---
|
||||
**Optimization Priority:** Algorithm → Batching → Pooling → LOD → Culling.
|
||||
|
||||
### 5. AI Selection by Complexity
|
||||
|
||||
@@ -123,8 +114,6 @@ Abstract input into ACTIONS, not raw keys:
|
||||
| **GOAP** | High | Emergent, planning-based |
|
||||
| **Utility AI** | High | Scoring-based decisions |
|
||||
|
||||
---
|
||||
|
||||
### 6. Collision Strategy
|
||||
|
||||
| Type | Best For |
|
||||
@@ -145,30 +134,33 @@ Abstract input into ACTIONS, not raw keys:
|
||||
| Cache nothing | Cache references |
|
||||
| Optimize without profiling | Profile first |
|
||||
| Mix input with logic | Abstract input layer |
|
||||
| Pick an engine by hype | Match engine to genre + team + delivery target |
|
||||
|
||||
---
|
||||
|
||||
## Routing Examples
|
||||
|
||||
### Example 1: "I want to make a browser-based 2D platformer"
|
||||
→ Start with `game-development/web-games` for framework selection
|
||||
→ Then `game-development/2d-games` for sprite/tilemap patterns
|
||||
→ Reference `game-development/game-design` for level design
|
||||
### “Browser 2D platformer”
|
||||
→ `game-development/engine-selection` → `game-development/web-games` → `game-development/2d-games` → `game-development/game-design`
|
||||
|
||||
### Example 2: "Mobile puzzle game for iOS and Android"
|
||||
→ Start with `game-development/mobile-games` for touch input and stores
|
||||
→ Use `game-development/game-design` for puzzle balancing
|
||||
### “UI-heavy web game with small arcade challenges”
|
||||
→ `game-development/engine-selection` (shell vs guest) → `game-development/web-games` → `game-development/2d-games` for guests only
|
||||
|
||||
### Example 3: "Multiplayer VR shooter"
|
||||
→ `game-development/vr-ar` for comfort and immersion
|
||||
→ `game-development/3d-games` for rendering
|
||||
→ `game-development/multiplayer` for networking
|
||||
### “Mobile puzzle”
|
||||
→ `game-development/mobile-games` → `game-development/game-design`
|
||||
|
||||
### “Multiplayer VR shooter”
|
||||
→ `game-development/vr-ar` → `game-development/3d-games` → `game-development/multiplayer`
|
||||
|
||||
### “Branching narrative with light stats”
|
||||
→ `game-development/engine-selection` (Ink/Twine) → host UI of your choice
|
||||
|
||||
---
|
||||
|
||||
> **Remember:** Great games come from iteration, not perfection. Prototype fast, then polish.
|
||||
|
||||
## Limitations
|
||||
|
||||
- Use this skill only when the task clearly matches the scope described above.
|
||||
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
|
||||
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
|
||||
|
||||
+115
@@ -0,0 +1,115 @@
|
||||
---
|
||||
name: engine-selection
|
||||
description: >-
|
||||
Selects game engines and frameworks by platform, genre, and architecture
|
||||
(full canvas shell vs hybrid DOM shell + guest viewport). Covers Phaser,
|
||||
PixiJS, Kaplay, Canvas/WebGL, Three.js, Babylon.js, Godot, Unity, Ink, Twine.
|
||||
Use when choosing a stack or comparing runtimes before implementation.
|
||||
risk: safe
|
||||
source: self
|
||||
date_added: "2026-07-17"
|
||||
---
|
||||
|
||||
# Engine selection
|
||||
|
||||
> Pick tools that match **delivery target**, **interaction model**, and **team constraints**. Engines serve the game type — not the reverse.
|
||||
|
||||
---
|
||||
|
||||
## Fit questions (ask first)
|
||||
|
||||
1. **Platform:** Web, mobile, PC, console, VR?
|
||||
2. **Primary loop:** Action/physics, turn-based, narrative branch, management/UI, hybrid?
|
||||
3. **Presentation:** Full-screen canvas, DOM/UI chrome, or both?
|
||||
4. **Toolchain:** No-build / ESM OK, or bundler + editor OK?
|
||||
5. **Authoring:** Code-only, or designers need Twine/Ink/Godot/Unity editors?
|
||||
|
||||
---
|
||||
|
||||
## Architecture patterns
|
||||
|
||||
| Pattern | When | Notes |
|
||||
|---------|------|-------|
|
||||
| **Full engine shell** | Game *is* the canvas/scene | Phaser, Godot, Unity, Kaplay as app root |
|
||||
| **Renderer + custom logic** | You want draw power, own gameplay | PixiJS, Three.js + your systems |
|
||||
| **Hybrid shell + guest** | Dense UI/text + occasional skill-checks | DOM/app shell; mount canvas engines in modals/viewports only |
|
||||
| **Narrative runtime** | Branching prose is the product | Ink, Twine; host chrome separately |
|
||||
| **Content-as-data** | Levels/events authored as packs | JSON/YAML + thin loader; engine optional |
|
||||
|
||||
---
|
||||
|
||||
## Web — decision tree
|
||||
|
||||
```
|
||||
What type of game?
|
||||
│
|
||||
├── Mostly DOM / panels / forms / text UI
|
||||
│ ├── + small arcade/spatial challenges
|
||||
│ │ └── Hybrid: custom shell + guest
|
||||
│ │ Raw Canvas/WebGL → Kaplay → Phaser → PixiJS
|
||||
│ └── + branching story
|
||||
│ └── Ink (inkjs) or Twine export → host in DOM
|
||||
│
|
||||
├── Full-screen 2D game
|
||||
│ ├── Full gameplay features (scenes, physics, input)
|
||||
│ │ └── Phaser 4 (or Kaplay if you want lighter/faster prototype)
|
||||
│ └── Mostly rendering / custom systems
|
||||
│ └── PixiJS 8 (or Raw Canvas/WebGL if tiny scope)
|
||||
│
|
||||
└── Full-screen 3D game
|
||||
├── Full engine / physics / XR
|
||||
│ └── Babylon.js
|
||||
└── Rendering-focused / lighter
|
||||
└── Three.js
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quick comparison (web & common exports)
|
||||
|
||||
| Tool | Type | Best for | Watch-outs |
|
||||
|------|------|----------|------------|
|
||||
| **Raw Canvas / WebGL** | 2D/low-level | Tiny games, learning, no framework tax | You own everything |
|
||||
| **Kaplay** (ex-Kaboom) | 2D toolkit | Fast prototypes, jam games | Less “full product” structure than Phaser |
|
||||
| **Phaser 4** | 2D engine | Complete 2D features | Heavier; often bundled |
|
||||
| **PixiJS 8** | 2D renderer | Performance, custom game code | Not a full gameplay framework alone |
|
||||
| **Three.js** | 3D renderer | Visuals, lightweight 3D | You add gameplay systems |
|
||||
| **Babylon.js** | 3D engine | Fuller 3D + XR | Heavier than Three for simple scenes |
|
||||
| **Ink + inkjs** | Narrative | Complex branching prose | Weak for real-time multi-entity sims |
|
||||
| **Twine / Twison / TweeJS** | Narrative | Educator-friendly branches | Export/host glue; not a physics engine |
|
||||
| **Godot 4** | Full engine | 2D/3D indie, open source | Web export iteration cost |
|
||||
| **Unity** | Full engine | Large teams, multi-platform | Heavy for simple web UI games |
|
||||
|
||||
Editor-first web shells (**Construct**, **GDevelop**) fit visual prototyping; weaker when you need versioned code-first content pipelines.
|
||||
|
||||
---
|
||||
|
||||
## Non-web defaults (see also platform skills)
|
||||
|
||||
| Target | Lean toward |
|
||||
|--------|-------------|
|
||||
| PC indie / open source | Godot 4 |
|
||||
| PC large team / multi-platform | Unity |
|
||||
| Mobile | See `game-development/mobile-games` (touch, stores, battery) |
|
||||
| VR/AR | See `game-development/vr-ar` (+ Babylon/Three on web) |
|
||||
|
||||
---
|
||||
|
||||
## Anti-patterns
|
||||
|
||||
| Don't | Do |
|
||||
|-------|-----|
|
||||
| Choose Unity/Godot for a form-heavy browser tool | Prefer DOM/hybrid |
|
||||
| Force Ink to run real-time concurrent simulations | Use narrative tools for branches; custom/sim code for clocks & entities |
|
||||
| Use Phaser as “the whole app” when the surrounding UI is HTML | Prefer a hybrid guest viewport |
|
||||
| Optimize for WebGPU on day one | Ship WebGL; add WebGPU + fallback when needed |
|
||||
|
||||
## When to Use
|
||||
|
||||
Use when choosing or comparing game engines/frameworks before implementation, especially for hybrid DOM+canvas or narrative-first products.
|
||||
|
||||
## Limitations
|
||||
|
||||
- Does not replace platform skills (`game-development/web-games`, `game-development/pc-games`, …).
|
||||
- Final choice still depends on team skill and shipping constraints.
|
||||
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
|
||||
+47
-45
@@ -1,6 +1,10 @@
|
||||
---
|
||||
name: web-games
|
||||
description: "Web browser game development principles. Framework selection, WebGPU, optimization, PWA."
|
||||
description: >-
|
||||
Web browser game development. Framework selection (Phaser, PixiJS, Kaplay,
|
||||
Canvas/WebGL, Three.js, Babylon.js), hybrid DOM+canvas, WebGPU, optimization,
|
||||
PWA, audio unlock. Use when building HTML5/WebGL/WebGPU games or choosing a
|
||||
browser runtime.
|
||||
risk: unknown
|
||||
source: community
|
||||
date_added: "2026-02-27"
|
||||
@@ -8,7 +12,7 @@ date_added: "2026-02-27"
|
||||
|
||||
# Web Browser Game Development
|
||||
|
||||
> Framework selection and browser-specific principles.
|
||||
> Framework selection and browser-specific principles. For stack choice details see `game-development/engine-selection`.
|
||||
|
||||
---
|
||||
|
||||
@@ -20,25 +24,43 @@ date_added: "2026-02-27"
|
||||
What type of game?
|
||||
│
|
||||
├── 2D Game
|
||||
│ ├── Full game engine features? → Phaser
|
||||
│ └── Raw rendering power? → PixiJS
|
||||
│ ├── Full game engine features? → Phaser 4
|
||||
│ ├── Fast prototype / jam? → Kaplay
|
||||
│ ├── Raw rendering power? → PixiJS 8
|
||||
│ └── Tiny / no dependency? → Raw Canvas / WebGL
|
||||
│
|
||||
├── 3D Game
|
||||
│ ├── Full engine (physics, XR)? → Babylon.js
|
||||
│ └── Rendering focused? → Three.js
|
||||
│ └── Rendering focused? → Three.js
|
||||
│
|
||||
└── Hybrid / Canvas
|
||||
└── Custom → Raw Canvas/WebGL
|
||||
├── Hybrid (DOM UI + canvas moments)
|
||||
│ └── Custom shell + guest viewport
|
||||
│ (Canvas/Kaplay/Phaser/Pixi inside a region/modal)
|
||||
│
|
||||
└── Narrative-first
|
||||
└── Ink (inkjs) or Twine export + DOM host
|
||||
```
|
||||
|
||||
### Comparison (2025)
|
||||
### Comparison
|
||||
|
||||
| Framework | Type | Best For |
|
||||
|-----------|------|----------|
|
||||
| **Phaser 4** | 2D | Full game features |
|
||||
| **PixiJS 8** | 2D | Rendering, UI |
|
||||
| **Three.js** | 3D | Visualizations, lightweight |
|
||||
| **Babylon.js 7** | 3D | Full engine, XR |
|
||||
| **Raw Canvas / WebGL** | 2D / low-level | Small scope, full control |
|
||||
| **Kaplay** | 2D toolkit | Rapid prototypes |
|
||||
| **Phaser 4** | 2D engine | Full game features |
|
||||
| **PixiJS 8** | 2D renderer | Rendering, custom systems |
|
||||
| **Three.js** | 3D renderer | Visualizations, lightweight 3D |
|
||||
| **Babylon.js** | 3D engine | Full engine, XR |
|
||||
|
||||
### Hybrid shell + guest
|
||||
|
||||
Use when chrome is HTML (menus, inventories, text, dashboards) but bursts of play need a canvas:
|
||||
|
||||
1. Mount guest in a container; pass context in.
|
||||
2. Run a **local** game loop in the guest.
|
||||
3. Return results (score, pass/fail); **destroy** guest (RAF, listeners, GL context as needed).
|
||||
|
||||
Do not let the guest own global app routing unless the product *is* a full-screen game.
|
||||
|
||||
---
|
||||
|
||||
@@ -56,8 +78,8 @@ What type of game?
|
||||
|
||||
### Decision
|
||||
|
||||
- **New projects**: Use WebGPU with WebGL fallback
|
||||
- **Legacy support**: Start with WebGL
|
||||
- **New GPU-heavy projects**: Use WebGPU with WebGL fallback
|
||||
- **Broad legacy / simple 2D**: Start with WebGL or Canvas 2D
|
||||
- **Feature detection**: Check `navigator.gpu`
|
||||
|
||||
---
|
||||
@@ -69,7 +91,7 @@ What type of game?
|
||||
| Constraint | Strategy |
|
||||
|------------|----------|
|
||||
| No local file access | Asset bundling, CDN |
|
||||
| Tab throttling | Pause when hidden |
|
||||
| Tab throttling | Pause when hidden (`visibilitychange`) |
|
||||
| Mobile data limits | Compress assets |
|
||||
| Audio autoplay | Require user interaction |
|
||||
|
||||
@@ -85,16 +107,12 @@ What type of game?
|
||||
|
||||
## 4. Asset Strategy
|
||||
|
||||
### Compression Formats
|
||||
|
||||
| Type | Format |
|
||||
|------|--------|
|
||||
| Textures | KTX2 + Basis Universal |
|
||||
| Textures | KTX2 + Basis Universal (or WebP/PNG for simple 2D) |
|
||||
| Audio | WebM/Opus (fallback: MP3) |
|
||||
| 3D Models | glTF + Draco/Meshopt |
|
||||
|
||||
### Loading Strategy
|
||||
|
||||
| Phase | Load |
|
||||
|-------|------|
|
||||
| Startup | Core assets, <2MB |
|
||||
@@ -105,35 +123,16 @@ What type of game?
|
||||
|
||||
## 5. PWA for Games
|
||||
|
||||
### Benefits
|
||||
|
||||
- Offline play
|
||||
- Install to home screen
|
||||
- Full screen mode
|
||||
- Push notifications
|
||||
|
||||
### Requirements
|
||||
|
||||
- Service worker for caching
|
||||
- Web app manifest
|
||||
- HTTPS
|
||||
**Benefits:** offline play, install, fullscreen, optional push.
|
||||
**Requirements:** service worker, web app manifest, HTTPS.
|
||||
|
||||
---
|
||||
|
||||
## 6. Audio Handling
|
||||
|
||||
### Browser Requirements
|
||||
|
||||
- Audio context requires user interaction
|
||||
- Create AudioContext on first click/tap
|
||||
- Resume context if suspended
|
||||
|
||||
### Best Practices
|
||||
|
||||
- Use Web Audio API
|
||||
- Pool audio sources
|
||||
- Preload common sounds
|
||||
- Compress with WebM/Opus
|
||||
- Create/resume `AudioContext` on first click/tap
|
||||
- Prefer Web Audio API; pool sources; preload common SFX
|
||||
- Compress with WebM/Opus when possible
|
||||
|
||||
---
|
||||
|
||||
@@ -146,15 +145,18 @@ What type of game?
|
||||
| Block on audio load | Lazy load audio |
|
||||
| Skip compression | Compress everything |
|
||||
| Assume fast connection | Handle slow networks |
|
||||
| Leave canvas engines running off-screen | Tear down guests |
|
||||
|
||||
---
|
||||
|
||||
> **Remember:** Browser is the most accessible platform. Respect its constraints.
|
||||
|
||||
## When to Use
|
||||
This skill is applicable to execute the workflow or actions described in the overview.
|
||||
|
||||
Use when building HTML5/WebGL/WebGPU games, choosing a browser runtime, or wiring hybrid DOM+canvas guests.
|
||||
|
||||
## Limitations
|
||||
|
||||
- Use this skill only when the task clearly matches the scope described above.
|
||||
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
|
||||
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
|
||||
|
||||
Reference in New Issue
Block a user