2016年2月26日金曜日

アクションRTS開発日誌とアニメーション雑記 その2

とりあえずもう2月も残すところあと4日 営業日的には2日。

ゲーム開発の進捗的には

1、ステートマシンを使ったAIによる 味方ユニットと敵ユニットの制御実装 1体づつ完了
2、ヒットの判定、ステートマシンをインターフェイス継承で宣言型統一、
その時のダメージ送信処理実装完了
3、サーチエリア(索敵)→同様の取得 またレイヤーわけ
そんでもって敵と味方でステートに使うEnumとステート数を分けることを決意
アップデートが軽くなるからスクリプト増えるのはもういいや。
別にキャラにつくスクリプトは増えないし・・・・。

またサーチエリアと連動して味方ユニットの状況によるステート切り替えを少しシビアに、
まだ単調なキャラクターなので8ステートほどで、管理はまだ大丈夫だけど、
ちょっと複雑になってきた。エラー処理があっちこっちとんでやばいかも

ボスなどはHPに応じてステート変化と自分の持つスキルを最初になにかみてから、
Random関数とかで発生頻度の乱数化しようとおもってたけど、個別にすることを決意。

正直スキル数もバラバラだし HP残量に応じて行動かえたいのでステータスが20を超えそう。
これは正直 噂の ビヘイビアツリー に移行したほうがいいのだろうか・・・・。

Unityで開発してるけど、アンリアルエンジンはブループリントでしかもそれがビヘイビアツリーということらしい。

一瞬ふらふらと行きかけたけど よくよく触ってみると自分のしたい内容を実装しようとすると、
C++やらないといけない。

業務ではMayaでPythonを自宅ではC#でUnityをそれに加えてC++は正直キャパオーバーだと思うので、やっぱり手を出さないよ。

ごめんねアンリアル!

とくにアンリアルにする決定打が今のところないんだよなぁ。
結局ゲームエンジンによってできることが変わるわけじゃないし。

シェーダーも自分でかけるしね。

開発日誌はこのへんで。



さてアニメーション。

開発日誌を(不定期)書き始めたおかげで、
色々とまたブログを有効活用していこうと思っている。

今年は自分の中でなにか覚醒する年なのかいろいろたぎってる。
というか去年一年で 相当な挫折というか無気力感みたいなものを味わい、
年末付近というか10月ごろからいろいろ心が折れてたんだけど、そこでなにもしなかった
反動かも。


☆キーの管理方法


2年ほど前からなのだけど僕はある種の法則に従ってキーを管理するようになった。

その管理方法というのが結構気に入っていて、名前もつけてしまった。


その名も「3つうち」。

映像系とかだとあまり通用しないかもしれない。
ゲームでもまぁ限定的なんだけどやろうと思えばできるのかな。

3つうちの特徴その1:


主要キー(特にダウンとアップ)を3つに分解する。


使える状況例:


どういうことかというと、
まずブロッキングを行う際にアップダウンなど主要キーを打つ。

仮アップ納品できる案件なら提出!

詰めてええで!っていわれたらつめはじめるときに
ポーズ間のタイミングやらインパクトやらをかえないようにしたい!
けど、連動だったりフォロースルーなども加えたい(のこしね)!

しかしながらのこしをいれようとしたりしたときの質量感だったり、
ポーズによっては短絡的にならないようにするには結構ポーズトゥのキー以外に
キーが必要になったり、1Fごとに打つのはやなのでキーをずらしたりすることになりがち・・・。

リグが少ないとなんとかなるんだけど、リグの数が多いと正直本来の緩急を
ブロッキングしてた頃の感じで(つまりは完全なポーズトゥで)管理できないんですよね。

(リアルな動き求められるときは特に。 バラバラ感がでるのと実際キーがばらけているのは
全く関係がないしね)

けどポーズトゥで作ると60fpsなんか顕著なんだけど正直キー揃えてより細かくなりがちだし、そこまで細かくうたなくていいところにまで影響するし邪魔になってくる。
かといってずらすとわっけわからんくなるからずらしたくないけど(以下ループ)

とか個人的にキーずらしをあまりいれたくない派としては(後々修正の時しんどいから)
そうそうになんか解決策ないかー!? となる状況があるとします。


使える解決:


そんなときにずらすという発想から もはやポーズを”前後”に増やすという発想に変えます。

そして増やすときには 必ず全部にキーを打つ(つまりポーズトゥを崩さない)

これが3つうちのキモです。

ずらしたい~あぁあああああああああ!!!!(以下略

の部分において 遅らせたい、ずらしたい分だけ良いと思う間隔分前後に
2つ、すべてのリグへキーを追加します。(ポーズを追加します)

そこから前動作時に本体よりも先行するものを 前に打ったポーズでアップ(またはダウン)に
中間で主要部位のキーポーズ、
後のポーズで遅れる(のこる)部位のキーポーズを

それぞれずらした状態にポーズを作成します。

はじめの主要キーのフレーム+ 前後 1つずつ(のこしやツメタメ用)だけで
ポーズで作る+調整するようにするわけです。

*注意

足りないってことはないと思うんです。
むしろ”ポーズが足りない” はわかるけど”ずらすためのキーが足りない”なら
実はポーズ不足じゃないか? ってなのも確認ができます。(白目


まぁここでポーズ不足に気が付いたらそもそも3つうちじゃ解決できないんですけども・・・。


逆にポーズ大杉(最大フレーム数敵にこのポーズ省略しないと仕様超える)とかにも、
早めに気が付けるかも。 キーもずれてないしまとめて消せてお得。

とはいえあくまで”ずらしたいけどキーが1Fずつずれるとかバラバラになるのがいや”、
という時の解決方法の一種だと思っています。

☆考え方


この三つうちというのは ”前動作” ”本動作” ”後動作” という
ひとつの動作を切り分けるキーの発想を、もっと細かいものにも当てはめたらどうなるか。
という発想から実践しています。

静止のところなら静止入る前と静止中 静止を出た後 などに主要キーがあるはず。
といったセオリー通り作ってるという前提はもちろん必要です。

さらにMayaだとこの前後のキーはブレイクダウンでうつとキーの色も変わってだ・・・・。

実際ブレイクダウンだし。

間隔調整系の修正もこれでまとめてキーを移動すればいいだけなので、
そこそこ長尺でもあとから修正が楽になるというわけだわー。

人によって管理の仕方は違うので、キーずらし慣れてる人には
おすすめしない・・・かなぁ・・・。

2016年2月13日土曜日

アクションゲーム制作 記録 その1

すごく久々の更新

今年の頭(2016初頭)から前々からアクションゲーム制作をやりたいなぁと
心におもっていただけだったのをついに行動に移すことにした。

企画内容は

・アクション要素がある → プレイヤーを自分で操作
・合戦っぽい要素がある → 大勢がぶつかり合う
・シュミレーションもちょっと混ぜるか → 味方のユニットをある程度指揮できる
・でもシンプルなものがいい → 操作は簡単
・PC向け

みたいなぼんやりとしたところから初めて近しい機能や遊びをもった
ゲームのプレイ感やよいところわるいところをまとめて・・・・
ベースにするゲーム性も目標をブラさないようにさだめ・・・

仕様書も作成してC#も勉強しつつ・・・

ついに仕様書は エクセル15ページに及ぶ物量になって、
キャラデザを知り合いの方に相談してやってもらえることになったので、
そちらの資料も作成して・・・

気が付けば1月が終わり、2月も半ば・・・

ちょっと後々のメモというか今後に生かせるように作業記録をブログにかいていこうかなんて
思い至る。


とりあえず1~2月頭までの進捗


戦闘関連

・大勢のキャラの登場

単純に前々からキャラごとに使用するマテリアルやメッシュ情報がインスタンスを一回だけしたものを参照する形にする場合はメモリを食わないのは知っていたのだけど、
InstanceとDestroyを繰り返すと「なんか重いなぁ」状態になっていた。

調べるとどうもこのInstとDestを頻繁に繰り返すことでガベージコレクションっていうメモリ解放の処理の際に危険を及ぼすらしく、このままでは出せて画面に20体くらいが限度なのか・・・?

と途方にくれてたら知り合いから「オブジェクトプール」というこれまた便利な方法があるということを聞き調査、スクリプトを試しに書いて機能を理解したので、キャラの死亡や復活のシステムはこいつを主体に動かすことになった。

あとステージセットアップ時に大量のキャラがGetCompornentをすることになるのをさけるために、
動的な参照はプールマネージャにまかせて、静的な参照はあらかじめプレハブで登録することにした。

ただオブジェクトプールシステムの性質上オンオフ切り替えのため、
復帰時の処理をどうするかが問題になったけどこれまたいろんなゲームのキャラ制御みてると
だいたい予測がついたのですぐに解決した。(肝心のなにをみて予測したか覚えてないw)
これメモになってるのか!?

ダメージ数値表示、エフェクト表示も実装。

ダメージ表示だが、RectTransformで制御するんだけどこれUIがスクリーンオーバーじゃなくて、
カメラ前表示だった場合普通にCanvasの下にいれててもワールド空間の座標を流し込むと、
いちいちWorldtoScreenSpaceとかやんなくてもいいようだ。

ただ大きさを一定にできないから、カメラの距離に応じてなにかしこうもうか悩み中。

それ以外だと映ってないのにUIが見えたりどっかとんでいったりとひどいことになる・・。
どうしたもんか。

・味方、敵AI

1クラスでAI制御を全部やろうとして複雑化、Update内容がとんでもないことになっていたのだけど、ステートマシンという概念を見つけて導入。

とりあえずまだ全部は書き直せてないけどうち1体のステート管理を完了する。
そこで Interfaceやクラス継承、仮想化とかの基礎を覚える。


Unityには関係ないんだけど、
Pythonにクラス継承があることをここにきてはじめて知る。
(いままで3年も使っててしらなかったし、多重継承できるってきいて余計ビックリ)

まぁMayaでの作業の効率化とか程度のスクリプティングだと
まったく使用しなくていいのだけどもw

リグシステムも複数のクラスは作ってたりはしたけど、今見ても継承するほどじゃなかった。
まぁところどころここもっと汎用性高くできるんじゃないの?とかいうところは
C#の基礎やったおかげで、オブジェクト指向プログラミングの便利さの片鱗にふれいろいろアイデアは思いついたので機会があれば書き直してみたいw
(これはUnity作業と関係ないw)


・アニメーション・モデル

まだ本番モデルがないので仮の別モデルを読み込んでアニメーションつけて、
プレイヤーのコンボシステムや移動関連を実験中

ゲーム用のモデルじゃないからマテリアル数と骨数がはんぱなくて重いw
でもおっぱいは揺れる(手付け&やる気アップ)

やっててよかったモーションデザイナー!
でも本番の揺れものはさすがに物理使いたいw


・ステータス関連

ステータスというクラスを定義してあらゆるキャラクターのステータスの箱を用意、
一人一人が持つ形をやめて、ステージ読み込みなどの際にメモリには最小限の情報だけが残ってそいつを関連するやつだけが見に行けるようにした。

レベルアップシステムは導入するつもりなのだけど、
キャラごと個別じゃなくて全員同じステータスの計算式を使う予定だから、
レベルをなげれば自動で計算結果が返ってくるクラスを作成してそいつを呼び出すことにした。


その他


・画面遷移

ほぼほぼ必要な機能と要件をまとめきった。
あとはUIを仮置きしてデータセーブとか読み込むべき情報といらない情報等を
洗い出してメモリになにをもたせるかの仕様を切る。



1か月半くらいで自分的にかなり大きく前進したと思う。
土日をメインにすすめてるからまだまだ先は長いけど
頑張っていくぞー。




【モーション記事じゃない】Python 辞書の作成時の登録順番を維持

あまぐりです。 最近作業中階層が非常に深かったり、 飛びまくってるところへ度々アクセスすることが多いんですね。 ので、エクスプローラーさんと行き来することが多いんですが、 案件変わるたびに入れ替えたりお気に入りフォルダやショートカットが 多大なことになってきて古いの...