大阪電気通信大学
高見研究室
はい。引き続きブンです。
前回はプログラムだけでアニメーションをやってみた場合の話でしたが、
画像を使ったプログラミングでアニメーションを行なうときの
制作目標となるイメージの整理と、
プログラムによるアニメーションの調整についての話を
実物を交えてしようと思います。
「プログラムだけでは表現しきれない部分を画像で表現する」
と言うだけであれば「画像を使えばそれでいい」と思いがちですし
単純そうですが、そもそも何を表現しようとしているのか、
そのために必要な画像と処理とは何かを考える必要があると思います。
さて、まず考えるべきなのはアニメーションの『用途』です。
もし人間の動きや姿勢について研究を行なっているとなると、
コンピュータ上で人間の動きをそのまま再現するような用途が考えられます。
この時に行なわれる再現（シミュレート）は当然リアルでなくてはなりません。
が、ゲーム内のキャラクターを動かす用途となると、
リアルさよりも、迫力や入力に対する反応（インタラクション）の提示
といった役割を果たす必要が出てきます。
また、空を飛んだり変身したり、となるとリアルさとはかけ離れた
アニメーションをさせなければならなりません。
現実ではない、つまり空想やイメージを表現する必要が出てきます。
今回はそんなイメージをどう表現するか、特に２Dに着目して話を続けます。
まあゲームの世界の話ですから、人間の関節がどこまで曲がるだとか、
速く走るためにはこんな姿勢で走れだとか、そんな話は抜きです。
気になる人は人間工学あたりを勉強して下さい。
次に、イメージの整理について考えていきます。
ここでは実例として、風景のアニメーションをやってみます。
なんで風景なのかといいますと、キャラクター以上に表現の自由度が高く、
イメージの整理という意味ではうってつけかな？と思ったからです。
キャラクターのアニメーションについては、のちほど実例付きでお話します。
ではまず、風景と一言で言っても前景と背景があります。
というより、画像を貼付ける順序といった方が分かりやすいかもしれません。
背景が一番後ろになるように一番はじめに配置し、
次にプレイヤーの操作キャラクター、そして最後に前景、
といったような感じで配置することでゲーム画面は構成されています。
が、パーツをもっと細かく分け、配置していく必要が場合によってがあります。
グダグダと説明するよりは実物で説明した方がいいでしょう。
ということで、前回使用したプログラムを改造し、
牢獄時計なるものを作ってみました。
この時計、パッと見でどのような画像が何枚、
どのように使用されているか分かりますか？
実際に使用した画像は下に貼付けておきますが、見ずに先に考えてみてください。
プログラムできる人は自分で画像を用意して実際に実装してみてください。
絵が下手でも結構です。落書きのような画像で構いません。
画像が用意できないという人も、とりあえず
必要な画像と処理を考えてみてください。
ではヒントとして私がどのように考え、イメージし、
どのように作っていったかを書こうかと思います。
まず、前回の時計のプログラムのデザインを
すべて画像に差し替えようと思い至りました。
アナログ表示もデジタル表示も前回のプログラムそのままですが、
前回とは真逆で、表示部分はすべて画像を使用します。
また、背景だけでなく前景もあり、別途アニメーションを
取り入れたものを作ろうと考えました。
で、できあがったものは今回の話のネタに使用しよう
（あまり時間をかけて作らないでおこう）と思いました。
さて。
この段階ではまだ目標がはっきりしただけであり、
実際に作るもののイメージはできていませんが、
ここで決めた目標に沿って、イメージを組み立てていきます。
この目標を念頭に置き、ここから外れた内容は不要な作業ということになります。
次に、時計の前景に何かを用意する、ということで想い至ったのが牢屋です。
時計を牢屋に入れたようなデザインにすることで、
背景に牢屋の内装、前景に格子を用意しようと思ったわけです。
さらに、牢屋でのアニメーション、ということで思いついたのが
時間帯によって行動が変化する牢屋の住人と、古くなった牢屋の電球です。
住人は朝、昼、夜などの時間帯にあわせて行動し、ぐうたら寝ていたり
うろうろしていたり、格子から外の様子を覗いていたりと、
いろんなことをします。が、これは今回は断念しました。
というのも、行動のバリエーションだけ住人の画像が必要になります。
また、住人の行動の制御を行なうための処理も必要です。
今回はあくまで、ここでの話のネタ用にしたかっただけなので、
そんなに時間をかけて作る必要はない、と考えました。
となると、とりあえず電球のチカチカする感じを
プログラムでの制御で表現しよう、となりました。
で、電球は牢屋の中に１つだけ設置されているイメージを思い浮かべ、
光りの他に薄暗さ、影の表現が欲しいと思いました。
電球は牢屋の中にあるので、今回影ができるとすれば格子部分です。
ただ、下のデジタル時計部分を影のように表現できないだろうか？
とも考えました。格子の影と同時にデジタル時計も現れるイメージです。
が、そうなるとデジタル時計部分の処理に手を加えることになります。
また、影という扱いであれば、床に映し出されたイメージにしたいので
床に映し出された格子の影と同じ角度で数値を表示したい、と思ったわけです。
やってみたい半面、そこまでする必要はありません。
オマケに数値が読みにくくなってしまう可能性もあったので、断念しました。
ということで。
電球による光りの表現と格子の影の表現をプログラムで制御しよう、
という結論に至ります。
では、全体像のイメージの整理をします。
背景に牢屋の内装、前景には格子があり、牢屋の中にはアナログ時計があります。
格子は画面全体を覆うのではなく、デジタル時計部分は開けておきます。
画面の位置（カメラ位置）は牢屋の奥のアナログ時計をまっすぐ見ている
イメージなので、斜めから見るような描写はしません。
そして電球による光りの描写は格子の内側、格子の影は格子の外側であり、
この光と影は対応してアニメーションします。
牢屋全体のイメージは電球が切れかけであるほどにボロいイメージです。
なので内装は色がくすんでいてひび割れており、格子も錆びている感じです。
で、メインとなる時計部分ですが、牢屋なので派手な色は使いたくありません。
また、明るいイメージではなく暗く重いイメージです。
ということで黒で統一しました。
しかし、アナログ時計部分は前に格子があるため、
ただの棒のような針のデザインをしてしまうと、時間によっては
格子で隠れてしまって見えなくなってしまう可能性があります。
なので横に少し広い針をデザインする必要があります。
また、文字版の数値やそれにあたる模様ですが、
格子でほとんど見えなくなるので、無しとしました。
デジタル時計部分は、囚人が牢屋で壁に数字（実際は正の字）を書くことで
何日目かどうかを数えているようなイメージがあったので、
既存のフォントを使わず手書きにしようと思いました。
ここまできてやっと実際に必要な画像と処理について考えていきます。
まず表示は、
背景、アナログ時計、光り、格子、影、デジタル時計の順で重ねて行ないます。
特に背景、光り、格子、影の部分は
プログラム側で正確な位置に重ねる必要があります。
ちゃんと重なるようにプログラム側で配置する座標を調整してもいいのですが、
画像サイズで統一することで、わざわざ調整する手間を省きます。
また、表示部分は線（牢屋の隅、格子部分）や円（アナログ時計部分）が多く、
数値（デジタル時計部分）も使用しているため、
プログラムでの図形描画を交えることも可能ですが、
目標として「表示部分はすべて画像」としているため行ないません。
代わりに画像ならではの表現（自然な感じや手書き感）を意識しました。
さて。光と影のアニメーションですが、
あくまで光と影の強弱を表現したいだけなので、
画像を数枚用意してパラパラ漫画のように再生するのではなく、
プログラムによって濃淡（透明度、アルファ値）を調整することで行ないます。
なので、光の部分と影の部分の透明度を変化させた場合の様子を
画像作成時の時点でチェックしておきます。
全く表示しない（光も影もない）状態ではこう見えて、
完全に表示している（光も影も一番濃い）状態ではこう見える、
というのをプログラミング前に確認しておきます。
AS3で透過はpng形式の画像で対応しているので、
透過を有効にしたpngとして保存しておけばＯＫです。
プログラミング言語によっては透過に対応していない、別途処理が必要になる、
ということがありますが、そういう場合にはブラシツールのような
薄く重ね塗りしたような表現（アンチエイリアスあり）ではなく、
ドットでの表現にした画像（アンチエイリアスなし）
を用意することで対応することができます。
そして透過したい部分は完全に関係のない色（緑など）で塗りつぶし、
プログラム側でその色を抜き取ってしまえばＯＫです。
（このあたりはひょっとしたら後日触れるかもしれません）
ではプログラム側での実際の光と影の強弱アニメーションですが、
完全なランダムでは激しくチカチカしてしまい不自然で、目にも悪いです。
なので現在の透明度（アルファ値）からどの程度暗くするか、
または明るくするか、をランダムで調整することで急激な変化を無くしました。
残るは時計部分ですが。
前回のプログラムからの画像の差し替えのみで行う、ということで
差し替えを行なうパーツを確認します。
まずアナログ時計ですが、文字版部分は背景にあたるため、
残るは短針、長針、秒針です。
これもまた、用意した画像の配置位置をプログラム側で
指定する必要がありますが、調整が面倒なので画像サイズを統一します。
そして最後にデジタル時計部分です。
数値切り替え時の回転アニメーションはプログラム側で行なうので
必要なのは0から9の画像、あと忘れてはならないのが『：』です。
これまた配置調整が面倒なので画像サイズを統一します。
さて。長々と私なりの作業工程を説明しましたが、
貴方なりに考え、イメージできましたか？
では実際に使用した画像です。
はい。ずらっと並べてみました。
どれがどのパーツか、あえて説明は省きます。
前述の説明で大体想像できると思いますので。
さて。
もうお気づきかもしれませんが。
実は『他人が作った既に完成しているものを見て作る』と
『１から自分で考え作る』では全くイメージする内容が異なります。
そして何か新しいものを作るときは、
自分一人にせよ多人数にせよ、１から考えなければなりません。
そして考えることができる内容そのものは自由です。もう本当に自由です。
でも自由であるからこそ、実現するために
何をしなければならないのか見失ってしまいます。
あれもしたい。これもしたい。やろうやろう。どうすればいい？こうすればいい。
あ、これ面白そう。これ便利じゃん。じゃあこれも使おう。あれも使おう。
そうなれば完成しません。
何をしていたのか、成果がなんなのか、はっきりしません。
なので、最初に目標を決めることが必要になります。
今回私もいろいろとやってみたいことがありましたが、妥協しました。
おそらく、読んでいて「こうしてみたら？」と思った人もいるかもしれません。
そういう人は、今回の目標でそれを実行する必要があるのか、
実現するなら、そのためにはどうすればいいのか、自分なりに考えてみて下さい。
ということで、イメージの整理の話はここまでです。
では次に、プログラムでのアニメーションの調整について話をします。
先ほどにもありましたが、イメージを元にどんな画像や処理を
用意していくのかが重要になるわけですが。
中でも人、あるいは人のような動きをするものをイメージし、
何かを作成していくことは多々あります。
というか、人だからこそ一番身近でイメージしやすいものは人であり、
人を元に何かをイメージしがちなのは仕方のないことです。
逆に言えば人のイメージは何よりも一般的で浸透している、ということです。
つまり骨格や姿勢、アニメーションにおいて
人から不自然だと思われる可能性の高い題材だということです。
しかし、人が思い描く人のイメージはあまり正確ではありません。
例えば、人間が取り得る行動を想像してください。
話す、歩く、食べる、寝る、勉強する、喧嘩する、いろいろあります。
が、これらすべてはすでに概念化されている情報であることは分かりますか？
例えば『話す』という行動の場合、どういう状態のときのことを指していますか？
口を開けている、ではありません。声を出している、だけではありません。
途中の息継ぎも含めて『話す』かもしれません。
手話かもしれません。実はネット上のチャットのことかもしれませんね。
さて。
なんでこんな話をするかといいますと、このような概念は
コンピュータにとって非常に再現の難しい題材だからです。
じゃあどうするのか、といいますと。
そんな概念に合うように、誤摩化しつつ再現するわけです。
口が動いてたら話してる。足が動いて進んでたら歩いてる。などなど。
となれば、どう誤摩化すのか、という話になってきます。
今であれば、画像とプログラムだけでどう誤摩化すか、です。
では、アクションゲームを想定して人の動作の概念を整理しましょう。
立ちます。
歩きます。
走ります。
ジャンプします。
上下左右に飛ぶのもやってみましょう。
これらを人の『状態（ステータス）』と呼び、立っている状態から歩く、
歩いている状態からジャンプする、などの変化を状態遷移と呼ぶとしましょう。
そして各状態にあった画像と処理を用意し、切り替えます。
切り替える瞬間（状態遷移を行なう瞬間）は操作者、プレイヤーに委ねられます。
つまり、どの瞬間にどんな状態遷移を行なうかを管理しなければなりません。
が、概念という点ではここまでの再現が限界です。
ここから先の、実際の動作に関しては具体的な答えはありません。
人が人をどう見ているか、そしてどんな目的でこれをしようするかによって、
何がよいのかが変わってきます。
ならば、ということで。
下に用意したFlashで実際にアニメーションの調整をやってみてください。
そして「これは微妙」「これなら丁度いい」「これはこういう状態？」
「ここまで動かす必要ある？」などなど、いろいろ考えてみて下さい。
操作説明ですが。
キーボードで操作を行なう前には必ずFlash部分をクリックし、
『半角入力』にした状態で行なって下さい。
上下左右キーで移動（棒人間なら上はジャンプ）、スペースキーで加速します。
左側のパラメータについてですが。
摩擦が数値が小さいほど滑らず、数値が大きいほど滑って止まらなくなります。
重力は数値が小さいほど下に向かってかかる力が小さくなり、
数値が大きいほど下に向かってかかる力が大きくなります。
加速度はキーを瞬間的に入力した場合に加算する距離（加速する量）です。
最大速度１はスペースキーを押していない状態の最大速度です。
最大速度２はスペースキーを押した状態の最大速度です。
次に右側のボタン群ですが。
『切り換え』ボタンをクリックすると、
棒人間と、なんだかよくわからない空飛ぶ人とを切り替えることができます。
空飛ぶ人は３年前に課題でシューティングゲームを作る際に描いたものです。
が、今回は動きだけなので弾は撃てません。
色数やハイライト、デザインセンス等は無視してください。気にしちゃダメ。
『最適値』ボタンをクリックすると、
左側のパラメータを現在表示しているもの（棒人間or飛ぶ人）に合わせて
私なりに最適かな？と思う値に設定します。
『状態遷移』ボタンが押されている状態だと、
キャラクターの現在の速度などに合わせて表示画像が変更されます。
押されていないと変更されません。
ぶっちゃけ画像によるパラパラアニメーションの再生と一時停止です。
また、『アイドリング』ボタンと『補間』ボタンは
このボタンが押されていないと有効になりません。
『アイドリング』ボタンが押されていると、
同じ状態（立ちや歩き）であっても画像の差し替えを行ないます。
押されていないと差し替えが行なわれません。
『補間』ボタンが押されていると、
棒人間であればジャンプの着地時、飛ぶ人であれば左右の移動開始時と終了時
（状態遷移を行なう瞬間）に別の画像を差し込み表示します。
押されていないと表示されません。
いわゆる動作が急激に変わる瞬間の状態を表示するかしないか、です。
はい。長々と続きまくってますがまとめです。
突然ですが、初期のマリオのアニメーションってどうなっているかご存知ですか？
非常に単純そうなドット絵だったというのはご存知だと思います。
でもあのドット絵によるアニメーション、状態遷移が結構あるんです。
立ち止まっているとき、走っているとき、ジャンプするとき、
急に方向転換するとき、キノコで大きくなるとき、スターを取ったとき、など。
マリオの服装の特徴も、ドットで細かく表現されています。
確かに枚数そのものは少ないかもしれませんし、
ドットでは表現しきれない部分もあるかもしれません。
かといって、必要な表現がされていないか、といえばそうではありません。
ゲームに必要最低限な表現がされており、心地よく操作することができ、
キノコで大きくなるというのも否現実的な話ですが、
それこそがマリオの特徴でもあります。
なにより、２Dでも３Dでも綺麗なグラフィックが実現可能となった今、
そんなマリオが時代遅れのゲームと見なされることはありません。
様々なハードに移植されたり、話題にされたりしています。
そしてマリオだけでなく、そういうゲームは数多く存在します。
はい。何が言いたいか、といいますと。
便利なツールや機能に振り回されてゲームを作っても、
面白いと思えるもののイメージや、表現したいことのイメージを
無視してしまうと本当に面白いゲームを作ることも、
誰かの心に残るようなゲームを作ることも
できないのではないだろうか？と私は思うのです。
そしてアニメーションによる表現はゲームの難易度のような、
システム的な部分に関係がないものほど、サボれるものが数多くあります。
だからこそ、ゲームを作る前にアニメーションに対する価値観を
自分の中でイメージすることによって決める必要があると思うのです。
アニメーションは時間もかかりますし面倒なので、
イメージを固め、どうすれば実現できるか考え、
行動に移すためには根性と覚悟が必要になります。
価値があるということは「やった方がいい。やろう」に繋がってきます。
アニメーションさせたいと思う人には、
まずそう思えるようになって欲しいですし、
実行に移して欲しいと私は思うわけです。
ということで今回はここまで。
次回はプレイヤーが操作することができるものとできないものの
アニメーションについて考察しようかと思います。
んでは、ここまでお付き合いありがとうございました。
（投稿：ブン）
コメントをお書きください