遊戲設計與現實的距離，你憑什麼說這個設計一定有效？

在之前的戰棋遊戲設計相關文章收尾篇中我提到過一個（主幹）體驗機制（反饋）（程度）的概念，之後的話題將暫時圍繞著這個概念進行展開。對於那篇文章中的體驗機制相關模型圖，請忘記那張圖，因為我發現有一半畫錯了。

說回正題，人們常說理想很美好，現實很殘酷，這個說法在遊戲設計中尤為常見，也是遊戲設計師在進行設計經常對自己，當然更多是針對他們的策劃同事所發出的靈魂拷問：你憑什麼說這個設計一定有效？

所謂的“有效”實際上是一個很大的概念，既包括設計者層面，也包括玩家層面，這裡就不一一列舉了。但是對於瞭解與研究體驗機制這個問題而言，分清設計與現實的距離無疑是第一步。


作為本環節的第一章節，在用例遊戲的選擇上相比《賽博朋克2077》，倒不如先從《只狼》說起。


他可不是亂打啊！

為了更好的說明相關問題，我專程去請教了一下屑一郎老師，但是屑一郎不愧是屑一郎，我誠心找他請教問題，他死活都不告訴我就算了，上來就給我來了幾刀，還讓我好好看好好學，好在我也是有備而來。

對於這段動作我們作兩段拆分，將其分為“流程”與“看破”，我們先說看破。通過GIF-1可以很清晰的看出，當弦一郎使用突刺時，狼不但貪了一刀，甚至還提前使用了墊步，但就結果而言，貪的刀既沒有打斷絃一郎的突刺，同時提前使用的墊步在移動一小段時間後，仍然成功觸發了“看破”，由此我們可以很容易地得出兩點戰鬥邏輯結論，即：狀態判定與時序判定。

這是非常好理解的兩點，用大白話來講就是弦一郎在使用突刺的時候我砍他，他不會被打斷而改變狀態，突刺行為會執行直到結束，狼在使用墊步來破解突刺的時候存在時間判定，雖然圖中狼提前使用了墊步，但是由於觸發“墊步”後，狼的狀態仍在“看破”被啟用（或程式規定）的有效時序內，因此即便撞到弦一郎的臉上，狼依然能 夠對突刺進行“看破”。

現在再來看看“流程”，我問屑一郎老師，雖然每次狼砍你的時候，你幾乎都能刀刀擋住，整的跟絕對防禦似的，請問你是裝了自動格擋的外掛嗎？（弦一郎：你剛才第一刀不是砍我身上了嗎？！）

在GIF-2中，狼和絃一郎一共拼了四刀，通過觀察可以發現，在第一刀的時候狼與弦一郎均使用了揮砍，但奇怪的是弦一郎在使出第一刀的過程中出現了左側舉刀揮砍，左側收刀的反人類行為現象，如果再結合第三刀的狀態結果，那麼這是否意味著在戰鬥的邏輯設計層面，遊戲在程式上就做出了當BOSS受到玩家的攻擊時，通過狀態環境或是狼的起手判定，AI就可以實現將攻擊行為強行改變為格擋行為的程式設計？

然而在第四刀中，弦一郎右側舉刀左側落，揮刀軌跡完整流暢的同時還成功與狼實現了一次擊劍打鐵，如此看來這一套“打鐵式”的基礎戰鬥邏輯，好像並不簡單，既然如此，那就多拼幾刀吧。

與之前的四刀不同，這裡狼使用了一套緩慢劍法，狼揮出去的第一刀可能有點快，但是我們還是可以很清楚的看到弦一郎應對第一刀時採用了“格擋”；但是觀察第二刀接第三刀與第三刀接第四刀這兩個過程，在狼都不是即刻出刀的情況下，弦一郎分別選擇了轉身砍接鎖喉與移動格擋，如果考慮狼的第二刀情況，弦一郎還進行了一次拉弓射箭動作，似乎這確實有點在狀態機上做針對狼的起手判定的感覺？答案開始接近了。

為了進一步觀察，狼在接下來的戰鬥中選擇以防禦為主，結果就不用我多說了，一通亂打，得寸進尺。

但即便如此，弦一郎在這整個戰鬥過程中都沒有出現與狼平砍拼刀時相似的平A的行為，整個過程幾乎都是由技能化的招式構成的連段攻擊。換句話說，這似乎意味著狼沒有起手向弦一郎發動攻擊，因此弦一郎也不會主動去找狼擊劍，而是根據既定設計中的判定來啟用一套預設的進攻程式動作。

現在我們再回頭看GIF-2中的第二刀，在第二刀中我們可以很清晰的看出這一招中弦一郎主動發起攻擊，並迫使狼選擇了格擋，如果狼此時選擇攻擊，那麼是否會使弦一郎更改狀態判定並觸發擊劍打鐵呢？答案是否定的。


在GIF-5中，狼在第三刀時沒有選擇格擋，而是繼續進攻，結果在對刀的過程中由於硬直狀態導致慢於弦一郎出手（同時出刀速度也不及弦一郎），導致自己受到了傷害。

現在結論就很清晰了，在狼與弦一郎擊劍的流程中，弦一郎會根據與狼的距離等環境狀態與狼的行為起手判斷做出判定，當狼向弦一郎發起攻擊時，弦一郎會通過針對性的動作，無論看起來是“格擋”行為還是看起來像揮砍的攻擊行為，最終都會應對狼的攻擊，和狼完成一次“打鐵”，然而在相互應對的過程中，弦一郎也會暗施小計，在反覆的“應對”行為中夾雜進攻性的動作以迫使狼改變戰鬥行為，通過GIF-2與GIF-5也可以很清晰的看出這些動作都有很明顯的特徵，即有明顯的揮刀軌跡；如果狼在與弦一郎的戰鬥中不選擇主動出擊，那麼弦一郎就會根據如環境中的距離判定，主動向狼發起一連串的“連招技能”，迫使狼不斷地防禦並遭受來自遊戲機制，或是玩家自身心理的壓力。但無論如何，從戰鬥形式設計與表現結果上看，狼與弦一郎拼刀戰鬥的過程就是我們所說的“死鬥”（打鐵）。遊戲通過攻防一體的應對性判定，不同情況下的狀態判定與行為觸發後的時序判定三種設計，共同構成了《只狼》的基礎戰鬥邏輯，並完成了對“死鬥”的還原設計與體驗現實實現。

不過所謂的設計實現並非僅僅依靠對遊戲層面的設計，那不過是一個概念還原的過程，使設計成功實現的關鍵在於對玩家遊戲行為的依賴，這一點將留至後文說明，先繼續說完剩下的“設計”。

你在教我打遊戲？

通過對《只狼》基礎戰鬥邏輯的分析，對於“打鐵”或是“死鬥”，無論在戰鬥流程層面，形式層面還是最後玩家的體驗層面，通過邏輯構成與實現效果，我們現在都有了一定的概念，但在實際的遊戲設計中，顯然作為一個BOSS單位，僅僅只是基礎的戰鬥邏輯肯定是不夠的，強大的敵人自然也需要強勁的招式，而對於強勁的招式玩家能否迎刃而解，也直接影響了這場“死鬥”是否精彩。


正如GIF-6中這一套刻在DNA裡的跳劈突刺，BOSS都不是隻會平A和防禦的傻瓜，他們總是會被設計一些殺手凌厲或是奇奇怪怪的招式技能，進而改變玩家的遊戲體驗。但用單純的“傳統遊戲體驗”分析去看待設計是不夠的，我們需要進入體驗機制的層面看問題。同樣以GIF-6的跳劈系列動作為例，如之前分析基礎戰鬥邏輯的那樣，還是先從設計的角度出發。


雖然弦一郎在不同“形態上”的動作衍生邏輯存在一定的出入，但就破解這些“招數”的方法而言，玩家的解法顯然是固定的，當看見弦一郎起身跳起時按下格擋，接下劈擊後如果看見弦一郎的刀刃閃光就立刻按下墊步，如果看見弦一郎轉身，狼的頭上出“危”，就立刻按下跳躍，如果是巴流的限定動作，則在成功格擋挑斬後保持冷靜，直到聽見弦一郎的喝聲後立刻按出墊步即可（GIF-7）。

通過減緩一半的播放速度，雖然感受不到“死鬥”中緊張的戰鬥節奏，但是對弦一郎的招式流程與相關破解卻可以進行很清晰的觀察。如果從時間的角度去分析，將每一次動作處理看作是一個QTE事件，那麼還原至現實玩家進行遊戲的環節中也不難得出玩家在戰鬥中，對BOSS每次一動作或戰鬥機制的拆解，就是一個QTE實現的過程。

但就QTE這個設計的形式而言，顯然是不能一概而論的，正如GIF用例與實際遊戲的表現那樣，玩家在面對要求3秒內完成QTE與要求在1秒內完成QTE，其結果必然是不同的，何況再增加對QTE事件處理的容錯率限制呢？

櫻舞是2020年DLC更新後弦一郎獲得的一個強力招式，玩家必須對三次揮砍進行“完美格擋”，否則即便處於防禦狀態，狼依舊會受到破防傷害，而櫻舞相對與之前的跳劈白給系列動作，玩家只能通過觀察進入應對狀態，通過經驗與熟練的技巧在弦一郎進行第一刀揮砍後立即按下兩次格擋，其中玩家在面對第三刀時更要求冷靜與觀察，在片刻（差不多是狼一次格擋啟用的時間）的停頓後再按出第三下格擋，以完成對櫻舞的完美防禦。

當然，無論是白給的跳劈系列動作還是殺傷力極大的櫻舞，弦一郎的這些動作都不會是完全獨立的，如果仍要以QTE的角度去立即，那麼顯然在QTE處理時間和玩家處理容錯率的基礎上，如何設計QTE之間的comb，增加玩家處理的複雜難度，顯然又是遊戲在體驗構造中的一次質變。出於對篇幅和閱讀時間的考慮，文章將對部分動作進行簡單的舉例說明。


弦一郎在回身斬擊後會進行移動，之後在玩家身邊打出一個鎖喉“危”。由於弦一郎斬擊的速度很快，如果玩家不能在弦一郎轉身前通過攻擊打斷，那麼玩家面對的選擇只有防禦，受擊，以及揮刀與弦一郎同時吃到傷害，但之後弦一郎後續的鎖喉會被打斷。（突然用原速播放會不會有些不適應呢？）


與用墊步解突刺不同，格擋解突刺存在條件且無任何收益。玩家必須保證突刺的觸發位置處於狼的格擋判定範圍內，這意味著格擋只能對上身段的突刺進行防禦，面對下段突刺時不會觸發。此外格擋突刺不會對BOSS造成軀幹值懲罰。


射箭，翻滾，側擊，實際上這是一個很有意思的設計，意在考驗玩家處理來自不同方向攻擊時調節視角與站位的操作能力，但是在實際的戰鬥中因為攝像機鎖定的設計，導致狼會自動向弦一郎的方向進行旋轉，這就是一種設計與現實的距離，理想很美好，現實表現卻沒達到預期。


但攝像機也並非一直有利於玩家，在特定的環境中也會讓玩家非常火大。

飛渡浮舟沒啥好說的，快速彈反的壓力與驗證點。重點是在心中弦一郎在動作上的設計邏輯，通過飛渡浮舟施加玩家軀幹值壓力，之後拉開距離進行射箭，在保證玩家有一定緩衝時間與空間的前提下最後以櫻舞收尾，在播放速度減半的前提下，其實也沒啥難度。


更新後經典雷反櫻舞雷反櫻舞套娃，其實仔細觀察可以發現狼在第一次雷反直到命中的時候弦一郎始終是出於落地格擋狀態的，但是這不代表玩家在進行櫻舞雷反的時候，狼可以位於地面，如果從之前的分析角度來看，這樣的設計同時包括了對玩家的反應時間與對複合機制處理的考驗。


實際上還有比較多的素材，比如一些動作的打斷機制，設計與現實的差異等，不過這個環節可以點到為止了，最後就給出幾個有趣的素材提供思考方向吧。





很難……嗎？

說起魂like遊戲，總是會不可避免地聯絡到“高難度”或是諸如“受苦”之類的話題，但實際上就《只狼》而言，通過剛才對弦一郎的簡單戰鬥邏輯與部分動作的設計分析，尤其是在GIF中播放速度減半的情況下，觀察下來似乎這個遊戲並沒有那麼難啊？（大噓）

好吧，遊戲的確存在難度，這一點是毫無疑問的，但是所謂的“難度”是在玩家進行遊戲行為，在體驗遊戲後得出的總結性概念，如果要對這個概念進行拆解與分析，顯然對於“難”和“度”的討論是最直接的思考方向。

既然如此，基於前文的內容鋪墊，再聯絡設計與實現的角度，可以很容易列舉出一張表格（同上文一樣，考慮到表格容量空間問題，因此表格中僅對標誌性動作行為作舉例說明）：




在表格中，可以很容易地發現，如果玩家想處理好弦一郎的動作機制並戰勝弦一郎，那麼玩家熟練遊戲與對應的操作幾乎都是“應對方案”的基礎條件。那麼從玩家在遊戲中的現實情況與遊戲難度的角度來看，玩家之所以覺得遊戲很難，是因為玩家在遊戲過程中，遊戲出現的機制處理或QTE超出了玩家現階段掌控的技巧運用能力，玩家必須要通過觀察與反覆的練習，學習弦一郎的櫻舞動作，實現對櫻舞的完美彈反，通過不斷地重複，保證弦一郎每一次突刺時玩家都可以按出看破，弦一郎每一次進行下段攻擊時玩家都可以按出踩頭……

換句話說，遊戲的難度一方面既是客觀存在的，一方面也是主觀存在的，對於客觀的角度而言，設計師在設計遊戲時就已經給出了一個尺度標準，玩家就如同沒有複習，直接進行第一次考試的考生，會就是會，不會就是不會，遊戲在設計時本身就為其實現後的“距離”定下了一個標準的“門檻”；而對於主觀的角度，則是玩家在考試中受挫後，對該挫折學習，複習，乃至熟練，最後一步步完成整個答卷的過程，在這個過程中，遊戲設計與其現實實現的“距離”是動態的，同時它也會根據玩家對技巧的學習情況逐步縮短。這兩種不同的難度尺度標準，共同構成了遊戲設計與遊戲現實實現的距離。

結論：第一條曲線

因此通過以《只狼》為案例遊戲，從“設計”與“現實”兩方面進行了分析，現在可以得出本文，也是“體驗機制”的第一條曲線結論了，即“玩家的學習曲線”。


對於參與遊戲行為的人而言，“玩”可以說是再也正常不過的行為了，但問題是每一個玩家都“會”玩遊戲嗎？在MMO遊戲中你要去戰鬥，那麼就必須要懂得職業技能的迴圈，想要精通戰鬥，那麼閉著眼睛在鍵盤上滾出迴圈就是基礎；在策略遊戲中，玩家不但要通過學習懂得自己“how to win”，也要在遊戲中懂得自己的對手“how to win”，從而在博弈的過程中實現玩家的高策略對決；至於說手遊，玩家學習曲線所反應的問題將表現得更加明顯，不過這是在第三章涉及到的內容，所以就不做展開了。

而圖中的第二條線，理想的體驗反饋與其周圍的虛線，在之前的戰棋話題文章中，我在此處標註的是“主幹體驗機制”。正如我在文章開頭所言的那樣，這是我犯下的一個錯誤，把模型畫錯了一半，但好在只是一個名詞誤用問題，模型背後大體的意思沒有太大變化。不過，“理想的體驗反饋”不能單獨拿出來看，它必須同玩家的學習曲線進行組合分析，因此我將在之後的第二篇文章中進行論述說明。單就以本文的內容和案例遊戲的例項說明情況而言，在大致的概念上其實也不是很難去理解，最直觀的結論就是玩家的遊戲技巧學習成長掛鉤遊戲的核心體驗反饋，但這終究只是皮毛，冰山在海平面下到底還是藏了不少東西。

結語

可能有人會覺得奇怪，講了這麼多東西，說白了就是在強調玩家的技巧，這和遊戲的體驗機制有什麼關係？何況以《只狼》這種魂like“硬核”遊戲作為案例，本身就存在一種特殊性，很難去說明普遍性問題，比如推箱子的AVG遊戲，壓根就不存在有多少技巧或是玩家“學習怎麼去玩遊戲”的問題……

這些都是很正常的想法，但實際上卻並非如此。首先體驗機制作為一個全新的概念，在這篇文章中我僅僅只是把這個理論中一個環節中的四分之一部分進行了形象的大體闡述，對於體驗機制這個概念而言，也只是出於“鋪墊”層面。同樣對於玩家遊戲技巧相關的看法，也會是一個全新的分析與研究角度，只不過是因為玩家在遊戲中的“學習”與“技巧”恰好都是構成遊戲體驗的|“機制”基礎罷了。

至於觀點與結論是否會因為案例遊戲的特殊性而難以說明普遍性問題，這一點完全不會，因為正如“體驗機制”這個詞語的概念一樣，它代表的是一個機制原理，而非具體設計方法，不管是正兒八經的遊戲，還是從流水線走過的產品遊戲，即便是“硬核”的反義詞，簡化甚至輕量到玩家只需要通過點選對話推進劇情的AVG文字冒險遊戲，我們得出的“玩家學習曲線”依然適用。

當然，這種適用並不是“生搬硬套”就能實現的，設計師必須換一個角度，如同從一個練習冊或試卷的出題人，搖身變成了課堂上的老師，而這些就是第二篇文章的內容了。

（文中部分gif圖有作刪減示意）


目前求職中，聯絡方式roundtable0d000721@yeah.net。