分數怎麼來的
評分方法
這裡每個數字都是有原始碼證據支撐的校準判斷。以下是規準、權重、流程、外部佐證——以及限制。
1–10 分規準
| 分數 | 意義 |
|---|---|
| 1–3 | 業餘／有嚴重問題 |
| 4–5 | 可運作但粗糙 |
| 6–7 | 紮實良好 |
| 8–9 | 專業水準 |
| 10 | 業界頂尖 |
權重
技術深度與遊戲設計權重最高（各 20%），因為它們定義一款遊戲「是什麼」；後端安全與程式品質（各 15%）決定它接觸真實使用者後能不能活下來；測試、完成度、原創性（各 10%）補完整體健檢。加權總分由各面向分數即時計算——改一個分數總分就跟著變。
| 面向 | 權重 | 評什麼 |
|---|---|---|
| 技術深度 | 20% | 引擎與渲染技術、效能工程（instancing、物件池、空間結構）、演算法含金量、架構難度。 |
| 遊戲設計 | 20% | 核心玩法循環、平衡、進程系統、手感、UI/UX。非遊戲專案（ssd）以「內容／教學設計」評此面向。 |
| 後端與安全 | 15% | API 設計、資料庫、防作弊、限流、密鑰衛生、輸入驗證——靜態網站則評部署安全實務。 |
| 程式品質 | 15% | 架構、模組化、命名、型別紀律、重複程度、magic numbers。 |
| 測試 | 10% | 自動化測試的存在與覆蓋、斷言、CI。完全沒有測試給 1–2 分。 |
| 完成度 | 10% | 可玩性／可用性、打磨程度、文件、部署狀態、音效美術完整性。 |
| 原創性 | 10% | 相對既有遊戲／內容有多少真正的新東西——以機制與實質內容評斷，不只看題材皮相。 |
分析流程
- 完整 clone、完整歷史。八個 repo 全數 clone 含完整 git 歷史；commit 時間軸、署名與節奏與程式碼一併分析。
- 讀原始碼，不是讀 README。每個專案的核心遊戲邏輯、後端 functions、資料庫 schema、安全機制、測試與建置設定都被直接閱讀。報告中每個論斷都引用具體檔案（多附行號）為證。
- 同一規準、交叉校準。六個專案由平行審查以完全相同的評分規準與指示打 1–10 分，再交叉校準確保每個「7 分」意義一致。唯一的非遊戲專案（ssd）將「遊戲設計」面向改評「內容／教學設計」。
- 現況查核。2026-07-20 檢查前六個專案的全部 11 個公開網址（部署、介紹頁、嵌入式遊戲），2026-08-25 以同樣方式檢查兩款人生模擬的部署——全數回應 HTTP 200，八個專案都活著。
外部佐證
- 類型背景：「Vampire Survivors–like」是有維基百科條目的公認子類型；3D 化（如 2025 年兩週賣百萬套的 Megabonk）已是既定趨勢——這是 zombie-survivors 原創性評分的脈絡。 來源 ↗
- 假廣告背景：《寒霜啟示錄》廣告與實際玩法的落差被大量記錄（「ads vs gameplay」型內容）——fake-whiteout-survival 正是把這個現象反諷地做成真遊戲。 來源 ↗
- 共同作者關係，用資料查核過：CheerLife 的 README 把原創概念署名給最先生（@mr.themost），與 YaKyoLife 片頭署名同一人——而 `mr.themost <ja42022@gmail.com>` 出現在 YaKyoLife 的 git 歷史中，與該 repo 擁有者帳號共用同一個 email。本報告據此把兩款遊戲視為同一條設計血脈。
限制與聲明
- 這是靜態的程式碼級體檢：沒有實測 FPS、沒有 fuzz API。運行期論斷（如「死程式碼不會觸發」）來自控制流閱讀，非動態量測。
- 分數是校準過的判斷，不是量測值。規準與證據全部公開，就是為了讓你可以不同意某個分數、並檢驗它背後的推理。
- 安全發現以防禦意識為目的呈現。文中的洩漏密鑰保護的是免費小遊戲的留言板；引用它們是為了衛生課，不是邀請函。
- commit 數在專案之間不可比較。CheerLife 全程透過 GitHub 網頁介面發布，那 17 個 commit 是上傳事件而非開發歷史；它真正的迭代發生在平台之外，完全無法從 git 讀出。
- 有兩個受檢日期，不是一個。前六個專案描述的是 2026-07-20 的 commit；yakyulife 與 CheerLife 於 2026-08-25 受檢，描述的是該日的狀態。
- 單一時間點快照（2026-07-20）。repo 會前進；分數描述的是受檢的 commit，不是未來。
這是獨立、非隸屬的分析。專案名稱、repo 與商標屬於各自擁有者。所有發現描述的是 2026-07-20 受檢時各 repo 的狀態。