玩過許多軟體的人或許都會對那些提供功能擴充界面（外掛界面）的軟體有相當的印象，例如emacs, firefox, notepad++, WoW, Homeworld2等。這些軟體如了原本就有的功能以外，由於擴充界面的存在，讓許多有創意有能力的大眾得以把程式改良到接近自己所喜愛的樣子；而這些被製作出來的外掛則反過來增加了程式的知名度，讓程式得以接觸更多的人。
外掛的特點是，我們可以在不修改原始程式的情況下增強原本程式的功能。這樣子的特點除了讓普羅大眾得以實現其夢想外，也讓遊戲內容設計人員和程式設計師得以更有彈性的分頭作業：程式設計師設計遊戲的核心（繪圖、計時器、基本規則、資料處理等），關卡設計人員設計關卡（佈景的擺設、場景物件與玩家的互動等），怪物設計人員設計怪物（外觀、行動規則等）。
以往的狀況，內容設計人員多半只能靜態的調整遊戲的內容。例如說，遊戲引擎提供「太靠近某物會受傷」的資料標記，內容設計人員就可以使用它；但如果內容設計人員想要「某物會產生物體並投射之」（設計師：設計個隱藏十字弓鑶在樹叢裡）的功能，就只能央求程式設計師來完成它。
假如程式設計師把遊戲引擎設計成有足夠的彈性並且提供了可擴充界面，那麼內容設計人員就可以更有彈性的設計遊戲的場景，再也不必擔心創意受限！
上面所提到擴充界面的使用涉及程式撰寫，然而為了讓有創意的人們得以方便的擴充程式的能力，擴充界面勢必得接受比較容易使用的程式語言。若是擴充界面所依賴的程式語言過於艱澀難懂，就會形成一道阻止人們創意發揮的高牆，讓外掛界面形同虛設。在我看來，KDE Dolphin的擴充界面便屬於此一情形：以C++為主，而且文件似乎不多。雖然Dolphin的作者可以指出現存的開放原始碼例子，但可想而知，這樣子的門檻相較於那些附上了「請你跟我這樣做」外掛製作教學的軟體，或是使用了簡單的程式語言（javascript, lua, python等）來當作擴充界面的軟體來說則可說相當的高。
之前提到過我製作了brainf*k (BF)的直譯器，接下來的目標是BF編譯器。可以做多種輸出的BF編譯器不是很棒嗎？我這樣想著。要製作多種輸出格式的編譯器的其中一種方法是把各種格式的輸出程式寫死在程式裡面，然後編譯時選一個，或者是全部編譯進程式裡面。另一種方法則是設計一個擴充界面，然後把輸出程式的輸出過程全部放到擴充區（外掛）裡面。看完上面的介紹之後，應該可以猜到我很明顯的是偏向後者。
擴充界面的設計..似乎是一個頭痛的問題呢！我第一個想到的設計是使用gmodule或類似的方法來載入動態執行程式庫外掛。然而製作動態執行程式庫並不是很有趣的事情：麻煩而且不跨平台。那麼，使用現成的scripting language來當作擴充界面語言如何？好是好，但又產生了另外的問題：要挑選哪個程式語言呢？Python? Ruby? Lua? Lisp?
Ruby不太熟悉，Python雖然熟悉，語法也輕簡，但感覺有點太大，Lisp..我不知道怎麼把lisp engine嵌入程式裡..剩下lua了，讓我瞧瞧...它的語法簡單易學（一小時就掌握語法！），lua引擎也不大（編入程式也不會嫌大），跨平台性也強（使用標準C）。真是個好選擇！
為了探索lua的基本用法，寫了一個計算程式（程式碼在這裡）。這個程式載入一個lua script，確定參數數量後，向使用者索取參數，接著把參數傳送給lua script中所記載的算式來進行計算。
沒有留言:
張貼留言