スクリプトコンパイラについて ( yac と lex も可 )

**439** · 01/11/07 15:31

みなさんのスクリプトって、どんな感じですか？
(エロ)ゲームプログラマーには一番難しい所かもしれません。
yac と lex も可です。

01/11/07 18:01

yacってなんだよ。。。。

19 · 01/11/07 18:08

追記。XML使うならパーサ(解析器)が必要。メジャーなパーサは以下の二つ。
*MSXML IE4以上なら一緒にインストールされていると思う。SDKはMSで入手のこと(.NETβがいいかも)
DOMとか新しい仕様を使いたければユーザにIE5以上のインストールをお願いすることになると思われる。
*XML4C Apacheから出ている。基本的にUNICODEしか使えないので、日本語コードが使いたければIBMが出している多国語対応版を利用のこと。
スタンドアロンで動くので、MSXMLのようなIEのインストール作業が必要ない。新らしXMLの規格への対応も迅速(DOM2やSchemaに対応済み)
ただし、DLLのファイルサイズがでかい。多国語対応版は文字コード変換DLLがいるため、さらにでかくなる。

XMLについて勉強する際は@IT等が良いと思われ。

18 · 01/11/07 18:46

BulletMLなんか見ると単純な処理ならいけそうに思えるよ
http://www.asahi-net.or.jp/~cs8k-cyu/bulletml/index.html

こんな感じなんだけど
<action>
<wait>20+$rand*50</wait>
<changeDirection>
<direction type="absolute">180</direction>
<term>10</term>
</changeDirection>
</action>

中間コード吐くようにすれば実行環境側にはパーサ必要ないし。

・・・でもあんまりメリットないかな。

**名無しさん＠お腹いっぱい。** · 01/11/09 01:11

>>21
ん？MSXML だけインストールさせれば？

XML 使う利点ねえ。
・自分でパーサ書かなくて済む
・生成も DOM 使えば簡単
・SOAP とかネットワーク分散とか
・DTD や XML Scheme といった標準規格で記述した仕様をそのまま使える

個人的には4番目が大きいな。
自分流で仕様書くと必ず曖昧で相手に伝わらない点が出てくるから。

**名無しさん＠お腹いっぱい。** · 01/11/09 01:48

せっかくなのでageましょう。

**名無しさん＠お腹いっぱい。** · 01/11/09 02:43

Microsoft XML Core Services 4.0 RTM
http://msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/001/766/msdncompositedoc.xml
MSXML 3.0 Parser Localized Versions
http://msdn.microsoft.com/downloads/sample.asp?url=/msdn-files/027/001/573/msdncompositedoc.xml&frame=true

**名無しさん＠お腹いっぱい。** · 01/11/09 10:08

>>23
・XMLエディタが使える。SchemeやDTD使って文法チェックや自動補完の支援も受けられる
・正確な文法を相手に伝えることができなくても、「こんなかんじ」でサンプル渡せばなんとなく書いてもらえる

**煽りじゃないけど** · 01/11/09 10:09

エロゲーのシナリオってホントにXMLなんて必要なの？
プログラマのオナニーじゃないの？

**名無しさん＠お腹いっぱい。** · 01/11/09 10:14

それは>>19でも指摘されてますな。
なにかこう、画期的なXMLエディタでも出てくれば事情が違ってくるんだろうけどねえ。

**名無しさん＠お腹いっぱい。** · 01/11/09 10:17

>>27
なんでエロゲーに限定やねん。
それはおいといて、キャラクタのデータベース作るときとか良いかもですよ?
たしかにCSV形式で必要十分っちゃそうなんだけど。

プログラマの自己満足?その通りですわ。本業にフィードバックできるしね。

**名無しさん＠お腹いっぱい。** · 01/11/09 10:27

ありがと。やっぱそうだよね。
変な関西弁だったけど(w

**名無しさん＠お腹いっぱい。** · 01/11/10 09:51

bison/flex派です。
プログラム板にも書きましたが、あがってないようなので…。

http://www.oishi.info.waseda.ac.jp/~oishi/interpreter/ma.html
を元に見よう見まねで電卓を作ってみました。++,+=,16進数等を追加。
↓ソースコード
http://page.freett.com/pluteus/works/bin/calc.lzh
まだif文などにバグありですが、これからゲームに組み込んで、
スクリプトエンジンにしたいと思います。

仕様は…
１デファイン機能
　電卓なので変数宣言不要
　関数は定義可能
２マクロ機能　なし
３計算式　a,b,c,d
４関数　b
５書式　e
６構造化　a,d,f,i,j
７セーブ機能　なし

switch～case文、break文、continue文、配列変数なども実装したいんですが、
どこかにbison用の構文解析ソースないですか？
簡易電卓機能までなら結構見つかるんですが、
スクリプトエンジンともなるとちょっと見つかりませんでした。
書籍を買えば分かるのかもしれませんが、
ソースを見たほうが速いので。

**名無しさん＠お腹いっぱい。** · 01/11/10 11:47

>>31
yaccので良ければgccのソースに含まれているよ
http://gcc.gnu.org/

っつーか探せば余裕ででてくるが？

31 · 01/11/10 12:23

>>32
>っつーか探せば余裕ででてくるが？
探すとこが良くなかったようですね、ありがとうございます。
(Googleで"bison flex ソース"とか)

gccくらい高度になると全部自力で構文解析してるのかと思ってました。
調べてみます。

**名無しさん＠お腹いっぱい。** · 01/11/12 07:02

みんなはゲーム用に使うスクリプトで、小数を定義してる？
やっぱり小数も扱えるようにしてあると便利なのだろうか・・・。
ちなみに、自分は bison 使って構文解析機作ってます。

**名無しさん＠お腹いっぱい。** · 01/11/12 10:01

>34
どうしても必要な場合、固定小数点でやってるよ。
小数点以下２バイト、実数２バイトで。

**名無しさん＠お腹いっぱい。** · 01/11/12 13:34

>>35
なんでそんな回りくどいことするの？
普通にbignum作ればそれでいいじゃん

**名無しさん＠お腹いっぱい。** · 01/11/12 21:08

>>36
どうしても必要な場合って言ってるだろ。
計算が速いから固定小数点使ってるんだよ。

**名無しさん＠お腹いっぱい。** · 01/11/12 23:48

固定小数点の計算が速かった時代も終わりつつあるってか終わってるな

**名無しさん＠お腹いっぱい。** · 01/11/13 00:03

うむ。最近のCPUは凄いのう。
ていうか、3Dゲームに使うスクリプトなら実数に対応せざるをえない。

**名無しさん＠お腹いっぱい。** · 01/11/13 16:43

486SXとかDXとか言ってた時代が懐かしい・・・

**名無しさん＠お腹いっぱい。** · 01/11/13 16:59

8086互換環境、しかもSmall Model用にゲーム向けスクリプト言語
環境作ってます。環境なんでエディタなんかも込みです。
最近のPCとは比べ物にならないくらい制限がキツイけど、これぐらい
キツイと逆に作り応えがあります。

**名無しさん＠お腹いっぱい。** · 01/11/13 22:53

マゾなの?テキストアドベンチャーでも作るの?

**名無しさん＠お腹いっぱい。** · 01/11/14 17:20

移転してきました。

**名無しさん＠お腹いっぱい。** · 01/11/14 17:49

>>37
どうしてもってなに？
bignumなんて一度作れば終わりじゃん。
もしかして、毎回スクラッチしてるの？

**名無しさん＠お腹いっぱい。** · 01/11/15 03:14

JAVAバイナリインタプリタの話題はやくしよー。
とりあえず、フリーのものさがしてみるよ。
コンシューマ機でものっけれるような素敵なのないかな。

**名無しさん＠お腹いっぱい。** · 01/11/15 03:30

この辺は使いえないですかね？
http://www.cc.yamaguchi-u.ac.jp/~shingo/WabaWorld/
携帯機用だから、コンシューマ機に載せ易いかも。

＿ · 01/11/15 04:23

1の言うスクリプトってよくわからない。
何の為に作るの？
あそこまで作るんだったら、Cをそのまんま使った方がいいと思うんだけど。
ちょっとした言語仕様を盛り込みたい為に、体系を一から構築するのって
どうなの？

**457** · 01/11/15 05:03

前スレの者ですが、
ざっと考えるだけでも

１）シナリオライターが逐次修正した物を
　　プログラマーがいちいち打ち込むのは大変。

　　プログラマーとシナリオライターが同じ場所に居るとは限らないし、
　　かといって、シナリオライターがソースを触ると危ないし、
　　シナリオライター全員の分の言語ライセンスを買うわけには行かない。
　
２）バージョンアップの時に、一部のシナリオファイルの改訂だけですむ

とか、色々あると思います。

**名無しさん＠お腹いっぱい。** · 01/11/15 12:39

>>46
WavaはどうやらGPLみたいですね。ﾄﾎﾎ(；´Д｀)
やっぱ仮想マシン自分で作れってことか。

**sage** · 01/11/15 13:11

>49
えっ！なになに！GPLだとまずいの！？
これゲームにのっけるとき、ソース公開せんといけなくなるの？

**名無しさん＠お腹いっぱい。** · 01/11/15 13:48

>>50
ご明察。
MS関係者が「GPLはソフトウェアに感染するウィルスみたいな物だ」と発言してオープンソース業界で問題になったことがあったが、
MSの気持ちは痛いほどよくわかるよ。
今の流行はGPLじゃないソースコード公開、勝手に使ってくれというライセンスやね。pngとかzlibとかPythonとかそうでしょ。

**名無しさん＠お腹いっぱい。** · 01/11/15 14:00

＞これゲームにのっけるとき、ソース公開せんといけなくなるの？
ニュアンスに違いかも知れないけど、誰かに要求されたらソースを公開する
必要がある、という意味だと思いますけど。
作ったからと言って、サイトに無償公開しろ、という意味ではないはず。

もちろん、利用したらGPLであることを記載しないといけないですけどね。

50 · 01/11/15 14:03

なるほどなるほど・・・
BladeOfDarknessっつー洋ゲーにPythonがつかわれてたのは
そういうことか。

スレ違いだけど、ゲームに剛体シミュいれたいなーとか、
シャドウボリュームつかいてーとか思ってる人は、
BladeOfDarknessみとくといいかも。
デモ版があるよ。

**名無しさん＠お腹いっぱい。** · 01/11/15 14:31

>>52
自分が配る時は無償でなくてもいいんだけど、
それを得た他人が無償でくばってもいいので
結局（ソフト自体は）無償で公開してるのと一緒。

**名無しさん＠お腹いっぱい。** · 01/11/15 15:38

え、GPLedな開発環境で作った成果物って別にGPLに縛られない
んじゃないかな。基本的に別物扱いで、実行環境等を入れるにしても
GPLに縛られるのはその実行環境のみのはず。
＃そうでなければgccなんて使ってられんぞ…。
ちょっと違うのはライブラリの場合で、これは大抵LGPLという緩い
ライセンスになっていて、そうなっていた場合は大抵ダイナミック
リンクする範囲では問題無くなってるはず。

間違ってたらスマソ。

**名無しさん＠お腹いっぱい。** · 01/11/15 15:52

>>55
>え、GPLedな開発環境で作った成果物って別にGPLに縛られない
>んじゃないかな。基本的に別物扱いで、実行環境等を入れるにしても
>GPLに縛られるのはその実行環境のみのはず。

GPLなライブラリやGPLなコードとリンクされる場合ね。縛られるのは。
LGPLでないかぎりはスタティックリンクでもダイナミックリンクでも
しばられる。

じゃあWindowsのDLLとGPLをまぜて使うときはどうなんだという
話はボーダーラインの話なのでGNUの見解を参照。

>＃そうでなければgccなんて使ってられんぞ…。

gccを非GPLなモノに使っていいのは特例です。

>ちょっと違うのはライブラリの場合で、これは大抵LGPLという緩い
>ライセンスになっていて、そうなっていた場合は大抵ダイナミック
>リンクする範囲では問題無くなってるはず。
こっちはあってる

GPLの話題は別のところでしましょうかね

**名無しさん＠お腹いっぱい。** · 01/11/15 17:33

誰か、GPL/LGPL等ライセンスとゲーム製作ってスレ作ってくれないかな。
携帯だからスレ作れないの。

**名無しさん＠お腹いっぱい。** · 01/11/15 18:57

作りました。

GPL/LGPL等ライセンスとゲーム製作
http://game.2ch.net/test/read.cgi/gamedev/1005818191/

**名無しさん＠お腹いっぱい。** · 01/11/15 21:40

本題ですけど、Javaの環境流用でなくても、
既存のスクリプトエンジン探せばいろいろ落ちてるんじゃないでしょうか。
未評価ですが、この辺とか。
http://home.elka.pw.edu.pl/~ppodsiad/seer/
http://www.compuphase.com/small.htm

もし自作するなら、あまり気合い入れて作りこまないほうがいいかもねー。
BASICとかバッチファイル並みで十分だと思う。
プログラマ以外にはろくに機能を使いこなせないスクリプトとか、
普通にコンパイラ使えばいいのにってスクリプトになるのもアレだし。

**名無しさん＠お腹いっぱい。** · 01/11/15 23:50

でも、既存の練られた言語ってやっぱりいいと思わない？
つかってるうちにその言語習得できちゃったりして。

**名無しさん＠お腹いっぱい。** · 01/11/16 00:22

seer, smallと来たところで、Luaもはずせませんな。
http://www.tecgraf.puc-rio.br/lua/

**名無しさん＠お腹いっぱい。** · 01/11/16 00:34

JavaのVMってアプローチがあるなら、CLIのVMってのもありではないのかな。
対応言語が増えすぎてしまうが(w

**名無しさん＠お腹いっぱい。** · 01/11/16 00:54

スクリプトコンパイラは（言語仕様が）あまり高性能すぎるのもどうかと思う。
あまり言語仕様が高性能すぎても、今度はスクリプトコンパイラ上で動くスクリプト自体の
デバッグに追われることになってしまう。

**名無しさん＠お腹いっぱい。** · 01/11/16 01:43

>>63
あまりに言語仕様が高性能すぎる

と、

スクリプトコンパイラ上で動くスクリプト自体の
デバッグに追われることになってしまう

ということになるってどういうことだろ・・・

言語仕様が単純でも高機能でもデバッグに追われるよ

**名無しさん＠お腹いっぱい。** · 01/11/16 04:20

今話してるスクリプトは、プログラマ以外が使うことを想定してるから
凝って自由度を上げすぎると、シナリオ担当者等が扱えきれなくて本末転倒
と言いたいのだと思われ。

**名無しさん＠お腹いっぱい。** · 01/11/16 06:25

すんませんスクリプトの手軽さはわかっとりますが、
JAVAを組み込むのにモえてもたよ。
http://www.netgene.co.jp/java/docs/javaPressVol14.html
ここを参照でまーなんとかできそうだ。

this->*(_opcodes[*_pc]))();
こんなことをやってオペコード実行しとりますが、
このやり方にマンセーなかたがいらっしゃいましたら、
てきとうなとこでウプしますけど。
はは・・・たたかれそうだな・・・。

**名無しさん＠お腹いっぱい。** · 01/11/16 07:06

JavaVM用の言語って現時点で一杯あるんやね。Javaにこだわる必要は無いな。
http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html

**名無しさん＠お腹いっぱい。** · 01/11/16 09:07

JavaVMかぁ。ちょっと面白そうだけど、今から勉強するならCLRかな～って気もする。
ただ、MSから仕様書拾ってきたらページ数ありすぎで読む気しない。
英語馬鹿でも読める、もちっと纏められた資料ってないんかの～。

**名無しさん＠お腹いっぱい。** · 01/11/16 11:32

良スレage

66 · 01/11/16 12:03

>>68
CLRかぁ！うーん・・・どうしよっかな・・・。
でも　>>67　のみて十分JavaVMでもいろんな言語いけるおもたよ。
日本語資料よくできてるし。
べつにバイナリコードでプログラムするわけないしね。

**名無しさん＠お腹いっぱい。** · 01/11/16 12:08

いっそのこと
Javaベースにしてメイン部分をJNIに逃がす、
ということはできないのだろうか。

**名無しさん＠お腹いっぱい。** · 01/11/16 14:33

GNUの連中がC#->JVMコンパイラ作ってるよ

**名無しさん＠お腹いっぱい。** · 01/11/16 16:54

>72
まぢ！Java言語じたいより、VMのほうが長生きする予感

**名無しさん＠お腹いっぱい。** · 01/11/16 23:36

>>66
せっかくだからアプしようぜ。

>>68
俺もダウンロードしてきたけど、読み応えありすぎるわ(w

**名無しさん＠お腹いっぱい。** · 01/11/17 00:39

>>71
できるだろうけど、ほとんど意味ないんじゃない？
プログラマ以外の人が簡単にゲームのフレームや流れを作れるようにするために
スクリプト作るってのが元の目的でしょ？

まあ面白いけど(w

**名無しさん＠お腹いっぱい。** · 01/11/17 01:35

.NETに対抗して.GNUとかやらんのかね

**名無しさん＠お腹いっぱい。** · 01/11/17 01:42

>>76
うーん、GPLなんかだと激しく萎えるなあ

**名無しさん＠お腹いっぱい。** · 01/11/17 01:59

http://www.gnu.org/projects/dotgnu/

**名無しさん＠お腹いっぱい。** · 01/11/17 02:07

>>78
ハハハ、なんつーかそこまでムキになるなやって感じやな。

**名無しさん＠お腹いっぱい。** · 01/11/19 00:29

age

**名前は開発中のものです。** · 01/11/24 21:29

>>76
あれ？やってなかったっけ？ほのかに記憶あるんだけど。

**名前は開発中のものです。** · 01/11/24 21:33

お気に入りのIDが出たYO!!

**名前は開発中のものです。** · 01/11/27 09:53

>>72
みつかんないよーどこにあるの！？

**名前は開発中のものです。** · 01/11/27 10:01

まだ作ってる途中ってことじゃないの？

**名前は開発中のものです。** · 01/11/27 11:15

>>81
>>78のリンクみろ

>>83
http://www.gnu.org/projects/dotgnu/projects.html 「* Support for Java bytecode」
http://www.southern-storm.com.au/portable_net.html
まだ実装されてません

85 · 01/11/27 11:37

嘘です
実装されてます

83 · 01/11/27 19:42

>>85 サンクス！Cygwinでコンパイルためしてみるよ～
良スレ（俺的に）アゲ

83 · 01/11/27 21:35

CYGWIN用C#コンパイラできました。結果報告。
・普通にC#コンパイラとして使えました。（EXE出力）
・JavaVMアセンブリソースのはきだし方。
%cscc -mjvm -S source.cs
この出力結果から、.classができるかどうかは、まだわかりません。

83 · 01/11/27 23:11

GNU C#コンパイラのJavaVM出力に関する結果報告

>>88　の方法で吐き出した　source.jl (JVM-ASMをIL形式で出力したもの）
をilasmにくわしてみた。
%ilasm -mjvm source.jl
（-mjvmオプションはソースをIL形式のJVMバイトコードで出力）
出力結果.objをみてみたけれども、.classにはほど遠い。

.jlをjasmin(JavaASM)のフォーマットに変換するのが
C#->.classへの近道っぽい。（わりとよく似てる）

厨房 · 01/11/28 00:36

JavaVMはスタックマシンだけどCLIはレジスタで結構違うって噂聞いたことあるけど…

**名前は開発中のものです。** · 01/11/28 00:56

>>90
CLIもスタックマシンらしいけど？
ここにC#コンパイラがどうしてJVMコードをはけるのかとか
なぜgccと統合しなかったのかとかが書いてある
http://www.southern-storm.com.au/pnet_faq.html

**名前は開発中のものです。** · 01/11/29 14:19

ありがとう。2.4節あたりに書いてあったね。
JavaVMと似てるならCLI真面目に勉強したいな。洋書読める程英語できないし、早く翻訳されないかな。

**名前は開発中のものです。** · 02/01/03 07:02

簡単なスクリプトのコンパイラって無い物でしょうか？
BASICのIFが使える程度で良いのですが、
色々調べても難しい物ばかりでなかなか良い物を探せません。
何か良い物があったら教えてください。

**名前は開発中のものです。** · 02/01/03 08:47

↑富士通から出ているF-BASIC for Win95 がお薦め。
グラフィックだとかも使えるしね。

**名前は開発中のものです。** · 02/01/03 09:31

>>94
おいおい。

>>93
コンパイラじゃないけどこの辺を
http://member.nifty.ne.jp/nakamula/recurs.htm

**名前は開発中のものです。** · 02/01/03 10:20

>>94
F-BASICは産業分野で大活躍しとる。
N-88Basicで書かれた昔の計測システムとかを動かすのにな

板違いsage

94 · 02/01/03 11:51

しまった。コンパイラ・コンパイラの板だったのか。素で間違えた。
スマソ。

**名前は開発中のものです。** · 02/01/03 17:17

>>94
ttp://member.nifty.ne.jp/KENJI/
ここがおすすめ

**名前は開発中のものです。** · 02/01/03 23:20

>>94
スクリプトコンパイラで検索すれば色々でてくるよ。

**名前は開発中のものです。** · 02/01/04 03:58

専学の卒業用のプログラムでスクリプトコンバータが必要ですが、
色々調べても難しい物ばかりなので、自分で拡張できそうにないです。
何か拡張を前提とした良い物って無いでしょうか。
ソースがわかりやすいものが良いです。

**名前は開発中のものです。** · 02/01/04 11:02

>>100
前述のリンクたどって1からスクリプト組んでみるといいと思う。
できたころには、他のスクリプトも拡張できるようになってる。

俺の場合だけど

**100** · 02/01/04 18:15

>>101
サンキューです。
単純なスクリプトコンパイラを作るのソースを参考にしてみます。
これなら簡単に理解できそうです。
専学で作ってるゲームシステムをどこかにアップしてみんなに見てもらうことって
出来るんでしょうか。
いえね、なにか自分のがプロの方にはどう見られるかと思ってね

**名前は開発中のものです。** · 02/01/05 19:27

ふつーにwebにゲームのソース公開しててもなかなかリアクションはこないみたい。
2chにさらすのが手っ取り早い。

**100** · 02/01/06 09:03

>>103
つまらない物だけど、もし出来上がったらさらします。
単なるアドベンチャーゲームのエンジンなんですが、
ちゃんと出来ているかというより、
今後何年間かでプロになれるかが心配なのでみんなに見てほしいです。

**名前は開発中のものです。** · 02/01/09 07:08

>104
100のADVシステムきぼん

**100** · 02/01/14 09:10

アドベンチャーゲームのエンジンをあぷしておきました。
ttp://www4.famille.ne.jp/~yo-ogawa/cgi-bin/bbs/upload.cgi
批評お願いします。
新しく板、作ったほうがいいでしょうか

**100** · 02/01/14 09:20

さっきの奴は半角版から行かないとだめなので、こちらにアップしておきます。
http://www.nyan-web.ne.jp/~mystyle-jp/cgi-bin/upboard/imgboard.cgi
サンプルも入れておきますので、批評お願いします。

**名前は開発中のものです。** · 02/01/14 09:31

まあまあじゃないの？最初としてはさあ。

**名前は開発中のものです。** · 02/01/14 20:57

やねうらをＳＤＫは、使ってみた感じ、言われてるより遥かに使いやすいと
思ったのだが。Ｃ言語っぽいし、WindowsAPIも呼び出せるし。

**名前は開発中のものです。** · 02/01/14 21:21

yaneSDKは大きく分かれるね
優秀なサンプルプログラム、ライブラリとしては後一歩のところがとどかない。

とかいて気付いたが、yaneSDKはそのままC言語だろ。（ｗ
正確にはC++だけど。

**名前は開発中のものです。** · 02/01/14 21:29

>>100
108 ではないけど、最初に形にした物としてはよいのでは。
自分が初めて形にした物よりはだいぶマシ（苦笑）

ただ、400 行以上にもなる関数があるのは頂けないので、
そのへんは注意せんとね。

**名前は開発中のものです。** · 02/01/14 22:01

>>110
スクリプト言語のほう言ってるんじゃない？
ここのスレで言っているからして。
しかしそれにしても、いまどきフリーのC/C++コンパイラもあるのに
わざわざC言語に劣るスクリプト言語を使うメリットはそんなに大きくないだろう。

**名前は開発中のものです。** · 02/01/14 22:06

スクリプトにすればわざわざコンパイルしなくていいじゃん。

**名前は開発中のものです。** · 02/01/14 22:14

>>113
一発でmake後実行できるように環境を整えておけば似たようなもんだよ。

スクリプト言語って記述しやすければ開発が楽になるが、腐った仕様の
スクリプト言語をつくっちまうと逆に足手まといになるね。

**名前は開発中のものです。** · 02/01/14 23:48

>>114
シナリオライタとプログラマが同一人物とは限らないし、
シナリオライタが複数いることもある。
プログラマ以外の人がシナリオを触ると、問題が出てくることが多い。

動作チェックするときにも再コンパイルをして、
コンパイラの最適化によるバグも防げる。
もちろん、スクリプトコンパイラは十分バグ出ししていることが必要だけど。

スクリプトコンパイラでちゃんとスクリプトのバグを出してくれるのであれば、
バグも出にくくなる。
表示される文字セットの問題(改行コードや主人公の名前など)も
解決しやすくなる。

シナリオの既読と未読などもスクリプトコンパイラの方が管理しやすい。
(Ｃのマクロでもできるけど)
スクリプト言語にＣ言語の記号を持ち込まなくて良い。
だいたいのシナリオライタはＣ言語の記号を説明すると、記号が多くいやがる。
ＢＡＳＩＣ風(ＰＡＳＣＡＬ風)な方が喜ばれることが多い。

弱点は動作スピードが若干遅くなること。

**名前は開発中のものです。** · 02/01/15 02:39

やねうらおＳＤＫは、デキは悪くないけど、
難易度がＣ言語やＣ＋＋のそれと変わらない気がする。汎用性ありすぎ。
つまり、あれを使いこなせるくらいなら素直にＶＣ＋＋弄った方が
いいかも。

**名前は開発中のものです。** · 02/01/15 06:34

ＳＤＫとスクリプトをごっちゃにしないでくれ。どっちがどっちがわからん

**名前は開発中のものです。** · 02/01/15 11:17

>>116
客観的にみたとしてもC/C++よりかなり使いにくいですが・・・

**100** · 02/01/15 15:07

新しいバージョンをあぷしました。
前回と違うところはシューティングシーンを付加しました。
No.558です。
http://www.nyan-web.ne.jp/~mystyle-jp/cgi-bin/upboard/imgboard.cgi

>>108&111
ありがとうございました。
専門学校卒業というだけで白い目で見られていたので、これで自信がもてました。