WonderPlanet DEVELOPER BLOG

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

SpriteStudioでアニメを作った後でも簡単データ整理

こんにちは、デザイナーの木村です。

本日は、少しプログラムを書き換えるだけで簡単にデータを整理できる方法をまとめたいと思います。
プログラムを書き換えると言っても、名称をちょっといじるだけなのでプログラムの知識は一切入りません。


例えばこんな風に、SpriteStudioのフォルダ構成を変更したい場合

変更点1:「common」フォルダ(pngとssceの素材入り)を「kaetai_sozai」にフォルダ名変更

変更点2:ssaeとsseeを新規フォルダ「kaetai_anime」にまとめる

     f:id:wp_harumura:20170804205550p:plain

変更してそのままプロジェクトを開くと、当然エラーでae,ce,eeは読み込めなくなってしまいます。
これを解消するのに、プログラムを書き換えるのが有効です。

解消するにあたり、まずプロジェクトをメモ帳などで開きます。
するとこの様な画面になります。
f:id:wp_harumura:20170804210942p:plain

次に開いた画面を一番下までスクロールしてください。
プログラムの下部に、ssce名,ssae名,ssee名と見慣れた名前が出てくると思います。
ここを書き換えてpjで読み取れる様にします。

【before】
f:id:wp_harumura:20170804212910p:plain

四角で囲った部分の名称を変更します。

【after】
f:id:wp_harumura:20170804213752p:plain

変更点は以下の通りです。

赤枠:ssceが入ったフォルダ名を「common」から「kaetai_sozai」に名称を変更したので、文字列を「common」から「kaetai_sozai」に変更
青枠:ssaeを「kaetai_anime」のフォルダに入れたため、文字列に「kaetai_anime/」を追加
緑枠:sseeを同じく「kaetai_anime」のフォルダに入れたため、文字列に「kaetai_anime/」を追加
紫枠:上記のルールに乗っ取り、文字列を変更

保存して終了です。
ただ、このままだとpngは読み取ってくれません。
pngを読み取れる様にするには、ssceとssaeもメモ帳などで開き、名称を変更する必要があります。
しかし、ssaeが複数存在したりアニメーション上でたくさんのレイヤーを使用している場合、書き換えがかなり発生してしまうため、pngに関してはプログラムを書き換える方法はお勧めしません。
アナログな方法ですが、SpriteStudio上でセルマップの「参照イメージ変更」を行うことをお勧めします。(大体の場合は素材はアトラス化されていると思うので)

これらの作業を行うことで、png以外はプロジェクトを開いてもエラーを吐き出さずにデータを開くことができます。

アニメーションを制作した後にフォルダ構成を変える際に、seやceなどを読み込み直すよりも時間をかなり短縮できると思いますので、お困りの方はぜひご活用ください。

Controller Emulatorを利用してDaydream実機なしでDaydream対応アプリを開発する方法

R&D事業部の近藤です。
今回はDaydreamのコントローラーのエミューレーターの導入方法を紹介します。

Daydreamにはレーターポインターのようなコントローラーが付属します。
WiiリモコンのようにポインターをオブジェクトやボタンなどのUIをクリックしてアプリを操作します。
しかしDaydreamは日本国内ではまだ販売されておらず入手するのはやや困難です。

そこで、Google VR SDKにはコントローラーをエミュレートして、Android端末をコントローラーとして使えるようにできるようになっています。
Daydream本体を持っていなくても開発ができるようになります。

導入前の準備

Daydream導入編の記事を参考にGoogle VR SDKをインポートして、Daydreamが使えるように準備しましょう。

Unity + Daydream開発はじめの一歩(2017.6月最新版) - WonderPlanet DEVELOPER BLOG

コントローラーエミュレーターのアプリのインストール

こちらのページからエミュレーターのアプリをダウンロードできますので、Android端末にインストールしましょう。
https://developers.google.com/vr/daydream/controller-emulator

インストールしたアプリを起動するとこのような画面が表示されます。
f:id:HidehikoKondo:20170707145604p:plain

Touchpad

タッチパッドの触っている部分により方向を判別して操作します。 ダブルクリックするとクリックできます。(本物のコントローラではシングルクリック)

Appボタン

Appボタンのクリックイベントをアプリに送信します。 このイベントをトリガーにして任意の動作をつけることができる。

Homeボタン

顔が向いている方向とカメラの方向がずれているときに、このボタンを押すと向きをあわせます(リセンター)。 本物のコントローラーの場合は、クリックするとDaydreamのホーム画面に戻ります。 長押しするとリセンターします。

Unity側の設定

コントローラエミュレータのプレハブの配置

インポートしたGoogle VR SDKにコントローラーエミュレーターを利用するのに必要なプレハブが含まれています。
「GvrControllerMain」「GvrEditorEmulator」「GvrControllerPointer」の3つを下のスクリーンショットのように配置します。 「GvrControllerPointer」はplayerオブジェクトの子オブジェクトとして配置します。

f:id:HidehikoKondo:20170628124821p:plain

コントローラーの設定

Hierarchyから「GvrControllerMain」を選択して、Inspectorを開きます。
「Emulator Connection Mode」の項目で「USB」または「Wi-Fi」の接続方法を選択します。 f:id:HidehikoKondo:20170627170437p:plain

USB

PCとAndroid端末をUSBケーブルを利用して接続します。
この接続方法でコントローラーを使用するには、事前にadbのパスを通しておく必要があります。

Wi-Fi

Wi-Fiを利用してワイヤレスでコントローラーエミュレーターを使用することができます。
PCとAndroid端末を同じWi-Fiアクセスポイントに接続します。
この接続方法でコントローラーを使用するためには「EmulatorConfig.cs」をIPアドレスを設定する必要があります。
IPアドレスは、コントローラーエミュレーターのアプリの画面上に記載されているIPアドレスを設定します。
f:id:HidehikoKondo:20170627171332p:plain

実行

エディターで実行ボタンを押します。
コントローラーエミュレーターの画面上部が緑色で「Connected」と表示されたら成功です!
コントローラーの傾きに応じてUnityの画面上に表示された白色のポインターが動きます。

f:id:HidehikoKondo:20170627172011p:plain
f:id:HidehikoKondo:20170627172854p:plain

これでDaydeamの実機がない状態でコントローラーの操作をエミュレートできるようになりました。
この記事ではとりあえずポインターが動かせる状態になっただけですが
もちろんクリックやスワイプの操作に応じてアプリ上のオブジェクトやUIを操作することもできます。
そのあたりの実装方法はまた次回の記事で紹介します。

負荷見積りについて

 インフラエンジニアの河井です。
 今回は、イベント時の負荷見積りについて書いてみます。


負荷見積りとは

 負荷見積りには大きく分けて「長期的な見積り」(長期間のサービス提供により増加した取扱データ量への対応)と、「短期的な見積り」(イベントやメディア露出による突発的なアクセス増への対応)がありますが、今回は後者について話をします。

取得すべき監視項目の決定

 AWSで言えば、ELBの時間辺りリクエスト数や、EC2のCPU使用率などの中から、利用すべき項目を抜き出します。たとえば、ELBの時間辺りリクエスト数であれば、以下のようなコマンドを実行することで取得することができます。

$ LB_NAME="LBの名前"
$ aws cloudwatch get-metric-statistics \
>   --namespace "AWS/ELB" \
>   --dimension Name=LoadBalancerName,Value=${LB_NAME} \
>   --metric-name RequestCount \
>   --start-time $(date --date '2 days ago' +%FT00:00:00Z) \
>   --end-time   $(date --date '1 days ago' +%FT23:59:59Z) \
>   --period 60 \
>   --statistics Sum

 必要最低限の項目の情報のみ取得する、という考え方もありますが、現時点では、取得できる項目はできるだけ取得しておく、ただし全てを見積りに使用するわけではない。という考えで見積りをおこなっています。使用しなかった項目は、見積りと結果にずれが生じた場合の資料として使用しています。

基準線の作成

 各項目の情報を取得したあとは、必要な項目ごとに時系列に分け、傾向を取得します。以下に示すのは、複数日のLBへのリクエスト数の平均を取り、グラフにしたものです。日に数回、アクセスの高くなる場所があることがわかります。これを、見積りの基準として使用します。 f:id:kwy:20170728184044p:plain

過去の特異日との比較

 次に示すのは、過去の特異日(青色のライン)と、基準線(橙色のライン)との比較です。Y軸の値が変わってしまったため、縦に押しつぶされてしまっていますが、右側から1/3ほどのところで、青線が跳ね上がっているのが判ると思います。このタイミングでイベント(プッシュ通知や新規クエストの開放、プレゼントの配布など)が発生しています。 f:id:kwy:20170728184108p:plain

 他にも、web/APIサーバーや、RDB, NoSQL等における、CPU,メモリ、ディスク、NW負荷などを併せて確認し、高負荷時の各サーバーの挙動の変化を確認します。

イベント規模の聞き取りと負荷見積り

 負荷に対する各サーバーの挙動がわかったところで、今度はプランナーチームから、今回のイベント規模について聞き取りをおこないます。
 この時のコツは、「できるだけ楽観的な予測を出してもらうこと」です。楽観的な見積もりの結果、想定を遥かに下回る負荷で、サーバー費用が無駄にかかる、と言うのはそれはそれで問題なのですが、サービスを止めてしまうことに比べれば遥かにマシです。サービスを止めてしまうと、現在のユーザーのみでなく、将来のユーザーを得る機会も失うことになりかねませんので。
 聞き取りの結果得られた情報から、イベントの想定負荷を見積ります。

システム増強メンテナンス

 得られた想定負荷と、過去のイベント時の処理量などから、現在のシステム構成で耐えきれるかを計算し、耐えきれないと判断した場合はシステム増強メンテナンスを実施します。これは、場合によっては数十分〜数時間のサービス停止を伴うことがあります。サービス停止が発生する場合は、関係するチームに連絡し、メンテナンス日時の調整やお知らせの発行、メンテナンス後のお知らせなどについて相談します。
 メンテナンスが完了すると、もうあとは当日を待つのみです。


 いかがでしたでしょうか? 実際には、このような見積りをしていても、当日は不安に押しつぶされそうになりながらイベント開始を待っていたりするのですが、それはまた別の話。
 ということで、今回は、こんな風に負荷見積りを行っている、という雰囲気を感じていただければ幸いです。

CircleCI 2.0の正式版がリリースされたので試してみた

始めまして、サーバエンジニアの山脇です。
サーバアプリケーションのテストと開発環境へのデプロイをCircleCIに任せているのですが、最近CircleCIが2.0リリースされたのでどんなことができるのか試してみたのでその内容を書きたいと思います。

1.0と2.0の比較

まず1.0から2.0に変わった点として設定ファイルの配置場所が変わりました。
1.0ではリポジトリ直下の circle.yml に設定ファイルを配置していましたが、2.0ではリポジトリ直下から .circleci/config.yml に設定ファイルを配置するようになりました。
以下で1.0と2.0でそれぞれテストをして動かし、masterブランチの場合デプロイする例(実行するコマンドはただのechoです)を記述してみました。

1.0の書き方

machine:
  python:
    version: 3.4.2
test:
  override:
    - echo test
deployment:
  deploy:
    branch: master
    commands:
      - echo deploy

1.0ではmachineのsetupやtest、deploymentなどをそれぞれ書くようになっていました。
実行順はあらかじめ決められており、上の場合だとmachine -> test -> deploymentの順に実行されていきます。

2.0の書き方

version: 2
jobs:
  build:
    docker:
      - image: python:3.4.2
    steps:
      - checkout
  test:
    docker:
      - image: python:3.4.2
    steps:
      - checkout
      - run: echo test
  deploy:
    machine: True
    steps:
      - run: echo deploy
workflows:
  version: 2
  build_and_test:
    jobs:
      - build
      - test:
          requires:
            - build
      - deploy:
          requires:
            - test
          filters:
            branches:
              only: master

2.0では自分たちでjobsで実行するタスクを定義して、workflowsでその実行順を定義するようになりました。
実際にCircleCIを使っていた際にdeployなどで「このコマンドは何をしているんだ?」という状態に陥ったことが何度もあるのでjobごとにやることを分けるのはすごくありがたいと感じています。

2.0の設定できること

① jobsで定義するjobはmachineとdockerがあります。machineの場合VMに、dockerはdockerのコンテナに必要な環境を構築してstepsの内容を実行します。
dockerを利用した場合にCircleCIのCLIでローカルマシンでの確認もできるようなので便利です。
② workflowsのjobsで実行するjobを呼びます。ここで定義されているjobが実行されるものになります。
(jobsに定義されていないjobを呼ぼうとするともちろんエラーになります。)

version: 2
jobs:
  build:
    docker:                   # ①
      - image: python:3.4.2
    steps:
      - checkout
      - run: echo build
  test1:
    docker:
      - image: python:3.4.2
    steps:
      - checkout
      - run: python --version
  test2:
    docker:
      - image: python:2.7.13
    steps:
      - checkout
      - run: python --version
  deploy:
    machine: True             # ①
    steps:
      - run: echo deploy
workflows:
  version: 2
  build_and_test:
    jobs:                     # ②
      - build
      - test1
      - test2
      - deploy

③ jobsで実行順番を指定したい場合はrequiresにどのjobが終了したらこのjobを実行するかを定義できます。
複数のjobが終了した時に動作されたい場合はリストにjobを追加(④ )するだけです。

workflows:
  version: 2
  build_and_test:
    jobs:
      - build
      - test1
          requires:    # ③
            - build
      - test2
          requires:    # ③
            - build
      - deploy
          requires:    # ④
            - test1
            - test2

②と③、④のように実行順を指定すると左側に実行順が早いものがきます。
実行順を指定しない場合 f:id:YHiroyuki:20170725162240p:plain 実行順を指定した場合 f:id:YHiroyuki:20170725162328p:plain

⑤ 特定のブランチだけで動作させたい場合はfiltersを追加います。
特定のブランチ以外を実行したい場合はonlyignoreに変更すれば指定したブランチ以外で実行が可能です。
ブランチの正規表現を使いたい場合は/でくくって内部で正規表現がかけます。(これは1.0と同じです)

workflows:
  version: 2
  build_and_test:
    jobs:
      - build
      - test1:
          requires:
            - build
      - test2:
          requires:
            - build
      - deploy:
          requires:
            - test1
            - test2
          filters:          # ⑤ 
            branches:
              only: master

↓ブランチを指定した状態で別ブランチをプッシュした場合deployのjobはスキップされます。 f:id:YHiroyuki:20170725162917p:plain ⑥ jobの実行前に「approve」しないと次のタスクを実行しないこともできます。

workflows:
  version: 2
  build_and_test:
    jobs:
      - build
      - test1:
          requires:
            - build
      - test2:
          type: approval   # ⑥
          requires:
            - build
      - deploy:
          requires:
            - test1
            - test2
          filters:
            branches:
              only: master

approve待ちの状態(ユーザがapproveを押すまで待機します) f:id:YHiroyuki:20170725160809p:plain

まとめ
jobとworkflowsを自分で設定できるようになったので必要な機能単位で設定しやすくなった。
実行順を変更しやすいため、ちょっとした入れ替えが簡単になった。
作業前にチェックしたいjobにはapprovalをいれる。

他にもできることはたくさんあるので公式のドキュメントを確認してみてください。
https://circleci.com/docs/2.0/

Cocos2d-x の EditBox で複数行表示する

おつかれさまです。エンジニアの藤澤です。

最近 Cocos2d-x の EditBox で比較的長い文章を入力したいケースがあったのですが、標準の EditBox では複数行表示に対応していないようで、文章が見切れてしまったため少々手を加えて対応しました。今回はそのときの内容を書いてみようと思います。

この記事は Cocos2d-x v3.2 をもとに書いていますが、v3.9 からは標準で複数行に対応しているようです(泣)

f:id:wp-fujisawa:20170718173454p:plainf:id:wp-fujisawa:20170718173502p:plain

下準備

標準の EditBox に手を加えるのに抵抗がある場合、自分の project に EditBox をコピーして標準のものと使い分けるのも手だと思います。必要なファイルは以下のとおりです。

  • extensions/GUI/CCEditBox/CCEditBox.h
  • extensions/GUI/CCEditBox/CCEditBox.cpp
  • extensions/GUI/CCEditBox/CCEditBoxImpl.h
  • extensions/GUI/CCEditBox/CCEditBoxImplIOS.h
  • extensions/GUI/CCEditBox/CCEditBoxImplIOS.mm
  • extensions/GUI/CCEditBox/CCEditBoxImplAndroid.h
  • extensions/GUI/CCEditBox/CCEditBoxImplAndroid.mm

コピーしたらまず namespace を独自のものに変更します。おもに NS_CC_EXT_BEGINNS_CC_EXT_END のところを変更するのと、それに伴いコンパイルエラーになるところを直してあげればよいです。

#define getEditBoxImplIOS() ((cocos2d::extension::EditBoxImplIOS*)editBox_)

のところも忘れずに……。

つぎに、CCEditBoxImpl.h の以下の関数を、自前の EditBoxImpl を返すように変更してやります(iOS, Android とも)

extern EditBoxImpl* __createSystemEditBox(EditBox* pEditBox);

最後に、CCEditBoxImplIOS.h の CCCustomUITextField, CCEditBoxImplIOS_objc が二重定義で怒られるのでいったんコメントアウトしてオリジナルの方を見るようにしておきます(あとで変更しますが)

iOS

iOS では内部的に UITextField を使用しているため、 UITextView を使うように変更します。

- @interface CCCustomUITextField : UITextField
+ @interface CustomUITextField : UITextView

これにあわせて UITextFieldDelegateUITextViewDelegate に変更します。

- @interface CCEditBoxImplIOS_objc : NSObject <UITextFieldDelegate>
+ @interface EditBoxImplIOS_objc : NSObject <UITextViewDelegate>

また、 UITextFieldUITextView で互換性のないところも適宜変更します。

        [textField_ setTextColor:[UIColor whiteColor]];
        textField_.font = [UIFont systemFontOfSize:frameRect.size.height*2/3]; //TODO need to delete hard code here.
-         textField_.contentVerticalAlignment = UIControlContentVerticalAlignmentCenter;
        textField_.backgroundColor = [UIColor clearColor];
-         textField_.borderStyle = UITextBorderStyleNone;
        textField_.delegate = self;
        textField_.hidden = true;
        textField_.returnKeyType = UIReturnKeyDefault;
-         [textField_ addTarget:self action:@selector(textChanged) forControlEvents:UIControlEventEditingChanged];
        self.editBox = editBox;
- - (BOOL)textFieldShouldBeginEditing:(UITextField *)sender
+ - (BOOL)textViewShouldBeginEditing:(UITextView *)sender
- - (BOOL)textFieldShouldEndEditing:(UITextField *)sender
+ - (BOOL)textViewShouldEndEditing:(UITextView *)sender
- - (BOOL)textField:(UITextField *) textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string
- {
-     if (getEditBoxImplIOS()->getMaxLength() < 0)
-     {
-         return YES;
-     }
-     
-     NSUInteger oldLength = [textField.text length];
-     NSUInteger replacementLength = [string length];
-     NSUInteger rangeLength = range.length;
-     
-     NSUInteger newLength = oldLength - rangeLength + replacementLength;
-     
-     return newLength <= getEditBoxImplIOS()->getMaxLength();
- }
+ - (BOOL)textView:(UITextView *)textView shouldChangeTextInRange:(NSRange)range replacementText:(NSString *)text
+ {
+     if ([text isEqualToString:@"\n"])
+     {
+         [textView resignFirstResponder];
+         return NO;
+     }
+     
+     if (getEditBoxImplIOS()->getMaxLength() >= 0)
+     {
+         NSUInteger oldLength = [textView.text length];
+         NSUInteger replacementLength = [text length];
+         NSUInteger rangeLength = range.length;
+         
+         NSUInteger newLength = oldLength - rangeLength + replacementLength;
+         
+         if (newLength > getEditBoxImplIOS()->getMaxLength())
+             return NO;
+     }
+     
+     [self textChanged];
+     
+     return YES;
+ }
void EditBoxImplIOS::setPlaceHolder(const char* pText)
{
-     _systemControl.textField.placeholder = [NSString stringWithUTF8String:pText];
    _labelPlaceHolder->setString(pText);
}

このままだと EditBox の領域外をタップしてもフォーカスが外れないので、platform/ios/CCEAGLView.mm をちょっといじってやる必要があります。

- if([view isKindOfClass:NSClassFromString(@"CCCustomUITextField")])
+ if([view isKindOfClass:NSClassFromString(@"CCCustomUITextField")] || [view isKindOfClass:NSClassFromString(@"CustomUITextField")])

これで入力中のテキストが折り返し表示されるようになりましたが、編集モードを終わるとテキストがセンター寄せ & 見切れてしまいますので、表示を調整します。

    _label = Label::create();
    _label->setAnchorPoint(Vec2(0, 0.5f));
    _label->setColor(Color3B::WHITE);
    _label->setVisible(false);
+    _label->setDimensions(size.width - CC_EDIT_BOX_PADDING * 2, size.height - CC_EDIT_BOX_PADDING * 2);
    _editBox->addChild(_label, kLabelZOrder);
    
    _labelPlaceHolder = Label::create();
    // align the text vertically center
    _labelPlaceHolder->setAnchorPoint(Vec2(0, 0.5f));
    _labelPlaceHolder->setColor(Color3B::GRAY);
+    _labelPlaceHolder->setDimensions(size.width - CC_EDIT_BOX_PADDING * 2, size.height - CC_EDIT_BOX_PADDING * 2);
    _editBox->addChild(_labelPlaceHolder, kLabelZOrder);

これでいい感じに表示されるようになりました。

Android

Android のほうは入力中のテキストは標準で折り返し表示されるので、編集モード以外の表示を調整してやれば OK です。

    _label = Label::create();
    _label->setSystemFontSize(size.height-12);
    // align the text vertically center
    _label->setAnchorPoint(Vec2(0, 0.5f));
    _label->setPosition(Vec2(CC_EDIT_BOX_PADDING, size.height / 2.0f));
    _label->setColor(_colText);
+     _label->setDimensions(size.width - CC_EDIT_BOX_PADDING * 2, size.height - CC_EDIT_BOX_PADDING * 2);
    _editBox->addChild(_label);
    
    _labelPlaceHolder = Label::create();
    _labelPlaceHolder->setSystemFontSize(size.height-12);
    // align the text vertically center
    _labelPlaceHolder->setAnchorPoint(Vec2(0, 0.5f));
    _labelPlaceHolder->setPosition(Vec2(CC_EDIT_BOX_PADDING, size.height / 2.0f));
    _labelPlaceHolder->setVisible(false);
    _labelPlaceHolder->setColor(_colPlaceHolder);
+     _labelPlaceHolder->setDimensions(size.width - CC_EDIT_BOX_PADDING * 2, size.height - CC_EDIT_BOX_PADDING * 2);
    _editBox->addChild(_labelPlaceHolder);

以上です。

Unity ShurikenのSubEmitterを使った季節の風物詩

デザイナーの宮澤です。 

ですね!

といったことでUnityのshurikenを使って簡単な花火を打ち上げようと思います。

テクスチャは用意せず、主にSub Emitterを活用して、

簡単に機能紹介ができたらと思います。

 

1.花火の元を作る。

メニューのGameObjectからParticle Systemを選択します。

f:id:wp_miyazawa:20170706112333p:plain

するとScene内に花火の元(Particle System)が生成されます。

ここから花火っぽくしていきます。

 

2.打ち上がりを作る。

花火の元を準備できたので、早速打ち上げていきます。

作成した状態ですでにたくさん打ちあがっています。

f:id:wp_miyazawa:20170706142739g:plain

ですがこのままだと花火っぽくないので、

尾をひくようにしていきます。

 

まず、Hierarchy内のParticle Systemを選択し、

Sub Emittersにチェックを入れます。

f:id:wp_miyazawa:20170706115807p:plain

チェックを入れると機能がアクティブになり編集できるようになるので、

Birthの右横にある+をポチッと押します。

f:id:wp_miyazawa:20170706115954p:plain

するとSubEmitterBirthという新しいParticleSystemが生成されます。

Sub Emitterは親のParticleをEmitterとして発生するため、

親が動くと発生位置がずれていく、といった感じで

親の通ったところに残って尾を引いているようになります。 

f:id:wp_miyazawa:20170706143109g:plain

ひとまずこの状態で次にすすみます。

 

3.メインの部分を作る。

打ちあがりましたので、次は爆発させます。

前項ではSub EmitterのBirthを使用しましたが、

次はDeathを使用します。

先ほど同様、今度はSub Emitters内のDeathの右横にある+をポチッと押します。

するとSubEmitterDeathという新しいParticleSystemが生成されます。

この段階でSub Emittersの中は下図のようになると思います。

f:id:wp_miyazawa:20170706123025p:plain

 

Deathは親が消滅したタイミングで発生させる機能で、

デフォルトだと親のParticleから球状に新しいParticleが発生します。

f:id:wp_miyazawa:20170706151801g:plain

 

まとめ

以下三段階でSubEmitterを利用した花火ができあがります。

①Particle Systemを作成

②SubEmittersにチェックを入れる

③2つ"+"をポチッ

 

補足

 このままでは花火風のもので終わってしまうため、

次の手順を行うとより花火に近づけると思います。

・花火の元(Particle System)

 -Start Lifetime(寿命)、Start Speed(打ち上がる速さ)の調整

 -EmissionのRateで出る数を調整

 -Color Over Lifetimeでフェードインアウト、色味を調整

・打ちあがっている時の尾(SubEmitterBirth)

 -Color Over Lifetimeでフェードインアウト、色味を調整

 -Size Over Lifetimeで大きさの調整

・最後の爆発(SubEmitterDeath) 

 -Gravity Modifierで重力をつける

 -Color Over Lifetimeでフェードインアウト、色味を調整

 -Size Over Lifetimeで大きさの調整

f:id:wp_miyazawa:20170706142505g:plain

 

shurikenでは多彩な表現が可能です。

たくさんのパラメータが自由に設定できるので、

追々紹介できたらと思います。

クラフィのイラストレギュレーション

クラッシュフィーバー
アートディレクターの磯部です。開発段階のときから
クラッシュフィーバーのデザイン周りに携わっております。

f:id:wp_isobe:20170704185236p:plain

クラッシュフィーバーには1000体以上のキャラクターが登場します。
種族も格好も違う、個性豊かな仲間たちですが、どこかクラフィらしい
ポップさを感じるデザインになっているのではないでしょうか。

キャラクターは多くのイラストレーター様によって描かれていますが、
描いて頂くときに雰囲気がバラバラにならないようルールを定めて、お願いをしています。
(これをイラストレギュレーションといいます)

今回はこのイラストレギュレーションについて説明していきましょう。
これさえ知ればクラフィっぽい絵がかけるかも…!?




■合言葉は「ハッチャケ ワクワク シャレオツ ポジティブ ポップ」
クラフィキャラクターを描くにあたって意識して欲しい言葉、それが
「ハッチャケ ワクワク シャレオツ ポジティブ ポップ」です。
クラッシュフィーバーのデザインは見ているだけでハッチャケていて
ワクワクして、それでいてシャレオツでポジティブでポップな必要があります。
なんのこっちゃという思うかもしれないですが、要するに見ているだけで
楽しくなれるようなデザインを目指しているっていうことですね笑
デザイナーチームはこの合言葉を常に頭に入れて作業をしております!

■デザインは現代感そして仮想空間感
クラッシュフィーバーには様々な服装をしたキャラクターがいますが、
舞台はファンタジーでも、遠い未来のSFでもありません。
明日には実現するかもしれない、現代に限りなく近い未来。
なので新しさを感じつつも、現代にもある服の要素を随所にとりいれています。
逆に着物やチャイナドレス等古くからの伝統を受け継ぐ服には
プラスで現代アレンジをしている場合もあります。

f:id:wp_isobe:20170704185254p:plain

▲和服に現代アレンジをした服の例。

■キャラクターには躍動感を!

キャラクターは今にも動き出しそうな躍動感を感じるポーズを
指定しています。地面を感じさせない、
宙に浮いたポーズもこのレギュレーションから生まれています。
イラストからキャラクターの動きが伝わってきませんか?
f:id:wp_isobe:20170704185251p:plain
▲躍動感を感じさせるポーズに!


■配色はカラフルに!
クラフィのキャラには、赤、緑、青、黄と色が決まっていますが
いかにも赤属性です!というカラーにしてしまうと、
まとまりすぎて、ワクワクした印象でなくなってしまうので、
あまり一つの属性色にとらわれすぎないような配色を指定しています。
言われてみればまぁ赤属性かなくらいの配色バランスになっていたりします。

■キャラクターの線色は赤茶色。
黒だとクラッシュフィーバーのポップな世界には少々きつく
赤茶だとしっくり馴染みますね。
f:id:wp_isobe:20170704185934p:plain

▲拡大してみると赤茶色なんですよ。

■影は二段階 ハイライトは一段階
基本はアニメ塗りとよばれる、色がはっきりわかれた手法で塗られています。
もし1キャラだけ厚塗りだったり、劇画調だったりしたら
浮いてしまいますよね。

■まわりにふんわり光彩を
クラフィは仮想世界ALICEを舞台にしております。
ALICE内のユニットは自由に宙に浮くことができるため、
浮遊感を2Dイラストでだすために、ふんわり浮いているイメージを
キャラクター周りの光彩で表現しております。

■最後にALICEで生まれた証を刻む
キャラクターにはALICEマークというALICEで生まれた証が
ついています。四角いマークの下にユニットIDが刻まれているのがわかりますでしょうか。

例外として、ウイルスキャラクターはバグなどの予想外な電子のひずみから
生まれていたり、どこからかネットを通じて
やってきたキャラクターになるのでALICEマークがついていません。

女王に生み出されたキャラやゴーストのキャラは別のマークがついているので
探してみてはいかがでしょう。

f:id:wp_isobe:20170704185247p:plain
▲ALICEマーク。四角の下にはIDが刻まれています。



このようなレギュレーションを経て
イラストレーター様に素敵にかいていただいた、キャラクター達。
今日もALICEでいきいきと暮らしていますので
是非会いに行ってあげてくださいね!