[もどる]
一括表示
0462 はじめまして、そしてYU-RISの機能について(特にSAVE)
投稿者:Deathworks 2006/05/25(木) 02:02

今日は、そしてはじめまして、Deathworksと申します。よろしくお願いします。

ちょっと最近YU-RISを使ってみましたけど、結構いいものだと思います(根性がありませんから、多分大した結果が出ませんけど、一度テストします)。

特に「SAVE」と「LOAD」の機能が強いらしいです。うまく使えば、RPGのマップなどのデータを「LOAD」で簡単にロード出来ると思います。ただ、一つの微妙なことが「SAVE」と「LOAD」の硬い決定です:「SAVE」を使えば、絶対に「.sd」を付ける事(によって、「Test01.dat.sd」というファイルが出てしまいました)。そして、ダイレクトリーが絶対に「save」になって、「/」などでパスを変更出来ない事もちょっと気を触りました。だって、ゲームのデータを「save」という所を置くのはちょっと変な気がします。

YU-RISを最初に使おうとした時は、「G_INT」のようなグローバルの変数の命令が問題になりました。マニュアルで「global.yst」だけでの命令などが載っていませんでしたから。ちょっとプログラミングの基本を知る初心者の為にマニュアルでの一言がいいと思います。

あっ!皆さんも気づいたかも知りませんけど、一応言いたいと思います:「MACRO」は「const」などの偽変数の変わりよく使えます:MACRO[NAME="MaxX" STR="199"]のように使えば、番号の「MACRO」も使えます。

CGについての機能はまだよく調べていません。でも、あるレイヤからの部分を他のレイヤの部分へコピーする命令がないような気がします。そして、テキストの(X,Y)を変化することも出来ない様な気がします。

そして、マニュアルを読む時、ちょっと気になったことがあります:レイヤセットを使えば、レイヤセットの中のレイヤを番号(NO)で使えますか。だって、番号を使えるとプログラミングが楽になりますから、出来れば番号で行きたいと思いますけど、セットはちょっとIDの文例に影響がありそうですから、不安になりました。セットは面白そう機能ですから、後でちょっと実験したいと思いますけど、NOで使えませんと使い道でちょっと困るかも知りません。

まぁ、私の分からないものやほしいものを気にしないで下さい。よく迷い人だけです。YU-RISは確かに「吉里○里」よりいい「SAVE」機能があって(エンジンの大きさと一緒にデータの扱いが「○里吉里」の一番大きな弱点だと思います)、そして「HS○」より気持ちいいと思います(○SPがあまり好きではありません)。βバージョンと言っても立派なものだと思います。

下手な日本語でごめんなさい。ちょっと変わったドイツ人だけですから、大目で見て下さい。

Deathworks

0463 はじめまして(^^)
投稿者:たくみ 2006/05/25(木) 22:07

Deathworksさん
はじめまして、たくみと申します(^^)
おぉっ、外人さんからの書き込みだ!凄い!

> ちょっと最近YU-RISを使ってみましたけど、結構いいものだと思います(根性がありませんから、多分大した結果が出ませんけど、一度テストします)。

ありがとうございます。おぉ、グローバルに認められた…嬉しい m(T▽T)m

> 特に「SAVE」と「LOAD」の機能が強いらしいです。うまく使えば、RPGのマップなどのデータを「LOAD」で簡単にロード出来ると思います。
> ただ、一つの微妙なことが「SAVE」と「LOAD」の硬い決定です:「SAVE」を使えば、絶対に「.sd」を付ける事(によって、「Test01.dat.sd」
> というファイルが出てしまいました)。そして、ダイレクトリーが絶対に「save」になって、「/」などでパスを変更出来ない事もちょっと
> 気を触りました。だって、ゲームのデータを「save」という所を置くのはちょっと変な気がします。

確かにそうですね。
どんなゲームでも作る事ができるツールを目指すなら、確かにその問題を解決しないといけないですね。
それでは、近いうちに「フォルダ(save/)」と「拡張子(.sd)」を変更できるように、あとパスの指定もできるようにします。

あと、実は SAVE, LOAD 命令の仕様を少し変更しようと思っています。
OPEN, CLOSE 命令を追加したいと思っていまして、
SAVE, LOAD 命令の前と後ろに OPEN, CLOSE 命令をそれぞれ書かないといけないようになります。
↓サンプルとして下のような感じです。

OPEN[FILE="userdata.dat"]
SAVE[DNO=1 SET=@A()]
SAVE[DNO=2 SET=$B()]
SAVE[DNO=3 ID=LAYER]
CLOSE[]

いままでより少し面倒になりますが、けれど、セーブの速度がUPするというメリットがあります。
特にCGをセーブする場合に顕著(けんちょ)になります。
あと、SAVE 命令にいちいちセーブファイル名を指定しなくても、OPEN 命令の中に1回だけ書けば済むようになります。


> YU-RISを最初に使おうとした時は、「G_INT」のようなグローバルの変数の命令が問題になりました。マニュアルで「global.yst」だけでの
> 命令などが載っていませんでしたから。ちょっとプログラミングの基本を知る初心者の為にマニュアルでの一言がいいと思います。

なるほど、確かに。マニュアルの「概要」の「変数」の項目には一応書いてあるんですが、そういえば G_INT, G_FLT, G_STR の項目には
「global.yst ファイル内じゃないと記述できない」ということは書いていませんでした。
次のバージョンで書いておきますね。


> あっ!皆さんも気づいたかも知りませんけど、一応言いたいと思います:「MACRO」は「const」などの偽変数の変わりよく使えます:MACRO[NAME="MaxX" STR="199"]のように使えば、番号の「MACRO」も使えます。

なるほど。const 定数ですね。
IF[@X > \MaxX] @X=\MaxX IFEND[]
こんな感じに使えますね(^^


> CGについての機能はまだよく調べていません。でも、あるレイヤからの部分を他のレイヤの部分へコピーする命令がないような気がします。
> そして、テキストの(X,Y)を変化することも出来ない様な気がします。

レイヤの部分コピー命令ですね。
まだ公開していませんが、もうほとんど機能は完成しています。
もうすぐ公開しようと思っています(^^)


> そして、マニュアルを読む時、ちょっと気になったことがあります:レイヤセットを使えば、レイヤセットの中のレイヤを番号(NO)で使えますか。
> だって、番号を使えるとプログラミングが楽になりますから、出来れば番号で行きたいと思いますけど、セットはちょっとIDの文例に影響が
> ありそうですから、不安になりました。セットは面白そう機能ですから、後でちょっと実験したいと思いますけど、NOで使えませんと使い道で
> ちょっと困るかも知りません。

レイヤセット自体には「ID」しか使えないですが、
レイヤセットの中のレイヤなら、「ID」「NO」両方使えます。

たとえば、

CG[ID=A/ SX=400 SY=300 Z=1] //400x300のレイヤセット「LSET」を作成

CG[ID=A/AA NO=1 Z=10 FILE="〜〜"] //レイヤ「AA」を作成
CG[ID=A/BB NO=2 Z=30 FILE="〜〜"] //レイヤ「BB」を作成
CG[ID=A/CC/ Z=20 SX=200 SY=200] //レイヤセット「CC」を作成

CG[ID=A/CC/AAA NO=1 Z=8 FILE="〜〜"] //レイヤ「AAA」を作成
CG[ID=A/CC/BBB NO=2 Z=7 FILE="〜〜"] //レイヤ「BBB」を作成
CG[ID=A/CC/CCC/ Z=1 SX=600 SY=500] //レイヤセット「CCC」を作成

上のように、レイヤセットの中のレイヤにもNOが使えます。


> まぁ、私の分からないものやほしいものを気にしないで下さい。よく迷い人だけです。YU-RISは確かに「吉里○里」よりいい「SAVE」機能があって
> (エンジンの大きさと一緒にデータの扱いが「○里吉里」の一番大きな弱点だと思います)、そして「HS○」より気持ちいいと思います(○SPが
> あまり好きではありません)。βバージョンと言っても立派なものだと思います。

有り難うございますー(^^)
ただ、吉里吉里やHSPでしか出来ない事もかなりたくさんありますから、
私もまだまだ頑張らないといけません。
もっとたくさんの機能を追加したら、正式版(Ver1.0)を公開したいと思っています。


> 下手な日本語でごめんなさい。ちょっと変わったドイツ人だけですから、大目で見て下さい。

いえいえ、かなりお上手でわかりやすく、びっくりしました(^^

スクリプトとはいえ、外人さんとプログラムの話が出来て凄く嬉しいです。
deathworksさん、またいつでも書き込んでくださいね(^^

0464 また「SAVE」と「LOAD」について
投稿者:Deathworks 2006/05/26(金) 23:21

今日は、Deathworksです。

> おぉっ、外人さんからの書き込みだ!凄い!

> > ありがとうございます。おぉ、グローバルに認められた…嬉しい m(T▽T)m

私がそんなに偉くないと思いますけど(汗)。

> それでは、近いうちに「フォルダ(save/)」と「拡張子(.sd)」を変更できるように、あとパスの指定もできるようにします。
> > あと、実は SAVE, LOAD 命令の仕様を少し変更しようと思っています。
> OPEN, CLOSE 命令を追加したいと思っていまして、
> SAVE, LOAD 命令の前と後ろに OPEN, CLOSE 命令をそれぞれ書かないといけないようになります。
> ↓サンプルとして下のような感じです。
> > OPEN[FILE="userdata.dat"]
> SAVE[DNO=1 SET=@A()]
> SAVE[DNO=2 SET=$B()]
> SAVE[DNO=3 ID=LAYER]
> CLOSE[]
> > いままでより少し面倒になりますが、けれど、セーブの速度がUPするというメリットがあります。

拡張子など変化出来るようになると助かります。「OPEN」と「CLOSE」はあって私にとって問題ではありませんけど、「CLOSE」を忘れる人がいればどうなるのがちょっと気になります。私の考えでは、ローカルの変数と同じく、自動的に「.yst」ファイルの終わりや「RETURN」命令で「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()の配列としての大きさが逆なら、平気ですか?

実は、ちょっとRPGについて考えたら、「LOAD」と「SAVE」に「END1」「END2」「END3」。。。「END8」のキーワードがあればいいと思います。配列なら、「ENDn」で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などのマップの場合のデータファイルの大きさが気になりました。

> > なるほど。const 定数ですね。
> IF[@X > \MaxX] @X=\MaxX IFEND[]
> こんな感じに使えますね(^^

うん。コードが分かり易くなります。そして何かの変化があれば、簡単に直します:例えば、配列を作るにも使えますから、後で「この配列が小さ過ぎる!」などのことがあっても、一つの「MACRO」の変化ですむことです。

> > レイヤの部分コピー命令ですね。
> まだ公開していませんが、もうほとんど機能は完成しています。
> もうすぐ公開しようと思っています(^^)
(T〜T)嬉しいです。

> > レイヤセット自体には「ID」しか使えないですが、
> レイヤセットの中のレイヤなら、「ID」「NO」両方使えます。
> > たとえば、
> > CG[ID=A/ SX=400 SY=300 Z=1] //400x300のレイヤセット「LSET」を作成
> > CG[ID=A/AA NO=1 Z=10 FILE="〜〜"] //レイヤ「AA」を作成
> CG[ID=A/BB NO=2 Z=30 FILE="〜〜"] //レイヤ「BB」を作成
> CG[ID=A/CC/ Z=20 SX=200 SY=200] //レイヤセット「CC」を作成
> > CG[ID=A/CC/AAA NO=1 Z=8 FILE="〜〜"] //レイヤ「AAA」を作成
> CG[ID=A/CC/BBB NO=2 Z=7 FILE="〜〜"] //レイヤ「BBB」を作成
> CG[ID=A/CC/CCC/ Z=1 SX=600 SY=500] //レイヤセット「CCC」を作成
> > 上のように、レイヤセットの中のレイヤにもNOが使えます。

なるほど、そうなら楽に使えると思います。

> 有り難うございますー(^^)
> ただ、吉里吉里やHSPでしか出来ない事もかなりたくさんありますから、
> 私もまだまだ頑張らないといけません。
> もっとたくさんの機能を追加したら、正式版(Ver1.0)を公開したいと思っています。

今のバージョンでも色々な事が出来ると思います。ところで、一つだけが気になりました。「Eris」というのはノベルのシステムですね。なぜ、皆さんがノベルのシステムを作るかしら。他のシステムと比べたら、ノベルのシステムの方が圧的に多いです。無敵の「Nscripter」からスクリーンのLayoutに上手な「ComicMaker」と初心者に対して優しいな「Yuuki!Novel」だけではありません、もう星の数ほどのシステムがあります。比べたら、インタネットからもらうの2DRPGシステム、例えば、は大体「Like A Quest Hyper」と「J-RPG」と「ERPG」だけになります。(「Cardwirth」と「SRC」がちょっと違うRPGタイプですから、ここに出ません。)勘違いしないで下さい。私もデジタルノベルが大好きです。ただ、この数の違いが不思議だと思います。一度聞きたいと思うことでしたから、ついに出てしまいましたけど、よろしければ考えを教えてくれませんか。

それでは、

Deathworks

0465 ゲーム製作について
投稿者: 2006/05/27(土) 01:50

はじめまして、Deathworks様
横からすいません。
ゲーム製作している人間からの意見なのですが。
ノベルシステムだから、ノベルしか作れないとは限らないです。
わたしは、今まで吉里吉里/kagでゲーム作っていますが。
その吉里吉里/kagででも育成SLGや簡易なRPGもどきのものを作られてる方もいらっしゃいます。
また、知り合いのNScripter使いの人の中にもやっぱり同じように育成SLGや簡易なRPGを作られてる方がいらっしゃいます。
だから、要はツールを使うクリエイターの発想次第ではないでしょうか。

現状でもYU-RISは多機能で使いやすくなってます。
Ellisは、ADVやビジュアルノベルを簡単に使いやすいというだけで、使いようによっては育成SLGもRPGも作ろうと思えば作れると思います。
ですから、YU-RISをマスターしてすばらしいゲームをお互い作っていければいいですね。

では、突然の乱入失礼しまた。

0466 どうもです
投稿者:たくみ 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」の説明で正しい様に書いてありますから、多分問題になりませんけど。

うわ…本当だ(T▽T
次のバージョンリリースの時に直しておきます。
ご報告ありがとうございます!


> そして、「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」のキーワードがあればいいと思います。
> 配列なら、「ENDn」で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)嬉しいです。

これはあと1週間くらいで出来ると思います(^^


> > 有り難うございますー(^^)
> > ただ、吉里吉里やHSPでしか出来ない事もかなりたくさんありますから、
> > 私もまだまだ頑張らないといけません。
> > もっとたくさんの機能を追加したら、正式版(Ver1.0)を公開したいと思っています。
> …
> 今のバージョンでも色々な事が出来ると思います。ところで、一つだけが気になりました。「Eris」というのはノベルのシステムですね。
> なぜ、皆さんがノベルのシステムを作るかしら。他のシステムと比べたら、ノベルのシステムの方が圧的に多いです。
> 無敵の「Nscripter」からスクリーンのLayoutに上手な「ComicMaker」と初心者に対して優しいな「Yuuki!Novel」だけではありません、
> もう星の数ほどのシステムがあります。比べたら、インタネットからもらうの2DRPGシステム、例えば、は大体「Like A Quest Hyper」と
> 「J-RPG」と「ERPG」だけになります。(「Cardwirth」と「SRC」がちょっと違うRPGタイプですから、ここに出ません。)
> 勘違いしないで下さい。私もデジタルノベルが大好きです。ただ、この数の違いが不思議だと思います。一度聞きたいと思うことでしたから、
> ついに出てしまいましたけど、よろしければ考えを教えてくれませんか。

それにはいろいろな理由があると思います。

まずすぐに思い浮かぶのは、多くのプログラマーさんにとって、アドベンチャーやノベルのシステムの制作が、
他のジャンル(RPGやアクションゲームなど)に比べて、作りやすいからだと思います(^^
ノベルシステムって、CGを画面に表示して、その上に文字を順番に表示していけば、極端に言えば、それで出来上がりなんですよね。
凄くシンプルなんです。(もちろん、高機能なシステムを作るとなるとまったく話が違ってきますけど)
だから、習作としてノベルシステムは選ばれやすいんだと思います。

あとは、はっきりとはわからないですけど、
パソコン上で、RPGをプレイする人とノベルをプレイする人の割合が違うのかな…と思います。
もちろんRPGをプレイするユーザーもかなり多いと思いますが、
ノベルをプレイするユーザーのほうがさらに多いのだと思います。
だからきっと、それに比例して(?)、制作ツールも多いのではないかと思います。
これがPS2などのハードになると、また違う割合なのでしょうね。


と、あと、薫さんがおっしゃってくれた、

> ノベルシステムだから、ノベルしか作れないとは限らないです。
> わたしは、今まで吉里吉里/kagでゲーム作っていますが。
> その吉里吉里/kagででも育成SLGや簡易なRPGもどきのものを作られてる方もいらっしゃいます。
> また、知り合いのNScripter使いの人の中にもやっぱり同じように育成SLGや簡易なRPGを作られてる方がいらっしゃいます。
> だから、要はツールを使うクリエイターの発想次第ではないでしょうか。

このあたりに関しては、Deathworks さんも実際にRPG制作にYU-RISを検討してくださっていますし、
十分理解されていらっしゃると思います(^^
RPGツールと比べてノベルツールを作る開発者のほうが多いのは単純に何故なんだろうという意味合いですし(^^


> 現状でもYU-RISは多機能で使いやすくなってます。
> Ellisは、ADVやビジュアルノベルを簡単に使いやすいというだけで、使いようによっては育成SLGもRPGも作ろうと思えば作れると思います。

有り難うございますm(_ _)m
もうちょっとで変数フラグ機能も正式に機能解放する予定ですので、
そうすれば出来るようになると思います(^^

ひとまずまた明日(28日)バージョンアップしたいと思います。

0469 どうもです
投稿者:Deathworks 2006/05/27(土) 19:50

今日は、Deathworksです。

> という制限が発生しますが、逆にその制限があったほうが、安全なスクリプトが書けて良いかと思います。

確かにその方が安全ですね。

> これはちょっと思い浮かびませんでした。
> この仕様なら、新たに発生する問題は何もないはずなので、

私もそうなると思いましたから、一応言い出そうと思いました。

> > YU-RIS は INT 変数を 64bit で扱っているので1つの要素で 8Byte ですね。
> なので、35*20 * 8Byte = 5600Byte、
> 200*200 のマップだと、 200*200 * 8Byte = 320000Byte(約300KB) になって、
> ファイルにセーブした場合、だいたいそのまま 300KB のファイルが作成されると思います。極端に大きくはないですね。
> ただ、マップデータだけで 300KB ですので、他のいろんなデータやパラメータを保存するとなると、
> どんどんサイズは大きくなってしまいますね(^^;

これが一つのマップの場合です。本格的のRPGで100以上のマップがあればおかしくないです(だって、家の中や洞窟のレベルや店の中が別々のマップになります)。それだけで25MB以上になります!そして、SAVE[]とLOAD[]がかなり早いですから、実際のマップに多分二つのファイルを使います(二つのレイヤを作る為に)。他のデータ(特にマップに付いたイベントのデータ)も同じような問題がありますから、ちょっと心配です。

> > それにはいろいろな理由があると思います。
> > まずすぐに思い浮かぶのは、多くのプログラマーさんにとって、アドベンチャーやノベルのシステムの制作が、
> 他のジャンル(RPGやアクションゲームなど)に比べて、作りやすいからだと思います(^^
> ノベルシステムって、CGを画面に表示して、その上に文字を順番に表示していけば、極端に言えば、それで出来上がりなんですよね。
> 凄くシンプルなんです。(もちろん、高機能なシステムを作るとなるとまったく話が違ってきますけど)
> だから、習作としてノベルシステムは選ばれやすいんだと思います。

確かにそうかも知りません。例えば、RPGでアイテムの管理や戦いシステムなどのものがあります。実際はそんな難しくないと思いますけど、作るまで恐ろしいものかも知りません。

> > あとは、はっきりとはわからないですけど、
> パソコン上で、RPGをプレイする人とノベルをプレイする人の割合が違うのかな…と思います。
> もちろんRPGをプレイするユーザーもかなり多いと思いますが、
> ノベルをプレイするユーザーのほうがさらに多いのだと思います。
> だからきっと、それに比例して(?)、制作ツールも多いのではないかと思います。
> これがPS2などのハードになると、また違う割合なのでしょうね。

それはどうかしら。Vectorを見るとそんな差を見えませんけど。RPG+Action RPG+戦闘Simulation(SRPGがよくませていますから)が大体Adventure+恋愛Simulationと同じ数らしいです。ちょっとAdventureの方が多いですけど、でもそれが倍になりません。こんな数を見れば、エンジンの数がやっぱり違和感を生み出します。


> RPGツールと比べてノベルツールを作る開発者のほうが多いのは単純に何故なんだろうという意味合いですし(^^

うん、その通りです。好奇心の質問だけでした。誰かを傷付いたら、本当にごめんなさい。こんなつもりではありませんでした。

それでは、

Deathworks

0478 マップデータ
投稿者:たくみ 2006/05/31(水) 04:28

> これが一つのマップの場合です。本格的のRPGで100以上のマップがあればおかしくないです
> (だって、家の中や洞窟のレベルや店の中が別々のマップになります)。それだけで25MB以上になります!
> そして、SAVE[]とLOAD[]がかなり早いですから、実際のマップに多分二つのファイルを使います(二つのレイヤを作る為に)。
> 他のデータ(特にマップに付いたイベントのデータ)も同じような問題がありますから、ちょっと心配です。

ですね。
でも例えば、データファイルとして各マップをファイルに保存しておき、
必要になったら LOAD 命令で読み込むというやり方でやれば、
(例えばフィールドから洞窟の中に入ったら、その時点で、アクティブなマップ用配列変数に洞窟のデータを上書きで読み込む)
数十MBも必要とせず、大きな配列変数1個(サブとして用意したとしても2,3個)で済むと思います。
必要に応じてマップを読み込む処理が必要になるので、ちょっと面倒になりますけどね…(@@;


> > > それにはいろいろな理由があると思います。
> > > まずすぐに思い浮かぶのは、多くのプログラマーさんにとって、アドベンチャーやノベルのシステムの制作が、
> > 他のジャンル(RPGやアクションゲームなど)に比べて、作りやすいからだと思います(^^
> > ノベルシステムって、CGを画面に表示して、その上に文字を順番に表示していけば、極端に言えば、それで出来上がりなんですよね。
> > 凄くシンプルなんです。(もちろん、高機能なシステムを作るとなるとまったく話が違ってきますけど)
> > だから、習作としてノベルシステムは選ばれやすいんだと思います。
> …
> 確かにそうかも知りません。例えば、RPGでアイテムの管理や戦いシステムなどのものがあります。実際はそんな難しくないと思いますけど、
> 作るまで恐ろしいものかも知りません。

そうですね。
単純に使用する変数の数も、ノベルと比べて非常に多く、複雑そうです。


> > > あとは、はっきりとはわからないですけど、
> > パソコン上で、RPGをプレイする人とノベルをプレイする人の割合が違うのかな…と思います。
> > もちろんRPGをプレイするユーザーもかなり多いと思いますが、
> > ノベルをプレイするユーザーのほうがさらに多いのだと思います。
> > だからきっと、それに比例して(?)、制作ツールも多いのではないかと思います。
> > これがPS2などのハードになると、また違う割合なのでしょうね。
> …
> それはどうかしら。Vectorを見るとそんな差を見えませんけど。RPG+Action RPG+戦闘Simulation(SRPGがよくませていますから)が
> 大体Adventure+恋愛Simulationと同じ数らしいです。ちょっとAdventureの方が多いですけど、でもそれが倍になりません。
> こんな数を見れば、エンジンの数がやっぱり違和感を生み出します。

そうですか…。まぁはっきりと私もわからないので、また推測ですけど、
ノベル制作ツールが多いのに関わらず、ノベルツールの数とRPGの数が現在ほぼ互角なのだとしたら、
市販のRPG制作ツールがかなり昔から出回っていて、それが普及して地位を獲得したからかな…?
「RPGツクールDante98」とか、Windows の前の DOS の時代からもう出ていたというのがあるでしょうか。
それに比べて、市販のノベル制作ツール、というのはその時代には確かまだ無かったと思います。
(もしあったらごめんなさい…)


> > RPGツールと比べてノベルツールを作る開発者のほうが多いのは単純に何故なんだろうという意味合いですし(^^
> うん、その通りです。好奇心の質問だけでした。誰かを傷付いたら、本当にごめんなさい。こんなつもりではありませんでした。

いえいえ、十分理解していますので大丈夫です(^^
何でもまた質問してくださいね。

0484 マップデータの誤解
投稿者:Deathworks 2006/05/31(水) 18:13

今日は、Deathworksです。

> でも例えば、データファイルとして各マップをファイルに保存しておき、
> 必要になったら LOAD 命令で読み込むというやり方でやれば、
> (例えばフィールドから洞窟の中に入ったら、その時点で、アクティブなマップ用配列変数に洞窟のデータを上書きで読み込む)
> 数十MBも必要とせず、大きな配列変数1個(サブとして用意したとしても2,3個)で済むと思います。
> 必要に応じてマップを読み込む処理が必要になるので、ちょっと面倒になりますけどね…(@@;

あっ!何かの誤解があったみたいです。私も最初から、「@DW_Current Map()」のような変数の一個でするつもりです。心配するのはハードディスクでの大きさです。大したグラフィックがなくても数MBの大きさのゲームがちょっと見苦しいと思います。「SAVE」と「LOAD」が強いからこそ一個の変数で済むはずです。

今はこちらにもあまり時間がありませんから、これで終わります。色々を教えてと考えてくれて有り難うございます。

Deathworks

0490 なるほど
投稿者:たくみ 2006/06/03(土) 21:52

>あっ!何かの誤解があったみたいです。私も最初から、「@DW_Current Map()」のような変数の一個でするつもりです。
> 心配するのはハードディスクでの大きさです。大したグラフィックがなくても数MBの大きさのゲームがちょっと見苦しいと思います。
>「SAVE」と「LOAD」が強いからこそ一個の変数で済むはずです。

なるほど、確かに必要なハードディスクの容量は大きくなりますね(@@;ゞ

あ、でもですね。
配布するときに、ZIP や LZH 形式などで圧縮することになると思いますが、
マップデータファイルの圧縮率はかなり良くなると思います。それは、
1つの変数(64bitデータ)に1〜2バイトの小さい値が入ったデータばかりになる筈ですので、
すごく規則的なデータになっている筈なのです。(※圧倒的に「0x00」ばっかりのデータになる)
そうなると、たとえばデータファイルひとつに約25MBあったとしても、圧縮すれば
数十〜数百KB程度にまでは減ってくれると思います(^^

ただもちろん、実行するときは当然解凍するので、
インストール容量はやっぱり大きいままですけどね(^^;

0471 いつもお世話になります。
投稿者: 2006/05/27(土) 21:51

たくみ様

お世話になります。
開発お疲れ様です。

>RPGツールと比べてノベルツールを作る開発者のほうが多いのは単純に何故なんだろうという意味合いですし
はい、それは承知しております。
ただ、現状あるRPGツールだと逆にそれに特化して小回りがきかないものが多いかと思います。
RPGツールだと確かにマップが作りやすくて戦闘システムも自分で無理に作らなくてもいいという利点はありますが、自分なりのものを作ろうとすると不自由に思うこともあります。
だけど、ノベルツールや汎用のゲームスクリプトだと、自分の作りたいものを形にしやすいので、これでRPGやSLGを作ってる人も結構多いと思います。
ですから、○○ツールというのに拘ったり、名乗ってる名前に囚われることはないのではないかなという意味あいでレスしたつもりなのですが。

開発者の意図しない使い方をしてクリエイターが作るのが、開発者様にとっては良いのか悪いのかはよくわからないのですが。
でも、YU-RISで良い作品を生み出すことで、YU-RISの評価も間接的に示せるのではないかと思っております。
ですから、YU-RISを使って良い作品を生み出すことが、わたしたちがたくみ様への感謝を示すことになるのではないかと思っています。
ですから、良い作品が出来るようにがんばりたいと思います。

たくみ様も開発がんばってください。
わたしも、お手伝いしているサークル様でYU-RISを使って製作することになりそうですので、実際に動きだしたらいろいろ具体的な要望や質問をすることもあると思います。
そのときは、またよろしくお願いします。

0483 システムの自由度
投稿者:たくみ 2006/05/31(水) 04:40

薫さんどうもです。
レス遅れましてすみません;;

> ただ、現状あるRPGツールだと逆にそれに特化して小回りがきかないものが多いかと思います。
> RPGツールだと確かにマップが作りやすくて戦闘システムも自分で無理に作らなくてもいいという利点はありますが、
> 自分なりのものを作ろうとすると不自由に思うこともあります。

特化させると小回りが効かなくなりがちなのはよく有りますね。
そのあたりRPGツクールの最新版(だったかな?)では、基本はGUIで作りつつ、
かつ独自に細かくいじくりたいところはプログラミングも出来るようになっているというのは、
良く考えてるなぁ…と思います。…難易度は高いらしいですが(^^;
実はERISライブラリも同じで、ヘタをすると1パターンなシステムしか作れなくなってしまうので、
ノベルに特化しつつも自由度は無くさない作りにしていくのが今後の目標です。

> だけど、ノベルツールや汎用のゲームスクリプトだと、自分の作りたいものを形にしやすいので、これでRPGやSLGを作ってる人も結構多いと思います。
> ですから、○○ツールというのに拘ったり、名乗ってる名前に囚われることはないのではないかなという意味あいでレスしたつもりなのですが。

なるほど。そうでしたか。
失礼いたしました(^^;ゞ

> 開発者の意図しない使い方をしてクリエイターが作るのが、開発者様にとっては良いのか悪いのかはよくわからないのですが。
> でも、YU-RISで良い作品を生み出すことで、YU-RISの評価も間接的に示せるのではないかと思っております。
> ですから、YU-RISを使って良い作品を生み出すことが、わたしたちがたくみ様への感謝を示すことになるのではないかと思っています。
> ですから、良い作品が出来るようにがんばりたいと思います。

有り難うございますm(_ _)m
そう言ってくださるだけでも、ここまで諦めずに作ってきて良かったな…と本当に思えます。
とはいっても、まだ正式版出てませんけどね…;
こちらもツールで協力できるよう、開発のほう頑張らせていただきます!

0468 ゲーム製作について
投稿者:Deathworks 2006/05/27(土) 19:30

今日は、Deathworksです。

> ノベルシステムだから、ノベルしか作れないとは限らないです。

うん、これがわかります。ある条件に反応するとあることが出来ます。例えば、配列がなければ、RPGを作るのが大変です。(無理ではありませんけど、無理矢理の感じのプログラムになりますけど。)

> わたしは、今まで吉里吉里/kagでゲーム作っていますが。
> その吉里吉里/kagででも育成SLGや簡易なRPGもどきのものを作られてる方もいらっしゃいます。

吉里吉里が私にとって痛い例です。吉里吉里がHSPのようになんでも簡単に出来るものだと思います。そして、(これは個人的の気持ちだけです)HSPよりちゃんとしたものです。でも、KAGがありますから、皆さんがノベルシステムだけに考え込み中らしいです。例えば、ふりーむのLinkのリストでは、吉里吉里がHSPの隣ではなくて、ノベルの場所にあります。それが酷いと思います。

> また、知り合いのNScripter使いの人の中にもやっぱり同じように育成SLGや簡易なRPGを作られてる方がいらっしゃいます。

うん、Nscripterの実力が確かに凄いです。今まで見たノベルシステムで一番強いものだと思います。(吉里吉里がノベルシステムではないと思いますから、比べません。)

> だから、要はツールを使うクリエイターの発想次第ではないでしょうか。

確かに色々なことが出来ます。いいアイデアがあれば、まさに向いてない待ち合わせが出来ます。でも、システムに向いていることや向いていないことがあります。そして、どんな形で名乗るのも気になります。

> Ellisは、ADVやビジュアルノベルを簡単に使いやすいというだけで、使いようによっては育成SLGもRPGも作ろうと思えば作れると思います。

でも、実際はYU-RISを使うものでしょう(確かめなかったから、間違う可能性があります)。そして、本当にYU-RISの機能をノベルを向いている方に使うとYU−RISよりRPGなどに向いていないはずです(教育SLGが大体ノベルと同じものですから、ノベル形だと思います)。なら、ノベルを作れば、Erisの方がいいといっても、他のゲームなら、YU-RISの方が言いになるはずだと思います。間違っているとごめんなさい、でもノベルシステムの名乗ることによっての当然の考えだと思います(”dedicated”のシステムですから)。

> ですから、YU-RISをマスターしてすばらしいゲームをお互い作っていければいいですね。

そうですね。どんな考え方であっても、面白いゲームを出来ると充分です。色々をはじめて、何も出来上げなかった私が自身あまりないけど、一応出来るだけ頑張りたいと思います。いつか何かで成功したいと思います。

う〜ん、この返事が部分的に不親切に見えるかも知りませんけど、そんなつもりではありません。私の質問に答えようしてくれて有り難いと思います。

Deathworks

0470 ゲーム製作について
投稿者: 2006/05/27(土) 21:35

Deathworks様

お返事ありがとうございます。
ツールについての考え方については、作者様の開発方針、ユーザーの使い方によってもいろいろ違いますから、こうだという決め付けは創造力の幅を狭くすることもあるかと思います。
ちなみに吉里吉里でシューティングを作られた方もいますし、NスクでシュミレーションRPGのようなものを作られてる方も実際にいます。
詳しいご紹介は避けますが。
だから、このツールではこれしか出来ないと決めてしまうと、その人にはそれしか出来ないと思います。

>配列がなければ、RPGを作るのが大変です。
配列変数が出来れば、確かに作るのは楽ですが。
でも、ないと出来ないということではありませんし。
何にしても『作る』ということは、大変なことです。
わたしも自分で今まで5つほど作品を作ってますし、現在も知り合いの作品の製作をいくつか手伝っております。
中には、連載形式で公開して製作3年目に入っているものもあります。
完成するまでは、いろんな問題や出来事があり、ものすごい根気がいります。
自分の気に入ったツールで作るのなら、できることで工夫して作ると案外いろいろできるものです。
確かにツールが多機能だったら、労力は減るのでものすごく助かりますが。

>ふりーむのLinkのリストでは、吉里吉里がHSPの隣ではなくて、ノベルの場所
リンクに関しては、リンクフリーだと作者へ報告しない場合もありますから、そうすると作者の意向は反映されないこともあると思いますので、サイト管理者の方針や考え方でそうなってしまうでしょう。
吉里吉里は、汎用的なゲームスクリプトとしていてもそういう位置づけになってしまうので仕方ありません。
だから、吉里吉里はということではないと思います。
これは、YU-RISでも同じではないでしょうか?
YU-RISは、汎用的なゲームシステムとしてあっても、現状、ADVゲームが多いですし、Ellisという簡単にノベルが作れるライブラリがあればノベル作品ももっと増えるでしょう。
だから、そういうツールだと言われたらRPGは作れないのかというとそうではないと思います。
乱暴な言い方ですが、自分の気に入ったツールが向いてないシステムだからといっても、作れるのならそれでひとつの作品を作ってしまえばいいのではないでしょうか?

>でも、実際はYU-RISを使うものでしょう
ゲーム作りたいという人が必ずしもプログラムが得意な人ばかりではないと思います。
初心者の人や手軽に作りたいという人にとっては、Ellisというライブラリは便利でそれで作られると思います。
でも、ほんとならYU-RISを使うべきだ、それは普通の使い方じゃないと言われてもそれは単なる製作の過程の問題にすぎないのではないでしょうか?
YU-RISだけで作られても、Ellisを使って作られても、結果出来上がった作品が素晴らしいRPGなりSLGになっていれば、作る側もその作品を手に取る側もなんら問題はないと思います。

一番はいろいろ言うよりも気に入ったツールで自分の作りたい作品を形にして示すことのほうが重要だと思います。
どんな形で名乗っていても、いろいろ言われても一番は作品を作って示すことのほうが言葉よりももっと確かアピールになると思います。

Deathworks様もがんばって良い作品を完成してください。
いいものが出来るようお祈りします。

0475 まぁ、色々な考え方がありますね。
投稿者:Deathworks 2006/05/29(月) 19:09

今日は、Deathworksです。

薫さん、かまってくれて有り難うございます。
薫さんのいうことが私の考えとあまり変わらないと思います。プログラマーの腕によって色々なことが出来るとよくわかります。例えば、最近遊んだ同人誌ゲームはNscripterで作られたダンジョンRPGです。
正しいどんな風に名乗るのがやってくれるプログラマーに影響があると思います。まだ何のシステムを知らないプログラマーは普通で作りたいゲーム用のシステムや何でも屋のシステムの中で探すはずです。例えば、シューティングゲームを作りたい人はシューティングゲームのエンジンや何でも出来るシステムを探すはずです。ノベルゲームシステムを探すはずがないと思います。あるシステムに慣れたプログラマーが違うんですけど、まだ自分の好きなシステムを見つけない人は大体こんな感じだと思います。
ですから、吉里吉里やYU-RISみたいな何でも出来るシステムのイメージを心配します(KAGの影響が強さですから、Erisを疑う人です)。
まぁ、これはあくまで私の感じだけですから、あまり気にしなくていいです。薫さんが違うと思うなら、それでよろしいと思います。結果的に大切のはゲーム制作で頑張る事でしょう。

> > Deathworks様もがんばって良い作品を完成してください。
> いいものが出来るようお祈りします。
本当に有り難うございます。薫さんも成功してお願っています。お互いに頑張りましょう。

Deathworks