歡迎來到鐵人賽的第三天！在確定了「兩款互動小遊戲 + 會員金流後台」的產品藍圖後，接下來要面對的就是工程師最關心的核心問題 —— 「這套跨平台遊戲與後端系統，到底該用什麼技術堆疊來開發？」

需求痛點：跨平台與「網頁免下載」試玩

我們這次的專案有一個非常關鍵的需求：遊戲除了要能上架 iOS 與 Android 雙平台外，更必須提供 Web 網頁版。因為對店家來說，顧客在等候時若還需要先下載 App，會大幅降低體驗意願；如果能透過 LINE 或網頁「點開即玩」，獲客門檻將會大幅降低。

信仰與現實的拉扯：為什麼不直接用 Kotlin？

上一篇有提到，我擁有多年 Kotlin (Android) 開發背景。因此，在找 Gemini 討論技術選型時，我的第一個想法就是：「我能不能用 Kotlin Multiplatform (KMP) 或 Kotlin 遊戲引擎把它們全部搞定？」

然而，身為專業 AI 顧問的 Gemini 很快幫我打破了這個迷思：

1. KMP / Compose 的侷限：Compose 適合開發一般的 App（如選單、表單），但缺乏遊戲必備的視覺化場景編輯器、精靈動畫（Sprite）系統與渲染循環（Game Loop）。
2. KorGE 引擎的挑戰：雖然 KorGE 是 100% 用 Kotlin 寫的 2D 遊戲引擎，但缺點是缺乏「所見即所得」的視覺化編輯介面，純靠程式碼微調座標會極度消耗開發時間，且生態系較小。

經過多方比較 Cocos Creator、Godot 4 與 KorGE，Gemini 推薦了最適解答：Cocos Creator。Cocos 天生為 Web 與跨平台而生，生成的 WebGL 包體極小、載入速度極快，且支援 TypeScript，能讓我們用最高效率做出流暢的 2D 遊戲。

後端的技術堅持：輕量強悍的 Kotlin + Ktor

前端決定採用 Cocos Creator 後，後端呢？雖然之前公司轉做 ASP.NET，但我對 Kotlin 的效能與語法依然情有獨鍾。當我向 Gemini 提出「後端我想繼續用 Kotlin」時，得到了強烈的肯定！

Gemini 為我推薦了 JetBrains 官方的 Ktor 框架：

• 極致輕量：由 Kotlin 協程（Coroutines）原生驅動，記憶體佔用極小、啟動以毫秒計。
• 完美契合遊戲需求：非常適合處理高頻率的存檔 API、離線收益結算與金流 Webhook 回調。
• JSONB 資料庫支援：搭配 PostgreSQL 與 Exposed ORM，能將玩家房間的貼紙座標直接壓縮為 JSONB 欄位高效存取，避免複雜的資料庫關聯查詢。

最終黃金組合宣告

經過這一輪與 Gemini 的深度技術討論，我們正式確定了這次鐵人賽的黃金技術堆疊：

• 前端遊戲引擎：Cocos Creator (TypeScript) —— 打造輕量流暢的跨平台/網頁小遊戲。
• 後端 API 服務：Kotlin + Ktor —— 處理會員驗證、離線收益防弊與金流交易。
• 資料庫：PostgreSQL (Exposed ORM) —— 利用 JSONB 儲存動態貼紙與遊戲狀態。

跨出舒適圈不代表放棄過去的經驗，而是學會用 AI 評估出開發阻力最小、商業價值最高的路徑。技術選型定案後，明天我們將正式進入 Vibe Coding 的核心理念與實戰心法！