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だとこの前後のキーはブレイクダウンでうつとキーの色も変わってだ・・・・。

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

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

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

0 件のコメント:

コメントを投稿

MotionBuilderとMayaと

お疲れ様です。 あまぐりです。 MBさん面倒なんですよね。 普通になにかツール作りたい時に、UI考えるじゃないですか。 Pysideで普通にかけちゃうから。 わざわざかのMotionBuilderさんので書かないわけです。 というかMBと共通で共有する情報欲し...