じゃ。のページ

装備は無属性耐性をつけてのぞみましょう。
この敵はステータスなどが見えなくなりますが、マリモが覚えた百見を使えばちゃんと見えるようになるのだと思います。
思いますというのは、ステータスや弱点などが本当にちゃんと見えているのか確かめようがない・・・ってこともないけど確かめるのがものすごく面倒だからです。
でも敵行動の表示はちゃんと見えるようになってました。
せっかく表示が正しく見えるようになるってことなので、ぼくはこいつに実は気絶がきくとかすごい情報が見れるんじゃないかと無茶苦茶期待していたのですが、それはなくてガックシでした。それでもあきらめきれなくて、百見でみた耐性も虚偽である可能性を考えて、スタンブロウを試してみましたがやはりだめでした。さすがにそんなに甘くないか。
でも行動がちゃんと見えるようになることは大きいです。
ターンによってダメージの大きい攻撃があって、それにだけ対処すればいいので、行動を見ないと勝てませんでした。
百見を解除もしてくるので解除されたら即再百見です。
ゲーム進行の中で強制的に覚えさせられた百見というスキルを使わないと倒しにくい敵の存在は、自由度が全くないことをゲーム作者さんから突き付けられているようでちょっとモヤモヤはしましたが、でもそれで敵を倒せて先へ進めるのはそれはそれで嬉しかったです。

ところで、唐突に中途半端なところからはじまったこのギフテッドワールド攻略記事でしたが、またまた中途半端ではありますがここでおわらせてもらいます。戦闘が類を見ないほど楽しめる、個人的にはここ数年で一番熱中できたゲームです。作者さん有難うございます！

状態異常耐性が全部０になる装備でのぞみます。
そしてイモミズクリの攻撃は無属性ばかりです。
なので無属性耐性に全振りします。
ぼくは無属軽減の指輪を店で大人買いしていっぱいつけました。
そして最初のターンの属性反転をしっかり受ける。
あとは攻撃に耐えながら、流転などで万象拘束大魔法をいつでも使えるようにして待機します。
８ターン目で属性を戻しに来るのでそれをスキップさせるために万象拘束大魔法を放ちます。
超強化でのフィジカルフォースなどを数回撃てばたおせるかもしれません。
あとイモミズクリは速度が速いので行動順で劣らないためにスピードを速める装備をつけておくと効果的です。

ちなみに流転する時はヨチヨチは隠匿迷彩術式を使いましょう。
即発なので行動を消費しないけれどCT短縮を1稼げます。
また今回のイモミズクリ戦では、流転使用ターンで無属性障壁を使うと、敵の攻撃が速いので、攻撃をしっかり押さえた後に流転で効果が消えるので、CT短縮も稼げるしお得感がすごいです。

前回の記事時点では、宝物庫のボスには店売りの耐性装備を三カ所につけたら十分な耐性が得られて勝てるんじゃないかと思ってました。
そうしたら、出ました、鹿ですよ。攻撃属性を複数持つあの鹿です。
耐性装備も複数必要なのでやっぱり合成をさぼるわけにはいきませでした。
ぼくは毎回どのボスにも耐性装備は整えずに何度もチャレンジしてはぼろ負けし、やむなく泣く泣く面倒な合成素材集めに走るということを繰り返しています。
今回の鹿でも結局無属性だけでなく風雷や火熱の耐性装備が必要となりました。
その中でも一番重要なのは無属性耐性かもしれませんね。
攻略上でやることとしては、やはりいつもと大体一緒です。
ヨチヨチに時の砂時計を装備させてＴＰ回復アイテムを惜しみなく使ってＣＴを稼ぎます。
流転も駆使して、万象拘束大魔法をできれば鹿の攻撃パターンの一周である5ターンに一度放てるのを目指します。無理ですが。
鹿の攻撃は強力な時もありますが、ランダム（乱）攻撃は比較的弱いです。
強力な攻撃の時に万象拘束大魔法をできれば理想です。
でもなかなかそうもいかないので、ヨチヨチが属性障壁でしのいでいくしかありません。
どうしても死にそうなときにはリカバリーをかけておくといいです。
死ぬと流転のためにかけ貯めた状態強化が解除されてしまうので、何としても死なないで進めたいところではありますが、それでも全滅してしまっては元も子もないのでやはり備えておくに越したことはありません。リカバリーかけておくキャラは即席レイズが使える（時がある）マリモがいいかもしれません。
鹿は中盤以降、キャベツを食べてHPを回復するターンがあります。
そのターンは万象拘束大魔法でスキップさせれたらいいのですがなかなかそうはいかないです。
しかし回復量はそれほど気にするほどではありません。
ぼくの場合はマリモが超強化してフィジカルフォースをHP満タンで攻撃力アップ状態なら鹿の回復量の3倍くらいのダメージを与えられました。
だからとにかく自分たちが死なないことを優先にして、だらだら戦い続ければいつかは勝てます。
がんばりましょう。

気づいてない人がもしいたら何なので念のため書いておくと、即席キュアでも回復できますー！

宝物庫の異形のモロイ、闇属性耐性をつけないといくら戦っても勝てないです。
闇属性耐性をつけたら簡単に勝てます。
装飾欄が3つに増えたからダークシールを全員三枚張ってもいいかもしれませんが、まあやはり手間でなければダークネスシールを合成するのが順当でしょう。
敵が仕掛けてくる状態異常は無効化も回復もできませんが、唯一装飾品のノーサンキューだけは有効です。
ただノーサンキューを装備するとあらゆる補助効果もきかなくなるので、補助効果がないのは我慢するとしても流転がきかなくなるのが痛いです。
あ、今から思えばすまーテストに装備させたらよかったかな。
スマーテストは流転はそれほど意味はないし、回復キャラがいつでも自由に動けるのは安心ですもんね。
装備を整えたら、戦闘の流れはいつもの通り、大技を打てる時は打って、流転をできるだけ使って、時の砂時計も活用して、万象拘束大魔法を使いこなす、おなじみのパターンでした。
そうか…装飾品の装備欄が3つになったんだから、店売り装備を3つ装備しただけでも相当の耐性になるのかな。
今後また耐性のために合成の素材集めをしないといけないことになったら、その前に試してみます。
それにしてもこのゲーム、耐性の重ね掛けがパーセントで計算されるの、プレイヤーとしては嬉しくないです…。
作者さんはがんばって改造したという、こだわりポイントだったようですが…。

前回で装飾装備か所を3カ所に増やせるアイテムが合成できるようになっているので、忘れず作りましょう。
今回は光属性耐性の装備が必須です。
聖騎士の兜の素材の騎士の兜はお城のお店で買えます。
攻略のかなめは、敵が5ターン目ごとに放ってくる反罰を受けないようにすることで、その方法としてはヨチヨチも5ターンごとに万象拘束大魔法を放つしかありません。
万象拘束大魔法のクールタイムはだいぶん長いので、それを短くする必要があります。
流転はもちろんですがヨチヨチに時の砂時計を装備させて、TP回復やテクニカルアイテム使用でそこそこ毎回万象拘束大魔法が出せるようになります。
流転でのＣＴ回復量を増やすために、補助効果付与アイテムを使うのが効果的です。
補助効果付与アイテムは領主の町の学校でチュートトが売ってくれます。
敵は沈黙状態も付与してくるので、沈黙を防げる装備も必要です。
敵の攻撃は最終ターン以外でも強いので、苦戦します。
防ぐためにはヨチヨチが聖光障壁をするしかないのですが、万象拘束もしないといけないし、時の砂時計のためTPを上げたり下げたりしないといけないしでヨチヨチがもうすごく大忙しです。
時の砂時計を他キャラにつけたらどうなんだろう…やってないからわかりません。
どうしても反罰攻撃を止められない時は観念して、できるだけ多くのキャラにリバイバルをかけておいて復活するしかないかも。
万象拘束のための流転のために、ヨチヨチにはステートキーパーズを装備させれば死んでも補助効果付与がリセットされなくて超いいです。
あるいは攻撃役のマリモでもいいかもしれません。
ここまで書いてきたことは全部どうやって時間稼ぎをするかという話ですが、もちろんそれだけではだめで、敵を倒すにはやはりマリモを強化した上での即発アタック・フィジカルフォース・パワーイズライトをどれだけ叩き込めるかということが重要になってきます。

ギフテッドワールドの攻略情報が今の所動画でしかないので、書いておきます。
ボスの倒し方です。
値段の高い装備が売られている間は、お金をためて買えば、勝てるようになります。
店売り最終装備の表示が出て敵に勝てなくなったら、合成工房で合成するしかありません。
少し手間ですが、ボスと戦ってみて、敵の攻撃の属性と敵の弱点の属性を確認して、合成工房内を歩いて、その弱点を克服できそうな装備を探し、その合成に必要な合成素材アイテムが何かをチェックし、図鑑でそのアイテムを開いてみてどこのマップで手に入りそうか目星をつけ、そのマップにワープして雑魚敵と戦って、どの敵が欲しいアイテムをドロップするか探し、見つかったらアイテム入手時にアイテム名に緑のチェック（必要数入手済の印）が表示されるまでそのアイテムを集め続ければ、いつか必要な装備を合成で入手できます。だいぶん手間ですね。
基本的にはマリモを超強化しパワーイズライトをする、というのが戦闘の流れになります。
そのために必要なCTを稼ぐために、回復したり、敵の攻撃を耐えしのいだりします。
終盤に即発レイズをまだ身につけていなければマリモの実家に帰ってみて下さい。
技能書の読み忘れもないように気をつけてください。
万象拘束大魔法の使いどころに気をつけてください。
流転を身につけたら活用してください。
それで宝物庫まで行けるんじゃないかと思います。
宝物庫の敵は強いです。
宝物庫のボスの倒し方を書きます。

今日は宝物庫の柵かじりねこです。
無属性耐性のある装備をできるだけ身につけてください。
敵に毒状態をかけるのは必須です。
気絶がきくのでマリモのスタンをできるだけ毎ターンでもかけてください。
ヨチヨチが時の砂時計（TP満タンでＣＴを減らす）を装備して下さい。
ＴＰ回復やＴＰ回復アイテムの使用でＣＴを進めれたらマリモがまたスタンをできるようになります。
それと万象拘束大魔法。
流転を活用してそれらを組み合わせれば、敵が行動できるターンはあまりなくなると思います。
宝物庫の柵かじりねこは、こちらがダメージを受けると大回復します。
なのでどうしても攻撃を受けないといけない時にはできるだけヨチヨチの無属性障壁でダメージを0にします。
無属性障壁でもダメージを0にできないメンバーがいるくらい無属性耐性装備が不足していれば、マリモに装備を集めて守護献身で一攻撃を一手に引き受け、さらに無属性障壁もかければダメージ0にできるので敵を回復させることもなくなると思います。
とにかく毒がきくのでうまくできたら比較的短時間で勝てるかもしれません。

随時更新する予定。

ぼくは絵が描けないので、ゲームを作っていても顔グラが用意できなくて歩行グラしかない場合、その歩行グラを顔グラとして使うしかありません。
けれども基本システムでの顔グラ表示は一枚の画像素材の全体丸ごとを表示するものです。
画像素材の分割の設定やパターン番号の指定はできません。
もしウルファールの歩行グラを顔グラ素材として指定すれば、24体のウルファールが表示されてしまいます。（多分）
しかし今夜はそれをごく簡単な改造で解決できたので、メモ代わりに書いておきます。
（ここに書くのはウディタVer2のことです。Ver3は未確認なのでわかりません。あしからず。）

・まずはシステムDBの「顔グラフィック」に歩行グラ用に作られた画像を設定したうえで、
・コモン68番「メッセージウィンドウ」を開いて
・127行目のコマンド「ピクチャ表示」を開いて
・ウルファールなどの同梱素材の規格（8方向3パターン）なら分割数を横６縦４にして
・パターンの同期のチェックを外して、パターン数を４（左前を向く画像）とかに指定する。


これだけで、歩行グラ素材の中の一つの画像を顔グラとして表示させることができるようになります。
ただしこのやり方だと全ての顔グラ用素材が分割され部分表示されてしまうので、通常の顔グラ素材と混在させるときには何とか工夫しないといけないので気をつけてください。
使える顔グラ素材なんて一枚も持っていないよ、という時だけ上の方法を使ってください。

それにしても解像度の粗さよ・・・。
まあサンプルゲームデータの顔グラに入ってるのもこんなもんだし、画像があるだけおんのじですね。

Yahoo！知恵袋というサイトによくある「この写真の人の名前を教えてください」という質問の答えを探す方法について、前回の記事で書きました。
あの記事ではその方法を知りたい方のために必要な情報をにコンパクトに書いたんです。
で、この記事ではそれにまつわるいろいろよけいなことを、コンパクトじゃなく書きます。
（自分語りを含むので興味ない人は読まないでくださいね）

まず画像検索であの手の質問に答えられる率はものすごーく低いです。
５パーセントもないのじゃないでしょうか。
半数以上はその画像はネット上では確認されていないです。
そして残りの大半は逆にネット上に氾濫してしまい、画像の出どころと紐付けられない形で出回ってしまっています。

こんなの、写真の被写体の了承が得られていない場合は本人は随分つらいかもしれないけれど、それってどうしようもないのだろうか。
特定の個人によって個人情報を流出されたりした場合はそれをたどって削除要請などもできるのかもしれないけれども。
けれどもよく出回っている画像というのは本当に世界中でシェアされていて、本人が消してほしいと思っても、それはとても不可能に思います。
というか顔や名前を売りたい芸能人でもない限り、たいがいの人はネット上に自分の顔が氾濫して嬉しいとは思わないんじゃないかな。
つらい人多いんだろうな。
まあ中には「自分の顔はこんなに世界中で拡散されてるんだ、自分に魅力がある証拠だからうれしい」とか、承認欲求を満たせてポジティブにとらえる人もいるかもしれないけれども、それはごくごく一部でしょう。

ちなみにその、つらいかもしれない人の名前探しをしているぼくの見解（言い分？）を書いておきます。
ぼくが調べているのはネット上に公開されている情報だけです。
その情報を公開することに本人が同意したか、そして現在でも後悔していないか、知るすべはありません。
そしてその情報はネット上にある限りはぼくでなくても誰でもアクセスできます。
ぼくが効率のいい方法を知っていたとしても、誰でも手間暇時間をかければいつかはたどり着けるであろう情報です。
そのような情報に対して、本人がつらいと思っている可能性がある一方で、その回答を求めている質問者がいます。
質問者の動機は様々でしょうし、知るすべはありません。
単純にすてきな写真の人のことをもっと知りたいという場合も多いでしょう。
恋人のスマホの待ち受けになっていた人物が誰なのか知りたいとかもあるかもしれません。
ひょっとしたら通勤途中に出会った見知らぬ異性を隠し撮りして個人情報を集めようとしている犯罪者さえいるかもしれません。
それらは分からないことです。
ただ、質問者の多くは求めていた回答が得られると、大変喜びます。
そのようなもろもろをトータルに勘案して、名前探しをすることは悪いことではないのではないかと判断しています。
断っておきますが、ネットには特定屋という人がいるらしく、個人があげた画像から映りこんでるものなどを手掛かりとして個人情報を特定したりするそうです。しかしそれは本人は望んでいないからよくないことだとぼくは思うし、やりません。（ネットに個人情報につながりうるデータをアップすることの脇の甘さは言えるでしょうが、それは別の話です。）
ぼくはネット上で名前やそれに類するものにたどりつくことに興味があるだけです。

とはいえ、質問者に喜ばれることだけがぼくが名前探しをするモチベーションではありません。
できなくて困っている人がいる一方でそれを自分は簡単にできるので、そこを埋めてあげたいというのはまぁあるんだけれども。
でもそれよりも自分のネットリテラシーを磨きたい、確認したいとか。
それと画像認識というＡＩを駆使した最先端技術の到達点を肌で感じたいとかが大きいです。
それらが大きな動機となっています。

画像認識の精度について書きましょうか。
いくつか試しましたが、いまのところGoogle Lens以外で使える画像検索の方法には出会えていません。
（有料の方法は試していません）
そしてそのGoogle Lensでも、認識という点では全然まだまだだなと感じます。
現状では、同一の画像がネット上にあるかないかがわかるだけです。
似た画像として提示される画像は、まあ、驚くほど全然似ていなかったりします。
ましてや同一人物の別シーンでの顔を同一人物として提示してくることなどはまだまだ夢物語のようです。
でも世間では顔認証とか実用化されているんですよね。
ネット上のデータだけでいいから、誰でも手軽に検索できる日がはやく来たらいいなと楽しみにしています。
指名手配犯は困るでしょうね。
（そういえば中国のスマートシティでは監視体制が完全に確立されていると聞きます）

まあ、日本のＰＣで個人ができる現状の画像検索と言ってもその程度なのですが。
それに対して質問者さんの質問の仕方、すなわち画像の選び方があまりにも「どうせいっちゅうねん！」と突っ込みたくなる場合があります。
画像の一部を加工して塗りつぶしたりとか。
スマホの画像のスクショなので上下に余白があったりだとか。
長い動画の中のある時点の写真だとか。
これらの場合はほぼ特定できません。
まあ余白がある場合はこちらでトリミングしてあげて検索してあげれば精度の高い検索はできるはずです。
ぼくも何度かはやってみましたが、手間をかけても結局特定にはつながらないことばかりなので、もうやめました。
まあ質問者さんも「名前を教えて」と言っていても、「同一画像をネットから探して」と言っているわけではないですからね。
第一義的には、被写体の身近にいる個人的な知り合いに向かって「あなたの知り合いなら教えて」という感覚だろうし。
そうでなくても「この人はアイドル（あるいは芸能人、インスタグラマー、Youtuber…）だからそれに詳しい人教えて」ということかもしれません。
ただぼくはそれらは全く詳しくないのでそういう方法では全然役には立てないのです。
画像を載せる場合はどこで手に入れた画像かを書いてくれたら随分探しやすくなるのにと思うことがよくあります。
（あるいは逆に、見つかるわけないからさっさとあきらめる、とかもできるし…）

この画像の名前探しを続けていると、写真を見ただけで「この人の名前はいくら探してもまず出てこないな」とわかるものがあります。
よくあるのは衣料品のモデル。消費者であるぼくらが目にすることは多い一方で、名前が出ていることはほとんどありません。例外的には有名ブランドが有名芸能人をイメージキャラクターとかキャンペーンガールとかに任命している場合はSNSなどで名前が出ています。ただ普通のショッピングサイトなどのモデルはほぼ絶対わかりません。
それからネット広告のモデルです。スマホアプリや動画の広告などで見つけた写真はまず名前を特定できません。
質問者がテレビ番組の一時点を撮影した画像も絶対にわかりません。全く同じ画像がネット上にないためです。
（例外として番組名と放送日からゲスト出演者名が特定できたことはありましたが、そんなことはほとんどないです）
その一方でCMなどはシーン数が少ないので（写真撮影にテレビの枠が写ったりしてない限り）画像検索でヒットすることがあります。
特にテレビCMはまとめサイトもあるし、絞り込めた芸能人のWikipediaにCM出演情報があるので特定につながったりします。
韓国のコスメ動画はなぜかわかる場合が多い気がします。ハングルは読めませんがmodel誰々と載っていることがあります。

検索結果の中で、名前特定に一番つながりやすいのはインスタグラムに本人があげている写真です。自分の顔ばかり上げる人が多いので特定が容易です。
次にみつかるのはTikTokです。本人があげていることも多いですが、美少女など、まとめてあげている場合もあるので要注意です。
ツイッターはみつかりません。名前が見つからないだけじゃなく、写真自体が見つからないことが多いです。検索結果としては特定のツイートがでるのですが、そのツイートには目的の画像はありません。そこについたコメントのアイコンにその画像が使用されている場合があります。しかもアイコン画像はコロコロ変える人も多いです。さらにはツイッターのアイコンは本人画像でない場合が多いです。せっかく目的の画像をアイコンにしているアカウントを見つけてもプロフィール欄を見ると本人じゃないとわかってがっくりることが多いです。（かわいい女の子を好きな人が、かわいい女の子をアイコンにしている場合が多いです）
ツイッターに限らないことですが、ジャニーズアイドルのファンは推しの顔をアイコンにする傾向があり、画像とアカウント名とが結びつかないことがほとんどです。
ピンタレストという画像共有ＳＮＳがあります。肖像権などどこ吹く風というちょっと恐ろしい世界なのですが、画像検索結果がピンタレストにでてくることがよくあります。世界中の多くの人にシェアされて出どころのわからない写真も多いのですが、引用元を表示する欄が一応あるので、時々特定につながることはあります。インスタグラムや個人ブログなどから引用した画像だとわかれば個人名がわかります。ツイッターよりはまだ有意義な情報につながる率が高いです。
一番意味がないのがYahoo！知恵袋です。画像検索にYahoo！知恵袋がヒットしても、それはその質問のためにアップされた画像のことなので当然名前は分かりません。また、Yahoo！知恵袋ではその画像が出てこないページが多くあります。そのリンク先のページでは別の画像について「この人の名前は何ですか」と質問されていて、よく似た質問として目的の画像が過去に表示されたのだろうけれども、それは時間がたつにつれて更新されていくので、閲覧している時点ではもう目的の画像は表示されていないということだろうと思います。ただ非常にまれなケースとして、ネット上で多く出回っている画像（そしてその中でも特に芸能人）の場合は過去にも同じ質問がされていてちゃんと回答も載っている場合があるのでその時ばかりは特定につながります。

こんなことをやってると、意外に海外の人の画像に興味がある人が多いんだなと驚かされます。
韓国や中国、あるいは西洋とかならまだわかるけど。
質問者さんの探求心はグローバルです。結構どこの国の人のことでも、国籍を知っていても名前を知りたがっています。
発音の仕方もわからない名前を知ってどうするのかとも思うんですが（まあ検索してさらに情報を集めたいんでしょうね）、ぼくも特定できた場合には現地の言語の名前と思われる部分をコピペして回答することもあります。

いろいろ書きましたがあなたのお役に立つことがあれば幸いです。

Yahoo！知恵袋というサイトがあります。
そこでよく「この写真の人の名前を教えてください」という質問を見かけます。
その答えをどうすれば知ることができるか、いろいろやってみました。
そこでたどりついた画像を探す方法についてこの記事で書きます。
方法以外のことは別の記事で書きます。

以下はぼくのやっている方法なので他にやり方もあるでしょうしベストではないかもしれませんがご了承ください。
パソコンを使います。
ブラウザはGoogle chromeを使います。ない方はインストールしてください。
マウスカーソルを画像に合わせて右クリックしてください。
Google Lensで画像を検索というのが出たらそれを選んでください。
ただし、リンクが貼られている画像だと出ないようなので、可能ならリンクのない画像を探してください。
また、「画像をドラッグして検索　×」と出る場合もありますが、それをするとおそらく検索精度が下がるので、可能ならそうならない画像を探してください。
「Google Lensで画像を検索」がでてきて、クリックしたら、モニター右にGoogle Lensの枠が出ます。
ぼくの環境だとこの読み込みに少し時間がかかります。
しばらくたっても進まない場合は操作を繰り返して再読み込みしてください。
読み込みに成功したら、画像の下の方には見た目で一致というリストが出たりします。（出ない場合もあります）
しかしここには参考になる情報はめったにないです。まれに探している画像の一部を加工した画像とか、連続写真の別のものが見つかることもありますが、大半はネット販売のリンクなので「人の名前を調べる」という目的の役には立ちません。
大事なのは画像の上にある「この画像を検索」です。ここをクリックします。
すると検索結果がでます。
類似の画像というのはこれまたほぼ役に立たないので気にしないでいいです。
また、なぜかたまに検索窓に画像データ以外に勝手な単語が入っている場合がありますが、その時は検索結果が適当なので、上の方の検索結果は気にせず下にスクロールしてください。
そうするとどこかに「一致した画像を含むページ」というのがあると思います。
Google Lensで検索したのに「一致した画像を含むページ」が出ない時は、ネット上にその同じ画像は見つけられていないということなので、あきらめるしかないかもしれません。
（「一致した画像を含むページ」に載っていないにもかかわらず、インスタグラムにその写真を見つけたこともあるので検索も完ぺきではないでしょうが、とりあえずここで出てこなければなすすべはありません）
その「一致した画像を含むページ」以下の検索結果に、同じ画像がある（あるいは、あった）はずです。
一つ一つ開いて、名前につながる手掛かりがないか調べます。
ただ、そのサイトによって特定できる可能性は全然違います。
詳しくは別の記事で書きますが、インスタグラムがあればそれを、なければTikTokを探せば、名前（アカウント名）にたどり着く確率はまだ高いです。
Yahoo！知恵袋はほぼ載っていません。検索結果がYahoo！知恵袋しかないようなら、その画像はネット上では（Googleには）確認されていないと思っていいかもしれません。
インスタグラムやTikTok等に探している画像と同じものが投稿されていた場合、そのアカウントのほとんどの投稿が同じ顔の自撮り等なら、探していた画像の顔の名前（ネット上の名前）はそのアカウント名であるとみなしていいと思います。
そして必要に応じてそのアカウントのプロフィール欄などを確認して、その写真の被写体の方についてのより詳しい情報を集めてもいいと思います。

この記事では画像検索の方法を知りたい人に向けて、方法だけを書きました。
興味ある方は参考にして画像検索してみて下さい。
個人的に思うことなどはまた別の記事に書きます。

昨年末に、上司からいきなり無茶振りをされましてね。
手書きの図形を見せられて、こんなのをパソコンで作ってーって。
円や直線を組み合わせた図形です。ここでお見せできないのが残念なんですが。
そこでぼくはまず素直にペイント系のソフトを使ってみたんです。
でも使い慣れてないしどうもうまくできない。
これはもうしょうがない、やはり、ウディタの出番です。
常日頃ウディタを活用していかにペイントを使わずに済ませるかに挑戦しているぼくにとってこれは必然でした。
ウディタだと描画の座標やサイズ、色調などを全部数値でピシッと決められるからやりやすいんですよね。
もちろん手間は少しかかりますけど。

勤務中にウディタを使ったのは初めてでした。
ピクチャ表示を使って何とか求められた図形を描画し、スクリーンショットで画像ファイルにして印刷しました。
それを上司に渡すと、まあ思いのほか喜んでくれましてね。
といってもペイントを使いこなせる人ならだれでも簡単にできるものかもかもしれないけど。
でもぼくにとってはやはりウディタでなきゃできなかったことなので。
やっててよかった、ウディタ！

ところで円や直線を描くのに、ピクチャ表示の中の「お手軽ウィンドウ」の隠し機能といわれている「図形表示」を使いました。
＜LINE＞ や ＜SQUARE＞などと入力することで、画像素材がなくても描画できるというありがたい機能です。
この ＜LINE＞で真横や縦に直線を引いたり、 ＜SQUARE＞で長方形を表示させるだけなら、直感的に思い通りの配置ができるんですけども。
今回ぼくは斜めの線を引く必要があり、これが意外と手間取ったというか、訳がわからなかったです。
っていうか今でもよくわかっていないのだけれども、数値をいろいろいじっていたら目的の図形ができたので、原理はよくわかってないけどもうそれでヨシとした、というのが実情です。
なんか難しいんです、斜め線を引くのん。
（直線一本引くのにこんなに悩んでる人いないだろなって思った）
そこで、これを機にちゃんと斜め線の引き方を確認しよう！というのが今回の記事の趣旨なわけです。


ウディタ公式マニュアルのページの説明を見てみると、このようにあります。

＜LINE＞ ： 「座標」から「座標＋生成サイズ」の位置に白い直線を引きます。

白いというのは明らかに誤りというかまあ余計な部分であり、正確にはRGB値の色の直線が引かれます。
で、この図形表示では角度の数値は設定できないんです。
（これができたら簡単なんだけどな）
そこで座標と生成サイズをあらわす4つの数値を入力することでどんな直線を描くかを指定するんです。
でも「座標」から「座標＋生成サイズ」の位置に、っていったらその2点間に引くのかと思うけど、そうじゃないんですね。
いろいろやってみて、なんとなく言語化できてきた気がする・・・。

「座標」の点を「位置」（左上や中央とか）とする位置に置かれた、「生成サイズ」の大きさの長方形の対角線（二つあるうち「座標」を通る方）を引く

というのが適当なのかどうか。
ややこしいのは「位置」を「中央」に設定した時には、まあ当然だけどその座標は直線の端にはならない（中央になる）。
だからその場合は2点間を結ぶなんて言うシンプルな説明は成り立たない。
（ぼくが仕事で描画した時は全部この「中央」を使っていたので余計に混乱したのだと、今わかりました）
そして、「中央」を使わないにしろ、生成サイズにマイナスの値を入れると「位置」の扱いが直感とは逆になります。
例えば「位置」を「左上」にしてある「座標」に生成サイズXもYもマイナスにしたら、「座標」から左上に向かって直線が描かれます。
これって全然左上の座標が指定できてないやん、って思っちゃうんですけどね。
線の一番左上は「座標」で指定したのとは全然違うところにあるから。というか「座標」で指定した位置が直線の右下になってる。
まあマイナスという数値の定義からしたら当然なんでしょうが、とにかく直観とは違うので戸惑いがありました。
そして、そもそも直線における左上とは何か、っていう訳の分からない問題もあります。
例えば画面上に書かれた４５°右上がりの直線があるとして、それに左上なんて、ないですよね。
でもその場合その直線の左下の端が「左上」で指定した位置になる。
そしてその直線の傾きをもっと強く（縦に近く）したら、その直線の左下よりも右上の方が「左上」に近いはずなんだけど、それでも左下が「左上」になっちゃう。

なんだか文字にすると屁理屈で揚げ足取りを書いてる気分になるんですが、とにかく実際やろうとすると全然訳が分からなかったのです。
理系の人なら全然すんなり理解できるのかもしれませんけどね。文系脳はどうしても日本語の意味に引っ張られてしまうのかな。
難しい。
まあ結論としては、機能で斜め線を引くとき、直感的にできなかったら試行錯誤してみてね！ということで。
結局ちゃんと説明できてない気がするけど・・・。
とにかく難しいってことです。

NANさんがツクールで作ったゲーム、ねこさんぽをプレイしました。
町を歩いて猫たちに出会い、会話したり、どこにいるのか探しだす、短時間でできる作品です。
小さい子供に楽しんでもらえる作品にしたかったということですが。
ぼくはゲームにはついつい戦略やストーリーを求めてしまいがちなので、そういった刺激が少ないこの作品には新鮮さを感じました。
ゲームに初めて出会う子供にはきっと楽しんでもらえる作品だと思います。
何より、親としては安心して遊ばせられるというのが魅力です。
依存症の心配はない。他者とのやり取りもない。課金もない。

「キャラが自分の思い通りに歩いた！」とか、「新しいマップが目の前に広がった！」とか、本来ゲームはそれだけで十分わくわくするはずなんですよね。
ましてゲーム体験の少ない子供ならなおさら。
変にゲーム慣れしてしまって「そんなんじゃものたりなーい！！」ってなってしまうけど、それって贅沢というかすごく恵まれて幸せなことなのだと思いだすことができました。

別にレトロゲームを礼賛するつもりはないけれども、これから初めてゲームに触れる子供は、このねこさんぽのような素朴な作品から一歩一歩ゲーム体験を積み重ねることができたなら、何度でも新鮮な気持ちで感動できるかもしれません。

現在フリゲ２０２１という投票イベントをやっているので、そこでこのねこさんぽも投票しておこうと思います。

ネオ繚乱記を知っていますか？
知りませんよね。
ぼくが初めてウディタで作ったゲームです。

今日ひさびさにブログの過去記事を整理していたんですけれども。
なんと、ネオ繚乱記のダウンロードサイトがリンク切れになっていることが判明！

おっかしいなあ。フリーソフトの老舗Vectorに登録していたのになあ。
Ｖector自体がサービス停止したわけでもないのに。
長年ほったらかしにしていたら消されちゃうのかな。
そりゃ向こうも営利企業だもんね。慈善事業じゃないもんね。仕方ないか。

でも残念な反面、ちょっとほっとしたというか・・・。あまりにも黒歴史な作品なので。
というわけで、入手不可です。やれやれ・・・。

へのへのもへじコモンというのを作りました。
公式コモン集に登録しました。


こんなのを描けます。まあこのコモンがなくても簡単にできるんですが。


素材がなくても画像表示したい！という、いつものです。
使いたい方、使ってください。

以下にReadMeを張り付けておきますね。

----------------------------------------------------------------------------------------------------


このコモンはアスキーアートを拡張させるために使います。
アスキーアートとはテキスト上に文字などを並べて絵などを表現するものです。
通常は文字サイズは一律で、表示位置はスペースと改行で規定されます。
けれどもウディタではそれらを自由に指定できます。
なので、好きなサイズ、好きな位置に文字などを表示することができます。
このコモンではデータベースを使うことでひとまとまりのアスキーア−トを扱いやすくしているので、全体の位置調整や、データの受け渡しなどが簡単です。
その一方で、単に自作のゲームに一度表示させるだけならわざわざこのコモンを使ってもあまりメリットはありません。
個別にピクチャ表示をいくつもして調整したほうが早いかもしれません。

画像素材を用意できない時、同梱素材だけで可能な画像表示の幅を広げること。
それを目的としてこのコモンを作りました。

・導入方法
1、同梱したＤＢのどちらかをユーザＤＢのどこかに読み込んでください。
その時ＤＢ何番に入れたか覚えておいてください。

２、コモンをどこかに読み込んでください。場所は１つ使います。

３、ゲーム内で表示させたいときにコモンを呼び出してください。
その際に必ずＤＢ何番に入れたかの数字を、引数の２つ目に入力してください（超重要）。

・使いこなす方法
引数の１つ目に１を入力したら、表示したピクチャを消せます。
表示位置を調節するには、コモンを開いて、赤いチェックポイントで囲った部分の数値を変えてください。
アスキーアートのすべての情報はデータベース内で指定してください。
複数表示させたい場合はコモンを複製し、コモン内でピクチャ番号を大きくずらして使ってください。

・サンプルについて
「へのへのもへじ」で作った顔と「〇・・レフ」で作った顔のデータをDBに入れています。
ウディタのデフォルトのフォントを使用する前提で作りました。
自作ゲーム内で無断で使用してくれても大丈夫です。

フィリピン産のパパイヤがスーパーで売っていたので、買って、切って、実を食べました。
残ったのが種。
この種はピリ辛でスパイスの代わりになると教えてもらったことがあります。
試しに果肉から取り出した種をかみ砕くと、確かに辛い。
唐辛子のような、胡椒のような味がします。
けれどもそれはすぐに消える、後を引かない辛さです。

ところが。それはそれとして。
（ここからぼくのやったことと、体験したことを書きます。その理論や科学的意味はなにもわかりません。）
パパイヤの種を実から取り出したものを、5分くらい水につけます。
そして種の周りについているゼリー状の皮を取り除きます。
（数十粒を手のひらでもんでとりました。）
すると黒いとげとげのような形になります。
それを口に入れてかみ砕きました。
すると黒い皮はくしゃくしゃしてコーヒーかすのような状態になりますが、その中にかすかに油分なのか、何か種の味を感じます。
不思議なことに辛みは全くありません。
辛み以外の強い味もほとんどありません。ただ「種のエッセンスを味わっているなー」と感じるほのかな風味があるのみです。

しかし、驚きはここから！
その後に水を飲むと、その味が異様な甘さなのです。
普通の水なのに、明らかに強い甘みを感じます。
水を飲むまでの口の中は甘かったわけではないのです。
飲んだ水が甘いのです。

すごく驚いて、そして水があまりに美味しいので、コップ２〜３杯飲みました。
すると甘い味はしなくなってしまいました。
洗い流されてしまったのでしょうか。

これは一体どういうことなのでしょう？
ネットで「パパイヤ　口が甘く」とか検索しても全然出てこないのでここに書きました。
これを読んだみなさん、もしもパパイヤを食べる機会があればぜひ試してみてください。

本の感想はブログに書くつもりはなかったんだけど。
この本だけは特別。すごいから。
内容もすごいけど知名度の低さがまたものすごい。
再版されたりしているわりに、作者名を検索してもWikipediaさえ作られていない。
今どきそんな著者がいたのか。
ましてや本書の内容にいたってはネット上にはほとんど書かれていない。
かろうじてアマゾンレビューがあるくらいだけど、そこにも部分引用や絶賛する感想があるだけで、やっぱり本の内容はほとんど書かれていない。
それならぼくが書きましょうと。
そういうわけです。

上野霄里さんという方は昭和６年生まれの文筆家。
その方が昭和４４（１９６９）年に書いたのが本書（おそらく代表作）単細胞的思考です。
内容はエッセイと言えばいいのかな。
作者の信念というか主張を、様々な比喩などを用いながら繰り返し表現しています。
何を言っているのかとても分かりにくい。
それもそのはず、作者は他人に理解されようとがんばることは恥ずかしいと考えているのです。
自分の心からの叫びだけに価値を置け、他人にどう思われるかを気にするな、既成の体系に価値を置くな。
そう主張します。
科学の発達も、経済の発展も、歴史の進歩も、一切意味がないというのです。
あらゆる組織や集団との関係をよくしようと励む行為は悪いことだと、そういうのです。
その主張から当然の帰結として、作者はものすごく尊大で、大衆を軽蔑しきっています。
とても面白いのですがとにかく難解だし部分部分には興味がわかないしで読み進めるのが苦痛で、途中で投げ出しました。なので半分しか読んでません。


それにしてもこれはむちゃくちゃ斬新！
こんな本が存在すること自体がもうすごいと思いました。
そしてこの本が有名でない理由もよくわかりました。
この本の内容に共鳴する人も多くいることだと思います。
けれどもこの内容に共鳴すればするほど、世間に向かって「こんな本があるよ！」って働きかけることには意味がないということになります。

最近ぼくはコロナ関連で再生産数という概念を知りました。
感染症にかかった人が何人にうつすかっていう数字で、１以上なら感染者が増えていくんですよね。
この本に触れた人が誰かに紹介する再生産数は１以下だと思う。
そうでなきゃネットが発達してるのにこんな個性的な書物がここまで知られてないなんてありえないと思う。

そして本書の知名度の低さについては時代の影響も強く感じました。
ネットが一般化した１９９５年以降の出版ならマニアには知られる本となり、ネタにもされ、伝説にもなったと思う。
でもそれよりはるかに前に埋もれてしまったトピックスが、時代をさかのぼってネット上に掘り起こされていくのはなかなか難しいのだろうと想像しました。

ひょっとしたらおじいちゃん界隈では有名な本なのかもしれませんね。
ネット上で本書に触れている数少ない方もほとんどが年配の方ではないかとお見受けしました。その方々がいなくなった時、本書は誰からも忘れられていくのかもしれません。

さて。ぼく個人のこの本の内容に対する考えです。
自分の心が大事だという点にはもろ手を挙げて賛成できます。
ただ、その自分とは何なのか。
ぼくは自分という概念に自分の生まれた時代、生きる社会、周囲の環境ということを織り込むことに抵抗はありません。
自分をよりよく生きるということが、社会をよりよく生きること（経済的安定を目指すとか）とほぼイコールであることを恥ずかしいとは思いません。
自分を生きるということは、もちろん自分の心に忠実に生きることでもあるでしょう。
でもそれだけではなくて、時代を生きる、社会を生きる、役割を生きる、立場を生きる、それらも全部自分を生きるということだと思います。
ぼくはそれらを全部やりたいし、というかそれらを放棄するという選択は全くあり得ないのですが、そのことを窮屈とも思っていないのです。


結局は好みの問題じゃないかな。
作者さんは熱烈に主張しているのですが、ぼくの感想としては「そう思いたいのならそう思っていればいいんじゃないでしょうか」というものです。
すごく刺激を受けて興味を持ったのは確かですが共感はしなかった。
でも共感はしないとはっきり言いきれるのはぼくの今までの数十年の人生経験があるからで、もしも若い時、社会とのかかわり方を確立する前に本書に出会っていたらきっと影響を受けていたと思います。
何も知らない時に断言されて煽られたらフラフラしちゃうよ。
若い時に本書に出会わなくてよかったとしみじみ思います。
でももし若い時に出会っていたら、その後今頃の歳になって、振り返って出会ってよかったと思っているかもしれないと思います。
それだけ影響力のある本です。こわいな。
（なお、ぼくは前半しか読んでいないので後半に全然違うことが書いてあったらごめんなさい。）

興味がある方は探して読んでください。

先日から始まった今年のウディコン。
今までに７作品ぐらいプレイしましたが、その中で一番楽しませてもらっているのがDMDAEMONさんのバリバリダアです。
ルールがわかりやすいです。
やることが簡単なので何も考えずにバリバリ楽しめます。
キャラ設定や世界観が個性的で先を見たいと思わせます。
年齢を重ねたためか、難しいゲームや不親切なゲームに我慢してまで付き合う忍耐力が下がってきていると感じるのですが、そんなぼくにバリバリダアはばりばり刺さりました。
本当、こんなゲームがしたかったんだよ。

そしてぼくがゲーム製作者としてすごくすごく勉強になった点があります。
それは、ひたすらバリバリし続けるだけの単調作業を続けるモチベーションを高めるための対戦システム。
こうすればよかったのか、と、目からうろこでした。

これについて説明する前に、ぼくが自分の過去作品でどんな課題を抱えていたかを詳しく書かせてください。
それは同じウディコン出品作、ぼら猫パズルでのこと。
ぼくはぼら猫パズルのパズルシステムにはすごく自信がありました。
すごく楽しかったから。
当時のブログから引用してみる。

面白すぎるゲームシステムが完成してしまいました！
（中略）
このゲームの残念なところは、あまりに面白すぎてついついプレイをし続けてしまい制作がちっとも進まないことです。


何このハイテンション。
で、ともかく面白い（自称）パズルができたのですが、そのパズルをプレイヤーに何度か（せめて面白さがわかってもらえるまででも）やり続けてもらうにはどうするかが課題となったわけです。一回のパズルはすぐ終わる。それを繰り返したくなる仕組みをどう作るか。
だって何回やっても全く同じゲーム作業ですもんね。同じことを何度もしても飽きさせない方法とは・・・。

・・・ぼくには思いつきませんでした。
そこで苦肉の策としてパズルを数回クリアするごとにシナリオを表示し、話の先を読みたければ何度もパズルをクリアしないといけないようにしました。
これはどう考えてもよくない方法です。
パズルと文章を読み進めるということは、うまく嚙み合っていない。
文章を読みたいなら、ワンクリックで読めるのが理想で、少しでも早く読みたい場合にはパズルは障害でしかないです。
でもぼくにはあれが限界でした。
プレイヤーがパズル完了後に残せるのは本質的にはスコアのみです。点数の大小が得られるのみです。
その点数の大小を得ることを楽しいと思わせる方法ははたしてあったのか。
それが、あったのです。
すなわちバリバリダアで採用されている対戦システムを導入すればよかったのです。

ぷよぷよだったか何か、市販のゲームでも敵と対戦する仕組みのゲームをしたことはありました。
また同じウディコン作品でいうと秋月ねこ柳さんのすやりす絵巻にも敵という概念がありました。
でもぶっちゃけプレイヤーは対戦相手なんて気にしてませんよね。
だって自分のプレイで必死だから、欄外で「敵」が何をしていようが、自分は自分のすべきことに集中するのみ！ですもん。
でもバリバリダアはその点すごい。
敵は、いるのだけれど、システム的な意味では目標スコアを提示するためだけに存在しているのです。
仕組みとしては「○○点を越えよう、そうしたらこのステージクリア！」と、文章表示しているのと同じです。
たったそれだけです。
それなのに、それなのに。
そこに敵キャラがいて、個性的なグラフィック、特徴的なキャラづけ（設定）、会話文といった演出によって、「この点数をクリアして敵を倒す！」というモチベーションが強烈に湧くのです。
ああ、ボラ猫も次々に現れる強敵とスコアを競わせればよかったのです。（それはもはやボランティアする猫ではなくなっていますが）
バリバリダアでぼくはそのことにはっきりと気付きました。

なお、バリバリダアは難易度設定もぼくにとっては絶妙で、それも楽しめた一つの要因でした。
何度も練習して熟達して、そしてすごい集中できて、なおかつ運にも恵まれたときに、ぎりぎりやっと最後の敵を倒せる、という難易度で、それは本当に楽しい体験でした。
作者さんは集団製作チームだそうですが、素直にすごいと思います。
そして単調作業にモチベーションをもたらす方法を教えてくれて感謝！
今度単調作業のゲームを作る時には絶対に対戦相手を出す！と心中深く決めました。

昨年のウディコンに出された扉は君の鍵で開くですが、その解答編あるいは解説付きのバージョンが作られることになり、前作は同心円、今作は離心円という副題がつくこととなりました。
そしてその離心円が今日公開されました！

ほぼ一年かけて作ってくれたNANさんお疲れさまでした。
前作を楽しめた人なら絶対楽しめると思います。
そして作者のNANさんの成し遂げたことにびっくりするんじゃないかな。（ぼくはした）
前作をが公開された時にもう、全ての設定や裏事情はNANさんの頭の中では完成していたんですね。
プレイした人はその表面しか見えていなかったけど。
主人公のちょっとした言動の裏にもちゃんと深い理由があったんだ。一年前から。
あーすごい。
こんなゲーム見たことがないです。こんな公開のされ方も。
まあゲームじゃないといえるかもしれないけど、でもやっぱりゲームです。
この作品に関わらせてもらえたことを光栄に思います。

同心円を未プレイの方は、まずはそっちからした方が推理や試行錯誤を楽しめるかもしれません。

7年位前に公開したオーラをまとう主人公演出コモンについてお問い合わせをいただき、改造の対応をさせてもらいました。
あのコモンは鏡コモンに比べたら反響は皆無だったけど、絶対需要があるとおもってたんだー。本当うれしい！
ピクチャ表示じゃないとできないこともあるし、主人公の瞬間瞬間の歩行グラ画像を表示させたいってことってきっとあるもんね。

今回はオーラをつけるキャラを主人公からマップイベントに。
素材の形式を8方向から４方向に変換。
という２点の改造をしました。

最新のウディタ、変数操作+でマップイベントの情報をいろいろ取得できるようになってる気がする・・・。
前からできたかな？たしかできなかったんじゃなかったかな。
いつも本当にありがとうございます煙狼さん。

鏡コモンだとソフトニシンさんが作ってくれたいろんな素材や規格に対応したのがもう既にあるんだけど。
主人公演出コモンは鏡像じゃないのでそれは使えないから、新たに画像のパターン数を求める数値「鏡像変換定数」（鏡像じゃないけど）を計算し直しました。
かなり難しかったけど、何とかなりました。
あらためて鏡コモンの中身をじっくり見てみて、この仕組みを思いついた自分って天才！とつくづく感心。
コモンのご相談はメールで受け付けます。時間があれば対応します。


余談だけどそのやり取りの中で気づいたのですが、gmailは「.common」形式のファイルをウイルスの可能性があるとして受け付けてくれないんですね。
怪しくないのにー！
アップローダーに上げるとかで対応するしかないようです。

日本の刑法では１３歳未満の性行為が禁止されているそうです。
それについて立憲民主党が「合意のある性行為の禁止年齢引き上げ」を検討していた中で、本多平直衆議院議員が「５０歳近くの自分が１４歳の子と性交したら、たとえ同意があっても捕まることになる。それはおかしい」と発言して話題となり、党から厳重注意を受けたそうです。
議員の発言がネットからバッシングされたことをを受け、党が「これは党の見解でない、本田個人の考えで、問題だ」との姿勢を示したのでしょう。

すごーく違和感を感じました。
本田議員の発言を責めちゃいけないとぼくは思います。
国会議員が自分の意見を表明して個人攻撃され撤回・謝罪させられるなんて、だめです。
議論をするための議員でしょう。
多様な国民を代表する議員でしょう。
どんな少数派の主張をする議員だって、議論を実りあるものにするためには必要です。
暗黙のルールがもう決まっているのなら、議員も議会もいらないじゃないですか。
１３歳以上でも性行為がダメというルールはいつの間にできていたのでしょうか。

ぼくは性行為の禁止年齢引き上げ自体には賛成です。
けれどもそう思わない人は非難されて当然という風潮は、言論を委縮させるし、勘弁してほしいなと思ってます。



…と書いてみましたが、ぼくの本音は「空気読めない人は非難されて当然という社会なんて、空気読めないぼくには困るー！」ということなのです。ほんとに。本多議員の災難が人ごとに思えない…。

仕事で表計算ソフトのExcel2013を使っているのですが、今日はぼくが今まで毎月繰り返してきた作業の効率化に大成功しました。その記録を残します。
ある一定形式の書類を複数枚、日付欄だけ変えて一枚ずつ印刷する方法です。

毎日一枚ずつ使う書類ってないですか？「今日の報告書」とか。日報っていうのか。
そこには必ず日付欄がありますよね。
ぼくは今まで日付は空欄にして手書きで記入していました。
一か月分３０枚を書くのに、毎月5分以上かかってたかな。よく間違えたりするし。
それを簡単にできるようになりました。
最初に作るのは少しだけ手間ですが、一度作ったら毎月作業がとても簡単になります。

一日分の書類が１ページに収まっているという前提で説明しますね。
まず日付欄にしたいセルを選択して、右クリックします。
「セルの書式設定」を選びます。
「日付」を選んで種類の中から好きな表示形式を選びます。
（曜日も入れたい時などは選択肢の中にはないので「ユーザー定義」を選んで設定します。詳しくは検索！）
これで、そのセルに5/30と入力したら自動で5月30日と表示されるようになりました。

そしてそのページ全体をコピーします。
それをその下、2ページ目に貼り付けます。
行や列の幅が初期値のまま触ってないならそのまま貼るだけでいいです。

でも列も幅もいじっている場合はちょっとした工夫がいります。
コピーするときに行番号欄を一ページ分選択します。
そして貼り付けるときに「形式を選択して貼り付け」を選び「元の列幅を保持」にします。
すると行や列の幅や高さを同じにしたまま貼り付けることができます。

これで2ページ目ができました。
でも日付欄は１ページ目と同じです。
なのでこれを自動で２日目を表示するように変えます。
日付欄を選択します。
小文字で「＝（イコール）」を入力し、続いて「１ページ目にある日付欄」をクリックし、続いて小文字で「+1」を入力し、Enterを押します。
そうすると自動で１ページ目の日付の次の日を表示します。

ここまでできたら今度は2ページ目をコピーして下に貼りつけます。
成功していたら3ページ目の日付欄は3日目になっているはずです。
後は必要なだけ下に貼り付けていきます。
一か月分などたくさんつなげるときは、貼り付けの終わった複数枚をコピーして貼れば早いです。
（１ページ貼った後は2ページ、次は４ページ、8ページというように）
ただその時ワークシートの一番上にある１ページ目はコピーしないようにしてください。
そこだけは日付欄の値が固定されているので。+1にしたページをコピーしてください。

毎月1回、一か月分印刷するとしたら、31ページ目まで作ってください。
１ページ目の日付欄に１日と入力しただけで、全ページ印刷することで３１日分を１クリックで印刷できます。
印刷するときに何ページ目から何ページ目までするのか指定すれば、必要な日付の範囲だけ印刷ができます。
今月は何日まである月かなんて考えなくてもよくなります。
1ページ目を1日にして31枚印刷すれば、その月が30日しかない場合には、最後の一枚は自動で翌月1日になります。
入力時に年（２０２１とか）まで入れていれば、うるう年さえ気にしないでよくなります。

毎回一番上の日付欄だけは入力してくださいね。それ以下は全自動です。
これと同じようなやり方で、書類一枚づつ個別の通し番号なんかも簡単に印刷できるようになると思います。

作業をとても効率化できるこの方法、もっと早く気づきたかったー。
日付を毎月31枚手書きで記入している人はぜひともやってみてください！

ウディタでカステラを二等分するゲームのシステムを作りました。
画面上に表示されたカステラをちょうど等分する位置でクリックできたら成功、というものです。



ゴボリーンさんという方の＜サークル活動＞というゲームが無料公開されているのですが、それに触発されたのが製作のきっかけです。
サークル活動は円を作るゲームです。
とても楽しくてぼくはずいぶん遊ばせてもらいました。
これをもっと劣化させて、長方形を二等分するだけでも楽しいんじゃないか、という発想を形にしたのがこのシステムです。
はたして楽しいのかな？
楽しくないのかな？
まあやってみないとわかんないということで、ウディタで作ってみました。
マウスを使ったゲームを作るのは初めてで、いろいろ手探りでちょっと大変でした。
でも何とか形にはなりました。

で、やってみて、楽しかった・・・のかな？
まあ、・・・それなりに楽しそうです。
楽しいような気もします。

ゲームの面白さって何でしょうね。
ぼくはゲームシステム以外はあまりうまく作れませんが、その一方で、ぼくがゲームに求める楽しさは大半が物語性や演出によるところが大きいと思います。
でもやはりコアになるゲームシステムの面白さって必要ですもんね。
まあそれでもゲームシステムで多少でも面白いかもと思えたなら、後は演出次第で大化けするのかもしれないなあ。

だれかゲームデザインしてくれませんかー？
二人の弟のためにカットするお兄ちゃんの話とかね。

職場で医療費のお知らせをもらいました。
健康保険に入っているので、一年間にどれだけ医者にかかったかが書かれた書類です。
ぼくは3割負担なのでそれだけの現金を支払ったけど、残りは健康保険から払われたよ、という内容が載っていました。

そしてそれをわざわざ知らせてくれる目的は「健康保険に関心を持ってもらうため」だそうです。
まあぶっちゃけ「これだけ払ってあげてるんだから、健康保険料を文句言わず払ってよ」と言いたいのでしょうね。

それはちょっと恩着せがましいなーと思いました。
健康保険はこれだけあなたの役に立ちましたよって、それだけ言ってくるのは片手落ちじゃないかな。
こっちが払った保険料にも言及してくれないと。
保険加入者は別に保険制度の敵じゃないんだから、情報をフェアに伝えてほしい。

通知をくれるのなら
・被保険者が年間に支払った保険料
・保険が支払ってくれた七割の医療費
・その差額が個人にとってもしマイナスなら、それを支払うことの意義
・その差額がプラスなら、健康に生きることは遠慮しないでいい当然の権利ってことと、それを支える保険制度のすばらしさ
なんかを書いてくれたらいいです。
あ、職場も保険料を払ってくれてるのかな？そしたらその額も書いてくれてもいいけど。

ぼくもまだ老人ではなく、しっかり働いている割にはほとんど病院に行ってません。
なのでおそらく上記の差し引きはかなりマイナスになると思います。
でも、それを損しただなんてなんて思わないから！
ぼくの払った保険金は、収入の少ない老人や貧困家庭、未来の子供のために有効に使ってくれるんでしょ？
そう言ってくれたならちゃんと信じるから。
だから、こそこそしないで、こんだけとりました、そしてこんだけ出しました、って言ってほしい。
正々堂々と胸張って通知してくれたらいいんです。

七割払わずに済んだメリットばかりアピールして毎月の手取り給与を減らしている点に触れないのは、ちょっと姑息かなと思って、そんな態度だと健康保険のイメージダウンにつながるんじゃないかと思ったのでした。

みなさん、じめじめした日は息苦しい、なんてことはないでしょうか？
ぼくはないです。

けれども。
高校の科学でぼくはこう習いました。
「気体の種類によらず、同じ温度・同じ圧力において、同じ体積の気体の中には同じ数の分子が含まれる」
これをアボガドロの法則というそうです。

だとするならば。
空気中に水分子が多い時は、その分だけ酸素分子は少なくなるはずです。
つまり空気が湿っているときは人間が呼吸しても取り入れることができる酸素の量は少ないはず。

仮にそうなら、例えば天気予報では「明日は湿度が高いので深呼吸を意識して酸素不足を防ぎましょう」とか言うはずですよね。
でもそんなのは聞いたことがないです。
理論的には空気中の酸素量には湿度が影響するはずなのに。
でも世の中を見渡してもそんな言説は聞いたことがない。
湿度が高い日には呼吸困難の人が増えるとかも見たことがない。

この矛盾はどう説明できるのか。
謎です。
ぼくの想像ですが。
ひょっとしたら、吸気（口やのどから吸った空気）は、肺に達するまでにほぼ湿度100パーセント以上になっているんじゃないかな。
口や気管を経る間に水分がどんどん吸気にまざっていって、それで乾いた空気も十分潤ってしまうのかもしれない。
だとすれば、空気が乾いていても湿っていても、肺に到達した時の酸素量に差はないのかもしれない。
詳しい方がいたら教えてください。

令和三年の元旦です。
あけましておめでとうございます。
新しい年を迎えたことだし、心機一転、ウディタについていろいろ書いてきたこのブログですが、今後はそれ以外のことも書いていこうと思います。
ウディタもやめるわけではないですが、なんせ最近はほとんど触らなくなっているので。
これからもよろしくお願いします。

今さらですが、ウディコンにて「扉は君の鍵で開く」は総合４位をいただきました。
遊んでくれた方、評価してくれた方、皆さんありがとうございました！

ＮＡＮさんより投票コメントも見せてもらいました。
それで多くの方に楽しんでもらえたのだと知り、とても嬉しかったです。
また多くの改善点の指摘やアドバイスをいただいてすごく参考になり、考えさせられることも多かったです。

結果発表前からいろいろな反応をいただきましたが、例えば「質問する単語を頻繁に切り替える必要があるのでもっと簡単に選択画面へアクセスしたい」というご指摘も見かけました。
簡単に質問単語を切り替えられるシステムを作るとプレイが快適になる反面、謎解きのための総当たりがしやすくなってしまうんじゃないかという懸念があったんです。
極端な話、全部のキャラの前で全部の登録単語を順番に聞いていけば何も推理しなくても正解にたどりつけてしまいます。
それはできればやめてほしいというのがＮＡＮさんの希望で、ぼくもそうでした。
でもよくよく考えると、ゲーム内では深い推理が必要な場面でなくても頻繁に質問単語を切り替えないといけない所もありました。
プレイした人は思いつくかもしれませんが、例えばうわさの出どころを調べるために人名をたどる時なんかがそうです。
あー、きっとこれを面倒に思った人もいたんだろなー、そりゃそうだなー、と思い、質問変更を簡単にできるように機能を追加してみました。
そしてＮＡＮさんも採用してくれました。Ｖｅｒ１．１１以降では、ゲーム中でＣキーを押すだけで質問単語が切り替わります。
簡単に切り替わるからって、プレイする皆さんはできればしっかり考えてから質問してくださいね。その方が真実にたどり着いた時の喜びが大きいので！

（ちょっと制作者向けの話を。興味ない人はとばして下さい。Ｃキーで質問変更するキー入力監視はサンプルゲームのメニュー起動をそのままコピペして使っています。監視するキーをＣキーに変え、呼び出すコモンを変えただけです。また質問するためのシフトキー監視にも同じものを使っています。すごく簡単。そしてめっちゃ有能！SmokingWOLFさんはコモンにこう書いてくれてます。
▼ メニュー起動の際、
▼ 「イベント中はメニューが起動しないようにする」
▼ 「マスとマスの間を移動中は、メニューの表示を待つ（一定時間が過ぎたら入力キャンセル）」
▼ 「メニューを開いたときは次の一歩を歩き出さないようにする」
▼ など、安全性と便利さを向上させるための工夫がなされています。
この安全設計のおかげで、例えばメニューを開いてる途中にＣキーで質問を変えちゃったりすることがないようになってます。大助かり！）



「難易度と不親切さを間違えているのでは？！と思う部分があった」というコメントもいただきました。
また「操作系統に統一性がない」というご意見もありました。これは刺さる・・・。
お菓子システムはＮＡＮさんの趣味だし、後半に出てくる「所有アイテムの使用」にしたって、ぼくはノータッチだしー。と、逃げたいところではあるんですが、でも確かに言われてみると非常にごもっともな指摘だし、何よりテストプレイを繰り返してもその違和感に気づけなかったことを反省しました。
だってプレイヤーはただでさえ謎の解明の過程で理不尽とも思えるストレスに直面したりするじゃないですか。詰まったり。
これはもうこのゲームの謎解きの宿命なのでＮＡＮさんもぼくも割り切ってます。大変申し訳ないけどがんばっていただくしかない。
でもだからといって、いやそれだからこそ、それ以外のユーザインターフェース、操作などの面ではストレスをなくすようにもっともっと考えなくちゃいけなかったなーと。

このゲームではどんなことができたかあげてみると。
キャンセルキーでメニューを開く。
持ち物から生徒手帳を見たりできる。
そして「持ち物」機能の中に進行上必須の「渡す」機能もある。
スマホから仲間を呼び出す。
質問キーで質問をする。
直近の追加機能で、Ｃキーで質問を変更する。
質問を変える方法はＣキーも入れたら４通りある。
校内で部室へ移動する方法も、徒歩、地図、メニュー項目の３通りある。
・・・たしかにまあ、とっちらかってるとは言えそう。
そしてそれがわかりにくさ、面倒さ、とっつきにくさにもつながったかもしれない。

これらを統一しようとしたらどうすればよかったのか。
全部メニュー項目にして並べて表示するという手もあったかもしれない。
３×３の９マスだったメニュー項目を１２マスくらいに増やして「渡す」「アイテム使用」「アイテム見る」とかにしたらよかったのかな。
そうしたら「お菓子を渡せるなんて気づかず何時間も詰まった」とか「アイテムは使うべき場所では自動で使えるかと思って詰まった」という事態（実際いただいたご指摘）は防げたかもしれない。
でも１２項目のメニューって、それが出ただけでもう敷居が高いというか、気軽にプレイできなくなりますよね。

あるいは全部の機能をキーボードからのショートカットキーで起動させれたらどうかな。
（ウィンドウズ専用というウディタの弱点を逆に長所にする！）
それも覚えるのが面倒だったりとっつきにくさもあるけど。まあ慣れたら便利かもしれないけど。
でも戦闘もなくステータス数値もない歩くだけのアドベンチャーなのに、そんなにたくさんの操作が用意されたらそれもひくなー。
やっぱり気軽にプレイできなくなる。

そう思うえば、たとえ不親切でも、いろんな操作があちこちに散らばってて、ぱっと見ではとっつきやすい現状が結局正解なのか。
ゲーム開始直後には「メニュー起動とシフトでの質問だけ覚えてね！あとはフツーのＡＤＶだよ！」と言ったほうが、まあ面倒そうと思われる可能性は少ないかな。
間口を広げて多くの方にプレイを始めてもらって、追加の操作はゲーム内で覚えてもらって。
運悪く機能に気づけなかった人にはあきらめてもらうしかないのか。それしか正解がないのか。
ＮＡＮさんの野性的なカンで、結局ベストでなくてもベターな操作系統に落ち着いていたのか。
そんなこと書いたら、ゲームシステムの不親切さのために何時間も無駄に悩ませてしまった方々に怒られますよね。
本当に申し訳なく思ってます。すみませんでした。

いろいろ反省したり考えたりしました。今後次回作なんかがもしもあればこの経験が生きると思います。
多くの方のご意見に力や意欲をもらいました。
本当にありがとうございました。

ゲームの内容やストーリー、登場人物なんかについて、制作関係者としてではなくいちプレイヤーとして感想とかいろいろ書きたいんだけど、ネタバレはいけないし、ぐっと我慢してます。最後の方までプレイしてくれた方の多くもきっと同じ気持ちなんだろうな。

暗闇行燈のＮＡＮさんと制作していたウディタ製のゲーム、扉は君の鍵で開くが完成しました。
第１２回ウディコンに出品予定です。
質問することで謎を解いていくゲームです。

よろしくおねがいします。

過去関連記事　ＮＡＮさんのゲーム作りを手伝っています

はじめに

最近小学生にウディタを教える機会があり、変数について説明したところ、「その数字の中身は、ゲームをしてていつ変わるの？」と聞かれました。
これは鋭い質問です。
これをきっかけに、ウディタの基本以前の基本について考え直してみました。


処理ははいつ起きるのか

小学生の質問への答えですが、変数操作が実行されるのはそのイベントが実行された時です。
イベントはいつ実行されるのか、それは当たり前すぎて、ウディタを始めたころ、何とはなしにわかったようでわからなくて、無意識的には少し引っかかっていた部分です（それでも困ることはなかったけれど）。この機会に言語化してみましょう。
（ここで書くのは１フレーム内にあらゆる処理がどの順で行われるかという難しい話でなく、もっと基本的なこと、並列イベントや、変数によるイベント起動条件さえ考えない、しごく単純な話です。）

ウディタ製ゲームをプレイ中はいつでも必ず、次に何を起こすかのボールはプレイヤーか作者のどちらかが持っています。
作者がその瞬間にやらせたいこと全てが終わって何もなくなったら、プレイヤーの入力待ちになります。
フィールドを歩くなど、プレイヤーは作者が次に何かを起こそうとする事態になるまで（作者に許された範囲内で）自由に操作ができます。
次にどういう場合にイベント（マップイベントかコモンイベント）を起動させるかはゲーム作者が指定します。

イベントが起動すると、イベント内に記入されたコマンドは上から順番に処理を進めていきます。
処理の流れに対して指定がない限り、一番下まで処理が終わって次にやることが残ってなければ、またプレイヤーが自由に操作する番が来ます。
（文章表示のキー入力待ちも広い意味では同じです）

こういったことは完全初期データからさわり始めた方には当たり前かもしれませんが、サンプルゲーム改造から入ったぼくには、はっきり理解できるまでに時間がかかりました。
常時並列のコモンが背後で動いていたためかもしれません。


全ての処理は上書き


ウディタで行われるコマンドの処理は、常に上書きです。
変数操作を例にしましょう。
Ｖ０＝１（通常変数０番の中身は１という数値）
Ｖ０＝２（通常変数０番の中身は２という数値）
という処理が二つ順に並んでいた場合、Ｖ０は一瞬は１になりますがその直後に２になります。
その２になった時に、前までの１はどこに行ったのかなどと考える必要はありません。
変数操作で使う「＝」（イコール）とは等号でなく、左辺の変数などに右辺の数値などを上書きするという意味です。
（そもそも等号なら、１だったものがイコール２だとか成りたちません）

処理が上書きということは変数操作以外にも当てはまり、絵を表示した後に消したら消えるし、音楽をかけた後に消したら途中でも消えます。
通常の生活ではそういう場面が少ないのかもしれませんね。
リンゴが入っていた箱の中身をミカンに変えようとしたら、ミカンをどこからか用意しないといけないし、不要になったリンゴをどうするかも考えないといけない。
１と言ってた値を今からは２に変えるといきなり言ったら「そんな急に言われても」とか「一貫性がない」と叱られるかもしれない。
この点ウディタは（おそらくプログラム全般はそうでしょうがぼくは知らない）、作者の意図が全てです。何に気兼ねすることもなく、それまでの経緯もお構いなしに、やりたいように処理をできます。


変数とは何か

話のついでに、ウディタにおける変数とは何かをぼくなりにまとめておきますね。

変数とは、数字や文字を書き込むための、ノートのような場所のこと。
通常変数と言う名前のノートには、０ページから続く各ページそれぞれに、数字を１つだけ書き込める。
最初はどのページにも０が書かれています。
これは情報がないという意味でなく、０という情報を最初から入れてあるという意味。
書き込まれた数字はゲーム作者が好きな時に書きかえることができます。

何のために書きかえるのかといえば、それは後で参照してゲーム内の処理に反映させるためです。
後から利用することもないのに変数の中身を変えても何も意味はなく、何も起こりません。

入力欄には右に＋０という部分がありますが、これは触る必要もないし、気にする必要もないです。

そして作者が意図しないのにプレイヤーのプレイ中に変数の中身が変わるということは本来ありません。
変数はあなたのノートです。作者のあなたのためにあるもので、ゲーム作りの強い味方です。
変数につまずいてウディタを断念する方は多いですが何とか粘ってもらいたいと思います。

メールアドレスが変わります。

kukukusurimanopi@hotmail.com

になります。
連絡のある時はここへメールを送ってください。

このたび、今まで長い間使ってきたエキサイトメールという無料サービスが終了してしまうんです。
残念で不便でさみしいのですが、どうしようもありません。
新しいメールアドレスも無料のサービスを利用しています。
使いこなせるのか不安いっぱいですが、ともかくどこかに移るしかないのではじめてみました。

ぼくはツイッターもやっておらず、スカイプも使いこなせず、ましてやフェイスブックなどとは無縁の人間です。
なので今後もネット上の皆さんとのやりとりはメールを中心にすることになると思うので、よろしくおねがいします。
コモンなどのご相談などもここへお気軽にお願いします。

むかしむかし。
といってもそれほど大昔でなく。
今見てみたら３年ちょっと前のことでした。
ぼくは歩行グラフィックの枚数を増やすコモンを作ったんです。
詳細はコチラ

でも公開できる素材がなかったので、コモンも公開できませんでした。
ウディタの歩行グラは通常３枚か５枚です。
それをピクチャ表示を使うことで、自由に枚数を指定できるようにしました。

ぼくは当時ある方のゲーム作りを手伝っていたのですが、その方はグラフィックに強いこだわりのある方で、頼まれて歩行グラ枚数を増やせるようにしました。
その方の希望に添えるコモンが完成し、その方自作の歩行グラをなめらかに歩けるようにできました。
ところがその方は病気がちで、とうとう音信不通になってしまったのです。
何度か「預かってる素材をお借りしてコモンを公開したらだめですか」と問い合わせるもお返事はなく。
ぼくは上記のリンクの自ブログで歩行グラ枚数を増やすのに成功したということだけ書いて、コモンは公開できないままに３年以上が過ぎたのです。

その間にもメールで何件かの問い合わせがありました。
そんな時はぼくはできる限り協力させてもらったのですが、やはりこのコモンには一定の需要があるのだと確信し、ぜひいつか公開したいという思いを持ち続けていたのです。

そしてこの度またeDaさんとおっしゃるドット職人さんから問い合わせをいただき、ご協力させてもらったところ、コモン用の素材の同梱配布を許可してもらうことができました。そこでついにコモン公開が実現することとなったのです。
ずっと念願だったのでとても嬉しいです。昨晩公式コモン集に「歩行グラフィック枚数を増やす」という名前でアップさせてもらいました。
今後多くの方に使ってもらえればと思います。

詳しいことはコモン同梱の説明書に書いたので、ここに再掲しておきます。
eDaさんありがとうございます！

---------------------------------------------------------------------------------------------------------------

歩行グラフィック枚数を増やすコモン　Ｖｅｒ１．００

　　　　　　　　　　　　　　　　　２０１８年８月２０日公開
コモンの場所を１つ使います。
ウディタ Ｖｅｒ２.２４に対応しています。
全画面サイズに対応していると思いますが３２０×２４０以外は未確認です。


＜このコモンでできること＞
ウディタでは歩行グラフィックは３枚か５枚しか選べません。
でもこのコモンを使って枚数を増やせます。
また通常、歩行中のグラフィックの表示順は１２３２１２３２・・と循環します。
このコモンでは１２３４５１２３４５・・と表示できます。
（例：歩行を横から見た場合、前に右足が出ている時と左足が出ている時を描き分けられます）

ただし、パーティーメンバーには対応していません。
一人分の画像のみ、先頭メンバー位置に表示します。


＜コモンの使い方＞
サンプル素材を使って画像を増やす方法を書きます。
（独自の歩行グラを使いたい時は、フォルダ内の画像を同名で上書きしてください）
１、コモンをどこにでも読み込んでください。
２、dataフォルダ内に同梱したdotフォルダを置いてください。
以上です。


＜素材の決まり＞
このコモンを改造せずに使う時は、素材は以下のルールで用意してください。
複数のパターンの画像は連結できません。
名前は静止時は、左向きなら4 上8　右6　下2　（半角数字）
移動中は左向きの１枚目なら4−１、２枚目なら4−２などにしてください。
パターン数はいくらでも増やして大丈夫です。
（多い場合、全部表示されるにはキャラが長い距離を直進する必要があります）
全ての画像サイズは同じサイズに統一してください。
斜め方向のグラフィック表示には未対応です。

＜ピクチャ表示の注意点＞
歩行グラフィックの表示にはピクチャを使用しています。
画面暗転でも消えない、エフェクトが無効、ピクチャ番号によって表示される層が異なるなどの点に注意してください。

＜おまけ機能：斜め移動時の表示画像の切り替え方＞
ゲーム設定から「キャラクター画像方向のタイプ」を設定することで、
４方向にすると斜め移動時には上下向きの画像を、
８方向にすると斜め移動時には左右向きの画像を、表示します。



＜同梱素材について＞
作者：eDaさん　（ツイッターアカウント@eDadoT553）
eDaさんのご協力のかげで、このコモンの公開が実現しました。
この場を借りて心よりお礼申し上げます。

・この素材はゲームに使用・公開していただけます。
・その際、作者名明記などの必要はありません。
・ただし作者名を偽ることや二次配布はご遠慮ください。

--------------------------------------------------------------------------
（説明書ここまで）

コモンのデフォルトでは、素材の向きは４方向、使用パターン数は８枚です。
これは改造で変えれます。難しい方はご相談ください。

まあ技術面をざっくりいうと、要は、「今の瞬間は何枚目の歩行グラを表示すべき時間帯か？」を把握することができたのです。
それによって使用ピクチャを特定できます。
（使用画像は今回はバラバラ。もちろん改造すれば連結した素材もパターン番号指定で使えます）
表示位置は鏡コモンなどで培った主人公表示コモンなどのやり方で座標が分かるし。
それを使って、主人公の位置に主人公の画像を表示しただけのことです。
ウディタの限界をまた一つ拡張できたような達成感はありますが、やっていることは鏡コモンよりも単純かもしれません。
ピクチャ表示なので、全くの初心者の方には戸惑う部分はあるかもしれないですが、まあ何とかしてください。

ごぶさたしています。
ＮＡＮさんといえば「落葉の大地を走れ」という作品で有名な方です。
「落葉の大地を走れ」はツクール２００３製なんですがバグが多くて非常に悩まれたんですよね。
（まあバグの全部がツクールのせいというわけではないでしょうが）
そこでＮＡＮさんもとうとうウディタに移ってくるということになって、以前ぼくと一緒にyou are my heroという作品を作りました。
ぼくは戦闘などを担当したんですが。
まあそんなわけで、ＮＡＮさんもウディタに慣れて、いよいよ次は本格的に腰を据えて、大作を作りはじめたわけです。
もちろんウディタで、です。
時代は現代。舞台は高校です。学園ものなのです。

その作品のお手伝いを前からさせてもらっています。
システムを作っています。というか、作りました。
「落葉の大地を走れ」で特徴的だった質問システム（プレイした方は分かるでしょうが）、あの仕組みをウディタで作りました。
ＮＡＮさんのブログでも小出しに紹介してもらっているので、そちらもご覧ください。
「落葉の大地を走れ」では質問単語を登録して町の人に質問すると、いろいろ答えてくれるんですけども。
それをどうやって作ったのかなーと、プレイ当時から興味はありました。
お聞きしてみたら、なんと、ウディタでいうところの条件分岐をいっぱいいっぱいつなげたみたいなんですね。
質問単語が○○なら以下の〜〜を実行、というのを下に下にひたすら入力していたみたいです。
どれだけ大変な作業だったか、想像もできません。
「落葉の大地を走れ」でいろいろ質問に答えてもらえる陰には、作者さんの大変な手間があったんです。

で、ウディタではＤＢを使って管理できるようにしました。
キャラごとに、何を聞かれたらどう答える、というのを一覧表に入力できるようにしました。
ＤＢは１行しか表示できないとか、見にくさの点では条件分岐を下に下につなげるのと五十歩百歩かもしれませんが。
それでもまあなんとかＮＡＮさんの求めるものを作ることができたみたいで、一安心です。
もっとも作ったのはしばらく前なので、もし改良を頼まれてももう忘れてるんじゃないかと不安なのです。
最近試しに中を見てみたら、なぜそうなっているのか理解できない部分がありました。自分で作ったのに！
まあ動いているならいいのです。今後サポートを頼まれないことを祈るのみです。

ちなみに何をやったか書いておくと。
質問用キー（シフト）の入力を監視して。
押されたら主人公の向いてる方の隣マスにマップイベントがあるかを判定して。
そのイベントに画像が設定されているかどうかでそれが人間かどうか判定して。
人間ならＤＢにあるそのキャラの反応する質問単語を調べて。
現在の質問に設定している文字列と一致するものがあったらＤＢに書いてある文章表示などをする。
そんな感じです。

それに加えて、文章表示以外もできるようにしたり。
パーティーメンバーに応じて反応を分岐させるようにしたり。
質問に使う類義語を登録しておき、同じ単語とみなすシステムとか。
質問単語を記録する仕組みやら。
会話中に出てきた単語を自動で登録する仕組みを作ったりしました。

あ、その、単語の自動登録の方法は独創的かもしれないので書いておきます。
文章表示中に出てくる単語を登録させたい時、その単語の前後を\c[0]で囲みます。
これは本来は「文字の色をデフォルトの色に変更する」ために使う特殊文字なんですけれども。
でも普通の色で文章表示している分には何の意味もありません。
そして別の並列（常時）コモンを動かしておいて、表示文章中に\c[0]が出てきたらそれで囲まれた部分を（すでに登録済でなければ）登録する、そんな風にしています。
登録部分を識別するための文字は別に何でもよかったんですけれども。
入力しても表示されず、そして何の効果もない文字がそれしか思い浮かばなかったのでそれを使いました。

ＮＡＮさんの新作はまだ完成半ばということです。
前作「落葉の大地を走れ」もなんと８年がかりの大作だったので、今回もそれくらいのスケールの作品なのかもしれません。
前作の反響の大きさを考えると今作はどのように受け止めてもらえるのか、とても楽しみです。
グラフィック関係でお手伝いいただける方を探しているという話もあるので、我こそはという方はぜひぜひお願いします。
「落葉の大地を走れ」同様、裏設定などにもものすごいこだわりというか労力をかけていらっしゃるので、完成はまだまだ先ですがファンの方はのんびり激しく期待してもらったらいいと信じます。
どうぞお楽しみに！
というよりぼく自身がものすごい楽しみにしているのです。

忍者の出てくるゲームを作りはじめました。
ウディタからはちょっと離れていたのでひさしぶりです。

今日気づいたのですが
マップイベントが起動条件の変数を満たさないで歩行グラが表示されない時は
そのイベントは動作指定の移動を受け付けないみたいです。
まあ本来はRPGエディタなので
シンボルエンカウントの敵が消えている間に急接近したりしたら困る！
とかの理由でそんな仕様なのでしょうか。
ともかくぼくは消えている間に動かしたいのです。
なんてったって忍者ですからね。忍んでなんぼです。にんにん。

というわけで、試行錯誤してます。
画像があればいいんでしょ、と思って、透過色のみの画像素材を歩行グラに指定したらいいのかと最初思いました。
でも素材の用意が面倒だったので、歩行グラに不透明度を設定できたことを思い出しました。
移動中だけ別ページで透明人間にしたらいいんやん！
さすがぼく、ウディタのカンは衰えてない！

でもやってみたら動かない。歩行グラを切り替えたら動かない。
同じ歩行グラ素材のままなら動くのに。
動作完了までウェイトにして、その後にグラを切り替えてるのに。
悩みます。どういうこと？

まあ最悪、バックを一色にして、消したい時だけ同色のピクチャをかぶせるという手もあるけど。
できればそんな荒業は使いたくないなーと考えてるのです。

ツクールＶＸ　ＡＣＥの英語版に当たるソフトが無料との情報を得て、ＤＬしてやってみました。
ツクールを触るのはほとんど初めてです。
英語なのでよくわからないけど、とりあえずマップ上に地形を配置すること、イベントを設置してしゃべらせることができました。
ちゃんと日本語の文章を表示できましたよ。
こんなに何もわからない自分でも一瞬でそれだけできるって、なんだかウディタより簡単そうです。
歩行グラや顔グラの選択が直感的にできます。
まあツクールは素材の権利関係がややこしいと聞くので、英語を十分理解できないぼくは、仮にゲームができたとしても怖くて公開できない気がします。
でも視野をひろげれたらいいなと思います。

簡易アクションシステムというものを公式コモン集に公開しました。
これはdataファイルで、まっさらのウディタのdataファイルと差し替えて使います。
これを使うと横スクロールアクションゲームが簡単にできるかもしれません。
アクションのシステムは今までも公式コモン集にはあったのですが、イベント設置の設定が自分にはややこしかったので簡単なものを作りました。
接触起動のイベントなどは、通常のマップと同じように直感的に設置できます。
決定キーでジャンプし、キャンセルキーでメニューを開きます。
敵に接触したら、接触した時の処理を敵のマップイベントに入れて実行させてもいいです。
ジャンプの動きはあまりなめらかではないですが、導入が簡単なので初心者の方に向いているかもしれません。

昔本当に面白かったファミリーコンピューターのソフト「スーパーマリオブラザーズ」への敬意をこめてこのシステムを作りました。

何かをるつくる技術よりも、それをつくりたいと着想できることが大事、と思ったんです。
ウディタのコモン作りについて。
もちろんつくりたいものができた時にそれをつくることができなかったら始まらないけど。

前回の記事で自分が今まで作ったコモンを振り返った時に、いいものができたと思えるのは鏡コモンと接近コモンです。
（公開コモンではないですが、ぼら猫パズルの「お片付け成功」判定システムも同じです。）
それらを「つくろう！」と思えたことが、とても幸せなことでした。
これからも「つくろう！」と思えることに出会えたらいいなと思います。

鏡コモンや接近コモンのように、シンプルでありながら、
「ウディタのデフォルト機能では簡単には実現できないけど、実現できたら汎用性が高く使える」
というものを作りたいです。

そういうものでリクエストがあったらぜひ教えてください。
コメント欄にお願いします。

今までいくつものウディタ用コモンイベントを作り、公式コモン集に公開してきました。
多くの人に利用してもらえているようでうれしい限りです。
その利用状況を反映しているかもしれないのが、各コモンに寄せられたコメント数です。
まあコメントせず利用する人も多いだろうし、コメントしても利用しない人もいるだろうけど。
そこで、公式コモン集で「じゃ。」と検索し、コメント数を見てみました。
（自分で自分のことを検索することをエゴサーチというそうですよ。）
これがその結果です。




じゃ。製作のコモン、コメント数ランキング！

第１位　鏡コモンセット
第２位　敵が追いかけてくるコモン
第３位　万能型用語辞典の改変版
第４位　キャラころりん
第５位　主人公の歩行グラ部分表示
・
・
・
という結果になっています。
うーん。いろいろ思う所があるので書いていきますね。

まずは鏡コモンセット。
これは何だかぼくの代表作のようになりました。
最近では今年のウディコンで最後に提出されて話題を集めた「ほたるのひかり」でも使ってもらいました。
ツクールＶＸでできる鏡の表示がウディタでできないのが悔しくて当時としては頑張って作りました。
後になってソフトニシンさんが作ってくれた改良版の方が汎用性も高いと思うのですが、今でもこのシンプルな粗の多いコモンを使ってもらっているのはうれしいです。
パーティーを組む時などはソフトニシンさんのほうをどうぞ！

敵が追いかけてくるコモン。
これはある意味ちょっと中途半端化なコモンです。
ちゃんと追わせたいなら、最近作った「接近コモン」の方がおすすめかも。
追いかけの起動方法がちょっとややこしいのも難点です。
まあ説明をめんどくさがって、ＲｅａｄＭｅが読みにくいというのもあると思うし。
導入が分からなければ遠慮せずにメールで聞いてきてください。
ただ一点接近コモンと比較して、動作が重くならないというのが大きな利点です。
ホラーゲーなどでマップの形によってはこちらで十分対応できるんでしょうね。
まあこのコメント数２位という結果は、公開期間の長さもあるかも。
もし接近コモンと同時に公開したなら、接近コモンの方が反応をもらえていたかもしれないと思います。

万能型用語辞典の改変版。
これはうちのロングセラーですね。
元の用語辞典を作ってくれたシニスレッドさんありがとうございます。
やはり自由に書きこんだり表示したりできるものがパッケージとして用意されていると便利ですよね。
上級者だと自作できるから問題ないですが、初心者だって項目表示はしたい、でも万能ウィンドウは難しい！
そんな時に助かるコモンです。
ぼく自身も、自作ゲームのうち４つくらいで使いました。
なおこのコモンも非常に不親切な部分があります。
デフォルトで「協力者情報の一覧です」とか書いてあるけど。
これの変え方や消し方は多分どこにも書いてなかったんじゃないかな。
なんて不親切なんだ・・・。
ＤＬしたものの「協力者情報以外には使えないやん」と投げちゃった人もいそう。ごめんなさい。
表示を変えたい方、わからない方は、メールで（以下略）。

キャラころりんはですね。
特にどうといっていうことはないです・・・。
あ、名前がまぎらわしいかなと後で思ったのですが、ころりんと回転させるのじゃなくて、回転済みの画像を表示するだけのコモンです。
誤解させた方、もしいたらすいませんでした。
ちなみにこの「キャラころりん」と「敵が追いかけてくる・・」それに「おまけ解放・・」は、短時間に必死で作りました。今だから書きますが。
当時の状況は、いつまでウディタを触っていられるかわからなかったので。
残された時間で悔いのないようにがんばったら、自分でも驚くパフォーマンスが出せました。
やればできるってことだー。

主人公の歩行グラ部分表示・・・。
これがコメント数５位にランクインしているのは、まあ誤差のようなもんですね。
コメントのうち１つは自分で書いたものだし。
しかもこれ恥ずかしいことに、マップチップの通行設定でできるんですよね。
水中を歩く表現などは。
公開してだいぶ経ってから知りました。
まあ完全非表示も可能、分割位置も自由に指定可能ということで、ピクチャ表示になってしまう不便さを差し引いても使うメリットを感じてもらえたなら、ぜひ利用してください。

ではここからはランク外のコモンについて。
素材を用意すれば簡単にできるのに、ということに対してはやはり反応が薄いですね。
そりゃそうか。
描画についてやりたいことが明確にわかっている場合、素材を用意したらできるということははっきりわかるけど、得体のしれないコモンを使ってみようとはなかなか思わないですよね。
でも、自分でいうのはなんだけど（誰も言ってくれないから自分で言うけど）、主人公演出セットはもっともっと評価されるべきだと思っています。
セットにしたから演出用と勘違いされたのかな。
この中に入れてある歩行グラをピクチャ表示させる仕組みは非常に可能性を持っています。
鏡コモンもこれの応用だし、またこれをつかえば歩行アニメの枚数を変えることもできます。
確かに改造できない人には使いにくいと思いますが、ぜひいろいろ使ってほしいです。
いや、まああまり使ってもらえないのはまあそうだろうと思うんですけどランキング最下位はちょっとさみしいかなって。自分の中の最高到達点と思っているので。

そんなわけで、これからもよろしくー！

前の記事に書いた通り、接近コモンは改造の余地が多いです。

起動条件判定を移動コモン内に移せば、処理が軽くなります。

距離未判定時に入れる数値を９９よりずっと多くしたら、もっともっと判定できるようになります。
（調べたところ、敵は主人公から７５０マス離れても移動方向を正確に読み取り接近しました。
その際の敵が移動する頻度は、７８１フレームに一回でした。）

追いつかれた時の処理を別のコモンに入れておき、予約で呼び出せばもっとよくなりそうです。

同じく移動コモン内に条件分岐でSys変数「イベント実行中？」が１ならイベント中断、としたらよさそうです。

引数で別モードを設定して、マップIDと追う敵のイベントIDを送るようにしたら、同じ設定変更を複数のコモンでやってもらわないでよくなります。
コモン番号が確定していれば変数呼び出し値で変数入力ができるけど。
今回はコモンを入れる場所がどこでもいいいようにコモン名で呼び出すようにしているので。
各コモンでいちいちマップIDと追う敵のイベントIDを入れてもらうしかないと思ったけど。
それを引数で送れることに気づきました。
けれども引数に使えるコモンセルフ0〜4を無駄に使い倒していて途方に暮れました。
検索して全部別変数に割り振り直したけど。
今回の教訓。
引数を使う予定はなくても、やっぱりコモンセルフ0〜4は大事に使おう。


それ以外の改善点として、マップ遷移直後に前マップの情報にもとづいた方向へ移動する不具合もありました。それも直しました。

あと、使用コモン数も減らせるかも。
使用DB数はきっと減らせるはず。０か１かでしか使っていないんだから、片方は10の位を使うとかでいけるはず。


それら諸々を改善しました。
でもそうするとなぜか動かなくなりした。
そこで投げ出しました。
それが二晩続きました。
なので今、休憩中です。

成功したら明日にも更新するかもしれないし、あるいはずっとこのままかも。
不便を感じた人は、できるなら上に書いたことを参考にして対処してください。
できないならメールください。

コモンを作る時に、誰に向けて作るかをいつも考えます。
ぼくは初心者に向けて作りたいです。
基本システムを使わない方法もわからないような初心者にむけて。
だって人数も多いだろうし。
他人の作ったコモンを一番必要としている人たちだろうし。
ウディタで何ができるのかなー、の延長で触ってる人。

コモン単体の機能としては、接近コモンは十分完成していると思うんですけどね。
接近するんだから。
現状で、わかりやすいはずです！
（もちろんすごくわかりにくいけど！）

これに、ぼくはいろいろ付け加えようと思います。
イベント実行中は起動しないとか・・・。
なんだとか・・・。
上に書いた、いろいろ。

これは何をやっているのだ、どうなっているのだ、という人には、何のためにそれをしているのかが分かりにくくなってしまうと思う。
何のためにそれをしている？、ええ、それは初心者の使いやすさのためです。内容を理解しようとがんばってくれてるあなたのためじゃないんです。ごめんね。

本質だけがむき出しになったわかりやすいコモンより、使えるコモンを作ります。
ゴテゴテするけど。ごめんね。

でもそう言っておきながら、あきらめるかもしれないですけどね。
ｺﾞﾒﾝﾈ。

昨夜接近コモンが完成し、公開しました。

接近コモンについてはこちら


前からこのコモンを作るのに試行錯誤する過程を紹介していた記事の延長で、完成に至るまでのことを記録しておきます。

前の解説（？）記事を読むと、処理速度に悩んでいますね。
たしかにそうでした。そんな時期もありました。（遠い目）

でもそんなことは問題じゃなかったんですね。
それより根本的な過ちがあったのでした。
主人公がマップ上のある位置に行くと挙動がおかしくなる不具合があったんですが…。
それを解決しようと悩み続けたところ、驚くべき大失敗が明らかに！

ループ回数を数えていたコモンセルフ変数を、そのループ内で別のループの回数を数えるのにも使っていたのでした！
２か所で！同時に！別々の目的で！
一つの変数を使っていました…。
こりゃ不具合もでるわー。
というよりむしろ、それでも曲りなりには動いていたのが不思議なくらいですね。

ちなみにその変数につけていた名前は「一時変数１」。
こんな名前は気をつけないといけませんね。
「○○カウント用」とかちゃんとわけないとミスの元！

そういうわけで今回の教訓、
変数の使い分けを惜しむな！
ということを学びました。

で、その部分を修正したところ…。
処理が正確になったのはもちろんですが、驚いたのはとにかく処理速度が速い早い！

厳密に言えば、処理落ちしがちというのは今までと変わらないのですが、当面の問題であった更新頻度の遅さが解決しました。
それに正確に判定されるから気持ちいい！
通行不可マスは距離９９を入れて判定していますけど、敵との距離が９９以上になっても正確に判定されるみたいです。
これはいつか機会があれば通行不可判定の値を９９よりもっと大きくしないといけませんね。
（機会ってなんだよ！やる気ないやん！ってツッコミが聞こえてきそうな気がした）

あと今回知ったこと。
動作指定で「XYに接近させる」の座標には通常変数とかが使えるんですね。
以前何かの時に、コモンセルフを入れて使えなかったからやむなく数値を直接入れて、８方向の分、８通りに条件分岐させた気がします。
何でコモンセルフだけダメなのかな。
動作指定機能はもとはマップイベント用に作られたのかもしれないですね。
それでコモンセルフは受けつけないという名残りがのこっているのかも、と推測。
まあそんなわけで今回はキャラの移動先を指定するのに予備変数を使いました。


それから、接近コモンとマップイベントの関係についても書いておきましょう。
ウディタで取得できる通行判定には、マップイベント込みのものと地形のみの二通りありますよね。
最初は使用者の設定でどちらでも選べるようにしようと思いました。
でもマップイベントって、動くじゃないですか。
まあ動かさなくてもいいんですけどね。
街中とかをうろつくモブキャラをよけながら接近させるなら、その時点のモブキャラの位置を毎回更新し続けないといけない。
それをやってみましたけど、とても重くなったので導入はあきらめました。
だって追うキャラが地形を判定して接近してくるのって、プレイヤーに「あのキャラ、ボクがどこにいるのかわかって自分で進路を考えて進んできてる！」って思わせるためじゃないですか。
ちがう？
ホラーゲームであれが好まれるのは、超越的な知能を持っていることをあらわすからかもな、と今思いつきましたよ。
ゲーム内のモブキャラの動きなんてたいてい反復とかじっとしたままとかランダムじゃないですか。
それが状況にあわせて最適解を判断できるなんて、
常識を超えてる！⇒理解の及ばないキャラかも！⇒なんだかちょっと怖い！
みたいな感情を誘発することが期待されているのかもしれませんね。
何の話でしたっけ？
通行設定の判定でしたね。
その自分で地形を読み取って考えて進んできてるはずの敵が、目の前に人が立っているというだけで、よけて通るということを思いつかず、その人が立ち去るまでずっと待ち続ける…。
そんなのおかしいですよね。ありえない。
茶番だ。
せっかくプレイヤーに「こいつは知能を持っているのか？」と思わせかけたのに、「なんだやっぱりアホやん」と思われてしまう。
これじゃ接近コモンを使う意味は全くないですね。
プレイヤーを幻滅させ現実に引き戻してしまうくらいなら、むしろ下手な小細工は最初からやめたほうがいい。
歩行グラの位置なんて細かいことでプレイヤーに何らかの体験を与えようとするのでなく、別の方法を考えたほうがいい。
と、そこまでコモンを作った時に考えていたかどうかは覚えていませんけど。
（きっと今あとから思いついたのでしょう）
ともかくコモンの説明書には「動いて」「すり抜けない」マップイベントは置かないように誘導するような書き方をしておきました。
まあそれでもおきたい人は置くんでしょうけどね。
それはそれでいいです。

それから、コモンを公開するというのは使えるようにするということです。
いくら接近コモンとはいえ、接近しました、はいおしまい、では使えない。
追いついた時の処理を入れる方法と、コモンの起動条件を設定する方法を一応用意しました。
両方とも満足できるできばえではないんですけど…。

追いついた時の処理については並列だからヘンです。
ウディタ同梱のサンプルゲームに入れると夕一が接近してくるんですけどね。
追いつかれた時の処理をオンにしていると、ゲーム開始するとさっそく来るんです、夕一が。
ウルファールがくるっとまわって口上を述べてる間に夕一が到達し、ゲームオーバーとか表示させやがるのです。
これは…。
あ、そっか。
別のコモンに追いつかれた時の処理を入れて、接近コモン内の「追いつかれた時の処理」としてはコモンの予約をすればいいのか・・・。

まあそれ以前に、ウルファールがしゃべっている間にも夕一が接近し続けるというのが普通のゲームとしてはおかしいですよね。
これはどうしたらいいのかな？
動作指定で接近移動させている部分に、システム変数の「イベント実行中？」の分岐をかませればいいのかな。
何か違うような気もしますけど。

などとぼくはどうしてここにそんなことを書き連ねるのか。
ウディタ開いて触ったらすぐわかることで、改善できたらバージョンアップすればいいだけなんですけどね。
完成して公開して、製作から解放されたその解放感がウディタからぼくを遠ざけるのかもしれない。
ウディタもコモンも好きだけど登録作業は好きでないかも。緊張するし。
とか、そんなことはどうでもいいですね。

後書いておくことは、と。
ソフトニシンさんに教えてもらった「ルート検索」「最短経路探索」の二つのコモンを確認しました。
「ルート検索」の方は、導入を試みましたが、ReadMeをどう読んでもぼくには残念ながら理解できませんでした。
コモンやDBを入れるとか変数呼び出し値とか引数とか、それは分かるんだけど、じゃあどういう時に何をしたら何がどうなるのかわからず、ぼくには使えませんでした。
でも６年も前、おそらくそのようなシステムがまだ公開されてなかった（のかな？）時期に公開された意味は大きい、きっと素晴らしいコモンなのだろうと思いました。

もうひとつの「最短経路探索」は、これまた素晴らしかったです。
仕組みは全然わからないけど、ちゃんと敵が接近してきました！
でもこれ、完全初期状態から作られたシステムなんですね。
これを借りた人が自分のゲームにどう使えるか、ちょっとわかりません。
しかもこれは作者さんが今作っているゲームのシステムだというし…。
それならこれを借りて同じ仕組みのゲームを公開する（しかも作者さんより早く？）のはちょっとためらわれますよね。
まあいいんですが。

話はそれますが、ぼくは自分を自作システムを作れる人と思っているけど、完全初期状態をみると頭の中も真っ白になります。
基本システムって何だろう。
その中枢部分はやっぱり戦闘ですよね。
そんなもの使わないほうが作りたい戦闘をよっぽど簡単に作れるというのはよくわかるのですが。
ぼくの場合fairysongなんかはほとんど基本システムは使わなかったんじゃないかなあ。
でも使わないにしても、やっぱりコモンの上の方にダダーっと並んでいてくれないと不安です。
何がデフォルトで何が基本システムかを分けて考えていないからでしょうね。
歩行処理とか、基本システムなくてもできるんでしょう？
わかっているようで実の所なにかよくわかっていません。
基本システムをそのまま使ったゲームなんて今さら作らないよーと思ってますが、それでもぼくはれっきとした基本システム派なのでしょう。

話を戻しまして、ともかく結論としては、今回ぼくが接近コモンを作った意味は大いにあったと思いました。
難しいのが平気な方や古いバージョンのウディタを使う方は「ルート検索」。
システムを自作できる方は「最短経路探索」。
基本システムを使う初心者の方はぼくの「接近コモン」。
が、それぞれおすすめかもしれません。

まあぼくの偏見で言うと、接近コモンを使いたいのは、大体が初心者の方じゃないでしょうか。
それが悪いと言ってるんじゃないですよ。
ホラーで。追っかけさせたいっていうのは。
ゲームを何作か作って、どんなゲームを作ったらどんな反応がもらえるかわかってきた時に、それじゃあ、今度は追っかけられるゲームを作ろうか、とは、なかなか一般的にはそうはなりにくそうには思います。

ぼくとしては、追っかけるゲームを作りたいと思った人が「ウディタなら（接近コモンやその他のコモンを使って）追いかけが簡単にできるらしい！」と知ったことがきっかけでウディタにはまり込み、二作目以降に力作を作り、それをぼくが楽しく遊ばせてもらえたならばうれしいです。
あ、接近コモン作者として何か余計なことを書いちゃってるかなぁ？
まあいつものことだしいいか。

現在、接近コモンを導入したい方にはメールを使ったサポート強化キャンペーンを実施中ですので、追いかけさせたい方、導入が難しかった方はご連絡くださいね。

何だかいろいろなことを書きました。
この文章の乱れ具合を見ても、接近コモンがいかに難産だったかをお察しいただけるのではないでしょうか。
製作を終えたぼくをこんな風にしてしまう、そんなコモンでした。
それでは失礼いたします。

先日から作っていた接近コモンがついに完成し、公式コモン集に登録しました。
長かったー。
鏡コモンと同じくらいがんばったかも。
ぼら猫システムと同じくらい難しかったです。
でも作れば作るほど自分の技術が成長しているようで嬉しいです。

ところでソフトニシンさんよりコメントをもらい、衝撃の事実を知らされました。
接近させるコモンは、もうすでに公式コモン集にあったようです。
中はまだ見てないけど。
あると知ってたら作らなかったー！
でも知るのが遅れて、成長の機会と充実した時間をもらえたからよかったです。

力尽きたので、以下に説明書を貼り付けます。
おやすみなさい。
-------------------------------------------------------------------

接近コモン　Ver.1.00　　（２０１６年９月２８日公開）
　　　
--------------------------------------------------------------------

敵などを主人公に接近させるコモンです。
地形にひっかからず障害をよけ、最短距離を接近してきます。

おまけ機能として
・接近機能の起動条件設定
・追いつかれた時の処理（サンプルあり）
・各マスの情報表示機能（デバッグ用）
がついています。




＜使用条件・仕様＞
ゲーム設定での歩幅は１歩を推奨します。（半歩でも一応は使えます）
接近させる時のマップの広さは最大で１００×１００マス。
マップイベントの通行不可は判定しません。
予備変数３の０番、１番を使います。
可変DB４つ、コモン４つを使います。
全ての画面解像度に対応しています。
コモンとDBの名前は変えないでください。
その他細かいことは、ずっと下の方を見てください。



＜簡単な使い方＞
ウディタ同梱サンプルゲームへの導入方法を説明します。
可変DBのタイプ数の設定を４つ以上増やしてください。
できたスペースに４つのDBを読み込んでください。
コモンのあいている所に４つのコモンを読み込んでください。
ゲーム基本設定を開き、移動幅を１マスに変えてください。

サンプルゲームで夕一に追わせるだけなら設定は一切不要です。
細かい設定もできます。
その場合は各コモンを開き、チェックポイント間の数値を変えてください。



＜細かい設定＞
各コモンを開き、チェックポイント間の数値を変えて設定します。
青色のコモンを順に開き、接近コモンを起動したいマップのIDを「追われるマップ番号」に入れてください。
上二つのコモンには、接近させるキャラのイベントIDを「接近するEvの番号」に入れてください。

動作がもしもとても重ければ「全マスの〜」コモンの「重ければ小さく」を５００とかにしてみてください。
（作者の環境では、通常でも少しは重くなるようです）
キャラの移動方向を４方向に限定したいなら、「追うキャラ〜」コモンの「移動方向数」を４にしてください。

追いつかれた時の処理をコモン内に入れるなら、「追うキャラ〜」コモンの「追いつかれた〜」を１にしてください。
そしてコモン内の説明に従って処理を入れてください。
（サンプルでは文章表示、効果音、ピクチャ表示をさせてます。変数操作の他「タイトルに戻る」もおすすめです。）

このコモンは基本的にはその敵のいるマップに入った瞬間から敵は接近してきます。
もし途中から接近させたい場合は「全マスの〜」コモンの６９行目を参照してください。
そして「回数付きループ」を１回に変え、条件を設定してください。
サンプルでは１回にすると「通常変数が０以外になった時」に接近が起動します。
ただし起動条件を設定すると処理が重くなります。

敵の接近経路がどう判定されているか確認するために、DBにいれた各マスの距離などを表示できます。
むらさき色のコモンの起動条件を並列（常時）にしてご活用ください。判定の様子がよくわかります。
ただし表示するのは最低サイズのマップの情報のみです。
それ以上広いと、主人公が左上に行った時の画面の情報だけを表示します。つまりスクロールに非対応です。
このコモンのみは消しても大丈夫です。


＜上に書いた以外の細かい仕様＞
通行方向設定のあるマップチップ（がけのふちなど）を使うと正しく認識されないこともあります。
（マス自体は通行可能なため）
地形の変更など、通行不可マスの配置を同一マップ内で変更させると正しく認識されません。
処理軽量化のため、通行判定はそのマップに入った直後（２フレーム後）に一回だけ取得しています。
敵の移動は並列処理のため、文章表示中やメニューを開いている間にも接近してきます。
不都合があればお手数ですが各自で対処をお願いします。

このコモンで何が行われているかを正確に書いておきます。
主人公か敵のいずれかが移動するたびに、各マスが主人公から何歩目かを判定します。
つまり両者とも停止中は情報は更新されません。
敵は移動終了するたびに、距離が一番小さいマスに移動します。
８方向の中で距離が最短のマスが複数ある時はどちらを選ぶかはシステム内で決まっています。ランダムではないです。
斜め移動したい時にそのマスに至る左右いずれかが通行不可なら断念して４方向移動します。
距離の判定更新には時間がかかる場合があるので、距離０の地点に敵が到達してしまうことがあります。
その時は主人公との距離が遠くないことが想定されるので、今まで主人公が歩いてきた軌跡を参照し、それをなぞって接近します。
厳密に言えば、その際は最短ルートを通らないこともあります。
ただし一瞬で次回の判定更新が起こるので移動先はすぐに修正されます。



＜マップイベントについて＞
モブキャラにひっかからせないためには以下の方法をとるしかありません。
・そもそも置かない
・全部すり抜けオンにする
・移動させない（そして通行不可マスの上に置くか、下記の改造をする）

マップ内全てのモブキャラが移動しないなら、
「全マスの〜」コモンの４２行目を開き、
「通行可能（タイル・Ev両方）」に変更すればマップイベントも避けて接近できるようになります。
（移動するモブキャラの配置を常時読み取ることも試しましたが、処理が重く実用化できませんでした。）



＜コモン使用のコツ＞
通常の使用ではあまり問題ないでしょうが、もし何かあれば以下を参考にして下さい。

マップはできるだけ狭くすれば処理は軽いです。
マップ内に通行不可のマスが多い方が処理は安定します。
主人公がマップ端にいるよりマップ中央にいる時の方が少しだけ敵の移動が正確です。
主人公と敵の距離が離れると敵の移動頻度は下がります。
動作指定で敵の移動頻度を設定しても無効です。移動速度は有効です。
主人公の移動速度が敵よりずっと速い場合は距離が大きく開きやすく、ぼろがでやすいです。
（まあ多少は離れていないと正確に接近しているということが見えにくいでしょうが）



＜さいごに＞
このコモンは多くの人に使ってもらいたいので、導入をサポートしようと思います。
質問などがあれば、ぜひメールをお寄せください。
できるだけ対処します。（２０１６年９月現在）


---------------------------------------------------------------------------------

前回までの続きです。
今までは、大きく分けて二つの処理、
・全マスの主人公からの距離を判定
・それを使って追いかけるキャラの移動
この二つを一つのコモン内でやっていました。


ところがそれでは距離判定が終わるまでキャラは動けません。
距離判定には短くても2秒くらいはかかります。
休み休み、立ち止まりながら追いかけてくることになってしまいます。
やっぱり追う時はたとえ移動速度はおそくとも途切れずに追い続けてほしいですよね。


そこで距離を判定する処理と移動させる処理とを二つのコモンに分離しました。
そうすることで理屈上は、最適なタイミング、つまり移動終了直後に次の移動開始ができるようになりました。
当然、移動頻度もあがった、はずなんですが・・・。


しかし実際には体感的にはあまり変化はありませんでした。
特に主人公と追うキャラとの距離が遠い場合はそれが顕著です。
それはなぜか。
判定距離の確定範囲は主人公を起点に広がっていきます。
なので追うキャラが離れていると距離未確定の時間が長いのです。


距離判定を行うたびに、距離の値を格記録している可変ＤＢをいったん初期化していました。
だから距離が未確定の時間ができてしまうわけですね。
なのでその待機時間を減らすために、初期化しないように作りかえました。
ＤＢには「前回判定時のそのマスの距離」を保持しつつ、新規の判定でそれに上書きしていきます。
そうすることで追うキャラはどこに移動したらいいかが常にわかるのようになりました。
待機時間はなくなり、途切れることなく歩き続けるようにできました。


けれどもそれはそれで、また別の不具合がでることがわかりました。
追うキャラがちゃんと追ってきてくれない時があるのです。
その状況には二種類あります。


一つは主人公が直進移動しつづけている場合。
追うキャラは常に追ってきて、距離判定も常に繰り返しているのですけれども。
距離判定を開始した直後くらいのタイミングに問題は起こります。
主人公の足元の主人公からの距離は０です。
けれども新規に判定が確定した範囲がまだ広がっていません。
そのために、主人公が移動してきた数歩前の地点にも同じく距離が０の地点があります。
主人公がいるとみなされる地点が二つできてしまうのです。
これは前回判定時の記録を消さないようにしたことの副作用です。
追ってくるキャラは、実際の主人公から少し離れたその距離０の位置で移動を終えてしまいます。
しばらく立ち止まりつづけ、距離判定の新規更新の波が届くに及んでやっと正常な接近を再開します。


もう一つは主人公と追うキャラの距離が短時間に大きく変化した場合。
距離が接近すれば、当然追うキャラの足元のマスの距離を示す値は小さくなります。
その後に何らかの理由で距離が離れると、主人公の足元から再判定した距離が広がっていくのですが、それが追うキャラに近づくころには距離の値は大きくなります。
高い値の波がやってきた時、追うキャラは値の小さい方へ移動するように設定されているため、逆戻りをしてしまいます。
主人公に接近すると距離が高くなると誤判定されてしまうのです。
これら二つのケースの問題があって、初期化しないというのもそれはそれで問題があると気づきました。


これはいったいどうすればいいのか。
初期化はしつつも判定待ちの待機時間をなくす方法も考えました。
たとえば判定待ちなら停止でなくウディタ標準機能の「主人公に接近」をさせてお茶を濁すとか。
でもこれは逃げですよね。
上手くいく状況もあるけれど、くぼみに向かってツッコんでいく場合もある。
そんなものを作っても意味はりません。


やっぱり、「現在の瞬間の正確な距離」が測定できていないのに、追うキャラに移動開始させるなら誤作動は避けられないかもしれません。
わずかな待機時間には目をつぶるしかないのか・・・。
部分部分を補う処理は思いつくんです。
主人公と追うキャラの双方が一直線上にいて、全てのマスが通行可能なら「主人公に接近」させるとか。
それでけっこうな部分はカバーできると思うのですが、それもやっぱり付け焼刃だしなぁ。


一度確定した「主人公と追うキャラを結ぶ最短の動線」から離れた位置にある袋小路などは判定の必要のないマスとみなし、処理速度を上げることも可能ではありそうです。
だけどもそれにしたって判定頻度を常に高く保っておかないと主人公がぴゅっとそこに突っ込むとかありえるし、やはり課題は残りそうです。


こうして文章にすることで、自分の作りたいものが改めて整理されてきました。
・適切なマスに移動する。
・できるだけ途切れず移動し続ける。
・処理落ちからくる移動速度低下を起こさない
これらを満たす仕組みを作りたいと思います。


王道ですが、処理を少しでも軽くして判定時間を短くし、判定頻度を上げるしかないかもしれません。
今からはちょっと処理速度を気にしてやってみます。
ウディタ界隈でよく知られているだめだめはきだめさんの情報を参照させてもらいます。
まさかこんな情報を使うシステムを作る時が来るとは思っていませんでした。
ウディタリバーシに参加した時も、他の方が思考に時間をかけているのを見てぼくにはとてもできないと思っていたものですが。


現状ではマスの通行可否を何度も判定し直していますが、それも最初に全部を一回だけ見てＤＢに記録し、そっちを参照した方が速いかもしれない。
また５０万回エラー防止のウェイトをどこに置くのがいいのか、１フレーム当たりの処理が何回を超えた時に挟むのがいいのか、いろいろ試してみようと思います。

昨日の続きです。

だいぶん改良できました！





正確な数字の広がりがうつくしい！
通行不可でない限り、主人公からの距離が放射状に（というかひし形に）広がっていきます。
このスクリーンショットではわかりにくいですが、回り込みもばっちりです！


ところで昨夜の画像がおかしかった理由は、処理がちゃんと終わらないうちに次の動作に移っていたためでした。
そこで動作が本当に終わったのか確認する処理をはさみ、まだなら再度実行するようにしました。
そこで正確な動作が実現できました。

でも今までは終わってなくても次に進んでたから軽かったのですが、終わるまで終わらくなったためにいやがおうにも重いです。

50万エラーを防ぐためにコモン内にウェイト処理を入れてます。
1フレーム当たりの処理回数に応じてウェイトをさせるんですけど。
何回以上ではさむかによって挙動が違って面白いです。

処理回数を上げると、マップ上の距離判定頻度が高まるのですが、キャラ移動速度が遅くなります。
処理回数を下げるとその逆で、頻度が下がって移動速度が普通に近づきます。

さてどうしましょうかね。
現状では判定と敵キャラ動作指定を同じコモン内でやっています。
判定が終わるまでは移動できない仕様です。
これを分離したらいいんじゃないかな。

地形が一定（と思っていいのですか？）なら、敵キャラの最短移動方向が急激に変わることはないから、判定がまだでも「さっきまでのベストアンサー」に向かわせたらいいんじゃないかな。
主人公たちの移動がおかしくならないくらいに判定頻度は下げて、敵移動は頻度に左右されないようにしようか。
うん、そうすることにします。


上に「地形が一定（と思っていいのですか？）」と書いたのはどういうことかというと、障害を配置できるタイプのタワーディフェンスゲームのことがちょっと脳裡をかすめたんです。
オブジェクト配置によって一瞬で進むべき方向が逆転するようなゲームだってありますよね。
まあそういうのに使いたいときは判定頻度を上げて、処理を軽量化して処理速度が落ちないよう頑張るしかないですね。

続きはまた明日。

あ、もし「さっさと中を見せろー」「早く配布してー」という人がいればメールくれたら対応しますので。
とりあえず実用レベルに達したものはできてるんですけどね。
もうちょいがんばります。

ぼくのサイトを見てくれる人の検索ワードやページビュー数を見ると、「敵が追いかけてくるコモン」に興味を持ってくれる人が多いみたいです。
あれは、主人公の足跡をたどってついてくるようにするコモンでした。
でも。ねえ。
やっぱりできれば、最短距離を追いかけてほしいですよね。
というわけで、これはもう、作らねばなりますまい！

やってみて、何日か試行錯誤して、少し形になってきました。
というか、初めて不完全ながらも動いたのでうれしい。
ので、記事にします。
記事にしたら頭の整理と、モチベーション追加注入ができるのです。


考え方としては、主人公を中心とした年輪を書きます。
ＤＢに用意した各マスの距離を格納する場所に、主人公からそのマスへの距離を入れます。
接近してくるキャラは、自分の周囲のマス中でその距離が一番近い方へ移動する、という仕組み。

ぼくがメモした作り方を以下に貼り付けます。

-------------------------------------------------------
（可変ＤＢ2枚使う。距離用（初期値は９９）と四方判定済フラグ用（初期値は０））

主人公ＸＹ取得
基準地＝主人公ＸＹ
現在判定中の距離＝０

「現在判定中の距離」を可変ＤＢ１枚目ＸＹに代入する


ループ---------------------
前判定の距離＝現在判定中の距離
現在判定中の距離＝＋１
その距離入力回数＝０（初期化）

マップ内から「前の距離」入力済かつフラグなしのマスを探す

あれば、隣接する4方向全てに（必要な場合※）「距離」を入力する。
（入力するたびに「その距離入力回数」＝＋１）
4方向おえたら2枚目ＤＢの基準地＝１にする


なかったら
その距離入力数＝０のままならループ中断

ループここまで-----------------

接近キャラの4方向の計測距離を見て、最少の移動方向を求める。
同じ計測値の方向が複数あっても、どれかに決めたらいい
接近キャラ移動


※基準地の4方向に関して
計測済みでないか
マップ外でないか
通行不可でないか
を判定
-------------------------------------------------------

何のことかわかんないですよね。大丈夫です、わかるように書いてないので。

やってみてもなかなかうまくいかなかったので、ぼら猫パズルで学んだ教訓を生かしました。
そう、おかしかったらすぐ可視可！
各マスの距離をマップ上に表示させました。
こんな感じ！



接近してくる犬は数字が一番少ないところに移動するのです。

よく見るといろいろおかしいですよね。
でもシンプルなマップならそれなりに動くんですよ。
画面中央に横一文字に通行不可マスがある場合、上にいる主人公が右に寄れば犬も右に、左に寄れば犬も左に移動し、まわりこんで主人公のところにまで到達しました。
うれしい！

明日以降不具合を減らします。
これが公開できたら、画期的かもなあ。
作ったことある人は多いだろうけど、コモン集にはきっとまだないもんなあ。
などと一人でほくそえんでいます。

「歩行グラ横顔整形」という名のコモンを作り、公式コモン集に登録しました。
これはキャラが横を向いている時だけ、ちょっと違う画像を表示できるという不思議なコモンです。




上半身の画像が変わる。美人になったかどうかは責任を負いません！


画像素材をを用意したら簡単にできることなのにー！といういつものシリーズの最新作です。
ピクチャ表示なので、デフォルトの木の画像の後ろに回り込めないので木と同時に使いにくいとか、制約は多いです。
鏡コモンの改造なので。


そういえば鏡コモンといえば、現在開催中のウディコンにエントリーされている作品「ほたるのひかり」の中で使用してもらっているのを確認しました。
コモンを使ってもらった作品が公開されたのを見たのは初めてなのでとてもうれしいです。
「ほたるのひかり」は非暗号化なので、他人の制作に興味のある人はこそーっとのぞかせてもらったらいいと思いますよ。
マップツリーを見ただけでものすごい力作っぽいと感じられるはず・・・。


そういえば（２度目）ウディコンといえば、前回の記事に、ウディコン出展中の最新作「ぼら猫パズル」のキー入力の解説をするとか書いてますね。
すいません、何を書こうと思ていたかほとんど覚えてない・・・。
キー入力については、サンプルゲームのメニュー呼び出しを複製し、判定キーだけを変えたら簡単だよ、と書こうと思ったのだと思います。うん、それだけです。

なにはともあれ、「歩行グラ横顔整形」コモンをどうぞよろしくー。

この解説は連日更新していこうと思っていたところ、ウディコンの掲示板にて不具合の報告をいただいてずっと格闘していました。
今夜やっと修正ができたので、それについて書きます。

でもまずその前にそもそもこのパズルはどういう仕組みで動いているかですよね。
前回の記事で書いた通り、描画関係はデフォルトシステムの流用で楽にできました。
そしてキー入力関係も既存のものの流用で簡単にできました。
（これについては後日記事を分けて書こうと思います。）
一番問題だったのはクリア判定です。

プレイヤーの操作によってマス目の並びがお片付け成功状態になった時に、それをどう判定するか。
これはとても難しかったです。
でもこれができたなら一つのゲームができるという確信があったので、ちょっと自分の技術力から見ると背伸びでしたが挑戦しました。
作りたいものがはっきり見えていて、それに向けて試行錯誤している時って創作者にとって至福の時間ですね。大変なんだけど。

実際の制作は作ってもうまく動かない、やり直しても動かない、の繰り返しでした。
作り直すたびに発想を変え別の方法を試すのですが、３つ目の方法を試している時、方法とか以前の初歩的な失敗があったことに気づきました。
イベントの位置を把握するために入力していたX座標とY座標とが逆になっていたのでした。あれまぁ。
そりゃあ、どおりで何度作り直しても上手くいかないわけです。
そこを修正した途端、３つ目の方法がうまく機能し始めました。
なので１つ目や２つ目のやり方でもできてたのかもしれないです。
でももう消しちゃったし、３つ目の方法でできているので検証する必要もなく、今となってはどうしていたかも忘れてしまいました。
なので実際に採用した方法を説明します。

まず可変データベースに、各マスに関する数値を記録する場所を５×５の２５用意しました。
マスの色は各マップイベントのセルフ変数に記憶させているので、この数値とは別です。
この数値のことは仮に感染値と名付けました。

そしてマスの入れかえ直後だけ動くコモンイベントを５つ用意しました。
５つのコモンは５つの色に対応します。
それらは各色に対して「端から順に見てその色が最初に出てきたとき、それとつながっている同じ色のますだけ感染値を入力する」という働きをするのです。
その結果、マスの入れかえ直後に全ての感染値を初期化しておけば、各色一つ目のかたまりのみ数値が入力されることになります。
ところでこのパズルの目指す状態は同じ色のますが全部かたまることです。
つまり一つ目のかたまりが全てとなって、二つ目のかたまりなんか存在しない、そんな状態を目指すのです。
なので５色全てが一つ目のかたまりだけになる、つまり未感染のますが存在しない、そういう状態になった時にクリアーしたと判定することにしました。

そして同じ色のかたまりを認識すること、これがまた非常に難しかったです。
これなんかは、以前tohさん主催のウディタリバーシに挑戦したからこそできたと思います。
あの経験がなかったらぼくには到底作れないシステムでした。
人との縁は不思議なものですね。出会いってありがたいです。

色のかたまりの認識を完全に制御することはぼくにはできませんでした。
今回採った方法は確率論的なものに頼っています。
イメージとしては、最初に出てきたその色のますを、菌に感染させる。
そして菌に自由な方向に発育を試させながら十分な時間を置き、それで感染している部分だけを隣接したかたまりであるとみなす。
そういう方法にしました。

各色について、最初に見つかったマスに置かれた「菌」は１１００回自由な方向に移動を試みます。移動先が別の色なら移動はできません。
この１１００という回数が大きくても少なくても不具合が起きました。
回数が少ないとかたまりの判定が不正確になります。
範囲が細長い場合には開始地点から反対の端まで感染が届かないまま判定終了することがありました。
逆に回数を多くすると処理が重くなります。
処理落ちを防ぐために、システム変数を使って１フレーム当たりのﾅﾝﾁｬﾗが５０万に近づいたらウェイトを入れるようにはしました。
それでも動きは遅くなるので、それではまずいので。
遅くならず、不正確にもならない回数が１１００回だったというわけです。

それらの機能を実装できて、一応クリア判定ができるようになったわけです。
ただ、ウディコン開始後に報告をいただいた誤判定は、実は公開前から何度も確認はしていました。

そして何度も修正を加え「ついに修正に成功した！」と、何度も何度も思いました。
この不具合は再現頻度が高くないので、確認が大変だったんですよね。
確認のプレイをして、５０回クリアしても出るか出ないかだったりする。
なので、修正をしたらとりあえず見つからなければ直ったと思いこむのですが、忘れたころに不具合が再確認され「え〜」となることがしばしばでした。




あってはならない、禁断の画像。同じ色が二ケ所に分かれているのに、大成功!の文字が・・・。


さっき書いたXY座標のミスと同じで、最終的に見つかった不具合は致命的なものだったので、それ以前にチョコチョコ修正していたことに意味があったのかなかったのかはよくわかりません。
ただその過程を通して、ぼくがウディタの仕様について考え抜くことはできました。
最初は並列コモンをいくつも適当に置いておいて「いつでも同時に動いてるだろ」と思っていたのですが・・・。
並列でも１フレーム内ではコモンは番号順に処理されるのだろうから、並び順がすごく大事なんじゃないかとか思って並べ替えてみたり。
並列コモン内の処理が完了するまでにフレームの切り替えが必要なんじゃないかとか疑心暗鬼になってあちこちに１フレームウェイトをはさんでみたり。
コモン呼び出しをやめて予約にしてみたり。
とにかく原因が分からないからいろいろ試しまくりました。
そして最終的にわかったことは、感染させるコモンが不完全だったのです。
（隣接ますに移動を試みた際にそのマスが範囲外だった時、記憶させている隣接ますのイベント番号を初期化し忘れていたのでした）

これに気づくまでには、このゲームシステムを作ったのと同じくらいの労力をかけました。
なので２作作った気分です。
反省点としては、可視化することの重要性ですね。
データベースの中に何が入っているかをちゃんと常時表示確認していれば、不具合自体はたまにしか起きなくても内部数値はしょっちゅうおかしなことになっているということにゲーム公開前に気づけたと思います。



忘れちゃいけない、可視化。

それとこれは難しいけれど、やっぱり先入観念を捨てるのが大事ですね。
ぼくの場合は並列とかフレームとかの仕様などをいまいち理解しきれていないという意識があるために、謎の不具合に出会ってそこばかり注目していました。
適切な場所を落ちついてよーく見れば３０分で「ここがおかしい」と気づけるはずの失敗でした。
いい勉強になりました。
せっかくプレイしてもらって不具合にあわれた方、申し訳ありませんでした。

次回はキー入力について少しだけ書いて、ぼら猫パズルのシステム解説を終わる予定です。

ウディコンに出すためにぼら猫パズルというゲームをきみのなまえをよばせてくださいで作りました。

このゲームを遊んで下さった方の中でなおかつウディタでの制作に興味のある方に向けたシステム面の話を数回に分けてかかせてもらいます。

まだ遊んでない方はよかったら一度遊んでもらって、このゲームはどう作るかという視点でこの文章を読んでもらえたらと思います。

なお、ぼら猫パズルは非暗号化で公開しているため、興味のある方は遠慮なく中をご覧ください（ただし素材の使用は禁止です）。

では解説記事一回目はあのパズルの描画をするためにウディタデフォルトの歩行システムをどう流用したかを書きます。



パズルのカーソルは、実は主人公の位置にあるのです。
主人公は実はウルファールの画像を仮に設定してあるのですが、「パーティーメンバーを透明に」しています。
そしてパズル実行中は常時主人公の位置を取得し、その座標を基準にした位置にカーソルをピクチャ表示させています。

デフォルトの歩行のシステムはとても便利なものです。
これを自作しようとしたら大変です。
方向キーの入力を監視しないといけないし、マスに来たら止まるとかもしないといけない。
ありあわせの機能を活用して、ずいぶん楽をさせてもらいました。


また、全てのますはマップイベントです。
マップイベントを２５枚並べています。
それぞれにページを５つ設定しています。
イベント画像を５色の正方形に設定して、起動条件となる変数の値によってページを変え、色が変わるようにしてあります。
これまた自作していたら手間のかかるところでした。

さらには、カーソルがパズル範囲から出てしまわないためにはパズル範囲の周囲や足元に敷き詰めたイベントのすり抜けオンオフ機能を使いました。
周囲は通行不可のイベントで囲んだのは言うまでもありません。
それに加えて、カーソルの一部が周囲に食い込まないようにするのも同じ機能を使っています。
カーソルは縦と横に向きを変えますが、透明の主人公の位置はカーソルが横向きなら左側、縦向きなら上側なのです。
なので対策を講じないと、例えばカーソルが横向けの時には右側が周囲の通行不可マスにかぶってしまうのです。
それを防ぐためにパズル枠内、通行可能範囲の右端、および下端に、イベントを並べました。
起動条件を「その時のカーソルの向きを示す変数」にしてすり抜けは不可にし、そのイベントが存在する時だけそちらには進めないようにしました。
また、カーソルを切り替えた時に枠に食い込むような位置にいた場合は、「場所移動」で透明の主人公を隣のますに瞬間移動させました。
何というか非常に泥臭い方法ばかりですが、それらのおかげで非常に簡単に作れました。

このようなパズルを作る時にここまで歩行システムやマップイベントを活用するというのはひょっとしたら珍しいかもしれないので、少し詳し目に書いてみた次第です。

ただ、既存のシステムを流用したことによる弊害もなかったわけではありません。
一番大きいのは、パズル範囲を画面中央に表示できないことです。
ウディタではどの画面サイズを取ろうとも縦・横に敷き詰めるマスの数は偶数です。
なので画面中央に一つのますを表示することは難しいし、奇数マスからなる何かを中央に置くのも大変です。
マップを使うゲームを作った経験のある方は、画面上下の部屋の出入り口などの幅が偶数ますだと偏るので困った方も多いと思います。

一応これには解決方法もないわけではないです。
全ての地形をイベントで配置し、マップが始まる直後に全てのイベントを半歩横へ移動すればいいです。
そのためのコモンも公式コモン集にて公開されていたと思います。

ただ今回のぼくの場合はそれも使えませんでした。
主人公の半歩移動が使えないからです。
マスを選択するためのカーソル移動なのに、カーソル位置がマスにぴったり重ならなかったら話になりませんもんね。

まあシステムを改造して、デフォルトの移動幅を半歩にしながらも停止位置がマスの真上なら強制的にさらに半歩進ませることもできるでしょうけど。
でもそこまでするとせっかく歩行システムを使っている利点がなくなってしまいそうだし、そうはしませんでした。（めんどうだし！）

おかげでパズル画面はわずかに右に寄っています。
そういえば「エフェクト」などを使って画面の表示位置を半歩分横にずらすこともできるのかも、とはちょっと思ったのですが。
でもぼくはエフェクトは苦手なのでやりませんでした。
エフェクトってピクチャ表示と相性が悪いじゃないですか。そうでもない？
今なんとなく思いついたけどウディタの描画演出をするのにピクチャ派とエフェクト派がいるかもしれませんね。
どっちも使いこなせたらそりゃいいけど、片方で事足りるケースが多そうな気もします。
まあぼくだってたまにはエフェクトも使いますけどね。
今回のぼら猫パズルでは・・・うーん、多分どこにも使ってません。

昨年のウディコンでは画像音声部門で高い評価をもらえましたが、こういう手抜きをプレイヤーは見てるかも知れませんね。
ほんのちょっと中央から偏ってるってだけでも、高い緊張感が保てない気はします。
まあ今回のゲームはゆるキャラとだらだら続けてもらいたいから緊張感はあんまりなくてもいいか。


話がそれましたが、それ以外のデフォルトシステム流用による弊害といえば、移動速度のことでしょうかね。
ゲームプレイを続けるとある時からカーソル移動速度を変更できるようになります。
これは主人公の「移動速度の変更」機能を使っています。
でもこれは細かい調整ができなくってね・・・。
通常だと快適なんですが、一つ遅くすると遅すぎてイライラするし、一つ早くすると操作性がすごく悪くなるし。
なので完成間際まで変更画面で「通常以外はお勧めしません」とか書いてお茶を濁していたんですけどね。
でもテストプレイヤーさんに「速いだと操作しにくい！」と残念がられてぼくは目が覚めました。
そりゃそうですよね。せっかく速くできるようになったのにそれが使い物にならないなんてストレスのもと以外の何物でもなく、無い方がましなくらいです。
そこでぼくは本気を出してがんばって、移動速度が速くても誤操作が起きにくいシステムを作りました。
主人公の座標を常時監視して、主人公がマスの真上を通過しようとした瞬間だけ、動作指定で数フレームだけ瞬間的に足止めする、という方法です。
これをすることで、移動速度を速めても意図したのに近い操作ができるようになりました。
ちなみにこれを作るためには使えそうで使えない方法がありましてね。
このブログでも何度か取り上げた、システム変数の「主人公が移動中？」というやつです。
鏡コモンを作る時に詳細にみた通り、この変数は主人公がマスの真上にいるのかどうかを判定できるんですけどね。
理屈上ではぼくがわざわざ座標を取得してやっているのと同じことを判定できそうなのですが。
けれどもこれは移動速度が速い連続移動中はマスの真上も瞬間的に素通りしてしまうんです。
それを知っていたので使いませんでした。

そういうことを思うと移動っていったい何だろうと考えてしまいます。
移動速度というのはマスからマスへ何フレームかけて到達するかなのでしょうかね。
その速度で移動開始をしたら、１フレームごとに何ピクセル移動するかが決まっているんでしょうね。
そしてキャラの瞬間瞬間の厳密な座標によって、キャラが今の瞬間いるマスがどこかとか、マスの真ん中にいるかとか、決まるんでしょうね。

少し話がそれるけど、昔習った数学の問題を思い出しまいた。
「たかし君が時速Aキロで池の周りをまわって、１０分後にスタート地点にいる確率はいくらでしょう？」
これ、正解はなんと０％なんですって。これにはびっくりした！今でも忘れません。
たまたまそこにいることだってあるだろうと思うんですけどね。
よりによって、一ミリもたがわず、その瞬間にその場所にぴったりといるということなんて、もう限りなく０に近いくらいありえないことらしいです。
そうだとするならば、そりゃあマスの真上を瞬間的に通過していくキャラを、１フレームに一回しか判定されないシステム変数が捕捉できる可能性は低いのかもしれませんね。
そう思うと１フレームって限りなく瞬間に近い概念と思っていたけれども、移動距離との関係でいえば全然瞬間なんかじゃないんですね。

１フレームって、意外と粗い。
これは今回のぼら猫パズルの制作で身に染みたことであって、これ以外の所でもまた出てくる命題です。
それについてはまた明日とかに書きます。

一回目の今回は、パズルゲームであってもデフォルトシステムをフル活用したということを書いてみました。
書き忘れていることもあるかもしれないけど。
興味のある方は参考にしてください。
質問もお待ちしています。

それと全然関係ない話ですが。
今作で一つだけお借りしたコモンがあります。
表記の義務はなくスペースの都合もあってゲーム内などでは表示しませんでしたが。
ひげさんの文字表示拡張コモンを公式コモン集よりお借りしました。
制作に興味のある人しか見ないだろうこの場を借りてお礼申し上げます。
ありがとうございました。
ゲーム開始直後にタイトルが上から降ってきてプルプルなるのにこのコモンを使っています。
おかげでかわいらしい演出ができました。

では、続きはまた次回ということで。

サークルきみのなまえをよばせてくださいで製作したパズルゲーム、ぼら猫パズルを公開しました！！！

ウディコンにも、だすー！

エントリー前だけど公開していいのかって？

いいんです！前日だからいいんです！（規約上）

だらだらと続けてしまうゲームです。
これは面白いと思うよ！
ぼくだけだろうか。どうなのだろうか。

プレイの快適さと、キャラクターの魅力を引き出すことを追求しました。

ここからダウンロードしてくださいね！

製作に関わってくれた皆さん、ありがとうございました！

きみのなまえをよばせてください

というサークルを相方さんと二人ではじめました。
当面は個人での制作は予定がないので、今後の活動報告などはそちらの方ですることになるかもしれません。
かといって、いままででもこのブログに作成中ゲームの情報とかはほとんど書いたことはなかったですけどね。
ウディタの技術面のこととかは、引き続きこっちに書くと思います。
今後もよろしくお願いします。

ちょっと、どうしよう・・・。
面白すぎるゲームシステムが完成してしまいました！
このゲームの構想を思いついて以来、ひたすらシステムを作り続けました。
とても難しかったのですが、どうしても作りたくて何度失敗してもめげずに挑戦してついに昨晩できました。

このゲームの残念なところは、あまりに面白すぎてついついプレイをし続けてしまい制作がちっとも進まないことです。
ぼくにしてはかなりめずらしい、完全に一人で作っている本格ゲームです。
ウディコン、出します。
そしてジャンルはまさかのパズルです。
それもfairy songみたいに考えるやつじゃなくて、感覚的にどんどんすすめていけるもの。

せっかくウディコンに出すんだから、しかも昨年は総合二位までもらったんだから、やっぱり楽しんでもらえるものを目指したいとは思います。

でもこのブログのコメント欄の常連さんであるアルボースさんがよく言ってる「自分で楽しめるゲームを作る」ということが今回わかった気がしています。
自分で心から楽しめるゲームを作れて今すごくうれしいです。
ウディタをさわり始めて３年ですがやっててよかったです。

願わくば、今回できたゲームシステムの魅力を余すことなくお伝えできるような完成作品としてまとめ上げていきたいものです。
ストーリーも作ります。
今回は自分でやります。多分。うん、やれる気がする。
絵は・・・未定です。依頼か募集かするかも。いや、これはまだわかりませんが。
ともかくいいものにします。
ただしパズルをずんずん進めていく楽しさの流れを損なわないように細心の工夫をしていきます。

そしてこのゲームが生まれたその裏で、ぼくの一つのゲームが幕を閉じました。
昔使っていた２０００年製の携帯電話に購入時から入っていたパズルゲーム「モバイルグンペイ」です。
通話はもちろん解約しているのですが、それでもゲームは昨年までよく遊んでいたのです。
けれどもしばらくしまっていた間に充電池が破裂し、もう二度と遊べなくなりました。
携帯ショップでも充電池のスペアは扱っていないとのことでした。
きっと今まで遊んだどのフリーゲームよりも長時間プレイした作品でした。

今回ぼくの作ったゲームシステムは、このモバイルグンペイの影響をほんの少しだけ受けています。
（パクリじゃないよ！）
どうぞお楽しみに。

以前からずっと制作を手伝っていた暗闇行燈さんのユア・マイ・ヒーローがとうとう完成し、この度公開されました！
ダウンロードはふりーむ！のこちらから。

暗闇行燈のＮＡＮさんと言えば、知る人ぞ知る大作フリーゲーム落葉の大地を走れの作者です。
この度は短編ＲＰＧですが、本格ストーリーが楽しめるＮＡＮさんらしい作品になっていると思います。
ぼくは戦闘全般を任せてもらい、自由に作らせてもらいました。
基本システムの戦闘を流用しながら、できるだけ基本システムらしさを感じさせない戦闘になるように工夫しました。




敵と向かい合う戦闘画面


戦闘バランス（難易度）の調整が難しくもあり面白くもありました。
納得のいくゲームシステムにしようと工夫する中で、今まで意識していなかった自分のゲームに対する嗜好がわかってきたのは意外でした。
面倒くさがりのぼくはレベル上げの作業もあまり好きでないし、攻略法を総当たりで探すのも好きでないです。
かといって攻略法が完全に明示されていてそれに従い進めれば誰でもクリアできるなんてのもうれしくないです。
ランダム性が大きいのも遠慮したいです。
攻略方法も示されているけど、それでも理不尽でない程度には工夫が必要、でも手順を踏めば攻略は容易。
そんなゲームをプレイしたいし、作りたいようなのです。ぼくはどうやら。
そのことがこの作品を作る過程で意識されてきました。
そしてぼくの今まで作ったネオ繚乱記とfairysongの２作が、ジャンルも違うのに実は同じものを目指していたのだとはじめて気づきました。
今作はお手伝いという立場ではありながら、ある意味ぼくの今までの集大成の作品になったような気がしています。
ラストダンジョンでの敵の動きなどにも工夫を凝らしたので、よかったらプレイしてみてください。
fairysongでもお世話になったＲｅさんが手掛けてくださったグラフィックは必見です。

今後はぼくが自分の作りたいＲＰＧを作ることはきっともうない気がします。
今後もし自分で作るのなら、アドベンチャーかシミュレーションという気がしています。
でもそれよりなにより、誰かが構想したゲームのシステムを形にしていくことをやっていきたいと思っています。

基本システムの改造をしていて、戦闘コマンドに装備変更という項目を追加しました。
メニューから呼び出す装備変更コマンドを呼び出し、「戦闘中に呼び出されていたなら終了後にメニューを開かない」という処理を入れることで、戦闘中に装備変更できるようになりました。
戦闘コマンドの特徴としては、ターンを消費せず、ターン開始前に何度でも実行できます。

それと同時に、装備武器によって戦闘コマンドを変更する仕組みも実装しました。
戦闘開始時に装備中の武器が単体攻撃か全体攻撃かを判定し、コマンド名を「単体攻撃」「全体攻撃」のいずれかにします。

それも実装できたのですが、戦闘中の装備変更と両立させることはできませんでした。
ターンを消費するコマンド内で装備を変更したところ、次ターンの開始前に出る戦闘コマンドは更新することはできたのですが。
ターン前に装備武器を替えようが戦闘コマンド変更をしようが、コマンド名は変更されることなく・・・。
まあ当然ですよね。
デフォルトの基本システムでは戦闘コマンドを表示後、次回表示の時（ターン後）までに再表示されることは想定されていませんもんね。

そこでコマンド変更処理に続けて、戦闘コマンドリストを改めて再表示する処理も入れたりしたのですが、やはりうまくいきませんでした。
基本システムの戦闘の流れの根幹部分ですもんね。なかなか、中途半端な知識では手を加えられません・・・。

基本システムを使うくらいならシステム自作する方が簡単だという人がいるのもうなずける気がしました。

ウディタであんなことできた、こんなことできたとブログに書くと自慢みたいだとちょっと思っていたのです。
なのでできなかったことも書いていきます。

・戦闘中のセーブ
基本システム改造しているのですが、戦闘コマンドにセーブがあったら斬新かなと思って試してみました。
技能に「セーブ」をつくってセーブのコモンを呼び出しました。
技能としてコモンを呼び出す時は引数が指定できずに悩みました。
モードを指定しないとセーブを閉じた後メニューが開いてしまうのです。
そこで考え、セーブコモンを複製し、片方は戦闘専用にしました。
そのコモンの冒頭に変数操作を入れることで、閉じた後にもメニューが開かないセーブができました。
さっそくセーブし、ロードしたら・・・あぁ、だめでした！
あわよくば戦闘の続きを再開できたらと期待していたのですが。
ロードするとかろうじて敵ピクチャなどは表示されていますが、戦闘状態は終わっていて、マップ上を自由に歩けました。
セーブをすると変数やＤＢの情報は記録され、そしてロードで再現できるのかもしれません。
けれどもどのイベントをどこまで実行中というのまでは記録できず、再開もできないのかもしれません。
戦闘を制御するコモンを実行中の中途でセーブしても、その時点でそのコモンを自動実行するような状況になっているわけではないから、ロード後も戦闘にならないのでしょうね。
ものすごくがんばればなんとかできるのかもしれませんが、大変そうなのであきらめます。


余談ですが、戦闘中のセーブを思い付いたきっかけも書き残しておきます。
それは我が家の家族たちの会話でした。

「もうゲームやめなさいー！」
「この戦闘終わるまでもうちょっと待って！」

このやりとりは毎日のように繰り返されています・・・。


できなかったことがあったらまた書きます。

このところずっと基本システムを改造しています。
基本システムと言えば前から気になっていたのがこれ、「薬草 x1」とかの表示。
基本システムではアイテムや装備の所持数を示すのに、xが使われてます。
そりゃ、見たら意味は分かるけど・・・。
でもxはエックスです！
どう見てもただのアルファベットですから！
これが個数をあらわすなんて、しかもそれがウディタでゲームを作る「基本」に組み込まれているなんて、おかしいー。
まあ基本システムが基本じゃないというのは散々言われていることですけどね。
というわけで、このxの変え方を書いておきます。

基本システムのコモン110番の２９行目、１０３行目、１６３行目あたりでデータベースにxを書き込んでいる所があります。
これを×(かける)とかに変えたらいいです。
ついでに、装備変更コマンドもデフォルトで使うなら、コモン112番の１９５行目あたりも同じように修正したらいいです。
（後日追記：コモン９９番の８５行目にもエックスがありました！修正してください。）
これで大丈夫！
「薬草 x1」とかの不思議な表示はなくなると思います。

こういう、ほんのちょっとした部分の修正を積み重ねていけば、基本システム臭さが大分薄れるんじゃないかと期待しながら作業しています。

Ｘ×XxｘＸ×XxｘＸ×XxｘＸ×XxｘＸ×XxｘＸ×XxｘＸ×XxｘＸ×XxｘＸ×XxｘＸ×Xxｘ

追記
ブログに表示されてるのを見たら、ぼくの環境ではxでもそれなりに「かける」に見えてしまいます。
x×
左がエックスで右が「かける」。
どっちもただのバツですね。
でもウディタでは違うから！
所有数を表す時のＸには4隅に短い横棒がついているから気になるんですー。
あ、もしかして「使用フォントが気に入らないなら変えたら」っていうだけの話？
ちがうー。エックスは「かける」じゃないー！

なんだかこう書いていると自分だけ神経質でいちゃもんつけている気分になってきました。
共感してくれる人がもしいたら、基本システムを使うときはこの記事を参考にしてください。

自作ゲームや参加した作品等をまとめました。

扉は君の鍵で開く（製作：暗闇行燈）DLページ　紹介ページ
好きな言葉で質問できる本格推理アドベンチャー。システムや校歌などを担当。君も謎を解こう！第１３回ウディコン４位いただきました。


ボラ猫パズル（製作：きみのなまえをよばせてください）DLページ
紆余曲折の末に完成したパズルゲーム。第８回ウディコン総合１８を位いただきました。


ユア・マイ・ヒーロー（製作：暗闇行燈）　DLページ
NANさんと一緒に作ったRPGです。ウディタの基本システムの戦闘の解読と改造をがんばりました。


ウルファールの地底迷宮　ＤＬページ
個性的なウルファールの顔グラ素材を使わせてもらった作品です。


独裁者２０１５　ＤＬページ
こっそりとウディコンに出した問題作です。内容が少し過激なので別名義でこわごわ公開しました。もう時効かな・・・？
（アップローダがサービス停止し、ウディコン公式ページからしか手に入りません。リンク先の７２番です）


fairy song〜歌う革命〜（集団制作）　紹介ページ
個人名義での製作ですが、シナリオ、デザイン、音楽、その他多くの方にご協力いただきました。第７回ウディコン総合２位いただきました。


らすとあとりえ（製作：√８）　紹介ページ
初めて中心となって集団制作した作品。第６回ウディコン出品作です。


フルーツシーカー（製作：√８）　紹介ページ
ＭＩＤＩの音楽作成で参加。実況者がぼくの作ったジングルを口ずさんでくれた喜びは忘れられないです。


勇者の冒険（製作：√８）　ＤＬページ
初めて集団制作した作品。あまりに斬新なシステム案はぼくが出しました。形にしてくれた共作者に感謝。


ネオ繚乱記　ＤLサイトがリンク切れの模様。入手不可？
初めての作品。未熟で恥ずかしいです。


その他ウディタ用のコモンイベント各種
自作コモンをウディタ公式コモン集に登録しています。代表作は鏡コモンなど。
（画像は主人公画像を上下に分けて別の不透明度で表示するコモン）

このごろ戦闘などいじってます。基本システムの改造です。
たいしたものじゃないけど記事タイトルのものができたので公開します。

よくＲＰＧをやってると敵の攻撃パターンに法則があったりしますよね。
何ターンに一回大ダメージの技が来るってやつ。
攻略法としては、それまでに回復しておき防御でしのぐ、みたいな感じでしょうか。

基本システムの戦闘でそんな敵を作ろうと思いました。
コモン１６０番を改造したので上書きして使ってください。

160_X[戦]AI実行.common
↑
こちら

なお、この条件と引き換えに、アクションの条件「[2002]３回目行動なら」が使えなくなってます。
というかその場所を借りてます。
本来ならデータ内容を指定するための選択肢の項目を追加すべきなのでしょうが、ＤＢのアクションの条件はたくさんあるので修正も面倒だし、どうせ３回目行動はぼくは使わないのでそこに入れてしまいました。
（３回目にした理由は、やはり１回目２回目は使うかもしれないからです。それに３回目も奇数には違いないですしね。）
コモンしか上書きしないので当然ＵＤＢは従来のままなので、まぎらわしいですがお気を付け下さい。
予備変数１−１番を使います。

えっと、あらためてどういうことをするコモンかというと、条件[2002]の判定が行われるたびに予備変数１−１に１を足して判定回数を数えます。
そしてこの回数が奇数回目ならそのアクションで指定した行動を実行します。

いろいろ制約が多いです。
一回の戦闘中での回数を数えたいなら、コモン203番を使うなどして戦闘が終わるたびに判定回数＝０にしてリセットしてください。
なぜ判定をしないと回数が数えられないのかと言えば、現在が何ターン目かを調べる方法が面倒だったからです。（そんな面倒じゃないはずですけど）
そのためこの条件は必ず判定されるようにしないといけないので、一番上のアクションなどにしてください。
また戦闘中にこの判定を使う者（敵も仲間も）が複数いたらカウントがおかしくなります。
なので、一体で出てくる敵だけに使わせてください。
汎用性のかけらもないコモンです。
昨夜に続いてぐだぐだです。

ちなみにＡＩのコモンを改造する時に、「何回目の行動？」と名づけられた変数があったのでこれ幸いと使ってみたのですが、全然うまくいかない・・・。これは２回攻撃とかを判定するものかもしれませんね。
昨夜と今夜のコモンはぼくが公開している中でも最低レベルのクオリティなので、よっぽど必要としている人以外は参考にもしなくていいと思います。

あ、でもＡＩを改造する時、条件としてどの変数がどうだったら、というのはあったら便利ですよね。
そういうのを作る人には参考になるかも知れないとは思います。
なんだか文章までぐだぐだです。
おやすみなさい。

記事タイトル、何のことかわかりませんね。
文字なんてどう表示したってモニタ上で光ってるじゃないかって？
そんな屁理屈を言ってはいけません。

黒い画面上に横書きに表示された文字列を、表示後ちょっとしてから、左の方からキラリーン！と明るい部分が移動して右にいく、というふうにするコモンを作ってみました。
こんな説明でわかるのかな。
ぼくは動画を作ったり貼ったりする技術がないため、がんばってイメージしてください。

・・・あ、そうだ、せめてスクリーンショットを貼っておこう。





赤色で表示された文字列が、左から右にかけてキラリーン！と輝きます。
せっかく作ったので配布します。実用的じゃないけど。
kirari-n.common
↑
こちらから

コモンを一つ使います。呼び出すと実行されます。ピクチャの消去は各自でお願いします。
汎用性は全然ないですけどね。
ＲＧＢ値の指定とかも数字を直接入力しているので、改造は面倒です。
興味のある方はやり方だけ参考にしてもらって、ご自分のゲームに合わせて作り直してください。

原理としては、黒地に白で表示した文字列のさらに上に減算でピクチャ表示し、グラデーション機能で透明な部分だけは減算が少ないので白っぽく表示される、という感じです。
文字の表示をした後に、最初に画面を覆う長方形、薄くなっていくグラデーション、濃くなっていくグラデーション、それにもう１枚画面を覆う長方形、計４枚のピクチャを並べて、同時に右に移動しているだけです。
座標の指定の仕方とかももっと簡単にできそうな気もしますけど、まあいいでしょう。
選択肢を選んだ後に効果音と共にキラリーン！と光る演出とかいいかもしれませんね。
選ぶとすぐに消えてしまうデフォルトの選択肢はそのままでは使えませんが。
さらにウィンドウも使えないのでご注意！
（誰が使うんだ、これ・・・）

ぼくが作った鏡コモンはパーティーメンバーを映せませんでした。
その理由は２つくらいあります。
まず「パーティーメンバーにもマップイベントＩＤが割り振られている」ことをぼくは知らなかったこと。
そして何より「マップイベントが表示中の画像名を知る方法」があるとは知らなかったこと。
まあ仮に知っていたとしても、意欲が尽きて作れなかった公算が大ですが・・・。

非常に複雑なコモンをコツコツ作って完成させ、鏡コモンの機能を飛躍的に拡張してくださったソフトニシンさんには感謝してもしきれません。
ソフトニシンさんはコモンをもちろん公開され、参考にすることを推奨してくださっているので、ここに自分のメモ的な意味も込めてまとめておきます。

マップイベントが現在表示中の画像名を知る方法。
これこそが、ソフトニシンさんが公開してくださった鏡コモン２種のキモとなる部分です。
個人的にそう思ってます。

コモン自体は本当に長い長いものですが、それはほんの３行です。

■変数操作: CSelf15 *= 10 + 0
■変数操作: CSelf15 += 9100009 + 0
■文字列操作：CSelf7 = 位置[CSelf15]の文字列

たったこれだけ。
コモンセルフ１５番に、画像名を知りたいマップイベントのＩＤを入れます。
そしてこの３行を実行すれば、コモンセルフ７番に歩行グラなどの画像ファイル名が返されます。

なんでそんなことになるんだ〜。
というのは悩んでも仕方ないので、これはどうやらありのままを素直に受け入れるのがいいようです。
ぼくが今まで作ったコモンでいうなら、階段の上り下りするコモンでも、主人公の表示高さを変更するのにこれと似た機能を使いました。
とにかく変数呼び出し値はただ者ではないとしか言いようがありません。

しかもこの３行のすごいところは、返ってくる画像名がその時点での最新情報だということです。
ページ切り替えや起動条件を満たさなくなるなどでそのマップイベント画像が消えた時、返される文字列はちゃーんと空白になります。
なんて便利なんでしょう！

ぼくが現在作っているゲームでは、主人公の前方隣接ますにいるマップイベントに対して、決定とはまた別のキーを使って決定とはまた別のアクションをするということを実装しています。
キー判定自体は基本システムの「歩行時並列処理」を流用してキー入力だけ変更したらできたのですが。
ただ、キーを押したときに前方にマップイベントがあったら反応するとした場合、キャラグラを表示していないイベントに対しても起動してしまうので困っていました。
そこでこのソフトニシンさんが使われていた方法を思い出したわけです。

この３行を実行して帰ってきた文字列が、
””（空白）と同じなら
マップイベント画像は表示されていない。
それ以外なら
マップイベント画像は表示されている。

そういうことが分かります。あー助かったー！
ソフトニシンさん、ありがとうございます！


あ、ちなみに、ぼくが知らなかったもう一つのこと、パーティーメンバーのマップイベントＩＤは何番なのかということですが・・・。
ここをお読みのみなさん、知りたいですよね？どうです？
（ぼくの想像では７割の方が興味ない、１割の方がもう知ってる、２割の方が知りたい、くらいかな？）
まあ、そこまで何もかも書いてしまうのもソフトニシンさんに気が引けるし、それはぜひ立ち鏡コモンなどをＤＬして確認してもらえたらと思います。
コメントでしっかり説明を入れてくれてるので、とても分かりやすくて勉強になります。

以前ご紹介した鏡面床のコモンを改造してくださったソフトニシンさんが、この度は立ち鏡コモンを改造して公開してくださいました！
公式コモン集で立ち鏡で検索してみてください。



使用例
（重なり順までバッチリ！！！）


ぼくの作った鏡コモン（立ち鏡用）は、主人公一人だけの鏡像を上のマスに映すだけのものでした。
映すことができただけでぼくは満足してしまい、鏡像の動きについて意識していなかったのですが・・・。
鏡像は主人公の位置と平行移動させていました。
でもこれはおかしいんですよね。
主人公とその向こうにある鏡とをプレイヤー視点、つまり斜め後ろから見下ろしたのなら、鏡に近づくほど鏡像も近づき、遠ざかるほど鏡像も遠ざかるはずです。
そこにソフトニシンさんはとことんこだわってくれました。

鏡像が鏡の下を起点に対照移動するほか、パーティーメンバーはもちろん、街の人も映ります。
おまけに地面も映ります。
（画像でいちめん地面のところに像が映って見えるのは、実は鏡に地面が映っているのです）
地面を映さないだとか、不透明度や色調の設定だとか、特定メンバーだけ移さないとか・・・。
ほかにも盛りだくさんの汎用性が確保されてます。
便利な素材も同梱されています。
設定はほんのちょっと手間かもしれませんが。

主人公が一人で鏡像が平行移動でもいいという人は導入が簡単なぼくの旧コモンでもいいですが、鏡にこだわりたい人はぜひ一度チェックしてみてください。

ウディタで文字を表示する時に便利な機能の一つに文字影をつけるというのがあります。
これはシステム変数２１番で指定でき、デフォルト（基本システム）では１になっています。
この数値は「そのピクセル数離れた位置に黒い影を表示する」ということを表します。


この機能、なんと表示済みの文字にも適応されるのです。
どういうことかというと、Sys21=0の時に表示した文字でも、後からSys21=１とかになった時には影が表示されるのです。


ぼくはこれを勘違いしていて、文字の性質変化をさせる特殊文字と同じように使えるのかと思ってました。
例えば一つの文章の中でも影ありと影なしを切り替えられるのかと思ってました。
そして影なし状態で文章表示後影あり状態にして別の文章を表示し、両方とも影がないもんだから、ナンデダ〜ナンデダ〜と小一時間悩みました。
影の有無を同時に併用することはできないんですね。

検索してもそのようなことはどこにも載ってなかったです。
ぼくみたいな勘違いをする人は少ないのかもしれませんね。
文字影が表示されない、と悩んでる方がもしいたら、それはひょっとしたら表示後にSys21を変更しているのかもしれません。
そういった使い方はできないようです、残念ながら・・・。

初心者がほしくなるかもしれないコモン第三弾は「キャラころりん」です。
これは主人公やパーティーメンバーその他のキャラの画像を回転させ寝かした状態などで表示するためのコモンです。
マップを使うゲームで倒れたキャラを出したい時など、歩行グラを寝かせたいですよね。
でも歩行グラを回転表示する機能はウディタであらかじめ用意されてはいないようです。
そこでこのコモンの出番！
これを使えば、歩行グラ素材の画像の一部分をピクチャとして回転表示できます。



こんなの


詳しい使い方などはコモンに同梱した説明書でご確認ください。
ピクチャなので表示しただけではマスを通行不可にはできませんが、やはり寝ているキャラのマスには行けないほうがいいですよね。
そこでその対策法も説明書に書いておきました。
簡単に言うと、ピクチャより下層に切り株などの小さくて通行不可のマップイベント置くという方法です。
切り株は倒れたキャラに隠れて見えないようにします。なんて原始的！
誰もが完全な透明タイルを含む素材を２つ持っていれば、その一つを通行不可にすることでキャラの位置に設置して通行不可にできるんですけどね。
もちろんタイルセットウィンドウの左上に表示される消しゴムのようなタイルを通行不可にできるならそれを使ってもらってもいいのです。
でもあのタイルを通行不可にできるかどうかは作品によるでしょうしね。

ちなみにこのキャラ画像を表示するのに歩行グラ画像が使えるというのは、初心者だったぼくには思いつきませんでした。２年ほど前のことですが。
ウディタに関する情報を手当たり次第探していた当時、藤田工房さんというサイトで見つけたMaRyuTangというゲームをプレイしました。
（藤田工房さんは黎明期のウディタの普及に貢献された方だそうです。多くの先達に感謝します！）
そのゲームの戦闘では、なんと歩行グラなどを敵に投げつけ攻撃するのです。
主人公の父親とかがぶん投げられ回転して飛んでいく絵づらはとても印象的なものでした。
と共に技術的にも「こんなことができるんだ」と驚きました。
最初はマップイベントを回転表示させるのかと思ったのですが、ピクチャ表示だったんですね。
しかもピクチャ表示する画像はpictureフォルダ以外に入ってるものでもいけたんですね。（←初心者）

思えばその時の驚きが、後にぼくが鏡コモンや主人公ピクチャ表示を作ることにつながったのかもしれないです。
もっともそれらで使った「アニメパターン取得」機能は確かウディタのＶｅｒ2.1以降に導入された気がします。
なので昔（といっても１０年も前じゃないのですが）の方々がどんなに技術があってもそれはできなかったんですよね。
それが今はやすやすとできるのだと思えば、与えられた環境に感謝して先輩から受け継いだバトンを次につなげれたら、とか思ったりもします。もちろん自分などにできることは微々たるものですが。
（そしてフリーゲーマーの多くがスマホに移行したといわれる昨今、ウディタを使う人が将来何人いるかも分からないのですけど・・・。まあきっとぼくを含めた数百人はいるでしょう、多分）

えらく話がそれてしまいました。なぜかぼくには歩行グラをピクチャ表示させることに思い入れがあるようです。
何はともあれキャラを寝かせたい人は「キャラころりん」をどうぞよろしく！

昨夜に続き、最近公式コモン集に登録したコモンの紹介です。

クリア後おまけ解放コモンとは、ゲームクリア後にタイトル画面に選択肢を増やすのに使うものです。
具体的には、ゲーム起動時に今までのクリア経験の有無を判定し、あれば文字列変数に文字列を入れて返すということをします。
ウディタのデフォルトの選択肢の仕様である「項目名が空白ならその選択項目は表示されない」と併用してください。

クリア後におまけイベント追加とか。
ＣＧギャラリー解放とか。
ＢＧＭ聞けるとか。
製作余話とか裏話とか。
いろいろできそうですよね。
クリア後だけ選択項目を出したい時に使ってください。

なおこのコモンではクリア経験の有無しか記録していませんけど・・・。
どのようなクリアの仕方だったのかも記録できたら、やれることがまた一段と広がりそうですね。
解放済みＣＧのみ表示とか。
そういったことをしたい場合は改造してください。
難しければご相談ください。

最近公式コモン集に３つのコモンを登録しました。

敵が追いかけてくるコモン
クリア後おまけ解放
キャラころりん

の３つです。
詳しい説明や使い方はコモン集のページや同梱した説明書で確認してください。
３つとも中級者以上には簡単に作れるかもしれない、初心者向けのコモンです。
コモンの機能としても、初めてウディタを触る人がほしくなるかなーというものを揃えました。
ただ導入は少しやっかいだったりします。
ピンポイントに「これをするコモン！」と決めて汎用性を捨てたらもっと簡単にできるんですけどね。
でもそれだとほとんどの人にコレジャナイ感を与えるので・・・。
汎用性を取るか導入の簡単さをとるかは、公開するコモンを作る上でいつも悩むところです。

これから３回に分けて、これらのコモンで何ができるかや製作余話などを書いてみます。


今夜はまず＜敵が追いかけてくるコモン＞についてです。




これはいわゆる「青鬼コモン」と呼ばれるものです。
（とそこまで一般化して言っていいのかわかりませんが。）
青鬼とはフリーの探索ホラーゲームです。
鬼が主人公を追いかけてくるのです。
「青鬼のようなゲームを作りたい！」という話をネットでよく見かけるのでぼくも少しプレイしてみました。
途中ですぐやめましたけど・・・。

これを作ったきっかけは、このブログのコメント欄の常連でもあるＨＮアルボースさんの作ったアズルイベイションをプレイしたことです。
少し話が脱線しますがこのゲームを紹介させてください。
ぼくの知る限り、これは全くもって究極の避けゲーです。
主人公は宇宙を旅する結晶体。ひたすら、避けて避けて避けまくれー！
百聞は一見にしかず。隠れた名作ですからぜひやってみてください。
用意されたステージ数は圧倒的なボリュームなので、避けゲー好きの人はやり込めること間違いなしです。

さてこのアズルイベイション、ボスステージでは接近してくるボスを一定時間避け続けられたらクリアーというしくみです。
技術的な話になりますが、これはウディタの機能「主人公に接近」と「場所移動」を組み合わせているようです。
単に「主人公に接近」させるだけでは敵は最短ルートを来るので障害物、特にくぼみなどに敵をハメることができればゲームが単調になってしまいます。
それを回避するためか、「場所移動」によるワープ、そしてランダム移動も取り入れられていました。
それを見てぼくも作ってみたくなった、というわけです。

参考までに公式コモン集もざーっと見てみましたが。
敵が接近してくるコモンの中で「主人公に接近」以外を使っているのは見つけ出せませんでした。
言い方を変えるとどれも障害物に引っかかってしまうということです。

なので障害物をよけるルートを計算して追ってくるコモンを作ろうかと思ったのですが。
でもこれは大変。
難しいので考え方を変えました。
主人公の移動した跡（軌跡）を追ってくるようにしました。

主人公の逃げたとおりに追ってくるなら通行不可マスに引っかかる心配はないですもんね。
ただ敵の追いかけを主人公のすぐ隣とかから始めるとゲームとしてかなり過酷です。
なので敵の追いかけが起動する時の主人公位置を設定できるようにしました。
決めた位置に主人公が行くと、敵が追いかけ始めるという仕様です。

これについてゲームの導入方法として説明書にも書き忘れていたことがありました。
敵の初期の設置位置からおいかけ起動位置までは、障害物がないようにしてください。
主人公の足跡がない場所については敵もどう追っていいかわからないので、単に「この座標へ接近」というような処理をしてます。
ここに書いても仕方ないかもしれないけど、使う人は気を付けてください。

それともう一点、後から気になってきたことがあります。
追いかけの起動は主人公が指定マスに行くことにしたんですけども。
その地点に行っただけでいきなり追いかけ開始というのは汎用性には欠けますよね。
このコモンはやはり探索ホラーなどでの使用を想定しているわけですが。
そうすると、ある地点を調べたら敵が追いかけてきた、という挙動にしたいかもしれない。
うーん、需要としてはどっちが多いんでしょうね。
指定位置に行って起動と、イベント実行で起動とでは。

一応、調べたら追いかけてきたという風にしたい場合の改造方法をここに書いておきます。
コモンの４８行目の変数操作をＸキーで切り取りしてください。
そして調べさせたいマップイベント（決定で実行）の中にＶキーで貼り付けてください。
これでいけると思います。


追いつかれた時の処理も工夫しようと思ったらいろいろ改造してください。
デフォルトでは文章表示（追いつかれた！）をした後にタイトル画面へ戻るようにしましたが。
まあこれはゲーム作者さんによってやりたいことは千差万別だろうから何とかしてもらうしかないです。


その辺りについて、あるいはそれ以外でも、相談や質問、ご意見やクレームなどあればメールでお寄せ下さい。


後日追記
書き忘れてた。
このコモンには、ショートカットモードがあります。
敵が主人公を追跡してくる際、主人公の逃げた軌跡が交差した場合に近道を選ぶ機能です。
もちろんオフにして主人公の逃げたとおりの道を追わせることもできます。

交差した場合だけでなく、軌跡が隣接した場合でも進路変更させてもいいかもしれないですね。
その方がより主人公位置を認識して考えて追っているようにみせられるかもしれません。
今後バージョンアップすることがあれば考えます。

昨夜仲間を動かしてはいけないと書きましたが、その問題の解決法をみつけました。

場所移動を使うことで隊列の乱れはなおります。同じ位置に移動しなおしてもいいです。（一瞬なので見た目はわかりません）
また「パーティー画像」からでききる「全員を主人公の位置にワープ」でもなおります。
仲間を移動したイベントシーンが終わって移動開始になる直前にどちらかを実行すれば、隊列が乱れることはありません。
もしもパーティの隊列がおかしいと思ったら試してみてください。

昨夜の記事がタイトル詐欺みたいになってしまった・・・。

------------------------------------------------------------------------------------
翌日追記
ここに書いた問題を簡単に解決する方法がありました。
次の記事へ
------------------------------------------------------------------------------------


動作指定でパーティーメンバーを動かすことができます。
上に移動とか。
でもこれをしたら、その後のパーティーの隊列の動きがおかしくなります。
右右と2マス動かした後に左左と動かし元の同じ位置に戻したとしても、それでもやはりおかしくなります。

これについて細かく説明します。
まずパーティーメンバーに動作指定をすると、指定した通りの動きをします。
その後彼彼女を引き連れて移動すると、本来いるべき位置を基準として移動で変化した位置関係を保持しつつ、ついてきます。
例えば右上に移動させたのなら、いるべき場所の右上にいつも来ます。

それだけだったらいいんですけども・・・。
その仲間の動くべき場所に行けない場合に問題が起こります。
行けない場合とは、その場所が通行できない場合とそしてその場所がマップ外の場合です。
ひきつれた仲間の挙動も、主人公などと同じようにすり抜けの可と不可を個別に設定できますが。
それですり抜け不可にした日なんかにはもう、すぐにどこかに引っかかっておかしくなります。
そしてすり抜け不可にしなくても、主人公がマップの端近くを移動して仲間の行くべき場所が画面外になった場合にやはりおかしくなります。

なので、仲間を移動して連れ歩いても不具合を起こさないためには・・・。
「仲間をすり抜け不可にしない」「主人公がマップの端に近寄れないようにする」「主人公の通行可能な範囲内に通行不可のマスを作らない」
この3つが必要になります。
まあシナリオ上仲間が最終離脱する際、「さよならー」と離れて行ってその後二度と隊列に復帰しないのならいいかもしれませんけど。
それとかラスボスに挑戦する前とか。
ともかく普通に仲間を連れ歩く途中ではは動かさないことが一番です。

とはいえシナリオイベント時には仲間を動かしたい場面も多々あるでしょう。
そういう時はウディタのシステムに組み込まれた仲間でなく、マップイベントを使うのが賢明です。
仲間を移動したくなったらその仲間を一時的にパーティーから外し、同時にマップイベントの起動条件を操作して出現させ、そちらに対して動作指定してください。


ちなみにさっきから動きがおかしくなるおかしくなると言ってますが、一体どうおかしくなるのかと言えば
・進行方向に応じて隊列の間隔が変わったり
・先頭主人公と別の方向に進むようになったり
などします。
つまりは無茶苦茶です。
ただし動くタイミングだけはさすがに同じですけど。
結束力の弱いパーティーを演出したいときにはあえてこの挙動を利用してもいいかもしれません。
みんなてんで勝手に好き放題、バラバラに動くので。
なお複数の仲間を連れている時に一人だけ移動させると、その一人以外はちゃんといるべき位置についてきます。
これはこれで協調性のない仲間の演出に使えるかもしれませんね。

そういえば。普段パーティーメンバーを連れ歩いているＲＰＧをしていても、イベントシーンではなぜかいきなり主人公一人の画像になり、定位置到着後にメンバーが左右に展開するとかよく見ますよね。
引き連れると事と個別の動作指定との相性が悪いからそんなことになるのかもしれません。


それにしてもこれはバグなのかな。
仲間の動作指定をしてもほとんど使い物にならないという点ではバグと言えるのかもしれませんが。
まあこれをどう利用すればどんな挙動をするのか、検証すればわかるのだから、必要に応じてかしこく使いこなせれたらいいですね。

なお、この記事で言っている仲間を動かすというのは動作指定を使った位置移動のことです。
その場でのジャンプや向きの変更は問題ないので安心して使ってください。

ウディタでマップを移動中、横向けの階段があったら地形に合わせた動きができるコモンを作りました。
こんなかんじ。



横キーを押し続けるだけで階段を斜めに登り、登り終わった時には自動で一マス上に移動しています。もちろん逆にも移動できます。
右向き階段と左向き階段のセットです。

ダウンロードはこちらから
↓↓↓
Common215to216_階段（右上がり）.common
（コモンの場所を二つ使います）

かなりお気に入りのコモンなのですが、汎用性は低く使用条件がかなり厳しいのでこのブログでだけ公開します。


＜使用条件・規格＞
３２０×２４０の画面専用
パーティー人数一人専用
主人公以外のキャラは上り下りできません
ゲームの基本設定で「キャラクターの影」機能は不使用を強く推奨
ゲームの基本設定で「キャラクター移動幅」は半歩専用
階段マップチップの通行設定は移動不可にして下さい（同梱素材なら上下とも。階を上下する時等に同じ素材を使いたい時は階段をマップイベントにしてすり抜けチェックするなどして下さい）
階段の上下マスは通行不可にして下さい。（上マスは階段上部があるからもともと不可ですが、上方から接近した場合にも移動できずおかしいので下レイヤーに通行不可タイルなどを表示して下さい。上の画像でいうとタル）
上下に２つある階段マスのうち、下のマスの真横に立って横キーを押した時だけ登りはじめます。半歩ずれても登れません。
階段を登る途中は半歩たりとも上下移動はできません。
上下や左右、隣接した位置に階段は置けません。


＜使い方＞
ウディタの初期状態から（サンプルゲーム改造）の設定方法を書きます。
コモンを２つあいている所に入れます。
ゲームの基本設定を開き、影を「使わない」にして移動が0.5マスになっているのを確認します。
タイルセット設定を開き、階段（上下）の通行設定を右クリックで不可にします。
レイヤー２などを開き、階段を置きたい位置に階段（下）、上のマスにタルなどを置きます。
その上のレイヤーを開き、タルなどと同じ位置に階段（上）を置きます。
階段の下のマスもタイルかイベント（キャラなど）を置くなどして通行不可にして下さい。
階段の位置にマップイベントを設置して下さい。その際に画像は設定しないでください。
起動条件は並列。
内容には一行だけ、コモンの呼び出しだけをしてください。（左右それぞれに応じたコモンを使用）

これでできるはずです。
同じ向きの階段を複数設置したい時はコモンをコピー＆ペーストし、各階段に一つづつ対応させた専用コモンを用意して呼び出して下さい。

こうして書いてみるとややこしくて難しそうですね・・・。
でもなかなかうれしいコモンなので、興味のある方はぜひお試しを！
改造歓迎、表記や報告は不要です。

プレイして下さった皆さんありがとうございました。

最初にシステム原案を提供してくださったてぃーさん。
感動のシナリオを一字一句書いて下さった及川シノンさん。
イラストとゲームデザインを一手に引き受けキャラの個性も考えて下さったＲｅさん。
おいそがしい中タイトルロゴ他素材を作って下さったはっぷさん。
最終ボスの形態をいろいろ考えて下さったジョゼさん。
作品テーマにふさわしい最高のＢＧＭを作って下さったＣａｓａｙａさん。
お力を貸していただいたにも関わらず一緒に完成を迎えられなかったかた。
Casayaさんと出会う場を提供してくれたゲーム製作サークル√８。
テストプレイで改善点を次々と見つけて下さったへっじほっぐさんとＮＡＮさん。
ありがとうございました。

fairy song〜歌う革命〜が思っていたより多くの方に楽しんでもらえているようでうれしいです。
あのゲ―ムの魅力は音楽・シナリオ・デザインに尽きるのですが、システム面としては「スキップ機能があってよかった」という感想をお聞きしました。
スキップさせるコモンは公式コモン集でも見かけた気がしますが（中は確認していないのですが）、この記事では自己流で作った方法を紹介します。

まず文章スキップではないのですが、オープニングにある文章スクロールでは文章移動中でもシフトを押すといつでも次に飛べるようにしました。
これは最初に文字列ピクチャを２３００ﾌﾚｰﾑかけて指定座標まで移動するように設定しています。
その後に回数つきループを置き、回数は２３００回に設定しています。
そしてそのループの中でまずスキップキーのキー入力を取得し、押されていたらループから出で移動中文章を消すようにし、押されていなければ１フレームウェイトするようにしました。
これで、毎フレームキー入力をを監視しつつも押されない限りは実質２３００フレームウェイトするようにできました。

イベント中の文章スキップについては、通常やるように文章表示をいくつも連続でならべて、それでキーに応じてスキップさせる方法はぼくには思いつきませんでした。
なので少し手間のかかる方法をとっています。
今回のゲームのイベント部分、会話吹き出し内の表示内容は、全てデータベース内に並べて入れておきました。（そのデータベース入力する際にＣＳＶ入力の便利さを知りました）
イベントが始まったらやはり同じくループ内でキー入力を取得し、押されてたらループから出る、押されてなければ「何番目の文章を表示するか」という変数に応じた場所の文章を表示してその変数に＋１する、というようにしました。
（顔グラ番号を指定する数値も同じ文章の冒頭に入れたのですがそれはまた別の話です・・・）

これらのやり方が普通なのかそうでないのか知りませんが、同じようなものを作りたいと思っている人にもしも参考になればいいと思います。

fairy song〜歌う革命〜は非暗号化での一般公開予定はありませんが、システム上の質問などありましたらメールで連絡をもらえたら対応させてもらいます。

現在製作中のゲームではマップを歩くのですが、主人公のみピクチャで表示するためＮＰＣ（以下キャラ）との重なりを調整するために使用ピクチャ番号を切り替えます。
＜関連ページ：主人公のピクチャ番号をどうしよう？＞

キャラが近くにいる場合のみピクチャ番号を大きくすることで、主人公が後ろに隠れるのを防ぎます。
ここで、特定マスにキャラがいるのかどうか判定する必要がでてきます。

それをするにはいろいろな要素を加味せねばならず、頭がこんがらがったのですが、表に書いて整理することでようやく見通しが立ったので忘れないように書いておきます。


特定マスにキャラがいるのかどうかをみるには、自分ルールを２つ作ればあとは変数操作＋を使った条件分岐２つで判定できそうです。

＜自分ルール２つ＞
・通行不可タイルにはキャラを置かない
・キャラの「すりぬけ」にチェックを入れない

この前提があれば、「タイルのみ」と「タイル＆イベント」の二種の通行設定をみるだけでいいです。




「タイルのみ」が通行可能でなおかつ「タイル＆イベント」が通行不可の場合のみ、そこにキャラがいると分かります。それ以外の場合はキャラはいません！

こう書くとシンプルなんですけど、これを思いつくまでにはイベントＩＤを取得してイベントの有無をみるとか画像設定しないマップイベントをどう判定するかとかいろいろ考えました。難しかったです。

自分ルールに例外を作りたい時も出てくるかもしれませんが、その時は「プレイヤー接触」でピクチャ番号を変更するような仕組みを個別に作って対処しようと思っています。

fairy song〜歌う革命〜の紹介サイト

こちらにおまけページができました！
fairy song〜歌う革命〜の世界をより楽しんでもらえる場所なので、ゲームを気に入って下さった方にはのぞいてもらいたいです。
ただしここを見るにはパスワードが必要です。
「HappyEnd」クリア後に「イベントリスト」を見てもらうとヒントになる文章があるので、まだのかたはぜひまずは「HappyEnd」クリアに挑戦して下さい！

今までウディタで作品をいくつか作ってきたぼくなのに、こんな基本的なことをわかってなかっただなんてびっくりしました、というお話・・・。

マップイベント起動条件「決定キーで実行」についてです。
この起動に、通行設定が関係してるってしっていました？
ぼくは知らなかった・・・。
今までなんとなく感覚的にやってたんですね。

マップイベントの位置に主人公が行けない場合、隣接マスからそちらを向いて決定を押せば実行。
マップイベントの位置に主人公が行ける場合、同じ位置（※）に立って決定を押せば実行。

（※さらによく確認したところ、歩幅設定が半歩の場合は左右のズレは全くない状態でないと起動せず、上下の場合は半歩のずれがあっても起動するようです。）

そのような仕様になっています。つまり気をつけるべきことは
マップイベントの位置に主人公が行ける場合、隣接マスからそちらを向いて決定を押しても実行しない！
ということです。

感覚的にはわかっていたから問題はなかったけど、意識したこともなかったです。
行ける場合、行けない場合と言うのは文字通りの意味なのですが。
通常ＮＰＣに話させる場合など、主人公やキャラを「すりぬけにチェック」しない限りはキャラ画像位置に行けないため、自然と隣接マスから話しかけることになり決定で起動できます。
またマップイベントにキャラ画像を設定しない場合（つまりそのマスを自由に通行可）でも、たとえばマップチップの配置で崖の上にマップイベントがあってその下から主人公が決定を押す場合それでも「行けない」には違いないのでやはり隣接マスから決定で起動できます。
でも行ける時は行かなきゃダメ！ということですね。

行ける行けないによって挙動が違うとは、驚きました。
ウディタを使う人なら初心者でも「画像のあるＮＰＣには話して実行」「足元が怪しい部分で決定キーで調べて実行」ということをすんなり実現できます。
これはよく考えたら別のことをやっているのですが、それが同じ「決定キーで実行」で実現できて感覚的なゲーム作りが可能になっていることは本当にすごいと思いました。

以前こちらでひっそりご紹介した自作ゲーム、fairy song 〜歌う革命〜が完成し、ウディコンにエントリーしました。




画面はこんなの。


一応ぼく個人名義の作品になってはいますが、多くの方に深く深く関わっていただき、事実上共同製作でした。
自分ひとりの力では決して作れない作品ができました。
シナリオがすごいです。
グラフィックもすごいです。
音楽もすごいです。
テストプレイヤーの方にも助けられました。
感謝してもしきれません。

ゲーム内容は、シミュレーションです。
舞台となる「カノン王国」には音楽にこだわりのある国民たちが大勢います。
１０日に一度演奏会を開いて彼らの満足する曲を聴かせ、仲間にしてください。
そのためには日々音楽の練習をしたり、その他いろんなことにいそしむことが必要です。
５１日目に何人が仲間になっていたかでエンディングが分岐します。

ベストエンド（国民全員が仲間になる）が一番見てほしいエンディングなので、難しいかもしれませんがぜひチャレンジしてほしいです。

遊ぶ上での注意点は・・・。
イベントをスキップする時は左シフトキーを押す！
国民参加条件にある連続とは「現時点までの連続回数」なので別行動でリセットされる！
その２点だけ覚えておいて下さい。
（ここを見ただけでは何のことかわからないと思いますが）

ウディコンの順位にはこだわりませんが、関わって下さった方々に「手伝ってよかったー」と思ってもらえる結果が出せたら嬉しいなと思っています。

fairy song 〜歌う革命〜の紹介サイトはこちらです。

ウディタで主人公をピクチャとして表示するとアニメーションの切替パターン数を自由に設定したりいろいろできて便利ですが、その一方でデフォルトでは当たり前だった機能が使えず、工夫が必要となります。
この記事では主人公をピクチャ表示する時、ピクチャ番号は何番にするのがいいかを考えてみます。

ちなみに今回考えるのは、サンプルゲームのウルファールだけをピクチャ表示する場合です。
つまり主人公以外はデフォルト。地形にはタイルセット、他キャラにはマップイベントを使用します。
（全キャラをピクチャ表示したりすればまた話は変わってきますけどね。それはおそらくですが、ソフトニシンさんの鏡面床コモン改をちょっと劣化改造すればできると思います。興味のある方は挑戦して下さい）

主人公だけピクチャで表示するには、ぼくが公式コモン集に登録した「主人公演出セット」に入れたコモンを使ってくださいね。

さて、ピクチャ番号、どうしたらいいでしょう。
ピクチャ番号を迷った時にぼくがいつも見るのは公式マニュアルの「ピクチャ」の説明です。
ここに貼りつけさせてもらいます。
これは今まで１００回以上見たと思う。いい加減覚えろって感じですね。
　
　・ピクチャ番号が100000(10万)未満なら文章や選択肢の下に表示
　・ピクチャ番号が100000(10万)以上なら文章や選択肢の上に表示
　・ピクチャ番号が-1〜-99999なら、マップの上、かつ、イベントの下に表示
　　（★属性などの一部チップはピクチャの上に表示されます）
　・ピクチャ番号が-10万以下なら、マップの下、かつ、遠景の上に表示

まず、タイルセット設定の「後ろに行くと隠れる」機能は使いたいです。
なので-1〜-99999がいいですね。
デフォルトの木の上部やテントなどとの重なりを違和感なくしようとすれば、これは必須です。

ところが！
それでは問題が！
それは他キャラとの重なり方です。
「-1〜-99999なら〜イベントの下に表示」とのことなので、これでは主人公なのに他キャラより下層になってしまいます。
それも街の人などならまだよくよく見ないと分からない程度ですが、馬とか、横長キャラだと重なりがおかしいのは一目瞭然です。
なのでキャラの横にいる時はピクチャ番号は正の値がいいですね。
キャラの下（画面座標ｙ座標という意味での下）だとどうでしょう？
下でも同じく主人公が上層がいいので正の値がいいです。
一方、主人公がキャラの一つ上のマスにいる時は下層がいいので負の値がいいです。


「後ろに行くと隠れる」「他キャラとの適切な重なり」これを両立する一つのピクチャ番号はないようです。
面倒でも何とか小細工するしかないですね。

ぼくがした方法を書きます。
常時並列コモンで主人公の下や斜め下のマスにイベントがあるか常時判定します。
イベントがある時だけ、ピクチャ番号は負の値に切り替える。

また、「後ろに行くと隠れる」を使いたい個所付近には「プレイヤー接触」起動のイベントを敷いておいてピクチャ番号は負の値に切り替える。

「後ろに行くと隠れる」の近くにはキャラクターは置かない。
縦に上下、二人のキャラは並べない。
・・・こんなところです。

なおピクチャ番号の切り替え時には、それまでのピクチャ番号を消去するのを忘れないでください。
さもないと切り替えた地点に残像が残り続けてしまいます！
切り替えと同時にピクチャを消去したら一瞬主人公が消えたので、発動ディレイを２フレーム後くらいにしたらうまくいきました。

まあ、全キャラ高さも横幅も１マスサイズである１６ピクセル以下のものしか使わなければそんなことは悩まなくていいんですが・・・そうもいきません。

こういうことをやっているとデフォルトがいかに親切だったかがわかりますね。
ほら、これなんか。








下の馬と、上の馬と、その間の高さの主人公、３者がそれぞれ適切な階層に表示されています。
ぼくのやり方ではこれは難しいのです。
ちょっとした、気付くかどうかというくらいの重なりなんですけどね。
でもやっぱりこういう部分にこだわってみたい気もします。


追記
なんと、これと同じことをなさって同じことを説明されているブログ記事を発見！
しかもぼくの文章よりもわかりやすい！
勝手にリンクはっていいんだろうか・・・。
「リンクはご自由にどうぞ。」とあるぞ・・・じゃ、いいっか。
主人公のピクチャ表示に興味のある方はこちらも参考になさってください。

　SUGAR　STAR様のページ

メロン企画というサークルの新作脱出ゲームウルファールの地底迷宮が公開されました。
ダウンロードはこちらから。
↓↓↓
ウルファールの地底迷宮.zip

ぼくはシステム担当として参加しました。
ゲーム内容は迷路です。
謎解きやフラグ立て、アイテム収集などの要素は一切ありません。
リソース管理といったことも（プレイヤーの時間を食う以外は）ありません。
シナリオやイベントはありますが、必須イベントは全て正解の経路上に配置しました。
迷路だから分かれ道は当然ありますが、攻略に関しては一本道です。
面白いかは別にして、結構納得のいく形のゲームができたと思っています。
これを突き詰めたらノベルになっていくのだろうなー。
素材は既成概念を吹き飛ばすクオリティのものを厳選しました。
短いゲームですのでお暇なときにどうぞ。

※このゲームは一時期ふりーむ！に登録していましたが現在はこのページから直接ダウンロードできます。
ふりーむ！にコメント下さった方、見れなくなって申し訳ありませんがありがとうございました。

大した内容ではないしウディタメモの一項目として書こうかと思いましたが、ちょっと簡潔に説明できなかったので一つの記事にします。

さて、タイトルですが何のことかややこしいですね。
例えば
ｖ１＝１
ｖ１＋＝３＊６
とした時、Ｖ１の値はどうなるのか。
これの答えは
ｖ１＝（１＋３）×６＝２４
になるか、あるいは
ｖ１＝１＋（３×６）＝１９
の、どっちかだろうと思うのですが。
みなさんわかります？

ぼくはわからなかったので調べてみました。
すると意外や意外、＜＜ERROR＞＞と表示されました。
等号以外を選んで項目二つを使うと計算できないんですね。
これは知らなかった・・・。
確かにそれがいいと思う。まぎらわしいし、数行に分けたらすっきりできることなので。

これについてどこかで説明されてるかと思い検索しましたが、ざっと見たところみつかりませんでした。
公式マニュアルでも見当たらないし。
まあそういう計算は「させないこと」になっているんでしょうね。
毎日のようにウディタを触っていますがまだまだ知らないことがたくさんあります。

この記事には書き足していきます。
・イベント挿入でマップイベントを呼び出す際、ページを指定するのには変数呼び出し値は使えません。

・通行不可について
変数操作＋で取得できる「指定座標位置の通行可能」は主人公のものです。
一口に通行可能と言っても通行するのが主人公かＮＰＣかによって意味が変わります。
ＮＰＣは画像未指定のマップイベントでも「すりぬけ」チェックをしていない限り通行できません。
けれども「すり抜け可でないの画像未指定のマップイベント」の有無は変数操作＋ではわかりません。

・キー入力について。
キーボード全入力受け付け時に複数のキーが押されていたら、キーコードの小さい方が入力されるようです。

・ファイル名末尾をX.pngやTX.pngにした歩行グラ素材を使うとキャラ停止中の画像も指定できるようになるのですが、その際に「変数操作＋」で「アニメパターン」を取得しても通常素材使用時と同じパターン番号しか返ってきません。
（現在連続移動中かどうかの正確な判定に使いたかったのですが無理でした）

・複数の並列起動のマップイベント内で、それぞれ別のコモンを呼び出します。それらのコモン内で「呼び出し元マップイベントの座標」を取得します。すると取得した値がおかしいことがあります。
並列起動ではきっとコマンドの流れを正しくたどれないのかもしれませんね。
（緑帯エラーでそういったことを見かけるので）

・同じく並列起動について。
並列起動のコモンイベントだと、現在のマップＩＤはちゃんと取得できるのに変数呼び出し値を使った「マップイベントYのセルフ変数X」への代入はできないみたいです。困ったことです。
（やむをえず「予備変数＜マップＩＤ＞の＜イベントＩＤ＞」というのを全マップの全イベントに割り振ってマップイベントを一括管理しました。かなり荒っぽいですが！）

・動作指定のジャンプをする時、移動する距離はコモンセルフ変数では指定できないようです。残念。

・同じくジャンプする時、ジャンプ先が通行不可ならジャンプしません。あたりまえ？
ジャンプさせたければすり抜けオンにしてからめりこませましょう！

・精密座標を使う時の注意点。取得地点はマス目の左上。なので、隣接マスの通行判定などをする時に大きなワナが・・・。左右、上下によって隣接マスへの距離が違うのです！上に1ずらすと隣接マスですが、下に１ずらしてもまだ基準マス内なのです。考えたら簡単なことですが、気付くのに時間がかかってすごく悩みました。

・ピクチャ表示の拡大率について。
５０％にしたら、横幅半分、高さ半分に表示します。
２００％にしたら、横幅2倍、高さ2倍に表示します。
拡大率というのはＸＹ各軸の長さに対する割合であって面積のことではないんですね。
（５０％表示だと面積は２５％になるんですね）

パターン数を増やすこと、できました！

(この記事を書いた３年後に公開できました！詳細はコチラ)

方法は以下の通り。技術的には特に変わった方法は使っていません。

まず、前に書いた「ざっくり言って移動中？」とでも呼ぶべき指標を作りました。
「主人公移動中？」が０の状態が２フレーム以上続いた時だけ主人公停止と判断します。
主人公が移動開始したら、常時その瞬間瞬間が移動開始後何フレーム目かを計ります。
その値を、自分で決めたアニメ切替間隔（単位はﾌﾚｰﾑ）で割ります。それは現在の瞬間は移動開始後幾つ目の画像を表示すべきか示します。
その幾つ目かの値を、アニメーションの一周期に使う枚数で割った余りを求めます。
その余りは、今の瞬間に表示すべき画像が一周期内における何枚目かを示します。
それと別に、一周期内における何枚目かがそれぞれどの画像を表示するかを指定しておきます。
（今回の場合は素材画像は連結されたものをつかったので、該当箇所を指すパターン番号を指定しました）
後は、前に作った「主人公画像をピクチャ表示するコモン」を劣化改造して使います。
適切な分割数を設定した指定素材の指定パターンを、常時主人公位置に表示します。

ちゃんと動きましたよ！
これを使えばアニメーションの枚数は好きなだけ増やせます。
アニメーション切替間隔も細かく設定できます。
デフォルトの切替順は「行って、戻って」を繰り返し循環しますが、これは自由な順に表示できます。
素材規格も、一枚一枚バラバラだろうが、並び順等も、自由自在です。

でも素材作りは大変ですね。
まあ横スクロールアクションとか、左右向け表示しかしない時には使いやすいかもしれないです。
（ピクチャ表示の為左右反転もコモン内でできるので、片側向き素材だけあればできます）
このコモンはとりあえずは公開はしません。
けれどいつか公開するかもしれません。
自作してみたい人はメールでご相談下さい。

今までにないものを作りたい！と意気込んで始めた今回の連載でしたが・・・。
実際作ってみると単に粛々と作ったらできたという、記事としては面白みのない結果になりました。
まあ実現できたことは画期的だとは思います。
いつか皆さんにお披露目できる時も来ると思うので、どうぞお楽しみにー。
（「歩行アニメーションのパターン数を増やしたい」の連載企画、これにて完。）

例によっていつものごとく、恥をさらします。
前々回の記事にて。

「アニメーションパターン切り替えのウェイト」なんていう項目がないかと思ったのですが・・・・・どうも見当たらないようです。
いくらウディタは何でもできるとはいえ、さすがにそこまでは設定できないのかもしれませんね。

と書きました。
・・・イベント制御のキャラ動作指定から、「アニメ頻度」を7段階で設定できました。
ぼくだって知らなかったはずはないのに・・・。
初めて作ったゲームでも使いまくっていた機能なのに・・・。

しかもそれに気づいたきっかけは、速度変更と間違えて気付かずにアニメ頻度変更していたのです。
そんなはずがないのに、いきなりアニメ間隔が昨夜と全然変わったので、ぼくはあまりの衝撃で一瞬何もかも信じられなくなりました。
まあ時間はかかりましたが原因究明でき、アニメ頻度指定機能の存在も思い出せたので、よしとしたいです・・・。
つづく。

デフォルトの歩行アニメーションの切替間隔が何フレームあるかを調べました。

＜調べ方＞
以下のコマンドを常時並列コモンで実行しました。（こんなのに興味のある人はいるかな）
なんとなく誤差がありそうですが、まぁあっても１フレームじゃないでしょうか。

■ウェイト：1 フレーム
■変数操作+: CSelf11[今のＰ番号] = 主人公 の アニメパターン[0-4]
■条件分岐(変数): 【1】CSelf11[今のＰ番号] が CSelf12[前のＰ番号]と同じ 【2】CSelf11[今のＰ番号] が CSelf12[前のＰ番号]以外
-◇分岐： 【1】 [ CSelf11[今のＰ番号] が CSelf12[前のＰ番号]と同じ ]の場合↓
|■変数操作: CSelf13[今になってからのフレーム数] += 1 + 0
|■
-◇分岐： 【2】 [ CSelf11[今のＰ番号] が CSelf12[前のＰ番号]以外 ]の場合↓
|■文字列操作：CSelf5[表示文字列] += "\cself[12]番を表示した時間は\cself[13]フレーム\n"
|■変数操作: CSelf13[今になってからのフレーム数] = 0 + 0
|■
◇分岐終了◇
■ﾋﾟｸﾁｬ表示：15 [左上]文字列[\cself[5]] X:381 Y:0 / 0(0)ﾌﾚｰﾑ / ﾊﾟﾀｰﾝ 1 / 透 255 / 通常 / 角 0 / 拡 50％ / ｶﾗｰ R[100] G[100] B[100]
■変数操作: CSelf12[前のＰ番号] = CSelf11[今のＰ番号] + 0

＜結果＞
連続移動中の切替は、この調査方法では５ﾌﾚｰﾑと４ﾌﾚｰﾑ交互に行われているように思われました。
具体的には、

３パターンの場合は（上段がパターン番号、下段が上段のパターンを表示し続けたﾌﾚｰﾑ数）
１０１２が
４５４５

５パターンの場合は（同）
３４３２１０１２が
５４５４５４５４

・・・となりました。
移動速度を変更しても切替間隔は変化しませんでした。


＜考察＞
まず疑問に思うのが、なぜ交互に間隔が５と４で変わるのかです。
ぼくの調べ方がまずいのかもしれませんが、それもよくわかりませんでした。
この数字を信じるなら１周期の表示をするのに１８ﾌﾚｰﾑかかっていますね。

昨夜調べてわかったのですが、一番遅い移動速度で１マス進むのに、３パターンだと１周期表示が巡るようです。
移動時間（マス/ﾌﾚｰﾑ）なんて基本的なことだからどこかに載ってないかと検索しましたが、ぱっと見では見当たらなかったです。

デジタルの原理は不案内なのですが、１８なんて１６に比べたら扱いやすいわけではないだろうに、全パターン４フレームにするわけにはいかなかったのでしょうかね。
やはりぼくの計り方がおかしいのでしょうか。
各パターン番号の表示内容と表示時間の関係に意味があるのかとも思いましたが、３パターンと５パターンで一貫性はないですね。
３パターンの場合は右足や左足が出てる時は長く、切替中の過渡期は短いです。
一方で５パターンでは足が出てる時と基本姿勢が短く、切替中の過渡期は長いです。

あ、まさか、全ての表示は４．５フレームで行われてるけどそれを計測したら処理の関係でこのように見えてしまうとか？
ウディタは何をするにもフレーム単位でしか動けないヤツだと思ってましたが、ひょっとして違うという可能性もあるのかな。
うーんよくわからない・・・。

--------------------------------------------------------------------------------
後日追記
この記事を書いてる時点で、アニメ頻度は変更できるということをすっかり忘れていました。
なので、ここで４５４５４５とか書いたのも7段階あるうちの一つの間隔に過ぎず、それほど深く考えるべき内容ではなかったと後でわかりました。
またこの記事で使った「ﾌﾚｰﾑ」という言葉は、計測したところ、定義である「一秒に60回」の半数以下という結果になりました。謎です。
このあたりのことは今でも理解できていませんが、ともかくこの記事の内容は鵜呑みにしないでください。
--------------------------------------------------------------------------------



＜今後の展望＞
これはまずいことになってきましたよ。
歩行アニメーションのパターン数を増やしたいということで始めた今回の試みですが・・・。
各パターンの表示時間を２分割すれば２倍の枚数のグラフィックでなめらかアニメーションができると思ってたのに、まさか複数の表示時間が混在していたとは。
けれどよく考えてみれば、枚数を２倍にしたら偶数になりますね。
偶数ならどこかでカクッとなってしまい、なめらかにアニメーションできない気がします。
「片側にふれて戻って反対にふれてもどって」、この動きは偶数じゃ帳尻が合いませんよね、多分。
表示時間を３分割すればいいんだけど、けれども４も５も、３では割れない・・・。
一体どうしたもんでしょうか。


今日の記事は「調査研究考察」というカテゴリーにしますが、それはここまで。以下は昨夜の続きのいうなれば「雑文」です。
せっかく「現在表示中のパターン番号」を取得できるんだから、それを使って「現在表示すべき画像」を決定したらいいと思ったのですが。
でもデフォルトのアニメーションがどうなっているか大体わかった今、アニメーションのパターン数を増やすためには、原理的にはデフォルトのパターン番号は関係ないですよね。
これを実現するために知りたいことはただ一つ。
現在の瞬間は移動継続中かどうか。それだけです。

そのための方法は３つくらい思いつきます。
一つは、今まで考えた「現在表示中のパターン番号」を使う方法。
この値が停止中の番号じゃなくなったらその瞬間から移動開始と分かります。でも移動終了判定が難しい。
アニメーションの途中でも停止の番号になりますもんね。
これをもとに停止の判定をするなら、その番号が４あるいは５より長いﾌﾚｰﾑの間続くことを見届けないといけません。
移動が終了しても６フレームくらいの間は画像は前のままです。
特に連続移動はしているけど移動方向を切り替えた場合の表示がおかしくなりそうな気がします。
なめらかさを追究するのに、６フレームの判定遅れはまずいですよね。デフォルトの方がましっていうレベルです。

別の方法は、全て手づくりでコツコツやる方法。
キー入力を参照して、移動先の通行設定も判定して、連続移動を判定します。
マスとマスの間を移動中のタイミングでは方向キー入力は受けつけないので、その瞬間だけ方向キーが押されてなくてもノーカンです。
なんだかできる気がしない・・・。

そして最後の方法は、システム変数の「主人公移動中？（1=Yes）」を使います。
でもこれの困った所は、マスの真上にぴったり重なった瞬間は連続移動中でも０になってしまうことです。
移動中にこの値を常時並列コモンで表示し続けると、０になる時とならない時があります。
（だいぶ前に初めて立ち鏡を作った時「鏡の前を横切っても映る時と映らない時とがあります」と書きましたがそれに通じるものがあるんでしょうね）
けれど今これを試していて不思議なことに気づきました。
最初確かに０になる時とならない時があって、切り替わり続けるのですが、しばらく歩き続けると、ある時を境にして、移動中は１、停止中は０という完璧な判定になります。
判定タイミングの問題なんでしょうけどね。
処理中に１フレームウェイトを入れるといつまでたっても最初と同じまま、切り替わり続けます。
わけがわかりません。

これらの方法はどれも一長一短でなかなかいい方法はないんですけどね。
しかしここであきらめるわけにはいきません。
なので次回の記事では、上に書いた３つ目の方法を使って考えてみます。
「主人公移動中？」が０の状態が２フレーム以上続いた時だけ主人公停止と判断する、「ざっくり言って移動中？」とでも呼ぶべき指標を作ろうかと思っています。

歩行アニメーションのパターン数とは、ウディタでキャラを歩かせた時に表示される画像の数のことです。
ウディタではその枚数は３枚か５枚を選択することができ、デフォルトのウルファールなどは３枚になっています。
この枚数をもっと増やせたら、更にリアルな表現ができるのでは？
・・・というわけで、さっそく考えてみることにしました。
そんなに手のかかる素材を用意できる人がどれだけいるかということは気にしない！


＜デフォルトの歩行アニメーションパターンの仕様＞

そもそもウディタにあらかじめ備わっている歩行アニメーションは一体どのようなものなのか。
まずはそれを調べました。

変数操作＋で取得した現在の瞬間の主人公の表示中のパターン番号を、常時表示してみました。





ちなみに使用しているファイル名末尾は通常の「.png」です。
（これをT.pngやTX.pngにすると、また違う挙動になるそうです。公式マニュアルに説明があるのですが、読んでも意味がよくわかりませんでした。まあそれはいいとして）
画像もなんだかよくわかりませんが、キャラを歩かせながら、その瞬間瞬間表示中のパターン番号を表示しているのです。
これでいろいろ試して、いろいろなことがわかりました。

・移動速度を一番遅くしパターン数５で歩幅が１歩だと、移動したら２３４３２１０１２の順で表示された（多分）
・移動速度を一番遅くしパターン数５で歩幅が半歩だと、移動したら２３４３２１２の順で表示された（多分）
・移動速度を一番遅くしパターン数３で歩幅が半歩だと、移動したら１２１０１２１の順で表示された（多分）
・移動速度は通常でパターン数３で歩幅が半歩だと、移動しても１のまま変わらない場合と１２１の場合がある
・移動速度を変更しても、おそらく１パターン当たりの表示時間は変わらない

つまり、歩行アニメーションとは・・・。
移動開始後から移動終了するまでの間、一定間隔で画像を切り替え続ける仕組みのようです。
移動が終了すると、表示周期が終わっていなくても強制的に停止時の画像に戻るようですね。
えっ？そんなこと知ってたって？
ふだんゲームを作ってもプレイしても、ぼくはアニメーションはそれ程意識していませんでした。
自然な動きだなとか、変わった動きだとか思うことはあっても、その切替間隔がどうなっているかまではなかなか意識がいかず・・・。
頭で考えると、パターン数５なら一歩移動する間に５種類の画像が表示されるのかと思ってしまいますが、必ずしもそうではないんですね。
表示間隔がミソらしいです。

まさかこの間隔をいじったりはできないでしょうね？
と思って、念のためにシステム変数などをチェックしてみました。
「アニメーションパターン切り替えのウェイト」なんていう項目がないかと思ったのですが・・・・・どうも見当たらないようです。
いくらウディタは何でもできるとはいえ、さすがにそこまでは設定できないのかもしれませんね。

さて、デフォルトの歩行アニメーションパターンの仕様はわかりました。
ではどうしましょう？
３枚と５枚あるデフォルトに、１枚や２枚をさらに追加するのは大変そうです。
けれどもぼくには心強い味方、主人公画像のピクチャ表示コモンがあります。
あれを使えば「従来表示すべきパターン番号」を判定し、それに応じて従来と違った画像を表示することもできます。
そこでぼくは考えました。
まずデフォルトの表示切替間隔を調べます。
それを２で割ります。
移動中に表示するパターン番号それぞれに対して、前半はこの画像、後半はこの画像と設定します。
移動開始したら現在パターン表示開始後の経過時間を常に取得すれば・・・。
そう、パターン数を２倍に増やして、なめらかな表示が実現できるはず！
きっと！多分！

この記事はいったんここまでにします。
次回、デフォルトのアニメ−ションの表示切替間隔を調べたいと思います。

ウディタリアンに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問もあればぼくの核心的な部分を引き出してもらえるかと思いましたが、なんだかまだまだ語り足りないような気もします。
けれども書くことで整理できた部分もあるだろうし、ありがとうございました。
今後はブログ記事でも自分語りを増やしていくかもしれません。

「ウディタでギターコード」というソフトを作りました。

ダウンロードはこちらから

ギターのコードが弾けます。
かなり限られたコードだけですが。
Cで始まるコード進行の曲などが弾けると思います。
こんなのを作ると、本物のギターがいかにすばらしいかよくわかりますね。
アコースティックなら電気もいらず、超高音質（生音ﾅﾏｵﾄ！）でしかもギターで出せる音は全部出せる！
同じことをウディタにやらせようとしたらどれだけ大変なことか・・・。
作成は一日ほどでしたがキー入力や効果音再生のいい勉強になりました。
軽量化にはとことんこだわりましたよ。驚きの軽さ、2.8MBです。
音素材はletsspeakさんのブログからお借りしました。
まあピアノで例えるなら、幼児用のおもちゃの鍵盤（黒鍵のないやつ）みたいなもんです。
けど、触ってるとちょっとそれなりに面白いですよ。
ギターなのに音はピアノなんですけどね。しかもノイズが激しい・・・！
誰か改良して下さい。
非暗号化です。コモン一つしか使用してません。
思えば基本システムを完全に消したゲーム（じゃないけど）は初めて作りました。
そして別に大したものじゃないのに、ウディタ公式サイトの初心者作品登録ページにも載せました。
あそこに載せるのは何年かぶりです。
起動すると画面が表示され、ZもXもEnterも方向キーも受けつけないので焦るかもしれませんが、ご安心を。
起動後はいつでも好きに演奏できます。気が済むまで。
ギター触ったことない人も気軽にお試し下さい。
ギター触ったことない人は好きな歌のコード（譜面や歌詞にCとかFとか書いてるやつ）をどこかから探してきて、それを見て歌いながら適当に操作したらそれっぽく雰囲気が出てヤミツキになるかもしれません。

ある掲示板で「フリーゲームのテストプレイ承ります」というサークルを見つけました。
へっじほっぐさんといいます。
へっじほっぐさんのホームページはこちら。

ぼくの制作中のゲーム、fairy song〜歌う革命〜のテストプレイをお願いしたところ、快く引き受けていただきました。
そして不具合をどんどん見つけていただき、的確な指摘をくださっています。

それにしてもテストプレイするサークルって珍しいですよね。
ぼくは他には聞いたことがありません。
そもそもどうしてそんなサークルができたのか。
何を目的にしているのか。
興味を抱いたぼくは、ぶしつけながらお聞きしてみました。
そのＱ＆Ａを掲載します。
-------------------------------------------------------------------------

Ｑ１どうしてしようと思ったんですか？

Ａ.とある会社のアルバイトをしていました。業種はデバッグでした。初めてだらけでどっぷり仕事の魅力にはまったものの、体が弱く通いづらいことがあり、辞めてしまいました。それでも夢にデバッグがでてくるので家で趣味で始めようと思いました！



Ｑ２目指すところは？
（有償案件をバンバン受けれるようになって収益化？ゲーム文化に貢献？有料ソフトもタダで遊ぶ？）

Ａ.有償無償はサークルがこじんまりしている限りは「こちらで払う代金が発生しない限りは先方様から代金をいただかない」という方針のもとやっていきます。
ゲーム文化に貢献ですね＾＾みなさんのゲームがちょっとでも皆様の手に渡り、評価されるよう願っています。



Ｑ３ホームページを見ると参加作品は「落葉の大地を走れ」だけになっていますが、まだそれだけですか？

Ａ.参加作品はサークルへっじほっぐとしては1作品のみです。



Ｑ４新規メンバーは積極的に募集中なんですか？

Ａ.新規メンバーは私がまとめられる範囲で募集していますが、18歳高校卒業していらっしゃる方のみですね！

----------------------------------------------------------------------
とのことでした。
なるほどなるほどー。

夢に出てくるって、本当にお好きなんでしょうね。
好きで楽しみながらやって、それでゲーム文化に貢献！
しかもそのために、誰もやっていないことを自分で考えてやり始めるってすごくかっこいいですね！
ぼくの作ったゲームが映えある2作品目になるのは光栄です。

フリーゲームを作成される方、もしいらしたら、テストプレイが必要な時はぜひ相談してみたらいかがでしょうか。
また新規メンバーも募集中とのこと、興味のある高卒以上の方はぜひ問い合わせてみて下さい。

かおグラＭＡＫＥＲというツールを発見しました！
バーツごとの位置移動や角度回転、左右反転や色調変更、そして当然ながら画像出力もできるようです！
おおおぅ！！！
カオメーカー制作企画はこれをもちまして終了します・・・！
このそそっかしさはどうにかしないとなぁ。
それにしてもこんな高機能ツールがあるのにウディタ作品の顔グラが同じものばかりになるのは一体どうしたわけか・・・？

春ですね。
万朶の桜が雨にぬれています。
ゲーム作りもちょっと一段落つきました。
そこでゲーム制作中に考えついた構想をここに書きます。

顔グラ合成器の拡張版を作ろうと思うのです。
名付けて「カオメーカー」！！！（仮称）
クリエイターのはしくれなんだから、作るとか言わずに「作った」と言えばいいだけかもしれませんけどね。
けれどこれはとても大きな企画になる可能性があるので、頭を整理するためにも、風呂敷を拡げつくすためにも、ここで文章化して公開して、自分で自分を追い詰めてみたいと思うのです。

そもそもの発端は・・・。
ゲーム作ってた時に、デザイン担当さんが表情差分の素材をたくさん用意して下さいましてね。
（おかげで活きいきしたキャラの表現ができました！）
例えば汗を垂らすだけなら、ウディタでもできるな、とか思ったのも着想のきっかけです。
それと、ふくわらいという古典的遊戯ですね、あれをウディタでできるかなとか思ったのもありました。
それらは同時発生的でした。多分。

それに加えて、今回のゲームでは「カーソル現位置に応じた処理をする」ということをとことんやりました。
ピクチャ表示については以前から「主人公ピクチャ表示コモン」などで経験はありました。
それらを組み合わせたらなんとかできそうだと、自然に思いつきました。

そもそも顔グラ合成器ってご存知ですか。
ウディタ作品でよく使われている、顔グラを合成できるツールです。
ぼくもネオ繚乱記では使わせてもらいました。
絵心のない自分のような人でも手軽に顔グラが作れる、すばらしいツールです。
その人気たるやすごいもので、ウディタ作品の数割はこのツールを利用して作られているように思います。
ただそのため、似た顔があふれてかえってしまっているのが残念なところですね。
それぞれの作者さんは自分だけの顔を作ったつもりなのに、結果はどこかで見たようなものになってしまっている。
顔グラ合成器に似たツールにキャラクターなんとか機というものもありますけれども。
使用したらわかる人にはすぐわかってしまうという点ではそれも顔グラ合成器によく似ています。
けれどもそんな状況は、顔グラ合成器の機能の自由度を高めれば、解決できるのではと思いました。

そうなると問題は、そもそもそんなものを作るスキルがぼくにあるのかということです。
プログラムは知らないし。
でもウディタを使えばきそうです。さすがウディタ、最高〜！
ウディタは画像の扱いが自由自在なので、顔グラ合成器の機能を拡張するのは簡単です。
後はネックになるのは、操作性や分かりやすさかな。その辺りは工夫したいです。

顔グラ合成器では顔パーツを組み合わせることができます。
色調の変更もできます。
ウディタを使えばそれに加えて何ができるか。いっぱいできますよー。
・各パーツの表示座標指定
・透明度設定
・表示角度指定（回転）
・左右反転
・レイヤー（表示する層）の順番の指定

例えば眉毛の素材を一つ用意すれば、左右の眉毛を、あらゆるサイズで、あらゆる角度で、あらゆる濃さで、あらゆる位置に表示できます。こりゃすごいっ！


ここまで読んでウディタをご存知の方は「え、でもウディタは画像ファイル出力できないやん」と思うかもしれません。ええごもっともです。けれどもできるのです。
それにはスクリーンショット機能を使います。

あ、読んでるあなた、「こりゃあかんわ」と引かないでくださいー！
なんとか実用に耐えるようにはしたいと思っていますので・・・。
まあ、生成される画像サイズは画面サイズになります。
それと透過色指定はできません。
ファイルの生成場所も指定できないです。
でもいいですよね、きっと。多分。
多くの問題はやり方次第で何とかなると思います。

具体的に今考えている方法を書いてみます。
ウディタにDataフォルダを二つ入れて配布します。
（フォルダ名は変化をつけて。片方を使い終わったらフォルダ外にドラッグし、残った方の名をDataにして使用します）
先に使うのははカオメーカー起動用。
もう一つは顔グラ素材作成後、その素材をそのまま普通に使える状態にした初期状態のウディタ。
後者はウディタのサンプルゲームです。
素材の置き場所の移動は手動でしてもらいましょう。
顔グラを表示するコモンに「素材サイズが画面サイズなら、縮小＆画面右端に余白をはみ出させて表示」という処理を挟み込めば、初心者でも気軽に使えるのではあるまいか。
幸いデフォルトの顔グラ表示位置は画面右端なので、余白部分を画面外にできるので好都合です。
カオメーカーの方では、正方形の顔グラを作れるようにします。
（正方形でなくてもいいと思うけど、顔グラ合成器の標準サイズ？が確かそうだったのでそれに合わせます）
その正方形の顔を画面いっぱいのサイズにし、左に寄せて表示します。
つまり画面サイズが320×240なら240×240の顔を描いて、右が余白です。
（画面サイズをどうするかは未定です）
素材の背後は透過できないので、ゲーム上では素材のバックはウィンドウ扱いするのがいいかもしれないですね。
なのでウィンドウっぽくするために枠を作ろうと思います。
まあデフォルトのウィンドウは角が丸いですが、顔のバックは完全な正方形です。
角を丸くしてもその背後を透過できないですもんね。
そういう風にしたら、他の画像加工ツールを使わなくても一応使えるのではないかと思います。

（余談ですが、ぼくが前に作ってこのブログでもご紹介した「ピクチャ分割表示コモン」あれがもっと高性能なら顔グラ素材の余白を非表示にできるんですけどね。あれは原寸大表示が前提なので使えないのです・・・）

あ、書きそびれてましたが、ぼくが考えているのはとりあえずウディタで簡単に使えるように、ということです。それ以上のことはちょっと手に余る・・・。
まあ顔の各パーツの拡大率や表示座標や回転を指定できることに大きな魅力を感じてもらえるのなら、このツールを使って画像を作り、別ツールで透過色指定や余部分白のカット、さらに縮小という方法もできるでしょう。

そしてもしもこのツールがウディタ界隈で大人気になれば、きっと有志の誰かがプログラムを使って多機能合成器を作ってくれるんじゃないでしょうかね。汎用性の高い。（←人任せ）
そのためにも、このツールで需要はあるということを証明できたらなぁと思います。
いや、需要はあるはずだと信じているんです。
絵の初心者でも誰にも似てない自分だけのキャラを手軽に作りたい、そんな需要は必ずあるはず・・・！
このツールが完成して公開して反響がなければ、それは操作性や使い勝手が悪かったせいだろう、と、需要についてはそれくらいに思っていますよっっ。

まあ制約や短所があるにしても、このツールを使わないとできないことがあるのなら、他ツールと併用してでも使ってくれる人もいるでしょう。
まさかこんなツール、もうすでに他にあるなんてことはないですよね。
画像加工ソフトでもレイヤーごとに色んなファイルからパーツを取り込んで拡大や回転はできることとは思いますが。（よく知りません）
顔グラ作りに特化して、操作が簡単で、デフォルト素材が入ってるのなんて、ないですよね？
（もしあったら作らない！）
でももし既にあるのなら、ウディタの初心者作品があんなに同じ顔で溢れることはないはず。
なので、作ります！
まぁぼちぼち・・・ね。
期待せず待って下さい。
アイデア盗用も歓迎です。
最後にカオメーカーのメリットとデメリット、検討事項を書き出しておきます。

＜メリット＞
・自由度の高い顔グラ作りができる。
・他ツール使用の必要なし。（画像加工初心者でもとっつきやすい）
・非暗号化ウディタで作るのでできる人なら改造できる。

＜デメリット＞
・背景透過できない。
・素材サイズが大きい。（容量も大きい）
・ウディタの基本システムで使用する時以外は他ツールの併用が必要

＜検討事項＞
・緑の帯の入らないスクショ撮影ってできましたよね？できるはず。できなきゃ詰みます！
・画面サイズの素材を顔グラサイズに縮小表示すると画質の劣化具合はどんなもんでしょうか。
（場合によっては素材は画面の左上で小さく作り、使用時は画面右下に余白を出して原寸大表示にします）

なんだか誇大妄想の垂れ流しのようになってしまった・・・。
ホラで終わらせないために実現したいと、ぼーんやりと思っています。
（さあ書いてしまったぞ、自分！もう逃げられないぞ！）

ここで今の心境を一首。

春の夜の　夢想（ゆめ）ばかりなる戯言に　甲斐なく堕ちむ　名こそ惜しけれ

ゲーム制作中です。
まだ未完成ですが、紹介ページを作っていただきました。
こちら。
↓↓↓
fairy song〜歌う革命〜


以下のサイトのフリー素材を使わせていただきました。
-------------------------------------------------------------
誰そ彼亭
http://may.force.mepage.jp/
Boston Age
http://areno.ongaeshi.biz/
Re:vre
http://nx.myafi.net/
-------------------------------------------------------------

まだしばらく制作は続きます。

tohさん企画のウディタリバーシの第二回が先日行われ、参加しました。

戦績は4勝2敗と、前回よりもよくなりました。
前回作成時は対戦相手がいないために手さぐりで作る楽しさがありましたが。
今回はライバルの思考ルーチンが一部公開されていたので、いかにしたら勝てるかを追求する楽しさがありました。

作りながらいろいろ感じたりもしましたが今日の所はそれを書くよりゲーム作りに注力したいので、手短ですが失礼します。

このたび、ソフトニシンさんとおっしゃる方がぼくの公開した鏡面床コモンを大きく進化させてくれました！
ソフトニシンさんのブログはこちら


以下を押したら公式コモン集にある「鏡面床コモン改」にとびます。


鏡面床コモン改



元々の鏡面床コモンは主人公一人目の影を足元に映せました。
それがこのたび・・・

・パーティーメンバーも映る。
・町の人やモンスターなどイベントも映る
・全マップサイズやあらゆる素材規格に対応
・その他各種調整が可能

と、目覚ましい進化を遂げました！

詳細はコモン集やソフトニシンさんのブログで確認してもらえたらいいのですが。
高機能であるにもかかわらず、導入がとにかく簡単！
前までと同じくコモンを入れてマップに穴をあけるだけでも鏡像が表示されます。
そしてこだわりたい人は多くの要素が自由に調整可能です。
さらになんと！80種類に及ぶ透過素材まで作成、同梱して下さいました！！！
ウディタデフォルトマップチップ使用なら、足を映さない水辺の表示もばっちりです。

マップの演出にこだわってみたい方はぜひチェックしてみてください！

さてそうして迎えたウディタリバーシ大会（第一回）つまり昨夜です。
tohさんがツイキャスとかいう今どきの仕組みを使って実況中継してくれて楽しかったです。
参加者は８人。
どうでもいいけどみなさんほとんどツイッターを使っているようです。
お若いのかなぁ。
ぼくのリアル生活での知人ではツイッターもラインもスカイプも使ってる人は誰一人としていませんよ。
ましてやツイキャスにいたっては。ぼくは今回初めて利用しました。
現代日本人の多様化と集団の細分化およびその断絶のすさまじさは想像を絶するようです。
ぼくが３０代も半ばを過ぎゲーム制作の世界に足を踏み入れたことは視野を広める意味でも僥倖だったと言えそうです。
話がそれました。ぼくはゲームに限らず日常の様々なことをブログに書きたいという衝動もあるのですが、それを自分に許すとただでさえ饒舌なぼくの文章はとどまるところを知らず暴走し出して多大な時間を奪っていくだろう事は目に見えているのであえて自分に文章はゲーム制作関係のみと縛りをかけることでそれを防ぎたいという思惑があるのです。長文連投も３つ目となるとどうもキーボードを押す指も滑るようです。

話を戻せば。
８人、総当たりで対戦しました。
試合を見ていていろいろ考えさせられました。
この記事ではそれを書きます。

試合中に盤上が一色になってしまい余白を残したまま勝敗が決したり、四隅を取られても勝った方がおられたり、スリリングな夜となりました。

驚いたのは時間切れで失格負けになった方がいらっしゃったことです。
ぼくは持ち時間の十分の一も使ったことはないので本当にびっくりしました。
そういう方はきっと先を読んでいるんでしょうね。
自分がこう置いたら相手が置けるのはどことどことどこで、それならどこが有利か・・・と。

見ていると角を取れるかどうかがほとんど勝敗を分けているように思えました。
（お一人バグを抱えたデータを提出してしまった方がいらして、角を取らせるような場所に自分から突っ込んでいってしまいお気の毒でした。関係ないですが、らすとあとりえのレビューを書いて下さった方なんですが）

勝つための方法論として、角を取るというのは大前提なんですね、きっと。
問題は、いかにして角の隣接マスをとらないかということです。
もっといえばいかにして相手に角の隣接マスをとらせられるか。

人間の思考では一辺や対角線が全て自分の色で埋まっていて角の隣接マスに踏み込んでも何とか大丈夫そうなケースもありますが。けれどもその判定を思考ルーチンに求めるのは難しいかもしれません。

ぼくの思考ルーチンは角の隣接はできる限り取らない、角を取れる時は必ず取る、その二点はまずまず隙はなかったと思います。
けれどもなぜだかこいつ、どんどん角の隣に踏み込んでいくんですね。
それはなぜか。
それは他に選択肢がないからです。
盤の四隅に角と周囲の四マスが四か所だけしか残されていない、他は埋まっている。そんな状況ならわかります。双方のルーチンが「角の隣は取らない」を厳守してのんべんだらりと進行していく（と言ったら相手に失礼か）場合はそういうこともありました。
けれどもそうでない。他にあちこちあいているのにわざわざ地雷を踏みに行く。
それは相手にこっちの手を読まれて、選択肢を少なく少なく追いつめられているからなんでしょう。おそらく。

ぼくが隣接マスの石の数を意識したのもそれに関係があって。
極端な話、敵の石を自分が完全に囲んでしまったらもうどこにも打てないわけです。
その状況に徐々に近づいていく過程で、タブーである角の隣に踏み込まざるを得ない状況に追い詰められてしまうのでしょうね。

これは相手の手を予測するしかないのでしょうかね。
相手の選択肢がなくなるように、なくなるように、誘導していく。
それには自分の石を置いた後の盤面をＤＢに置いてそれを判定するのが自然な気はします。

優勝された方がどこかのタイミングで「これを何とかするには４手先まで読まないといけないのかー」とかなんとかつぶやいていらっしゃったような記憶があります。（違ったらすいません！）
ということはまさか３手先までは読んでるというのでしょうか・・・！

次回に向けてどうするかを迷っています。
出場はもちろんしたいと思っています。
予測タイプに踏み出すか。
それとも従来の最適化路線をさらに追及するか。
処理速度なら負けません！って。
ぼくは今回の企画に参加して気付いたのですが、自分は思っていた以上に統計が好きなようです。
学生時代はさんざん嫌ったものですが。
どういう要素をどの比重でどのタイミングで加味すれば一番強いか。
それを考え試行錯誤する過程が好きです。
勝ちに行くならそんなことは言ってられないのかなぁ。
予測タイプを作るのには本体のコモンを流用できそうとはいえやはり難しそうだしめんどうかなぁ。
めんどうなんて言っていたら共同制作仲間に「それならそんな長文連投なんかしてないで作業進めてよー」と怒られそうですが。

まあまずは作り方をどうするか悩む以前に、オセロの定石などをもう少し勉強しようと思います。
いや、もちろんゲーム制作も進めますー。許して下さいー！
まあオセロに興味ない（と思う）方々がこんな長文３連発に目を通すわけはないですよね。
これでウディタリバーシシリーズはいったん終了のはずです。
長々お読み下さった方ありがとうございました。

tohさん主催のウディタリバーシ企画には気軽に参加できるよ、と前回書きました。
本当にウディタの上級者でなくてもオセロの思考ルーチンを作れるのです。
そのための環境が用意されています。
もちろん大会で好成績を目指すには高い技術も必要かもしれないですが。

今回の記事ではそんな「必ずしもウディタの扱いに熟達していない方」（もちろんぼくもそうです）にむけて、思考ルーチンの作り方やぼくの考えたこと、やったことを書きます。
（昨夜の大会で戦ったような方はお恥ずかしいのであまり見ないでほしいような気もしますが。）

興味のある方はまずtohさんの企画特設ページからゲームデータをダウンロードして下さい。
ウディタの本体も同梱されているので簡単に制作開始できます。

その中のコモンに思考ルーチンサンプルというのがありますね。
それをまず改変しましょう。
これは置く石の位置を決めるコモンです。
自分の番が回ってきたらここで置く位置を決定し、位置番号で返します。

これを開いてもらえれば分かる人はわかると思いますが、意外とシンプルです。
６４あるマス全てそれぞれの現状に対して、自分の色の石を置けば何枚ひっくりかえせるかを判定します。（０枚、つまりひっくり返せない時は置けないということです）
それが置けるなら可変ＤＢ内の上から順に詰めてに置ける位置番号を記憶させています。
ＤＢが完成したらＤＢの項目数から０の間のランダムな数をを選び、そこに格納されている位置番号を返す、それだけです。

もちろんランダムだから強くはないですが。
でもたったこれだけの処理で置けない場所に置いてしまったりその他いろいろややこしいことを解決してくれてるんだから素敵ですね。

そこでこれを改造するわけですが。
いちばん簡単なのは６４か所を判定する時に条件を付け、特定位置ならそこに即決してしまうことでしょうね。
６４回のループの中に
「判定位置が角（を示す番号）の時、置ける石の数が１以上だったら置く位置はそこ！そしてこのイベントは終了！」
そんな処理を挟み込むだけで、角に置けるなら有無を言わさず置いてしまう、あなただけの思考ルーチンが出来上がりです。（角に置けなければランダムに置く）
どうです？意外と簡単じゃないでしょうか？
（今回の記事はウディタのすごく初心者の方は対象でないので、すいませんがご了承ください。）

自分のオリジナル思考ルーチンができたら、それを元からあるランダムに置くルーチンと対決させられます。
４隅に置ける時だけ置く、それだけでも勝率に影響はあるはずです。
統計の好きな方にとってこれって身震いするほど興味深いことだと思いますよ。
自分が好きに設定した思考ルーチンがどれほど戦績に影響するか。
角を取ったら有利と言われますが、ではそれ以外の、例えば左上から右に３下に３（3-cとかいうらしい）ならどうでしょう？ランダムに比べたらやはり負けやすくなるか勝ちやすくなるか、かすかな影響はあるでしょう。
おもしろいですよねー。おもしろくないですかー？

さて、位置によって条件分岐する方法は一番簡単で、角を取れるなら取ろうというのはおそらく戦略としてそんなに間違っていなさそうな気がします。
けれどもその次、さてどうするかという時に技術以前に大きな問題がありました。
オセロのいい手とはどういうものかということ自体がぼくはわかってないんですよね。

正直に言うとこれまでぼくは、常に最大枚数ひっくりかえせる位置に置けばいいのかなくらいに思ってました。
けれども検索して調べたら全然そんなことはないんですね。
むしろ序盤は取りすぎないくらいがいいと書いてあったりする。
そして自分の石が相手の色に囲まれるほどいいという。
そんなこんなをぼくは初めて知りました。
それと、角の隣はやはり置きたくない。

それらに考慮した思考ルーチンをぼくは作りました。
使った要素としては、
・角か、角の隣接マスか、そうでないか
・置く位置に隣接する石はいくつあるか
・石を置くのは何手目か
・何枚ひっくりかえせるか
です。
それに加えて、それらの要素をどう加味して最終決定するかという仕組みも作りました。
だって角の隣に置きたくないとはいえ、他に置けないなら置くしかないのに、もしいつまでも置かなかったら失格になりますもんね。
そのために各要素で加点減点させて最終決定するようにしました。
プログラム用語でそういうのをどう言うのかは知りません。
それらについて上から順に、どうやったかをざっと書きますね。

・角か、角の隣接マスか、そうでないか
愚直に全部条件分岐で済ませました。
角およびその周囲は１６マスありますが。
１６回の分岐を作り、「もし判定位置がそれに該当したら〜」としました。
もっとスマートな方法もあるんでしょうけどね。
まあコマンドが長くなろうが自分にとって分かりやすいのが一番です。

・置く位置に隣接する石はいくつあるか
位置番号は連番なのにＤＢにある盤面記録は左から何番目、上から何番目と座標形式になってます。
その値は位置番号を割ったり、％を使って割った余りを求めたりで出せます。
これまた愚直に、その石の隣接位置を示す座標を８回設定し、石があるかを判定しました。
主催者tohさんはそんな時の為に判定座標が盤面から出ていないかを調べるコモンまで作ってくれているのです！その親切設計には感激しました。
周囲８か所に石があるかを判定した結果の合計が隣接石数です。

・石を置くのは何手目か
序盤中盤と局面に応じて打つ手を変えるにはこれを判定しないといけません。
どうしたらいいかわからなかったのでこのコモンの実行回数を数えたんですけどね。
自分の手番が来る度に呼び出されるんだからその回数を数えれば何手目かわかるはずだ、と。
でもtohさんのツイッターを見てたらなんと大会では連戦するというんですね。
それだとコモン内変数が初期化されない！
そこであわててとりみだしてtohさんにどうしましょーとかお恥ずかしいメールを送ったのですが、ゲーム本体で使用されている「石数を表示するための変数」を参照することでなんとか自己解決しました。

・何枚ひっくり返せるか
これは簡単。tohさんが用意してくれてるコモンが自動的に数値を返してくれます。
これをもし自力で作らないといけなかったらぼくはこの企画には参加できなかったと思います。

そしてこれらの要素を使い、石を置く位置としての適切さを比較・判定する仕組みを作りました。
可変ＤＢに数値を置く欄を作って足したり引いたりしました。
角なら＋１００点、角の隣ならー５０点。
局面が３０手までならそれに隣接石数を加点。それ以降は返せる枚数を加点。
そんな風にしてみました。

それ以外の要素として、外枠に接する位置（以下外枠といいます）も判定したのですが。
外枠ってちょっとひっくり返されにくそうじゃないですか。
なので優先的に取るようにしたらどうかと思って試したら・・・全然そんなことはなかったです。
「外枠なら取る、そうでなければランダム」という思考ルーチンを作って「ただのランダム」と対戦させたところ、なんと負けてしまいました。

あれ？今思いついたんですが、それなら「外枠ならポイント減点」という機能をつけたらもうちょっと強くできたのだろうか？
見た目的に返されにくそう、という自分の直感を取るか、統計結果を取るか。ですよね。
統計と言ってもその比較対象がランダムかそれともぼくの考えた似たり寄ったりのシステムしかないというのが、その戦術の有効性を推し量るのに効果があるのかないのかも全くわからないのですが。
でもそれににしたってランダム配置にも負けるって、どれだけ弱いんでしょうね。

置く位置を最終決定するには、ＤＢ内にある獲得点数の最大値を持つ位置番号を見つけないといけません。
上から順に現在の最大値が参照中の値以下だったら最大値を更新、そうでなかったら何もせず下の項目の判定に移る、ということをしました。
（プログラムを触り慣れた方にはきっとそういうのはあまりに決まり切った手順なのかもしれませんが、ぼくのような素人はいつも手探り・手作りです。）

また、各要素が決定に与える影響力をどうするかや、序盤中盤の切り替わり時も何手目にするか試行錯誤して悩みました。
隣接石数から返す石数に切り替えるタイミングは３０手目（自分の１５手目）にしました。
それ以前よりもそれ以後よりも一番勝率が高かったからです。
まあそれだって本当に同時に切り替えがいいのかなんて全然わからないのですが。
ひょっとしたら１０手目から返す石数を意識し出した方がいいのかもしれないし、終盤まで隣接石数にこだわった方が強かったのかもしれません。
けれど全部の状況を試すわけにもいきませんもんね。

え？全部の状況を試すわけにいかない？
できないことはないとは思います。このゲームデータを改造し、ある変数を徐々に上げていく異なる思考ルーチンで多様な相手と連戦させデータを取り、最適解を求める。それを自動化する。
実行時間はかかりますが半分放置で、ウディタの機能としてはできると思います。
ぼくの技術でできるだろうか。ぎりぎりできそうな気もします。
けれども、意欲は、ない！！！です。さすがにさすがに、そこまでは。

まあともかく、そんなこんなでできたのを昨夜の大会に提出し、見事２勝５敗の戦績をおさめたわけです。
ぼくの作ったコモンは企画用特設ページから入手できるようにしてもらえると思います、いずれ。

ぼくのコモンは強いか弱いかというとまあ２勝５敗という数字で現れる程度なのですが、この思考ルーチン作成に当たっては比較対象が多く欲しいというのは切実に感じたんですよね。
上にも書きましたが、新しい要素を導入してみてそれが勝率アップにつながるのか判定したい時。
勝ったからと言って、その対戦相手の特性に依存したものかどうかの判定がすごく難しいんです。
難しいというか不可能なので、疑心暗鬼にならざるを得ない。
しかも同じ相手でもボロ勝ち、ボロ負け両方起こることすらあるし、なにがなんだかわからない。
そのなにがなんだかわからない中にも一つの参考材料になればという気持ちを込めて、コモンの公開をtohさんにお願いしたという次第です。

さて、そうして大会本番を迎えました。
これ以上は長くなるので（もう十分に長いけど）、その時の模様や感じたことなどは次の記事に書きます。

あけましておめでとうございます。
ぼくは近ごろもあいかわらずゲームの集団制作を進めています。

さてウディタリバーシ企画（tohさん主催）というイベントにこのたび参加しました。
それに関連していくつか記事を書こうと思います。
一回目の今回は、ウディタリバーシ企画とはどのようなものかについてです。

tohさんの企画特設ページへ

上のリンクを見てもらえば詳しいことは分かるのですが、ぼくなりに説明させてもらいます。
ひとことでいえば「ウディタで作ったオセロの思考ルーチンをみんなで競おう」という企画です。
第一回目の大会は昨夜あり、ぼくも参加して２勝５敗の成績をおさめました！

最初この企画を見かけた時は実はいまいち敬遠していたのです。
オセロをウディタで作るなんてそんなの大変すぎる、自分には無理に違いない、と。
けれども一晩考えて、できないのはできないにしても興味は湧いてきました。
特に盤面情報を保持する方法とデータベースを使用できるのか知りたくなりました。
そこで主催者のtohさんが配布しているゲームデータをのぞいてみました。

のぞいてびっくり、とても簡単でした。
いや、思考ルーチン作りは別に簡単ではないのですが、それ以外の面倒なもろもろはtohさんが
一手に実装してくれていました。
ぼくが今回のこの記事で書くことは、上のリンクとそこで配布されているゲームデータを見ればわかることです。
けれどもあえて記事にして何を伝えたいかといえば、思った以上に気軽に参加できるよ！ということです。

もちろんウディタの技術は必要です。コモンイベントを自作した経験がある方でないと難しいとは思います。
でも参加者はオセロの仕組みを作る手間にわずらわされることなく、一番楽しいエッセンスの部分だけを作れるのです。
どこに石を置けるのか、そこに置けば何枚の石を裏返すことができるのかを取得する方法も既に用意されています。
作成した思考ルーチン同士対戦させたりプレイヤーと戦ったりする機能も実装済みです。
親切なことには選択可能な指し手の中からランダムで選ぶサンプルコモンまで添付されています。
そのコモンをほんのちょっと改変して・・・。
例えばランダムに選ぶ処理の前に「その場所が角ならそこに置く」という処理を置けば、それだけで自分なりの思考ルーチンの完成です。
ぼくがどんな方法でどんなコモンを作り大会に臨んだかは次の記事に書きます。

次回の大会も近いうちに開催されるようです。
ぼくのように先入観で敬遠する人のためにこの文を書きました。
意外と簡単！レベルを問わなければ、ウディタを使う人なら誰でも参加できる企画です。
みなさんもぜひどうぞ。

ウディタ上でドット絵を生成できるコモンを作りました。
画像分割表示に続いて、ソフトを使えば簡単にできるのに〜！な企画第二弾です。
まあゲーム中に文字列を書き変えればドット絵を修正できるので何かに使えるかもしれません。

以下はテストです。
（クリックすると公式コモン集のコモン位置にとびます。）


ドット絵生成

これはちくぼんさんという方が作られた、ウディタ公式コモン集のコモンにリンクを貼るためのブログパーツです。
http://tikubonn.org/plugin/wod-common-ev/
こちらで公開されています。
ブログから公式投稿コモンにリンクさせたい場合は便利ですよ。
ちくぼんさんありがとうございます。

ウディタ公式コモン集にコモンを二つ公開しました 。

桜吹雪あるいは紙吹雪コモンは、指定した位置から指定した枚数（最大８０枚）の●（黒丸・色指定可）を指定内のランダムな位置に移動させます。

画像分割表示コモンは画像を上下か左右、任意の位置で分割してそれぞれ指定した不透明度で表示します。
分割というとバラバラになると誤解されるかな。位置は離れません。隣接します。
つまり不透明度が同じだとただの一枚表示に見えます。

興味のある方は公式コモン集内で検索してください。
もし質問などあればメールとかでどうぞ。

ゲームのアイデアを募集しました。
いただいたアイデアを元に、作成していきたいと思っています。
ご応募してくださった方、ご応募を考えてくださった方、ありがとうございました！

先日から公式コモン集で公開している万能用語事典の機能について、ここで改めて解説します。
（以前の記事はこちら）
またＩＤ順に表示するバージョンも公開します。



写真は改変版の表示画面



まず、万能用語事典とは・・・
・画面左にあらかじめＤＢに入れた項目名を一覧表示し
・カーソルを合わせた項目の説明や画像を画面右に表示し
・決定を押せばその項目についての詳細説明を全画面で表示できる（使わないことも可能）
そんなコモンです。
シニスレッドさんとおっしゃる方が作られた「万能型用語辞典コモン基本2用」と、ぼくが改変させてもらった「万能型用語辞典の改変版」の二つが現在公式コモン集に登録されています。



●「万能型用語辞典コモン基本2用」（シニスレッドさん作）について
ゲーム作者は辞典の内容をユーザＤＢで設定しておきます。
プレイヤーは辞典を開く度に、全ての項目を見ることができます。
ゲーム開始時から全ての情報を表示できるので、ゲーム内の用語説明やヘルプなどに最適です。


●「万能型用語辞典の改変版」（じゃ。作）について
ゲーム作者は辞典に入れたい（予定の）内容をユーザＤＢであらかじめ設定しておきます。
ゲーム内で記入コモンが実行される度に、指定した項目が辞典に追加記入されます。
プレイヤーは記入済みの項目だけを見ることができます。
ゲーム内で獲得したアイテムや出会ったキャラの情報だけ表示できるので、アイテム図鑑やキャラ情報等に向いています。
辞典内での項目の並び方は、辞典に記入された順です。

追加機能！
？？？を明かしていく上書きや、項目削除も可能になりました。
詳細情報10ページまで設定可能が標準仕様になりました。

----------------------------------------------------------------------------
以下はここでしか公開していないコモンです。

「ＩＤ順：万能型用語辞典の改変版一式」
通常の辞典改変版とは異なり、項目の並び方はユーザＤＢのＩＤ番号順になります。
項目を追加記入すると、番号順の位置に挿入されます。
上書き、削除、詳細10ページ表示には未対応です。
出会った敵の情報を出現エリアに分けて並べたい場合等、並び順を一定にしたい時に便利です。
＜使用方法＞
ダウンロード先にはＤＢを含めた一式を入れています。
コモン内のりいどみい等を参照して導入してみて下さい。
ダウンロード
↓↓↓
id順ー万能型用語辞典の改変.lzh

設定が少しややこしいかもしれませんが、目的に応じて使ってくださいね。

先頭主人公をピクチャ表示するコモンを応用し、７つの演出コモンを作りました。
それを普通の表示コモンと合わせて公式コモン集に登録しました。「主人公演出セット」で検索！



写真は残像コモン。

通常表示コモンもそちらに入っているので、以前このブログで公開した同じものは停止します。
以下にコモンの説明を転記しておきます。

主人公の表示を演出するコモンの詰め合わせです。
コモンは８か所使いますが各々単体で使えます。必要ないものは消去して下さい。
＜内容＞
�@通常表示　�Aオーラをまとう　�B歩くと溶ける、溶解人間　�C分身の術　�D残像付き移動　�E歩くと巨大化　�F歩くと日焼け　�G前のめりの移動　　詳しくは各コモンを参照して下さい。

＜使用方法＞
各コモンをどこにでもいいので読み込んで下さい。
使用する演出コモン（基本的には一つだけ）を選んで、その起動条件を「並列実行(常時)」にして下さい。
ゲーム内でそのまま呼び出せば起動します。引数＜コモンセルフ０＞を０にして呼び出せば元に戻ります。

＜注意＞
8方向用素材使用限定です。(ゲーム設定の移動方向は４でも８でも対応しています)
可変DBに設定した「パーティーメンバー１」、一人分（←重要！）の画像のみ、先頭メンバー位置に表示します。
演出にはピクチャ表示を使います。（画面暗転でも消えない、エフェクトが無効、ピクチャ番号による表示される層に注意してください）
複数の演出コモンを併用したい場合コモン冒頭付近の「パーティー全員を透明にする」「パーティー全員の透明を解除」を消去した上で、それらはコモン外などで各自適当に設定して下さい。動作の保証はできませんが。（ピクチャ番号の大小に注意して下さい）
画面サイズ３２０と６４０、異なるサイズの歩行グラ素材でで動作確認済み。
演出表示中は影は表示しないので、あらかじめ影なしを推奨します。(テストプレイ時は有りの方がわかりやすいです)

主人公画像ピクチャ表示の応用企画第二弾！
残像コモンができました。



半歩移動ごとに像を残したはずなのになぜかせまく見えます。イモムシみたい・・・。
デフォルトではもっと間隔をあけるようにします。
数十フレームかけて後ろから消えていく仕様です。

≪今日学んだこと≫
変数操作＋で画像サイズを取得しても、素材としての元のサイズしかわからない。
表示時に拡大率を指定して表示サイズが実際は違っていても、それは判定できない。
表示中のサイズが知りたければ取得した値に拡大率をかけて100で割ることが必要。

先日作った主人公歩行グラのピクチャ表示コモンを応用し、いろいろな表現をしようと思います。
今日は歩けば歩くほど主人公の体が溶けていくコモンを作りました。
名付けて溶解コモン！
足元から徐々に溶けて身長は低くなり、そのうち頭だけになり、最後は横線だけになったりします。

・１ピクセル溶けるのに何歩かかるか
・最終的に何ピクセル残るか
・溶ける時に鳴る効果音

を指定できるようにしました。
完全に透明人間にしてしまうと操作がストレスフルになるので、溶け残り？の表示ありをデフォルトにしました。
これを使ってゲームを作るなら、何歩歩いてどれだけ溶けたかがわかる万歩計溶解ウォッチというアイテムを出したいなとか夢をひろげています。
生首といいグロテスクなのは嫌いなはずなのだけどもなぜか作ってしまう・・・。
似たような応用コモンがたくさんできたら、いずれまとめて公開したいです。

≪今日学んだこと≫
回数付きループの回数は0未満には指定できない。
ただし変数で指定した場合は回数をマイナスにすることもできる。
けれどもその場合ループ内は実行されず、0回と同じ扱いにされるらしい。

万能型用語辞典の改変版というのを作って公式コモン集に登録しました。
もとはシニスレッドさん（悪魔の壁さん）という方が作った用語辞典です。
登録済み情報を一覧できるコモンだったのですが、それにゲーム内で追加していけるように改変しました。
ぼくの処女作ネオ繚乱記でも、サークル製らすとあとりえでも使わせてもらったものです。


Read meの一部分を抜粋するとこんな感じです。

＜コモンの仕組み＞
ユーザＤＢは完成した事典です。
可変ＤＢは始めは白紙の事典です。
記入コモンで指定項目を書き写します。
表示コモンでその時点の可変ＤＢの内容を表示します。


どんなことをするコモンかなんとなくイメージしてもらえるでしょうか・・・？
公式コモン集のコメント欄でそのコモンをほしいという要望を２回もらったので公開にいたりました。
用語辞典としてはもちろん、アイテム図鑑やモンスター図鑑として便利です。
基本システムのデータベースと連動していないので応用がきくかと思います。
データベースのアイテムリストやモンスターリストと連動させるにはほんの少しだけ改造が必要です。
現状ではゲーム内で記入した順に上から詰めて項目が増えていきます。
なのでアイテムなどのコンプリートを目指して「？？？」を明らかにしていくような場合にも改造は必要です。
シニスレッドさん（悪魔の壁さん）ありがとうございました。


なお、このコモンと合わせてらすとあとりえで使った、はつやさん作もぐらたたきコモンも改造・公開しようと思ったのですが、あまりに簡単な改造で済むので公開は遠慮することにしました。限りなく再配布になってしまうので・・・。

あれはウディタ２に未対応なんですよね。それをコモン１行いじるだけで対応させられるので、方法は公式コモン集のコメントに書きました（もぐらで検索！）。
らすとあとりえでもぐらたたきをして、もしも「使ったみたい」と思った方がいたら参考にしてください。

おとつい夜に公開した歩行グラ部分表示コモンですが、公式コモン集で「下半身を透過表示すれば」というご意見をいただきました。これは目からウロコ！
そこでさっそく上半身と下半身、それぞれの不透明度を設定できるようにしました。


公式コモン集で公開中！

すると水中らしい演出ができるのみならず、下半身のみの表示まで可能になりました！
（何に使えるかわかりませんが）
アドバイスくださったバルゴさん、本当にありがとうございました！

主人公ピクチャ表示コモンというのをこのたび作りました。
昨夜公開した部分表示コモンの元になった、汎用性の高い物です。

追記
後日これを応用して作ったコモン８つと合わせて公式コモン集に登録しました。「主人公演出セット」で検索！



↑このコモンの使用例。主人公はこう見えてウルファール。


以下にコモン内に書いた説明を抜粋します。　　
-------------------------------------------------------------------------------------

●できること
主人公の全身をピクチャとして表示します。

●使用方法
このコモンをどこにでも読み込んで下さい。
ゲーム内でそのまま呼び出せば主人公がピクチャ表示になります。
引数＜コモンセルフ０＞を０にして呼び出せば元に戻ります。
205行目のピクチャ表示コマンド内、数値が１６００・・・でない部分を変更すると通常イベントとしてはできない表示ができます。
(拡大率・カラー・不透明度・角度・表示形式)

●注意
8方向用素材使用限定です。(ゲーム設定の移動方向は４でも８でも対応しています)
ピクチャ表示されるので、画面暗転で消えない、MAP通行設定「後ろに行くと隠れる」が無効、その他挙動の変化に注意して下さい。
起動時に「パーティ画像を透明にする」を実行するので、起動中はイベントとしての全身像は消えます。
可変DBに設定した「パーティーメンバー１」、一人分の画像のみ、先頭メンバー位置に表示します。
ピクチャ表示時は影の表示はしないので、通常から影は非表示にしておくといいかもしれません。
画面サイズ３２０と６４０で動作確認済みです。

-------------------------------------------------------------------------------------

このコモンは鏡コモンを作る過程でできました。
常時、画面上の主人公画像を取得する。それと同じ画像を同じ位置にピクチャとして表示する。
考えればこれは今年3月にはできていたことなんですね。

でもぼくは鏡や水面像というその先を見据えていたので、このすごさに気づいていませんでした。
鏡や主人公の部分表示が完成して公開した今、徐々にそれがわかってきました。
ちょっと改造すれば様々な演出ができる、可能性の大きいコモンだと思います。

上の画像はいろんな機能を詰め込んだので何だかよくわかりませんが・・・。
主人公画像を拡大しています。
色調変更し、減算表示にしています。
表示角度を傾けています。
これを、マップ上を自在に歩かせ自在な向きの像を表示させることができます。
（このすごさを伝えるのに動画を作ってみたくなってきました）
そしてエフェクトでマップをシェイクやズームさせても主人公には影響しません。
耐震性ウルファールの誕生です。
具体的には何ができるのかを考えてみます。

●このコモンを導入するだけで
・主人公の拡大率・カラー・不透明度・角度・表示形式を変更できます

●ちょっと改造するだけで
・歩けば歩くほど巨大化するキャラとか
・左右を向いている時だけ常に体が傾いている、いつも前のめりなキャラとか
・キャラと同じ画像を少し拡大して加算表示にしてキャラより下層に表示したらオーラ（闘気？コスモ？）をまとえるとか
・ＨＰが減るほど透明度が上がるキャラとか
・分身の術とか
・立ち鏡に映る像や鏡面床に映る像の表示とか（これは完成・公開済）

●だいぶん改造すれば
・主人公画像の部分表示とか（これも完成・公開済）

など考えられます。まだまだあるでしょう。
ぜひ皆さんのアイデアで使ってみて下さい。
なおこのコモンをそのまま使うと見た目はほとんど変わらないので（影が消える位）、本当の初心者にはどう使っていいか難しいかもしれないです。
なので今回は公式コモン集への登録は見送りました。
いずれこれを改造したコモンの詰め合わせをアップしてもいいかなと夢見ています。（追記：できたよ！）

ウディタで主人公の歩行グラを部分表示するコモンができました。
いわゆる生首コモンです。
生首など作りたくも見たくもないのですが、まあ水中移動時にも使えるし公式コモン集に公開しました。
「歩行グラ部分」で検索！



せっかく部分表示ができたのに水面に映る演出用には使わなかったので・・・。
水面用には上下反転したのを下のマスの地底に表示したのですが、主人公と同じ位置に同じ画像を部分表示するようにしました。
用途は限られると思うけど使ってくれる人はいるだろうか。

余談ですが、鏡コモン以来ぼくを悩ませた不具合が解決しました。
画面スクロールしない時に表示画像が遅れてついてくるあれです。
状況に合わせて座標に補正を入れることで正常な表示ができたので、鏡コモン２種にも入れて昨日バージョンアップさせました。この部分表示コモンにも同じ処理を使っています。