OCR迴圈:說說遊戲中的挑戰與體驗
本文出自知乎問題“如何平衡遊戲難度與遊戲體驗?”伯卿丶遊吟的回答:
https://www.zhihu.com/question/627312930/answer/3260484793
前言
這篇文章整理自一個回答,如何平衡遊戲難度與遊戲體驗?雖然題主問的主要是玩家的角度,但是我引申了設計角度下挑戰設計和體驗的關係。也萌生了將這部分理解整理一下的思路。希望這篇文章可以幫助到設計師夥伴們。
什麼是挑戰和體驗?
從遊戲設計的角度來說,挑戰是玩家在遊戲過程中需要面對的考驗,一個完整的挑戰(Challenge)是“運用玩家能力+掌握角色技能+克服障礙”構成的。
體驗某種程度上可以說是由目標(Objective)、挑戰(Challenge)和獎勵(Reward)構成的OCR迴圈的整體。良好的體驗是建立在明確的目標、合適的挑戰、以及挑戰相匹配的獎勵這樣的基礎上的。
具體來說,挑戰是怎麼設計的?
通常來說,我們可以把玩家的能力概括成為八大型別:
- Timing時機:考驗的是玩家能否抓住某個時間視窗
- Reflexes反應:考驗的是玩家能否在規定時間內作出正確應對
- Precision精準:考驗的是玩家能否精準地命中目標或其他方式與其互動
- Measurent衡量:考驗的是玩家能否在空間中掌握好某個尺度
- Tactical Choices戰術選擇:考驗的是臨場的戰術反應和決斷
- Strategy策略:考驗的是玩家全域性的策略與戰略思維
- Management管理:考驗的是玩家對於資源的調配與使用
- Cleverness機敏:考驗的是玩家收集線索,推理答案的能力
前四個更偏向於機體能力(客觀能力),後四個更偏向于思維能力(主觀能力)。客觀能力往往有著比較明顯的人體上限,比如正常人的反應速度在300ms左右,小於100ms的Timing考驗幾乎是不可能的。而主觀能力則擁有更大的可能性,幾萬種可能性中的唯一解也是可以被玩家不斷嘗試出來並穩定復現的。
那麼一個挑戰的設計,往往就是從選擇什麼樣的玩家能力考驗開始的。然後是確定需要用到(遊戲中的)角色什麼能力,玩家是否熟練掌握。最後是根據前兩者來設計合適的障礙。而挑戰難度的組成也可以從兩方面來看待,“主觀維度”取決於玩家能力考驗的“困難度”與“複雜度”;“客觀維度”取決於“角色能力”與“玩家掌握度”。
補充來說,困難度就是玩家能力考驗的苛刻程度,複雜度就是玩家能力考驗種類的組合複雜度。角色能力包括角色的數值,屬性,掌握的能力種類等等,玩家掌握度則是說玩家是否知道角色能力的所有使用方式,適用範圍,以及衍生效果等等。
挑戰如何服務於體驗?
我們總是希望玩家能處在成長和挑戰交替上升的心流中。即:讓玩家感受到成長——玩家開始掌控遊戲——讓玩家接觸更高的挑戰——玩家開始激發鬥志——克服挑戰後玩家再次獲得成長,這樣的迴圈中。那麼設定與玩家能力相匹配的挑戰,以及讓玩家獲得有意義的,有成就感的獎勵就至關重要。畢竟,我們不希望玩家玩的無聊,或者過分挫敗了。
所以我們在設計挑戰時,需要衡量玩家此時的狀態,需要一個超出其之前舒適區多少的挑戰。如果玩家剛剛掌握某項能力,整個體驗流還在逐漸積累的過程中,那麼我們可以提供比較溫和的挑戰,讓玩家在過程中熟悉與掌握(這有會涉及教學Tutorial部分的設計思維)。而如果體驗流已經進入高潮,需要一個足夠的挑戰來檢驗玩家是否真正掌握到此為止的遊戲內容,那麼就適合設計一個比較難的挑戰,並且讓玩家有所預期。最常見的就是一場BOSS戰鬥了。大多數時候,讓玩家之前依賴的某個戰術失效,但是如果玩家可以活用能力仍舊可以克服困難最終贏得挑戰,是一個不錯的設計思路。(這也常出現在謎題Puzzle挑戰中)
挑戰往往是與情感激烈程度掛鉤的,而情感是體驗的重要構成部分。在挑戰中增加針對性的設計可以讓玩家體驗到不同的情緒。比如震動,環境崩塌,傾斜相機等干擾加持下的挑戰,會給人一種不安定、危機感。不斷迫近的敵人和負面環境元素可以讓玩家不再戀戰,希望儘快轉移。而如果想讓玩家復仇之火熊熊燃燒,眼中只有仇敵地心無旁騖地戰鬥,則可以使用高爾夫球杆(不是)……則可以使用扭曲空間,色彩和光照聚焦敵人等的設計手法,輔助以心理活動與暗示。
獎勵(Reward)也很值得一講,但是我覺得可以另開一篇文章來說,給自己先留個坑。
怎麼知道是設計出了問題還是挑戰對我來說太難了?
可以沿剛才的思路的自我剖析一下,如果是以下的情況:
- 遊戲中存在提升角色能力的渠道,但是你並不知道
- 這個挑戰需要玩家使用一項現在還沒有的能力,但是你並不知道
- 你感受到的不是挑戰的難度(Hard),而是敵人在玩賴(Unfair)
- 你感受到的不是自己的技術(Skill)被檢驗,而是憑藉運氣(Luck)才能完成
- 你搞錯了目標(Objective),在嘗試的並不是遊戲預期設計的挑戰(Challenge)
- ……
那麼我們可以說,這個挑戰設計是有問題的。要麼規則不合理,要麼提示不到位。這也是我們設計師所儘量避免出現的情況。所以我們在使用者測試的時候會非常關注這一點。
而如果是以下的情況:
- 這個挑戰對某一項玩家能力要求過於苛刻,超出你的能力。
- 這個挑戰對多項玩家能力要求過於複雜,超出你的能力。
- 角色能力遠低於挑戰的建議能力,但是你想嘗試。
- 你知道可以有更輕鬆透過的方式,但是你想嘗試一種更具挑戰性的打法。
- ……
那麼我們可以說,當前玩家不適合這個挑戰,他現在的難度超出了你的能力範圍,你可以試著提升自己的能力或者遊戲中角色的能力來適應這個挑戰。從設計的角度來說,玩家在這次Skill Test過程中被認為是“不透過”的。
宏觀角度來說,如果實際整體透過情況滿足設計預期,那麼這個挑戰本身沒啥問題,而是玩家在挑戰高難度的內容。反之,如果實際整體透過情況不如設計預期,那麼就是設計師把這個挑戰搞得太過火了——
設計角度如何平衡遊戲難度與遊戲體驗
如何降低難度?
從困難度上降低,可以給予更寬鬆的判定區間,更明顯的提示,更寬容的按鍵識別等等。
從複雜度上降低,可以弱化與拆分玩家能力考驗的耦合性。或者整合多元操作,讓玩家的輸入可以更容易地達成多個複合動作。比如鬼泣的Auto Combo。
更粗暴的是從容錯上降低難度,在困難度和複雜度都不降低的情況下,讓玩家在一次挑戰中有更多犯錯的機會,考驗本身不變,但是讓玩家心理負擔降低。(這裡其實有個簡單的例子,就是一次不錯地從1默寫到1000的小遊戲,本身考驗不難,但是容錯為0,一次犯錯就全盤皆輸,玩家的壓力還是會很大的。當然,這個遊戲並不有趣……)
如果我們不想降低所有人的挑戰難度
好,那麼再進一步,我們如何在保持挑戰高難度的情況下,儘可能地向下相容更多的玩家呢?
從最簡單的想,我們可以提供降低難度的選項,當然,驕傲的玩家們一般都不會做出這樣的選擇,那麼我們也可以暗中後臺降低挑戰的難度,比如增加Timing考驗的檢測容差。當玩家受到致命傷害的時候稍微抬一手,留一個殘血嗑藥的時機。適當地降低敵人的攻擊慾望,甚至在AI上降低玩家之前一直躲不過的連招出現的頻率等等。這些後臺的微調可以保持挑戰的壓迫性,並且讓玩家在瀕死邊緣有更高的容錯,可以強化玩家是“使出渾身解數,生死之間堪堪戰勝挑戰”的英雄成就感,畢竟誰不喜歡絲血反殺呢?
我們還可以從宏觀角度來解決問題,我們可以提供給玩家更寬的體驗路徑,先去嘗試其他遊戲內容,為挑戰做準備。比如艾爾登法環中,如果不夠強可以去其他地方慢慢刷等級,獲取更好的裝備,帶著更好的屬性再來迎接挑戰。比如臥龍蒼天隕落中,允許玩家以20士氣的情況下去面對關底BOSS,來獲得數值上的相對優勢。或者讓玩家有更多的練習機會,熟練掌握挑戰中一部分的模式(Pattern),從而降低對整個考驗的難度。
更巧妙的設計是允許玩家在明確目標的情況下,用遊戲所支援的各種辦法來透過考驗。即非唯一解,或者在有些遊戲中也可以被說成是“逃課”玩法。比如塞爾達中的神廟,比如只狼中的一些BOSS,比如恥辱中不同關卡的通關方式。玩家群體是多元的,當我們塑造了一個虛擬世界的時候,教給玩家非常多的規則和邏輯。那麼當玩家合理地使用這些規則和邏輯來嘗試攻克挑戰的時候,應當得到正面反饋。
結語
我非常喜歡一句話,“Design both for and against player at the same time.”我們在做設計的時候,總是希望玩家能面對挑戰,但是又不被挑戰所難倒。畢竟我們不是為了彰顯設計師的惡意(emmm大概大部分的情況下不是吧),或者讓玩家感受沮喪與挫敗。讓玩家失敗從來不是設計目的,讓玩家知道挑戰是什麼,如何戰勝挑戰才是。設計師就好像努力讓玩家不掛科,但是也別太輕鬆拿高分的出題老師。
一切的一切,歸根結底,是想保證不同玩家在面臨這個挑戰的時候,可以收穫到足夠的情緒峰值。
原文:https://www.zhihu.com/question/627312930/answer/3260484793
相關文章
- 18. 再說迴圈~列表和迴圈的高階操作
- 說說iOS與記憶體管理(中)iOS記憶體
- 從setTimeout說事件迴圈模型事件模型
- 遊戲的規則真的是封閉的嗎?說說遊戲中的“魔法圈”概念是如何施展“魔法”的遊戲
- 關於FDF迴圈互助遊戲系統開發詳情說明遊戲
- JavaScript 事件迴圈(1) —— 從 setTimeout 說起JavaScript事件
- Java迴圈:想說愛你不容易Java
- 從一個案例,細說瀏覽器的事件迴圈瀏覽器事件
- 圖靈假說70年:兩類AI與封閉性挑戰圖靈AI
- 傳說中的裸奔節–認識及體驗CSSCSS
- 曹工說Redis原始碼(6)-- redis server 主迴圈大體流程解析Redis原始碼Server
- MySQL實戰 | 06/07 簡單說說MySQL中的鎖MySql
- 說說iOS與記憶體管理(上)iOS記憶體
- 遊戲化設計中的“雙迴圈”遊戲
- 競技遊戲中的反饋迴圈遊戲
- 7-31 字串迴圈左移,這題毫無挑戰字串
- OA管理軟體新體驗:與舊時代說再見
- 迴圈中的非同步&&迴圈中的閉包非同步
- 15,javase程式碼實戰-迴圈控制——迴圈的終止與過濾(六)Java
- 說說Flutter中的SemanticsFlutter
- 說說Flutter中的RepaintBoundaryFlutterAI
- 他說遇到了迴圈匯入,但是我怎麼看我的程式碼都沒有迴圈匯入
- Dart中的非同步與事件迴圈Dart非同步事件
- LOL主播說4短時間沒有人可以挑戰PDD遊戲直播一哥地位遊戲
- 遊戲博弈論研究:最優解策略與混合迴圈戰略博弈遊戲
- C#中的For與Foreach迴圈:一場效能對話與實戰解析C#
- 從for迴圈中的定時器說開去,閉包和非同步的一點事兒定時器非同步
- 說說JavaScript中的事件模型JavaScript事件模型
- 面對遊戲圈的黑暗,這群人勇敢說出了“不”遊戲
- 《球球大作戰》原始碼解析(7):遊戲迴圈原始碼遊戲
- 以GTA為例,說說開放世界體系的概念,和在遊戲設計中的奇妙之處遊戲設計
- 面對產業安全的新挑戰,騰訊安全如何“現身說法”?產業
- 對實體店來說,電商直播系統的出現是機遇還是挑戰?
- 遊戲的戰略(二)——選擇性的戰略與落地的挑戰遊戲
- 說說Mongodb 與 MySQL的那些事MongoDBMySql
- 據說這將是一款讓你真實體驗遊戲製作人的遊戲遊戲
- 遊戲機制設計:資源管理挑戰與遊戲中的AI設計遊戲AI
- 說說在 Python 中如何遞迴建立不存在的資料夾路徑Python遞迴