遊戲開發與後端需求教學

一、遊戲分類與後端需求

市面上的遊戲可以粗略分成幾類：

1. 純前端小遊戲

• 例子：Dad N’ Me、無個性戰隊、Dragon Fist 2、拳皇
• 遊戲邏輯全部在客戶端（瀏覽器 / 本機）
• 不需要長期存檔，關掉遊戲就結束
• 完全不需要後端

2. 單機開放世界或大型單機 RPG

• 例子：Skyrim、Zelda、Elden Ring、GTA5 單機模式
• 進度存在本機檔案（Save File 或 Local Storage）
• 不需要 server 也能完整遊玩
• 換裝置需要手動搬檔案，不是後端問題

3. 線上遊戲 / MMORPG / 手機課金遊戲

• 例子：GTA Online、原神、天堂M
• 玩家資料存在 server → 需要後端
• 多人同步、課金系統、防作弊
• 帳號登入是跨裝置進度的手段之一

二、單機 vs 跨裝置 vs 線上遊戲

• 單機開放世界 → 本地存檔即可 → 不需要後端
• 跨裝置 / 雲端存檔 → 需要帳號 / server → 需要後端
• 多人同步 / 課金 → server 掌控世界 → 必須後端

三、遊戲資料庫選擇

存玩家進度的遊戲會用不同資料庫，依規模和需求決定：

1. 傳統 SQL（關聯式）

• MySQL / MariaDB：小到中型遊戲，存玩家資料、課金、排行榜
• PostgreSQL：需要複雜查詢或交易保證
• Oracle / MS SQL Server：大型商業遊戲，金融/課金密集

2. NoSQL / 分散式資料庫

• MongoDB：玩家資料、物品背包（JSON 格式）
• Redis：快取、排行榜、即時遊戲狀態
• Cassandra / DynamoDB：大型 MMO，高可用、跨區域
• CockroachDB / TiDB：分散式 SQL，水平擴展 + 一致性

3. 混合架構

• 核心資料（帳號、課金） → SQL
• 即時狀態、排行榜 → Redis / Memcached
• 物品、地圖、任務 → 專用自定義資料庫或檔案
• 雲端服務 → AWS / GCP / Azure 提供全套分散式 DB + Cache

4. 舉例

• 原神 → 自家雲端 + MySQL + Redis
• FIFA Online → Oracle + Redis
• World of Warcraft → MySQL + 自家 server 狀態管理
• Roblox → 自家分散式 DB + Redis

四、誤解整理與業界反面教材

很多人常有這些誤解，導致專案在架構初期就走向壞軌：

• 「開放世界遊戲一定有後端」 → 錯，單機開放世界不需要。
• 「現代都市題材最容易做」 → 巨大盲點。現代建築外觀與室內隔間極其繁複（RAM Overflow）。諸多現代題材手遊（如 Gameloft 的 Gangstar Vegas）為了妥協效能，將九成建築變為無法進入的靜態死物件（Static Meshes），給人強烈的虛假感。
• 「把神權奇幻嵌進現代很酷」 → 審美違和。如好萊塢電影《基督再臨》（Legion）與美劇《天使聖戰》（Dominion），讓大天使拿 M16 步槍在現代公路餐館與凡人對射，引發嚴重的科技與奇幻代碼排斥，最終落入邏輯死循環與宮鬥壞軌。

五、簡單判斷是否需要後端

問三個問題就夠：

1. 玩家能否修改存檔？
2. 玩家之間會互相影響嗎？
3. 公司是否需控制經濟 / 排行 / 防作弊？

如果全部否 → 不需要後端（如本作定錨於 10 世紀黎凡特，主打 100% 全建築自由進出與個體超能力越獄，純單機即可流暢運行）；任一是 → 一定要後端。