ぼくは絵が描けないので、ゲームを作っていても顔グラが用意できなくて歩行グラしかない場合、その歩行グラを顔グラとして使うしかありません。
けれども基本システムでの顔グラ表示は一枚の画像素材の全体丸ごとを表示するものです。
画像素材の分割の設定やパターン番号の指定はできません。
もしウルファールの歩行グラを顔グラ素材として指定すれば、24体のウルファールが表示されてしまいます。（多分）
しかし今夜はそれをごく簡単な改造で解決できたので、メモ代わりに書いておきます。
（ここに書くのはウディタVer2のことです。Ver3は未確認なのでわかりません。あしからず。）
・まずはシステムDBの「顔グラフィック」に歩行グラ用に作られた画像を設定したうえで、
・コモン68番「メッセージウィンドウ」を開いて
・127行目のコマンド「ピクチャ表示」を開いて
・ウルファールなどの同梱素材の規格（8方向3パターン）なら分割数を横６縦４にして
・パターンの同期のチェックを外して、パターン数を４（左前を向く画像）とかに指定する。
これだけで、歩行グラ素材の中の一つの画像を顔グラとして表示させることができるようになります。
ただしこのやり方だと全ての顔グラ用素材が分割され部分表示されてしまうので、通常の顔グラ素材と混在させるときには何とか工夫しないといけないので気をつけてください。
使える顔グラ素材なんて一枚も持っていないよ、という時だけ上の方法を使ってください。
それにしても解像度の粗さよ・・・。
まあサンプルゲームデータの顔グラに入ってるのもこんなもんだし、画像があるだけおんのじですね。
2023年03月10日
2022年12月02日
Yahoo！知恵袋で「この写真の人の名前を教えてください」という質問に答えてみて
Yahoo！知恵袋というサイトによくある「この写真の人の名前を教えてください」という質問の答えを探す方法について、前回の記事で書きました。
あの記事ではその方法を知りたい方のために必要な情報をにコンパクトに書いたんです。
で、この記事ではそれにまつわるいろいろよけいなことを、コンパクトじゃなく書きます。
（自分語りを含むので興味ない人は読まないでくださいね）
まず画像検索であの手の質問に答えられる率はものすごーく低いです。
５パーセントもないのじゃないでしょうか。
半数以上はその画像はネット上では確認されていないです。
そして残りの大半は逆にネット上に氾濫してしまい、画像の出どころと紐付けられない形で出回ってしまっています。
こんなの、写真の被写体の了承が得られていない場合は本人は随分つらいかもしれないけれど、それってどうしようもないのだろうか。
特定の個人によって個人情報を流出されたりした場合はそれをたどって削除要請などもできるのかもしれないけれども。
けれどもよく出回っている画像というのは本当に世界中でシェアされていて、本人が消してほしいと思っても、それはとても不可能に思います。
というか顔や名前を売りたい芸能人でもない限り、たいがいの人はネット上に自分の顔が氾濫して嬉しいとは思わないんじゃないかな。
つらい人多いんだろうな。
まあ中には「自分の顔はこんなに世界中で拡散されてるんだ、自分に魅力がある証拠だからうれしい」とか、承認欲求を満たせてポジティブにとらえる人もいるかもしれないけれども、それはごくごく一部でしょう。
ちなみにその、つらいかもしれない人の名前探しをしているぼくの見解（言い分？）を書いておきます。
ぼくが調べているのはネット上に公開されている情報だけです。
その情報を公開することに本人が同意したか、そして現在でも後悔していないか、知るすべはありません。
そしてその情報はネット上にある限りはぼくでなくても誰でもアクセスできます。
ぼくが効率のいい方法を知っていたとしても、誰でも手間暇時間をかければいつかはたどり着けるであろう情報です。
そのような情報に対して、本人がつらいと思っている可能性がある一方で、その回答を求めている質問者がいます。
質問者の動機は様々でしょうし、知るすべはありません。
単純にすてきな写真の人のことをもっと知りたいという場合も多いでしょう。
恋人のスマホの待ち受けになっていた人物が誰なのか知りたいとかもあるかもしれません。
ひょっとしたら通勤途中に出会った見知らぬ異性を隠し撮りして個人情報を集めようとしている犯罪者さえいるかもしれません。
それらは分からないことです。
ただ、質問者の多くは求めていた回答が得られると、大変喜びます。
そのようなもろもろをトータルに勘案して、名前探しをすることは悪いことではないのではないかと判断しています。
断っておきますが、ネットには特定屋という人がいるらしく、個人があげた画像から映りこんでるものなどを手掛かりとして個人情報を特定したりするそうです。しかしそれは本人は望んでいないからよくないことだとぼくは思うし、やりません。（ネットに個人情報につながりうるデータをアップすることの脇の甘さは言えるでしょうが、それは別の話です。）
ぼくはネット上で名前やそれに類するものにたどりつくことに興味があるだけです。
とはいえ、質問者に喜ばれることだけがぼくが名前探しをするモチベーションではありません。
できなくて困っている人がいる一方でそれを自分は簡単にできるので、そこを埋めてあげたいというのはまぁあるんだけれども。
でもそれよりも自分のネットリテラシーを磨きたい、確認したいとか。
それと画像認識というＡＩを駆使した最先端技術の到達点を肌で感じたいとかが大きいです。
それらが大きな動機となっています。
画像認識の精度について書きましょうか。
いくつか試しましたが、いまのところGoogle Lens以外で使える画像検索の方法には出会えていません。
（有料の方法は試していません）
そしてそのGoogle Lensでも、認識という点では全然まだまだだなと感じます。
現状では、同一の画像がネット上にあるかないかがわかるだけです。
似た画像として提示される画像は、まあ、驚くほど全然似ていなかったりします。
ましてや同一人物の別シーンでの顔を同一人物として提示してくることなどはまだまだ夢物語のようです。
でも世間では顔認証とか実用化されているんですよね。
ネット上のデータだけでいいから、誰でも手軽に検索できる日がはやく来たらいいなと楽しみにしています。
指名手配犯は困るでしょうね。
（そういえば中国のスマートシティでは監視体制が完全に確立されていると聞きます）
まあ、日本のＰＣで個人ができる現状の画像検索と言ってもその程度なのですが。
それに対して質問者さんの質問の仕方、すなわち画像の選び方があまりにも「どうせいっちゅうねん！」と突っ込みたくなる場合があります。
画像の一部を加工して塗りつぶしたりとか。
スマホの画像のスクショなので上下に余白があったりだとか。
長い動画の中のある時点の写真だとか。
これらの場合はほぼ特定できません。
まあ余白がある場合はこちらでトリミングしてあげて検索してあげれば精度の高い検索はできるはずです。
ぼくも何度かはやってみましたが、手間をかけても結局特定にはつながらないことばかりなので、もうやめました。
まあ質問者さんも「名前を教えて」と言っていても、「同一画像をネットから探して」と言っているわけではないですからね。
第一義的には、被写体の身近にいる個人的な知り合いに向かって「あなたの知り合いなら教えて」という感覚だろうし。
そうでなくても「この人はアイドル（あるいは芸能人、インスタグラマー、Youtuber…）だからそれに詳しい人教えて」ということかもしれません。
ただぼくはそれらは全く詳しくないのでそういう方法では全然役には立てないのです。
画像を載せる場合はどこで手に入れた画像かを書いてくれたら随分探しやすくなるのにと思うことがよくあります。
（あるいは逆に、見つかるわけないからさっさとあきらめる、とかもできるし…）
この画像の名前探しを続けていると、写真を見ただけで「この人の名前はいくら探してもまず出てこないな」とわかるものがあります。
よくあるのは衣料品のモデル。消費者であるぼくらが目にすることは多い一方で、名前が出ていることはほとんどありません。例外的には有名ブランドが有名芸能人をイメージキャラクターとかキャンペーンガールとかに任命している場合はSNSなどで名前が出ています。ただ普通のショッピングサイトなどのモデルはほぼ絶対わかりません。
それからネット広告のモデルです。スマホアプリや動画の広告などで見つけた写真はまず名前を特定できません。
質問者がテレビ番組の一時点を撮影した画像も絶対にわかりません。全く同じ画像がネット上にないためです。
（例外として番組名と放送日からゲスト出演者名が特定できたことはありましたが、そんなことはほとんどないです）
その一方でCMなどはシーン数が少ないので（写真撮影にテレビの枠が写ったりしてない限り）画像検索でヒットすることがあります。
特にテレビCMはまとめサイトもあるし、絞り込めた芸能人のWikipediaにCM出演情報があるので特定につながったりします。
韓国のコスメ動画はなぜかわかる場合が多い気がします。ハングルは読めませんがmodel誰々と載っていることがあります。
検索結果の中で、名前特定に一番つながりやすいのはインスタグラムに本人があげている写真です。自分の顔ばかり上げる人が多いので特定が容易です。
次にみつかるのはTikTokです。本人があげていることも多いですが、美少女など、まとめてあげている場合もあるので要注意です。
ツイッターはみつかりません。名前が見つからないだけじゃなく、写真自体が見つからないことが多いです。検索結果としては特定のツイートがでるのですが、そのツイートには目的の画像はありません。そこについたコメントのアイコンにその画像が使用されている場合があります。しかもアイコン画像はコロコロ変える人も多いです。さらにはツイッターのアイコンは本人画像でない場合が多いです。せっかく目的の画像をアイコンにしているアカウントを見つけてもプロフィール欄を見ると本人じゃないとわかってがっくりることが多いです。（かわいい女の子を好きな人が、かわいい女の子をアイコンにしている場合が多いです）
ツイッターに限らないことですが、ジャニーズアイドルのファンは推しの顔をアイコンにする傾向があり、画像とアカウント名とが結びつかないことがほとんどです。
ピンタレストという画像共有ＳＮＳがあります。肖像権などどこ吹く風というちょっと恐ろしい世界なのですが、画像検索結果がピンタレストにでてくることがよくあります。世界中の多くの人にシェアされて出どころのわからない写真も多いのですが、引用元を表示する欄が一応あるので、時々特定につながることはあります。インスタグラムや個人ブログなどから引用した画像だとわかれば個人名がわかります。ツイッターよりはまだ有意義な情報につながる率が高いです。
一番意味がないのがYahoo！知恵袋です。画像検索にYahoo！知恵袋がヒットしても、それはその質問のためにアップされた画像のことなので当然名前は分かりません。また、Yahoo！知恵袋ではその画像が出てこないページが多くあります。そのリンク先のページでは別の画像について「この人の名前は何ですか」と質問されていて、よく似た質問として目的の画像が過去に表示されたのだろうけれども、それは時間がたつにつれて更新されていくので、閲覧している時点ではもう目的の画像は表示されていないということだろうと思います。ただ非常にまれなケースとして、ネット上で多く出回っている画像（そしてその中でも特に芸能人）の場合は過去にも同じ質問がされていてちゃんと回答も載っている場合があるのでその時ばかりは特定につながります。
こんなことをやってると、意外に海外の人の画像に興味がある人が多いんだなと驚かされます。
韓国や中国、あるいは西洋とかならまだわかるけど。
質問者さんの探求心はグローバルです。結構どこの国の人のことでも、国籍を知っていても名前を知りたがっています。
発音の仕方もわからない名前を知ってどうするのかとも思うんですが（まあ検索してさらに情報を集めたいんでしょうね）、ぼくも特定できた場合には現地の言語の名前と思われる部分をコピペして回答することもあります。
いろいろ書きましたがあなたのお役に立つことがあれば幸いです。
あの記事ではその方法を知りたい方のために必要な情報をにコンパクトに書いたんです。
で、この記事ではそれにまつわるいろいろよけいなことを、コンパクトじゃなく書きます。
（自分語りを含むので興味ない人は読まないでくださいね）
まず画像検索であの手の質問に答えられる率はものすごーく低いです。
５パーセントもないのじゃないでしょうか。
半数以上はその画像はネット上では確認されていないです。
そして残りの大半は逆にネット上に氾濫してしまい、画像の出どころと紐付けられない形で出回ってしまっています。
こんなの、写真の被写体の了承が得られていない場合は本人は随分つらいかもしれないけれど、それってどうしようもないのだろうか。
特定の個人によって個人情報を流出されたりした場合はそれをたどって削除要請などもできるのかもしれないけれども。
けれどもよく出回っている画像というのは本当に世界中でシェアされていて、本人が消してほしいと思っても、それはとても不可能に思います。
というか顔や名前を売りたい芸能人でもない限り、たいがいの人はネット上に自分の顔が氾濫して嬉しいとは思わないんじゃないかな。
つらい人多いんだろうな。
まあ中には「自分の顔はこんなに世界中で拡散されてるんだ、自分に魅力がある証拠だからうれしい」とか、承認欲求を満たせてポジティブにとらえる人もいるかもしれないけれども、それはごくごく一部でしょう。
ちなみにその、つらいかもしれない人の名前探しをしているぼくの見解（言い分？）を書いておきます。
ぼくが調べているのはネット上に公開されている情報だけです。
その情報を公開することに本人が同意したか、そして現在でも後悔していないか、知るすべはありません。
そしてその情報はネット上にある限りはぼくでなくても誰でもアクセスできます。
ぼくが効率のいい方法を知っていたとしても、誰でも手間暇時間をかければいつかはたどり着けるであろう情報です。
そのような情報に対して、本人がつらいと思っている可能性がある一方で、その回答を求めている質問者がいます。
質問者の動機は様々でしょうし、知るすべはありません。
単純にすてきな写真の人のことをもっと知りたいという場合も多いでしょう。
恋人のスマホの待ち受けになっていた人物が誰なのか知りたいとかもあるかもしれません。
ひょっとしたら通勤途中に出会った見知らぬ異性を隠し撮りして個人情報を集めようとしている犯罪者さえいるかもしれません。
それらは分からないことです。
ただ、質問者の多くは求めていた回答が得られると、大変喜びます。
そのようなもろもろをトータルに勘案して、名前探しをすることは悪いことではないのではないかと判断しています。
断っておきますが、ネットには特定屋という人がいるらしく、個人があげた画像から映りこんでるものなどを手掛かりとして個人情報を特定したりするそうです。しかしそれは本人は望んでいないからよくないことだとぼくは思うし、やりません。（ネットに個人情報につながりうるデータをアップすることの脇の甘さは言えるでしょうが、それは別の話です。）
ぼくはネット上で名前やそれに類するものにたどりつくことに興味があるだけです。
とはいえ、質問者に喜ばれることだけがぼくが名前探しをするモチベーションではありません。
できなくて困っている人がいる一方でそれを自分は簡単にできるので、そこを埋めてあげたいというのはまぁあるんだけれども。
でもそれよりも自分のネットリテラシーを磨きたい、確認したいとか。
それと画像認識というＡＩを駆使した最先端技術の到達点を肌で感じたいとかが大きいです。
それらが大きな動機となっています。
画像認識の精度について書きましょうか。
いくつか試しましたが、いまのところGoogle Lens以外で使える画像検索の方法には出会えていません。
（有料の方法は試していません）
そしてそのGoogle Lensでも、認識という点では全然まだまだだなと感じます。
現状では、同一の画像がネット上にあるかないかがわかるだけです。
似た画像として提示される画像は、まあ、驚くほど全然似ていなかったりします。
ましてや同一人物の別シーンでの顔を同一人物として提示してくることなどはまだまだ夢物語のようです。
でも世間では顔認証とか実用化されているんですよね。
ネット上のデータだけでいいから、誰でも手軽に検索できる日がはやく来たらいいなと楽しみにしています。
指名手配犯は困るでしょうね。
（そういえば中国のスマートシティでは監視体制が完全に確立されていると聞きます）
まあ、日本のＰＣで個人ができる現状の画像検索と言ってもその程度なのですが。
それに対して質問者さんの質問の仕方、すなわち画像の選び方があまりにも「どうせいっちゅうねん！」と突っ込みたくなる場合があります。
画像の一部を加工して塗りつぶしたりとか。
スマホの画像のスクショなので上下に余白があったりだとか。
長い動画の中のある時点の写真だとか。
これらの場合はほぼ特定できません。
まあ余白がある場合はこちらでトリミングしてあげて検索してあげれば精度の高い検索はできるはずです。
ぼくも何度かはやってみましたが、手間をかけても結局特定にはつながらないことばかりなので、もうやめました。
まあ質問者さんも「名前を教えて」と言っていても、「同一画像をネットから探して」と言っているわけではないですからね。
第一義的には、被写体の身近にいる個人的な知り合いに向かって「あなたの知り合いなら教えて」という感覚だろうし。
そうでなくても「この人はアイドル（あるいは芸能人、インスタグラマー、Youtuber…）だからそれに詳しい人教えて」ということかもしれません。
ただぼくはそれらは全く詳しくないのでそういう方法では全然役には立てないのです。
画像を載せる場合はどこで手に入れた画像かを書いてくれたら随分探しやすくなるのにと思うことがよくあります。
（あるいは逆に、見つかるわけないからさっさとあきらめる、とかもできるし…）
この画像の名前探しを続けていると、写真を見ただけで「この人の名前はいくら探してもまず出てこないな」とわかるものがあります。
よくあるのは衣料品のモデル。消費者であるぼくらが目にすることは多い一方で、名前が出ていることはほとんどありません。例外的には有名ブランドが有名芸能人をイメージキャラクターとかキャンペーンガールとかに任命している場合はSNSなどで名前が出ています。ただ普通のショッピングサイトなどのモデルはほぼ絶対わかりません。
それからネット広告のモデルです。スマホアプリや動画の広告などで見つけた写真はまず名前を特定できません。
質問者がテレビ番組の一時点を撮影した画像も絶対にわかりません。全く同じ画像がネット上にないためです。
（例外として番組名と放送日からゲスト出演者名が特定できたことはありましたが、そんなことはほとんどないです）
その一方でCMなどはシーン数が少ないので（写真撮影にテレビの枠が写ったりしてない限り）画像検索でヒットすることがあります。
特にテレビCMはまとめサイトもあるし、絞り込めた芸能人のWikipediaにCM出演情報があるので特定につながったりします。
韓国のコスメ動画はなぜかわかる場合が多い気がします。ハングルは読めませんがmodel誰々と載っていることがあります。
検索結果の中で、名前特定に一番つながりやすいのはインスタグラムに本人があげている写真です。自分の顔ばかり上げる人が多いので特定が容易です。
次にみつかるのはTikTokです。本人があげていることも多いですが、美少女など、まとめてあげている場合もあるので要注意です。
ツイッターはみつかりません。名前が見つからないだけじゃなく、写真自体が見つからないことが多いです。検索結果としては特定のツイートがでるのですが、そのツイートには目的の画像はありません。そこについたコメントのアイコンにその画像が使用されている場合があります。しかもアイコン画像はコロコロ変える人も多いです。さらにはツイッターのアイコンは本人画像でない場合が多いです。せっかく目的の画像をアイコンにしているアカウントを見つけてもプロフィール欄を見ると本人じゃないとわかってがっくりることが多いです。（かわいい女の子を好きな人が、かわいい女の子をアイコンにしている場合が多いです）
ツイッターに限らないことですが、ジャニーズアイドルのファンは推しの顔をアイコンにする傾向があり、画像とアカウント名とが結びつかないことがほとんどです。
ピンタレストという画像共有ＳＮＳがあります。肖像権などどこ吹く風というちょっと恐ろしい世界なのですが、画像検索結果がピンタレストにでてくることがよくあります。世界中の多くの人にシェアされて出どころのわからない写真も多いのですが、引用元を表示する欄が一応あるので、時々特定につながることはあります。インスタグラムや個人ブログなどから引用した画像だとわかれば個人名がわかります。ツイッターよりはまだ有意義な情報につながる率が高いです。
一番意味がないのがYahoo！知恵袋です。画像検索にYahoo！知恵袋がヒットしても、それはその質問のためにアップされた画像のことなので当然名前は分かりません。また、Yahoo！知恵袋ではその画像が出てこないページが多くあります。そのリンク先のページでは別の画像について「この人の名前は何ですか」と質問されていて、よく似た質問として目的の画像が過去に表示されたのだろうけれども、それは時間がたつにつれて更新されていくので、閲覧している時点ではもう目的の画像は表示されていないということだろうと思います。ただ非常にまれなケースとして、ネット上で多く出回っている画像（そしてその中でも特に芸能人）の場合は過去にも同じ質問がされていてちゃんと回答も載っている場合があるのでその時ばかりは特定につながります。
こんなことをやってると、意外に海外の人の画像に興味がある人が多いんだなと驚かされます。
韓国や中国、あるいは西洋とかならまだわかるけど。
質問者さんの探求心はグローバルです。結構どこの国の人のことでも、国籍を知っていても名前を知りたがっています。
発音の仕方もわからない名前を知ってどうするのかとも思うんですが（まあ検索してさらに情報を集めたいんでしょうね）、ぼくも特定できた場合には現地の言語の名前と思われる部分をコピペして回答することもあります。
いろいろ書きましたがあなたのお役に立つことがあれば幸いです。
Google Lensで画像を探す方法
Yahoo！知恵袋というサイトがあります。
そこでよく「この写真の人の名前を教えてください」という質問を見かけます。
その答えをどうすれば知ることができるか、いろいろやってみました。
そこでたどりついた画像を探す方法についてこの記事で書きます。
方法以外のことは別の記事で書きます。
以下はぼくのやっている方法なので他にやり方もあるでしょうしベストではないかもしれませんがご了承ください。
パソコンを使います。
ブラウザはGoogle chromeを使います。ない方はインストールしてください。
マウスカーソルを画像に合わせて右クリックしてください。
Google Lensで画像を検索というのが出たらそれを選んでください。
ただし、リンクが貼られている画像だと出ないようなので、可能ならリンクのない画像を探してください。
また、「画像をドラッグして検索 ×」と出る場合もありますが、それをするとおそらく検索精度が下がるので、可能ならそうならない画像を探してください。
「Google Lensで画像を検索」がでてきて、クリックしたら、モニター右にGoogle Lensの枠が出ます。
ぼくの環境だとこの読み込みに少し時間がかかります。
しばらくたっても進まない場合は操作を繰り返して再読み込みしてください。
読み込みに成功したら、画像の下の方には見た目で一致というリストが出たりします。（出ない場合もあります）
しかしここには参考になる情報はめったにないです。まれに探している画像の一部を加工した画像とか、連続写真の別のものが見つかることもありますが、大半はネット販売のリンクなので「人の名前を調べる」という目的の役には立ちません。
大事なのは画像の上にある「この画像を検索」です。ここをクリックします。
すると検索結果がでます。
類似の画像というのはこれまたほぼ役に立たないので気にしないでいいです。
また、なぜかたまに検索窓に画像データ以外に勝手な単語が入っている場合がありますが、その時は検索結果が適当なので、上の方の検索結果は気にせず下にスクロールしてください。
そうするとどこかに「一致した画像を含むページ」というのがあると思います。
Google Lensで検索したのに「一致した画像を含むページ」が出ない時は、ネット上にその同じ画像は見つけられていないということなので、あきらめるしかないかもしれません。
（「一致した画像を含むページ」に載っていないにもかかわらず、インスタグラムにその写真を見つけたこともあるので検索も完ぺきではないでしょうが、とりあえずここで出てこなければなすすべはありません）
その「一致した画像を含むページ」以下の検索結果に、同じ画像がある（あるいは、あった）はずです。
一つ一つ開いて、名前につながる手掛かりがないか調べます。
ただ、そのサイトによって特定できる可能性は全然違います。
詳しくは別の記事で書きますが、インスタグラムがあればそれを、なければTikTokを探せば、名前（アカウント名）にたどり着く確率はまだ高いです。
Yahoo！知恵袋はほぼ載っていません。検索結果がYahoo！知恵袋しかないようなら、その画像はネット上では（Googleには）確認されていないと思っていいかもしれません。
インスタグラムやTikTok等に探している画像と同じものが投稿されていた場合、そのアカウントのほとんどの投稿が同じ顔の自撮り等なら、探していた画像の顔の名前（ネット上の名前）はそのアカウント名であるとみなしていいと思います。
そして必要に応じてそのアカウントのプロフィール欄などを確認して、その写真の被写体の方についてのより詳しい情報を集めてもいいと思います。
この記事では画像検索の方法を知りたい人に向けて、方法だけを書きました。
興味ある方は参考にして画像検索してみて下さい。
個人的に思うことなどはまた別の記事に書きます。
そこでよく「この写真の人の名前を教えてください」という質問を見かけます。
その答えをどうすれば知ることができるか、いろいろやってみました。
そこでたどりついた画像を探す方法についてこの記事で書きます。
方法以外のことは別の記事で書きます。
以下はぼくのやっている方法なので他にやり方もあるでしょうしベストではないかもしれませんがご了承ください。
パソコンを使います。
ブラウザはGoogle chromeを使います。ない方はインストールしてください。
マウスカーソルを画像に合わせて右クリックしてください。
Google Lensで画像を検索というのが出たらそれを選んでください。
ただし、リンクが貼られている画像だと出ないようなので、可能ならリンクのない画像を探してください。
また、「画像をドラッグして検索 ×」と出る場合もありますが、それをするとおそらく検索精度が下がるので、可能ならそうならない画像を探してください。
「Google Lensで画像を検索」がでてきて、クリックしたら、モニター右にGoogle Lensの枠が出ます。
ぼくの環境だとこの読み込みに少し時間がかかります。
しばらくたっても進まない場合は操作を繰り返して再読み込みしてください。
読み込みに成功したら、画像の下の方には見た目で一致というリストが出たりします。（出ない場合もあります）
しかしここには参考になる情報はめったにないです。まれに探している画像の一部を加工した画像とか、連続写真の別のものが見つかることもありますが、大半はネット販売のリンクなので「人の名前を調べる」という目的の役には立ちません。
大事なのは画像の上にある「この画像を検索」です。ここをクリックします。
すると検索結果がでます。
類似の画像というのはこれまたほぼ役に立たないので気にしないでいいです。
また、なぜかたまに検索窓に画像データ以外に勝手な単語が入っている場合がありますが、その時は検索結果が適当なので、上の方の検索結果は気にせず下にスクロールしてください。
そうするとどこかに「一致した画像を含むページ」というのがあると思います。
Google Lensで検索したのに「一致した画像を含むページ」が出ない時は、ネット上にその同じ画像は見つけられていないということなので、あきらめるしかないかもしれません。
（「一致した画像を含むページ」に載っていないにもかかわらず、インスタグラムにその写真を見つけたこともあるので検索も完ぺきではないでしょうが、とりあえずここで出てこなければなすすべはありません）
その「一致した画像を含むページ」以下の検索結果に、同じ画像がある（あるいは、あった）はずです。
一つ一つ開いて、名前につながる手掛かりがないか調べます。
ただ、そのサイトによって特定できる可能性は全然違います。
詳しくは別の記事で書きますが、インスタグラムがあればそれを、なければTikTokを探せば、名前（アカウント名）にたどり着く確率はまだ高いです。
Yahoo！知恵袋はほぼ載っていません。検索結果がYahoo！知恵袋しかないようなら、その画像はネット上では（Googleには）確認されていないと思っていいかもしれません。
インスタグラムやTikTok等に探している画像と同じものが投稿されていた場合、そのアカウントのほとんどの投稿が同じ顔の自撮り等なら、探していた画像の顔の名前（ネット上の名前）はそのアカウント名であるとみなしていいと思います。
そして必要に応じてそのアカウントのプロフィール欄などを確認して、その写真の被写体の方についてのより詳しい情報を集めてもいいと思います。
この記事では画像検索の方法を知りたい人に向けて、方法だけを書きました。
興味ある方は参考にして画像検索してみて下さい。
個人的に思うことなどはまた別の記事に書きます。
2022年01月03日
ウディタで直線を引く機能を使う
昨年末に、上司からいきなり無茶振りをされましてね。
手書きの図形を見せられて、こんなのをパソコンで作ってーって。
円や直線を組み合わせた図形です。ここでお見せできないのが残念なんですが。
そこでぼくはまず素直にペイント系のソフトを使ってみたんです。
でも使い慣れてないしどうもうまくできない。
これはもうしょうがない、やはり、ウディタの出番です。
常日頃ウディタを活用していかにペイントを使わずに済ませるかに挑戦しているぼくにとってこれは必然でした。
ウディタだと描画の座標やサイズ、色調などを全部数値でピシッと決められるからやりやすいんですよね。
もちろん手間は少しかかりますけど。
勤務中にウディタを使ったのは初めてでした。
ピクチャ表示を使って何とか求められた図形を描画し、スクリーンショットで画像ファイルにして印刷しました。
それを上司に渡すと、まあ思いのほか喜んでくれましてね。
といってもペイントを使いこなせる人ならだれでも簡単にできるものかもかもしれないけど。
でもぼくにとってはやはりウディタでなきゃできなかったことなので。
やっててよかった、ウディタ！
ところで円や直線を描くのに、ピクチャ表示の中の「お手軽ウィンドウ」の隠し機能といわれている「図形表示」を使いました。
＜LINE＞ や ＜SQUARE＞などと入力することで、画像素材がなくても描画できるというありがたい機能です。
この ＜LINE＞で真横や縦に直線を引いたり、 ＜SQUARE＞で長方形を表示させるだけなら、直感的に思い通りの配置ができるんですけども。
今回ぼくは斜めの線を引く必要があり、これが意外と手間取ったというか、訳がわからなかったです。
っていうか今でもよくわかっていないのだけれども、数値をいろいろいじっていたら目的の図形ができたので、原理はよくわかってないけどもうそれでヨシとした、というのが実情です。
なんか難しいんです、斜め線を引くのん。
（直線一本引くのにこんなに悩んでる人いないだろなって思った）
そこで、これを機にちゃんと斜め線の引き方を確認しよう！というのが今回の記事の趣旨なわけです。
ウディタ公式マニュアルのページの説明を見てみると、このようにあります。
＜LINE＞ ： 「座標」から「座標＋生成サイズ」の位置に白い直線を引きます。
白いというのは明らかに誤りというかまあ余計な部分であり、正確にはRGB値の色の直線が引かれます。
で、この図形表示では角度の数値は設定できないんです。
（これができたら簡単なんだけどな）
そこで座標と生成サイズをあらわす4つの数値を入力することでどんな直線を描くかを指定するんです。
でも「座標」から「座標＋生成サイズ」の位置に、っていったらその2点間に引くのかと思うけど、そうじゃないんですね。
いろいろやってみて、なんとなく言語化できてきた気がする・・・。
「座標」の点を「位置」（左上や中央とか）とする位置に置かれた、「生成サイズ」の大きさの長方形の対角線（二つあるうち「座標」を通る方）を引く
というのが適当なのかどうか。
ややこしいのは「位置」を「中央」に設定した時には、まあ当然だけどその座標は直線の端にはならない（中央になる）。
だからその場合は2点間を結ぶなんて言うシンプルな説明は成り立たない。
（ぼくが仕事で描画した時は全部この「中央」を使っていたので余計に混乱したのだと、今わかりました）
そして、「中央」を使わないにしろ、生成サイズにマイナスの値を入れると「位置」の扱いが直感とは逆になります。
例えば「位置」を「左上」にしてある「座標」に生成サイズXもYもマイナスにしたら、「座標」から左上に向かって直線が描かれます。
これって全然左上の座標が指定できてないやん、って思っちゃうんですけどね。
線の一番左上は「座標」で指定したのとは全然違うところにあるから。というか「座標」で指定した位置が直線の右下になってる。
まあマイナスという数値の定義からしたら当然なんでしょうが、とにかく直観とは違うので戸惑いがありました。
そして、そもそも直線における左上とは何か、っていう訳の分からない問題もあります。
例えば画面上に書かれた４５°右上がりの直線があるとして、それに左上なんて、ないですよね。
でもその場合その直線の左下の端が「左上」で指定した位置になる。
そしてその直線の傾きをもっと強く（縦に近く）したら、その直線の左下よりも右上の方が「左上」に近いはずなんだけど、それでも左下が「左上」になっちゃう。
なんだか文字にすると屁理屈で揚げ足取りを書いてる気分になるんですが、とにかく実際やろうとすると全然訳が分からなかったのです。
理系の人なら全然すんなり理解できるのかもしれませんけどね。文系脳はどうしても日本語の意味に引っ張られてしまうのかな。
難しい。
まあ結論としては、機能で斜め線を引くとき、直感的にできなかったら試行錯誤してみてね！ということで。
結局ちゃんと説明できてない気がするけど・・・。
とにかく難しいってことです。
手書きの図形を見せられて、こんなのをパソコンで作ってーって。
円や直線を組み合わせた図形です。ここでお見せできないのが残念なんですが。
そこでぼくはまず素直にペイント系のソフトを使ってみたんです。
でも使い慣れてないしどうもうまくできない。
これはもうしょうがない、やはり、ウディタの出番です。
常日頃ウディタを活用していかにペイントを使わずに済ませるかに挑戦しているぼくにとってこれは必然でした。
ウディタだと描画の座標やサイズ、色調などを全部数値でピシッと決められるからやりやすいんですよね。
もちろん手間は少しかかりますけど。
勤務中にウディタを使ったのは初めてでした。
ピクチャ表示を使って何とか求められた図形を描画し、スクリーンショットで画像ファイルにして印刷しました。
それを上司に渡すと、まあ思いのほか喜んでくれましてね。
といってもペイントを使いこなせる人ならだれでも簡単にできるものかもかもしれないけど。
でもぼくにとってはやはりウディタでなきゃできなかったことなので。
やっててよかった、ウディタ！
ところで円や直線を描くのに、ピクチャ表示の中の「お手軽ウィンドウ」の隠し機能といわれている「図形表示」を使いました。
＜LINE＞ や ＜SQUARE＞などと入力することで、画像素材がなくても描画できるというありがたい機能です。
この ＜LINE＞で真横や縦に直線を引いたり、 ＜SQUARE＞で長方形を表示させるだけなら、直感的に思い通りの配置ができるんですけども。
今回ぼくは斜めの線を引く必要があり、これが意外と手間取ったというか、訳がわからなかったです。
っていうか今でもよくわかっていないのだけれども、数値をいろいろいじっていたら目的の図形ができたので、原理はよくわかってないけどもうそれでヨシとした、というのが実情です。
なんか難しいんです、斜め線を引くのん。
（直線一本引くのにこんなに悩んでる人いないだろなって思った）
そこで、これを機にちゃんと斜め線の引き方を確認しよう！というのが今回の記事の趣旨なわけです。
ウディタ公式マニュアルのページの説明を見てみると、このようにあります。
＜LINE＞ ： 「座標」から「座標＋生成サイズ」の位置に白い直線を引きます。
白いというのは明らかに誤りというかまあ余計な部分であり、正確にはRGB値の色の直線が引かれます。
で、この図形表示では角度の数値は設定できないんです。
（これができたら簡単なんだけどな）
そこで座標と生成サイズをあらわす4つの数値を入力することでどんな直線を描くかを指定するんです。
でも「座標」から「座標＋生成サイズ」の位置に、っていったらその2点間に引くのかと思うけど、そうじゃないんですね。
いろいろやってみて、なんとなく言語化できてきた気がする・・・。
「座標」の点を「位置」（左上や中央とか）とする位置に置かれた、「生成サイズ」の大きさの長方形の対角線（二つあるうち「座標」を通る方）を引く
というのが適当なのかどうか。
ややこしいのは「位置」を「中央」に設定した時には、まあ当然だけどその座標は直線の端にはならない（中央になる）。
だからその場合は2点間を結ぶなんて言うシンプルな説明は成り立たない。
（ぼくが仕事で描画した時は全部この「中央」を使っていたので余計に混乱したのだと、今わかりました）
そして、「中央」を使わないにしろ、生成サイズにマイナスの値を入れると「位置」の扱いが直感とは逆になります。
例えば「位置」を「左上」にしてある「座標」に生成サイズXもYもマイナスにしたら、「座標」から左上に向かって直線が描かれます。
これって全然左上の座標が指定できてないやん、って思っちゃうんですけどね。
線の一番左上は「座標」で指定したのとは全然違うところにあるから。というか「座標」で指定した位置が直線の右下になってる。
まあマイナスという数値の定義からしたら当然なんでしょうが、とにかく直観とは違うので戸惑いがありました。
そして、そもそも直線における左上とは何か、っていう訳の分からない問題もあります。
例えば画面上に書かれた４５°右上がりの直線があるとして、それに左上なんて、ないですよね。
でもその場合その直線の左下の端が「左上」で指定した位置になる。
そしてその直線の傾きをもっと強く（縦に近く）したら、その直線の左下よりも右上の方が「左上」に近いはずなんだけど、それでも左下が「左上」になっちゃう。
なんだか文字にすると屁理屈で揚げ足取りを書いてる気分になるんですが、とにかく実際やろうとすると全然訳が分からなかったのです。
理系の人なら全然すんなり理解できるのかもしれませんけどね。文系脳はどうしても日本語の意味に引っ張られてしまうのかな。
難しい。
まあ結論としては、
結局ちゃんと説明できてない気がするけど・・・。
とにかく難しいってことです。
2021年12月14日
ねこさんぽをプレイしました
NANさんがツクールで作ったゲーム、ねこさんぽをプレイしました。
町を歩いて猫たちに出会い、会話したり、どこにいるのか探しだす、短時間でできる作品です。
小さい子供に楽しんでもらえる作品にしたかったということですが。
ぼくはゲームにはついつい戦略やストーリーを求めてしまいがちなので、そういった刺激が少ないこの作品には新鮮さを感じました。
ゲームに初めて出会う子供にはきっと楽しんでもらえる作品だと思います。
何より、親としては安心して遊ばせられるというのが魅力です。
依存症の心配はない。他者とのやり取りもない。課金もない。
「キャラが自分の思い通りに歩いた！」とか、「新しいマップが目の前に広がった！」とか、本来ゲームはそれだけで十分わくわくするはずなんですよね。
ましてゲーム体験の少ない子供ならなおさら。
変にゲーム慣れしてしまって「そんなんじゃものたりなーい！！」ってなってしまうけど、それって贅沢というかすごく恵まれて幸せなことなのだと思いだすことができました。
別にレトロゲームを礼賛するつもりはないけれども、これから初めてゲームに触れる子供は、このねこさんぽのような素朴な作品から一歩一歩ゲーム体験を積み重ねることができたなら、何度でも新鮮な気持ちで感動できるかもしれません。
現在フリゲ２０２１という投票イベントをやっているので、そこでこのねこさんぽも投票しておこうと思います。
町を歩いて猫たちに出会い、会話したり、どこにいるのか探しだす、短時間でできる作品です。
小さい子供に楽しんでもらえる作品にしたかったということですが。
ぼくはゲームにはついつい戦略やストーリーを求めてしまいがちなので、そういった刺激が少ないこの作品には新鮮さを感じました。
ゲームに初めて出会う子供にはきっと楽しんでもらえる作品だと思います。
何より、親としては安心して遊ばせられるというのが魅力です。
依存症の心配はない。他者とのやり取りもない。課金もない。
「キャラが自分の思い通りに歩いた！」とか、「新しいマップが目の前に広がった！」とか、本来ゲームはそれだけで十分わくわくするはずなんですよね。
ましてゲーム体験の少ない子供ならなおさら。
変にゲーム慣れしてしまって「そんなんじゃものたりなーい！！」ってなってしまうけど、それって贅沢というかすごく恵まれて幸せなことなのだと思いだすことができました。
別にレトロゲームを礼賛するつもりはないけれども、これから初めてゲームに触れる子供は、このねこさんぽのような素朴な作品から一歩一歩ゲーム体験を積み重ねることができたなら、何度でも新鮮な気持ちで感動できるかもしれません。
現在フリゲ２０２１という投票イベントをやっているので、そこでこのねこさんぽも投票しておこうと思います。
2021年11月25日
さよなら、ネオ繚乱記
ネオ繚乱記を知っていますか？
知りませんよね。
ぼくが初めてウディタで作ったゲームです。
今日ひさびさにブログの過去記事を整理していたんですけれども。
なんと、ネオ繚乱記のダウンロードサイトがリンク切れになっていることが判明！
おっかしいなあ。フリーソフトの老舗Vectorに登録していたのになあ。
Ｖector自体がサービス停止したわけでもないのに。
長年ほったらかしにしていたら消されちゃうのかな。
そりゃ向こうも営利企業だもんね。慈善事業じゃないもんね。仕方ないか。
でも残念な反面、ちょっとほっとしたというか・・・。あまりにも黒歴史な作品なので。
というわけで、入手不可です。やれやれ・・・。
知りませんよね。
ぼくが初めてウディタで作ったゲームです。
今日ひさびさにブログの過去記事を整理していたんですけれども。
なんと、ネオ繚乱記のダウンロードサイトがリンク切れになっていることが判明！
おっかしいなあ。フリーソフトの老舗Vectorに登録していたのになあ。
Ｖector自体がサービス停止したわけでもないのに。
長年ほったらかしにしていたら消されちゃうのかな。
そりゃ向こうも営利企業だもんね。慈善事業じゃないもんね。仕方ないか。
でも残念な反面、ちょっとほっとしたというか・・・。あまりにも黒歴史な作品なので。
というわけで、入手不可です。やれやれ・・・。
2021年11月07日
驚き！パパイヤの種で、口の中が甘くなる！
フィリピン産のパパイヤがスーパーで売っていたので、買って、切って、実を食べました。
残ったのが種。
この種はピリ辛でスパイスの代わりになると教えてもらったことがあります。
試しに果肉から取り出した種をかみ砕くと、確かに辛い。
唐辛子のような、胡椒のような味がします。
けれどもそれはすぐに消える、後を引かない辛さです。
ところが。それはそれとして。
（ここからぼくのやったことと、体験したことを書きます。その理論や科学的意味はなにもわかりません。）
パパイヤの種を実から取り出したものを、5分くらい水につけます。
そして種の周りについているゼリー状の皮を取り除きます。
（数十粒を手のひらでもんでとりました。）
すると黒いとげとげのような形になります。
それを口に入れてかみ砕きました。
すると黒い皮はくしゃくしゃしてコーヒーかすのような状態になりますが、その中にかすかに油分なのか、何か種の味を感じます。
不思議なことに辛みは全くありません。
辛み以外の強い味もほとんどありません。ただ「種のエッセンスを味わっているなー」と感じるほのかな風味があるのみです。
しかし、驚きはここから！
その後に水を飲むと、その味が異様な甘さなのです。
普通の水なのに、明らかに強い甘みを感じます。
水を飲むまでの口の中は甘かったわけではないのです。
飲んだ水が甘いのです。
すごく驚いて、そして水があまりに美味しいので、コップ２～３杯飲みました。
すると甘い味はしなくなってしまいました。
洗い流されてしまったのでしょうか。
これは一体どういうことなのでしょう？
ネットで「パパイヤ 口が甘く」とか検索しても全然出てこないのでここに書きました。
これを読んだみなさん、もしもパパイヤを食べる機会があればぜひ試してみてください。
残ったのが種。
この種はピリ辛でスパイスの代わりになると教えてもらったことがあります。
試しに果肉から取り出した種をかみ砕くと、確かに辛い。
唐辛子のような、胡椒のような味がします。
けれどもそれはすぐに消える、後を引かない辛さです。
ところが。それはそれとして。
（ここからぼくのやったことと、体験したことを書きます。その理論や科学的意味はなにもわかりません。）
パパイヤの種を実から取り出したものを、5分くらい水につけます。
そして種の周りについているゼリー状の皮を取り除きます。
（数十粒を手のひらでもんでとりました。）
すると黒いとげとげのような形になります。
それを口に入れてかみ砕きました。
すると黒い皮はくしゃくしゃしてコーヒーかすのような状態になりますが、その中にかすかに油分なのか、何か種の味を感じます。
不思議なことに辛みは全くありません。
辛み以外の強い味もほとんどありません。ただ「種のエッセンスを味わっているなー」と感じるほのかな風味があるのみです。
しかし、驚きはここから！
その後に水を飲むと、その味が異様な甘さなのです。
普通の水なのに、明らかに強い甘みを感じます。
水を飲むまでの口の中は甘かったわけではないのです。
飲んだ水が甘いのです。
すごく驚いて、そして水があまりに美味しいので、コップ２～３杯飲みました。
すると甘い味はしなくなってしまいました。
洗い流されてしまったのでしょうか。
これは一体どういうことなのでしょう？
ネットで「パパイヤ 口が甘く」とか検索しても全然出てこないのでここに書きました。
これを読んだみなさん、もしもパパイヤを食べる機会があればぜひ試してみてください。
2021年08月03日
単細胞的思考（上野 霄里：著）という本の前半の紹介と感想
本の感想はブログに書くつもりはなかったんだけど。
この本だけは特別。すごいから。
内容もすごいけど知名度の低さがまたものすごい。
再版されたりしているわりに、作者名を検索してもWikipediaさえ作られていない。
今どきそんな著者がいたのか。
ましてや本書の内容にいたってはネット上にはほとんど書かれていない。
かろうじてアマゾンレビューがあるくらいだけど、そこにも部分引用や絶賛する感想があるだけで、やっぱり本の内容はほとんど書かれていない。
それならぼくが書きましょうと。
そういうわけです。
上野霄里さんという方は昭和６年生まれの文筆家。
その方が昭和４４（１９６９）年に書いたのが本書（おそらく代表作）単細胞的思考です。
内容はエッセイと言えばいいのかな。
作者の信念というか主張を、様々な比喩などを用いながら繰り返し表現しています。
何を言っているのかとても分かりにくい。
それもそのはず、作者は他人に理解されようとがんばることは恥ずかしいと考えているのです。
自分の心からの叫びだけに価値を置け、他人にどう思われるかを気にするな、既成の体系に価値を置くな。
そう主張します。
科学の発達も、経済の発展も、歴史の進歩も、一切意味がないというのです。
あらゆる組織や集団との関係をよくしようと励む行為は悪いことだと、そういうのです。
その主張から当然の帰結として、作者はものすごく尊大で、大衆を軽蔑しきっています。
とても面白いのですがとにかく難解だし部分部分には興味がわかないしで読み進めるのが苦痛で、途中で投げ出しました。なので半分しか読んでません。
それにしてもこれはむちゃくちゃ斬新！
こんな本が存在すること自体がもうすごいと思いました。
そしてこの本が有名でない理由もよくわかりました。
この本の内容に共鳴する人も多くいることだと思います。
けれどもこの内容に共鳴すればするほど、世間に向かって「こんな本があるよ！」って働きかけることには意味がないということになります。
最近ぼくはコロナ関連で再生産数という概念を知りました。
感染症にかかった人が何人にうつすかっていう数字で、１以上なら感染者が増えていくんですよね。
この本に触れた人が誰かに紹介する再生産数は１以下だと思う。
そうでなきゃネットが発達してるのにこんな個性的な書物がここまで知られてないなんてありえないと思う。
そして本書の知名度の低さについては時代の影響も強く感じました。
ネットが一般化した１９９５年以降の出版ならマニアには知られる本となり、ネタにもされ、伝説にもなったと思う。
でもそれよりはるかに前に埋もれてしまったトピックスが、時代をさかのぼってネット上に掘り起こされていくのはなかなか難しいのだろうと想像しました。
ひょっとしたらおじいちゃん界隈では有名な本なのかもしれませんね。
ネット上で本書に触れている数少ない方もほとんどが年配の方ではないかとお見受けしました。その方々がいなくなった時、本書は誰からも忘れられていくのかもしれません。
さて。ぼく個人のこの本の内容に対する考えです。
自分の心が大事だという点にはもろ手を挙げて賛成できます。
ただ、その自分とは何なのか。
ぼくは自分という概念に自分の生まれた時代、生きる社会、周囲の環境ということを織り込むことに抵抗はありません。
自分をよりよく生きるということが、社会をよりよく生きること（経済的安定を目指すとか）とほぼイコールであることを恥ずかしいとは思いません。
自分を生きるということは、もちろん自分の心に忠実に生きることでもあるでしょう。
でもそれだけではなくて、時代を生きる、社会を生きる、役割を生きる、立場を生きる、それらも全部自分を生きるということだと思います。
ぼくはそれらを全部やりたいし、というかそれらを放棄するという選択は全くあり得ないのですが、そのことを窮屈とも思っていないのです。
結局は好みの問題じゃないかな。
作者さんは熱烈に主張しているのですが、ぼくの感想としては「そう思いたいのならそう思っていればいいんじゃないでしょうか」というものです。
すごく刺激を受けて興味を持ったのは確かですが共感はしなかった。
でも共感はしないとはっきり言いきれるのはぼくの今までの数十年の人生経験があるからで、もしも若い時、社会とのかかわり方を確立する前に本書に出会っていたらきっと影響を受けていたと思います。
何も知らない時に断言されて煽られたらフラフラしちゃうよ。
若い時に本書に出会わなくてよかったとしみじみ思います。
でももし若い時に出会っていたら、その後今頃の歳になって、振り返って出会ってよかったと思っているかもしれないと思います。
それだけ影響力のある本です。こわいな。
（なお、ぼくは前半しか読んでいないので後半に全然違うことが書いてあったらごめんなさい。）
興味がある方は探して読んでください。
2021年07月22日
バリバリダアが面白い。そして対戦という形式の有用性について。
先日から始まった今年のウディコン。
今までに７作品ぐらいプレイしましたが、その中で一番楽しませてもらっているのがDMDAEMONさんのバリバリダアです。
ルールがわかりやすいです。
やることが簡単なので何も考えずにバリバリ楽しめます。
キャラ設定や世界観が個性的で先を見たいと思わせます。
年齢を重ねたためか、難しいゲームや不親切なゲームに我慢してまで付き合う忍耐力が下がってきていると感じるのですが、そんなぼくにバリバリダアはばりばり刺さりました。
本当、こんなゲームがしたかったんだよ。
そしてぼくがゲーム製作者としてすごくすごく勉強になった点があります。
それは、ひたすらバリバリし続けるだけの単調作業を続けるモチベーションを高めるための対戦システム。
こうすればよかったのか、と、目からうろこでした。
これについて説明する前に、ぼくが自分の過去作品でどんな課題を抱えていたかを詳しく書かせてください。
それは同じウディコン出品作、ぼら猫パズルでのこと。
ぼくはぼら猫パズルのパズルシステムにはすごく自信がありました。
すごく楽しかったから。
当時のブログから引用してみる。
面白すぎるゲームシステムが完成してしまいました！
（中略）
このゲームの残念なところは、あまりに面白すぎてついついプレイをし続けてしまい制作がちっとも進まないことです。
何このハイテンション。
で、ともかく面白い（自称）パズルができたのですが、そのパズルをプレイヤーに何度か（せめて面白さがわかってもらえるまででも）やり続けてもらうにはどうするかが課題となったわけです。一回のパズルはすぐ終わる。それを繰り返したくなる仕組みをどう作るか。
だって何回やっても全く同じゲーム作業ですもんね。同じことを何度もしても飽きさせない方法とは・・・。
・・・ぼくには思いつきませんでした。
そこで苦肉の策としてパズルを数回クリアするごとにシナリオを表示し、話の先を読みたければ何度もパズルをクリアしないといけないようにしました。
これはどう考えてもよくない方法です。
パズルと文章を読み進めるということは、うまく嚙み合っていない。
文章を読みたいなら、ワンクリックで読めるのが理想で、少しでも早く読みたい場合にはパズルは障害でしかないです。
でもぼくにはあれが限界でした。
プレイヤーがパズル完了後に残せるのは本質的にはスコアのみです。点数の大小が得られるのみです。
その点数の大小を得ることを楽しいと思わせる方法ははたしてあったのか。
それが、あったのです。
すなわちバリバリダアで採用されている対戦システムを導入すればよかったのです。
ぷよぷよだったか何か、市販のゲームでも敵と対戦する仕組みのゲームをしたことはありました。
また同じウディコン作品でいうと秋月ねこ柳さんのすやりす絵巻にも敵という概念がありました。
でもぶっちゃけプレイヤーは対戦相手なんて気にしてませんよね。
だって自分のプレイで必死だから、欄外で「敵」が何をしていようが、自分は自分のすべきことに集中するのみ！ですもん。
でもバリバリダアはその点すごい。
敵は、いるのだけれど、システム的な意味では目標スコアを提示するためだけに存在しているのです。
仕組みとしては「○○点を越えよう、そうしたらこのステージクリア！」と、文章表示しているのと同じです。
たったそれだけです。
それなのに、それなのに。
そこに敵キャラがいて、個性的なグラフィック、特徴的なキャラづけ（設定）、会話文といった演出によって、「この点数をクリアして敵を倒す！」というモチベーションが強烈に湧くのです。
ああ、ボラ猫も次々に現れる強敵とスコアを競わせればよかったのです。（それはもはやボランティアする猫ではなくなっていますが）
バリバリダアでぼくはそのことにはっきりと気付きました。
なお、バリバリダアは難易度設定もぼくにとっては絶妙で、それも楽しめた一つの要因でした。
何度も練習して熟達して、そしてすごい集中できて、なおかつ運にも恵まれたときに、ぎりぎりやっと最後の敵を倒せる、という難易度で、それは本当に楽しい体験でした。
作者さんは集団製作チームだそうですが、素直にすごいと思います。
そして単調作業にモチベーションをもたらす方法を教えてくれて感謝！
今度単調作業のゲームを作る時には絶対に対戦相手を出す！と心中深く決めました。
今までに７作品ぐらいプレイしましたが、その中で一番楽しませてもらっているのがDMDAEMONさんのバリバリダアです。
ルールがわかりやすいです。
やることが簡単なので何も考えずにバリバリ楽しめます。
キャラ設定や世界観が個性的で先を見たいと思わせます。
年齢を重ねたためか、難しいゲームや不親切なゲームに我慢してまで付き合う忍耐力が下がってきていると感じるのですが、そんなぼくにバリバリダアはばりばり刺さりました。
本当、こんなゲームがしたかったんだよ。
そしてぼくがゲーム製作者としてすごくすごく勉強になった点があります。
それは、ひたすらバリバリし続けるだけの単調作業を続けるモチベーションを高めるための対戦システム。
こうすればよかったのか、と、目からうろこでした。
これについて説明する前に、ぼくが自分の過去作品でどんな課題を抱えていたかを詳しく書かせてください。
それは同じウディコン出品作、ぼら猫パズルでのこと。
ぼくはぼら猫パズルのパズルシステムにはすごく自信がありました。
すごく楽しかったから。
当時のブログから引用してみる。
面白すぎるゲームシステムが完成してしまいました！
（中略）
このゲームの残念なところは、あまりに面白すぎてついついプレイをし続けてしまい制作がちっとも進まないことです。
何このハイテンション。
で、ともかく面白い（自称）パズルができたのですが、そのパズルをプレイヤーに何度か（せめて面白さがわかってもらえるまででも）やり続けてもらうにはどうするかが課題となったわけです。一回のパズルはすぐ終わる。それを繰り返したくなる仕組みをどう作るか。
だって何回やっても全く同じゲーム作業ですもんね。同じことを何度もしても飽きさせない方法とは・・・。
・・・ぼくには思いつきませんでした。
そこで苦肉の策としてパズルを数回クリアするごとにシナリオを表示し、話の先を読みたければ何度もパズルをクリアしないといけないようにしました。
これはどう考えてもよくない方法です。
パズルと文章を読み進めるということは、うまく嚙み合っていない。
文章を読みたいなら、ワンクリックで読めるのが理想で、少しでも早く読みたい場合にはパズルは障害でしかないです。
でもぼくにはあれが限界でした。
プレイヤーがパズル完了後に残せるのは本質的にはスコアのみです。点数の大小が得られるのみです。
その点数の大小を得ることを楽しいと思わせる方法ははたしてあったのか。
それが、あったのです。
すなわちバリバリダアで採用されている対戦システムを導入すればよかったのです。
ぷよぷよだったか何か、市販のゲームでも敵と対戦する仕組みのゲームをしたことはありました。
また同じウディコン作品でいうと秋月ねこ柳さんのすやりす絵巻にも敵という概念がありました。
でもぶっちゃけプレイヤーは対戦相手なんて気にしてませんよね。
だって自分のプレイで必死だから、欄外で「敵」が何をしていようが、自分は自分のすべきことに集中するのみ！ですもん。
でもバリバリダアはその点すごい。
敵は、いるのだけれど、システム的な意味では目標スコアを提示するためだけに存在しているのです。
仕組みとしては「○○点を越えよう、そうしたらこのステージクリア！」と、文章表示しているのと同じです。
たったそれだけです。
それなのに、それなのに。
そこに敵キャラがいて、個性的なグラフィック、特徴的なキャラづけ（設定）、会話文といった演出によって、「この点数をクリアして敵を倒す！」というモチベーションが強烈に湧くのです。
ああ、ボラ猫も次々に現れる強敵とスコアを競わせればよかったのです。（それはもはやボランティアする猫ではなくなっていますが）
バリバリダアでぼくはそのことにはっきりと気付きました。
なお、バリバリダアは難易度設定もぼくにとっては絶妙で、それも楽しめた一つの要因でした。
何度も練習して熟達して、そしてすごい集中できて、なおかつ運にも恵まれたときに、ぎりぎりやっと最後の敵を倒せる、という難易度で、それは本当に楽しい体験でした。
作者さんは集団製作チームだそうですが、素直にすごいと思います。
そして単調作業にモチベーションをもたらす方法を教えてくれて感謝！
今度単調作業のゲームを作る時には絶対に対戦相手を出す！と心中深く決めました。
2021年06月21日
扉は君の鍵で開く 離心円 が公開されました
昨年のウディコンに出された扉は君の鍵で開くですが、その解答編あるいは解説付きのバージョンが作られることになり、前作は同心円、今作は離心円という副題がつくこととなりました。
そしてその離心円が今日公開されました！
ほぼ一年かけて作ってくれたNANさんお疲れさまでした。
前作を楽しめた人なら絶対楽しめると思います。
そして作者のNANさんの成し遂げたことにびっくりするんじゃないかな。（ぼくはした）
前作をが公開された時にもう、全ての設定や裏事情はNANさんの頭の中では完成していたんですね。
プレイした人はその表面しか見えていなかったけど。
主人公のちょっとした言動の裏にもちゃんと深い理由があったんだ。一年前から。
あーすごい。
こんなゲーム見たことがないです。こんな公開のされ方も。
まあゲームじゃないといえるかもしれないけど、でもやっぱりゲームです。
この作品に関わらせてもらえたことを光栄に思います。
同心円を未プレイの方は、まずはそっちからした方が推理や試行錯誤を楽しめるかもしれません。
そしてその離心円が今日公開されました！
ほぼ一年かけて作ってくれたNANさんお疲れさまでした。
前作を楽しめた人なら絶対楽しめると思います。
そして作者のNANさんの成し遂げたことにびっくりするんじゃないかな。（ぼくはした）
前作をが公開された時にもう、全ての設定や裏事情はNANさんの頭の中では完成していたんですね。
プレイした人はその表面しか見えていなかったけど。
主人公のちょっとした言動の裏にもちゃんと深い理由があったんだ。一年前から。
あーすごい。
こんなゲーム見たことがないです。こんな公開のされ方も。
まあゲームじゃないといえるかもしれないけど、でもやっぱりゲームです。
この作品に関わらせてもらえたことを光栄に思います。
同心円を未プレイの方は、まずはそっちからした方が推理や試行錯誤を楽しめるかもしれません。
2021年06月16日
オーラをまとう（主人公演出コモン）に需要が・・・！
7年位前に公開したオーラをまとう主人公演出コモンについてお問い合わせをいただき、改造の対応をさせてもらいました。
あのコモンは鏡コモンに比べたら反響は皆無だったけど、絶対需要があるとおもってたんだー。本当うれしい！
ピクチャ表示じゃないとできないこともあるし、主人公の瞬間瞬間の歩行グラ画像を表示させたいってことってきっとあるもんね。
今回はオーラをつけるキャラを主人公からマップイベントに。
素材の形式を8方向から４方向に変換。
という２点の改造をしました。
最新のウディタ、変数操作+でマップイベントの情報をいろいろ取得できるようになってる気がする・・・。
前からできたかな？たしかできなかったんじゃなかったかな。
いつも本当にありがとうございます煙狼さん。
鏡コモンだとソフトニシンさんが作ってくれたいろんな素材や規格に対応したのがもう既にあるんだけど。
主人公演出コモンは鏡像じゃないのでそれは使えないから、新たに画像のパターン数を求める数値「鏡像変換定数」（鏡像じゃないけど）を計算し直しました。
かなり難しかったけど、何とかなりました。
あらためて鏡コモンの中身をじっくり見てみて、この仕組みを思いついた自分って天才！とつくづく感心。
コモンのご相談はメールで受け付けます。時間があれば対応します。
余談だけどそのやり取りの中で気づいたのですが、gmailは「.common」形式のファイルをウイルスの可能性があるとして受け付けてくれないんですね。
怪しくないのにー！
アップローダーに上げるとかで対応するしかないようです。
あのコモンは鏡コモンに比べたら反響は皆無だったけど、絶対需要があるとおもってたんだー。本当うれしい！
ピクチャ表示じゃないとできないこともあるし、主人公の瞬間瞬間の歩行グラ画像を表示させたいってことってきっとあるもんね。
今回はオーラをつけるキャラを主人公からマップイベントに。
素材の形式を8方向から４方向に変換。
という２点の改造をしました。
最新のウディタ、変数操作+でマップイベントの情報をいろいろ取得できるようになってる気がする・・・。
前からできたかな？たしかできなかったんじゃなかったかな。
いつも本当にありがとうございます煙狼さん。
鏡コモンだとソフトニシンさんが作ってくれたいろんな素材や規格に対応したのがもう既にあるんだけど。
主人公演出コモンは鏡像じゃないのでそれは使えないから、新たに画像のパターン数を求める数値「鏡像変換定数」（鏡像じゃないけど）を計算し直しました。
かなり難しかったけど、何とかなりました。
あらためて鏡コモンの中身をじっくり見てみて、この仕組みを思いついた自分って天才！とつくづく感心。
コモンのご相談はメールで受け付けます。時間があれば対応します。
余談だけどそのやり取りの中で気づいたのですが、gmailは「.common」形式のファイルをウイルスの可能性があるとして受け付けてくれないんですね。
怪しくないのにー！
アップローダーに上げるとかで対応するしかないようです。
2021年06月08日
暗黙のルール、こわっ！って、政治家の炎上を見て思いました
日本の刑法では１３歳未満の性行為が禁止されているそうです。
それについて立憲民主党が「合意のある性行為の禁止年齢引き上げ」を検討していた中で、本多平直衆議院議員が「５０歳近くの自分が１４歳の子と性交したら、たとえ同意があっても捕まることになる。それはおかしい」と発言して話題となり、党から厳重注意を受けたそうです。
議員の発言がネットからバッシングされたことをを受け、党が「これは党の見解でない、本田個人の考えで、問題だ」との姿勢を示したのでしょう。
すごーく違和感を感じました。
本田議員の発言を責めちゃいけないとぼくは思います。
国会議員が自分の意見を表明して個人攻撃され撤回・謝罪させられるなんて、だめです。
議論をするための議員でしょう。
多様な国民を代表する議員でしょう。
どんな少数派の主張をする議員だって、議論を実りあるものにするためには必要です。
暗黙のルールがもう決まっているのなら、議員も議会もいらないじゃないですか。
１３歳以上でも性行為がダメというルールはいつの間にできていたのでしょうか。
ぼくは性行為の禁止年齢引き上げ自体には賛成です。
けれどもそう思わない人は非難されて当然という風潮は、言論を委縮させるし、勘弁してほしいなと思ってます。
…と書いてみましたが、ぼくの本音は「空気読めない人は非難されて当然という社会なんて、空気読めないぼくには困るー！」ということなのです。ほんとに。本多議員の災難が人ごとに思えない…。
それについて立憲民主党が「合意のある性行為の禁止年齢引き上げ」を検討していた中で、本多平直衆議院議員が「５０歳近くの自分が１４歳の子と性交したら、たとえ同意があっても捕まることになる。それはおかしい」と発言して話題となり、党から厳重注意を受けたそうです。
議員の発言がネットからバッシングされたことをを受け、党が「これは党の見解でない、本田個人の考えで、問題だ」との姿勢を示したのでしょう。
すごーく違和感を感じました。
本田議員の発言を責めちゃいけないとぼくは思います。
国会議員が自分の意見を表明して個人攻撃され撤回・謝罪させられるなんて、だめです。
議論をするための議員でしょう。
多様な国民を代表する議員でしょう。
どんな少数派の主張をする議員だって、議論を実りあるものにするためには必要です。
暗黙のルールがもう決まっているのなら、議員も議会もいらないじゃないですか。
１３歳以上でも性行為がダメというルールはいつの間にできていたのでしょうか。
ぼくは性行為の禁止年齢引き上げ自体には賛成です。
けれどもそう思わない人は非難されて当然という風潮は、言論を委縮させるし、勘弁してほしいなと思ってます。
…と書いてみましたが、ぼくの本音は「空気読めない人は非難されて当然という社会なんて、空気読めないぼくには困るー！」ということなのです。ほんとに。本多議員の災難が人ごとに思えない…。
2021年05月30日
＜Excel＞日付を変えて一枚ずつ印刷する方法
仕事で表計算ソフトのExcel2013を使っているのですが、今日はぼくが今まで毎月繰り返してきた作業の効率化に大成功しました。その記録を残します。
ある一定形式の書類を複数枚、日付欄だけ変えて一枚ずつ印刷する方法です。
毎日一枚ずつ使う書類ってないですか？「今日の報告書」とか。日報っていうのか。
そこには必ず日付欄がありますよね。
ぼくは今まで日付は空欄にして手書きで記入していました。
一か月分３０枚を書くのに、毎月5分以上かかってたかな。よく間違えたりするし。
それを簡単にできるようになりました。
最初に作るのは少しだけ手間ですが、一度作ったら毎月作業がとても簡単になります。
一日分の書類が１ページに収まっているという前提で説明しますね。
まず日付欄にしたいセルを選択して、右クリックします。
「セルの書式設定」を選びます。
「日付」を選んで種類の中から好きな表示形式を選びます。
（曜日も入れたい時などは選択肢の中にはないので「ユーザー定義」を選んで設定します。詳しくは検索！）
これで、そのセルに5/30と入力したら自動で5月30日と表示されるようになりました。
そしてそのページ全体をコピーします。
それをその下、2ページ目に貼り付けます。
行や列の幅が初期値のまま触ってないならそのまま貼るだけでいいです。
でも列も幅もいじっている場合はちょっとした工夫がいります。
コピーするときに行番号欄を一ページ分選択します。
そして貼り付けるときに「形式を選択して貼り付け」を選び「元の列幅を保持」にします。
すると行や列の幅や高さを同じにしたまま貼り付けることができます。
これで2ページ目ができました。
でも日付欄は１ページ目と同じです。
なのでこれを自動で２日目を表示するように変えます。
日付欄を選択します。
小文字で「＝（イコール）」を入力し、続いて「１ページ目にある日付欄」をクリックし、続いて小文字で「+1」を入力し、Enterを押します。
そうすると自動で１ページ目の日付の次の日を表示します。
ここまでできたら今度は2ページ目をコピーして下に貼りつけます。
成功していたら3ページ目の日付欄は3日目になっているはずです。
後は必要なだけ下に貼り付けていきます。
一か月分などたくさんつなげるときは、貼り付けの終わった複数枚をコピーして貼れば早いです。
（１ページ貼った後は2ページ、次は４ページ、8ページというように）
ただその時ワークシートの一番上にある１ページ目はコピーしないようにしてください。
そこだけは日付欄の値が固定されているので。+1にしたページをコピーしてください。
毎月1回、一か月分印刷するとしたら、31ページ目まで作ってください。
１ページ目の日付欄に１日と入力しただけで、全ページ印刷することで３１日分を１クリックで印刷できます。
印刷するときに何ページ目から何ページ目までするのか指定すれば、必要な日付の範囲だけ印刷ができます。
今月は何日まである月かなんて考えなくてもよくなります。
1ページ目を1日にして31枚印刷すれば、その月が30日しかない場合には、最後の一枚は自動で翌月1日になります。
入力時に年（２０２１とか）まで入れていれば、うるう年さえ気にしないでよくなります。
毎回一番上の日付欄だけは入力してくださいね。それ以下は全自動です。
これと同じようなやり方で、書類一枚づつ個別の通し番号なんかも簡単に印刷できるようになると思います。
作業をとても効率化できるこの方法、もっと早く気づきたかったー。
日付を毎月31枚手書きで記入している人はぜひともやってみてください！
ある一定形式の書類を複数枚、日付欄だけ変えて一枚ずつ印刷する方法です。
毎日一枚ずつ使う書類ってないですか？「今日の報告書」とか。日報っていうのか。
そこには必ず日付欄がありますよね。
ぼくは今まで日付は空欄にして手書きで記入していました。
一か月分３０枚を書くのに、毎月5分以上かかってたかな。よく間違えたりするし。
それを簡単にできるようになりました。
最初に作るのは少しだけ手間ですが、一度作ったら毎月作業がとても簡単になります。
一日分の書類が１ページに収まっているという前提で説明しますね。
まず日付欄にしたいセルを選択して、右クリックします。
「セルの書式設定」を選びます。
「日付」を選んで種類の中から好きな表示形式を選びます。
（曜日も入れたい時などは選択肢の中にはないので「ユーザー定義」を選んで設定します。詳しくは検索！）
これで、そのセルに5/30と入力したら自動で5月30日と表示されるようになりました。
そしてそのページ全体をコピーします。
それをその下、2ページ目に貼り付けます。
行や列の幅が初期値のまま触ってないならそのまま貼るだけでいいです。
でも列も幅もいじっている場合はちょっとした工夫がいります。
コピーするときに行番号欄を一ページ分選択します。
そして貼り付けるときに「形式を選択して貼り付け」を選び「元の列幅を保持」にします。
すると行や列の幅や高さを同じにしたまま貼り付けることができます。
これで2ページ目ができました。
でも日付欄は１ページ目と同じです。
なのでこれを自動で２日目を表示するように変えます。
日付欄を選択します。
小文字で「＝（イコール）」を入力し、続いて「１ページ目にある日付欄」をクリックし、続いて小文字で「+1」を入力し、Enterを押します。
そうすると自動で１ページ目の日付の次の日を表示します。
ここまでできたら今度は2ページ目をコピーして下に貼りつけます。
成功していたら3ページ目の日付欄は3日目になっているはずです。
後は必要なだけ下に貼り付けていきます。
一か月分などたくさんつなげるときは、貼り付けの終わった複数枚をコピーして貼れば早いです。
（１ページ貼った後は2ページ、次は４ページ、8ページというように）
ただその時ワークシートの一番上にある１ページ目はコピーしないようにしてください。
そこだけは日付欄の値が固定されているので。+1にしたページをコピーしてください。
毎月1回、一か月分印刷するとしたら、31ページ目まで作ってください。
１ページ目の日付欄に１日と入力しただけで、全ページ印刷することで３１日分を１クリックで印刷できます。
印刷するときに何ページ目から何ページ目までするのか指定すれば、必要な日付の範囲だけ印刷ができます。
今月は何日まである月かなんて考えなくてもよくなります。
1ページ目を1日にして31枚印刷すれば、その月が30日しかない場合には、最後の一枚は自動で翌月1日になります。
入力時に年（２０２１とか）まで入れていれば、うるう年さえ気にしないでよくなります。
毎回一番上の日付欄だけは入力してくださいね。それ以下は全自動です。
これと同じようなやり方で、書類一枚づつ個別の通し番号なんかも簡単に印刷できるようになると思います。
作業をとても効率化できるこの方法、もっと早く気づきたかったー。
日付を毎月31枚手書きで記入している人はぜひともやってみてください！
2021年03月06日
カステラを二等分するシステム
ウディタでカステラを二等分するゲームのシステムを作りました。
画面上に表示されたカステラをちょうど等分する位置でクリックできたら成功、というものです。
ゴボリーンさんという方の＜サークル活動＞というゲームが無料公開されているのですが、それに触発されたのが製作のきっかけです。
サークル活動は円を作るゲームです。
とても楽しくてぼくはずいぶん遊ばせてもらいました。
これをもっと劣化させて、長方形を二等分するだけでも楽しいんじゃないか、という発想を形にしたのがこのシステムです。
はたして楽しいのかな？
楽しくないのかな？
まあやってみないとわかんないということで、ウディタで作ってみました。
マウスを使ったゲームを作るのは初めてで、いろいろ手探りでちょっと大変でした。
でも何とか形にはなりました。
で、やってみて、楽しかった・・・のかな？
まあ、・・・それなりに楽しそうです。
楽しいような気もします。
ゲームの面白さって何でしょうね。
ぼくはゲームシステム以外はあまりうまく作れませんが、その一方で、ぼくがゲームに求める楽しさは大半が物語性や演出によるところが大きいと思います。
でもやはりコアになるゲームシステムの面白さって必要ですもんね。
まあそれでもゲームシステムで多少でも面白いかもと思えたなら、後は演出次第で大化けするのかもしれないなあ。
だれかゲームデザインしてくれませんかー？
二人の弟のためにカットするお兄ちゃんの話とかね。
画面上に表示されたカステラをちょうど等分する位置でクリックできたら成功、というものです。
ゴボリーンさんという方の＜サークル活動＞というゲームが無料公開されているのですが、それに触発されたのが製作のきっかけです。
サークル活動は円を作るゲームです。
とても楽しくてぼくはずいぶん遊ばせてもらいました。
これをもっと劣化させて、長方形を二等分するだけでも楽しいんじゃないか、という発想を形にしたのがこのシステムです。
はたして楽しいのかな？
楽しくないのかな？
まあやってみないとわかんないということで、ウディタで作ってみました。
マウスを使ったゲームを作るのは初めてで、いろいろ手探りでちょっと大変でした。
でも何とか形にはなりました。
で、やってみて、楽しかった・・・のかな？
まあ、・・・それなりに楽しそうです。
楽しいような気もします。
ゲームの面白さって何でしょうね。
ぼくはゲームシステム以外はあまりうまく作れませんが、その一方で、ぼくがゲームに求める楽しさは大半が物語性や演出によるところが大きいと思います。
でもやはりコアになるゲームシステムの面白さって必要ですもんね。
まあそれでもゲームシステムで多少でも面白いかもと思えたなら、後は演出次第で大化けするのかもしれないなあ。
だれかゲームデザインしてくれませんかー？
二人の弟のためにカットするお兄ちゃんの話とかね。
2021年02月10日
医療費のお知らせをもらいました
職場で医療費のお知らせをもらいました。
健康保険に入っているので、一年間にどれだけ医者にかかったかが書かれた書類です。
ぼくは3割負担なのでそれだけの現金を支払ったけど、残りは健康保険から払われたよ、という内容が載っていました。
そしてそれをわざわざ知らせてくれる目的は「健康保険に関心を持ってもらうため」だそうです。
まあぶっちゃけ「これだけ払ってあげてるんだから、健康保険料を文句言わず払ってよ」と言いたいのでしょうね。
それはちょっと恩着せがましいなーと思いました。
健康保険はこれだけあなたの役に立ちましたよって、それだけ言ってくるのは片手落ちじゃないかな。
こっちが払った保険料にも言及してくれないと。
保険加入者は別に保険制度の敵じゃないんだから、情報をフェアに伝えてほしい。
通知をくれるのなら
・被保険者が年間に支払った保険料
・保険が支払ってくれた七割の医療費
・その差額が個人にとってもしマイナスなら、それを支払うことの意義
・その差額がプラスなら、健康に生きることは遠慮しないでいい当然の権利ってことと、それを支える保険制度のすばらしさ
なんかを書いてくれたらいいです。
あ、職場も保険料を払ってくれてるのかな？そしたらその額も書いてくれてもいいけど。
ぼくもまだ老人ではなく、しっかり働いている割にはほとんど病院に行ってません。
なのでおそらく上記の差し引きはかなりマイナスになると思います。
でも、それを損しただなんてなんて思わないから！
ぼくの払った保険金は、収入の少ない老人や貧困家庭、未来の子供のために有効に使ってくれるんでしょ？
そう言ってくれたならちゃんと信じるから。
だから、こそこそしないで、こんだけとりました、そしてこんだけ出しました、って言ってほしい。
正々堂々と胸張って通知してくれたらいいんです。
七割払わずに済んだメリットばかりアピールして毎月の手取り給与を減らしている点に触れないのは、ちょっと姑息かなと思って、そんな態度だと健康保険のイメージダウンにつながるんじゃないかと思ったのでした。
健康保険に入っているので、一年間にどれだけ医者にかかったかが書かれた書類です。
ぼくは3割負担なのでそれだけの現金を支払ったけど、残りは健康保険から払われたよ、という内容が載っていました。
そしてそれをわざわざ知らせてくれる目的は「健康保険に関心を持ってもらうため」だそうです。
まあぶっちゃけ「これだけ払ってあげてるんだから、健康保険料を文句言わず払ってよ」と言いたいのでしょうね。
それはちょっと恩着せがましいなーと思いました。
健康保険はこれだけあなたの役に立ちましたよって、それだけ言ってくるのは片手落ちじゃないかな。
こっちが払った保険料にも言及してくれないと。
保険加入者は別に保険制度の敵じゃないんだから、情報をフェアに伝えてほしい。
通知をくれるのなら
・被保険者が年間に支払った保険料
・保険が支払ってくれた七割の医療費
・その差額が個人にとってもしマイナスなら、それを支払うことの意義
・その差額がプラスなら、健康に生きることは遠慮しないでいい当然の権利ってことと、それを支える保険制度のすばらしさ
なんかを書いてくれたらいいです。
あ、職場も保険料を払ってくれてるのかな？そしたらその額も書いてくれてもいいけど。
ぼくもまだ老人ではなく、しっかり働いている割にはほとんど病院に行ってません。
なのでおそらく上記の差し引きはかなりマイナスになると思います。
でも、それを損しただなんてなんて思わないから！
ぼくの払った保険金は、収入の少ない老人や貧困家庭、未来の子供のために有効に使ってくれるんでしょ？
そう言ってくれたならちゃんと信じるから。
だから、こそこそしないで、こんだけとりました、そしてこんだけ出しました、って言ってほしい。
正々堂々と胸張って通知してくれたらいいんです。
七割払わずに済んだメリットばかりアピールして毎月の手取り給与を減らしている点に触れないのは、ちょっと姑息かなと思って、そんな態度だと健康保険のイメージダウンにつながるんじゃないかと思ったのでした。
2021年01月05日
呼吸と湿度
みなさん、じめじめした日は息苦しい、なんてことはないでしょうか？
ぼくはないです。
けれども。
高校の科学でぼくはこう習いました。
「気体の種類によらず、同じ温度・同じ圧力において、同じ体積の気体の中には同じ数の分子が含まれる」
これをアボガドロの法則というそうです。
だとするならば。
空気中に水分子が多い時は、その分だけ酸素分子は少なくなるはずです。
つまり空気が湿っているときは人間が呼吸しても取り入れることができる酸素の量は少ないはず。
仮にそうなら、例えば天気予報では「明日は湿度が高いので深呼吸を意識して酸素不足を防ぎましょう」とか言うはずですよね。
でもそんなのは聞いたことがないです。
理論的には空気中の酸素量には湿度が影響するはずなのに。
でも世の中を見渡してもそんな言説は聞いたことがない。
湿度が高い日には呼吸困難の人が増えるとかも見たことがない。
この矛盾はどう説明できるのか。
謎です。
ぼくの想像ですが。
ひょっとしたら、吸気（口やのどから吸った空気）は、肺に達するまでにほぼ湿度100パーセント以上になっているんじゃないかな。
口や気管を経る間に水分がどんどん吸気にまざっていって、それで乾いた空気も十分潤ってしまうのかもしれない。
だとすれば、空気が乾いていても湿っていても、肺に到達した時の酸素量に差はないのかもしれない。
詳しい方がいたら教えてください。
ぼくはないです。
けれども。
高校の科学でぼくはこう習いました。
「気体の種類によらず、同じ温度・同じ圧力において、同じ体積の気体の中には同じ数の分子が含まれる」
これをアボガドロの法則というそうです。
だとするならば。
空気中に水分子が多い時は、その分だけ酸素分子は少なくなるはずです。
つまり空気が湿っているときは人間が呼吸しても取り入れることができる酸素の量は少ないはず。
仮にそうなら、例えば天気予報では「明日は湿度が高いので深呼吸を意識して酸素不足を防ぎましょう」とか言うはずですよね。
でもそんなのは聞いたことがないです。
理論的には空気中の酸素量には湿度が影響するはずなのに。
でも世の中を見渡してもそんな言説は聞いたことがない。
湿度が高い日には呼吸困難の人が増えるとかも見たことがない。
この矛盾はどう説明できるのか。
謎です。
ぼくの想像ですが。
ひょっとしたら、吸気（口やのどから吸った空気）は、肺に達するまでにほぼ湿度100パーセント以上になっているんじゃないかな。
口や気管を経る間に水分がどんどん吸気にまざっていって、それで乾いた空気も十分潤ってしまうのかもしれない。
だとすれば、空気が乾いていても湿っていても、肺に到達した時の酸素量に差はないのかもしれない。
詳しい方がいたら教えてください。
2021年01月01日
ゲーム以外のことも書いていきます
令和三年の元旦です。
あけましておめでとうございます。
新しい年を迎えたことだし、心機一転、ウディタについていろいろ書いてきたこのブログですが、今後はそれ以外のことも書いていこうと思います。
ウディタもやめるわけではないですが、なんせ最近はほとんど触らなくなっているので。
これからもよろしくお願いします。
あけましておめでとうございます。
新しい年を迎えたことだし、心機一転、ウディタについていろいろ書いてきたこのブログですが、今後はそれ以外のことも書いていこうと思います。
ウディタもやめるわけではないですが、なんせ最近はほとんど触らなくなっているので。
これからもよろしくお願いします。
2020年09月02日
「扉は君の鍵で開く」ウディコン４位に！
今さらですが、ウディコンにて「扉は君の鍵で開く」は総合４位をいただきました。
遊んでくれた方、評価してくれた方、皆さんありがとうございました！
ＮＡＮさんより投票コメントも見せてもらいました。
それで多くの方に楽しんでもらえたのだと知り、とても嬉しかったです。
また多くの改善点の指摘やアドバイスをいただいてすごく参考になり、考えさせられることも多かったです。
結果発表前からいろいろな反応をいただきましたが、例えば「質問する単語を頻繁に切り替える必要があるのでもっと簡単に選択画面へアクセスしたい」というご指摘も見かけました。
簡単に質問単語を切り替えられるシステムを作るとプレイが快適になる反面、謎解きのための総当たりがしやすくなってしまうんじゃないかという懸念があったんです。
極端な話、全部のキャラの前で全部の登録単語を順番に聞いていけば何も推理しなくても正解にたどりつけてしまいます。
それはできればやめてほしいというのがＮＡＮさんの希望で、ぼくもそうでした。
でもよくよく考えると、ゲーム内では深い推理が必要な場面でなくても頻繁に質問単語を切り替えないといけない所もありました。
プレイした人は思いつくかもしれませんが、例えばうわさの出どころを調べるために人名をたどる時なんかがそうです。
あー、きっとこれを面倒に思った人もいたんだろなー、そりゃそうだなー、と思い、質問変更を簡単にできるように機能を追加してみました。
そしてＮＡＮさんも採用してくれました。Ｖｅｒ１．１１以降では、ゲーム中でＣキーを押すだけで質問単語が切り替わります。
簡単に切り替わるからって、プレイする皆さんはできればしっかり考えてから質問してくださいね。その方が真実にたどり着いた時の喜びが大きいので！
（ちょっと制作者向けの話を。興味ない人はとばして下さい。Ｃキーで質問変更するキー入力監視はサンプルゲームのメニュー起動をそのままコピペして使っています。監視するキーをＣキーに変え、呼び出すコモンを変えただけです。また質問するためのシフトキー監視にも同じものを使っています。すごく簡単。そしてめっちゃ有能！SmokingWOLFさんはコモンにこう書いてくれてます。
▼ メニュー起動の際、
▼ 「イベント中はメニューが起動しないようにする」
▼ 「マスとマスの間を移動中は、メニューの表示を待つ（一定時間が過ぎたら入力キャンセル）」
▼ 「メニューを開いたときは次の一歩を歩き出さないようにする」
▼ など、安全性と便利さを向上させるための工夫がなされています。
この安全設計のおかげで、例えばメニューを開いてる途中にＣキーで質問を変えちゃったりすることがないようになってます。大助かり！）
「難易度と不親切さを間違えているのでは？！と思う部分があった」というコメントもいただきました。
また「操作系統に統一性がない」というご意見もありました。これは刺さる・・・。
お菓子システムはＮＡＮさんの趣味だし、後半に出てくる「所有アイテムの使用」にしたって、ぼくはノータッチだしー。と、逃げたいところではあるんですが、でも確かに言われてみると非常にごもっともな指摘だし、何よりテストプレイを繰り返してもその違和感に気づけなかったことを反省しました。
だってプレイヤーはただでさえ謎の解明の過程で理不尽とも思えるストレスに直面したりするじゃないですか。詰まったり。
これはもうこのゲームの謎解きの宿命なのでＮＡＮさんもぼくも割り切ってます。大変申し訳ないけどがんばっていただくしかない。
でもだからといって、いやそれだからこそ、それ以外のユーザインターフェース、操作などの面ではストレスをなくすようにもっともっと考えなくちゃいけなかったなーと。
このゲームではどんなことができたかあげてみると。
キャンセルキーでメニューを開く。
持ち物から生徒手帳を見たりできる。
そして「持ち物」機能の中に進行上必須の「渡す」機能もある。
スマホから仲間を呼び出す。
質問キーで質問をする。
直近の追加機能で、Ｃキーで質問を変更する。
質問を変える方法はＣキーも入れたら４通りある。
校内で部室へ移動する方法も、徒歩、地図、メニュー項目の３通りある。
・・・たしかにまあ、とっちらかってるとは言えそう。
そしてそれがわかりにくさ、面倒さ、とっつきにくさにもつながったかもしれない。
これらを統一しようとしたらどうすればよかったのか。
全部メニュー項目にして並べて表示するという手もあったかもしれない。
３×３の９マスだったメニュー項目を１２マスくらいに増やして「渡す」「アイテム使用」「アイテム見る」とかにしたらよかったのかな。
そうしたら「お菓子を渡せるなんて気づかず何時間も詰まった」とか「アイテムは使うべき場所では自動で使えるかと思って詰まった」という事態（実際いただいたご指摘）は防げたかもしれない。
でも１２項目のメニューって、それが出ただけでもう敷居が高いというか、気軽にプレイできなくなりますよね。
あるいは全部の機能をキーボードからのショートカットキーで起動させれたらどうかな。
（ウィンドウズ専用というウディタの弱点を逆に長所にする！）
それも覚えるのが面倒だったりとっつきにくさもあるけど。まあ慣れたら便利かもしれないけど。
でも戦闘もなくステータス数値もない歩くだけのアドベンチャーなのに、そんなにたくさんの操作が用意されたらそれもひくなー。
やっぱり気軽にプレイできなくなる。
そう思うえば、たとえ不親切でも、いろんな操作があちこちに散らばってて、ぱっと見ではとっつきやすい現状が結局正解なのか。
ゲーム開始直後には「メニュー起動とシフトでの質問だけ覚えてね！あとはフツーのＡＤＶだよ！」と言ったほうが、まあ面倒そうと思われる可能性は少ないかな。
間口を広げて多くの方にプレイを始めてもらって、追加の操作はゲーム内で覚えてもらって。
運悪く機能に気づけなかった人にはあきらめてもらうしかないのか。それしか正解がないのか。
ＮＡＮさんの野性的なカンで、結局ベストでなくてもベターな操作系統に落ち着いていたのか。
そんなこと書いたら、ゲームシステムの不親切さのために何時間も無駄に悩ませてしまった方々に怒られますよね。
本当に申し訳なく思ってます。すみませんでした。
いろいろ反省したり考えたりしました。今後次回作なんかがもしもあればこの経験が生きると思います。
多くの方のご意見に力や意欲をもらいました。
本当にありがとうございました。
ゲームの内容やストーリー、登場人物なんかについて、制作関係者としてではなくいちプレイヤーとして感想とかいろいろ書きたいんだけど、ネタバレはいけないし、ぐっと我慢してます。最後の方までプレイしてくれた方の多くもきっと同じ気持ちなんだろうな。
遊んでくれた方、評価してくれた方、皆さんありがとうございました！
ＮＡＮさんより投票コメントも見せてもらいました。
それで多くの方に楽しんでもらえたのだと知り、とても嬉しかったです。
また多くの改善点の指摘やアドバイスをいただいてすごく参考になり、考えさせられることも多かったです。
結果発表前からいろいろな反応をいただきましたが、例えば「質問する単語を頻繁に切り替える必要があるのでもっと簡単に選択画面へアクセスしたい」というご指摘も見かけました。
簡単に質問単語を切り替えられるシステムを作るとプレイが快適になる反面、謎解きのための総当たりがしやすくなってしまうんじゃないかという懸念があったんです。
極端な話、全部のキャラの前で全部の登録単語を順番に聞いていけば何も推理しなくても正解にたどりつけてしまいます。
それはできればやめてほしいというのがＮＡＮさんの希望で、ぼくもそうでした。
でもよくよく考えると、ゲーム内では深い推理が必要な場面でなくても頻繁に質問単語を切り替えないといけない所もありました。
プレイした人は思いつくかもしれませんが、例えばうわさの出どころを調べるために人名をたどる時なんかがそうです。
あー、きっとこれを面倒に思った人もいたんだろなー、そりゃそうだなー、と思い、質問変更を簡単にできるように機能を追加してみました。
そしてＮＡＮさんも採用してくれました。Ｖｅｒ１．１１以降では、ゲーム中でＣキーを押すだけで質問単語が切り替わります。
簡単に切り替わるからって、プレイする皆さんはできればしっかり考えてから質問してくださいね。その方が真実にたどり着いた時の喜びが大きいので！
（ちょっと制作者向けの話を。興味ない人はとばして下さい。Ｃキーで質問変更するキー入力監視はサンプルゲームのメニュー起動をそのままコピペして使っています。監視するキーをＣキーに変え、呼び出すコモンを変えただけです。また質問するためのシフトキー監視にも同じものを使っています。すごく簡単。そしてめっちゃ有能！SmokingWOLFさんはコモンにこう書いてくれてます。
▼ メニュー起動の際、
▼ 「イベント中はメニューが起動しないようにする」
▼ 「マスとマスの間を移動中は、メニューの表示を待つ（一定時間が過ぎたら入力キャンセル）」
▼ 「メニューを開いたときは次の一歩を歩き出さないようにする」
▼ など、安全性と便利さを向上させるための工夫がなされています。
この安全設計のおかげで、例えばメニューを開いてる途中にＣキーで質問を変えちゃったりすることがないようになってます。大助かり！）
「難易度と不親切さを間違えているのでは？！と思う部分があった」というコメントもいただきました。
また「操作系統に統一性がない」というご意見もありました。これは刺さる・・・。
お菓子システムはＮＡＮさんの趣味だし、後半に出てくる「所有アイテムの使用」にしたって、ぼくはノータッチだしー。と、逃げたいところではあるんですが、でも確かに言われてみると非常にごもっともな指摘だし、何よりテストプレイを繰り返してもその違和感に気づけなかったことを反省しました。
だってプレイヤーはただでさえ謎の解明の過程で理不尽とも思えるストレスに直面したりするじゃないですか。詰まったり。
これはもうこのゲームの謎解きの宿命なのでＮＡＮさんもぼくも割り切ってます。大変申し訳ないけどがんばっていただくしかない。
でもだからといって、いやそれだからこそ、それ以外のユーザインターフェース、操作などの面ではストレスをなくすようにもっともっと考えなくちゃいけなかったなーと。
このゲームではどんなことができたかあげてみると。
キャンセルキーでメニューを開く。
持ち物から生徒手帳を見たりできる。
そして「持ち物」機能の中に進行上必須の「渡す」機能もある。
スマホから仲間を呼び出す。
質問キーで質問をする。
直近の追加機能で、Ｃキーで質問を変更する。
質問を変える方法はＣキーも入れたら４通りある。
校内で部室へ移動する方法も、徒歩、地図、メニュー項目の３通りある。
・・・たしかにまあ、とっちらかってるとは言えそう。
そしてそれがわかりにくさ、面倒さ、とっつきにくさにもつながったかもしれない。
これらを統一しようとしたらどうすればよかったのか。
全部メニュー項目にして並べて表示するという手もあったかもしれない。
３×３の９マスだったメニュー項目を１２マスくらいに増やして「渡す」「アイテム使用」「アイテム見る」とかにしたらよかったのかな。
そうしたら「お菓子を渡せるなんて気づかず何時間も詰まった」とか「アイテムは使うべき場所では自動で使えるかと思って詰まった」という事態（実際いただいたご指摘）は防げたかもしれない。
でも１２項目のメニューって、それが出ただけでもう敷居が高いというか、気軽にプレイできなくなりますよね。
あるいは全部の機能をキーボードからのショートカットキーで起動させれたらどうかな。
（ウィンドウズ専用というウディタの弱点を逆に長所にする！）
それも覚えるのが面倒だったりとっつきにくさもあるけど。まあ慣れたら便利かもしれないけど。
でも戦闘もなくステータス数値もない歩くだけのアドベンチャーなのに、そんなにたくさんの操作が用意されたらそれもひくなー。
やっぱり気軽にプレイできなくなる。
そう思うえば、たとえ不親切でも、いろんな操作があちこちに散らばってて、ぱっと見ではとっつきやすい現状が結局正解なのか。
ゲーム開始直後には「メニュー起動とシフトでの質問だけ覚えてね！あとはフツーのＡＤＶだよ！」と言ったほうが、まあ面倒そうと思われる可能性は少ないかな。
間口を広げて多くの方にプレイを始めてもらって、追加の操作はゲーム内で覚えてもらって。
運悪く機能に気づけなかった人にはあきらめてもらうしかないのか。それしか正解がないのか。
ＮＡＮさんの野性的なカンで、結局ベストでなくてもベターな操作系統に落ち着いていたのか。
そんなこと書いたら、ゲームシステムの不親切さのために何時間も無駄に悩ませてしまった方々に怒られますよね。
本当に申し訳なく思ってます。すみませんでした。
いろいろ反省したり考えたりしました。今後次回作なんかがもしもあればこの経験が生きると思います。
多くの方のご意見に力や意欲をもらいました。
本当にありがとうございました。
ゲームの内容やストーリー、登場人物なんかについて、制作関係者としてではなくいちプレイヤーとして感想とかいろいろ書きたいんだけど、ネタバレはいけないし、ぐっと我慢してます。最後の方までプレイしてくれた方の多くもきっと同じ気持ちなんだろうな。
2019年04月12日
ウディタの基本
はじめに
最近小学生にウディタを教える機会があり、変数について説明したところ、「その数字の中身は、ゲームをしてていつ変わるの？」と聞かれました。
これは鋭い質問です。
これをきっかけに、ウディタの基本以前の基本について考え直してみました。
処理ははいつ起きるのか
小学生の質問への答えですが、変数操作が実行されるのはそのイベントが実行された時です。
イベントはいつ実行されるのか、それは当たり前すぎて、ウディタを始めたころ、何とはなしにわかったようでわからなくて、無意識的には少し引っかかっていた部分です（それでも困ることはなかったけれど）。この機会に言語化してみましょう。
（ここで書くのは１フレーム内にあらゆる処理がどの順で行われるかという難しい話でなく、もっと基本的なこと、並列イベントや、変数によるイベント起動条件さえ考えない、しごく単純な話です。）
ウディタ製ゲームをプレイ中はいつでも必ず、次に何を起こすかのボールはプレイヤーか作者のどちらかが持っています。
作者がその瞬間にやらせたいこと全てが終わって何もなくなったら、プレイヤーの入力待ちになります。
フィールドを歩くなど、プレイヤーは作者が次に何かを起こそうとする事態になるまで（作者に許された範囲内で）自由に操作ができます。
次にどういう場合にイベント（マップイベントかコモンイベント）を起動させるかはゲーム作者が指定します。
イベントが起動すると、イベント内に記入されたコマンドは上から順番に処理を進めていきます。
処理の流れに対して指定がない限り、一番下まで処理が終わって次にやることが残ってなければ、またプレイヤーが自由に操作する番が来ます。
（文章表示のキー入力待ちも広い意味では同じです）
こういったことは完全初期データからさわり始めた方には当たり前かもしれませんが、サンプルゲーム改造から入ったぼくには、はっきり理解できるまでに時間がかかりました。
常時並列のコモンが背後で動いていたためかもしれません。
全ての処理は上書き
ウディタで行われるコマンドの処理は、常に上書きです。
変数操作を例にしましょう。
Ｖ０＝１（通常変数０番の中身は１という数値）
Ｖ０＝２（通常変数０番の中身は２という数値）
という処理が二つ順に並んでいた場合、Ｖ０は一瞬は１になりますがその直後に２になります。
その２になった時に、前までの１はどこに行ったのかなどと考える必要はありません。
変数操作で使う「＝」（イコール）とは等号でなく、左辺の変数などに右辺の数値などを上書きするという意味です。
（そもそも等号なら、１だったものがイコール２だとか成りたちません）
処理が上書きということは変数操作以外にも当てはまり、絵を表示した後に消したら消えるし、音楽をかけた後に消したら途中でも消えます。
通常の生活ではそういう場面が少ないのかもしれませんね。
リンゴが入っていた箱の中身をミカンに変えようとしたら、ミカンをどこからか用意しないといけないし、不要になったリンゴをどうするかも考えないといけない。
１と言ってた値を今からは２に変えるといきなり言ったら「そんな急に言われても」とか「一貫性がない」と叱られるかもしれない。
この点ウディタは（おそらくプログラム全般はそうでしょうがぼくは知らない）、作者の意図が全てです。何に気兼ねすることもなく、それまでの経緯もお構いなしに、やりたいように処理をできます。
変数とは何か
話のついでに、ウディタにおける変数とは何かをぼくなりにまとめておきますね。
変数とは、数字や文字を書き込むための、ノートのような場所のこと。
通常変数と言う名前のノートには、０ページから続く各ページそれぞれに、数字を１つだけ書き込める。
最初はどのページにも０が書かれています。
これは情報がないという意味でなく、０という情報を最初から入れてあるという意味。
書き込まれた数字はゲーム作者が好きな時に書きかえることができます。
何のために書きかえるのかといえば、それは後で参照してゲーム内の処理に反映させるためです。
後から利用することもないのに変数の中身を変えても何も意味はなく、何も起こりません。
入力欄には右に＋０という部分がありますが、これは触る必要もないし、気にする必要もないです。
そして作者が意図しないのにプレイヤーのプレイ中に変数の中身が変わるということは本来ありません。
変数はあなたのノートです。作者のあなたのためにあるもので、ゲーム作りの強い味方です。
変数につまずいてウディタを断念する方は多いですが何とか粘ってもらいたいと思います。
2018年08月26日
メールアドレス変更のお知らせ
メールアドレスが変わります。
kukukusurimanopi@hotmail.com
になります。
連絡のある時はここへメールを送ってください。
このたび、今まで長い間使ってきたエキサイトメールという無料サービスが終了してしまうんです。
残念で不便でさみしいのですが、どうしようもありません。
新しいメールアドレスも無料のサービスを利用しています。
使いこなせるのか不安いっぱいですが、ともかくどこかに移るしかないのではじめてみました。
ぼくはツイッターもやっておらず、スカイプも使いこなせず、ましてやフェイスブックなどとは無縁の人間です。
なので今後もネット上の皆さんとのやりとりはメールを中心にすることになると思うので、よろしくおねがいします。
コモンなどのご相談などもここへお気軽にお願いします。
kukukusurimanopi@hotmail.com
になります。
連絡のある時はここへメールを送ってください。
このたび、今まで長い間使ってきたエキサイトメールという無料サービスが終了してしまうんです。
残念で不便でさみしいのですが、どうしようもありません。
新しいメールアドレスも無料のサービスを利用しています。
使いこなせるのか不安いっぱいですが、ともかくどこかに移るしかないのではじめてみました。
ぼくはツイッターもやっておらず、スカイプも使いこなせず、ましてやフェイスブックなどとは無縁の人間です。
なので今後もネット上の皆さんとのやりとりはメールを中心にすることになると思うので、よろしくおねがいします。
コモンなどのご相談などもここへお気軽にお願いします。
2018年08月20日
歩行グラフィックの枚数を増やすコモンを公開しました
むかしむかし。
といってもそれほど大昔でなく。
今見てみたら３年ちょっと前のことでした。
ぼくは歩行グラフィックの枚数を増やすコモンを作ったんです。
詳細はコチラ
でも公開できる素材がなかったので、コモンも公開できませんでした。
ウディタの歩行グラは通常３枚か５枚です。
それをピクチャ表示を使うことで、自由に枚数を指定できるようにしました。
ぼくは当時ある方のゲーム作りを手伝っていたのですが、その方はグラフィックに強いこだわりのある方で、頼まれて歩行グラ枚数を増やせるようにしました。
その方の希望に添えるコモンが完成し、その方自作の歩行グラをなめらかに歩けるようにできました。
ところがその方は病気がちで、とうとう音信不通になってしまったのです。
何度か「預かってる素材をお借りしてコモンを公開したらだめですか」と問い合わせるもお返事はなく。
ぼくは上記のリンクの自ブログで歩行グラ枚数を増やすのに成功したということだけ書いて、コモンは公開できないままに３年以上が過ぎたのです。
その間にもメールで何件かの問い合わせがありました。
そんな時はぼくはできる限り協力させてもらったのですが、やはりこのコモンには一定の需要があるのだと確信し、ぜひいつか公開したいという思いを持ち続けていたのです。
そしてこの度またeDaさんとおっしゃるドット職人さんから問い合わせをいただき、ご協力させてもらったところ、コモン用の素材の同梱配布を許可してもらうことができました。そこでついにコモン公開が実現することとなったのです。
ずっと念願だったのでとても嬉しいです。昨晩公式コモン集に「歩行グラフィック枚数を増やす」という名前でアップさせてもらいました。
今後多くの方に使ってもらえればと思います。
詳しいことはコモン同梱の説明書に書いたので、ここに再掲しておきます。
eDaさんありがとうございます！
---------------------------------------------------------------------------------------------------------------
歩行グラフィック枚数を増やすコモン Ｖｅｒ１．００
２０１８年８月２０日公開
コモンの場所を１つ使います。
ウディタ Ｖｅｒ２.２４に対応しています。
全画面サイズに対応していると思いますが３２０×２４０以外は未確認です。
＜このコモンでできること＞
ウディタでは歩行グラフィックは３枚か５枚しか選べません。
でもこのコモンを使って枚数を増やせます。
また通常、歩行中のグラフィックの表示順は１２３２１２３２・・と循環します。
このコモンでは１２３４５１２３４５・・と表示できます。
（例：歩行を横から見た場合、前に右足が出ている時と左足が出ている時を描き分けられます）
ただし、パーティーメンバーには対応していません。
一人分の画像のみ、先頭メンバー位置に表示します。
＜コモンの使い方＞
サンプル素材を使って画像を増やす方法を書きます。
（独自の歩行グラを使いたい時は、フォルダ内の画像を同名で上書きしてください）
１、コモンをどこにでも読み込んでください。
２、dataフォルダ内に同梱したdotフォルダを置いてください。
以上です。
＜素材の決まり＞
このコモンを改造せずに使う時は、素材は以下のルールで用意してください。
複数のパターンの画像は連結できません。
名前は静止時は、左向きなら4 上8 右6 下2 （半角数字）
移動中は左向きの１枚目なら4－１、２枚目なら4－２などにしてください。
パターン数はいくらでも増やして大丈夫です。
（多い場合、全部表示されるにはキャラが長い距離を直進する必要があります）
全ての画像サイズは同じサイズに統一してください。
斜め方向のグラフィック表示には未対応です。
＜ピクチャ表示の注意点＞
歩行グラフィックの表示にはピクチャを使用しています。
画面暗転でも消えない、エフェクトが無効、ピクチャ番号によって表示される層が異なるなどの点に注意してください。
＜おまけ機能：斜め移動時の表示画像の切り替え方＞
ゲーム設定から「キャラクター画像方向のタイプ」を設定することで、
４方向にすると斜め移動時には上下向きの画像を、
８方向にすると斜め移動時には左右向きの画像を、表示します。
＜同梱素材について＞
作者：eDaさん （ツイッターアカウント@eDadoT553）
eDaさんのご協力のかげで、このコモンの公開が実現しました。
この場を借りて心よりお礼申し上げます。
・この素材はゲームに使用・公開していただけます。
・その際、作者名明記などの必要はありません。
・ただし作者名を偽ることや二次配布はご遠慮ください。
--------------------------------------------------------------------------
（説明書ここまで）
コモンのデフォルトでは、素材の向きは４方向、使用パターン数は８枚です。
これは改造で変えれます。難しい方はご相談ください。
まあ技術面をざっくりいうと、要は、「今の瞬間は何枚目の歩行グラを表示すべき時間帯か？」を把握することができたのです。
それによって使用ピクチャを特定できます。
（使用画像は今回はバラバラ。もちろん改造すれば連結した素材もパターン番号指定で使えます）
表示位置は鏡コモンなどで培った主人公表示コモンなどのやり方で座標が分かるし。
それを使って、主人公の位置に主人公の画像を表示しただけのことです。
ウディタの限界をまた一つ拡張できたような達成感はありますが、やっていることは鏡コモンよりも単純かもしれません。
ピクチャ表示なので、全くの初心者の方には戸惑う部分はあるかもしれないですが、まあ何とかしてください。
といってもそれほど大昔でなく。
今見てみたら３年ちょっと前のことでした。
ぼくは歩行グラフィックの枚数を増やすコモンを作ったんです。
詳細はコチラ
でも公開できる素材がなかったので、コモンも公開できませんでした。
ウディタの歩行グラは通常３枚か５枚です。
それをピクチャ表示を使うことで、自由に枚数を指定できるようにしました。
ぼくは当時ある方のゲーム作りを手伝っていたのですが、その方はグラフィックに強いこだわりのある方で、頼まれて歩行グラ枚数を増やせるようにしました。
その方の希望に添えるコモンが完成し、その方自作の歩行グラをなめらかに歩けるようにできました。
ところがその方は病気がちで、とうとう音信不通になってしまったのです。
何度か「預かってる素材をお借りしてコモンを公開したらだめですか」と問い合わせるもお返事はなく。
ぼくは上記のリンクの自ブログで歩行グラ枚数を増やすのに成功したということだけ書いて、コモンは公開できないままに３年以上が過ぎたのです。
その間にもメールで何件かの問い合わせがありました。
そんな時はぼくはできる限り協力させてもらったのですが、やはりこのコモンには一定の需要があるのだと確信し、ぜひいつか公開したいという思いを持ち続けていたのです。
そしてこの度またeDaさんとおっしゃるドット職人さんから問い合わせをいただき、ご協力させてもらったところ、コモン用の素材の同梱配布を許可してもらうことができました。そこでついにコモン公開が実現することとなったのです。
ずっと念願だったのでとても嬉しいです。昨晩公式コモン集に「歩行グラフィック枚数を増やす」という名前でアップさせてもらいました。
今後多くの方に使ってもらえればと思います。
詳しいことはコモン同梱の説明書に書いたので、ここに再掲しておきます。
eDaさんありがとうございます！
---------------------------------------------------------------------------------------------------------------
歩行グラフィック枚数を増やすコモン Ｖｅｒ１．００
２０１８年８月２０日公開
コモンの場所を１つ使います。
ウディタ Ｖｅｒ２.２４に対応しています。
全画面サイズに対応していると思いますが３２０×２４０以外は未確認です。
＜このコモンでできること＞
ウディタでは歩行グラフィックは３枚か５枚しか選べません。
でもこのコモンを使って枚数を増やせます。
また通常、歩行中のグラフィックの表示順は１２３２１２３２・・と循環します。
このコモンでは１２３４５１２３４５・・と表示できます。
（例：歩行を横から見た場合、前に右足が出ている時と左足が出ている時を描き分けられます）
ただし、パーティーメンバーには対応していません。
一人分の画像のみ、先頭メンバー位置に表示します。
＜コモンの使い方＞
サンプル素材を使って画像を増やす方法を書きます。
（独自の歩行グラを使いたい時は、フォルダ内の画像を同名で上書きしてください）
１、コモンをどこにでも読み込んでください。
２、dataフォルダ内に同梱したdotフォルダを置いてください。
以上です。
＜素材の決まり＞
このコモンを改造せずに使う時は、素材は以下のルールで用意してください。
複数のパターンの画像は連結できません。
名前は静止時は、左向きなら4 上8 右6 下2 （半角数字）
移動中は左向きの１枚目なら4－１、２枚目なら4－２などにしてください。
パターン数はいくらでも増やして大丈夫です。
（多い場合、全部表示されるにはキャラが長い距離を直進する必要があります）
全ての画像サイズは同じサイズに統一してください。
斜め方向のグラフィック表示には未対応です。
＜ピクチャ表示の注意点＞
歩行グラフィックの表示にはピクチャを使用しています。
画面暗転でも消えない、エフェクトが無効、ピクチャ番号によって表示される層が異なるなどの点に注意してください。
＜おまけ機能：斜め移動時の表示画像の切り替え方＞
ゲーム設定から「キャラクター画像方向のタイプ」を設定することで、
４方向にすると斜め移動時には上下向きの画像を、
８方向にすると斜め移動時には左右向きの画像を、表示します。
＜同梱素材について＞
作者：eDaさん （ツイッターアカウント@eDadoT553）
eDaさんのご協力のかげで、このコモンの公開が実現しました。
この場を借りて心よりお礼申し上げます。
・この素材はゲームに使用・公開していただけます。
・その際、作者名明記などの必要はありません。
・ただし作者名を偽ることや二次配布はご遠慮ください。
--------------------------------------------------------------------------
（説明書ここまで）
コモンのデフォルトでは、素材の向きは４方向、使用パターン数は８枚です。
これは改造で変えれます。難しい方はご相談ください。
まあ技術面をざっくりいうと、要は、「今の瞬間は何枚目の歩行グラを表示すべき時間帯か？」を把握することができたのです。
それによって使用ピクチャを特定できます。
（使用画像は今回はバラバラ。もちろん改造すれば連結した素材もパターン番号指定で使えます）
表示位置は鏡コモンなどで培った主人公表示コモンなどのやり方で座標が分かるし。
それを使って、主人公の位置に主人公の画像を表示しただけのことです。
ウディタの限界をまた一つ拡張できたような達成感はありますが、やっていることは鏡コモンよりも単純かもしれません。
ピクチャ表示なので、全くの初心者の方には戸惑う部分はあるかもしれないですが、まあ何とかしてください。
2018年07月21日
ＮＡＮさんのゲーム作りを手伝っています
ごぶさたしています。
ＮＡＮさんといえば「落葉の大地を走れ」という作品で有名な方です。
「落葉の大地を走れ」はツクール２００３製なんですがバグが多くて非常に悩まれたんですよね。
（まあバグの全部がツクールのせいというわけではないでしょうが）
そこでＮＡＮさんもとうとうウディタに移ってくるということになって、以前ぼくと一緒にyou are my heroという作品を作りました。
ぼくは戦闘などを担当したんですが。
まあそんなわけで、ＮＡＮさんもウディタに慣れて、いよいよ次は本格的に腰を据えて、大作を作りはじめたわけです。
もちろんウディタで、です。
時代は現代。舞台は高校です。学園ものなのです。
その作品のお手伝いを前からさせてもらっています。
システムを作っています。というか、作りました。
「落葉の大地を走れ」で特徴的だった質問システム（プレイした方は分かるでしょうが）、あの仕組みをウディタで作りました。
ＮＡＮさんのブログでも小出しに紹介してもらっているので、そちらもご覧ください。
「落葉の大地を走れ」では質問単語を登録して町の人に質問すると、いろいろ答えてくれるんですけども。
それをどうやって作ったのかなーと、プレイ当時から興味はありました。
お聞きしてみたら、なんと、ウディタでいうところの条件分岐をいっぱいいっぱいつなげたみたいなんですね。
質問単語が○○なら以下の～～を実行、というのを下に下にひたすら入力していたみたいです。
どれだけ大変な作業だったか、想像もできません。
「落葉の大地を走れ」でいろいろ質問に答えてもらえる陰には、作者さんの大変な手間があったんです。
で、ウディタではＤＢを使って管理できるようにしました。
キャラごとに、何を聞かれたらどう答える、というのを一覧表に入力できるようにしました。
ＤＢは１行しか表示できないとか、見にくさの点では条件分岐を下に下につなげるのと五十歩百歩かもしれませんが。
それでもまあなんとかＮＡＮさんの求めるものを作ることができたみたいで、一安心です。
もっとも作ったのはしばらく前なので、もし改良を頼まれてももう忘れてるんじゃないかと不安なのです。
最近試しに中を見てみたら、なぜそうなっているのか理解できない部分がありました。自分で作ったのに！
まあ動いているならいいのです。今後サポートを頼まれないことを祈るのみです。
ちなみに何をやったか書いておくと。
質問用キー（シフト）の入力を監視して。
押されたら主人公の向いてる方の隣マスにマップイベントがあるかを判定して。
そのイベントに画像が設定されているかどうかでそれが人間かどうか判定して。
人間ならＤＢにあるそのキャラの反応する質問単語を調べて。
現在の質問に設定している文字列と一致するものがあったらＤＢに書いてある文章表示などをする。
そんな感じです。
それに加えて、文章表示以外もできるようにしたり。
パーティーメンバーに応じて反応を分岐させるようにしたり。
質問に使う類義語を登録しておき、同じ単語とみなすシステムとか。
質問単語を記録する仕組みやら。
会話中に出てきた単語を自動で登録する仕組みを作ったりしました。
あ、その、単語の自動登録の方法は独創的かもしれないので書いておきます。
文章表示中に出てくる単語を登録させたい時、その単語の前後を\c[0]で囲みます。
これは本来は「文字の色をデフォルトの色に変更する」ために使う特殊文字なんですけれども。
でも普通の色で文章表示している分には何の意味もありません。
そして別の並列（常時）コモンを動かしておいて、表示文章中に\c[0]が出てきたらそれで囲まれた部分を（すでに登録済でなければ）登録する、そんな風にしています。
登録部分を識別するための文字は別に何でもよかったんですけれども。
入力しても表示されず、そして何の効果もない文字がそれしか思い浮かばなかったのでそれを使いました。
ＮＡＮさんの新作はまだ完成半ばということです。
前作「落葉の大地を走れ」もなんと８年がかりの大作だったので、今回もそれくらいのスケールの作品なのかもしれません。
前作の反響の大きさを考えると今作はどのように受け止めてもらえるのか、とても楽しみです。
グラフィック関係でお手伝いいただける方を探しているという話もあるので、我こそはという方はぜひぜひお願いします。
「落葉の大地を走れ」同様、裏設定などにもものすごいこだわりというか労力をかけていらっしゃるので、完成はまだまだ先ですがファンの方はのんびり激しく期待してもらったらいいと信じます。
どうぞお楽しみに！
というよりぼく自身がものすごい楽しみにしているのです。
ＮＡＮさんといえば「落葉の大地を走れ」という作品で有名な方です。
「落葉の大地を走れ」はツクール２００３製なんですがバグが多くて非常に悩まれたんですよね。
（まあバグの全部がツクールのせいというわけではないでしょうが）
そこでＮＡＮさんもとうとうウディタに移ってくるということになって、以前ぼくと一緒にyou are my heroという作品を作りました。
ぼくは戦闘などを担当したんですが。
まあそんなわけで、ＮＡＮさんもウディタに慣れて、いよいよ次は本格的に腰を据えて、大作を作りはじめたわけです。
もちろんウディタで、です。
時代は現代。舞台は高校です。学園ものなのです。
その作品のお手伝いを前からさせてもらっています。
システムを作っています。というか、作りました。
「落葉の大地を走れ」で特徴的だった質問システム（プレイした方は分かるでしょうが）、あの仕組みをウディタで作りました。
ＮＡＮさんのブログでも小出しに紹介してもらっているので、そちらもご覧ください。
「落葉の大地を走れ」では質問単語を登録して町の人に質問すると、いろいろ答えてくれるんですけども。
それをどうやって作ったのかなーと、プレイ当時から興味はありました。
お聞きしてみたら、なんと、ウディタでいうところの条件分岐をいっぱいいっぱいつなげたみたいなんですね。
質問単語が○○なら以下の～～を実行、というのを下に下にひたすら入力していたみたいです。
どれだけ大変な作業だったか、想像もできません。
「落葉の大地を走れ」でいろいろ質問に答えてもらえる陰には、作者さんの大変な手間があったんです。
で、ウディタではＤＢを使って管理できるようにしました。
キャラごとに、何を聞かれたらどう答える、というのを一覧表に入力できるようにしました。
ＤＢは１行しか表示できないとか、見にくさの点では条件分岐を下に下につなげるのと五十歩百歩かもしれませんが。
それでもまあなんとかＮＡＮさんの求めるものを作ることができたみたいで、一安心です。
もっとも作ったのはしばらく前なので、もし改良を頼まれてももう忘れてるんじゃないかと不安なのです。
最近試しに中を見てみたら、なぜそうなっているのか理解できない部分がありました。自分で作ったのに！
まあ動いているならいいのです。今後サポートを頼まれないことを祈るのみです。
ちなみに何をやったか書いておくと。
質問用キー（シフト）の入力を監視して。
押されたら主人公の向いてる方の隣マスにマップイベントがあるかを判定して。
そのイベントに画像が設定されているかどうかでそれが人間かどうか判定して。
人間ならＤＢにあるそのキャラの反応する質問単語を調べて。
現在の質問に設定している文字列と一致するものがあったらＤＢに書いてある文章表示などをする。
そんな感じです。
それに加えて、文章表示以外もできるようにしたり。
パーティーメンバーに応じて反応を分岐させるようにしたり。
質問に使う類義語を登録しておき、同じ単語とみなすシステムとか。
質問単語を記録する仕組みやら。
会話中に出てきた単語を自動で登録する仕組みを作ったりしました。
あ、その、単語の自動登録の方法は独創的かもしれないので書いておきます。
文章表示中に出てくる単語を登録させたい時、その単語の前後を\c[0]で囲みます。
これは本来は「文字の色をデフォルトの色に変更する」ために使う特殊文字なんですけれども。
でも普通の色で文章表示している分には何の意味もありません。
そして別の並列（常時）コモンを動かしておいて、表示文章中に\c[0]が出てきたらそれで囲まれた部分を（すでに登録済でなければ）登録する、そんな風にしています。
登録部分を識別するための文字は別に何でもよかったんですけれども。
入力しても表示されず、そして何の効果もない文字がそれしか思い浮かばなかったのでそれを使いました。
ＮＡＮさんの新作はまだ完成半ばということです。
前作「落葉の大地を走れ」もなんと８年がかりの大作だったので、今回もそれくらいのスケールの作品なのかもしれません。
前作の反響の大きさを考えると今作はどのように受け止めてもらえるのか、とても楽しみです。
グラフィック関係でお手伝いいただける方を探しているという話もあるので、我こそはという方はぜひぜひお願いします。
「落葉の大地を走れ」同様、裏設定などにもものすごいこだわりというか労力をかけていらっしゃるので、完成はまだまだ先ですがファンの方はのんびり激しく期待してもらったらいいと信じます。
どうぞお楽しみに！
というよりぼく自身がものすごい楽しみにしているのです。
2017年11月07日
忍者のゲームを作りはじめました
忍者の出てくるゲームを作りはじめました。
ウディタからはちょっと離れていたのでひさしぶりです。
今日気づいたのですが
マップイベントが起動条件の変数を満たさないで歩行グラが表示されない時は
そのイベントは動作指定の移動を受け付けないみたいです。
まあ本来はRPGエディタなので
シンボルエンカウントの敵が消えている間に急接近したりしたら困る！
とかの理由でそんな仕様なのでしょうか。
ともかくぼくは消えている間に動かしたいのです。
なんてったって忍者ですからね。忍んでなんぼです。にんにん。
というわけで、試行錯誤してます。
画像があればいいんでしょ、と思って、透過色のみの画像素材を歩行グラに指定したらいいのかと最初思いました。
でも素材の用意が面倒だったので、歩行グラに不透明度を設定できたことを思い出しました。
移動中だけ別ページで透明人間にしたらいいんやん！
さすがぼく、ウディタのカンは衰えてない！
でもやってみたら動かない。歩行グラを切り替えたら動かない。
同じ歩行グラ素材のままなら動くのに。
動作完了までウェイトにして、その後にグラを切り替えてるのに。
悩みます。どういうこと？
まあ最悪、バックを一色にして、消したい時だけ同色のピクチャをかぶせるという手もあるけど。
できればそんな荒業は使いたくないなーと考えてるのです。
2016年11月05日
ＶＸ ＡＣＥをやってみました
ツクールＶＸ ＡＣＥの英語版に当たるソフトが無料との情報を得て、ＤＬしてやってみました。
ツクールを触るのはほとんど初めてです。
英語なのでよくわからないけど、とりあえずマップ上に地形を配置すること、イベントを設置してしゃべらせることができました。
ちゃんと日本語の文章を表示できましたよ。
こんなに何もわからない自分でも一瞬でそれだけできるって、なんだかウディタより簡単そうです。
歩行グラや顔グラの選択が直感的にできます。
まあツクールは素材の権利関係がややこしいと聞くので、英語を十分理解できないぼくは、仮にゲームができたとしても怖くて公開できない気がします。
でも視野をひろげれたらいいなと思います。
ツクールを触るのはほとんど初めてです。
英語なのでよくわからないけど、とりあえずマップ上に地形を配置すること、イベントを設置してしゃべらせることができました。
ちゃんと日本語の文章を表示できましたよ。
こんなに何もわからない自分でも一瞬でそれだけできるって、なんだかウディタより簡単そうです。
歩行グラや顔グラの選択が直感的にできます。
まあツクールは素材の権利関係がややこしいと聞くので、英語を十分理解できないぼくは、仮にゲームができたとしても怖くて公開できない気がします。
でも視野をひろげれたらいいなと思います。
2016年10月27日
どうつくるかより、何をつくるか
何かをるつくる技術よりも、それをつくりたいと着想できることが大事、と思ったんです。
ウディタのコモン作りについて。
もちろんつくりたいものができた時にそれをつくることができなかったら始まらないけど。
前回の記事で自分が今まで作ったコモンを振り返った時に、いいものができたと思えるのは鏡コモンと接近コモンです。
（公開コモンではないですが、ぼら猫パズルの「お片付け成功」判定システムも同じです。）
それらを「つくろう！」と思えたことが、とても幸せなことでした。
これからも「つくろう！」と思えることに出会えたらいいなと思います。
鏡コモンや接近コモンのように、シンプルでありながら、
「ウディタのデフォルト機能では簡単には実現できないけど、実現できたら汎用性が高く使える」
というものを作りたいです。
そういうものでリクエストがあったらぜひ教えてください。
コメント欄にお願いします。
2016年10月03日
接近コモン、その後
前の記事に書いた通り、接近コモンは改造の余地が多いです。
起動条件判定を移動コモン内に移せば、処理が軽くなります。
距離未判定時に入れる数値を９９よりずっと多くしたら、もっともっと判定できるようになります。
（調べたところ、敵は主人公から７５０マス離れても移動方向を正確に読み取り接近しました。
その際の敵が移動する頻度は、７８１フレームに一回でした。）
追いつかれた時の処理を別のコモンに入れておき、予約で呼び出せばもっとよくなりそうです。
同じく移動コモン内に条件分岐でSys変数「イベント実行中？」が１ならイベント中断、としたらよさそうです。
引数で別モードを設定して、マップIDと追う敵のイベントIDを送るようにしたら、同じ設定変更を複数のコモンでやってもらわないでよくなります。
コモン番号が確定していれば変数呼び出し値で変数入力ができるけど。
今回はコモンを入れる場所がどこでもいいいようにコモン名で呼び出すようにしているので。
各コモンでいちいちマップIDと追う敵のイベントIDを入れてもらうしかないと思ったけど。
それを引数で送れることに気づきました。
けれども引数に使えるコモンセルフ0～4を無駄に使い倒していて途方に暮れました。
検索して全部別変数に割り振り直したけど。
今回の教訓。
引数を使う予定はなくても、やっぱりコモンセルフ0～4は大事に使おう。
それ以外の改善点として、マップ遷移直後に前マップの情報にもとづいた方向へ移動する不具合もありました。それも直しました。
あと、使用コモン数も減らせるかも。
使用DB数はきっと減らせるはず。０か１かでしか使っていないんだから、片方は10の位を使うとかでいけるはず。
それら諸々を改善しました。
でもそうするとなぜか動かなくなりした。
そこで投げ出しました。
それが二晩続きました。
なので今、休憩中です。
成功したら明日にも更新するかもしれないし、あるいはずっとこのままかも。
不便を感じた人は、できるなら上に書いたことを参考にして対処してください。
できないならメールください。
コモンを作る時に、誰に向けて作るかをいつも考えます。
ぼくは初心者に向けて作りたいです。
基本システムを使わない方法もわからないような初心者にむけて。
だって人数も多いだろうし。
他人の作ったコモンを一番必要としている人たちだろうし。
ウディタで何ができるのかなー、の延長で触ってる人。
コモン単体の機能としては、接近コモンは十分完成していると思うんですけどね。
接近するんだから。
現状で、わかりやすいはずです！
（もちろんすごくわかりにくいけど！）
これに、ぼくはいろいろ付け加えようと思います。
イベント実行中は起動しないとか・・・。
なんだとか・・・。
上に書いた、いろいろ。
これは何をやっているのだ、どうなっているのだ、という人には、何のためにそれをしているのかが分かりにくくなってしまうと思う。
何のためにそれをしている？、ええ、それは初心者の使いやすさのためです。内容を理解しようとがんばってくれてるあなたのためじゃないんです。ごめんね。
本質だけがむき出しになったわかりやすいコモンより、使えるコモンを作ります。
ゴテゴテするけど。ごめんね。
でもそう言っておきながら、あきらめるかもしれないですけどね。
ｺﾞﾒﾝﾈ。
2016年09月28日
接近コモン④
昨夜接近コモンが完成し、公開しました。
接近コモンについてはこちら
前からこのコモンを作るのに試行錯誤する過程を紹介していた記事の延長で、完成に至るまでのことを記録しておきます。
前の解説（？）記事を読むと、処理速度に悩んでいますね。
たしかにそうでした。そんな時期もありました。（遠い目）
でもそんなことは問題じゃなかったんですね。
それより根本的な過ちがあったのでした。
主人公がマップ上のある位置に行くと挙動がおかしくなる不具合があったんですが…。
それを解決しようと悩み続けたところ、驚くべき大失敗が明らかに！
ループ回数を数えていたコモンセルフ変数を、そのループ内で別のループの回数を数えるのにも使っていたのでした！
２か所で！同時に！別々の目的で！
一つの変数を使っていました…。
こりゃ不具合もでるわー。
というよりむしろ、それでも曲りなりには動いていたのが不思議なくらいですね。
ちなみにその変数につけていた名前は「一時変数１」。
こんな名前は気をつけないといけませんね。
「○○カウント用」とかちゃんとわけないとミスの元！
そういうわけで今回の教訓、
変数の使い分けを惜しむな！
ということを学びました。
で、その部分を修正したところ…。
処理が正確になったのはもちろんですが、驚いたのはとにかく処理速度が速い早い！
厳密に言えば、処理落ちしがちというのは今までと変わらないのですが、当面の問題であった更新頻度の遅さが解決しました。
それに正確に判定されるから気持ちいい！
通行不可マスは距離９９を入れて判定していますけど、敵との距離が９９以上になっても正確に判定されるみたいです。
これはいつか機会があれば通行不可判定の値を９９よりもっと大きくしないといけませんね。
（機会ってなんだよ！やる気ないやん！ってツッコミが聞こえてきそうな気がした）
あと今回知ったこと。
動作指定で「XYに接近させる」の座標には通常変数とかが使えるんですね。
以前何かの時に、コモンセルフを入れて使えなかったからやむなく数値を直接入れて、８方向の分、８通りに条件分岐させた気がします。
何でコモンセルフだけダメなのかな。
動作指定機能はもとはマップイベント用に作られたのかもしれないですね。
それでコモンセルフは受けつけないという名残りがのこっているのかも、と推測。
まあそんなわけで今回はキャラの移動先を指定するのに予備変数を使いました。
それから、接近コモンとマップイベントの関係についても書いておきましょう。
ウディタで取得できる通行判定には、マップイベント込みのものと地形のみの二通りありますよね。
最初は使用者の設定でどちらでも選べるようにしようと思いました。
でもマップイベントって、動くじゃないですか。
まあ動かさなくてもいいんですけどね。
街中とかをうろつくモブキャラをよけながら接近させるなら、その時点のモブキャラの位置を毎回更新し続けないといけない。
それをやってみましたけど、とても重くなったので導入はあきらめました。
だって追うキャラが地形を判定して接近してくるのって、プレイヤーに「あのキャラ、ボクがどこにいるのかわかって自分で進路を考えて進んできてる！」って思わせるためじゃないですか。
ちがう？
ホラーゲームであれが好まれるのは、超越的な知能を持っていることをあらわすからかもな、と今思いつきましたよ。
ゲーム内のモブキャラの動きなんてたいてい反復とかじっとしたままとかランダムじゃないですか。
それが状況にあわせて最適解を判断できるなんて、
常識を超えてる！⇒理解の及ばないキャラかも！⇒なんだかちょっと怖い！
みたいな感情を誘発することが期待されているのかもしれませんね。
何の話でしたっけ？
通行設定の判定でしたね。
その自分で地形を読み取って考えて進んできてるはずの敵が、目の前に人が立っているというだけで、よけて通るということを思いつかず、その人が立ち去るまでずっと待ち続ける…。
そんなのおかしいですよね。ありえない。
茶番だ。
せっかくプレイヤーに「こいつは知能を持っているのか？」と思わせかけたのに、「なんだやっぱりアホやん」と思われてしまう。
これじゃ接近コモンを使う意味は全くないですね。
プレイヤーを幻滅させ現実に引き戻してしまうくらいなら、むしろ下手な小細工は最初からやめたほうがいい。
歩行グラの位置なんて細かいことでプレイヤーに何らかの体験を与えようとするのでなく、別の方法を考えたほうがいい。
と、そこまでコモンを作った時に考えていたかどうかは覚えていませんけど。
（きっと今あとから思いついたのでしょう）
ともかくコモンの説明書には「動いて」「すり抜けない」マップイベントは置かないように誘導するような書き方をしておきました。
まあそれでもおきたい人は置くんでしょうけどね。
それはそれでいいです。
それから、コモンを公開するというのは使えるようにするということです。
いくら接近コモンとはいえ、接近しました、はいおしまい、では使えない。
追いついた時の処理を入れる方法と、コモンの起動条件を設定する方法を一応用意しました。
両方とも満足できるできばえではないんですけど…。
追いついた時の処理については並列だからヘンです。
ウディタ同梱のサンプルゲームに入れると夕一が接近してくるんですけどね。
追いつかれた時の処理をオンにしていると、ゲーム開始するとさっそく来るんです、夕一が。
ウルファールがくるっとまわって口上を述べてる間に夕一が到達し、ゲームオーバーとか表示させやがるのです。
これは…。
あ、そっか。
別のコモンに追いつかれた時の処理を入れて、接近コモン内の「追いつかれた時の処理」としてはコモンの予約をすればいいのか・・・。
まあそれ以前に、ウルファールがしゃべっている間にも夕一が接近し続けるというのが普通のゲームとしてはおかしいですよね。
これはどうしたらいいのかな？
動作指定で接近移動させている部分に、システム変数の「イベント実行中？」の分岐をかませればいいのかな。
何か違うような気もしますけど。
などとぼくはどうしてここにそんなことを書き連ねるのか。
ウディタ開いて触ったらすぐわかることで、改善できたらバージョンアップすればいいだけなんですけどね。
完成して公開して、製作から解放されたその解放感がウディタからぼくを遠ざけるのかもしれない。
ウディタもコモンも好きだけど登録作業は好きでないかも。緊張するし。
とか、そんなことはどうでもいいですね。
後書いておくことは、と。
ソフトニシンさんに教えてもらった「ルート検索」「最短経路探索」の二つのコモンを確認しました。
「ルート検索」の方は、導入を試みましたが、ReadMeをどう読んでもぼくには残念ながら理解できませんでした。
コモンやDBを入れるとか変数呼び出し値とか引数とか、それは分かるんだけど、じゃあどういう時に何をしたら何がどうなるのかわからず、ぼくには使えませんでした。
でも６年も前、おそらくそのようなシステムがまだ公開されてなかった（のかな？）時期に公開された意味は大きい、きっと素晴らしいコモンなのだろうと思いました。
もうひとつの「最短経路探索」は、これまた素晴らしかったです。
仕組みは全然わからないけど、ちゃんと敵が接近してきました！
でもこれ、完全初期状態から作られたシステムなんですね。
これを借りた人が自分のゲームにどう使えるか、ちょっとわかりません。
しかもこれは作者さんが今作っているゲームのシステムだというし…。
それならこれを借りて同じ仕組みのゲームを公開する（しかも作者さんより早く？）のはちょっとためらわれますよね。
まあいいんですが。
話はそれますが、ぼくは自分を自作システムを作れる人と思っているけど、完全初期状態をみると頭の中も真っ白になります。
基本システムって何だろう。
その中枢部分はやっぱり戦闘ですよね。
そんなもの使わないほうが作りたい戦闘をよっぽど簡単に作れるというのはよくわかるのですが。
ぼくの場合fairysongなんかはほとんど基本システムは使わなかったんじゃないかなあ。
でも使わないにしても、やっぱりコモンの上の方にダダーっと並んでいてくれないと不安です。
何がデフォルトで何が基本システムかを分けて考えていないからでしょうね。
歩行処理とか、基本システムなくてもできるんでしょう？
わかっているようで実の所なにかよくわかっていません。
基本システムをそのまま使ったゲームなんて今さら作らないよーと思ってますが、それでもぼくはれっきとした基本システム派なのでしょう。
話を戻しまして、ともかく結論としては、今回ぼくが接近コモンを作った意味は大いにあったと思いました。
難しいのが平気な方や古いバージョンのウディタを使う方は「ルート検索」。
システムを自作できる方は「最短経路探索」。
基本システムを使う初心者の方はぼくの「接近コモン」。
が、それぞれおすすめかもしれません。
まあぼくの偏見で言うと、接近コモンを使いたいのは、大体が初心者の方じゃないでしょうか。
それが悪いと言ってるんじゃないですよ。
ホラーで。追っかけさせたいっていうのは。
ゲームを何作か作って、どんなゲームを作ったらどんな反応がもらえるかわかってきた時に、それじゃあ、今度は追っかけられるゲームを作ろうか、とは、なかなか一般的にはそうはなりにくそうには思います。
ぼくとしては、追っかけるゲームを作りたいと思った人が「ウディタなら（接近コモンやその他のコモンを使って）追いかけが簡単にできるらしい！」と知ったことがきっかけでウディタにはまり込み、二作目以降に力作を作り、それをぼくが楽しく遊ばせてもらえたならばうれしいです。
あ、接近コモン作者として何か余計なことを書いちゃってるかなぁ？
まあいつものことだしいいか。
現在、接近コモンを導入したい方にはメールを使ったサポート強化キャンペーンを実施中ですので、追いかけさせたい方、導入が難しかった方はご連絡くださいね。
何だかいろいろなことを書きました。
この文章の乱れ具合を見ても、接近コモンがいかに難産だったかをお察しいただけるのではないでしょうか。
製作を終えたぼくをこんな風にしてしまう、そんなコモンでした。
それでは失礼いたします。
接近コモンについてはこちら
前からこのコモンを作るのに試行錯誤する過程を紹介していた記事の延長で、完成に至るまでのことを記録しておきます。
前の解説（？）記事を読むと、処理速度に悩んでいますね。
たしかにそうでした。そんな時期もありました。（遠い目）
でもそんなことは問題じゃなかったんですね。
それより根本的な過ちがあったのでした。
主人公がマップ上のある位置に行くと挙動がおかしくなる不具合があったんですが…。
それを解決しようと悩み続けたところ、驚くべき大失敗が明らかに！
ループ回数を数えていたコモンセルフ変数を、そのループ内で別のループの回数を数えるのにも使っていたのでした！
２か所で！同時に！別々の目的で！
一つの変数を使っていました…。
こりゃ不具合もでるわー。
というよりむしろ、それでも曲りなりには動いていたのが不思議なくらいですね。
ちなみにその変数につけていた名前は「一時変数１」。
こんな名前は気をつけないといけませんね。
「○○カウント用」とかちゃんとわけないとミスの元！
そういうわけで今回の教訓、
変数の使い分けを惜しむな！
ということを学びました。
で、その部分を修正したところ…。
処理が正確になったのはもちろんですが、驚いたのはとにかく処理速度が速い早い！
厳密に言えば、処理落ちしがちというのは今までと変わらないのですが、当面の問題であった更新頻度の遅さが解決しました。
それに正確に判定されるから気持ちいい！
通行不可マスは距離９９を入れて判定していますけど、敵との距離が９９以上になっても正確に判定されるみたいです。
これはいつか機会があれば通行不可判定の値を９９よりもっと大きくしないといけませんね。
（機会ってなんだよ！やる気ないやん！ってツッコミが聞こえてきそうな気がした）
あと今回知ったこと。
動作指定で「XYに接近させる」の座標には通常変数とかが使えるんですね。
以前何かの時に、コモンセルフを入れて使えなかったからやむなく数値を直接入れて、８方向の分、８通りに条件分岐させた気がします。
何でコモンセルフだけダメなのかな。
動作指定機能はもとはマップイベント用に作られたのかもしれないですね。
それでコモンセルフは受けつけないという名残りがのこっているのかも、と推測。
まあそんなわけで今回はキャラの移動先を指定するのに予備変数を使いました。
それから、接近コモンとマップイベントの関係についても書いておきましょう。
ウディタで取得できる通行判定には、マップイベント込みのものと地形のみの二通りありますよね。
最初は使用者の設定でどちらでも選べるようにしようと思いました。
でもマップイベントって、動くじゃないですか。
まあ動かさなくてもいいんですけどね。
街中とかをうろつくモブキャラをよけながら接近させるなら、その時点のモブキャラの位置を毎回更新し続けないといけない。
それをやってみましたけど、とても重くなったので導入はあきらめました。
だって追うキャラが地形を判定して接近してくるのって、プレイヤーに「あのキャラ、ボクがどこにいるのかわかって自分で進路を考えて進んできてる！」って思わせるためじゃないですか。
ちがう？
ホラーゲームであれが好まれるのは、超越的な知能を持っていることをあらわすからかもな、と今思いつきましたよ。
ゲーム内のモブキャラの動きなんてたいてい反復とかじっとしたままとかランダムじゃないですか。
それが状況にあわせて最適解を判断できるなんて、
常識を超えてる！⇒理解の及ばないキャラかも！⇒なんだかちょっと怖い！
みたいな感情を誘発することが期待されているのかもしれませんね。
何の話でしたっけ？
通行設定の判定でしたね。
その自分で地形を読み取って考えて進んできてるはずの敵が、目の前に人が立っているというだけで、よけて通るということを思いつかず、その人が立ち去るまでずっと待ち続ける…。
そんなのおかしいですよね。ありえない。
茶番だ。
せっかくプレイヤーに「こいつは知能を持っているのか？」と思わせかけたのに、「なんだやっぱりアホやん」と思われてしまう。
これじゃ接近コモンを使う意味は全くないですね。
プレイヤーを幻滅させ現実に引き戻してしまうくらいなら、むしろ下手な小細工は最初からやめたほうがいい。
歩行グラの位置なんて細かいことでプレイヤーに何らかの体験を与えようとするのでなく、別の方法を考えたほうがいい。
と、そこまでコモンを作った時に考えていたかどうかは覚えていませんけど。
（きっと今あとから思いついたのでしょう）
ともかくコモンの説明書には「動いて」「すり抜けない」マップイベントは置かないように誘導するような書き方をしておきました。
まあそれでもおきたい人は置くんでしょうけどね。
それはそれでいいです。
それから、コモンを公開するというのは使えるようにするということです。
いくら接近コモンとはいえ、接近しました、はいおしまい、では使えない。
追いついた時の処理を入れる方法と、コモンの起動条件を設定する方法を一応用意しました。
両方とも満足できるできばえではないんですけど…。
追いついた時の処理については並列だからヘンです。
ウディタ同梱のサンプルゲームに入れると夕一が接近してくるんですけどね。
追いつかれた時の処理をオンにしていると、ゲーム開始するとさっそく来るんです、夕一が。
ウルファールがくるっとまわって口上を述べてる間に夕一が到達し、ゲームオーバーとか表示させやがるのです。
これは…。
あ、そっか。
別のコモンに追いつかれた時の処理を入れて、接近コモン内の「追いつかれた時の処理」としてはコモンの予約をすればいいのか・・・。
まあそれ以前に、ウルファールがしゃべっている間にも夕一が接近し続けるというのが普通のゲームとしてはおかしいですよね。
これはどうしたらいいのかな？
動作指定で接近移動させている部分に、システム変数の「イベント実行中？」の分岐をかませればいいのかな。
何か違うような気もしますけど。
などとぼくはどうしてここにそんなことを書き連ねるのか。
ウディタ開いて触ったらすぐわかることで、改善できたらバージョンアップすればいいだけなんですけどね。
完成して公開して、製作から解放されたその解放感がウディタからぼくを遠ざけるのかもしれない。
ウディタもコモンも好きだけど登録作業は好きでないかも。緊張するし。
とか、そんなことはどうでもいいですね。
後書いておくことは、と。
ソフトニシンさんに教えてもらった「ルート検索」「最短経路探索」の二つのコモンを確認しました。
「ルート検索」の方は、導入を試みましたが、ReadMeをどう読んでもぼくには残念ながら理解できませんでした。
コモンやDBを入れるとか変数呼び出し値とか引数とか、それは分かるんだけど、じゃあどういう時に何をしたら何がどうなるのかわからず、ぼくには使えませんでした。
でも６年も前、おそらくそのようなシステムがまだ公開されてなかった（のかな？）時期に公開された意味は大きい、きっと素晴らしいコモンなのだろうと思いました。
もうひとつの「最短経路探索」は、これまた素晴らしかったです。
仕組みは全然わからないけど、ちゃんと敵が接近してきました！
でもこれ、完全初期状態から作られたシステムなんですね。
これを借りた人が自分のゲームにどう使えるか、ちょっとわかりません。
しかもこれは作者さんが今作っているゲームのシステムだというし…。
それならこれを借りて同じ仕組みのゲームを公開する（しかも作者さんより早く？）のはちょっとためらわれますよね。
まあいいんですが。
話はそれますが、ぼくは自分を自作システムを作れる人と思っているけど、完全初期状態をみると頭の中も真っ白になります。
基本システムって何だろう。
その中枢部分はやっぱり戦闘ですよね。
そんなもの使わないほうが作りたい戦闘をよっぽど簡単に作れるというのはよくわかるのですが。
ぼくの場合fairysongなんかはほとんど基本システムは使わなかったんじゃないかなあ。
でも使わないにしても、やっぱりコモンの上の方にダダーっと並んでいてくれないと不安です。
何がデフォルトで何が基本システムかを分けて考えていないからでしょうね。
歩行処理とか、基本システムなくてもできるんでしょう？
わかっているようで実の所なにかよくわかっていません。
基本システムをそのまま使ったゲームなんて今さら作らないよーと思ってますが、それでもぼくはれっきとした基本システム派なのでしょう。
話を戻しまして、ともかく結論としては、今回ぼくが接近コモンを作った意味は大いにあったと思いました。
難しいのが平気な方や古いバージョンのウディタを使う方は「ルート検索」。
システムを自作できる方は「最短経路探索」。
基本システムを使う初心者の方はぼくの「接近コモン」。
が、それぞれおすすめかもしれません。
まあぼくの偏見で言うと、接近コモンを使いたいのは、大体が初心者の方じゃないでしょうか。
それが悪いと言ってるんじゃないですよ。
ホラーで。追っかけさせたいっていうのは。
ゲームを何作か作って、どんなゲームを作ったらどんな反応がもらえるかわかってきた時に、それじゃあ、今度は追っかけられるゲームを作ろうか、とは、なかなか一般的にはそうはなりにくそうには思います。
ぼくとしては、追っかけるゲームを作りたいと思った人が「ウディタなら（接近コモンやその他のコモンを使って）追いかけが簡単にできるらしい！」と知ったことがきっかけでウディタにはまり込み、二作目以降に力作を作り、それをぼくが楽しく遊ばせてもらえたならばうれしいです。
あ、接近コモン作者として何か余計なことを書いちゃってるかなぁ？
まあいつものことだしいいか。
現在、接近コモンを導入したい方にはメールを使ったサポート強化キャンペーンを実施中ですので、追いかけさせたい方、導入が難しかった方はご連絡くださいね。
何だかいろいろなことを書きました。
この文章の乱れ具合を見ても、接近コモンがいかに難産だったかをお察しいただけるのではないでしょうか。
製作を終えたぼくをこんな風にしてしまう、そんなコモンでした。
それでは失礼いたします。
2016年09月22日
接近コモン③
前回までの続きです。
今までは、大きく分けて二つの処理、
・全マスの主人公からの距離を判定
・それを使って追いかけるキャラの移動
この二つを一つのコモン内でやっていました。
ところがそれでは距離判定が終わるまでキャラは動けません。
距離判定には短くても2秒くらいはかかります。
休み休み、立ち止まりながら追いかけてくることになってしまいます。
やっぱり追う時はたとえ移動速度はおそくとも途切れずに追い続けてほしいですよね。
そこで距離を判定する処理と移動させる処理とを二つのコモンに分離しました。
そうすることで理屈上は、最適なタイミング、つまり移動終了直後に次の移動開始ができるようになりました。
当然、移動頻度もあがった、はずなんですが・・・。
しかし実際には体感的にはあまり変化はありませんでした。
特に主人公と追うキャラとの距離が遠い場合はそれが顕著です。
それはなぜか。
判定距離の確定範囲は主人公を起点に広がっていきます。
なので追うキャラが離れていると距離未確定の時間が長いのです。
距離判定を行うたびに、距離の値を格記録している可変ＤＢをいったん初期化していました。
だから距離が未確定の時間ができてしまうわけですね。
なのでその待機時間を減らすために、初期化しないように作りかえました。
ＤＢには「前回判定時のそのマスの距離」を保持しつつ、新規の判定でそれに上書きしていきます。
そうすることで追うキャラはどこに移動したらいいかが常にわかるのようになりました。
待機時間はなくなり、途切れることなく歩き続けるようにできました。
けれどもそれはそれで、また別の不具合がでることがわかりました。
追うキャラがちゃんと追ってきてくれない時があるのです。
その状況には二種類あります。
一つは主人公が直進移動しつづけている場合。
追うキャラは常に追ってきて、距離判定も常に繰り返しているのですけれども。
距離判定を開始した直後くらいのタイミングに問題は起こります。
主人公の足元の主人公からの距離は０です。
けれども新規に判定が確定した範囲がまだ広がっていません。
そのために、主人公が移動してきた数歩前の地点にも同じく距離が０の地点があります。
主人公がいるとみなされる地点が二つできてしまうのです。
これは前回判定時の記録を消さないようにしたことの副作用です。
追ってくるキャラは、実際の主人公から少し離れたその距離０の位置で移動を終えてしまいます。
しばらく立ち止まりつづけ、距離判定の新規更新の波が届くに及んでやっと正常な接近を再開します。
もう一つは主人公と追うキャラの距離が短時間に大きく変化した場合。
距離が接近すれば、当然追うキャラの足元のマスの距離を示す値は小さくなります。
その後に何らかの理由で距離が離れると、主人公の足元から再判定した距離が広がっていくのですが、それが追うキャラに近づくころには距離の値は大きくなります。
高い値の波がやってきた時、追うキャラは値の小さい方へ移動するように設定されているため、逆戻りをしてしまいます。
主人公に接近すると距離が高くなると誤判定されてしまうのです。
これら二つのケースの問題があって、初期化しないというのもそれはそれで問題があると気づきました。
これはいったいどうすればいいのか。
初期化はしつつも判定待ちの待機時間をなくす方法も考えました。
たとえば判定待ちなら停止でなくウディタ標準機能の「主人公に接近」をさせてお茶を濁すとか。
でもこれは逃げですよね。
上手くいく状況もあるけれど、くぼみに向かってツッコんでいく場合もある。
そんなものを作っても意味はりません。
やっぱり、「現在の瞬間の正確な距離」が測定できていないのに、追うキャラに移動開始させるなら誤作動は避けられないかもしれません。
わずかな待機時間には目をつぶるしかないのか・・・。
部分部分を補う処理は思いつくんです。
主人公と追うキャラの双方が一直線上にいて、全てのマスが通行可能なら「主人公に接近」させるとか。
それでけっこうな部分はカバーできると思うのですが、それもやっぱり付け焼刃だしなぁ。
一度確定した「主人公と追うキャラを結ぶ最短の動線」から離れた位置にある袋小路などは判定の必要のないマスとみなし、処理速度を上げることも可能ではありそうです。
だけどもそれにしたって判定頻度を常に高く保っておかないと主人公がぴゅっとそこに突っ込むとかありえるし、やはり課題は残りそうです。
こうして文章にすることで、自分の作りたいものが改めて整理されてきました。
・適切なマスに移動する。
・できるだけ途切れず移動し続ける。
・処理落ちからくる移動速度低下を起こさない
これらを満たす仕組みを作りたいと思います。
王道ですが、処理を少しでも軽くして判定時間を短くし、判定頻度を上げるしかないかもしれません。
今からはちょっと処理速度を気にしてやってみます。
ウディタ界隈でよく知られているだめだめはきだめさんの情報を参照させてもらいます。
まさかこんな情報を使うシステムを作る時が来るとは思っていませんでした。
ウディタリバーシに参加した時も、他の方が思考に時間をかけているのを見てぼくにはとてもできないと思っていたものですが。
現状ではマスの通行可否を何度も判定し直していますが、それも最初に全部を一回だけ見てＤＢに記録し、そっちを参照した方が速いかもしれない。
また５０万回エラー防止のウェイトをどこに置くのがいいのか、１フレーム当たりの処理が何回を超えた時に挟むのがいいのか、いろいろ試してみようと思います。
ラベル：コモン
2016年09月20日
接近コモン②
昨日の続きです。
だいぶん改良できました！
正確な数字の広がりがうつくしい！
通行不可でない限り、主人公からの距離が放射状に（というかひし形に）広がっていきます。
このスクリーンショットではわかりにくいですが、回り込みもばっちりです！
ところで昨夜の画像がおかしかった理由は、処理がちゃんと終わらないうちに次の動作に移っていたためでした。
そこで動作が本当に終わったのか確認する処理をはさみ、まだなら再度実行するようにしました。
そこで正確な動作が実現できました。
でも今までは終わってなくても次に進んでたから軽かったのですが、終わるまで終わらくなったためにいやがおうにも重いです。
50万エラーを防ぐためにコモン内にウェイト処理を入れてます。
1フレーム当たりの処理回数に応じてウェイトをさせるんですけど。
何回以上ではさむかによって挙動が違って面白いです。
処理回数を上げると、マップ上の距離判定頻度が高まるのですが、キャラ移動速度が遅くなります。
処理回数を下げるとその逆で、頻度が下がって移動速度が普通に近づきます。
さてどうしましょうかね。
現状では判定と敵キャラ動作指定を同じコモン内でやっています。
判定が終わるまでは移動できない仕様です。
これを分離したらいいんじゃないかな。
地形が一定（と思っていいのですか？）なら、敵キャラの最短移動方向が急激に変わることはないから、判定がまだでも「さっきまでのベストアンサー」に向かわせたらいいんじゃないかな。
主人公たちの移動がおかしくならないくらいに判定頻度は下げて、敵移動は頻度に左右されないようにしようか。
うん、そうすることにします。
上に「地形が一定（と思っていいのですか？）」と書いたのはどういうことかというと、障害を配置できるタイプのタワーディフェンスゲームのことがちょっと脳裡をかすめたんです。
オブジェクト配置によって一瞬で進むべき方向が逆転するようなゲームだってありますよね。
まあそういうのに使いたいときは判定頻度を上げて、処理を軽量化して処理速度が落ちないよう頑張るしかないですね。
続きはまた明日。
あ、もし「さっさと中を見せろー」「早く配布してー」という人がいればメールくれたら対応しますので。
とりあえず実用レベルに達したものはできてるんですけどね。
もうちょいがんばります。
だいぶん改良できました！
正確な数字の広がりがうつくしい！
通行不可でない限り、主人公からの距離が放射状に（というかひし形に）広がっていきます。
このスクリーンショットではわかりにくいですが、回り込みもばっちりです！
ところで昨夜の画像がおかしかった理由は、処理がちゃんと終わらないうちに次の動作に移っていたためでした。
そこで動作が本当に終わったのか確認する処理をはさみ、まだなら再度実行するようにしました。
そこで正確な動作が実現できました。
でも今までは終わってなくても次に進んでたから軽かったのですが、終わるまで終わらくなったためにいやがおうにも重いです。
50万エラーを防ぐためにコモン内にウェイト処理を入れてます。
1フレーム当たりの処理回数に応じてウェイトをさせるんですけど。
何回以上ではさむかによって挙動が違って面白いです。
処理回数を上げると、マップ上の距離判定頻度が高まるのですが、キャラ移動速度が遅くなります。
処理回数を下げるとその逆で、頻度が下がって移動速度が普通に近づきます。
さてどうしましょうかね。
現状では判定と敵キャラ動作指定を同じコモン内でやっています。
判定が終わるまでは移動できない仕様です。
これを分離したらいいんじゃないかな。
地形が一定（と思っていいのですか？）なら、敵キャラの最短移動方向が急激に変わることはないから、判定がまだでも「さっきまでのベストアンサー」に向かわせたらいいんじゃないかな。
主人公たちの移動がおかしくならないくらいに判定頻度は下げて、敵移動は頻度に左右されないようにしようか。
うん、そうすることにします。
上に「地形が一定（と思っていいのですか？）」と書いたのはどういうことかというと、障害を配置できるタイプのタワーディフェンスゲームのことがちょっと脳裡をかすめたんです。
オブジェクト配置によって一瞬で進むべき方向が逆転するようなゲームだってありますよね。
まあそういうのに使いたいときは判定頻度を上げて、処理を軽量化して処理速度が落ちないよう頑張るしかないですね。
続きはまた明日。
あ、もし「さっさと中を見せろー」「早く配布してー」という人がいればメールくれたら対応しますので。
とりあえず実用レベルに達したものはできてるんですけどね。
もうちょいがんばります。
2016年09月19日
接近コモン①
ぼくのサイトを見てくれる人の検索ワードやページビュー数を見ると、「敵が追いかけてくるコモン」に興味を持ってくれる人が多いみたいです。
あれは、主人公の足跡をたどってついてくるようにするコモンでした。
でも。ねえ。
やっぱりできれば、最短距離を追いかけてほしいですよね。
というわけで、これはもう、作らねばなりますまい！
やってみて、何日か試行錯誤して、少し形になってきました。
というか、初めて不完全ながらも動いたのでうれしい。
ので、記事にします。
記事にしたら頭の整理と、モチベーション追加注入ができるのです。
考え方としては、主人公を中心とした年輪を書きます。
ＤＢに用意した各マスの距離を格納する場所に、主人公からそのマスへの距離を入れます。
接近してくるキャラは、自分の周囲のマス中でその距離が一番近い方へ移動する、という仕組み。
ぼくがメモした作り方を以下に貼り付けます。
-------------------------------------------------------
（可変ＤＢ2枚使う。距離用（初期値は９９）と四方判定済フラグ用（初期値は０））
主人公ＸＹ取得
基準地＝主人公ＸＹ
現在判定中の距離＝０
「現在判定中の距離」を可変ＤＢ１枚目ＸＹに代入する
ループ---------------------
前判定の距離＝現在判定中の距離
現在判定中の距離＝＋１
その距離入力回数＝０（初期化）
マップ内から「前の距離」入力済かつフラグなしのマスを探す
あれば、隣接する4方向全てに（必要な場合※）「距離」を入力する。
（入力するたびに「その距離入力回数」＝＋１）
4方向おえたら2枚目ＤＢの基準地＝１にする
なかったら
その距離入力数＝０のままならループ中断
ループここまで-----------------
接近キャラの4方向の計測距離を見て、最少の移動方向を求める。
同じ計測値の方向が複数あっても、どれかに決めたらいい
接近キャラ移動
※基準地の4方向に関して
計測済みでないか
マップ外でないか
通行不可でないか
を判定
-------------------------------------------------------
何のことかわかんないですよね。大丈夫です、わかるように書いてないので。
やってみてもなかなかうまくいかなかったので、ぼら猫パズルで学んだ教訓を生かしました。
そう、おかしかったらすぐ可視可！
各マスの距離をマップ上に表示させました。
こんな感じ！
接近してくる犬は数字が一番少ないところに移動するのです。
よく見るといろいろおかしいですよね。
でもシンプルなマップならそれなりに動くんですよ。
画面中央に横一文字に通行不可マスがある場合、上にいる主人公が右に寄れば犬も右に、左に寄れば犬も左に移動し、まわりこんで主人公のところにまで到達しました。
うれしい！
明日以降不具合を減らします。
これが公開できたら、画期的かもなあ。
作ったことある人は多いだろうけど、コモン集にはきっとまだないもんなあ。
などと一人でほくそえんでいます。
あれは、主人公の足跡をたどってついてくるようにするコモンでした。
でも。ねえ。
やっぱりできれば、最短距離を追いかけてほしいですよね。
というわけで、これはもう、作らねばなりますまい！
やってみて、何日か試行錯誤して、少し形になってきました。
というか、初めて不完全ながらも動いたのでうれしい。
ので、記事にします。
記事にしたら頭の整理と、モチベーション追加注入ができるのです。
考え方としては、主人公を中心とした年輪を書きます。
ＤＢに用意した各マスの距離を格納する場所に、主人公からそのマスへの距離を入れます。
接近してくるキャラは、自分の周囲のマス中でその距離が一番近い方へ移動する、という仕組み。
ぼくがメモした作り方を以下に貼り付けます。
-------------------------------------------------------
（可変ＤＢ2枚使う。距離用（初期値は９９）と四方判定済フラグ用（初期値は０））
主人公ＸＹ取得
基準地＝主人公ＸＹ
現在判定中の距離＝０
「現在判定中の距離」を可変ＤＢ１枚目ＸＹに代入する
ループ---------------------
前判定の距離＝現在判定中の距離
現在判定中の距離＝＋１
その距離入力回数＝０（初期化）
マップ内から「前の距離」入力済かつフラグなしのマスを探す
あれば、隣接する4方向全てに（必要な場合※）「距離」を入力する。
（入力するたびに「その距離入力回数」＝＋１）
4方向おえたら2枚目ＤＢの基準地＝１にする
なかったら
その距離入力数＝０のままならループ中断
ループここまで-----------------
接近キャラの4方向の計測距離を見て、最少の移動方向を求める。
同じ計測値の方向が複数あっても、どれかに決めたらいい
接近キャラ移動
※基準地の4方向に関して
計測済みでないか
マップ外でないか
通行不可でないか
を判定
-------------------------------------------------------
何のことかわかんないですよね。大丈夫です、わかるように書いてないので。
やってみてもなかなかうまくいかなかったので、ぼら猫パズルで学んだ教訓を生かしました。
そう、おかしかったらすぐ可視可！
各マスの距離をマップ上に表示させました。
こんな感じ！
接近してくる犬は数字が一番少ないところに移動するのです。
よく見るといろいろおかしいですよね。
でもシンプルなマップならそれなりに動くんですよ。
画面中央に横一文字に通行不可マスがある場合、上にいる主人公が右に寄れば犬も右に、左に寄れば犬も左に移動し、まわりこんで主人公のところにまで到達しました。
うれしい！
明日以降不具合を減らします。
これが公開できたら、画期的かもなあ。
作ったことある人は多いだろうけど、コモン集にはきっとまだないもんなあ。
などと一人でほくそえんでいます。
ラベル：コモン
2016年07月27日
ぼら猫パズルシステム解説その２ クリア判定の方法と不具合顛末記
この解説は連日更新していこうと思っていたところ、ウディコンの掲示板にて不具合の報告をいただいてずっと格闘していました。
今夜やっと修正ができたので、それについて書きます。
でもまずその前にそもそもこのパズルはどういう仕組みで動いているかですよね。
前回の記事で書いた通り、描画関係はデフォルトシステムの流用で楽にできました。
そしてキー入力関係も既存のものの流用で簡単にできました。
（これについては後日記事を分けて書こうと思います。）
一番問題だったのはクリア判定です。
プレイヤーの操作によってマス目の並びがお片付け成功状態になった時に、それをどう判定するか。
これはとても難しかったです。
でもこれができたなら一つのゲームができるという確信があったので、ちょっと自分の技術力から見ると背伸びでしたが挑戦しました。
作りたいものがはっきり見えていて、それに向けて試行錯誤している時って創作者にとって至福の時間ですね。大変なんだけど。
実際の制作は作ってもうまく動かない、やり直しても動かない、の繰り返しでした。
作り直すたびに発想を変え別の方法を試すのですが、３つ目の方法を試している時、方法とか以前の初歩的な失敗があったことに気づきました。
イベントの位置を把握するために入力していたX座標とY座標とが逆になっていたのでした。あれまぁ。
そりゃあ、どおりで何度作り直しても上手くいかないわけです。
そこを修正した途端、３つ目の方法がうまく機能し始めました。
なので１つ目や２つ目のやり方でもできてたのかもしれないです。
でももう消しちゃったし、３つ目の方法でできているので検証する必要もなく、今となってはどうしていたかも忘れてしまいました。
なので実際に採用した方法を説明します。
まず可変データベースに、各マスに関する数値を記録する場所を５×５の２５用意しました。
マスの色は各マップイベントのセルフ変数に記憶させているので、この数値とは別です。
この数値のことは仮に感染値と名付けました。
そしてマスの入れかえ直後だけ動くコモンイベントを５つ用意しました。
５つのコモンは５つの色に対応します。
それらは各色に対して「端から順に見てその色が最初に出てきたとき、それとつながっている同じ色のますだけ感染値を入力する」という働きをするのです。
その結果、マスの入れかえ直後に全ての感染値を初期化しておけば、各色一つ目のかたまりのみ数値が入力されることになります。
ところでこのパズルの目指す状態は同じ色のますが全部かたまることです。
つまり一つ目のかたまりが全てとなって、二つ目のかたまりなんか存在しない、そんな状態を目指すのです。
なので５色全てが一つ目のかたまりだけになる、つまり未感染のますが存在しない、そういう状態になった時にクリアーしたと判定することにしました。
そして同じ色のかたまりを認識すること、これがまた非常に難しかったです。
これなんかは、以前tohさん主催のウディタリバーシに挑戦したからこそできたと思います。
あの経験がなかったらぼくには到底作れないシステムでした。
人との縁は不思議なものですね。出会いってありがたいです。
色のかたまりの認識を完全に制御することはぼくにはできませんでした。
今回採った方法は確率論的なものに頼っています。
イメージとしては、最初に出てきたその色のますを、菌に感染させる。
そして菌に自由な方向に発育を試させながら十分な時間を置き、それで感染している部分だけを隣接したかたまりであるとみなす。
そういう方法にしました。
各色について、最初に見つかったマスに置かれた「菌」は１１００回自由な方向に移動を試みます。移動先が別の色なら移動はできません。
この１１００という回数が大きくても少なくても不具合が起きました。
回数が少ないとかたまりの判定が不正確になります。
範囲が細長い場合には開始地点から反対の端まで感染が届かないまま判定終了することがありました。
逆に回数を多くすると処理が重くなります。
処理落ちを防ぐために、システム変数を使って１フレーム当たりのﾅﾝﾁｬﾗが５０万に近づいたらウェイトを入れるようにはしました。
それでも動きは遅くなるので、それではまずいので。
遅くならず、不正確にもならない回数が１１００回だったというわけです。
それらの機能を実装できて、一応クリア判定ができるようになったわけです。
ただ、ウディコン開始後に報告をいただいた誤判定は、実は公開前から何度も確認はしていました。
そして何度も修正を加え「ついに修正に成功した！」と、何度も何度も思いました。
この不具合は再現頻度が高くないので、確認が大変だったんですよね。
確認のプレイをして、５０回クリアしても出るか出ないかだったりする。
なので、修正をしたらとりあえず見つからなければ直ったと思いこむのですが、忘れたころに不具合が再確認され「え～」となることがしばしばでした。
あってはならない、禁断の画像。同じ色が二ケ所に分かれているのに、大成功!の文字が・・・。
さっき書いたXY座標のミスと同じで、最終的に見つかった不具合は致命的なものだったので、それ以前にチョコチョコ修正していたことに意味があったのかなかったのかはよくわかりません。
ただその過程を通して、ぼくがウディタの仕様について考え抜くことはできました。
最初は並列コモンをいくつも適当に置いておいて「いつでも同時に動いてるだろ」と思っていたのですが・・・。
並列でも１フレーム内ではコモンは番号順に処理されるのだろうから、並び順がすごく大事なんじゃないかとか思って並べ替えてみたり。
並列コモン内の処理が完了するまでにフレームの切り替えが必要なんじゃないかとか疑心暗鬼になってあちこちに１フレームウェイトをはさんでみたり。
コモン呼び出しをやめて予約にしてみたり。
とにかく原因が分からないからいろいろ試しまくりました。
そして最終的にわかったことは、感染させるコモンが不完全だったのです。
（隣接ますに移動を試みた際にそのマスが範囲外だった時、記憶させている隣接ますのイベント番号を初期化し忘れていたのでした）
これに気づくまでには、このゲームシステムを作ったのと同じくらいの労力をかけました。
なので２作作った気分です。
反省点としては、可視化することの重要性ですね。
データベースの中に何が入っているかをちゃんと常時表示確認していれば、不具合自体はたまにしか起きなくても内部数値はしょっちゅうおかしなことになっているということにゲーム公開前に気づけたと思います。
忘れちゃいけない、可視化。
それとこれは難しいけれど、やっぱり先入観念を捨てるのが大事ですね。
ぼくの場合は並列とかフレームとかの仕様などをいまいち理解しきれていないという意識があるために、謎の不具合に出会ってそこばかり注目していました。
適切な場所を落ちついてよーく見れば３０分で「ここがおかしい」と気づけるはずの失敗でした。
いい勉強になりました。
せっかくプレイしてもらって不具合にあわれた方、申し訳ありませんでした。
次回はキー入力について少しだけ書いて、ぼら猫パズルのシステム解説を終わる予定です。
2016年07月23日
ぼら猫パズルシステム解説その１ 歩行システムを流用したパズル作り
ウディコンに出すためにぼら猫パズルというゲームをきみのなまえをよばせてくださいで作りました。
このゲームを遊んで下さった方の中でなおかつウディタでの制作に興味のある方に向けたシステム面の話を数回に分けてかかせてもらいます。
まだ遊んでない方はよかったら一度遊んでもらって、このゲームはどう作るかという視点でこの文章を読んでもらえたらと思います。
なお、ぼら猫パズルは非暗号化で公開しているため、興味のある方は遠慮なく中をご覧ください（ただし素材の使用は禁止です）。
では解説記事一回目はあのパズルの描画をするためにウディタデフォルトの歩行システムをどう流用したかを書きます。
パズルのカーソルは、実は主人公の位置にあるのです。
主人公は実はウルファールの画像を仮に設定してあるのですが、「パーティーメンバーを透明に」しています。
そしてパズル実行中は常時主人公の位置を取得し、その座標を基準にした位置にカーソルをピクチャ表示させています。
デフォルトの歩行のシステムはとても便利なものです。
これを自作しようとしたら大変です。
方向キーの入力を監視しないといけないし、マスに来たら止まるとかもしないといけない。
ありあわせの機能を活用して、ずいぶん楽をさせてもらいました。
また、全てのますはマップイベントです。
マップイベントを２５枚並べています。
それぞれにページを５つ設定しています。
イベント画像を５色の正方形に設定して、起動条件となる変数の値によってページを変え、色が変わるようにしてあります。
これまた自作していたら手間のかかるところでした。
さらには、カーソルがパズル範囲から出てしまわないためにはパズル範囲の周囲や足元に敷き詰めたイベントのすり抜けオンオフ機能を使いました。
周囲は通行不可のイベントで囲んだのは言うまでもありません。
それに加えて、カーソルの一部が周囲に食い込まないようにするのも同じ機能を使っています。
カーソルは縦と横に向きを変えますが、透明の主人公の位置はカーソルが横向きなら左側、縦向きなら上側なのです。
なので対策を講じないと、例えばカーソルが横向けの時には右側が周囲の通行不可マスにかぶってしまうのです。
それを防ぐためにパズル枠内、通行可能範囲の右端、および下端に、イベントを並べました。
起動条件を「その時のカーソルの向きを示す変数」にしてすり抜けは不可にし、そのイベントが存在する時だけそちらには進めないようにしました。
また、カーソルを切り替えた時に枠に食い込むような位置にいた場合は、「場所移動」で透明の主人公を隣のますに瞬間移動させました。
何というか非常に泥臭い方法ばかりですが、それらのおかげで非常に簡単に作れました。
このようなパズルを作る時にここまで歩行システムやマップイベントを活用するというのはひょっとしたら珍しいかもしれないので、少し詳し目に書いてみた次第です。
ただ、既存のシステムを流用したことによる弊害もなかったわけではありません。
一番大きいのは、パズル範囲を画面中央に表示できないことです。
ウディタではどの画面サイズを取ろうとも縦・横に敷き詰めるマスの数は偶数です。
なので画面中央に一つのますを表示することは難しいし、奇数マスからなる何かを中央に置くのも大変です。
マップを使うゲームを作った経験のある方は、画面上下の部屋の出入り口などの幅が偶数ますだと偏るので困った方も多いと思います。
一応これには解決方法もないわけではないです。
全ての地形をイベントで配置し、マップが始まる直後に全てのイベントを半歩横へ移動すればいいです。
そのためのコモンも公式コモン集にて公開されていたと思います。
ただ今回のぼくの場合はそれも使えませんでした。
主人公の半歩移動が使えないからです。
マスを選択するためのカーソル移動なのに、カーソル位置がマスにぴったり重ならなかったら話になりませんもんね。
まあシステムを改造して、デフォルトの移動幅を半歩にしながらも停止位置がマスの真上なら強制的にさらに半歩進ませることもできるでしょうけど。
でもそこまでするとせっかく歩行システムを使っている利点がなくなってしまいそうだし、そうはしませんでした。（めんどうだし！）
おかげでパズル画面はわずかに右に寄っています。
そういえば「エフェクト」などを使って画面の表示位置を半歩分横にずらすこともできるのかも、とはちょっと思ったのですが。
でもぼくはエフェクトは苦手なのでやりませんでした。
エフェクトってピクチャ表示と相性が悪いじゃないですか。そうでもない？
今なんとなく思いついたけどウディタの描画演出をするのにピクチャ派とエフェクト派がいるかもしれませんね。
どっちも使いこなせたらそりゃいいけど、片方で事足りるケースが多そうな気もします。
まあぼくだってたまにはエフェクトも使いますけどね。
今回のぼら猫パズルでは・・・うーん、多分どこにも使ってません。
昨年のウディコンでは画像音声部門で高い評価をもらえましたが、こういう手抜きをプレイヤーは見てるかも知れませんね。
ほんのちょっと中央から偏ってるってだけでも、高い緊張感が保てない気はします。
まあ今回のゲームはゆるキャラとだらだら続けてもらいたいから緊張感はあんまりなくてもいいか。
話がそれましたが、それ以外のデフォルトシステム流用による弊害といえば、移動速度のことでしょうかね。
ゲームプレイを続けるとある時からカーソル移動速度を変更できるようになります。
これは主人公の「移動速度の変更」機能を使っています。
でもこれは細かい調整ができなくってね・・・。
通常だと快適なんですが、一つ遅くすると遅すぎてイライラするし、一つ早くすると操作性がすごく悪くなるし。
なので完成間際まで変更画面で「通常以外はお勧めしません」とか書いてお茶を濁していたんですけどね。
でもテストプレイヤーさんに「速いだと操作しにくい！」と残念がられてぼくは目が覚めました。
そりゃそうですよね。せっかく速くできるようになったのにそれが使い物にならないなんてストレスのもと以外の何物でもなく、無い方がましなくらいです。
そこでぼくは本気を出してがんばって、移動速度が速くても誤操作が起きにくいシステムを作りました。
主人公の座標を常時監視して、主人公がマスの真上を通過しようとした瞬間だけ、動作指定で数フレームだけ瞬間的に足止めする、という方法です。
これをすることで、移動速度を速めても意図したのに近い操作ができるようになりました。
ちなみにこれを作るためには使えそうで使えない方法がありましてね。
このブログでも何度か取り上げた、システム変数の「主人公が移動中？」というやつです。
鏡コモンを作る時に詳細にみた通り、この変数は主人公がマスの真上にいるのかどうかを判定できるんですけどね。
理屈上ではぼくがわざわざ座標を取得してやっているのと同じことを判定できそうなのですが。
けれどもこれは移動速度が速い連続移動中はマスの真上も瞬間的に素通りしてしまうんです。
それを知っていたので使いませんでした。
そういうことを思うと移動っていったい何だろうと考えてしまいます。
移動速度というのはマスからマスへ何フレームかけて到達するかなのでしょうかね。
その速度で移動開始をしたら、１フレームごとに何ピクセル移動するかが決まっているんでしょうね。
そしてキャラの瞬間瞬間の厳密な座標によって、キャラが今の瞬間いるマスがどこかとか、マスの真ん中にいるかとか、決まるんでしょうね。
少し話がそれるけど、昔習った数学の問題を思い出しまいた。
「たかし君が時速Aキロで池の周りをまわって、１０分後にスタート地点にいる確率はいくらでしょう？」
これ、正解はなんと０％なんですって。これにはびっくりした！今でも忘れません。
たまたまそこにいることだってあるだろうと思うんですけどね。
よりによって、一ミリもたがわず、その瞬間にその場所にぴったりといるということなんて、もう限りなく０に近いくらいありえないことらしいです。
そうだとするならば、そりゃあマスの真上を瞬間的に通過していくキャラを、１フレームに一回しか判定されないシステム変数が捕捉できる可能性は低いのかもしれませんね。
そう思うと１フレームって限りなく瞬間に近い概念と思っていたけれども、移動距離との関係でいえば全然瞬間なんかじゃないんですね。
１フレームって、意外と粗い。
これは今回のぼら猫パズルの制作で身に染みたことであって、これ以外の所でもまた出てくる命題です。
それについてはまた明日とかに書きます。
一回目の今回は、パズルゲームであってもデフォルトシステムをフル活用したということを書いてみました。
書き忘れていることもあるかもしれないけど。
興味のある方は参考にしてください。
質問もお待ちしています。
それと全然関係ない話ですが。
今作で一つだけお借りしたコモンがあります。
表記の義務はなくスペースの都合もあってゲーム内などでは表示しませんでしたが。
ひげさんの文字表示拡張コモンを公式コモン集よりお借りしました。
制作に興味のある人しか見ないだろうこの場を借りてお礼申し上げます。
ありがとうございました。
ゲーム開始直後にタイトルが上から降ってきてプルプルなるのにこのコモンを使っています。
おかげでかわいらしい演出ができました。
では、続きはまた次回ということで。
このゲームを遊んで下さった方の中でなおかつウディタでの制作に興味のある方に向けたシステム面の話を数回に分けてかかせてもらいます。
まだ遊んでない方はよかったら一度遊んでもらって、このゲームはどう作るかという視点でこの文章を読んでもらえたらと思います。
なお、ぼら猫パズルは非暗号化で公開しているため、興味のある方は遠慮なく中をご覧ください（ただし素材の使用は禁止です）。
では解説記事一回目はあのパズルの描画をするためにウディタデフォルトの歩行システムをどう流用したかを書きます。
パズルのカーソルは、実は主人公の位置にあるのです。
主人公は実はウルファールの画像を仮に設定してあるのですが、「パーティーメンバーを透明に」しています。
そしてパズル実行中は常時主人公の位置を取得し、その座標を基準にした位置にカーソルをピクチャ表示させています。
デフォルトの歩行のシステムはとても便利なものです。
これを自作しようとしたら大変です。
方向キーの入力を監視しないといけないし、マスに来たら止まるとかもしないといけない。
ありあわせの機能を活用して、ずいぶん楽をさせてもらいました。
また、全てのますはマップイベントです。
マップイベントを２５枚並べています。
それぞれにページを５つ設定しています。
イベント画像を５色の正方形に設定して、起動条件となる変数の値によってページを変え、色が変わるようにしてあります。
これまた自作していたら手間のかかるところでした。
さらには、カーソルがパズル範囲から出てしまわないためにはパズル範囲の周囲や足元に敷き詰めたイベントのすり抜けオンオフ機能を使いました。
周囲は通行不可のイベントで囲んだのは言うまでもありません。
それに加えて、カーソルの一部が周囲に食い込まないようにするのも同じ機能を使っています。
カーソルは縦と横に向きを変えますが、透明の主人公の位置はカーソルが横向きなら左側、縦向きなら上側なのです。
なので対策を講じないと、例えばカーソルが横向けの時には右側が周囲の通行不可マスにかぶってしまうのです。
それを防ぐためにパズル枠内、通行可能範囲の右端、および下端に、イベントを並べました。
起動条件を「その時のカーソルの向きを示す変数」にしてすり抜けは不可にし、そのイベントが存在する時だけそちらには進めないようにしました。
また、カーソルを切り替えた時に枠に食い込むような位置にいた場合は、「場所移動」で透明の主人公を隣のますに瞬間移動させました。
何というか非常に泥臭い方法ばかりですが、それらのおかげで非常に簡単に作れました。
このようなパズルを作る時にここまで歩行システムやマップイベントを活用するというのはひょっとしたら珍しいかもしれないので、少し詳し目に書いてみた次第です。
ただ、既存のシステムを流用したことによる弊害もなかったわけではありません。
一番大きいのは、パズル範囲を画面中央に表示できないことです。
ウディタではどの画面サイズを取ろうとも縦・横に敷き詰めるマスの数は偶数です。
なので画面中央に一つのますを表示することは難しいし、奇数マスからなる何かを中央に置くのも大変です。
マップを使うゲームを作った経験のある方は、画面上下の部屋の出入り口などの幅が偶数ますだと偏るので困った方も多いと思います。
一応これには解決方法もないわけではないです。
全ての地形をイベントで配置し、マップが始まる直後に全てのイベントを半歩横へ移動すればいいです。
そのためのコモンも公式コモン集にて公開されていたと思います。
ただ今回のぼくの場合はそれも使えませんでした。
主人公の半歩移動が使えないからです。
マスを選択するためのカーソル移動なのに、カーソル位置がマスにぴったり重ならなかったら話になりませんもんね。
まあシステムを改造して、デフォルトの移動幅を半歩にしながらも停止位置がマスの真上なら強制的にさらに半歩進ませることもできるでしょうけど。
でもそこまでするとせっかく歩行システムを使っている利点がなくなってしまいそうだし、そうはしませんでした。（めんどうだし！）
おかげでパズル画面はわずかに右に寄っています。
そういえば「エフェクト」などを使って画面の表示位置を半歩分横にずらすこともできるのかも、とはちょっと思ったのですが。
でもぼくはエフェクトは苦手なのでやりませんでした。
エフェクトってピクチャ表示と相性が悪いじゃないですか。そうでもない？
今なんとなく思いついたけどウディタの描画演出をするのにピクチャ派とエフェクト派がいるかもしれませんね。
どっちも使いこなせたらそりゃいいけど、片方で事足りるケースが多そうな気もします。
まあぼくだってたまにはエフェクトも使いますけどね。
今回のぼら猫パズルでは・・・うーん、多分どこにも使ってません。
昨年のウディコンでは画像音声部門で高い評価をもらえましたが、こういう手抜きをプレイヤーは見てるかも知れませんね。
ほんのちょっと中央から偏ってるってだけでも、高い緊張感が保てない気はします。
まあ今回のゲームはゆるキャラとだらだら続けてもらいたいから緊張感はあんまりなくてもいいか。
話がそれましたが、それ以外のデフォルトシステム流用による弊害といえば、移動速度のことでしょうかね。
ゲームプレイを続けるとある時からカーソル移動速度を変更できるようになります。
これは主人公の「移動速度の変更」機能を使っています。
でもこれは細かい調整ができなくってね・・・。
通常だと快適なんですが、一つ遅くすると遅すぎてイライラするし、一つ早くすると操作性がすごく悪くなるし。
なので完成間際まで変更画面で「通常以外はお勧めしません」とか書いてお茶を濁していたんですけどね。
でもテストプレイヤーさんに「速いだと操作しにくい！」と残念がられてぼくは目が覚めました。
そりゃそうですよね。せっかく速くできるようになったのにそれが使い物にならないなんてストレスのもと以外の何物でもなく、無い方がましなくらいです。
そこでぼくは本気を出してがんばって、移動速度が速くても誤操作が起きにくいシステムを作りました。
主人公の座標を常時監視して、主人公がマスの真上を通過しようとした瞬間だけ、動作指定で数フレームだけ瞬間的に足止めする、という方法です。
これをすることで、移動速度を速めても意図したのに近い操作ができるようになりました。
ちなみにこれを作るためには使えそうで使えない方法がありましてね。
このブログでも何度か取り上げた、システム変数の「主人公が移動中？」というやつです。
鏡コモンを作る時に詳細にみた通り、この変数は主人公がマスの真上にいるのかどうかを判定できるんですけどね。
理屈上ではぼくがわざわざ座標を取得してやっているのと同じことを判定できそうなのですが。
けれどもこれは移動速度が速い連続移動中はマスの真上も瞬間的に素通りしてしまうんです。
それを知っていたので使いませんでした。
そういうことを思うと移動っていったい何だろうと考えてしまいます。
移動速度というのはマスからマスへ何フレームかけて到達するかなのでしょうかね。
その速度で移動開始をしたら、１フレームごとに何ピクセル移動するかが決まっているんでしょうね。
そしてキャラの瞬間瞬間の厳密な座標によって、キャラが今の瞬間いるマスがどこかとか、マスの真ん中にいるかとか、決まるんでしょうね。
少し話がそれるけど、昔習った数学の問題を思い出しまいた。
「たかし君が時速Aキロで池の周りをまわって、１０分後にスタート地点にいる確率はいくらでしょう？」
これ、正解はなんと０％なんですって。これにはびっくりした！今でも忘れません。
たまたまそこにいることだってあるだろうと思うんですけどね。
よりによって、一ミリもたがわず、その瞬間にその場所にぴったりといるということなんて、もう限りなく０に近いくらいありえないことらしいです。
そうだとするならば、そりゃあマスの真上を瞬間的に通過していくキャラを、１フレームに一回しか判定されないシステム変数が捕捉できる可能性は低いのかもしれませんね。
そう思うと１フレームって限りなく瞬間に近い概念と思っていたけれども、移動距離との関係でいえば全然瞬間なんかじゃないんですね。
１フレームって、意外と粗い。
これは今回のぼら猫パズルの制作で身に染みたことであって、これ以外の所でもまた出てくる命題です。
それについてはまた明日とかに書きます。
一回目の今回は、パズルゲームであってもデフォルトシステムをフル活用したということを書いてみました。
書き忘れていることもあるかもしれないけど。
興味のある方は参考にしてください。
質問もお待ちしています。
それと全然関係ない話ですが。
今作で一つだけお借りしたコモンがあります。
表記の義務はなくスペースの都合もあってゲーム内などでは表示しませんでしたが。
ひげさんの文字表示拡張コモンを公式コモン集よりお借りしました。
制作に興味のある人しか見ないだろうこの場を借りてお礼申し上げます。
ありがとうございました。
ゲーム開始直後にタイトルが上から降ってきてプルプルなるのにこのコモンを使っています。
おかげでかわいらしい演出ができました。
では、続きはまた次回ということで。
2016年06月04日
サークル活動開始しました
きみのなまえをよばせてください
というサークルを相方さんと二人ではじめました。
当面は個人での制作は予定がないので、今後の活動報告などはそちらの方ですることになるかもしれません。
かといって、いままででもこのブログに作成中ゲームの情報とかはほとんど書いたことはなかったですけどね。
ウディタの技術面のこととかは、引き続きこっちに書くと思います。
今後もよろしくお願いします。
2016年03月10日
できなかったこと②
基本システムの改造をしていて、戦闘コマンドに装備変更という項目を追加しました。
メニューから呼び出す装備変更コマンドを呼び出し、「戦闘中に呼び出されていたなら終了後にメニューを開かない」という処理を入れることで、戦闘中に装備変更できるようになりました。
戦闘コマンドの特徴としては、ターンを消費せず、ターン開始前に何度でも実行できます。
それと同時に、装備武器によって戦闘コマンドを変更する仕組みも実装しました。
戦闘開始時に装備中の武器が単体攻撃か全体攻撃かを判定し、コマンド名を「単体攻撃」「全体攻撃」のいずれかにします。
それも実装できたのですが、戦闘中の装備変更と両立させることはできませんでした。
ターンを消費するコマンド内で装備を変更したところ、次ターンの開始前に出る戦闘コマンドは更新することはできたのですが。
ターン前に装備武器を替えようが戦闘コマンド変更をしようが、コマンド名は変更されることなく・・・。
まあ当然ですよね。
デフォルトの基本システムでは戦闘コマンドを表示後、次回表示の時（ターン後）までに再表示されることは想定されていませんもんね。
そこでコマンド変更処理に続けて、戦闘コマンドリストを改めて再表示する処理も入れたりしたのですが、やはりうまくいきませんでした。
基本システムの戦闘の流れの根幹部分ですもんね。なかなか、中途半端な知識では手を加えられません・・・。
基本システムを使うくらいならシステム自作する方が簡単だという人がいるのもうなずける気がしました。
メニューから呼び出す装備変更コマンドを呼び出し、「戦闘中に呼び出されていたなら終了後にメニューを開かない」という処理を入れることで、戦闘中に装備変更できるようになりました。
戦闘コマンドの特徴としては、ターンを消費せず、ターン開始前に何度でも実行できます。
それと同時に、装備武器によって戦闘コマンドを変更する仕組みも実装しました。
戦闘開始時に装備中の武器が単体攻撃か全体攻撃かを判定し、コマンド名を「単体攻撃」「全体攻撃」のいずれかにします。
それも実装できたのですが、戦闘中の装備変更と両立させることはできませんでした。
ターンを消費するコマンド内で装備を変更したところ、次ターンの開始前に出る戦闘コマンドは更新することはできたのですが。
ターン前に装備武器を替えようが戦闘コマンド変更をしようが、コマンド名は変更されることなく・・・。
まあ当然ですよね。
デフォルトの基本システムでは戦闘コマンドを表示後、次回表示の時（ターン後）までに再表示されることは想定されていませんもんね。
そこでコマンド変更処理に続けて、戦闘コマンドリストを改めて再表示する処理も入れたりしたのですが、やはりうまくいきませんでした。
基本システムの戦闘の流れの根幹部分ですもんね。なかなか、中途半端な知識では手を加えられません・・・。
基本システムを使うくらいならシステム自作する方が簡単だという人がいるのもうなずける気がしました。
2016年01月20日
できなかったこと①
ウディタであんなことできた、こんなことできたとブログに書くと自慢みたいだとちょっと思っていたのです。
なのでできなかったことも書いていきます。
・戦闘中のセーブ
基本システム改造しているのですが、戦闘コマンドにセーブがあったら斬新かなと思って試してみました。
技能に「セーブ」をつくってセーブのコモンを呼び出しました。
技能としてコモンを呼び出す時は引数が指定できずに悩みました。
モードを指定しないとセーブを閉じた後メニューが開いてしまうのです。
そこで考え、セーブコモンを複製し、片方は戦闘専用にしました。
そのコモンの冒頭に変数操作を入れることで、閉じた後にもメニューが開かないセーブができました。
さっそくセーブし、ロードしたら・・・あぁ、だめでした！
あわよくば戦闘の続きを再開できたらと期待していたのですが。
ロードするとかろうじて敵ピクチャなどは表示されていますが、戦闘状態は終わっていて、マップ上を自由に歩けました。
セーブをすると変数やＤＢの情報は記録され、そしてロードで再現できるのかもしれません。
けれどもどのイベントをどこまで実行中というのまでは記録できず、再開もできないのかもしれません。
戦闘を制御するコモンを実行中の中途でセーブしても、その時点でそのコモンを自動実行するような状況になっているわけではないから、ロード後も戦闘にならないのでしょうね。
ものすごくがんばればなんとかできるのかもしれませんが、大変そうなのであきらめます。
余談ですが、戦闘中のセーブを思い付いたきっかけも書き残しておきます。
それは我が家の家族たちの会話でした。
「もうゲームやめなさいー！」
「この戦闘終わるまでもうちょっと待って！」
このやりとりは毎日のように繰り返されています・・・。
できなかったことがあったらまた書きます。
2016年01月11日
＜ウディタ＞ 「薬草 x1」っていったい何なの！
このところずっと基本システムを改造しています。
基本システムと言えば前から気になっていたのがこれ、「薬草 x1」とかの表示。
基本システムではアイテムや装備の所持数を示すのに、xが使われてます。
そりゃ、見たら意味は分かるけど・・・。
でもxはエックスです！
どう見てもただのアルファベットですから！
これが個数をあらわすなんて、しかもそれがウディタでゲームを作る「基本」に組み込まれているなんて、おかしいー。
まあ基本システムが基本じゃないというのは散々言われていることですけどね。
というわけで、このxの変え方を書いておきます。
基本システムのコモン110番の２９行目、１０３行目、１６３行目あたりでデータベースにxを書き込んでいる所があります。
これを×(かける)とかに変えたらいいです。
ついでに、装備変更コマンドもデフォルトで使うなら、コモン112番の１９５行目あたりも同じように修正したらいいです。
（後日追記：コモン９９番の８５行目にもエックスがありました！修正してください。）
これで大丈夫！
「薬草 x1」とかの不思議な表示はなくなると思います。
こういう、ほんのちょっとした部分の修正を積み重ねていけば、基本システム臭さが大分薄れるんじゃないかと期待しながら作業しています。
Ｘ×XxｘＸ×XxｘＸ×XxｘＸ×XxｘＸ×XxｘＸ×XxｘＸ×XxｘＸ×XxｘＸ×XxｘＸ×Xxｘ
追記
ブログに表示されてるのを見たら、ぼくの環境ではxでもそれなりに「かける」に見えてしまいます。
x×
左がエックスで右が「かける」。
どっちもただのバツですね。
でもウディタでは違うから！
所有数を表す時のＸには4隅に短い横棒がついているから気になるんですー。
あ、もしかして「使用フォントが気に入らないなら変えたら」っていうだけの話？
ちがうー。エックスは「かける」じゃないー！
なんだかこう書いていると自分だけ神経質でいちゃもんつけている気分になってきました。
共感してくれる人がもしいたら、基本システムを使うときはこの記事を参考にしてください。
2015年11月06日
マップイベントが表示中の画像名は何かを知る方法
ぼくが作った鏡コモンはパーティーメンバーを映せませんでした。
その理由は２つくらいあります。
まず「パーティーメンバーにもマップイベントＩＤが割り振られている」ことをぼくは知らなかったこと。
そして何より「マップイベントが表示中の画像名を知る方法」があるとは知らなかったこと。
まあ仮に知っていたとしても、意欲が尽きて作れなかった公算が大ですが・・・。
非常に複雑なコモンをコツコツ作って完成させ、鏡コモンの機能を飛躍的に拡張してくださったソフトニシンさんには感謝してもしきれません。
ソフトニシンさんはコモンをもちろん公開され、参考にすることを推奨してくださっているので、ここに自分のメモ的な意味も込めてまとめておきます。
マップイベントが現在表示中の画像名を知る方法。
これこそが、ソフトニシンさんが公開してくださった鏡コモン２種のキモとなる部分です。
個人的にそう思ってます。
コモン自体は本当に長い長いものですが、それはほんの３行です。
■変数操作: CSelf15 *= 10 + 0
■変数操作: CSelf15 += 9100009 + 0
■文字列操作：CSelf7 = 位置[CSelf15]の文字列
たったこれだけ。
コモンセルフ１５番に、画像名を知りたいマップイベントのＩＤを入れます。
そしてこの３行を実行すれば、コモンセルフ７番に歩行グラなどの画像ファイル名が返されます。
なんでそんなことになるんだ～。
というのは悩んでも仕方ないので、これはどうやらありのままを素直に受け入れるのがいいようです。
ぼくが今まで作ったコモンでいうなら、階段の上り下りするコモンでも、主人公の表示高さを変更するのにこれと似た機能を使いました。
とにかく変数呼び出し値はただ者ではないとしか言いようがありません。
しかもこの３行のすごいところは、返ってくる画像名がその時点での最新情報だということです。
ページ切り替えや起動条件を満たさなくなるなどでそのマップイベント画像が消えた時、返される文字列はちゃーんと空白になります。
なんて便利なんでしょう！
ぼくが現在作っているゲームでは、主人公の前方隣接ますにいるマップイベントに対して、決定とはまた別のキーを使って決定とはまた別のアクションをするということを実装しています。
キー判定自体は基本システムの「歩行時並列処理」を流用してキー入力だけ変更したらできたのですが。
ただ、キーを押したときに前方にマップイベントがあったら反応するとした場合、キャラグラを表示していないイベントに対しても起動してしまうので困っていました。
そこでこのソフトニシンさんが使われていた方法を思い出したわけです。
この３行を実行して帰ってきた文字列が、
””（空白）と同じなら
マップイベント画像は表示されていない。
それ以外なら
マップイベント画像は表示されている。
そういうことが分かります。あー助かったー！
ソフトニシンさん、ありがとうございます！
あ、ちなみに、ぼくが知らなかったもう一つのこと、パーティーメンバーのマップイベントＩＤは何番なのかということですが・・・。
ここをお読みのみなさん、知りたいですよね？どうです？
（ぼくの想像では７割の方が興味ない、１割の方がもう知ってる、２割の方が知りたい、くらいかな？）
まあ、そこまで何もかも書いてしまうのもソフトニシンさんに気が引けるし、それはぜひ立ち鏡コモンなどをＤＬして確認してもらえたらと思います。
コメントでしっかり説明を入れてくれてるので、とても分かりやすくて勉強になります。
2015年10月25日
＜ウディタ＞文字影機能を誤解していました
ウディタで文字を表示する時に便利な機能の一つに文字影をつけるというのがあります。
これはシステム変数２１番で指定でき、デフォルト（基本システム）では１になっています。
この数値は「そのピクセル数離れた位置に黒い影を表示する」ということを表します。
この機能、なんと表示済みの文字にも適応されるのです。
どういうことかというと、Sys21=0の時に表示した文字でも、後からSys21=１とかになった時には影が表示されるのです。
ぼくはこれを勘違いしていて、文字の性質変化をさせる特殊文字と同じように使えるのかと思ってました。
例えば一つの文章の中でも影ありと影なしを切り替えられるのかと思ってました。
そして影なし状態で文章表示後影あり状態にして別の文章を表示し、両方とも影がないもんだから、ナンデダ～ナンデダ～と小一時間悩みました。
影の有無を同時に併用することはできないんですね。
検索してもそのようなことはどこにも載ってなかったです。
ぼくみたいな勘違いをする人は少ないのかもしれませんね。
文字影が表示されない、と悩んでる方がもしいたら、それはひょっとしたら表示後にSys21を変更しているのかもしれません。
そういった使い方はできないようです、残念ながら・・・。
これはシステム変数２１番で指定でき、デフォルト（基本システム）では１になっています。
この数値は「そのピクセル数離れた位置に黒い影を表示する」ということを表します。
この機能、なんと表示済みの文字にも適応されるのです。
どういうことかというと、Sys21=0の時に表示した文字でも、後からSys21=１とかになった時には影が表示されるのです。
ぼくはこれを勘違いしていて、文字の性質変化をさせる特殊文字と同じように使えるのかと思ってました。
例えば一つの文章の中でも影ありと影なしを切り替えられるのかと思ってました。
そして影なし状態で文章表示後影あり状態にして別の文章を表示し、両方とも影がないもんだから、ナンデダ～ナンデダ～と小一時間悩みました。
影の有無を同時に併用することはできないんですね。
検索してもそのようなことはどこにも載ってなかったです。
ぼくみたいな勘違いをする人は少ないのかもしれませんね。
文字影が表示されない、と悩んでる方がもしいたら、それはひょっとしたら表示後にSys21を変更しているのかもしれません。
そういった使い方はできないようです、残念ながら・・・。
2015年10月14日
＜ウディタ＞仲間を動かしても隊列を乱さない方法
昨夜仲間を動かしてはいけないと書きましたが、その問題の解決法をみつけました。
場所移動を使うことで隊列の乱れはなおります。同じ位置に移動しなおしてもいいです。（一瞬なので見た目はわかりません）
また「パーティー画像」からでききる「全員を主人公の位置にワープ」でもなおります。
仲間を移動したイベントシーンが終わって移動開始になる直前にどちらかを実行すれば、隊列が乱れることはありません。
もしもパーティの隊列がおかしいと思ったら試してみてください。
昨夜の記事がタイトル詐欺みたいになってしまった・・・。
場所移動を使うことで隊列の乱れはなおります。同じ位置に移動しなおしてもいいです。（一瞬なので見た目はわかりません）
また「パーティー画像」からでききる「全員を主人公の位置にワープ」でもなおります。
仲間を移動したイベントシーンが終わって移動開始になる直前にどちらかを実行すれば、隊列が乱れることはありません。
もしもパーティの隊列がおかしいと思ったら試してみてください。
昨夜の記事がタイトル詐欺みたいになってしまった・・・。
2015年10月13日
＜ウディタ＞仲間を動かしてはいけません
------------------------------------------------------------------------------------
翌日追記
ここに書いた問題を簡単に解決する方法がありました。
次の記事へ
------------------------------------------------------------------------------------
動作指定でパーティーメンバーを動かすことができます。
上に移動とか。
でもこれをしたら、その後のパーティーの隊列の動きがおかしくなります。
右右と2マス動かした後に左左と動かし元の同じ位置に戻したとしても、それでもやはりおかしくなります。
これについて細かく説明します。
まずパーティーメンバーに動作指定をすると、指定した通りの動きをします。
その後彼彼女を引き連れて移動すると、本来いるべき位置を基準として移動で変化した位置関係を保持しつつ、ついてきます。
例えば右上に移動させたのなら、いるべき場所の右上にいつも来ます。
それだけだったらいいんですけども・・・。
その仲間の動くべき場所に行けない場合に問題が起こります。
行けない場合とは、その場所が通行できない場合とそしてその場所がマップ外の場合です。
ひきつれた仲間の挙動も、主人公などと同じようにすり抜けの可と不可を個別に設定できますが。
それですり抜け不可にした日なんかにはもう、すぐにどこかに引っかかっておかしくなります。
そしてすり抜け不可にしなくても、主人公がマップの端近くを移動して仲間の行くべき場所が画面外になった場合にやはりおかしくなります。
なので、仲間を移動して連れ歩いても不具合を起こさないためには・・・。
「仲間をすり抜け不可にしない」「主人公がマップの端に近寄れないようにする」「主人公の通行可能な範囲内に通行不可のマスを作らない」
この3つが必要になります。
まあシナリオ上仲間が最終離脱する際、「さよならー」と離れて行ってその後二度と隊列に復帰しないのならいいかもしれませんけど。
それとかラスボスに挑戦する前とか。
ともかく普通に仲間を連れ歩く途中ではは動かさないことが一番です。
とはいえシナリオイベント時には仲間を動かしたい場面も多々あるでしょう。
そういう時はウディタのシステムに組み込まれた仲間でなく、マップイベントを使うのが賢明です。
仲間を移動したくなったらその仲間を一時的にパーティーから外し、同時にマップイベントの起動条件を操作して出現させ、そちらに対して動作指定してください。
ちなみにさっきから動きがおかしくなるおかしくなると言ってますが、一体どうおかしくなるのかと言えば
・進行方向に応じて隊列の間隔が変わったり
・先頭主人公と別の方向に進むようになったり
などします。
つまりは無茶苦茶です。
ただし動くタイミングだけはさすがに同じですけど。
結束力の弱いパーティーを演出したいときにはあえてこの挙動を利用してもいいかもしれません。
みんなてんで勝手に好き放題、バラバラに動くので。
なお複数の仲間を連れている時に一人だけ移動させると、その一人以外はちゃんといるべき位置についてきます。
これはこれで協調性のない仲間の演出に使えるかもしれませんね。
そういえば。普段パーティーメンバーを連れ歩いているＲＰＧをしていても、イベントシーンではなぜかいきなり主人公一人の画像になり、定位置到着後にメンバーが左右に展開するとかよく見ますよね。
引き連れると事と個別の動作指定との相性が悪いからそんなことになるのかもしれません。
それにしてもこれはバグなのかな。
仲間の動作指定をしてもほとんど使い物にならないという点ではバグと言えるのかもしれませんが。
まあこれをどう利用すればどんな挙動をするのか、検証すればわかるのだから、必要に応じてかしこく使いこなせれたらいいですね。
なお、この記事で言っている仲間を動かすというのは動作指定を使った位置移動のことです。
その場でのジャンプや向きの変更は問題ないので安心して使ってください。
翌日追記
ここに書いた問題を簡単に解決する方法がありました。
次の記事へ
------------------------------------------------------------------------------------
動作指定でパーティーメンバーを動かすことができます。
上に移動とか。
でもこれをしたら、その後のパーティーの隊列の動きがおかしくなります。
右右と2マス動かした後に左左と動かし元の同じ位置に戻したとしても、それでもやはりおかしくなります。
これについて細かく説明します。
まずパーティーメンバーに動作指定をすると、指定した通りの動きをします。
その後彼彼女を引き連れて移動すると、本来いるべき位置を基準として移動で変化した位置関係を保持しつつ、ついてきます。
例えば右上に移動させたのなら、いるべき場所の右上にいつも来ます。
それだけだったらいいんですけども・・・。
その仲間の動くべき場所に行けない場合に問題が起こります。
行けない場合とは、その場所が通行できない場合とそしてその場所がマップ外の場合です。
ひきつれた仲間の挙動も、主人公などと同じようにすり抜けの可と不可を個別に設定できますが。
それですり抜け不可にした日なんかにはもう、すぐにどこかに引っかかっておかしくなります。
そしてすり抜け不可にしなくても、主人公がマップの端近くを移動して仲間の行くべき場所が画面外になった場合にやはりおかしくなります。
なので、仲間を移動して連れ歩いても不具合を起こさないためには・・・。
「仲間をすり抜け不可にしない」「主人公がマップの端に近寄れないようにする」「主人公の通行可能な範囲内に通行不可のマスを作らない」
この3つが必要になります。
まあシナリオ上仲間が最終離脱する際、「さよならー」と離れて行ってその後二度と隊列に復帰しないのならいいかもしれませんけど。
それとかラスボスに挑戦する前とか。
ともかく普通に仲間を連れ歩く途中ではは動かさないことが一番です。
とはいえシナリオイベント時には仲間を動かしたい場面も多々あるでしょう。
そういう時はウディタのシステムに組み込まれた仲間でなく、マップイベントを使うのが賢明です。
仲間を移動したくなったらその仲間を一時的にパーティーから外し、同時にマップイベントの起動条件を操作して出現させ、そちらに対して動作指定してください。
ちなみにさっきから動きがおかしくなるおかしくなると言ってますが、一体どうおかしくなるのかと言えば
・進行方向に応じて隊列の間隔が変わったり
・先頭主人公と別の方向に進むようになったり
などします。
つまりは無茶苦茶です。
ただし動くタイミングだけはさすがに同じですけど。
結束力の弱いパーティーを演出したいときにはあえてこの挙動を利用してもいいかもしれません。
みんなてんで勝手に好き放題、バラバラに動くので。
なお複数の仲間を連れている時に一人だけ移動させると、その一人以外はちゃんといるべき位置についてきます。
これはこれで協調性のない仲間の演出に使えるかもしれませんね。
そういえば。普段パーティーメンバーを連れ歩いているＲＰＧをしていても、イベントシーンではなぜかいきなり主人公一人の画像になり、定位置到着後にメンバーが左右に展開するとかよく見ますよね。
引き連れると事と個別の動作指定との相性が悪いからそんなことになるのかもしれません。
それにしてもこれはバグなのかな。
仲間の動作指定をしてもほとんど使い物にならないという点ではバグと言えるのかもしれませんが。
まあこれをどう利用すればどんな挙動をするのか、検証すればわかるのだから、必要に応じてかしこく使いこなせれたらいいですね。
なお、この記事で言っている仲間を動かすというのは動作指定を使った位置移動のことです。
その場でのジャンプや向きの変更は問題ないので安心して使ってください。
2015年08月25日
＜ウディタ＞文章スキップ
fairy song～歌う革命～が思っていたより多くの方に楽しんでもらえているようでうれしいです。
あのゲ―ムの魅力は音楽・シナリオ・デザインに尽きるのですが、システム面としては「スキップ機能があってよかった」という感想をお聞きしました。
スキップさせるコモンは公式コモン集でも見かけた気がしますが（中は確認していないのですが）、この記事では自己流で作った方法を紹介します。
まず文章スキップではないのですが、オープニングにある文章スクロールでは文章移動中でもシフトを押すといつでも次に飛べるようにしました。
これは最初に文字列ピクチャを２３００ﾌﾚｰﾑかけて指定座標まで移動するように設定しています。
その後に回数つきループを置き、回数は２３００回に設定しています。
そしてそのループの中でまずスキップキーのキー入力を取得し、押されていたらループから出で移動中文章を消すようにし、押されていなければ１フレームウェイトするようにしました。
これで、毎フレームキー入力をを監視しつつも押されない限りは実質２３００フレームウェイトするようにできました。
イベント中の文章スキップについては、通常やるように文章表示をいくつも連続でならべて、それでキーに応じてスキップさせる方法はぼくには思いつきませんでした。
なので少し手間のかかる方法をとっています。
今回のゲームのイベント部分、会話吹き出し内の表示内容は、全てデータベース内に並べて入れておきました。（そのデータベース入力する際にＣＳＶ入力の便利さを知りました）
イベントが始まったらやはり同じくループ内でキー入力を取得し、押されてたらループから出る、押されてなければ「何番目の文章を表示するか」という変数に応じた場所の文章を表示してその変数に＋１する、というようにしました。
（顔グラ番号を指定する数値も同じ文章の冒頭に入れたのですがそれはまた別の話です・・・）
これらのやり方が普通なのかそうでないのか知りませんが、同じようなものを作りたいと思っている人にもしも参考になればいいと思います。
fairy song～歌う革命～は非暗号化での一般公開予定はありませんが、システム上の質問などありましたらメールで連絡をもらえたら対応させてもらいます。
あのゲ―ムの魅力は音楽・シナリオ・デザインに尽きるのですが、システム面としては「スキップ機能があってよかった」という感想をお聞きしました。
スキップさせるコモンは公式コモン集でも見かけた気がしますが（中は確認していないのですが）、この記事では自己流で作った方法を紹介します。
まず文章スキップではないのですが、オープニングにある文章スクロールでは文章移動中でもシフトを押すといつでも次に飛べるようにしました。
これは最初に文字列ピクチャを２３００ﾌﾚｰﾑかけて指定座標まで移動するように設定しています。
その後に回数つきループを置き、回数は２３００回に設定しています。
そしてそのループの中でまずスキップキーのキー入力を取得し、押されていたらループから出で移動中文章を消すようにし、押されていなければ１フレームウェイトするようにしました。
これで、毎フレームキー入力をを監視しつつも押されない限りは実質２３００フレームウェイトするようにできました。
イベント中の文章スキップについては、通常やるように文章表示をいくつも連続でならべて、それでキーに応じてスキップさせる方法はぼくには思いつきませんでした。
なので少し手間のかかる方法をとっています。
今回のゲームのイベント部分、会話吹き出し内の表示内容は、全てデータベース内に並べて入れておきました。（そのデータベース入力する際にＣＳＶ入力の便利さを知りました）
イベントが始まったらやはり同じくループ内でキー入力を取得し、押されてたらループから出る、押されてなければ「何番目の文章を表示するか」という変数に応じた場所の文章を表示してその変数に＋１する、というようにしました。
（顔グラ番号を指定する数値も同じ文章の冒頭に入れたのですがそれはまた別の話です・・・）
これらのやり方が普通なのかそうでないのか知りませんが、同じようなものを作りたいと思っている人にもしも参考になればいいと思います。
fairy song～歌う革命～は非暗号化での一般公開予定はありませんが、システム上の質問などありましたらメールで連絡をもらえたら対応させてもらいます。
2015年08月23日
＜ウディタ＞ 特定マスにキャラがいるかどうか判定する方法
現在製作中のゲームではマップを歩くのですが、主人公のみピクチャで表示するためＮＰＣ（以下キャラ）との重なりを調整するために使用ピクチャ番号を切り替えます。
＜関連ページ：主人公のピクチャ番号をどうしよう？＞
キャラが近くにいる場合のみピクチャ番号を大きくすることで、主人公が後ろに隠れるのを防ぎます。
ここで、特定マスにキャラがいるのかどうか判定する必要がでてきます。
それをするにはいろいろな要素を加味せねばならず、頭がこんがらがったのですが、表に書いて整理することでようやく見通しが立ったので忘れないように書いておきます。
特定マスにキャラがいるのかどうかをみるには、自分ルールを２つ作ればあとは変数操作＋を使った条件分岐２つで判定できそうです。
＜自分ルール２つ＞
・通行不可タイルにはキャラを置かない
・キャラの「すりぬけ」にチェックを入れない
この前提があれば、「タイルのみ」と「タイル＆イベント」の二種の通行設定をみるだけでいいです。
「タイルのみ」が通行可能でなおかつ「タイル＆イベント」が通行不可の場合のみ、そこにキャラがいると分かります。それ以外の場合はキャラはいません！
こう書くとシンプルなんですけど、これを思いつくまでにはイベントＩＤを取得してイベントの有無をみるとか画像設定しないマップイベントをどう判定するかとかいろいろ考えました。難しかったです。
自分ルールに例外を作りたい時も出てくるかもしれませんが、その時は「プレイヤー接触」でピクチャ番号を変更するような仕組みを個別に作って対処しようと思っています。
＜関連ページ：主人公のピクチャ番号をどうしよう？＞
キャラが近くにいる場合のみピクチャ番号を大きくすることで、主人公が後ろに隠れるのを防ぎます。
ここで、特定マスにキャラがいるのかどうか判定する必要がでてきます。
それをするにはいろいろな要素を加味せねばならず、頭がこんがらがったのですが、表に書いて整理することでようやく見通しが立ったので忘れないように書いておきます。
特定マスにキャラがいるのかどうかをみるには、自分ルールを２つ作ればあとは変数操作＋を使った条件分岐２つで判定できそうです。
＜自分ルール２つ＞
・通行不可タイルにはキャラを置かない
・キャラの「すりぬけ」にチェックを入れない
この前提があれば、「タイルのみ」と「タイル＆イベント」の二種の通行設定をみるだけでいいです。
「タイルのみ」が通行可能でなおかつ「タイル＆イベント」が通行不可の場合のみ、そこにキャラがいると分かります。それ以外の場合はキャラはいません！
こう書くとシンプルなんですけど、これを思いつくまでにはイベントＩＤを取得してイベントの有無をみるとか画像設定しないマップイベントをどう判定するかとかいろいろ考えました。難しかったです。
自分ルールに例外を作りたい時も出てくるかもしれませんが、その時は「プレイヤー接触」でピクチャ番号を変更するような仕組みを個別に作って対処しようと思っています。
ラベル：ウディタ
2015年08月03日
fairy song～歌う革命～の紹介サイトにおまけページが追加されました！
fairy song～歌う革命～の紹介サイト
こちらにおまけページができました！
fairy song～歌う革命～の世界をより楽しんでもらえる場所なので、ゲームを気に入って下さった方にはのぞいてもらいたいです。
ただしここを見るにはパスワードが必要です。
「HappyEnd」クリア後に「イベントリスト」を見てもらうとヒントになる文章があるので、まだのかたはぜひまずは「HappyEnd」クリアに挑戦して下さい！
こちらにおまけページができました！
fairy song～歌う革命～の世界をより楽しんでもらえる場所なので、ゲームを気に入って下さった方にはのぞいてもらいたいです。
ただしここを見るにはパスワードが必要です。
「HappyEnd」クリア後に「イベントリスト」を見てもらうとヒントになる文章があるので、まだのかたはぜひまずは「HappyEnd」クリアに挑戦して下さい！
ウディタの超基本、マップイベント起動条件「決定キーで実行」について
今までウディタで作品をいくつか作ってきたぼくなのに、こんな基本的なことをわかってなかっただなんてびっくりしました、というお話・・・。
マップイベント起動条件「決定キーで実行」についてです。
この起動に、通行設定が関係してるってしっていました？
ぼくは知らなかった・・・。
今までなんとなく感覚的にやってたんですね。
マップイベントの位置に主人公が行けない場合、隣接マスからそちらを向いて決定を押せば実行。
マップイベントの位置に主人公が行ける場合、同じ位置（※）に立って決定を押せば実行。
（※さらによく確認したところ、歩幅設定が半歩の場合は左右のズレは全くない状態でないと起動せず、上下の場合は半歩のずれがあっても起動するようです。）
そのような仕様になっています。つまり気をつけるべきことは
マップイベントの位置に主人公が行ける場合、隣接マスからそちらを向いて決定を押しても実行しない！
ということです。
感覚的にはわかっていたから問題はなかったけど、意識したこともなかったです。
行ける場合、行けない場合と言うのは文字通りの意味なのですが。
通常ＮＰＣに話させる場合など、主人公やキャラを「すりぬけにチェック」しない限りはキャラ画像位置に行けないため、自然と隣接マスから話しかけることになり決定で起動できます。
またマップイベントにキャラ画像を設定しない場合（つまりそのマスを自由に通行可）でも、たとえばマップチップの配置で崖の上にマップイベントがあってその下から主人公が決定を押す場合それでも「行けない」には違いないのでやはり隣接マスから決定で起動できます。
でも行ける時は行かなきゃダメ！ということですね。
行ける行けないによって挙動が違うとは、驚きました。
ウディタを使う人なら初心者でも「画像のあるＮＰＣには話して実行」「足元が怪しい部分で決定キーで調べて実行」ということをすんなり実現できます。
これはよく考えたら別のことをやっているのですが、それが同じ「決定キーで実行」で実現できて感覚的なゲーム作りが可能になっていることは本当にすごいと思いました。
マップイベント起動条件「決定キーで実行」についてです。
この起動に、通行設定が関係してるってしっていました？
ぼくは知らなかった・・・。
今までなんとなく感覚的にやってたんですね。
マップイベントの位置に主人公が行けない場合、隣接マスからそちらを向いて決定を押せば実行。
マップイベントの位置に主人公が行ける場合、同じ位置（※）に立って決定を押せば実行。
（※さらによく確認したところ、歩幅設定が半歩の場合は左右のズレは全くない状態でないと起動せず、上下の場合は半歩のずれがあっても起動するようです。）
そのような仕様になっています。つまり気をつけるべきことは
マップイベントの位置に主人公が行ける場合、隣接マスからそちらを向いて決定を押しても実行しない！
ということです。
感覚的にはわかっていたから問題はなかったけど、意識したこともなかったです。
行ける場合、行けない場合と言うのは文字通りの意味なのですが。
通常ＮＰＣに話させる場合など、主人公やキャラを「すりぬけにチェック」しない限りはキャラ画像位置に行けないため、自然と隣接マスから話しかけることになり決定で起動できます。
またマップイベントにキャラ画像を設定しない場合（つまりそのマスを自由に通行可）でも、たとえばマップチップの配置で崖の上にマップイベントがあってその下から主人公が決定を押す場合それでも「行けない」には違いないのでやはり隣接マスから決定で起動できます。
でも行ける時は行かなきゃダメ！ということですね。
行ける行けないによって挙動が違うとは、驚きました。
ウディタを使う人なら初心者でも「画像のあるＮＰＣには話して実行」「足元が怪しい部分で決定キーで調べて実行」ということをすんなり実現できます。
これはよく考えたら別のことをやっているのですが、それが同じ「決定キーで実行」で実現できて感覚的なゲーム作りが可能になっていることは本当にすごいと思いました。
2015年07月26日
fairy song ～歌う革命～が完成！
以前こちらでひっそりご紹介した自作ゲーム、fairy song ～歌う革命～が完成し、ウディコンにエントリーしました。
画面はこんなの。
一応ぼく個人名義の作品になってはいますが、多くの方に深く深く関わっていただき、事実上共同製作でした。
自分ひとりの力では決して作れない作品ができました。
シナリオがすごいです。
グラフィックもすごいです。
音楽もすごいです。
テストプレイヤーの方にも助けられました。
感謝してもしきれません。
ゲーム内容は、シミュレーションです。
舞台となる「カノン王国」には音楽にこだわりのある国民たちが大勢います。
１０日に一度演奏会を開いて彼らの満足する曲を聴かせ、仲間にしてください。
そのためには日々音楽の練習をしたり、その他いろんなことにいそしむことが必要です。
５１日目に何人が仲間になっていたかでエンディングが分岐します。
ベストエンド（国民全員が仲間になる）が一番見てほしいエンディングなので、難しいかもしれませんがぜひチャレンジしてほしいです。
遊ぶ上での注意点は・・・。
イベントをスキップする時は左シフトキーを押す！
国民参加条件にある連続とは「現時点までの連続回数」なので別行動でリセットされる！
その２点だけ覚えておいて下さい。
（ここを見ただけでは何のことかわからないと思いますが）
ウディコンの順位にはこだわりませんが、関わって下さった方々に「手伝ってよかったー」と思ってもらえる結果が出せたら嬉しいなと思っています。
fairy song ～歌う革命～の紹介サイトはこちらです。
画面はこんなの。
一応ぼく個人名義の作品になってはいますが、多くの方に深く深く関わっていただき、事実上共同製作でした。
自分ひとりの力では決して作れない作品ができました。
シナリオがすごいです。
グラフィックもすごいです。
音楽もすごいです。
テストプレイヤーの方にも助けられました。
感謝してもしきれません。
ゲーム内容は、シミュレーションです。
舞台となる「カノン王国」には音楽にこだわりのある国民たちが大勢います。
１０日に一度演奏会を開いて彼らの満足する曲を聴かせ、仲間にしてください。
そのためには日々音楽の練習をしたり、その他いろんなことにいそしむことが必要です。
５１日目に何人が仲間になっていたかでエンディングが分岐します。
ベストエンド（国民全員が仲間になる）が一番見てほしいエンディングなので、難しいかもしれませんがぜひチャレンジしてほしいです。
遊ぶ上での注意点は・・・。
イベントをスキップする時は左シフトキーを押す！
国民参加条件にある連続とは「現時点までの連続回数」なので別行動でリセットされる！
その２点だけ覚えておいて下さい。
（ここを見ただけでは何のことかわからないと思いますが）
ウディコンの順位にはこだわりませんが、関わって下さった方々に「手伝ってよかったー」と思ってもらえる結果が出せたら嬉しいなと思っています。
fairy song ～歌う革命～の紹介サイトはこちらです。
2015年07月02日
＜ウディタ＞主人公をピクチャ表示する時、ピクチャ番号をどうしよう？
ウディタで主人公をピクチャとして表示するとアニメーションの切替パターン数を自由に設定したりいろいろできて便利ですが、その一方でデフォルトでは当たり前だった機能が使えず、工夫が必要となります。
この記事では主人公をピクチャ表示する時、ピクチャ番号は何番にするのがいいかを考えてみます。
ちなみに今回考えるのは、サンプルゲームのウルファールだけをピクチャ表示する場合です。
つまり主人公以外はデフォルト。地形にはタイルセット、他キャラにはマップイベントを使用します。
（全キャラをピクチャ表示したりすればまた話は変わってきますけどね。それはおそらくですが、ソフトニシンさんの鏡面床コモン改をちょっと劣化改造すればできると思います。興味のある方は挑戦して下さい）
主人公だけピクチャで表示するには、ぼくが公式コモン集に登録した「主人公演出セット」に入れたコモンを使ってくださいね。
さて、ピクチャ番号、どうしたらいいでしょう。
ピクチャ番号を迷った時にぼくがいつも見るのは公式マニュアルの「ピクチャ」の説明です。
ここに貼りつけさせてもらいます。
これは今まで１００回以上見たと思う。いい加減覚えろって感じですね。
・ピクチャ番号が100000(10万)未満なら文章や選択肢の下に表示
・ピクチャ番号が100000(10万)以上なら文章や選択肢の上に表示
・ピクチャ番号が-1～-99999なら、マップの上、かつ、イベントの下に表示
（★属性などの一部チップはピクチャの上に表示されます）
・ピクチャ番号が-10万以下なら、マップの下、かつ、遠景の上に表示
まず、タイルセット設定の「後ろに行くと隠れる」機能は使いたいです。
なので-1～-99999がいいですね。
デフォルトの木の上部やテントなどとの重なりを違和感なくしようとすれば、これは必須です。
ところが！
それでは問題が！
それは他キャラとの重なり方です。
「-1～-99999なら～イベントの下に表示」とのことなので、これでは主人公なのに他キャラより下層になってしまいます。
それも街の人などならまだよくよく見ないと分からない程度ですが、馬とか、横長キャラだと重なりがおかしいのは一目瞭然です。
なのでキャラの横にいる時はピクチャ番号は正の値がいいですね。
キャラの下（画面座標ｙ座標という意味での下）だとどうでしょう？
下でも同じく主人公が上層がいいので正の値がいいです。
一方、主人公がキャラの一つ上のマスにいる時は下層がいいので負の値がいいです。
「後ろに行くと隠れる」「他キャラとの適切な重なり」これを両立する一つのピクチャ番号はないようです。
面倒でも何とか小細工するしかないですね。
ぼくがした方法を書きます。
常時並列コモンで主人公の下や斜め下のマスにイベントがあるか常時判定します。
イベントがある時だけ、ピクチャ番号は負の値に切り替える。
また、「後ろに行くと隠れる」を使いたい個所付近には「プレイヤー接触」起動のイベントを敷いておいてピクチャ番号は負の値に切り替える。
「後ろに行くと隠れる」の近くにはキャラクターは置かない。
縦に上下、二人のキャラは並べない。
・・・こんなところです。
なおピクチャ番号の切り替え時には、それまでのピクチャ番号を消去するのを忘れないでください。
さもないと切り替えた地点に残像が残り続けてしまいます！
切り替えと同時にピクチャを消去したら一瞬主人公が消えたので、発動ディレイを２フレーム後くらいにしたらうまくいきました。
まあ、全キャラ高さも横幅も１マスサイズである１６ピクセル以下のものしか使わなければそんなことは悩まなくていいんですが・・・そうもいきません。
こういうことをやっているとデフォルトがいかに親切だったかがわかりますね。
ほら、これなんか。
下の馬と、上の馬と、その間の高さの主人公、３者がそれぞれ適切な階層に表示されています。
ぼくのやり方ではこれは難しいのです。
ちょっとした、気付くかどうかというくらいの重なりなんですけどね。
でもやっぱりこういう部分にこだわってみたい気もします。
追記
なんと、これと同じことをなさって同じことを説明されているブログ記事を発見！
しかもぼくの文章よりもわかりやすい！
勝手にリンクはっていいんだろうか・・・。
「リンクはご自由にどうぞ。」とあるぞ・・・じゃ、いいっか。
主人公のピクチャ表示に興味のある方はこちらも参考になさってください。
SUGAR STAR様のページ
2015年06月26日
「ウルファールの地底迷宮」が公開されました。
メロン企画というサークルの新作脱出ゲームウルファールの地底迷宮が公開されました。
ダウンロードはこちらから。
↓↓↓
ウルファールの地底迷宮.zip
ぼくはシステム担当として参加しました。
ゲーム内容は迷路です。
謎解きやフラグ立て、アイテム収集などの要素は一切ありません。
リソース管理といったことも（プレイヤーの時間を食う以外は）ありません。
シナリオやイベントはありますが、必須イベントは全て正解の経路上に配置しました。
迷路だから分かれ道は当然ありますが、攻略に関しては一本道です。
面白いかは別にして、結構納得のいく形のゲームができたと思っています。
これを突き詰めたらノベルになっていくのだろうなー。
素材は既成概念を吹き飛ばすクオリティのものを厳選しました。
短いゲームですのでお暇なときにどうぞ。
※このゲームは一時期ふりーむ！に登録していましたが現在はこのページから直接ダウンロードできます。
ふりーむ！にコメント下さった方、見れなくなって申し訳ありませんがありがとうございました。
ダウンロードはこちらから。
↓↓↓
ウルファールの地底迷宮.zip
ぼくはシステム担当として参加しました。
ゲーム内容は迷路です。
謎解きやフラグ立て、アイテム収集などの要素は一切ありません。
リソース管理といったことも（プレイヤーの時間を食う以外は）ありません。
シナリオやイベントはありますが、必須イベントは全て正解の経路上に配置しました。
迷路だから分かれ道は当然ありますが、攻略に関しては一本道です。
面白いかは別にして、結構納得のいく形のゲームができたと思っています。
これを突き詰めたらノベルになっていくのだろうなー。
素材は既成概念を吹き飛ばすクオリティのものを厳選しました。
短いゲームですのでお暇なときにどうぞ。
※このゲームは一時期ふりーむ！に登録していましたが現在はこのページから直接ダウンロードできます。
ふりーむ！にコメント下さった方、見れなくなって申し訳ありませんがありがとうございました。
2015年06月11日
≪ウディタ≫計算式で等号（代入）以外を使う時の、右辺にある項目二つの計算の優先順位について
大した内容ではないしウディタメモの一項目として書こうかと思いましたが、ちょっと簡潔に説明できなかったので一つの記事にします。
さて、タイトルですが何のことかややこしいですね。
例えば
ｖ１＝１
ｖ１＋＝３＊６
とした時、Ｖ１の値はどうなるのか。
これの答えは
ｖ１＝（１＋３）×６＝２４
になるか、あるいは
ｖ１＝１＋（３×６）＝１９
の、どっちかだろうと思うのですが。
みなさんわかります？
ぼくはわからなかったので調べてみました。
すると意外や意外、＜＜ERROR＞＞と表示されました。
等号以外を選んで項目二つを使うと計算できないんですね。
これは知らなかった・・・。
確かにそれがいいと思う。まぎらわしいし、数行に分けたらすっきりできることなので。
これについてどこかで説明されてるかと思い検索しましたが、ざっと見たところみつかりませんでした。
公式マニュアルでも見当たらないし。
まあそういう計算は「させないこと」になっているんでしょうね。
毎日のようにウディタを触っていますがまだまだ知らないことがたくさんあります。
さて、タイトルですが何のことかややこしいですね。
例えば
ｖ１＝１
ｖ１＋＝３＊６
とした時、Ｖ１の値はどうなるのか。
これの答えは
ｖ１＝（１＋３）×６＝２４
になるか、あるいは
ｖ１＝１＋（３×６）＝１９
の、どっちかだろうと思うのですが。
みなさんわかります？
ぼくはわからなかったので調べてみました。
すると意外や意外、＜＜ERROR＞＞と表示されました。
等号以外を選んで項目二つを使うと計算できないんですね。
これは知らなかった・・・。
確かにそれがいいと思う。まぎらわしいし、数行に分けたらすっきりできることなので。
これについてどこかで説明されてるかと思い検索しましたが、ざっと見たところみつかりませんでした。
公式マニュアルでも見当たらないし。
まあそういう計算は「させないこと」になっているんでしょうね。
毎日のようにウディタを触っていますがまだまだ知らないことがたくさんあります。
2015年06月09日
ウディタのメモ
この記事には書き足していきます。
・イベント挿入でマップイベントを呼び出す際、ページを指定するのには変数呼び出し値は使えません。
・通行不可について
変数操作＋で取得できる「指定座標位置の通行可能」は主人公のものです。
一口に通行可能と言っても通行するのが主人公かＮＰＣかによって意味が変わります。
ＮＰＣは画像未指定のマップイベントでも「すりぬけ」チェックをしていない限り通行できません。
けれども「すり抜け可でないの画像未指定のマップイベント」の有無は変数操作＋ではわかりません。
・キー入力について。
キーボード全入力受け付け時に複数のキーが押されていたら、キーコードの小さい方が入力されるようです。
・ファイル名末尾をX.pngやTX.pngにした歩行グラ素材を使うとキャラ停止中の画像も指定できるようになるのですが、その際に「変数操作＋」で「アニメパターン」を取得しても通常素材使用時と同じパターン番号しか返ってきません。
（現在連続移動中かどうかの正確な判定に使いたかったのですが無理でした）
・複数の並列起動のマップイベント内で、それぞれ別のコモンを呼び出します。それらのコモン内で「呼び出し元マップイベントの座標」を取得します。すると取得した値がおかしいことがあります。
並列起動ではきっとコマンドの流れを正しくたどれないのかもしれませんね。
（緑帯エラーでそういったことを見かけるので）
・同じく並列起動について。
並列起動のコモンイベントだと、現在のマップＩＤはちゃんと取得できるのに変数呼び出し値を使った「マップイベントYのセルフ変数X」への代入はできないみたいです。困ったことです。
（やむをえず「予備変数＜マップＩＤ＞の＜イベントＩＤ＞」というのを全マップの全イベントに割り振ってマップイベントを一括管理しました。かなり荒っぽいですが！）
・動作指定のジャンプをする時、移動する距離はコモンセルフ変数では指定できないようです。残念。
・同じくジャンプする時、ジャンプ先が通行不可ならジャンプしません。あたりまえ？
ジャンプさせたければすり抜けオンにしてからめりこませましょう！
・精密座標を使う時の注意点。取得地点はマス目の左上。なので、隣接マスの通行判定などをする時に大きなワナが・・・。左右、上下によって隣接マスへの距離が違うのです！上に1ずらすと隣接マスですが、下に１ずらしてもまだ基準マス内なのです。考えたら簡単なことですが、気付くのに時間がかかってすごく悩みました。
・ピクチャ表示の拡大率について。
５０％にしたら、横幅半分、高さ半分に表示します。
２００％にしたら、横幅2倍、高さ2倍に表示します。
拡大率というのはＸＹ各軸の長さに対する割合であって面積のことではないんですね。
（５０％表示だと面積は２５％になるんですね）
・イベント挿入でマップイベントを呼び出す際、ページを指定するのには変数呼び出し値は使えません。
・通行不可について
変数操作＋で取得できる「指定座標位置の通行可能」は主人公のものです。
一口に通行可能と言っても通行するのが主人公かＮＰＣかによって意味が変わります。
ＮＰＣは画像未指定のマップイベントでも「すりぬけ」チェックをしていない限り通行できません。
けれども「すり抜け可でないの画像未指定のマップイベント」の有無は変数操作＋ではわかりません。
・キー入力について。
キーボード全入力受け付け時に複数のキーが押されていたら、キーコードの小さい方が入力されるようです。
・ファイル名末尾をX.pngやTX.pngにした歩行グラ素材を使うとキャラ停止中の画像も指定できるようになるのですが、その際に「変数操作＋」で「アニメパターン」を取得しても通常素材使用時と同じパターン番号しか返ってきません。
（現在連続移動中かどうかの正確な判定に使いたかったのですが無理でした）
・複数の並列起動のマップイベント内で、それぞれ別のコモンを呼び出します。それらのコモン内で「呼び出し元マップイベントの座標」を取得します。すると取得した値がおかしいことがあります。
並列起動ではきっとコマンドの流れを正しくたどれないのかもしれませんね。
（緑帯エラーでそういったことを見かけるので）
・同じく並列起動について。
並列起動のコモンイベントだと、現在のマップＩＤはちゃんと取得できるのに変数呼び出し値を使った「マップイベントYのセルフ変数X」への代入はできないみたいです。困ったことです。
（やむをえず「予備変数＜マップＩＤ＞の＜イベントＩＤ＞」というのを全マップの全イベントに割り振ってマップイベントを一括管理しました。かなり荒っぽいですが！）
・動作指定のジャンプをする時、移動する距離はコモンセルフ変数では指定できないようです。残念。
・同じくジャンプする時、ジャンプ先が通行不可ならジャンプしません。あたりまえ？
ジャンプさせたければすり抜けオンにしてからめりこませましょう！
・精密座標を使う時の注意点。取得地点はマス目の左上。なので、隣接マスの通行判定などをする時に大きなワナが・・・。左右、上下によって隣接マスへの距離が違うのです！上に1ずらすと隣接マスですが、下に１ずらしてもまだ基準マス内なのです。考えたら簡単なことですが、気付くのに時間がかかってすごく悩みました。
・ピクチャ表示の拡大率について。
５０％にしたら、横幅半分、高さ半分に表示します。
２００％にしたら、横幅2倍、高さ2倍に表示します。
拡大率というのはＸＹ各軸の長さに対する割合であって面積のことではないんですね。
（５０％表示だと面積は２５％になるんですね）
ラベル：ウディタ
2015年05月19日
＜ウディタ＞歩行アニメーションのパターン数を増やしたい④
パターン数を増やすこと、できました！
(この記事を書いた３年後に公開できました！詳細はコチラ)
方法は以下の通り。技術的には特に変わった方法は使っていません。
まず、前に書いた「ざっくり言って移動中？」とでも呼ぶべき指標を作りました。
「主人公移動中？」が０の状態が２フレーム以上続いた時だけ主人公停止と判断します。
主人公が移動開始したら、常時その瞬間瞬間が移動開始後何フレーム目かを計ります。
その値を、自分で決めたアニメ切替間隔（単位はﾌﾚｰﾑ）で割ります。それは現在の瞬間は移動開始後幾つ目の画像を表示すべきか示します。
その幾つ目かの値を、アニメーションの一周期に使う枚数で割った余りを求めます。
その余りは、今の瞬間に表示すべき画像が一周期内における何枚目かを示します。
それと別に、一周期内における何枚目かがそれぞれどの画像を表示するかを指定しておきます。
（今回の場合は素材画像は連結されたものをつかったので、該当箇所を指すパターン番号を指定しました）
後は、前に作った「主人公画像をピクチャ表示するコモン」を劣化改造して使います。
適切な分割数を設定した指定素材の指定パターンを、常時主人公位置に表示します。
ちゃんと動きましたよ！
これを使えばアニメーションの枚数は好きなだけ増やせます。
アニメーション切替間隔も細かく設定できます。
デフォルトの切替順は「行って、戻って」を繰り返し循環しますが、これは自由な順に表示できます。
素材規格も、一枚一枚バラバラだろうが、並び順等も、自由自在です。
でも素材作りは大変ですね。
まあ横スクロールアクションとか、左右向け表示しかしない時には使いやすいかもしれないです。
（ピクチャ表示の為左右反転もコモン内でできるので、片側向き素材だけあればできます）
このコモンはとりあえずは公開はしません。
けれどいつか公開するかもしれません。
自作してみたい人はメールでご相談下さい。
今までにないものを作りたい！と意気込んで始めた今回の連載でしたが・・・。
実際作ってみると単に粛々と作ったらできたという、記事としては面白みのない結果になりました。
まあ実現できたことは画期的だとは思います。
いつか皆さんにお披露目できる時も来ると思うので、どうぞお楽しみにー。
（「歩行アニメーションのパターン数を増やしたい」の連載企画、これにて完。）
ラベル：ウディタ
2015年05月17日
＜ウディタ＞歩行アニメーションのパターン数を増やしたい③
例によっていつものごとく、恥をさらします。
前々回の記事にて。
「アニメーションパターン切り替えのウェイト」なんていう項目がないかと思ったのですが・・・・・どうも見当たらないようです。
いくらウディタは何でもできるとはいえ、さすがにそこまでは設定できないのかもしれませんね。
と書きました。
・・・イベント制御のキャラ動作指定から、「アニメ頻度」を7段階で設定できました。
ぼくだって知らなかったはずはないのに・・・。
初めて作ったゲームでも使いまくっていた機能なのに・・・。
しかもそれに気づいたきっかけは、速度変更と間違えて気付かずにアニメ頻度変更していたのです。
そんなはずがないのに、いきなりアニメ間隔が昨夜と全然変わったので、ぼくはあまりの衝撃で一瞬何もかも信じられなくなりました。
まあ時間はかかりましたが原因究明でき、アニメ頻度指定機能の存在も思い出せたので、よしとしたいです・・・。
つづく。
前々回の記事にて。
「アニメーションパターン切り替えのウェイト」なんていう項目がないかと思ったのですが・・・・・どうも見当たらないようです。
いくらウディタは何でもできるとはいえ、さすがにそこまでは設定できないのかもしれませんね。
と書きました。
・・・イベント制御のキャラ動作指定から、「アニメ頻度」を7段階で設定できました。
ぼくだって知らなかったはずはないのに・・・。
初めて作ったゲームでも使いまくっていた機能なのに・・・。
しかもそれに気づいたきっかけは、速度変更と間違えて気付かずにアニメ頻度変更していたのです。
そんなはずがないのに、いきなりアニメ間隔が昨夜と全然変わったので、ぼくはあまりの衝撃で一瞬何もかも信じられなくなりました。
まあ時間はかかりましたが原因究明でき、アニメ頻度指定機能の存在も思い出せたので、よしとしたいです・・・。
つづく。
2015年05月15日
＜ウディタ＞歩行アニメーションのパターン数を増やしたい
歩行アニメーションのパターン数とは、ウディタでキャラを歩かせた時に表示される画像の数のことです。
ウディタではその枚数は３枚か５枚を選択することができ、デフォルトのウルファールなどは３枚になっています。
この枚数をもっと増やせたら、更にリアルな表現ができるのでは？
・・・というわけで、さっそく考えてみることにしました。
そんなに手のかかる素材を用意できる人がどれだけいるかということは気にしない！
＜デフォルトの歩行アニメーションパターンの仕様＞
そもそもウディタにあらかじめ備わっている歩行アニメーションは一体どのようなものなのか。
まずはそれを調べました。
変数操作＋で取得した現在の瞬間の主人公の表示中のパターン番号を、常時表示してみました。
ちなみに使用しているファイル名末尾は通常の「.png」です。
（これをT.pngやTX.pngにすると、また違う挙動になるそうです。公式マニュアルに説明があるのですが、読んでも意味がよくわかりませんでした。まあそれはいいとして）
画像もなんだかよくわかりませんが、キャラを歩かせながら、その瞬間瞬間表示中のパターン番号を表示しているのです。
これでいろいろ試して、いろいろなことがわかりました。
・移動速度を一番遅くしパターン数５で歩幅が１歩だと、移動したら２３４３２１０１２の順で表示された（多分）
・移動速度を一番遅くしパターン数５で歩幅が半歩だと、移動したら２３４３２１２の順で表示された（多分）
・移動速度を一番遅くしパターン数３で歩幅が半歩だと、移動したら１２１０１２１の順で表示された（多分）
・移動速度は通常でパターン数３で歩幅が半歩だと、移動しても１のまま変わらない場合と１２１の場合がある
・移動速度を変更しても、おそらく１パターン当たりの表示時間は変わらない
つまり、歩行アニメーションとは・・・。
移動開始後から移動終了するまでの間、一定間隔で画像を切り替え続ける仕組みのようです。
移動が終了すると、表示周期が終わっていなくても強制的に停止時の画像に戻るようですね。
えっ？そんなこと知ってたって？
ふだんゲームを作ってもプレイしても、ぼくはアニメーションはそれ程意識していませんでした。
自然な動きだなとか、変わった動きだとか思うことはあっても、その切替間隔がどうなっているかまではなかなか意識がいかず・・・。
頭で考えると、パターン数５なら一歩移動する間に５種類の画像が表示されるのかと思ってしまいますが、必ずしもそうではないんですね。
表示間隔がミソらしいです。
まさかこの間隔をいじったりはできないでしょうね？
と思って、念のためにシステム変数などをチェックしてみました。
「アニメーションパターン切り替えのウェイト」なんていう項目がないかと思ったのですが・・・・・どうも見当たらないようです。
いくらウディタは何でもできるとはいえ、さすがにそこまでは設定できないのかもしれませんね。
さて、デフォルトの歩行アニメーションパターンの仕様はわかりました。
ではどうしましょう？
３枚と５枚あるデフォルトに、１枚や２枚をさらに追加するのは大変そうです。
けれどもぼくには心強い味方、主人公画像のピクチャ表示コモンがあります。
あれを使えば「従来表示すべきパターン番号」を判定し、それに応じて従来と違った画像を表示することもできます。
そこでぼくは考えました。
まずデフォルトの表示切替間隔を調べます。
それを２で割ります。
移動中に表示するパターン番号それぞれに対して、前半はこの画像、後半はこの画像と設定します。
移動開始したら現在パターン表示開始後の経過時間を常に取得すれば・・・。
そう、パターン数を２倍に増やして、なめらかな表示が実現できるはず！
きっと！多分！
この記事はいったんここまでにします。
次回、デフォルトのアニメ－ションの表示切替間隔を調べたいと思います。
ウディタではその枚数は３枚か５枚を選択することができ、デフォルトのウルファールなどは３枚になっています。
この枚数をもっと増やせたら、更にリアルな表現ができるのでは？
・・・というわけで、さっそく考えてみることにしました。
そんなに手のかかる素材を用意できる人がどれだけいるかということは気にしない！
＜デフォルトの歩行アニメーションパターンの仕様＞
そもそもウディタにあらかじめ備わっている歩行アニメーションは一体どのようなものなのか。
まずはそれを調べました。
変数操作＋で取得した現在の瞬間の主人公の表示中のパターン番号を、常時表示してみました。
ちなみに使用しているファイル名末尾は通常の「.png」です。
（これをT.pngやTX.pngにすると、また違う挙動になるそうです。公式マニュアルに説明があるのですが、読んでも意味がよくわかりませんでした。まあそれはいいとして）
画像もなんだかよくわかりませんが、キャラを歩かせながら、その瞬間瞬間表示中のパターン番号を表示しているのです。
これでいろいろ試して、いろいろなことがわかりました。
・移動速度を一番遅くしパターン数５で歩幅が１歩だと、移動したら２３４３２１０１２の順で表示された（多分）
・移動速度を一番遅くしパターン数５で歩幅が半歩だと、移動したら２３４３２１２の順で表示された（多分）
・移動速度を一番遅くしパターン数３で歩幅が半歩だと、移動したら１２１０１２１の順で表示された（多分）
・移動速度は通常でパターン数３で歩幅が半歩だと、移動しても１のまま変わらない場合と１２１の場合がある
・移動速度を変更しても、おそらく１パターン当たりの表示時間は変わらない
つまり、歩行アニメーションとは・・・。
移動開始後から移動終了するまでの間、一定間隔で画像を切り替え続ける仕組みのようです。
移動が終了すると、表示周期が終わっていなくても強制的に停止時の画像に戻るようですね。
えっ？そんなこと知ってたって？
ふだんゲームを作ってもプレイしても、ぼくはアニメーションはそれ程意識していませんでした。
自然な動きだなとか、変わった動きだとか思うことはあっても、その切替間隔がどうなっているかまではなかなか意識がいかず・・・。
頭で考えると、パターン数５なら一歩移動する間に５種類の画像が表示されるのかと思ってしまいますが、必ずしもそうではないんですね。
表示間隔がミソらしいです。
まさかこの間隔をいじったりはできないでしょうね？
と思って、念のためにシステム変数などをチェックしてみました。
「アニメーションパターン切り替えのウェイト」なんていう項目がないかと思ったのですが・・・・・どうも見当たらないようです。
いくらウディタは何でもできるとはいえ、さすがにそこまでは設定できないのかもしれませんね。
さて、デフォルトの歩行アニメーションパターンの仕様はわかりました。
ではどうしましょう？
３枚と５枚あるデフォルトに、１枚や２枚をさらに追加するのは大変そうです。
けれどもぼくには心強い味方、主人公画像のピクチャ表示コモンがあります。
あれを使えば「従来表示すべきパターン番号」を判定し、それに応じて従来と違った画像を表示することもできます。
そこでぼくは考えました。
まずデフォルトの表示切替間隔を調べます。
それを２で割ります。
移動中に表示するパターン番号それぞれに対して、前半はこの画像、後半はこの画像と設定します。
移動開始したら現在パターン表示開始後の経過時間を常に取得すれば・・・。
そう、パターン数を２倍に増やして、なめらかな表示が実現できるはず！
きっと！多分！
この記事はいったんここまでにします。
次回、デフォルトのアニメ－ションの表示切替間隔を調べたいと思います。
2015年05月10日
ウディタリアンに100の質問
ウディタリアンに100の質問というのに答えます。
記事投稿日時点での回答なので、違う時のぼくは違うことを言います。
ウディタリアンとはウディタを使う人のことだそうです。
Q.1 お名前(ＨＮ)を教えて下さい。
じゃ。
Q.2 ＨＮの由来はありますか？ あればそれは何？
忘れました。
Q.3 宜しければ性別・年齢・血液型を教えて下さい。
３０代男性です。
でも数年前から３０代と言っているのですが、正直に言い続けるなら今後ある時点から４０代です、と言わなきゃならなくなりますよね。
それじゃバレバレ！ぼやけさせてる意味がないじゃないですかー。
しょうがない、今後はできるだけ年齢を公開しないようにします。
もし「じゃ。」の活動が今後も続くなら、１０年後くらいにいきなり「４０代です」と言ってるかも知れません。
Q.4 普段は何をしてる人ですか？
内緒。
Q.5 アナタのＰＣ環境は？
Windows VISTAのノートパソコンです。
Q.6 一日のウディタの平均使用時間は？
15分。
Q.7 ゲーム制作の最高制作時間は？
わかりません。
Q.8 ゲームを完成させた事はありますか？
あります！
Q.9 今現在、自作ゲームを公開してますか？
してます！
Q.10 ゲームを作る時に心がけていることは？
プレイヤーに作業感を感じさせないようにしたいと思っています。
しらみつぶしに探索しないと先へ進めないとかは避けたいです。
でもそれがなかなか難しいんですけどね。
Q.11 ゲームを作るときに欠かせないものは何かありますか？
他人からの視点が欠かせません。
実際にアドバイスをもらわなくても、自分の中で意識するだけでも大分違います。
Q.12 貴方がウディタを始めたキッカケは何？
自分の納得のいくＲＰＧの戦闘システムを作りたいと思ったのだと思います。
そんな気持ちはいつの間にかなくなりましたが。
Q.13 ウディタ歴はどのくらいですか？
3年目に突入したところです。
Q.14 ウディタの良いところは何？
日本語でできるところ。
Q.15 逆に、ウディタの悪いところはありますか？
思いつきません。
Q.16 今作ってる(もしくは作りたい)ゲームはどんなゲーム？
経営シミュレーション。
いつか一度、斬新な出オチゲームも作ってみたいです。
「白い巨塔」「最速ファンタジー」みたいな。
Q.17 貴方の技術力はどのくらい？(例：自作メニューが限界,STGくらいは作れます)
育成シミュレーションくらいは作れそうです。
Q.18 貴方の一番得意なことは？(例：立ち絵が得意,ストーリーを考える事)
集団製作でのすりあわせ。
要求される仕様と自分の技術力との兼ね合いで、落とし所を提案する。
Q.19 ゲーム製作を挫折するときってどんなとき？
そういえば納得いかない形で挫折したことはないかもしれません。
聞かれて気づきましたが、これって幸せなことですね。
Q.20 あなたの失敗談を一つ
いつも失敗だらけです・・・。
今まで、自分についての多面的角度からの情報発信が足りなかった気がします。そのために誤解を生んだこともあったかもしれません。
伝えなきゃ伝わらない！
これからはぼくという人間の判断材料を出すようにしたいです。
Q.21 ゲームを作るとき、素材は自作しますか？自作する場合、何を自作するのか教えて下さい。(グラフィック、音楽等)
ＢＧＭは作ったことがあります。
Q.22 ウディタに今後追加されるとうれしい機能はありますか？
変数操作＋の汎用性を更に高めてほしいです。
Q.23 ウディタアクティブ時間よりも非アクティブ時間の方が多かったりする？
見方がいまいちよくわからないのです・・・。ウィンドウ上の数字、カッコ内と外、どっちがどっちなのかとか。
公式マニュアルを見ても探し出せず。（今念のため確認したら、画像にはカッコさえなかったです）
みんなよく知っていますね。
Q.24 よく利用している素材屋さん等はありますか？
ありません。
Q.25 ウディタ以外でよく使うソフトはありますか？
JTrim、PictBear、ミノ式シーケンサー、ペイント、リサイズ超簡単！、エクセル
Q.26 あなたはsnsなどのウディタコミュニティに参加していますか？
参加していたけど、放置している間に消えちゃいましたよ。どうなったんでしょうね。
Q.27 参加している方は参加した目的は何ですか？
ほ、ほんのできごころで・・・。
Q.28 ウディコン・ウディフェス等に参加した事はありますか？(ない方は今後参加する予定はありますか？)
昨年、第六回ウディコンに「らすとあとりえ」というサークル作品で参加しました。
今後も参加したいと思っています。
Q.29 ゲーム製作の作業は早いですか？
よくわかりません。作り込みは浅い方だと思うので、作り込む人に比べたら早いと思います。
Q.30 製作意欲が湧いてくるときはどんなときですか？
「あなたがこれをやってくれたら何かが生み出される！」と、誰かにそそのかされた時。
Q.31 逆に製作意欲が落ちるときはどんなときですか？
共同製作で、コミュニケーションが不十分だったことが実装後になってわかったとき、とか・・・。
Q.32 製作をしていて良かった！と思うことは？
誰かに喜んでもらえたら嬉しいです。
Q.33 ゲームの容量は気になりますか？あと容量はどこまで許せる？
とても気になります。でもどこまでも許します。
Q.34 ゲーム制作は、まずどの部分から取りかかりますか？
タイトル画面から順番に、ということが多いです。
そんなやり方で肝心なシステム部分ができなかったらどうするつもりなんでしょうねー。
Q.35 製作中、どのあたりが苦労しますか？
個人的にはモチベーションの維持。
まあそれは制作仲間とのいいご縁があれば解決することが多いです。
集団制作の上ではやはり意思疎通ですね。
Q.36 貴方の現在の目標は？
プレイヤーが少しでもゲームから影響を受けてくれたら、目標達成です。
目標というほど目指してはいないけど「フリーゲーム あの人に聞きたい!」で赤松弥太郎さんのインタビューを受けたいです。
Q.37 ウディタ公式サイトの作品登録ページに登録した作品はありますか？
一応ありますよ。
Q.38 ウディタ公式サイトのコモンイベント集&素材集に登録した素材はありますか？
ある！ある！
Q.39 配布日の発表は、配布日から何日前にしますか？
決めていません。
Q.40 ゲームシステムを作るときは何から作りますか？(例:処理内容から考える,とりあえず作る)
大体の処理は基本システムの改造なので、基本システムの不要部分を削ることから始めます。
Q.41 ゲーム製作は何人でやってますか？
１～数人です。あ、これじゃ答えになってませんね。その時によっていろいろです。
Q.42 デバッグする時にあなたが心がけている事は？
デバッグの意味をいまいち厳密にわかっていなかったので調べたら「バグを見つけ直すこと」だそうですね。
で、バグを調べたら「プログラムの誤り」だそうです。
ぼくはいつもバグという言葉を使うのにためらってしまうのです。
「バグがある」とかは、自分では言いたくないのです。（人が使うのは全然構わないのですが）
自分で作ったものがおかしいなんて（無責任なので）言えない気がします。そうなるように作ったんだからそうなっただけなので。
完成・公開後の作品の不具合はバグと言うしかないでしょうけどね。
・・・心がけてることは特にないです。
Q.43 ウディタでオンライン機能を使うならどんな機能を付けますか？
簡単なランキング機能。
Q.44 サイトの名前を教えて下さい
じゃ。のゲームのページ
Q.45 サイト名の由来を教えて下さい。
そのままです。
最初は違う目的のブログで、タイトルも違っていました。その頃のことをご存知の方がいたら恥ずかしいです。
Q.46 HPを作るときに使うソフトは？(ブログなら利用サイト等)
シーサーブログ
Q.47 今の自分のHP・ブログに満足していますか？
全く満足していません。ぼくのことを、こんなえせメタリックで無機質なデザインをかっこいいと思うセンスの人だと思われていたら、大変心外です！
でもデザインにこだわりのある姿勢を見せることの方がもっと恥ずかしいことだと思うので変えようと思ったことはないです。
（そんな見てくれだけ変えて何かが変わるとでも思っているのかー、という批判を断じて受けまいという決意。）
異様に屈折していますよねー。この心理は難解かもしれませんが、ここでそんなどうでもいいことを書いても仕方がないので割愛します。
Q.48 自分のHP・ブログをどんな感じにしたい？
ずっと、誰かの役に立つニッチな情報を含む活動記録にしたいと思ってきました。
けれど最近もう少し自分についての話を解禁して、自分を表現して伝えて理解してもらうための場にしていこうかと模索中です。
個人情報は書きませんけど。
Q.49 HP・ブログの更新頻度はどのくらい？
波がありますね。
Q.50 「ここはオススメ！」っていうサイトはある？
ちきりんの日記
内田樹の研究室
ジワジワ来るTwitterまとめ
ＮＨＫnewsＷｅｂ特集インデックス
これらは全部オススメで、世の中を分かった気になれる情報で溢れています。
Q.51 キャラクターメイキングについて、思う存分語って下さい。
キャラクターの存在にリアリティーが欲しいです。
「そんな人よくいるよね」ということではなくて、「そんな人も確かにいるのかもしれない」と思わせるという意味で。
そんなキャラを造形するのはぼくは苦手です。
Q.52 ストーリー製作について、思う存分語って下さい。
ぼくは作品を通してプレイヤーを楽しませたいと基本的には思っています。
けれどその一方で、フリーゲームは必ずしもエンターテイメントでなくてもいいとも考えています。
プレイヤーの期待を最後まで裏切り抜くような、救いのない問題作も作ってみたいという気もちょっとします。
（単なるホラーや殺しまくればいいというのじゃないのは言うまでもないですが）
とにかく意表を衝きたいというのはちょっとありますね。
Q.53 ゲームシステムについて、思う存分語って下さい。
作るべきゲームシステムはあらかじめ決まっていて、それを工夫して実装するのがぼくは楽しくて好きです。
ゲームシステムのあり方を考えること自体はそれほど好きでもないです。
むしろぼくにゲームシステムのあり方を任せたら、楽をしよう楽をしようとどこまでもシンプルになっていくでしょう。
なのでぼくがすばらしいゲームシステムを作るには、妥協の嫌いな「お尻たたき係」がいたらうまくいくかもしれません。
共同制作をしたいと思うゆえんでもあります。
ユーザーインターフェイスはわかりやすさと美しさ、どちらも大切です。
Q.54 やっぱり自作グラフィックのゲームには魅力を感じる？
特に感じません。
でも作者さんの、キャラへの思い入れが強い作品は魅力的ですね。
Q.55 好きなゲームのジャンルは？(RPG・アクション等)
自由度の高いアドベンチャーや○○シミュレーション（○○に入るのは何でもいい）。
ホラーやＢＬは勘弁願います。
Q.56 貴方の好きな世界観は何？(例：SF,ファンタジー,現代)
特にこだわりはありません。
Q.57 主人公にするならどんなタイプにしますか？(例：熱血・クール等)
適当です。
Q.58 ヒロインはどんな感じが好きですか(例：幼女・幼なじみ等)
清純な感じが好きです。完全無欠じゃない方がいいです。
Q.59 ゲームの主人公は女性派？男性派？
どちらでもいいです。
Q.60 キャラの名前はどうやって考えますか？
非常に適当です。
らすとあとりえの主人公は「仮名の男」だったのでカナオにしました。友人はトモオです。
Q.61 ゲーム製作で一番凝ってしまうところは？
「インパクト量÷手間」の公式で求められるコストパフォーマンスを追究すること、かもしれません。
ゲームの質そのものじゃないのだ・・・。
ゲームの質のためには手間を惜しまない友人知人も多く、心から尊敬しています。
Q.62 ゲーム製作で一番重視する点はなんですか？
製作に関わる方が全員楽しむこと。
Q.63 これは絶対外せないというものは？
ゲーム性が欲しいです。それが難しいんですが。
グラフィックも音楽もストーリーもなくても楽しめるゲームをまず作って、それをさらに彩るというのが理想です。
Q.64 グラフィックとストーリーならどっちを優先させますか？
そんなー！
最近までグラフィック担当とストーリー担当、お二方にお世話になって製作したぼくに、それを聞きますか！
角が立っちゃうじゃないですか・・・。
Q.65 参考にしている作品はありますか？
もう10年くらいプレイしていませんが「王様な日々」というフリーゲームを意識することがあります。
「スーパーモンキー大冒険」という市販ゲームもたまに意識します。
Q.66 あなたの作ったゲームキャラクターで気に入ったキャラはいますか？
はい。
Q.67 あなたの作中で登場するキャラクターの妄想はよくするほうですか？
シナリオを自作する時だけよくします。
Q.68 新作を作るとして前作との世界観の相関を持たせたいですか？(または完全オリジナル)
どちらともいえません。
Q.69 作品のタイトルはどんな感じでつけていますか？
自分がつける時は、固有名詞を入れるか（ネオ繚乱記）、固有名詞っぽくしたい（らすとあとりえ）というのはあります。
Q.70 ゲームプレイ時間はどれくらいが丁度良いと思いますか？
プレイする身になればある程度は長い方がいいと思うのです。
でも上に書いたコストパフォーマンスを追究してみたい欲が強いので、作る側としては超短編にも思いがあります。
Q.71 システムは完全自作派？それとも基本システム利用？
作る作品に合わせて一番やりやすいようにします。
Q.72 ウディタのヴァージョンver1派ver2派(そのverを使っている理由もお願いします)
ver2を使っています。理由は高機能だそうなので、です。
Q.73 好きな市販ゲームは？
ドラゴンクエスト１～５、幻想水滸伝２、ToysDream、モバイルGUMPEI
Q.74 ゲームのテストプレイはこまめにする方？
していただく方です。ありがとうございます。
Q.75 残り25問です。今の気持ちは？
他の方の回答しているのを拝見すると疲れたとか早く終わりたいというのをよく見かけますが、そんな気持ちはないです。
むしろ「あと四分の一しかないけどそれだけでちゃんとぼくの書きたいことを上手に引き出してくれるんでしょうねぇ？」という気持ちです。
Q.76 やってみたい企画はありますか？
ウディタの初心者さんをサポートしたいです。
挫折する人を減らしたい。
ゲーム作者を増やして、ぼくの好みのゲームを増やしたい。
それをプレイしたいです。
Q.77 ゲーム制作をしたことで失ったものはありますか？
ゲームレビューを書いていたのですが、ゲーム製作を始める前と同じ視点では書けなくなりました。
製作の大変さを知り、無責任に書き散らすことの怖さを知ってしまいました。
Q.78 製作中に起きたハプニングなどありましたら教えて下さい。
データが消えました。バックアップは大事ですね。
集団製作するたびに、素材作者さんの苦労は他人からはわからないということを痛感する出来事があります。
Q.79 ゲームの中身を見てみたいと思った作品はありますか？
あります。
Q.80 貴方が今から共同制作するとします。あなたの役職は何？(例：テストプレイヤー)
進行管理とシステム製作。
Q.81 テストプレイヤーはどんな人がプレイしていますか？
テストプレイサークルへっじほぐさんや、大変お世話になっている友人。
Q.82 よいゲームの条件を一つ簡単にあげるとしたら?
プレイヤーの生き方に影響を与えること。
Q.83 製作をしていて一番上達したなーと思うことは？
個人的な技術面ではループやＤＢやＣＳＶ入出力などを自由に使いこなせるようになったこと。
けれどそれ以上に、ゲーム作者としての視野の広がり。
「この界隈ではどんな思いの人がどんな活動をしていているか」という、以前は全く知らなかった世界を知ったことが大きいです。
Q.84 ゲーム製作を一言で言うとなんでしょうか？
ぼくにとっては世の中と関わる一つの手段です。
Q.85 もしもゲーム会社に就職する事になったら、どこのゲーム会社に就職したい？
仕事でやるなら就職でなく起業します。資本金は限りなく０円で。
Q.86 友達のゲームをプレイしたらえらくつまらなかった･･･。さて、友達には何て言う？
相手によりますよね。相手が言ってほしそうな事を言います。
基本的にはたとえつまらなかろうがほめまくります。
ともかく完成させた努力をほめちぎります。
Q.87 自分のゲームをテストプレーしてたらとんでもないバグが！！その時、貴方の心境は？
「え、嫌だ！直すのめんどくさい！これは仕様ですって押し通せないかな？少し調べて大変なら、いっそのことこの機能は実装をやめよう」
Q.88 ストーリーは良いけどシステムがクソなゲーム。システムは良いけどストーリーがクソなゲーム。遊ぶならどっち？
どっちと聞かれたら迷いますね。
でも自分にとってシステムかストーリーのいずれかがクソ（ないよりひどい）と明らかにわかっているのなら、迷わずゴミ箱行きです。
（それは自分でプレイしてみないと、他人の評価ではわかりません。）
フリーゲームはあまりに数が多く、それに対してぼくたちにはあまりに時間が足りません。
まぁ、それなのにぼくはさらにゲームの数を増やそうとしているんですけどね。
Q.89 もし自分をゲームに出すとしたら配役は何？
メタな立場のキャラになって、プレイヤーの自己意識を脅かしてみたいです。
「モニターのそっちから覗いて、自分だけ安全地帯にいるつもりなんだろ。残念だったな、オレもあんたと同じそっちの世界の住人だったんだゼ」とか言ってみたい。
Q.90 ひそかにライバルだと思っている人はいますか？
います。誰かへの対抗心や反発心で創作意欲がかき立てられることがよくあります。
その意味では、いわゆる企画クラッシャーというような人でも「彼を見返すために意地でも完成させる！」と思わせてくれて役立つこともあるので、人の良い悪いは簡単には言えないものですね。
Q.91 ウルファールさん可愛いよね？
ええ、まあ。
しかしそんなことより彼女の本領は帽子の羽の根元の宝石だと思います。
あの宝石の見え方はすごいですよ。
さすがはウディタのマスコット、デフォルトキャラの模範です。
こんなに便利なシンボルを身に付けたキャラ、ぼくは他に知りません。
額の斜め前に位置する宝石は、8方向のうち4方向からのみ見えます。
絶妙な位置に宝石があるために、キャラの全ての方向は宝石の見える/見えないで半分に分けることができるのです。
例えばもしそれが額の中央だったなら、正面、左右、斜めの６方向から見えてしまうでしょう。
ぼくはウディタで鏡に映る像を表示するコモンを作りました。
その左右が反対になっている不具合を教えてくれたのはウルファールの帽子の羽の位置でした。
彼女にはその点で本当に感謝しています。
Q.92 貴方の現実世界での友達は貴方がゲーム制作をしている事を知ってる？
一人だけ知っている友人がいます。
年賀状に「ゲーム製作は進んでますか」って書かないでくださいよー。
家族にばれるじゃないですか・・・。
Q.93 現実世界で、ウディタを使用している友達はいますか？
いません。
いや、「ウディタを使用しているぼくの友達」は現実世界に存在していますが・・・まあ揚げ足取りはやめますね。
Q.94 突然ですが、叫んで下さい。
みんな！ありがとう！！！
Q.95 あなたにとってウディタとは？
ゲームソフトかも。
Q.96 「完成が楽しみ！」なウディタ製ゲームはある？あればそれは何？
「SURVIVOR」（天音 紫穏さん作）
Q.97 これからウディタを始める人に何か一言
困った時は、こちらをクリックして下さい。
Q.98 今後ウディタを使い続けて行きますか？
はい。
Q.99 今後の活動について教えてください。
ゲームを作ります。
プレイヤーを楽しませられるゲームを作りたいです。
どちらかといえば個人製作よりも、どなたかとの共同製作に軸足を置くと思います。
Q.100 お疲れ様でした。最後に、何か一言。
100問もあればぼくの核心的な部分を引き出してもらえるかと思いましたが、なんだかまだまだ語り足りないような気もします。
けれども書くことで整理できた部分もあるだろうし、ありがとうございました。
今後はブログ記事でも自分語りを増やしていくかもしれません。
記事投稿日時点での回答なので、違う時のぼくは違うことを言います。
ウディタリアンとはウディタを使う人のことだそうです。
Q.1 お名前(ＨＮ)を教えて下さい。
じゃ。
Q.2 ＨＮの由来はありますか？ あればそれは何？
忘れました。
Q.3 宜しければ性別・年齢・血液型を教えて下さい。
３０代男性です。
でも数年前から３０代と言っているのですが、正直に言い続けるなら今後ある時点から４０代です、と言わなきゃならなくなりますよね。
それじゃバレバレ！ぼやけさせてる意味がないじゃないですかー。
しょうがない、今後はできるだけ年齢を公開しないようにします。
もし「じゃ。」の活動が今後も続くなら、１０年後くらいにいきなり「４０代です」と言ってるかも知れません。
Q.4 普段は何をしてる人ですか？
内緒。
Q.5 アナタのＰＣ環境は？
Windows VISTAのノートパソコンです。
Q.6 一日のウディタの平均使用時間は？
15分。
Q.7 ゲーム制作の最高制作時間は？
わかりません。
Q.8 ゲームを完成させた事はありますか？
あります！
Q.9 今現在、自作ゲームを公開してますか？
してます！
Q.10 ゲームを作る時に心がけていることは？
プレイヤーに作業感を感じさせないようにしたいと思っています。
しらみつぶしに探索しないと先へ進めないとかは避けたいです。
でもそれがなかなか難しいんですけどね。
Q.11 ゲームを作るときに欠かせないものは何かありますか？
他人からの視点が欠かせません。
実際にアドバイスをもらわなくても、自分の中で意識するだけでも大分違います。
Q.12 貴方がウディタを始めたキッカケは何？
自分の納得のいくＲＰＧの戦闘システムを作りたいと思ったのだと思います。
そんな気持ちはいつの間にかなくなりましたが。
Q.13 ウディタ歴はどのくらいですか？
3年目に突入したところです。
Q.14 ウディタの良いところは何？
日本語でできるところ。
Q.15 逆に、ウディタの悪いところはありますか？
思いつきません。
Q.16 今作ってる(もしくは作りたい)ゲームはどんなゲーム？
経営シミュレーション。
いつか一度、斬新な出オチゲームも作ってみたいです。
「白い巨塔」「最速ファンタジー」みたいな。
Q.17 貴方の技術力はどのくらい？(例：自作メニューが限界,STGくらいは作れます)
育成シミュレーションくらいは作れそうです。
Q.18 貴方の一番得意なことは？(例：立ち絵が得意,ストーリーを考える事)
集団製作でのすりあわせ。
要求される仕様と自分の技術力との兼ね合いで、落とし所を提案する。
Q.19 ゲーム製作を挫折するときってどんなとき？
そういえば納得いかない形で挫折したことはないかもしれません。
聞かれて気づきましたが、これって幸せなことですね。
Q.20 あなたの失敗談を一つ
いつも失敗だらけです・・・。
今まで、自分についての多面的角度からの情報発信が足りなかった気がします。そのために誤解を生んだこともあったかもしれません。
伝えなきゃ伝わらない！
これからはぼくという人間の判断材料を出すようにしたいです。
Q.21 ゲームを作るとき、素材は自作しますか？自作する場合、何を自作するのか教えて下さい。(グラフィック、音楽等)
ＢＧＭは作ったことがあります。
Q.22 ウディタに今後追加されるとうれしい機能はありますか？
変数操作＋の汎用性を更に高めてほしいです。
Q.23 ウディタアクティブ時間よりも非アクティブ時間の方が多かったりする？
見方がいまいちよくわからないのです・・・。ウィンドウ上の数字、カッコ内と外、どっちがどっちなのかとか。
公式マニュアルを見ても探し出せず。（今念のため確認したら、画像にはカッコさえなかったです）
みんなよく知っていますね。
Q.24 よく利用している素材屋さん等はありますか？
ありません。
Q.25 ウディタ以外でよく使うソフトはありますか？
JTrim、PictBear、ミノ式シーケンサー、ペイント、リサイズ超簡単！、エクセル
Q.26 あなたはsnsなどのウディタコミュニティに参加していますか？
参加していたけど、放置している間に消えちゃいましたよ。どうなったんでしょうね。
Q.27 参加している方は参加した目的は何ですか？
ほ、ほんのできごころで・・・。
Q.28 ウディコン・ウディフェス等に参加した事はありますか？(ない方は今後参加する予定はありますか？)
昨年、第六回ウディコンに「らすとあとりえ」というサークル作品で参加しました。
今後も参加したいと思っています。
Q.29 ゲーム製作の作業は早いですか？
よくわかりません。作り込みは浅い方だと思うので、作り込む人に比べたら早いと思います。
Q.30 製作意欲が湧いてくるときはどんなときですか？
「あなたがこれをやってくれたら何かが生み出される！」と、誰かにそそのかされた時。
Q.31 逆に製作意欲が落ちるときはどんなときですか？
共同製作で、コミュニケーションが不十分だったことが実装後になってわかったとき、とか・・・。
Q.32 製作をしていて良かった！と思うことは？
誰かに喜んでもらえたら嬉しいです。
Q.33 ゲームの容量は気になりますか？あと容量はどこまで許せる？
とても気になります。でもどこまでも許します。
Q.34 ゲーム制作は、まずどの部分から取りかかりますか？
タイトル画面から順番に、ということが多いです。
そんなやり方で肝心なシステム部分ができなかったらどうするつもりなんでしょうねー。
Q.35 製作中、どのあたりが苦労しますか？
個人的にはモチベーションの維持。
まあそれは制作仲間とのいいご縁があれば解決することが多いです。
集団制作の上ではやはり意思疎通ですね。
Q.36 貴方の現在の目標は？
プレイヤーが少しでもゲームから影響を受けてくれたら、目標達成です。
目標というほど目指してはいないけど「フリーゲーム あの人に聞きたい!」で赤松弥太郎さんのインタビューを受けたいです。
Q.37 ウディタ公式サイトの作品登録ページに登録した作品はありますか？
一応ありますよ。
Q.38 ウディタ公式サイトのコモンイベント集&素材集に登録した素材はありますか？
ある！ある！
Q.39 配布日の発表は、配布日から何日前にしますか？
決めていません。
Q.40 ゲームシステムを作るときは何から作りますか？(例:処理内容から考える,とりあえず作る)
大体の処理は基本システムの改造なので、基本システムの不要部分を削ることから始めます。
Q.41 ゲーム製作は何人でやってますか？
１～数人です。あ、これじゃ答えになってませんね。その時によっていろいろです。
Q.42 デバッグする時にあなたが心がけている事は？
デバッグの意味をいまいち厳密にわかっていなかったので調べたら「バグを見つけ直すこと」だそうですね。
で、バグを調べたら「プログラムの誤り」だそうです。
ぼくはいつもバグという言葉を使うのにためらってしまうのです。
「バグがある」とかは、自分では言いたくないのです。（人が使うのは全然構わないのですが）
自分で作ったものがおかしいなんて（無責任なので）言えない気がします。そうなるように作ったんだからそうなっただけなので。
完成・公開後の作品の不具合はバグと言うしかないでしょうけどね。
・・・心がけてることは特にないです。
Q.43 ウディタでオンライン機能を使うならどんな機能を付けますか？
簡単なランキング機能。
Q.44 サイトの名前を教えて下さい
じゃ。のゲームのページ
Q.45 サイト名の由来を教えて下さい。
そのままです。
最初は違う目的のブログで、タイトルも違っていました。その頃のことをご存知の方がいたら恥ずかしいです。
Q.46 HPを作るときに使うソフトは？(ブログなら利用サイト等)
シーサーブログ
Q.47 今の自分のHP・ブログに満足していますか？
全く満足していません。ぼくのことを、こんなえせメタリックで無機質なデザインをかっこいいと思うセンスの人だと思われていたら、大変心外です！
でもデザインにこだわりのある姿勢を見せることの方がもっと恥ずかしいことだと思うので変えようと思ったことはないです。
（そんな見てくれだけ変えて何かが変わるとでも思っているのかー、という批判を断じて受けまいという決意。）
異様に屈折していますよねー。この心理は難解かもしれませんが、ここでそんなどうでもいいことを書いても仕方がないので割愛します。
Q.48 自分のHP・ブログをどんな感じにしたい？
ずっと、誰かの役に立つニッチな情報を含む活動記録にしたいと思ってきました。
けれど最近もう少し自分についての話を解禁して、自分を表現して伝えて理解してもらうための場にしていこうかと模索中です。
個人情報は書きませんけど。
Q.49 HP・ブログの更新頻度はどのくらい？
波がありますね。
Q.50 「ここはオススメ！」っていうサイトはある？
ちきりんの日記
内田樹の研究室
ジワジワ来るTwitterまとめ
ＮＨＫnewsＷｅｂ特集インデックス
これらは全部オススメで、世の中を分かった気になれる情報で溢れています。
Q.51 キャラクターメイキングについて、思う存分語って下さい。
キャラクターの存在にリアリティーが欲しいです。
「そんな人よくいるよね」ということではなくて、「そんな人も確かにいるのかもしれない」と思わせるという意味で。
そんなキャラを造形するのはぼくは苦手です。
Q.52 ストーリー製作について、思う存分語って下さい。
ぼくは作品を通してプレイヤーを楽しませたいと基本的には思っています。
けれどその一方で、フリーゲームは必ずしもエンターテイメントでなくてもいいとも考えています。
プレイヤーの期待を最後まで裏切り抜くような、救いのない問題作も作ってみたいという気もちょっとします。
（単なるホラーや殺しまくればいいというのじゃないのは言うまでもないですが）
とにかく意表を衝きたいというのはちょっとありますね。
Q.53 ゲームシステムについて、思う存分語って下さい。
作るべきゲームシステムはあらかじめ決まっていて、それを工夫して実装するのがぼくは楽しくて好きです。
ゲームシステムのあり方を考えること自体はそれほど好きでもないです。
むしろぼくにゲームシステムのあり方を任せたら、楽をしよう楽をしようとどこまでもシンプルになっていくでしょう。
なのでぼくがすばらしいゲームシステムを作るには、妥協の嫌いな「お尻たたき係」がいたらうまくいくかもしれません。
共同制作をしたいと思うゆえんでもあります。
ユーザーインターフェイスはわかりやすさと美しさ、どちらも大切です。
Q.54 やっぱり自作グラフィックのゲームには魅力を感じる？
特に感じません。
でも作者さんの、キャラへの思い入れが強い作品は魅力的ですね。
Q.55 好きなゲームのジャンルは？(RPG・アクション等)
自由度の高いアドベンチャーや○○シミュレーション（○○に入るのは何でもいい）。
ホラーやＢＬは勘弁願います。
Q.56 貴方の好きな世界観は何？(例：SF,ファンタジー,現代)
特にこだわりはありません。
Q.57 主人公にするならどんなタイプにしますか？(例：熱血・クール等)
適当です。
Q.58 ヒロインはどんな感じが好きですか(例：幼女・幼なじみ等)
清純な感じが好きです。完全無欠じゃない方がいいです。
Q.59 ゲームの主人公は女性派？男性派？
どちらでもいいです。
Q.60 キャラの名前はどうやって考えますか？
非常に適当です。
らすとあとりえの主人公は「仮名の男」だったのでカナオにしました。友人はトモオです。
Q.61 ゲーム製作で一番凝ってしまうところは？
「インパクト量÷手間」の公式で求められるコストパフォーマンスを追究すること、かもしれません。
ゲームの質そのものじゃないのだ・・・。
ゲームの質のためには手間を惜しまない友人知人も多く、心から尊敬しています。
Q.62 ゲーム製作で一番重視する点はなんですか？
製作に関わる方が全員楽しむこと。
Q.63 これは絶対外せないというものは？
ゲーム性が欲しいです。それが難しいんですが。
グラフィックも音楽もストーリーもなくても楽しめるゲームをまず作って、それをさらに彩るというのが理想です。
Q.64 グラフィックとストーリーならどっちを優先させますか？
そんなー！
最近までグラフィック担当とストーリー担当、お二方にお世話になって製作したぼくに、それを聞きますか！
角が立っちゃうじゃないですか・・・。
Q.65 参考にしている作品はありますか？
もう10年くらいプレイしていませんが「王様な日々」というフリーゲームを意識することがあります。
「スーパーモンキー大冒険」という市販ゲームもたまに意識します。
Q.66 あなたの作ったゲームキャラクターで気に入ったキャラはいますか？
はい。
Q.67 あなたの作中で登場するキャラクターの妄想はよくするほうですか？
シナリオを自作する時だけよくします。
Q.68 新作を作るとして前作との世界観の相関を持たせたいですか？(または完全オリジナル)
どちらともいえません。
Q.69 作品のタイトルはどんな感じでつけていますか？
自分がつける時は、固有名詞を入れるか（ネオ繚乱記）、固有名詞っぽくしたい（らすとあとりえ）というのはあります。
Q.70 ゲームプレイ時間はどれくらいが丁度良いと思いますか？
プレイする身になればある程度は長い方がいいと思うのです。
でも上に書いたコストパフォーマンスを追究してみたい欲が強いので、作る側としては超短編にも思いがあります。
Q.71 システムは完全自作派？それとも基本システム利用？
作る作品に合わせて一番やりやすいようにします。
Q.72 ウディタのヴァージョンver1派ver2派(そのverを使っている理由もお願いします)
ver2を使っています。理由は高機能だそうなので、です。
Q.73 好きな市販ゲームは？
ドラゴンクエスト１～５、幻想水滸伝２、ToysDream、モバイルGUMPEI
Q.74 ゲームのテストプレイはこまめにする方？
していただく方です。ありがとうございます。
Q.75 残り25問です。今の気持ちは？
他の方の回答しているのを拝見すると疲れたとか早く終わりたいというのをよく見かけますが、そんな気持ちはないです。
むしろ「あと四分の一しかないけどそれだけでちゃんとぼくの書きたいことを上手に引き出してくれるんでしょうねぇ？」という気持ちです。
Q.76 やってみたい企画はありますか？
ウディタの初心者さんをサポートしたいです。
挫折する人を減らしたい。
ゲーム作者を増やして、ぼくの好みのゲームを増やしたい。
それをプレイしたいです。
Q.77 ゲーム制作をしたことで失ったものはありますか？
ゲームレビューを書いていたのですが、ゲーム製作を始める前と同じ視点では書けなくなりました。
製作の大変さを知り、無責任に書き散らすことの怖さを知ってしまいました。
Q.78 製作中に起きたハプニングなどありましたら教えて下さい。
データが消えました。バックアップは大事ですね。
集団製作するたびに、素材作者さんの苦労は他人からはわからないということを痛感する出来事があります。
Q.79 ゲームの中身を見てみたいと思った作品はありますか？
あります。
Q.80 貴方が今から共同制作するとします。あなたの役職は何？(例：テストプレイヤー)
進行管理とシステム製作。
Q.81 テストプレイヤーはどんな人がプレイしていますか？
テストプレイサークルへっじほぐさんや、大変お世話になっている友人。
Q.82 よいゲームの条件を一つ簡単にあげるとしたら?
プレイヤーの生き方に影響を与えること。
Q.83 製作をしていて一番上達したなーと思うことは？
個人的な技術面ではループやＤＢやＣＳＶ入出力などを自由に使いこなせるようになったこと。
けれどそれ以上に、ゲーム作者としての視野の広がり。
「この界隈ではどんな思いの人がどんな活動をしていているか」という、以前は全く知らなかった世界を知ったことが大きいです。
Q.84 ゲーム製作を一言で言うとなんでしょうか？
ぼくにとっては世の中と関わる一つの手段です。
Q.85 もしもゲーム会社に就職する事になったら、どこのゲーム会社に就職したい？
仕事でやるなら就職でなく起業します。資本金は限りなく０円で。
Q.86 友達のゲームをプレイしたらえらくつまらなかった･･･。さて、友達には何て言う？
相手によりますよね。相手が言ってほしそうな事を言います。
基本的にはたとえつまらなかろうがほめまくります。
ともかく完成させた努力をほめちぎります。
Q.87 自分のゲームをテストプレーしてたらとんでもないバグが！！その時、貴方の心境は？
「え、嫌だ！直すのめんどくさい！これは仕様ですって押し通せないかな？少し調べて大変なら、いっそのことこの機能は実装をやめよう」
Q.88 ストーリーは良いけどシステムがクソなゲーム。システムは良いけどストーリーがクソなゲーム。遊ぶならどっち？
どっちと聞かれたら迷いますね。
でも自分にとってシステムかストーリーのいずれかがクソ（ないよりひどい）と明らかにわかっているのなら、迷わずゴミ箱行きです。
（それは自分でプレイしてみないと、他人の評価ではわかりません。）
フリーゲームはあまりに数が多く、それに対してぼくたちにはあまりに時間が足りません。
まぁ、それなのにぼくはさらにゲームの数を増やそうとしているんですけどね。
Q.89 もし自分をゲームに出すとしたら配役は何？
メタな立場のキャラになって、プレイヤーの自己意識を脅かしてみたいです。
「モニターのそっちから覗いて、自分だけ安全地帯にいるつもりなんだろ。残念だったな、オレもあんたと同じそっちの世界の住人だったんだゼ」とか言ってみたい。
Q.90 ひそかにライバルだと思っている人はいますか？
います。誰かへの対抗心や反発心で創作意欲がかき立てられることがよくあります。
その意味では、いわゆる企画クラッシャーというような人でも「彼を見返すために意地でも完成させる！」と思わせてくれて役立つこともあるので、人の良い悪いは簡単には言えないものですね。
Q.91 ウルファールさん可愛いよね？
ええ、まあ。
しかしそんなことより彼女の本領は帽子の羽の根元の宝石だと思います。
あの宝石の見え方はすごいですよ。
さすがはウディタのマスコット、デフォルトキャラの模範です。
こんなに便利なシンボルを身に付けたキャラ、ぼくは他に知りません。
額の斜め前に位置する宝石は、8方向のうち4方向からのみ見えます。
絶妙な位置に宝石があるために、キャラの全ての方向は宝石の見える/見えないで半分に分けることができるのです。
例えばもしそれが額の中央だったなら、正面、左右、斜めの６方向から見えてしまうでしょう。
ぼくはウディタで鏡に映る像を表示するコモンを作りました。
その左右が反対になっている不具合を教えてくれたのはウルファールの帽子の羽の位置でした。
彼女にはその点で本当に感謝しています。
Q.92 貴方の現実世界での友達は貴方がゲーム制作をしている事を知ってる？
一人だけ知っている友人がいます。
年賀状に「ゲーム製作は進んでますか」って書かないでくださいよー。
家族にばれるじゃないですか・・・。
Q.93 現実世界で、ウディタを使用している友達はいますか？
いません。
いや、「ウディタを使用しているぼくの友達」は現実世界に存在していますが・・・まあ揚げ足取りはやめますね。
Q.94 突然ですが、叫んで下さい。
みんな！ありがとう！！！
Q.95 あなたにとってウディタとは？
ゲームソフトかも。
Q.96 「完成が楽しみ！」なウディタ製ゲームはある？あればそれは何？
「SURVIVOR」（天音 紫穏さん作）
Q.97 これからウディタを始める人に何か一言
困った時は、こちらをクリックして下さい。
Q.98 今後ウディタを使い続けて行きますか？
はい。
Q.99 今後の活動について教えてください。
ゲームを作ります。
プレイヤーを楽しませられるゲームを作りたいです。
どちらかといえば個人製作よりも、どなたかとの共同製作に軸足を置くと思います。
Q.100 お疲れ様でした。最後に、何か一言。
100問もあればぼくの核心的な部分を引き出してもらえるかと思いましたが、なんだかまだまだ語り足りないような気もします。
けれども書くことで整理できた部分もあるだろうし、ありがとうございました。
今後はブログ記事でも自分語りを増やしていくかもしれません。
ラベル：ウディタリアンに100の質問
2015年04月17日
「ウディタでギターコード」というソフトを作りました
「ウディタでギターコード」というソフトを作りました。
ダウンロードはこちらから
ギターのコードが弾けます。
かなり限られたコードだけですが。
Cで始まるコード進行の曲などが弾けると思います。
こんなのを作ると、本物のギターがいかにすばらしいかよくわかりますね。
アコースティックなら電気もいらず、超高音質（生音ﾅﾏｵﾄ！）でしかもギターで出せる音は全部出せる！
同じことをウディタにやらせようとしたらどれだけ大変なことか・・・。
作成は一日ほどでしたがキー入力や効果音再生のいい勉強になりました。
軽量化にはとことんこだわりましたよ。驚きの軽さ、2.8MBです。
音素材はletsspeakさんのブログからお借りしました。
まあピアノで例えるなら、幼児用のおもちゃの鍵盤（黒鍵のないやつ）みたいなもんです。
けど、触ってるとちょっとそれなりに面白いですよ。
ギターなのに音はピアノなんですけどね。しかもノイズが激しい・・・！
誰か改良して下さい。
非暗号化です。コモン一つしか使用してません。
思えば基本システムを完全に消したゲーム（じゃないけど）は初めて作りました。
そして別に大したものじゃないのに、ウディタ公式サイトの初心者作品登録ページにも載せました。
あそこに載せるのは何年かぶりです。
起動すると画面が表示され、ZもXもEnterも方向キーも受けつけないので焦るかもしれませんが、ご安心を。
起動後はいつでも好きに演奏できます。気が済むまで。
ギター触ったことない人も気軽にお試し下さい。
ギター触ったことない人は好きな歌のコード（譜面や歌詞にCとかFとか書いてるやつ）をどこかから探してきて、それを見て歌いながら適当に操作したらそれっぽく雰囲気が出てヤミツキになるかもしれません。
ダウンロードはこちらから
ギターのコードが弾けます。
かなり限られたコードだけですが。
Cで始まるコード進行の曲などが弾けると思います。
こんなのを作ると、本物のギターがいかにすばらしいかよくわかりますね。
アコースティックなら電気もいらず、超高音質（生音ﾅﾏｵﾄ！）でしかもギターで出せる音は全部出せる！
同じことをウディタにやらせようとしたらどれだけ大変なことか・・・。
作成は一日ほどでしたがキー入力や効果音再生のいい勉強になりました。
軽量化にはとことんこだわりましたよ。驚きの軽さ、2.8MBです。
音素材はletsspeakさんのブログからお借りしました。
まあピアノで例えるなら、幼児用のおもちゃの鍵盤（黒鍵のないやつ）みたいなもんです。
けど、触ってるとちょっとそれなりに面白いですよ。
ギターなのに音はピアノなんですけどね。しかもノイズが激しい・・・！
誰か改良して下さい。
非暗号化です。コモン一つしか使用してません。
思えば基本システムを完全に消したゲーム（じゃないけど）は初めて作りました。
そして別に大したものじゃないのに、ウディタ公式サイトの初心者作品登録ページにも載せました。
あそこに載せるのは何年かぶりです。
起動すると画面が表示され、ZもXもEnterも方向キーも受けつけないので焦るかもしれませんが、ご安心を。
起動後はいつでも好きに演奏できます。気が済むまで。
ギター触ったことない人も気軽にお試し下さい。
ギター触ったことない人は好きな歌のコード（譜面や歌詞にCとかFとか書いてるやつ）をどこかから探してきて、それを見て歌いながら適当に操作したらそれっぽく雰囲気が出てヤミツキになるかもしれません。
2015年04月10日
テストプレイサークル「へっじほっぐ」さんのこと
ある掲示板で「フリーゲームのテストプレイ承ります」というサークルを見つけました。
へっじほっぐさんといいます。
へっじほっぐさんのホームページはこちら。
ぼくの制作中のゲーム、fairy song～歌う革命～のテストプレイをお願いしたところ、快く引き受けていただきました。
そして不具合をどんどん見つけていただき、的確な指摘をくださっています。
それにしてもテストプレイするサークルって珍しいですよね。
ぼくは他には聞いたことがありません。
そもそもどうしてそんなサークルができたのか。
何を目的にしているのか。
興味を抱いたぼくは、ぶしつけながらお聞きしてみました。
そのＱ＆Ａを掲載します。
-------------------------------------------------------------------------
Ｑ１どうしてしようと思ったんですか？
Ａ.とある会社のアルバイトをしていました。業種はデバッグでした。初めてだらけでどっぷり仕事の魅力にはまったものの、体が弱く通いづらいことがあり、辞めてしまいました。それでも夢にデバッグがでてくるので家で趣味で始めようと思いました！
Ｑ２目指すところは？
（有償案件をバンバン受けれるようになって収益化？ゲーム文化に貢献？有料ソフトもタダで遊ぶ？）
Ａ.有償無償はサークルがこじんまりしている限りは「こちらで払う代金が発生しない限りは先方様から代金をいただかない」という方針のもとやっていきます。
ゲーム文化に貢献ですね＾＾みなさんのゲームがちょっとでも皆様の手に渡り、評価されるよう願っています。
Ｑ３ホームページを見ると参加作品は「落葉の大地を走れ」だけになっていますが、まだそれだけですか？
Ａ.参加作品はサークルへっじほっぐとしては1作品のみです。
Ｑ４新規メンバーは積極的に募集中なんですか？
Ａ.新規メンバーは私がまとめられる範囲で募集していますが、18歳高校卒業していらっしゃる方のみですね！
----------------------------------------------------------------------
とのことでした。
なるほどなるほどー。
夢に出てくるって、本当にお好きなんでしょうね。
好きで楽しみながらやって、それでゲーム文化に貢献！
しかもそのために、誰もやっていないことを自分で考えてやり始めるってすごくかっこいいですね！
ぼくの作ったゲームが映えある2作品目になるのは光栄です。
フリーゲームを作成される方、もしいらしたら、テストプレイが必要な時はぜひ相談してみたらいかがでしょうか。
また新規メンバーも募集中とのこと、興味のある高卒以上の方はぜひ問い合わせてみて下さい。
へっじほっぐさんといいます。
へっじほっぐさんのホームページはこちら。
ぼくの制作中のゲーム、fairy song～歌う革命～のテストプレイをお願いしたところ、快く引き受けていただきました。
そして不具合をどんどん見つけていただき、的確な指摘をくださっています。
それにしてもテストプレイするサークルって珍しいですよね。
ぼくは他には聞いたことがありません。
そもそもどうしてそんなサークルができたのか。
何を目的にしているのか。
興味を抱いたぼくは、ぶしつけながらお聞きしてみました。
そのＱ＆Ａを掲載します。
-------------------------------------------------------------------------
Ｑ１どうしてしようと思ったんですか？
Ａ.とある会社のアルバイトをしていました。業種はデバッグでした。初めてだらけでどっぷり仕事の魅力にはまったものの、体が弱く通いづらいことがあり、辞めてしまいました。それでも夢にデバッグがでてくるので家で趣味で始めようと思いました！
Ｑ２目指すところは？
（有償案件をバンバン受けれるようになって収益化？ゲーム文化に貢献？有料ソフトもタダで遊ぶ？）
Ａ.有償無償はサークルがこじんまりしている限りは「こちらで払う代金が発生しない限りは先方様から代金をいただかない」という方針のもとやっていきます。
ゲーム文化に貢献ですね＾＾みなさんのゲームがちょっとでも皆様の手に渡り、評価されるよう願っています。
Ｑ３ホームページを見ると参加作品は「落葉の大地を走れ」だけになっていますが、まだそれだけですか？
Ａ.参加作品はサークルへっじほっぐとしては1作品のみです。
Ｑ４新規メンバーは積極的に募集中なんですか？
Ａ.新規メンバーは私がまとめられる範囲で募集していますが、18歳高校卒業していらっしゃる方のみですね！
----------------------------------------------------------------------
とのことでした。
なるほどなるほどー。
夢に出てくるって、本当にお好きなんでしょうね。
好きで楽しみながらやって、それでゲーム文化に貢献！
しかもそのために、誰もやっていないことを自分で考えてやり始めるってすごくかっこいいですね！
ぼくの作ったゲームが映えある2作品目になるのは光栄です。
フリーゲームを作成される方、もしいらしたら、テストプレイが必要な時はぜひ相談してみたらいかがでしょうか。
また新規メンバーも募集中とのこと、興味のある高卒以上の方はぜひ問い合わせてみて下さい。
2015年04月06日
カオメーカー企画終了！
かおグラＭＡＫＥＲというツールを発見しました！
バーツごとの位置移動や角度回転、左右反転や色調変更、そして当然ながら画像出力もできるようです！
おおおぅ！！！
カオメーカー制作企画はこれをもちまして終了します・・・！
このそそっかしさはどうにかしないとなぁ。
それにしてもこんな高機能ツールがあるのにウディタ作品の顔グラが同じものばかりになるのは一体どうしたわけか・・・？
バーツごとの位置移動や角度回転、左右反転や色調変更、そして当然ながら画像出力もできるようです！
おおおぅ！！！
カオメーカー制作企画はこれをもちまして終了します・・・！
このそそっかしさはどうにかしないとなぁ。
それにしてもこんな高機能ツールがあるのにウディタ作品の顔グラが同じものばかりになるのは一体どうしたわけか・・・？
カオメーカー
春ですね。
万朶の桜が雨にぬれています。
ゲーム作りもちょっと一段落つきました。
そこでゲーム制作中に考えついた構想をここに書きます。
顔グラ合成器の拡張版を作ろうと思うのです。
名付けて「カオメーカー」！！！（仮称）
クリエイターのはしくれなんだから、作るとか言わずに「作った」と言えばいいだけかもしれませんけどね。
けれどこれはとても大きな企画になる可能性があるので、頭を整理するためにも、風呂敷を拡げつくすためにも、ここで文章化して公開して、自分で自分を追い詰めてみたいと思うのです。
そもそもの発端は・・・。
ゲーム作ってた時に、デザイン担当さんが表情差分の素材をたくさん用意して下さいましてね。
（おかげで活きいきしたキャラの表現ができました！）
例えば汗を垂らすだけなら、ウディタでもできるな、とか思ったのも着想のきっかけです。
それと、ふくわらいという古典的遊戯ですね、あれをウディタでできるかなとか思ったのもありました。
それらは同時発生的でした。多分。
それに加えて、今回のゲームでは「カーソル現位置に応じた処理をする」ということをとことんやりました。
ピクチャ表示については以前から「主人公ピクチャ表示コモン」などで経験はありました。
それらを組み合わせたらなんとかできそうだと、自然に思いつきました。
そもそも顔グラ合成器ってご存知ですか。
ウディタ作品でよく使われている、顔グラを合成できるツールです。
ぼくもネオ繚乱記では使わせてもらいました。
絵心のない自分のような人でも手軽に顔グラが作れる、すばらしいツールです。
その人気たるやすごいもので、ウディタ作品の数割はこのツールを利用して作られているように思います。
ただそのため、似た顔があふれてかえってしまっているのが残念なところですね。
それぞれの作者さんは自分だけの顔を作ったつもりなのに、結果はどこかで見たようなものになってしまっている。
顔グラ合成器に似たツールにキャラクターなんとか機というものもありますけれども。
使用したらわかる人にはすぐわかってしまうという点ではそれも顔グラ合成器によく似ています。
けれどもそんな状況は、顔グラ合成器の機能の自由度を高めれば、解決できるのではと思いました。
そうなると問題は、そもそもそんなものを作るスキルがぼくにあるのかということです。
プログラムは知らないし。
でもウディタを使えばきそうです。さすがウディタ、最高～！
ウディタは画像の扱いが自由自在なので、顔グラ合成器の機能を拡張するのは簡単です。
後はネックになるのは、操作性や分かりやすさかな。その辺りは工夫したいです。
顔グラ合成器では顔パーツを組み合わせることができます。
色調の変更もできます。
ウディタを使えばそれに加えて何ができるか。いっぱいできますよー。
・各パーツの表示座標指定
・透明度設定
・表示角度指定（回転）
・左右反転
・レイヤー（表示する層）の順番の指定
例えば眉毛の素材を一つ用意すれば、左右の眉毛を、あらゆるサイズで、あらゆる角度で、あらゆる濃さで、あらゆる位置に表示できます。こりゃすごいっ！
ここまで読んでウディタをご存知の方は「え、でもウディタは画像ファイル出力できないやん」と思うかもしれません。ええごもっともです。けれどもできるのです。
それにはスクリーンショット機能を使います。
あ、読んでるあなた、「こりゃあかんわ」と引かないでくださいー！
なんとか実用に耐えるようにはしたいと思っていますので・・・。
まあ、生成される画像サイズは画面サイズになります。
それと透過色指定はできません。
ファイルの生成場所も指定できないです。
でもいいですよね、きっと。多分。
多くの問題はやり方次第で何とかなると思います。
具体的に今考えている方法を書いてみます。
ウディタにDataフォルダを二つ入れて配布します。
（フォルダ名は変化をつけて。片方を使い終わったらフォルダ外にドラッグし、残った方の名をDataにして使用します）
先に使うのははカオメーカー起動用。
もう一つは顔グラ素材作成後、その素材をそのまま普通に使える状態にした初期状態のウディタ。
後者はウディタのサンプルゲームです。
素材の置き場所の移動は手動でしてもらいましょう。
顔グラを表示するコモンに「素材サイズが画面サイズなら、縮小＆画面右端に余白をはみ出させて表示」という処理を挟み込めば、初心者でも気軽に使えるのではあるまいか。
幸いデフォルトの顔グラ表示位置は画面右端なので、余白部分を画面外にできるので好都合です。
カオメーカーの方では、正方形の顔グラを作れるようにします。
（正方形でなくてもいいと思うけど、顔グラ合成器の標準サイズ？が確かそうだったのでそれに合わせます）
その正方形の顔を画面いっぱいのサイズにし、左に寄せて表示します。
つまり画面サイズが320×240なら240×240の顔を描いて、右が余白です。
（画面サイズをどうするかは未定です）
素材の背後は透過できないので、ゲーム上では素材のバックはウィンドウ扱いするのがいいかもしれないですね。
なのでウィンドウっぽくするために枠を作ろうと思います。
まあデフォルトのウィンドウは角が丸いですが、顔のバックは完全な正方形です。
角を丸くしてもその背後を透過できないですもんね。
そういう風にしたら、他の画像加工ツールを使わなくても一応使えるのではないかと思います。
（余談ですが、ぼくが前に作ってこのブログでもご紹介した「ピクチャ分割表示コモン」あれがもっと高性能なら顔グラ素材の余白を非表示にできるんですけどね。あれは原寸大表示が前提なので使えないのです・・・）
あ、書きそびれてましたが、ぼくが考えているのはとりあえずウディタで簡単に使えるように、ということです。それ以上のことはちょっと手に余る・・・。
まあ顔の各パーツの拡大率や表示座標や回転を指定できることに大きな魅力を感じてもらえるのなら、このツールを使って画像を作り、別ツールで透過色指定や余部分白のカット、さらに縮小という方法もできるでしょう。
そしてもしもこのツールがウディタ界隈で大人気になれば、きっと有志の誰かがプログラムを使って多機能合成器を作ってくれるんじゃないでしょうかね。汎用性の高い。（←人任せ）
そのためにも、このツールで需要はあるということを証明できたらなぁと思います。
いや、需要はあるはずだと信じているんです。
絵の初心者でも誰にも似てない自分だけのキャラを手軽に作りたい、そんな需要は必ずあるはず・・・！
このツールが完成して公開して反響がなければ、それは操作性や使い勝手が悪かったせいだろう、と、需要についてはそれくらいに思っていますよっっ。
まあ制約や短所があるにしても、このツールを使わないとできないことがあるのなら、他ツールと併用してでも使ってくれる人もいるでしょう。
まさかこんなツール、もうすでに他にあるなんてことはないですよね。
画像加工ソフトでもレイヤーごとに色んなファイルからパーツを取り込んで拡大や回転はできることとは思いますが。（よく知りません）
顔グラ作りに特化して、操作が簡単で、デフォルト素材が入ってるのなんて、ないですよね？
（もしあったら作らない！）
でももし既にあるのなら、ウディタの初心者作品があんなに同じ顔で溢れることはないはず。
なので、作ります！
まぁぼちぼち・・・ね。
期待せず待って下さい。
アイデア盗用も歓迎です。
最後にカオメーカーのメリットとデメリット、検討事項を書き出しておきます。
＜メリット＞
・自由度の高い顔グラ作りができる。
・他ツール使用の必要なし。（画像加工初心者でもとっつきやすい）
・非暗号化ウディタで作るのでできる人なら改造できる。
＜デメリット＞
・背景透過できない。
・素材サイズが大きい。（容量も大きい）
・ウディタの基本システムで使用する時以外は他ツールの併用が必要
＜検討事項＞
・緑の帯の入らないスクショ撮影ってできましたよね？できるはず。できなきゃ詰みます！
・画面サイズの素材を顔グラサイズに縮小表示すると画質の劣化具合はどんなもんでしょうか。
（場合によっては素材は画面の左上で小さく作り、使用時は画面右下に余白を出して原寸大表示にします）
なんだか誇大妄想の垂れ流しのようになってしまった・・・。
ホラで終わらせないために実現したいと、ぼーんやりと思っています。
（さあ書いてしまったぞ、自分！もう逃げられないぞ！）
ここで今の心境を一首。
春の夜の 夢想（ゆめ）ばかりなる戯言に 甲斐なく堕ちむ 名こそ惜しけれ
万朶の桜が雨にぬれています。
ゲーム作りもちょっと一段落つきました。
そこでゲーム制作中に考えついた構想をここに書きます。
顔グラ合成器の拡張版を作ろうと思うのです。
名付けて「カオメーカー」！！！（仮称）
クリエイターのはしくれなんだから、作るとか言わずに「作った」と言えばいいだけかもしれませんけどね。
けれどこれはとても大きな企画になる可能性があるので、頭を整理するためにも、風呂敷を拡げつくすためにも、ここで文章化して公開して、自分で自分を追い詰めてみたいと思うのです。
そもそもの発端は・・・。
ゲーム作ってた時に、デザイン担当さんが表情差分の素材をたくさん用意して下さいましてね。
（おかげで活きいきしたキャラの表現ができました！）
例えば汗を垂らすだけなら、ウディタでもできるな、とか思ったのも着想のきっかけです。
それと、ふくわらいという古典的遊戯ですね、あれをウディタでできるかなとか思ったのもありました。
それらは同時発生的でした。多分。
それに加えて、今回のゲームでは「カーソル現位置に応じた処理をする」ということをとことんやりました。
ピクチャ表示については以前から「主人公ピクチャ表示コモン」などで経験はありました。
それらを組み合わせたらなんとかできそうだと、自然に思いつきました。
そもそも顔グラ合成器ってご存知ですか。
ウディタ作品でよく使われている、顔グラを合成できるツールです。
ぼくもネオ繚乱記では使わせてもらいました。
絵心のない自分のような人でも手軽に顔グラが作れる、すばらしいツールです。
その人気たるやすごいもので、ウディタ作品の数割はこのツールを利用して作られているように思います。
ただそのため、似た顔があふれてかえってしまっているのが残念なところですね。
それぞれの作者さんは自分だけの顔を作ったつもりなのに、結果はどこかで見たようなものになってしまっている。
顔グラ合成器に似たツールにキャラクターなんとか機というものもありますけれども。
使用したらわかる人にはすぐわかってしまうという点ではそれも顔グラ合成器によく似ています。
けれどもそんな状況は、顔グラ合成器の機能の自由度を高めれば、解決できるのではと思いました。
そうなると問題は、そもそもそんなものを作るスキルがぼくにあるのかということです。
プログラムは知らないし。
でもウディタを使えばきそうです。さすがウディタ、最高～！
ウディタは画像の扱いが自由自在なので、顔グラ合成器の機能を拡張するのは簡単です。
後はネックになるのは、操作性や分かりやすさかな。その辺りは工夫したいです。
顔グラ合成器では顔パーツを組み合わせることができます。
色調の変更もできます。
ウディタを使えばそれに加えて何ができるか。いっぱいできますよー。
・各パーツの表示座標指定
・透明度設定
・表示角度指定（回転）
・左右反転
・レイヤー（表示する層）の順番の指定
例えば眉毛の素材を一つ用意すれば、左右の眉毛を、あらゆるサイズで、あらゆる角度で、あらゆる濃さで、あらゆる位置に表示できます。こりゃすごいっ！
ここまで読んでウディタをご存知の方は「え、でもウディタは画像ファイル出力できないやん」と思うかもしれません。ええごもっともです。けれどもできるのです。
それにはスクリーンショット機能を使います。
あ、読んでるあなた、「こりゃあかんわ」と引かないでくださいー！
なんとか実用に耐えるようにはしたいと思っていますので・・・。
まあ、生成される画像サイズは画面サイズになります。
それと透過色指定はできません。
ファイルの生成場所も指定できないです。
でもいいですよね、きっと。多分。
多くの問題はやり方次第で何とかなると思います。
具体的に今考えている方法を書いてみます。
ウディタにDataフォルダを二つ入れて配布します。
（フォルダ名は変化をつけて。片方を使い終わったらフォルダ外にドラッグし、残った方の名をDataにして使用します）
先に使うのははカオメーカー起動用。
もう一つは顔グラ素材作成後、その素材をそのまま普通に使える状態にした初期状態のウディタ。
後者はウディタのサンプルゲームです。
素材の置き場所の移動は手動でしてもらいましょう。
顔グラを表示するコモンに「素材サイズが画面サイズなら、縮小＆画面右端に余白をはみ出させて表示」という処理を挟み込めば、初心者でも気軽に使えるのではあるまいか。
幸いデフォルトの顔グラ表示位置は画面右端なので、余白部分を画面外にできるので好都合です。
カオメーカーの方では、正方形の顔グラを作れるようにします。
（正方形でなくてもいいと思うけど、顔グラ合成器の標準サイズ？が確かそうだったのでそれに合わせます）
その正方形の顔を画面いっぱいのサイズにし、左に寄せて表示します。
つまり画面サイズが320×240なら240×240の顔を描いて、右が余白です。
（画面サイズをどうするかは未定です）
素材の背後は透過できないので、ゲーム上では素材のバックはウィンドウ扱いするのがいいかもしれないですね。
なのでウィンドウっぽくするために枠を作ろうと思います。
まあデフォルトのウィンドウは角が丸いですが、顔のバックは完全な正方形です。
角を丸くしてもその背後を透過できないですもんね。
そういう風にしたら、他の画像加工ツールを使わなくても一応使えるのではないかと思います。
（余談ですが、ぼくが前に作ってこのブログでもご紹介した「ピクチャ分割表示コモン」あれがもっと高性能なら顔グラ素材の余白を非表示にできるんですけどね。あれは原寸大表示が前提なので使えないのです・・・）
あ、書きそびれてましたが、ぼくが考えているのはとりあえずウディタで簡単に使えるように、ということです。それ以上のことはちょっと手に余る・・・。
まあ顔の各パーツの拡大率や表示座標や回転を指定できることに大きな魅力を感じてもらえるのなら、このツールを使って画像を作り、別ツールで透過色指定や余部分白のカット、さらに縮小という方法もできるでしょう。
そしてもしもこのツールがウディタ界隈で大人気になれば、きっと有志の誰かがプログラムを使って多機能合成器を作ってくれるんじゃないでしょうかね。汎用性の高い。（←人任せ）
そのためにも、このツールで需要はあるということを証明できたらなぁと思います。
いや、需要はあるはずだと信じているんです。
絵の初心者でも誰にも似てない自分だけのキャラを手軽に作りたい、そんな需要は必ずあるはず・・・！
このツールが完成して公開して反響がなければ、それは操作性や使い勝手が悪かったせいだろう、と、需要についてはそれくらいに思っていますよっっ。
まあ制約や短所があるにしても、このツールを使わないとできないことがあるのなら、他ツールと併用してでも使ってくれる人もいるでしょう。
まさかこんなツール、もうすでに他にあるなんてことはないですよね。
画像加工ソフトでもレイヤーごとに色んなファイルからパーツを取り込んで拡大や回転はできることとは思いますが。（よく知りません）
顔グラ作りに特化して、操作が簡単で、デフォルト素材が入ってるのなんて、ないですよね？
（もしあったら作らない！）
でももし既にあるのなら、ウディタの初心者作品があんなに同じ顔で溢れることはないはず。
なので、作ります！
まぁぼちぼち・・・ね。
期待せず待って下さい。
アイデア盗用も歓迎です。
最後にカオメーカーのメリットとデメリット、検討事項を書き出しておきます。
＜メリット＞
・自由度の高い顔グラ作りができる。
・他ツール使用の必要なし。（画像加工初心者でもとっつきやすい）
・非暗号化ウディタで作るのでできる人なら改造できる。
＜デメリット＞
・背景透過できない。
・素材サイズが大きい。（容量も大きい）
・ウディタの基本システムで使用する時以外は他ツールの併用が必要
＜検討事項＞
・緑の帯の入らないスクショ撮影ってできましたよね？できるはず。できなきゃ詰みます！
・画面サイズの素材を顔グラサイズに縮小表示すると画質の劣化具合はどんなもんでしょうか。
（場合によっては素材は画面の左上で小さく作り、使用時は画面右下に余白を出して原寸大表示にします）
なんだか誇大妄想の垂れ流しのようになってしまった・・・。
ホラで終わらせないために実現したいと、ぼーんやりと思っています。
（さあ書いてしまったぞ、自分！もう逃げられないぞ！）
ここで今の心境を一首。
春の夜の 夢想（ゆめ）ばかりなる戯言に 甲斐なく堕ちむ 名こそ惜しけれ
2015年03月25日
制作ゲームの紹介ページと素材表記
ゲーム制作中です。
まだ未完成ですが、紹介ページを作っていただきました。
こちら。
↓↓↓
fairy song～歌う革命～
以下のサイトのフリー素材を使わせていただきました。
-------------------------------------------------------------
誰そ彼亭
http://may.force.mepage.jp/
Boston Age
http://areno.ongaeshi.biz/
Re:vre
http://nx.myafi.net/
-------------------------------------------------------------
まだしばらく制作は続きます。
まだ未完成ですが、紹介ページを作っていただきました。
こちら。
↓↓↓
fairy song～歌う革命～
以下のサイトのフリー素材を使わせていただきました。
-------------------------------------------------------------
誰そ彼亭
http://may.force.mepage.jp/
Boston Age
http://areno.ongaeshi.biz/
Re:vre
http://nx.myafi.net/
-------------------------------------------------------------
まだしばらく制作は続きます。
2015年02月09日
第２回ウディタリバーシ参加報告
tohさん企画のウディタリバーシの第二回が先日行われ、参加しました。
戦績は4勝2敗と、前回よりもよくなりました。
前回作成時は対戦相手がいないために手さぐりで作る楽しさがありましたが。
今回はライバルの思考ルーチンが一部公開されていたので、いかにしたら勝てるかを追求する楽しさがありました。
作りながらいろいろ感じたりもしましたが今日の所はそれを書くよりゲーム作りに注力したいので、手短ですが失礼します。
戦績は4勝2敗と、前回よりもよくなりました。
前回作成時は対戦相手がいないために手さぐりで作る楽しさがありましたが。
今回はライバルの思考ルーチンが一部公開されていたので、いかにしたら勝てるかを追求する楽しさがありました。
作りながらいろいろ感じたりもしましたが今日の所はそれを書くよりゲーム作りに注力したいので、手短ですが失礼します。
2015年01月14日
ウディタリバーシ③
さてそうして迎えたウディタリバーシ大会（第一回）つまり昨夜です。
tohさんがツイキャスとかいう今どきの仕組みを使って実況中継してくれて楽しかったです。
参加者は８人。
どうでもいいけどみなさんほとんどツイッターを使っているようです。
お若いのかなぁ。
ぼくのリアル生活での知人ではツイッターもラインもスカイプも使ってる人は誰一人としていませんよ。
ましてやツイキャスにいたっては。ぼくは今回初めて利用しました。
現代日本人の多様化と集団の細分化およびその断絶のすさまじさは想像を絶するようです。
ぼくが３０代も半ばを過ぎゲーム制作の世界に足を踏み入れたことは視野を広める意味でも僥倖だったと言えそうです。
話がそれました。ぼくはゲームに限らず日常の様々なことをブログに書きたいという衝動もあるのですが、それを自分に許すとただでさえ饒舌なぼくの文章はとどまるところを知らず暴走し出して多大な時間を奪っていくだろう事は目に見えているのであえて自分に文章はゲーム制作関係のみと縛りをかけることでそれを防ぎたいという思惑があるのです。長文連投も３つ目となるとどうもキーボードを押す指も滑るようです。
話を戻せば。
８人、総当たりで対戦しました。
試合を見ていていろいろ考えさせられました。
この記事ではそれを書きます。
試合中に盤上が一色になってしまい余白を残したまま勝敗が決したり、四隅を取られても勝った方がおられたり、スリリングな夜となりました。
驚いたのは時間切れで失格負けになった方がいらっしゃったことです。
ぼくは持ち時間の十分の一も使ったことはないので本当にびっくりしました。
そういう方はきっと先を読んでいるんでしょうね。
自分がこう置いたら相手が置けるのはどことどことどこで、それならどこが有利か・・・と。
見ていると角を取れるかどうかがほとんど勝敗を分けているように思えました。
（お一人バグを抱えたデータを提出してしまった方がいらして、角を取らせるような場所に自分から突っ込んでいってしまいお気の毒でした。関係ないですが、らすとあとりえのレビューを書いて下さった方なんですが）
勝つための方法論として、角を取るというのは大前提なんですね、きっと。
問題は、いかにして角の隣接マスをとらないかということです。
もっといえばいかにして相手に角の隣接マスをとらせられるか。
人間の思考では一辺や対角線が全て自分の色で埋まっていて角の隣接マスに踏み込んでも何とか大丈夫そうなケースもありますが。けれどもその判定を思考ルーチンに求めるのは難しいかもしれません。
ぼくの思考ルーチンは角の隣接はできる限り取らない、角を取れる時は必ず取る、その二点はまずまず隙はなかったと思います。
けれどもなぜだかこいつ、どんどん角の隣に踏み込んでいくんですね。
それはなぜか。
それは他に選択肢がないからです。
盤の四隅に角と周囲の四マスが四か所だけしか残されていない、他は埋まっている。そんな状況ならわかります。双方のルーチンが「角の隣は取らない」を厳守してのんべんだらりと進行していく（と言ったら相手に失礼か）場合はそういうこともありました。
けれどもそうでない。他にあちこちあいているのにわざわざ地雷を踏みに行く。
それは相手にこっちの手を読まれて、選択肢を少なく少なく追いつめられているからなんでしょう。おそらく。
ぼくが隣接マスの石の数を意識したのもそれに関係があって。
極端な話、敵の石を自分が完全に囲んでしまったらもうどこにも打てないわけです。
その状況に徐々に近づいていく過程で、タブーである角の隣に踏み込まざるを得ない状況に追い詰められてしまうのでしょうね。
これは相手の手を予測するしかないのでしょうかね。
相手の選択肢がなくなるように、なくなるように、誘導していく。
それには自分の石を置いた後の盤面をＤＢに置いてそれを判定するのが自然な気はします。
優勝された方がどこかのタイミングで「これを何とかするには４手先まで読まないといけないのかー」とかなんとかつぶやいていらっしゃったような記憶があります。（違ったらすいません！）
ということはまさか３手先までは読んでるというのでしょうか・・・！
次回に向けてどうするかを迷っています。
出場はもちろんしたいと思っています。
予測タイプに踏み出すか。
それとも従来の最適化路線をさらに追及するか。
処理速度なら負けません！って。
ぼくは今回の企画に参加して気付いたのですが、自分は思っていた以上に統計が好きなようです。
学生時代はさんざん嫌ったものですが。
どういう要素をどの比重でどのタイミングで加味すれば一番強いか。
それを考え試行錯誤する過程が好きです。
勝ちに行くならそんなことは言ってられないのかなぁ。
予測タイプを作るのには本体のコモンを流用できそうとはいえやはり難しそうだしめんどうかなぁ。
めんどうなんて言っていたら共同制作仲間に「それならそんな長文連投なんかしてないで作業進めてよー」と怒られそうですが。
まあまずは作り方をどうするか悩む以前に、オセロの定石などをもう少し勉強しようと思います。
いや、もちろんゲーム制作も進めますー。許して下さいー！
まあオセロに興味ない（と思う）方々がこんな長文３連発に目を通すわけはないですよね。
これでウディタリバーシシリーズはいったん終了のはずです。
長々お読み下さった方ありがとうございました。
tohさんがツイキャスとかいう今どきの仕組みを使って実況中継してくれて楽しかったです。
参加者は８人。
どうでもいいけどみなさんほとんどツイッターを使っているようです。
お若いのかなぁ。
ぼくのリアル生活での知人ではツイッターもラインもスカイプも使ってる人は誰一人としていませんよ。
ましてやツイキャスにいたっては。ぼくは今回初めて利用しました。
現代日本人の多様化と集団の細分化およびその断絶のすさまじさは想像を絶するようです。
ぼくが３０代も半ばを過ぎゲーム制作の世界に足を踏み入れたことは視野を広める意味でも僥倖だったと言えそうです。
話がそれました。ぼくはゲームに限らず日常の様々なことをブログに書きたいという衝動もあるのですが、それを自分に許すとただでさえ饒舌なぼくの文章はとどまるところを知らず暴走し出して多大な時間を奪っていくだろう事は目に見えているのであえて自分に文章はゲーム制作関係のみと縛りをかけることでそれを防ぎたいという思惑があるのです。長文連投も３つ目となるとどうもキーボードを押す指も滑るようです。
話を戻せば。
８人、総当たりで対戦しました。
試合を見ていていろいろ考えさせられました。
この記事ではそれを書きます。
試合中に盤上が一色になってしまい余白を残したまま勝敗が決したり、四隅を取られても勝った方がおられたり、スリリングな夜となりました。
驚いたのは時間切れで失格負けになった方がいらっしゃったことです。
ぼくは持ち時間の十分の一も使ったことはないので本当にびっくりしました。
そういう方はきっと先を読んでいるんでしょうね。
自分がこう置いたら相手が置けるのはどことどことどこで、それならどこが有利か・・・と。
見ていると角を取れるかどうかがほとんど勝敗を分けているように思えました。
（お一人バグを抱えたデータを提出してしまった方がいらして、角を取らせるような場所に自分から突っ込んでいってしまいお気の毒でした。関係ないですが、らすとあとりえのレビューを書いて下さった方なんですが）
勝つための方法論として、角を取るというのは大前提なんですね、きっと。
問題は、いかにして角の隣接マスをとらないかということです。
もっといえばいかにして相手に角の隣接マスをとらせられるか。
人間の思考では一辺や対角線が全て自分の色で埋まっていて角の隣接マスに踏み込んでも何とか大丈夫そうなケースもありますが。けれどもその判定を思考ルーチンに求めるのは難しいかもしれません。
ぼくの思考ルーチンは角の隣接はできる限り取らない、角を取れる時は必ず取る、その二点はまずまず隙はなかったと思います。
けれどもなぜだかこいつ、どんどん角の隣に踏み込んでいくんですね。
それはなぜか。
それは他に選択肢がないからです。
盤の四隅に角と周囲の四マスが四か所だけしか残されていない、他は埋まっている。そんな状況ならわかります。双方のルーチンが「角の隣は取らない」を厳守してのんべんだらりと進行していく（と言ったら相手に失礼か）場合はそういうこともありました。
けれどもそうでない。他にあちこちあいているのにわざわざ地雷を踏みに行く。
それは相手にこっちの手を読まれて、選択肢を少なく少なく追いつめられているからなんでしょう。おそらく。
ぼくが隣接マスの石の数を意識したのもそれに関係があって。
極端な話、敵の石を自分が完全に囲んでしまったらもうどこにも打てないわけです。
その状況に徐々に近づいていく過程で、タブーである角の隣に踏み込まざるを得ない状況に追い詰められてしまうのでしょうね。
これは相手の手を予測するしかないのでしょうかね。
相手の選択肢がなくなるように、なくなるように、誘導していく。
それには自分の石を置いた後の盤面をＤＢに置いてそれを判定するのが自然な気はします。
優勝された方がどこかのタイミングで「これを何とかするには４手先まで読まないといけないのかー」とかなんとかつぶやいていらっしゃったような記憶があります。（違ったらすいません！）
ということはまさか３手先までは読んでるというのでしょうか・・・！
次回に向けてどうするかを迷っています。
出場はもちろんしたいと思っています。
予測タイプに踏み出すか。
それとも従来の最適化路線をさらに追及するか。
処理速度なら負けません！って。
ぼくは今回の企画に参加して気付いたのですが、自分は思っていた以上に統計が好きなようです。
学生時代はさんざん嫌ったものですが。
どういう要素をどの比重でどのタイミングで加味すれば一番強いか。
それを考え試行錯誤する過程が好きです。
勝ちに行くならそんなことは言ってられないのかなぁ。
予測タイプを作るのには本体のコモンを流用できそうとはいえやはり難しそうだしめんどうかなぁ。
めんどうなんて言っていたら共同制作仲間に「それならそんな長文連投なんかしてないで作業進めてよー」と怒られそうですが。
まあまずは作り方をどうするか悩む以前に、オセロの定石などをもう少し勉強しようと思います。
いや、もちろんゲーム制作も進めますー。許して下さいー！
まあオセロに興味ない（と思う）方々がこんな長文３連発に目を通すわけはないですよね。
これでウディタリバーシシリーズはいったん終了のはずです。
長々お読み下さった方ありがとうございました。
2015年01月13日
ウディタリバーシ②
tohさん主催のウディタリバーシ企画には気軽に参加できるよ、と前回書きました。
本当にウディタの上級者でなくてもオセロの思考ルーチンを作れるのです。
そのための環境が用意されています。
もちろん大会で好成績を目指すには高い技術も必要かもしれないですが。
今回の記事ではそんな「必ずしもウディタの扱いに熟達していない方」（もちろんぼくもそうです）にむけて、思考ルーチンの作り方やぼくの考えたこと、やったことを書きます。
（昨夜の大会で戦ったような方はお恥ずかしいのであまり見ないでほしいような気もしますが。）
興味のある方はまずtohさんの企画特設ページからゲームデータをダウンロードして下さい。
ウディタの本体も同梱されているので簡単に制作開始できます。
その中のコモンに思考ルーチンサンプルというのがありますね。
それをまず改変しましょう。
これは置く石の位置を決めるコモンです。
自分の番が回ってきたらここで置く位置を決定し、位置番号で返します。
これを開いてもらえれば分かる人はわかると思いますが、意外とシンプルです。
６４あるマス全てそれぞれの現状に対して、自分の色の石を置けば何枚ひっくりかえせるかを判定します。（０枚、つまりひっくり返せない時は置けないということです）
それが置けるなら可変ＤＢ内の上から順に詰めてに置ける位置番号を記憶させています。
ＤＢが完成したらＤＢの項目数から０の間のランダムな数をを選び、そこに格納されている位置番号を返す、それだけです。
もちろんランダムだから強くはないですが。
でもたったこれだけの処理で置けない場所に置いてしまったりその他いろいろややこしいことを解決してくれてるんだから素敵ですね。
そこでこれを改造するわけですが。
いちばん簡単なのは６４か所を判定する時に条件を付け、特定位置ならそこに即決してしまうことでしょうね。
６４回のループの中に
「判定位置が角（を示す番号）の時、置ける石の数が１以上だったら置く位置はそこ！そしてこのイベントは終了！」
そんな処理を挟み込むだけで、角に置けるなら有無を言わさず置いてしまう、あなただけの思考ルーチンが出来上がりです。（角に置けなければランダムに置く）
どうです？意外と簡単じゃないでしょうか？
（今回の記事はウディタのすごく初心者の方は対象でないので、すいませんがご了承ください。）
自分のオリジナル思考ルーチンができたら、それを元からあるランダムに置くルーチンと対決させられます。
４隅に置ける時だけ置く、それだけでも勝率に影響はあるはずです。
統計の好きな方にとってこれって身震いするほど興味深いことだと思いますよ。
自分が好きに設定した思考ルーチンがどれほど戦績に影響するか。
角を取ったら有利と言われますが、ではそれ以外の、例えば左上から右に３下に３（3-cとかいうらしい）ならどうでしょう？ランダムに比べたらやはり負けやすくなるか勝ちやすくなるか、かすかな影響はあるでしょう。
おもしろいですよねー。おもしろくないですかー？
さて、位置によって条件分岐する方法は一番簡単で、角を取れるなら取ろうというのはおそらく戦略としてそんなに間違っていなさそうな気がします。
けれどもその次、さてどうするかという時に技術以前に大きな問題がありました。
オセロのいい手とはどういうものかということ自体がぼくはわかってないんですよね。
正直に言うとこれまでぼくは、常に最大枚数ひっくりかえせる位置に置けばいいのかなくらいに思ってました。
けれども検索して調べたら全然そんなことはないんですね。
むしろ序盤は取りすぎないくらいがいいと書いてあったりする。
そして自分の石が相手の色に囲まれるほどいいという。
そんなこんなをぼくは初めて知りました。
それと、角の隣はやはり置きたくない。
それらに考慮した思考ルーチンをぼくは作りました。
使った要素としては、
・角か、角の隣接マスか、そうでないか
・置く位置に隣接する石はいくつあるか
・石を置くのは何手目か
・何枚ひっくりかえせるか
です。
それに加えて、それらの要素をどう加味して最終決定するかという仕組みも作りました。
だって角の隣に置きたくないとはいえ、他に置けないなら置くしかないのに、もしいつまでも置かなかったら失格になりますもんね。
そのために各要素で加点減点させて最終決定するようにしました。
プログラム用語でそういうのをどう言うのかは知りません。
それらについて上から順に、どうやったかをざっと書きますね。
・角か、角の隣接マスか、そうでないか
愚直に全部条件分岐で済ませました。
角およびその周囲は１６マスありますが。
１６回の分岐を作り、「もし判定位置がそれに該当したら～」としました。
もっとスマートな方法もあるんでしょうけどね。
まあコマンドが長くなろうが自分にとって分かりやすいのが一番です。
・置く位置に隣接する石はいくつあるか
位置番号は連番なのにＤＢにある盤面記録は左から何番目、上から何番目と座標形式になってます。
その値は位置番号を割ったり、％を使って割った余りを求めたりで出せます。
これまた愚直に、その石の隣接位置を示す座標を８回設定し、石があるかを判定しました。
主催者tohさんはそんな時の為に判定座標が盤面から出ていないかを調べるコモンまで作ってくれているのです！その親切設計には感激しました。
周囲８か所に石があるかを判定した結果の合計が隣接石数です。
・石を置くのは何手目か
序盤中盤と局面に応じて打つ手を変えるにはこれを判定しないといけません。
どうしたらいいかわからなかったのでこのコモンの実行回数を数えたんですけどね。
自分の手番が来る度に呼び出されるんだからその回数を数えれば何手目かわかるはずだ、と。
でもtohさんのツイッターを見てたらなんと大会では連戦するというんですね。
それだとコモン内変数が初期化されない！
そこであわててとりみだしてtohさんにどうしましょーとかお恥ずかしいメールを送ったのですが、ゲーム本体で使用されている「石数を表示するための変数」を参照することでなんとか自己解決しました。
・何枚ひっくり返せるか
これは簡単。tohさんが用意してくれてるコモンが自動的に数値を返してくれます。
これをもし自力で作らないといけなかったらぼくはこの企画には参加できなかったと思います。
そしてこれらの要素を使い、石を置く位置としての適切さを比較・判定する仕組みを作りました。
可変ＤＢに数値を置く欄を作って足したり引いたりしました。
角なら＋１００点、角の隣ならー５０点。
局面が３０手までならそれに隣接石数を加点。それ以降は返せる枚数を加点。
そんな風にしてみました。
それ以外の要素として、外枠に接する位置（以下外枠といいます）も判定したのですが。
外枠ってちょっとひっくり返されにくそうじゃないですか。
なので優先的に取るようにしたらどうかと思って試したら・・・全然そんなことはなかったです。
「外枠なら取る、そうでなければランダム」という思考ルーチンを作って「ただのランダム」と対戦させたところ、なんと負けてしまいました。
あれ？今思いついたんですが、それなら「外枠ならポイント減点」という機能をつけたらもうちょっと強くできたのだろうか？
見た目的に返されにくそう、という自分の直感を取るか、統計結果を取るか。ですよね。
統計と言ってもその比較対象がランダムかそれともぼくの考えた似たり寄ったりのシステムしかないというのが、その戦術の有効性を推し量るのに効果があるのかないのかも全くわからないのですが。
でもそれににしたってランダム配置にも負けるって、どれだけ弱いんでしょうね。
置く位置を最終決定するには、ＤＢ内にある獲得点数の最大値を持つ位置番号を見つけないといけません。
上から順に現在の最大値が参照中の値以下だったら最大値を更新、そうでなかったら何もせず下の項目の判定に移る、ということをしました。
（プログラムを触り慣れた方にはきっとそういうのはあまりに決まり切った手順なのかもしれませんが、ぼくのような素人はいつも手探り・手作りです。）
また、各要素が決定に与える影響力をどうするかや、序盤中盤の切り替わり時も何手目にするか試行錯誤して悩みました。
隣接石数から返す石数に切り替えるタイミングは３０手目（自分の１５手目）にしました。
それ以前よりもそれ以後よりも一番勝率が高かったからです。
まあそれだって本当に同時に切り替えがいいのかなんて全然わからないのですが。
ひょっとしたら１０手目から返す石数を意識し出した方がいいのかもしれないし、終盤まで隣接石数にこだわった方が強かったのかもしれません。
けれど全部の状況を試すわけにもいきませんもんね。
え？全部の状況を試すわけにいかない？
できないことはないとは思います。このゲームデータを改造し、ある変数を徐々に上げていく異なる思考ルーチンで多様な相手と連戦させデータを取り、最適解を求める。それを自動化する。
実行時間はかかりますが半分放置で、ウディタの機能としてはできると思います。
ぼくの技術でできるだろうか。ぎりぎりできそうな気もします。
けれども、意欲は、ない！！！です。さすがにさすがに、そこまでは。
まあともかく、そんなこんなでできたのを昨夜の大会に提出し、見事２勝５敗の戦績をおさめたわけです。
ぼくの作ったコモンは企画用特設ページから入手できるようにしてもらえると思います、いずれ。
ぼくのコモンは強いか弱いかというとまあ２勝５敗という数字で現れる程度なのですが、この思考ルーチン作成に当たっては比較対象が多く欲しいというのは切実に感じたんですよね。
上にも書きましたが、新しい要素を導入してみてそれが勝率アップにつながるのか判定したい時。
勝ったからと言って、その対戦相手の特性に依存したものかどうかの判定がすごく難しいんです。
難しいというか不可能なので、疑心暗鬼にならざるを得ない。
しかも同じ相手でもボロ勝ち、ボロ負け両方起こることすらあるし、なにがなんだかわからない。
そのなにがなんだかわからない中にも一つの参考材料になればという気持ちを込めて、コモンの公開をtohさんにお願いしたという次第です。
さて、そうして大会本番を迎えました。
これ以上は長くなるので（もう十分に長いけど）、その時の模様や感じたことなどは次の記事に書きます。
本当にウディタの上級者でなくてもオセロの思考ルーチンを作れるのです。
そのための環境が用意されています。
もちろん大会で好成績を目指すには高い技術も必要かもしれないですが。
今回の記事ではそんな「必ずしもウディタの扱いに熟達していない方」（もちろんぼくもそうです）にむけて、思考ルーチンの作り方やぼくの考えたこと、やったことを書きます。
（昨夜の大会で戦ったような方はお恥ずかしいのであまり見ないでほしいような気もしますが。）
興味のある方はまずtohさんの企画特設ページからゲームデータをダウンロードして下さい。
ウディタの本体も同梱されているので簡単に制作開始できます。
その中のコモンに思考ルーチンサンプルというのがありますね。
それをまず改変しましょう。
これは置く石の位置を決めるコモンです。
自分の番が回ってきたらここで置く位置を決定し、位置番号で返します。
これを開いてもらえれば分かる人はわかると思いますが、意外とシンプルです。
６４あるマス全てそれぞれの現状に対して、自分の色の石を置けば何枚ひっくりかえせるかを判定します。（０枚、つまりひっくり返せない時は置けないということです）
それが置けるなら可変ＤＢ内の上から順に詰めてに置ける位置番号を記憶させています。
ＤＢが完成したらＤＢの項目数から０の間のランダムな数をを選び、そこに格納されている位置番号を返す、それだけです。
もちろんランダムだから強くはないですが。
でもたったこれだけの処理で置けない場所に置いてしまったりその他いろいろややこしいことを解決してくれてるんだから素敵ですね。
そこでこれを改造するわけですが。
いちばん簡単なのは６４か所を判定する時に条件を付け、特定位置ならそこに即決してしまうことでしょうね。
６４回のループの中に
「判定位置が角（を示す番号）の時、置ける石の数が１以上だったら置く位置はそこ！そしてこのイベントは終了！」
そんな処理を挟み込むだけで、角に置けるなら有無を言わさず置いてしまう、あなただけの思考ルーチンが出来上がりです。（角に置けなければランダムに置く）
どうです？意外と簡単じゃないでしょうか？
（今回の記事はウディタのすごく初心者の方は対象でないので、すいませんがご了承ください。）
自分のオリジナル思考ルーチンができたら、それを元からあるランダムに置くルーチンと対決させられます。
４隅に置ける時だけ置く、それだけでも勝率に影響はあるはずです。
統計の好きな方にとってこれって身震いするほど興味深いことだと思いますよ。
自分が好きに設定した思考ルーチンがどれほど戦績に影響するか。
角を取ったら有利と言われますが、ではそれ以外の、例えば左上から右に３下に３（3-cとかいうらしい）ならどうでしょう？ランダムに比べたらやはり負けやすくなるか勝ちやすくなるか、かすかな影響はあるでしょう。
おもしろいですよねー。おもしろくないですかー？
さて、位置によって条件分岐する方法は一番簡単で、角を取れるなら取ろうというのはおそらく戦略としてそんなに間違っていなさそうな気がします。
けれどもその次、さてどうするかという時に技術以前に大きな問題がありました。
オセロのいい手とはどういうものかということ自体がぼくはわかってないんですよね。
正直に言うとこれまでぼくは、常に最大枚数ひっくりかえせる位置に置けばいいのかなくらいに思ってました。
けれども検索して調べたら全然そんなことはないんですね。
むしろ序盤は取りすぎないくらいがいいと書いてあったりする。
そして自分の石が相手の色に囲まれるほどいいという。
そんなこんなをぼくは初めて知りました。
それと、角の隣はやはり置きたくない。
それらに考慮した思考ルーチンをぼくは作りました。
使った要素としては、
・角か、角の隣接マスか、そうでないか
・置く位置に隣接する石はいくつあるか
・石を置くのは何手目か
・何枚ひっくりかえせるか
です。
それに加えて、それらの要素をどう加味して最終決定するかという仕組みも作りました。
だって角の隣に置きたくないとはいえ、他に置けないなら置くしかないのに、もしいつまでも置かなかったら失格になりますもんね。
そのために各要素で加点減点させて最終決定するようにしました。
プログラム用語でそういうのをどう言うのかは知りません。
それらについて上から順に、どうやったかをざっと書きますね。
・角か、角の隣接マスか、そうでないか
愚直に全部条件分岐で済ませました。
角およびその周囲は１６マスありますが。
１６回の分岐を作り、「もし判定位置がそれに該当したら～」としました。
もっとスマートな方法もあるんでしょうけどね。
まあコマンドが長くなろうが自分にとって分かりやすいのが一番です。
・置く位置に隣接する石はいくつあるか
位置番号は連番なのにＤＢにある盤面記録は左から何番目、上から何番目と座標形式になってます。
その値は位置番号を割ったり、％を使って割った余りを求めたりで出せます。
これまた愚直に、その石の隣接位置を示す座標を８回設定し、石があるかを判定しました。
主催者tohさんはそんな時の為に判定座標が盤面から出ていないかを調べるコモンまで作ってくれているのです！その親切設計には感激しました。
周囲８か所に石があるかを判定した結果の合計が隣接石数です。
・石を置くのは何手目か
序盤中盤と局面に応じて打つ手を変えるにはこれを判定しないといけません。
どうしたらいいかわからなかったのでこのコモンの実行回数を数えたんですけどね。
自分の手番が来る度に呼び出されるんだからその回数を数えれば何手目かわかるはずだ、と。
でもtohさんのツイッターを見てたらなんと大会では連戦するというんですね。
それだとコモン内変数が初期化されない！
そこであわててとりみだしてtohさんにどうしましょーとかお恥ずかしいメールを送ったのですが、ゲーム本体で使用されている「石数を表示するための変数」を参照することでなんとか自己解決しました。
・何枚ひっくり返せるか
これは簡単。tohさんが用意してくれてるコモンが自動的に数値を返してくれます。
これをもし自力で作らないといけなかったらぼくはこの企画には参加できなかったと思います。
そしてこれらの要素を使い、石を置く位置としての適切さを比較・判定する仕組みを作りました。
可変ＤＢに数値を置く欄を作って足したり引いたりしました。
角なら＋１００点、角の隣ならー５０点。
局面が３０手までならそれに隣接石数を加点。それ以降は返せる枚数を加点。
そんな風にしてみました。
それ以外の要素として、外枠に接する位置（以下外枠といいます）も判定したのですが。
外枠ってちょっとひっくり返されにくそうじゃないですか。
なので優先的に取るようにしたらどうかと思って試したら・・・全然そんなことはなかったです。
「外枠なら取る、そうでなければランダム」という思考ルーチンを作って「ただのランダム」と対戦させたところ、なんと負けてしまいました。
あれ？今思いついたんですが、それなら「外枠ならポイント減点」という機能をつけたらもうちょっと強くできたのだろうか？
見た目的に返されにくそう、という自分の直感を取るか、統計結果を取るか。ですよね。
統計と言ってもその比較対象がランダムかそれともぼくの考えた似たり寄ったりのシステムしかないというのが、その戦術の有効性を推し量るのに効果があるのかないのかも全くわからないのですが。
でもそれににしたってランダム配置にも負けるって、どれだけ弱いんでしょうね。
置く位置を最終決定するには、ＤＢ内にある獲得点数の最大値を持つ位置番号を見つけないといけません。
上から順に現在の最大値が参照中の値以下だったら最大値を更新、そうでなかったら何もせず下の項目の判定に移る、ということをしました。
（プログラムを触り慣れた方にはきっとそういうのはあまりに決まり切った手順なのかもしれませんが、ぼくのような素人はいつも手探り・手作りです。）
また、各要素が決定に与える影響力をどうするかや、序盤中盤の切り替わり時も何手目にするか試行錯誤して悩みました。
隣接石数から返す石数に切り替えるタイミングは３０手目（自分の１５手目）にしました。
それ以前よりもそれ以後よりも一番勝率が高かったからです。
まあそれだって本当に同時に切り替えがいいのかなんて全然わからないのですが。
ひょっとしたら１０手目から返す石数を意識し出した方がいいのかもしれないし、終盤まで隣接石数にこだわった方が強かったのかもしれません。
けれど全部の状況を試すわけにもいきませんもんね。
え？全部の状況を試すわけにいかない？
できないことはないとは思います。このゲームデータを改造し、ある変数を徐々に上げていく異なる思考ルーチンで多様な相手と連戦させデータを取り、最適解を求める。それを自動化する。
実行時間はかかりますが半分放置で、ウディタの機能としてはできると思います。
ぼくの技術でできるだろうか。ぎりぎりできそうな気もします。
けれども、意欲は、ない！！！です。さすがにさすがに、そこまでは。
まあともかく、そんなこんなでできたのを昨夜の大会に提出し、見事２勝５敗の戦績をおさめたわけです。
ぼくの作ったコモンは企画用特設ページから入手できるようにしてもらえると思います、いずれ。
ぼくのコモンは強いか弱いかというとまあ２勝５敗という数字で現れる程度なのですが、この思考ルーチン作成に当たっては比較対象が多く欲しいというのは切実に感じたんですよね。
上にも書きましたが、新しい要素を導入してみてそれが勝率アップにつながるのか判定したい時。
勝ったからと言って、その対戦相手の特性に依存したものかどうかの判定がすごく難しいんです。
難しいというか不可能なので、疑心暗鬼にならざるを得ない。
しかも同じ相手でもボロ勝ち、ボロ負け両方起こることすらあるし、なにがなんだかわからない。
そのなにがなんだかわからない中にも一つの参考材料になればという気持ちを込めて、コモンの公開をtohさんにお願いしたという次第です。
さて、そうして大会本番を迎えました。
これ以上は長くなるので（もう十分に長いけど）、その時の模様や感じたことなどは次の記事に書きます。
ウディタリバーシ①
あけましておめでとうございます。
ぼくは近ごろもあいかわらずゲームの集団制作を進めています。
さてウディタリバーシ企画（tohさん主催）というイベントにこのたび参加しました。
それに関連していくつか記事を書こうと思います。
一回目の今回は、ウディタリバーシ企画とはどのようなものかについてです。
tohさんの企画特設ページへ
上のリンクを見てもらえば詳しいことは分かるのですが、ぼくなりに説明させてもらいます。
ひとことでいえば「ウディタで作ったオセロの思考ルーチンをみんなで競おう」という企画です。
第一回目の大会は昨夜あり、ぼくも参加して２勝５敗の成績をおさめました！
最初この企画を見かけた時は実はいまいち敬遠していたのです。
オセロをウディタで作るなんてそんなの大変すぎる、自分には無理に違いない、と。
けれども一晩考えて、できないのはできないにしても興味は湧いてきました。
特に盤面情報を保持する方法とデータベースを使用できるのか知りたくなりました。
そこで主催者のtohさんが配布しているゲームデータをのぞいてみました。
のぞいてびっくり、とても簡単でした。
いや、思考ルーチン作りは別に簡単ではないのですが、それ以外の面倒なもろもろはtohさんが
一手に実装してくれていました。
ぼくが今回のこの記事で書くことは、上のリンクとそこで配布されているゲームデータを見ればわかることです。
けれどもあえて記事にして何を伝えたいかといえば、思った以上に気軽に参加できるよ！ということです。
もちろんウディタの技術は必要です。コモンイベントを自作した経験がある方でないと難しいとは思います。
でも参加者はオセロの仕組みを作る手間にわずらわされることなく、一番楽しいエッセンスの部分だけを作れるのです。
どこに石を置けるのか、そこに置けば何枚の石を裏返すことができるのかを取得する方法も既に用意されています。
作成した思考ルーチン同士対戦させたりプレイヤーと戦ったりする機能も実装済みです。
親切なことには選択可能な指し手の中からランダムで選ぶサンプルコモンまで添付されています。
そのコモンをほんのちょっと改変して・・・。
例えばランダムに選ぶ処理の前に「その場所が角ならそこに置く」という処理を置けば、それだけで自分なりの思考ルーチンの完成です。
ぼくがどんな方法でどんなコモンを作り大会に臨んだかは次の記事に書きます。
次回の大会も近いうちに開催されるようです。
ぼくのように先入観で敬遠する人のためにこの文を書きました。
意外と簡単！レベルを問わなければ、ウディタを使う人なら誰でも参加できる企画です。
みなさんもぜひどうぞ。
ぼくは近ごろもあいかわらずゲームの集団制作を進めています。
さてウディタリバーシ企画（tohさん主催）というイベントにこのたび参加しました。
それに関連していくつか記事を書こうと思います。
一回目の今回は、ウディタリバーシ企画とはどのようなものかについてです。
tohさんの企画特設ページへ
上のリンクを見てもらえば詳しいことは分かるのですが、ぼくなりに説明させてもらいます。
ひとことでいえば「ウディタで作ったオセロの思考ルーチンをみんなで競おう」という企画です。
第一回目の大会は昨夜あり、ぼくも参加して２勝５敗の成績をおさめました！
最初この企画を見かけた時は実はいまいち敬遠していたのです。
オセロをウディタで作るなんてそんなの大変すぎる、自分には無理に違いない、と。
けれども一晩考えて、できないのはできないにしても興味は湧いてきました。
特に盤面情報を保持する方法とデータベースを使用できるのか知りたくなりました。
そこで主催者のtohさんが配布しているゲームデータをのぞいてみました。
のぞいてびっくり、とても簡単でした。
いや、思考ルーチン作りは別に簡単ではないのですが、それ以外の面倒なもろもろはtohさんが
一手に実装してくれていました。
ぼくが今回のこの記事で書くことは、上のリンクとそこで配布されているゲームデータを見ればわかることです。
けれどもあえて記事にして何を伝えたいかといえば、思った以上に気軽に参加できるよ！ということです。
もちろんウディタの技術は必要です。コモンイベントを自作した経験がある方でないと難しいとは思います。
でも参加者はオセロの仕組みを作る手間にわずらわされることなく、一番楽しいエッセンスの部分だけを作れるのです。
どこに石を置けるのか、そこに置けば何枚の石を裏返すことができるのかを取得する方法も既に用意されています。
作成した思考ルーチン同士対戦させたりプレイヤーと戦ったりする機能も実装済みです。
親切なことには選択可能な指し手の中からランダムで選ぶサンプルコモンまで添付されています。
そのコモンをほんのちょっと改変して・・・。
例えばランダムに選ぶ処理の前に「その場所が角ならそこに置く」という処理を置けば、それだけで自分なりの思考ルーチンの完成です。
ぼくがどんな方法でどんなコモンを作り大会に臨んだかは次の記事に書きます。
次回の大会も近いうちに開催されるようです。
ぼくのように先入観で敬遠する人のためにこの文を書きました。
意外と簡単！レベルを問わなければ、ウディタを使う人なら誰でも参加できる企画です。
みなさんもぜひどうぞ。
ラベル：ウディタリバーシ
2014年10月26日
ゲームのアイデアを募集しました
ゲームのアイデアを募集しました。
いただいたアイデアを元に、作成していきたいと思っています。
ご応募してくださった方、ご応募を考えてくださった方、ありがとうございました！
いただいたアイデアを元に、作成していきたいと思っています。
ご応募してくださった方、ご応募を考えてくださった方、ありがとうございました！
2014年08月19日
残像コモン完成！
主人公画像ピクチャ表示の応用企画第二弾！
残像コモンができました。
半歩移動ごとに像を残したはずなのになぜかせまく見えます。イモムシみたい・・・。
デフォルトではもっと間隔をあけるようにします。
数十フレームかけて後ろから消えていく仕様です。
≪今日学んだこと≫
変数操作＋で画像サイズを取得しても、素材としての元のサイズしかわからない。
表示時に拡大率を指定して表示サイズが実際は違っていても、それは判定できない。
表示中のサイズが知りたければ取得した値に拡大率をかけて100で割ることが必要。
残像コモンができました。
半歩移動ごとに像を残したはずなのになぜかせまく見えます。イモムシみたい・・・。
デフォルトではもっと間隔をあけるようにします。
数十フレームかけて後ろから消えていく仕様です。
≪今日学んだこと≫
変数操作＋で画像サイズを取得しても、素材としての元のサイズしかわからない。
表示時に拡大率を指定して表示サイズが実際は違っていても、それは判定できない。
表示中のサイズが知りたければ取得した値に拡大率をかけて100で割ることが必要。
2014年08月18日
溶解コモン
先日作った主人公歩行グラのピクチャ表示コモンを応用し、いろいろな表現をしようと思います。
今日は歩けば歩くほど主人公の体が溶けていくコモンを作りました。
名付けて溶解コモン！
足元から徐々に溶けて身長は低くなり、そのうち頭だけになり、最後は横線だけになったりします。
・１ピクセル溶けるのに何歩かかるか
・最終的に何ピクセル残るか
・溶ける時に鳴る効果音
を指定できるようにしました。
完全に透明人間にしてしまうと操作がストレスフルになるので、溶け残り？の表示ありをデフォルトにしました。
これを使ってゲームを作るなら、何歩歩いてどれだけ溶けたかがわかる万歩計溶解ウォッチというアイテムを出したいなとか夢をひろげています。
生首といいグロテスクなのは嫌いなはずなのだけどもなぜか作ってしまう・・・。
似たような応用コモンがたくさんできたら、いずれまとめて公開したいです。
≪今日学んだこと≫
回数付きループの回数は0未満には指定できない。
ただし変数で指定した場合は回数をマイナスにすることもできる。
けれどもその場合ループ内は実行されず、0回と同じ扱いにされるらしい。
今日は歩けば歩くほど主人公の体が溶けていくコモンを作りました。
名付けて溶解コモン！
足元から徐々に溶けて身長は低くなり、そのうち頭だけになり、最後は横線だけになったりします。
・１ピクセル溶けるのに何歩かかるか
・最終的に何ピクセル残るか
・溶ける時に鳴る効果音
を指定できるようにしました。
完全に透明人間にしてしまうと操作がストレスフルになるので、溶け残り？の表示ありをデフォルトにしました。
これを使ってゲームを作るなら、何歩歩いてどれだけ溶けたかがわかる万歩計溶解ウォッチというアイテムを出したいなとか夢をひろげています。
生首といいグロテスクなのは嫌いなはずなのだけどもなぜか作ってしまう・・・。
似たような応用コモンがたくさんできたら、いずれまとめて公開したいです。
≪今日学んだこと≫
回数付きループの回数は0未満には指定できない。
ただし変数で指定した場合は回数をマイナスにすることもできる。
けれどもその場合ループ内は実行されず、0回と同じ扱いにされるらしい。
2014年08月17日
万能型用語辞典の改変版を公開、と、もぐらたたきコモンのこと
万能型用語辞典の改変版というのを作って公式コモン集に登録しました。
もとはシニスレッドさん（悪魔の壁さん）という方が作った用語辞典です。
登録済み情報を一覧できるコモンだったのですが、それにゲーム内で追加していけるように改変しました。
ぼくの処女作ネオ繚乱記でも、サークル製らすとあとりえでも使わせてもらったものです。
Read meの一部分を抜粋するとこんな感じです。
＜コモンの仕組み＞
ユーザＤＢは完成した事典です。
可変ＤＢは始めは白紙の事典です。
記入コモンで指定項目を書き写します。
表示コモンでその時点の可変ＤＢの内容を表示します。
どんなことをするコモンかなんとなくイメージしてもらえるでしょうか・・・？
公式コモン集のコメント欄でそのコモンをほしいという要望を２回もらったので公開にいたりました。
用語辞典としてはもちろん、アイテム図鑑やモンスター図鑑として便利です。
基本システムのデータベースと連動していないので応用がきくかと思います。
データベースのアイテムリストやモンスターリストと連動させるにはほんの少しだけ改造が必要です。
現状ではゲーム内で記入した順に上から詰めて項目が増えていきます。
なのでアイテムなどのコンプリートを目指して「？？？」を明らかにしていくような場合にも改造は必要です。
シニスレッドさん（悪魔の壁さん）ありがとうございました。
なお、このコモンと合わせてらすとあとりえで使った、はつやさん作もぐらたたきコモンも改造・公開しようと思ったのですが、あまりに簡単な改造で済むので公開は遠慮することにしました。限りなく再配布になってしまうので・・・。
あれはウディタ２に未対応なんですよね。それをコモン１行いじるだけで対応させられるので、方法は公式コモン集のコメントに書きました（もぐらで検索！）。
らすとあとりえでもぐらたたきをして、もしも「使ったみたい」と思った方がいたら参考にしてください。
もとはシニスレッドさん（悪魔の壁さん）という方が作った用語辞典です。
登録済み情報を一覧できるコモンだったのですが、それにゲーム内で追加していけるように改変しました。
ぼくの処女作ネオ繚乱記でも、サークル製らすとあとりえでも使わせてもらったものです。
Read meの一部分を抜粋するとこんな感じです。
＜コモンの仕組み＞
ユーザＤＢは完成した事典です。
可変ＤＢは始めは白紙の事典です。
記入コモンで指定項目を書き写します。
表示コモンでその時点の可変ＤＢの内容を表示します。
どんなことをするコモンかなんとなくイメージしてもらえるでしょうか・・・？
公式コモン集のコメント欄でそのコモンをほしいという要望を２回もらったので公開にいたりました。
用語辞典としてはもちろん、アイテム図鑑やモンスター図鑑として便利です。
基本システムのデータベースと連動していないので応用がきくかと思います。
データベースのアイテムリストやモンスターリストと連動させるにはほんの少しだけ改造が必要です。
現状ではゲーム内で記入した順に上から詰めて項目が増えていきます。
なのでアイテムなどのコンプリートを目指して「？？？」を明らかにしていくような場合にも改造は必要です。
シニスレッドさん（悪魔の壁さん）ありがとうございました。
なお、このコモンと合わせてらすとあとりえで使った、はつやさん作もぐらたたきコモンも改造・公開しようと思ったのですが、あまりに簡単な改造で済むので公開は遠慮することにしました。限りなく再配布になってしまうので・・・。
あれはウディタ２に未対応なんですよね。それをコモン１行いじるだけで対応させられるので、方法は公式コモン集のコメントに書きました（もぐらで検索！）。
らすとあとりえでもぐらたたきをして、もしも「使ったみたい」と思った方がいたら参考にしてください。
2014年08月16日
歩行グラ部分表示に不透明度を設定
おとつい夜に公開した歩行グラ部分表示コモンですが、公式コモン集で「下半身を透過表示すれば」というご意見をいただきました。これは目からウロコ！
そこでさっそく上半身と下半身、それぞれの不透明度を設定できるようにしました。
公式コモン集で公開中！
すると水中らしい演出ができるのみならず、下半身のみの表示まで可能になりました！
（何に使えるかわかりませんが）
アドバイスくださったバルゴさん、本当にありがとうございました！
そこでさっそく上半身と下半身、それぞれの不透明度を設定できるようにしました。
公式コモン集で公開中！
すると水中らしい演出ができるのみならず、下半身のみの表示まで可能になりました！
（何に使えるかわかりませんが）
アドバイスくださったバルゴさん、本当にありがとうございました！
2014年08月09日
水面に映る像
ここをご覧の方で、らすとあとりえのＶｅｒ．３．００以降を遊んでくれた方がどれくらいいるかわかりませんが。
カーライカムという町の川辺に行くと、水面に主人公の上半身だけが映ります。
そう、このブログで前からちょこっと言っていた、歩行グラフィックの部分表示に成功しました。
↑
足が映ってっていない！たったこれだけのことがウディタでは画期的！（多分）
鏡面床は前に完成していました。床全面に像が映る場合には対応できていたのです。
けれども水辺で主人公の姿が水面に映る時、足元のがけ部分に足が映るのがおかしいので、歩行グラの部分表示を目指していました。
それがこの度できたわけです。
原理としては１キャラ分の画像を高さ１ピクセルの横線の集合としてとらえ、その線を上下並び順を逆にして１ピクセルづつずらして表示する、という方法です。
並列実行しておけばリアルタイムに主人公の位置に対応した部分像を主人公の足元に表示できました。
けれども・・・。
問題は起動条件でした。
カーライカムでは水面像表示の起動条件は水辺のマスを踏むこと、消去の条件はその上のマスを踏むことです。
実はこれ、納得いってません。
というのも像の表示がついたり消えたりするのに違和感があるのです。
前に公開した鏡コモンや鏡面床コモンでは地底に常時表示していたために、マップチップからはみ出した部分がピクセル単位の滑らかさで表示されていたんですよね。
それが今回は、表示するか消えるかのどちらかだけです。表示場所に到着するまでは一切表示されないし、消去場所に到着するまでは全身消去されません。
これじゃせっかく足元だけ映らないようにしたのに、結局陸上でも像が映ってしまっています。
らすと あとりえは歩幅は一歩を採用しているのですが、半歩なら更におかしなことになりそうです。
地底表示の滑らかさを体験してしまっているだけによけい満足できません。
がけや水面のマップチップを使わないといけないので地底表示が使えず、そんな状況になっているのです。
ところでこんなことを言うと差しさわりがあるのかもしれませんが、ぼくが水面に像が映るコモンを作りたいのはらすと あとりえの為ではないです。
そのコモンを公開して、大げさに言うとウディタの可能性を広げたいというか。
ウディタでできることを増やして、多くの人に選択肢として提示したいということがあります。
だからある程度汎用性があって導入もしやすいものができないと意味がないんですよね。
結論から言うと、今回水面に映る像のコモンの一般公開はしません。
歩行グラの部分表示ができて、なおかつその像が鏡面床のようになめらかに表示できたなら多くの人に喜んでもらえると思うのですが・・・。
残念ながら今のぼくでは汎用性を持たせて導入しやすいものを作るには技量が足りないようです。
以下にどうすれば実現できるか、考えたことを記録しておきます。
とにかく像の表示位置を地底にしないと、なめらかな表示はできないようです。
（水辺周囲の全てのマスの地形をイベントとして配置してマップ上イベント下に表示という手もあるかもしれませんが、それをコモン利用者全員に強制するのは無理がありそうです。導入に手間がかかりすぎるし、ぼくも利用希望者全員に理解してもらえるよう説明できる自信はありません。）
地底に表示はしたいのですが、がけ部分がないと足を消している意味がありません。
だからがけは表示したいです。
とすると、がけ部分だけ表示し、水面部分だけ透過処理したオートタイルマップチップが必要です。
それを作ればいいのですが、ウディタ同梱素材でマップを作る場合、水辺のがけと言えばタイルセットの一番上、右から４番目を使うことが多いかと思います。そこでその水部分を透過すればいいのですが、あのチップは周囲が透過されていて、下地の草地や砂地の上に水を配するようになっています。本来レイヤー２以上で使うものなんですね。レイヤー１で使うと岸部分が黒くなってしまいます。
だから水面を透過した差し替え用素材を用意するなら、岸部分に使用を想定される黄緑や肌色を配さないといけないです。
それがぼくにはなかなか難しい。
ドット素材を本格的に作ったことがないので、黄緑や肌色の大地と連結させて不自然じゃない水辺を作るにはそうとうな労力が必要です。
その上そうして作ったとしても汎用性を持たせられない。
「水面に映る像を使いたければ地面の色は黄緑か肌色限定でお願いします」となってしまう。
しかも更にその導入はオートタイルの差し替えや設定が必要で、初心者が気軽にできるものではないかもしれない。
そこまで思うと同梱素材の改変で水面像を表示させるのは大変だと思いました。
がけ素材としてそのまま使えそうな同梱マップチップを探しましたが・・・。
木製のドア枠の上部なんてちょうどいいんですけどね。
ドア枠をがけに見立てた
でもこれをがけとして見るとがけの中ほどに水面ラインがあるので、ライン以下は映らないとおかしいですね。つまりマップチップより上・・・。これを採用するなら地底という手は使えないようです。
前にも書きましたがこの技術は生首とか、ホラーの演出にも使えそうですけどね。まあ趣味じゃないので作る予定はしていません。
関係ないけど、ピクチャの部分表示コモンなんて需要はあるのかな？
パターンを考えないといけない歩行グラフィックと違って、ただの一枚素材のグラフィックを部分表示することはとても簡単です。
でもウディタじゃ手軽にはできないから作ったら使ってもらえるかもしれない！
何より汎用性があるのがいいですね。
どんな状況で使うのか想像はつきませんが。ちょっと考えてみよう・・・。
まあそんなこんな試行錯誤をしているという、近況報告でした。
カーライカムという町の川辺に行くと、水面に主人公の上半身だけが映ります。
そう、このブログで前からちょこっと言っていた、歩行グラフィックの部分表示に成功しました。
↑
足が映ってっていない！たったこれだけのことがウディタでは画期的！（多分）
鏡面床は前に完成していました。床全面に像が映る場合には対応できていたのです。
けれども水辺で主人公の姿が水面に映る時、足元のがけ部分に足が映るのがおかしいので、歩行グラの部分表示を目指していました。
それがこの度できたわけです。
原理としては１キャラ分の画像を高さ１ピクセルの横線の集合としてとらえ、その線を上下並び順を逆にして１ピクセルづつずらして表示する、という方法です。
並列実行しておけばリアルタイムに主人公の位置に対応した部分像を主人公の足元に表示できました。
けれども・・・。
問題は起動条件でした。
カーライカムでは水面像表示の起動条件は水辺のマスを踏むこと、消去の条件はその上のマスを踏むことです。
実はこれ、納得いってません。
というのも像の表示がついたり消えたりするのに違和感があるのです。
前に公開した鏡コモンや鏡面床コモンでは地底に常時表示していたために、マップチップからはみ出した部分がピクセル単位の滑らかさで表示されていたんですよね。
それが今回は、表示するか消えるかのどちらかだけです。表示場所に到着するまでは一切表示されないし、消去場所に到着するまでは全身消去されません。
これじゃせっかく足元だけ映らないようにしたのに、結局陸上でも像が映ってしまっています。
らすと あとりえは歩幅は一歩を採用しているのですが、半歩なら更におかしなことになりそうです。
地底表示の滑らかさを体験してしまっているだけによけい満足できません。
がけや水面のマップチップを使わないといけないので地底表示が使えず、そんな状況になっているのです。
ところでこんなことを言うと差しさわりがあるのかもしれませんが、ぼくが水面に像が映るコモンを作りたいのはらすと あとりえの為ではないです。
そのコモンを公開して、大げさに言うとウディタの可能性を広げたいというか。
ウディタでできることを増やして、多くの人に選択肢として提示したいということがあります。
だからある程度汎用性があって導入もしやすいものができないと意味がないんですよね。
結論から言うと、今回水面に映る像のコモンの一般公開はしません。
歩行グラの部分表示ができて、なおかつその像が鏡面床のようになめらかに表示できたなら多くの人に喜んでもらえると思うのですが・・・。
残念ながら今のぼくでは汎用性を持たせて導入しやすいものを作るには技量が足りないようです。
以下にどうすれば実現できるか、考えたことを記録しておきます。
とにかく像の表示位置を地底にしないと、なめらかな表示はできないようです。
（水辺周囲の全てのマスの地形をイベントとして配置してマップ上イベント下に表示という手もあるかもしれませんが、それをコモン利用者全員に強制するのは無理がありそうです。導入に手間がかかりすぎるし、ぼくも利用希望者全員に理解してもらえるよう説明できる自信はありません。）
地底に表示はしたいのですが、がけ部分がないと足を消している意味がありません。
だからがけは表示したいです。
とすると、がけ部分だけ表示し、水面部分だけ透過処理したオートタイルマップチップが必要です。
それを作ればいいのですが、ウディタ同梱素材でマップを作る場合、水辺のがけと言えばタイルセットの一番上、右から４番目を使うことが多いかと思います。そこでその水部分を透過すればいいのですが、あのチップは周囲が透過されていて、下地の草地や砂地の上に水を配するようになっています。本来レイヤー２以上で使うものなんですね。レイヤー１で使うと岸部分が黒くなってしまいます。
だから水面を透過した差し替え用素材を用意するなら、岸部分に使用を想定される黄緑や肌色を配さないといけないです。
それがぼくにはなかなか難しい。
ドット素材を本格的に作ったことがないので、黄緑や肌色の大地と連結させて不自然じゃない水辺を作るにはそうとうな労力が必要です。
その上そうして作ったとしても汎用性を持たせられない。
「水面に映る像を使いたければ地面の色は黄緑か肌色限定でお願いします」となってしまう。
しかも更にその導入はオートタイルの差し替えや設定が必要で、初心者が気軽にできるものではないかもしれない。
そこまで思うと同梱素材の改変で水面像を表示させるのは大変だと思いました。
がけ素材としてそのまま使えそうな同梱マップチップを探しましたが・・・。
木製のドア枠の上部なんてちょうどいいんですけどね。
ドア枠をがけに見立てた
でもこれをがけとして見るとがけの中ほどに水面ラインがあるので、ライン以下は映らないとおかしいですね。つまりマップチップより上・・・。これを採用するなら地底という手は使えないようです。
前にも書きましたがこの技術は生首とか、ホラーの演出にも使えそうですけどね。まあ趣味じゃないので作る予定はしていません。
関係ないけど、ピクチャの部分表示コモンなんて需要はあるのかな？
パターンを考えないといけない歩行グラフィックと違って、ただの一枚素材のグラフィックを部分表示することはとても簡単です。
でもウディタじゃ手軽にはできないから作ったら使ってもらえるかもしれない！
何より汎用性があるのがいいですね。
どんな状況で使うのか想像はつきませんが。ちょっと考えてみよう・・・。
まあそんなこんな試行錯誤をしているという、近況報告でした。
2014年08月01日
謝辞 ～らすと あとりえ～
らすと あとりえは共同制作ゲームで、サークル名義の作品です。
共同制作メンバーに非常に感謝しているのももちろんですが、ここでは一方的に素材をお借りした外部の方へのお礼を書かせてもらいます。
ＢＧＭ：真島こころ様
ふりーむ！素材ライブラリーでピアノ曲を多数公開されている方です。ゲーム内のほとんどの部分でこの方の曲を使わせてもらいました。
繊細なピアノの音に心が和みます。ホームページでは色使いの印象的なイラストも公開されています。
ＢＧＭ：Ｎｉｓｈｉｏ様
ゲーム用のＭＩＤＩ曲を公開されている方です。このブログの一番古い記事に僕と比べれば月とすっぽんですと書いたのはこの方のことです。
前作に続き今回もこの方の曲を多く使用させてもらいました。
ＢＧＭ：Blue Piano Man様
エンディングにこの方の温かい曲を使わせていただきました。制作仲間にエンドロール作成を頼んだところ、即座に「音楽はこれを使います」といわれました。
やさしいメロディーがゲームの余韻に浸らせてくれます。
ジングル：あまなつ様
この方はぼくと同じくウディタをなさる方で、先日自作ゲームを公開されました。
ゲーム内の様々な挙動に挑戦され、それを発信し続けている姿にいつも励まされてきました。音楽も作られるとは知らなかったのですがこの度ジングル集を公開されたので早速使わせてもらいました。
コモン：悪魔の壁様
ウディタの公式コモン集にいくつものコモンを投稿なさっている方です。この方の万能用語辞典はとても便利なので前作でも使わせてもらいました。
掲載ページのコメント欄に要望が出ているようなので、勝手ながらいずれ改造して公開させてもらいたいと思っています。
コモン：つつじ椿様
同じく公式コモン集に、レベルの高い多くのコモンを投稿されています。らすと あとりえを起動中にウインドウの外を触った時、画面が青くなるのはこの方のおかげです。ちょっとした遊び心が素敵です。
コモン：はつや様
らすと あとりえをプレイされたらわかりますが、ゲーム内の最も大事な場面でミニゲームがあります。それはこのはつや様が作ったものをほぼそのまま使わせてもらっています。
とても面白いのですが、このコモンはウディタの前バージョン向けの仕様なので最新バージョンで起動するように改造して公開したいと思っています。
皆さま、本当にありがとうございました。
共同制作メンバーに非常に感謝しているのももちろんですが、ここでは一方的に素材をお借りした外部の方へのお礼を書かせてもらいます。
ＢＧＭ：真島こころ様
ふりーむ！素材ライブラリーでピアノ曲を多数公開されている方です。ゲーム内のほとんどの部分でこの方の曲を使わせてもらいました。
繊細なピアノの音に心が和みます。ホームページでは色使いの印象的なイラストも公開されています。
ＢＧＭ：Ｎｉｓｈｉｏ様
ゲーム用のＭＩＤＩ曲を公開されている方です。このブログの一番古い記事に僕と比べれば月とすっぽんですと書いたのはこの方のことです。
前作に続き今回もこの方の曲を多く使用させてもらいました。
ＢＧＭ：Blue Piano Man様
エンディングにこの方の温かい曲を使わせていただきました。制作仲間にエンドロール作成を頼んだところ、即座に「音楽はこれを使います」といわれました。
やさしいメロディーがゲームの余韻に浸らせてくれます。
ジングル：あまなつ様
この方はぼくと同じくウディタをなさる方で、先日自作ゲームを公開されました。
ゲーム内の様々な挙動に挑戦され、それを発信し続けている姿にいつも励まされてきました。音楽も作られるとは知らなかったのですがこの度ジングル集を公開されたので早速使わせてもらいました。
コモン：悪魔の壁様
ウディタの公式コモン集にいくつものコモンを投稿なさっている方です。この方の万能用語辞典はとても便利なので前作でも使わせてもらいました。
掲載ページのコメント欄に要望が出ているようなので、勝手ながらいずれ改造して公開させてもらいたいと思っています。
コモン：つつじ椿様
同じく公式コモン集に、レベルの高い多くのコモンを投稿されています。らすと あとりえを起動中にウインドウの外を触った時、画面が青くなるのはこの方のおかげです。ちょっとした遊び心が素敵です。
コモン：はつや様
らすと あとりえをプレイされたらわかりますが、ゲーム内の最も大事な場面でミニゲームがあります。それはこのはつや様が作ったものをほぼそのまま使わせてもらっています。
とても面白いのですが、このコモンはウディタの前バージョン向けの仕様なので最新バージョンで起動するように改造して公開したいと思っています。
皆さま、本当にありがとうございました。
新作公開！ らすと あとりえ
この度、結構中心になって作らせてもらったゲームらすと あとりえが公開されました。
多くの方の助けなしにはここまで来れず感謝でいっぱいです。ありがとうございます。
ダウンロードはこちらから
タイトル画面
本作は、錬金アドベンチャーというジャンルでして。
主人公は近所のお姉さんの病気を治そうと、エリクサーを作るためにかけずり回ります。
錬金術のレシピを手に入れて、素材を採集して、錬金術でアイテムを合成する、そんなゲームです。
志を果たせなかった主人公
そしてまさかの、ウディコン出品（予定）！
ミニゲームもあるのでよかったらどうぞ！
このゲームについては今後いろいろ語るかもしれません。
とりあえず今日の所はお知らせまで。
多くの方の助けなしにはここまで来れず感謝でいっぱいです。ありがとうございます。
ダウンロードはこちらから
タイトル画面
本作は、錬金アドベンチャーというジャンルでして。
主人公は近所のお姉さんの病気を治そうと、エリクサーを作るためにかけずり回ります。
錬金術のレシピを手に入れて、素材を採集して、錬金術でアイテムを合成する、そんなゲームです。
志を果たせなかった主人公
そしてまさかの、ウディコン出品（予定）！
ミニゲームもあるのでよかったらどうぞ！
このゲームについては今後いろいろ語るかもしれません。
とりあえず今日の所はお知らせまで。
ラベル：らすと あとりえ
2014年07月02日
＜ウディタ＞ 攻撃した後寝てしまう味方 を作る
自分が攻撃をした後に寝てしまう味方を設定する方法です。
以前２ちゃんねる上でどうしたらそれが可能かという話がありました。
そこで当時考えたものです。
その記録も今では普通には見れなくなったようなので、ここに記録しておきます。
ウディタ２、基本システム使用、寝るキャラ名は「ウルファール」
①コモン２０３ ○[変更可]戦闘開始時処理に以下を書き込みます。
（戦闘開始時に、敵全員に状態異常２３番を１００ターンかけます）
■DB読み込み（可変）：Cself0＝可変DB[タイプ１３のデータ数]
■変数操作：Cself1=Cself0-10
■回数つきループ[Cself1]回
|■変数操作Cself2＝Cself3+10
|■可変DB書込：DB[13:Cself2:23]()=100
|■変数操作Cself3+=1+0
ループここまで
■
②UDBタイプ７：属性名の～ データ６の属性名を「眠り返し」にします。
③UDBタイプ０：技能 データ４の項目[0]を「寝させる」にします。
ページ２の項目[22]付加するステータス状態を[1]眠りにし、その下の付与率％を１００にします。
④UDBタイプ０：技能 データ０通常攻撃をデータ１に上書きコピペし、データ名を「寝る前攻撃」にします。項目[17]付与属性を[6]眠り返しにします。
⑤UDBタイプ８：状態設定 データ23の項目[0]状態名を空白にしたまま、
ページ３の[40]カウンター有？を[4]寝させるに、その下(この属性を～)を[6]眠り返しにします。項目[43]（カウンター発動文）に「ウルファールは寝た」と書きます。
⑥UDBタイプ６：戦闘コマンド データ０通常攻撃をデータ８に上書きコピペし、コマンド名はそのままで項目[2]（選択時の効果）を[1]寝る前攻撃にします。
⑦可変DBタイプ２：主人公行動AI データ１２ウルファールの項目[2]を[1]寝る前攻撃にします。
⑧可変DBタイプ０：主人公ステータス データ１２ウルファールの３ページ項目[47]を[8]通常攻撃にします。
これは何をしているのかというと・・・。
敵は全て戦闘開始時に「（空白）」という状態異常にします。
ウルファールの攻撃には「眠り返し」属性をつけます。
「（空白）」にかかっている時は「眠り返し」属性の攻撃を受けた時「寝させる」を１００％ カウンターさせるよう設定しています。
攻撃をミスしたら寝ません。
そういうことです。
これで攻撃後に寝てしまうキャラが実現できると思います。
以前２ちゃんねる上でどうしたらそれが可能かという話がありました。
そこで当時考えたものです。
その記録も今では普通には見れなくなったようなので、ここに記録しておきます。
ウディタ２、基本システム使用、寝るキャラ名は「ウルファール」
①コモン２０３ ○[変更可]戦闘開始時処理に以下を書き込みます。
（戦闘開始時に、敵全員に状態異常２３番を１００ターンかけます）
■DB読み込み（可変）：Cself0＝可変DB[タイプ１３のデータ数]
■変数操作：Cself1=Cself0-10
■回数つきループ[Cself1]回
|■変数操作Cself2＝Cself3+10
|■可変DB書込：DB[13:Cself2:23]()=100
|■変数操作Cself3+=1+0
ループここまで
■
②UDBタイプ７：属性名の～ データ６の属性名を「眠り返し」にします。
③UDBタイプ０：技能 データ４の項目[0]を「寝させる」にします。
ページ２の項目[22]付加するステータス状態を[1]眠りにし、その下の付与率％を１００にします。
④UDBタイプ０：技能 データ０通常攻撃をデータ１に上書きコピペし、データ名を「寝る前攻撃」にします。項目[17]付与属性を[6]眠り返しにします。
⑤UDBタイプ８：状態設定 データ23の項目[0]状態名を空白にしたまま、
ページ３の[40]カウンター有？を[4]寝させるに、その下(この属性を～)を[6]眠り返しにします。項目[43]（カウンター発動文）に「ウルファールは寝た」と書きます。
⑥UDBタイプ６：戦闘コマンド データ０通常攻撃をデータ８に上書きコピペし、コマンド名はそのままで項目[2]（選択時の効果）を[1]寝る前攻撃にします。
⑦可変DBタイプ２：主人公行動AI データ１２ウルファールの項目[2]を[1]寝る前攻撃にします。
⑧可変DBタイプ０：主人公ステータス データ１２ウルファールの３ページ項目[47]を[8]通常攻撃にします。
これは何をしているのかというと・・・。
敵は全て戦闘開始時に「（空白）」という状態異常にします。
ウルファールの攻撃には「眠り返し」属性をつけます。
「（空白）」にかかっている時は「眠り返し」属性の攻撃を受けた時「寝させる」を１００％ カウンターさせるよう設定しています。
攻撃をミスしたら寝ません。
そういうことです。
これで攻撃後に寝てしまうキャラが実現できると思います。
ラベル：ウディタ
2014年06月21日
フルーツシーカー 公開！
このたびぼくの関わらせていただいたフリーゲームが公開されました。
↓紹介ページ
http://www5170uo.sakura.ne.jp/works/project03/
フルーツシーカーといいまして、ジャンルは「ほのぼの探索ＲＰＧ」です。
ゲームに使われている素材のほとんどは、このゲームのためだけに作られたものです。
グラフィックがきれいでかわいいです。
マップチップなんか、このゲームの雰囲気に合うように心をこめて一つ一つ作られています。
ぼくは音楽を担当させていただきました。
ゲームタイトルも、サンプル曲のタイトルとして送ったものから採用してもらいました。
こんなにすごい作品に関わることができて光栄に思っています。
ふりーむからダウンロードできます。遊ぶにはツクールＶＸのＲＴＰが必要です。
↓紹介ページ
http://www5170uo.sakura.ne.jp/works/project03/
フルーツシーカーといいまして、ジャンルは「ほのぼの探索ＲＰＧ」です。
ゲームに使われている素材のほとんどは、このゲームのためだけに作られたものです。
グラフィックがきれいでかわいいです。
マップチップなんか、このゲームの雰囲気に合うように心をこめて一つ一つ作られています。
ぼくは音楽を担当させていただきました。
ゲームタイトルも、サンプル曲のタイトルとして送ったものから採用してもらいました。
こんなにすごい作品に関わることができて光栄に思っています。
ふりーむからダウンロードできます。遊ぶにはツクールＶＸのＲＴＰが必要です。
ラベル：フルーツシーカー
2014年06月12日
フラグ 分岐 自由度 コンプリート
ゲームを作っています。
マップ上を歩いて人と会話して、フラグが立ったら次のイベントが開放せれる。そういうのを、性懲りもなく作っています。そういうのは前回の自作ゲームで終りにしようと思っていたのに、これまたどうしたことか・・・。
アイテムを全部そろえて、キャラステータスを最高になるまで育て上げて、全てのイベントを体験する・・・そんなプレイスタイルのことを何と言うんでしたっけ？忘れました。
そういうプレイを可能にしようと思えば、自由度は低くなりますよね。全てのアイテムは、手を伸ばせば届く所にあって、二者択一を迫られることはなく、タイミングによる分岐もない・・・。その方がいいのかなあ。
どういうプレイヤーを想定するかにもよるんでしょうね。
プレイヤーが何度もやり込んでくれるのだとすれば、一回目で気付けなかったイベントに２回目で気付けて、何度もやりがいがある、とかがいいのかもしれません（周回制にはしないので～周目とは言いません）。
まあ自分ごときのゲームをそうそうやり込んでくれる人は少ないだろうという現実を見れば、ひと通りさらっとプレイしてみて「こんなもんか」と、とりこぼしたイベントがある可能性を気にかけることもない、そんなプレイヤーが大半だと思ってよさそうです。
それだとしたら、それなら全てのイベントは出し惜しみしないで、適当に進めてもだいたい出現するようにしてもよさそうなのですが、それだと一本道感が出てくるのが悩ましいですね。
プレイヤーには自分の気持ちのおもむくまま好き放題にプレイしているように感じさせ、それでいて作者の意図通り、ラストに向けて避けて通れないイベントは外さず体験してもらう、それでも強制された感はない・・・。
そんなのがいいんですが、どうすればいいんでしょうか。
そういえば、こんな手品があります。
「１～３の数字を選んで下さい」と言い、選んでもらったら「あなたがそれを選ぶことはわかっていました」と言う。
１ならマッチ箱に入った一本のマッチを見せる。。
２ならマッチ箱の中に書かれていた２という数字を見せる。
３ならマッチ箱の底に書かれていた３という数字を見せる。
「ほ～らね」と。
ゲームの演出でもそういうことが上手くできればいいのですが。「好きな方を選んで下さい。あなたが選ばなかった方は、２度と見れませんが、でも人生もそんなもんだし、選ぶしかないのです。さあ、選んで！」というずぶとさも欲しいです。
でも選ばなかった選択肢って、もし選んでいたらどうなっていたか気になるから、直前にセーブでもしていようもんならやり直してみますよね。そしてそれは「そんなめんどくさいことさせるなよ」という気持ちにつながると思う。
それならいっそ、分岐は分岐と気付かせず、知らないうちに限定ルートに足を踏み入れさせるのが親切かとも思います。
けれどもそうすると、多くの分岐パターンを用意したにもかかわらず、「なんだ、一本道か」と思わせてしまい、その割にはラストに至るまでの情報提示などが十分でない場合も多くなるので、「説明不足でわかりにくいな」とか思われるリスクも高まってしまいます。
どうすればいいんだー、という堂々巡りは今後も当分続きそうです。
マップ上を歩いて人と会話して、フラグが立ったら次のイベントが開放せれる。そういうのを、性懲りもなく作っています。そういうのは前回の自作ゲームで終りにしようと思っていたのに、これまたどうしたことか・・・。
アイテムを全部そろえて、キャラステータスを最高になるまで育て上げて、全てのイベントを体験する・・・そんなプレイスタイルのことを何と言うんでしたっけ？忘れました。
そういうプレイを可能にしようと思えば、自由度は低くなりますよね。全てのアイテムは、手を伸ばせば届く所にあって、二者択一を迫られることはなく、タイミングによる分岐もない・・・。その方がいいのかなあ。
どういうプレイヤーを想定するかにもよるんでしょうね。
プレイヤーが何度もやり込んでくれるのだとすれば、一回目で気付けなかったイベントに２回目で気付けて、何度もやりがいがある、とかがいいのかもしれません（周回制にはしないので～周目とは言いません）。
まあ自分ごときのゲームをそうそうやり込んでくれる人は少ないだろうという現実を見れば、ひと通りさらっとプレイしてみて「こんなもんか」と、とりこぼしたイベントがある可能性を気にかけることもない、そんなプレイヤーが大半だと思ってよさそうです。
それだとしたら、それなら全てのイベントは出し惜しみしないで、適当に進めてもだいたい出現するようにしてもよさそうなのですが、それだと一本道感が出てくるのが悩ましいですね。
プレイヤーには自分の気持ちのおもむくまま好き放題にプレイしているように感じさせ、それでいて作者の意図通り、ラストに向けて避けて通れないイベントは外さず体験してもらう、それでも強制された感はない・・・。
そんなのがいいんですが、どうすればいいんでしょうか。
そういえば、こんな手品があります。
「１～３の数字を選んで下さい」と言い、選んでもらったら「あなたがそれを選ぶことはわかっていました」と言う。
１ならマッチ箱に入った一本のマッチを見せる。。
２ならマッチ箱の中に書かれていた２という数字を見せる。
３ならマッチ箱の底に書かれていた３という数字を見せる。
「ほ～らね」と。
ゲームの演出でもそういうことが上手くできればいいのですが。「好きな方を選んで下さい。あなたが選ばなかった方は、２度と見れませんが、でも人生もそんなもんだし、選ぶしかないのです。さあ、選んで！」というずぶとさも欲しいです。
でも選ばなかった選択肢って、もし選んでいたらどうなっていたか気になるから、直前にセーブでもしていようもんならやり直してみますよね。そしてそれは「そんなめんどくさいことさせるなよ」という気持ちにつながると思う。
それならいっそ、分岐は分岐と気付かせず、知らないうちに限定ルートに足を踏み入れさせるのが親切かとも思います。
けれどもそうすると、多くの分岐パターンを用意したにもかかわらず、「なんだ、一本道か」と思わせてしまい、その割にはラストに至るまでの情報提示などが十分でない場合も多くなるので、「説明不足でわかりにくいな」とか思われるリスクも高まってしまいます。
どうすればいいんだー、という堂々巡りは今後も当分続きそうです。
2014年03月23日
緊急！ ウディタ素材 鏡③
緊急事態です！
なんと、満を持して公開したはずの鏡コモンに信じられない不具合がありました。
あろうことか、鏡なのに映る像が左右反転しているのです！！！
気付いた人はいただろうか？
ウルファールの帽子の羽がぼくに教えてくれました。
まさかあの羽に助けられるとは。
鏡としては許されざる過ちだと思います。左右反転だなんて。
とりいそぎ、公式コモン集での公開を取り下げました。
たかが一マスサイズのグラフィック表示と油断していたかもしれません。
うーん、鏡、奥が深すぎる。
鏡について考えようとするなら、位相幾何学だか何だか、難しい学問をしないといけないのだろうか。
ちなみに、連続鏡面壁の原理は完成しました（左右反転だけど）。
後は汎用性を高めるだけだと思っていた矢先だったのに！
今後は鏡開発はいったん中断し、というか鏡開発の一環として、反転画像作製技術開発に取りかかります。
手間とPC処理能力は食うにしても、原理的にはできると思っています。
ご迷惑をおかけした方、いらっしゃったら大変申し訳ありませんでした。
それにしても、このおっちょこちょいは直さないといけませんね。
なんと、満を持して公開したはずの鏡コモンに信じられない不具合がありました。
あろうことか、鏡なのに映る像が左右反転しているのです！！！
気付いた人はいただろうか？
ウルファールの帽子の羽がぼくに教えてくれました。
まさかあの羽に助けられるとは。
鏡としては許されざる過ちだと思います。左右反転だなんて。
とりいそぎ、公式コモン集での公開を取り下げました。
たかが一マスサイズのグラフィック表示と油断していたかもしれません。
うーん、鏡、奥が深すぎる。
鏡について考えようとするなら、位相幾何学だか何だか、難しい学問をしないといけないのだろうか。
ちなみに、連続鏡面壁の原理は完成しました（左右反転だけど）。
後は汎用性を高めるだけだと思っていた矢先だったのに！
今後は鏡開発はいったん中断し、というか鏡開発の一環として、反転画像作製技術開発に取りかかります。
手間とPC処理能力は食うにしても、原理的にはできると思っています。
ご迷惑をおかけした方、いらっしゃったら大変申し訳ありませんでした。
それにしても、このおっちょこちょいは直さないといけませんね。
ウディタ素材 鏡②
先日はウディタ上で鏡を実現する方法について書きなぐりました。
「キャラの座標をピクセル単位で取得する方法がわからない」とか「コモンだと呼び出し元の座標を求めるのが面倒」とか書きましたが、それらの問題はあっという間に解決しました。
たいていのことが出来てしまうウディタはすごいです。
数日がたち鏡が一応形になったので、ウディタ公式ページのコモンイベント集に投稿しました。
（追記、公開を取り下げました。詳細は次の日のページをごらんください。）
興味のある方は「鏡コモン」で検索して下さい。
今日はそのコモンについてです。
用途が限定される部分が多いので、それを誰かが自分のゲームに合うよう改造しようとした時に、参考になる内容をここにに書きます。配布サイトでの説明や同梱説明書と重複する部分もありますが、ご了承ください。
原理としては、
「主人公と並列マップイベントが重なった時だけ、上のマスに鏡に映った画像を表示する」
そんなコモンです。
マップイベントが並列起動という所は特徴的かもしれません。
普通主人公の位置によってイベントを起動するには「プレイヤー接触」を使うことが多いかもしれませんが、今回は鏡の前から離れた事も判定しないといけないので、マップ内では常時監視が出来る並列起動を使いました。並列起動ならどこにあっても条件が合えば動いているのだから置く場所などどこでもいいようなものですが、コモンの導入を簡単にするために、鏡の下のマスの座標を指定するという役割もその並列イベントに持たせた結果、鏡の前に置くことになりました。
座標の重なりはピクセル単位で監視しています。だから半歩ずれていても映りません。正面に立ち止まった時だけ映ります。鏡の前を横切った時は映る時と映らない時があります。
半歩ずれて映らないことが不自然にならないように、中央を透過した鏡の枠素材を用意しました。鏡の枠はマップでなくイベントとして置く仕様です。
これはピクチャの表示順の都合で、鏡に映る像（以下、鏡像）を枠よりも下に表示させるための工夫です。
ちなみに枠はウディタにデフォルトで入っているタイルセットに追加しました。
イベントとして使うなら単独のキャラグラフィックでよかった気もしますが、はじめ枠をイベントとして使うことを想定していなかった時点で作りました。そして迷いましたがそのまま公開しました。
というのは、鏡は縦に二マス分のサイズがあるのですが、その上のマスは通常の使用ではマップタイルで十分だからです。どういうことかというと通常は鏡像は一つ上のマスにほぼ収まるので、枠が必要なのは鏡の下半分です。タイルに組み込んであれば鏡の上下の位置関係が一目でわかるし、マップとして使うかイベントとして使うかの選択の幅も広がるかと思ってタイルに入れたままを選んだのです。
鏡像にどのピクチャを使うか、正確には指定ピクチャの一部分をどのパターン番号で呼び出すか、その求め方がこのコモンの一番独創的な部分かと思います。
詳細は前回書いたつもりだったのですが、でもよく読むと全然説明していないので、ここにあらためて書きます。
「キャラの向き」×１０＋「アニメーション番号」＋「鏡像変換定数」＝「使いたいパターン番号」
となるような、「鏡像変換定数」という数値を求めました。これはキャラの向きに応じて８通りあります。
（なおこれは３パターン８方向の歩行グラフィック専用の数値なので、別規格で同じことをしたい方は、この乱文を解読して自作して下さい。まあメールで頼まれたら考えるかもしれません、が。）
上の式は左辺にも右辺にも同じアニメーション番号の数値を足しているので、
「キャラの向き」＋「鏡像変換定数ダッシュ」＝「使いたい３つのうちの左のパターン番号」
とかいうまた別の鏡像変換定数を出すこともできたかもしれませんが、けっきょくそれにまたアニメーション番号を足してパターン番号を求めないといけないのでややこしいことには変わりないので、一つの式にまとまるようにしました。
ちなみにこのコモンは、アニメーションの配置パターンがそろっているという前提で作っています。
３パターンアニメーションの場合、キャラ表示はキャラがある向きを向いていてそして３つのわずかに変化する画像を切り替え表示し続ければ問題はないので、配置順がどうあろうと構わないのです。仮に上中下という３つなら、上中下でも中下上でも（初期画像は違っても）同じなのです。けれどこのコモンでは上中下と中上下の混在は困ります。
主人公のアニメーションに同期した別向きの鏡像を映す仕様なので、主人公が上、鏡像が下ということになっては問題なのです。
まあ正直なところ、ぼくは３パターンがどう違うか見分けるような細かい神経を持ち合わせておらず、配布サイトにスクリーンショットを撮ったウルファールの歩行グラフィックについてもパターンが対応しているのかどうかも実は確認していません。（そもそもコモンの動作テストをしたウディタサンプルゲームでは主人公は歩かない時アニメーションしないので、鏡の前で立ち止まっても動かない）
そこで、もしも鏡に映った像とその前に立つキャラとがあまりに違う動きをしていて困るという場合は、鏡像変換定数周りをその変則的な歩行グラフィックに対応させる大改造が必要かもしれません。そんな方がいれば大変でしょうが応援します。
このコモンではとにかく使用者の導入の手間を軽減することを目指しました。コモンの自作はおろかマップイベントもテキスト表示しかできない、条件分岐もマップイベントの起動条件に頼り切っていた昨年夏の自分でも使えるようにしました。
そのためにコモンの引数指定を最大限に使いました。もっとも昨年のぼくはコモンの引数指定なんてできませんでしたが。・・・そうですね、その説明もするべきですね。
ここをごらんの初心者の方に説明します。（ここまで訳のわからないことを羅列したあとにどれだけの初心者がを読んでいるかわかりませんが。）引数指定というのは、コモンを呼び出す時にコモンに引き渡す情報のことです。コモン呼び出しを指定する画面でコモン名を見ただけでOKしてしまわず、[コモンEv入力（数値）]の下などでどんな設定ができるか気をつけてみてみて下さいね。
ぼくの鏡のコモンでは①鏡の通し番号、②鏡像の高さの補正、③鏡像の透明度、④鏡の下地になる画像をコモンに描かせるか、の、その４点を引数で指定できます。全てプルダウンリストで選択するだけで済むので簡単です。
その一方でこのコモンを改造しようとしている人には、これらの初心者への配慮がかえってコモンを理解しにくく、使いにくくしているだろうことは申し訳ないです。あらゆることが出来るウディタだから好きな設定が出来るのに、初心者の利便ために自由度が制限され、それを取っ払うために面白くもない他人の作った仕様を理解しないといけないというのは納得いかない部分もあると思います。そんなことするくらいなら全部自作した方がよほど早いと思うかもしれません。それでもぼくは今回はこのコモンは初心者でも簡単に導入できるということを目指したので、そのために不便を強いられる改造しようとする人にお詫びの気持ちを込めてここにできるだけヒントとなることを書いておこうと思っています。
引数①の通し番号というのは鏡の識別番号です。同じ番号のコモンから呼び出された鏡像および鏡の下地画像（後述）は同じピクチャ番号で表示されます。そのため複数の鏡を配置した時に、あるマップイベントに座標が一致しないために別のマップイベント上に立っていても鏡像が映らない現象が起きます。それを防ぐために鏡を複数置く場合は①を変えて下さい。言いかえれば鏡のチャンネルのようなものです。ちなみに上限は１５枚ですが、ちょっとした改造で画面いっぱいに置くことも可能になると思うので、やってみたいけれどわからない方はメールで質問して下さい。
②③はそのままなので説明はいらないと思います。いろいろ試してみて下さい。ただ、鏡の枠をイベントにするのは普通下半分だけでいいと上の方に書きましたが、②で高くする場合は枠を上下ともイベントにして鏡像より上層に描かれるようにして下さい。
④の鏡の下地になる画像、これも導入の手間を減らす工夫です。鏡の下地、つまり枠の中・鏡像のバックは、灰色っぽければいいだろうからマップをタイルセットの机？の中央部分などにしてもらえばいいのだけれど、導入方法を説明する文章に「鏡の位置のマップの色は～」と書きながら、わざわざやってもらうくらいならこっちで用意してしまおうと思いたち、＜SQUARE＞というピクチャを使って描いてしまいました。このピクチャ番号は鏡像の１６倍にしていますが、それが１５以下だと鏡像と番号が重複して不具合が起こりうるからです。
水面に姿が映る等の時には④は非表示に設定して下さい。
最後にこのコモンの今後のバージョンアップなどの見通しなどについて考えてみたいと思います。
まず、画面サイズが３２０×２４０限定というのはこのコモンの汎用性を損なう大きな問題だと思っています。
できれば改善したいし、これはおそらくぼくの技術で可能なような気はしています。ただ需要があるかわからないので、もしも別サイズを希望するコメントなどがいくつかもらえたら考えようかと思っています。
ゲーム画面に映るパーティー画像がそのまま映らないのも大問題です。
現状では可変DBの「パーティーメンバー１」の画像しか映せず、複数パーティーやイベントがうろつくマップでは使えないという致命的欠点があります。
しかし「パーティー画像」設定ではパーティーメンバーリストにないキャラ画像も隊列に入れることが出来、その情報を保持している場所も見当がつかないのでこれが改善できる見通しは立ちません。
一番実現したいのは、連続鏡面壁の実現です。これはできそうな気もします。そもそもぼくは前回書いた文章でばれてしまったようについ最近までキャラクターの座標をピクセル単位で取得できるということを知らなかったので、そのあたりについてはこれから考えてみます。それが実現すれば、一番最初に目指した鏡面床ももうすぐそこです。
この企画はまだ続く！
追記
このコモン導入時の注意事項を書いておきます。
ぼく自身何度も「あれ？」とつまずいている部分なので・・・。
●●●●●鏡コモン導入時の注意点●●●●●●
・コモンを呼び出すマップイベントは並列起動！！！
・すり抜けの設定にはチェックを入れておく！！！
・鏡の枠はイベントとして設置！！！
「キャラの座標をピクセル単位で取得する方法がわからない」とか「コモンだと呼び出し元の座標を求めるのが面倒」とか書きましたが、それらの問題はあっという間に解決しました。
たいていのことが出来てしまうウディタはすごいです。
数日がたち鏡が一応形になったので、ウディタ公式ページのコモンイベント集に投稿しました。
（追記、公開を取り下げました。詳細は次の日のページをごらんください。）
今日はそのコモンについてです。
用途が限定される部分が多いので、それを誰かが自分のゲームに合うよう改造しようとした時に、参考になる内容をここにに書きます。配布サイトでの説明や同梱説明書と重複する部分もありますが、ご了承ください。
原理としては、
「主人公と並列マップイベントが重なった時だけ、上のマスに鏡に映った画像を表示する」
そんなコモンです。
マップイベントが並列起動という所は特徴的かもしれません。
普通主人公の位置によってイベントを起動するには「プレイヤー接触」を使うことが多いかもしれませんが、今回は鏡の前から離れた事も判定しないといけないので、マップ内では常時監視が出来る並列起動を使いました。並列起動ならどこにあっても条件が合えば動いているのだから置く場所などどこでもいいようなものですが、コモンの導入を簡単にするために、鏡の下のマスの座標を指定するという役割もその並列イベントに持たせた結果、鏡の前に置くことになりました。
座標の重なりはピクセル単位で監視しています。だから半歩ずれていても映りません。正面に立ち止まった時だけ映ります。鏡の前を横切った時は映る時と映らない時があります。
半歩ずれて映らないことが不自然にならないように、中央を透過した鏡の枠素材を用意しました。鏡の枠はマップでなくイベントとして置く仕様です。
これはピクチャの表示順の都合で、鏡に映る像（以下、鏡像）を枠よりも下に表示させるための工夫です。
ちなみに枠はウディタにデフォルトで入っているタイルセットに追加しました。
イベントとして使うなら単独のキャラグラフィックでよかった気もしますが、はじめ枠をイベントとして使うことを想定していなかった時点で作りました。そして迷いましたがそのまま公開しました。
というのは、鏡は縦に二マス分のサイズがあるのですが、その上のマスは通常の使用ではマップタイルで十分だからです。どういうことかというと通常は鏡像は一つ上のマスにほぼ収まるので、枠が必要なのは鏡の下半分です。タイルに組み込んであれば鏡の上下の位置関係が一目でわかるし、マップとして使うかイベントとして使うかの選択の幅も広がるかと思ってタイルに入れたままを選んだのです。
鏡像にどのピクチャを使うか、正確には指定ピクチャの一部分をどのパターン番号で呼び出すか、その求め方がこのコモンの一番独創的な部分かと思います。
詳細は前回書いたつもりだったのですが、でもよく読むと全然説明していないので、ここにあらためて書きます。
「キャラの向き」×１０＋「アニメーション番号」＋「鏡像変換定数」＝「使いたいパターン番号」
となるような、「鏡像変換定数」という数値を求めました。これはキャラの向きに応じて８通りあります。
（なおこれは３パターン８方向の歩行グラフィック専用の数値なので、別規格で同じことをしたい方は、この乱文を解読して自作して下さい。まあメールで頼まれたら考えるかもしれません、が。）
上の式は左辺にも右辺にも同じアニメーション番号の数値を足しているので、
「キャラの向き」＋「鏡像変換定数ダッシュ」＝「使いたい３つのうちの左のパターン番号」
とかいうまた別の鏡像変換定数を出すこともできたかもしれませんが、けっきょくそれにまたアニメーション番号を足してパターン番号を求めないといけないのでややこしいことには変わりないので、一つの式にまとまるようにしました。
ちなみにこのコモンは、アニメーションの配置パターンがそろっているという前提で作っています。
３パターンアニメーションの場合、キャラ表示はキャラがある向きを向いていてそして３つのわずかに変化する画像を切り替え表示し続ければ問題はないので、配置順がどうあろうと構わないのです。仮に上中下という３つなら、上中下でも中下上でも（初期画像は違っても）同じなのです。けれどこのコモンでは上中下と中上下の混在は困ります。
主人公のアニメーションに同期した別向きの鏡像を映す仕様なので、主人公が上、鏡像が下ということになっては問題なのです。
まあ正直なところ、ぼくは３パターンがどう違うか見分けるような細かい神経を持ち合わせておらず、配布サイトにスクリーンショットを撮ったウルファールの歩行グラフィックについてもパターンが対応しているのかどうかも実は確認していません。（そもそもコモンの動作テストをしたウディタサンプルゲームでは主人公は歩かない時アニメーションしないので、鏡の前で立ち止まっても動かない）
そこで、もしも鏡に映った像とその前に立つキャラとがあまりに違う動きをしていて困るという場合は、鏡像変換定数周りをその変則的な歩行グラフィックに対応させる大改造が必要かもしれません。そんな方がいれば大変でしょうが応援します。
このコモンではとにかく使用者の導入の手間を軽減することを目指しました。コモンの自作はおろかマップイベントもテキスト表示しかできない、条件分岐もマップイベントの起動条件に頼り切っていた昨年夏の自分でも使えるようにしました。
そのためにコモンの引数指定を最大限に使いました。もっとも昨年のぼくはコモンの引数指定なんてできませんでしたが。・・・そうですね、その説明もするべきですね。
ここをごらんの初心者の方に説明します。（ここまで訳のわからないことを羅列したあとにどれだけの初心者がを読んでいるかわかりませんが。）引数指定というのは、コモンを呼び出す時にコモンに引き渡す情報のことです。コモン呼び出しを指定する画面でコモン名を見ただけでOKしてしまわず、[コモンEv入力（数値）]の下などでどんな設定ができるか気をつけてみてみて下さいね。
ぼくの鏡のコモンでは①鏡の通し番号、②鏡像の高さの補正、③鏡像の透明度、④鏡の下地になる画像をコモンに描かせるか、の、その４点を引数で指定できます。全てプルダウンリストで選択するだけで済むので簡単です。
その一方でこのコモンを改造しようとしている人には、これらの初心者への配慮がかえってコモンを理解しにくく、使いにくくしているだろうことは申し訳ないです。あらゆることが出来るウディタだから好きな設定が出来るのに、初心者の利便ために自由度が制限され、それを取っ払うために面白くもない他人の作った仕様を理解しないといけないというのは納得いかない部分もあると思います。そんなことするくらいなら全部自作した方がよほど早いと思うかもしれません。それでもぼくは今回はこのコモンは初心者でも簡単に導入できるということを目指したので、そのために不便を強いられる改造しようとする人にお詫びの気持ちを込めてここにできるだけヒントとなることを書いておこうと思っています。
引数①の通し番号というのは鏡の識別番号です。同じ番号のコモンから呼び出された鏡像および鏡の下地画像（後述）は同じピクチャ番号で表示されます。そのため複数の鏡を配置した時に、あるマップイベントに座標が一致しないために別のマップイベント上に立っていても鏡像が映らない現象が起きます。それを防ぐために鏡を複数置く場合は①を変えて下さい。言いかえれば鏡のチャンネルのようなものです。ちなみに上限は１５枚ですが、ちょっとした改造で画面いっぱいに置くことも可能になると思うので、やってみたいけれどわからない方はメールで質問して下さい。
②③はそのままなので説明はいらないと思います。いろいろ試してみて下さい。ただ、鏡の枠をイベントにするのは普通下半分だけでいいと上の方に書きましたが、②で高くする場合は枠を上下ともイベントにして鏡像より上層に描かれるようにして下さい。
④の鏡の下地になる画像、これも導入の手間を減らす工夫です。鏡の下地、つまり枠の中・鏡像のバックは、灰色っぽければいいだろうからマップをタイルセットの机？の中央部分などにしてもらえばいいのだけれど、導入方法を説明する文章に「鏡の位置のマップの色は～」と書きながら、わざわざやってもらうくらいならこっちで用意してしまおうと思いたち、＜SQUARE＞というピクチャを使って描いてしまいました。このピクチャ番号は鏡像の１６倍にしていますが、それが１５以下だと鏡像と番号が重複して不具合が起こりうるからです。
水面に姿が映る等の時には④は非表示に設定して下さい。
最後にこのコモンの今後のバージョンアップなどの見通しなどについて考えてみたいと思います。
まず、画面サイズが３２０×２４０限定というのはこのコモンの汎用性を損なう大きな問題だと思っています。
できれば改善したいし、これはおそらくぼくの技術で可能なような気はしています。ただ需要があるかわからないので、もしも別サイズを希望するコメントなどがいくつかもらえたら考えようかと思っています。
ゲーム画面に映るパーティー画像がそのまま映らないのも大問題です。
現状では可変DBの「パーティーメンバー１」の画像しか映せず、複数パーティーやイベントがうろつくマップでは使えないという致命的欠点があります。
しかし「パーティー画像」設定ではパーティーメンバーリストにないキャラ画像も隊列に入れることが出来、その情報を保持している場所も見当がつかないのでこれが改善できる見通しは立ちません。
一番実現したいのは、連続鏡面壁の実現です。これはできそうな気もします。そもそもぼくは前回書いた文章でばれてしまったようについ最近までキャラクターの座標をピクセル単位で取得できるということを知らなかったので、そのあたりについてはこれから考えてみます。それが実現すれば、一番最初に目指した鏡面床ももうすぐそこです。
この企画はまだ続く！
追記
このコモン導入時の注意事項を書いておきます。
ぼく自身何度も「あれ？」とつまずいている部分なので・・・。
●●●●●鏡コモン導入時の注意点●●●●●●
・コモンを呼び出すマップイベントは並列起動！！！
・すり抜けの設定にはチェックを入れておく！！！
・鏡の枠はイベントとして設置！！！
ラベル：ウディタ
2014年03月18日
ウディタ素材 鏡①
ツクールでは鏡面床という演出をするスクリプト（？）があるそうです。
見下ろし型RPGのマップ上で、ツルツルの床にキャラクターの姿が逆さに映るのです。足元に。
これをウディタでどう実現できるか考えてみました。
並列実行のイベントを使ってキャラの座標を監視し、キャラ画像をピクチャとして取り込み反転させ表示すればいいと考えました。
けれどキャラの座標をピクセル単位で取得する方法がわかりませんでした。
なめらかな広がりを持つ床の上で、キャラがマス目中央にさしかかるたびに影がカクカクするのはおかしいです。
そこで、ぼくの今の技術力では鏡面床はいったんあきらめることにしました。
そして、「床はシームレスだから難しいんだ」と、レベルを下げて一面鏡に挑戦することにしました。
これなら鏡正面に来た時以外は姿が映らなくても不自然じゃないから、細かい座標も必要なく簡単なはず！
・・・と思ったのですが、しかしそれは間違いでした。
というのは、鏡は立てますよね、普通。
女性のスカートをのぞきたいヘンタイさんの仕掛けた罠でもない限り、床に鏡があることはないわけで。
とすると、鏡の場所はキャラクターの上のマスになります。そこで意外な問題が。
下のマスにキャラの上下反転画像を映せばいい鏡面床とは違い、キャラの上のマスに置く一面鏡の場合、そこに映る画像は複雑極まりないのです。
具体的には、後ろ姿を映さないといけない。鏡面床がキャラ画像の角度と透明度だけ変えればよかったのとは大違いで別画像を用意しないといけないのです。
けれどもそこであきらめるのは悔しかったので、キャラの情報を取得して一面鏡に映す画像を用意する方法を考えました。
汎用性を求めると技術がいくらあっても足りないので、使用状況を極限まで限定（注１）しました。するとある程度めどが立ったので、まだ途中ですがモチベーション維持のためにここに公開します。
キャラクターの向き、アニメーション番号、そして分割ピクチャのパターン番号という３つの要素をこねくりまわして、「鏡像変換定数」とでもいうべき数値を出しました。
これは「鏡の下のマスに立った主人公の向きによって、鏡にうつすべき主人公画像のパターン番号を求めるのに必要な数」です。なんだかすごいですよね。
以下にそれを説明する画像を用意しました。無茶苦茶ですが。
左上はウディタで向きを表す数、その右は３パターン８方向の歩行グラフィックの配置、その実例がその下の画像、右上のエクセル表が今日のキモで、その下はウディタのパターン番号の振り方です。
ぼくの思考経路を書いても意味がないので結果だけ書きます。
「キャラの向き」×１０＋「アニメーション番号」＋「鏡像変換定数」＝「パターン番号」
です。一番右上の表が「鏡像変換定数」です。これには方向と連動した法則性のようなものがないかと期待していたのですが、こうして書き出してみてもぼくには見出すことはできませんでした。方向というのはビット積（２進数）に関係するので、ぼくがそれを理解できればまた違ったかもしれないですが・・・。
まあ、この「鏡像変換定数」をデータベースに入れておけば、鏡に映す画像が一行で指定できそうな気がしています。
今日はここまで！
（注１：歩行グラは３パターン８方向限定、アニメパターンの並び順は対応しているという前提、パーティーメンバーは主人公一人という前提、マップイベントとしての使用限定←コモンだと呼び出し元の座標を求めるのが面倒なので）
見下ろし型RPGのマップ上で、ツルツルの床にキャラクターの姿が逆さに映るのです。足元に。
これをウディタでどう実現できるか考えてみました。
並列実行のイベントを使ってキャラの座標を監視し、キャラ画像をピクチャとして取り込み反転させ表示すればいいと考えました。
けれどキャラの座標をピクセル単位で取得する方法がわかりませんでした。
なめらかな広がりを持つ床の上で、キャラがマス目中央にさしかかるたびに影がカクカクするのはおかしいです。
そこで、ぼくの今の技術力では鏡面床はいったんあきらめることにしました。
そして、「床はシームレスだから難しいんだ」と、レベルを下げて一面鏡に挑戦することにしました。
これなら鏡正面に来た時以外は姿が映らなくても不自然じゃないから、細かい座標も必要なく簡単なはず！
・・・と思ったのですが、しかしそれは間違いでした。
というのは、鏡は立てますよね、普通。
女性のスカートをのぞきたいヘンタイさんの仕掛けた罠でもない限り、床に鏡があることはないわけで。
とすると、鏡の場所はキャラクターの上のマスになります。そこで意外な問題が。
下のマスにキャラの上下反転画像を映せばいい鏡面床とは違い、キャラの上のマスに置く一面鏡の場合、そこに映る画像は複雑極まりないのです。
具体的には、後ろ姿を映さないといけない。鏡面床がキャラ画像の角度と透明度だけ変えればよかったのとは大違いで別画像を用意しないといけないのです。
けれどもそこであきらめるのは悔しかったので、キャラの情報を取得して一面鏡に映す画像を用意する方法を考えました。
汎用性を求めると技術がいくらあっても足りないので、使用状況を極限まで限定（注１）しました。するとある程度めどが立ったので、まだ途中ですがモチベーション維持のためにここに公開します。
キャラクターの向き、アニメーション番号、そして分割ピクチャのパターン番号という３つの要素をこねくりまわして、「鏡像変換定数」とでもいうべき数値を出しました。
これは「鏡の下のマスに立った主人公の向きによって、鏡にうつすべき主人公画像のパターン番号を求めるのに必要な数」です。なんだかすごいですよね。
以下にそれを説明する画像を用意しました。無茶苦茶ですが。
左上はウディタで向きを表す数、その右は３パターン８方向の歩行グラフィックの配置、その実例がその下の画像、右上のエクセル表が今日のキモで、その下はウディタのパターン番号の振り方です。
ぼくの思考経路を書いても意味がないので結果だけ書きます。
「キャラの向き」×１０＋「アニメーション番号」＋「鏡像変換定数」＝「パターン番号」
です。一番右上の表が「鏡像変換定数」です。これには方向と連動した法則性のようなものがないかと期待していたのですが、こうして書き出してみてもぼくには見出すことはできませんでした。方向というのはビット積（２進数）に関係するので、ぼくがそれを理解できればまた違ったかもしれないですが・・・。
まあ、この「鏡像変換定数」をデータベースに入れておけば、鏡に映す画像が一行で指定できそうな気がしています。
今日はここまで！
（注１：歩行グラは３パターン８方向限定、アニメパターンの並び順は対応しているという前提、パーティーメンバーは主人公一人という前提、マップイベントとしての使用限定←コモンだと呼び出し元の座標を求めるのが面倒なので）
2014年03月15日
フリーソフト、ミノ式シーケンサーで作ったMIDIをツクール上で再生すると２周目から音質が変わる不具合の対処法
タイトル通りの内容についてです。
手軽に作曲できるミノ式シーケンサーというフリーソフトがあるのですが、それを使って作成したMIDIファイルをツクールで再生すると、２周目以降から音質が変わるという不具合が起こりました。
原因の詳細はわからず、これがミノ式のみで起こることなのかもわかりません。
ただ対処法などはわかりました。
曲の最終小節を削除し、そこに同じ譜面を打ち込むことで不具合は解消しました。（ぼくの場合）
最終小節を削除するだけでも現象はなくなるのですが、それだと曲がおかしくなるので・・・。
同じ悩みを抱える人がいれば試して下さい。
ちなみに、最終小節を後ろの方に貼りつけて最終小節を削除し、新たに張り直して後ろのコピーを消すという方法では改善されません。けれども打ちなおせば良くなるので、特定の譜面の入力状況によって引き起こされているのではないようです。
またこれには、ループポイント設定も、音色も関係ありません。
またツクール（VX）でもウディタでも、同じファイルでは同じ現象が起きます。
曲の冒頭を削除しても改善されません。
この情報に興味のある人は少ないと思いますが、このことを知りたがっている人が検索でたどり着けるように念のためここに書き残しておきます。
それにしても、このブログには最近は誰かに有用な情報を書こうと思っているのですが、情報がピンポイントすぎますね。
手軽に作曲できるミノ式シーケンサーというフリーソフトがあるのですが、それを使って作成したMIDIファイルをツクールで再生すると、２周目以降から音質が変わるという不具合が起こりました。
原因の詳細はわからず、これがミノ式のみで起こることなのかもわかりません。
ただ対処法などはわかりました。
曲の最終小節を削除し、そこに同じ譜面を打ち込むことで不具合は解消しました。（ぼくの場合）
最終小節を削除するだけでも現象はなくなるのですが、それだと曲がおかしくなるので・・・。
同じ悩みを抱える人がいれば試して下さい。
ちなみに、最終小節を後ろの方に貼りつけて最終小節を削除し、新たに張り直して後ろのコピーを消すという方法では改善されません。けれども打ちなおせば良くなるので、特定の譜面の入力状況によって引き起こされているのではないようです。
またこれには、ループポイント設定も、音色も関係ありません。
またツクール（VX）でもウディタでも、同じファイルでは同じ現象が起きます。
曲の冒頭を削除しても改善されません。
この情報に興味のある人は少ないと思いますが、このことを知りたがっている人が検索でたどり着けるように念のためここに書き残しておきます。
それにしても、このブログには最近は誰かに有用な情報を書こうと思っているのですが、情報がピンポイントすぎますね。
2014年02月27日
無料広告を試しました
自作ゲームを、無料広告ジョビューに掲載してもらいました。
多少の宣伝効果があるそうです。（ほんと？）
載せてもらうにはＨＴＭＬ形式とかいう記述をせねばならず、難しかったです。
いい勉強になりました。
ただ、今となっては、ネオ繚乱記を多くの人にプレイしてほしいという気持ちはなくなりました。
まあだからといって公開停止にするのもなにか違うと思うので、そのままにしています。
また気がむけば、報告いただいたバグの修正をしたいと思っています。
それと同時に、次のゲームを作りたいです。
プレイヤーにやさしいゲームを、作りたいと思っています。
多少の宣伝効果があるそうです。（ほんと？）
載せてもらうにはＨＴＭＬ形式とかいう記述をせねばならず、難しかったです。
いい勉強になりました。
ただ、今となっては、ネオ繚乱記を多くの人にプレイしてほしいという気持ちはなくなりました。
まあだからといって公開停止にするのもなにか違うと思うので、そのままにしています。
また気がむけば、報告いただいたバグの修正をしたいと思っています。
それと同時に、次のゲームを作りたいです。
プレイヤーにやさしいゲームを、作りたいと思っています。
2014年02月25日
ツクールＶＸゲームで音が出ない時
ゲームプレイ中にＦ１を押し、チェックボックスにチェックを入れるとよい。
たったこれだけのことがわからず、ランタイムパッケージを再インストールしたり、愛用してるＶｉｓｔａの仕様を疑ったりしつつ、一年くらい経過していました。
このチェックはおそらく一年以上前に自分で操作したのだろうけれど、その設定はどうやら、違うＶＸゲームをしようがランタイムパッケージを再インストールしようが、持ち越されるようです・・・。
同じことに困る人が、このページにたどり着きますように。
おまけのマメ知識
ＶＸのゲームの起動が遅い場合は、exeファイルを右クリックして「管理者として実行」すれば早いかもしれないらしい。やってみたら、確かに早いかもしれなかったです。
たったこれだけのことがわからず、ランタイムパッケージを再インストールしたり、愛用してるＶｉｓｔａの仕様を疑ったりしつつ、一年くらい経過していました。
このチェックはおそらく一年以上前に自分で操作したのだろうけれど、その設定はどうやら、違うＶＸゲームをしようがランタイムパッケージを再インストールしようが、持ち越されるようです・・・。
同じことに困る人が、このページにたどり着きますように。
おまけのマメ知識
ＶＸのゲームの起動が遅い場合は、exeファイルを右クリックして「管理者として実行」すれば早いかもしれないらしい。やってみたら、確かに早いかもしれなかったです。
2014年01月12日
ゲーム製作と公開にまつわる僕の新しいチャレンジ
僕は昨年までＰＣは
・ネットを見る、通販で買い物
・フリーゲームをする
・ブログ（ゲームレビュー）を書く
・仕事で少し（Ｅｘｃｅｌ、メール）
これくらいしか使っていませんでした。
今回ゲームを製作・公開するに当たっては、できるだけ色々新しいことにチャレンジしたいと思いました。
その結果
・ウディタでゲーム作り
・作曲・効果音作り
・グラフィック作り
・アニメーション作り（ブログへの貼り方が分からず公開は挫折）
・２ちゃんねる上でゲーム共同制作の呼びかけ（場違いだと指摘されましたが。でもおかげでこのブログが始まりました。ドメイン名にだけその頃の名残りがあります）
・日常使用と別のメールアカウントの新規作成
・ふりーむ！でテストプレイヤー募集
・ウディタ公式ページに初心者ゲーム登録
・アンケートサービス クエスタントの利用（回収回答数はゼロでしたが）
・ベクターへのゲーム登録
・ゲーム作りで技術的に色々教えてもらったサイトの方の「レビュー作品募集」に応募
などなど、今までにない体験をたくさんさせてもらいました。（ちなみに全部無料で）
そして今日はまた、攻略情報をＷｉｋiに書き込ませてもらい、ＦＣ２とやらの形式の記述も初めてしました。
ゲーム作りを通して世界が広がり、知識・経験が増えていくことがとても嬉しいです。
わくわくしています。
今後は、ゲームの宣伝ということに取り組んでみてもいいかなと思っています。
２ちゃんねるなどで「このゲームしてみて」と書くと「作者乙」と言われて嫌がられるので、
許された場所で、作者であるということを伏せず、どれだけ宣伝ができるのかを試してみたいです。
（ゲームの知名度を高めたいたいというよりは、多様な宣伝の可能性を体感してみたいと思っています。）
まあ、迷惑顔をされない程度に・・・。
新しい世界、新しい人、新しい自分との出会いを楽しみます。楽しみです。
今後の進展はまたここに書きます。
応援してくださっている方、ありがとうございます。
・ネットを見る、通販で買い物
・フリーゲームをする
・ブログ（ゲームレビュー）を書く
・仕事で少し（Ｅｘｃｅｌ、メール）
これくらいしか使っていませんでした。
今回ゲームを製作・公開するに当たっては、できるだけ色々新しいことにチャレンジしたいと思いました。
その結果
・ウディタでゲーム作り
・作曲・効果音作り
・グラフィック作り
・アニメーション作り（ブログへの貼り方が分からず公開は挫折）
・２ちゃんねる上でゲーム共同制作の呼びかけ（場違いだと指摘されましたが。でもおかげでこのブログが始まりました。ドメイン名にだけその頃の名残りがあります）
・日常使用と別のメールアカウントの新規作成
・ふりーむ！でテストプレイヤー募集
・ウディタ公式ページに初心者ゲーム登録
・アンケートサービス クエスタントの利用（回収回答数はゼロでしたが）
・ベクターへのゲーム登録
・ゲーム作りで技術的に色々教えてもらったサイトの方の「レビュー作品募集」に応募
などなど、今までにない体験をたくさんさせてもらいました。（ちなみに全部無料で）
そして今日はまた、攻略情報をＷｉｋiに書き込ませてもらい、ＦＣ２とやらの形式の記述も初めてしました。
ゲーム作りを通して世界が広がり、知識・経験が増えていくことがとても嬉しいです。
わくわくしています。
今後は、ゲームの宣伝ということに取り組んでみてもいいかなと思っています。
２ちゃんねるなどで「このゲームしてみて」と書くと「作者乙」と言われて嫌がられるので、
許された場所で、作者であるということを伏せず、どれだけ宣伝ができるのかを試してみたいです。
（ゲームの知名度を高めたいたいというよりは、多様な宣伝の可能性を体感してみたいと思っています。）
まあ、迷惑顔をされない程度に・・・。
新しい世界、新しい人、新しい自分との出会いを楽しみます。楽しみです。
今後の進展はまたここに書きます。
応援してくださっている方、ありがとうございます。
2014年01月11日
ネオ繚乱記 攻略ページを作りました
このところ、ゲームを公開してせっかく遊んで下さる方がいるのだから、どこかに攻略情報を書いておきたいと思っていました。
当然ここでいいとか思っていたのですが、ちょうど今日（！）フリーゲームの攻略を集めるＷｉｋiが新しくできたようなので、さっそく書き込ませてもらいました。
攻略に詰まった際はぜひ参考にしてください。
フリーゲーム攻略Wikiはこちら
当然ここでいいとか思っていたのですが、ちょうど今日（！）フリーゲームの攻略を集めるＷｉｋiが新しくできたようなので、さっそく書き込ませてもらいました。
攻略に詰まった際はぜひ参考にしてください。
フリーゲーム攻略Wikiはこちら
2013年12月26日
自作ゲーム「ネオ繚乱記」 公開しました！
自作ゲーム、ネオ繚乱記を公開しました。
■ゲーム内容について
「ネオ繚乱記」は探索型アドベンチャーゲームです。
（所要時間は２時間程度）
逆さ言葉の収集要素があります。
ダウンロードはこちらをクリック！！
タイトル画面
多くの方にテストプレイにご協力いただきありがとうございました。
公開日は2013年12月26日です。
ゲーム中の一場面
ゲームを作る上でお世話になったサイトの方に、図々しくもレビューをお願いしました！
こんなことをここに書いて、不採用になったら恥ずかしい！けど、まあいいか・・・。
ちなみにこのページのコメント欄にバグ報告その他貴重なご意見を頂いていますが、これは以前仮に公開していたテストプレイ版に対するものなので、完成版では指摘のバグ等はなくなっています。
安心してダウンロード、プレイしてくださいね。（せっかくいただいた声なので消すのが忍びなくて、まぎらわしくてすいません）
■ゲーム内容について
「ネオ繚乱記」は探索型アドベンチャーゲームです。
（所要時間は２時間程度）
逆さ言葉の収集要素があります。
ダウンロードはこちらをクリック！！
タイトル画面
多くの方にテストプレイにご協力いただきありがとうございました。
公開日は2013年12月26日です。
ゲーム中の一場面
ゲームを作る上でお世話になったサイトの方に、図々しくもレビューをお願いしました！
こんなことをここに書いて、不採用になったら恥ずかしい！けど、まあいいか・・・。
ちなみにこのページのコメント欄にバグ報告その他貴重なご意見を頂いていますが、これは以前仮に公開していたテストプレイ版に対するものなので、完成版では指摘のバグ等はなくなっています。
安心してダウンロード、プレイしてくださいね。（せっかくいただいた声なので消すのが忍びなくて、まぎらわしくてすいません）
ラベル：ネオ繚乱記
2013年11月26日
いろいろ整理しました
この度ブログタイトルを変えました。
ハンドルネームも「じゃ」から「じゃ。」に変えました。
過去記事をいくつか消したり変えたりしました。
作成途中の自作ゲームのタイトルその他の募集は、感想、テストプレイを除いて打ち切りにします。
自作ゲームのタイトルは「ネオ繚乱記」にしました。
考えてくださった方、ありがとうございました。
ここはいずれはゲーム制作関係に限らず、何でも書く場にしようと思います。
けれどまずはゲーム作りを優先させます。
じゃ。のブログをよろしくおねがいします。
ハンドルネームも「じゃ」から「じゃ。」に変えました。
過去記事をいくつか消したり変えたりしました。
作成途中の自作ゲームのタイトルその他の募集は、感想、テストプレイを除いて打ち切りにします。
自作ゲームのタイトルは「ネオ繚乱記」にしました。
考えてくださった方、ありがとうございました。
ここはいずれはゲーム制作関係に限らず、何でも書く場にしようと思います。
けれどまずはゲーム作りを優先させます。
じゃ。のブログをよろしくおねがいします。
2013年11月22日
関西人の挑戦。標準語を使ったゲーム作り
僕は関西人です。だから普段、関西弁を話しています。
今までは自分の話す言葉が関西弁だと意識したこともなかったのですが、ゲームを作ってそのことに気づかされました。何事であれ、新しい発見は嬉しいです。
今回のゲームで僕は、広く日本人全般に違和感なく遊んでもらうために当然のこととして登場キャラに標準語を話させました。
しかし、くだけた会話文を書くのには骨が折れました。
考えてみると標準語の話し言葉など、今まで使ったことなかったですもんね。だって必要ないから。書き言葉なら標準語も関西弁も無いようなものですが、話し言葉となるとやはり違います。
特に女の子のセリフの文末が難しかったです。
関西弁なら「○○やん？」で済む所を「○○じゃない？」とか打ち込みながら、「関東の女の子は普段本当にこんな言葉つこてるんやろか」とか考えていました。
「ふざけんなや」で済むところが「ふざけないでちょうだい」になったり、僕の書く標準語は関西弁よりも大分長くなります。それは一般的にそういうものなのか、それとも僕の標準語能力が低いためにそうなるのか・・・。
また、標準語を書こうとすると何か変に気取っているように感じたりするのですが、これはもう仕方ないと割り切って、気にしないことにしました。
標準語の土俵で勝負しないといけないというのは地方人にはハンディといえるかもしれません。創作作品に使うのが、普段から使いこんで骨肉化された言葉なのかそうでないかには大きな違いがあるはずです。
まあここはしかし、モデルやタレントにハーフの人が多いのと同じで、地方人は地方人として、その異質さを持ち味にすればいいのだと、ポジティブに考えたいと思います。まあ僕のゲーム作りに関して言えば勝負でも何でもなくて、自分が楽しむだけのことですし。
でも今度作るゲームは、もうちょっと会話を減らそうかなと思ったり・・・。それか、コテコテの大阪弁のゲームもいいかな。
いろいろ考えるのですが、そういえば、まだあれは完成していないんだった！
・・・はい、作ります。
今までは自分の話す言葉が関西弁だと意識したこともなかったのですが、ゲームを作ってそのことに気づかされました。何事であれ、新しい発見は嬉しいです。
今回のゲームで僕は、広く日本人全般に違和感なく遊んでもらうために当然のこととして登場キャラに標準語を話させました。
しかし、くだけた会話文を書くのには骨が折れました。
考えてみると標準語の話し言葉など、今まで使ったことなかったですもんね。だって必要ないから。書き言葉なら標準語も関西弁も無いようなものですが、話し言葉となるとやはり違います。
特に女の子のセリフの文末が難しかったです。
関西弁なら「○○やん？」で済む所を「○○じゃない？」とか打ち込みながら、「関東の女の子は普段本当にこんな言葉つこてるんやろか」とか考えていました。
「ふざけんなや」で済むところが「ふざけないでちょうだい」になったり、僕の書く標準語は関西弁よりも大分長くなります。それは一般的にそういうものなのか、それとも僕の標準語能力が低いためにそうなるのか・・・。
また、標準語を書こうとすると何か変に気取っているように感じたりするのですが、これはもう仕方ないと割り切って、気にしないことにしました。
標準語の土俵で勝負しないといけないというのは地方人にはハンディといえるかもしれません。創作作品に使うのが、普段から使いこんで骨肉化された言葉なのかそうでないかには大きな違いがあるはずです。
まあここはしかし、モデルやタレントにハーフの人が多いのと同じで、地方人は地方人として、その異質さを持ち味にすればいいのだと、ポジティブに考えたいと思います。まあ僕のゲーム作りに関して言えば勝負でも何でもなくて、自分が楽しむだけのことですし。
でも今度作るゲームは、もうちょっと会話を減らそうかなと思ったり・・・。それか、コテコテの大阪弁のゲームもいいかな。
いろいろ考えるのですが、そういえば、まだあれは完成していないんだった！
・・・はい、作ります。
2013年11月21日
ゲーム作りって特殊だ！
僕が全くの素人からゲームを作り初めてから、半年位がたちました。最近、ゲームはどんなに作り込んでもモトデがかからない、そのことに新鮮な驚きを感じています。
ふつうの物作りでは、仮に椅子を改良して背もたれをつけるとするなら、それだけ材料がいります。その材料が買わないと手に入らないなら、追加のお金がかかります。
現代でも質素は一応美徳ということになっていて、ありあわせのものだけで満足できることはいいことだろうと僕などは思っているのですが、だから必要以上に物を買わない、無駄に電気がついていたら消すなど、知らず知らず身についています。
でもゲーム作りの世界では、そんなことは気にしなくていいんですね（おそらくプログラムというものは全般的にそうなのかもしれません）。僕が今回使用しているウディタというツールはとても高性能なようで、間違った使い方をしない限りはそうとう使い倒しても処理落ちなどないようです。
僕みたいなめんどくさがりは、色々な処理をできるだけ手抜きして済まそうとするのですが、するとやはりその程度のものしかできません。
だから、負荷がかかりすぎない限りは、あれやこれや、プレイヤーにとっていいと思われることは手間を押しまずやった方がいいのだろうと思うのです。
例えばループ処理というのがあり、同じ処理を何度もぐるぐる繰り返すことがあるのですが、これなんか僕から見ると水道の水を出しっぱなしにしているようで、どうもついつい控えたくなる。でもよく考えると控える理由は何もないんですね。プログラム内のぐるぐるをおさえても、電気代が安くなるわけでもない。
「プレイヤーには負担をかけるけど、内部処理はスマートです」なんて、何の自慢にもなりません。
つまり、一定スペックの動作環境があるなら、時間と手間さえ惜しまなければいくらでもいくらでもよりよいものを創りだせる。これって、ほとんど錬金術です。材料がなくても、今までなかったものがどんどんできるんだから。
すごいことだなーと、本当感心します。きっとこの世界になじんでる人には当たり前のことなのでしょうが、こんな世界もあったんですね。
まあその創造の対価となる、時間と手間というやつのコストがばかにならないわけですが。
・・・今夜もゲーム、作ります。
ふつうの物作りでは、仮に椅子を改良して背もたれをつけるとするなら、それだけ材料がいります。その材料が買わないと手に入らないなら、追加のお金がかかります。
現代でも質素は一応美徳ということになっていて、ありあわせのものだけで満足できることはいいことだろうと僕などは思っているのですが、だから必要以上に物を買わない、無駄に電気がついていたら消すなど、知らず知らず身についています。
でもゲーム作りの世界では、そんなことは気にしなくていいんですね（おそらくプログラムというものは全般的にそうなのかもしれません）。僕が今回使用しているウディタというツールはとても高性能なようで、間違った使い方をしない限りはそうとう使い倒しても処理落ちなどないようです。
僕みたいなめんどくさがりは、色々な処理をできるだけ手抜きして済まそうとするのですが、するとやはりその程度のものしかできません。
だから、負荷がかかりすぎない限りは、あれやこれや、プレイヤーにとっていいと思われることは手間を押しまずやった方がいいのだろうと思うのです。
例えばループ処理というのがあり、同じ処理を何度もぐるぐる繰り返すことがあるのですが、これなんか僕から見ると水道の水を出しっぱなしにしているようで、どうもついつい控えたくなる。でもよく考えると控える理由は何もないんですね。プログラム内のぐるぐるをおさえても、電気代が安くなるわけでもない。
「プレイヤーには負担をかけるけど、内部処理はスマートです」なんて、何の自慢にもなりません。
つまり、一定スペックの動作環境があるなら、時間と手間さえ惜しまなければいくらでもいくらでもよりよいものを創りだせる。これって、ほとんど錬金術です。材料がなくても、今までなかったものがどんどんできるんだから。
すごいことだなーと、本当感心します。きっとこの世界になじんでる人には当たり前のことなのでしょうが、こんな世界もあったんですね。
まあその創造の対価となる、時間と手間というやつのコストがばかにならないわけですが。
・・・今夜もゲーム、作ります。
2013年11月19日
効果音作り
ＢＧＭは挫折したものの、効果音は自作できないかと思ってフリーソフトを探してみました。
すると面白い物を見つけました。
かなウェーブという効果音作成ソフトです。
（↑ベクターの紹介サイトにリンクを張ります。）
これのすごいところは、「ういーん」とか「がちゃん」とか、かなを入力することでそれに応じた雰囲気の効果音が作れてしまうのです。
これを触っていると面白くて、時間を忘れてたくさん作ってしまいました。
結局、今回のゲーム内ではアイテムを手に入れたら「ぱっぱぴー」、協力者が増えたら「なかまかな」と鳴らすことにしました。（その通りに発声されるわけではないです。）
ここをご覧の方で、効果音が必要な方がもしいたら、ぜひ一度このソフトを試して下さい。
もともと僕は逆さ言葉が好きで、きっと根っからの文字好き、言葉好きなんでしょうね。
文字列が音になるだけでワクワクします。
ちなみにＢＧＭを試作したのも、テキスト音楽サクラというソフトでした。
これは「どみそっそー」と入力すればその通りの音が鳴る仕組みです。
いろんなソフトが無償配布されていて、僕のような素人でも創作活動にチャレンジできるのは有難い限りです。
すると面白い物を見つけました。
かなウェーブという効果音作成ソフトです。
（↑ベクターの紹介サイトにリンクを張ります。）
これのすごいところは、「ういーん」とか「がちゃん」とか、かなを入力することでそれに応じた雰囲気の効果音が作れてしまうのです。
これを触っていると面白くて、時間を忘れてたくさん作ってしまいました。
結局、今回のゲーム内ではアイテムを手に入れたら「ぱっぱぴー」、協力者が増えたら「なかまかな」と鳴らすことにしました。（その通りに発声されるわけではないです。）
ここをご覧の方で、効果音が必要な方がもしいたら、ぜひ一度このソフトを試して下さい。
もともと僕は逆さ言葉が好きで、きっと根っからの文字好き、言葉好きなんでしょうね。
文字列が音になるだけでワクワクします。
ちなみにＢＧＭを試作したのも、テキスト音楽サクラというソフトでした。
これは「どみそっそー」と入力すればその通りの音が鳴る仕組みです。
いろんなソフトが無償配布されていて、僕のような素人でも創作活動にチャレンジできるのは有難い限りです。
2013年11月18日
祝！初コメント！
このブログで初めてゲームの感想のコメントを頂きました！ありがとうございます！
このブログ、消さなくてよかった・・・。
キャラの掛け合いが楽しめたと言ってもらえてとても嬉しいです。
ああいったものをぼくはまあ一応面白いと思っている訳ですが、けれどもきっとそれはあまり一般受けはしない気がするのです。（だから感想を教えてもらって不必要なカドをとってできるだけ人当たりをよくしたいと思っているんです。）
でも、もしほんの少人数でもそれを楽しんでもらえる人がいるなら、寝不足になりながらゲームを作ったかいがありました。あー嬉しい。
そうですね、効果音、あった方がいいですよね、やっぱり。今日も制作を進めていて、ＢＧＭを入れたのですが、テストプレイすると効果音のことがふと頭をよぎって「あった方がいいけど面倒だし、なしでもいいかー」とか思ったのですが、もう決めました。断然、入れます！誰が何と言おうが入れます！
アイテムを手に入れたり技を身につけたり、協力者がふえたりしたらやっぱり演出で音は欲しいですよね。わざわざ動きを止めるほど大げさな曲でなくても。
サカコトゲットの時はどうしよう・・・まあいいかな。いや、やっぱいりるかな？
ここでもし感想がいただけなければ一応完成させたものをテストプレイ版Ｖｅｒ．２としてまたアップして、ふりーむのテストプレイヤー募集掲示板ででもお願いしようかと思っていたのですが、今日コメントに気づいて、もうこのまま完成まで突っ走ってしまおうか、迷っています。
それにしても反応をもらえることがここまで励みになるとは・・・。ご期待にこたえられるよう、完成を急ぎます。
このブログ、消さなくてよかった・・・。
キャラの掛け合いが楽しめたと言ってもらえてとても嬉しいです。
ああいったものをぼくはまあ一応面白いと思っている訳ですが、けれどもきっとそれはあまり一般受けはしない気がするのです。（だから感想を教えてもらって不必要なカドをとってできるだけ人当たりをよくしたいと思っているんです。）
でも、もしほんの少人数でもそれを楽しんでもらえる人がいるなら、寝不足になりながらゲームを作ったかいがありました。あー嬉しい。
そうですね、効果音、あった方がいいですよね、やっぱり。今日も制作を進めていて、ＢＧＭを入れたのですが、テストプレイすると効果音のことがふと頭をよぎって「あった方がいいけど面倒だし、なしでもいいかー」とか思ったのですが、もう決めました。断然、入れます！誰が何と言おうが入れます！
アイテムを手に入れたり技を身につけたり、協力者がふえたりしたらやっぱり演出で音は欲しいですよね。わざわざ動きを止めるほど大げさな曲でなくても。
サカコトゲットの時はどうしよう・・・まあいいかな。いや、やっぱいりるかな？
ここでもし感想がいただけなければ一応完成させたものをテストプレイ版Ｖｅｒ．２としてまたアップして、ふりーむのテストプレイヤー募集掲示板ででもお願いしようかと思っていたのですが、今日コメントに気づいて、もうこのまま完成まで突っ走ってしまおうか、迷っています。
それにしても反応をもらえることがここまで励みになるとは・・・。ご期待にこたえられるよう、完成を急ぎます。
2013年11月15日
じゃの近況
誰もプレイ感想のコメントをくれないのがさみしくもあるのですが、よく考えるとコメントってなかなか書きずらいよね、と、書き込みがないのはコメント欄のせいだということにして、とりあえずメールアドレスを張り付けてみたのは昨日のことなのですが、それから一日たって誰かがメールをくれたかどうかはここでは秘密なのです！
メールのいい所は、そこで何かのやり取りが行われているかどうか、傍目には見えないということですね。
「ゲームの感想はコメントで」と言っているのに誰一人書き込まないっていうのは、これはまあ悲しすぎるし、それを誰が見ても一目瞭然という状態はなかなかキビシイものがありますね。我ながら自分がイタい存在なのだと認めざるを得なくなってしまう。
そう、きっと誰かがじゃにメールでプレイ報告を送ってるんだよ。みんなそう思って。お願い！
まあメールはメールで、僕のような正体不明な存在に日常使いのメールアドレスを教える物好きは少ないだろうし、かといって僕に連絡するためにわざわざフリーメールを登録（捨てアカウントっていうやつですね）する人はさらにいないだろうから、敷居が高くなるということはあるかもしれないけど。
誰も連絡をくれないならさっさとこんなブログはひきはらってしまえばいいと思うものの、不思議なことにもったいなくも、何を思ってか毎日数十人の方がのぞきにきてくれているようなのです。内容もなく更新もしないこんな場所なのに。ありがとうございます。
そういうことならまあゲームの制作日記でも書こうかと。
今は、ひょっとしたらだれか感想をくれるかもという期待（幻想？）を捨て切れていないので、僕はシナリオには手をつけず、音楽にとりかかることにしました。
そしてフリーの作曲ソフトでBGMを作りました。単旋律で短いメロディーを繰り返す、いたって簡単なものです。ぼくは音楽にはこだわらないから、どんなにシンプルな曲でも自作して、自作ということに惹かれて少しでもプレイする人が増えればいいと思ったのですが・・・。
曲を作ってみて、驚きました。できた曲は想像をはるかに超えて、あまりにもチープすぎ・・・！
そこで参考までに音楽素材を無料配布するサイトを初めてのぞいたのですが、レベルの高さにびっくりしました。僕と比べれば月とすっぽんです。
音楽自作と銘打って僕の曲をかけるより、素直にお借りした方がゲームをプレイして下さる方のためだと思いました。
よく「素材自作なんてすごい！」とか聞くのですが、それは自作する手間をかけたことがすごいのではなくて、公開するに値するレベルのものを作りだせたことがすごいのだということを初めて知りました。
そりゃ、手間をかけるだけで評価されるなら、誰だって手間をかけますよね。一つやってみて、一つまたかしこくなりました。やってみなきゃわからないことばっかりですね。
まあ今日はこのあたりにしておきましょう。
ここにこんなことを書きている時間があればゲームを作った方がいいのかもしれませんが・・・。だから次回更新はいつかわかりません。でも明日かも。
じゃ。
メールのいい所は、そこで何かのやり取りが行われているかどうか、傍目には見えないということですね。
「ゲームの感想はコメントで」と言っているのに誰一人書き込まないっていうのは、これはまあ悲しすぎるし、それを誰が見ても一目瞭然という状態はなかなかキビシイものがありますね。我ながら自分がイタい存在なのだと認めざるを得なくなってしまう。
そう、きっと誰かがじゃにメールでプレイ報告を送ってるんだよ。みんなそう思って。お願い！
まあメールはメールで、僕のような正体不明な存在に日常使いのメールアドレスを教える物好きは少ないだろうし、かといって僕に連絡するためにわざわざフリーメールを登録（捨てアカウントっていうやつですね）する人はさらにいないだろうから、敷居が高くなるということはあるかもしれないけど。
誰も連絡をくれないならさっさとこんなブログはひきはらってしまえばいいと思うものの、不思議なことにもったいなくも、何を思ってか毎日数十人の方がのぞきにきてくれているようなのです。内容もなく更新もしないこんな場所なのに。ありがとうございます。
そういうことならまあゲームの制作日記でも書こうかと。
今は、ひょっとしたらだれか感想をくれるかもという期待（幻想？）を捨て切れていないので、僕はシナリオには手をつけず、音楽にとりかかることにしました。
そしてフリーの作曲ソフトでBGMを作りました。単旋律で短いメロディーを繰り返す、いたって簡単なものです。ぼくは音楽にはこだわらないから、どんなにシンプルな曲でも自作して、自作ということに惹かれて少しでもプレイする人が増えればいいと思ったのですが・・・。
曲を作ってみて、驚きました。できた曲は想像をはるかに超えて、あまりにもチープすぎ・・・！
そこで参考までに音楽素材を無料配布するサイトを初めてのぞいたのですが、レベルの高さにびっくりしました。僕と比べれば月とすっぽんです。
音楽自作と銘打って僕の曲をかけるより、素直にお借りした方がゲームをプレイして下さる方のためだと思いました。
よく「素材自作なんてすごい！」とか聞くのですが、それは自作する手間をかけたことがすごいのではなくて、公開するに値するレベルのものを作りだせたことがすごいのだということを初めて知りました。
そりゃ、手間をかけるだけで評価されるなら、誰だって手間をかけますよね。一つやってみて、一つまたかしこくなりました。やってみなきゃわからないことばっかりですね。
まあ今日はこのあたりにしておきましょう。
ここにこんなことを書きている時間があればゲームを作った方がいいのかもしれませんが・・・。だから次回更新はいつかわかりません。でも明日かも。
じゃ。
