DeNA TechCon 2018に行ってきました
DeNA TechCon 2018に行ってきました。
聴講したセッションは以下の通りです。
- Keynote - エンジニアが引っ張るDeNAの"モノづくり"
- SWETの取り組むImage Based Testing
- 大規模ゲーム開発におけるBuild高速化と安定化
- DeNA TechCon2018 ゲーム体験を支えるための強化学習
- 世界へ向けたゲーム開発 ローカライズ支援ツールLION
- DeNAのネイティブアプリにおけるサーバー開発の現在と未来
- 全体的な感想
内容を改めて振り返りつつ、レポートとしてまとめていきたいと思います。
※あくまで自分がメモした内容を書き連ねているものであり、
各タイトル下のリンクにあるスライドの内容が正しいものとなります。
Keynote - エンジニアが引っ張るDeNAの"モノづくり"
概要
DeNAの歴史を振り返り、それぞれのシーンでエンジニアがどのような挑戦をしてきたかという話。
また、掲げているミッション・ビジョンに合せてエンジニアのあり方、モノづくりをどう捉えているか語られていた。
- ミッション
- Delight & Impact the World 世界に喜びと驚きを
- ビジョン
- インターネットやAIを活用し、永久ベンチャーとして世の中にデライトを届ける
DeNAの歴史を大きく分けると以下の3つ
EC, SNS
- ビッターズ、モバオクの開発
モバイルゲーム,ゲームPF
Mobageの開発
- エンジニアがサービス設計を主導
- 使いやすさに拘り抜いて開発
- 川崎氏が1人で3ヶ月で開発
- 1人のエンジニアがサービスを考え抜いて開発をしていくことが理にかなっている
- 要件定義から実装まで、1人で考えながら手を動かすことでスピードも出る
- もちろんサービスの規模が大きくなれば1人ではカバーしきれなくなるが、
最初に動くものを作る上では1人で考え抜く方が早くちゃんとしたものが作れる
Mobageの負荷分散
- トラフィック急増に伴い、1日あたり20数億PVが発生
- MHA for MySQLの技術的挑戦(MHA for MySQLとDeNAのオープンソースの話)
- サービスを止めずにメンテナンス可能に
-
- ブラウザでネイティブ並みの表現を
- グラブルでNative並みの表現を実現したWahid(GitHub - DeNADev/wahid: A CreateJS-compatible library for games)
- 5fps -> 30fps
- CreateJSとの互換性を維持
- 端末、OS、ブラウザーの差異を吸収
事業多角化
タクベルの開発
自動車事故削減に向けたCV技術を活用
- Deep LearningベースのCV技術
- CVをエッジ(車載端末)で動作させる組み込み
- 運転行動指標を算出するデータサイエンス
- 安全運転コーチングに向けた危険予知
- Deep LearningベースのCV技術
まとめ
- サービスづくりをエンジニアが引っ張る
- いいモノづくり = Delight につながる
- サービスの課題を高い技術力で解決
- サービスの拡大 = Impact につながる
感想
- 市場において先行する、あるいは他にない規模のサービスを展開する上で技術的な挑戦は不可欠。
- いかなるサービスも最初はプロトタイプ開発からであり、エンジニアが主体となりスピード感とこだわりを持って開発するべき。
- サービスの種類やフェーズによって問われる技術やエンジニアとしてのスタンスは少し異なるが、
いずれにしても技術によって課題解決を図ること、サービスを考えながら開発に取り組むことが重要なのだと思った。
SWETの取り組むImage Based Testing
概要
DeNA社内でテストの自動化やエンジニアの生産性向上のためのツールの開発・導入などを行うチームであるSWETが、 どのような技術開発を行ったかについての事例紹介。 以前からDeNA TechConなど社外発表の場において技術開発事例紹介をしてきたが、 今回はWeb ApplicationとMobile Game(Native Game)におけるImage Based Testingについての紹介。
SWETのミッション
- DeNAのサービス全般の品質向上
- エンジニアの開発生産性向上
Web Applicationにおける事例紹介
WebApplicationにおけるVisual Regression Testingの紹介
既存のVisual Regression Testingに関するサービス
- browserStack(Cross Browser Testing Tool. 1000+ Browsers, Mobile, Real IE.)
- 多様な端末、ブラウザ上でのキャプチャ取得が可能
- Applitools(Automated Visual Testing | Applitools)
- 過去画像との差分を表示してくれる管理コンソール
- browserStack(Cross Browser Testing Tool. 1000+ Browsers, Mobile, Real IE.)
Visual Regression Testingの課題
スクリーンショットクローラ
- 自律的にサイト内を巡回・テスト対象ページを見つけ出す
- モチベーション
- UIテストに詳しくなくても自動テスト管理できるようにしたい
クローラ利用の流れ
並列化
クローラ部分のシステム構成
- zalenium(GitHub - zalando/zalenium: Allows anyone to have a disposable, flexible, container based Selenium Grid infrastructure featuring video recording, live preview, basic auth & online/offline dashboards)
- WebdriverIO(WebdriverIO - WebDriver bindings for Node.js)
- クローラ側ではスクロールバーやクリックすみリンクなどの差分は検出しないように作り込みをしている
画像差分の確認
- githubの利用
- masterブランチに正解データを入れ、masterとの差分を目視で確認
まとめ
課題
- フォーム入力
- サイトごとにカスタムロジックをかく→最初の問題に逆戻り
- フォームを検出して自動で埋める技術が必要
- 同一ページ内の状態変化
- 取得したいキャプチャは1ページ1枚とは限らない
- レンダリング結果の違いを自動で検出する
- フォーム入力
- 展望
機械学習によるUIの意味認識
- 意味に基づくエレメント取得
Webページの意味解析技術
- 先行研究 Using Semantic Similarity in crawling-based web application testing
- HTMLをパターン認識して、UIエレメントの意味やページ状態を推定する
会員登録フォーム意味推定
- 精度としては大体100%近くから50%くらいまで
- 全結合三層のNN
- 深層学習ではない
- トピックごとに精度の差があり
- 生年月日はselect boxなので判別しやすい
- userIDはサービスの名前が入ってきたりもして判別しづらい、など
- ポップアップなどのパーツへの拡張
- 学習データの拡張と深層学習の適用予定
Mobile Gameにおける事例紹介
※ ゲームアプリ = Mobile Game(Native Game)
ゲームアプリのUIテスト自動化の現状
- web/ネイティブアプリはテスティングツール・ライブラリやノウハウが整備されており、UIテストの実装を行いやすい
- ゲームアプリに対してはそういったデファクトのツールやプラクティスが整っていない
ゲームアプリのUIテスト自動化の難しさ
画像処理技術を使って自動化
- Open CVのテンプレートマッチング
テンプレートマッチングとは
- 特定の画像パターン(テンプレート)が存在するかを判定
画像処理を使った自動化へのハードル
- 画像処理および画像処理ライブラリに関する知識の習得
- 画像処理に向いた言語の習得
- イメージアセットの管理
- 閾値のチューニング →これらの面倒なところを省力化するためExMachinaを開発
Exmachina
- テスト用イメージアセットの管理
- ページ単位、ページ情報という形で管理する
- 識別子(Identifier)とどのような操作が可能か(Action)を管理
- ページの判定機能
- 画像データをインプットとしてそれがどのページに該当するのかを判定
- セマンティックな情報を使ったテストが可能
- ページ判定機能を使ったテストシナリオの自動化
- テストシナリオは簡易に記述できるようにしてある
- 画像処理やAction実行といった複雑な処理はバックエンドで吸収
- テスト用イメージアセットの管理
シナリオテストの自動化からクローラへの応用
- テスト用イメージアセットの管理(Identifier, Action)から、現在どのページにいるか、どのようなアクションが行えるかを取得可能
- クローリング結果の比較
- 画面遷移の差分と、ページの画像的な差分を取れる
- 意図せぬUIの変更や、エラークラッシュの検出が容易になる
まとめ
- アプリのページ情報を管理する
- セマンティックな情報に基づいたテストを実現
- バックエンドで画像処理など複雑な処理を吸収するため、画像処理を意識せずにテストプログラムを組める
- ゲームアプリに対してもVisual Regression Testができる
課題
- ページ登録作業(テスト用イメージアセットの情報登録作業)の省力化
- 複数解像度への対応
対応
- semantic segmentation
- 画像内の各画素がそれぞれどのオブジェクトクラスに属するのかを分類するためのアプローチ
- ネイティブやウェブアプリでセマンティックな情報を取得し、それを学習データとして、ゲームアプリを解析させる
- pix2code(GitHub - tonybeltramelli/pix2code: pix2code: Generating Code from a Graphical User Interface Screenshot)
- 画像からxml/htmlに起こしてセマンティックな情報での解析に繋げる
- semantic segmentation
全体まとめ
- Web ApplicationとMobile GameそれぞれにおいてImage Based TestingによるUIテストの自動化を行った
- 今後、さらなる自動化・省力化のために機械学習を活用していく
感想
- それぞれの事例において個別のプロダクトに依存しない汎用的な形、かつ利用者にとって導入コストが低くなるように作られていて素晴らしかった
- 品質・生産性の向上を図る上で自動テストの存在はもはや欠かせないものだが、その維持コストを極小化するために機械学習の導入というアプローチが取られるのは手段としても技術的にも興味深い話だと思った
大規模ゲーム開発におけるBuild高速化と安定化
概要
大規模化するゲーム開発においてビルドの高速化、安定化には大きな価値がある。 ビルドの高速化、安定化のためのUnity、Jenkinsにおけるプラクティスの紹介と、 その他自動化、ワークフロー改善事例の紹介。
大規模複雑化するスマートフォンゲーム開発の課題
- 高品質かつ多機能
- 短いスパンでの機能、イベントの提供
- 特にアセットの容量が肥大化、ビルド時間が膨大に
- ライトからコアユーザーも遊べる複雑なゲームスキーム
- グラフィックスも2Dから3Dへより高品質へ
複数のGameイベントを週替わりでリリース →お客様を飽きさせないために様々な取り組みを並行で走らせなければならない
生じる問題
- コンテンツ・Asset大容量化→ビルド時間が膨大→毎日QAを回せない→品質が悪い→お客様に満足してゲームをPlayしてもらえない
Build高速化は非常に価値がある
- try and errorを回しやすくする
- QAを回しやすくする
Buildを高速化して課題を解決(Unity・Jenkins)
- Unityプロジェクトのリポジトリをキャッシュ
- AssetBundleの差分Build
- 分散・並列Build(プラットフォーム、開発案件ごと)
その他
- スペックが高いマシンでbuildしているか
- 対象ノードでウィルススキャンが実行されていないか
2,3についてUnity/Jenkinsの実践を交えて紹介
最大のボトルネックはUnity AssetBundle Build 差分buildで高速化しよう
- Unity AssetBundle Build高速化方法
- 一度buildしたAssetBundleファイルと同時に生成されるManifestファイルをgitで管理する
Unity側でManifestファイルをみて高速化してくれる - Assetは更新すべきファイルだけ、差分でbuildする
- フォルダの差分を検出するのは単純ではない
フォルダに含まれるアセットが別フォルダの共有アセットへ依存している - 共有アセットを含めフォルダの差分を検出したい
- 一度buildしたAssetBundleファイルと同時に生成されるManifestファイルをgitで管理する
- Unity AssetBundle Build高速化方法
EditorUtility.CollectDependencies()を使うことで共有Assetも差分検出できる
(AssetBundle 対象のフォルダついて、Asset の依存関係も含めて実ファイルのハッシュ値を計算する · GitHub)- AssetBundle対象フォルダは以下の各種Asset + Assetが依存するすべてのアセットファイル → フォルダ内のすべての実ファイルハッシュ値が計算できる
このようにあらゆる高速化を組み合わせる必要がある
Jenkinsを活用した分散・並列Build
- Jenkins Master/Slave全体構成
- Jenkins masterへの命令通知
- 各Slaveでの処理
Client Build, AssetBundle Build, Master validation, preprocess, migration, deploy, etc... - アプリのupload, githubへの自動コミット, BaaSのデプロイ
- 並列開発をしていると、キューが詰まるため、案件・ブランチごとにslave nodeを分ける
- Jenkins Master/Slave全体構成
Jenkins - Platformごとに分散Build
- Build Flow pluginのparallelブロックを使うことでノードごとに分散・並列実行できる NodeLabel Parameter Pluginを利用
- Nodeごとに同じJobは同時に一つだけ実行できるようにしたい場合はThrottle Concurrent Builds Pluginが使える
Jenkins - 同一開発ブランチで排他制御
- Masterを扱う処理は同一開発ブランチで安易に分散並列ビルドすると不整合が起こる
- 開発ブランチ単位で排他制御しつつ並列実行、高速化が必要
- Groovyでコードを書いて排他制御できる (Jenkins – 同一 branch を Groovy を使って排他制御 · GitHub)
DeNAのゲーム開発はSakashoを使いサーバレスアーキテクチャが主流に
Baasを用いると開発効率は上がるが、migrationについては別アプローチが必要
- 手動オペレーションが入ると障害が発生する
- データマイグレーションの最適化・徹底した自動化が必要
- 4つのフェーズでマイグレーションを最適化、自動化を徹底
merge → validation/build → migration → deploy
- 4つのフェーズでマイグレーションを最適化、自動化を徹底
- 手動でmergeコンフリクト解消も大変
- merge祭りjob導入
- merge作業を自動化、人為的なコンフリクト以外は自動的に解消
- ほぼコンフリクトの内容は自動で解消できる、現在のブランチを正とする
- merge祭りjob導入
- 手動でデータ更新は不整合が起こる
- データMigrationを徹底して自動化
- 先々起きるわからない問題は考えず、手動が入ることでの事故を防止するために徹底的に自動化
- 極力シンプルなJobで設計する必要がある
マイグレーションを自動化するJobインターフェース
- Configuration / Run に分離
- パラメータを設定するだけで使い回せるよう共通化
- コケたjobから容易に再実行
その際に省略可能なjobのチェックを外す - cronで時間起動する
大規模開発に適したgitワークフロー
1. エンジニア以外も全員gitを使う
2. エンジニアを介さずにpull requestをmerge出来るまでワークフローを熟考する
危険なデータがマージされない仕組みを考え抜く
すべてのAssetはimportする際にチェックして所定の場所に配置
キャラクタ、マップ、クエストはパラメータから自動生成
MasterはJenkins JOBでスプレッドシートから自動pull request
3. 事故が起きたらエンジニアが責任を持って振り返る覚悟でやる
まとめ
- 大規模化されていくゲーム開発に対して改善を積み重ねていくことが大事、絶えず改善することで安定化できる
- 様々な改善策は毎日考え続けることである日パッと思い浮かぶ
- スマートフォンゲームはまだまだ大規模化する
感想
- ゲーム全体のアーキテクチャや更新データ入稿の頻度などによって具体的なプラクティスは異なりそうだが、どのような環境においても通じる考え方を聞くことができてよかった
- 特に並列開発におけるフロー整備やJobの切り分けについては最初から完璧にできるものではないが、常に改善を続けることでやがて品質の底上げにつながるということを実感しているので、非常に参考になり面白かった
DeNA TechCon2018 ゲーム体験を支えるための強化学習
DeNA TechCon2018 ゲーム体験を支えるための強化学習
概要
逆転オセロニアにおけるAI開発の取り組みについて現状の開発事例と今後の展望についての紹介
ゲーム領域におけるAI開発の背景
- 逆転オセロニアについて
- 戦略に応じてバランスよくデッキを構築する必要がある
- ルールはシンプル、戦い方は多様で奥深い
- キャラクタースキルの微妙なバランスや流行によってゲーム環境が日々変化している
- キャラクタースキルのバランス調整をミスなく、効率的に行いたい
- 絶妙なバランスを保つ難易度が高い
- ゲーム環境はどんどん複雑になるので調整コストも爆発していく
- ミスをするとゲームの品質を落とす、ゲームバランスの毀損
- 解決したい運用課題
- 新しいスキルの評価が正確にできない
- キャラクターの性能テストにかかる工数が大きい
- チューニングを続けても見落としリスクがある
- すべてのユーザーセグメントの体感を検証するのは難しい
- 実現できたら嬉しいこと
- リリース前の新しいスキルでも検証ができること
自律的なキャラクター運用の学習 - 大量の検証によって性能を評価できること
シミュレータを使った大量の自己対戦の実現 - 壊れケースを効率的に検知できること
人間のようなリテラシーで合理的に探索する方法の実現
- リリース前の新しいスキルでも検証ができること
新環境でも柔軟に運用方法を獲得する強いAIの実現
強化学習を使ったアプローチ
強化学習とは
ある環境下で、目的とする利益を最大化するための戦略(行動系列)を獲得する機械学習の一種- 未知の環境(新しいゲーム環境)に対しても学習が可能
- 試行錯誤を繰り返しながら自律的に学習ができる
強化学習とゲームタスク
研究開発ロードマップ
4つの技術を組み合わせ環境に柔軟に対応する強いAIを作る- 教師あり学習
そもそも学習ができるのか検証(プレイヤーの対戦ログを使用)
大量の棋譜ログを活用し人間が実際に打つような打ち手を学習 - 表現学習
キャラクター運用の特徴を学習
キャラを拡張できるか検証 - 強化学習
自己対戦による自律的な学習 - 先読み機能
数手先を読むことによる推論的な学習、強化学習時の学習サポート
- 教師あり学習
AI技術の紹介
教師あり学習
- 上位プレイヤーの対戦棋譜を用いて作成
- 入力データ(特徴量)
- ステータス
- 手駒・デッキ情報
- 選択可能な行動
- 盤面情報
- 出力データ(教師信号)
- プレイヤーが選択したかいなかのバイナリ変数
- 入力データ(特徴量)
- 上位プレイヤーの対戦棋譜を用いて作成
アーキテクチャ概要
- DQNに着想を得た構造
- 盤面情報は畳み込みニューラルネットワークで処理
- DQNに着想を得た構造
実験結果
- 既存NPC(ルールベースAI)に対して高い勝率が出せている
- AIはチューニングによって既存ルールベースAIより大幅に強くなる
- 意味のある戦術を学んでいることが示唆できる
設定と工夫点
- 選択・非選択を教師信号として再利用
- 人間のようにプレイするAIを獲得したい
- 上位プレイヤーの負けた情報も有効活用
- ネットワーク・学習の詳細
- Batch Normalizationは有効、Dropoutは弱め
- 活性化情報:ELU(ReLUよりも有効だった)
- 損失関数:Cross Entropy
- 大量の棋譜があるためデータ読み込みを効率化
- 並列化、キューなどを駆使してデータ読み込みを効率化
- 選択・非選択を教師信号として再利用
表現学習
- 何ができるのか
- キャラクターを低次元のベクトルで表現できる
- キャラクター数分の次元から固定次元に削減できる
- モデルサイズ削減、学習速度向上が期待できる
- 運用方法が似たキャラクターは同じような表現になる
- キャラクターを低次元のベクトルで表現できる
- 何ができるのか
-
- 低次元ベクトルを獲得する埋め込み層を行動入力の後に導入
- マルチタスク学習としてモデルを訓練する
獲得した表現の可視化
- キャラ表現を2次元に削減しプロット
- 戦略に応じた表現が得られる
- 低次元ベクトルを活用して教師あり学習・強化学習を効率化
- キャラ表現を2次元に削減しプロット
強化学習
- 自己対戦による自律的な学習
自己対戦による成長
- 強化学習エージェントは自分自身と対戦して自律的に戦略を学ぶ
- 対戦相手も自分と同様に成長
- 過去バージョンを使用
- 実際は様々なAIエージェントを相手として用いる(教師あり学習エージェント、ルールベースAI、etc...)
- いろんな対戦相手に対応するため
- 実際は様々なAIエージェントを相手として用いる(教師あり学習エージェント、ルールベースAI、etc...)
- 強化学習エージェントは自分自身と対戦して自律的に戦略を学ぶ
実験結果
- ある特定の状況ではゼロからミドルレベルのプレイヤー並みまで成長することが確認できている
難しさと対策
オセロニアへの強化学習の適用には複数の難しさがある- 毎ターン取れる行動の種類が変わる(可変長行動)
- 可変長行動を扱うネットワーク構造の使用+表現学習
- 豊富な計算資源を使っても実験に時間がかかる
- 教師あり学習の結果を強化学習の初期化に一部使用した効率化
- いろんな戦術の相手 + 不完全情報
- 様々な戦略を持つAIエージェントとの自己対戦
- 毎ターン取れる行動の種類が変わる(可変長行動)
先読み機能
オセロニアでの活用案
- 強化学習との組み合わせによるAIの強化
- 推論サポート
- ミスが許されない勝ち筋を見つけやすくなる
- 先読み機能だけでも教師あり学習・強化学習と同じような強さが確認できている
- 不利なデッキ同士の対戦でも高い勝率
- シミュレータの計算速度に依存した課題も存在
- 強化学習との組み合わせによるAIの強化
まとめ
Webツールを活用したチューニング
- AIの戦いを可視化するWebツールを使用してチューニングをサポート
- 統計量の可視化
- AIの人間らしさを検証
- AIの戦いを可視化するWebツールを使用してチューニングをサポート
今後に向けて
プロジェクト観点で難しい点、嬉しい点
AI活用を見越してやっておいたほうがいいこと
- 高速なシミュレータ開発
- 描画ロジックとバトルロジックを切り離しやすいような設計
- AIの学習を念頭に置いたログ設計
- プレイヤー分析のためのログ以外にもAI学習用のログ設計が必要
- 最新技術に追従する体制づくり
- 現場との密なコミュニケーション
- 課題を適切に定義する、企画提案するためのサービス理解
- どれほどの成果が出るかがわからない、期待値のすり合わせが必要
- 高速なシミュレータ開発
研究開発観点のやりがい
今後の可能性
- 今後ゲーム業界全体においてAI活用が活発化してくるのではないか
- 実用化を加速させるために会社の枠を超えた知見共有を行いたい
感想
- 様々な事例が紹介され、特に表現学習における獲得した表現の可視化の部分が良かったと思った
- ゲームの運用面から考えると人による判断が最終的に方向性を決定しているため、ゲームにおけるAI活用の取り組みとは何か奇抜な新しいゲームの仕組みを作り出すためのものではなく、人が参照できる情報とその分析の幅を広げ、多角的にゲームの状態を判断するための取り組みだと再認識させられる
(ユーザーが自らAIクライアントを育てて何かするようなゲームにおけるAI活用、みたいなものは除く) - 運用されているゲームにとってバランス調整は肝でありそれを補助するという時点ですでに成果を出していると個人的には思うが、さらなる成果を追求していった結果として運用タイトルを遊ぶユーザーの未来の行動全体を予測する仕組みができて、ゲームバランスだけでなく事業面に対しても優位な示唆が得られるものが出来上がるのではないかと思った
世界へ向けたゲーム開発 ローカライズ支援ツールLION
世界へ向けたゲーム開発 〜ローカライズ支援ツール『LION』〜
概要
モバイルゲームの海外同時配信・運用におけるローカライズ支援ツールとして開発されたLIONが実際にどのような課題を解決しているかについての紹介
モバイルアプリ運用時代のローカライズ事情
ゲーム事業部が目指している事
- 日本で評価されているゲームを世界中に発信する事
- そのために
- 各地域に合わせた適切なローカライズを行う必要がある
ゲームのローカライズとは
多言語化のフロー
- ローカライズすべき文字列のすべてに対してユニークなIDラベルをつける
- すべてのIDに対し日本語でデータ作成後、それを元に各言語へ翻訳していく
- 言語によってはどの言語からどの言語に翻訳できるかに制約があるため、2段階に分けて翻訳を進める必要がある
ex)日本語→英語→フランス語、イタリア語、etc...
- 言語によってはどの言語からどの言語に翻訳できるかに制約があるため、2段階に分けて翻訳を進める必要がある
ローカライズタイトルのスケジュール
- 企画が決まり、日本語テキストが準備できたら翻訳開始
- 翻訳完了後は、テキストバグがなくなるまで修正、反映を繰り返す
運用フェーズに入ると
- データ更新の際にテキストの追加や更新も同時に発生
- それぞれの開発で同じフローを繰り返し実施
→運用を考慮したローカライズフロー構築が重要となる
翻訳開始から完了までの作業と役割
- 翻訳のために必要な作業
- 翻訳ファイル準備
- 各種スケジュール調整
- 翻訳者への翻訳ファイル発注
- 翻訳ファイルの納品確認
ここまではコーディネーターの作業 - 翻訳作業(間違い修正含む)
翻訳者の作業
- 翻訳のために必要な作業
コーディネーターの作業詳細
- 翻訳対象の抽出
- 新規翻訳及び更新などによる変更部分に判別して翻訳依頼する
- 補足情報の追加
- 重複している文字列の排除
- 文字カウント
- スケジュール、費用検討
- 翻訳依頼ファイルを作成する
- 翻訳の進捗管理
- 翻訳対象の抽出
翻訳者の作業詳細
- 翻訳者は依頼ファイル内のテキストを翻訳
- コーディネーターが準備した補助情報が正確な翻訳の鍵となる
- 補助情報とは何か
- スクリーンショット
- 使用箇所や表示領域などの情報
- 関連テキスト
- 補助情報とは何か
これらが手作業だと何が起きるか
- 翻訳発注ファイル作成の準備効率低下
- 作業時間を要する
- ミスが発生しやすい
- 用語統一の困難が発生
- 適切な管理をしないと多大な時間を要する
- 翻訳発注ファイル作成の準備効率低下
運用タイトルにおけるローカライズの課題
- 手作業を可能な限り自動化し、効率化して困難をなくすと運用タイトルの同時ローカライズでも品質を高くできる
ローカライズ支援ツールLION
ローカライズで発生する様々な手作業
→システムに落とし効率化、標準化するLIONとは
LIONの機能
- プロジェクト設定
- 複数タイトルで同時利用
- 他のタイトルに関する情報は見れてはいけない
- ローカライズフローでは様々な役割のメンバーが作業
- 各役割に最適化したUIが必要
- 複数タイトルで同時利用
→適切なアクセスコントロール
→プロジェクトごと、アカウントごとのロール設定
- 翻訳テキストの依存関係を考慮した適切なバージョニングが必要
翻訳者ごとに表示すべき翻訳元言語が違う
文字列ID/ラベル管理
- 各テキストをユニークなID/ラベルで管理
- 言語ごとのバージョン管理
- どのバージョンのテキストをどの言語に翻訳したのか正しく追跡できるようにする
xlsxによるアップロード
- 慣れたアプリケーションを使用してデータ作成したい
- webのUIを使って一つずつ入力するのはとても面倒
- 更新内容は目視しやすくしたい
→xlsxファイル形式での一括入力をサポート →アップロード時の差分自動抽出
- 慣れたアプリケーションを使用してデータ作成したい
柔軟な文字列検索
- 様々なケースで検索が必要
- ソース言語の更新が反映されていない文字列
- 単語自体が間違っていた文字列
- データベース化によって各検索用途に対応
- 様々なケースで検索が必要
検索結果に対して一括操作
- 大量データの更新を一括で行えるように作り込み
- 内容修正
- ハッシュタグ付与
- xlsxダウンロード
- 大量データの更新を一括で行えるように作り込み
リリース制御
- 運用においてデータ更新は何度もある
- 更新タイミング
- イベント、機能追加、UI改修、etc...
- 並行して開発されているデータに同じ文字列が含まれることもある
- 更新タイミング
- リリーススケジュール設定管理
- リリース名
- 公開順を決める通し番号
- ID/言語/バージョン単位でスケジュール設定可能
- これらによりリリース時の事故を防止している
- 運用においてデータ更新は何度もある
翻訳サポート
- 翻訳対象の選定時・翻訳時に必要な情報
- 翻訳メモリ
- 翻訳済みデータとの類似率表示
- 含有文字列
- 用語集
- コメント・ファイル添付
発注フローのシステム化
- 複数の発注が同時並行で処理される
- コーディネーターの役割である発注管理の負担大
- 一つの発注に関連する情報を保持するオーダー
- ピックアップした文字列のリスト
- 文字カウント
- スケジュール
- アサイン
- LIONがオーダー管理をサポート
- 複数の発注が同時並行で処理される
バックエンドのAPI化
- 使いやすいUI→SPA化
- SPA化のためにAPIが必要
- アプリのビルド環境への組み込みにも必要
- Jenkinsなど
- 使いやすいUI→SPA化
LIONの技術コンポーネント * サーバー * Ruby on Rails + MySQL + Elasticsearch * API化
フロント
CI
- サーバ、フロントの自動テスト/ビルド
- 開発環境への自動デプロイ
LIONの運用
- 運用タイトル、開発タイトルそれぞれで使い始めるための準備中
- 運用からの組み込みと開発時からの組み込み→大きく違う
- 組み込みに当たって見えてくる課題は今後解消・最適化していく予定
今後の展開
- 便利機能
- 各操作手順をできるだけ減らすための最適化
- UI情報の保持
- 文字数/行数制限
- 通知の最適化
- タイトル側で使うためのコンポーネント
- コンバータやランタイム提供
- 自動翻訳?
- 没入感を損なわないレベルの自動翻訳が前提
- 便利機能
まとめ
感想
- ゲームタイトルの運用において煩雑な手作業の数々を一つのシステムにまとめるというのは、作業リソースの削減だけでなく障害の元となる入稿ミスやデータの不備を防ぐことにもつながるので、単純な効率化に収まらない大きなメリットがあると思う
- LIONの事例においても翻訳サポートツールとしての機能に限らず、アプリのビルド環境への組み込みやリリース制御の機能まで含まれているのは、ゲームタイトル運用での翻訳にまつわるコストやリスクを最小限に抑えるための有効な手段だと思った
- 翻訳に限らずゲームにまつわる各種データ、ファイルについて汎化された編集・入稿ツールがあるか、開発できるかというのは開発組織としての長期的な資産に関わってくるのではないかと思った
DeNAのネイティブアプリにおけるサーバー開発の現在と未来
概要
ネイティブアプリ向け内製BaasのSakashoを開発しこれまでどのような戦略でサーバーサイド開発をしてきたのか、そして今後どのように展開していくのかについての紹介
これまで
- 現在
- 内製開発6タイトルリリース
- 多数のタイトルを新規開発中
- 協業開発でも多数のタイトルを開発・運用中
どういう戦略でここまで来たのか?
- Sakasho
- 内製Baasであり汎用ゲームサーバ
- 特徴
- Sakashoサーバー+クライアントアプリで完結
- 多数のタイトルのサーバを一手に引き受ける
- 同一アプリケーション
- 一つのチーム
- タイトルチームはクライアントエンジニアだけ
- サーバー開発は一切していない
- 一般的なソーシャルゲームの機能をほぼ実装
- Sakasho
なぜそうしたか
- 選択と集中
- Webブラウザゲームでは単縦な表現力について一定の制限がある
- その中で様々なゲームシステムやサーバー技術が生まれた
- ネイティブアプリにおいてはその表現力を存分に発揮しないといけない
- 強みのある領域に集中するのではなく、強みを生むための領域に集中
- アーキテクチャの統一
- サーバーで何をやるかクライアントで何をやるかという設計
- キリがない話
- 一度間違うとかなり痛い目を見るポイント
- 最適かはわからないが間違いではないラインで全体を統一
- かなりクライアントに主導権を寄せている
- サーバーで何をやるかクライアントで何をやるかという設計
- 運用ポリシーの集中
- ゲームの外の世界だが、サービス運営には必要な要素群
- お客様対応
- 配信プラットフォームに関連する諸々
- ゲームの外の世界だが、サービス運営には必要な要素群
- サーバー技術の集約
- いわゆる大規模サービスを支える技術
- ネイティブアプリゲーム特有の傾向(やってみてわかったこと)
- Webサービスとネイティブアプリゲームとでは結構違う
- 選択と集中
結果
- サーバー開発・運用は1チームで同時並行で多数のタイトルを展開できた
- アーキテクチャはある程度統一され、同じノウハウを適用できた
- 各タイトルチームはクライアント側の開発に注力できた
- サービス運用はある程度均質化された
- サーバー負荷に関連するトラブルはかなり少なかった
→戦略が結果につながった
これから
現状を振り返り
どうすべきか
- 良い点:可能な限り残したい
- 独自のカスタマイズをしないなら開発が不要
- サーバー運用できるだけ省力化したい
- 課題点:全て解決したい
- 独自のカスタマイズや最適化を可能にしたい
- ホワイトボックス化
- 意志決定をチーム内で完結させたい
- 少数の組織が独自に意志決定できるように
- 独自のカスタマイズや最適化を可能にしたい
- 良い点:可能な限り残したい
具体的にどうすれば良いか
ネイティブアプリ開発の未来
- ブラックボックスではなくホワイトボックス
- 独自のカスタマイズをしないなら開発が不要
- 基本的な機能はライブラリとして用意
- 用意はするが、差し替え可能・改変可能
- 独自の機能を追加しやすいつくり
- 引き続き、共通基盤チームは作る
- タイトルを跨いだ最適化や再利用は行う
- 現在新規開発中のタイトル開発に合わせて取り組み中
まとめ
- 魅力的な面白いゲームを開発し、世界にDelightを届ける
- そのために
- より自由度高く、作りたいゲームが作れるように
- より開発効率よく、作りたいゲームに集中できるように
- この二つを両立できるような開発・運用体制を整えていく
感想
- 共通基盤としてネイティブアプリに必要なサーバー機能を網羅するように取り組み積み上げてきたからこそ独自カスタマイズも視野に入れて開発できるようにライブラリとして切り出すことが可能であり、これは当たり外れもあるゲーム開発においても大きく変わらないもの(サーバー機能)を共通で提供できるように固めて資産化してきたことの非常に大きなメリットだと思った
- 今後独自カスタマイズをするとしてもサーバー機能は一通り実装が揃っている状態でスタートできるのであれば、一から機能開発をするのではなくインフラ面で新しい取り組みをしたりログ収集・分析基盤開発に開発リソースを割くことができるので、より新しい挑戦がしやすいのではないかと思った
全体的な感想
- 全体を通してビジネス面での必要性に応じた各方面での自動化・効率化・集約化の話が多く、その上でどのような技術を使っているのかどういった設計にしているのかという考え方を学ぶことができた会だったと思う
- 主にネイティブゲーム開発に関わるセッションを受講したが、どれも大規模化していくネイティブゲーム開発に対して技術とその使い方で勝負しているので、今後より開発リソースに対するアウトプットのコスパが良い(良い意味で)開発ができるようになっていくのではないかと思った