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

WonderPlanet DEVELOPER BLOG

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

クラッシュフィーバー リジェクト事例

iOS

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

ご存知の通り、iOS の App Store でアプリを公開するためには Apple による審査が必要です。 クラッシュフィーバーもリリースから 1 年以上経ち、何度もアップデートを繰り返してきましたが、その間、審査のリジェクトも何度か経験してきました。数えてみたら これまで 28 回のアップデートを行ない、8 回もリジェクトされてました。 今回はその中の一部の事例と、どのように対応したかを書いてみたいと思います。

スクリーンショットの過度な装飾

iTunes Connect 上でアプリの紹介用にスクリーンショットを 5 枚まで登録できますが、目を引くように派手な装飾や煽り文句を載せることも多いかと思います。クラッシュフィーバーでもデザイナさんがあれこれ苦労してかっこいいスクリーンショットを作ってくれていたんですが、これが "3.3 – Apps with names, descriptions, screenshots, or previews not relevant to the content and functionality of the App will be rejected” に引っかかってリジェクトされてしまいました。 正直どこまでが OK でどこからが NG なのかよく分からないのですが、実際のゲーム画面が極力隠れないようにスクリーンショットを作り直してもらったところ、審査を通過することができました。

なお、こういったメタデータでのリジェクトの場合、審査に出し直す(iTunes Connect 上で審査提出ボタンを押す)しなくても、問題解決センターで直接返信するだけで再度審査してもらえます。むしろ、そのほうが再度審査に出すよりも早く見てもらえます。

メンテ中で審査できない

サービスの運営上メンテナンスは避けて通れませんが、運悪く審査のタイミングがメンテナンスにぶつかってしまうと、「ゲームが始められない」と言われてリジェクトされてしまうことになります。特定のバージョンのみアクセスを許可し、それ以下のバージョンはアクセスを弾くような仕組みは用意しておきましょう。

また、忘れてしまいがちなのが、ベータテスト実施後、そのバージョンをそのまま審査に出す場合です。この場合、ユーザさんの手元にあるバージョンと審査用のバージョンが同じになってしまうため、上記のような仕組みが使えませんので注意が必要です。この場合、バージョンを上げて審査に出し直すことになるかと思います。

課金アイテムをどこから購入するか分からない (1)

課金アイテムを新規に登録する場合、その課金アイテムに対して審査が入ることになりますが、それがゲーム内のどこから購入できるか分からないということでリジェクトされてしまったことがありました。このときは簡単な画面遷移図を作って送付したところ、「親切な説明ありがとう!」というメッセージとともに審査を通してもらえました(笑)

ちなみに、こういった不安がある場合、あらかじめ「App Review に関する情報」のメモ欄に説明を書いておくとよいようです。もしくは課金アイテムを登録するページの「審査メモ」欄。

課金アイテムをどこから購入するか分からない (2)

上記に関連して、期間限定のセール商品を登録する場合、一般ユーザさんには見せるわけにはいかないが、審査用には表示する必要が出てきます。これについても、メンテナンスの件と同様、特定のバージョンのみ購入できるような仕組みを用意しておきましょう。

再現性の低い不具合

「最初のダウンロードが途中で止まって先に進まない」と言われてリジェクトされたことがありました。しかし社内では再現できず、何度かやりとりしたものの進展ありませんでした。仕方ないので「こちらではちゃんと動いているんですが……」ということで動画を撮って送付したところ審査を通してもらうことができました。同じような不具合が起きている方がいましたらすみません……

番外編

ところで、iOS の審査でのリジェクトは有名な話(?)ですが、android でも一度リジェクトされたことがありました。正確にはリジェクトとは違いますが。

Google Play Developer Console 上にセキュリティアラートがつくことがありますが、ここで警告されている対応期限までに問題を解決しないと、それ以降のアップデートがブロックされてしまいます。一見ふだん通りアップデートできたように見えますが、数時間後にアップデートがブロックされた旨の警告が表示されるので注意が必要です。また、一度アップデートがブロックされてしまうと、修正版をアップロードした後も数時間待たないと警告が消えません。内心あせりますが、落ち着いて待ちましょう。

クラッシュフィーバーの場合は OpenSSL の脆弱性について警告を受けたのですが、Cocos2d-x 自体と、それとは別のライブラリ内で OpenSSL が使用されており、一方を対応して安心していたところ、もう一方が引っかかってしまいました……。

$ unzip -p YourApp.apk | strings | grep “OpenSSL"

のコマンドで確認できますので、しっかり確認しておきましょう……。 ちなみに、Cocos2d-x の場合は external/curl ディレクトリの libcurl で OpenSSL が使われておりますので、以下から最新版を取ってくるなどして対応するとよいかと思います。

github.com

開発でのデータ整理について

効率化

デザイナーの木村です。主に3D関連の業務を行っています。
今回は簡単に思えてなかなか上手くいかない、データ整理のことについてお話しします。

1 :現場ではこんなことが…

ゲーム開発は基本的に複数人で行うため、
ファイルの共有やデータの受け渡しなどを日常的に行います。
ところが関わる人が増えれば増えるほどデータの整理は難しくなっていくのです。

  • フォルダ階層がやたらと深い!
  • 新しいもの、古いものの判断がしづらい!
  • 同じ名前のファイルがここにも!あそこにも!


誰が見てもどこに何が保存されているのか、わかるような整理の仕方が難しい。
ワークデータやファイルを保存しておく場所が散らかっているのは問題です。

『必要なデータを探し当てるのに無駄な時間がかかってストレスがたまる!』

2 :ルールがないから無法地帯と化す

というわけで、必要なのはレギュレーションの作成です。
命名規則についてはしっかりと資料化することで皆の意識が高まり、
フォルダ管理する際も綺麗な並びになります。


▼例
アイコン素材なら必ず頭文字に「Ico」を付ける
背景素材なら必ず頭文字に「BG」を付ける、など

こんな感じの素材であれば
f:id:wp_hkimura:20160910220027p:plain…Ico_Star_01.png
というように、共通ルールとともにわかりやすい命名をする(+番号)というのもおすすめです。


あとはフォルダの管理です。
複数人で触るから問題なわけであって、一旦ひとりの人間がまとめることによって
わかりやすく使いやすいフォルダ構造を構築することができると思います。
そして、なるべく早い段階で情報共有できるような場を設けることも大事です。

3:まとめ

効率の良いゲーム開発をするためには命名規則やフォルダ振り分け規則など、
レギュレーションを決めた上で作業し規則を守ること。思いやりをもって整理整頓することが大切です。

Adobe Creative Cloudで制作工数をゴリゴリ削ろう

Adobe

どうもこんにちは、デザイナーの大鹿です。

今回はバナー制作における工数削減対策の一つ「Adobe Creative Cloud」について

お話させていただきます。

 

クラッシュフィーバーは他アプリと比較してみると

バナーの使用数が飛び抜けて多いプロダクトだと感じています。

新ユニット追加とキャンペーンが被ると、そこだけで60点以上の

バナーを制作した時もありました。

(しかも諸事情により制作日数は限界まで削られる場合がほとんどです)

これらを納期通りに各部署へお届けするためには

いかに制作工数を短縮するかが重要となります。

 

Adobe Creative Cloud(以下CC)Adobe社が提供するクラウドサービスです。

PhotoshopillustratorなどAdobe製品を通じてグラフィック素材や

レイヤースタイル、カラーコードをクラウド上の「ライブラリ」フォルダに

保存・共有することができます。

ウェブデザインやDTP業界ではお馴染みのサービスですが

同じ流れを汲むバナー制作でもかなり活躍してくれます。

 

f:id:ooshika:20160912013000p:plain

例として、こちらが私のライブラリフォルダの中身です。

上の小さいサムネがカラーコード、下の大きいサムネはレイヤースタイルです。

 

f:id:ooshika:20160912112737p:plain

そして汎用グラフィック素材です。

ライブラリの中身はPhotohop上でこんな感じに表示されます。

f:id:ooshika:20160912112800p:plain

 

使用方法も簡単で、レイヤースタイルはレイヤーを選択して

サムネをクリックするだけで適用されます。

グラフィック素材はツールウィンドウからドラッグするだけで

配置することができます。

配置されたオブジェクトはCCと紐付いており、CC側のデータが更新されると

紐付いたすべてのオブジェクトも更新されます。

 

そしてCCは自分のライブラリを他ユーザーと共有することができます。

CCツールのメニューから「共同利用」を選択すると・・

f:id:ooshika:20160912020628p:plain

 

Adobeのマイページが立ち上がり、共有させたいユーザーを招待することができます。 

f:id:ooshika:20160912020930p:plain

 

ライブラリを共有しておけばサテライトオフィスの方や外注先の方も

レギュレーションに沿った共通の演出、素材が利用可能となります。

ただし注意点が一つ。

先ほど「配置したオブジェクトはCCと紐付いている」と書きましたが

不用意にCC側のデータを変更したり削除していしまうと

ライブラリを共有するすべてのユーザーが影響を受けてしまいます。

(制作PSDを開いた途端、素材が差し替わってしまう!などなど)

当たり前のことですが、ライブラリを触るときは

連絡を密にして大惨事にならないよう気をつけてください。

 

導入初期だけはデータを掻き集めたりと、手間がかかりますが

一度動き出せばとても頼りになるサービスです。

皆様もぜひ触ってみてください。

iOSアプリをビルド無しで再署名の方法

iOS

ブログを担当する戸田です。今回はiOSアプリ(iPAファイル)の再署名について紹介していきます。

iOSアプリの開発を行っていると「Apple Developer Program」の証明書にて有効期限が設定されているため、証明書の期限が切れてしまうとiOSアプリを利用することができなくなります。iOSアプリを再利用するには、証明書を更新後に再ビルドを行う必要があります。そのため、ビルドに時間が掛る場合やビルド環境がない場合でも行える方法になります。

iPAファイルを展開する。

「unzip」コマンドで、iPAファイル(sample.ipa)を展開します。

$ unzip sample.ipa

Entitlementsファイルを作成

「codesign」コマンドから再署名に必要になるentitlementsファイルを作成します。

$ codesign -d --entitlements :- Payload/Sample.app > entitlements.plist

Provisioning Profileを更新

Apple Developerから更新したProvisioning ProfileをDownloadをして、「cp」コマンドを利用して、Provisioning Profileを上書きします。

$ cp -p Sample.mobileprovision ./Payload/Sample.app/embedded.mobileprovision

再署名を実施

署名には「codesign」コマンドを利用します。また、証明証の設定は、「'iPhone Developer: XXXXXXX'」の部分に適応したい証明書の名称を設定します。

codesign --force --sign 'iPhone Developer: XXXXXXX' --entitlements entitlements.plist 'Payload/Sample.app'

コマンドの実行後にreplacing existing signatureと表示されたら再署名の成功になります。

Zipで圧縮

iPAファイルはZipで圧縮したファイルのため、「zip」コマンドを利用してiPAファイルを作成します。

$ mkdir new-ipa
$ zip -ry new-ipa/Sample.ipa Payload

その後、iPAファイルをデバイスにインストールして、アプリが利用出来るようになります。

FirebaseをAndroidで使う(導入編)

Android

ブログ担当の佐藤です。

今回は Firebase というクラウドサービスの紹介と実際にAndroidに導入したお話を書かせていただきます。

 

Firebaseとは、mBaaS(Mobile Backend as a Service)というクラウドサービスの1つです。

Firebaseの特徴は、オンラインでサインアップできることとリアルタイム同期型データベースであることです。

 

これを利用してチャット機能もできるみたいです!

また、スマホアプリでプッシュ通知やAnalytics、クラッシュレポートやログイン時の認証機能なんかもできるみたいです!盛りだくさん!

 

* 導入編

Androidでの導入はとても簡単でしたw

 

1. Firebase登録をする

https://firebase.google.com/

↑こちらから登録をします。

 

f:id:wp_sato:20160906121206p:plain

Googleアカウントでログインし、上記URLを開くとこんな画面が出てくるので「GET STARTED FOR FREE」ボタンを押して登録します

 

f:id:wp_sato:20160906121514p:plain

 

2.プロジェクトの作成 

f:id:wp_sato:20160906121738p:plain

次に「新規プロジェクトを作成」ボタンを押して新規プロジェクトを作成します。

プロジェクト名を入力し国を選択するとプロジェクトが作成されます。

 

f:id:wp_sato:20160906122236p:plain

 

 プロジェクトを作成すると↑のような画面が出てきます。

今回はAndroidを選択しました。

 

3.アプリに追加

f:id:wp_sato:20160906122658p:plain

 選択するとアプリ詳細を入力するダイアログが出てくるのでパッケージ名を入力し、「アプリを追加」ボタンを押します。

ボタンを押すと、google-service.jsonのダウンロードが始まります。

 

f:id:wp_sato:20160906122920p:plain

f:id:wp_sato:20160906122944p:plain

 

その後は表示されるダイアログの指示にしたがってアプリの設定をしていきます。

説明がすごく丁寧でわかりやすい(°▽°)

 

ダイアログの指示にしたがって変更した設定ファイルがこちらです

 

firebasetest/build.gradle

buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:2.1.3'

// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}

// ↓を追加
buildscript {
dependencies {
// Add this line
classpath 'com.google.gms:google-services:3.0.0'
}

}

allprojects {
repositories {
jcenter()
}
}

task clean(type: Delete) {
delete rootProject.buildDir
}



firebasetest/app/build.gradle

apply plugin: 'com.android.application'
android {
compileSdkVersion 24
buildToolsVersion "21.1.2"

defaultConfig {
applicationId "com.example.firebasetest"
minSdkVersion 21
targetSdkVersion 24
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}

dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
testCompile 'junit:junit:4.12'
compile 'com.android.support:appcompat-v7:24.2.0'
}
// ↓を追加
apply plugin: 'com.google.gms.google-services'

 

青字のところを追加しました。


以上でAndroidでのFirebase設定は完了です。
すごく簡単でした!

今度何かしらFirebaseの機能を使ったアプリを作ってみたいなと思います(°▽°)

 

【Unity 5.3】コルーチン変更点

Unity C-Sharp

クライアントエンジニアの乾です、今回はUnity5.3でコルーチン周りでの変更点
について書きたいと思います。

1:コルーチン内からのコルーチン呼び出し

5.3以降はコルーチン内の呼び出しはStartCoroutine()が省略する事が可能に
なりました。
これによりMonoBehaviourを継承していないクラスでも扱いやすくなりました。

// 5.3以前の書き方
public IEnumerator Coroutine(MonoBehaviour monoBehaviour){
    yield return monoBehaviour.StartCorouitne(Coroutine2()); 
}
// 5.3以降の書き方
public IEnumerator Coroutine(){
    yield return  Coroutine2() ;
}

2:追加クラス(WaitWhile、WaitUntil)

WaitWhileWaitUntilが追加されました。
これらが追加された事によってコルーチンを書く時に多用していた処理が簡略化されました。

// 5.3以前の書き方
private IEnumerator WaitCoroutine(){
    // 条件b1が満たされている間は待機
    while (b1) {yield return null;}
    // 条件b2が満たされるまで待機
    while (!b2) {yield return null;}
}

// 5.3以降の書き方
private IEnumerator WaitCoroutine(){
    // 条件b1が満たさている間は待機
    yield return new WaitWhile (()=>{return b1;});
    // 条件b2が満たされるまで待機
    yield return new WaitUntil (()=>{return b2;});
}

3:カスタムコルーチン

Unity 5.3 から追加されたCustomYieldInstructionを継承する事で、独自のコルーチンを楽に定義することが可能になりました。

// 例:対象が非有効化するまで監視するコルーチンクラス。
public class WaitForDisable : CustomYieldInstruction {
    // 監視対象
    public GameObject target{ get; private set;}

    /// <summary>
    /// 待機継続条件
    /// </summary>
    /// <value><c>true</c> if keep waiting; otherwise, <c>false</c>.</value>
    public override bool keepWaiting{
        get{
            return target.activeSelf;
        }
    }

    public WaitForDisable(GameObject target){
        this.target = target;
    }
}

使用例

IEnumerator Coroutine(){
    // 対象オブジェクトが非有効化になるまで遅延
    yield return new WaitForDisable (target);
    Debug.Log ("Complete!!");
}

よく使うような遅延条件はクラス化してしまった方が見やすいかもしれません。
以上5.3でのコルーチン周り変更点でした!!

ゲーム仕様について責任を持つ

開発

こんにちは、開発プランナーの岩柿です。

クラッシュフィーバーの仕様企画/作成の業務を行っています。

 

「ゲーム仕様について責任を持つ」というタイトルは、クラッシュフィーバーの

プロジェクト体制図の「開発プランナー」の概要に書かれている文言です。

この一行の文を初めて見た時は、

『サラッと書いてあるけど、とても重要な事が書かれている・・・』と、改めて責任感を感じました。

 

ワンダープラネットに入社する前までは、

ゲームのUIや仕様などについて、さほど深く考えるという事はなかったのですが、

何故こういうUI配置なのだろう?何故わざわざこんな制限を付けているのだろう?

など、ゲームの設計や仕組みについて、仕様の目的や意図を考える癖が付きました。

 

・仕様を考える

仕様を考える際に、留意する点は様々ありますが、特に自分が留意している点を紹介します。

 

1.仕様の目的を汲み取り、最短で目的を達成する

  仕様を切るにあたって、まず目的があり、目的の達成手段として仕様が存在します。

  最短で目的を達成する為には、目的がブレないように、

  仕様を切る事が重要になります。(常に目的と照らしながら仕様作成します) 

f:id:iwagaki_001:20160817170454j:plain

2.各チームとの連携

  仕様は、自分の考えや一存だけでは作れません。

  プロデューサーとの擦り合わせは元より

  ・実現可能かどうか

  ・工数はどれぐらい掛かりそうか

  ・他の仕様に影響はないか

  など、各チームとコンセンサスを取りつつ進行します。

 

  これをしっかりやっておかないと、

  実装時に想定外な問題/課題が浮上したり、考慮が足りていない個所が出て来たり、

  いわゆる「仕様変更」が発生してしまう場合があります。

  こういうケースを減らす為に、最初に仕様を切る時は、

  各所としっかり擦り合わせを行いつつ進行する必要があります。

f:id:iwagaki_001:20160817172112j:plain

 

・フラッシュアイデア

様々な作成予定の仕様リストの中に「フラッシュアイデア」というものがあります。

これは、工数や影響範囲などはあまり考慮せずに、直観や感覚で感じた

『こういう機能があると嬉しい』『こうするともっとよくなるのでは?』

といったアイデアのリストになり、Trelloで管理しています。 

 

「あると便利そう」から「是非実現したい」まで、様々な幅広いアイデアが沢山ある為、

優先順位を決め、順番に対応を行っています。

 

また、クラッシュフィーバーのスタッフからは、

KPIに関わりそうなものや、ユーザビリティ向上に影響を及ぼしそうなものなど、 

コアゲーマーならではの鋭いフラッシュアイデアを貰う事も少なくありません。

f:id:iwagaki_001:20160817175625j:plain

 

・まとめ

 ・常に目的に照らしながら、仕様を作成する。

 ・各チームとのコンセンサスを取る。