じゃ。のページ

昨夜ここに文章を書いて自分の考えをまとめました。
そして一晩寝て、整理がついて見えてきたことがあります。

ぼくは可能なら水面の像をなめらかに映したい。
それには地底表示しかない。
がけはその上層に表示すればいい。
それなら足を消す必要はない。
つまり、足を映さない水面像表示は鏡面床コモンでできる。

そのことに気づくのに、昨日の長文の考えをたどる必要がありました。
お恥ずかしい。
もしぼくの読みにくい文を読解して意図を正確に理解してくれている人がいたら「何を悩んでんの？」とあきれたかもしれません。
ピクチャの部分表示は必要なかったのです。
技術的に厄介な処理を実現できたから、頭がそこから離れなくなったんですね。
策士、策におぼれるというか・・・。ぼくは策士じゃないけど。

そうとわかれば、オートタイル素材も作るっきゃないですよね！
なんせ鏡面床コモンがそのまま使えるんです。汎用性も高く、導入は楽々！
苦手だとか面倒だとか言わず、腹をくくって作りました。



↑こちら

オリジナルに比べてぼやけています。そして地面の色は明るい黄緑色一色限定。
しかも水面が揺れるアニメ付きのはずが、なぜかがけが揺れる特別仕様。
誰か作りなおしてー！
けれどこれを使って、精密なキャラの位置に忠実に映るべき部分だけを映るべきタイミングに表示できます。もちろんがけに足は映りません。
うれしくなって調子に乗って、らすとあとりえにも導入しました。
サークル製作品なのに自分の趣味の為に私物化しているようで申し訳ないですが、まあいいでしょう（？）。



↑足も映らず、この通り！

ウディタ公式コモン集の鏡面床コモンにも素材を追加しました。コモン使用の幅が広がったと思います。
それにしても地底表示という手法はなんて使い勝手がいいんでしょうね。

ここをご覧の方で、らすとあとりえのＶｅｒ．３．００以降を遊んでくれた方がどれくらいいるかわかりませんが。
カーライカムという町の川辺に行くと、水面に主人公の上半身だけが映ります。
そう、このブログで前からちょこっと言っていた、歩行グラフィックの部分表示に成功しました。



↑
足が映ってっていない！たったこれだけのことがウディタでは画期的！（多分）


鏡面床は前に完成していました。床全面に像が映る場合には対応できていたのです。
けれども水辺で主人公の姿が水面に映る時、足元のがけ部分に足が映るのがおかしいので、歩行グラの部分表示を目指していました。
それがこの度できたわけです。
原理としては１キャラ分の画像を高さ１ピクセルの横線の集合としてとらえ、その線を上下並び順を逆にして１ピクセルづつずらして表示する、という方法です。
並列実行しておけばリアルタイムに主人公の位置に対応した部分像を主人公の足元に表示できました。

けれども・・・。
問題は起動条件でした。
カーライカムでは水面像表示の起動条件は水辺のマスを踏むこと、消去の条件はその上のマスを踏むことです。
実はこれ、納得いってません。
というのも像の表示がついたり消えたりするのに違和感があるのです。
前に公開した鏡コモンや鏡面床コモンでは地底に常時表示していたために、マップチップからはみ出した部分がピクセル単位の滑らかさで表示されていたんですよね。
それが今回は、表示するか消えるかのどちらかだけです。表示場所に到着するまでは一切表示されないし、消去場所に到着するまでは全身消去されません。
これじゃせっかく足元だけ映らないようにしたのに、結局陸上でも像が映ってしまっています。
らすと あとりえは歩幅は一歩を採用しているのですが、半歩なら更におかしなことになりそうです。
地底表示の滑らかさを体験してしまっているだけによけい満足できません。
がけや水面のマップチップを使わないといけないので地底表示が使えず、そんな状況になっているのです。

ところでこんなことを言うと差しさわりがあるのかもしれませんが、ぼくが水面に像が映るコモンを作りたいのはらすと あとりえの為ではないです。
そのコモンを公開して、大げさに言うとウディタの可能性を広げたいというか。
ウディタでできることを増やして、多くの人に選択肢として提示したいということがあります。

だからある程度汎用性があって導入もしやすいものができないと意味がないんですよね。
結論から言うと、今回水面に映る像のコモンの一般公開はしません。
歩行グラの部分表示ができて、なおかつその像が鏡面床のようになめらかに表示できたなら多くの人に喜んでもらえると思うのですが・・・。
残念ながら今のぼくでは汎用性を持たせて導入しやすいものを作るには技量が足りないようです。


以下にどうすれば実現できるか、考えたことを記録しておきます。
とにかく像の表示位置を地底にしないと、なめらかな表示はできないようです。
（水辺周囲の全てのマスの地形をイベントとして配置してマップ上イベント下に表示という手もあるかもしれませんが、それをコモン利用者全員に強制するのは無理がありそうです。導入に手間がかかりすぎるし、ぼくも利用希望者全員に理解してもらえるよう説明できる自信はありません。）
地底に表示はしたいのですが、がけ部分がないと足を消している意味がありません。
だからがけは表示したいです。
とすると、がけ部分だけ表示し、水面部分だけ透過処理したオートタイルマップチップが必要です。
それを作ればいいのですが、ウディタ同梱素材でマップを作る場合、水辺のがけと言えばタイルセットの一番上、右から４番目を使うことが多いかと思います。そこでその水部分を透過すればいいのですが、あのチップは周囲が透過されていて、下地の草地や砂地の上に水を配するようになっています。本来レイヤー２以上で使うものなんですね。レイヤー１で使うと岸部分が黒くなってしまいます。
だから水面を透過した差し替え用素材を用意するなら、岸部分に使用を想定される黄緑や肌色を配さないといけないです。
それがぼくにはなかなか難しい。
ドット素材を本格的に作ったことがないので、黄緑や肌色の大地と連結させて不自然じゃない水辺を作るにはそうとうな労力が必要です。
その上そうして作ったとしても汎用性を持たせられない。
「水面に映る像を使いたければ地面の色は黄緑か肌色限定でお願いします」となってしまう。
しかも更にその導入はオートタイルの差し替えや設定が必要で、初心者が気軽にできるものではないかもしれない。
そこまで思うと同梱素材の改変で水面像を表示させるのは大変だと思いました。

がけ素材としてそのまま使えそうな同梱マップチップを探しましたが・・・。
木製のドア枠の上部なんてちょうどいいんですけどね。


ドア枠をがけに見立てた

でもこれをがけとして見るとがけの中ほどに水面ラインがあるので、ライン以下は映らないとおかしいですね。つまりマップチップより上・・・。これを採用するなら地底という手は使えないようです。

前にも書きましたがこの技術は生首とか、ホラーの演出にも使えそうですけどね。まあ趣味じゃないので作る予定はしていません。
関係ないけど、ピクチャの部分表示コモンなんて需要はあるのかな？
パターンを考えないといけない歩行グラフィックと違って、ただの一枚素材のグラフィックを部分表示することはとても簡単です。
でもウディタじゃ手軽にはできないから作ったら使ってもらえるかもしれない！
何より汎用性があるのがいいですね。
どんな状況で使うのか想像はつきませんが。ちょっと考えてみよう・・・。

まあそんなこんな試行錯誤をしているという、近況報告でした。

らすと あとりえは共同制作ゲームで、サークル名義の作品です。
共同制作メンバーに非常に感謝しているのももちろんですが、ここでは一方的に素材をお借りした外部の方へのお礼を書かせてもらいます。

ＢＧＭ：真島こころ様
ふりーむ！素材ライブラリーでピアノ曲を多数公開されている方です。ゲーム内のほとんどの部分でこの方の曲を使わせてもらいました。
繊細なピアノの音に心が和みます。ホームページでは色使いの印象的なイラストも公開されています。

ＢＧＭ：Ｎｉｓｈｉｏ様
ゲーム用のＭＩＤＩ曲を公開されている方です。このブログの一番古い記事に僕と比べれば月とすっぽんですと書いたのはこの方のことです。
前作に続き今回もこの方の曲を多く使用させてもらいました。

ＢＧＭ：Blue Piano Man様
エンディングにこの方の温かい曲を使わせていただきました。制作仲間にエンドロール作成を頼んだところ、即座に「音楽はこれを使います」といわれました。
やさしいメロディーがゲームの余韻に浸らせてくれます。

ジングル：あまなつ様
この方はぼくと同じくウディタをなさる方で、先日自作ゲームを公開されました。
ゲーム内の様々な挙動に挑戦され、それを発信し続けている姿にいつも励まされてきました。音楽も作られるとは知らなかったのですがこの度ジングル集を公開されたので早速使わせてもらいました。

コモン：悪魔の壁様
ウディタの公式コモン集にいくつものコモンを投稿なさっている方です。この方の万能用語辞典はとても便利なので前作でも使わせてもらいました。
掲載ページのコメント欄に要望が出ているようなので、勝手ながらいずれ改造して公開させてもらいたいと思っています。

コモン：つつじ椿様
同じく公式コモン集に、レベルの高い多くのコモンを投稿されています。らすと あとりえを起動中にウインドウの外を触った時、画面が青くなるのはこの方のおかげです。ちょっとした遊び心が素敵です。

コモン：はつや様
らすと あとりえをプレイされたらわかりますが、ゲーム内の最も大事な場面でミニゲームがあります。それはこのはつや様が作ったものをほぼそのまま使わせてもらっています。
とても面白いのですが、このコモンはウディタの前バージョン向けの仕様なので最新バージョンで起動するように改造して公開したいと思っています。

皆さま、本当にありがとうございました。

この度、結構中心になって作らせてもらったゲームらすと あとりえが公開されました。
多くの方の助けなしにはここまで来れず感謝でいっぱいです。ありがとうございます。

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



タイトル画面

本作は、錬金アドベンチャーというジャンルでして。
主人公は近所のお姉さんの病気を治そうと、エリクサーを作るためにかけずり回ります。
錬金術のレシピを手に入れて、素材を採集して、錬金術でアイテムを合成する、そんなゲームです。




志を果たせなかった主人公


そしてまさかの、ウディコン出品（予定）！

ミニゲームもあるのでよかったらどうぞ！
このゲームについては今後いろいろ語るかもしれません。
とりあえず今日の所はお知らせまで。

ある場所でコモンのリクエストを受けつけたところ、立ち絵・顔グラ付きのステータス画面が欲しいという声をもらいました。
そこでやっつけ仕事ですが作りました。「装備」コマンドの着脱をできなくしてグラフィックを表示しただけです。

ダウンロード
↓　↓　↓
Data.lzh

導入の説明が面倒だったので、初期状態のウディタに入れたdataフォルダをアップします。
dataフォルダに上書きして使って下さい。
作成中のゲームに導入するには試行錯誤して下さい。
でも作れる人なら自作した方が早いと思います。



立ち絵と顔グラは、ウディタ公式のwikiより借りました。
使用報告その他の制限はない素材です。

メニューの「相談」の位置で「ステータス」を開くことができます。
メンバー切替え確認のために、エディと夕一も最初から仲間になっています。
キャラ画像はピクチャフォルダに入れて可変ＤＢ[0:XX:3]と可変ＤＢ[0:XX:59]で設定して下さい。
コモン２１８「ステ画面描画」の２１７行目、２２１行目で拡大率や座標の調整をして下さい。

自分が攻撃をした後に寝てしまう味方を設定する方法です。
以前２ちゃんねる上でどうしたらそれが可能かという話がありました。
そこで当時考えたものです。
その記録も今では普通には見れなくなったようなので、ここに記録しておきます。

ウディタ２、基本システム使用、寝るキャラ名は「ウルファール」

�@コモン２０３　○[変更可]戦闘開始時処理に以下を書き込みます。
（戦闘開始時に、敵全員に状態異常２３番を１００ターンかけます）

■DB読み込み（可変）：Cself0＝可変DB[タイプ１３のデータ数]
■変数操作：Cself1=Cself0-10
■回数つきループ[Cself1]回
|■変数操作Cself2＝Cself3+10
|■可変DB書込：DB[13:Cself2:23]()=100
|■変数操作Cself3+=1+0
ループここまで
■

�AUDBタイプ７：属性名の〜　データ６の属性名を「眠り返し」にします。
�BUDBタイプ０：技能　データ４の項目[0]を「寝させる」にします。
ページ２の項目[22]付加するステータス状態を[1]眠りにし、その下の付与率％を１００にします。
�CUDBタイプ０：技能　データ０通常攻撃をデータ１に上書きコピペし、データ名を「寝る前攻撃」にします。項目[17]付与属性を[6]眠り返しにします。
�DUDBタイプ８：状態設定　データ23の項目[0]状態名を空白にしたまま、
ページ３の[40]カウンター有？を[4]寝させるに、その下(この属性を〜)を[6]眠り返しにします。項目[43]（カウンター発動文）に「ウルファールは寝た」と書きます。
�EUDBタイプ６：戦闘コマンド　データ０通常攻撃をデータ８に上書きコピペし、コマンド名はそのままで項目[2]（選択時の効果）を[1]寝る前攻撃にします。
�F可変DBタイプ２：主人公行動AI　データ１２ウルファールの項目[2]を[1]寝る前攻撃にします。
�G可変DBタイプ０：主人公ステータス　データ１２ウルファールの３ページ項目[47]を[8]通常攻撃にします。

これは何をしているのかというと・・・。
敵は全て戦闘開始時に「（空白）」という状態異常にします。
ウルファールの攻撃には「眠り返し」属性をつけます。
「（空白）」にかかっている時は「眠り返し」属性の攻撃を受けた時「寝させる」を１００％ カウンターさせるよう設定しています。
攻撃をミスしたら寝ません。

そういうことです。
これで攻撃後に寝てしまうキャラが実現できると思います。

このたびぼくの関わらせていただいたフリーゲームが公開されました。

↓紹介ページ
http://www5170uo.sakura.ne.jp/works/project03/

フルーツシーカーといいまして、ジャンルは「ほのぼの探索ＲＰＧ」です。
ゲームに使われている素材のほとんどは、このゲームのためだけに作られたものです。
グラフィックがきれいでかわいいです。
マップチップなんか、このゲームの雰囲気に合うように心をこめて一つ一つ作られています。
ぼくは音楽を担当させていただきました。
ゲームタイトルも、サンプル曲のタイトルとして送ったものから採用してもらいました。
こんなにすごい作品に関わることができて光栄に思っています。

ふりーむからダウンロードできます。遊ぶにはツクールＶＸのＲＴＰが必要です。

コメント欄で鏡コモンの640対応をご要望頂いていたのに気付いたので、作りました。
でも640は規格が色々ありそうで、どれ！と決めにくいのが困るところです。
まあ320も色々あるんだろうけれど、とりあえずデフォルト素材は誰もが持ってますもんね。

とりあえず手元にあった640用歩行グラに合うように作ってみました。
４方向３パターンです。
この素材の特徴は右向きと左向きのアニメパターンの並びが左右対称なことです。
デフォルトのウルファールの時とは違って全状況に応じたパターン番号を指定する必要がありました。
そこでコモン内での変換定数指定は断念しました。
ユーザＤＢに情報を入れて、それを参照するようにしました。


状況別バターン番号の表と参考にした素材


コモンと使い方
↓これをダウンロードします。
640用、壁鏡.lzh


コモンを読み込みます。
ユーザＤＢをタイプ１８に読み込みます。
（１８を使っていたら別の所に入れ、コモン内からの参照先もそこに変えます。）
常時並列実行なので、マップチップのない所ではキャラの上（むこう）に姿が映るはずです。

それにしても、方向が４と８とあって画像サイズもまちまち、それに加えてパターンの並び方まで様々とは！
汎用性のあるコモンを作ることは絶望的な気もします。
どの規格でも使えるものを作るのは難しいようです。
もしご要望がいただければ、個別に考えさせていただきます。時間があったら。

ゲームを作っています。
マップ上を歩いて人と会話して、フラグが立ったら次のイベントが開放せれる。そういうのを、性懲りもなく作っています。そういうのは前回の自作ゲームで終りにしようと思っていたのに、これまたどうしたことか・・・。

アイテムを全部そろえて、キャラステータスを最高になるまで育て上げて、全てのイベントを体験する・・・そんなプレイスタイルのことを何と言うんでしたっけ？忘れました。

そういうプレイを可能にしようと思えば、自由度は低くなりますよね。全てのアイテムは、手を伸ばせば届く所にあって、二者択一を迫られることはなく、タイミングによる分岐もない・・・。その方がいいのかなあ。

どういうプレイヤーを想定するかにもよるんでしょうね。
プレイヤーが何度もやり込んでくれるのだとすれば、一回目で気付けなかったイベントに２回目で気付けて、何度もやりがいがある、とかがいいのかもしれません（周回制にはしないので〜周目とは言いません）。

まあ自分ごときのゲームをそうそうやり込んでくれる人は少ないだろうという現実を見れば、ひと通りさらっとプレイしてみて「こんなもんか」と、とりこぼしたイベントがある可能性を気にかけることもない、そんなプレイヤーが大半だと思ってよさそうです。

それだとしたら、それなら全てのイベントは出し惜しみしないで、適当に進めてもだいたい出現するようにしてもよさそうなのですが、それだと一本道感が出てくるのが悩ましいですね。

プレイヤーには自分の気持ちのおもむくまま好き放題にプレイしているように感じさせ、それでいて作者の意図通り、ラストに向けて避けて通れないイベントは外さず体験してもらう、それでも強制された感はない・・・。
そんなのがいいんですが、どうすればいいんでしょうか。

そういえば、こんな手品があります。
「１〜３の数字を選んで下さい」と言い、選んでもらったら「あなたがそれを選ぶことはわかっていました」と言う。
１ならマッチ箱に入った一本のマッチを見せる。。
２ならマッチ箱の中に書かれていた２という数字を見せる。
３ならマッチ箱の底に書かれていた３という数字を見せる。
「ほ〜らね」と。

ゲームの演出でもそういうことが上手くできればいいのですが。「好きな方を選んで下さい。あなたが選ばなかった方は、２度と見れませんが、でも人生もそんなもんだし、選ぶしかないのです。さあ、選んで！」というずぶとさも欲しいです。

でも選ばなかった選択肢って、もし選んでいたらどうなっていたか気になるから、直前にセーブでもしていようもんならやり直してみますよね。そしてそれは「そんなめんどくさいことさせるなよ」という気持ちにつながると思う。

それならいっそ、分岐は分岐と気付かせず、知らないうちに限定ルートに足を踏み入れさせるのが親切かとも思います。
けれどもそうすると、多くの分岐パターンを用意したにもかかわらず、「なんだ、一本道か」と思わせてしまい、その割にはラストに至るまでの情報提示などが十分でない場合も多くなるので、「説明不足でわかりにくいな」とか思われるリスクも高まってしまいます。

どうすればいいんだー、という堂々巡りは今後も当分続きそうです。

鏡が完成しました。
前回は左右反転技術の開発とか物々しいことを書きましたが、これもいつものごとくウディタではちょちょいのちょいだということが判明しました。何ができるのかくらい確認してから文章を書け、という気もします、我ながら。
その方法を教えて下さった方がいらっしゃり、本当に助かりました。ありがとうございます。
それに合わせて、目標だった鏡面床も一応完成させることが出来ました。
二つ合わせてセットにして、ウディタ公式コモン集にあらためてアップしました。
必要な方はそちらで「鏡コモンセット」で検索してみて下さい。



　↑
（これは鏡面床コモンの使用例）


鏡コモンの原理については前と変わった部分も多いので、ここで説明します。
前々回の記事を書いた時点まで、ぼくは鏡像の表示座標は鏡の中心じゃないといけないと思っていました。
そのために「半歩かぶっても映りません」とか書いて、枠を作ってごまかしたりしたのですが。
どうしてそんな考えにとらわれたかというと、それはきっと最初にぼくがキャラ座標はマス目でしか取得できないと勘違いしていたからです。
そして、鏡の起動条件ということをすごく狭く考えていました。
鏡に映すんだから鏡の前に立った時だけ起動しないといけない。主人公が鏡の前に立っているかどうかを常に判定しないといけない。
そういう思い込みがありました。
でも、発想を変えれば違う方法がありました。像は常に表示するんです。ピクチャ表示は常にしていて、鏡の前に来た時だけ、そのピクチャがモニターに現れるようにすればいい。
そのためにはピクチャは常にマップの下（イメージとしては地底）に表示し、鏡部分にはマップチップを置かないよう（イメージとしては深い穴）にすればいいと気付きました。

これに気付けたのは、鏡面床を視野に入れていたからかもしれません。
鏡の前に立つだけなら、起動条件は「点」つまり０次元でいいんですよね。
でもその鏡を横にたくさん並べて、鏡面壁を作ろうとしたら起動条件は「線」、１次元になる。
直線上にいる時だけ鏡が起動するということですね。
そしてどこでも鏡を使える状態、すなわち鏡面床を考えれば起動条件は「面」２次元です。
範囲内の床の上ならどこにいても鏡が起動しないといけない。
いつでもどこでも鏡を起動していればいいんです。その鏡面床の範囲の条件指定（座標がナンボからナンボまで）を考えるのが面倒だったので、マップチップの重なりを使って鏡のない所でも地底に表示することを思いつけたのです。
それによって、鏡面床と、半歩の重なりで半身が映ることと、やりたかったこと２つを一挙に実現できました。
常時起動なので導入もずいぶん簡単にでき、コモンを読み込ませるだけになりました。

この発想の先にあるものは起動条件３次元の鏡かな、とか考えたのですが、ちょっと思考の限界を超えました。
ウルファールを万華鏡の底を歩かせたりジャンプさせたりし、斜め上視点から周囲の壁に移る像の変化を楽しむとかがそれに該当するかもしれませんが、需要も魅力もなさそうだし技術もおよばないので、２次元で満足することにします。

あと残るは肝心の左右反転です。
ウルファールのキャラチップセットとにらめっこして考えた結果、立ち鏡に映る全ての像には左右反転処理が必要とわかりました。
また、それに使う反転前画像は、このブログの「鏡�@」で書いた鏡像変換定数では求められないことがわかりました。
そこで新たに別の鏡像変換定数を求め直しました。
そして問題の左右反転方法ですが、上に書いた教えてもらった方法は画像の横拡大率を−１００％にするというものでした。
そんな便利な方法があると知らなかったぼくが考えていたのは、表示ピクチャを横幅１ピクセルごとのタテ線として考え、その配置を左右逆に並べる方法です。最近使えるようになったループを駆使して、それもまたなんとか実現できました。
またそれとも別に、画像変形という処理でも可能と分かりました。

ただそれら３つの反転方法には共通の問題がありました。
鏡像を表示しながらキャラを横に走らせた時、少し遅れてついて来るのです。
気にならないと言えば気にならない程度なのですが、やはり鏡の像がずれているのは問題です。
常時起動のイベント内で常に反転画像を表示し直しているので、負荷が原因かもしれないと考えました。
そこでピクチャ番号をマップチップより大きくしてみたり画面外からの移動での表示を試したり、いろいろしたのですが・・・。
結局ズレの理由はわかりませんでした。負荷は関係ないかもわかりません。
しょうがないので荒技ですが、キー入力を監視して横キーが押された時だけ、移動方向に２ピクセル進んだ位置に表示するようにしました。これでぴったりそろいました。反転方法はせっかくだから教えていただいたやり方を採用しました。
そろったのを見て驚いたのですが、そろうときれいです。上下で同じ象が同時に同じ動きをすると、ほんの少しずれているのと全然違います。前にアニメーションの変化はほとんど意識していないと書いたぼくですが、アニメーションがそろっているのもはっきりわかるくらい、上下の像は完璧に動いてくれました。そろうように悩んで手間をかけたかいがありました。

ちなみに上下の移動時もズレはあるようです。けれどそれは気にならなかったので手は加えませんでした。キャラが上に移動し止まった直後、鏡像はわずかに上に移動します。まあこれは急ブレーキによってキャラの体の角度が変化したことによる映り方の変化だととれる程度だし、それはそれでいいかんじと思いました。

地面に穴をあける仕様なので、ウディタでは遠景を設定しなければ穴の底は漆黒の闇なので、鏡のベースになる画像を用意して鏡像のさらに下に常時表示させることにしました。キャラが画面上のどこにいても画面端の鏡が黒くならないように、画像の幅は画面サイズの２倍以上にしました。
キャラクターはマップ上をのんきに歩いているように見えても、地底では自分の鏡像と画面サイズ以上の巨大な鏡をどこに行くにも連れ歩いているのです。それはマップに掘られた深い穴のほとりにさしかかった時だけかいま見えるという仕組みです。

壁用の立ち鏡と鏡面床との違いは、映る像の向きが違うのはもちろんですが、そのもととなる使用グラフィックも違うということがわかりました。鏡面床の場合は画像の選定は全く簡単で、その瞬間のキャラのグラフィックをそのまま使えばいいんですよね。
だからこれは鏡像変換定数というのはおかしいかも知れません（変換はしていないので）。
けれどもキャラが現在使用している、歩行グラフィックのパターン番号（アニメパターンでなく）を簡単に取得する方法は見当たらなかったので、ここはやはりキャラの向きとアニメバターンから割り出す数値が必要でした。

これは前からですが、鏡像変換定数は並列のコモン内で入力させています。つまり一度入力させればすむものですが、毎フレーム同じ数値を８つも読み込み直してくれているようです。そのおかげでデータベースなどを使わずにすみ、導入がずいぶんしやすくなっています。ウディタには無茶苦茶にこき使われてもらって感謝しています。

さて公式コモン集に公開した「鏡コモンセット」には立ち鏡と鏡面床と二つのコモンを入れているのですが、その二つは基本的には併用できません。同じマップで両方使いたい方は改造が必要です。改造のヒントは一応配布フォルダ内にテキストで書きましたが、２種類の鏡の起動を制御する方法はマップ構造によってケースバイケースだと思うので、一概には何とも言えません。遠景使用についても同じです。相談いただければ時間が許せば一緒に考えようとは思います。

これでほぼ目指したものはできたわけですが、個人的にはせっかく思いついた手動で画像を反転させる技術を何かに生かしたいと思い考えたのですが、キャラ画像を線単位で操作できるわけだから、これを使えば例えばキャラの下３分の１とかを表示できます。生首！とかもできますが、一度やってみたいのは水面に映るキャラの像です。鏡面床コモンを使っただけでは、キャラの全身が映るので、岸辺が崖などになっている場合に崖に映ってしまうのです。表示位置は調整できますが、足の影が足からあまり離れた所から始まっていると違和感があるだろうし・・・。そこでピクセル単位で表示部分を指定出来れば、と考えています。

本当はそれより何より目指したいのは、複数パーティーの二人目キャラや通行人も映る鏡を作ることなのですが、どうしていいかわからないので、ここをお読みの方でもしアイデアがあればぜひ教えてもらえればと思います。
長文が続いた鏡シリーズでしたが、とりあえずいったんこれで終わります。長々読んで下さったあなた、どうもありがとうございました。

緊急事態です！
なんと、満を持して公開したはずの鏡コモンに信じられない不具合がありました。
あろうことか、鏡なのに映る像が左右反転しているのです！！！
気付いた人はいただろうか？
ウルファールの帽子の羽がぼくに教えてくれました。
まさかあの羽に助けられるとは。
鏡としては許されざる過ちだと思います。左右反転だなんて。
とりいそぎ、公式コモン集での公開を取り下げました。
たかが一マスサイズのグラフィック表示と油断していたかもしれません。
うーん、鏡、奥が深すぎる。
鏡について考えようとするなら、位相幾何学だか何だか、難しい学問をしないといけないのだろうか。

ちなみに、連続鏡面壁の原理は完成しました（左右反転だけど）。
後は汎用性を高めるだけだと思っていた矢先だったのに！
今後は鏡開発はいったん中断し、というか鏡開発の一環として、反転画像作製技術開発に取りかかります。
手間とPC処理能力は食うにしても、原理的にはできると思っています。

ご迷惑をおかけした方、いらっしゃったら大変申し訳ありませんでした。
それにしても、このおっちょこちょいは直さないといけませんね。

先日はウディタ上で鏡を実現する方法について書きなぐりました。

「キャラの座標をピクセル単位で取得する方法がわからない」とか「コモンだと呼び出し元の座標を求めるのが面倒」とか書きましたが、それらの問題はあっという間に解決しました。
たいていのことが出来てしまうウディタはすごいです。

数日がたち鏡が一応形になったので、ウディタ公式ページのコモンイベント集に投稿しました。
（追記、公開を取り下げました。詳細は次の日のページをごらんください。）
興味のある方は「鏡コモン」で検索して下さい。
今日はそのコモンについてです。
用途が限定される部分が多いので、それを誰かが自分のゲームに合うよう改造しようとした時に、参考になる内容をここにに書きます。配布サイトでの説明や同梱説明書と重複する部分もありますが、ご了承ください。

原理としては、
「主人公と並列マップイベントが重なった時だけ、上のマスに鏡に映った画像を表示する」
そんなコモンです。

マップイベントが並列起動という所は特徴的かもしれません。
普通主人公の位置によってイベントを起動するには「プレイヤー接触」を使うことが多いかもしれませんが、今回は鏡の前から離れた事も判定しないといけないので、マップ内では常時監視が出来る並列起動を使いました。並列起動ならどこにあっても条件が合えば動いているのだから置く場所などどこでもいいようなものですが、コモンの導入を簡単にするために、鏡の下のマスの座標を指定するという役割もその並列イベントに持たせた結果、鏡の前に置くことになりました。

座標の重なりはピクセル単位で監視しています。だから半歩ずれていても映りません。正面に立ち止まった時だけ映ります。鏡の前を横切った時は映る時と映らない時があります。
半歩ずれて映らないことが不自然にならないように、中央を透過した鏡の枠素材を用意しました。鏡の枠はマップでなくイベントとして置く仕様です。
これはピクチャの表示順の都合で、鏡に映る像（以下、鏡像）を枠よりも下に表示させるための工夫です。


ちなみに枠はウディタにデフォルトで入っているタイルセットに追加しました。
イベントとして使うなら単独のキャラグラフィックでよかった気もしますが、はじめ枠をイベントとして使うことを想定していなかった時点で作りました。そして迷いましたがそのまま公開しました。

というのは、鏡は縦に二マス分のサイズがあるのですが、その上のマスは通常の使用ではマップタイルで十分だからです。どういうことかというと通常は鏡像は一つ上のマスにほぼ収まるので、枠が必要なのは鏡の下半分です。タイルに組み込んであれば鏡の上下の位置関係が一目でわかるし、マップとして使うかイベントとして使うかの選択の幅も広がるかと思ってタイルに入れたままを選んだのです。

鏡像にどのピクチャを使うか、正確には指定ピクチャの一部分をどのパターン番号で呼び出すか、その求め方がこのコモンの一番独創的な部分かと思います。
詳細は前回書いたつもりだったのですが、でもよく読むと全然説明していないので、ここにあらためて書きます。

「キャラの向き」×１０＋「アニメーション番号」＋「鏡像変換定数」＝「使いたいパターン番号」
となるような、「鏡像変換定数」という数値を求めました。これはキャラの向きに応じて８通りあります。
（なおこれは３パターン８方向の歩行グラフィック専用の数値なので、別規格で同じことをしたい方は、この乱文を解読して自作して下さい。まあメールで頼まれたら考えるかもしれません、が。）
上の式は左辺にも右辺にも同じアニメーション番号の数値を足しているので、
「キャラの向き」＋「鏡像変換定数ダッシュ」＝「使いたい３つのうちの左のパターン番号」
とかいうまた別の鏡像変換定数を出すこともできたかもしれませんが、けっきょくそれにまたアニメーション番号を足してパターン番号を求めないといけないのでややこしいことには変わりないので、一つの式にまとまるようにしました。

ちなみにこのコモンは、アニメーションの配置パターンがそろっているという前提で作っています。
３パターンアニメーションの場合、キャラ表示はキャラがある向きを向いていてそして３つのわずかに変化する画像を切り替え表示し続ければ問題はないので、配置順がどうあろうと構わないのです。仮に上中下という３つなら、上中下でも中下上でも（初期画像は違っても）同じなのです。けれどこのコモンでは上中下と中上下の混在は困ります。
主人公のアニメーションに同期した別向きの鏡像を映す仕様なので、主人公が上、鏡像が下ということになっては問題なのです。
まあ正直なところ、ぼくは３パターンがどう違うか見分けるような細かい神経を持ち合わせておらず、配布サイトにスクリーンショットを撮ったウルファールの歩行グラフィックについてもパターンが対応しているのかどうかも実は確認していません。（そもそもコモンの動作テストをしたウディタサンプルゲームでは主人公は歩かない時アニメーションしないので、鏡の前で立ち止まっても動かない）
そこで、もしも鏡に映った像とその前に立つキャラとがあまりに違う動きをしていて困るという場合は、鏡像変換定数周りをその変則的な歩行グラフィックに対応させる大改造が必要かもしれません。そんな方がいれば大変でしょうが応援します。

このコモンではとにかく使用者の導入の手間を軽減することを目指しました。コモンの自作はおろかマップイベントもテキスト表示しかできない、条件分岐もマップイベントの起動条件に頼り切っていた昨年夏の自分でも使えるようにしました。
そのためにコモンの引数指定を最大限に使いました。もっとも昨年のぼくはコモンの引数指定なんてできませんでしたが。・・・そうですね、その説明もするべきですね。
ここをごらんの初心者の方に説明します。（ここまで訳のわからないことを羅列したあとにどれだけの初心者がを読んでいるかわかりませんが。）引数指定というのは、コモンを呼び出す時にコモンに引き渡す情報のことです。コモン呼び出しを指定する画面でコモン名を見ただけでOKしてしまわず、[コモンEv入力（数値）]の下などでどんな設定ができるか気をつけてみてみて下さいね。

ぼくの鏡のコモンでは�@鏡の通し番号、�A鏡像の高さの補正、�B鏡像の透明度、�C鏡の下地になる画像をコモンに描かせるか、の、その４点を引数で指定できます。全てプルダウンリストで選択するだけで済むので簡単です。
その一方でこのコモンを改造しようとしている人には、これらの初心者への配慮がかえってコモンを理解しにくく、使いにくくしているだろうことは申し訳ないです。あらゆることが出来るウディタだから好きな設定が出来るのに、初心者の利便ために自由度が制限され、それを取っ払うために面白くもない他人の作った仕様を理解しないといけないというのは納得いかない部分もあると思います。そんなことするくらいなら全部自作した方がよほど早いと思うかもしれません。それでもぼくは今回はこのコモンは初心者でも簡単に導入できるということを目指したので、そのために不便を強いられる改造しようとする人にお詫びの気持ちを込めてここにできるだけヒントとなることを書いておこうと思っています。
引数�@の通し番号というのは鏡の識別番号です。同じ番号のコモンから呼び出された鏡像および鏡の下地画像（後述）は同じピクチャ番号で表示されます。そのため複数の鏡を配置した時に、あるマップイベントに座標が一致しないために別のマップイベント上に立っていても鏡像が映らない現象が起きます。それを防ぐために鏡を複数置く場合は�@を変えて下さい。言いかえれば鏡のチャンネルのようなものです。ちなみに上限は１５枚ですが、ちょっとした改造で画面いっぱいに置くことも可能になると思うので、やってみたいけれどわからない方はメールで質問して下さい。

�A�Bはそのままなので説明はいらないと思います。いろいろ試してみて下さい。ただ、鏡の枠をイベントにするのは普通下半分だけでいいと上の方に書きましたが、�Aで高くする場合は枠を上下ともイベントにして鏡像より上層に描かれるようにして下さい。
�Cの鏡の下地になる画像、これも導入の手間を減らす工夫です。鏡の下地、つまり枠の中・鏡像のバックは、灰色っぽければいいだろうからマップをタイルセットの机？の中央部分などにしてもらえばいいのだけれど、導入方法を説明する文章に「鏡の位置のマップの色は〜」と書きながら、わざわざやってもらうくらいならこっちで用意してしまおうと思いたち、＜SQUARE＞というピクチャを使って描いてしまいました。このピクチャ番号は鏡像の１６倍にしていますが、それが１５以下だと鏡像と番号が重複して不具合が起こりうるからです。
水面に姿が映る等の時には�Cは非表示に設定して下さい。

最後にこのコモンの今後のバージョンアップなどの見通しなどについて考えてみたいと思います。
まず、画面サイズが３２０×２４０限定というのはこのコモンの汎用性を損なう大きな問題だと思っています。
できれば改善したいし、これはおそらくぼくの技術で可能なような気はしています。ただ需要があるかわからないので、もしも別サイズを希望するコメントなどがいくつかもらえたら考えようかと思っています。
ゲーム画面に映るパーティー画像がそのまま映らないのも大問題です。
現状では可変DBの「パーティーメンバー１」の画像しか映せず、複数パーティーやイベントがうろつくマップでは使えないという致命的欠点があります。
しかし「パーティー画像」設定ではパーティーメンバーリストにないキャラ画像も隊列に入れることが出来、その情報を保持している場所も見当がつかないのでこれが改善できる見通しは立ちません。
一番実現したいのは、連続鏡面壁の実現です。これはできそうな気もします。そもそもぼくは前回書いた文章でばれてしまったようについ最近までキャラクターの座標をピクセル単位で取得できるということを知らなかったので、そのあたりについてはこれから考えてみます。それが実現すれば、一番最初に目指した鏡面床ももうすぐそこです。
この企画はまだ続く！

追記
このコモン導入時の注意事項を書いておきます。
ぼく自身何度も「あれ？」とつまずいている部分なので・・・。
●●●●●鏡コモン導入時の注意点●●●●●●
・コモンを呼び出すマップイベントは並列起動！！！
・すり抜けの設定にはチェックを入れておく！！！
・鏡の枠はイベントとして設置！！！

ツクールでは鏡面床という演出をするスクリプト（？）があるそうです。
見下ろし型RPGのマップ上で、ツルツルの床にキャラクターの姿が逆さに映るのです。足元に。
これをウディタでどう実現できるか考えてみました。

並列実行のイベントを使ってキャラの座標を監視し、キャラ画像をピクチャとして取り込み反転させ表示すればいいと考えました。
けれどキャラの座標をピクセル単位で取得する方法がわかりませんでした。
なめらかな広がりを持つ床の上で、キャラがマス目中央にさしかかるたびに影がカクカクするのはおかしいです。
そこで、ぼくの今の技術力では鏡面床はいったんあきらめることにしました。

そして、「床はシームレスだから難しいんだ」と、レベルを下げて一面鏡に挑戦することにしました。
これなら鏡正面に来た時以外は姿が映らなくても不自然じゃないから、細かい座標も必要なく簡単なはず！

・・・と思ったのですが、しかしそれは間違いでした。
というのは、鏡は立てますよね、普通。
女性のスカートをのぞきたいヘンタイさんの仕掛けた罠でもない限り、床に鏡があることはないわけで。
とすると、鏡の場所はキャラクターの上のマスになります。そこで意外な問題が。
下のマスにキャラの上下反転画像を映せばいい鏡面床とは違い、キャラの上のマスに置く一面鏡の場合、そこに映る画像は複雑極まりないのです。
具体的には、後ろ姿を映さないといけない。鏡面床がキャラ画像の角度と透明度だけ変えればよかったのとは大違いで別画像を用意しないといけないのです。

けれどもそこであきらめるのは悔しかったので、キャラの情報を取得して一面鏡に映す画像を用意する方法を考えました。
汎用性を求めると技術がいくらあっても足りないので、使用状況を極限まで限定（注１）しました。するとある程度めどが立ったので、まだ途中ですがモチベーション維持のためにここに公開します。

キャラクターの向き、アニメーション番号、そして分割ピクチャのパターン番号という３つの要素をこねくりまわして、「鏡像変換定数」とでもいうべき数値を出しました。
これは「鏡の下のマスに立った主人公の向きによって、鏡にうつすべき主人公画像のパターン番号を求めるのに必要な数」です。なんだかすごいですよね。
以下にそれを説明する画像を用意しました。無茶苦茶ですが。


左上はウディタで向きを表す数、その右は３パターン８方向の歩行グラフィックの配置、その実例がその下の画像、右上のエクセル表が今日のキモで、その下はウディタのパターン番号の振り方です。
ぼくの思考経路を書いても意味がないので結果だけ書きます。

「キャラの向き」×１０＋「アニメーション番号」＋「鏡像変換定数」＝「パターン番号」

です。一番右上の表が「鏡像変換定数」です。これには方向と連動した法則性のようなものがないかと期待していたのですが、こうして書き出してみてもぼくには見出すことはできませんでした。方向というのはビット積（２進数）に関係するので、ぼくがそれを理解できればまた違ったかもしれないですが・・・。

まあ、この「鏡像変換定数」をデータベースに入れておけば、鏡に映す画像が一行で指定できそうな気がしています。
今日はここまで！

（注１：歩行グラは３パターン８方向限定、アニメパターンの並び順は対応しているという前提、パーティーメンバーは主人公一人という前提、マップイベントとしての使用限定←コモンだと呼び出し元の座標を求めるのが面倒なので）

タイトル通りの内容についてです。
手軽に作曲できるミノ式シーケンサーというフリーソフトがあるのですが、それを使って作成したMIDIファイルをツクールで再生すると、２周目以降から音質が変わるという不具合が起こりました。

原因の詳細はわからず、これがミノ式のみで起こることなのかもわかりません。
ただ対処法などはわかりました。
曲の最終小節を削除し、そこに同じ譜面を打ち込むことで不具合は解消しました。（ぼくの場合）
最終小節を削除するだけでも現象はなくなるのですが、それだと曲がおかしくなるので・・・。
同じ悩みを抱える人がいれば試して下さい。

ちなみに、最終小節を後ろの方に貼りつけて最終小節を削除し、新たに張り直して後ろのコピーを消すという方法では改善されません。けれども打ちなおせば良くなるので、特定の譜面の入力状況によって引き起こされているのではないようです。
またこれには、ループポイント設定も、音色も関係ありません。
またツクール（VX）でもウディタでも、同じファイルでは同じ現象が起きます。
曲の冒頭を削除しても改善されません。


この情報に興味のある人は少ないと思いますが、このことを知りたがっている人が検索でたどり着けるように念のためここに書き残しておきます。

それにしても、このブログには最近は誰かに有用な情報を書こうと思っているのですが、情報がピンポイントすぎますね。

床屋クルクルって、何のことかわかりますか？
ぼくの作った言葉ですけど。
・・・そう、あれのことです。

今日はウディタを使う人のための内容です。
ウディタで動く床屋クルクルのセットを作りました。
使いたい人はどうぞ。
↓↓↓
tokoya kurukuru.lzh
ここからダウンロードできます。

使用画面



遠景で動くクルクル模様と、枠のマップチップのセットです。

仕様
・３２０×２４０専用です。
・床屋クルクルの裏は通れません。
・遠景を使うので、同じマップで他の遠景を使うことはできません。
・床屋クルクルは縦に２マスのサイズです。
・複数の床屋クルクルを設置できますが、動く速度をそれぞれ別に設定することはできません。
・ゲーム内でプレイヤーの操作によって床屋クルクルを動かしたり速度を変えたりはできません。
・プレイヤーの移動で画面がスクロールすると、クルクルの速度が変化してみえる場合があります。

利用規約
表記・報告必要ありません。

３月16日追記
床屋クルクルの枠は、導入しやすいようにウディタデフォルトのマップチップセットの下につなげたものを公開しています。画像加工が面倒だという方も手軽に導入できます！
（わざわざ追記するほど需要があるとも思いませんが、一応念のため・・・。）

自作ゲームを、無料広告ジョビューに掲載してもらいました。
多少の宣伝効果があるそうです。（ほんと？）
載せてもらうにはＨＴＭＬ形式とかいう記述をせねばならず、難しかったです。
いい勉強になりました。

ただ、今となっては、ネオ繚乱記を多くの人にプレイしてほしいという気持ちはなくなりました。
まあだからといって公開停止にするのもなにか違うと思うので、そのままにしています。
また気がむけば、報告いただいたバグの修正をしたいと思っています。

それと同時に、次のゲームを作りたいです。
プレイヤーにやさしいゲームを、作りたいと思っています。

ゲームプレイ中にＦ１を押し、チェックボックスにチェックを入れるとよい。

たったこれだけのことがわからず、ランタイムパッケージを再インストールしたり、愛用してるＶｉｓｔａの仕様を疑ったりしつつ、一年くらい経過していました。
このチェックはおそらく一年以上前に自分で操作したのだろうけれど、その設定はどうやら、違うＶＸゲームをしようがランタイムパッケージを再インストールしようが、持ち越されるようです・・・。


同じことに困る人が、このページにたどり着きますように。

おまけのマメ知識
ＶＸのゲームの起動が遅い場合は、exeファイルを右クリックして「管理者として実行」すれば早いかもしれないらしい。やってみたら、確かに早いかもしれなかったです。

フリーゲーム、中でも特にＲＰＧで、会話文はどのように表示されているでしょうか。
好きなゲームのある方は、その会話がどのように表示されていたか覚えていますか？
僕は全く思い出せません。そこで調べてみました。
対象としたのはダウンロード型フリーソフトの有名作品・古典的作品です。
表は小さいですがクリックすると大きく表示されます。
レミュオールは経営シミュレーション、帽子世界はアクションＲＰＧ、それ以外はＲＰＧです。





年は公開年です。古い順に並べました。

会話キャラ名は誰がしゃべっているかの名前の表示方法です。

「」は会話文をカッコで囲っているかどうかです。

文末。はみたまま、文末に句点がついているかです。

顔グラは、顔グラフィックの位置です。


※調べ方はタイトル名を画像検索してでたものを見ただけです。なのでキャラの重要度によって別の形式がある場合もあると思います。





こう見るとけっこうバラバラですね。
意識したこともなったし、きっとどプレイヤーにとってはどうでもいいのかもしれません。細かい形式など意識に上らないかもしれません。
けれどゲームを作る側にしたら、やはりどうするかを決めないといけないですから大事ですよね。


あと、顔グラのないゲームもあるかと思っていたのですが、ここにあげた作品には全てありました。ただそのほとんどは主要キャラのみで、全ての人物に顔グラがあったのはElonaだけだったかと思います。
顔グラの位置はほとんど左でした。けれどウディタのデフォルトでは右なので、今後は右も増えるかもしれません。

文頭だけカッコをつけて文末では省略する記法はこれを見る限り２００５年以降は採用されていないようです。時代の流れなのでしょうか。
文末の句点（。）を確認できる画像を探すのは苦労しました。スクリーンショットとして見栄えのいいシーンが検索結果に集まっていた可能性もあるのですが、画像の過半数は文末が『！』で終わっていました。

このような情報は意外と役に立つかもしれないと思い、この場に公開しました。
ゲーム制作する方は参考にして下さい。

僕は昨年までＰＣは

・ネットを見る、通販で買い物
・フリーゲームをする
・ブログ（ゲームレビュー）を書く
・仕事で少し（Ｅｘｃｅｌ、メール）

これくらいしか使っていませんでした。

今回ゲームを製作・公開するに当たっては、できるだけ色々新しいことにチャレンジしたいと思いました。
その結果

・ウディタでゲーム作り
・作曲・効果音作り
・グラフィック作り
・アニメーション作り（ブログへの貼り方が分からず公開は挫折）
・２ちゃんねる上でゲーム共同制作の呼びかけ（場違いだと指摘されましたが。でもおかげでこのブログが始まりました。ドメイン名にだけその頃の名残りがあります）
・日常使用と別のメールアカウントの新規作成
・ふりーむ！でテストプレイヤー募集
・ウディタ公式ページに初心者ゲーム登録
・アンケートサービス　クエスタントの利用（回収回答数はゼロでしたが）
・ベクターへのゲーム登録
・ゲーム作りで技術的に色々教えてもらったサイトの方の「レビュー作品募集」に応募

などなど、今までにない体験をたくさんさせてもらいました。（ちなみに全部無料で）
そして今日はまた、攻略情報をＷｉｋiに書き込ませてもらい、ＦＣ２とやらの形式の記述も初めてしました。

ゲーム作りを通して世界が広がり、知識・経験が増えていくことがとても嬉しいです。
わくわくしています。
今後は、ゲームの宣伝ということに取り組んでみてもいいかなと思っています。
２ちゃんねるなどで「このゲームしてみて」と書くと「作者乙」と言われて嫌がられるので、
許された場所で、作者であるということを伏せず、どれだけ宣伝ができるのかを試してみたいです。
（ゲームの知名度を高めたいたいというよりは、多様な宣伝の可能性を体感してみたいと思っています。）
まあ、迷惑顔をされない程度に・・・。
新しい世界、新しい人、新しい自分との出会いを楽しみます。楽しみです。

今後の進展はまたここに書きます。
応援してくださっている方、ありがとうございます。

このところ、ゲームを公開してせっかく遊んで下さる方がいるのだから、どこかに攻略情報を書いておきたいと思っていました。
当然ここでいいとか思っていたのですが、ちょうど今日（！）フリーゲームの攻略を集めるＷｉｋiが新しくできたようなので、さっそく書き込ませてもらいました。
攻略に詰まった際はぜひ参考にしてください。
フリーゲーム攻略Wikiはこちら

自作ゲーム、ネオ繚乱記を公開しました。

■ゲーム内容について
「ネオ繚乱記」は探索型アドベンチャーゲームです。
（所要時間は２時間程度）
逆さ言葉の収集要素があります。

ダウンロードはこちらをクリック！！


タイトル画面

多くの方にテストプレイにご協力いただきありがとうございました。
公開日は2013年12月26日です。


ゲーム中の一場面

ゲームを作る上でお世話になったサイトの方に、図々しくもレビューをお願いしました！
こんなことをここに書いて、不採用になったら恥ずかしい！けど、まあいいか・・・。

ちなみにこのページのコメント欄にバグ報告その他貴重なご意見を頂いていますが、これは以前仮に公開していたテストプレイ版に対するものなので、完成版では指摘のバグ等はなくなっています。
安心してダウンロード、プレイしてくださいね。（せっかくいただいた声なので消すのが忍びなくて、まぎらわしくてすいません）

この度ブログタイトルを変えました。
ハンドルネームも「じゃ」から「じゃ。」に変えました。
過去記事をいくつか消したり変えたりしました。
作成途中の自作ゲームのタイトルその他の募集は、感想、テストプレイを除いて打ち切りにします。
自作ゲームのタイトルは「ネオ繚乱記」にしました。
考えてくださった方、ありがとうございました。
ここはいずれはゲーム制作関係に限らず、何でも書く場にしようと思います。
けれどまずはゲーム作りを優先させます。
じゃ。のブログをよろしくおねがいします。

僕は関西人です。だから普段、関西弁を話しています。
今までは自分の話す言葉が関西弁だと意識したこともなかったのですが、ゲームを作ってそのことに気づかされました。何事であれ、新しい発見は嬉しいです。

今回のゲームで僕は、広く日本人全般に違和感なく遊んでもらうために当然のこととして登場キャラに標準語を話させました。
しかし、くだけた会話文を書くのには骨が折れました。
考えてみると標準語の話し言葉など、今まで使ったことなかったですもんね。だって必要ないから。書き言葉なら標準語も関西弁も無いようなものですが、話し言葉となるとやはり違います。
特に女の子のセリフの文末が難しかったです。
関西弁なら「○○やん？」で済む所を「○○じゃない？」とか打ち込みながら、「関東の女の子は普段本当にこんな言葉つこてるんやろか」とか考えていました。
「ふざけんなや」で済むところが「ふざけないでちょうだい」になったり、僕の書く標準語は関西弁よりも大分長くなります。それは一般的にそういうものなのか、それとも僕の標準語能力が低いためにそうなるのか・・・。
また、標準語を書こうとすると何か変に気取っているように感じたりするのですが、これはもう仕方ないと割り切って、気にしないことにしました。

標準語の土俵で勝負しないといけないというのは地方人にはハンディといえるかもしれません。創作作品に使うのが、普段から使いこんで骨肉化された言葉なのかそうでないかには大きな違いがあるはずです。
まあここはしかし、モデルやタレントにハーフの人が多いのと同じで、地方人は地方人として、その異質さを持ち味にすればいいのだと、ポジティブに考えたいと思います。まあ僕のゲーム作りに関して言えば勝負でも何でもなくて、自分が楽しむだけのことですし。

でも今度作るゲームは、もうちょっと会話を減らそうかなと思ったり・・・。それか、コテコテの大阪弁のゲームもいいかな。
いろいろ考えるのですが、そういえば、まだあれは完成していないんだった！
・・・はい、作ります。

僕が全くの素人からゲームを作り初めてから、半年位がたちました。最近、ゲームはどんなに作り込んでもモトデがかからない、そのことに新鮮な驚きを感じています。

ふつうの物作りでは、仮に椅子を改良して背もたれをつけるとするなら、それだけ材料がいります。その材料が買わないと手に入らないなら、追加のお金がかかります。
現代でも質素は一応美徳ということになっていて、ありあわせのものだけで満足できることはいいことだろうと僕などは思っているのですが、だから必要以上に物を買わない、無駄に電気がついていたら消すなど、知らず知らず身についています。

でもゲーム作りの世界では、そんなことは気にしなくていいんですね（おそらくプログラムというものは全般的にそうなのかもしれません）。僕が今回使用しているウディタというツールはとても高性能なようで、間違った使い方をしない限りはそうとう使い倒しても処理落ちなどないようです。
僕みたいなめんどくさがりは、色々な処理をできるだけ手抜きして済まそうとするのですが、するとやはりその程度のものしかできません。
だから、負荷がかかりすぎない限りは、あれやこれや、プレイヤーにとっていいと思われることは手間を押しまずやった方がいいのだろうと思うのです。

例えばループ処理というのがあり、同じ処理を何度もぐるぐる繰り返すことがあるのですが、これなんか僕から見ると水道の水を出しっぱなしにしているようで、どうもついつい控えたくなる。でもよく考えると控える理由は何もないんですね。プログラム内のぐるぐるをおさえても、電気代が安くなるわけでもない。
「プレイヤーには負担をかけるけど、内部処理はスマートです」なんて、何の自慢にもなりません。

つまり、一定スペックの動作環境があるなら、時間と手間さえ惜しまなければいくらでもいくらでもよりよいものを創りだせる。これって、ほとんど錬金術です。材料がなくても、今までなかったものがどんどんできるんだから。

すごいことだなーと、本当感心します。きっとこの世界になじんでる人には当たり前のことなのでしょうが、こんな世界もあったんですね。
まあその創造の対価となる、時間と手間というやつのコストがばかにならないわけですが。
・・・今夜もゲーム、作ります。

ＢＧＭは挫折したものの、効果音は自作できないかと思ってフリーソフトを探してみました。
すると面白い物を見つけました。

かなウェーブという効果音作成ソフトです。
（↑ベクターの紹介サイトにリンクを張ります。）
これのすごいところは、「ういーん」とか「がちゃん」とか、かなを入力することでそれに応じた雰囲気の効果音が作れてしまうのです。
これを触っていると面白くて、時間を忘れてたくさん作ってしまいました。

結局、今回のゲーム内ではアイテムを手に入れたら「ぱっぱぴー」、協力者が増えたら「なかまかな」と鳴らすことにしました。（その通りに発声されるわけではないです。）
ここをご覧の方で、効果音が必要な方がもしいたら、ぜひ一度このソフトを試して下さい。

もともと僕は逆さ言葉が好きで、きっと根っからの文字好き、言葉好きなんでしょうね。
文字列が音になるだけでワクワクします。
ちなみにＢＧＭを試作したのも、テキスト音楽サクラというソフトでした。
これは「どみそっそー」と入力すればその通りの音が鳴る仕組みです。
いろんなソフトが無償配布されていて、僕のような素人でも創作活動にチャレンジできるのは有難い限りです。

このブログで初めてゲームの感想のコメントを頂きました！ありがとうございます！
このブログ、消さなくてよかった・・・。

キャラの掛け合いが楽しめたと言ってもらえてとても嬉しいです。
ああいったものをぼくはまあ一応面白いと思っている訳ですが、けれどもきっとそれはあまり一般受けはしない気がするのです。（だから感想を教えてもらって不必要なカドをとってできるだけ人当たりをよくしたいと思っているんです。）
でも、もしほんの少人数でもそれを楽しんでもらえる人がいるなら、寝不足になりながらゲームを作ったかいがありました。あー嬉しい。

そうですね、効果音、あった方がいいですよね、やっぱり。今日も制作を進めていて、ＢＧＭを入れたのですが、テストプレイすると効果音のことがふと頭をよぎって「あった方がいいけど面倒だし、なしでもいいかー」とか思ったのですが、もう決めました。断然、入れます！誰が何と言おうが入れます！
アイテムを手に入れたり技を身につけたり、協力者がふえたりしたらやっぱり演出で音は欲しいですよね。わざわざ動きを止めるほど大げさな曲でなくても。
サカコトゲットの時はどうしよう・・・まあいいかな。いや、やっぱいりるかな？

ここでもし感想がいただけなければ一応完成させたものをテストプレイ版Ｖｅｒ．２としてまたアップして、ふりーむのテストプレイヤー募集掲示板ででもお願いしようかと思っていたのですが、今日コメントに気づいて、もうこのまま完成まで突っ走ってしまおうか、迷っています。
それにしても反応をもらえることがここまで励みになるとは・・・。ご期待にこたえられるよう、完成を急ぎます。

誰もプレイ感想のコメントをくれないのがさみしくもあるのですが、よく考えるとコメントってなかなか書きずらいよね、と、書き込みがないのはコメント欄のせいだということにして、とりあえずメールアドレスを張り付けてみたのは昨日のことなのですが、それから一日たって誰かがメールをくれたかどうかはここでは秘密なのです！

メールのいい所は、そこで何かのやり取りが行われているかどうか、傍目には見えないということですね。
「ゲームの感想はコメントで」と言っているのに誰一人書き込まないっていうのは、これはまあ悲しすぎるし、それを誰が見ても一目瞭然という状態はなかなかキビシイものがありますね。我ながら自分がイタい存在なのだと認めざるを得なくなってしまう。

そう、きっと誰かがじゃにメールでプレイ報告を送ってるんだよ。みんなそう思って。お願い！

まあメールはメールで、僕のような正体不明な存在に日常使いのメールアドレスを教える物好きは少ないだろうし、かといって僕に連絡するためにわざわざフリーメールを登録（捨てアカウントっていうやつですね）する人はさらにいないだろうから、敷居が高くなるということはあるかもしれないけど。

誰も連絡をくれないならさっさとこんなブログはひきはらってしまえばいいと思うものの、不思議なことにもったいなくも、何を思ってか毎日数十人の方がのぞきにきてくれているようなのです。内容もなく更新もしないこんな場所なのに。ありがとうございます。

そういうことならまあゲームの制作日記でも書こうかと。

今は、ひょっとしたらだれか感想をくれるかもという期待（幻想？）を捨て切れていないので、僕はシナリオには手をつけず、音楽にとりかかることにしました。
そしてフリーの作曲ソフトでBGMを作りました。単旋律で短いメロディーを繰り返す、いたって簡単なものです。ぼくは音楽にはこだわらないから、どんなにシンプルな曲でも自作して、自作ということに惹かれて少しでもプレイする人が増えればいいと思ったのですが・・・。

曲を作ってみて、驚きました。できた曲は想像をはるかに超えて、あまりにもチープすぎ・・・！
そこで参考までに音楽素材を無料配布するサイトを初めてのぞいたのですが、レベルの高さにびっくりしました。僕と比べれば月とすっぽんです。
音楽自作と銘打って僕の曲をかけるより、素直にお借りした方がゲームをプレイして下さる方のためだと思いました。

よく「素材自作なんてすごい！」とか聞くのですが、それは自作する手間をかけたことがすごいのではなくて、公開するに値するレベルのものを作りだせたことがすごいのだということを初めて知りました。
そりゃ、手間をかけるだけで評価されるなら、誰だって手間をかけますよね。一つやってみて、一つまたかしこくなりました。やってみなきゃわからないことばっかりですね。

まあ今日はこのあたりにしておきましょう。
ここにこんなことを書きている時間があればゲームを作った方がいいのかもしれませんが・・・。だから次回更新はいつかわかりません。でも明日かも。

じゃ。