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

<!-- SDLC Requirements Engineering — Layer 1：Business Requirements -->

Document Control

Change Log

§0 背景研究（/devsop-idea 自動蒐集）

競品/參考資源

• colyseus-2d-multiplayer-card-game-templates（GitHub，sominator）：Unity / Phaser / Defold / Godot 四種 2D 卡牌模板，使用 Colyseus 作為 Server backend。可直接參考其 room state 設計。
• Colyseus 官方 UNO 範例：Turn-based 卡牌遊戲官方範例，完整展示 Schema-based state sync 與 Command Pattern。
• Riffle（GitHub，Ronan-H）：Angular + Colyseus 的 Web 卡牌遊戲，展示 Web client 與 Colyseus 整合實務。
• Colyseus Cocos Creator SDK（官方）：Colyseus 已提供 Cocos Creator 官方 SDK，使用方式與 JavaScript/TypeScript SDK 一致。
• 既有三公遊戲：多為單機版、地區性娛樂 App（如各類「三公」關鍵字 Google Play App），但普遍欠缺專業 UI/UX、無 Server-authoritative 架構保證公平性。

技術建議

• Client：Cocos Creator 3.x（Web + 手機跨平台），TypeScript 開發。
• Server：Colyseus 0.15.x（locked）（Node.js/TypeScript），@colyseus/schema 做狀態同步。
• 架構原則：Server-authoritative — Schema 類別僅含欄位定義，遊戲邏輯獨立於 State，使用 Command Pattern 管理回合流程。
• 持久層：PostgreSQL（玩家資料、牌局紀錄）+ Redis（matchmaking queue、session cache）。
• 部署：Colyseus Cloud 或自建 k8s【Q5 待決，截止 2026-05-15，見§14】；Client 走 WebSocket + TLS。

已知風險

• R-Legal（台灣法規）：三公屬「博弈」性質遊戲。依我國《刑法》第 266 條與最高法院判例，凡以「財物或可兌換財物之物」為賭注即違法。本產品必須採「虛擬籌碼、不可兌換、不可購買」模式以規避賭博罪嫌疑。《詐欺犯罪危害防制條例》亦將線上遊戲經營者納入規管，須遵守身份驗證、可疑交易通報等義務。
• R-Cheat：卡牌遊戲最大技術風險為作弊（偷看牌、結果預測、外掛注入）。Server-authoritative 是基本功，但 Client 端仍可能有自動下注/讀秒外掛，須配合行為分析與伺服器速率限制。
• R-Scale：Colyseus 單實例約支援 1,000-3,000 同時連線；若目標規模 >10,000，需提早規劃 horizontal scaling（@colyseus/redis-presence + matchmaker driver）。
• R-UX：賭場風格 + 像素美術在跨平台（手機小螢幕）易顯擁擠；UI 需響應式設計並考慮大螢幕／小螢幕不同 layout。

1. Executive Summary（PR-FAQ 風格）

1.1 假設新聞稿

標題： Sayyo Games 推出「三公 Online」，打造華人市場首款 Server-Authoritative 公平三公即時多人遊戲

>

第一段（What & Who）： Sayyo Games 今日推出「三公 Online」，一款主打「絕對公平」的即時多人三公遊戲。玩家可跨手機與網頁加入房間，與真人對戰，享受復古像素風賭場氛圍，所有牌局計算由伺服器權威判定，杜絕任何作弊可能。

>

第二段（Why Now）： 市面既有三公遊戲多為單機 App 或 P2P 連線，玩家普遍擔心對手作弊或伺服器灌水；同時現代華人玩家在手機與網頁間頻繁切換，需要跨平台即時對戰體驗。Colyseus 等 authoritative 框架成熟、Cocos Creator 跨平台能力完整，讓我們得以用小團隊在 4 個月內交付專業級多人遊戲。

>

第三段（How It Works）： （1）進入大廳，選擇籌碼級距或快速配對；（2）房間開局後，伺服器洗牌、發牌，Client 僅呈現動畫；（3）玩家下注、比牌、結算，所有計算在 Server 完成，玩家獲得無作弊疑慮的公平體驗。

>

用戶引言： 「以前玩三公 App 最怕對手作弊或 App 發牌不公平。這款每一張牌、每一次比較都由伺服器決定，終於能安心玩了。」— 張先生，45 歲，華人社群三公老玩家。

1.2 FAQ（預先回答最困難的問題）

2. Problem Statement

2.1 現狀描述

華人玩家（特別是 35-55 歲年齡層）對三公這類傳統撲克遊戲有強烈懷舊需求，目前主要透過：

• 線下實體聚會（受空間與時間限制）；
• 既有手機三公 App（Google Play / App Store 可搜到數十款，但多為單機對 AI、或 P2P 連線，美術簡陋、公平性不透明）；
• 通訊軟體自建群組配合線下籌碼（門檻高、易生糾紛）。

共通痛點：缺乏「可信、即時、跨平台、美術精緻」的三公多人遊戲。

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 問題規模（量化）

【F11 重要聲明】 下表所有財務預測數字均基於 AI 推斷假設，非來自可信第三方市場研究報告。數字僅供內部方向性參考，不得作為投資決策或財務承諾依據。驗證期限：假設 A1（付費/留存偏好）需於封測前驗證；假設 A5（付費率 3%）需於 Launch+3M 前以同類 App Benchmark 驗證（見 §8.2）。

3. Business Objectives

3.1 商業目標

核心目標宣言（F1）： 至 2026-08-21（BRD核准日2026-04-21起4個月）上線一款 Server-authoritative 即時多人三公遊戲，以「絕對公平」為差異化核心，於 Launch+6M 達成 Peak CCU ≥ 500、DAU ≥ 2,000、於 Launch+3M 達成公平性 NPS ≥ 70，並於 Launch+9M 建立合規虛擬籌碼變現模式，付費率 ≥ 3%，奠定 Sayyo Games 華人休閒遊戲平台基礎。

3.2 與公司策略的對應

3.3 投資報酬分析（3 情境）

【免責聲明】 本表收益預測均為 AI 推斷假設，非來自可信第三方市場研究（詳見§2.3 免責聲明）。不得作為投資決策或財務承諾依據。建議 Launch+3M 後以實際數據更新。

3.4 Requirements Traceability Matrix（需求追溯矩陣，RTM）

3.5 Benefits Realization Plan（效益實現計畫）

4. Stakeholders & Users

4.1 Target Users

4.2 Not Our Users

• ❌ 未成年玩家（18 歲以下）：法規與道德考量，必須有年齡驗證閘門。
• ❌ 尋求真實金錢賭博的玩家：本產品僅提供虛擬籌碼，不可兌換實體金錢。
• ❌ 國際市場非華人用戶：首發聚焦繁體中文市場，英文/其他語系為未來擴展。

4.3 Stakeholder Map

4.4 RACI Matrix

5. Proposed Solution

5.1 解法概述

打造一款 Server-authoritative 即時多人三公遊戲，Client 端以 Cocos Creator 負責 UI/動畫/輸入，Server 端以 Colyseus（Node.js/TypeScript） 負責所有遊戲邏輯。

【F12 美術策略決策】 v1.0 以像素風為主要美術風格（完整實作所有畫面）。賭場風格僅製作 2-3 個關鍵畫面的 A/B 測試素材（大廳主頁、牌局主畫面、結算畫面），供 Beta 封測期間進行用戶測試。2026-07-21（GA-1M）前由 PM + Art Director 依測試數據做出最終美術方向決策，決策結果記入 Decision Log（D7）。若決策未能於 Beta 前完成，預設維持像素風為正式版風格。

5.2 核心價值主張

Customer Jobs（用戶要完成的任務）：

• Functional：與真人玩一場公平、流暢、跨平台的三公牌局。
• Emotional：懷舊感、賭場刺激感、贏牌成就感、社交歸屬感。
• Social：與朋友組桌、炫耀手氣、累積牌技聲望。

Pain Relievers：

• Server-authoritative 架構，杜絕 Client 作弊疑慮。
• 跨平台（Web + Android + iOS）即時連線，不分裝置自由加入。
• 專業像素/賭場美術，提升質感。

Gain Creators：

• 虛擬籌碼等級（青銅→鑽石）累積，產生進度感。
• 每日任務、排行榜、好友組桌，強化社交。
• 新手引導教學，降低老玩家以外的進入門檻。

5.3 解法邊界與 MoSCoW

In Scope（本版本 MVP）：

★ 虛擬籌碼每日贈送腳注： PRD已升級為Must Have；升級決策記入D14。

Out of Scope（明確排除）：

• ❌ 真實金錢下注（法規風險）。
• ❌ 虛擬籌碼兌換現實財物（法規風險）。
• ❌ 未成年用戶（必須有年齡閘）。
• ❌ 跨區伺服器（首版僅亞太區）。
• ❌ 觀戰模式（Spectator Mode）：v1.0 不實作，避免 Schema 複雜度上升與延遲問題，需求已記錄至 Q6 與 D5，延後至 v1.x 評估。（F4）
• ❌ 【F2條件】IAP 虛擬籌碼購買：是否在 Out of Scope 取決於法律意見書（預計 2026-05-15 完成）。法律意見書完成前，IAP 功能不得進入開發排程；若法務判定有法律風險，IAP 移入 Out of Scope，以 Rewarded Ad 廣告模式替代。

5.4 籌碼經濟設計約束（F10）

房間級距表（Room Tier）

注意（F2）： 房間入場條件（房間級距）與等級門檻（玩家等級）為獨立系統：等級門檻決定徽章/獎勵，房間入場條件決定可進入房間。

中途跌破入場門檻規則：玩家在遊戲過程中籌碼跌破當前房間入場條件時，當局牌局繼續正常進行；當局結算後，若玩家餘額仍低於入場門檻，系統提示「餘額不足本房間入場條件，本局結束後將移至大廳」，並於下一局開始前自動將玩家移出房間至大廳，不影響已在進行的牌局。

籌碼 500-999 邊緣情況：若玩家餘額介於 500-999 籌碼（高於救濟觸發值 <500，但低於最低房間入場門檻青銅廳 ≥1,000），系統於大廳顯示提示：『您的籌碼不足進入任何房間，請完成每日任務或等待每日免費籌碼（每日 00:00 UTC+8 重置）』；不觸發救濟機制；玩家可透過完成每日任務（獎勵≥500籌碼）或等待每日免費籌碼（+5,000籌碼）後恢復青銅廳進房資格（entry≥1,000）。

設計原則： 籌碼為純娛樂性虛擬貨幣，不反映任何真實財務價值，不可兌換、不可轉移至其他帳號（好友間籌碼轉移明確禁止）。

5.5 三公規則草案附錄（F3）

【Q2 關閉決策】 採用台灣標準版三公規則，詳見下表。本決策已記入 Decision Log（見 §15 D6）。

莊家（Banker）機制（F2）

玩家操作計時器：每位閒家有 30 秒決定 Call 或 Fold（莊家下注後計時開始）；超時自動視為 Fold，下注額=0，不入底池，無任何籌碼損失；計時器倒數顯示於 Client UI。（30 秒為預設值，PRD 可調整；記入 Decision Log D11。）

斷線期間計時器行為：玩家斷線時，其操作計時器繼續倒數（不暫停）；若30秒內重連，顯示剩餘時間，玩家可繼續操作；若剩餘時間已歸零，系統已自動視為Fold，重連後玩家可觀看當局結果但無法再操作。

牌局流程（Server 執行順序）

1. Server 洗牌（費雪-葉茨演算法）→ 發牌（每人 3 張暗牌）
2. 莊家查看手牌 → 下注底注（≥ 本廳最低下注額，≤ 當局最高限注；依房間tier動態決定，見§5.4房間級距表）；莊家操作計時器：莊家有 30 秒完成底注下注；超時後系統自動以本廳最低下注額代為下注並進入Step 3。（規則與閒家計時器一致；記入 Decision Log D12）
3. 閒家依順時鐘順序逐一決定 Call（跟注，下注與莊家等額）或 Fold（棄牌）；每人 30 秒計時
4. 所有未 Fold 玩家翻牌；Fold 玩家手牌於結算時保持暗牌狀態（不公開，v1.0規則）；結算動畫僅顯示未Fold玩家的手牌比較過程。
5. Server 比牌（依 §5.5 比牌規則）→ 計算結算金額
6. 結算與籌碼分配（三步驟）：

• Step 6a（確認結果與底池）：Server 確認每位閒家的比牌結果；莊家獲勝之閒家下注額歸入底池；棄牌（Fold）閒家下注額=0，不下注，不入底池；莊家敗之閒家下注額不入底池（由莊家直接支付本金 1× + 賠率 N×）。
• Step 6b（抽水）：從底池（輸家閒家下注額加總）扣除 5% 抽水（floor 取整，最少 1 籌碼）；抽水進入遊戲維運基金。空底池守衛：若底池（輸家閒家下注額加總）= 0（即全部閒家均勝、全員棄牌、或勝者與棄牌者合計無任何輸家），則抽水=0；最少1籌碼條款不適用，與PRD §5.3 Step 6b空底池守衛一致。
• Step 6c（分配）：閒家勝時，莊家直接支付給該閒家：本金（1× 下注額，不經底池）+ N× 下注額賠率；合計閒家總取回 = (1+N)× 下注額，淨利潤 = N× 下注額。莊家勝時，底池中閒家下注額（扣 5% 抽水後）歸莊家。抽水僅從莊家獲勝收取的閒家下注額中扣除；閒家勝時的本金與賠率由莊家全額支付，不受抽水影響。結算完成後 Server 廣播最終狀態至所有 Client。

基礎規則

公牌規則（F3 明確決定）

賠率表（台灣標準版）

賠率計算語義（Payout Semantics）：

• 閒家勝時：閒家本金（1×下注額）由莊家直接歸還（不經底池），另外由莊家額外支付對應倍數賠率（N×）；總取回 = (1+N)× 下注額。
• 例：閒家下注 1,000 籌碼、三公勝（1:3）→ 取回 1,000（本金，莊家直接歸還）+ 3,000（莊家賠付）= 共 4,000 籌碼；淨利潤 +3,000。
• 莊家勝時：閒家下注額全額歸底池，莊家從底池獲得（扣抽水後）。
• 抽水：僅從莊家獲勝所得的閒家下注額加總（輸家下注額）× 5%，floor取整，結算前扣除；閒家獲勝局的本金與賠率由莊家全額支付，不受抽水影響。
• 【抽水說明】：抽水僅從「莊家獲勝局的閒家下注額」中扣除，閒家獲勝局的本金與賠率不含抽水（由莊家全額支付）。

【F2 全閒家棄牌特殊情境】 全閒家棄牌時：底池=0，抽水=0，莊家底注退回（莊家籌碼淨變動=0）。

結算方向（雙向）：莊家與每位未 Fold 閒家進行獨立比牌結算。閒家勝→莊家直接從自身籌碼支付（1+N）×下注額給該閒家（本金與賠率均不經底池）；閒家敗→閒家下注額歸入底池。閒家下注額構成底池（莊家本金不入底池）；閒家勝時，莊家直接從自身籌碼支付（1+N）×下注額；閒家敗時，閒家下注額入底池；結算後從底池（輸家下注額合計）扣除5%抽水（floor取整，最少1籌碼），剩餘歸莊家。輸家閒家下注額構成底池（贏家閒家本金由莊家直接返還，不入底池）。

混合結果結算順序（莊家同局有贏有輸時）：Server 採原子性三步驟：(1) 確認每位閒家的本局比牌結果（贏/輸/Fold）；莊家敗的閒家下注額由莊家從自身籌碼支付（本金+賠率）；莊家勝的閒家下注額歸入底池；(2) 從底池（輸家閒家下注額合計）扣除 5% 抽水（floor取整，最少1籌碼）；(3) 依比牌結果依順時鐘順序逐一支付：莊家直接支付給贏家閒家：本金（1×下注額）+ N×賠率；輸家閒家不取回；莊家最終淨增減 = 所有輸家下注總額 – 所有贏家賠率支出 – 抽水（含莊家破產規則 D13）。

莊家結算破產處理：若莊家在結算過程中籌碼不足以支付所有贏家賠率，採用以下規則：(1) 依閒家順時鐘順序逐一結算；(2) 每位贏家依序收取其應得賠率（先到先得）；(3) 莊家籌碼歸零後，後續排隊贏家所得為零（不按比例分配，不取回本金，得零）；(4) 抽水 = floor(破產前已完成結算之輸家閒家下注額加總 × 5%)，最少1籌碼（底池 > 0 時）；未完成結算部分不計入抽水底數；不按比例扣除；(5) 此規則已納入 Decision Log D13。

特殊情況：三公 vs 三公：若莊閒均持三公（Sam Gong，三張牌均為10點牌（10/J/Q/K）），則依 D8 同點比大小規則（第一步比最大單張花色：黑桃>紅心>方塊>梅花；花色亦同則比最大單張點數：K>Q>J>10>9>...>2>A）比較；若兩步皆相同（完全相同花色牌，理論上不可能），則平手退注。（決策見 §15 D10）

注意： 上述賠率為虛擬籌碼計算基準，不涉及任何真實金錢。賠率設計需由 Game Designer 在 PRD 階段進行籌碼平衡模擬驗證，確保長期籌碼總量維持合理。

6. Market & Competitive Analysis

6.1 競品分析

6.2 市場定位（Positioning Map）

          專業級 / 授權級
               │
               │  ○ PokerStars（國際撲克）
               │         ● 三公 Online（目標定位：華人專業三公）
               │
非華人導向 ────┼──────── 華人導向
               │
  ○ Zynga Poker│  ○ 既有三公 App（華人但業餘）
               │
          業餘 / 單機級

定位聲明： 三公 Online 定位為「華人市場首款 Server-Authoritative 專業級三公多人遊戲」，差異化在於公平性保證 + 華人原生玩法 + 專業跨平台美術。

7. Success Metrics

7.1 北極星指標

North Star： 週活躍對戰場次數（Weekly Active Rounds）— 代表真正在玩、回來玩、並且享受對戰的使用者總量。

量化目標（F9）： Launch+6M 目標：週活躍對戰場次 ≥ 50,000 場

7.2 業務指標階層

Outcome：華人三公玩家信任並長期使用「三公 Online」作為主要娛樂平台
  Output：CCU ≥ 500 / DAU ≥ 2,000 / 7日留存 ≥ 35%
  Output：公平性 NPS ≥ 70 / 投訴作弊率 ≤ 0.1%
    Input：每週上線場次 / 籌碼商店轉換率 / 新手引導完成率

【F8】付費率定義： 付費率 = 當月有IAP消費唯一帳號數 / 當月MAU × 100%。分母為當月登入至少1次之唯一帳號數（MAU），分子為同月內完成至少1筆IAP交易之唯一帳號數。

7.3 投資門檻（Go / No-Go 條件）

8. Constraints & Assumptions

8.1 業務限制

8.2 關鍵假設（需驗證）

8.3 非功能需求（NFR）（F6）

9. Regulatory & Compliance Requirements

9.0 Web 平台 Cookie 同意需求（F23）

【F23】 Web 平台首次載入時顯示 Cookie 同意橫幅，符合個資法告知義務。若有歐盟用戶，需符合 GDPR ePrivacy 指令之明確 opt-in 同意（不得預設勾選）。Cookie 分類至少包含：必要性 Cookie（不可拒絕）、分析性 Cookie（可選拒絕）、行銷性 Cookie（可選拒絕）。同意紀錄需記錄時間戳與版本號，保留 3 年。

歐盟用戶觸發條件（F17）： 以IP地理位置偵測（CloudFlare CF-IPCountry header或MaxMind GeoIP DB）；若用戶IP所屬國家為歐盟成員國，強制顯示GDPR opt-in同意流程（明確opt-in，非pre-checked）。

9.1 適用法規

9.2 合規影響評估

9.3 合規時程里程碑

9.4 合規責任矩陣（F14）

9.5 Data Governance & Lifecycle Management

資料主權： 首版資料存於台灣 / 日本 AWS 區域；若歐盟用戶介入，啟動 GDPR SCCs。

9.6 Intellectual Property & Licensing

10. Risk Assessment

11. Business Model

11.1 商業模式畫布

11.2 商業模式假設驗證

12. High-Level Roadmap

timeline
    title 三公 Online 高層次里程碑
    section Discovery（2026-04-21起–1個月）
        Week 1-2 : BRD + PRD 核准
        Week 3-4 : EDD / ARCH / Cocos+Colyseus PoC
    section Build（1–3個月）
        Month 2 : Alpha（核心玩法 + Server 邏輯）
        Month 3 : 美術/動畫完整 + 帳號系統
        Month 4 : Beta 封測 100 人
    section Launch（4個月）
        Month 4 末 : GA 上線（繁中 / 台港澳）（2026-08-21）
    section Growth（4–12個月）
        Launch + 3M : 付費系統 + 排行榜（2026-11-21）
        Launch + 6M : 每日任務功能優化與進階版本（v1.0 Should Have基礎功能於GA上線，Launch+6M為完整強化版）、排行榜優化（VIP訂閱列入v1.x計畫，Out of Scope v1.0）（2027-02-21）
        Launch + 12M : 第二品類（大老二或21點）（2027-08-21）

13. Dependencies

13.0 版本鎖定策略（F9）

風險說明（F9）： Colyseus 0.15 → 0.16 有重大 API Breaking Changes（Room lifecycle、Schema 序列化格式均有變動）。版本過於寬鬆（>=0.15）可能導致 npm install 時自動升級，引發線上不相容問題。

13.1 Vendor & Third-Party Dependency Risk Assessment

14. Open Questions

15. Decision Log

16. Glossary

17. References

• 背景研究（/devsop-idea 自動蒐集）：見 §0
• 競品資訊：見 §6
• 使用者原始需求草稿：docs/IDEA.md §6 原文
• Colyseus 官方文件：https://docs.colyseus.io/
• Cocos Creator 官方文件：https://docs.cocos.com/creator/
• 台灣線上遊戲反詐義務：《詐欺犯罪危害防制條例》

18. BRD→PRD Handoff Checklist

18.1 Handoff 前置條件確認

18.2 Handoff 時移交的文件

18.3 PRD Owner 接受確認

19. Organizational Change Management

19.1 變革影響評估

19.2 訓練與溝通計畫

19.3 抗拒緩解策略

19.4 成功衡量（Internal Adoption）

20. Approval Sign-off

此 BRD 由 /devsop-idea 自動生成（v0.1-draft），請執行 /devsop-brd-review 進行正式審查與補齊缺漏。