横スク探索ゲームを作りたい！<1>
前回の記事を書いてからちょうど2週間が経ちました。
前まで作っていた3Dモデルをドット絵風に描画する処理は、絵が描けない&ドット絵なんて枚数書かなきゃいけないし面倒くさいという自分がドット絵風ゲームを作るためのものです。
ということで今回からは実際にゲームを作る記事も書いていこうと思います。
作りたいのは横スクの探索アドベンチャーゲーム。
ストーリー的元ネタは僕の大好きなJGバラード作の「沈んだ世界」。
ざっくり今脳内構想しているストーリーは、
『地球温暖化によって気温が上昇し人類は国を離れ野原と化した南極大陸に移住してから早何十年。調査船の一員としてかつての日本にやってきた主人公は、その地に残って細々と生活していた生存者たちと出会う。(略)一週間の調査期間のうちに主人公は一癖も二癖もある生存者たちを何人救うことができるのだろうか。』
みたいな感じです。マルチエンド対応。
ゲーム制作においてストーリーは第一目標じゃなくてモチベーションだと思っているのでまだざっくりです。最初からストーリーを求めて作っちゃうと、少人数製作及び個人製作のゲームでは挫折しがちだになると思っているので。あくまでゲームが作りたいんであって物語が作りたいんじゃないんだ僕は。
てな感じでコツコツ作っていたんですがやっとまぁ開発中の一画面見せられるかなって感じになったので、詰まったところとかのメモと一緒に載せときます。
もろクロックタワーですねはい。
後々から変えていけばいいんですという身勝手な理論をかましていきます、やっぱ既製品を参考にするのが初心者にはちょうどいいんですよね…
一応動画でも。
プレイヤーキャラの描画には前の記事で作ったドット絵描画処理をフルに使ってます。
・詰まって解決したところ備忘録
ープレイヤーの動き
移動先を指定するとキャラがそちらに向いてそれから移動。という処理です。
まずQuaternion.LookRotationを使ってプレイヤーキャラの回転と移動先の角度差を求めQuaternion.Lerpで補間。
回転が収まってきた（＝回転しきっていないまま動き出す)かどうかは前フレームとの回転の度合いを比較して、一定以下かどうかを計算し収まってきていれば移動を開始する。
現時点では移動にはVector3.SmoothDampを利用。でも動きに違和感を感じるときがままあるから変更するかもしれない。
enumで移動中、目的地点に到達、停止中のフラグを列挙しておいて、到達した瞬間かつ目的地点が調べられるオブジェクトであればオブジェクトについているメッセージ用の処理を呼ぶように。
移動先の座標については、Input.mousePositionで持ってきたマウスの位置を平行投影のカメラによるCamera.ScreenToWorldPointでワールド座標に変換し、それをさらにPixel Perfect CameraのRoundToPixelメソッドでドット近傍にスナップして使ってます。
ーUI上にマウスがいるとき、キャラが移動しないようにする
UI上を押しているのにキャラが動いてしまうのを防ごうと、マウス位置からRayを飛ばしてUIのレイヤーに当たったら…という処理を最初に書いたんですけどうまくいかず。
調べたらUIにはRayは使えないと。2D的な処理と3D的な処理を複合させるのはunity公式側の想定外なのだろうか…みんな結構やると思うんだけどなぁ。
結果、下のサイトを参考に実装しました。丸パクリです。
ーカーソルの動き
調べられるオブジェクトに近づくと、にゅっっと引き寄せられるような動きをします。
これはドット絵描画の時にも使ったレンダリングの時だけ位置を変える処理でやっています。
LateUpdate()内で現在描画しているカメラがカーソルを描画していれば位置をオブジェクトの中心にLeapし、描画が終わった直後のOnRenderObject()で本来の座標に戻す。
これだけで吸い寄せられる”ように見えます”。実際の座標的には別にオブジェクトに吸い寄せられていません。
ーカメラの使い分け
まず最初使う予定だったのはUI用の平行投影カメラとゲーム画面用の透視投影カメラの２つでそれぞれPixel Perfect Cameraをアタッチしていました。
しかし途中でテキスト文字の処理を描いたところ文字をpixelperfectにされると変だなーと思ったのでドットフォントをpixelperfectなしで表示することにしました。
参考までに
Arialで左がpixelperfectあり、右がpixelperfectなし
ちなみに自分は近年よくあるドット絵風のゲームでこういうフォント使われると萎えます。やめてほしい…
ドットフォントで左がpixelperfectあり、右がpixelperfectなし
ドットフォントでpixelperfectなしが一番きれいでいいですよね。
ちなみにフォントはここのをお借りしました。
結果、平行投影のUI用カメラ、テキスト用カメラとゲーム画面背景用の透視投影カメラの３つを使い分けてます。
あと、自作の3Dモデルドット絵描画処理は平行投影のカメラじゃないとガクつくので、キャラクタはUI用カメラのレイヤーに表示しています。
キャラの手前にモノを置きたいときは追加でカメラを作らなきゃいけないですけど…まぁそのときはそのときかな、どうせ一人で作ってるわけなので仕様変更は気軽にできますしね。
ーテキスト表示
各オブジェクトには調べられた際のテキストを保持するスクリプトをアタッチしておきます。
オブジェクトをゲーム画面で調べると、シングルトンのText_Managerクラスに飛ばされてそこで各オブジェクトのテキストを処理します。
まずはstring.splitを用いて改行コードで文字列を分割し、改行ごとに配列に格納します。
便利ですねこのstring.splitメソッド、代入して欲しい配列と文字列と分割する文字コードを入れるだけで各配列の要素に振り分けてくれるとは思ってなくてかなり処理が楽に済みました。大学の課題ではC言語使って何度もループに飛ばしてやった記憶…C#様々ですね。
配列に文字列を格納出来たら、あとは１要素ずつ表示するだけです。簡単！
とりあえず表示側は実装できたので、あとは各オブジェクトが持つテキストについてこういうフラグが立っていたら別のテキストを送って…みたいな処理を書いてあげればいいだけになりました。
とはいえこれがまだ思いつかない。
ある程度進捗溜まったら更新しますのでそれじゃまた～
Unityで3Dモデルをドット絵風に描画したい<4>
さて暫定最終回やっていきましょう。
下の画像は記事のサムネ用
今回はずばりドット絵における回転です。
前回のラストでも言及しましたが、ドット絵を用いていた昔のゲームにおいてのオブジェクトの回転とは角度ごとに新規でドット絵を描くことを意味します。
それがスーファミを含むいわゆる16bitマシンとなると、回転をハードウェア側で行ってくれるので新規でドット絵を描く必要がなくなりました。
とはいえキャラ自体は奥行きのないドット絵なので、例えば画面内で「右向きの身体を左向きにする」といったアニメーションを動かしたいときにはハードウェア側の回転機能は何ら意味がありません。そういう処理をしたいとなって生まれたのがポリゴンを使ったゲームですからね。
つまり、3Dモデルのドット絵風描画にとって、回転とはポリゴン的ななめらかな回転ではなくドット絵的な手書きならではのガクガクとした回転を意味します。
今回はそれに手を付けていきましょう。
・ドット絵的回転制御…階調化
考え方は簡単です。
「描画時にオブジェクトの角度を階調化し、描画終了後に本来の角度に戻す」、これに尽きます。
直観的に扱いやすいように角度を度数法に直し、それから階調化します。
階調化の角度をn度ずつとしたときに(n*k-n/2)から(n*k+n/2)までの間に属するオブジェクトの角度を(n*k)に直すようにしましょう。
四捨五入改め(n-n/2)捨(n+n/2)入ですね。
この処理を描画の直前に行います。
描画の直前＝プレイする人や物理演算の影響が終わった後、と考えられるのでここではLateUpdate内で行います。
その2でやったチラ付き防止のと考え方は同じです。
・ドット絵的回転制御…値戻し
自分がひたすらに行き詰ったのはここです。
値を戻すといってもどうやればいいんだろうと。
素直に考えると、プレイする人による操作や物理演算が始まる前。つまりUpdateやFixedUpdateの前に実行したいです。
しかしUnityにはそこに動作するメソッドがありません。
そこでLateUpdateの後かつ描画自体が終わった後、1フレームの最後の最後に実行されるOnRenderObjectの中で値戻しをすることにしました。
これはカメラのレンダリングが終わったら実行されるメソッドで、確実に描画後のタイミングに実行されます。
しかしここで問題が。
上手く動かないんです。
それも実行する度にバグの挙動が変わってそもそもキャラが回転しなくなったり、動くけども階調化されなかったり、Scene画面ではうまく行ってるのにGame画面ではうまくいかなかったり。
頭の中がハテナでいっぱいでここで3日ほど停滞しました。
・「描画時だけ適応したい処理」の実装方法とは
結果、OnRenderObjectの挙動に原因がありました。
OnRenderObjectはカメラごとに描画されるたびに呼び出されます。
自分はオブジェクトと背景でカメラを分けたいなと思っていたのでプロジェクト内に2つカメラを置いていました。
そのせいで各カメラの描画される順番の前後によってバグが発生していました。
それさえわかってしまえば簡単で、こんなコードにしてみました。
void OnRenderObject() {
if (((Camera.current.cullingMask & (1 << transform.gameObject.layer))==1)
&&!(Camera.current == UnityEditor.SceneView.lastActiveSceneView.camera)){
//ここで描画時の回転から本来の回転に戻す
}
}
Camera.current.cullingMaskはOnRenderObject()を呼び出しているカメラが描画するレイヤ、transform.gameObject.layerはオブジェクトの属するレイヤです。
ビット演算をしてカリングマスクで指定された描画レイヤーの中にオブジェクトのレイヤーが含まれているかを検出します。
そしてもう一つ、実はこのOnRenderObjectはゲーム画面ではなくシーン画面の描画でも呼び出されてしまいます。
なのでシーン画面とゲーム画面を両方出しながらデバッグ作業をしているとバグるんです。シーン画面ではうまく行ってるのに～っていうのはそれが原因でした。
そこで!(Camera.current == UnityEditor.SceneView.lastActiveSceneView.camera)という文でOnRenderObjectを呼び出しているカメラがシーン画面の描画用カメラでないことを確認しています。UnityEditor.SceneView.lastActiveSceneView.cameraはシーン画面描画用カメラそのものらしいです。
このif文によって、オブジェクトの描画が終了した瞬間にのみ処理を行うことができます。
これで回転制御処理も完成です！無事回転もコマ落ちした雰囲気が出せました。
ついでにこれまでの結果も合わせてみてみましょう。
左から、
ただPixelPerfectCameraを適応しただけ
PixelPerfectCameraと座標のドットスナップ、アニメーションのコマ落ちを適応
上にさらに回転制御もした完成形
となっています。
ということでドット絵描画シリーズも終わりです。(何か思いついたことがあれば続くかもしれませんが。)
クロックタワーとかプリンスオブペルシャくらいのドット絵感になればいいかなと思って始めたので個人的にはとりあえず満足のいくものができました。
なにも考えずPixelPerfectCameraとこのスクリプトをアタッチすればいい見た目になるのでこれからのゲーム作りが捗ればいいなと思います。
様々なサイトなどを参照しながら書いたのでコード全体については公開しませんのでご了承ください。
<追記>
カメラが透視投影のとき、うまく動いてないことに気が付いたので多分続きますはい
Unityで3Dモデルをドット絵風に描画したい<3>
tkg-lag.hatenablog.com
まずは前回の成果から
今回からきちんと動画を貼ることにしました、なぜ標準で動画が使えないんだはてなブログ
前回はとりあえず静止画としてはいい感じだけど動かすとちらつくよねってのを直して上の動画みたいな感じになりました。
今回はアニメーションがぬるぬる過ぎてレトロゲーっぽくない！ってとこを直していきます。
・まずはアニメーションをコマ送りに
｢Unity コマ抜き｣とかで調べるとまず出てくるのは多分3Dアニメ界隈の話です。
3Dでのアニメを手書き作画っぽく見せるためにわざとキャラの動きの目立つところのみを残してコマを抜いていってカクつかせる、って手法をリミテッドアニメーションというらしいです。
そっち方面でのUnity的解決策だとそもそもアニメーション自体を改変したり、アニメーションのコマを残したい部分の秒数を一個一個手打ちして処理するってのが多かったんです、けどそれはちょっとなぁと。
そもそもこのドット絵描画のコンセプトは｢ドット絵描くのがめんどくさいから3Dモデルそのままぶち込めばドット絵っぽくなってほしい｣っていうのでしたから面倒なのは避けたいです。
もっと言えば3Dアニメのようにきれいになる必要は無いんです。それっぽいだけでいいので。
そこでここでは単純にAmimatorコンポーネントを一定周期でオンオフする手法を取りました。
Amimatorコンポーネントをアニメーションの途中でオフにすると、キャラはオフにされた時点の動きで静止します。
オンに戻すとそのオフにされたところからアニメーションが再開されます。
つまりAmimatorのオンオフを繰り返せばいわゆるコマ送り状態でキャラの動きが描画されます。
ちなみに今回からUnityChanではなくこちらのモデルを利用します。
理由はキャラのディティールが細かくないほうがドット絵向きだから、UnityChanは細かすぎるねん
まだただ描画が遅れてる感じですよね。
そりゃそうです、Animatorをオフにすると動きが一時停止、オンにするとそこから再開されるんですから。
やりたいのは描画速度はそのままでコマが抜かれてるような処理です。
・アニメーションのコマ抜き処理完成へ
じゃあどうすればいいのかといえば、Animatorの再生速度を上げればいいです。
推測ですが、Animatorの再生速度を上げる処理自体がコマ抜きに近い処理がされているのではないかと思います。
つまり速度1のとき1→2→3→4→5→6→…と再生されるところを速度2だと1→3→5→…と処理されるということです。
この再生速度の処理と先ほどのコマ送りを利用すれば1→(一時停止)→2→(一時停止)→3→(一時停止)→…というコマ送り状態から、1→(一時停止)→10→(一時停止)→20→(一時停止)→…という理想のコマ抜きができるはずです！
ということでやってみました。
オンオフの頻度と速度は同じ値にしています、他の値考えるのめんどくさかったので。
どうでしょう、個人的にはまぁ良い感じなんじゃないかと思います。
あと、コマ抜きしてるせいで描画頻度がn秒間隔の時、例えば歩き→歩行のアニメ遷移が最大n秒遅延してしまい、移動キーを入力した瞬間は地面を滑ってるようになってしまいますのでついでにそれも直しています。
すぐ遷移して欲しいアニメーションのリストをインスペクタから作っておいて、前フレームと今のフレームでのアニメ―ションを取得して遷移が発生したときにはカウンタをリセットすることですぐアニメーションが始まるようにしています。
ということで前回と今回の成果をまとめて見てみましょう。
左から、
ただのドット描画→描画位置のドットスナップ→スナップ＆アニメーションコマ抜き
となっています。
いい感じじゃないかなぁ？？？自分で見てるとよくわかんなくなってきました。
あと追加する要素があるとしたら回転のコマ抜きですかね。
スーファミをイメージすると、画面方向に垂直な回転(Unityで言うところのZ軸回転)は有名な｢拡大縮小回転｣を使ってハードウェア側で処理できるのでドット絵は追加で不要、つまりぬるぬる動いてもらって問題ないんです。
でも画面方向じゃないX軸Y軸回転は｢拡大縮小回転｣の対象外なので(スーパーFXチップの力でも借りない限り)逐一ドット絵を描いていたはずです。
つまり、その方向の回転についてはコマを抜いてあげたほうがドット絵としてのリアリティが増すんじゃないかなと考えてます。
どう処理するかはまだ思いついてないですけど、ドット座標にスナップしてあげたときと同様に取れる角度を離散化してあげればできるかなとふわっと考えてます。
というわけで多分次回最終回…？？(他に何か思いつかない限り)
Unityで3Dモデルをドット絵風に描画したい<2>
tkg-lag.hatenablog.com前回の続きから
とりあえずここまでの結果がこれ
いい風に見えるよね
見えるでしょ
でも動きで見ると変なんですよね
わかりますかこのガビガビ感というかゆらゆら感
とても一枚絵な感じがしませんよね、これじゃだめなのだ。
・一枚絵っぽくするためのチラ付き防止
なぜガビガビになっているかというと描画はドット単位なのにオブジェクトの座標は小数点までなめらかに動いちゃうから、ドットとドットの間でゆらゆらしちゃうんですね。
つまるところオブジェクトの座標をドットごとにスナップしてあげればいいんです。
ドットごとにスナップするためには画面内のドット数と実際の画面の画素数の割合を出してあげて…うーん…と一週間くらい苦戦したんですけどもっと簡潔にやる方法がありました。
PixelPerfectCameraスプリクト内のRoundToPixelメソッドです。
これは引数にワールド座標を入れてあげると一番近いドットの座標を返してくれる、まさにこの作業にうってつけの関数。ありがたく使わせてもらいましょう。
ということでこのチラ付き処理に必要なのはたったの一行。
transform.position = pixel_camera.RoundToPixel(transform.position);
pixel_cameraはカメラのPixelPerfectCameraをgetcomponentして代入しておきましょう、これで終わりです。
これを物理処理やらなんやらが終わった後に処理されるLateUpdate内で実行してあげればオブジェクトの座標がドットにスナップされて綺麗に表示されます。
結果がこれです。
どうでしょう、一枚絵のスプライトっぽく見えますかね。
あとはこのコードをそれぞれのオブジェクトにアタッチしてあげればOKです。
オブジェクトをカメラに追従したいときとかはカメラ側にもアタッチしてあげると綺麗に表示されるのでチラ付き問題はこれで解決です。
スクリプトのオンオフでチラ付きが改善されるのわかりますかね？
とりあえず今回はここまで。今はコマ落ち処理をどうやろうか悩み中です。
Unityで3Dモデルをドット絵風に描画したい<1>
作るといってもとりあえず現状作りかけのものを紹介する
基本的な方針は下の方を参考にした
mizuooon.hatenablog.jp
とりあえず当初欲しいなとおもった機能
シェーダを書いて解決した要素
・リアルになりすぎないイラスト的な影とハイライトの付き方
・モデル全体の色数の制限
・輪郭線の描画
スプリクトを書いて解決した要素
・動きのコマ落ち(昔のゲームのドット絵は1コマ1コマ手作業で描いていたはずなので、その雰囲気を再現したい)
・一枚絵らしく見せるために動く際のチラつきを減らす(上記サイトの”その２”を見てくれるとわかる)
その他
・ドット絵らしいピクセル感のある描画
・モデルはドット絵化、背景はそのまま、みたいに適応するものしないものを選べるようにしたい
現状報告その1
順を追いながら説明していく
・ドット絵らしいピクセル感のある描画
→unityの公式AssetのPixelPerfectCameraを使う
これはカメラに映る画面全体の解像度と、1m当たりに詰め込むピクセル数を設定してあげると勝手に映っているものの描画をピクセルパーフェクトにしてくれるasset。
ポストエフェクトで自作できる気もするけどとにかく手軽なので導入。
公式の例だと2Dのスプライトとかに使っている例しか出てこないけど普通に画面全体の描写に適応されるので3Dモデルでも関係なくピクセル化できる。
他に考えたのは
シェーダ内でピクセル化
→輪郭線がドット化できないから没
描画結果をレンダーテクスチャに書き出して、板ポリゴンに張り付けた上でピクセル化
→めんどくさい、位置の調節がむずかしい、重いの三重苦で没
下はただのStandardshaderを適応した球のモデルをPixelPerfectCameraで描画してみた図。
まぁドットではあるけどこれじゃないよね。
・リアルになりすぎないイラスト的な影とハイライトの付き方
影は単純に濃さを可変できるようにした。
頂点シェーダ内の式はこんな感じ。
_NomalColorはモデルのベースとなる色、_GradationColorは影の強さを指すfloatの変数。
float l = dot(normalize(o.lightDir), v.normal) * 0.5 + 0.5;
o.shadecolor = lerp(_NomalColor* _GradationColor, _NomalColor, l * l);
法線と光の方向の内積から影の付く度合いlを計算し、lerpで影が付く部分は_NomalColor* _GradationColorで濃いベース色に、つきにくい部分は_NomalColorで着色するようにしている。
lを二乗している理由は単純に影の付き方を強めるため。ただのlでは影が弱く感じたため。
ハイライトは先述のサイトを参考に環境マップで実装した。
上の画像の明るいところのみ加算してやると下のようになる。
これは下のコードのようになる。
fixed4 col = (rgb2hsv(tex2D(_MatCap, i.uv)).z < _CapPower) ?(i.shadecolor* _BlendPower + tex2D(_MainTex, i.uvtex)*(1- _BlendPower)): (tex2D(_MatCap, i.uv) * _BlendPower + tex2D(_MainTex, i.uvtex) * (1 - _BlendPower)));
筆者が三項演算子好きが故に見づらくなってしまっているのでif文に描き直すと、
if(rgb2hsv(tex2D(_MatCap, i.uv)).z < _CapPower){
i.shadecolor* _BlendPower
+
tex2D(_MainTex, i.uvtex)*(1- _BlendPower);
}
else{
tex2D(_MatCap, i.uv) * _BlendPower
+
tex2D(_MainTex, i.uvtex) * (1 - _BlendPower);
}
_MainTexはモデルのテクスチャ、_MatCapが先ほどのモノクロの画像を指すテクスチャ。
rgb2hsvはrgb(赤緑青)情報からhsv(色相、彩度、明度)に色味を変換する関数。それのzはつまり明度であるので、環境テクスチャの明度が_CapPowerより小さい(＝暗い部分)場合は前者に、大きい(＝明るい部分)は後者に分岐する。
テクスチャを_BlendPowerで弱めたものと、前者では先ほど説明した式で算出した影を、後者では環境テクスチャをハイライトとしてそれぞれ加算している。
ここまでやった結果をピクセル化すると以下のようになる。
ハイライト様々といった感じ、でもまだレトロゲーっぽくはないかな。
・モデル全体の色数の制限
色数の制限というか、減色処理といった感じ。
ホントは使える色をパレットで指定して～とかやったほうがそれっぽくなるんだろうけどそこまでの技術はないのでただ色を階調化してあげる。
fixed4 posterize(fixed4 color) {
float4 tmp = (_GradationNum == 0 ?
color
: (floor(color/ _GradationNum) * (_GradationNum))
);
return tmp;
}
与えられた色を階調化する関数、これは簡単なので三項演算子のまま説明しちゃう。
_GradationNumは減色後の色数。これが0の時は与えられた色をそのまま返す。
他の場合はよく見る式を通して階調化。シンプル。
_GradationNumの値を変えれば減色の数も変わるので扱いやすい。
これに先ほどの影とハイライト、及びピクセル化をすると下のように。
だいぶそれらしくなってきたのではないだろうか。この調子で行こう。
・輪郭線の描画
これがだいぶ悩んだ、ただ線を膨らませて二度描画だとエッジが欠けちゃって綺麗にならない。
結果既存の手法を丸パクリさせてもらうことに。
こちらの記事を参考にしたので内容は省略。これまでの結果はこうなった。
完全な円になっていないのはさておきいい感じではなかろうか。
他の例も一応挙げとく。
自作シェーダでの表示なのでUnityChanシェーダーとは色味がかなり違うけど、もうちょっとパラメータいじれば寄せれはすると思うがドット化するのであんま関係ないかな。目とかはつぶれちゃうので非表示にしてる。
とりあえず今回はここまで、続きは後で気が向いたら書きます。
