再換一種角度來看遊戲,來看死亡擱淺
我看了很多關於死亡擱淺的文章,有從批判心流設計的,有鼓吹動畫狀態機的,也有鼓吹劇情的。但沒有任何一個人真正從“連線”這個角度出發,讓我覺得有一些遺憾。
不管是作為玩家,還是設計者,我覺得在3A遊戲模式比較固化的今天,死亡擱淺帶來一個不一樣的味道,一段不一樣的體驗。小島秀夫做到了,他從立項時就定下的目標,連線。但遺憾的是,死亡擱淺可能也是隻有”小島秀夫”才能做出來的遊戲。在開始文章之前,我想對這款遊戲進行一個總結。”死亡擱淺,是一個讓玩家發自內心去關心其他玩家,去幫助其他玩家的遊戲。"
接下來,我想大家放下對死亡擱淺遊戲性的爭論,放下對死亡擱淺劇情的爭論,放下小島秀夫是否跌下神壇的爭論,我們換個角度來看死亡擱淺,換個角度來看遊戲。我想通過最近在遊戲倫理課上學習到的關懷倫理學的角度,來看死亡擱淺的設計。本人學識淺薄,可能文章深度不夠深,還請諒解,在這更想是提供一個新的角度。
關懷倫理學
關懷倫理學,顧名思義,是想定義人們生活中,什麼樣的行為才能被稱之為關懷。與傳統的道德倫理框架不同,關懷倫理學更加強調關係的重要性,例如,Utilitarianism(功利主義)強調如果一個行為能將“快樂”最大話,那麼這個行為是正確的。Kantianism(康德主義)強調如果一個行為在被“普遍化”的情況下,沒有產生衝突的話,那麼這個行為就是正確的。關懷倫理學的作者提出了決定關懷的四大要素,Attentivenes(專心),Responsibility(責任),Competence(能力,勝任),Responsiveness(反應)。
Attentiveness(專心)
Attentiveness,意思是你要認清楚別人的需求是什麼。在做某件事情的時候,換位思考他人,思考別人的需求是什麼。知道他人的需求,是關懷這個行為的前提。
Responsibility(責任)
Responsibility,意思是將他人的問題/需求,看作是自己的問題/需求。在這裡,要分清楚Responsibility(責任)與Obligation(義務)的區別。
Obligation(義務)的意思是,你的行為在特定的情況下,因為文化或者社會風氣的原因,是被要求或者是期待的。例如,國內流行尊老愛幼的說法,很多情況下,給孕婦老人讓座不是你發自內心的關心他人,而是因為社會風氣的影響,你不得不去做。
Competence(能力)
在你知道了他人的需求,並且願意承擔這份責任後,你需要將關懷這個行為進行到底,就是Competence的意義了。例如,朋友生病了,去醫院看望一眼這個行為,在關懷倫理學的定義裡是不算關心他人的。而是,要持續的去醫院看望朋友,每次帶上自己煲的雞湯,或做的便當直到朋友出院才算。
Responsiveness(反應)
收到他人照顧的人,應該回應他人的關心以及照顧。接著上面的例子,朋友在每天收到你的愛心便當後,會表現出非常感恩,用笑臉來回應你的照顧。心中可能暗暗想著,如果以後你生病了,也會這樣去照顧你。這裡也要區分,Responsiveness(反應)以及Reciprocity(互惠)的不同。我們在關心他人的時候,是不追求回報的。
好,現在我們知道了在關懷倫理學中的四大要素。那麼,我們如何把關懷倫理學應用在遊戲上呢?
其他遊戲中的關懷
作為設計者,我們一般都是希望玩家在每一個遊戲中的行為都是有所反饋的,並且,如果我們希望玩家做什麼行為,但我們無疑是會用獎勵去激勵玩家,多去做。舉個例子,Pokemon GO中,玩家是能夠給好友傳送禮物的,傳送禮物這個行為會讓玩家提高玩家與玩家之間的好感度,到達一定好感度時,玩家能獲得一定的經驗,從他人獲得禮物中的道具就越好。在一般的MMORPG中,副本里,大家是為了獲得副本中即將獲得的裝備,才彼此的關心對方,例如給他人加Buff或者是給他人補血。
但,玩家在做這些行為時,真的是發自內心的想贈與他人禮物嗎?真的是發自內心的關注隊伍裡其他隊友的狀態嗎?不是,大家只是為了這個行為後所產生的獎勵/利益。遊戲中的好友列表,也慢慢逐漸變成了工具人列表。在我玩Pokemon GO時,每日給他人發禮物,收禮物,已經變成了一個機械化的行為了,我也只是為了獎勵而去做。
Pokemon GO中,並沒有機制促進說,我去換位思考我的朋友們,他們新手期可能需要哪些精靈,我們可以贈送給他,或者說他需要哪些道具。這無疑是非常遺憾的。
工具人列表
那麼在其他遊戲中,有真正引導玩家去關心他人的嗎?那麼答案是,動物森友會。在動森裡,每一個動物NPC都有著跟玩家一樣的許可權,他們不像其他遊戲中的NPC,是為了玩家而服務的,他們有著自己的生活。玩家的行為並不會對他們造成任何影響。玩家與NPC的關係也不會給玩家帶來很多的影響,就算你不跟任何NPC做朋友,遊戲也能正常的遊玩。不像是其他遊戲,與NPC增進關係,能提升玩家的個人能力或者隊伍能力,例如女神異聞錄5中,增加關係能解禁隊友的能力。
在動森中,玩家對NPC的友好行為,例如送禮物,對話,只是會獲得來自其他動物NPC更加主動的行為,對遊戲的目標並沒有什麼影響。例如,其他動物會主動過來跟你搭話,會邀請你去她家做客,會給你寫信,可能會送你禮物。玩家還會得到關於這個動物更多的資訊,它的喜好,它的故事。
更多關於關懷倫理學與遊戲可以去閱讀 Videogames and the Ethics of Care by John Murphy and Jose Zagal這篇文章。那麼接下來我們來看看死亡擱淺是如何對應關懷倫理學的四大要素的。
死亡擱淺如何讓玩家發自內心去關懷
”Omoiyari (おもいやり)在日語中的意思是“體諒、關懷”,有點類似於所謂的“同理心”。小島秀夫在被媒體問到《死亡擱淺》的創作靈感時,提到了兩件事:戰時,有個士兵給他的妻子寫信,交給部隊後經過四個月的船運,然後他的妻子開啟了信。也許那時他已經犧牲了。她必須要想丈夫四個月前在幹什麼,這就是 omoiyari 的感覺——關心他人。另一件是富士山裡的山中小屋,這是專門給疲憊的旅行者休息的地方。“我總是對小屋心存感激,感激搭建它的人。所以我認為如果有人有這種想法,他們也可以把它傳遞給他人。這就是我對遊戲的願景——不是主題,而是願景。”小島秀夫也相信玩家們在遊戲裡“不會有太多的惡意行為”,玩家會自發地互相幫助,而不是試圖阻礙別人。“我們做了很多遊戲測試,有時你會發現一座橫跨河流的橋樑,但只修到了河中央,但這可能不是故意的。我希望就算人們從橋上掉下來也能用善意揣測別人。”
Attentiveness(專心)
在死亡擱淺的前5-6個小時裡,玩家都是沒有連線到開羅爾網路的。設計者,直接讓玩家體會沒有他人幫助下,遊戲的難度,而且在開頭第二個任務直接就安排送人,在整個遊戲中操作起來比較困難的任務。但,玩家在這前5-6個個小時裡,能理解並且掌握遊戲裡的3大障礙,地形,BT,米爾人,理解這三個障礙的困難以及帶來的挑戰。遊戲也在慢慢的給予玩家能戰勝這些障礙的道具。在就完成了關懷倫理學的第一個前提,就是知道他人的需求。
我相信大家都是能體會到這一點的,在遊戲沒有連上開羅爾網路時,遊戲緩慢的劇情推進,非常漫長的播片,以及非常難以掌控的操作地形。都是在不斷的給予玩家負面情緒。為什麼我說,這是隻有“小島秀夫”能做出的遊戲?因為,如果不是“小島秀夫”明星製作人的明星效應,可能很少人能撐過前面困難且漫長的前期,進入到後面催產素開始瘋狂催化的中期後期。死亡擱淺與其他一些遊戲不同,一開始就把玩家放在了一個相對困難的位置,在這個階段,瞭解送貨的艱辛。這才給後面換位思考,以及遇上他人幫助的感動做鋪墊。開頭最讓我影響深刻的有兩點,一點是最開始連上開羅爾網路時,玩家們放下相互鼓勵的標語,以及在學會造橋後,當我往回走,開到湖邊建起的一座座大橋。只有經歷了過河BT爬山的艱辛,才能理解這一刻被別人幫助的幸福感,才能換位思考其他玩家的需求。
回頭,公路所帶來的感動
Responsibility(責任)
遊戲在Responsibility其實是做的比較狡猾的。將他人的問題換做成自己的問題,但在死亡擱淺中,因為非同步聯機系統,玩家在面對沒有網路的情況下,就是在跟他人同時面臨一樣的問題。玩家,在思考如何解決自己的問題時,無意中也在幫助他人解決問題。也因為物資有限的情況下,玩家不能解決所有自己將要面臨的問題或者說障礙,也給他人創造瞭解決問題的機會。例如,我可能有梯子過河,但我沒有梯子直接爬山,我解決了別的玩家過河的問題,別的玩家在未來也可能解決了我爬山的問題。而且,遊戲中並不存在必須要用道具才能到的地方,在沒有道具的情況下,遊戲需要玩家繞更遠的路,或者遇到BT米爾人。所以,當玩家再回來時,發現問題被解決時,就能感受到相互幫助的美好,從而促進玩家開始幫助別人。在好的位置上的建築,會獲得更多的人的點贊,樹立了標杆,讓玩家們去學習。不斷跳出的被他人點讚的提示,也是在慢慢的讓玩家學會換位思考他人。
例如,我自己,在獲得了他人放在末日生存者門前的充電樁的幫助,我就開摩托回去,在基地前也放置了一個。獲得了超過千贊,成就感滿滿。
很多玩家說,黑魂的非同步聯機跟死亡擱淺蠻像的,實則兩者還是有一定的差距。黑魂的非同步聯機存在負面反饋的情況,例如“前方有寶箱”“前面有驚喜”“往前走。蠟石作為留下標記的道具,對玩家本身並沒有任何影響。但,在死亡擱淺中,能留下的標語被設計者所限制到基本只能帶來”正向反饋“的標語。留下壞的梯子或者繩子,本身就在消耗玩家自己的資源。看到預期會不好的梯子,玩家也可以選擇拆除。
死亡擱淺在盡力保留了非同步聯機能帶來正向反饋的部分。但在Responsibility這塊,遊戲依然有做的不是很好的地方。例如,遺失貨物以及撿起其他玩家丟失的貨物給別人送回去。玩家的物資因為有米爾人的存在,丟失的貨物大多數都是不必要以及多餘的物品,基本他人將貨物送回給我,提示也非常的不夠明顯,而且物品還存在固定的站點,還需要我去花時間去取,那不如再造。無法激發我想要去給其他玩家的慾望。
雪山真的很難,送炸彈也真的很難
Competence(能力)
整一個遊戲都是圍繞著”連線“這個主題來設計的,送快遞無疑是連線這個核心體驗的載體。而這個載體能最大化的將連線這個感受傳遞給玩家。玩家是從頭到尾都與他人連線著,除了結尾的超長結局動畫以外,玩家都是在主動連線他人,以及被他人連線這個loop迴圈著。
但,比較遺憾的是,在這一方面,死亡擱淺也受限於這個載體,導致在照顧他人到底這個要素上做的不是特別好。例如,滑索擁有都只能同步到一個或者是兩個,基本刷不到能完整連線到一起的滑索,公路在經歷過一開始的瘋狂修建後,也很少傳送變化。
Responsiveness(反應)
死亡擱淺與其他遊戲最大的不同可能就是獎勵玩家的方式。在其他遊戲中,獎勵通常會帶給玩家直接的成長。但在死亡擱淺中,點贊卻只能給玩家帶來非常細微的提升,例如一點負重,一點平衡。就如我上文所說,真正的關心他人是不求他人回報的,為了利益而去關心他人並不是真正的關心。我覺得死亡擱淺並不是為了提供玩家成長感或者說是成就感,更多的是被認同感。點贊,是對於你放置的建築給予他人的幫助的認同。
在現實生活中,我們有時充滿善意的行為,有時可能會被他人誤解,或者僅被少數人認可,又或者說被他人利用。在死亡擱淺裡,玩家會收到一條條其他玩家對你的認可,這種直接對你善意行為的認可,是其他遊戲很少關注或者說觸及的。也因為這些直接的認可,驅動著玩家進一步的換位思考他人。我在打完了一遍遊戲後,我回頭又看了一遍秦先生的直播。秦先生在後期花了大量的時間,修了一條完整的雪山索道,在他後來的weibo下都能看到類似的評論,秦先生的索道救了我的命。
死亡擱淺給玩家帶來的反饋並不侷限於點贊,沿著他人腳印所走的路會變成小徑,玩家休息的地方會變成石頭,玩家點贊次數越多,地圖上刷到他人的東西也就越多,一起上廁所的地方會變成蘑菇。玩家無時無刻都是在這種相互連線的氛圍下游玩的,很難不參與到其中。
我的最後
總結
關懷倫理學這節課可以說,給了我一個全新的角度去看待遊戲,甚至是給我了一個全新的角度去設計遊戲。而死亡擱淺無疑是近期最能代表這個理論在遊戲中運用的作品。在我本身遊玩的時候,也無時無刻的在享受著與他人連線的樂趣,所以我想要把這個角度分享出去。希望能有更多關於真正與他人連線,真正用遊戲機制引導相互關心的遊戲出現!
本文是在我個人遊戲通關後3周寫出,可能有漏洞,分析不到位,或者說遺漏之處,還請各位多多諒解。也可以在評論區多多補充!
作者:EEhentai
來源:奶牛關
原地址:https://cowlevel.net/article/2080533
相關文章
- 換個角度看GAN:另一種損失函式函式
- 換個角度看原型鏈原型
- 如果從oo角度來看sessionfactory的建立,請分析一下?Session
- 從專業的角度來看,遊戲中的兵刃格鬥靠不靠譜?遊戲
- 一起來看MyBatis(一)MyBatis
- [譯] 以面試官的角度來看 React 工作面試面試React
- 以程式碼愛好者角度來看AMD與CMD
- 線上excel轉換成pdf,看過來!Excel
- 從“殺人遊戲”來看SOA的實施遊戲
- 策劃看過來——種田遊戲也考驗玩法設計能力?遊戲
- 【詳解】換一個角度看Socket的資料讀寫
- 換一種態度看程式設計師!程式設計師
- 換一個角度,看華為雲的變化,雲產業的更迭產業
- 從 Kakao 的遊戲收入預估來看微信的遊戲未來成長遊戲
- 從“跳一跳”來看微信小程式的未來微信小程式
- 換個視角來看TypeScript中的交叉運算TypeScript
- 來看三段程式
- 【JS 口袋書】第 8 章:以更細的角度來看 JS 中的 thisJS
- 從網際網路+角度看雲端計算的現狀與未來
- 對面的程式Yuan看過來,看過來,這裡的內容很精彩!
- 開發者角度看自走棋玩法
- 從JDK角度看物件克隆JDK物件
- 「訊息佇列」看過來!佇列
- 我的簽名我來看
- 通過一道題來看React事件模型React事件模型
- 從itpub看來的一道組合題
- 如何看位元組跳動遊戲未來的成功與否?遊戲
- 你需要用電子露營遊戲來看風景嗎?遊戲
- 原來從資訊理論的角度看親子關係,會更通透許多
- 從新產品成功的角度來看產品開發組織設計(轉)
- 關於看門狗的兩種模型以及帶來的思考模型
- 程式媛看過來!來自Google的特殊獎勵Go
- 從解放勞動力來看未來的科技程式
- 從JDK原始碼角度看FloatJDK原始碼
- 從JDK原始碼角度看LongJDK原始碼
- 從JDK原始碼角度看IntegerJDK原始碼
- 從 JDK 原始碼角度看 BooleanJDK原始碼Boolean
- 從 JDK 原始碼角度看 ObjectJDK原始碼Object