Live2D+Unity開発の勘所と連携のコツ -成人向けゲームでの事例から

はじめに

成人向けインディーズゲームサークル「サークル暇乞い」実装・ディレクター・統括担当の吉田です。主にUnity製ゲームを製作している累計売上2000万円程度の中規模サークルです。よろしくお願いいたします。

弊サークルのUnity製ゲームアプリにLive2Dを導入し、2019年5月にリリースしました。その開発の際にクリエイターさんと連携してみて、個々のワークフローや作業範囲の分割でハマりどころが結構多かったため、忘備録として書き残したいと思います。これからLive2Dを導入される方のお役に立ちましたら幸いです。

対象読者は、Live2Dについてチュートリアル動画程度の知識は持っているものとします。
想定している読者としては、初めてアプリケーションに導入するような方,これからLive2Dを使ったプロジェクトに参画するイラストレーター・Live2Dエンジニアを想定しています。
外注などで分業を行っている組織において外注用の仕様書を書く際や、作業計画において各クリエイターの作業範囲を割り振る際に役立つかと思います。

話のキモ

この記事で述べたい内容を一言に集約すると、
Live2D+Unity開発のカギはワークフローの組み方とスクラム開発であるということです。
（※ここでのワークフローという言葉は、成果物を人から人へ渡していく作業フローを指しています。）
クリエイターが本質的な作業に注力する上での最大の障害は組織内での連携です。Live2D開発では常に次の実装の進め方を意識する必要があり、この課題を解決し、自己組織化されたチームに変えていくことがLive2D作業では大切になります。

まずは今回の開発での成果物

ア〇ールレーンのように、タッチに反応してアニメーションが遷移するLive2DアニメをUnityで実装したい！ということで下記のようなものを作りました。成人向け注意です。

成人向けLive2Dクリッカーゲーム完成しました！
イラスト:雅茶様(@rebagacha) CV:柊真冬様(@hiiragi_mafuyu)によるフルLive2D×フルボイス作品です。視覚効果+UIのリッチ化により臨場感とインタラクティブ性に力を入れています。是非デモと体験版で確かめてください！
体験版はGW明けに公開されます。 pic.twitter.com/1wZG8hAI23

— 吉田/サークル暇乞い (@coldsleep6666) 2019年4月27日

どのような組織で開発を行ったか

メンバーとスキルレベル

Unityエンジニア 1名

• UnityでのLive2D使用経験なし
• Live2Dの知識は公式チュートリアル程度
• モデルは作ったことがない
• イラストは描けない

イラストレーター 1名

• Live2D向けのイラスト作成経験なし
• 公式チュートリアル動画・公式モデルのレイヤ分割について事前に学習

Live2Dエンジニア 2名

• イラストが描け、既存イラストのレイヤを分割することができる
• Unityの使用経験や組み込み用モデル制作経験なし

ワークフロー

上記を作るには、イラスト・イラストから作成したLive2Dモデル・Unityによる制御の３つが必要になります。これを下記の順に作業を進めていきました。
1. 仕様と命名規約の作成
2. イラスト作成作業
3. Live2Dモデル/モーション作成作業
4. Unityでの制御スクリプトの実装

実際の制作での困り事

本作の開発はメンバーがそれぞれ自分の担当範囲の知識しか持っていない状況からスタートしました。つまり、Live2DエンジニアはUnityについて知識を持たず、UnityエンジニアはLive2Dでのモデルの作成方法について公式チュートリアル程度の知識しか持たない状態です。これを前提に、各々の専門分野を各人が担当するという分業体制で作業に臨みました。これは一見素朴で各々の専門性に基づいた合理的な分割であるように見えますが、実際には成果物の不備で次のタスクが滞った際に作業者間で調整作業が発生し、多くの工数を手戻りのリカバーに費やすことになったり、クオリティを妥協することになりました。例えば、

• イラストのレイヤ分けが間違っており、Live2D側でグルー作業に支障をきたしたが、Live2Dエンジニアが修正不可能な箇所であったため、Live2Dエンジニアが説明をしつつイラストレーターが修正
• Live2Dモーションに不備があり、Unity側でモーションブレンドに失敗したが、Live2Dモーションが複雑化していたため、Live2Dエンジニアで修正作業が発生
• Unityエンジニアがあらかじめ柔軟な変更を可能にするようなLive2Dモデルの策定を行えず、Live2Dエンジニア間での調整が都度発生、最終的に連携と修正コストのためクオリティを妥協

といった具合です。
Live2Dでは各フローの専門作業同士が密に関連しているために、成員が独立に作業を進めるということが非常に困難です。ですから、鍵となるのは互いが前後の作業についてある程度知識を持った状態で作業に臨むこと、つまりスクラム開発の体制をとることです。このようにすることで、ある程度コミュニケーションの溝を埋めて滑らかに連携を取りながら作業を進めていくことができます。また、副次的な効果として、スキル面で不安の残る作業を別工程で肩代わりし、互いにサポートしつつクオリティを担保することが可能です。実際に開発の終盤では密にコミュニケーションをとる体制に移行し、ある程度作業効率をあげることができました。

スクラムとは

トヨタなどで採用されている生産方式の一種です。スクラムでは自分の作業に関連のある作業について知識を持っておくことで、最適な形で連携を取ることを目指します。
Live2Dを用いた開発では大きく下の作業を別々の担当者がこなしていくことになります。

• アプリケーション仕様の決定
• イラスト作成
• Live2Dモデル/モーション作成
• Unityでの制御スクリプト作成

スクラムでは、これらの作業の内、自分の作業に隣接するものについて知識を入れていきます。（仕様を作る方は全体について浅く知っておきましょう）

スクラム体制の構築

三つの作業はそれぞれ全く別のスキルが必要になりますから、成員の学習コストが増えないよう、知識範囲を最小限に絞る必要があります。サークルでの経験をもとに、以降では各担当が何を知っておくとスムーズにワークフローが進むのかを具体的に列挙していきたいと思います。

仕様を考える際に知るべきポイントはここだ！

表情差分をイラストで作るか、Live2Dで作るかを決める

アニメーションで目などのパーツを変形させる方法で表情を作るのは非常に難しい作業です。差分イラストとして顔をいくつか作っておく方法の方がLive2D作業の難易度は低くすることができます。
ただし、各顔ごとに瞬きや口パクを設定する必要があるので、表情差分数が多い場合はこの作業は非常に工数が増えてしまいます。このあたりを考慮して、表情差分数は5個程度にしておくと良いかと思います。

ポーズをイラストで作るか、Live2Dで作るかを決める

VTuberのように、汎用の直立ポーズから全てのポーズを作るのは難しいです。
よく見られるLive2Dモデルの原画は直立ポーズですが、この直立ポーズから全てのポーズを派生させて作成するのは大変ハイレベルな作業で、できる方は限られてきます。（これを便宜上汎用立ち絵と呼ぶことにします）
もし決めポーズなど、あらかじめ決め打ちでも良いポーズがあるのであれば、そのポーズは汎用立ち絵によって作成するのではなく、別の原画を用意し、別のモデルとして作成するべきです。特にLive2D技術者が技術的に未熟であってイラストレーターの作業に余裕がある場合、この方法は非常に有効な打開策となります。
ポーズをイラスト側で作成するのか、Live2Dモデルとして作成するのかを事前に工数と相談してよく考え流必要があります。

ポーズから可動パーツを決める

関節があるところには回転デフォーマとレイヤ分割があります。具体的にどの関節が回転するのか、xyzのどの軸の回転があれば良いのか、あらかじめ仕様書に明記しておくことで、イラスト、Live2Dエンジニアの共通の仕様書とすることができます。また、先にポーズを決めてから可動箇所の決定に移るようにしましょう。Live2Dエンジニアの方にポーズの仕様書を見せることで、見栄えに寄与しない可動箇所を効率的な形で削ってもらうことが可能です。

パラメータ名、パーツ名、提出ファイル名の命名規約を決める

特にこだわりがなければパスカルケースをお勧めします。最終的にUnityではこれらをプロパティとして操作するため、自然な名前になるからです。Live2DをUnityに組み込む際には、命名はLive2D側で決めたものに固定されてしまうため、基本的には命名はLive2Dエンジニアの受け持つ作業になりますが、命名規約はC#のものを踏襲していないと開発者が地獄を見ます。最悪は変数名の仕様書を書くなどして必ず意思疎通を取っておきましょう。回転なら接頭辞Rotから始めるなど、公式モデルに従って命名を行うと、Live2D技術者が複数いる際でも混乱が少なく抑えられます。

作成に使うLive2D、ペイントツール、Unityエディタのバージョンを統一する

エンジニアの間では当たり前ですが、クリエイターの間では当たり前ではありません。よく確認しておきましょう。

同時再生されるアニメーションを明確にし、レイヤとして分けておく

これはどういうことかというと、例えば身振り手振りと表情のように別々のアニメーションだが同時に再生したいアニメーションがあるとき、これらを別レイヤのアニメーションとして区別し、書類にまとめておくということです。これはUnityでのBlendTreeによって、モーションブレンド（後述）を実現するための仕様です。
大まかには、

• いくつかの独立したアニメを同時に再生したい場合
• 着せ替えや衣装破れのような"部分的なアニメの取り替え"を行いたいとき

これらの時にレイヤとして切り出します。
例えば、衣装の着せ替えであれば、衣装の透過度アニメーションとそれ以外のアニメーションを別のレイヤとして切り出します。こうすることで、Live2D作業が始まった際、スムーズに意思疎通を行うことができます。

アプリケーションでアニメを再生した際、変な間ができないように注意する

アプリケーションに組み込む際は、タッチに鋭敏に反応してアニメーションを再生したい場合が多々あります。この際に、アニメーションの開始と終端が緩慢だと変な魔ができてしまうことが多々あります。開発時には操作に対する再生アニメーションと操作の内容を流れ図で描き、実際のアプリケーション内での挙動を想像してアニメを作成してもらえるようLive2Dエンジニアによく確認しておきましょう。

制作に御用聞きの「外注」としてではなく主体的な「メンバー」として参加してもらうことを確認する

これが一番大事です。スクラムはコミュニケーションが取れないと回りません。

イラストレーターが知るべきポイントはここだ！

ワークフロー

イラストレーターは仕様書を受け取り、イラストの構図の決定、ラフ画の提出、後続の作業を意識したレイヤ分割済みpsdファイルの作成を行います。

公式がサポートしているペイントツールを知る

Live2D Cubism Editorでは、公式にサポートされているペイントツールは下記の二つのみであることが明言されています。

• Adobe Photoshop
• Celsys CLIP STUDIO PAINT
• (出展：https://docs.live2d.com/cubism-editor-manual/precautions-for-psd-data/)

思わぬ落とし穴なので注意してください。
なおGIMPで作成したpsdだとうまく読み込まれませんでしたが、SAIで作成したものは問題なく動きました。（あくまで私の環境ではですが）

公式配布モデルのレイヤ構造を知る

Live2Dでは、公式モデルを踏襲して作ったものは大体において正しく動くようになっています。公式モデルで何がレイヤ分けされているのか確認しておくことで、編集のしやすいレイヤ分けにすることができます。可能なら公式のチュートリアル動画でレイヤの分け方について学習しましょう。
公式モデル https://docs.live2d.com/cubism-editor-manual/sample-model/?locale=ja
チュートリアル:https://docs.live2d.com/cubism-editor-tutorials/psd/
また、余裕があるならワープデフォーマ,回転デフォーマ,グルーについて知識を持っておくと、Live2D側で必要とされるレイヤ分割仕様に見当がつくようになります。公式チュートリアルは大した量ではないので、全て学んでおくと結局は時間短縮になるかと思います。

作成できないポーズがないか確認する

元絵によっては作成できないポーズがあります。たとえば、仁王立ちのイラストから諸手を上げたポーズを作ることはLive2Dでは不可能です。手を挙げた際に、手のひらのイラストが必要になるからです。あらかじめ作るポーズがどのようなものなのかを想定し、必要なパーツが足りるかどうかはイラストレーターが考えるのがもっとも早い段階で手戻りを防げます。Live2Dエンジニアと仕様の作成者に質問し、疑問を解消しましょう。なおこれが開発終盤で発覚すると非常に長い待ち時間が発生し地獄と化します。

主線を結合しない

主線を結合してしまうと、Live2D側で作業がしづらくなります。Live2Dエンジニアの開発スタイルにもよりますが、結合する前にLive2Dエンジニアに確認を取るのが吉です。

レイヤ名を重複させない

後続の作業で厄介な不具合を生む原因になります。命名規則を設けてレイヤ名が重複しないよう管理しましょう。

適切なレイヤ名をつける

後続の作業ではレイヤ名を元にしてレイヤを判断するため、レイヤ1などの名前がついているとLive2Dエンジニアが発狂します。必ず適切な名前をつけておきましょう。レイヤ名の命名も基本的に公式モデルに合わせておくと齟齬なく連携を取ることが可能です。

前面にあるものは前面に描く

グルー・デフォーマの仕様上、関節を曲げた際などにきちんと前面のものが前面に書かれていないと厄介なことになります。関節部分のレイヤ分けは割と作業に直結する部分なので、膝部分などは特に、膝の皿のみ独立させて前面に書くといったテクニックが必要になるため、わからなければLive2Dエンジニアの方に分割をやってもらう方が良いと思います。

グルーの数をポージングによって減らす

グルーが必要な脇、ひじなどが見えていないイラストの方が、遥かにアニメの制作が楽になります。余裕があれば仕様作成者と打ち合わせておくと、Live2D技術者に喜ばれます。

イラストレーターの方が上記に気をつけることで、イラストの自由度を最大限に引き上げ、また後続の作業の工数を大幅に短縮することが可能です。

Live2Dエンジニアが知るべきポイントはここだ！

ワークフロー

Live2Dエンジニアはイラストを受け取り、moc3形式にしたデータ類およびモーションデータ（json形式）をUnity技術者に提出します。組み込み可能なアニメに仕上げるためのUnityの知識と、レイヤ分けできる程度のイラスト作業への習熟が必要です。
経験上、担当業務として、イラストのレイヤ分け、モデルの作成、モーションの作成、組み込み形式データへの書き出し、ビューワでの確認作業を担当すると手戻りがなく良いです。
組み込みデータの作り方はこちらから学習しておきましょう。
https://docs.live2d.com/cubism-editor-manual/export-moc3-motion3-files/

モーションブレンドという概念の理解

素のLive2DとUnityで最も異なるのは、Unityではモーション間を遷移したり、複数のモーションを重ねて同時再生（Motion Blending）する操作があるということです。
Unityではこの表現を多用することを覚えておきましょう。
公式サイトのこちらから学習できます。
https://docs.live2d.com/cubism-editor-manual/scene-blend/

BlendTreeへの対応

上記のモーションブレンドは、具体的にはUnityのBlendTreeを使って実装することになります。BlendTreeに対応するには、同時に再生される複数のアニメーションが、同時に一つのパラメータを操作していないことが必要です。（例えば、口を開くアニメーションと閉じるアニメーションを同時に再生したら、口がどのようにアニメーションするかはランダムになってしまいます）したがって、同時再生するアニメから、同一のパラメータを操作しないように手動でモーションのキーフレームを除去する必要があります。どのアニメーションが同時に再生されるかどうかは、仕様作成者が決めたレイヤを参照して判断します。

Cubism3 Viewer for Unityを使用する

モーションブレンドの実行結果はUnity上で確認する必要がありますが、Unityの知識を持たないLive2Dエンジニアにとって確認環境を整えるのはあまりに学習コストの大きな作業です。そのため、Unityを使わずともUnity上での動きを確認できるように公式がこのようなツールを出してくれています。
Cubism3 Viewer for Unity
https://docs.live2d.com/cubism-editor-manual/cubism3viewer/
これを使ってUnity技術者に提出する前に一度テストを行いましょう。仕様で決めた指定のレイヤーを同時再生し、おかしな動きをしなければクリアです。

Unity環境の用意（出来ればでOK）

一度でいいので、Unity技術者にお願いしてプロジェクトデータをもらい、自分の作成したデータが組み込み後どのようにUnityに取り込まれているか見てみましょう。（Unityの使える環境を整えることが必要です）特にパーツIDなどが直接パラメータの名前として取り込まれていることや、キーフレームがAnimationのキー値として読み込まれることなどを理解しておくと、Unity技術者に優しいモデルおよびモーションを作る手がかりを得ることができます。
なお、Unityでは、Mecanim,Animation,BlendTreeの3つの仕組みを使って実装することになります。これらの言葉だけ知っておくとエンジニアと連携が撮りやすいです。

パーツID・シーン（モーション）名を適切な英語名でつける

最重要です。仕様で決定した規約に基づいて名前をつけましょう。ここはエンジニアに質問して作業するくらいでちょうどいいと思います。というのは、UnityエンジニアはパーツIDの名前によって動きを制御するからです。したがって、きちんとした規約の元でパーツIDをつけてください。これができていないと後続の作業は阿鼻叫喚になります。基本はこれも公式モデルを参考にしてパーツIDをつけておくと良いです。
また、必ず英語名を使ってください。アプリケーションのフォルダパスに日本語ファイル名があると、Unityは予期せぬ誤作動を起こすことがあります。

パラメータの定義域はLive2DSDKに準拠

Unityで目パチやリップシンクを実装する際には、定義域は次のようになっていなければなりません。

• 口の開閉（リップシンク）のパラメータ変域:0~1
• 瞬きのパラメータ変域 :0~1
• 呼吸のパラメータ変域

これはUnity用ランタイム(Live2D SDK3.0)に対応するためです。
この設定を行うことで、声量に合わせたリップシンクと自動の瞬きをUnityで使うことができ、大変見栄えのある動きをつけることができます。なお、やはりこれも公式モデルを踏襲する形に仕上げておけば問題なく動かすことができます。

組み込みデータの出力形式を知る

Unityエンジニアに聞いて組み込みデータの出力形式を決めてもらいましょう。SDKのバージョンを考慮したり、場合によってはリップシンクデータを焼き込んでくれといわれる場合もあるかもしれません。

以上がLive2Dエンジニアの注意点です。Live2Dエンジニアはイラストとエンジニアの板挟みになり気をつけることが多くて大変です。

Unityエンジニアが知るべきポイントはここだ！

ワークフロー

きちんとこれまでの作業ができているなら、Unityエンジニアは組み込みを行うだけで済みます。

SDKには2系と3系の間に大きな断絶がある

互換性がありません。モデルをどのCubism Editorで作成するのかきちんと周知しておきましょう。

BlendTreeを使ってレイヤごとの制御を実現する

下記のスクリプトを使って実装を行います。
https://docs.live2d.com/cubism-sdk-tutorials/blendexpression/?locale=ja

Animationのループ時のガタツキを抑える

Live2DSDKのモーションは、Unityに取り込むと単なるAnimationファイルになります。この際ループアニメとして作っていると、始点と終点に別々のパラメータを持つキーフレームが打たれている場合にアニメーションがガタつく場合があります。通常のアニメーションの変更と同じように編集しましょう。また、これらを発見したら将来の変更に備えてLive2Dモーションを編集して直しておくことをお勧めします。

アニメーション遷移時の感じをLive2Dエンジニアにフィードバックする

Live2Dにはアニメーション遷移がありませんので、Live2Dエンジニアは遷移の手触り感を想像することしかできません。一方、Unityエンジニアは細かい部分まで遷移の様子を想像することができます。製品が完成したら必ずフィードバックし、必要なら修正をお願いしましょう。

以上がUnityエンジニアの作業です。Unityアプリケーションが最終目的になっているので気にすることは少ないですが、最終的な製品イメージを持っているのはエンジニアだけです。他の工程に気を配り、間違った方向に進みかけていたら止めるなどのアクションが取れる役割なので、余裕があるならばたまにレビューを行うとよいでしょう。

最後に

分かりにくいことや疑問点があればTwitterでもなんでも構いませんのでご質問ください。