[閒聊] 你真的清楚遊戲的開發難度嗎？（上）
原文標題：你真的清楚遊戲的開發難度嗎？（上）
原文網址：https://bit.ly/3tGiZF8
https://medium.com/that-game-designer/%E4%BD%A0%E7%9C%9F%E7%9A%84%E6%B8%85%E6%
A5%9A%E9%81%8A%E6%88%B2%E7%9A%84%E9%96%8B%E7%99%BC%E9%9B%A3%E5%BA%A6%E5%97%8E-
%E4%B8%8A-1318c44ae021
| 淺談各種遊戲類型，研發的成本與技術難點
水狼陽介
每隔一陣子，總會冒出幾個熱情的新手，想做一些不一樣的遊戲挑戰嘗試，然後又被業內
老手嘲笑不實際等等。
有一部分原因，其實是因為新手們不知道不同類型的遊戲研發難度。
筆者思索已久，決定整合一下各大領域的遊戲類型，簡單分析一下研發上的難點，以及專
案規模和成本比重等資訊，供新手們參考。
| 寫在前面
|
| 這篇的難度資訊會以星數的方式呈現，畢竟遊戲開發很複雜，沒有定案，只能大概列出
| 各種要素的「相對值」。實際會依照開發團隊和規模有不小的差異，故本篇提供的資訊
| 僅供參考囉。
-
先來解釋一下評級種類
1.研發難度
這是一個綜合評估指標，用來比較不同類型的遊戲，開發的難度差異大概為何。
2.研發成本
這也是一個綜合評估指標，針對研發總體所需要消耗的金額做一個概估，所有的人事和
研發成本都放在一起計算。
3.團隊規模
這邊的團隊規模，是針對「是否有需要獨立職能」來做評估的。例如若開發的領域特別
需要「特效」或「2D／3D 動作」，這部分就很難讓程式或企劃兼職。這個評級項目會
體現出該領域研發「需要專精人才」的需求度。
4.研發時長
即便提高成本和團隊規模，可以稍微縮短研發時長，但根據行銷、市場反應做調整等等
，每一種遊戲類型還是會有適合的研發時間。這裡針對不同類型的遊戲做一個相對值的
概估。
5.技術門檻
這部分和「團隊規模」也有點關聯，是指單一專精人才（通常是指程式）需要的技術水
準相對值。
| 另外，底下的各星數，如果沒特別標註，就是單機產品的難易度。如果要連網或做成營
| 運型遊戲，技術門檻和成本都先加兩顆星再說。
-
AVG／文字冒險／視覺小說
| 研發難度：★
| 研發成本：★★
| 團隊規模：★
| 研發時長：★
| 技術門檻：★
| 技術需求較少，主要偏表現類例如動畫、動態演出等。現在有非常多可以直接使用的插
| 件（例如 Fungus、Ustage 等等），開發難度降低非常多。
冒險類遊戲（Adventure Game）應該算遊戲史上相當早期就出現的類型。這類遊戲著重劇
情和抉擇，本身通常沒有數值養成要素，提供給玩家的是一段精心設計的敘事旅程。
在日本這類遊戲往往跟二次元結合，也稱為 Galgame（美少女遊戲）或是戀愛遊戲（更著
重戀愛要素）。
https://i.imgur.com/N1OV77V.jpg
「心動文學社」就是有著 Meta 要素的 AVG 遊戲，在 Steam 上有非常不錯的成績
AVG 類遊戲最大的成本會是角色立繪、場景等美術資源，以及文字量的控管和翻譯，尤其
以文字敘述導向為主的內容，往往動輒幾十萬字，翻譯以來很可能翻譯費用比其他研發成
本加起來還要多。
沒做過這個類型的新手，會需要特別留意的包括：
1.不要什麼都從零開始，善用能取得的工具吧！
使用現成工具或是 Unity+Asset Store 都可以很大幅度的降低研發門檻，要善用能取
得的工具。
2.美術會是最重要的部分
研發成本中美術的比重占的最高（翻譯暫且不談），玩家在不清楚劇情的情況下，也都
會以畫面為優先考量，這部分需要多花心力。
3.美術外包契約與需求開立的精確度
上面提到角色差分會是很重要的體驗重點，如果立繪採用外包，如何外包、在一開始就
規劃好差分需求，也是新手需要考慮的重點之一。
4.遊戲劇本和小說是不一樣的
雖然稱為「視覺小說」，但遊戲劇本的撰寫和小說描寫是有差距的，需要更多立繪動畫
（飄移、淡入淡出或螢幕震動等）來增強代入感。如果用小說的經驗來設計遊戲，能提
供的體驗會很平淡。除此之外，劇情分歧和選擇支的規劃管理對沒經驗的開發者來說也
是一個挑戰。
-
延伸閱讀
【遊戲製作】製作一款Galgame（文字冒險遊戲／視覺小說）需要多少錢？
https://home.gamer.com.tw/artwork.php?sn=5049455
熟練運用這四項劇情策畫的必備工具，輕鬆解決遊戲分支劇情創作難題
https://mp.weixin.qq.com/s/F3sFB7Cy25Xy3291XeNtTA
-
參考資料
冒險遊戲 - 維基百科，自由的百科全書
https://zh.wikipedia.org/wiki/%E5%86%92%E9%99%A9%E6%B8%B8%E6%88%8F
美少女遊戲 - 維基百科，自由的百科全書
https://zh.wikipedia.org/wiki/%E7%BE%8E%E5%B0%91%E5%A5%B3%E9%81%8A%E6%88%B2
戀愛冒險遊戲 - 維基百科，自由的百科全書
https://bit.ly/3tO48ZJ
https://zh.wikipedia.org/wiki/%E6%88%80%E6%84%9B%E5%86%92%E9%9A%AA%E9%81%8A%E6
%88%B2
-
Point & Click + Puzzle/Escape（點擊解謎）
| 研發難度：★
| 研發成本：★
| 團隊規模：★
| 研發時長：★
| 技術門檻：★
| 技術需求較少，只有點擊執行判定，以研發來說完全的程式新手都可以用 PlayMaker
| 之類的可視化輔助工具做出來。
這個領域的名稱在台灣玩家可能比較少聽到，但其實是非常常見的遊戲類型。
只要是會需要在場景內，或是一定的範圍內，藉由點擊的方式就能體驗大部份內容，就會
被算在「Point & Click」裡面了。
而這類遊戲大部份都以解謎、敘事導向為主。例如 The Room 系列就是相當有名的例子。
P.S. 這類遊戲還有一個優勢，就是點擊操作在 PC 和行動裝置上的雙向移植成本很低，
就算點擊判定全部重作，也不需要大改內容，如果想要跨平台發行可以考慮這種作法。
https://miro.medium.com/max/783/1*UtCvQaj5SjbK84ZJnXwULQ.png
在 Steam 上，Point & Click 其實是一個很熱門的分類，可以跟解謎、驚悚或是 RPG 要
素結合。
沒做過這個類型的新手，會需要特別留意的包括：
1.謎題的設計
謎題難度的設計拿捏，以及提示的表現方式等。
2.美術風格的統一與 UX 互動
如果是需要玩家在大場景上找東西的話，能互動的東西需要有特別的標註，UX 輔助需
要做好。
3.AVG 或敘事功能的結合
如果有角色和對白等要素，和前面的 AVG 需要考量的事情一樣，包括差分外包和敘事
展現方式等等。
可以參考一些 Steam 上有特色的作品
The Blind Prophet
https://store.steampowered.com/app/968370/The_Blind_Prophet/
也有不少開發商選擇作系列作，有自己的特色。
例如 Rusty Lake（鏽湖）就是以驚悚解謎為特色的開發商。
Cube Escape Collection
https://store.steampowered.com/app/1292940/Cube_Escape_Collection/
或是也有大量商業化，以一些魔幻題材做4～6小時小品的開發商。
9 Clues 2: The Ward
https://store.steampowered.com/app/369420/9_Clues_2_The_Ward/
-
Puzzle 益智關卡
| 研發難度：★
| 研發成本：★
| 團隊規模：★
| 研發時長：★★
| 技術門檻：★(★)
| 技術需求較少，以核心機制的實現為主。較常用開發環境內建的物理引擎做計算，或是
| 簡單的策略機制。
這類遊戲主要是以大量的益智類關卡做鋪量，這在手機上的 Hyper Casual 類遊戲也算挺
常見的。
只要有一套適合鋪量的遊戲機制就可以了，技術門檻不高。真正的難點會放在關卡設計鋪
量這塊，需要比較多時間設計和產出。
https://miro.medium.com/max/1066/0*vrqJxXmgro0TVEAz.jpg
手機上其實挺常見這類的遊戲，休閒益智類一直是全球通用的市場標籤。
沒做過這個類型的新手，會需要特別留意的包括：
1.會低估難度曲線與新手引導的重要性
這點在手機平台上尤其重要。隨著關卡的拓展，一定會需要加入新的「機制」或要素，
這時教學和難度的曲線掌控就相當重要。
2.會低估「關卡編輯工具」的重要性
關卡編輯器會是非常重要的工具。Puzzle 類遊戲需要關卡設計師大量鋪內容，如果沒
有方便的工具，會大大影響產出效率。
3.在初期選用「有趣但不好拓展」的核心機制
這點容易發生在對謎題鋪量沒有經驗的團隊或開發者身上。如果初期選用了相對難搭配
和鋪量的機制，在後期關卡需要加入新機制或是要設計的更難時就會遇到瓶頸。
4.用了物理引擎計算的副作用
雖然 Unity 等工具內建的物理引擎相當方便，但別忘了物理引擎的缺點就是「難以預
測」以及「耗效能」，如果用的不好，很容易導致 Bug 頻發或是設備發熱（在手機上
尤其明顯）。
https://miro.medium.com/max/842/0*51yy4XtX7NNZzjxv.jpg
憤怒鳥是用了物理引擎做計算，效果很不錯
Steam 上有幾款不錯的 Puzzle 類遊戲可以參考：
Baba Is You
https://store.steampowered.com/app/736260/Baba_Is_You/
Filament
https://store.steampowered.com/app/1137350/Filament/
地城謎蹤
https://store.steampowered.com/app/1229060/
-
3-Match（三消／消除類）
| 研發難度：★★（★★）
| 研發成本：★★（★★★）
| 團隊規模：★★（★★）
| 研發時長：★★（★）
| 技術門檻：★（★★）
| 這邊括號內的星星，是特別標註出來給「手機平台營運型三消遊戲」用的。
| 技術門檻主要體現在「關卡編輯器」、「生成珠子的機率控制演算法」和「消除判定」
| 等。
https://miro.medium.com/max/2716/0*tFzffN-v6H6ZjkGY.jpg
例如 Candy Crush 或是夢幻家園，都是手機上非常出名的三消類遊戲
筆者這邊特別把消除類遊戲獨立出來，是因為這個遊戲領域算是非常有辨識性，且與其他
Puzzle 類的遊戲相比，開發成本也高不少。
消除類遊戲一般分成幾個類型
．連線消除（3消）
連線消除就是最常見的3消遊戲了，珠子藉由矩陣方格的形式，玩家用對調的方式讓珠
子連成水平或垂直的組合。
從比較早的「珠寶消除」等遊戲開始，各家後來都採用豐富的特效和爆破效果來營造爽
感。除了傳統的水平垂直之外，連成「田」字型的四格後來也常常被設計成可以消除的
組合。
．單擊消除（單消）
單消指的是一樣屬於矩陣方格，但玩家一次只單擊一個格子，會將該格子上的珠子，與
相鄰同顏色的珠子都一起消除。相較之下因為消除只會有一次，比較難營造類似3消的
那種「爽感」。
．接觸消除（線消）
線消算是比較特別的類型，也有多種變體。以概念來說，算是用一條線將同樣顏色的珠
子連起來，然後一起消除。連線越長，分數越高。
不過現在也常見不走「矩陣方格」，改用球狀物體之類的方式，或是和休閒博奕做結合
的玩法。
．轉珠（拖拽整盤）
轉珠應該不用筆者再贅述了吧？
從龍族拼圖開始，轉珠算是一個非常獨特的機制，消除的邏輯是3消，但操作算是把多
個對調連在一起一氣呵成，反而以「時間」作為消除的限制，讓回合制 RPG 有類似半
即時制的刺激感，這種體驗在現今的遊戲中也相當少見了。
https://miro.medium.com/max/2160/0*X6u7rn1RAVDNnfHV.jpg
手機上把三消和 RPG 卡牌養成結合的產品，除了左邊的 Puzzle & Empire 外，末日喧囂
等遊戲也跟著加入戰場。
這邊特別備註一下，沒有經驗和一定資金的團隊，絕對不建議做「營運類型的三消遊戲」
（特指手機平台上）。
北美乃至全球，三消都是女性向休閒遊戲的最大一塊餅，大廠分都來不及，小團隊絕對不
要想不開XD。一線大廠的三消團隊配置，少則50人，多則破百，單款產品都研發至少一年
半以上，物量堆疊的規模不是中小團隊能負擔得起的。
沒做過這個類型的新手，會需要特別留意的包括：
1.與 Puzzle 類型一樣，需要多關注關卡編輯器的重要性。
2.通常三消需要關卡鋪量，甚至是外圍系統（例如劇情、場景美術資源等），這些量有時
候甚至比核心機制本身還要昂貴。
-
Arcade（街機）
https://i.imgur.com/Mow4tZa.jpg
| 研發難度：★
| 研發成本：★
| 團隊規模：★
| 研發時長：★★
| 技術門檻：★
Arcade（街機遊戲）指的就是以前在遊樂場會看到的大型機台，部份古早型號的主機遊戲
內也大都是這種類型的遊戲。
Arcade 遊戲大多數是「操作反應」類型的遊戲，也就是考驗玩家手眼協調的技巧和預判
能力等。主要特色包括會有「積分」（通常取決於玩家可以在關卡內撐多久不失敗），部
份遊戲會有使用遊戲貨幣升級技能等外圍要素。
在2010年代手機遊戲剛興起時，主流遊戲也是以 Arcade 為主，像是「小雞過馬路」、「
瘋狂噴射機」或是「Flappy Bird」等遊戲都是屬於這類。
https://miro.medium.com/max/2000/0*YXIUBgwc0dUXR4Qr.png
Jetpack Joyride（瘋狂噴氣機）就是當年非常有名的 Arcade 類型遊戲
以下盤點幾種比較常見的 Arcade 類型遊戲：
1.Arcade-跑酷
跑酷類遊戲算是歷久彌新的遊戲類型了。
跑酷類遊戲通常是有一個單一的方向，玩家要操作角色讓這個旅程一直持續下去。
包括上面提到的 Jetpack Joyride、神廟逃亡等，都是當年很有名的例子。
https://i.imgur.com/DCzHAhc.jpg
Subway Surfers 就是一款在手機上長年霸榜的跑酷型 Arcade Game
當然跑酷這個要素也可以跟其他東西結合，例如 Steam 上就有不少以跑酷為核心，但其
實不是街機類遊戲的作法。
Ghostrunner - 幽影行者
https://store.steampowered.com/app/1139900/Ghostrunner/
2.Arcade-輕度動作/技巧遊戲
上面有提到，Arcade 幾乎都是反應型的遊戲，因為這種作法在短期反饋（玩家成就感的
取得）以及難度控制上都是比較好拿捏的。
https://miro.medium.com/max/1400/1*N1HoM8nGvrvZlW864VPJiw.png
例如「瘋狂動物園」就是有一些外圍經營要素的操作型 Arcade Game
3.Arcade-超休閒
這邊特別提到超休閒，是因為手機上超休閒遊戲幾乎與 Arcade 遊戲的客群完全重疊。
這類客群喜好輕體量、短期能立刻看到反饋特質的遊戲。也因為如此，手機上的 Arcade
遊戲營收現在也大都以廣告變現為主。
不過這個趨勢正在扭轉，就如同筆者常說的，市場3～5年一個循環，超休閒的大量氾濫其
實也讓市場對這類遊戲的疲勞度慢慢累積，現在的休閒類遊戲，如果不加入一些輕度養成
或積累的要素，會比較難在紅海中殺出血路。
https://miro.medium.com/max/1400/0*D96-ttdM0rzLYh8J.jpg
超休閒類型的遊戲，特質與街機非常類似。付費點也常放在「接關」等節點上
-
Simulator／Sim（模擬體驗）
| 研發難度：★★（★）
| 研發成本：★（★★）
| 團隊規模：★（★★）
| 研發時長：★★（★）
| 技術門檻：★★
| 根據想模擬的題材，研發難度會有挺大的差異。
這邊的模擬類遊戲指的是模擬器（Simulator），主要是提供玩家一些現實世界中很難去
體驗的東西。
（P.S.模擬經營類的遊戲我們留待下篇再談）
例如「小偷模擬器」就是讓玩家嘗試扮演小偷，在不被主人或警察發現的情況下偷走最有
價值的東西。
https://miro.medium.com/max/750/0*3R1uofz6c5pxnk6b.jpg
破窗？開鎖？這些在現實生活中無法體驗的東西就是模擬類遊戲最大的賣點
根據遊戲想提供給玩家的體驗類型，以及複雜程度，這類遊戲的研發成本會有很大的差異
。
沒做過這個類型的新手，會需要特別留意的包括：
1.市場定位是否重複
例如已經有一款「小偷模擬器」類型的遊戲，再做同類型的嘗試是否能做出差異化或更
好的體驗？這些在立案時就需要納入考量。
2.複雜度與寫實程度是否在團隊掌控之內
例如想做到比較複雜的「料理模擬」，包括食材的處理、各種烹調方式和擬物化的 UI
呈現方式，對於小團隊而言可能就比較不那麼適合。
（P.S. 不過如果單純是娛樂向，例如很多 VR 遊戲單純只是讓玩家進去玩樂用的，那
就可以不用太計較細節）
3.知識點是否齊備
例如想做裝修工人的體驗遊戲，對於室內裝修、水電接線等知識的呈現是否正確。這對
玩家來說也是一種學習，因此錯誤的資訊或呈現方式是很重要的。
例如筆者最近就在體驗這款車禍模擬器：
車禍現場模擬器
https://store.steampowered.com/app/852220/
-
射擊遊戲
射擊類遊戲實在族繁不及備載，不同類型也很難混為一談，暫且分成 2D 和 3D 來談。
https://miro.medium.com/max/600/0*hHMmT1v_07sydMg3.jpg
只要是「發射出子彈」的幾乎都算是射擊類遊戲，或至少有射擊要素的遊戲
2D射擊／彈幕射擊
| 研發難度：★★
| 研發成本：★
| 團隊規模：★
| 研發時長：★★
| 技術門檻：★★
| 最大的技術門檻應該會是擊中判定與效能優化，尤其是彈幕類遊戲，如果採用物理引擎
| 的碰撞判定，很容易出現失誤和耗能很兇的問題。
2D 射擊遊戲也是新人比較容易嘗試的類型之一。
比較大的技術門檻通常會是子彈的判定部份，例如若是使用 Unity 的 Collider 碰撞判
斷，遇到很快的子彈可能會在前後幀都沒有觸碰到判定範圍的情況下，子彈直接穿過目標
打空。
此外太多子彈同時在場時，也容易因為大量的觸發判定而導致效能消耗或發熱。這點比較
常用子彈池（一大批子彈物件輪換使用，不採用大量物件銷毀或生成的方式降低計算量）
來解決。
-
3D 射擊
| 研發難度：★★★
| 研發成本：★★
| 團隊規模：★★
| 研發時長：★★★
| 技術門檻：★★★
| 3D 射擊類（以 FPS 第一人稱為主）的開發難點主要會體現在打擊感、槍械手感調優、
| 美術資源和音效等需求上。
| 目前遊戲引擎上有不少這類遊戲的現成插件，可以省不少功夫，但實際表現的調整還是
| 需要依照專案需求，最好要有這方面開發經驗的人員比較好。
| 技術部份會著重在包括 NPC 的 AI、射擊判定等，若有連線需求會需要更有經驗的程式
| 成員協助。
3D 類射擊遊戲在某些方面反而會比 2D 遊戲開發速度更快，畢竟這類遊戲是市場主流之
一，市面上有非常多現成的插件和模型可以直接使用。
但也因為這個領域競爭激烈，如果單純只是射擊或多人競技，很難和大廠（例如 APEX 或
CS）匹敵，小團隊必須做出一些差異化。
此外，槍械類的「打擊感」也是一個很重要的重點，玩家是會因為打擊感或射擊手感而決
定是否留下的。這部份的優化追求會非常吃重，如果真的想開發這類遊戲，「有此類遊戲
開發經驗的設計師」會是很重要的必要條件。
https://miro.medium.com/max/489/0*-euMX3PfJ9nT3KV9.jpg
槍械參數、特效、螢幕搖晃、音效和換彈動作等，共同構築了所謂的「手感」
手感部份的設計可以參考以下這篇：
射擊遊戲中強烈的手感如何營造出來？
https://mp.weixin.qq.com/s/_u-trLS7-Co8SevftV3MjA
-
2D 動作／2D 橫向捲軸+平台／俯視角
| 研發難度：★★
| 研發成本：★★
| 團隊規模：★★
| 研發時長：★★★
| 技術門檻：★★
| 技術門檻比較少，大部分是操作手感優化和關卡設計，這類偏遊戲體驗的東西。
終於來到最多人會想嘗試的類型了。2D 橫向捲軸或是 2D 平台算是小團隊或是新手最常
見的切入方式，但其實一款好的平台跳躍遊戲並不是真的那麼「容易完成」。
Unity 為了吸引更多人使用，把 2D 平台遊戲作為最「簡單」的入門類型，只需要物理引
擎和設定碰撞箱就可以達成，但其實這種作法有非常非常多的副作用。
包括物理引擎的不可預期、效能的損耗以及短幀數下的判定等等，因此市面上手感操作好
的遊戲，「絕大部分」都不是基於物理引擎製作（或至少在碰撞判斷上不全是基於物理）
，還是必須要用嚴謹的邏輯去構築的。
https://i.imgur.com/UAwWTT8.jpg
例如 Deadcell 就不是基於物理引擎做移動判斷的，這類遊戲的製作並不是真的如同教學
影片裡面一樣簡單
沒做過這個類型的新手，會需要特別留意的包括：
1.認為物理引擎可以解決大部分問題
實際上往往相反，物理引擎在比較複雜的遊戲中只能協助解決一小部分需求，大部分還
是需要工程師用邏輯來處理的。
2.忽視了「關卡設計」的重要性
玩家如何理解要怎麼過關？移動路徑是明確的嗎？平台的設計是否能明確提示玩家這些
資訊？
對這部份沒有經驗的新手，非常推薦至少去詳細拆解一兩款遊戲的關卡設計，例如「鏟
子騎士」等就是很不錯的研究素材。
不過「隨機生成」關卡的類型比較難分析，不建議從 Roguelike 或是隨機地牢的類型
開始。
-
3D 動作
| 研發難度：★★★（★★）
| 研發成本：★★★（★）
| 團隊規模：★★★
| 研發時長：★★★★（★）
| 技術門檻：★★★（★）
| 技術需求較高，不推薦無經驗的小團隊或個人嘗試，這部份算是市場主流，競爭較為激
| 烈的紅海。
3D 動作遊戲也是個非常大範圍的領域，除卻射擊類型已經在前面講過，包括「魔物獵人
」、「荒野之息」、「三國無雙」或是「原神」等遊戲都算在這個領域中。
也因為類型非常廣，這邊不做太細的介紹。
以 3D 動作遊戲而言，市場對操作手感和打擊感的需求已經被堆的比較高了，這部份不建
議新人做嘗試，風險較大。
這類遊戲研發時會需要特別留意的包括：
1.打擊感
這點就不詳述了，未來會再開一篇特別聊這個部份。網路上查也有不少資料可以參考。
2.手感與長時間操作的疲勞度
有些操作長時間對玩家其實是種負擔，在手把適配和交互設計上要特別留意。
3.鏡頭的規劃（Cemera Control）
遊戲畫面鏡頭的控制其實是非常專業的議題，這點在 3D 射擊遊戲比較不那麼重要，因
為第一人稱的遊戲中，玩家會自己移動視角，但在 3D 動作類通常是第三人稱視角，此
時鏡頭的自然移動參數和控制就相對重要，特效的大小、甚至關卡和怪物的大小，都需
要有明確規範，以免最後成品的效果打折扣。
4.特效、音效和動作銜接
這些是一開始比較會忽略的細節，音效可能還好，但特效和動作銜接如果在一開始沒有
好好規劃，後期要再優化會是比較沈重的負擔（尤其如果美術資源外包的情況下）。
-
額外補充：類魂遊戲（Souls-like）
| 研發難度：★★★★
| 研發成本：★★（★★★）
| 團隊規模：★★（★）
| 研發時長：★★★★
| 技術門檻：★★★
| 根據美術等級，從 2D～3D～3A，成本和研發時間的差異也是很大的。
類魂遊戲絕對不會只是「難」而已，重點在難的有深度，而且讓玩家心甘情願的重複挑戰
。
而且另一個常常被人忽略的部份，是類魂遊戲需要有「很強的美術呈現」讓玩家願意克服
挫折感不斷嘗試，這點雖然不是類魂遊戲最困難的門檻，卻是對研發資金量的考驗。
延伸閱讀
類魂的魂在哪裡？－－類魂遊戲設計思考
https://mp.weixin.qq.com/s/Re7Dc-4YGG26VHXEuY6dtA
如何設計一張有「魂味」的地圖？－－論「類魂」遊戲關卡的拓樸結構
https://mp.weixin.qq.com/s/cxpE0XBBCaGgnzY_QLcRKA
-
額外補充：銀河戰士惡魔城（Metrovania）
| 研發難度：★★★★
| 研發成本：★★★
| 團隊規模：★★
| 研發時長：★★★★★
| 技術門檻：★★（★）
目前大部分的 Metrovania 遊戲都還是以橫向捲軸為主，一方面是受到始祖（銀河戰士和
惡魔城系列）的影響，另一方面是因為3D比較難「綜覽關卡」，也就是玩家無法直接藉由
觀察關卡，就知道「哪些地方現在還過不去」。
雖然這類機制在 3D 遊戲內也不少見（例如開放世界很常有一開始無法進入的地區），但
通常我們在談 Metrovania 時還是以橫捲為主。例如血咒之城即便是 3D 建模，但仍然保
留橫向捲軸的玩法。
這類遊戲新手常常會忽略的，其實是「內容量」這件事情，包括關卡數量、機制的解鎖，
到 Boss 需求等等。
Metrovania 的技術門檻其實不會和 2D 橫向捲軸差太多，困難點會是對「製程」的掌握
以及整體的遊戲規劃，也是不建議無經驗的團隊一開始就挑戰的類型，除了是長期抗戰之
外，帶領專案的人大局觀要夠強，才不會研發到中途走偏。
-
小結
這篇也是屬於躺在我草稿區非常久，但不確定要怎麼寫完的文章之一。主要是遊戲的類型
實在太廣，很難一概而論。
因此這個主題上篇會比較貼近小團隊會想要嘗試的研發方向，而下篇則會來聊聊大團隊或
比較具商業規模的公司可能會想挑戰的領域。這樣分上下集應該會比較好吸收。
主要還是想提供一些基本盤，讓沒有經驗的團隊可以參考。
作為2022年的開篇，這應該是挺合適的。
那麼，今天就先到這邊。
-
可利用文章列表，持續追蹤最新文章：
水狼的遊戲設計文章列表
https://bit.ly/3GuSUwx
https://docs.google.com/spreadsheets/d/
1FTD4JoJLmWwANOw6O1rHEc3qnqgViYn2ofIokoe0afk/edit#gid=0
--
清廉正直射命丸文，世界第一可愛
https://i.imgur.com/XqOptr2.jpg
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.174.177.242 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/C_Chat/M.1642391414.A.50B.html
推
01/17 11:55,
2年前
, 1F
01/17 11:55, 1F
推
01/17 11:55,
2年前
, 2F
01/17 11:55, 2F
推
01/17 11:55,
2年前
, 3F
01/17 11:55, 3F
推
01/17 11:58,
2年前
, 4F
01/17 11:58, 4F
推
01/17 11:59,
2年前
, 5F
01/17 11:59, 5F
推
01/17 12:00,
2年前
, 6F
01/17 12:00, 6F
推
01/17 12:02,
2年前
, 7F
01/17 12:02, 7F
推
01/17 12:02,
2年前
, 8F
01/17 12:02, 8F
推
01/17 12:08,
2年前
, 9F
01/17 12:08, 9F
推
01/17 12:09,
2年前
, 10F
01/17 12:09, 10F
推
01/17 12:18,
2年前
, 11F
01/17 12:18, 11F
推
01/17 12:19,
2年前
, 12F
01/17 12:19, 12F
推
01/17 12:28,
2年前
, 13F
01/17 12:28, 13F
推
01/17 12:29,
2年前
, 14F
01/17 12:29, 14F
推
01/17 12:30,
2年前
, 15F
01/17 12:30, 15F
推
01/17 12:31,
2年前
, 16F
01/17 12:31, 16F
推
01/17 12:31,
2年前
, 17F
01/17 12:31, 17F
推
01/17 12:32,
2年前
, 18F
01/17 12:32, 18F
推
01/17 12:32,
2年前
, 19F
01/17 12:32, 19F
推
01/17 12:34,
2年前
, 20F
01/17 12:34, 20F
推
01/17 12:37,
2年前
, 21F
01/17 12:37, 21F
推
01/17 12:39,
2年前
, 22F
01/17 12:39, 22F
推
01/17 12:39,
2年前
, 23F
01/17 12:39, 23F
→
01/17 12:39,
2年前
, 24F
01/17 12:39, 24F
推
01/17 12:41,
2年前
, 25F
01/17 12:41, 25F
→
01/17 12:44,
2年前
, 26F
01/17 12:44, 26F
推
01/17 12:46,
2年前
, 27F
01/17 12:46, 27F
推
01/17 12:46,
2年前
, 28F
01/17 12:46, 28F
推
01/17 12:47,
2年前
, 29F
01/17 12:47, 29F
推
01/17 12:51,
2年前
, 30F
01/17 12:51, 30F
推
01/17 12:52,
2年前
, 31F
01/17 12:52, 31F
推
01/17 13:02,
2年前
, 32F
01/17 13:02, 32F
推
01/17 13:14,
2年前
, 33F
01/17 13:14, 33F
推
01/17 13:15,
2年前
, 34F
01/17 13:15, 34F
推
01/17 13:19,
2年前
, 35F
01/17 13:19, 35F
推
01/17 13:22,
2年前
, 36F
01/17 13:22, 36F
推
01/17 13:25,
2年前
, 37F
01/17 13:25, 37F
推
01/17 13:37,
2年前
, 38F
01/17 13:37, 38F
推
01/17 13:38,
2年前
, 39F
01/17 13:38, 39F
推
01/17 13:41,
2年前
, 40F
01/17 13:41, 40F
推
01/17 13:44,
2年前
, 41F
01/17 13:44, 41F
推
01/17 13:45,
2年前
, 42F
01/17 13:45, 42F
推
01/17 13:53,
2年前
, 43F
01/17 13:53, 43F
推
01/17 13:58,
2年前
, 44F
01/17 13:58, 44F
推
01/17 14:03,
2年前
, 45F
01/17 14:03, 45F
推
01/17 14:06,
2年前
, 46F
01/17 14:06, 46F
推
01/17 14:10,
2年前
, 47F
01/17 14:10, 47F
推
01/17 14:10,
2年前
, 48F
01/17 14:10, 48F
推
01/17 14:15,
2年前
, 49F
01/17 14:15, 49F
推
01/17 14:28,
2年前
, 50F
01/17 14:28, 50F
推
01/17 14:33,
2年前
, 51F
01/17 14:33, 51F
推
01/17 14:35,
2年前
, 52F
01/17 14:35, 52F
推
01/17 14:51,
2年前
, 53F
01/17 14:51, 53F
推
01/17 14:52,
2年前
, 54F
01/17 14:52, 54F
推
01/17 15:26,
2年前
, 55F
01/17 15:26, 55F
推
01/17 15:49,
2年前
, 56F
01/17 15:49, 56F
推
01/17 16:39,
2年前
, 57F
01/17 16:39, 57F
推
01/17 16:52,
2年前
, 58F
01/17 16:52, 58F
推
01/17 20:06,
2年前
, 59F
01/17 20:06, 59F
→
01/17 20:06,
2年前
, 60F
01/17 20:06, 60F
推
01/17 20:22,
2年前
, 61F
01/17 20:22, 61F
推
01/17 21:26,
2年前
, 62F
01/17 21:26, 62F
推
01/17 22:51,
2年前
, 63F
01/17 22:51, 63F
推
01/18 09:10,
2年前
, 64F
01/18 09:10, 64F