- [2023 TGDF 台北遊戲開發者論壇](https://2023.tgdf.tw/)
- [共筆目錄](https://hackmd.io/@bogay/TGDF-2023)

## 講者介紹

[陳亦威](https://2023.tgdf.tw/speakers/maxwei)

目標成為製作人，在遊戲業從大公司打滾到小團隊，苦無機會才驚覺是自己太難相處所以跑出來獨立開發的遊戲設計師，希望能專注於創作有挑戰性、不愧對自己靈魂也讓玩家能感受樂趣的遊戲。

## 議程介紹

以實務上在自己兩款作品《活屍戰棋》《鬥技場的阿利娜》開發過程和經驗為例，嘗試分析和分享出我自己認為有價值的心得。

目標對象：偏初心者向，對遊戲開發過程有初步理解，但想多一些其他人實務上經驗分享的人。分享的內容偏向個人主觀想法較多，能知道 PINIX 開發遊戲實務上的執行方式當作參考。

# 內容筆記

<!-- 在這裡之下寫筆記。 -->

## 開場簡介

講者 2 款遊戲：都是戰棋

- Wanna Survive 活屍戰棋
- Alina of the Arena 鬥技場的阿利娜

## 我如何開發遊戲

將遊戲分為 2 個階段：

1. 建立遊戲機制和核心循環
2. 量產遊戲

## 建立遊戲機制與核心循環

迭代開發：每一個月建立版本並找人測試 -> 取得回饋 -> 改善下一版。

- 為何週期是一個月：配合「增肥聚會」活動。著重在「找到測試的人」
- 不一定要一個月，請找到適合自己的週期
- 什麼樣的版本才適合開始做測試？
- 越早越好，但要不只是「可以跑」
- 至少要有「規則」和「目標」
- 因為需要的是確認**體驗目標是否可透過規則達成**，不是請人debug
- 以活屍戰棋為例
- 有一版測試是「活屍不會直接抓人」「目標：全員到達橋的對面」
- 另一版改善了地圖並能施放技能

## 迭代開發流程


- 先完善機制
- 然後進行教學
- UX 在迭代過程中不停更新、完善
- 上述這個過程，逐步完成核心循環

### 遊戲機制的迭代

- 不急著做教學（因為機制還在調整）。口頭說明「規則」和「目標」
- 持續保留「感覺不錯的功能(部分)」，砍掉「明顯有問題的功能(部分)」
- 這部份吃開發者主觀意識，並無標準答案
- 舉例：鬥技場的阿利娜，曾迭代並移除複數卡牌使用的機制

### 教學的迭代

- 停止口頭說明，讓教學自己去教會玩家
- 玩家失敗時會認為是自己的問題，而不是教學沒說明(代表這階段，規則需對玩家可見，且玩家可知道改進方向)
- 觀察玩家卡住的點，並於下次進行教學的完善
- 目標：「開發者不在的時候，玩家也能（透過教學）順順的玩遊戲」

### UX 的迭代

- UX是迭代開發中最能改善的東西
- 目標：「讓 UX 可以自己告訴玩家所有必要的資訊」

## 迭代過程中，如何測試遊戲

### 測試實務的重點

- 閉嘴：不要一直（口頭）教學
- 讓你的遊戲自己去教，測驗你的教學與UX
- （前提：有做教學）
- 觀察玩家（但不用一直發問）
- 安靜地觀察玩家操作並記下你觀察到的問題
- 結束後再向玩家提問
- 允許玩家邊玩邊發問（但告知不會回答，只聆聽）
- 事先告知在遊玩過程中不會回答，除非嚴重到卡住測試
- 問題代表玩家當下的想法，大多數是你遊戲中沒有傳達好的地方
- 儘量不要打斷玩家的遊戲體驗

### 測試後的訪問

- 事前準備好一些問題：
- 每次可用的基本問題(有什麼你遊玩後，最想告訴我的東西，不論好壞)
- 為此次測試設計的客製化問題
- 不要引導問答：
- 不要在問題裡直接講出答案，並盡可能挖深一點
- ex. :x: 「你知道教學裡面有教你把卡牌拖曳到上方嗎？」 :heavy_check_mark: 「你知道怎麼使用卡牌嗎？」
- 讓對方說明並比對自己心中的假設。如果互不相同，則盡量挖深兩方的差異性（瞭解原因）
- 量化問題：打分數
- 幫助你理解問題的嚴重程度、需不需要修改
- 設定選項數字組沒有中間值 (i.e. 雙數 ex.1~6分)
- 不要去說服或教育對方你為何這樣設計

### 測試目標與測試項目

不同的測試員適合測試不同的內容。

- 白紙測試員：從來沒玩過你的遊戲的人
- 只有一次：玩過就不再是白紙了
- 適合測試 UX 和教學
- 遊玩過的玩家：已經有一些（你的）遊戲經驗
- 直接測試後期關卡、新敵人等
- 是不是受眾 (TA，Target Audience)
- 依照是否為受眾，調整他的意見的比重

## 量產遊戲

### 如何定義「(進入)量產時期」

要有「最小展示用產品」 (類似 MVP)

以「鬥技場的阿利娜」為例：

- 有基本卡片量就可以玩出簡單流派
- 有基本怪物量完成第一層流程
- 有小量事件、武器、道具
- 有8成以上的美術風格確認

最小展示用產品：定義

- 最小可行的展示內容
- 接近可參展、曝光、找開發商、參加比賽的美術完成度

生產流程確認

- 有明確流程知道如何生產出遊戲內容
- 抓預估時間的 1.5 倍較為保險

開發團隊重心轉移至生產內容

- 避免修改大系統、機制
- 如有需要，仍可修改小量機制和增加功能

### 迭代測試 v.s. 提前曝光

迭代開發的測試不等於商業上的對外曝光。兩者都是「早點讓玩家看到」，但意思其實不太一樣。

- 迭代開發的測試：
- 最小可行性產品(Minimu Viable Product)
- 對象封閉、小型聚會、私約，比較像封測不希望擴散出去
- 測試中需要專注觀察遊玩過程，測試後進行長時間訪問
- 對玩家來說，第一印象不重要
- 商業曝光(量產時期)：
- 最小展示用產品
- 對象公開、可展覽、能夠擴散宣傳，追求更多的曝光
- 不需要專注觀察，更應該追求即便開發者不在，作品也能自行運作
- 對玩家來說，第一印象很重要
- 希望大家能分辨這兩者的差異

### 講者聲明

都是個人經驗，僅供參考～

## QA
[Slido連結](https://app.sli.do/event/hvauSZcFBX3qQoTNq3ah1k/live/questions)