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

WonderPlanet DEVELOPER BLOG

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

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

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

チームメンバー

現在チームのメンバーは 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のデータ容量を削減する

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の連携について

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

今回は開発でも使っている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

 

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

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

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

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

チーム開発するエンジニアがポモドーロ・テクニックを実践するためのアイデアとツールの紹介

ネイティブアプリケーション事業部サーバエンジニアの桐島です。

先日、社内エンジニアLT会にて、ポモドーロ・テクニックについて発表したところ、 「自分はこんな感じでやってるよー」という意見が出たり、気になっているひとが結構多い感じだったので、ブログにも書いてみます。

ポモドーロ・テクニックとは

Francesco Cirillo さんが、1980年代後半に考案した、時間管理法です。

小休憩を細かく取ることで生産性を向上させる、という考えがベースになっています。

ポモドーロ・テクニックのやり方

具体的な実践方法は以下となります。

  1. やることを決める
  2. 25分後に鳴るようにタイマーを設定する
  3. タイマーが鳴るまでタスクを処理する
  4. タイマーが鳴ったら、短い休憩(3〜5分)をして、1に戻る(これが1ポモドーロ)
  5. 4ポモドーロしたら、より長い休憩(15-30分)をして、1に戻る

とてもシンプルですね。

とは言うものの、ポモドーロは個人の時間管理方法であり、会社組織でのチームワークのための時間管理方法ではないので、ある日突然自分の時間だけをポモドーロ単位で区切っても上手くいきません。

そこで、自分の仕事環境に合った形で実践してみることにしました。

自分流の実践方法

  • ポモドーロ管理対象タスクを絞り込む
    • 自分だけで完了するタスク(他のひとが絡まない範囲のタスク)
    • 今日中に終われば良いタスク(xx時xx分まで、という近々の〆がない)
    • 1ポモドーロ単位(25分)で完了するタスク
  • ポモドーロができる時間帯を確保する
  • ポモドーロの休憩 = 通知系の確認時間 とする
  • 1日の最後のタスクに取り掛かっていて、良い感じに集中しているときは小休憩は不要とする

一日に回せるポモドーロ数は少なくなってしまうのですが、 しばらくこのやり方で試してみようと考えています。

ポモドーロの効果

単純な仕掛けですが、新しいポモドーロを開始すると、このタスクはこのポモドーロ内でやり切るぞ、という心理が働きます。

残り時間が迫ってくると、タスクを完了させるために自然と全力が出ます。

夏休みが終わる前日に凄まじい勢いで宿題をやり切る、あのイメージです(僕は夏休みに入る前に終わらせるタイプでしたが)。

結果として、生産性は明確に向上していると思います。

タスクを25分単位で区切るやり方は初めてなので、まだ1ポモドーロの見積りが良い感じにできていないですが、 小さな休憩と集中を繰り返す方法は自分には合っていると感じています。

ポモドーロするためのサポートツール

Pomodoro Timer on BitBar

BitBarのプラグインです。 シンプルなポモドーロタイマーで、導入も使い方もとても簡単で素晴らしいです。 ポモドーロに取り組み始めるタイミングでは丁度良いツールかと思います。

KanbanFlow

しばらくポモドーロを実践していると、その実績・効果を管理・計測したくなってきます。 それを実現してくれるのがKanbanFlowというツールです。

KanbanFlowの簡単な紹介

一見するとTrelloの様なカンバンツールなのですが、ポモドーロ管理のための機能が揃っています。

例えば、以下の様に、ポモドーロタイマーを開始することができます。

f:id:s-krsm:20161130000032p:plain

開始したポモドーロを停止すると、その理由を設定することができます。 理由の項目は自分でも追加可能です。

f:id:s-krsm:20161130000221p:plain

もちろん履歴も確認できます(ブログを書くタスクが終わらない様子が伝わってきます)。

f:id:s-krsm:20161130000710p:plain

そして、タスク単位の履歴だけでなく、任意の期間での集計も行えます。

しばらく、このツールを使ってポモドーロ・ライフを送りたいと思います!

おまけ

「ポモドーロ」という名称ですが、 Cirilloさんが、時間管理のためにトマト型のキッチンタイマーを使用していたことが由来らしいです。 (トマトはイタリア語で「pomodoro」)

GatlingでWeb APIのシグネチャ検証に対応する

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

認証済みで使用されるWeb APIの多くは、リクエストURLやパラメータをベースに生成したHMACをHTTPリクエストヘッダーに指定することで、サーバーサイドでリクエストの改ざんを検知する仕組みになっています。

応用が効かない負荷テストツールでは、この手のシグネチャ生成をサポートするのが手間な事があるのですが、 GatlingではScalaによってシグネチャ生成処理を自由に書くことができます。

Gatlingは、Java製の非同期HTTPクライアントとして有名なAsyncHttpClient を使用しています。 AsyncHttpClientはシグネチャ生成のためのフック処理をサポートしており、GatlingにおいてもAsyncHttpClientが提供しているSignatureCalculator を実装することで、リクエストの直前にシグネチャを生成し、任意のHTTPリクエストヘッダーに値を設定する事が可能となっています。

SignatureCalculator は以下のような定義になっています。

public interface SignatureCalculator {
  void calculateAndAddSignature(Request request, RequestBuilderBase<?> requestBuilder);
}

第一引数の request には、Gatling DSLで構築したURLやリクエストヘッダー/ボディが設定されています。 この request の値を使用して、シグネチャを生成し、第二引数の requestBuilder に対してシグネチャ用のHTTPリクエストヘッダーを設定することになります。

以下に、一例を示します。SignatureCalculator はsingle method interfaceなので、ここでは関数として定義します。

import javax.crypto.Mac
import javax.crypto.spec.SecretKeySpec
import com.hunorkovacs.koauth.service.Arithmetics

object Utils {

  // シグネチャ生成用秘密鍵
  val secret = sys.env.getOrElse("API_SECRET", "your secret")

  /** シグネチャ生成およびHTTPリクエストヘッダーへの設定 */
  def generateAndAddSignature(request: Request, rb: RequestBuilderBase[_]): Unit = {
    val token = request.getHeaders().get("Authorization").replace("Bearer ", "")
    val signingKey = s"$token&$secret"

    val method = request.getMethod()
    val url = request.getUrl()

    val encodedUrl = Arithmetics.urlEncode(url)
    // getByteDataでbodyのバイト配列が取得できないためボディの文字列からバイト配列を取得
    val body = Option(request.getStringData()).map(_.getBytes()).map(new String(_)).getOrElse("")
    val encodedBody = Arithmetics.urlEncode(body)
    val baseStr = s"$method&$encodedUrl&$encodedBody".toUpperCase()

    val mac = Mac.getInstance("HmacSHA256")
    val key = new SecretKeySpec(signingKey.getBytes("utf-8"), "HmacSHA256")
    mac.init(key)
    val signature = mac.doFinal(baseStr.getBytes("utf-8"))
    // bytes to Hex
    val sigHex = signature.map("%02x" format _).mkString
    rb.addHeader("X-Signature", sigHex)
    rb.addHeader("X-Signature-Method", "HMAC-SHA256")
  }

このgenerateAndAddSignature は、以下のようにして使用します。

  val getPlayerStatus = http("player status")
    .get("/v1/players/me")
    .header("Authorization", "Bearer " + authToken)
    .signatureCalculator(generateAndAddSignature _)  // eta-expansionでメソッドを値にして、signatureCalculatorメソッドに渡す
    .check(status.in(200 to 210))

まとめ

今回は、Gatlingでのシグネチャ検証にどのように対応するかをHMACの生成の一例とともにご紹介しました。

Scalaで自由にアルゴリズムを実装できるのは、Gatlingの強みです。 負荷テスト用にシグネチャ検証をバイパスするのではなく、シグネチャ検証も含めた負荷テストを実施するように心がけましょう。