遊戲介紹
《ONS通用遊戲引擎高清版》
分享類型：免費
所屬分類：模擬遊戲
系統要求： 1.6版本 2.1版本 2.2版本 2.3版本 2.4版本 3.1版本 3.2版本
分 辨 率：240*320 320*480 480*640 480*800 480*854 640*960
所需許可權：無敏感許可權
Onscripter（Open Source Nscripter Galgame Engine）是一個用來解析NScripter腳本的第三方開源AVG遊戲引擎，可以在多種平台和設備上（Windows，Linux，FreeBSD，Android，iOS，Symbian……etc）上運行使用NScripter腳本編譯的文字冒險類遊戲。
發展歷史
最初是一個叫Ogapee的傢伙想在自己的Zaurus（SHARP公司推出的高性能PDA）上運行遊戲，於是自己寫了一個在Linux下運行的NScripter等效引擎，命名為ONScripter（Open-source NScripter），並不斷完善之。由於開放原始碼並且是用高度可移植的SDL庫編寫的，很多愛好者就把它移植到不同的平台上，並不斷地把使用其他遊戲引擎的AVG遊戲移植到該平台上，不斷地發揚光大。流傳的中文版並無官方授權，乃由玩家自行改版產生。
目的
與NScripter為了編寫新遊戲不同，ONScripter設計當初就是為了在別的平台運行用NS製作的遊戲。目前發展最成熟的是安卓和Linux平台，大多數遊戲都能夠順利移植。通用引擎只有Waffle(AVG32)和ONScripter已經成功移植，而ONScripter又是當中資料和工具比較多的，因此也會有人把本來不是NS引擎編寫的遊戲用NS重新編寫並用ONS在別的平台上運行，例如《Fate / stay night》和《CLANNAD》等。
套用案例
商用作品
銀色（貓貓社）
月は東に日は西に ～Operation Sanctuary～（オーガスト）
バイナリィ・ポット（オーガスト）
Princess Holiday ～転がるりんご亭千夜一夜～（オーガスト）
水色（貓貓社）
同人作品寒蟬鳴泣之時系列（07th Expansion）
海貓鳴泣（07th Expansion）
月姫（TYPE-MOON）
ONS通用遊戲引擎高清版ひとかた（お竜）
水仙~narcissu~1&2（stage-nana）
移植作品
Key社
AIR\Clannad\Planetarian\Little Busters!
KID社
Memories Off 2nd\ever17minori
eden*\ef-the first tale\ef-the latter tale\天使的日曜日AKABEiSOFT2
車輪之國、向日葵的少女\車輪之國、悠久的少年少女貓貓社
銀色
彈珠汽水
Scarlett八月社
穢翼的尤斯蒂婭
夜明前的琉璃色
CUFFS社
緣之空
悠之空PULLTOP
遙仰凰華
Lass
3daysTYPE-MOON
Fate stay Night
技術
對比Nscripter
由於NScripter上手容易，運行速度快，擴充性也不錯，廣泛受到同人遊戲製作群的歡迎。引擎代碼本身雖然為非公開，但是在非商業用途下是屬於免費軟體。
NScripter本身只支持Windows，不過兼容度極高非官方的ONScripter可支持跨平台的需求。
ONScripter兼容大多數NS指令，但兩者的API及指令集仍然有區別，少數命令有不兼容的現象。
開發者可利用所謂的中間語言來撰寫遊戲的代碼。
優點
SDL & ONScripter: 可移植性。ONScripter 最大的優點就是其高度可移植性，這不僅是由於它基於移植性極佳的 SDL，更是因為它自身就是以高度可移植性為目標編寫的。ONScripter 的作者原先使用的設備是 Sharp 的 Zaurus. 這台跑 Linux 的設備性能非常有限，還是很佩服作者下決心去做這件事情的。 假如它只能跑在 Zaurus 上的話，那么隨著 Zaurus 的離去，它也會逐漸化為塵土。 但是開源和可移植性帶給了它更長久的生命力。
ONScripter 選擇 SDL 為其基礎是一個很好的決策——SDL 大概是目前能跑的設備最多的圖像引擎之一。 ONScripter 使用的其他庫基本也都是移植性比較好的庫，對比用了 boost 的 rlvm，移植了後者的設備就少了很多。
開源的好處就是大家都可以貢獻自己的力量。 在大家的支持下，ONScripter 支持的設備越來越多。 國內的設備一但移植上了SDL，接下來最常見的被移植的遊戲就是 opal(開源版仙劍，同樣基於 SDL) 和 ONScripter 了。 這也是為什麼十年過去了，ONScripter 仍然被我們所使用的原因。對於移植者來說，大家選擇 ONScripter 最大的理由就是它實在是太能跨平台了。 縱使它有這樣那樣的缺點，很多時候也沒有更好的選擇。 對比 ONScripter 一次寫成造福萬設，能做到這一點的其他引擎實在是找不到了。
NScripter: 完善的基本功能。
ONScripter 的另一大成功之處在於，它的目的在於模擬 NScripter.
高橋的 NScripter 在當年大受歡迎， 雖然現在看來功能還是欠缺不少，但不得不承認， NScripter 的確是一個合格的 Galgame 引擎。 它具備實現一個 Galgame 所需要的全部基本功能的能力。
並且，假如你依照它給的框架走，實現起來也非常精煉。
大量原版 NScripter 引擎的遊戲被移植也使得 ONScripter 大受歡迎，同時也煥發了那些老遊戲以及 NScripter 自身的第二生命。
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 自身的第二生命。
缺點
性能。性能問題一方面是 SDL 的問題，一方面是 ONScripter 自己編寫的問題。
SDL 的主要問題在於最初移植過去的時候一般是基於軟解的。當然該來的總是會來的，硬體加速還是會來的。
ONScripter 的代碼里的確有些寫的很“素”的地方。 平蕪泫的評價一語中的：“該說不愧是日本人的思維么？在指定環境下面能夠非常好地工作，不是這個環境就糟糕了。。。。”
順提，該貼里的 bug 是 Arch 里的 SDL_ttf 的問題，其實和 ONScripter 關係不大，現已修復。
我倒不覺得性能是極度重要的問題。當然它確實重要。
一方面，只要總的框架沒有大問題，先保證正確再最佳化也不為過，畢竟過早最佳化是萬惡之源，開源對這種問題也是一種好的解決方案。
另一方面，ONScripter 很大的瓶頸還是在 IO 和顯示上。 對於那些 label 用鍊表 lookup 之類的，倒也真不是什麼性能問題。
NScripter 的表達能力。
我想這部分才是我對 ONScripter 意見最大的部分——儘管這部分應該歸到 NScripter 的問題上。
平蕪泫的評價在這裡仍然適用： 如果你照著高橋佬的想法走，NScripter 是非常爽快的； 但如果不是這樣的話，你就會覺得 NScripter 處處捆人手腳。
不幸的是，移植的目的是模仿另一款遊戲重新實現它，想完全照著 NScripter 的思路走往往沒那么容易。
高橋是很清楚一款 Galgame 引擎需要什麼的，但是除此之外的事情他就懶得管了。NScripter 的語言設計明顯是混亂的。命令式的風格，一些計算上的東西又明顯是彙編的樣式，很多函式明顯是後頭擦屁股添上的，最終發現這事沒法弄了又開始支持 lua……總之，NScripter 自己從語言角度而言還是很不靈活的。 說實在的，很多事情不是不能實現，而是實現太麻煩。
.動畫效果實現繁瑣。
NScripter 的動畫基本要靠自己寫循環控制。不講究時間精確性可以用 for 循環，追求時間卡準可以 while(即 if-goto) 循環靠 timer 精確控制，當然可以抽象到自定義過程中，總歸還是麻煩的很。
更別提縮放和旋轉了。要是實現全螢幕雨點效果呢？那就不得不依賴外掛程式，而那是平台相關的，移植性很差。
順提，msp 的移動效率不咋樣。NScripter 語言的混亂之處還在於，它竟然有lsp、lsp2、drawsp、blt等不同體系的功能去做類似的事情。
並行動畫實現困難。
怎樣讓兩個移動共同實現？你不得不在一個循環中同時做兩個移動。 如果你已經把移動抽象到一個過程中了呢？ 如果是全螢幕震動的同時移動呢？ 如果是移動同時縮放呢？ 上面這些 Fate 里都不少，而且我希望抽象到一個過程中。我當時很頭疼。
對比 Kirikiri2 里解析腳本默認不阻塞動畫執行，這邊表達起來的確費勁的多。
但還好，上面起碼還算是好表達的。如果想表達類似穢翼序章窗外的雨滴落下，或者魔法使之夜裡人物對話時背景緩緩移動的效果呢？
NScripter 對話過程中同步畫面移動的方法只有利用多幀圖片動畫，這得做多少張？對魔夜這種大背景圖緩慢移動的，恐怕圖片都載入不進去。
畫面再加工能力匱乏。
很多引擎會對圖片加效果，比如通過色調和光線變化可以將一張圖重複利用在多個場景。
也有圖片直接翻轉和旋轉使用的。
NScripter 倒是支持黑白和反色。如果不需要考慮統一處理，也可以做旋轉。 除此之外就很有限了。當然總可以靠圖像處理軟體預先處理，然後替換檔案名稱(fate 移植時是這么做的)。只是，麻煩。
聲音部分的控制能力簡單。
一些其他引擎的遊戲，有時會將一段音樂分為兩段， 一段是 head 只播放一次，一段是 loop 只循環這部分。 有些引擎乾脆就把兩段合併為一個檔案，設定好 loop 的時間段即可。
對語音有時需要更精確的控制時間，比如語音結束的時候觸發 XX 效果。
NScripter 中很難實現這些部分。最大的難點還是在“如果當前正在對話，將無法控制其他部分”。
語言表達能力缺乏。
NScripter 從語言特性上和 php 有部分地方挺有共同之處的， 比如它們在自己的領域表現都不錯，但是語言設計的都挺不考量的。
NScripter 里真正有的是過程而非函式，注意它定義過程用的是 defsub. 比如說，對於類似$2 = str(int($1) + int($0)) 這種東西，你就不得不一堆 atoi/itoa 過去，還要產生一堆臨時變數，簡潔度大打折扣。NScripter 最缺乏的是臨時變數。 NScripter 里的所有變數都是全局相關的。 假如你需要實現很多過程的時候，你就不得不擔心變數分配問題了。這實際上是很噁心的。
NScripter 里沒有自定義結構。你需要自己設計地址分配，自己設計接口。
NScripter 缺乏一些反射功能(也許用這個詞不妥)，比如，某層載入的圖片檔案名稱是什麼？在什麼位置？是否真的載入了檔案(而不是載入但不顯示)？ 如果你需要，那就只好自己保存下來——用自定義的結構。
拿 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 計算是一件痛苦的事情。
動作環境
Onscripter能在一下平台運行：
Android (1.6 or later)
Zaurus (SL-C700, etc.)
Linux
MacOSX
Windows
Windows Mobile
Windows CE
WindowsPhone7
PSPiPhone, iPod touch
NetWalker
Brain (WindowsCE 6.0)
NetBSD, DragonFly BSD
OS2/Warp
Playstation3
WiiFreeBSD
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分支
（此義項待完善）
維護
Onscripter-jis
Ogapee
Onscripter-gbk
natdon及國內的Android-Galgame研究組
Onscripter-en
Uncle Mion等
相關參考書籍
NScripter官方手冊，由秀和システム2004年9月11日出版（第一版）。 ISBN編碼：ISBN 4-7980-0867-2 。該書已經絕版，具體請參考後面的修訂版。
Nscripter高級官方讀本，由秀和システム2005年7月9日出版（第一版）。 ISBN編碼：ISBN 4-7980-1104-5。
Nscripter官方手冊修訂版，由秀和システム2007年12月21日出版（第一版）。 ISBN編碼：ISBN 978-4-7980-1852-2。
Nscripter從零開始製作冒險（小說）遊戲，由新紀元社2006年9月1日出版（第一版）。 ISBN編碼：ISBN 4-7753-0496-8。
