KLabGames Tech Blog

KLabは、多くのスマートフォン向けゲームを開発・提供しています。 スマートフォン向けゲームの開発と運用は、Webソーシャルゲームと比べて格段に複雑で、またコンシューマゲーム開発とも異なったノウハウが求められる領域もあります。 このブログでは、KLabのゲーム開発・運用の中で培われた様々な技術や挑戦とそのノウハウについて、広く紹介していきます。

こんにちは、makki_d です。

前回の技術書典3に続き、技術書典4でもまたまたKLabの有志で同人誌を頒布しました。 この記事ではその報告をしたいと思います。

前回同様、紙の同人誌の他に、電子版を無料配布していました。 この記事の下部にもダウンロードリンクを用意しましたので、興味のあるかたはぜひご覧ください。

技術書典とは

技術書典は、プログラミングについての同人誌を作成しているサークル TechBooster達人出版会が主催する技術・科学系同人誌即売会です。

ナンバリングイベントの4回目となる今回は、前回と同じく秋葉原のアキバ・スクエアで4/22に開催されました。 晴天に恵まれたこともあり、来場者数6000人超となる一大イベントとなりました。

頒布した本

表紙

今回も執筆者が書きたいことを書いたため、雑多な内容となっています。

  • Cygwin 環境で Docker を快適に使うために
  • Unity で開発しているスマホゲームで Xcode のバージョンアップをする
  • Re:VIEW で書いた原稿の CI を AWS CodeBuild で回す
  • WebAssembly で行列の演算をする
  • Python インスタンスの属性は辞書(dict)で管理されているのか調べてみた

また、次の記事は締め切りに間に合わなかったため、電子版にのみ収録しています。

  • リアルの街を Unity に取り込む 〜GIS へのいざない〜

なお、表紙等のイラストは社内のデザイナー・イラストレーターによるものです。 表紙や裏表紙、当日配布したDLカードに描かれたキャラクターは、眼鏡っ娘率100%という超豪華仕様となっており、 イベント当日も一部の方々に大好評でした。

ブースはこんな感じでした。

ブース

執筆方法

参加の経緯やツール選定については以前の記事を見ていただくとして、 今回もRe:VIEWで執筆し、データをGitHubで管理しました。

さらに、今回はGitHubへのpushをトリガーとしてAWS CodeBuildでPDFを生成し、Slackに共有するというCI環境を構築してみました。 詳細は本誌の「Re:VIEW で書いた原稿の CI を AWS CodeBuild で回す」をご覧ください。

前回からの改善点

表紙に内容を書いた

前回の反省点として、ぱっとみてどんな内容の本かわからないという失敗がありました。 今回は表紙に各記事の内容をそのまま書いてみました。 表紙を見て興味をもって頂いた方も見受けられたので、良い改善でした。

大判ポスターを立てた

スペース前に人だかりができてしまうと、机上に説明書きなどを立てても見えなくなってしまっていました。 さらに前回は、黒文字のみの説明書き自体がそもそも目立たなかったというのも問題でした。

今回は多くの人に見てもらえるよう、表紙を拡大した大判ポスターを用意しておきました。 来場者自体が多かったこともあり、おかげさまでスペース前には常に人がいるような状態でしたが、 ポスターを見て足を止めてくださる方も多かったです。

CIでPDFを生成してレビューの効率を上げた

今回はレビューのフロー自体を変えてみました。 著者は記事を直接masterにコミットしてGitHubにpushします。 するとCIでPDFが生成されるので、レビュワーは最新のPDFを見て、修正案やコメントをPRの形で著者に伝えるという方式にしました。

前回は各記事をGitHubのPRの形でレビューしていましたが、やはり組版された状態のほうが文章のレビューはしやすかったです。

次回に向けて

今回はイベント自体が盛況だったことにも助けられ、新刊・既刊ともに完売することができました。 ただ、無料配布の電子版DLカードのほうも早々に完売してしまい、電子版をお求めの方にはご不便をおかけしてしまいました。 次回以降、本はもちろんのこと特にDLカードも十分な数を用意したいと思います。

また諸般の事情により今回は「かんたん後払い」を受け付けることができませんでした。 次回はどうにか対応したいと考えています。

最後に

KLab有志としての参加は2回目となりました。 イベント自体も回を重ねるごとに盛況となっており、運営の皆様、参加者の皆様、本当にありがとうございました。 これからもKLab有志として参加できることを楽しみにしていますので、今後ともよろしくお願いします。

電子版

ここまで読んでいただきありがとうございました。 電子版PDFダウンロード

はじめまして。普段はiOSを使っているのに開発中はAndroid周りについて見ること多いsuzu-jです。

最近はHuawei製の端末等、国内でも搭載しているSoCがSnapdragonではない端末が増えてきました。 そんな端末でも、読み込まれているテクスチャや、描画順の確認等、グラフィックス周りのデバッグをするために、今回は Mali Graphics Debugger の使い方を紹介します。

対象はCPUがARMでGPUがMaliのAndroidとなります。 x86系統のCPUだとrootedな端末が必要な上、手順が違うため今回の記事では対象外です。

説明は dtab Compact d-02HWindows 上で行いますので、Mac等その他のOSを使っている方は適宜読み替えてください。

なお、大体のアプリに繋げられてしまうSnapdragon系列と違い、こちらは残念ながら自分でビルドするアプリケーションでしか見れません。 むしろセキュリティ的に見えるのがおかしいと思うのですが。

PC側の準備

まずはダウンロード、公式サイトから自分のプラットフォームに応じてダウンロードしてインストールします。

インストール後は Edit->PreferencesPath to ADB にADBのパスを指定しておきましょう。

mgd_adb_path

端末側の準備

端末側にはDebuggerと繋げるためのアプリケーションをインストールする必要があります。

Windowsでインストール先を変えていなければ、 C:\Program Files\Arm\Mali Developer Tools\Mali Graphics Debugger v4.8.0\target\android\MGD.apk があるため adb install でインストールしましょう。

アプリケーション側の準備

アプリケーション側にはPluginを入れる必要があります。

Pluginは C:\Program Files\Arm\Mali Developer Tools\Mali Graphics Debugger v4.8.0\target\android\ 以下に、各CPUに応じたlibMGD.soがあるので、デバッグしたい端末に応じて配置していきましょう。

今回の端末はarm-v7aの端末なので C:\Program Files\Arm\Mali Developer Tools\Mali Graphics Debugger v4.8.0\target\android\arm\unrooted\armeabi-v7a\libMGD.soAssets\Plugins\Android\libs\armeabi-v7a 以下に配置します。

通常であればこれで準備完了となります。

Debuggerとアプリケーションの接続

対象アプリのAPKをインストール後に、PCとAndroidを繋げたまま、Android側の Mali Graphics Debugger を起動しましょう。 Enable MGD Deamon: の項目をONにして下のアプリケーション一覧からDebuggerに繋げたいアプリを起動しましょう。

mgd_android

アプリを起動したらPC側のDebuggerから Debug->Open the Device Manager を選択すると、接続している端末の一覧を開きます。

mgd_test_select_device

接続したい端末名の左にあるアイコンを選択すれば接続完了。晴れて各種描画関連の確認が出来るようになりました!

mgd_test_connected

上手く接続できない場合

Debugger起動前にアプリを開いている場合、うまく接続できないことがあるようなので、アプリのタスクキルをしてから再度開きなおしてみましょう。

Activityをカスタマイズしている等の場合、Activity側にも手を入れる必要があります。UnityPlayernew するより前に System.loadLibrary("MGD"); を呼んであげましょう。 よくわからないけれど使っている外部PluginがActivityを書き換えている、という場合は onCreate をOverrideしたActivityを作ってあげると動くことが多いと思います。

それではよい最適化ライフを!

明日、20日目はやまださんです。よろしくお願いします。

この記事はKLab Advent Calendar 2017の18日目の記事です

皆さんこんにちは、 jukey17 です

私はクライアントサイドエンジニアとしてゲームのプロトタイプを作る仕事を何度か経験しているのですが、今回はその際に体得した自分なりのノウハウをまとめてみようと思います よろしくお願いします

はじめに

この記事では、Unityを使ったプロトタイプ開発をベースに少人数体制(プログラマ・プランナー・デザイナー各1名ずつなど)で開発を進めていった経験を元に話を進めていきます

なのでUnityを使ったゲーム開発の経験がある方を対象とした内容になっています

プロトタイプ開発の仕事での経験ベースの話ではありますが、個人制作や学校・サークルでのチーム製作にも置き換えて考えられるような内容にまとめているので、参考にして頂ければと思います

仕様を素早く実装する → 仕様の変化を先読みした実装をする

最初に どういった考え方でプロトタイプ開発をすべきか というまとめっぽい話から始めます

大枠としてこれを念頭に置いて開発を進めておきたいということが伝わればと思います

プロトタイプ開発は「どのようなゲームを作っていくべきかを模索する」段階であるため、仕様がキッチリと決まっていることはほぼありません

アレを試してみよう、コレを組み合わせてみよう、やっぱりソレは削ろう... このようにして目まぐるしく実装内容が変わっていくのがプロトタイプ開発です

そうなってくるとついつい「とにかく数をこなすために急いで実装しなければ」と考えてしまうのですが、そうしてしまうと使い回しの効かない書き捨て品質なコードを書いてしまいがちになってしまいます

1回実装して終わりであればその実装の速度を重視して書き捨て品質にコードを書いてもよいと思うのですが、プロトタイプ開発では複数の種類の実装をしたり、その中で幾つかの機能を使い回してみたりと、とにかく色々な要素を組み合わせて面白さを追求していくため1回実装して終わりということは絶対にありません

  • 「先週試して外した機能をもう一度復活させたい」
  • 「パターンAで調整したパラメータをパターンBでも使いたい」
  • 「別の機能で使っている演出をとりあえず使い回してほしい」
  • などなど...

プロトタイプ開発では上記のような試行錯誤が沢山繰り返されます(特に後半になればなるほどこのような内容が増えます)

期間内で継続して開発スピードを出すにはこれらの試行錯誤を如何に予測して捌き続けることができるかが鍵だと個人的には思っています

ということで、上記の例を元にこれらの考え方を持ってどのように開発を進めていくのかを紹介していきたいと思います

プロトタイプ開発でありがちなケースとその対応

「先週試して外した機能をもう一度復活させたい」

仕様の定まっていないプロトタイプ開発ならではのよくあるケースの一つです

これをシューティングゲームにて敵を追尾していく弾を発射するという仕様を例に2つのコードを比較してみましょう

  • サンプルコードA
class Player : MonoBehaviour
{
    [SerializeField] GameObject homingBulletPrefab;
    [SerializeField] float homingBulletProgress;
    [SerializeField] float homingSpeed;
    [SerializeField] GameObject homingFinishEffectPrefab;
    
    GameObject homingBulletObject;

    void Update()
    {
        // 追尾弾発射
        if (Input.GetKeyDown(KeyCode.H))
        {
            // 連続では撃てない
            if (homingBulletObject == null)
            {
                homingBulletObject = Instantiate(homingBulletPrefab);
                homingBulletProgress = 0.0f;
            }
        }

        // 追尾弾の処理
        if (homingBulletObject != null && enemy != null)
        {
            homingBulletObject.transform.position = Vector3.Lerp(transform.position, enemy.transform.position, homingBulletProgress);
            homingBulletProgress += Time.deltaTime * homingSpeed;

            if (homingBulletProgress > 1.0f)
            {
                Destroy(homingBulletObject);
                homingBulletObject = null;

                // 着弾したら自機に演出が出る
                var effect = Instantiate(homingFinishEffectPrefab);
                Destroy(effect, 2.0f);
            }
        }
    }
}
  • サンプルコードB
class Player : ShipBase
{
    // 追尾弾の処理は特になし
}

[ReqiredComponent(typeof(ShipBase))]
class HomingBulletFirer : MonoBehaviour
{
    [SerialzieField] HomingBullet homingBullet;
    [SerializeField] float speed;

    ShipBase parentShip;

    void Start()
    {
        parentShip = gameObject.GetComponent<ShipBase>();
    }

    void Update()
    {
        // 追尾弾発射
        if (Input.GetKeyDown(KeyCode.H))
        {
            // 連続では撃てない
            if (!homingBullet.IsActive)
            {
                homingBullet.Fire(parentShip.transform, parentShip.Target.transform, speed, OnLanded);
            }
        }
    }

    void OnLanded()
    {
        // 着弾したら自機に演出が出る
        EffectManager.SpawnPlayerHomingFinishEffect();
    }
}

class HomingBullet : MonoBehaviour
{
    public void Fire(Tranform start, Transform end, float speed, Action onLanded)
    {
        // 弾を発射する処理
    }
}

サンプルコードAでは追尾弾をそのまま自機(Player)クラスに書いていますが、サンプルコードBでは追尾弾を発射するクラスと追尾弾自身のクラスを分けて実装しています

サンプルコードAの場合は表題の対応をする場合は、該当コードをコメントアウトしておいてそれを解除するか、削除しておいてgitなどのバージョン管理システムから掘り起こして復活させなければなりません

サンプルコードBの場合は HomingBulletFirer クラスを Player クラスが付いている GameObject に付けたり外したりするだけで対応が可能です

今回のようなシンプルな実装内容であれば、サンプルコードAのような実装でも一括でコメントアウトするだけでなんとかなりそうですが、もっと処理が複雑になって色んな所に該当コードが散らばっていくとそう簡単にはいかなくなります

サンプルコードBのように 「機能単位でパーツ(部品)を分けておく」 ことで繰り返される試行錯誤にも素早く対応していくことが可能です

Unityではこのようなまとまった処理をパーツ(部品)として扱うコンポーネント指向を基本とした設計がなされているので、サンプルコードBのようなパーツを分けた実装がしやすい構造になっています

実装を進めながらドンドンとパーツを増やしていき、それらを付けたり・外したり・組み合わせたりするだけで素早く沢山のパターンを試せるような状況を作っていくようにしましょう!

「パターンAで調整したパラメータをパターンBでも使いたい」

プロトタイプ開発では複数パターンを用意して遊び比べることが多くこういった話もよくあるできごとです

こちらもシューティングゲームを題材に2つのサンプルコードでどのように対応すべきかを見ていきましょう

サンプルコードA

// 撃てる弾の種類が複数ある・ボムが使える自機
class PlayerA : MonoBehaviour
{
    [SerializeField] int baseHp;
    [SerializeField] int baseAttack;
    [SerializeField] float moveSpeed;
    [SerializeField] BulletType[] usableBulletTypes;
    [SerializeField] int maxBombCount;

    ...
}

// 撃てる弾は1種類で特殊なスキルが発動できる自機
class PlayerB : MonoBehaviour
{
    [SerializeField] int baseHp;
    [SerializeField] int baseAttack;
    [SerializeField] float moveSpeed;
    [SerializeField] float skillIntervalTime;

    ...
}

サンプルコードB

class PlayerParam : ScriptableObejct
{
    [SerializeField] int baseHp;
    [SerializeField] int baseAttack;
    [SerializeField] float moveSpeed;
}

// 撃てる弾の種類が複数ある・ボムが使える自機
class PlayerA : MonoBehaviour
{
    public void Initialize(PlayerParam initialParam, BulletType[] usableBulletTypes, int maxBombCount)
    {
        // パラメータの保持などの初期化処理
    }

    ...
}

// 撃てる弾は1種類で特殊なスキルが発動できる自機
class PlayerB : MonoBehaviour
{
    public void Initialize(PlayerParam initialParam, float skillIntervalTime)
    {
        // パラメータの保持などの初期化処理
    }

    ...
}

サンプルコードAでは2パターンの自機をクラスに必要なパラメータを SerializeField 属性を付けて定義していますが、サンプルコードBではパラメータクラスを用意して初期化処理を呼んだ際にそれを設定しています

どちらのコードも外からパラメータを設定できるようにしている点は同じですが、サンプルコードBではパラメータを専用のクラスに逃している点に注目してください

このようにロジック(自機の挙動を定義する Player) とデータ(自機のパラメータを定義する PlayerParam)に分けることでパラメータの使い回しが容易になります

今回は自機を対象としていますが、シューティングゲームであれば、敵や弾、ボムなどある程度の機能単位でデータを別クラスに逃しておくのをオススメします

このようにして先にデータを切り出しておくことで、ある程度内容が固まったあとにプランナーの人を中心にパラメータ調整を行うといったことになってもスムーズに移行することができます

Unityの場合、データとして扱うために最適化された ScriptableObject やJSONを扱うための JsonUtility などがあるのでそれを活用しましょう!

Tips パラメータを外部から設定できるようにするためには何を使うべきか?

SerializeField 属性(Inspector)を使う

一番手っ取り早いのはサンプルコードAでも紹介している SerializeField 属性を使ってInspectorから設定できるようにする対応です

これは複数パターンを試したり色んなところで使い回したりしないようなパラメータ(ゲーム全体の設定など)を弄れるようにしたい場合に使いましょう

ScriptableObject を使う

SerializeField を使う場合に比べて実装コストは少し上がりますが、サンプルコードBのように複数パターンを試したり色んなところで使い回したりするような場合に効果を発揮できます

一度構造を作ってしまえばデータを複製してパターンも作れますし、そのままAssetBundle化することも可能です

のちのちエンジニアの手を使わずにデータのチューニングをしていくことを見越しておくと先にデータを外部ファイルに逃がしておいたほうがよいです

JSONを使う

利点は ScriptableObject と同じです

最終的にそのデータをどのように取得してくるかを想定して使い分けるとよいと思います

APIを叩いてレスポンスを受け取ってから次の処理に進むようなケースが想定されている場合はデータをJSONで定義しておいたほうが都合が良いでしょう(ステージの難易度情報やデッキの情報など)

「別の機能で使っている演出をとりあえず使い回してほしい」

仮で用意しておき、後から違うものに入れ替えるという状況もプロトタイプ開発ではよくあるケースです

プロトタイプ開発ではゲームの中身をどれだけ面白くできるかに注力して進めていくので、見た目の作り込みが後追いになることが多いです

進め方によってはデザイナーは関与せずにプリミティブなオブジェクト(簡単な記号や図形)のみを組み合わせただけでプロトタイプ開発を行うこともあります

そういった場合でも手戻り少なく実装を進めるにはどうするべきか、こちらもコードを見てみましょう

サンプルコードA

class Player : MonoBehaviour
{
    // HPを回復したときに呼ばれる
    void OnHeal()
    {
        // 回復演出は出しっぱなしにしてそのまま消す
        var effect = Instantiate(healEffectPrefab, transform);
        Destroy(effect, 1.5f);
    }

    // HPがゼロになったときに呼ばれる
    void OnDead()
    {
        if (isDead)
        {
            return;
        }
        StartCoroutine(PlayDeadEffectCoroutine);
    }

    IEnumerator PlayDeadEffectCoroutine()
    {
        var effect = Instantiate(deadEffectPrefab, transform);
        yield return new WaitForSecond(2.0f);

        Destroy(effect);
        // ゲームオーバー処理
        GameOver();
    }
}

サンプルコードB

class Player : MonoBehaviour
{
    // HPがゼロになって死亡演出が完了した後に呼ばれる
    public Action OnFinishDeadEffect { get; set; }

    // HPを回復したときに呼ばれる
    void OnHeal()
    {
        EffectManager.EmitHealEffect();
    }

    // HPがゼロになったときに呼ばれる
    void OnDead()
    {
        EffectManager.EmitDeadEffect(OnFinishDeadEffect);
    }
}

サンプルコードAでは Player クラスに直接エフェクトの発生処理を書いているのに対し、サンプルコードBでは エフェクトの発生処理を EffectManager にお願いする形になっています

自機のための演出になるので Player クラスに処理を書くと言う考え方は間違ってはいませんが、ゲームでの演出処理は「演出が終わったら」や「途中で中断したい」などの複雑な対応をするケースが多いです(そして調整の度にそのタイミングが代わります)

Prefabなどにまとめて全て演出側に処理を逃がせれば理想的ですが、内容がコロコロ入れ替わるプロト開発ではいきなり全ての処理を外に逃がすのも難しいです

そこでサンプルコードBでは EffectManager なる演出の複雑な遷移などをアレコレ吸収してくれる機能を外に用意しました

このようにしておくことで演出の差し替えが後で入ったとしても基本的には EffectManager に手を入れるだけにすることができます

ただし EffectManager をそのままエフェクトを何でも処理してくれる便利屋として扱っていくと今度は EffectManager が肥大化していって整理が難しくなってきてしまうので、その場合は様子を見つつ EffectManager も分割していきましょう

まとめ

ということでここまでつらつらと書き連ねて来ましたが、内容的にはプログラミングを設計する上で気をつけた方がよい基本的な事柄をまとめているということに気づきましたでしょうか

要は プロトタイプ開発であろうと速度重視の書き捨てコードを書くべきではない というのが私の結論です

少人数(1人)で開発を進めていくとついついルーズにコードを書いてしまいがちですが、開発が進んでいけば自分以外の人も多く関わってくることを考えると常に整理しながら開発を進めていけるのが理想です

個人の開発だったとしても、何日か経ったあと自分の書いたコードを見返して何が書いてあるのかよく分からなくなると言う経験はしたことがあるはずです

未来のチームメンバー(自分)が少しでもラクにできるコードを書くように心がけていきましょう!

明日の19日目はsuzu-jさんです。よろしくお願いします。

↑このページのトップヘ