why scripting?
why scripting?
簡單一句話就是:「為了增進生產力」。不過這樣回答的話,就會衍生出另外一個問題:
「為什麼要增進生產力?」當然不是這個問題,這種問題根本沒有回答的必要。
這個問題是:「如何增進生產力?」
我們知道有一些狀況下,必須不斷修改程式,不管是因為現階段不知道最好的解決方式
是什麼,或是現況真的是會不斷改變。總而言之,我們必須「嘗試」而後「修改」。
這種時候,我們可以用需要 compile 而後 link 的程式語言(或是工作環境)嗎?
這篇影片道出了一些 "why": Better Web App Development
可以不用看沒關係,這邊會稍微提一下大概內容。簡單地說,GUI 的部份是最明顯的。
因為我們不知道我們的 user 會比較想要哪一種操作模式,甚至,連他們自己也不清楚。
這種事說來很不可思議,但實際上就是如此。很多事情是很難預測的。或是該說,
要正確地預測事情的成本,遠遠高於直接試試看,再從中獲取經驗,進而修改以符合
我們的希望。所以我們需要的是「能夠快速修改、變化」的程式語言(或是工作環境)。
scripting 就是為此而誕生的。他們的立意和 system programming 有著根本上的不同,
所以無須拿此二者來比較。這一篇並不是想探討此二者間的異同,所以不會再對此著墨。
這裡直接假設兩者同等重要,以此討論兩者之間該如何取得平衡。
*
事實上,越是前端的程式,越是需要此種「變化」的特性。因為 system programming
是面對機器,而機器可不會跟你鬧脾氣。(如果不明原因的當機不算的話…)
但是 scripting 通常是面對人,而人可是可以陰晴不定,今天好好的明天就跟你翻臉,
或是嘴巴說不要,身體倒是挺誠實的,諸如此類的問題可多著。
為了「適應」人的這種「特性」,我們也需要一個擅長「變化」的東西,
以此銜接 system, application, 與人類。
除此之外,大家也都知道 scripting 的執行效率一定遠遠不如 binary program,
在大部份的情況下,這不是個問題。因為現在的電腦已經快到一種很恐怖的境界了,
真的非常需要執行效能的狀況,其實很少。更何況大家都知道 80-20(1) 法則,效能的
重要性只會隨著時間越來越減少,但永遠不會消失,因為人的慾望是無窮的…。
*
舉遊戲程式為例。一般比較大型的遊戲程式,大抵上都會切成三個部份。第一個是
廣為人知的 engine, 這邊的執行效能是非常 critical 的。第二部份是遊戲主程式,
這部份一般而言,效能也是非常重要的,所以還是會以 C++ 來完成。但是有些東西,
卻不得不引入 scripting, 儘管執行效能可能會是個問題,但還是不得不引入。
這就是第三個部份,掌控一些最細微的遊戲設定,也是跟「人」最有關係的部份。
為何這部份需要引入 scripting? 最簡單的例子就是平衡度設定。Dragon 是否太強?
Drawf 是否太弱?Golem 需不需要再多加個 Trample 的能力?Ranger 的 favored enemy
是否該換成 Goblin? 諸如此類,不是一開始就能確定,你一定得「玩一玩」才有可能
知道的麻煩事。甚至,必須讓成千成萬個玩家去玩過,才會知道的,很隱晦的事。
在複雜系統之下,這種碰過才知道的事,是非常多的。但是我們可不能稍微修改一下,
重新 compile, link, 泡杯咖啡。接著測試兩分鐘,啊,不行,這個數字應該再減少一個
單位。重複上面發生的事。這樣別說效率很差了,耐心都被磨光了。有些時候,士氣其實
是遠遠重要於產出的程式,像這種極度消磨耐心的事,再怎麼樣都是不能出現的。
引入 scripting 的好處就在這裡,我們可以輕易地修改程式,接著直接重新啟動遊戲
即可。更有甚者,直接叫你的遊戲重讀 script 檔即可,連重新啟動遊戲都不必。
不過就像我上面說的,基本上遊戲是個幾乎每一處都很 critical 的程式,所以
scripting 也要越快越好。最常被選用的就是 Lua, 因為他真的很快。不過啊,個人是
不太喜歡使用 Lua, 因為他和 C++ 間的連接不是那麼地良好,怎麼說,有點詭異…。
第二個最常被使用的,可能是 Python. 這是個相當不錯的程式語言,boost 也有一整份
Python 的 binding library. 不過我個人還是比較偏好 Ruby 一點,Ruby 是目前為止
我看過我覺得最好的 scripting language, 原因很多,但主要可能是因為他對物件導向
的支援非常完善,而物件導向在遊戲裡,是個幾乎可以說不能沒有的東西。光 GUI 就
非常仰賴物件導向了,更何況 GUI 只是遊戲的一部分。這部份可以很複雜,也可以很
單純。但不管怎麼樣,物件導向都太重要了。
*
所以事實上,我是很希望遊戲程式可以引入 Ruby, 雖然 Ruby 的執行效能比較差,
但應該好用的東西就應該好用到底,應該跑得快的東西就應該快到底,我是這樣認為的。
Python 被用很多,但我相信 Ruby 也會越來越重要。最近也確實如雨後春筍一般,
四處都出現其應用,不是嗎? :p
boost 沒有提供 Ruby binding 是有點可惜,我想這是因為 Ruby 的熱門是最近幾年的
事。不過呢,SWIG 還是有提供 Ruby 的 binding! 而且也是相當完整的支援。
何不就來試試 C++ 透過 SWIG 與 Ruby 溝通的方式呢? :p
欲知詳情,請待下回分曉。
2007.03.16 godfat 真常
p.s. 為何遊戲一定要用 C++? 這…不在本篇討論範圍裡 :o
(1) 一個程式只有 20% 的部份會佔去 80% 的執行效率。或是各種類似說法。
簡單一句話就是:「為了增進生產力」。不過這樣回答的話,就會衍生出另外一個問題:
「為什麼要增進生產力?」當然不是這個問題,這種問題根本沒有回答的必要。
這個問題是:「如何增進生產力?」
我們知道有一些狀況下,必須不斷修改程式,不管是因為現階段不知道最好的解決方式
是什麼,或是現況真的是會不斷改變。總而言之,我們必須「嘗試」而後「修改」。
這種時候,我們可以用需要 compile 而後 link 的程式語言(或是工作環境)嗎?
這篇影片道出了一些 "why": Better Web App Development
可以不用看沒關係,這邊會稍微提一下大概內容。簡單地說,GUI 的部份是最明顯的。
因為我們不知道我們的 user 會比較想要哪一種操作模式,甚至,連他們自己也不清楚。
這種事說來很不可思議,但實際上就是如此。很多事情是很難預測的。或是該說,
要正確地預測事情的成本,遠遠高於直接試試看,再從中獲取經驗,進而修改以符合
我們的希望。所以我們需要的是「能夠快速修改、變化」的程式語言(或是工作環境)。
scripting 就是為此而誕生的。他們的立意和 system programming 有著根本上的不同,
所以無須拿此二者來比較。這一篇並不是想探討此二者間的異同,所以不會再對此著墨。
這裡直接假設兩者同等重要,以此討論兩者之間該如何取得平衡。
*
事實上,越是前端的程式,越是需要此種「變化」的特性。因為 system programming
是面對機器,而機器可不會跟你鬧脾氣。(如果不明原因的當機不算的話…)
但是 scripting 通常是面對人,而人可是可以陰晴不定,今天好好的明天就跟你翻臉,
或是嘴巴說不要,身體倒是挺誠實的,諸如此類的問題可多著。
為了「適應」人的這種「特性」,我們也需要一個擅長「變化」的東西,
以此銜接 system, application, 與人類。
除此之外,大家也都知道 scripting 的執行效率一定遠遠不如 binary program,
在大部份的情況下,這不是個問題。因為現在的電腦已經快到一種很恐怖的境界了,
真的非常需要執行效能的狀況,其實很少。更何況大家都知道 80-20(1) 法則,效能的
重要性只會隨著時間越來越減少,但永遠不會消失,因為人的慾望是無窮的…。
*
舉遊戲程式為例。一般比較大型的遊戲程式,大抵上都會切成三個部份。第一個是
廣為人知的 engine, 這邊的執行效能是非常 critical 的。第二部份是遊戲主程式,
這部份一般而言,效能也是非常重要的,所以還是會以 C++ 來完成。但是有些東西,
卻不得不引入 scripting, 儘管執行效能可能會是個問題,但還是不得不引入。
這就是第三個部份,掌控一些最細微的遊戲設定,也是跟「人」最有關係的部份。
為何這部份需要引入 scripting? 最簡單的例子就是平衡度設定。Dragon 是否太強?
Drawf 是否太弱?Golem 需不需要再多加個 Trample 的能力?Ranger 的 favored enemy
是否該換成 Goblin? 諸如此類,不是一開始就能確定,你一定得「玩一玩」才有可能
知道的麻煩事。甚至,必須讓成千成萬個玩家去玩過,才會知道的,很隱晦的事。
在複雜系統之下,這種碰過才知道的事,是非常多的。但是我們可不能稍微修改一下,
重新 compile, link, 泡杯咖啡。接著測試兩分鐘,啊,不行,這個數字應該再減少一個
單位。重複上面發生的事。這樣別說效率很差了,耐心都被磨光了。有些時候,士氣其實
是遠遠重要於產出的程式,像這種極度消磨耐心的事,再怎麼樣都是不能出現的。
引入 scripting 的好處就在這裡,我們可以輕易地修改程式,接著直接重新啟動遊戲
即可。更有甚者,直接叫你的遊戲重讀 script 檔即可,連重新啟動遊戲都不必。
不過就像我上面說的,基本上遊戲是個幾乎每一處都很 critical 的程式,所以
scripting 也要越快越好。最常被選用的就是 Lua, 因為他真的很快。不過啊,個人是
不太喜歡使用 Lua, 因為他和 C++ 間的連接不是那麼地良好,怎麼說,有點詭異…。
第二個最常被使用的,可能是 Python. 這是個相當不錯的程式語言,boost 也有一整份
Python 的 binding library. 不過我個人還是比較偏好 Ruby 一點,Ruby 是目前為止
我看過我覺得最好的 scripting language, 原因很多,但主要可能是因為他對物件導向
的支援非常完善,而物件導向在遊戲裡,是個幾乎可以說不能沒有的東西。光 GUI 就
非常仰賴物件導向了,更何況 GUI 只是遊戲的一部分。這部份可以很複雜,也可以很
單純。但不管怎麼樣,物件導向都太重要了。
*
所以事實上,我是很希望遊戲程式可以引入 Ruby, 雖然 Ruby 的執行效能比較差,
但應該好用的東西就應該好用到底,應該跑得快的東西就應該快到底,我是這樣認為的。
Python 被用很多,但我相信 Ruby 也會越來越重要。最近也確實如雨後春筍一般,
四處都出現其應用,不是嗎? :p
boost 沒有提供 Ruby binding 是有點可惜,我想這是因為 Ruby 的熱門是最近幾年的
事。不過呢,SWIG 還是有提供 Ruby 的 binding! 而且也是相當完整的支援。
何不就來試試 C++ 透過 SWIG 與 Ruby 溝通的方式呢? :p
欲知詳情,請待下回分曉。
2007.03.16 godfat 真常
p.s. 為何遊戲一定要用 C++? 這…不在本篇討論範圍裡 :o
(1) 一個程式只有 20% 的部份會佔去 80% 的執行效率。或是各種類似說法。
2 則留言:
而單純比大小的話, Lua 絕對是勝者. Lua 還有魔獸世界3幫忙背書. 作為遊戲腳本 Lua 也勝任有餘.
Python 也是 OO 語言, 同時還具備支持 procedure/function 程式設計的彈性.
另外一個優點是 python 與 c/c++ 之間互相的嵌入性已經經過10多年地考驗來證實其強健處.
我知道[吸血鬼: 暗夜獵殺]系列是採用 python 作腳本語言.
話說回來, 用 Ruby 作遊戲的嵌入腳本語言應該也沒什麼問題才對. 也許日本那邊已經有這樣的作品也不一定? 只是我們不知道吧.
魔獸世界3 ? XD
不過就我所知,Blizzard 慣用 Lua 是真的。
Ruby 就我所知,是有遊戲用之,只是目前還遠沒 Lua 和 Python 多。
其實我也沒特別在注意,不然可以多舉點例子 :p
現在只想得到 RPG Maker XP 是比較大的一個例子。
而且這是好多年前的事了,應該有四五年左右了。
張貼留言