【ウディタ】初心者向けテクニック3（当たり判定）
1.当たり判定
キャラが敵と接触している、
あるいはキャラに攻撃がヒットしている、
などのいわゆる当たり判定は
ゲームではとても大事な要素ですね。
ウディタの場合、マップイベントでは
「プレイヤー接触」
「イベント接触」
を選ぶことができます（図1-1）。
ですが、今回はキャラクターイベントを使わず、
ピクチャによる当たり判定を説明します。
2.当たり判定の考え方
シューティングで考えてみましょう。
丸い自機に、同じく丸い攻撃がヒットしたとします（図2-1）。
この図を見ても分かる通り、
自機と攻撃がちょうど接触する距離というのは、
自機の中心と攻撃の中心までの距離が
互いの半径の合計と同じになる時
なのです（図2-2）。
つまり自機が攻撃と接触しているかどうかは、
下記の式が成立するかどうかで判定できるんですね。
(自機の半径 + 攻撃の半径) >= 自機の中心～攻撃の中心までの距離
「じゃあもし自機の半径が10で、攻撃の半径が20なら……
自機の半径と攻撃の半径の合計は30で、それから……
あれ、自機の中心から攻撃の中心までってどうやって出すんだ？」
3.三平方の定理
三平方の定理というのは、直角三角形に対して
下記の式が成り立つという定理です。
辺（斜めの部分）の二乗 = 底辺の二乗 + 高さの二乗
実は自機と攻撃の中心座標を結び付けると、
ひとつの三角形が姿を現します。
この三角形に三平方の定理をあてはめると、 下記のようになります。
（自機の中心～敵の中心までの距離）の二乗 =
（攻撃x座標 - 自機x座標）の二乗 + （攻撃y座標 - 自機y座標）の二乗
そういえば、自機の中心～敵の中心までの距離が
自機の半径 + 攻撃の半径とイコールになるとちょうど接触しているんでした。
つまり下記の式が成り立つ時、
ちょうど自機と攻撃が接触していることになります。
（自機の半径 + 攻撃の半径）の二乗 =
（攻撃x座標 - 自機x座標）の二乗 + （攻撃y座標 - 自機y座標）の二乗
4.ここだけ覚えよう
何か定理とかめんどくせーし話なげえんだよと思う方は
ここだけ覚えておきましょう。
（自機の半径 + 攻撃の半径）の二乗 >=
（攻撃x座標 - 自機x座標）の二乗 + （攻撃y座標 - 自機y座標）の二乗
これが当たり判定の条件式です。
成立する時は接触していることになるし、
成立しない時は接触していないことになります。
5.当たり判定（ウディタ）
では、自機の座標が（60, 60）で
攻撃の座標が（70, 80）の場合を考えてみましょう。
自機の半径は5、攻撃の半径は15とします。
（5 + 15)の二乗 >= (70 - 60）の二乗 + (80 - 60）の二乗
↓
20 * 20 >= 10 * 10 + 20 * 20
↓
400 >= 100 + 400
どうやら接触していないようです。
実際のウディタ画面で見てみても
接触していないのがわかりますね（図5-1）。
では、攻撃の座標が（60, 80）の場合を考えてみましょう。
（5 + 15)の二乗 >= (60 - 60）の二乗 + (80 - 60）の二乗
↓
20 * 20 >= 0 * 0 + 20 * 20
↓
400 >= 0 + 400
ちょうどぴったし接触しているようです。
実際のウディタ画面で見てみても
接触しているのがわかりますね（図5-2）。
形が複雑になるともう少し色々考えないとだめですが、
円形の当たり判定であればこんな感じで判定出来るので、
シューティングゲームなどに活かすことが出来そうですね。
【ウディタ】初心者向けテクニック2（二点間の角度の算出）
1.二点間の角度の算出
座標（x1, y1）に対する座標（x2, y2）の角度を算出する。
……と表記するとすごーく面倒な気がしてしまいますね。
キャラに置き換えてみましょう。
プレイヤーキャラから見て敵はどの角度にいるかを算出する。
どうでしょう、さっきよりは興味を持てる感じになっているでしょうか？
2.難しく考えなくてもOK
例の如くウディタには角度を算出する機能が既に備わっています（図2-1）。
難しいことは考えず、
「手順通りにやると相手のいる角度がわかるらしいぞ」
ぐらいの軽い気持ちでやっていきましょう。
3.二点間の角度の算出（ウディタ）
ウディタの場合、相手と自分の座標の差分を渡すだけで
角度を算出してくれます。
例えばキャラが座標（10, 10）にいて、
敵が座標（20, 30）にいるとしたら、
差分は下記の通りになります。
差分x座標（10） = 敵のx座標（20） - キャラのx座標（10）
差分y座標（20） = 敵のy座標（30） - キャラのy座標（10）
差分y座標（20） *= - 1
これをウディタの算出機能にそれぞれ渡せばOKです（実例は図3-1）。
角度 = ウディタの角度算出機能（差分x座標, 差分y座標）
y座標に-1を掛けているのは、ウディタの仕様上、
上がマイナスで下がプラスになるためです。
※ウディタの場合は画面最上部がy座標0で
下にいくほどどんどんy座標が増えていくので、
グラフなどのy座標とは考え方が真逆になる。
ここも混乱しやすいところだと思うので、
そういうもんなんだ理解でもOKです。
また、ウディタ側に記載もある通り、
算出された角度は掛ける10された値になっているので、
本来の角度を算出する場合は割る10する必要がある点に注意です。
が、ウディタは角度を常に掛ける10の値で扱う仕様であるため、
ピクチャなどに利用する場合はそのままでもよさそうです。
4.サンプルコモン
画面中央から見て0度～90度までの角度の範囲に
マウスカーソルがある場合に〇を表示、
ない場合は×を表示するサンプルコモンを置いておきます。
https://kazaeditor.net/asset/Tech02_SampleCommon.zip
プレイヤー機に向かって攻撃を放つ敵キャラの実装や
キャラの視野に敵キャラがいるかの判定など、
色んなことに応用出来そうですね。
【新作公開】マサオさがし
というわけで、第11回ウディコンにエントリーしました。
No.20「マサオさがし」です。
本作は例の如くソローさんとの共同制作で、ソローさんの
シリーズキャラクター「マサオくん」を主人公にした間違い探しゲームです。
3分～10分前後で遊べるミニゲームとなっていますので、
お気軽にプレイしてみてください。
クリア後にはオンラインランキングもあります。
▼DLリンク
WOLF RPGエディター コンテスト 応募作品
マサオくんの顔がいい感じにこのゲームと相性がよくって、
じっと見てるとどれも間違っているような気になってくるんですよね（ゲシュタルト崩壊）。
あと謎のゾーンに入ると、
難しいやつも何故か連続で気づける時があります。
謎です（不思議）。
今回は去年の反省を踏まえ、開発期間には余裕を持たせていたため、
他にもちょっとだけお遊び要素を入れることができました。
そんなにがっつり長時間やるゲームではないので（目も疲れますし）、
気軽にのんびり遊んでもらえれば幸いです。
【ウディタ】初心者向けテクニック1（円座標の算出）
1.円座標の算出
半径（r）の長さが決まっている円の座標計算を行う場合、
三角関数を用いることで、
任意の角度（Θ）のx,y座標を算出することができます。
【x座標の算出】
x = r * cosΘ
【y座標の算出】
y = r * sinΘ
2.sinとかcosとか分からなくてもOK
sinとかcosとかチンプンカンプンという人もいると思いますが、
ウディタの場合は角度からsin,cosを算出する機能が備わっているため（図2-1）、
難しいことを考えなくてもOKです。
「手順通りに計算すると円周上の座標を計算できるらしいぞ」
ぐらいの軽い気持ちで使ってみましょう。
3.円座標の算出（ウディタ）
先程の公式に合わせて、
半径rと角度Θにおける円周上の座標算出を
ウディタで行う場合は下記のようになります（実例は図3-1）。
【x座標の算出】
cosΘ = ウディタのcos算出機能 ( Θ * 10 )
x = r * cosΘ
x /= 1000
【y座標の算出】
sinΘ = ウディタのsin算出機能 ( Θ * 10 )
y = r * sinΘ
y /= 1000
ウディタ側に記載もある通り、
sin・cosの算出に用いる角度は掛ける10してあげる必要があるのと、
算出されたsin・cosは掛ける1000の値になっているため、
最後に割る1000してあげる必要がある点に注意ですね。
4.サンプルコモン
画面中央からランダムの角度に向かって
ピクチャが飛んでいくサンプルコモンを置いておきます。
https://kazaeditor.net/asset/Tech01_SampleCommon.zip
円形の座標が算出できると、
リングコマンドの実装なんかもできそうですね。
【開発記】マサオのジャンピングレース
1.制作ゲームについて
先週、初めてUnityで3Dのゲームを制作しました。
共同制作をしたSOrowさんのシリーズキャラクター、
マサオくんを主役としたアクションミニゲームです。
シンプルな操作で5～10分で遊べますので、
よかったらプレイしてみてください。
オンラインランキングへの登録お待ちしてます！('◇')ゞ
【DL版】 www.freem.ne.jp
【ブラウザ版】 unityroom.com
2.Unityで作ってみた感触
率直なことを言えば、なかなか苦労しました。
これまでは3D座標の考え方がまるでなかったので、
最初はVector3クラス自体が「なんぞこれ」といった感じ。
また、慣れないうちはMonoBehaviourを継承した各オブジェクトが持つ
Updateメソッドが毎フレーム呼ばれるという仕様が、
組み方を間違えると逆に求めている動作の障害になったり……。
これまで使ってきたツールなら簡単にぱぱっと出来ることが、
Unityだと妙な回り道をしないとさくっと出来なかったり……。
ただ、逆にUnityであれば超簡単に出来ることも多々あり、
マルチプラットフォームである点や便利なライブラリを活用出来る点など、
Unityならではの恩恵と勝手の違いをじっくりと感じた開発でした。
3.苦労した点
1.データの管理方法
これまではツール側に標準でDB機能がついていたので、
データ管理などは特に迷うことがなかったのですが、
Unityにはそもそもそういうものが存在しない。
使い捨てだけどシーンをまたいだ情報を保存したい時に、
いちいちPlayerPrefabとか使いたくないなあとか
Staticクラスでもいけるけど視覚的に設定したいなあと思い、
調べてみたらScriptableObjectなる便利な機能があったので解決。
シングルトンとの組み合わせは非常に便利でした。
2.ピクチャの状態変更
これまで使ってきたツールであれば、
移動や透明度の変更などがコマンドで手軽に出来たのですが、
Unityではアニメーションを活用する形になります。
ただ、最初はアニメーションの作り方もよくわからなかったので、
ピクチャを透明度0から255（Unityの場合は0～1.0）に60fかけて
表示したいだけなんだけどなあ、さくっとできないかなあ……
なんて不満を持ってました。
3.セーブロード
そんなものはUnityにはなーい！ 自分で作るのじゃ！
でもPlayerPrefabを使えば簡単なデータはセーブ・ロード出来るし、
今回はそれでいっか～、なんて思っていたのですが、
テスターさんがUnity経験者だったため、
ハイスコアを改ざん出来てしまうという問題を教えてくれました。
／(^o^)＼ﾅﾝﾃｺｯﾀｲ
仕方がなくJSONと暗号化を用いて
きちんとセーブデータを作成するようにしました。
PlayerPrefabに重要な情報は保存しちゃダメ、ゼッタイ。
4.画面を真っ暗にする
ひじょーに難しかった。
ライトの向きや強さだけを考えればよい訳ではなく、
skyboxの設定やオブジェクトのシェーダーにも深い関わりがあり、
調べた通りにやっても真っ暗にはならなかったり
影響を受けないオブジェクトが存在したりして、
オープニングの冒頭部分だけで無駄に時間かかってたりします。
今回はskyboxをスクリプト側で変更したり
あたかも照らされた風にオブジェクトをアクティブにしたりして
わりと強引に演出しています。
しかしオープニングはオブジェクト生成やカメラワークなど、
Unityならではの演出が出来たので作っててとても楽しかったです。
お気に入り！
4.楽だった点
1.差分管理
パッケージ出力で更新点だけを簡単に差分出力出来るので、
共同制作者間のデータ受け渡しは非常にスムーズに出来ました。
2.Prefabという概念
変更を一括適用出来るというのはやはり作業負荷を大きく減らしますね。
3.ListやLinqが使える
C#サイコー！ヽ( ´ｰ`)ﾉ
4.VisualStudioで簡単にデバッグできる
VisualStudioサイコー！ヽ( ´ｰ`)ﾉ
※Microsoftの回し者ではないです
5.今後について
今回は3Dで作ったものの、今後も3Dで作るかどうかは微妙なところですね。
3Dでもっとしっかりした物を作ろうとした場合、
素材不足になるのは目に見えているので……。
また、Unityというツール自体が、足りないもの、自分で作ると大変な部分を
有料Assetにて補っていくことで個人でもクオリティの高いものを作れるツール、
という印象があるので、もしやるなら有料Assetを購入する必要があるかなと。
でないと超膨大な時間を浪費することになってしまいそう。
でもそこまでいくともうフリーゲームではないよなあという思いもあり、
どのツールでどのぐらいの規模のゲームをどこまでコストかけてやるか、
という点においてはものすごーく思案中です。
でもまあ今回は3Dで作れて楽しかったです。
モデルデータを作ってくれたSOrowさんにはいつもながら感謝です。
そしてプレイしてくださった方々にも毎度感謝です。
未プレイの方はよかったらプレイしてみてください。
それでは。
