■ TechCon WebサイトURL
https://techcon.dena.com/2021/session/10/
■ Twitterリンク
https://twitter.com/search?q=%23denatechcon%20%23techcon_10
■ 概要
大規模なモバイルゲーム開発におけるリソース管理では、高頻度の動的配信、高速なダウンロード、高速な暗号化と、高速なビルド、リソース解析によるネタバレ防止、柔軟なアドレッシングなど、安定したゲーム運用を高効率で支えるために様々な要求に応える必要があります。
本セッションでは、大規模なモバイルゲーム開発におけるリソース管理へ求められる性質と、DeNAがそれらに対してどのようなアプローチでどのようなモジュール構成で解決を図ったのかを解説します。
■ Speaker：大竹 悠人（Haruto Otake）
2009年にWeb動画配信サービス会社に入社。複数の新規Webサービス、ゲーム機/家電向けのサービスの立ち上げに携わる。2013年にDeNAに入社し、ブラウザゲーム運営、新規ネイティブタイトル開発を経験。成果物の技術資産化を推し進める過程で、ライブラリなどのゲーム基盤開発業務に携わるようになる。現在はゲーム開発者の声に耳を傾けながら、ゲーム開発の課題をより良い、効率的な方法で解決できるような基盤を様々な方面で模索している。
■ tag
#Game
#Unity
#CSharp
#リソース管理
#AssetBundle#HTTP2
Summarize this content in Japanese [音楽] みなさんこんにちは モバイルゲームを支えるり臓腑管理基盤の作り方という題で大竹ハブとが発表させて いただきます 宜しくお願いします このセッションでは unity を対象としてモバイルゲームのリソース管理基盤が 解決すべき課題と dena がとったそれの快慶作について そして基板ライブラリとフレームはこう明確に分離するアプローチとその利点について もお話ししていこうと思います 発表者の自己紹介です大竹ハルトと言います 電飾ではサーバーからフロントエンドまでさまざまな領域でさまざまなサービスを作っ ていました ディーエヌエー入社してからはブラウザやユニティー生のタイトルの新規開発や運用 開発を担当していき 現代では unity 桜の内部ダリア stk の開発 またトラブルシューティングなどに従事しています 早速ですがモバイルゲームのリソース基盤が再掲すべき課題について話していこうと 思います まず課題として存在する者から大きなものを今回は別居してみました まず継続的なゲーム運営のための差分管理 次に巨大な初期ダウンロード 次にアプリバイナリーに組み込むいそう西の対応 次にコンテンツの保護と梗塞などぞの両立 次にアップデート実施までのリソースの人食う 最後に開発の意図 day 3乾速度を紹介しないビルドです 順番に説明していこうと思います 継続的なゲーム運営のための差分間についてです モバイルゲームではゲーム運営のために継続的なコンテンツ追加を行っていく必要が あります 月34回程度のよくあるペースでゲーム内のイベントの運用を行うにはアプリの更新を 伴わないリソース更新が行えることが必須になります これを実現するためにはネットワーク経由で偽装走行開始必要なダウンロード差分を アプリ側がて桐ケ 算出できるような必要があります モバイルゲームの丹蔵数更新の差分はその奥がにソース追加になりますが 既存リソースの差し替えもある程度は発生します 更新を行うタイミングというのが利用者による食べ アップデートの時に一つ前のバージョンになるからとは限りません もっと古いバージョンからアップデートすることもありえます またダウンロード中にアプリが終了されることも考えられるためダウンロード済みか どうかやファイル破損のチェックなどが必要になります 次に巨大な初期ダウンロードの効率化についてです 今のモバイルゲームでは1 gb 以上のダウンロードがインストール後に発生して
しまうということも多々あります ここで利用者に長い待ち時間を教えることはそのまま利用者の離脱にもつながって しまいます またサイズ自体が大きいとお客様も通信容量を 消費してしまいこれも嫌煙される理由になります これに関しては必要に応じてダウンロードさせる戦略もあるのですがこれはピン スタントに利用者の通信容量を消費させるということも意味しています またどうしてもつとつ同ロード画面を挟んだり ダミーの表情挟んで非同期に汗と御膳などを見せ方の工夫が多く必要になります ゲームのイメージを損なうこともありますので全ての場面体適用できるような取得では ありません 次にアプリ by ナニー久美子6造成の対応についてです チュートリアル用など追加ダウンロード間田に利用したいリソースを アプリ本体に組み込みたいという要求が特に ios も app store の 契約問題で 存在します ですが android ios ともにアプリバイナリの子ソースの組み込みには 一定の制限が存在します まず android についてそれぞれのプラットフォームの制限を説明していき ます android では2021年後半から android アップバンドルの適用が 義務化されて ob が新規タイトルでは利用不可能になります obb では人気がバイトまでのアプリを配信可能でしたが a ab では150 mb 以上は配信することができなくなってしまいます これはプレイヤーセットデリバリーという機能に別途対応することで1キロバイトなど のアプリを配信することも可能になります また android ではリソース6組み込み時には典範的に apk のファイル 内部に アーカイブされて格納されるという子なんであるとね
通常のファイルのように扱うことが難しくアクセス手段に大きな制限かかります ios では先ほど申し上げたように app store の規約上 起動時にアップが正しく機能するようバイナリーに十分なコンテンツを含む必要があり ます ですので一般には ios でのモバイルゲームというのはチュートリアルなどを踏む 必要がありかなり大きなサイズで配信することになってしまいます 一方でサイズ的には2 gb まで配信可能ですし 通常のファイルシステムと同じようなアクセスが可能なので純粋な技術的な制約として は android に比べるとゆるいものになっています 次にコンテンツ保護と凹足などの両立についてです 特に他社様の ip を使わせていただくタイトルでは暗号化によるコンテンツ保護の 仕組みが必要です ですが暗号化はどうしても処理としてオーバーヘッドがかかります 特に unity はこれが高くつきがちでした この負荷によってゲームの体感を損なわないようにしつつコンテンツ保護は果たすと いうバランスをとっていく必要があります 次にアップデート実施までのリソースの1区についてです ゲームからまだ利用されていないリソースがダウンロード可能になっているとその理想 その内容を技術なる利用者が解析してくる可能性があります これは俗に言うネタバレ解析 e 9などと呼ばれる行為ですがさまざまなゲームで 実際に行われイベントやキャラなどの情報が公式な情報郊外の前に両者の間で広まって しまうという事態がたびたび起きています 最後に開発のイテレーションを阻害しない人についてですね スムーズなリリースや開発中の試行錯誤のサイクルを早めるために ビズフェアでプロへが素早く実施できることはもちろんモバイルゲームでは運用してき た時間に比例してビルド対象物の数が1000形に増加していってしまうためこれを 見越しておく必要があります ここまででこれだ6点について解説していきました モバイルゲームのにソース管理には多くの課題があることがおわかりいただけたのでは ないかと思います ここかだこれらの解決を行うアプローチについて具体的な事例からお伝えしていこうか と思います 目に dna のアプローチでは基本指針として統合されたひとつのソリューションで はなく課題両機を絞った複数なだいぶダイヤ 文字おりに分割した上で解決を目指していきました そして全体を通して利用側が先ほどの課題がすべて解決できる状態というのを目指して いきました
もし信じそう形で実装さで dena のリゾーツ管理を支える主要大ぶらりがプチ等 になります まず空間効率に優れたにソースのディビジョン感じと暗号化を行う 字事務 次に http 2によるリソースの並列ダウンロードを行う アセットフェっチャー 最後に高速な増分アセットバンドルビルドと労働を行うアブ true になります 順番に改正していきます あた人はファイルベースのリソース管理ライブラリです 特徴としてはアドレスベースのリソースアクセスが可能で 複数のリビジョンのリソースを効率的に保持できまた高速にデプロイすることができ ます また様々な種類のストレージの透過的ありを使い分けが可能で 透過的な暗号化や解析によるえっ 束で防止機能を持っています 7人では特定のリビジョンのリソース全体をツリーと呼んでいます 釣り餌ごとにアドレスを識別子とした仮想的なストレージを持てるようなものになって います このつのようにフォルダのような構造もます+宿霧のアドレスとして指定することが できます このツリーの中ではに像その実態は中身を貼っ集荷されてそのハッシュ値をファイル名 としてブログというものとして保存されますつまり アドレスの名前そのままでは保存されません リソースの識別子であるアドレスとブログの紐付け情報を インテックスという情報として保持することでツリーは成り立っています この図のように a [音楽] 左もアドレスそれぞれのかゆみについて 中身が端っこされて右のようなハッシュ値で保存されています ブロブをな紙の端8時をファイル名として扱うことには大きな意味があります これによって異なるリビジョン間で共通するリソースは同一のブログとして扱って保持 することができます また中身が同じであれば歩となるアドレスを持っているリソースであっても同一の グループとして放射されます これによって水がや変更のあったリソースの分だけのストレージの追加消費 のみで複数のリビジョンのリソースを同時にストレージに保持することが可能になり ます この図のように共闘するリソースは同じファイルを向いていることだわ かと思います 繁栄とハッシュ値がファイル名になるためファイルの上書きが原理的に発生説 イミュ食べるな特性を持ちます今で言うより リビジョンの切り替えは安全か2高速に行うことができます また中身のハッシュ値とファイル名を比較するだけでインデックスを参照しなくても 破損チェックを行うことができます 紐付け情報であるインデックスもまたプロ部と同様にそのシリアライズされた結果の ハッシュ値をファイル名として保存されます このハッシュ値がそのままリビジョンを識別する値にもあります これらのブログやインデックスのご存知電話へ
ハッシュ値の戦闘1バイトでサブディレクトリを作ってそこに格納するようにしてい ます 大量のファイルを一つのディレクトに保存していると大きなパフォーマンス低下を は多くのをボイスで起こしてしまうのですがこの工夫によってこれを開始しています インテックスのシリアライズ時の工夫としてメモリフットプリントの軽減と問い合わせ 速のの両立を目的にフラットバッファーとを使って全体のでしレア大豆を伴わない インデックス情報も問い合わせを可能にしています アドレスは毒14ビットにハッシュ化した上でインデックスに格納することで少ない フットプリントで高速な比較を可能にした上でフラットバッファーとにデータ構造とし てアドレスのハッシュで相当したリストとして各アドレスの情報を格納しておくことで 最低限の領域ので白大豆のみで フラッターファンのデータを直接二分探索が行えるようになっています モバイルゲームの運用のために複製のにビジョンを比較した様々な操作を行えるように しています intex 同士の追加変更差分の特定やインデックスに含まれるがストレージに存在 しないブルー冒涜をできるようにすることでダウンロードが必要なり造成やその正しい ハッシュ値を簡単に取得できるようにしています また複数の保持すべきビジョンを指定することでどのツリーからも保持されなくなった ブログを特定し削除することができるようになっています これによってリビジョン更新子に必要ななくなった風土位にソースを削除することが できるようにしています ツリーを生成してから配信するまでの簡単な手順を説明してみます まず用意している cli ツールから釣りの形式にいそうそう変換します この変換結果は特定のディレクトリに測れるのでこの 変換結果をディレクトリごと cdn にデプロイするだけでデプロイ作業は完了し ます アプリ側ではデプロイ先のベース言われると最新のリビジョン番号から インテックスの url を特定してダウンロードします このインテックそういう見込んでダウンロードをまだしていないグループというのを 撤去してそのブログをすべてダウンロードします こうすることでつ理由を読み込むことができるようになります デプロイに関してはアラジンは非常に効率的なでプレイが可能なようになっています 以前にデプロイしていないブログのみを検討するだけでよい作りになっているため 極めて高速なで黒いが可能です 上書きが発生しないという特性によってサーバーに存在するファイルというのは転送 する必要がないということを小できるので この不拘束デプロイを実現することができています google クラウドストレージであれば gs utilities cp の ハイフンへのオプションを使うとサーバーに存在しないファイルのみの転送を簡単に 実現することができます またデプロイ先のサーバーでも同時にさせるのリビジョンを効率的に保持することが できるようになっているため てバック用途でも便利になっています
プロフだの弓書でのストレージのアクセスは抽象化をした上で様々な種類のストレージ でノーアクセスを提供しています デコレーター的に使えるような実装もあるためアプリバンドルしたリソースと ダウンロードしたりそうそう透過的に効率的に使い分けることができます 対応するストレージの種類としては通常のファイルシステムはもちろんのこと android でのストリーミング assets やプレイヤーセットデリバリー などにも対応しています プレイヤーセットデリバリー対応では google play アプリプラグインず for unity という google 提供の便りを利用しています これによって兄がセットパック9に保存したアラジンの3を読み込めるようにしている んですが プレイヤーセットデリバリーは非圧縮でリソースが格納されるうえ プラグインからリソースの実態があり彼はファイルパスとそのオフセットサイズという データとして られます これを生かしてアクセス範囲を制限できる5ストリームに包んで実装し 展開処理を行うことなく少ないオーバーヘッドで読み込めることができるようにしてい ます 具体的な複数ストレージ対応の利用例としては アナジェンのデフォルト挙動にもしているこのようなシナリオがあります まずアプリに同梱されているそうそういう全室 必要であればキャッシュの透過的なコピーを行い もしアプリに同梱されていない場合は 書き込み可能なファイルシステムから読み込み書き込みは無条件に書き込み可能な ファイルシステムに対して行うというものです ここまで行うとアプリ道交法藏須藤ダウンロードリソースを支えてが意識しなくても 完全に透過的に扱うことができます この利用例での具体的な構造を図で表してみました 読み込みと書き込みを分離するリーダー大ターヤ ファイルパスが提供できなかったり飼育できないにそうそうキャッシュするキャッシュ 度リーダーなどもデコレーター実装を使って3種類の具体的なストレージを使い分ける ようになっています 用途に合わせて細かなカスタマイズも行なえるようになっています リソースの読み込み手段をストリームと落ちているのを生かして 透過的な暗号化手段を提供しています 暗号化の実装の適宜入れ替えが可能なようになっています 標準ではランダムアクセス可能なストリーム暗号を提供しており アセットバンドルロード from ストリームという api を利用する要件を 満たすように実装しています これを活用するとアセットバンドルの暗号化利用時にも ちゃん蔵人が可能になります
実装は c #での総合運用製等速度の両立のためアンセーフでかつアドケーション フリーな実装として術をしていて 増としに暗号化の悪影響がほとんど確認できないぐらいのパフォーマーパーツを現在 発揮できています 混合魚の高速化のためバースト塩対応も検討しています 単に暗号化をするだけではなく解析によるネタバレ防止機能も備えています ネタバレの原因はクライアント内に隠した 単一の鍵を海賊されて公開されたリソースの暗号化が解かれてしまうことが主要因とし てあります 難読化などの手段対応を行っても基本的には時間を稼ぐ手段にしかならず 鍵が一度は別れた時点で突破されてしまいます ですので一般的には url を何度かしたりそもそも利用会社の直前までゲームか ダウンロードさせないことで解決することが多いです でとか鍵をクライアントが知ることが不可能な状況であれば 解析体制はアンコウ完了後リズムの強度に従うことにできます そこでアラジンでは暗号化鍵を複数扱えるようにし鍵自体もツリーとは独立して配布 できるようにしました リソース前には鍵 id が指定され弾タイムでツリーから取得できるのはこの鍵 it の女になっています 鍵愛に2000紐解く実際の書情報というのは別途利用開始前に公開されたものを取得 し公開済みの鍵は独自のキーストアに格納して利用するようになっています これによりイベント開始前に入りそうそう開封しても鍵がわからないのでアドごりずむ 自体を攻撃しない限り海賊が難しくなります 鍵のサイズはにソースよりも当然小さく固定的なものなのでリソース自体の公開 タイミング制御人も柔軟な生協が可能になります ここまでで継続的なゲーム運営のための差分管理 アプリバイナリに組み込む利倉西の対応 コンテンツ保護と法則などの両立 アップデート実施までのリソースの1区 この4点の課題を解決することができました 次のモジュールの話に移っていきたいとおもいます アセットフェっチャーは高速な並立リソースダウンローダーです 特徴として http 2によって高速に並列ダウンロードが可能で 様々な配信方式に対応できゲームエンジンを問わず利用可能というものになっています ダウンローダーとして 指定されたリソースをしてストレージに展開することというのに特化した実装になって います 入力として url と保存先と想定するハッシュ値の組をのリストというのを受けて これらをまとめて並列にダウンロードした上で結果の破損判定やリトライを行い保存先 にそれぞれを展開するということをまとめて行います そもそもリソースんダウンロードが必要なのかどうかというのは一切アセットフェっ チャーでは判定しないようにしており 今回の組み合わせではこれらはすべてアラジンがはで判定しています
Http 2が高速に並列ダウンロードができる理由はさまざまありますが大きな ところとして http 2が1接続で並列に大量のリクエストとレスポンスの やり取りを効率的に行えるためです 1ファイルの受信が終わってから次のリクエストを送って受診し始めるまでの時間を 短くできるので高速にダウンロードが可能になります このため特に小さなたファイルの大量のダウンロードでは非常に強いという性質を http つは持っています 九大でも1ファイルに10分なのであパイプすることで転送効率を高めることができる のですが 化野ようにアワー解剖を行わないような前提の配信方式と http 2の相性は抜群 で大きな効果が挙げられます 具体的なダウンロード速度をアラジンのツリーデータを使ったサンプルで比較してみ ました この例では2万個の動きドバイとのファイルをダウンロードした時の時間で計測してい ますが http 2による並列化のありなしで8倍もの時間差が出ていることが分かります http 1では163票ですが http 2では20秒近くで完了しています 注意点として http 2時の配信にあたってはサーバーがきちんと http 2 に対応していることを確認する必要があります cdn であれば基本的には問題ないのですか エンジン x などでリバースプロキシを挟んで ip 制限などを行った場合に たと http 2に一応対応していたとしても速度が低下してしまうということが 起こることがあり得ます これは嵐んとの組み合わせでは利用しない機能なのですが 10パー5の対応もしています これを利用するとダウンロードした十方順番に保存先ディレクトリに展開するところ までの処理をダウンロードしながらを順次を行ってくれるのでパー5されたパッチを 順次適用していくような方式でもカバーすることができます またジップだけでなく独自のアーカイブ形式にも対応しておりこれを用いるとリソース 前に圧縮の有無を選択した上で10符 同様の運用が可能になります
またリップカール o バックエンドとして sheep ラプス+デビュー実装して いるため unity 向けにはネイティブプラグインとしてのインターフェイスをかぶせるよう な形にしています このような作りのため unity はもちろん内製エンジンを含むその他のエンジン でも問題なく利用可能なようになっています プラットフォームとしても mac os windows linux ios android のエディターも含めた後プラットフォームに対応しています これで巨大な初期ダウンロードという課題を解決することができました 最後のモジュールの話に移っていきたいとおもいます アブドゥールはアセットバンドルブレード等労働を行うだいぶだりです 特徴として vcs ベースな校少ないインクリメンタルビルド機能を持ち シンプルなドレッシングと最適化される時柱の角6管理が可能です また厳密な重複廃城ポリシーを持ち リソースマネージャーベースの柔軟な労働機能も持つものになっています アブルールではアドレス油セットシステムの一部のモジュールだけを使っています アドレスサーブルのバックエンドであるリソースマネージャーと スクリプタ振るビルドパイプラインを利用 ています あとは道土状況を見えるイベントピュア なども利用していますですがアドレスサーブルの本体でのアセットバンドル管理機能や ビルド機能は利用しないようになっています あブルーでのインクリメンタルビルはスクリプター full build パイプラインを使ってカスタムした custom build パイプラインて実現しています きっとから移転のビルド以降で変化したセット王子の2ストを取得して アセット間の依存情報をもとにビルドする必要のあるアセットバンドルを特定したうえ で実ビルドを行い カタログを差分更新します ギッとへの依存の部分は抽象化されて差し替え可能なようになっているので きっと以外の他の vcs にも容易に対応できるようになっています セット前にグローバルがアドレスを設定しアドレスバブルのようなシンプルな ドレッシングでのロードができるようになっています カタログファイルのシーラーない図形色にはフラットパフワードを採用して
アロケーションを極力回避していて 特にアセットでは 大量の文字列を持つアドレス子が使うことになるのでこれを奇数木として共通化して 埋め込むことで効率的な保持を可能にしています またそもそもアセットの読み込みでは1列のハッシュ値のみを原則として扱うことで 文字列比較をほとんど行わずにカタログでの労働を行うことができるようになってい ます アセットバンドルを扱う際には容易にアセットバンドル館でのはセットの重複が起きて しまい しばしば深刻なパフォーマンス問題を引き起こします アドレスサブ土を使うときにはアナライザーを用いて重複を検知することができますが 独自に使う 作る場合にはその代替策が必要になります そもそもビルド中のすべてのアセットに対して所属するアセットバンドルが1位に 定まるのであればこの問題というのは発生しません アブドゥールでは所属するアセットバンドルが1円にた黙らないアセットがビルドさ れようとすると枝を出して修正をすぐさま促すようにしました 具体的なアセットバンドルの合成はインターフェイス経由で実装を外部注入する形に なっています これをパックルールと呼びバンドル名とファイルパスと アドレスのクムのリストを返したりそれらに関するいくつかの逆引きの問い合わせも 可能なことを要求しています フォルダファインでパッキングする親父何実装などは標準で用意していますが増えもや ワークやゲームがーでのポリシーに合わして個別に実装して対処することを前提として います アセットバンドルのロードはこのように時計たという実装を用意して実現しています リソースマネージャーに登録されたプロバイダーという実装が実際の読み込みを行うの で 時計たに読み込みたいアセットのアドレスを渡すことで 誓たは標準のプロバイダーを正しく利用できるように情報を載せたロケーションを生成 して利用側に返します 依存するアセットバンドルは透過的にどう動画されるように時計ションの依存関係とし て構築した上で返しています このロケーションオープリソースマネージャーに渡すことで利用者はリソースをロード することができます どうとされたセットの管理はにソースマネージャーの管理機構をそのまま利用してい ます このためリソースマネージャーリリースに堂々開始時に得られるハンドルを渡すだけで 開放を行うことができます 複数の箇所から同じアセットを要求された場合にもリソースマネージャーが自動的に 参照カウントを行ってくれるため利用側が意識する必要はありません アセットバンドルの解放処理は所属する焦っ等を全て開放した時点で 自動的に開放されるためこれも意識する必要はありません エディターでの確認時にはアセットバンドルでなくそのまま元は窃盗アセット データベースからどうぞーしできないと非常に効率が悪くなります これはロケーターの差し替えによって実現できるようになっています この際にはカタログを使わずに直接パックルールを利用して実装に問い合わせることで 動くようになっています 暗号化を行う際アセットバンドル道土 from ストリームという api を使う ことでストリームかだアセットバンドルをロードすることができます これを用いると固定長の内部バッファの商品のみで高速なランダムアクセスを行って
くれるため メモリフットプリントや暗号化の計算量を大幅に削減することができます 移転ではブルーが場で暗号を実装していたのですが今はこれを廃止して アラジン川の暗号化ストリームを扱うことで透過的に実現しています あが人経由での濃度時には専用の時計たに加えて専用の独自プロバイダーを利用します 枚分のアセットバンドルを読み込む際には通常のプロバイダーを用いるのですが暗号化 されたものを扱う際には専用のプロバイダーが仇人経由でストリームを取得し アセットバンドルロード from ストリームでアセットバンドルを読み込みます この使い分けを行うのはへ アセットバンドルロード from ファイルが利用可能な状況であればこちらの方が う 軽量で改です これで開発のイテレーション速度を阻害しないビルドという課題を解決でき全ての課題 を解決することができました ですが複数のライブだによって課題解決を提供する際の問題点として 設計に柔軟性を持たせ幅広ユースケースで対応できるということはユースケース毎に それらに落ちた引数など情報を注入しなければならないということにつながるという ものがあります 多くのタイトルにこれらを投入していくにあたってはこれらのライブラリを仲介する ような層が必要になってきます これは内政負0正区の一部であるシャレン理想シーズを直接的なフロントエンドとして タイトルには利用してもらうことで実現しています 今回の3モジュールを中心に他の基板モジュールを組み合わせてよりユースケースを 絞り込んだフレームワークとして実装されています このフレームワークの中で時給が9人のイテレーションを改善する仕組みも実装してい ます これがデバッグファイルシステムというものです いそうそう実機確認する際には いそうそうアプリに組み込んだりサーバへのアップデートとダウンロードアップデート と 等ダウンロードが必要で 調整しながら実機確認を行わなければならないと言う 事態の時には非常にイテレーションが回し暗く そのような場合に開発効率が大きく低下してもてしまうという問題があります これを pc 上のにそうそう実機から直接参照してしまうということで解決してい ます これを用いると usb 接続した pc 上のリソースを実機のリソースのように 透過的に扱うことができます 今回紹介したライブラリを利用した際の全体な的な構成はこのようになっています ゲームタイトルがは車輪偽装手術を使うだけで 会のモジュールの恩恵を受けることができます 先ほどもデバッグファイルシステムのバックエンドである vfs デブは嫌というも順については去年の私の鉄コンの公園で解説をしていますの で興味がありましたができそちらをご覧下さい
理容師の攻勢をさらに別の図で表してみたものがこちらになります アセットワームルールでアセットバンドルにビルドされこれが仇人でツリーとして構築 されて cdn にアップロードされます クライアントではサーバー課題られたにビジョンに従って ツリー大アセットフェっチャーデータうんろーどしアセットのロード要求に応じてアブ ズールが仇人を経由して焦っとバンク読み出し アセット or ブーブが返します 最後にだいぶライトフレームワークを分離していく利点について話そうと思います まずこれによってフレームワークを導入していなくても部分的に成果を取り入れること が可能になりました 実際に車輪偽装シーズを使わない時でも 今回説明したライブラリの導入に成功しています またアセットフェチャーに関しては比喩に聞いタイトルでも導入することに成功してい ます 次に問題を小さなポンプで再現可能になることがあります 切り分けさえ行えば問題のあるも十分のみに集中でき自動テストもしやすいので問題 解決が容易になります またライブだり元責任範囲が限定的かつ明確になります それぞれを単純化でき柔軟性を担保することができます また向き合う領域が単純である方がそれぞれで尖った設計を行って競争力を持った機能 を開発することができると考えています またゲーム側での決めになるような部分というのを フレームワークがに委ねることができるのでだいぶだりが意思決定の速度的なボトル ネックになるというのを避けることができます まとめです モバイルゲームのリソース管理機版にはさまざまな課題があります dena では役割を絞って尖った機能性と柔軟性をもったさまざまなだよぐらいを 開発して課題解決を行いました なおかつ分かりやすいインターフェースのフレームワークそうを提供することで使い手 側にも行き沿っています 以上で発表を終わりますご静聴ありがとうございました ご視聴いただいた皆様こちらのセッションはいかがでしたでしょうか 今後の改善に役立ててまいりますのでぜひアンケート回答への協力をお願いいたします 本日 2021年3月3日にアンケートご回答 いただいた方の中から抽選で某計110名さまにご覧いただいている商品をプレゼント いたします 多くのセッションを主張してたくさんアンケートに回答いただくほど当選確率がアップ しますのでぜひ他の折衝もご覧ください また dna ていくコーン全体についてのアンケートにもぜひご回答ください 今後 dna はエンジニアブログや df テック本ミニなどで様々な技術情報を 発信してまいります
Twitter で at dna 9ステッつをフォローすでぜひ 最新情報を受け取ってください mobility テクノロジーズは配車アプリ go はじめ 交通事故削減や走行データ活用にも取り組み技術の力で交通を今まさに 自身が外れています mot の180名以上のエンジニアから技術情報をお届けしています こちらのツイッターアカウントもぜひフォローください皆様ご視聴いただきありがとう ございました
