IDEA — 三公遊戲（Sam Gong 3-Card Poker）即時多人線上平台

<!-- SDLC Requirements Engineering — Layer 0：Idea Capture -->

<!-- 由 /devsop-idea 自動填寫；未來需求變更時，此文件作為「原始意圖」比對基準 -->

Document Control

1. Idea Essence（核心本質）

1.1 一句話描述（Elevator Pitch）

三公 Online 幫助華人休閒撲克玩家解決「擔心既有三公 App 作弊/不公平」的痛點，方式是以 Server-authoritative 架構（Cocos Creator Client + Colyseus Server）打造一款跨平台即時多人三公遊戲。

1.2 核心假說（Lean Hypothesis）

If we build 一款 Server-authoritative、伺服器完全掌控洗牌/發牌/比牌/結算的即時多人三公遊戲，搭配像素/賭場風格專業 UI,

then 華人 25-55 歲休閒撲克玩家

will 選擇本產品作為主要三公娛樂平台並願意購買虛擬籌碼,

which will lead to Peak CCU ≥ 500、付費率 ≥ 3%、並建立可複製至其他撲克品類的 authoritative server 基礎能力.

1.3 成功願景（Success Vision）

12 個月後，若本專案成功，以下情境將成真：

• 用戶維度：華人三公玩家社群口碑推薦「最公平的三公 App」，7 日留存 ≥ 35%，公平性 NPS ≥ 70。
• 業務維度：DAU ≥ 2,000、Peak CCU ≥ 500、ARPPU ≥ USD 10，年收益達 NT$ 800 萬以上。
• 技術維度：Cocos + Colyseus 技術棧沉澱為公司 multiplayer 基礎能力，可於 3 個月內複製至其他撲克品類（大老二、21 點）。

1.4 Innovation Type Classification（創新類型分類）

本 IDEA 的分類：Sustaining（持續性創新）

分類依據：既有華人三公 App 市場已存在，但品質良莠不齊。本產品在相同市場中以「Server-authoritative 公平性 + 專業美術 + 跨平台」差異化競爭，屬於「更好的解法」而非創造新市場。資源投入策略走「快速 ROI + 精準行銷」路徑。

2. Problem Statement（問題陳述）

2.1 現狀描述（As-Is Narrative）

華人玩家（35-55 歲為主力）熱愛傳統三公遊戲，目前仰賴三條路徑滿足需求：（1）線下實體聚會，受空間時間限制；（2）Google Play / App Store 上數十款既有三公 App，但多為 Client-side 計算、美術粗糙、公平性不透明；（3）通訊軟體自建群組配合線下籌碼，門檻高且易生糾紛。玩家對「可信、即時、跨平台、美術精緻」的三公多人遊戲有強烈未被滿足需求。

2.2 根本原因分析（5 Whys）

問題現象：玩家擔心既有三公 App 作弊或發牌不公平
  Why 1：既有 App 多為 Client-side 計算或 P2P 架構
    Why 2：開發團隊多為小團隊/個人，缺乏後端 authoritative server 能力
      Why 3：authoritative server 需要專業後端框架與持續維運成本
        Why 4：過去幾年 authoritative 多人框架（如 Colyseus）成熟度不足且學習曲線陡
          Why 5（根本原因）：缺乏「易用、成熟、支援 Cocos Creator」的 authoritative server 生態，使小團隊無法負擔此類產品開發

2.3 問題規模（量化估算）

3. Target Users（目標使用者）

3.1 主要使用者群（Q1 澄清結果）

使用者描述：華人休閒撲克遊戲玩家（主群 35-55 歲；次群 25-34 歲上班族；海外華人社群）

3.2 Jobs to Be Done（用戶核心任務）

3.3 非目標使用者（Not Our Users）

4. Value Hypothesis（價值假說）

4.1 核心價值主張（Value Proposition Canvas）

Pain Relievers（痛點緩解）：

Gain Creators（增益創造）：

4.2 差異化定位

相對既有三公 App（Client-side 計算、美術粗糙、P2P 連線）與國際撲克品牌（德撲為主、非華人原生），本產品的獨特差異是華人市場首款 Server-authoritative 的三公專業級多人遊戲，以公平性為核心賣點，搭配華人市場原生玩法與本土化美術風格。

5. MVP & Learning Plan（最小可行驗證計畫）

5.1 MVP 邊界定義

明確不在 MVP 範圍（Non-MVP）：

• ❌ 虛擬籌碼 IAP 購買（推遲至 Launch + 3M，優先驗證留存）
• ❌ VIP 訂閱（推遲至 Launch + 6M）
• ❌ 多語系（首版僅繁中）
• ❌ 其他撲克品類（v2 規劃）
• ❌ 觀戰模式（v1.1 視用戶需求評估）

5.2 Validation Metrics（驗證指標，Pre-BRD 階段）

驗證計畫時程：

Week 1-2：法律意見書 + 技術 PoC 啟動
Week 2-3：使用者訪談（N ≥ 10）+ 付費意願調查
Week 3：Go/Kill/Pivot 決策
Week 4+：進入 PRD / EDD 階段

5.3 Riskiest Assumption（最高風險假設，Leap of Faith）

以下假設一旦被推翻，整個 IDEA 必須根本性調整或放棄。

我們假設 以「虛擬籌碼不可兌換娛樂產品」形式運營的三公遊戲在台灣法律框架下可合法上架並持續運營。

若此假設為假，則 整個商業模式不成立，專案應 停止或根本性調整（如改為純休閒益智遊戲去除籌碼元素）。

我們將透過 正式法律意見書 + 向平台（Google/Apple）預審 在 BRD 核准前 4 週 驗證此假設。

6. Clarification Interview Record（澄清訪談記錄）

本節記錄 /devsop-idea Step 2 的完整結果。本次採「AI 自動填入」模式，未執行互動式提問；以下所有欄位為 AI 根據使用者草稿原文推斷。

Q1 — 主要使用者

Q2 — 核心痛點

Q3 — 技術限制或偏好

Q4 — 預期使用規模

Q5 — 其他補充說明（動態追問）

原始 IDEA（使用者輸入原文，逐字保留）

三公遊戲（Cocos + Colyseus）開發草稿

一、專案目標
打造一款即時多人三公（3-card poker / Sam Gong）遊戲，採用：
Client（Cocos Creator）：負責 UI、動畫、玩家操作
Server（Colyseus / Node.js）：負責遊戲邏輯、狀態同步（authoritative）
核心原則：
🎯 Server authoritative，Client 只做展示與輸入

二、核心玩法（簡述）
每位玩家發 3 張牌
根據三公規則比大小（點數 / 公牌）
支援下注（betting）
最終結算輸贏
（規則細節可後補或做成 config）

三、系統架構
1️⃣ Client（Cocos）
負責：
- UI（桌面、玩家位置、籌碼）
- 動畫（發牌動畫、翻牌動畫、結算動畫）
- 要有豐富UI設計互動，主角，布景相關，要有專業UI/UX設計，像素風格，CASINO 21點風格都可以
- 玩家操作（下注、比牌、準備）
- 狀態呈現（從 server sync）
👉 不做任何結果計算（避免作弊）

2️⃣ Server（Colyseus）
負責：
- 洗牌（shuffle）
- 發牌（deal）
- 比牌（compare）
- 結算（settlement）
- 遊戲流程控制（state machine）
- 玩家狀態同步（room state）

保留原文供未來 ECR（Engineering Change Request）審查時比對，確認需求變更屬 BUG 修正還是範圍擴充。

7. Market & Competitive Intelligence（市場與競品情報）

7.1 競品 / 參考資源

7.2 技術生態建議

7.3 研究來源

8. Initial Risk Assessment（初始風險評估）

8.1 風險矩陣

8.2 Kill Conditions（專案終止條件）

8.3 Pre-mortem Exercise（失敗前情境模擬）

想象 12 個月後，這個專案已徹底失敗。最可能的失敗原因：

Pre-mortem 結論： 最可能的失敗路徑是 F1（法規風險），需在 BRD 階段優先設計合規邊界與律師意見書；次要風險是 F4（作弊），需在 EDD 階段納入反作弊設計。

9. Business Potential（初步商業潛力）

9.1 商業模式假說

9.2 戰略對齊

10. Executive Sponsorship & Stakeholder Alignment

10.1 Executive Sponsor

10.2 Stakeholder Pre-alignment Matrix

10.3 Communication Plan

11. IDEA Quality Score（構想品質評分）

整體評分：★★★☆☆（3/5）

【IDEA 品質評分】★★★☆☆（3/5）
  + 目標清晰：✅ Server-authoritative 三公多人遊戲
  + 可行性：✅ 技術棧成熟（Cocos + Colyseus 官方整合）
  △ 使用者具體度：AI 推斷華人市場，需訪談確認
  △ 範圍邊界：AI 已補齊 Out of Scope，建議 PRD 階段細化
  - 痛點量化：草稿聚焦技術而非玩家行為，建議訪談量化

12. Critical Assumptions（關鍵假設清單）

13. Open Questions（待解問題）

14. IDEA → BRD Handoff Checklist

15. Traceability Note（溯源說明）

此文件是需求鏈的起點，扮演「原始意圖記錄者」的角色。

向下追溯（Forward）：

IDEA.md （本文件）
  └─► BRD.md       ← /devsop-idea 已自動生成
        └─► PRD.md      ← /devsop-gen-prd 待生成
              └─► PDD.md      ← /devsop-gen-pdd
                    └─► EDD.md      ← /devsop-gen-edd
                          └─► ARCH / API / SCHEMA / BDD → 實作

需求變更判斷準則：

Appendix A：Research Raw Data（研究原始資料）

搜尋 1：競品與開源專案

查詢：sam gong 3-card poker 三公 multiplayer card game colyseus open source github
結果摘要：
- 無 Sam Gong / 三公 專屬的 Colyseus 開源實作
- sominator/colyseus-2d-multiplayer-card-game-templates：4 引擎卡牌模板
- Ronan-H/riffle：Angular + Colyseus Web 卡牌
- Colyseus 官方 UNO 範例
- Colyseus Cocos Creator 官方 SDK 已就緒
結論：有成熟 framework 與參考實作，但無 Sam Gong 專屬範本，需自行實作

搜尋 2：技術最佳實踐

查詢：Colyseus Cocos Creator multiplayer card game server authoritative state sync best practices 2026
結果摘要：
- Colyseus 使用 Schema-based state sync，Server 負責 mutate，Client 訂閱變更
- Best practice：Schema class 僅含欄位定義；遊戲邏輯走 Command Pattern，獨立於 Schema
- patchRate 優化：Colyseus 追蹤 property-level 變動，只發送最新值降低頻寬
- Cocos Creator SDK 使用方式與 JS/TS SDK 一致
- Colyseus UNO 範例為 turn-based 卡牌官方實作參考
結論：架構路線清楚，Command Pattern 管遊戲流程，Schema 管同步

搜尋 3：合規與反作弊

查詢：online multiplayer card game anti-cheat server authoritative pitfalls gambling regulation Taiwan
結果摘要：
- 台灣《刑法》第 266 條：凡以財物或可兌換財物之物為賭注即違法
- 《詐欺犯罪危害防制條例》明確將線上遊戲經營者納入規管，罰鍰 NT$10 萬-200 萬
- 數位部為主管機關，須配合身份驗證、可疑交易通報
- 反作弊：Server-authoritative 為基本功，但 Client 仍可能有自動化外掛
- 研究：SecureTCG（P2P 卡牌反作弊協定）可參考思路
結論：法規風險為最高風險；技術上 Server-authoritative 足以擋 Client 直接作弊，但需補強行為分析

Appendix B：Document History

Appendix C：Attached Materials（附件與素材）

以下素材由使用者於 /devsop-idea 呼叫時提供，已自動存入 docs/req/ 目錄。

（目前無附件。若後續需補充素材——例如三公詳細規則文件、美術風格參考圖、競品截圖——請將檔案複製至 docs/req/ 目錄，更新此清單後，gen-* skills 即可自動讀取。）

此 IDEA.md 由 /devsop-idea 自動保留，記錄需求探索過程中的所有原始輸入與假設。

若未來需求發生變化，可對照此文件確認原始意圖，判斷屬 BUG 修正或 ECR（需求變更）。