設計筆記:世界觀設計
本篇就是一個話癆的碎碎念,以及對日常工作生活的階段性覆盤。
前言:為什麼要做世界觀?
在每個故事開始前,我都會問自己的一句話: “為什麼要做世界觀?”,和虛無縹緲的各種定義沒關係,實際上僅僅只是一個幫助自己開工的小玩法。
我們大可說一聲:為愛發電?
那麼我們又是為誰的愛發電? 這句的出處已經忘記來源,文章內容已然忘清,但是這句話卻開始焊死在我的腦裡。
純為作者自己,或許僅僅只是一個核心的想法就可以逐漸把世界填充成型,創世神翻手為雲覆手為雨,創作者只需要為自己的喜惡負責,除去筆下的生靈,沒有人有資格評判你的世界觀設計。
若為讀者、玩家的喜愛的話,合適的使用者調研則是大家需要考慮的點。誠如漢斯·羅伯特·姚斯所說:“一部文學作品在其出現的歷史時刻,對他的第一讀者的期待視野是滿足、超越、失望或反駁,這種方法明顯的提供了一個決定其審美價值的尺度。期待視野與作品間的距離,熟識的先在審美經驗與新作品接受所需求的‘視野的變化’之間的距離,決定著文學作品的藝術特性。”
當我們為自己的作品打上特定標籤以吸引特定使用者時,投其所好則是我們用來回饋他們的方式。在爽文中看打臉,在種田文中看歲月靜好,在二遊、乙女遊戲尋求精神寄託,這些都是所屬使用者簡單而又重要的“需求”,一旦作品所打的“特定標籤”與使用者期待有所背離,則可能會出現可怕的反噬。比如:
因此,在開工之前,不妨問自己一句: “為什麼要做世界觀?”,若為自己喜歡的題材而發電,那麼客觀上來講,使用者的喜好反而是最不需要考慮的。若為讀者、玩家的喜愛的話,並以此為生的,請務必做好使用者調研,否則在花費大量精力後事與願違之下還可能被踩上兩腳,被咒罵上幾句:“又當又立”。
什麼是世界觀設計?
百度百科中對世界觀的定義是:世界觀是指處在什麼樣的位置、用什麼樣的時間段的眼光去看待與分析事物……
百度百科詞條
坦白講,這個詞對我來說太過於抽象,以至於我不能很好地用自己的語言轉述這個定義。所以我準備乾脆拋棄百度百科,按自己的想法以及喜好來推導。
世界先得真實,開放地圖才有意義
在【世界先得真實,開放地圖才有意義】一篇中,我提到過:我喜歡在遊戲中放飛自我,有一搭沒一搭地體驗遊戲,但是當遇到神奇的遊戲景觀時,我想尋覓到它的來路和源頭。拋開所有的現實因素,我想要創造一個能經得起推敲的、邏輯自洽的世界,在這個世界的舞臺上,每一個故事都能在故事的“曾經”找到答案;每一個角色都擁有自己的生活,他們是社會的縮影,也是歷史的見證;而故事的主角僅僅只需要在這個世界中投入自己的“關注”,做出“抉擇”,就能收穫到屬於自己的故事。
那麼,為了完成這樣一個世界的構造,有哪些設計是必須的?這個世界的政治、歷史、文化等方方面面該如何規劃?這個世界各大事件的發展中,是不是擁有值得令人深思的社會學議題?哪些元素的設計可以讓整個故事更有故事感,更有畫面感?
在我看來,這些都是世界觀設計過程中永恆探討的議題,這個議題或許需要足夠久遠的時間才能真正形成自己的方法論,但不出發永遠也找不到屬於自己的答案。
起點:核心概念與規則
概念、規則及現象(舞臺)
oc 設計時通常是由一個吸引人眼球的“高概念”發散後逐漸豐富而來。如:百面千相以換面具等於演戲等於可以切換自身形象,這樣的遠超出於常識的“技能”是否擁有其自己的來源?這樣的“技能”代入到歷史當中會發生怎樣的變化?“技能”代入到什麼的角色中會發生有趣的化學反應?
當然我不是百面千相文案組成員,不能代表他們的思路流程。這裡只是想作為一個例子來說明:大部分世界自有一套自己的“核心”,而這個“核心”可以作為一個錨點,幫我們快速構建我們對那個世界的想象——這個核心,我定義為:核心概念。
世界觀概念層的設計,很大程度上是定義概念以及制定規則,然後去解釋我們發現的一些現象,這些現象具體如何在故事舞臺上呈現。
雖然整個邏輯鏈,看起來很簡單,就是a+b推演出c的過程。但得益於故事開始前就已經腦洞出來的批次素材,再疊加上世界觀背景故事的發展,我們很大程度是先有故事再考慮故事與世界觀是否相容;基於這種情況,我們很容易把概念和規則弄混了。
此處以水作例子:在世界觀概念設計的時候,為了形容常溫下的水,我們可能會給水加個定語:常溫水,為了形容水沒有味道的特徵,我們又為這個水疊加了特徵:常溫下無味的水。定語少的情況下相對會比較簡潔,但如果這個水的特徵疊上七八個以後,就會讓人感覺繁雜。如:常溫下無色無味用透明玻璃杯裝著的液態水……
這導致了我們對這個概念本身會有著模糊的理解。我的解決思路是把定義和規則分開:
- 概念就是一句話,最最簡單的一句話。水就是水,水就是h20。 (所有人認可後都不能改的)
- 規則是,圍繞著概念展開的。比如說,水有3種狀態,但100度以下的水液態在常規壓強下是液態的;水具有流動性;純水是無色無味的
- 概念+規則指向了一個結果:我們現實生活中,常溫25度的天氣下,我們看到的水就是液態的,具有流動性的水。
理清概念、規則及現象(舞臺)的作用
在舞臺故事呈現的大部分時候,概念、規則及現象(舞臺)是很難區分開來的,並且在設計的時候,太固執於設定側的設計,有時候會反過來壓縮“舞臺故事”設計的時間。所以是否真的需要將這三者完全區分開來,則是一個很有意思的話題。
個人的做法是:先不管它。先按著自己的想法把故事寫下去,寫到某個時候,發現自己的文章卡殼,意識到自己的某個內容因為缺乏理論支撐而模稜兩可時,停下來看看自己文章中出現過的概念,並重新順下這三者之間的關係。
此時,會發現,核心概念在整個舞臺表現方面,起到了很大的錨點的作用:比如只狼裡面的的核心概念是“不死之力”,。外來的龍汙染了源之宮的水源,水從上往下陸續影響了不同的地圖,毒性因地勢得以稀釋,不同地方的中毒程度會有所不同)。
原圖出處: https://www.zhihu.com/question/350163635/answer/855039564
這個時候,理清概念、規則及現象(舞臺)的作用就凸顯出來了:
- 在邏輯層面,核心概念是整個世界觀共有的東西,透過一定邏輯的發散,可以讓整個世界聯絡性更強。
- 在故事舞臺的層面,概念與基礎規則互相影響的地方,則是故事發展的可能走向,往往這些故事發生的節點是,整個故事世界的某個關鍵節點,此處稱為:“核心事件”。“核心事件”,影響範圍可能輻射到多個地圖或者勢力,比如說:奧尼亞花盛開算是一個很關鍵的事件,這個事件直接影響了蓋利德場景的多項設計。具體可以看【世界先得真實,開放地圖才有意義】篇,這裡就不展開了。整個故事舞臺的核心事件放到一起,再配以世界的時間軸,就是一條完整的“世界觀時間線”。
- 在實踐層面,理清概念、規則及現象(舞臺)可以很好地避免了用未知推未知的情況。在寫故事過程中,先有故事還是先有概念,是個先有雞後有蛋的問題。這類公說公有理婆說婆有理的問題之下,選擇對自己有利的說法,從推理邏輯上來說是行得通的 —— 也就是說,先補足規則還是先補足結果都是可以的。一個完整的邏輯鏈是前後呼應的,我們實踐的時候如果能確保理清概念、規則及現象(舞臺)中的兩個因素,那麼推匯出另外一個因素,或者另外一個因素是否修改,就是一個很明確的過程。
綜上,理清概念、規則及現象(舞臺)的核心作用是讓自己在困頓的時候理清自己的思路。
故事舞臺的表演
冰山理論及故事大綱
如果將故事舞臺發生的劇情當成世界觀的一種表現方法,它將是區域地形氣候、生物群落、植被構成的生態鏈、人文景觀及特色文化圖騰、英雄背景交代、個性獨特之外最重要的一環。觀看者將順著劇情的脈絡,逐步體驗到海面的之上的八分之一的冰山,從而順著這部分冰山,展開展開想象,瞭解下故事背後的思想和情感。
上述說法僅僅只是基於個人喜好而產生的想法,每個人都有自己一個屬於自己的,關於“故事該怎麼寫?”的答案。基於我對塑造“真實世界”的執著,在故事開始之前,我會藉由將故事裡的“訊息”進行規劃:
處於冰山之上的是在故事舞臺最核心,最耀眼的地方,這些基本訊息構成故事的基本元素,講述這一個完整的故事。
而在故事之外的淺水區域:“配角可以有自己的生活。”、“場景可以有屬於自己的故事。”、“一個故事發生的時候,它發生的原因都能在故事的“曾經”找到答案。”……這些依靠故事本身進行淺層探索就能發現的小驚喜,我稱之為:水平面區域。
故事之外的細枝末節透露出來的小規則與設定,最後將故事引向冰山本體——“核心概念”與設計者的哲思。(又繞回來了,邏輯閉環了屬於是。)
故事裡的“訊息”層次豐富固然是個好事,但也容易伴隨著一個巨大的風險:“跑題”。為了應對這樣的問題,簡潔明瞭的故事大綱則成為我的救命稻草,但故事的設定本身就是邊寫邊完善的,細節方面牽一髮而動全身,因此大綱方面我不習慣寫得很細,後面參考了網上的一些資料(非原創哈,就是忘記來源了),開始嘗試用圖形來當我的大綱,大致樣式如下:
出處:分享一個寫小說用的 obsidian 示例庫 - 余月魚鴿的文章 - 知乎https://zhuanlan.zhihu.com/p/690369660
故事細節及日常積累
俗話說站在岸上永遠也學不會游泳,一部小說、一款遊戲想要落地,永遠也離不開真正地下手寫作、操作。而我們真正開工的時候,才會意識到,哪怕頭腦風暴早已風起雲湧;哪怕腦海裡的人物早已經在血海深仇中經歷過幾百次恩怨情仇;哪怕我早已經知道這個故事篇章中,我想要為故事賦予怎樣的故事描寫;可手中的鍵盤就是惜字如金,捨不得的敲下一個空白鍵——雖然也有才思泉湧,健步如飛的時刻,但卡文這件事難免逃不掉。
總會有:不甘心寫上“挖槽,真好看!”,卻也擠不出來:“落霞與孤鶩齊飛,秋水共長天一色。”的時刻。
難免會遇到,在故事中想設計一個很有儀式感的求婚方式,繞了一圈後選擇把人騙到人口眾多的地方擺上蠟燭,在親友的圍觀下見證歷史。 也有一種“儀式”僅僅只存在雙方的小互動:a知道b每次吃漢堡時都會開啟漢堡塗番茄醬,而且喜歡塗在菜葉子上,所以a在求婚時,特意把戒指洗好消毒後藏在菜葉子上b一定會發現的地方。b或許會心照不宣地把戒指戴在手上,笑而不語;或許會找上親友吐槽;但整體來說,這個“儀式”本身是成功的,b已經把a的習慣刻進腦子裡了,才能做出這麼反常卻確保不會失誤的行為。從個人感官而言,我更喜歡第二類的儀式感。
文章的文筆,故事的情節很大程度上會受自己走路的路,見過的人,讀過的書影響,這部分很難一蹴而就。若想“於平淡中見波瀾,於細微處見真章”,大部分的情況下,需要一定量的日常積累 —— 我曾經迷信於這一點,因此做過不少筆記:語句摘錄、閱讀隨筆、日常碎片、反常識言論……
近期在重新梳理並構建自己的“數字花園”時發現了一個問題,之前的我對自己太自信了,大部分筆記記下後就被遺忘。直至自己重新看到時依舊會感嘆:這個妹妹我曾經見過。但自己為什麼會記錄這個內容?
從筆記利用率的角度考慮,我使用雙鏈筆記的方式來最佳化這個問題:記下筆記後,從使用的角度再進行一次整理,將筆記與現有的主題聯絡起來,並且建立雙鏈連結與之產生聯絡。後續檢視或新增這個主題的資料時,相關筆記的複用性也就自然而然變高。
另外,在入庫時就進行關聯還有另外一個好處,相似,相反的主題,筆記容易產生碰撞,彙集到一定程度後進行反思,相似部分進行簡化或彙總,相反部分刨根問底即可形成一篇新的筆記,讓自己對指定主題的記憶更加深刻。
資料庫現狀
補充(挖坑實錄)
在小說或遊戲世界涉及到較大的世界觀時,在核心概念之外,還需將其中的資訊點再次進行拆分,將地圖、勢力、角色等資訊進行細化,這三者的思路差不多。後續會以【勢力設計】為例整理一則勢力框架筆記,以及【角色】的具體設計思路。
在資料收集方面,吸取了pkmer社群中關於知識管理的經驗後,我在重構數字花園時遇到的,如資料的來源繁雜,筆記、收集到的資料容易積灰等問題,以及解決這些問題的思路。後續會以【折騰歷史:資料庫的構建】為標題進行復盤。
余月魚鴿:折騰歷史:資料庫的構建
https://zhuanlan.zhihu.com/p/695296864
在遊戲劇情設計領域,遊戲表現劇情的手法是多種多樣的:高光時刻存在電影級別的演出與劇情體驗,日常的npc互動,對話也能給到玩家特定的訊息,甚至極端一點,場景氛圍、場景邊緣圍牆透露出來的訊息也能達到增強敘事體驗的效果。關於這個,不同公司的劇情製作管線基本不相同,自己的覆盤雖然已經梳理完畢,但也不會可以掛出來。後續會將筆記庫中的關於劇情表現相關的內容二次進行彙總與整理到:【遊戲劇情設計相關】專欄中,本專欄主要收錄、摘抄、整理了自己或網路上看到的一些遊戲劇情的表達技巧。
原文:https://zhuanlan.zhihu.com/p/695296864
相關文章
- 讀書筆記#五導家-設計觀筆記
- 設計模式筆記(2)設計模式筆記
- JAVA設計模式筆記Java設計模式筆記
- 【設計模式】設計模式(一)-- 大話設計模式讀書筆記設計模式筆記
- Java設計模式學習筆記(一) 設計模式概述Java設計模式筆記
- C#設計模式學習筆記:設計原則C#設計模式筆記
- 非同步程式設計筆記非同步程式設計筆記
- 高併發設計筆記筆記
- Windows sdk程式設計筆記Windows程式設計筆記
- 設計模式學習筆記設計模式筆記
- 網路程式設計筆記程式設計筆記
- 學習筆記-設計模式筆記設計模式
- 漫談世界觀敘事設計中的工具鏈
- Python學習筆記之 Python設計思想&設計原則Python筆記
- 設計筆記003:關卡設計的流程(系統向)筆記
- 【設計模式】外觀設計模式
- go併發程式設計筆記Go程式設計筆記
- php設計模式學習筆記PHP設計模式筆記
- JavaScript非同步程式設計筆記JavaScript非同步程式設計筆記
- 《Windows核心程式設計》筆記(一)Windows程式設計筆記
- 【設計模式筆記】(二)- Builder模式設計模式筆記UI
- JavaScript設計模式學習筆記JavaScript設計模式筆記
- shell指令碼程式設計筆記指令碼程式設計筆記
- C++核心程式設計筆記C++程式設計筆記
- RESTful 介面設計規範 筆記REST筆記
- nodejs筆記-非同步程式設計NodeJS筆記非同步程式設計
- Java 基礎程式設計筆記Java程式設計筆記
- JavaScript高階程式設計筆記JavaScript程式設計筆記
- 架空世界設計中的重要性排序:世界觀、人物、情節、要素排序
- 四. 文字程式設計--Windows程式設計課程學習筆記程式設計Windows筆記
- Node.js 設計模式 學習筆記 之 流程式設計Node.js設計模式筆記程式設計
- 設計模式之外觀模式設計模式
- 設計模式-外觀模式設計模式
- javascript設計模式(張容銘)學習筆記 – 外觀模式繫結事件JavaScript設計模式筆記事件
- 設計模式學習筆記(十九)觀察者模式及應用場景設計模式筆記
- 《Go 語言程式設計》讀書筆記(十一)底層程式設計Go程式設計筆記
- laracon 2018 演講《Laravel 當中的程式設計設計模式》筆記Laravel程式設計設計模式筆記
- Java高階程式設計筆記 • 【第4章 網路程式設計】Java程式設計筆記