Scrivener 和 Campfire 的差異，不只是誰的功能比較多

搜尋 Scrivener vs Campfire，通常不是因為其中一套明顯比較差。

而是因為兩者都能協助小說創作，卻從不同地方開始理解作者的工作。

Scrivener 先看見的是一份正在成長的長篇。

它把書拆成章節、場景、文件、研究資料與可以重新排列的結構，讓作者不用在一份巨大文件裡來回移動。

Campfire 先看見的則是一個由許多元素組成的故事。

角色、地點、物品、關係、文化、時間線、地圖與正文，都可以用不同模組整理，再依照專案需要互相連結。

簡單來說，Scrivener 擅長把一本書變成容易控制的寫作專案。

Campfire 擅長把一個故事世界變成容易整理的知識結構。

但這個比較還少了一個問題。

當角色在正文裡移動、物品轉手、地點毀滅、陣營重組之後，這些變化只是被作者分別記在不同地方，還是會真正改變故事走到那一刻的世界？

這個問題不是功能數量可以直接回答的。

它涉及的是正文與世界觀之間，究竟只是放在同一個專案裡，還是真的屬於同一條因果。

Scrivener 把長篇變成可以操作的文件結構

Scrivener 最成熟的地方，是它知道一本長篇不應該只是一份從第一頁延伸到最後一頁的文件。

作者可以把正文拆成卷、章節、場景或更小的片段，再透過 Binder 管理整個專案。

Corkboard 可以把文件變成索引卡。

Outliner 可以讓作者從較高的角度查看章節順序、摘要、字數與自訂資料。

研究資料、圖片、網頁與筆記也能放在正文旁邊，需要時直接分割畫面參考。

作品完成後，Compile 則負責把分散的章節重新組合，輸出成 Word、PDF、電子書或其他格式。

Scrivener 也提供 Snapshots，讓作者在大幅修改一段文字以前保留舊版本。

這些功能共同處理的是一個很實際的問題：

一本書越長，作者越不能只靠捲動頁面來理解它。

Scrivener 的功能設計很清楚地把產品定位在長篇寫作、研究整理、結構調整與最終輸出上。

角色表和地點表當然也可以放進 Scrivener。

作者可以建立文件範本、自訂中繼資料、使用關鍵字，或者替每個角色建立獨立資料頁。

它並不是只能寫正文的純文字編輯器。

只是這些設定資料仍然主要以文件、筆記、標籤與作者自己設計的結構存在。

Scrivener 很擅長讓作者找到資料。

至於資料在故事不同時間點應該是什麼狀態，通常仍由作者自己判斷。

Campfire 把故事拆成可以連結的世界模組

Campfire 採取的是另一條路。

角色不是一份普通文件。

地點、物品、文化、宗教、語言、關係、時間線、地圖與故事弧，也不必全部塞進相同格式的資料頁。

作者可以按照自己的故事需要，使用不同模組建立世界元素，再透過可自訂的欄位與面板保存資料。

角色可以擁有背景、特徵與關係。

地點可以保存說明與圖片。

物品可以成為獨立元素。

Timeline、Calendar 與 Arcs 則可以協助作者觀看事件、日期與故事發展。

Manuscript 模組讓正文也能留在同一個創作環境裡。

Campfire 的優勢不只是資料種類很多。

更重要的是，它承認世界觀裡不同事物需要不同的整理方式。

一個角色和一個地點不應該只是兩份換了標題的筆記。

它們在世界裡扮演不同角色，也需要不同資料結構。

Campfire 同時提供瀏覽器、桌面與行動裝置上的使用方式，並讓創作者依需求選擇寫作與世界觀模組。

它目前也涵蓋角色、地點、物品、關係、時間線、故事弧與 Manuscript 等功能。

所以 Campfire 不是單純替世界觀準備一個更漂亮的資料夾。

它試圖讓故事世界本身成為可以被組織、瀏覽與連結的專案。

兩套工具都能保存正文和設定，但保存不等於同步

如果只比較功能清單，Scrivener 和 Campfire 的重疊其實不少。

兩者都能保存正文。

都能拆分章節。

都能建立角色與地點資料。

都能整理研究、筆記與故事結構。

也都有方法讓作者找到需要的內容。

真正的差異，不只在於資料能不能被放進去。

而在於資料改變時，其他地方會不會知道。

假設角色洛恩在第六章進入王城。

第九章從守衛身上取得一把銅鑰匙。

第十四章把鑰匙交給米拉。

第十八章王城遭到封鎖。

第二十二章，米拉帶著鑰匙再次回到城門。

這些內容完全可以被寫進 Scrivener。

作者也可以在 Campfire 建立洛恩、米拉、王城與銅鑰匙，並把相關事件放進時間線。

問題出現在作者回到第十二章。

那一刻，銅鑰匙在誰手上？

洛恩是否仍在王城？

米拉是否已經取得鑰匙？

王城是否已經封鎖？

作者需要的不是角色和物品的最終資料。

也不是整條時間線上所有事件的總覽。

作者需要的是故事走到第十二章時，由前面事件共同形成的世界狀態。

Scrivener 可以把相關章節、筆記與角色頁並排，讓作者查找。

Campfire 可以透過角色、物品、地點與時間線模組，把需要交叉比對的資料整理得更清楚。

但在這兩種工作方式裡，作者仍然需要理解事件順序，然後自己推導第十二章的答案。

資料都在。

答案也可能都找得到。

可是世界的「當時」仍然需要由作者重新拼出來。

一把鑰匙可以同時存在於三種不同的真相裡

長篇寫作最容易發生的問題，不是作者完全沒有記錄。

而是同一件事在不同地方留下了不同版本。

正文寫著洛恩已經把鑰匙交給米拉。

洛恩的角色頁仍然把銅鑰匙列在隨身物品裡。

銅鑰匙的資料頁寫著持有人未知。

時間線則只寫了「兩人在王城分別」。

每一份資料都不是完全錯誤。

它們只是沒有一起更新。

更麻煩的是，作者腦中可能還保存著另一個版本。

在最初的大綱裡，洛恩本來沒有交出鑰匙。

作者後來修改正文，卻仍然記得原本安排。

等到第二十二章需要使用鑰匙時，他很自然地讓洛恩把它拿出來。

這時候，問題不在作者找不到設定。

也不在世界觀資料不夠完整。

問題是正文、設定、時間線與記憶同時保留了不同版本的世界。

Scrivener 能幫作者管理這些文件。

Campfire 能幫作者管理這些世界元素。

但只要正文中的事件與資料頁之間仍然需要人工同步，作者就必須自己擔任兩套真相之間的對帳者。

故事越往前，這項工作越不只是整理。

它開始變成持續維護世界歷史。

世界觀資料不只有內容，還有時間

角色資料通常回答：

這個人是誰？

物品資料回答：

這件東西有什麼用途？

地點資料回答：

這個地方原本是什麼樣子？

這些問題都很重要。

但故事還會產生另一組問題：

這個角色在此刻在哪裡？

這件物品在這一章由誰持有？

這個地點在這場事件發生以前是否仍能進入？

這個陣營在領袖死亡後還剩下什麼結構？

同一個角色、物品與地點，可以在不同章節擁有不同答案。

因此，世界觀不能只有一份永遠顯示最新結果的資料。

它還需要保存每一次改變發生的位置。

洛恩取得鑰匙，是一次事件。

洛恩把鑰匙交給米拉，是另一次事件。

王城遭到封鎖，也是一次事件。

第十二章的世界，只承認發生在它以前的改變。

第十八章以後的世界，才需要承擔王城封鎖帶來的限制。

這不是多寫幾份角色卡就能徹底解決的問題。

因為作者真正需要的不是更多資料頁。

而是一個能沿著故事時間回答「此刻世界是什麼狀態」的方法。

InkWeave 讓正文事件與世界資料屬於同一條時間線

InkWeave 同樣具有正文編輯、卷冊與章節管理。

角色、物品、地點、陣營與屬性，也都是可以建立、查看與管理的世界實體。

不同之處在於，這些實體不是只放在正文旁邊供作者查閱。

它們可以被正文裡已確認的事件改變。

角色移動到王城，會留下移動事件。

角色取得、放置或轉交物品，會改變物品的歸屬與位置。

地點被封鎖、禁入或毀滅，會改變後續行動條件。

角色死亡、失蹤、轉職或改變屬性，也會留在實際發生的故事位置上。

所以當作者把游標放在第十二章，InkWeave 不需要只顯示銅鑰匙最後由誰持有。

因果律引擎可以沿著第十二章以前已經確認的事件，推導那一刻的答案。

洛恩已經取得鑰匙。

但他還沒有把它交給米拉。

王城也尚未遭到封鎖。

當游標移動到第二十二章，世界才會帶著後面更多事件的結果出現。

這裡的關鍵不是 InkWeave 也有一張時間線。

而是正文順序本身就是世界時間。

事件不是作者另外寫在摘要裡的說明。

它們是改變角色、物品、地點與陣營狀態的因果來源。

寫作現場不必再和世界觀分開

當作者在 Scrivener 或 Campfire 裡寫到角色名，他可以搜尋角色資料、打開相關頁面，或者把設定放在正文旁邊參考。

這些方式都比在大量散落筆記裡尋找資料有效。

InkWeave 再往前一步。

當已建立的角色、物品或地點出現在正文中，它們不只是一段可以搜尋的名字。

AVG Stage 與 Inspector 可以依照游標所在的故事位置，帶回這些實體此刻的狀態。

角色現在在哪裡。

物品目前由誰持有。

地點裡有哪些角色與物品。

相關狀態是否已經改變。

當角色和地點在正文裡靠近，世界可以詢問這裡是否發生移動。

角色和物品靠近時，可以先呈現物品目前的歸屬，再讓作者確認這裡是取得、放置、轉交，還是只有提到。

兩名角色靠近時，也可以檢查他們是否位於同一個地方，以及是否已經存在關係。

系統不會因為看到兩個名字，就自行決定故事發生了什麼。

最後仍然由作者確認。

但作者不必先離開正在寫的句子，到另一套資料裡重新拼湊世界。

設定不再只是寫作以前準備、寫作途中查閱、寫作以後補充的資料。

它會帶著前文造成的改變，回到正文旁邊。

回修前文時，差異會變得更明顯

長篇很少從第一章一路寫到最後一章，中途完全不修改。

作者可能回到第九章，決定洛恩根本沒有取得那把鑰匙。

這個修改看起來只動到一個場景。

但第十四章的轉交事件立刻失去前提。

洛恩不能把自己沒有取得的物品交給米拉。

第二十二章依賴米拉持有鑰匙的場景，也跟著失去來源。

在一般文件與世界觀管理流程裡，作者可以使用搜尋、時間線、標籤、筆記與版本比較，逐一找出需要修改的地方。

Scrivener 的 Snapshots 很適合保存修改前的文字。

Campfire 的角色、物品與 Timeline 模組也能幫助作者整理相關資料。

但它們的主要工作，是讓作者看見並管理內容。

InkWeave 的因果律引擎處理的是內容之間是否仍然成立。

當較早的取得事件被移除，後面的轉交不再只是「可能需要留意」。

它失去了因果來源。

驗證系統可以指出：這裡要求角色交出一件他在目前世界線裡並未持有的物品。

它不會替作者決定如何修復。

作者可以讓洛恩改用其他方式取得鑰匙。

可以把轉交改成另一件物品。

也可以接受後面的城門場景必須改寫。

InkWeave 不保證故事永遠不會改變。

它保證改變不必悄悄發生。

真正的選擇，是世界觀與正文要不要一起運作

Scrivener 和 Campfire 都不是只能用一句話概括的工具。

Scrivener 不只有正文。

Campfire 也不只有設定。

兩者都能承擔相當完整的小說創作流程，只是它們整理故事的中心不同。

如果比較停在章節、角色卡、時間線、圖片與輸出格式，最後很容易變成一張誰勾選了更多功能的表格。

但長篇故事真正困難的地方，通常不是功能表裡少了一個欄位。

而是角色、物品、地點與陣營在正文裡改變以後，所有後續內容是否仍然承認那些改變。

InkWeave 並不是在寫作工具和世界觀工具之間再增加第三套需要維護的資料。

它本身就是正文與世界觀共同運作的地方。

作者可以從第一章開始建立角色與物品。

也可以從第一個事件開始，讓世界記住它們如何移動、轉手、改變與失去。

故事現在有多長，不是重點。

重要的是，作者不必等到世界變得複雜以後，才開始補救已經分裂的資料。

當正文裡的事件能夠改變世界，世界又能把當時的狀態帶回正文，寫作與世界觀管理就不再是兩份需要反覆對帳的工作。

Scrivener 把長篇變成可以控制的寫作專案。

Campfire 把故事世界變成可以整理的知識結構。

InkWeave 則讓寫作專案與世界結構沿著同一條因果一起改變。

真正要比較的，不只是你能把多少資料放進工具裡。

而是當故事開始發生以後，那個世界會不會記得自己已經變成了什麼。