使いやすい API 設計

2016年12月5日公開 2019年5月22日更新

これはドリコム Advent Calendar 2016 5日目です。

1 自己紹介
2 内容
3 ドリコムのAssetBundleダウンロードシステムの紹介
4 ドリコムのAssetBundleダウンロードシステムのAPIの紹介
- 4.1 APIのまとめ
5 API設計で開発しやすかった話
- 5.1 開発したものと要望が乖離しなかった
- 5.2 テスト駆動開発のような形で開発ができた
6 まとめ

自己紹介

こんにちは。クライアントアーキテクト部の広井です。

クライアントアーキテクト部では、主に各ゲームプロダクトで共通に使う機能・仕組みの開発を行っています。

内容

今回はまずドリコムのUnity向けゲーム開発基盤で開発しているAssetBundleダウンロードシステムについて紹介します。

次に、AssetBundleダウンロードシステムのAPIを紹介します。使いやすさを考えてAPI設計をしていたという話をします。

最後に、API設計が開発を助ける意味でも重要に感じたという話をします。

ドリコムのAssetBundleダウンロードシステムの紹介

ドリコムでは既存のAssetBundleダウンロードシステムを参考に、AssetBundleダウンロードシステムを独自に開発しています。既存のものからの変更点を中心に、ドリコムのAssetBundleダウンロードシステムの紹介をします。

事前知識:Asset, AssetBundleとは

Assetとは、ゲームで使用される個々のアイテムを表すものです。 AssetBundleとは、いくつかのAssetを1つのファイルにまとめたものです。 AssetBundleは、Assetのダウンロード利用を簡易化するために用います。

ゲームでAssetを利用する際には、まず目的のAssetを含むAssetBundleファイルをダウンロードし、その中から目的のAssetをロードして利用します。

既存のAssetBundleダウンロードシステムについて

Unityがデモとして公開しているAssetBundleダウンロードシステムがあります。

https://bitbucket.org/Unity-Technologies/assetbundledemo

動作の概要は下図のようになっています。

こちらの実装が利用可能か検証しました

ドリコムでもこちらの実装を使うことを考えていましたが、検証の結果いくつか要件に合わないところが見つかりました。要件に合わなかった点は以下です。（一部抜粋）

配信サーバにドリコムで独自の処理を加える必要があったのですが、その拡張ができなかった。
ファイル解析からAssetを保護するために、暗号化の仕組みを加える必要があった。

この結果から、ドリコムでは上記を解決したAssetBundleダウンロードシステムを開発することになりました。

ドリコムのAssetBundleダウンロードシステムについて

AssetBundleダウンロードシステムを独自開発をすることになりましたが、動き方のベースは既存のAssetBundleダウンロードシステムを参考にしています。

主な変更点は以下です。（一部抜粋）

ファイル解析からAssetを保護するために、配信するファイルは暗号化済みAssetBundleファイルにしています。
配信サーバが独自実装になったため、クライアントのダウンロード処理の中も大きく変わっています。

動作の概要は下図のようになっています。既存のものとの差は、配信サーバからダウンロードするファイルが暗号化済みAssetBundleファイルになっている点です。

ドリコムのAssetBundleダウンロードシステムのAPIの紹介

ドリコムのAssetBundleダウンロードシステムの内容は前項目までの通りです。このシステムを実際にゲーム開発で使うために用意したAPIを紹介します。

APIのまとめ

実際にAssetを利用するために用いるLoadAssetがあり、 LoadAssetの実行時間を短くするための事前ダウンロードやメモリキャッシュがあるという形になっています。利用者はこの3つのAPIを組み合わせて利用することで、実行速度の観点で良いパフォーマンスを実現できるようになってあります。

API設計で開発しやすかった話

最後にAPI設計がされていて、開発がしやすかったためその話をします。主に以下の2点でメリットを感じました。

開発したものと要望が乖離しなかった

今回のAssetBundleファイルのダウンロードシステムは開発に着手する前に、ゲーム開発チームへどのような要望があるのかをヒアリングしてAPIを決めていました。

その結果、実際に開発したものとゲーム開発チームの要望が乖離することなく開発を進めることができたと感じています。

テスト駆動開発のような形で開発ができた

今回は機能の実装前に公開するAPIとその機能が固まっていました。そのため、APIを実験する環境を作ってからその中の処理を実装するということが可能でした。

APIが正常に実行できるようにと意識して開発をするため、必要な実装が明確にわかる状態を維持することができたと感じています。

まとめ

以前ゲーム開発チームにいたときはライブラリを利用するときぐらいでしかAPIを意識することがありませんでした。

クライアントアーキチームに移り、APIの中を実装するようになって改めてAPI設計の重要性を認識し、今回の記事を書かせていただいた次第です。

これからは自分もよいAPI設計ができるように、今回の内容を忘れないようにしようと思います。