| | |
|
投稿者：たくみ 2006/05/27(土) 08:30
Deathworks さんどうもです。
> 拡張子など変化出来るようになると助かります。「OPEN」と「CLOSE」はあって私にとって問題ではありませんけど、
> 「CLOSE」を忘れる人がいればどうなるのがちょっと気になります。私の考えでは、ローカルの変数と同じく、
> 自動的に「.yst」ファイルの終わりや「RETURN」命令で「CLOSE」になるのが一番安全だと思います。まぁ、今だけ出来た考えだけです。
そのあたりも考えないといけないですね。
今考えているのは、IF〜IFENDと同じで、OPEN 命令が記述されていたら CLOSE 命令も正しく一緒に記述されているか
コンパイラのほうで調べて、記述されていなければコンパイルエラーとする仕様です。
この仕様の場合、OPEN 命令が記述されたファイルと同じ場所に CLOSE 命令が書かれていなければならない、
という制限が発生しますが、逆にその制限があったほうが、安全なスクリプトが書けて良いかと思います。
> 「LOAD」の命令のマニュアルの説明で小さな間違いがありそうです。キーワードのチャートでDNOが0〜8192で大丈夫だと書いてありますけど、
> でも実際は1〜8192です。「SAVE」の説明で正しい様に書いてありますから、多分問題になりませんけど。
うわ…本当だ（Ｔ▽Ｔ
次のバージョンリリースの時に直しておきます。
ご報告ありがとうございます！
> そして、「SAVE」と「LOAD」の機能についてもう一つの質問と考えがあります：
> INT[@Source(3,3)]
> INT[@Target(7,7)]
> SAVE[FILE="kamawan" DNO=13 SET=@Source()]
> LOAD[FILE="kamawan" DNO=13 LET=@Target()]
> そうすれば、@Target()がどんな内容になりますか？それとも「LOAD」の失敗になります？
> そして、@Source()と@Target()の配列としての大きさが逆なら、平気ですか？
これは失敗になりますね。LOAD 命令を実行したときに、
「格納先の変数の配列の添字サイズが違います」というエラーメッセージが出ると思います。
> 実は、ちょっとRPGについて考えたら、「LOAD」と「SAVE」に「END1」「END2」「END3」。。。「END8」のキーワードがあればいいと思います。
> 配列なら、「ENDｎ」でn次の大きさを決定出来るように：
> INT[@Source(3,3)]
> INT[@Target(7,7)]
> SAVE[FILE="kamawan" DNO=13 SET=@Source()]
> LOAD[FILE="kamawan" DNO=13 LET=@Target() END1=3 END2=3]
> そうすれば、@Source()のデータが@Target(0,0)から@Target(2,2)へコピーされる。
> 「SAVE」に同じような機能があれば、配列の部分をセーブすることが出来ます。
なるほど…（＠＠
これはちょっと思い浮かびませんでした。
この仕様なら、新たに発生する問題は何もないはずなので、
ぜひ採用させていただく方向で検討したいと思います（＾＾
ただ、実装はしばらく後になってしまうかと思います。
先に実装しなくてはならない機能が溜まっているので、それが片付いてからになると思います。
> RPGのマップについて考えたら、こんなことが浮かびました。だって、プログラムの中のマップは大体
>
> MACRO[NAME="X_Max" STR="200"]
> MACRO[NAME="Y_Max" STR="200"]
>
> G_INT[@DW_Map(\[X_Max],\[Y_Max])]
>
> のようなマップの最大の大きさを持つような配列になります。
> でも、これより小さなマップの方が多いですから、35x20などのマップの場合のデータファイルの大きさが気になりました。
YU-RIS は INT 変数を 64bit で扱っているので1つの要素で 8Byte ですね。
なので、35*20 * 8Byte = 5600Byte、
200*200 のマップだと、 200*200 * 8Byte = 320000Byte(約300KB) になって、
ファイルにセーブした場合、だいたいそのまま 300KB のファイルが作成されると思います。極端に大きくはないですね。
ただ、マップデータだけで 300KB ですので、他のいろんなデータやパラメータを保存するとなると、
どんどんサイズは大きくなってしまいますね（＾＾；
そういう意味で、確かに部分セーブロード機能があると便利ですね。
> > > なるほど。const 定数ですね。
> > IF[@X > \MaxX] @X=\MaxX IFEND[]
> > こんな感じに使えますね（＾＾
> …
> うん。コードが分かり易くなります。そして何かの変化があれば、簡単に直します:例えば、配列を作るにも使えますから、
> 後で「この配列が小さ過ぎる！」などのことがあっても、一つの「MACRO」の変化ですむことです。
ですね。
保守性が高いスクリプトが書けますね。
> > > レイヤの部分コピー命令ですね。
> > まだ公開していませんが、もうほとんど機能は完成しています。
> > もうすぐ公開しようと思っています（＾＾）
> （T〜T)嬉しいです。
これはあと１週間くらいで出来ると思います（＾＾
> > 有り難うございますー（＾＾）
> > ただ、吉里吉里やＨＳＰでしか出来ない事もかなりたくさんありますから、
> > 私もまだまだ頑張らないといけません。
> > もっとたくさんの機能を追加したら、正式版(Ver1.0)を公開したいと思っています。
> …
> 今のバージョンでも色々な事が出来ると思います。ところで、一つだけが気になりました。「Eris」というのはノベルのシステムですね。
> なぜ、皆さんがノベルのシステムを作るかしら。他のシステムと比べたら、ノベルのシステムの方が圧的に多いです。
> 無敵の「Nscripter」からスクリーンのLayoutに上手な「ComicMaker」と初心者に対して優しいな「Yuuki!Novel」だけではありません、
> もう星の数ほどのシステムがあります。比べたら、インタネットからもらうの２DRPGシステム、例えば、は大体「Like A Quest Hyper」と
> 「J-RPG」と「ERPG」だけになります。（「Cardwirth」と「SRC」がちょっと違うRPGタイプですから、ここに出ません。）
> 勘違いしないで下さい。私もデジタルノベルが大好きです。ただ、この数の違いが不思議だと思います。一度聞きたいと思うことでしたから、
> ついに出てしまいましたけど、よろしければ考えを教えてくれませんか。
それにはいろいろな理由があると思います。
まずすぐに思い浮かぶのは、多くのプログラマーさんにとって、アドベンチャーやノベルのシステムの制作が、
他のジャンル（ＲＰＧやアクションゲームなど）に比べて、作りやすいからだと思います（＾＾
ノベルシステムって、ＣＧを画面に表示して、その上に文字を順番に表示していけば、極端に言えば、それで出来上がりなんですよね。
凄くシンプルなんです。（もちろん、高機能なシステムを作るとなるとまったく話が違ってきますけど）
だから、習作としてノベルシステムは選ばれやすいんだと思います。
あとは、はっきりとはわからないですけど、
パソコン上で、ＲＰＧをプレイする人とノベルをプレイする人の割合が違うのかな…と思います。
もちろんＲＰＧをプレイするユーザーもかなり多いと思いますが、
ノベルをプレイするユーザーのほうがさらに多いのだと思います。
だからきっと、それに比例して（？）、制作ツールも多いのではないかと思います。
これがＰＳ２などのハードになると、また違う割合なのでしょうね。
と、あと、薫さんがおっしゃってくれた、
> ノベルシステムだから、ノベルしか作れないとは限らないです。
> わたしは、今まで吉里吉里/kagでゲーム作っていますが。
> その吉里吉里/kagででも育成SLGや簡易なRPGもどきのものを作られてる方もいらっしゃいます。
> また、知り合いのNScripter使いの人の中にもやっぱり同じように育成SLGや簡易なRPGを作られてる方がいらっしゃいます。
> だから、要はツールを使うクリエイターの発想次第ではないでしょうか。
このあたりに関しては、Deathworks さんも実際にＲＰＧ制作にYU-RISを検討してくださっていますし、
十分理解されていらっしゃると思います（＾＾
ＲＰＧツールと比べてノベルツールを作る開発者のほうが多いのは単純に何故なんだろうという意味合いですし（＾＾
> 現状でもYU-RISは多機能で使いやすくなってます。
> Ellisは、ADVやビジュアルノベルを簡単に使いやすいというだけで、使いようによっては育成SLGもRPGも作ろうと思えば作れると思います。
有り難うございますｍ（＿ ＿）ｍ
もうちょっとで変数フラグ機能も正式に機能解放する予定ですので、
そうすれば出来るようになると思います（＾＾
ひとまずまた明日(28日)バージョンアップしたいと思います。
| |
| | |
|
