シルバーセカンド開発日誌
 ここはゲーム開発者SmokingWOLF(スモーキングウルフ)の開発日誌です。
 【現在の目標】→ ウディタ3.5のバグを落ち着かせる! & 『片道勇者2』の開発!
 ※以前のブログが使えなくなったので、ただいまこの開発日誌に移転中です。
ウディタ 2/4

2025-01-25 (土)   ウディタ3.5、こっそりベータ公開中!
 ということで1/18からこっそりウディタ3.5を公開中です! ウディタ公式サイトのバグ報告スレッドで! 
 Ver3.500で公開され、今はVer3.509になっています。毎日平均10点以上も直し続けて1/24までの修正点が80個近くになるほど大量のバグが発生しているので、表だっての公開はまだ控えております! まだベータな感じですが気になる方はよければお試しください! 今も必死で修正中です!

 そんな中、さっそく新機能を使ってすごいものを作っておられる方もいらっしゃるので、Xからご紹介させていただきます! みなさま本当にありがとうございます!

 ※Ver3.507で「ピクチャ挙動Ver2」使用時の文字列の改行幅が2倍になりました。申し訳ございませんがこちらが正しい仕様っぽいので修正が必要な方は修正お願いします!



【画像データをXY配列(二次元配列)で管理できる機能で画像合成】

 こちらで投稿されている映像のようにオーバーレイ合成やクリッピングマスクっぽいこともできるようになりました!(しかもXY配列4つ使ってそのままピクチャ表示することもできます!)
 画像のアルファ値やRGB値をXY配列に読み書きする機能を使えば、画像合成回りの自由度がかなり上がります! 
 隠しコード「<<LOAD_IMAGE_TO_XY/A=?/R=?/G=?/B=?>>(ファイル名)」を使えば、画像ファイルの2次元データを4つのXY配列(ARGB分)に読み込むことができますので、あとは計算次第でなんでもできますよ!




【お絵かき掲示板が作れる!】

 前述の「XY配列の内容を画像として表示する機能」を使えば、もちろんお絵かき掲示板だって作れます! がこちらは想像以上にちゃんと動いててすごい!
 今回の新機能(隠しコード)で、XY配列から画像をファイル出力することも可能になりましたので、ウディタで完結するペイントツールを作ることも普通に可能になりました!

https://x.com/F0X_k/status/1880511375426089325




【【XY配列や新しい計算機能を使って地形生成】】

 XY配列が来たので作れたー! とおっしゃってた気がしますが、アルゴリズムでこんな自然な地形生成ができるそうです! すごい!
 XY配列にその地形情報を色塗りすれば画像にもできるので、こんな風に「ランダム世界の世界地図」のお手軽表示だってできるようになります!

 


【サウンドのパン機能を3Dゲームに搭載】

 そしてこちらはサウンドのパン機能の利用見本! 音源の場所が3Dチックに聞こえるようになっていて、ウディタ3D学会の方々の作品もさらに満足度アップ! 
 そもそもこの3D具合の完成度がすさまじい!! すごい!





【【ミニマップをゲーム内だけで作れる!】】

 XY配列を使えば無から画像が作れますので、ミニマップだってゲーム内だけでピクチャ1枚にして作れます! ということを実演してくださっています!

https://x.com/shiratamamoti/status/1882064450259402816




【ウディタ3.5の紹介記事を書いてくださいました】

 そしてこちらはウディタ3.5の感想記事! テンション高い内容&ウルファールのイラストまでありがとうございます! 

【ウディタver3.5(ベータ)公開おめでとうございます記事 (あきら様より)】 (アーカイブ)


 プロ版にはレイヤー5まで使えたりフォントの暗号化ができたりしますのでさらなる上級者の方はよければぜひ!(ただしウディコン審査中はプロ版が使えないのでご注意を!)




【これまでの新機能紹介記事のリンクまとめ】

 これまで書いてきた新機能紹介の記事が8回分もあるので、もし細かく見ていきたい方はこちらもどうぞ!

その1(セキュリティ関連や始まり)
その2(空Ev作成/フォント暗号化)
その3(経路探索/キャラレイヤー強化)
その4(ピクチャリンク/DBソート/特殊文字入力) 
その5(自動移動/パン/オートタイルアニメ速度)
その6(XY配列/TXT入出力[Git用]) 
その7(タブウィンドウ/正規表現/ゲーム内画像生成/レイヤー5搭載)
その8(BGSチャンネル機能・エフェクトディレイ・コマンド折りたたみ)



【引き続きバグ修正がんばります!】

 しばらくは必死にウディタ3.5のバグを直す日々が続くと思います!
 安全にご利用になりたい方はもう少しお待ちいただいてから、もう3.5に慣れていっちゃうぞーという方はぜひもうお試しください! 今はバグ報告スレッドでこっそり公開中です!

 ということで引き続きバグ修正、がんばっていきます!
 開発費はすでに完全に枯渇してるので石油王のウディタユーザーの方がいらっしゃいましたらご支援/投げ銭もお待ちしております!!! さすがにここまで来て新しくウディタプロ版買われる人はあんまりいらっしゃらないので、ウディタのマネタイズとしてはほぼ一旦終了してしまった感じです(そしてこれ以上努力してウディタを売ろうとするより、自分でゲームを作った方が圧倒的にお金にできます、当たれば!)。

 早くウディタ3.5を落ち着かせて私もゲーム作っていかないとですね! がんばります!
 2025-01-25 (土) web拍手 by FC2 カテゴリ: ウディタ




2025-01-11 (土)   ウディタ3.5開発中その8 BGSチャンネル・コマンド折りたたみ等
 ウディタ3.5開発の経過報告、その8! たぶん最終回です!
 引き続きX(Twitter)などでご要望をいただいて「あ、これ入れたいと思ってたやつだ、忘れてた!」となっては追加で実装する日々が続いております!
 新機能は目次だけご覧になればだいたい分かるとは思いますが、それぞれ詳しく見ていきましょう!


●BGSの多チャンネル化!


 なんとウディタ3.5ではBGSにチャンネル機能が付きます!
 以下の映像で再生見本を流しておりますので気になる方はぜひ!

https://www.youtube.com/watch?v=-raNSyYmVUg


 「BGS」とは「WAVやOGG、MP3形式」のサウンドのみ、つまりMIDI以外を「ループ」で流せるモードなのですが、これが多チャンネルで再生できると色んなことができます!
 滝の音や鳥の声みたいな環境音をたくさん同時に鳴らしたり、パン(左右偏り)や音量の大小差を付けたり、なんでしたら状況が変わるとシームレスに音が切り替わっていくインタラクティブミュージック的なこともしやすくなるかもしれません!
 こだわる人には色々使い道があると思いますので、今後ぜひご利用ください!
 


●ピクチャエフェクトにディレイ設定可!

 エフェクトの「ピクチャ」にディレイが設定可能になります!
 つまり座標を元のピクチャから+10する、みたいなのをディレイを付けて未来の分まで設定しほうだいになるってことですね!


 これによって、ディレイだけで大量のエフェクト予約などして気軽に動かしたりもできますし、そっちのほうがピクチャ本体を動かすより処理が軽いと思いますので、色んな意味でさらに無理ができると思います! 私もピクチャエフェクトで色々制御することが多いので、これは私も欲しかったやつです!

 ちなみに、これはピクチャコマンドの「ディレイ」設定と内部処理的には同じものが使われていますので、ピクチャ側の「ディレイリセット」コマンドでエフェクトのディレイごと全部消すことができます。まとめて消えた方がラクだと思いますのでこれでいきます!



●コマンド折りたたみやコメントアウトが可能に!

 これも映像を作ってありますのでよければご覧ください!
https://www.youtube.com/watch?v=jZzEkfpF1yQ


 「折りたたみ」は文字通り、「条件分岐」や「ループ」コマンドを折りたたんでおける機能です! 条件分岐は分岐1つずつでも、全部まとめてでも折りたためます!
 折りたたんだコマンドはダブルクリックですぐ展開可能です。

 「コメントアウト」は直接そういうコマンド名があるわけではなく『0回ループに入れる』というコマンドが追加されます!
 0回ループに入れた部分は処理されないので、コメントと同じく緑色になります。処理されない部分が一目瞭然に!
 なお「0回ループ」内に「ラベル地点(他の場所からジャンプしてこられる)」コマンドを入れてそこに飛ばす、という使い方もあるので、0回ループ内でも「ラベル地点」があったらそこ以降は色が元に戻るようにしています。安心!

 また、「0回ループ」や「1回ループ」を選択したときに右クリックメニューを開くと、ループ0→1回、1→0回の切り替えもできます! ショートカット(Q)もあるのでバッチリ!
 これから気軽に0~1回ループに入れていきましょう!
 ただし「ループから出る」とか「ループ先頭に戻る」処理の範囲が変わってしまうので、それだけはご注意を。




●ファイル選択ウィンドウで音声再生も可能に!+画像が自動拡大で見やすく!

 ファイル選択画面に以下の強化を加えました!

●画像サイズに応じて自動拡大縮小されるようになります! 小さい画像は200~400%に、大きな画像は枠内におさまるように。
●音声再生が可能です! MIDIはゲーム内と同じ音源で再生されますし、効果音のチェックも非常にラクになります!


 見てみたい方はこちらの動画より! ↓
https://www.youtube.com/watch?v=-kd-mIkBHaM


 しかしこの一見大したことなさそうな『ファイル選択ウィンドウ』、搭載されている機能を考えると余裕で1アプリ相当になると思います! ツクールとかに入ってるファイル選択ウィンドウも実は凄い! いろいろ見られるようにしたり、色んな形式の音声を再生できるようにしておくのは、実は思ったよりも大変でした。
 でも、これからは画像も音声も気軽にチェックできますよ!



●\imgの特殊文字を強化! 文中にアニメーションアイコンを入れたり画像の一部切り出し可能に!

 「\img」または「\imgS」に裏技を追加しました!
 「\img(S)」の後に「<DIV/」「<CUT/」「<ANIME/」から始まるコードを記入すると、画像を特別な方法で表示することができます。それぞれの例は以下の通りです。

- 分割表示 DIV \\img[<DIV/X3/Y4/5>Pic/Test.jpg]
  「Pic/Test.jpg」を横3、縦4パターンで分割し、パターン5を表示します。
  パターン番号はピクチャと同じで、「1」から始まります。

- 部分切り出し CUT \\img[<CUT/X123-150/Y200-300>Pic/Test.jpg]
 「Pic/Test.jpg」の X123~150、Y200~300pxの範囲だけ切り出して表示します。
  X0-2なら左端の1ピクセル目から幅2ピクセル分だけ表示されます。

- アニメアイコン ANIME \\img[<ANIME/X6/Y4/8>CharaChip/Chicken.png]
 「CharaChip/Chicken.png」を横6、縦4パターンで分割し、8フレームごとにアニメーションします。
 アイコンとしてアニメーションさせた上にルビを付けることも可能です!
 見本はこちら↓
  → 





 という感じで、今回もウディタ3.5での表現力がアップしたり、開発の快適性もアップしております! 普通に一ヶ月単位で遅れるくらい実装が大変な部分もありましたが、この先ずっとウディタを使うことを考えれば安い投資でしょう!


<余談:マスク機能について>
 あと、ご要望の中でたびたび挙がるものとしてマスク機能の強化があるのですが、これはライブラリ側の都合で、今の通り「マスク1枚しか使えない」+「画像を回転させたり拡大したりしてマスクすることはできなさそう」が限界そうでした(そしておそらく、1フレーム中に何度も切り替えする前提の処理速度で使えるマスク切り替え機能は入ってない気がします)。なので、マスクについては当面は変更されないと思います。

 他にも描画周りはほとんどの処理をライブラリに依存しており、「何かの新機能を作るべく代わりの機能で似た機能を代替しようと思ったらめちゃめちゃ重くて結局使い物にならなかったー!」となって終わる経験も今回たびたび繰り返しています。
 需要が高くても実装されないものは、だいたいこういう経緯で搭載を諦めていることが多かったりしますのでその点はご容赦ください。
 他にも実装されない理由として、単純に技術的に難しいとか、出てきそうなバグがあまりに多すぎて心が折れた、私にとっての需要や興味がなさすぎた、などもあります。ウディタ3.5開発では、それを乗り越えられた量がすごくいっぱいありましたね! やはり元気は大事!


<今後について>
 そしてまた、ウディタ開発予算もすでに超絶マイナス突破してるので、今回挙げた分で、3.5への修正は終わりにする予定です! お賽銭やご支援をくださった皆さま、本当にありがとうございます!
 現在は、すぐ見つかるバグの修正や、新機能の調整や、マニュアル修正にいそしんでおります! 一通りすぐ見つけられる分の問題を解決できましたらリリースできると思いますので、ほんのり楽しみにしつつ、もう少々お待ちください!(もちろん公開されてもバグは出るでしょうね! よければご協力お願いいたします)

 それでは最後の仕上げ作業、がんばっていきます!
 2025-01-11 (土) web拍手 by FC2 カテゴリ: ウディタ




2024-12-14 (土)   ウディタ3.5開発中7 タブ・正規表現・レイヤー5・XY配列ピクチャ
 ウディタ3.5開発の経過報告、その7です!
 Xなどで様々なご要望をいただいており「あ、これ入れたいと思ってたやつだ!」となっては追加で実装する日々が続いております!
 当面の最後の大規模実装だと思って、自分の技術で作れそうなもの、かつ私や多くの人が必要そうなものはどんどん採り入れ中です。

 ということで、今回もウディタ3.5に実装される新機能をご紹介します!



●タブウィンドウ化! 行ったり来たりする作業の効率アップ!



 ウディタ3.5からは「マップイベントウィンドウ」「コモンイベントウィンドウ」「データベースウィンドウ」の3つにタブが付きます!
 いま開いている場所(イベント番号や行数、スクロール位置など)がタブごとに保存できるので、たまにある「あっちとこっちの処理を見比べながらデータをコピーしたり入力したりする」場面では非常に便利です!
 忘れておきたくない場所にタブを開いておけば後からでも開けるので安心!

 特に「データベースウィンドウ」でのマルチウィンドウ機能が欲しいというご要望をだいぶ昔からいただいていたのですが、それもこのタブ機能で、ある程度はカバーできるようになると思います(技術的な都合でよさげなマルチウィンドウが作れませんでした)。

 なおこのタブ機能、ちゃんと「エディターオプション」から従来通りの「タブなし」に戻すこともできます! 以前通りの方がいい方や、タブの縦幅すらカットしたい人にはそちらもぜひ!




●【正規表現】が「文字列操作」や「条件(文字列)」に搭載!

 文字列周りの処理についに『正規表現』が実装されました!
 紹介映像を作りましたので見られる方は以下をどうぞ! 正規表現について知識ゼロの方でも、ほんのり使い方が分かると思います! たぶん。


 ウディタ3.5では、【文字列操作】に「正規表現で()内抽出」と「正規表現で置換」、そして【条件(文字列)】の比較コマンドに「の正規表現と一致」が追加されます!
(ちなみに「条件(文字列)」には他にも「を含まない」場合と「が最後にある」場合の比較コマンドも追加されました! これらも便利!)

 「正規表現」とはおおまかに言うと「あいまい検索」みたいなことができる機能!
 たとえば「人数400人」が入った文字列S1に対して、正規表現で「人数(\d{1,4})人」の「(正規表現の)()内を抽出」処理を行うと、S1には「400」という数値のみが返されるのです!
 「\d{1,4}」は「1~4桁の半角数字」で、それを()で囲んでいるので、その数値部分だけ抽出して返してくれるわけですね!
 もし1つの文字列に2つ以上当てはまる部分があったら、2行の文字列として返してくれるようになっています。
 
 また、「条件(文字列」の「の正規表現と一致」も同様で、正規表現で「人数\d{1,4}人」(\d{1,4}=1~4桁の半角数字)と指定しておくと、文字列側が「人数1人」でも「人数1234人」でも「条件を成立」させられるのです!!
 一方で、文字列が「人が1人」だった場合は、いくら似てても「成立しません」。

 このあいまいさは「\d」に始まる「メタ文字」というもので色々な表現を書くことができます。
 たとえばさっきの延長で、「\d{1-3}-\d{1-4}-\d{1-4}」の正規表現に該当する文字列が含まれてたら「電話番号っぽい数字が入力されたぞ!」みたいに認識できたりするわけです! 
 これを駆使すれば、「掲示板への書き込みで電話番号っぽいのが書かれていたらその投稿を弾く」みたいな処理だって作れるわけですね! 正規表現のおかげで、「000-0000-0000」から「999-9999-9999」まで全パターンの禁止ワードを入れたりする必要はなくなるのです!

 この「正規表現」はプログラミングにおいてよく使われるもので、文字列の取り回しやすさの限界値が大幅にアップします!
 といってもかなりのガチ勢向けで、私も普段よく使うもの以外は見ずに書けないので割と達人向けです!
 テキストスクリプトなどを作成される方にはとても便利だと思いますので、よければぜひご利用ください。
 
 これから正規表現を学びたい人には、「正規表現 サンプル」などで検索すれば勉強になるページが色々出ると思いますので、色々探してみてください!




●マップのレイヤーが5まで使用可能に!(プロ版専用)

 これまで3レイヤーまでしか使えなかったマップのレイヤーが、ウディタ3.5からはレイヤー5まで使用可能になります! ただし使用できるのは「プロ版のみ」です!

 仮にプロ版で「レイヤー5」まで使ったマップを作って、そのデータを無料版Game.exeで起動すると、「レイヤー3までしか表示されなくなります」ので、その点はご注意ください。
 つまりウディコンでは、審査中はマップレイヤー4~5は使えないということですね。

 
 ↑マップレイヤーの拡張は「ゲーム基本設定Pro」から設定可能です。
 レイヤー4だとマップの描画負荷が1.33倍、レイヤー5だと1.67倍になりますのでそこはご注意を!
 それでも、従来よりもさらに複雑なマップ表現が行えるようになります!




●「XY配列をピクチャとして表示」する機能を追加!

 これは事実上、「ゲーム内で好きに画像を作れる」機能です!
 アルファ値、R、G、Bのパラメータを保存した4つのXY配列(2次元配列、無限に作れる)をピクチャのファイル名指定欄に隠しコマンドで指定すると、その配列の値にしたがった画像をゲーム中に表示することができます!!
 以下のコマンドをピクチャのファイル名のところに入れると出せます!

「<XY_IMAGE/A=?/R=?/G=?/B=?/XSIZE=??/YSIZE=??>」または
「<XY_IMAGE/A=?/R=?/G=?/B=?>」


 「?」部分には、Aならアルファ値だけを格納したXY配列番号を、R、G、Bにも同様に各色の0~255の値を記したXY配列番号を指定します。XSIZE=??やYSIZE=??の部分には使用するサイズを記載します。
 たとえば「<XY_IMAGE/A=1/R=2/G=3/B=4>」と指定すると、アルファ値としてXY配列「1」、R、G、B値としてXY配列「2,3,4」に入っている値でピクチャを表示してくれるのです!

↓右上に出てるのがXY配列ピクチャで作ったミニマップ!


 つまりマップの通行設定を格納して即席で「ミニマップ」を作ったり、なんらかの「グラフ」を出したり、「複数の画像」を読み込んで1枚に重ねたりと色んな使い方ができます!
 特にミニマップがゲーム内処理だけで作れるようになるのは大きいのではないでしょうか!(従来から、アイコンなどを活用して作ることはできてましたけれどね!)

 なお、XY配列からピクチャ化する「表示」の瞬間の負荷は大きめになってしまっているので、そこはご了承ください。
 毎フレームやるにはちょっと向かないかもしれないので、【主人公付近だけ表示するミニマップ】を作るにも、たとえばいったん全マップ分を作っておいて「マスク」で主人公の近くの分だけを見せるようにするとか、そういった工夫が必要になる可能性もあります。



●キー入力に「押し続けフレーム数」の取得も追加!


 前回、「キー入力」に「新押し時のみ」「離した時のみ」の取得モードを追加しましたが、コメントを見てあと1つ足りないと思ったので「押し続けフレーム数」の取得モードも追加しました!
 これで「新押し時」と合わせれば、「↑キーを押しっぱなしにしてたら一定時間ごとにリピートされる」、「ショットキーを押し続けていると一定間隔で自動連射」みたいなのが簡単に作れるようになります!
 情報としてはシンプルですが色んな処理を書かずに済むようになるので、ちょっと楽になるはずです! これまで上手に処理を組めなかった人にもお役に立てるでしょう!

(なお、この「新押し時のみ」~「押し続けフレーム」の取得モードは、「キーボード・パッドボタン(スティックやPOVキー除く)・マウスクリック」のみに使えますので、その点はご了承ください)



●エディターからのテストプレイ開始が快適に!

 エディターからのテストプレイ、これまでは『すでにGame.exeがテストで立ち上がってる状態』でテストプレイを開始すると「(ゲームの)重複起動です」みたいなエラーが出るだけでなんだか面倒臭い感じになっていました!

 が! 今回からはすでにテストプレイからのGame.exeが立ち上がっていれば次にテストプレイを押したとき、自動でそのゲームのウィンドウが最前面に来ます! 地味だけどとても便利!



 ちなみにこの機能、どうしてこれまで簡単に作れなかったかというと、Editor.exeとGame.exeの通信機能を用意しないとダメだったからですね!
 というのも、最近のWindowsはよそのEXEのウィンドウをいじったりする処理が極めて強く制限されており、Editorから立ち上げたと分かっているGame.exeのウィンドウすら、Editorから直接最前面にすることができなかったのです。
 なので最前面にするだけといっても、内部的にEditorからGameに対して「最前面に出して~」と通信を行い、「Game.exe側でそれを受信したら自主的に最前面表示になる」という回りくどい手順が必要だったのです。
 
 今後はゲーム画面を開きたかったら、とにかくF9やCtrl+Tやテストプレイボタンを押せばいいだけになるので手軽です!
 もう毎回数秒かけてマウスカーソルでタスクバーからゲームのウィンドウを開きなおす必要もなくなるので、効率がほんのちょっとアップするはずです!




 という感じで、ウディタ3.5での快適性アップや、やれることの幅の拡張が進んでおります!

 残る新機能予定は『BGSの多チャンネル化』など! BGSは割と全体に処理が食い込んでるので、すごい修正量となってしまいますが、ウディタの長年の弱点だったのでこの機会に補強したいと考えています!
 根本からの修正は今みたいな大規模修正のチャンスじゃないとなかなか着手できない部分なので、これを逃したら普通に次のチャンスは 3年後 などになってしまうと思います。せっかくなので、この機会に強化しちゃいましょう!
 もちろんここまで作った機能にも大量のバグが出ておりまして「ギョワアア!」って叫びながら直しております!


 そして引き続き、チップやBOOTHなどからご支援くださっている方、本当にありがとうございます! リソース的にはもう限界をややオーバーしちゃってましたが、おかげさまでもう一踏ん張りがんばれております! 本当に助かります!
 
 ウディタ3.5のリリースは運がよければ今年中、やっぱりダメそうなら来年始め頃になると思いますが、気長にお待ちいただけますと幸いです。当面の最終大規模更新と思って全力を尽くします!


 そしてまた、12月24日にはうちのサイト、シルバーセカンドが26周年! もし生放送ができそうなら今年を振り返る生放送をやろうと思いますので、そちらもうっすらお楽しみに!(体調の都合でナシになる可能性は常にあります)

 ということで年末に向けてのラストスパート、引き続きがんばります! うおお!!
 2024-12-14 (土) web拍手 by FC2 カテゴリ: ウディタ




2024-11-30 (土)   ウディタ3.5開発中その6 キー入力・XY配列・Git間接対応
 ということでウディタ3.5開発の経過報告、その6です!
 今回で最終回かと思いましたが、データのテキスト入出力機能を実装してたら想定以上に時間がかかっちゃったのでまだまだ続きそうです。


●念願の「XY配列」(二次元配列)機能を搭載!

 一部の人には念願だった二次元配列機能が搭載されます! その名も『XY配列』!
 数値データのみが入る、最大『10000×10000』の二次元配列を無限に作ることができる機能で、1つずつの読み書きだけでなくCSVからの入出力やソートなども可能です!



 使い勝手としては、「数値だけを入れられるDB(ただし項目数は100から10000まで拡張可)が無限に作れる」みたいな感触となっております。
 
 XY配列の入力画面は以下の通り! ……といっても、この「XY配列」機能はインターフェースとしては従来のDBと並んでいる扱いなので、そのまんま「DB操作」画面です。


【特徴】

●「配列番号/名前」には好きな「番号」または「文字列(名前)」を指定できます。
 「X列」と「Y列」には「数値(変数)」だけ指定可能です。

 → この「配列」は、あらかじめ用意する必要はありません。なかった場合、数値を格納した時点で勝手に作られます。

●「X列」と「Y列」は、使った番号まで自動で配列が拡張されます。
 サイズの限界は最大でX、Y共に「10000」までです。

●「新データ挿入・抜き取り・コピー・ソート・CSV入出力」機能も使用可能です。

●XY配列の内容はもちろんセーブデータにも保存されます。



【どういう場面で使える?】

●自作システムを作ってる最中に出てくる、「DBを作るほどでもないけど大量の数値を扱いたい!」という場面で非常に有用です!
 たとえば「素早さが高い順に行動順の並び変えをしたい!」みたいな処理をするときも、今後はいちいち可変DBに計算用のDBを作る必要はなく、XY配列だけで完結できてしまいます!

●単純に自作システム内で、コモンセルフの足りない分を補うのにも有用です!
(使えるのは「数値」だけですのでそこはご注意を)

●コモンイベント配布においても、処理がほぼ数値データだけで済む場合は、わざわざ可変DBの新たなタイプを作らなくてもXY配列だけで用が済むようになります! コモン導入がシンプルに!
 → その場合、使用されるXY配列の名前は「(作者名)_(コモン名)_1」みたいにしておいてくださると他のコモン作者さまとバッティングしなくなるので安心ですね。

●他には『マップに関わるなんらかの処理で使う』というのがすぐ思いつきます!
 「マップと同じサイズのXY配列」を作って、何かの値を格納したり読んだりする、ということが従来よりも圧倒的に簡単にできるでしょう。

●「名前で一部の変数を管理したい」という需要にも応えられます!
 たとえば1x1の配列を使用し、配列名に「[物語用]ウルフがトイレに行ったフラグ」などと入れれば名前でのフラグ管理も可能になります。

●今後、2次元配列を入出力とする「何か」を私が作る場合でも気軽に色々できます!
 今回の更新では、【4つのXY配列「アルファ値・赤・緑・青」を指定すれば、その配列のアルファ、RGB値で画像を出力できる隠しコード】みたいな機能も検討中です。ウディタをちょっとしたペイントツールにすることもできますよ!


 といった感じで、地味ですが利便性が上がり、夢も広がります!
 



●データのテキスト入出力機能!

 データのテキスト入出力機能! これは入れるか迷ったのですが、今回入れなかったらたぶんあと3年くらい搭載されなくなりそうだったので10日くらいかけて思い切って実装していました。10日で実装できたのなら割のいい投資です。

 これは、ゲーム設定、各データベース、コモンイベント、タイル設定、マップファイルを「TXTファイル」でも出力、ないし読み込み可能にする機能です。
 これができると何が嬉しいって、Gitで差分管理やバージョン管理がしやすくなるんですよ!
 というのも、これまではウディタの各種ファイルは、.datや.mpsのような、人間が読めない「バイナリファイル」で保存されていたため、Gitで差分を取ったりするのが難しかったのです。ですがこれが「テキストファイル」なら、しっかり管理してくれます。

↓マップファイルのテキスト版、最初の方にマップチップ情報、(見えない)後ろにイベントデータが書き込まれています



【Gitを使うと何ができる?】
●定期的にコミットすることで、コミット単位で書き換えた場所だけを後から確認できる
 致命的なバグが起きてしまったけれど原因が分からないとき、「いじった部分」だけを追跡すればどこが悪かったのかを見つけ出しやすくなります。

●前にコミットした時点の内容に巻き戻せる! バグが起きて困ったときに、データを巻き戻したりできます。

●他の人のテキストファイルと、修正部分を「マージ(合体)」させることができる。うまく作業の仕組み作りができれば、遠隔での共同作業もいくらか可能になるかも!

→ といったGit利用におけるこれらの強みを、ウディタでも一手間かかるものの享受できるようになります!
 ただ最初はGitの扱いがだいぶ難しいと思いますので、あくまでできる人向けです(私は分からないなりに色々操作した結果、過去のバックアップデータを全部吹っ飛ばしたことがあります)



【TXT入出力にはどんなモードがある?】
 このデータのTXT入出力機能には以下のモードがあります!

●「エディターオプション」から、ファイルのセーブ時に自動でTXTファイルも保存されるよう切り替えできる。
→ 一番シンプルなモード。ゲーム設定やコモン、DB、マップなどを保存した際に自動でTXTも出力されます。ただ環境によっては少し保存処理が重くなるかもしれません。

●「エディターオプション」から、指定したフォルダに「TXTファイルをまとめて出力」、ないし「TXTファイルからまとめて読込」できる。
→ Gitのバージョン管理では全ファイルをまとめて戻すことが多いので、エディター内からも「まとめてTXT読込」でデータを復元できる機能を用意しておきました。その逆の「まとめてTXT出力」機能はたまに出力したい人向け。

●コマンドラインでまとめて出力・読み込みできる。
 Editor.exe -txtoutput -target ALL -txt_folder Data_AutoTXT
 みたいにコマンドプロンプトで入れると、「ALL」対象である「基本データ(ゲーム設定・DB・コモン・タイル設定・マップ)」と「全マップ」が「Data_AutoTXT」フォルダ以下にフォルダ構造を再現してTXT出力されたりします。逆に、そこから読み込んで各ファイルを復元する「-txtinput」モードもあります。
→ batファイルなどを使える人なら、「Gitにコミットする直前だけまとめてTXT出力する」みたいな工夫もできるはずです。
→ 「-target」オプションは 「ALL(全部)」の他に「BASIC(基本データのみ)」と「MAP(全マップ)」があります。




●キー入力強化! 「新押し」と「離した時」の取得が可能に!



 もう上の画像を見てくださるだけでピンと来る方も多いかもしれません!
 3.5ではいつも通りの「押されている状態」を得るだけでなく、「新たに押された瞬間」「離した瞬間」の1フレームだけ値を返す、という取得方法が追加されます!
 
 いちおう自作コモンイベントでもこの処理自体は作れるのですが、従来は毎フレーム「そのキーが押されているか」を記録し続けなければ「このフレーム中に新たに押されたか」「離されたか」を知ることは難しく、意外に手間な部分でした。なんならうまくまだ作れない人もいらっしゃるでしょう。
 そこがワンコマンドで作れるようになったので、以後はだいぶ気楽に使うことができます!


【「新押し」機能はタイピングゲームに強そう!】
 従来の「押されている状態」を使い、「キーボード全キー(を取得)」と合わせてタイピングゲームを作っておられた方もいらっしゃるかもしれませんが、実はこれだと同時押しされている際、「同時押しされている中で最も小さいキーコードの値だけが返される」という問題がありました。つまりAキー(130)から指が離れてない状態でSキー(131)を押しても、判定上は「A(130)」のキー値しか返されないという状況になってしまうのです。

 ですが! 3.5からは「新押し時のみ取得」で「全キー」を取得するようにすれば、最初に押されたキーは1フレームで返し終わってしまい、別キーが受理可能になるので、「新押し時のみ取得」を使えば前のキーを押したまま別のキーを押してもちゃんと新しい方のキーが返される」ようになるのです! これはタイピングゲームがすごい作りやすくなりますよ!
(といっても、0.016秒内に2キーを同時押しされるとやっぱり小さいキーコード1つしか認識されないという問題はあるので、そこまで気にされる方は従来通り1キーずつ全チェックされるしかないんですけれども)

 「1フレーム差あれば全キー受理される」くらいの精度のゲームであれば作るのが相当楽になるはずですので、タイピングゲーム作りに挑戦される方もこの機会にぜひご利用ください!


 もちろんアクションゲームやRPGでもキー反応をより正確にすることができるはずですので、どんなゲームにおいても、ぜひこの「新押し時のみ」「離され時のみ」判定は役立つと思います! 私もいっぱい使う場面がありそうです。



 といった感じで、今回も「作り方」から変わってしまうような重要な新機能がいろいろ実装できました!
 
 この調子だと公開時期がほぼクリスマスになったりするかもしれませんが、どうか気長にお待ちください! まだ故人の都合で、リアルの用事もいろいろ発生してしまっているものでして。


 また、BOOTHなどでご支援くださっている方、本当にありがとうございます!
 いよいよウディタプロ版の売上げも停滞しつつあり、ウディタプロ版や関連するBOOTH売上に対する作業時給がこの3ヶ月間ずっと200円前後になっているので、もうこれが最後の大規模更新のチャンスだと思って色んなものを体中から出しながらも色々追加しておりました!
 が、みなさんのご支援のおかげでもう一踏ん張りがんばれております! 本当に助かります!

 引き続きラストスパート、がんばっていきます!
 2024-11-30 (土) web拍手 by FC2 カテゴリ: ウディタ




2024-11-16 (土)   ウディタ3.5開発中その5 自動移動・サウンドのパン機能など
 ということでウディタ3.5開発の経過報告、その5です!
 「これまで欲しかったけど入れられなかった新機能」をまだまだいっぱい追加中!
 今回もご紹介していきます!


●動作指定に「自動移動」機能を搭載!

 以前、隠しコードで「経路探索機能」を実装しましたよ~とお伝えしましたが、次はもっと使いやすいよう、「動作指定」に落とし込んでみました!
 それがこの「自動移動」コマンドです!
 紹介映像を作りましたのでよければまずそちらをご覧ください!

 ※映像は開発中のものです


 この「自動機能」、行き先を指定すれば勝手にそこまで経路を判断して歩いて行ってくれます!
 モードとしては[単純][スマート][大負荷]の3種が用意されています。それぞれ以下の違いがあります。


 
- 自動移動[単純]:最初に「マップ通行設定のみ(Evはないものとする)」で移動ルートを計算し、以後はルート通り進みます。進路上に他のイベントや主人公がいた場合は止まります。
 → プレイヤーやイベントが道を塞いで止まってしまっても問題ない状況向け。
 
- 自動移動[スマート]:最初に大局的な進行ルートを「マップ通行設定」のみで取得し、基本はそれに沿って移動しますが、他イベントや主人公が経路を塞いでいた場合は少し迂回して移動します。
 → それなりに賢く移動させたい場合はこれがおすすめです。負荷もほどほど。
  ただし「イベントでゴールまでの通路が塞がれている」場合は途中で止まってしまいます。
 
- 自動移動[大負荷]:大局的な進行ルートも「マップとイベント両方込み」の当たり判定で取得し、数歩ごとに何度もおおまかなルートを再取得し直します。負荷が高いです。
 → イベントが完全に道を塞いでいて、非常に遠回りせねばならない状況でも経路探索に成功する可能性があります。
  ただし「ランダム移動するキャラがたまたま経路を塞いでいる」場合もそれに敏感に反応して大局的な進行ルートを変えてしまったり、「道がない」と判断して一時的に止まってしまったりする場合があります。

- 「自動移動一歩のみ」オプション: 自動移動のゴール地点まで行かず、1歩移動した時点で処理を終了するオプションです。ゴール地点が頻繁に変化する状況で有用です(たとえばこれナシで「自動移動」すると、追いかけっこのときも「3秒前の主人公の位置」を追い続けてしまい、そこに一回着くまで自動移動経路が変わらない問題が起きます! そういうときに「一歩のみ」オプションをオンにして「動作を繰り返す」ようにしておけば、1歩で終了→最新の場所を経路探索して1歩移動→……と繰り返すので常に最新の位置を追い続けてくれます。ただし負荷は高くなります)


 という感じ! 基本は、キャラを避けて移動させたいなら「スマート」、そうでないなら「単純」モード、ゴール地点が移動する場合は「自動移動一歩のみ」をオンにする、で問題ないと思います!

【これからの動作指定】
 動作指定でこれまで↑↑→→↓↓←↑←↑みたいに1歩ずつ指定していたのが、今後は行き先までの経路を「自動移動」ワンボタンで設定できるため、動作指定の作業はかなり簡略化されると思います! 後述の「マップ表示」機能と合わせればさらにサクサク入力可能なはず!

 もちろん機能面での広がりも大きく、「スマート」自動移動で「たくさんイベントが歩く中をうまくよけて通らせる」ことがワンボタンでできるようになったのは非常に大きな点です。
 想像してみてください。酒場のウェイターやウェイトレスさんが、歩いている人を避けながらテーブルに食事を配膳しにいったり食器を回収しにいくような指定だってものすごく簡単にできるようになるんですよ!
 
 なんなら「自動生成されたマップ」や、「自分で1マスずつ壁を配置して作った村」内ですら、簡単に道を判断して移動させられるようになるというのはものすごく大きなメリットのはず! 仕事場に行って働いて、夜になったら自分の家のベッドに帰るなんて処理も簡単!
 作れるゲームの幅も一気に広がるはずです!



●動作指定中の「マップ表示」機能も!

 そして引き続き「動作指定」画面の話なのですが、ウディタ3.5からは動作指定を設定中に並行動作するマップ画面を表示させることが可能になります! むしろどうして今までなかったんだ感がありますが、実装はすごく面倒臭かったです!

 ↓並行して表示できる「マップ画面」搭載!


 このマップ画面は、「クリックした地点の座標」や、「そこにあるイベント名」を確認できるだけでなく、【ダブルクリックすると動作指定画面の「座標指定」欄にその座標がセット】されます!

 なので今回の「自動移動」コマンドと合わせれば、

 マップをダブルクリック(座標が格納される) →
 「自動移動」をぽちっ →
 次の移動先をダブルクリック →
 「自動移動」をぽちっ


 という手順を繰り返すだけで、あっという間に経路指定ができるのです!
 もうこれまでのように座標をメモしながら↑↑→→とか一歩接近とか入力しまくらなくてもいいんです! 
 
 これによって動作指定周りの入力効率が冗談抜きで10倍くらいになると思いますので、キャラを動かすのもこれまで以上に気軽にできると思います。



●サウンドのパン機能!

 お待たせしました! 「サウンド」コマンドについに『パン』機能が搭載されます!
 その前に「パン」って何?って思われる方も多いと思いますが、これは「音の左右バランスを調整する機能」のこと! 右から鳴らすとか、ちょっと左から鳴らす、みたいなことができるわけですね!
 
 以下はパンの見本映像! ヘッドフォン推奨です(画質が低すぎるとモノラル音声になってパンが体験できないので、その場合は画質を「360p」以上に上げてみてください)


 上の映像にあるように、「BGM・BGS」の再生においては、同じファイル名を指定して違うパンの値をセットすることで、「再生を止めずに」パンだけ変更が可能です!
 効果音は「再生開始時にしかパンをセットできません」のでその点はご注意を!
 もし右から左にぴゅ~んと流れる音を流したい場合は「BGS」などをご利用ください。
 
 このサウンドのパン機能、音の位置にこだわる場合は、たぶんどんなゲームにでも使えます。
 「右から戦闘の音が聞こえる!」といった情報はアクションゲームでも有用ですし、ホラーゲームで部屋の前を通り過ぎていく何者かの足音を表現したりするのも面白そうですね。
 パンは「-255(左)~0(中央)~255(右)」の範囲で設定可能で、いつものように「変数」でも指定できます。



●DBやコモンからのデータベース参照が「タイプ名」でも可能に!

 このタイトルを見てすぐ意味が分かる人は相当のウディタリアンです!
 データベースの「データ名」や「データ内容の特殊設定」、コモンイベントの「入力設定」などにおいて、データベースから「データ名」を読み取って番号と一緒に並記する機能があります。それを「データベース参照」と言うのですが、これまではDBのタイプには「番号」しか指定できませんでした。
 が! Ver3.5からは「タイプ名」の【名前】でも指定が可能となります! 以下の画像のように!



 「タイプ呼び出しなんて【名前】で呼んでも【番号】で呼んでも同じじゃん」と思われる方もいらっしゃるかもしれませんが、使い込んでいくと全然そうじゃないんですよ! 開発が長期に渡ると「DBのタイプの場所(番号)を入れ変えたい~!」ってなることが意外にあって、そんなとき番号でタイプ指定してるとヘタに場所(タイプ番号)が変えられなくて困るんですよ!
 一方、そこを「名前」で指定しておけば、DBタイプの番号が変わってもそのまま読み込まれるので安心! というわけです!(まあ番号は変えられても、今度はDBタイプ「名」の方が簡単には変えられなくなるんですけども。でも名前は普通変えないですからね)

 ということで、これからはデータベースも整理しやすくなるでしょう!
 私もいま開発中のゲームで「DB並べ替えたいなあ、でも面倒臭くなるしなあ」と50回くらい思ったので、この機能を使ってきれいに並べ替えたいと思います。


●オートタイルアニメ速度変更!

 ウディタのオートタイルは、画像を横に長くしてアニメパターンを作っておくと自動でアニメーションさせることができるのですが、これまでは「毎秒3コマ(20フレームに1回)」のスピードでしかアニメーションさせられませんでした。
 ですが今回、オートタイルにフレーム数を指定する手段が搭載されます!

 たとえば「Water_Auto.png」というオートタイルがあったとき、「Water_Auto_FRAME=5.png」という感じに「_FRAME=??」と入れると、1コマのアニメーション時間をそのフレーム数に変更できるのです!(※1フレーム=1/60秒)

↓滝のアニメーション速度を変えた見本
https://twitter.com/WO_LF/status/1853416989018214459

 これまでも強引にピクチャでオートタイルを再現してアニメーション速度を変えることもできなくはありませんでしたが、今回からはもっとマシな方法で速度を変更できます! よければぜひご利用ください!



 という感じで、今回も新機能盛りだくさん!
 次がたぶん最終のご紹介になると思います! つまり公開もおそらく間近という雰囲気になってきますので、ご期待ください!

 とはいえ、今回いじった分がかなり多くて致命的なバグもまだ結構ポコポコ出ているため、いつ出せるかははっきりと明言しにくい状況です。「11月末か12月頭くらいに出せたらいいなあ!」くらいで見込んでおりますが、あまり信用しすぎずにお待ちください。
 2024-11-16 (土) web拍手 by FC2 カテゴリ: ウディタ




2024-11-02 (土)   ウディタ3.5開発中その4 ピクチャリンク・DBソートなど
 ということでたぶんその4くらいになったウディタ3.5開発の経過報告です!
 引き続き「これまで欲しかったけど入れられなかった新機能」をいろいろ追加中!
 今回もご紹介していきます!


●キャラへのピクチャリンク機能

 今回の目玉! マップイベントやプレイヤーなどのキャラクターに『ピクチャをリンク』させることが可能になります!

 ピクチャをキャラにピクチャリンクさせるとどうなるかというと、『ピクチャをキャラクターに永久に追従させられる』ようになるのです!
 これは「マップイベント」を使う自作システムを作り込む人にはうれしい機能!
 もう並列イベントでゲージのピクチャをキャラ位置に動かし続けなくてもいい時代になります!

 より厳密には、ピクチャリンクすると「キャラの(マップズームも加味した)画面上のX・Y座標をリンクしたピクチャに『加算』し、マップズームに応じた『拡大率変化』をかける」という処理が行われます。一言でいうと、キャラクターにピクチャがくっついたような動きをするわけです。

 紹介映像も作ってみましたので、よければぜひご覧ください!



 で、ピクチャリンク機能は「エフェクト」コマンドの「キャラ」欄から使用可能でして、設定可能な内容は以下の通りとなっています。「マップズーム(の拡大率)への連動」は外すことも可能です。

ピクチャID
 キャラにリンクしたいピクチャ番号を設定します。

リンクさせるレイヤー
 - キャラの表に:キャラのすぐ表側にピクチャが表示されます(キャラ本体と同じく、リンクさせたピクチャが他キャラや▲チップで隠れます)。
 - キャラの裏に:キャラのすぐ裏側にピクチャが表示されます。
 - 影レイヤーに:「全てのキャラの足下」のレイヤー、かつ「地面のY座標(キャラの「高さ」を変更しても変化しません)」にピクチャが表示されます。(ピクチャレイヤーのマップの上、キャラの下とほぼ同じ)
 - ピクチャのまま:ピクチャのレイヤーのまま、キャラの座標や拡大率のみ反映し続けます。

連動させるパラメータ
 - XY拡大連動:(マップズームを考慮した)画面X・Y座標をピクチャに「加算」し、マップズームによる拡大率の変化をピクチャにも反映させます。
 - XYのみ連動:(マップズームを考慮した)画面X・Y座標をピクチャに「加算」します。マップズームの拡大率はピクチャに反映されません。



【どんなことに使える?】
 ピクチャリンク機能の用途ですぐ思いつくのは、頭の上に状態異常マークや感情マークを出したまま歩かせたり、HPゲージを出したりすること!
 「キャラにピクチャをリンク」と1行指定するだけで、ゲージのピクチャがずっとそのキャラについていってくれます!

 なおゲージを頭に出したいときは、ピクチャの座標は「中央下」基準で(0,-30)[※上に30ピクセルだけずらす]のように指定します。これにキャラの足下中央の座標が足されるので、自然に頭の上に表示されるのです。
 他にも、ただ「キャラの名前」を頭の上に出しておきたいだけでも、従来ほどの苦労は不要になります! ピクチャを0,0座標とか0,-30座標あたりに出して、ピクチャリンクのコマンド1発おこなうだけで実現可能!


【これまでアクセスできなかったキャラ間の描画優先度にも挟み込める!】
 さらにはこれまで不可能だった、『ピクチャの表示優先度をそのキャラと同じ』にすることも、このピクチャリンクを使えば可能になります!
 これまでピクチャは、「キャラレイヤー全体や、マップ下地レイヤー全体の上か下」にあったので「自分の前にいるキャラで隠れるピクチャ」というのは作れなかったのですが、今回からはそれも可能!
 ピクチャでオーラを出したキャラが「木の裏」に行けば、オーラの一部も「木の裏」に隠れるようにできるのです!(従来のピクチャだと、「キャラだけは木に隠れてるけどオーラだけどうやっても木の前側にでちゃう」という感じになってしまっていました)

 他にも、透明キャラにピクチャをリンクさせれば、「キャラの前後関係やイベント判定処理はそのまま使いつつ、キャラ描画だけを全部ピクチャで行う」こともできるようになります。
 補正したピクチャをキャラに重ねて、HD-2Dっぽいエフェクトをかけたりするのもたぶんだいぶ簡単に!
 「影レイヤー」へのリンクも用意してあるので、影をピクチャで描画するようにだってだいぶ簡単にできるでしょう(これ自体は工夫すれば前もできたんですけれども)。

 さらには「メッセージを頭の上に表示させたまま歩かせる」なんてことも非常に簡単に作れるようになります! これまでのように、並列イベントでずっとピクチャ座標をキャラに追随させる必要がなくなるので、かなりすっきりと処理を作れるはずです。

 私の開発中の『片道勇者2』でも多くのキャラの上下にゲージなどの情報を出すことをしているので、これが使えたらもっと簡単に実装が進んでいたと思いますが後の祭りです。




●可変DBのソート(並び変え)機能

 ついに来ました、可変DBを特定の項目の値にしたがってソートする機能!
 ゲーム中のデータの並び変え処理を作らなければならなくなった人なら誰でも欲しかったはず!

 これは特定の「項目」の値の大小にしたがって可変DBの「データ」を並び変える機能です。
 「昇順(小→大)か降順(大→小)」か、「どのデータ範囲を並び変えるか」「並び変えにはどの『項目』の値を見るか」を指定してソートできます。文字列ソートもいちおう可能ですが、C++のstring型の文字の大小関係をそのまま使ってるだけなので、詳しい話は言えません。たぶんUTF-8のコード順になると思います。


 それでこのソート機能、それこそ「すばやさ順」で1ターン中の戦闘の行動順を計算する、といったことに始まり、「アイテムの性能別ソート」や、あるいは項目に「乱数」を入れてから並び変えることで「シャッフル」させることだって可能!
 いちいちこういうソート処理を苦労して作らなくてもよくなるので、これからはその労力を他に回せます!

 どこまでできるかの紹介は下の動画で説明しておりますので、よければぜひご覧ください(でも動画内で素早さを「小さい順」にソートしてるのはちょっと変ですね! 素早さで行動順を算出するなら「大きい方」から並べないと!)





●Editorで右クリックから特殊文字入力

 ウディタには、数値欄に1600000(コモンセルフ0)のように100万以上の変数呼び出し値を入れることで、数値そのものでなく「変数の値」を指定できる機能があります。
 主な入力箇所では変数用のプルダウンメニューが使えるので別に使わなくてもいいんですが、けっこうなところでこの入力方式を要求する場所がありました。



 そこで! Ver3.5からは上の画像のように、数値欄の右クリックメニューに各種特殊文字を入力できる機能が搭載されます!
 「数値欄」には変数呼び出し値を右クリックメニューから見本入力できるほか、「文字列欄」には¥v[?]や¥f[?]のような「特殊文字」も指定可能!
 今後はいちいちマニュアルなどを見なくてもよくなります!



●総合的なパフォーマンス向上

 ウディタ3.5では細かなところでパフォーマンスが向上します!


●【起動時間/調整】Editorの起動時間が短縮されました。
→ 【参考】 サンプルゲーム入りEditorの起動時間が作者環境で 約19秒→約11秒(約40%カット) に短縮されました。

→ 代わりに各イベントコマンド入力欄の「初回表示」時のみ0.数秒~1秒程度の待ち時間がかかるようになります。2回目以降の切り替えは高速です。
(最初に全てロードせず、初めてクリックされたときにコマンド入力欄をロードするようにしたためです)


●【文字列操作/調整】「上1行切り出し」の処理速度が向上しました。
→ 16KBで320行のファイルを30回、1行切り出しで最後まで読み込ませたテストでは処理時間が620ms→約360msになりました。
 処理速度にして約70%アップ!
→ テキストスクリプト機能を自作しておられる方が一番使う機能だと思いますのでそこそこ貢献できると思います。私もかなり使ってます。


●【コモンイベント・データベース/調整】
 コモンイベントやデータベースファイルに圧縮をかけるよう修正
→ サンプルゲームのファイルが以下のように削減されます!
 CommonEvent.dat 1232KB => 352KB (約71%削減!)
 DataBase.dat 88KB => 18KB (約80%削減!)
 CDataBase.dat 81KB => 7KB  (約91%削減!)
 SDataBase.dat 2,787バイト => 693バイト (約75%削減!)


 といった具合に、可能な範囲で細かなところの性能アップも行っております!
 あと、計測できなかったので載せていませんが、イベントコマンド切り替え時のレスポンスも全体的に上がってると思います。



●「変数操作+」の大幅強化

 3.5では「変数操作+」で新たな情報が取得可能になります!

●【キャラ】コマンドに追加
- 画面X座標[マップズーム反映]
- 画面Y座標[マップズーム反映]
 → 通常の画面X・Y座標と違い、「マップズームの拡大率」の影響を加味した現在の画面上の座標を返します。
 
- すりぬけ属性[1=YES 0=NO]
 
 
●【位置】コマンドに追加
- キャラ通行可能方向[1上+2左+4右+8下]
- タイルのカウンター属性[1=YES 0=NO]
 
 
●【位置】コマンドに【画面座標】オプション追加 (「画面座標」は新規追加)
 「画面座標(ピクセル単位)」を指定し、その位置の情報を得ることができます。
 
- px座標のイベントID[マップズーム加味]
 → 指定座標下にイベントがあるか判定できます。
  座標として「マウス座標(Sys71~72:マウスXY座標)」を指定すればマウス下のイベントを返せます。マップズームも考慮します。
   
- px座標のイベントID+範囲拡張[マップズーム加味]
 → 接触範囲拡張部分も含めたイベントIDを取得できます。
 
- px座標のマップX[マップズーム加味]
- px座標のマップY[マップズーム加味]
- px座標の精密マップX[マップズーム加味]
- px座標の精密マップY[マップズーム加味]
- px座標の最上ピクチャID[Z加味/なし:-20億]
- px座標の最上ピクチャID[Z無視/なし:-20億]
- ピクセルのR値
- ピクセルのG値
- ピクセルのB値
 → ピクセルのRGB値は、指定画面座標の1ピクセルのRGB値を0~255で返します。
 
 
●【ピクチャ】コマンドに追加
- ピクチャの横分割数
- ピクチャの縦分割数
- カラーR・G・B値
- 表示形式[0:通常 1:加算 2:減算 3:乗算]
- スクロールとリンク[ON=1]
- 設定された処理時間フレーム
- 現在の残り処理時間フレーム
- 最小の発動ディレイ(1以上のみ,なければ-1)
- 最大の発動ディレイ(なければ-1)
- IDより前にあるピクチャ番号[なし:同値]
- IDの次にあるピクチャ番号[なし:同値]
 
 
●【その他】コマンドに追加
- 今フレームに決定/接触起動したマップEvID(なし:-1)
 → これを使えば新たに生成した空イベントの起動も検知できます。ただし起動した瞬間の1フレームしかイベント値を返さないので注意してください。
 
- マウスが画面内にあるか?(YES=1)
 
- マウス座標の範囲拡張EvID(小さいID優先,なければ-1)
 → 「接触範囲拡張」も考慮した範囲で、マウス座標下のイベントIDを得られます。



 といった具合!

 新しい内容としては「指定IDより前後の、実際にあるピクチャ番号」が分かるようになったことや、「指定ピクセル位置のRGB値が取得できる」ことでしょうか。「画面上の指定ピクセルのRGB値を得られれば、それを大きな四角に広げてモザイク処理が作れるね」とおっしゃっている方もいらっしゃいました。

 あと他にも、「画面上のXYピクセル位置上の情報」を取れるようになったのも便利ポイント! 
 たとえば「マップズームを加味した指定ピクセル座標のマップXYマスの値」が一発で取れるようになったので、『マップズームが自由なゲーム』でのタイルやオブジェクト、範囲座標をカーソル選択する場合も、作るのがけっこう楽になると思います。

 他にも、「マップズームを加味したキャラの画面X・Y座標」や「イベントの接触範囲拡張を考慮したマウス下判定」を取得しやすくなったのは朗報だと思います!
 特に、「キャラをマウスで拾って移動させたりする」といった処理をする場合でも「接触範囲拡張」を広げてキャラのクリック範囲を広げてあげたりしやすくなるので、よければぜひご利用ください。
 これらはがんばれば計算できないこともなかったのですが、私もいちいちその補正を反映する処理を作るのが面倒臭かったですからね!




●文字列操作の裏技に「画像の1点の不透明度+RGB値を得る」機能が追加!

 文字列操作の「隠しコード実行」コマンドとして、画像のX、Y座標の不透明度、RGB値を得る <<GET_IMAGE_ARGB_X=?/Y=?>>(ファイル名)コマンドが搭載されます!

 これは (ファイル名)で指定した画像の、X=?、Y=?座標のピクセルの不透明度、RGB値を「不透明度(改行)R値(改行)G値(改行)B値」という文字列で得られるという機能!
不透明度やRGB値はそれぞれ0~255の値を取ります。
「不透明度が取得できる」という点が特に重要です!
 
 というのもこの機能で不透明度を得られるのが何に使えるかというと、
「クリック位置の『不透明度』をチェックして、画像中の立ち絵がある部分をクリックした場合だけ反応させる(透明な場所をクリックしたときは何も反応しないようにする)」
 といった処理をしたい状況や、あるいは一枚絵マップを作る際、
「32ピクセルごとに画像をチェックしておき、もし不透明なピクセルがあったらそのマスは侵入不能にする」
 といった自動判定をするのに使えます!
 他、自由な形状の「当たり判定」をあらかじめ自動認識しておくのにも使えるかもしれません。

 ただしこの機能は「画像ファイルの左上を(0,0)とした座標を指定して情報を得る」機能なので、たとえばマウス位置の画像部分が透明か知りたい場合は「マウス座標が画像のどの位置にあたるか」を計算し直する必要があります。その点はご注意ください。

 それでも画像の「不透明度」情報を得られるようになると、判定の面で色々やれることが広がります! 手作業で画像の当たり判定を作っておくという超面倒臭い作業の必要もなくなるので、もしそういうので苦労されていた方はよければぜひご利用ください。




 といった具合に、今回も自作システム内の『作り方』からして変わってしまうような新機能がいっぱい!
 まだ次回予定分もたくさんありますので、引き続きウディタ3.5の情報をお楽しみに!
 2024-11-02 (土) web拍手 by FC2 カテゴリ: ウディタ




2024-10-19 (土)   続々ウディタ3.5開発中 経路探索&キャラレイヤー強化ほか!
 引き続きウディタ3.5への改修作業を続行中です!(3.40呼びしてましたが搭載予定の新機能が多くなりすぎるので、3と4の中間大規模修正として「3.5」呼びにすることにしました)

 ここまでにご紹介した目玉新機能は「空イベントの生成機能」「フォント暗号化」など!
 今回も、「作れる内容」や「作り方」が大きく変わる目玉の新機能が続々登場です!


◆ウディタ3.5の新機能予告、続き!

【○経路探索機能!】

 まず「経路探索機能」とは、スタートとゴールの座標だけ指示したら、ゴールまでの道順を自動的に算出してくれる機能のこと!
 紹介動画を作りましたので、見られる方はまずそちらをご覧ください! 直感的に理解できると思います。



 私の環境だと、迷路みたいな道でも500マスまで先の道の経路を1msくらいで算出可能でした!(1フレーム16.6msなので、それを超えない処理時間に抑えれば処理落ちはしないことになります)

 まともにコモンイベントとして作ると10マスくらいの経路探索でも重くなることがあるので、この速度で動作する経路探索処理が基本機能として使えるのはかなり大きいと思います。



-【どういう場面で使える?】

 経路探索が簡単にできれば、以下のような処理の実現可能性がグッと上がります!

●マウスクリックした地点まで、NPCや障害物を避けてキャラを移動させることが簡単に!
 
●ガイドボタンを押すと次の目標地点までの道順がラインで表示される、みたいな演出も当然可能!
 
●生活系ゲームで、キャラがベッドから起きて仕事場に行って食堂でご飯食べてまたベッドに戻る、みたいな処理だって従来より非常に簡単に作れます!
 
●建物も自分で設置できるクラフトゲームや開拓シミュレーションゲームでも、経路を自動認識して移動させることが簡単に! 木こりして指定箇所に木材を運ぶ、みたいな処理も実現しやすく!
 
●ローグライク(不思議のダンジョン)系ゲームでも、モンスターの移動経路や最短の接近ルートが簡単に算出可能になります!
 
●タワーディフェンスゲームで「敵の侵攻ルート」を算出したり、「自分の設置物で敵のルートが変わる」「ちゃんと味方陣地までの経路が空いているかを調べる」といった処理も低コストで実現可能になります!
 
●追いかけっこ展開でも障害物を避けて移動可能です!





-【経路探索機能の使い方】

 使い方はちょっとマニアックです!
 たとえば「文字列操作」の「隠しコード実行」コマンド(Ver3.5で搭載されます)から

 <<FIND_PATH_DIR8_SX=1/SY=2/EX=6/EY=5>>

 と指定すると、マップの(1,2)座標[SX=/SY=の値]から(6,5)座標[EX=/EY=の値]までの道順を、以下のような文字列として得ることができます。

  966662222/END

 算出された移動経路は、テンキーに対応した1~9の方向を羅列した文字列で示されています。
 9なら「右上」、6なら「右」、2なら「下」なので、上の経路は【スタート地点の(1,2)座標から右上、右、右、右、右、下へ4歩すると(6,5)に着きます】という意味になります。

 方向じゃなくて1歩ずつの座標で知りたいよ! という人も安心! 隠しコードに「/POS」を追加すれば、以下のように得られる経路の文字列が「1歩ずつの座標」として返されます。

 <<FIND_PATH_DIR8_SX=1/SY=2/EX=6/EY=5/POS>>
  ↓結果
 2,1/3,1/4,1/5,1/6,1/6,2/6,3/6,4/6,5/END

 あとは「文字列操作」でいいように切り取って使ってください! という感じです!

 なお、この経路探索は今のところ「1マスごと」の処理のみ可能です。1マスまるまる通行可能でないマスの場合、「通行できる」と認識されない可能性があるので、そこは注意してください。




-【イベントの当たり判定を考慮した経路計算も可能!】

 このコマンド、素のまま使うと「マップの通行判定だけ」を考慮したルートを算出するのですが、隠しコードに「/EV=-2」(-2=主人公、ここには動かすイベントのIDを入れる)と入れると、『イベントの当たり判定を考慮した経路』を算出できます!
 <<FIND_PATH_DIR8_SX=1/SY=2/EX=6/EY=5/EV=-2>>みたいな感じですね。マップイベントを動かしたいときは、マップイベントID3なら/EV=3みたいに指定します。

 以下の投稿みたいに、多数の猫が上下してる道でも猫を避けて移動が可能です! ただしイベントのように動くものも考慮する場合、毎フレーム経路を計算しなおさないといけませんので、計算負荷は上がります。




-【経路探索にはどういうアルゴリズムを使ってるの?】

 ここは余談ですが、経路探索アルゴリズムとしては、高速に最短経路の近似解を求められる「A*(エースター)」アルゴリズム(Wikipedia、処理見本アニメあり)を使用させていただいております。
 すごく簡単に言うと、「目的地への道の中で、より近そうな道から優先して探すことで、全ての道を試すよりもずっと速く経路を見つけられる」という仕組みのアルゴリズムです。
 ただし、このアルゴリズムで得られるのはあくまで近似解なので、常に「【最も短い】経路」が算出できるとは限らないことに注意してください。2番目くらいの距離の道を最終結果として返すことも多いです。
 ですがプロのゲーム開発の現場でも使われているくらいの優秀なアルゴリズムで、だいたいは良い経路を算出してくれます。多少最適じゃない道を出しても、ゲームという媒体なら「キャラやナビがポンコツだから」などで説明できますから安心!(?)




-【いずれはもっと簡単に使えるようにしたい!】

 こんな風に隠しコードを使ったり、「文字列操作」を駆使しなければならないことから、いまのところ経路探索機能は『自作システムを組める人向け』の機能と言えます!

 が! もし(私の作業負荷とゲーム内負荷の両方の意味で)軽い負荷で作れそうなら、「動作指定」内に、目標地点まで自動で移動してくれる「自動移動」処理なども入れたいなあと考えています。
 うまくいけば、一歩ずつ歩く方向を指定する必要があった時代が終わるかもしれません! そうなればイベントシーンの作成負荷も大幅削減されますよね。

 ということで、自作システム作者さまにも普段使いの方にも夢が広がる経路探索機能の搭載、お楽しみに!




【○キャラチップレイヤー機能が強化! レイヤー無制限化+サイズ不問+1レイヤーごとにエフェクト可能に!】

 ずっと『(α版)』と書いてあった「重ねキャラチップ」機能ですが、今回の修正でたくさん進化して正式版となります!
 こちらも映像を作りましたのでよければご覧ください!




-【レイヤー5枚制限が撤廃、無制限に! レイヤー番号も好きに指定可】

 これまではキャラの「上」のみに5枚までしか置けなかったキャラチップレイヤーですが、これからはキャラの「上下」に「無制限に」重ねられるようになります!
 さらにレイヤー「-1000」みたいに好きな番号を入れても問題なく動作します!
 扱いがかなり雑でもよくなったので、キャラメイク系のゲームでもキャラチップに色んな服を着せたり武器を持たせたりできるようになるでしょう。



-【キャラ本体の裏側にも追加可能に】

 さっきもチラっと言いましたが、キャラの「裏側」にもレイヤーを追加可能です!
 あとから表にも裏にも好きに追加できるので、これまでのような少ない枚数をギリギリで運用する必要がなくなります。ザツに管理できるのは大事!



-【重ねる画像サイズが自由に!】

 これまでは「重ねるキャラチップ」は『本体とまったく同じ画像サイズ』でなければダメでしたが、最新版ではそこが自由になります!
 ちょっとくらいフォーマットが違ってても大丈夫! 
 本体よりだいぶ大きい乗り物に乗せることだって可能になります。



-【1レイヤーごとに色を変えたりXY座標をずらしたりできるように!】

 さらにレイヤー1枚ごとに色相や彩度、明るさを変えたり、XY座標をずらしたりが可能になります!
 色違いの服を用意する必要はなくなりますし、レイヤーごとに多少のずれがあった場合はこれで補正可能です! これで開発コスト削減!
 やり方は以下のように、画像ファイルの前に<>で挟んでオプションを指定するだけ!

 <X+=4/Y+=-2/HUE=90>CharaChip/Chicken.png
 この例だとX座標に+4、Y座標に-2、色相90(0~360の範囲)の補正をかけたChicken.pngのレイヤーが表示されます。

 他にも、/HALFと入れると画像サイズを半分にしたりできます! ウルファールを1/2サイズにちっちゃくして船に乗せたりも!





【○『ピクチャ挙動Ver2』が搭載!】

 これまでのピクチャ挙動は、「表示」時の挙動が状況次第で違ってややこしかったり、ピクチャを挟めるレイヤーが少なかったりして少し不便でした。
 同じIDのピクチャを使った場合、文字列ピクチャを「表示」し直すたびに不透明度ゼロから表示され直したり、文字列から画像ピクチャを出すとワープしたり、画像ピクチャから画像ピクチャを出すとワープせずに移動したりと一貫性がありません! 「消去」指示すると「移動予定先」にワープしてから消えるという変な動作もありました。

 なので、ここでいろいろ整理しようと『ピクチャ挙動Ver2』の搭載を決定しました!
 Ver1の旧挙動とVer2では、以下のような挙動の差があります。


●これまでのピクチャ挙動Ver1[旧挙動]
レイヤー挙動:ピクチャ番号マイナス時の表示レイヤーが以下のようになります。
 「-1~-99999の場合は『キャラの下 ・ マップの上』に表示」
 「-100000以下の場合は『マップの下 ・ 遠景の上』に表示」
 
【表示】コマンド時の挙動
 すでに同IDでピクチャが表示されている場合、「異なる画像で【表示】」または「文字列ピクチャの【表示】」をした場合に、
 - 処理時間が残ってる状態だと『不透明度』が「直前のピクチャ指定時点の値の状態に戻る」
 - 文字列から画像、画像から文字列、文字列から文字列に切り替わるときに「新しい場所に瞬間表示される」という挙動になります。
 - 「ファイル読込ピクチャ」で全く同じ画像を【表示】した場合のみ、【移動】と同じ処理になります。
 - 他にも、「処理時間」ありで「消去」されるときは「移動予定先に瞬間移動して消え始める」という挙動になっています。
 という具合になかなかのカオス具合になっていました。


 ↓

●ピクチャ挙動Ver2[ver3.5以降]
レイヤー挙動:ピクチャ番号マイナス時の表示レイヤーが以下のようになります。
 「-1~-99999なら『フォグの下 ・ ★マップチップの上』に表示」
 「-100000~-199999なら『★マップチップより下 ・ キャラや▲マップチップの上』に表示」
 「-200000~-299999なら『キャラや▲マップチップより下 ・ マップの上』に表示」
 「-300000~-399999なら『マップより下 ・ 遠景の上』に表示」
 「-400000以下なら『遠景の下』に表示」
 
【表示】コマンド時の挙動
 すでに同じIDでピクチャが表示されている場合、処理途中でも「座標」や「不透明度」はその瞬間のパラメータを常に引き継いで処理されます。
 - すでにピクチャ表示済みの場合、常に【移動】コマンドと同等の処理が行われます。シンプル!
 - また「処理時間」ありで「消去」される場合も、「実行された瞬間の座標」で止まって消去される自然な動作になります。





 という感じです! これまで開発されていた方はVer1のままにしておく方が安全ですが、今後の新作開発ではVer2をご利用になることをおすすめします!
 特に「★チップの下・キャラの上」あたりのレイヤーは従来ではピクチャを挟むことができなかったので、ムズムズしてた人も多いと思います。
 今後はもうちょっとピクチャも扱いやすくなると思います!




【○マップだけをピクチャに取り込む『<MAP_SCREENSHOT>』機能が搭載!】

 すでにVer3.0で、画面全体をピクチャとして取り込んで使える「<SCREENSHOT>」機能が搭載されましたが、Ver3.5ではマップ画面だけを取り込む「<MAP_SCREENSHOT>」機能が搭載されます!
 使い方はピクチャの画像ファイル名に、「<MAP_SCREENSHOT>」と入れるだけ!
 そうするとその瞬間のマップがピクチャとして表示できます!



【「全画面取り込みと変わらないんじゃ?」って? いえいえ違うんですよ!】
 このマップ取り込み機能、画面全体を取り込むのとあんまり変わらないように見えますが、重要なのは「ID0以上のピクチャを無視できる」という点!
 というのも、全画面を取り込んだピクチャを毎フレーム更新したりすると「2フレーム目から出した全画面ピクチャそのものも取り込んで表示してしまうので見た目がカオスになっていく」という問題があったのです! 絶妙に使いにくい!

 ですが今回取得可能になったのは「マップのみ」なので、これを使えば「メニューやメッセージウィンドウ」、「直前に出した全画面ピクチャ」を取り込んだりせず、きれいなマップだけが使えます! よって、さらに画面取り込みの使い勝手がよくなるわけです!


【<MAP_SCREENSHOT>で何ができる?】
 マップのみを毎フレーム「表示」し直せば、当然リアルタイムのマップがピクチャとして好きに表示可能! これでできる表現の幅も格段に広がります!
 たとえば何に使えるかというと、演出強化の面では「画面を斜めや上下逆さにしたり」「サイケな画面演出や崩れたマップ画面を演出したり(細かくパターン分割して座標をずらしたり動かしたり、個別に色変えしたり)」「【イラスト上のディスプレイ画面】にマップ画面を自由変形ではめ込みしたり、その状態のままゲームを続行させたり」なんてことも可能になります!
 他にもプレイ面での強化としては「広大な範囲の全マップを裏で出しておいて、プレイ時はそれをCUT機能で切り出してピクチャ拡大して表示し、別々の場所で起きていることを分割映像で見せる」なんてことも実現可能です。「ダンジョンに侵入者が入ってきた! 今の侵入者はこういう動きをしている!(侵入者付近のマップ画面を切り取ってピクチャ表示する)」なんていうライブカメラ的な演出もできます! 画面内に全マップをおさめるのがちょっと難しいですけども。


【ミニマップ作りにも!】
 さらにマニアックな話をすると、ウディタにおける「マップ画面」とはすなわちピクチャIDが「-1」以下のレイヤーでもあります!
 つまり『マイナスのピクチャでお絵かきした内容をで保存しておいて使う』という画像バッファみたいな使い方も可能!

 特に便利そうな用途として考えられるのがマップごとの「ミニマップ」自動生成機能です! マップに侵入した際やロードした際、裏でミニマップの画像を作って「」で撮影しておき、あとはそれを「切り出し」表示したり「マスク」を使ったりして表に表示することで、良い感じにミニマップ自動生成&表示ができそうです!

 実装できる技術さえあればアイデアは無限大! ぜひ色々考えてみてください!



 という感じで、ここまででさえ、「作り方そのもの」や「作れるゲームの幅」まで変わってしまう修正が盛りだくさん!

 私の介護もいったん終わり、長時間集中し続けてもよくて夜ずっと寝られる環境を得たことで5年ぶりくらいに全力が出せるようになってるので、プログラミング筋(きん)も絶好調です!
 さらに他の新機能にもチャレンジしていきますのでお楽しみに!


 便利度が上がるたびに「なんで自分の『片道勇者2』の開発でこれがなかったんだよォォォォー!」ってすでに何回か叫んでいますが、もっと自分が叫んじゃうような新機能も入れていきたいですね。
 引き続きがんばります! 次回の新機能紹介もこれに劣らないものが出せればと思いますので、お楽しみに!
 2024-10-19 (土) web拍手 by FC2 カテゴリ: ウディタ




2024-10-05 (土)   続、ウディタ中規模アップデート作業中!
 ということでずっとみっちりウディタの修正作業中です!
 セキュリティ周りみたいな、「表にご報告しにくい割に膨大な作業量の場所」はおおよそ済んだので、あとは楽しい新機能搭載フェイズ、というところです!

 今回はここまでに実装に成功した、ちょっと興味深いであろう新機能についてご紹介していきます!


◆Ver3.40の新機能、一部紹介!

【空のイベント作成機能(※裏技)】

 一部の人から割と待望されていた「空のイベント」を作る機能が搭載されます! うまくコマンドにおさまらなかったので文字列操作の隠し機能による裏技になってしまいましたが上級者の方しか使わないと思うので問題ないはず!
(隠し機能:「文字列操作」の「に↓のファイル内容読込」を選んで「<<」から始まる裏コードを入れると使える機能)

↓空イベント生成コマンドの開発中デモ。大量の夕一が新イベントとして生成されています。まだ開発途中なせいで初期位置が(0,0)になっており目標位置までニワトリがコンベア出荷されてるように見えますが、完成版では目標位置に「瞬間表示」で出現します


 この『空イベント生成機能』、使い方としては「文字列操作」の「に↓のファイル内容読込」に隠しコードとして

<<MAKE_EVENT_X=4/Y=2/TR=1>>
CharaChip/[Chara]Animal_Chicken.png
(※続けて1行で入力)

 みたいに指定すると、座標(4,2)に、「決定キーで起動」(TR=1)する、画像「CharaChip/[Chara]Animal_Chicken.png」の新イベントを設置することができます!
 XY座標や画像だけでなく、イベントの「起動条件」も(TR=1:決定キー、2:プレイヤー接触、3:イベント接触)から指定できます。

 「でも生成されたイベントはコマンドが空だから『起動条件』なんて関係なくない!?」と思われるかもしれませんが、今回の中規模修正でプレイヤーが起動した空イベントのIDを検出できるようにする予定なので、意味はあります!
 空イベントでも「起動さえ検知」できれば、熟練者の方なら何とでもしようがあるはず!
(たとえば「変数操作+」の中に「今フレームの決定キー/接触で起動したマップEvID」を得られるコマンドを新たに付けたりすれば実現できると見込んでいます)

 これらの機能を駆使すれば、究極的にはマップエディタで1キャラも置かなくったってイベントを配置・制御できるようになります!
 ただしイベントの最大配置数は「10000個まで」となっておりますので、そこはご注意を。

 また、「生成されたイベントID」も返り値として得られるので、そこもご安心ください(文字列変数に"12"みたいな文字列が入るので、「変数操作」を使って数値に変換してください)


【ついでに「イベント削除機能」も搭載!(ただし空イベントのみ)】
 ちなみにイベント生成機能に対して、「イベント削除機能(<<DELETE_EVENT_ID>>(イベントID) )」も作りました。ただし、こちらは実質「空イベント」しか消せません。
 コマンド実行途中のイベントが消えるとクラッシュしてしまうことが分かったので、「何もイベントコマンドを持っていない」「ページ1つだけ」かつ「自動起動でも並列起動でもない」のイベントの場合だけ削除可能となっています。



【このイベント生成・削除機能で何ができるか?】
 で、空イベントが生成できると何がいいかって、色々あるんですよ! たとえば以下のような用途が考えられます。


●『牧場物語』系みたいな「作物が無限に出てくるゲーム」や、「キャラやアイテムが置き放題なオープンワールドゲーム」を作る場合でも、あらかじめ空のイベントを大量に作っておく必要がなくなります!
 これまではその用途でマップイベントを使うために、マップに5000個(エディタの限界数)の空イベントを作られたという方もいらっしゃいますからね! これからはそういったことをしなくても、必要なときに空イベントを作れば大丈夫になるわけです。

●他にも、「どのマップに行っても100人くらい仲間がついてくる」とか、「そもそも特定マップに固定配置のキャラがいなくて、みんな常にどこかの色んなマップを歩き回っている」ようなRPGを作るときだって便利になります!

●「マップチップの一部をキャラチップで代用したい」場合にも有用です!
 マップチップの「タグ」に応じて「自動でその場所にマップイベントを配置し直したりする」なんてことも少ない作業数で実現できるようになるので、マニアックな配置をしたいときでも安心です!
(さっきのMAKE_EVENTコマンドの画像指定で4みたいに入れるとタイル画像が設定できます)


 従来でも、これらはどれも「全マップに大量の空イベントを作っておく」ことで対応可能な案件ではありましたが、そんなことまでして作りたくない場面も多かったでしょうから、今後はそういった作業が必要だった作品ももっと作りやすくなるはずです!
 すでに「夢が広がる~」とおっしゃっている方は、そういうところで挫折した経験や苦労された経験がお有りなのだと思います。今後はそこもラクになりますよ!




【ファイル個別暗号化(プロ版機能)で「フォント暗号化」ができた!】

 「ファイル個別暗号化機能(復号キーなどを設定して.wolfxファイルに変換できる)」自体は前回もご紹介しましたが、それで得られた副産物として、『フォント暗号化』が可能になりました!

 たとえば「UmePlusGothic.ttf」をファイル個別暗号化すると「UmePlusGothic.ttf.wolfx」ファイルに変換されるわけですが、これをGamePro.exeと同じ場所や、Dataフォルダ内に入れておくと、普通のttfファイルと同じく起動時に読み込みが可能です!
 それでいてttf.wolfxは暗号化されているので、直接Windowsで読み込むことはできなくなります。ファイル名も「Font1.ttf.wolx」みたいに変えれば何のフォントを使っているかも分からなくなるでしょう。

 こういう形で使えば「二次利用可能な形での再配布」ではなくなるらしいので、ある程度は使えるフォントの幅も広がると思います。もちろん、フォントごとの規約はしっかり守ってくださいね!
 ただしこの「ファイル個別暗号化」機能は『プロ版専用』なので、その点はあらかじめご了承ください。ウディコンなどでは使えないってことですね。




【エディターのウィンドウサイズの調整や、フォント切り替え(2種)ができるようになった!】

 「エディターオプション」からエディターのウィンドウサイズを調整できるようになりました!
 「マップイベントウィンドウ」や「イベントコマンド挿入ウィンドウ」が思ったより幅を取るからあと1割だけ小さくしたいんだけど……という私みたいな人や、3840ディスプレイ持ってるけどWindowsの拡大率100%だとだとウディタ画面が小さすぎるよぉぉ! という人のために搭載されます!

 といっても技術的な都合で拡大できない場所もあるのでそこはご了承ください。いつも見るであろう「マップ/コモンイベントウィンドウ」や「データベースウィンドウ」、「コマンド入力ウィンドウ」あたりは押さえてありますが、メニューアイコンや上部メニュー欄などの拡大縮小はちょっと難しそうだったのでできていません。


【エディターのフォント変更機能】
 あとフォント変更も2種から選択可能に!
 これまでは「MS UIゴシック」というカクカクフォントでしたが、これからは「Meiryo UI」というなめらかフォントも選べるようになります! また、「太字」への切り替えもできますよ。






【「マップエディタ」や「場所移動の移動先選択」で「x2」拡大モードを追加!】

 これもディスプレイの画面解像度が上がってきた時代に対応するためのもので、マップチップを1/1よりさらに大きい「x2」ズームで表示できるようになります!
 一見簡単に作れそうに見えましたが、ちょっとやりかけたらすごい作業量が必要だったので今回のチャンスを待っていた部分です。需要はそこまで高くなかったかもしれませんが、この機会に入れられて何よりです。





 という感じで、今も毎日全力でウディタ修正中です!
 いつものことですが早く終わらせないと作業の時給換算がマズいですからね! それが全力で頑張れる動機になっているのは良いことではあるんですが。

 実装に成功すれば紹介に値するであろう新機能の予定は他にもありますので、引き続きお楽しみに!
 2024-10-05 (土) web拍手 by FC2 カテゴリ: ウディタ




2024-09-20 (金)   ウディタVer3.4へ中規模修正中!+セキュリティ話
 ということで現在ウディタがVer3.3台からVer3.40に変わるので、この機会に中規模アップデートしようと作業中です!
 

◆Ver3.40で何がアップデートされそう?

 今回のアップデートでは大きな目玉要素はないかもしれませんが、「まとまった修正ができるならやっておこうかな」と思ってためていた内容の実装を進めていく予定です。
 リソース的・技術的にやれるか分からない挑戦も多いので実装されない可能性もありますが、今回は有力そうな一部をご紹介していきます。



【キャラチップレイヤーの指定を自由なレイヤー±値で設定できないか挑戦】

 キャラチップレイヤーは元のキャラチップに1~5レイヤーで別のキャラチップ、たとえば服や手持ち武器などを重ねる機能です。
 従来は「元画像から上」の「1~5レイヤー」だけの狭い範囲、少ない枚数に画像を上乗せするだけでしたが、今後、『レイヤー「-1」や「-10000」みたいに裏側へ出せたり、無制限な値・枚数を入れても普通に使える』ようにできればだいぶ実用的になるはずです! と思って機能改修を検討しています!
 追加で、キャラチップレイヤー処理で『レイヤー「0」を指定すれば本体チップをいじれる』ようにしておくのも汎用性の面でよさそうですね。
(ただし現状、「同じチップサイズ」じゃないと重ねられないのは従来通りになりそうですのでそこはご注意を! これに対応しようとしたら問題が山ほど噴出したのでまだ難しいです)



【変数操作の機能追加】

 代入演算子に「=√[x1000]」を入れたり、右辺の計算に「ビット和(論理和)」「排他ビット(排他的論理和)」を追加してみる予定です。
 右辺の計算には「ビット積」だけがなぜかあったんですが、『片道勇者2』内でそれを使って『ビット和』を計算する処理を作っている最中に急に冷静になってしまいました。「自分でウディタに機能足せるんだからそこは作ろうよ……!」って。
 このあたりのビット操作処理ができるようになると、プログラミング知識が豊富な人ならより幅広いことや高速処理ができるはずです。



【セキュリティ周りの更新「ファイル個別暗号化」】

 今回も新しいプロテクト方式と新しい暗号化方式を追加予定ですが、その他に、もし作れそうならプロ版機能として「ファイル個別にユーザー自身で暗号化できる機能」も搭載できないかなと考え中です。
 1個ずつのpngやtxtファイルをユーザが設定したキーで暗号化でき、その画像やテキストファイルはエクスプローラーからなどでは直接読めなくなります。

 おそらく、「ゲーム内でその暗号化ファイルの読み込み時に正しい【復号キー】が設定されていないとファイルとして読み込めない」という形になるでしょう。
(開発中は元ファイルと暗号化済ファイルを並べて置いておけて、ゲームデータ作成時に暗号化済ファイルがあるファイルが消される、みたいな形が扱いやすくて理想だと思います。当然、開発中でも暗号化済ファイルがあればそちらの方を優先して読みに行くようにして)

 データを暴こうとする人は仮に.wolfファイル(暗号化フォルダ)を解凍できるところまでいっても、個別暗号化ファイルの【復号キー】をファイルごとにコモンイベントやマップイベント内から探さないといけないので手動解析の手間が増えますし、もしオンライン経由で必要なタイミングでだけ【復号キー】をDLしたりする形にするなら復号化がもっと困難になります。
 もっと強固にファイルを守りたい人向けの、最終防衛線的な機能になるでしょう。



◆雑談 PC内のEXEだけでセキュリティを守るには限界があったお話

 私はこれまで、Game.exeやEditor.exeみたいなEXEファイルの逆解析って、たぶん機械語で出てくるからすごい読みにくいんじゃないかなー、となんとなく思ってたんですよ。

 ところがつい最近、セキュリティのお勉強がてらEXEファイルの逆解析ツールを使ってみたんですが、その性能に目玉が飛びました!
 私が試したのはアメリカ国家安全保障局が提供しているものだったんですが、まずは見てくださいよこれ!
  ↓
クリックで拡大


 左側が私が手で書いたソースコードで、右側が作成済みのEXEファイルを逆解析して自動的に再構成されたコードです! 「右側」をご覧になると分かると思いますが、コード構成としては実質完璧に元の内容を復元できているんですよ! すごい!

 つまり普通に作られたEXEファイルは、関数名や変数名が目隠しされた状態とはいえ、『処理自体は全部見られる』状態になってしまっているのです!
 こんなこと、普通に趣味プログラミングをしてるだけじゃ全然知りえなかったことです! もちろん関連処理を全部しっかりコピーすればそのまま動作もするでしょう。

 ウディタ内でたとえると、EXEファイルそのものが「コモンイベント」だとすると、「コモンセルフ変数名」と「コモンイベント名」が謎の文字になってるだけで暗号化も何もされていないコモンイベントがそのまま見られるような状態になってしまっているのです! やってる計算や文字列操作など全ての処理が分かってしまう!
 いちおうそれでも、「がんばらないと内容を解析できない」というのは全くそうなのですが、ここまでできてしまえば達人がじっくり見ていけば色んな情報が分かるので、解析のハードルは私の想定よりめちゃめちゃ低いです。たぶん今の私ですら、かなりの解析を進められるでしょう。
 そして何より、EXEの上にいくら暗号化を積み重ねても、EXE自体の中味が見え見えなので土台があまりにボロボロすぎて、時間たっぷりかけて解析をしようとする人から見れば何も守れていません。

 なので、ウディタ側で提供される暗号化処理も基本的には全て丸見え状態であり、ローカルファイル内(PC内だけで完結するゲームデータ)だけでセキュリティを守るというのは非常に困難だったのです。セキュリティについて学べば学ぶほど、そう確信します。
(なおプログラマー側がやれる最後の壁として、「難読化(コードを壮絶に読みにくくする)」や「仮想環境でEXEを囲って実行する(ただし処理が外部から見られにくくなるので高確率でマルウェア扱いされる)」といった対応策はありますが、ここまでするとなると個人レベルでやれることを超えています)


 ツール提供側としては、(作業用のリソースが確保できるくらいのプロ版の売上げが出たら)半年に1回とか何ヶ月かに1回ペースで最新の暗号化方式を出すくらいならできる可能性はあります。
 が、どんなに強力なセキュリティを作ったとしても、今回の話のように前提自体が防御にあまりにも向いてないので、解析しようとする側が一定水準の能力を持っていれば絶対に暗号化なども破られてしまいます。
 原理的にそうならざるを得ないので、この点はどうかご理解ください。



【それでもデータを守りたい場合は? オンラインにデータを置く方式】
 もしウディタ作品でどうしてもファイルやデータを守りたい場合は、サーバー依存のゲームのように、『イベントシーンやゲーム段階が進むごとに必要な画像やデータを一時的にダウンロードして使用する』といった形でデータを守る仕組みが必要になるでしょう。
 実質オンラインゲーム化!

 今後はどうしても秘匿したいデータがある人向けに、サーバー経由でデータを取り扱うアイデアをマニュアルに記載していく感じの対応にしようと考えています。私がウディタのセキュリティ周りに時間を使っているとそれだけで寿命もお金もなくなってしまうので。



【セキュリティの難しさを学べたことについて】
 色々述べてきましたが、セキュリティ周りに関して今回みたいな説明ができるところまで勉強ができたこと自体は本当によかったと思っています。

 ファイルやEXEの解析とも部分的に関係がありますが「なんでチートがなくならないの?」という理由の一端を理解できましたし、アンチチートツールを提供してチート対策を実現している人たちがすさまじく不断の努力をされていることも理解できました。
 こういったセキュリティは、それだけを行う、優れた人たちが集まった専門チームが日々アップデートしていくつもりでやらないと防御しきれないものなのだと強く納得できました(そしてそこまでやっても、負けてしまうことがときどきあるのです)。

 とはいえ私も、その難易度の高さを理解した上で、かけられるコストの範囲内でのセキュリティ対応はやっていこうと考えています。
 ただコストの面として、ウディタの修正だけやっていても生活ができるならいいのですが、今月は2週間経過時点でプロ版収益から考えた時給が一時200円切ったりしてるのでとてもヤバいです!(今現在は時給230円くらい、皆さんありがとうございます!)。
 まとまったセキュリティ更新のチャレンジとしては、今回の修正をいったん最後にしようと思っています。私が餓死しちゃう!



 ということで、今もみっちりウディタの修正作業中です!
 日々勉強で楽しいのは楽しいですが、ゲームの方を作らないと本当に生活がまずいので、ウディタ開発もほどほどにバランス良くがんばっていきたいですね!

 9月内におおよその修正が終わればいいのですが、優先して入れるべき面白そうな機能を思いついた場合はその分遅れていきます。
 そうなった場合は、次回も新機能のご紹介が続くでしょう!

 ということで、ウディタVer3.40中規模更新、ほどほどの期待でお楽しみに!
 出せる情報があったら、X(Twitter)[要Xアカウント]などでもちょいちょい情報を出して行ければと思います!
 2024-09-20 (金) web拍手 by FC2 カテゴリ: ウディタ




2024-09-07 (土)   ウディコン:ゲームコンテストの裏側と改善の歴史
 今回は『ウディコン(WOLF RPGエディターコンテスト)』というゲームコンテストを15年やってきて、私が得てきた知見や、ルール変更の歴史について残しておこうと思います!
 これからゲームコンテストを開きたい人はぜひ参考にしてください。コンテストの裏側の苦労を知ってみたい人にもぜひどうぞ。たぶん15000文字以上あるので多いですよ!


※第13回ウディコンイラストよりウルファール&夕一


◆ウディコン開催前の話

【自前でウディコンを開催する理由 コンテストパークが終わったから】

 最初は、自前でコンテストをやるつもりはありませんでした。
 というのも、ツクールシリーズ販売会社さま(当時は株式会社エンターブレイン)による『コンテストパーク』というアマチュアゲームコンテストがあったので、ウディタ利用者のみなさまが目標にしてもらうコンテストもそこに任せればいいや! と考えていたのです。

 私もそれまでに2作品をコンテストパークに投稿しており、「出せる場」と「締め切り」があることがどれほど自分のゲーム開発のモチベーションに良い影響を与えていたかをその身で痛感していました。
 コンテストパークがなかったら、『シルフェイド幻想譚』(RPGツクール2000製)も『モノリスフィア』(ウディタα版製)も完成させてなかったかもしれません。受賞作品には審査員からのコメントも付いて、これがうれしかったんですよ!


↑これはシルフェイド幻想譚のコンテストパーク金賞受賞時のページ(インターネットアーカイブより)


 ですが、ウディタを正式リリースした2008年3月から3ヶ月後の、2008年6月。なんと『コンテストパーク』が終了してしまいました!
 そう、目指してもらうべきコンテストがポッカリなくなってしまったのです!
 私はそれから半年くらい、どう動くべきか考えていました。そして悩みつつも、最後はコンテストを自前でやることを決めたのです。

 内々で実行可能性を考え、準備を行い、実際にウディタコンテストの開催を発表したのは『コンテストパーク』終了から9ヶ月後の2009年の3月(窓の杜さまのニュースより/アーカイブ)でした。
 そして第1回ウディコンが開催されたのは予定通り、その夏の2009年7月です。


 ちなみに同じ思いを抱いた方々がいらっしゃったのか、あるいは上記と関係ないタイミングだったのかは覚えていないのですが、小規模なコンテストとして(おそらく2008年頃から)『非公式ウディコン』も有志の方で開催してくださっていました! 
 こちらがウディタ限定コンテストの『元祖』というべき存在で、実際のコンテストの様子を見せてくださっていたことで「ウディタコンテスト……公式でやってもたぶんいけそう!」という実現可能性の確信につながっています。
 『コンテストパークの終了』と並んで『非公式ウディコンの存在』もまた、今のウディコンという大きな火をともしてくれた偉大なる始まりだったのです。



【ウディコンの初心 やる気と宣伝のサポートをしたかった】



 上は第1回ウディコン開催の2ヶ月前に書いた、2009年5月の私の記事の抜粋です。

 ここではウディコンを始める理由として、ウディタ利用者の皆さまへの「やる気」と「宣伝」の補助が挙げられています。
 開発ツールのサポートの一環として、コンテストを通してユーザーに「やる気」の提供まで試みようとするなんていま考えたら個人レベルでやることじゃないような気もしますが、当時の自分は無謀でした。そもそも自分用ツクールを作るところからして無謀でした。でもコンテスト開催もツクール提供側で行われていましたから、自分もそれを見習おうと思ったのでしょうね。


 ひとまずウディコンの最初の開催動機は、ゲーム開発者の方への「やる気」と「宣伝効果」を提供することです。
 これだけだと奉仕者的な「立派な建て前」なのですが、個人的な感情としては、

「私が『コンテストパーク』でもらった『ワクワク』や『やる気』を、みんなにも体験してもらいたい!」

 という思いがありました。

 すでにウディコンを楽しんでくださっている方には言うまでもないんですが、とても面白いんですよ、コンテストのワクワク感! 出す方も遊ぶ方も!
 「これらを味わえた身として、この体験は将来につないでいきたい!」と思っていました。

 私にとってのゲーム作りも、そういう「面白かったからみんなも味わって!」という動機で始まることは多いです。今回も、「イベント開催」という形でそれを実行することになりました。




◆ウディコンの最初のシステム

【最初は人気投票に近い投票システムだった】

 ウディコン初期は、当時あった『3分ゲーコンテスト』というコンテストの規約を参考にルールを設定しました。投票ルールもほぼ同じ形だったと思いますが、3分ゲーのほうは過去のページが消えていて正確なことが言えません。

 『3分ゲーコンテスト』は完全一般投票制で、人気投票に近いシステムです。「一番票、二番票、印象票」にあたる作品を選ぶと、票の重さに応じて作品にポイントが加算される形だったはずです。

 私がそのコンテストを見ていて感じたのは、「配点の重み付け」を付けてある程度の「人気の差」をカバーできているものの、状況次第では強力な『人気の波』に押されてしまう可能性もあるかもしれないなあ、という想像でした。

 たとえば多くの人に「印象票(一番得点が低い)」のゲームとして選ばれた場合でも、総合順位そのものは「合計点」で決まるので、その得票数の数がケタ違いならば「印象票」だけでも1位になれてしまうのです! そもそも知名度が高い人が投稿してきたら、それだけでコンテストがめちゃめちゃになりますよね。
 その結果、『事前の知名度』だけで得点が大幅に左右されてしまうという『穴』が生まれてしまう可能性があるため、「もし自分がコンテストをやるとしたら『品質』を評価する軸も欲しいな」とぼんやり考えていました。

 といっても、人気が集まりやすい作品は基本的に『素晴らしい作品』なので、評価の大筋としてはそれで正しく評価されていました。『3分ゲーコンテスト』の基本ルールは、十分な成果を期待できる名システムだったと思います!

 なにより『3分ゲーコンテスト』がすばらしいのは、『プレイヤー側がコンテストに参加できる』という形式であること!
 企業の審査員の方々によって審査される『コンテストパーク』とは違い、プレイヤーの側も巻き込んでいく楽しさがあります。この楽しさもまた、取り入れられたら面白いだろうなと思っていました。




【半分審査員制にして、一般審査と別の『品質評価』をしようとした】

 ということで第1回ウディコンでは、恥ずかしげもなく『3分ゲーコンテスト』をベースにさせていただいてルールを考えることになりました(ウディコン規約にも3分ゲーコンテストを元にしたと書いてあります)。

 ウディコン初期の投票ルールは、『数名の審査員』と『多数の一般投票者』が「一位(5点)、次点(3点)、好印象(1点)」の作品をそれぞれ選び、それぞれの「累計ポイントの割合(%)」の合計がその作品の総ポイントになるという形にしていました。

 たとえば『審査員ら全員が作品Aに総得点のうちの24%の票』を入れ、『一般投票で作品Aに8%の票』が入れば、作品Aの順位ポイントは24%+8%=「32%」となります。この32%を得た作品Aは、31%の作品Bより上の順位となるわけです。


 ↑第1回ウディコンの結果。一般投票では1位じゃないけど審査員票を足して1位になった作品(1位)や、両方バランス良く点を取って上位になってたり(3位)、一般票が強い人気作品が審査員票で中和されてたり(7位)、やりこむと面白い作品を審査員側が引き上げるケースもありました(4位)。


 この方式は、ある程度はうまく機能していたと思います。というのも、

●「一般投票」だけで決めるとプレイ数が多い「見た目がキャッチーな作品」が明らかに強くなり、品質面の評価がにぶる可能性がある。

●一方で「審査員」だけの審査だと、得点が足りなくて隠れ名作のピックアップまで手が回らなくなる(一般審査の方が得点的にきめ細かく評価される)し、何よりプレイヤー側で参加できないのは面白くない。


 という問題がそれぞれにあったため、ダブル審査は互いの弱点をおぎなう折衷案として考えたルールだったのです。
 役割分担としては、『品質のみの評価は審査員側で行い』、『人気×品質の部分を一般投票側で評価しよう&それでユーザー参加の楽しさを作ろう!』という雰囲気だったわけですね。
 『審査員側』のポイントは、一般投票で「人気」が先行しすぎた結果が出てしまう場合に『安全弁』として作用させたい意図がありました(もちろん誤解のないように言っておきますと、面白さも1位であればその「人気作品」の「審査員」票もトップ割合になりますよ!)

 たとえばどういう状況を防ぎたかったかというと

●面白さは1位ってほどじゃないけどフォロワー10万人の有名Vtuberが作ったからってファンの人がみんな「一位票」を入れてぶっちぎり1位になっちゃってるー!
 
●「見た目がいいゲーム」の方がプレイヤー数が相対的にDL数が多くなるせいで何よりも見た目がいいゲームが強すぎるー!!
 (実際、最新の第16回ウディコンのトップ争いでさえ、見た目がいい作品は他の20%以上投票数が多くなっていました)


 みたいな状況に対応するために、半分を「審査員制」にしたわけです。
(とはいえ、「既存ファンがいる人の作品」の方は実際に来たら優勝をほぼ止められなかったでしょうけども! でも当時はウディコンも、そういった方が来ない場末(ばすえ)のコンテストでしたから、特に問題にはなりませんでした)

 上記「既存ファンが多い人が応募するとヤバイ」「見た目がいい作品が強くなりがち」の2つは、投票数が重要なゲームコンテストをするならどっちも想定しておくべき課題だと思います。
 何なら一般投票のみならば、(運営でもある)私が出て割と簡素なゲームを出したとしても、票数だけ稼いで優勝する状況がありえたでしょう。それは避けなければなりません。

 といっても、この「ほぼ人気投票」システムでやってきた第3回ウディコンまでに関しては、上位作品については「一般投票」も「審査員審査」も両者の投票率上位が一致する確率はそこそこ高くて、おおざっぱには「人気投票」的な評価でも問題ない感触がありました。
 もちろん、「イラストがかわいい」などの理由で一般投票の得票数に1.5倍くらいのボーナスがかかっていそうなこともあるので、そこは将来の課題でした。




【この方式の問題点:審査員の負担が心身ともに重い】

 さて、次はこの審査員&一般投票のハイブリッド方式の問題点について話しますが、「得点を出す方式」自体には、実はそんなに問題は起きませんでした。

 何が問題だったかというとこの方式、審査員の心身の負担が非常に大きかったということです。
 私も、運営と審査をダブルでやるのがあまりにキツすぎて寿命が縮むかと思ったので、第3回では私が運営に集中する形にして、審査は「協力してくださる審査員の方(そのときは6名)」に全てお任せする形にしてしまうほどでした。

 体の負担と心の負担について、それぞれ見ていきます。


【体の負担】
 まず体の負担に関してまずかったのは、『増加する作品に対する審査負担が増えすぎた』ことです。
 第1回は29作品! 第2回は53作品! 第3回は68作品!
 「ヤバい!! これ全部遊んでたら次は誰か帰らぬ人になるかもしれない!」と思ってもおかしくありません(結局作品数の増加はその辺で止まったんですけども)


【心の負担】
 そしてコンテストでの審査は、心の負担も大きいものでした。
 まず、審査員側は審査内容に納得してもらえるよう、「審査コメントの書き方」や「採点」にも非常に神経を使っています。
 ですが開催規模が大きくなれば、いくらコメントや採点に注意しても、審査員は「順位に納得できない人(主に作品ファンの方)」からの批判を浴びる立場になってしまいます。

 もちろん、皆さん良識あるプレイヤーの方々の方が圧倒的に多いので、規模が小さいうちは批判する声も小さかったのですが、それでも規模が大きくなれば必ず批判の声が一定数出てきてしまいます。それを審査員ご本人が目にすると、相当に辛いのはあきらかです。

 何よりテキストSNSの『Twitter(現X)』が急に普及しだしたのもちょうどウディコン開催の頃で、まだ今みたいにマナーガチガチじゃなかった頃のSNSユーザーが、素直すぎる感想や批判を投げちゃったりする時期でもありました。
 それもまた、心に痛みを発生させる状況の一因になっていたかもしれません。
 この精神負担を考えると、審査員制は長くは続けられないと真剣に思っていました。


【追加の負担・そもそも「運営作業」だけでも大変】
 そして「多くの作品の審査作業」「批判によるダメージへの想定」の他にも、さらにはウディコンの『運営作業』そのものも、最初は全員で協力しなければいけないほど非常に大きな負担が発生していました。
 肉体的な疲労と精神的な疲労がダブルで襲いかかる審査員の負担はとても大きく、私はこれらに対し、改善が必要だと考えていました。




◆ウディコンの今のシステムができあがるまで

【完全に一般投票だけで結果が出るように変えた】

 第3回終了後、「規模が大きくなってくると審査員制はまずい! 負担が大きすぎる!」と思った私がまず行ったのは、『全て一般審査のみで順位を決定する方式』への変更でした。

 ですが一般審査で順位を決定するにも、これまで何度も言っているとおり、すでに知名度を持つ人がファンの方々に投票してもらえば勝てる『人気投票』みたいになっては、参加者の方も一般審査の方も冷めてしまいます。可能ならこれまでも何度か考えたように、「品質」の評価をメインにしたいところです。
 ですが同時に、「注目される」ということ自体も、ある程度は重要な評価軸の一つにすべきだと思います。ゲームというコンテンツは『注目される力』も重要ですよね!

 また当時、「色んな評価軸で『1番』が生まれるといいよね」というコメントもSNSでいただいており、私はそれがとてもすばらしいことだと感じました。
 「部門1位が取れた!」と喜べる人は『部門の数だけ増える』わけで、また、多様な面で順位が出るような評価方式をすれば、作品の強みや弱みも洗い出しやすくなります。
 開発者の方にとっても、今後をはかる良い指標になることでしょう。

 なので、作るべき新ルールの目標は、以下の3点になりました。

◆「品質」が主に評価される。
◆「色んな評価軸」で評価される。
◆人気だけで順位が決まるようにしない。ただし「人気」自体は評価に含められるようにする。





-【[ルール構築]部門別の得点付けシステムの導入】

 前述の「品質重視」の目標に従い、評価システムはこれまでの「ほぼ人気投票方式」から、非公式ウディコンで採用されていた「各部門の得点付け」方式寄りに変えることにしました。

 部門分けは、非公式で開催されていたウディコンが
「総合」「システム」「シナリオ」「素材」「自由裁量」
だったのに対し、こちらの公式ウディコンでは
「熱中度」「物語性」「斬新さ」「画像音声」「遊びやすさ」「その他(自由裁量)」
 の6部門を総合して、総合評価が算出されるようにしました。

 特に『斬新さ』は絶対に入れないといけないと思っていた項目で、これがないとどこかで見たシステムのゲームが連勝するという問題が起きると考えていて、「絶対にみんな冷めちゃいますよね!」と考えていました。
 『斬新さ』部門については非常に重要な点なので、後にもっと掘り下げて話していきます。

 先に、「平均点と人気の複合評価」について話していきます。
 



-【[ルール構築の課題]平均点と人気の複合評価】

 ウディコン新ルールでの得点付けは、部門ごとに「平均点の順位ポイント」、「合計点の順位ポイント」、そして「中央値」の3つが加算され、この合計値が総合順位用のポイントになります。


↑第14回ウディコンの「熱中度」部門の例。「平均点・合計点・中央値」でランクPが足されて「熱中度得点」になっているのが分かります

 この「平均点の順位ポイント」、「合計点の順位ポイント」、「中央値」の3つの意図について、それぞれ見ていきます。


【平均点の順位ポイント】
 これは、たとえば「熱中度」における『平均点』が高順位であるほど得点が多くなる! という形のポイントです。単純で皆さんも納得しやすい評価だと思います。
 たとえば平均点8.5点で1番だった作品Aには「30ポイント」、平均点8.2点で2番だった作品Bは「29ポイント」、みたいに得点が与えられます。

 が、実はこれだけだと穴があり、

●投票者が極めて少ない状態では「超ファン」の方からの投票だけになりやすく、過剰に平均点が高くなる。
●投票者が多いと「合わない人」からの低得点率も増えて平均点が下がっていく。


 という2つの問題が起きると思っていました。
 それを調整するために取り入れたのが次の「合計点の順位ポイント」でした。


【合計点の順位ポイント】
 「合計点」は全ての一般審査員が入れた部門点を合計した値で、大きいほど高得点を得られます。
 たとえば、熱中度に8点を入れた人が10人いると合計点は80になり、それが合計点1位ならば「15ポイント」がもらえます。続けて、合計点が75点くらいで2位の人も「15ポイント」、3位の67点の人は「14ポイント」……みたいに、「合計点が高い順」に高ポイントが与えられるわけです。
 といっても、影響度は「平均点」の『半分』で、2位下がるごとに1点ずつ減っていくようになっています。

 『品質がメイン、ただし人気もいくらか加味する』というバランスを取るために仮にこの割合にしたのですが、ウディコンを10回以上やっても変わらず使えているので、ゲームバランス的にはまあまあいい塩梅(あんばい)だったのかもしれません。

 また上で書いた通り、投票者が「少数の超ファンの人だけ」だと「平均点」が上がりやすく、投票者が多くなるほど「平均点」が下がりやすい傾向がありますので、そこで増減した値のバランスを取るためにもこの「合計点」項目は重要でした。
 この合計点によってそこそこ良い感じに、プレイヤー数による平均点のプラスマイナス補正を打ち消し合う関係になっていると思います。

 上位争いに混ざるなら、この「合計点」、もとい「人気」は必須です。
 ほぼありえない想定ですが、仮に『全て10点満点の投票が1票だけ』入って、それ以外まったく票が入らず審査が終わって「全部門の平均点が10.0点満点」になったとしても、「合計点」の順位ポイントが全部門で0になるので、トップにはなれないようになっています。



【中央値】
 『中央値』、聞き慣れない数字かもしれませんが、たとえば101人の点を小さい順から大きい順に並べた場合の「51人目の数値」が『中央値』になります。要するに「真ん中の人の数字」で、「平均点」とは違います。9人が「1,2,3,4,7,9,9,9,9」みたいに点を付けた場合、中央値は「7点」になり、平均点は「5.9点」です。

 『中央値』のポイントは数値通りそのまま加算されます。「『平均点』と並べれば情報を立体的に把握しやすくなりそうかな?」という程度の意図で用意されており、得点上はさほど大きな意味はありません。
 この中央値ポイントは、上位争いにおいて「品質が良ければ1点分有利になるかどうか」程度のおまけ要素だったのですが、たまに「X年ぶりの中央値9点だとォ!?」とか「初の中央値10点が出たァァーッ!!」というのが分かったりして面白かったので、これはこれで指標の一つとして入れてよかったと思っています。

 なお「中央値が10点」ということは、『半分以上の人が10点を入れた』という意味になります。第14回や第16回ウディコンの画像音声部門で中央値10点が出ましたが、とんでもない偉業であることが分かります。





-【[評価基準]コンテストを守るために重要な「斬新さ」部門】

 6部門のうちの「斬新さ」という部門は非公式ウディコンにはなかった項目で、私が明確な意図を持って追加しました。人によっては「ゲームは面白かったら斬新じゃなくてもいいでしょ!」というご意見もあるかもしれません。

 「斬新さ」を入れているのは「私が個人的に斬新なゲームを求めているから」という理由もありますが、それ以上に重要な理由があります。
 というのも、「斬新さ」部門がないとコンテスト内で以下のような現象が発生してしまうことが予想されたからです。

●1.よくできた既存ゲームのクローン作品が上位に来てしまう!
 
●2.ウディコンで高評価を得た前作の、ほぼ同じシステムの続編が何度も上位に来てしまう!


 1は「既存ゲームのクローン作品が上位に来るのはコンテストとしてつまらない」とごもっともな内容だと思いますが、さらに危ないのは2の方!
 2の「ほぼ同じシステムの続編が何度もコンテストを連覇してしまう問題」は、別のゲームコンテストで一瞬それっぽい流れになったのを実際に見たことがありました。この流れになると運営もプレイヤー側も気分が上がらなくなるので、これだけは何とか避けなければならないと思っていました。

 たとえば参加者のみなさま同士で
「そっちが『前作の続編』で来るなら、俺は『最近流行りのゲームのクローン作品』で勝負するぜ!」
 などの展開が常態化すると、コンテストとしてはだいぶつらみがあります。
 上位作品が見慣れたものばっかりになるのはたぶん面白くない!

 そういった状況を抑止する「防御力アップ」の目的で、私は『斬新さ』をウディコンの評価として取り入れることにしました。
 この評価軸がある限り、「前に出したゲームと全く同じシステム」の続編ゲームをウディコンに出した場合は、「斬新さ」の項目がほぼ「ランク外」か低順位になってしまうでしょう。そのマイナスを背負ってまで1位になるのは相当に難しいはずです。

 実際、過去に1位を取得された方でも、次に出されるときは旧システムの流用であれどもしっかり「新たな面白さ」を味わえるよう改良したり、新たなゲームシステムで出してくださっているので、「斬新さ」は入れてよかったなと思う評価項目です。

 とにかく、
「優勝するためにはまったく同じ手は通用しない(ので、仮に続編を出すにしても新たな工夫をしてね)」
 という方向に誘導するのは、コンテストを長く続けるにあたってとても大事な点だと思うんですよ。


【余談:「斬新さ」と「遊びやすさ」の両立は難しい】
 ちなみに、ゲームシステム面で「斬新さ」を取りに行くと、ルールを伝えるのが開発者的に難しくなるため「遊びやすさ」が減少しがちです。
 だって、『まだ誰も遊んだことがないルールのゲーム』のチュートリアルを作ったり難易度調整をしたりしないといけないんですよ!? 初めての試みで、何もかも難しいことだらけになります。
 でも「斬新さ」を取りに行かないとトップを取りに行くのは難しい! そうなると「遊びやすさ」が確保しにくくなるため必要思考量や要求されるセンスも増大し、どんどん修羅の道に突入していくことになります。

 でも実現が非常に難しいことだからこそ、そんな「新しくて面白くて遊びやすいゲーム」に触れてみたいと思っているプレイヤーの方もたくさんおられると思いますし、私だってそのうちの一人です。
 そして参加者の方にとっても、この領域に挑戦できる人にとっては、とてもやり甲斐があるミッションになるでしょう。




-【[総合順位]総合順位は(妥当性は低くとも)民主的っぽく算出したかった】

 総合評価の計算には、これまでで計算された『各部門別の得点』に加え、各一般審査員の方が入力した、『各部門の「重視度」を平均した値』が使われます。複雑で何言ってるかパッと分からないですね!

 たとえば「物語性は40%重視する」など各人に選んでもらったのを平均して、総合評価用の「平均重視度」を算出します。
 もし「物語性には意味がない、重要度10%!」と思った人が非常に多かったなら、総合評価においても「物語性」の得点の影響度が減ります。一見、民主的っぽく思えますね。

 この「重視度の平均」は、だいたい毎回「熱中度 80%、斬新さ 50%、物語性 60%、画像/音声 50%、遊びやすさ 75%」前後の値になります。斬新さと画像音声が低めでもいいのは、面白ければ何でもいい感じの方が多いからでしょうか。


 そして総合グランプリは、作品ごとに
 [部門別得点]×[一般投票者が投票時に選んだ『重視度』の平均%]
 によって求められた得点を、6部門全て足して算出されたポイントで決定されます。

 たとえば熱中度で50点を獲得し、重視度平均が「熱中度80%」になったなら、50×0.80=「40点」が総合得点に加算されます。それを6部門それぞれに対しておこない、全部足したものが、総合順位計算用の最終ポイントとなります。


 私はルール変更後の第4回開始前に「こういうやり方なら割と民主的なので、皆さんの順位への不満も減るのでは……!?」と、ちょっとだけ期待していました。


 でも実は、第4回と第5回でも、納得行かない方からのコメントはまだ目立つくらいには飛んできていました。
 「これでもダメなのかー!」と私は頭を抱えていました。




-【[仕上げ]総合順位発表に納得しやすくなる情報を加えたら苦情が減った】

 そんな風に第5回まで、「こんな順位に納得行かない!」というコメントが結構あったのですが、第6回からの結果発表に「ある情報」を載せるだけで、そういったコメントが急激に減りました。
 さて、一体何をしたのでしょうか? 

 以下は第4回の順位発表欄と、第6回の順位発表欄です。赤線部分に注目してみてください。


 ↑第4回ウディコン 順位発表欄



 ↑第6回ウディコン 順位発表欄

 もうお分かりですね!
 それは総合順位の発表欄で「各部門得点の『順位』を並記するようにした」こと!

 実は第5回までは「各部門の得点」だけ表記されていて、そこに「順位」は載っていませんでした。
 つまり第5回までは「熱中43.9+斬新28.3+……」とだけしか出ていなかったのですが、今は「熱中43.9(1位)+斬新28.3(14位)……」のように出ているのです!

 この各部門の「順位」表記が付いて何がよくなったかって、『(納得できなさそうな)順位を見た次の瞬間』に「どの部門で致命的に得点を落としたのかが一目瞭然になる」んですよ! それと同時に「強い部門ではしっかりちゃんと評価されていた」ということも理解できるのです!
(といいますか、その順位情報を入れないと各得点の真の意味が直感的に分からなかったので、単純に私の配慮不足なところがありました)


 すごくいいゲームでもあまりに高難易度だったりすると、「熱中度」が3位以内なのに「遊びやすさ」の順位が「ランク外」になってしまうこともあって総合順位が下がってしまう場合があります。
 こういう作品も前述の変更によって、投票した人が結果を見たときに
 「あー『熱中度』は期待通りのトップ順位だったけど『遊びやすさ』の面で受け入れられなくて総合順位にひびいたのかーなるほど!」
 とすぐ分かるようになったわけですね!


 この点は小さい工夫ながらも『納得感』を生むために非常に重要だった感触で、この順位表記を入れた第6回あたりから「作品の順位に納得いかない」という声が極端に減りました。というより、ほぼゼロになった印象がありました。

 もちろん「この方式に慣れてきた」という理由も何割かはあるでしょうが、コンテスト運営の陰にはこんな風に『一見小さいけど重要な補助情報を入れるのも大事なんだな』と感じさせられた、気付きにくい出来事もあったのです。


 そしてこの教訓は、ゲーム開発にも活かせる話です。
 『ほんの一つの数字が見えているか否か』だけの差で、プレイヤーの「納得感」を大きく変えられることもあるのです!

 これだからゲーム開発もコンテスト運営も奥が深い! と思います。




【君が一番だと思ったゲームこそが一番!:総合順位と宝物となる作品かどうかは別】

 コンテストの「総合順位」と「あなたにとって宝物となる作品かどうか」は別問題!
 というニュアンスのことを、第4~5回あたりの総評から毎回書くようになりました。(そこから年を経るごとに内容が徐々にブラッシュアップされています)

 私は「ウディコンにおける総合順位」の出し方が「部門別ランキングに比べれば妥当性が低いよなあ」と内心思っているからこそ、このコメントをしているのですが、
『総合順位とあなたにとっての宝物かどうかは別問題! 次も宝物作ってくれるように作者さんの次回作に向けて応援してあげてね!』
 という考え方自体は、とても重要なことだと思っています。

 この考えは、順位に納得が行かない人に対してのいくらかのなぐさめになるところもあり、また、他の人もこの文言を使って順位にガッカリした人を励ましてくれていたりするところもあったようなので、書いてよかったなと思っている部分です。


 でもこれだけだとやっぱり足らず、「順位に納得が行かない」の空気が決定的に減ったのは、やはり前述の「各部門の順位表記の追加」のときだったように思います。
 昔は「自分が好きならみんなも絶対好きなはずだ!」という感性が皆さんの間でかなり根強かった感触で、「好きな作品が高順位にならないのが本当に理不尽だ」と思われる方も多かったように思うのですが、「部門別の順位表記」が出るようになったおかげで「順位を落とす作品には、多くの人に合わなかった部分も含まれている」というのがだんだん理解されていった印象でした。


 ちなみに、私の一番好きなゲームはウディコンではしょっちゅう7~10位くらいになっていました。
 私は『よく分からない状態から探っていく』ゲームや『かなりクセがある』系のゲームもけっこう好きで、たまに激ハマりする作品があるのですが、そういうタイプはどうしても「遊びやすさ」で点を取れないんですよ!




【多くの手順を自動化して運営を省力化した】

 また、第4回からは基本的に1人でウディコン運営をすることになりました。必要なら協力者の方にごく短期間だけ手伝っていただいたりしています。

 基本1人ベースにしたのは、それまでの審査員のみんなの心身の負担がとても大きかったので「ここから先は、何かあったときに責任や負担を負うのはもう自分だけでいい」というヒロイズム精神による側面もいくらかあったように思います。
 ですがそれと同時に、「何かあったら一人で爆散すればいいんだ! 一人なら何もこじれずにやめられる!」みたいな気持ちも裏にありました。
 それまでの第3回までに感じていたキツさが度を越していたからかもしれませんが、なかなかヤケな感じが出ていますね。
 
 なお第3回までのコンテスト運営作業で特に大変だったのは以下の3点で、このあたりの労力をカットできればだいぶラクができると考えた私は、サーバープログラムによる『自動化』を進めていました。

◆新規エントリー作品が来たときのページ更新作業
→ 作品のエントリーチェックが終わったらボタン1発で追加登録できるのが理想です。
 
◆エントリー情報(ゲームデータ)の差し替え対応作業
 → 最終的には「エントリー内容修正フォーム」ができて、何もしなくてよくなりました。
 
◆結果発表ページの作成作業
 → 集計済みのデータを入れたら自動的に結果発表ページを作ってくれるものが理想です。


 第1~3回あたりまではこれらを手動で行っていたのですが、正直かなりの労力を支払わなければならず、控えめに言っても地獄のようでした。運営に協力してくださった審査員の皆さんには感謝の限りです。

 もちろんこれ以外にも「お問い合わせ」や「その他の問題」がいっぱい来ており、その対応にも追われている中でこの作業もやらねばならないわけです!
 なので私も審査員の皆さんも心身の負担は大きく、第1~3回ウディコンでは途中から全員死にそうな気分になっており、コンテストが終わる頃にはお互いが「死線をくぐり抜けてきた戦友」みたいな雰囲気になってしまうほどでした。


【自動化は一部分ずつ進めていました】

 私は何の因果か、それまでのサイト運営で「Perl」という、サーバー上で動作するスクリプト言語を少しだけ扱えるようになってので、投票ルールが変わる第4回前から運営をラクに行えるウディコン運営システムを徐々に作っていくことにしました。
(ただ今ではPerlはさすがに古いので、せめてPHPなどがおすすめでしょうか)

 まず最初は「一部分の自動化」をして運営し、また手作業での実際の運営手順を洗い出し、作成すべき結果発表ページの構成が見えてきたらそこも自動化し……。
 と繰り返していって、それから何度かのウディコンを経ていく中で、今もコンテストシステムは改修・増築され続けています。

 今では前述の3つの重い作業「エントリー」「差し替え」「結果発表」において、人間の判断力がいらない単純作業は大部分が自動化できるようになっています。

 コンテスト運営は、1回目はまず手順を洗い出すために手動で運営しなくてはならないとしても、2回目以降はその手順を元に自動化の仕組み作りができるので、自動化し始められると一人でもコンテスト運営が可能になると思いますよ!

 最近はAIに頼めばプログラムやHTMLも作ってくれる時代なので、サーバープログラムについてあまり知らない状態からでも、コンテスト運営システム作成の実現しやすさは上がっていると感じます。





【作品紹介を個別ページにせずズラっと並べた、思わぬ効用】

 ウディコンは最初、「『作品別の個別ページ』を作って、作品名をクリックするとそこへ飛ぶようにしようかな?」とちらっと思っていたのですが、結局1ページ内に多数の作品が並ぶ形になりました。これには特に強い意図はなく、単純に私が作りやすかったからでした。


  ↑第16回ウディコン、エントリー一覧ページ


 ですが今思うと、ズラっと1ページ内に作品群が並んでいることには大きなメリットがありました。
 それは、外部サイトからリンクをクリックしてやって来たプレイヤーの人がこのページを開いたとき、今みたいに一覧で並んでいる方式ならば【周りのいくつかのゲームも絶対に目に入る】ということ!
 外部から「個別ページ」へのリンクだと、その1ゲームしか目に入らないので広がりがないのですが、1ページ内にたくさんゲームが並んでいればついでに他の作品も目にするチャンスも増えますし、何より普通に遊ばれる方にとっても次々に「ダウンロード」していきやすい!

 そういう意味でも、1ページ内に全エントリー作品群の情報がまとまっている方式は、今はとてもアリだったなと思っています。





【結果発表前の2時間前から、カウントダウン発表をするようになった】

 2014年の第6回ウディコンから、Twitter(現X)で上位12位の「カウントダウン発表」を行うようになりました。
 これは単純で低コストながら、感情面においてかなり大きな効果を感じられるイベントで、それ以後ずっと行っています。

 「カウントダウン発表」がどういうものかというと、まず全ての結果発表が土曜日の「21:00」に行われる予定だとします。
 そうしたら、2時間前の19:00からTwitterで私が
「さーて今回の第12位は……『【作品名】』です! 遊びやすさとその他部門で5位を獲得ー!!」
 みたいに順位を発表していきます。

 そして10分経つごとに「今回の第11位!」、「10位!」みたいにカウントダウンで発表していき、20:50に「今年の第1位」が発表されるわけですね!

 
 この方式、ただ情報を小分けに発表していくというだけなのですが、1位分の発表ごとに、作者さまは自分の作品が来ないかとドキドキし、一般審査の皆さんも自分の応援した作品が来ないかとドキドキできるので、思った以上に感情を盛り上げられる効果があったように思います。
 「だいたいの結果は想像できるけど実際どうなるか分からない」中での答え合わせって、ゲームでもそうですけどなんでこんなに興奮するんでしょうね。

 なお上位を取れる見込みがある作者さまは、この2時間近くのあいだ、人によっては「早く楽にしてくれー心臓がもたないよー!!」みたいな、まるで拷問のような苦しさを感じるそうです。
 私も「これ作者さまにはいじわるなイベントだなあ……でもやったほうが面白いからなあ」と思いながらやっています。こんなにジリジリ待たされるの、人生の中でもなかなかないですよね。
 作者さまには心の中で謝罪しつつ、このやり方自体は今後も続けていく予定です。


 そしてここまで挙げた第6回ウディコンまでのアップデートによって、ウディコンの全体のおおまかなルールはほぼ完成され、今に至る第16回まで使用され続けています。
 もちろん細かな規約変更はときどきありますが、ウディコン運営における特徴的な部分に関しては、以上でおおよそ全て紹介できたと思います。



◆ウディコンの今後の見通し

 さて、ここまでウディコンの主なルール変更の歴史を語ってきましたが、ここからは将来の話をさせていただきます。



【ウディタのユーザー数はたぶん縮小中】

 いきなりですが、ウディタのダウンロード数は基本的に減少傾向にあります。
 最近はもう測ってないのですが、12年前の全盛期に比べると今はアクセス数もダウンロード数も15%(1/6以下)くらいかそれ以下になっているはずです。

 昔と違ってガッツリゲームを作りたい人には、普及率の高いUnityや、人気が高まりつつあるGodotエンジンがありますし、PC版のRPGツクールシリーズはブラウザ版やスマホ用データが作りやすくて今も健在ですし、ノベルゲーム分野でもティラノビルダーなど多数のツールがありますので、おのおの使いやすい開発ツールを使ってくださっているのだと思います。
 よって、今からわざわざウディタを選ぶ理由はあんまりないはず! 私も未経験なら、就職に有利かもしれないUnityあたりをお勉強しているでしょう。


 ゲームを作りたい人は、それぞれが一番良いと思った道具を選んで歩まれていることでしょうから、ウディタが使われなくなること自体は1ゲーム開発者として応援すべきことだと思っています。
 私自身、RPGツクールの進歩と共に成長して、最後には巣立った身ですからね!
(初期からのRPGツクールは新機能や柔軟な機能がどんどん増えていって、その過程でユーザーは自作システム作りやアルゴリズム作りに慣れることができました。スクリプトが搭載されてからはプログラミングができる人も増えました。そこから別ツールに移った人もいれば、私なんてツクールで学んだプログラミング技術をとっかかりにしてウディタという派生ツクールまで自作できたのです!)




【縮小していく中でも楽しめるコンテストを】

 そしてウディコンも、新規ユーザー数の少なさから縮小方向に向かっていくと考えています。
 なぜかコンテスト規模が落ちていないのは単純に、「リピーター」になってくださっている作品参加者の方や一般審査の皆さまのおかげです! 応募作品にいたっては、今回の第16回でも「過去に参加経験がある方」の作品だけですでに50%分くらいに達しているはずです。

 私の何度かのコミュニティ運営経験から推測すると、時が経つにつれて新規参加者の方がほぼいらっしゃらなくなって、最終的には「経験者だけが回す同窓会」みたいなコンテストに近付いていくでしょう。
 そしていずれ40~50作品ほぼ全てが経験者の作品になって、それもだんだん減っていって、最後にもう旧知の仲になってる人同士で10~20作品くらいのご応募があったあたりで、私が
『ウディコンは今回で最終回とします。これまでXX年間ありがとうございました!』
 と言って終われることを、自然で理想的な将来像とおいています。
(なお理想的じゃないルートとしては、炎上して次回開催が不能になったり、想像以上に早くしらけちゃう事故が起きて衰退したり、私が事故に遭っていなくなることですね)

 当たり前のことですが、ものごとが永遠に続くなんてことは絶対にありません。
 そしてだからこそ、『人口が減っても楽しめる』ようにできれば一番理想です。
 50人しかいない村でも、超盛り上がるお祭りがあったら楽しいですからね! 話題になれば外から観光客もいっぱい来ちゃうかも! みたいな感じで。

 実際、ウディコンのルールは初期に比べてだいぶうまく機能したり、なじんだり、盛り上げに貢献できているようで、本当によかったと思います。
 
 また、仮に「同窓会」みたいになっても、この評価システムが機能している間は
『熱中できて、心に残って、見た目もこだわって、斬新で、遊びやすいゲーム』
 を目指せるだけ目指して、みんな作り続けるでしょう。
 それを目指した作品はほとんどの場合、面白いはずですし、いくつかの作品はいつもの通り、「新しい楽しさ」や物語的な「感動」を運んでくれるはずです。

 なので、人が減っていっても、最後まで楽しみたっぷりで終われることを期待しています。もちろんその過程で、さまざまな運営努力や判断も求められ続けるのでしょうけれども。



【いつか来る、ウディタもウディコンも利用されなくなる時代】

 時代と共にウディタが使われなくなっていくのと同様に、ウディコンが利用されなくなっていくことも必然だと思います。でもそれは、必ずしも寂しいことではありません。
 なぜなら、ウディコンから注目が離れていくということは「他にもっと面白い場所がちゃんと生まれている」ということなんですから!

 ウディコンはそもそも『コンテストパーク』終了にともない、ウディタ利用者さまへの「やる気」や「宣伝効果」アップ目的で始まったものです。
 もっと他に「やる気を出せる場所」があったり「宣伝効果が期待できる場所」があるなら、ぜひそちらで思いっきり楽しんでもらうべきです。ウディコンが生まれた理由自体、「代わりがなかったから」なのですから、新しい選択肢が広がるのはとても素敵なことだと思います。

 どんなものも、もっと良いものが生まれる中で徐々に衰退していくのは自然の流れです。
 皆さんも新しいツールや新しい場所を探したり、そこに飛び込む心構えもいくらかしていただきながら、それでも今ウディタやウディコンが面白いのでしたら、その間は思い切り楽しんで活用していただければいいのだと思います!

 ということを本当の衰退期に言うと負け惜しみみたいに聞こえたりシャレにならなかったりするので、盛り上がっている今のうちに言っておきたかったんです!!


 もしウディコンがいつか終わってしまったとしても、私はその浮いた時間でゲームを作って、他のコンテストに参加しているかもしれません。
 それもまた、私にとってはうれしい結末です。




 ということで、ウディコンについていま思いつく限りのことを書いてみました! だいぶ長くなってしまいましたが、いかがだったでしょうか。

 こうやっていざ見返してみると、ただコンテストをするだけでも色んなことを考えてきた気がしますね!
 そしてまた、ウディコンの在り方について思い出すいいきっかけになったとも思います。


 この内容が、これからゲームコンテストを開くかもしれない皆さまの一助となれば幸いです。
 そしてまた、楽しんでくれる人がいる限りは――そして私が楽しめている限りは、ウディコンを可能な限り続けていくつもりです!
 よければ来年のウディコンも、作品エントリー側としても、遊ぶ側としても、楽しんでいただけますと幸いです!
 2024-09-07 (土) web拍手 by FC2 カテゴリ: ウディタ
ウディタ 2/4


▲一番上へ戻る


Copyright © SmokingWOLF / Silver Second