如何設計冒險遊戲 (Adventure Game) DreamYeh
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
主旨：
敝人夢想一直都是讓所有人都輕易學習如何設計遊戲，本篇
文章會大致上講解冒險遊戲（Adventure Game）如何被設計出來
，以及更重要的，一個冒險遊戲編輯器的撰寫。
期盼企劃人員看了本篇，能更了解如何劇情遊戲的劇本觀念
，也期盼想設計劇情遊戲的人看了本篇，能不藉由任何工具就設
計出一個好玩的劇情遊戲來。
敝人也會在之後設計個冒險遊戲編輯器。並釋放出原始檔來
，讓大家能真正看到冒險遊戲的實際設計面貌，也可以藉由編輯
器簡單設計出遊戲來！讓設計遊戲的高門檻不在是高門檻！
本篇文章大多是用敝人觀點去想，一套ＡＶＧ該怎麼設計，
或許跟實際設計法會有差距，或許哪裡沒有想到。若件到哪裡有
不足的，或有額外想法的，歡迎大家討論。
本篇文章也特別感謝子商的親切的建議。
現在，就讓我們開始ＡＶＧ設計的旅程。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
主題一、什麼是冒險遊戲（ＡＶＧ）？
別緊張，本篇並不會花很大篇幅去說明什麼是ＡＶＧ。與其
看大篇幅介紹，你還不如去找幾套經典的ＡＶＧ來嘗試一下，舉
凡無人島之旅、金田一 悲報島新的悲劇、 或是一些網路上很容
易就玩到的電子小說。這些都是很經典的ＡＶＧ－我們可以這樣
給ＡＶＧ簡單定義。
ＡＶＧ是偏重劇情的遊戲，它一定有個複雜的劇情（不會像
是超級瑪莉那樣只是要救公主的故事），常以大量文字來表示，
玩家可以做的動作大多是要在幾個劇情分支點，去做出選擇，不
同的選擇會導致不同結果。
它與ＲＰＧ一個很大差異在於，ＲＰＧ通常會把視點拉到世
界上方，好讓玩家可以自由操作角色，在一張大地圖上四處打怪
、冒險。ＡＶＧ通常會省略升級模式、在地圖上跑來跑去的活動
，而更重視於劇情的描寫、角色心境描寫、情境述說等。
依照這樣定義，ＡＶＧ範圍可是很廣泛喔！舉凡電子小說、
一般常見戀愛遊戲、一些電影改編遊戲、網路上常可以下載到的
小遊戲如逃離房間系列，都可以列入這個範疇。
當然這個定義也非完全的，近代也越來越多遊戲根本分不出
它的類型。當然啦～這裡不是要來跟大家討論遊戲分類理論的，
我們大致了解什麼是ＡＶＧ就好了。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
主題二、分歧點
讓我們一窺ＡＶＧ最重要的因子，分歧點。也就是玩家可以
選擇一個分歧點，就走向某個劇情。比方說玩家可以選擇要走樓
梯還是走電梯、看見一個房間門可以選擇要不要去開啟他。
當然也有ＡＶＧ完全沒有分歧點，像是電子小說，你只要滑
鼠原地按按按就可以看到劇情不斷被推進，直到結束。但基本上
兩者的設計原理還是一樣的（當然啦，電子小說是更簡單的）。
而這個分歧點概念，就構成整個ＡＶＧ基本設計模型，如下
：
Ｃ .....
↗
Ｂ→Ｄ .....
↗
Ａ→Ｅ→Ｆ .....
其中每個字母都代表一個「劇情」，而那個劇情裡面就會有
我們想要秀的文字、場景、音樂、想要出現的人物、它們的對話
等等。
以程式觀點，要架構這部分的決策性結構是很直覺的，你可
以輕易用一個變數表示現在應該秀出什麼場景、展示什麼變數。
然後用一個Switch或if指令讓程式知道你該做什麼。
ＡＶＧ的要點，就在於設計這些劇情、回答選項、還有每進
入一個新劇情想要做的動作。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
主題三、事件與變數
假設現在，你已經開始遊戲，並在某個分支點中選擇了你要
走向什麼劇情，可是你要怎麼讓遊戲知道你現在在哪個劇情中呢
？
又，接著你可能在某個劇情裡，發生一個事件，比方說撿到
一把鑰匙好了－那你要知道你得到一把鑰匙呢？
唯一的辦法，就是利用一個變數來儲存。
對於沒程式經驗的人，變數這個辭可能會有點難理解。其實
你可以想像這個世界有個記事官，它有本簿子專門在記載「什麼
事情發生了、什麼事情沒發生」。比方說你今天看到一筆錢，你
可以選擇撿，它就會記載「你撿了錢」－由於它只看得懂數字，
它可能在某個欄位記載１，你若沒撿錢它就會在那個欄位記載為
０。
接著世界（程式）就會根據你記載的變數，去做相對應的變
化。
以程式的觀點來看，這些動作就是「發生個事件、玩家做出
什麼選擇、就著就要改變某個『變數』」，我們通常稱這些變數
為旗標（Flag）。
整個ＡＶＧ設計模型，就會被簡化為對這些旗標的操控、以
及針對旗標不同做出的決策機制。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
主題四、劇本
讓我們喘口氣，繼續回來看這個ＡＶＧ最重要的構成因子－
劇本。
一個劇本應該有哪些東西？這當然要隨著你的遊戲內容有所
改變了－一個經典劇本裡面通常有這些東西－
場景－發生某個劇情時候，它的背景圖片是什麼？有什麼樣
的動畫？比方說如果你描寫某劇情發生在日落時候，
你背景可能是一片黃昏晚霞。
人物－在這個場景中出場的人物，在大多ＡＶＧ裡面它通常
以角色的圖片來表示。而人物出場的型態，很常見到
的一種形式就是一個圖片的飛入。
選項－需要讓玩家選定的選項，比方說是撿起、開啟一個東
西與否。內容可以是文字、或是圖片。
文字－這裡包括上述場景的文字描述、現在劇情的描寫、主
人翁們的心境描寫、還有人物們的對話。
當然很多人會更希望每個人物都有專屬的對話框
音樂－當然啦，到某個場景，你一定會有希望播送的音樂。
動畫－這是一個高級而普遍的要求！有些人很希望場景中能
加入一些複雜的動畫，比方說男女主角對話時候整個
場景就飄滿著櫻花啊、或是主角在雪原漫步時候飄落
著漫天飛雪。
以程式觀點來說這部分是最複雜的，你將會發現你可
能花更多的時間在於把某個場景的動畫弄得更漂亮。
而那些動畫對玩家來說可能只是小小的服務。因此我
們在實踐這部分，通常是用外掛方式來處理。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
主題五、劇本的資料結構
想像你已經定義好一個劇本模型了，接著麻煩的就是，你要
讓程式看懂這個劇本。
可是如同我們前面所述，程式這傢伙是很笨的！它只看得懂
數字！也就是什麼欄位是什麼數字時候，程式該做些什麼。就好
像我們前面舉例的一本簿子一樣。
而儲存這些數字的欄位、格式，我們就稱之為 資料結構。
如果你還是不懂，那我們可以再舉個例子－你可以想像你手
上有一本書，這本書每一頁都是記載各種「劇情」，那劇情怎麼
被記載？
必定是這本書每一頁都有一個「統一」的欄位，比方說第一
欄紀錄著現在是什麼場景、第二欄位紀錄著現在撥放著什麼音樂
。
而玩家可以做出各式各樣選擇，讓某些欄位變成特定的值，
而程式本體就像一個幫你翻書的人，它會根據一個特定的指示幫
你把書翻到某一頁－
比方說第十欄位是１的時候就翻到第８頁這樣。
而第十欄位很可能記載著你剛剛做的決定，比方說開門就讓
該欄位寫成１、開窗就寫成２。
你可以想像整個ＡＶＧ就好像你在看一本書，有個翻書員、
說書人、以及一個記事官。翻書員會引導你走向某一頁劇情（這
就是我們剛剛提的主題２）、說書員會告訴你這一頁劇情在說些
什麼、而記事官就隨時用這些欄位記載現在故事進行模式。
好，讓我們回到主題，記載方式。以這個例子我們可以看到
我們顯然需要一個統一的結構，來記載現在各式各樣的事物。你
可能會問為何強調需要統一格式－你可以想想看如果不同一格式
會發生什麼樣的錯誤。（再次強調你遇到那個翻書員可沒這麼聰
明）
而這些固定的欄位結構，我們稱之為容器，或資料結構。以
上面舉的劇本格式為例，它可能需要以下格式來儲存。
typedef struct Drama
{
struct Drama *NextPage[3]; //紀錄下一頁要翻到哪裡
char *Load_Music; //要讀入的音樂檔名
char *Load_Image; //要讀入的圖片檔名
char *Text_Story; //故事文字
char *Text_Menu; //選項文字
};
好吧，如果是非程式人員，可能看不懂上面表達的型態，
其實，這裡只有第一項翻的頁數是使用指標型態來指到下一個
要翻到的頁碼在哪裡。其他一律都是用字串來表示。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
主題六、劇本的演算法
好，現在你已經有本記載各式各樣劇情的簿子了－現在，你
還需要一個幫你翻簿子的人－玩家可不願意自己去根據那些複雜
的資料結構自行判斷要翻到哪一頁去。
如何設計這位幫你翻簿子的人呢？我想這部分是相當直覺的
！使用if..else、或是switch機制。你可以根據每個劇情不同的
旗標、玩家做出的選擇，去判斷下一個要指向的頁碼在哪裡。
接著要解決的問題，就剩下如何載入那些資料結構，讓畫面
顯示某張圖片、播送哪首音樂、以及顯示哪些文字了。這部分有
相當多函式庫可以支援。
若以BCB或 .Net設計，更有元件可以直接撥放音樂、顯示圖
片！
如此一來，在搭配剛剛的資料結構，一個ＡＶＧ就這樣設計
出來了！！
在此我們舉個程式例子：
void AVGMain(Drama *TempDrama)
{
int Next_Page; //定義下個要翻到的頁數
while (TempDrama!=NULL)
{
AVGShow(TempDrama); //秀出音樂、圖片、文字
AVGEventExe(TempDrame); //引導劇情
Next_Page = AVG_Next(TempDrame); //找尋下一頁要跳到哪’
TempDrama = TempDrama.NextPage[Next_Page]; //跳頁:)
}
}
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
主題七、劇本編輯器
旅行到這..如果你是個企劃組人員，你一定會上述兩個核心
主題頭大到不得了吧。
你甚至可能抱怨：「弄了半天～我還是不懂怎麼寫嘛！」
但你要知道，了解上面講述的概念對你來說還是很重要的。
或許你看不懂程式碼部分，但相信這些概念對於你設計一套遊戲
－或許藉由任何工具，是大有幫助的。
一些程式組成員可能也會發現，我故意漏講一些概念，像是
指標，甚至我還有偷用到 Link List，這些有趣的資料結構對於
儲存劇本有多大幫助。不過在這裡為了普遍性我想還是給大家自
行研究。:P
那回歸我們本意，既然我們是希望每個人都可以簡單學會遊
戲設計－那上面講的所有專業知識，你都可以忘掉了－不過你切
記你還是要了解他基本概念是什麼－
接著你可能就會希望，有個能人能設計出個簡單的ＡＶＧ設
計引擎，來幫助不懂程式的你怎麼寫ＡＶＧ來！
簡單的ＡＶＧ編輯器？這當然是有可能的！甚至是最容易實
現的遊戲編輯器。典型的ＡＶＧ編輯器有戀愛遊戲設計大師、吉
里吉里、和ＥＡＶＧ。
簡單來說就是避開讓企劃人員接觸到程式碼的可能，藉由一
些虛擬碼、甚至是一些介面，讓企劃人員可以簡單製作ＡＶＧ。
所謂虛擬碼是什麼？它就是一個專門給程式看「現在要做什
麼」的代碼。
以吉里吉里為例，它底層程式架構為ＴＳＪ語法，那是一個
類似JavaScript的程式語言。但由於一般人學習該語法仍有門檻
，因此他又有一個 KAG虛擬碼把 TSJ包起來。
比方說我們可以定義<I>代表顯示某張圖片、<S>代表撥放某
首音樂，<T>代表顯示一段文字，並在一定時間後消去。
那企劃組人員要寫一段劇情，它就可以這樣寫：
<I>Angel_At_Snow.jpg</I>
<S>Angel's Song.mp3 </S>
<T>他佇立在一片雪白的遠野，四周都是白的</T>
<T>他的衣服是白的，背後的翅膀也是白的</T>
<T>輕飄飄的羽毛好像跟瑞雪融合，倘佯在一片白色的無盡裡...</T>
這對企劃組來來說，可以說是大大節省的他所需要付出的心
力和學習時間，只要透過簡單的語法，就可以輕易交代現在劇本
內容、以及要表現出來的場景。
那他程式方面設計原理是什麼？
其實也很簡單，就是一個幫助企劃組人員把上述虛擬碼轉化
成程式碼，在幫助他們把程式碼編譯出來的步驟。
比方說上述虛擬碼，轉換成程式可能是這樣的：
#include <MyLibary.h> //我們可能會大幅簡化顯示圖片和音樂的過程
//因此，你必須寫一些函式庫，然後包進來
Image_Main->LoadFromFile("Angel_At_Snow.jpg");
Form->Music->LoadFromFile("Angel's Song.mp3");
Memo1->Lines->Append("他佇立在一片雪白的遠野，四周都是白的");
Memo1->Lines->Append("他的衣服是白的，背後的翅膀也是白的");
Memo1->Lines->Append("輕飄飄的羽毛好像跟瑞雪融合，
倘佯在一片白色的無盡裡...");
接著就在編譯成可以執行的執行檔就好了。中間當然別忘了
Link你的函式庫。因為你在轉化虛擬碼為實際程式碼過程中。
很有可能被迫省略一些步驟，比如說圖片特效處理，那些東
西對企劃人員來說可能只是一行－
OB
<A> "滿天飛雪的動畫" </A>
而這些對你來說很有可能其實是一大串的程式碼。因此你必
須額外寫函數庫，以便企劃人員可以更簡單地寫出他的遊戲來。
你們兩個互相合作，他貢獻他的編劇能力、你貢獻你的程式
技術，一個遊戲，就這樣誕生了！！！
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
結語：
終於到結語了！鬆了口氣吧！經過這次旅程，我們從ＡＶＧ
基本概念說起，討論他分歧點概念、事件概念、劇情概念，並簡
單提及ＡＶＧ的資料結構與演算法。
後面我們特別介紹了如何去撰寫一個ＡＶＧ編輯器。這裡目
的就是希望讓遊戲設計門檻更降低！讓遊戲設計更普及！希望大
家看完本篇文章，能得到些什麼啟示，也歡迎大家針對本篇文章
內容繼續進行討論！
之後敝人也會投入去撰寫個免費的、公開原始碼的ＡＶＧ編
輯器，期盼讓更多人能加入遊戲設計行列，讓一群人一起追逐夢
想！
若你跟敝人有著共同的理想，希望創造出個大家的遊戲、能
被大家共同設計的遊戲、為了大家而發展出的遊戲。也歡迎你跟
敝人聯絡～
希望能跟大家一起築夢！一起設計出好玩得遊戲來！
－－－－－－－－－－－－－－－－－－－－－－－－－－－－
留言列表
美食 (2)