読者です 読者をやめる 読者になる 読者になる

WonderPlanet DEVELOPER BLOG

ワンダープラネットの開発者ブログです。モバイルゲーム開発情報を発信。

UnityのAnimationClip周りの小ネタ

Unity

3Dデザイナーの宮澤です。

今回はMaya等の3Dソフトから書き出したモーションデータを、

Unityに組み込む際のちょっとした小ネタを紹介します。

 

▼AnimationClipだけ取り出したい

データ削減に伴って、不要なスケルトンデータやメッシュデータは削除して、

必要なAnimationClipだけ残したい時の方法を紹介します。

①FBX内のAnimationClipを選択

②Command(Ctrl) + D 

以上で取り出すことができ、編集可能となります。

この時、複数のAnimationClipを同時に取り出すことも可能です。

f:id:wp_miyazawa:20170217103535p:plain

▼AnimationClipのリネームが面倒くさい…

FBXのファイル名を変えていてもAnimationClipの名前は決まって「Take 001」になっていると思います。

しかもFBX内にある状態だと編集不可…

f:id:wp_miyazawa:20170217103710p:plain

▼FBXデータの先頭に「@(アットマーク)」を付ける

Unityに組み込む前に、FBXのファイル名に「@」を付けるだけで、

AnimationClipの名前がファイル名と同じものに変換されます。

(AnimationClipのほうに「@」はつかない!)

f:id:wp_miyazawa:20170217103733p:plain

 

▼まとめ

・Command(Ctrl) + D でFBXからAnimationClipを取り出せる

・「@」を付けるとAnimationClipのデフォルトの名前(Take 001)がFBXと同じになる

リネームによる人的ミスでキャラクターが動かない…

なんて不幸を少しでも削減できたらと思います。

 

 

Unityプロジェクトのビルド環境改善

Jenkins Unity Xcode

アプリエンジニアの山下です。 プロダクト自体の改善はもちろんですが、開発環境を改善していくこともエンジニアの重要な仕事だと思います。

今回はUnityプロジェクトをビルドしストア提出用アプリ(ipa/apk)を作る上で 起こった問題とその解消方法についてまとめてみました。

ビルド作成時の問題

開発を進めていく上で、現行プロジェクトをビルドしてQAや開発に関わっているメンバーに配布することは多々あります。 しかし開発が進むにつれプロジェクトが膨らんでいき、ビルド手順の複雑化とビルド時間の増大が問題になってきました。

特に手順の複雑化は属人性を高め、ビルド職人がいないとビルドを作れない事態にまで及びました。 一時期ビルド手順書が作られましたが、日々の開発による手順の変化に対応できず、属人化を避けることはできませんでした。

Jenkins の導入

まず属人化解消のため、Jenkinsによる自動ビルド環境を構築しました。

特筆する点としては、作成されるapk/ipaの用途に応じて、デバッグモード有効・無効、サーバの向き先などを予め指定したジョブを複数用意しています。 一例を挙げると以下の通りです。

f:id:wp-yamas:20170203112251p:plain

  • Beta-Build (デバッグ機能有効・開発サーバ)
  • RC-Build (デバッグ機能無効・ステージングサーバ)
  • Release-Build (ストア提出用・本番サーバ)

これにより、最低限のパラメータを設定すれば、後はビルド実行をポチるだけという状態にまで落とし込みました。

またジョブは行程ごとに細分化されており、ジョブ間の連携はパラメータと成果物の受け渡しで行っています。 パラメータの受け渡しはParameterized Trigger Pluginを使用しています。

Parameterized Trigger Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin

同じ工程は一つのジョブに集約できるため、メンテナンス性を向上しています。

f:id:wp-yamas:20170202122808p:plain

これで属人化は大きく解消できたと思います。

Mac Pro の導入

これまでビルドサーバには以下の構成のMac miniを使用していました。

Mac mini (Late 2014)
2.6 GHz Intel Core i5
16 GB 1600 MHz DDR3
Intel Iris 1536 MB
1TB HDD

そしてビルドに要していた時間がこちらです。 おおよそ1時間かかっていました。

Mac mini
    iOS … 61分41秒
    Android … 52分01秒

そのため期限が迫っているときのビルドはちょっとしたバグやオペレーションミスが命取りでした。 ビルド時間は細かい改善箇所はあれど、マシンスペックによる要因がとにかく大きいと判断したため、ここは一旦スペックの高いMac Proの導入で改善しました。

Mac Pro (Late 2013)
2.7 GHz 12-Core Intel Xeon E5
64 GB 1866 MHz DDR3
AMD FirePro D500 3072 MB
1TB SSD

6コアモデルのMac ProからCPU、RAM、SSDをそれぞれアップグレードしています。 そして実際に同じビルドを走らせた結果がこちらです。

Mac Pro
    iOS … 61分41秒 → 13分55秒
    Android … 52分01秒 → 10分52秒

ビルド時間が大きく短縮されました。

特にiOSのXcodeビルドは、IDEBuildOperationMaxNumberOfConcurrentCompileTasksオプションの指定をすることにより、並列処理する数を上げており、12コアCPUのパフォーマンスをより発揮できるようになります。

xcodebuild archive \
       CODE_SIGN_IDENTITY="${CODE_SIGN_IDENTITY}" \
       PROVISIONING_PROFILE="${PROVISIONING_PROFILE}" \
       -scheme Unity-iPhone \
       -archivePath Project.xcarchive \
       -IDEBuildOperationMaxNumberOfConcurrentCompileTasks=12

まとめ

今回はJenkinsとMac Proの導入によりビルド環境の改善を行いましたが、開発環境の問題は他にもまだまだ存在しています。 日々の改善でよりよい開発環境を実現したいと思います。

クラッシュフィーバー クライアント開発チームのご紹介

開発

おつかれさまです。エンジニアの藤澤です。 自分はクラッシュフィーバーのクライアント開発を担当しているんですが、最近ふと、いまの開発チーム(開発スタイル?)が自分にあっているというか、いまの環境 恵まれてるなあ、と感じることがありまして、今回はそれをご紹介したいと思います。

チームメンバー

現在チームのメンバーは 4 人です。

おもにバトル部分を担当する人、マルチ部分を担当する人、それ以外の部分を担当する人、といった具合におおまかに担当が分かれています。 日本人は属人化を嫌う人が多いように感じますが、担当がおおまかに分かれていることで、タスクの割り振りなどイチイチ決めなくても各々が自発的に動けますし、コードもクリーンな状態に保ててよいです。(自分の担当分以外でもだいたいの機能とかは分かっているので、その人じゃないと どうしようもない、ということもないですし)

いわゆるマネージャーはおりませんが、役割分担ができていますし、各々自分で判断して動けるメンバーが揃っているので、スムーズに動けています。

タスク管理・スケジュール管理

タスクは GitHub の Issue で管理しています。

新機能や改善要望、不具合情報など、ふだんから誰でも Issue に登録しておき、次のバージョンでどのタスクを入れるかをその中から決めます。

スケジュールは

  1. どのタスクを入れたいかと優先度、リリース予定日をプロデューサー、ディレクターが決める
  2. エンジニアがそれを見て期日内に収まりそうにないタスクを省く

といった具合に決まります。細かい工数見積もりなどはせずに さくっと決めてしまいます。

GitHub の Milestone の機能でバージョンごとに Issue をグループ化し、すべての Issue が片付いたら完了です。

スケジュール表なども作っておらず、細かいスケジュール管理もしていませんが、ひとつのバージョンの実装期間が だいたい 1 〜 2 週間なので、毎朝の進捗共有だけでこと足りています。

開発スタイル

アジャイルでやろうとか ○○型でやろうとかは とくに意識していません。

開発の流れは

  1. プロデューサーやディレクターがおおまかにやりたいことを決める
  2. プランナーが仕様をつめる
  3. 実装
  4. QA
  5. 社内リリース(新しいバージョンを実際に本番につないで しばらくプレイしてみる)
  6. 本番リリース

という感じで行ないますが、エンジニアが細かい仕様を自分で判断して先に実装を進めちゃうこともありますし、QA 期間中に実際に動かしながら「やっぱりこうしたほうがいいんじゃない」ということで軌道変更したりします。

その他

コーディングルールなどはありません。(宗教の押し付けに感じられるので……) 変数の命名はキャメル形式にしようとか、既存のコードになるべくあわせようとか、その程度です。

Git の運用は git flow と github flow の中間みたいになるのでしょうか(あまり詳しくないのですが)。

  1. master ブランチは市場に出ている最新の状態
  2. develop ブランチは開発中の最新の状態
  3. develop から feature を切って実装を行ない、develop に Pull request
  4. 複数バージョンの開発が並走する場合は develop_2.0 みたいに develop ブランチが複数存在することもある。前のバージョンがリリースされたら develop にマージし、develop を最新の状態に保つ。

という感じです。master は本番環境向けの設定、develop は開発環境向けの設定にカスタマイズしてあり、リリース時の設定変更もれとかがないようにしています。

職場環境はオープンオフィスなので、まわりの会話から他のチームの状況とか分かってよいのですが、割り込みも多くて実装に集中できないのがジレンマです……。

まとめ

これだけ書くと なんだか まともな管理もしていない無秩序な集団のようにも見えますが、決してそういうわけではなく、まだ社員ぜんぶで十数人だったころの よいベンチャーらしさみたいな部分をうまく残せているんじゃないかと思っています。

SpriteStudioのデータ容量を削減する

SpriteStudio

2Dデザイナーの木村です。
アニメーションを作っていると、ついついキーを多く打ちすぎてしまい重くなってしまった!なんてことはございませんでしょうか。
今回のデザイナー記事は、SpriteStudioのテクスチャアニメーションのデータ削減方法についてお話します。

▼ テクスチャサイズを小さくする

テスクチャのサイズを削減するには、エフェクト系の素材の大きさを1/2程度にすることがお勧めです。

エフェクトであれば、多少ぼやけていても気にならないことが多いです。一瞬しか出ないものや、αブレンド方法を加算にする素材はサイズを小さくしても問題ありません。

逆に、素材の大きさを小さくすると見栄えが悪くなるものが、テキストとくっきりした素材です。テキストの対処方法としては、1文字ずつ分けて並べるのも手です。

 

f:id:wp_harumura:20170118205730p:plain

アニメーションのデータを小さくする

1.インスタンス機能を使う

インスタンス機能とは、作ったアニメーションを「インスタンスパーツ」として別のアニメーションに配置し、再生する機能です。

複数のssaeで同じ動きを入れたい場合、1つアニメーションを作って各ssae内にインスタンスパーツを配置するだけでOKです!

この機能を使うことにより、データを小さくするだけでなく項数も削減できます。

(Photoshopでいうところのスマートオブジェクトといった感じでしょうか…)

詳しくは、こちらの公式サイトをご覧ください。

インスタンス機能の使い方 | OPTPiX Help Center

 

2.無変化キーの削除を行う

SpriteStudioには、パーツのアニメーションの演出に影響が無いアトリビュートを削除する機能があります。

アニメーションを作っていると、知らず知らずの内に余計なキーが打たれていることがありますが、この機能はキーとキーの間で何も変化していない箇所を自動で削除してくれます。

アニメーションが完成後、必ずこの機能を使いましょう!

もれなくプログラマーもデザイナーも幸せになれますヽ(*´▽´*)ノ

無変化キーの機能の場所は、こちらご覧ください。

「無変化キーの削除」ウィンドウ | OPTPiX Help Center

 

まとめ

どんなに良いアニメーションが出来ても、ゲームのローディングが遅くなるほど容量が大きくては、本末転倒です。

以前、まさにこの壁にぶち当たり四苦八苦しました。

出来上がったアニメーションのテクスチャを、後で半分のサイズにしたりなんてことが起こると、のちに全てのキーでスケールを直すといった地獄が待っています。

上記3点を行うだけでも、かなりのデータ容量削減ができますので、もしお困りでしたら是非試してみてください。

GitHubとCircleCIの連携について

GitHub CI

サーバーエンジニアの若原です。

今回は開発でも使っているCircleCIのGitHub連携について紹介させていただきます。 CircleCIとは継続的インテグレーションのためのクラウドサービスです。 GitHubと連携することができ、git pushなどをトリガーにビルドを走らせることができます。

1コンテナまでは無料で使用することが可能ですが、複数のビルドを並列で行うためにはコンテナを増やす必要があり、2つ以上のコンテナを使用したい場合は有料となります。プロジェクトの規模を考えて適切な量のコンテナ数を追加する必要があります。

サインアップ

CircleCIへはGitHubのアカウントでサインアップすることができます。

f:id:wp-wakahara:20170110020126p:plain

プロジェクトの追加

サインアップ直後にダッシュボードに遷移します。プロジェクトが存在しないため赤枠内の「Add Projects」からGitHubのプロジェクトを追加します。

f:id:wp-wakahara:20170110020026p:plain

追加したいプロジェクトの「Build project」からプロジェクトを追加します。

f:id:wp-wakahara:20170110020120p:plain

CI設定

CIの実行内容を記載する「circle.yml」を、追加したプロジェクトのrootディレクトリに設置します。

circle.ymlの以下サンプルは以下のとおりです。

machine:
  timezone: # タイムゾーン
    Asia/Tokyo
  python:   # 言語のバージョン指定(ruby,phpなど)
    version: 3.4.2
  environment: # 環境変数
    TEST_ENV: test

dependencies:
  override:
    - 依存ライブラリのインストールコマンドなど

database:
  override:
    - DBやテーブルを作成したり、サンプルデータを作成するコマンドなど

test:
  override:
    - テストを実行するコマンド
    
deployment:
  deploy:
    branch: master
    commands:
      - デプロイを実行するコマンド

他にも様々なカスタマイズが可能です。詳しくは公式サンプル をご確認ください。

作成したcircle.ymlをリポジトリにpushすることで自動的にビルドが走ります。

また、CIが不要なドキュメントのみ修正などをpushする際には、コミットコメントに[ci skip]と含めることでCIをスキップすることができます。

UIアニメーションについて

開発
新卒デザイナーの小久保です。
 
今回はゲーム内のUIアニメーションについてお話しします。
 
 
UIアニメーションとは
「ユーザーがアクションを起こした時に、視覚的に何が起こったのかを
よりわかりやすく伝える為のもの」だと私は考えています。
アニメーションで表現できるものは様々です。
UIアニメーションの主な役割として以下のものが挙げられます。
 
 
・見てほしいものを強調する
 アニメーションを加えることで画面を華やかにするだけでなく、
 プレイヤーを次の行動に誘導する指針になります。
 (例:イベントボタンにアニメーションを追加することで
    イベント開催中であることをユーザーに伝え、ページへ誘導することができます)
 
・情報をより伝えやすくする
 要素が何か変化する時にその過程を見せることで、
 より変化の因果関係が伝わりやすくなります。
 (例:ユニットの強化で強化素材がユニットに吸い込まれる演出を追加すると、
    ユニットと強化素材の関係をより強調することができます)
 
・見落としをなくす
 目まぐるしく変わるゲームの中では見落としがちな情報もあります。
 見落としやすい数字の変化などもアニメーションを追加し、
 視覚的変化を大きくすることで見落としを防ぐことができます。
 (例:獲得した経験値やコインを既存の数値に足していく演出などで
    どの数字がどこに追加されたのか一目でわかります)
 
・不安にさせない
 ボタンを押したときに何の反応もないとユーザーは不安になってしまいます。
 全ての動作に対して何らかの反応を即座に返すことで不安の防止になります。
 (例:全てのボタンに押したことがわかるような動きをつける)
 
 
アニメーション制作
上記を考慮してアニメーションを作っていきます。
私の所属するチームでは2つのアニメーション方法があります。
・デザイナーがアニメーションツール(SpriteStudio)を使用して作成するもの
・エンジニアさんがUnityで設定して動かすもの
この2つの使い分けは主にデザイナーでしか再現できないか否かと、
容量を割くべきかどうかの2点で判断されています。
f:id:kokubom:20170116011343j:plain
調節と実機確認を何度か繰り返します。
 
エンジニアさんがUnityで動かす場合でもデザイナーがサンプル動画を作成する場合もあります。
エンジニアさんにお願いする場合はコミュニケーションをとりながら、
データの作り方を相談して制作を進めます。
 
 
まとめ
UIアニメーションは画面作りの味付けのイメージがあるかと思いますが、
ユーザー様へ確実に情報を伝えるためにもアニメーションは必要不可欠な要素だと思います。
 今回のブログでアニメーションにも様々な意図があることを知っていただけたなら幸いです。
色々な制約はありますがその中でよりわかりやすくワクワクするものを作っていける様に、
これからも頑張ります。
 
途中に出てきたSpriteStudioについて詳しく知りたい方は
こちらの公式サイトをご覧ください。

www.webtech.co.jp

ユニットキャラクターが完成するまでの工程について

デザイナーの小嶋です。

 

今回のデザイナー記事はイラストが どのように完成するのか です。

以前の記事でキャラクター指示書についてお話ししたかと思います。

キャラクターのコンセプト、デザイン等イメージを固め、その指示書を元に外部クリエイター様がキャラクターを描き上げて行きます。

 

イラストの工程について

 

外注したイラストには全部で3工程存在します。

 

1、ポーズラフ工程

キャラクターのポーズ、武器の位置、エフェクトのイメージを大雑把なラフで描いたもの。

基本的に、顔や髪、衣装は描かなくても良いのですが、イラストレーター様によては描き込んで来られる方もいます。

この工程では、キャラクターのポーズが指示書に沿っているか、魅力的であるかをチェックしていきます。

イマイチな場合は再考及び修正、または当社にて直しを入れて行きます。

 

f:id:t-kojim1982:20161206143211j:plain

 

2、詳細ラフ工程

キャラクターの顔、髪、衣装、武器デザイン、エフェクト等、完成を想像できるレベルまで描き込んだ工程。

この工程では、キャラクターデザインは魅力的か、デッサンに狂いは無いか、指示書指定内容に沿っているか、エフェクトはキャラクターの魅力を損なわず入っているか、全体の配色は属性色をメインに使っているか等をチェックしていきます。

覚醒後のキャラクターの場合は覚醒前よりパワーアップ感があるか、より魅力的になっているかもチェックします。

指示書に沿っていない、デザインがイマイチな場合は再考、修正、または当社にて直しを入れて行きます。

この工程でほぼイラストの出来具合が決まります、非常に重要な工程です。

 

f:id:t-kojim1982:20161206143234j:plain

 

3、着彩工程

詳細ラフを元にレギュレーションに沿って仕上げまで描き上げられた工程です。

雑だった線、陰影、ハイライトは綺麗に整えられます。

この工程では、詳細ラフから大きく変化した所は無いか、アウトラインの配色はレギュレーション通りか、光彩の処理は大丈夫か、塗り忘れやはみ出しは無いか、ゴミが無いか等をチェックしていきます。

それらをチェックし、イラストが完成へと至ります。

 

f:id:t-kojim1982:20161206143259j:plain

 

以上がイラスト完成までのプロセスです。

指示書がクリエイター様に渡って完成に至るまでには様々な段階を踏んで行きます。

クリエイター様の素敵なイラストは社内の厳しいチェックを通り、皆様の前に登場しているのです。

これからもより魅力的なイラストでユーザー様の目を楽しませて行きたいと考えておりますので、今後登場する新キャラクターに是非ご期待下さい!