從零開始獨立游戲開發(fā)學習筆記（三十五）--游戲設計學習筆記3--《游戲設計藝術(shù)》3
很久沒有走這條路了，設計雖然學起來不難（實際使用之前），但是東西還蠻多的。
1. 游戲通過迭代提高
1.1 決策
很多時候，我們需要對創(chuàng)意進行判斷和取舍。我們可能擁有一大堆的創(chuàng)意，但是其實并不太能確定到底哪個創(chuàng)意好。
（在 Unity 官方的 Creative Core 教程中其實有一節(jié)專門講到?jīng)Q策行為，關(guān)于這個教程我有專門寫的文章。但是我并沒有把決策行為寫到文章里，因為我覺得官方教程給的建議沒什么用。）
而游戲設計藝術(shù)里給的建議則是我認為比較有價值的：
直接用，直接去實現(xiàn)。當做的時候再去決策，發(fā)現(xiàn)不好的時候就去放棄。
我認為這個方法比起官方教程的有道理的地方在于：
在實際上手之前，所有的猜測都是沒有具體細節(jié)，也沒有環(huán)境的猜想。只有實際上手后才能有更多的視角。如果更近一步，實現(xiàn)出來后，到時候理解肯定也會更深入。那時才是最了解這個決策的優(yōu)缺點的時候。
很自然就能想到，在毫無細節(jié)的時候，也就是剛開始的時候，幾乎就不可能有真正好的一個理解，除非以前做過有經(jīng)驗。
當然這個建議并不好做，涉及到一些困難，比如說時間問題，以及人一般也不太愿意推翻自己做的決定。但是如果能夠克服這些困難或者做一些妥協(xié)，是比較有好處的。
1.2 八項測試
最終的設計方案出來后，需要接受以下 8 項測試。如果有一項沒通過，打回重來，并且還要再測一次。因為打回重來的時候，可能改好了一個，同時卻改壞了另一個。
（當然，不用那么嚴格，尤其是獨立開發(fā)者，如果測試和自己想表達的東西沖突的時候，還是遵循自己的想法，盡量滿足即可）
1.2.1 測試 1：自己滿足即可
第一個測試很簡單，你自己自身。或者團隊成員（如果有的話），對這個設計的直覺上的滿意。
直覺不一定對，但是缺點會被其他測試彌補。因此還是要選擇自己很滿意的設計來。
Q：這個游戲看起來不錯嘛嗎？
1.2.2 測試 2：目標受眾
你的設計是否符合目標受眾的要求。具體內(nèi)容會在后面講到。
Q：我們的目標受眾喜歡這個游戲嗎？
1.2.3 測試 3：體驗設計的如何
前面幾章一直在講如何提高游戲體驗。這個測試就是看這些技巧應用的如何。
Q：這個游戲經(jīng)過精心設計嗎？
1.2.4 測試 4：創(chuàng)新
很好理解，是否有玩家之前沒見過的內(nèi)容。
Q：這個游戲是否與眾不同？
1.2.5 測試 5：商業(yè)和市場
考慮到商業(yè)的話，會有非常多的考量因素，畢竟商業(yè)是非常難的事情。具體細節(jié)會在之后講到。（不過要相當相當后了，書里是第 32 章講商業(yè)，現(xiàn)在這里才到第 8 章）
Q：這個游戲能盈利嗎？
1.2.6 測試 6：工程
不是所有的創(chuàng)意都能實現(xiàn)的。你的創(chuàng)意很牛逼，你想做一個水系魔法師主角，幾百萬個水滴由玩家隨意操控。但你的程序員今天還在問你什么叫做 deep copy。
Q：這個游戲在技術(shù)上是否可實現(xiàn)？
1.2.7 測試 7：社交/社區(qū)
游戲好玩是一部分。但是還有一部分是在社交和社區(qū)上的。游戲是否能在玩家間迅速蔓延？是否有一個繁榮的社區(qū)？這些也會在之后講到（也是非常后） Q：這個游戲達到了我們的社交/社區(qū)目標了嗎？
1.2.8 測試 8：玩法測試
這個最重要的當然不能缺。游戲做出來后，趕緊去玩，有能力就去測試。找出實際游玩的體驗，對反饋進行改進。后面也會詳細講該內(nèi)容。（非常后）
設計過程中也許會有改變測試，而不是設計的情況。比如說有時候測試之后發(fā)現(xiàn)雖然預期目標人群的年輕男性完全不喜歡這游戲，卻對年長女性特別有吸引力。那之后測試的時候完全可以直接就把目標人群給改了。
1.3 15 號透鏡：八項測試
就是剛剛提到的 8 個測試。
1.4 迭代規(guī)則
前面已經(jīng)提到過，快速迭代的方法有一個致命缺陷。那就是很多時候，并沒有那么多時間，有時候開發(fā)一個特性就可能花一兩個月了。這個時候說拋棄掉再是下一個，確實有點傷。
一般來說，這和游戲類型相關(guān)。一些比較簡單的類型，如卡牌等。開發(fā)時間較短，可以在比較短的時間內(nèi)快速的迭代多次。
但如果你恰好就是那很難迭代，一次開發(fā)就要很久的類型的話。那就需要仔細地安排進度了，很多時候，設計和開發(fā)交替迭代循環(huán)。這個方式，當然，是沒有完美的可能性的。對于這種情況，就是在玩一個固定預算固定時間內(nèi)，盡量優(yōu)化進度和設計，讓游戲盡量完美的賭博。
所以很多時候，做游戲并不是達到完美，而是一個迭代游戲。在有限的時間和預算內(nèi)，盡量多的測試和該進。
迭代規(guī)則：你測試和改進的越多，游戲就會越出色。
迭代需要問自己這里兩個問題：
Q1：怎樣才能讓每次迭代都有意義？
Q2：怎樣才能盡可能快地進行迭代？
想要回答這兩個問題，我們需要參考的是軟件工程的經(jīng)驗，因為兩者很相似。
1.5 軟件工程的歷史
最開始，軟件工程師們開發(fā)沒有什么規(guī)則，就只是只在最開始盡可能的預測，然后開發(fā)。這通常會有巨大的問題。
1.5.1 瀑布模型
因此后來為了統(tǒng)一規(guī)則，出現(xiàn)了瀑布式流程，但是規(guī)則是統(tǒng)一了，瀑布流程卻是一個完全沒法迭代的規(guī)則。只是把整個軟件開發(fā)流程固定為：系統(tǒng)需求->軟件需求->分析->程序設計->編寫代碼->測試->運營。
可以看出模塊化的很好，但是沒有看到迭代的存在。事實上提出這個瀑布理念的人在論文里其實一直在強調(diào)迭代很好，瀑布流程應該加上迭代的能力。但是目前大多數(shù)瀑布流程在教學上都是以線性流程的方式出現(xiàn)的。
1.5.2 巴里·伯姆的螺旋模型
后來，1986 年，巴里·伯姆提出了螺旋模型，如下圖：
螺旋模型比較復雜，從中間開始，順時針向外旋轉(zhuǎn)。
模型包含許多的細節(jié)，不過我們不需要了解。只需要關(guān)注其中最重要的三個點：風險評估，原型和迭代。
可以簡單總結(jié)一下螺旋模型建議我們做的事情：
想出一個基礎的設計。
找出設計中最大的風險。
建立原型來消除這個風險。
測試在這個原型。
基于從原型中得到的結(jié)論，改進得到更詳細的設計。
回到第二步
重復這個循環(huán)知道系統(tǒng)完成。這個模型很好地解決了之前提出的兩個問題：
Q1：怎樣才能讓每次迭代都有意義？ A1：評估并消除風險。
Q2：怎樣才能盡可能快地進行迭代？ A2：構(gòu)建多個粗糙的原型。
后人在螺旋模型的基礎上做了許多改進，而其中最成功的方式則是赫赫有名的敏捷開發(fā)。
1.5.3 敏捷開發(fā)（agile）
或多或少，大家都聽說過這個名詞。無論是從老板的畫餅中，項目負責人口中，或者一些項目管理軟件的官網(wǎng)第一頁介紹中，都會出現(xiàn)這個名詞。
AGI 我們都知道，空軌的人物屬性都是用英文頭 3 個字母表示，小時候比較難理解的就是 SPD 和 AGI 不知道什么意思。敏捷開發(fā)這個詞聽起來很不像人話，也不太符合中文語法習慣，但想表達的其實就是快速開發(fā)的含義。
1.5.3.1 敏捷宣言
在 2001 年，一群軟件工程師在一個叫做雪鳥的滑雪圣地，提出了《敏捷宣言》。繼承了巴里·伯姆的思想，嘗試提出偉大軟件背后的價值觀和準則。宣言分為宣言本身，以及 12 條準則。
宣言本身如下：
個體和互動?勝過 流程和工具
可用的軟件?勝過 詳盡的文檔
客戶合作?勝過 合同談判
響應變化?勝過 遵循計劃
即是說，盡管右項有其價值，但我們更重視左項。
十二條準則如下:
我們最重要的目標，是通過今早并持續(xù)不斷地交付有價值的軟件使客戶滿意。
欣然面對需求的變化，即使在開發(fā)后期也一樣。敏捷開發(fā)利用變化，為客戶贏得競爭優(yōu)勢。
經(jīng)常交付可工作的軟件，相隔幾個星期或一兩個月，通常周期較短。
業(yè)務人員和開發(fā)人員必須相互合作，每一天都要。
激發(fā)個體的斗志，以他們?yōu)楹诵拇罱椖俊Ｌ峁┧璧沫h(huán)境和支援，輔以信任，從而達成目標。
不論團隊內(nèi)外，傳遞信息效果最好，效率最高的方式是面對面交談。
可工作的軟件是進度的首要度量標準。
敏捷過程倡導可持續(xù)開發(fā)。責任人，開發(fā)人員，客戶要能夠共同維持其穩(wěn)定的步調(diào)。
堅持不懈地追求技術(shù)卓越和良好設計，敏捷能力由此增強。
以簡潔為本，極力減少不必要的工作量。
最好的架構(gòu)，需求和設計來自自我組織的團隊。
團隊定期反思如何能夠提高成效，以此調(diào)整自身的舉止表現(xiàn)。
當然，敏捷開發(fā)還包含相當多的細節(jié)。這里不作深入講述。并且敏捷開發(fā)還有很多延伸版本。敏捷開發(fā)對電子游戲有很大幫助，相當多的電子游戲聲稱采用了某個版本的敏捷開發(fā)。
這里有幾個不同版本的敏捷開發(fā)都會涉及到的核心元素：
靈活的目標：（說實話原文沒看懂，感覺前后自相矛盾，甚至不太像人話）這里直接摘抄原話：“敏捷哲學的核心觀點是，我們無法精確得知計劃所需時間。通過圍繞一組更加靈活的目標制定計劃而不是忍受對計劃作出改變，要有計劃地改變計劃。在開發(fā)過程中，團隊能夠迅速適應新的創(chuàng)意和信息?！?/p>
優(yōu)先級列表：每次想到一個新的特性，就加入列表。然后每次迭代的時候，進行優(yōu)先度分級，先完成高優(yōu)先度的，再完成后面的。這個方法基于一個假設：永遠不可能完成所有的特性。但能夠完成重要的特性。
沖刺：敏捷開發(fā)會定一系列的小沖刺目標，一般是幾個星期完成某一目標，且需要在最后完成一個堅實的成果。沖刺背后的思想是 DDL 很有用。
爭分奪秒的會議：相對于那種每周一次超長的會議。敏捷開發(fā)更多是每天進行一次超短的會議，甚至可以站著開會，每個人只解釋三件事“昨天做了啥？今天準備干啥？現(xiàn)在遇到了什么問題？”在會議結(jié)束的時候，當面去找那些有問題的成員去解決問題。
演示日：每個沖刺階段的最后，大家聚在一起面對面地觀察和測試工作成果。然后在這個基礎上，大家一起進行風險分析，以及下一沖刺階段的目標。
回顧：每個沖刺階段的最后，還會有一個回顧會議。和演示日不一樣，這個會議不討論產(chǎn)品，而是工作流程。團隊成員每個人都有機會在此討論什么流程是正確和錯誤的，怎樣在下一沖刺階段調(diào)整這個流程。
用這種視角來看疫情期間影響的無數(shù)項目，就可以給出一個全新的觀點。
這些受到疫情影響的項目，很有可能就是因為敏捷開發(fā)受到限制的原因。敏捷開發(fā)極度強調(diào)面對面交談，快速的會議。但是疫情使得面對面不可能，同時遠程會議也相當累人，由于缺少眼神和面部眾多細節(jié)，獲取信息也少。
1.5 風險評估和原型設計
記住一點，敏捷開發(fā)不是一個既定的固定流程，所有項目直接按著來就行。敏捷開發(fā)只是一種思想，每個項目的敏捷開發(fā)的流程都不一樣。而這些不同流程的設計，核心就是風險評估和原型設計。
不跟你廢話，直接上案例：氣泡城的囚徒
假設你的團隊決定做一個關(guān)于城市跳傘的電子游戲。并且已經(jīng)對游戲元素進行了一個簡短的描述：
元素
還記得游戲構(gòu)成基本元素嗎？是這四個：劇情，機制，藝術(shù)，技術(shù)。
劇情：你是一只會跳傘的貓，名字叫“微笑”。氣泡城的居民都被一個邪惡的巫師困在房間里。你需要通過跳傘潛入城市，滑下煙囪，拯救市民，并找到阻止巫師的方法。
機制：在向城市跳傘的時候，你可以試著抓住從城市中升起的魔法氣泡。使用魔法氣泡的能量向邪惡的禿鷲發(fā)出射線，防止它們戳破氣泡或者撕碎你的降落傘。同時你必須控制降落傘到城市中的幾個目標建筑之上。
藝術(shù)：卡通風格的外觀和游戲體驗。
技術(shù)：使用第三方引擎的，多平臺的 3D 主機游戲。
很好，現(xiàn)在一個美術(shù)普通，無聊，手感稀爛，Steam 評論好評如潮，銷量 1000 份的每天都可以看到的 3D 運動游戲躍然紙上。（不是）
現(xiàn)在你有了這些元素，你可以開始制作游戲了。
第一個方法是，現(xiàn)在立刻開始制作。寫代碼，設計關(guān)卡，角色動畫，直到做完，然后看一下做出的成品咋樣。
但是這有巨大問題。假設這個項目持續(xù) 18 個月，你花了 6 個月做了第一版，開始測試。然后發(fā)現(xiàn)，玩法不好玩，咋辦？或者做到第 5 個月發(fā)現(xiàn)，引擎做不成這個特性，咋辦？花了 1/3 的時間，卻只完成了一次迭代，這就是問題。
第二個方法，也是正確的方法。是和團隊一起做一個風險分析，把所有可能會危害到項目的風險列成一個列表。對于剛剛這個游戲，你可以列出以下風險列表：
風險列表
收集泡泡/射擊禿鷲的機制可能并不有趣。
游戲引擎可能無法繪制整個城市，禿鷲，以及其氣泡。
我們目前的想法是有 30 種不同的房子。但我們可能沒時間畫那么多，包括設計和動畫。
我們不確定人們是否會喜歡我得角色和動畫。
今年夏天有一部關(guān)于跳傘的電影會上映，發(fā)行商可能會要求我們以此作為主題。
假如只考慮這些風險，我們該怎么做呢？為了實現(xiàn)風險消除，我們就需要做原型開發(fā)了：
對于第一個風險。我們可以以一種非常簡單的方式將其實現(xiàn)，用一些簡單的幾何形狀來代替。然后快速開發(fā)原型，試玩，判斷是否有趣。不停迭代直到其變得好玩。也許你會覺得，做了這么多原型，寫了這么多代碼，這些代碼可能之后永遠都用不上，很浪費。但是其帶來的迭代時間上的節(jié)省，以及游戲質(zhì)量的提高，是比較合理的。
對于風險 2，解決方式就是在屏幕上展示預估的數(shù)量的相同物品，看引擎是否能夠承受。這個原型不測試玩法，只專門用來測試性能。
風險 3 的話，就是讓藝術(shù)家先畫一個房子，計算出單個的時間，然后評估整體的時間。如果發(fā)現(xiàn)無法介紹，那就需要對設計進行相應的變化。
第 4 個風險，往往不是游戲原型。而是一個藝術(shù)原型，讓畫師繪制作品，或者渲染出 3 位建模。曝光在媒體，最好是目標人群前。觀察其是否喜愛。整理出喜歡和討厭的原因。對角色和動畫進行改動。
風險 5 聽起來很怪，但卻是經(jīng)常發(fā)生的。這種情況一個原型可能就沒用了。你可以在制作游戲的時候讓其變得容易修改成電影化的樣子?；蛘咧谱鲀蓚€游戲的計劃，等等各種有的沒的可能性。
1.5.1 16 號透鏡：風險消除
具體細節(jié)都是上面講的內(nèi)容了。
問自己這幾個問題：
有哪些可能的風險？
我們怎樣防止這種風險發(fā)生？
面對風險是一件比較難的事情，因為很多時候人不想面對這些問題。這是一種誘惑，只專注于自己自信的事情（就像我遲遲不學美術(shù)和音樂一樣）。必須抵抗住這種誘惑，來解決這些風險。
1.5.2 制作原型的 10 個秘訣
技巧 1：回答一個問題
每個原型必須得回答一個或者多個問題。不然原型就是在浪費時間。
這個原型是用來測試玩法的？還是性能的？還是角色設計？等等。
避免過度構(gòu)建原型，別做著做著開始打磨原型了。原型只專注于解決問題。
技巧 2：忘記質(zhì)量
不要把原型做的太精致。這不只是浪費時間的問題。甚至，一個在別的方面做的太精致的游戲。可能會讓人忽視掉它的問題。
比如說你做一個玩法測試，然后你玩法本身其實不行，但是你美術(shù)和音樂和劇情做的太好了。測試者都玩哭了，根本無視掉玩法怎么樣了，玩完告訴你這游戲太棒了。你就會得到錯誤的情報，你的玩法并沒有實際上得到驗證。
技巧 3：不要太過留戀
沒什么好說的。字面意思。不要覺得拋棄掉原型是浪費。
技巧 4：設定原型的優(yōu)先級
就像在敏捷開發(fā)里提到的一樣，給原型設定好優(yōu)先級。優(yōu)先完成高優(yōu)先級的原型。
在評判優(yōu)先級的時候，需要考慮到依賴性。比如一個原型的成功與否關(guān)系到別的原型有沒有意義，那這個原型無疑是非常高優(yōu)先級的。
技巧 5：有效的并行原型
因為原型專注的問題比較少，因此對于團隊來說，完全可以多個原型并行進行。技術(shù)構(gòu)建玩法原型，美術(shù)構(gòu)建藝術(shù)原型，等等
技巧 6：并不一定要數(shù)字化
就像之前提到的，原型不一定是程序，也可能是畫，3D 建模，一個發(fā)布到社交網(wǎng)站上的 gif 圖。
有些時候，甚至可以是一個紙上的原型。比如數(shù)值，規(guī)則之類的。當然，前提是你覺得在紙上做這些比用電腦制作花費時間短。
技巧 7：無需交互
原型并不一定能夠交互?？赡芫椭皇钦故疽恍┢?。還是那句話，注重要解決的問題，其他的打磨都是沒有必要的。
技巧 8：選一款能快速迭代的引擎
反正最后都是要拋棄的。并不是說你用 Unity 制作游戲，原型也一定要用 Unity 來做。市面上有很多專門為原型制作而產(chǎn)生的工具。用那些工具能更快的出效果，也許自定義度不夠，但那沒關(guān)系，原型里不需要用即可。
比如說像是 Unreal 其實就可以用藍圖來做原型設計。真實開發(fā)再寫 C++。
技巧 9：先構(gòu)建玩具
玩具和游戲的區(qū)別在于，玩具本身就很好玩。
棒球游戲中，球是玩具，整個過程是游戲。一個能跳的水管工是玩具，《超級馬里奧》才是游戲。
當然不是說主角才是玩具，比如說《GTA》的設計時，玩具是那個城市，這個城市栩栩如生，已經(jīng)很好玩了。然后我們再添加主角進去和進行互動，等等細節(jié)。
《見證者》中，蝌蚪文就是玩具，剩下的就是等游戲自己把自己做出來了。
當玩具和游戲都有趣了，就會擁有兩個層級上的好玩。蔚藍的人物手感已經(jīng)就很好玩了，光是在一個地方跳來跳去就已經(jīng)足夠有趣，后面就只是擴展了。
17 號透鏡：玩具
問自己這幾個問題：
如果我的游戲沒有目標，那它還好玩嗎？如果不是，怎么改進？
人們看到我的游戲，能否在不清楚玩法之前，就已經(jīng)想跟它互動了？
這個透鏡有兩種使用方式：
第一種是在一個游戲已經(jīng)開發(fā)好的時候，使用該透鏡，讓其具有玩具的特質(zhì)。
第二種是在游戲開發(fā)之前，先做一個玩具出來，再圍繞著它做成游戲。
技巧 10：抓住迭代的機會
像有些時候，比如說移植到新的平臺的時候?？梢园堰@當做一次迭代的機會，再次提高游戲的質(zhì)量。
1.6 一些工業(yè)預算法則
工業(yè)上，開發(fā)游戲有著各種各樣上的限制，尤其是預算和時間。作者自己總結(jié)了兩個工業(yè)上，避免預算不夠的法則：
1.6.1 計劃性削減預算法則
計劃游戲的時候。確保當你的 50% 的預算被削減了，依然能做出一個可玩的版本，即使放棄了一些別的特性。這個法則要求你的核心系統(tǒng)不要過于復雜。
1.6.2 50% 法則
所有的核心玩法應該在前半段時間里完成。即用一半的時間讓游戲變得可玩，用剩下一半時間讓游戲變得更好。
1.7 你的秘密燃料
1.7.1 18 號透鏡：激情
一直帶著之前的分析來思考游戲，會很容易忘記初心。每次完成一個原型并消除風險后，問自己這幾個問題：
我對這個游戲的成功還有極大的激情嗎？
如果我失去了激情，怎樣才能找回它？
如果激情沒有回來，我是不是該做些別的？
如果你自己都會游戲失去了激情，也許這個游戲在哪些方面是有問題的。必須找到這個問題所在，否則你的游戲很容易死去。
但同時，激情也可能有危險，因為激情是不合理的，需要小心對待它。
2. 自己的想法
看到這種反自我表達的風險評估，毫無感情的工業(yè)法則，以及居然要專門為失去激情做一個透鏡，就覺得挺難受的。一個工作居然需要我使用技巧來避免失去激情，還挺難過的。
因此這一部分的內(nèi)容，我決定選擇性參考。不過迭代的思想，風險評估等我覺得還是很有用的。
