Skip to content
T1KTheOneKit

game-feedback-mandate-cocos

Game Feedback Mandate — Cocos Creator Mechanics

Section titled “Game Feedback Mandate — Cocos Creator Mechanics”

Engine extension of the designer kit’s rules/game-feedback-mandate.md (theonekit-designer). The parent rule owns the mandate, the five-channel/six-class contract, the timing budget, and the blocking Feedback Matrix gate — this file does not restate any of that. It carries only the two Cocos prohibitions that must fire unsummoned, and the haptic waiver a Cocos Feedback Matrix cannot be filled in without.

The channel → Cocos mechanism table, the engine hazards, and the performance budget are reference material read while implementing a feedback event, not before deciding to: they live in t1k-cocos-playable-juice → references/feedback-channel-mechanisms.md. Load that skill when you fill a Feedback Matrix row (theonekit-cocos#332, core#1203 placement doctrine).

The two prohibitions

Section titled “The two prohibitions”
  • Feedback never runs in a Domain or Application layer. For any feature built as a t1k-game-arch module, those layers are lint-blocked from importing cc.* at all (eslint-plugin-import no-restricted-paths). A use case emits a domain event on the module’s SignalBus; a Presentation-layer cc.Component subscribes and is the ONLY place that drives a motion preset, AudioService.playSFX, or a pooled VFX spawn. Writing feedback into a use case is not a style nit here — it fails CI.
  • Every feedback node is a pool object — never instantiate() per event. vfx bursts, AudioEmitter nodes and Toast popups all fire per-event, so they are exactly the pattern code-quality-cocos.md’s trigger table already makes pooling mandatory for. Route them through ObjectPoolManager, pre-warmed for the worst case, and stop any in-flight tween or emitter before the node is recycled.

Haptics — assume unavailable, and say so in the matrix

Section titled “Haptics — assume unavailable, and say so in the matrix”

This kit has no haptic mechanism at all: no HapticService, no native-bridge call site, no navigator.vibrate wrapper anywhere under .claude/modules/. Its primary target makes that permanent rather than a gap to fill in passing — playable ads run in an in-app webview or mobile browser, where the Vibration API is unsupported outright on iOS Safari/WebKit and gesture-gated elsewhere. Treat haptic as unavailable by default on this target family, not merely degraded.

So a Cocos Feedback Matrix satisfies its haptic-REQUIRED cells (input-ack, invalid-action) by:

  1. Carrying the acknowledgment on a stronger visual beat (an extra shake/flash/scale-punch), the one channel guaranteed to render everywhere.
  2. Marking the haptic cell feedback-waiver: no haptic mechanism in kit; target is H5/web where navigator.vibrate is unsupported (iOS Safari/WebKit) or gesture-gated — the parent rule’s waiver mechanism exists precisely for a documented, honest gap like this. Never silently omit it.
  3. Dropping the waiver and wiring the real channel if the project ships a native build with an actual haptic bridge — that bridge is project-specific integration work, not a kit capability.
Section titled “Related”
  • rules/game-feedback-mandate.md (theonekit-designer) — the parent mandate.
  • t1k-cocos-playable-juice → references/feedback-channel-mechanisms.md — the channel → mechanism table, engine hazards, and performance budget moved out of this rule.
  • code-quality-cocos.md — the mandatory pooling/FSM/SignalBus pattern triggers the second prohibition leans on.
  • game-feedback-mandate-unity.md (theonekit-unity) — the sibling engine extension.