ONScripter

最初是一個叫Ogapee的傢伙想在自己的Zaurus（SHARP公司推出的高性能PDA）上運行遊戲，於是自己寫 了一個在Linux下運行的NScripter等效引擎，命名為ONScripter（Open-source NScripter），並不斷完善之。由於開放源代碼並且是用高度可移植的SDL庫編寫的，很多愛好者就把它移植到不同的平台上，並不斷地把使用其他遊戲引擎的AVG遊戲移植到該平台上，使得ONScripter不斷地發揚光大。

流傳的中文版並無官方授權，乃由玩家自行改版產生。

與NScripter為了編寫新遊戲不同，ONScripter設計當初就是為了在別的平台運行用NScripter製作的遊戲。目前發展最成熟的是安卓和Linux平台，大多數遊戲都能夠順利移植。目前，通用引擎只有Waffle(AVG32)和ONScripter已經成功移植，而ONScripter又是當中資料和工具比較多的，因此也會有人把本來不是NS引擎編寫的遊戲用NS重新編寫並用ONS在別的平台上運行，例如《Fate / stay night》和《CLANNAD》等。

商用作品（不完全列表）

同人作品（不完全列表）

移植作品（不完全列表）

與Nscripter的區別

由於NScripter上手容易，運行速度快，擴充性也不錯，廣泛受到同人遊戲製作群的歡迎。引擎代碼本身雖然為非公開，但是在非商業用途下是屬於免費軟體。

NScripter本身只支持Windows，不過兼容度極高非官方的ONScripter可支持跨平台的需求。

ONScripter兼容大多數NS指令，但兩者的API及指令集仍然有區別，少數命令有不兼容的現象。

開發者可利用所謂的中間語言來撰寫遊戲的代碼。

開發與分支

運行環境

Onscripter能在以下平台運行：

• Android (1.6 or later)

• Zaurus (SL-C700, etc.)

• Linux

• MacOSX

• Windows

• Windows Mobile

• Windows CE

• PSP

• iOS 4或以上

• NetWalker

• Brain (WindowsCE 6.0)

• NetBSD, DragonFly BSD

• OS2/Warp

• Playstation3

• Wii

• FreeBSD

• Dreamcast

……

以下為必須：

●C++ 環境：

○g++ 4.4.4 或更高(Linux)

○Visual Studio 2008 C++ 或更高(Windows)

●Unicode集的 TTF 字體(文件名default.ttf)

●libjpeg-6b (Independent JPEG Group)

●bzip2-1.0.5 (bzip2)

●SDL-1.2.14, SDL_image-1.2.10, SDL_mixer-1.2.8, SDL_ttf-2.0.9 (Simple Directmedia Layer)

●FreeType 2.3.11 (the Free Type Project)

以下為推薦項目，可根據自己的實際情況酌情考慮：

●Mpeg Audio Decoder

●avifile Decoder

基於NScripter產生的其它分支

ONScripter-EN：

ONScripter-EN是一個主要由英文社區維護的分支，目的是為了更簡單方便地引進適合英文社區的引擎增強。舉例來說，ONScripter-EN支持遊戲內切換英文-日文，而在ONScripter中，支持的遊戲語言在編譯時就已經確定了。

這個引擎被用於很多的英化遊戲中，比如英文版《水仙》和《月姬》等。

Proportional ONScripter：

PONScripter ("Proportional-OnScripter"的簡稱) 是ONScripter-EN的一個分支。側重於為西方語言化翻譯作品提供一個簡單的移植工具。PONScripter在ONScripter-EN代碼基礎上做出了大量的改動，並故意不向後兼容。

PONScripter 最初由Peter "Haeleth" Jolly維護。從2009年七月起主要由寒蟬鳴泣之時英化小組的Mion of Sonozaki Futago-tachi維護。

使用PONScripter移植的遊戲有：英文版《沙耶之歌》、《水仙2》。

ONScripter-GBK：

ONScripter-GBK版最早出現在PSP上，其後又出現在魅族M8上（由WinCE版修改而來），而Android版的ONScripter-GBK最早由nbnb001修改ONScripter-JIS版而來，而後一直是natdon在進行維護。相比起原版而言，GBK版本的ONScripter支持新的腳本加密格式（nt2/nt3），以及新的命令（控制震動等）。Android上最新版的ONScripter-GBK被整合進了麵包工坊的MiNE模擬器中。

維護

1.SDL & ONScripter: 可移植性。

ONScripter 最大的優點就是其高度可移植性，這不僅是由於它基於移植性極佳的 SDL，更是因為它自身就是以高度可移植性為目標編寫的。

ONScripter 的作者原先使用的設備是 Sharp 的 Zaurus. 這台跑 Linux 的設備性能非常有限，還是很佩服作者下決心去做這件事情的。假如它只能跑在 Zaurus 上的話，那麼隨著 Zaurus 的離去，它也會逐漸化為塵土。但是開源和可移植性帶給了它更長久的生命力。

ONScripter 選擇 SDL 為其基礎是一個很好的決策——SDL 大概是目前能跑的設備最多的圖像引擎之一。 ONScripter 使用的其他庫基本也都是移植性比較好的庫，對比用了 boost 的 rlvm，移植了後者的設備就少了很多。

開源的好處就是大家都可以貢獻自己的力量。在大家的支持下，ONScripter 支持的設備越來越多。國內的設備一但移植上了SDL，接下來最常見的被移植的遊戲就是 opal(開源版仙劍，同樣基於 SDL) 和 ONScripter 了。這也是為什麼十年過去了，ONScripter 仍然被我們所使用的原因。

對於移植者來說，大家選擇 ONScripter 最大的理由就是它實在是太能跨平台了。縱使它有這樣那樣的缺點，很多時候也沒有更好的選擇。對比 ONScripter 一次寫成造福萬設，能做到這一點的其他引擎實在是找不到了。

2.NScripter: 完善的基本功能。

ONScripter 的另一大成功之處在於，它的目的在於模擬 NScripter。

高橋的 NScripter 在當年大受歡迎，雖然現在看來功能還是欠缺不少，但不得不承認， NScripter 的確是一個合格的 Galgame 引擎。它具備實現一個 Galgame 所需要的全部基本功能的能力。

並且，假如你依照它給的框架走，實現起來也非常精鍊。

大量原版 NScripter 引擎的遊戲被移植也使得 ONScripter 大受歡迎，同時也煥發了那些老遊戲以及 NScripter 自身的第二生命。

1.性能。

性能問題一方面是 SDL 的問題，一方面是 ONScripter 自己編寫的問題。

SDL 的主要問題在於最初移植過去的時候一般是基於軟解的。當然該來的總是會來的，硬體加速還是會來的。

ONScripter 的代碼里的確有些寫的很“素”的地方。平蕪泫的評價一語中的：

“該說不愧是日本人的思維么？在指定環境下面能夠非常好地工作，不是這個環境就糟糕了……”

順提，該貼里的 bug 是 Arch 里的 SDL_ttf 的問題，其實和 ONScripter 關係不大，現已修復。

我倒不覺得性能是極度重要的問題。當然它確實重要。

一方面，只要總的框架沒有大問題，先保證正確再優化也不為過，畢竟過早優化是萬惡之源，開源對這種問題也是一種好的解決方案。

另一方面，ONScripter 很大的瓶頸還是在 IO 和顯示上。對於那些 label 用鏈表 lookup 之類的，倒也真不是什麼性能問題。

2.NScripter 的表達能力。

我想這部分才是我對 ONScripter 意見最大的部分——儘管這部分應該歸到 NScripter 的問題上。

平蕪泫的評價在這裡仍然適用：如果你照著高橋佬的想法走，NScripter 是非常爽快的；但如果不是這樣的話，你就會覺得 NScripter 處處捆人手腳。

不幸的是，移植的目的是模仿另一款遊戲重新實現它，想完全照著 NScripter 的思路走往往沒那麼容易。

高橋是很清楚一款 Galgame 引擎需要什麼的，但是除此之外的事情他就懶得管了。NScripter 的語言設計明顯是混亂的。命令式的風格，一些計算上的東西又明顯是彙編的樣式，很多函數明顯是後頭擦屁股添上的，最終發現這事沒法弄了又開始支持 lua……

總之，NScripter 自己從語言角度而言還是很不靈活的。說實在的，很多事情不是不能實現，而是實現太麻煩。

3.動畫效果實現繁瑣。

NScripter 的動畫基本要靠自己寫循環控制。不講究時間精確性可以用 for 循環，追求時間卡准可以 while(即 if-goto) 循環靠 timer 精確控制，當然可以抽象到自定義過程中，總歸還是麻煩的很。更別提縮放和旋轉了。

要是實現全屏雨點效果呢？那就不得不依賴插件，而那是平台相關的，移植性很差。

順提，msp 的移動效率不咋樣。

NScripter 語言的混亂之處還在於，它竟然有lsp、lsp2、drawsp、blt等不同體系的功能去做類似的事情。

并行動畫實現困難。

怎樣讓兩個移動共同實現？你不得不在一個循環中同時做兩個移動。如果你已經把移動抽象到一個過程中了呢？如果是全屏震動的同時移動呢？如果是移動同時縮放呢？上面這些 Fate 里都不少，而且我希望抽象到一個過程中。我當時很頭疼。

對比 Kirikiri2 里解析腳本默認不阻塞動畫執行，這邊表達起來的確費勁的多。

但還好，上面起碼還算是好表達的。如果想表達類似穢翼序章窗外的雨滴落下，或者魔法使之夜裡人物對話時背景緩緩移動的效果呢？

NScripter 對話過程中同步畫面移動的方法只有利用多幀圖片動畫，這得做多少張？對魔夜這種大背景圖緩慢移動的，恐怕圖片都載入不進去。

4.畫面再加工能力匱乏。

很多引擎會對圖片加效果，比如通過色調和光線變化可以將一張圖重複利用在多個場景。也有圖片直接翻轉和旋轉使用的。

NScripter 倒是支持黑白和反色。如果不需要考慮統一處理，也可以做旋轉。除此之外就很有限了。

當然總可以靠圖像處理軟體預先處理，然後替換文件名(fate 移植時是這麼做的)。只是，麻煩。

5.聲音部分的控制能力簡單。

一些其他引擎的遊戲，有時會將一段音樂分為兩段，一段是 head 只播放一次，一段是 loop 只循環這部分。有些引擎乾脆就把兩段合併為一個文件，設定好 loop 的時間段即可。

對語音有時需要更精確的控制時間，比如語音結束的時候觸發 XX 效果。

NScripter 中很難實現這些部分。最大的難點還是在“如果當前正在對話，將無法控制其他部分”。

6.語言表達能力缺乏。

NScripter 從語言特性上和 php 有部分地方挺有共同之處的，比如它們在自己的領域表現都不錯，但是語言設計的都挺不考量的。

NScripter 里真正有的是過程而非函數，注意它定義過程用的是 defsub. 比如說，對於類似$2 = str(int($1) + int($0)) 這種東西，你就不得不一堆 atoi/itoa 過去，還要產生一堆臨時變數，簡潔度大打折扣。

NScripter 最缺乏的是臨時變數。 NScripter 里的所有變數都是全局相關的。假如你需要實現很多過程的時候，你就不得不擔心變數分配問題了。這實際上是很噁心的。

NScripter 里沒有自定義結構。你需要自己設計地址分配，自己設計介面。

NScripter 缺乏一些反射功能(也許用這個詞不妥)，比如，某層載入的圖片文件名是什麼？在什麼位置？是否真的載入了文件(而不是載入但不顯示)？如果你需要，那就只好自己保存下來——用自定義的結構。

拿 NScripter 計算是一件痛苦的事情。