デブサミ2019のCI/CDとかゲームQAとかの話 #devsumi

Developers Summit 2019、今年は2日目だけ行ってきました。テストとか自動化まわりのセッションの、気になったところだけ のメモ。

全量、また、その他のセッションの資料はこちらのページに追々貼られるはず。

codezine.jp

【15-E-2】CI/CDを使い倒して数段上のソフトウェア開発をしよう！

speakerdeck.com

デブサミ2019【15-E-2】CI/CDを使い倒して数段上のソフトウェア開発をしよう！ #devsumiE - Togetter

CircleCIの金洋国さん。「なぜCI/CDへの関心がこれほど高まっているのか？」という問いかけから、CI/CDのWhat/Why/Why not/Beyndについて。

• Why CI?
  • 実行し忘れ
  • 昔書いたテストが壊れて動かない
    • 「使われていない自動化は壊れていく」（出典：サイボウズを支えるCircleCI）
  • テスト結果が環境依存
• Why not CI?
  • CI導入の障害
    • テストがない
      • テストがなくても、構文チェック、カバレジ*1、サイクロマティック複雑度、ドキュメント自動生成など、自動で継続的に実行できる（効果のある）タスクはある
      • 可視化する。バッジ、ダッシュボード、メールやチャットでの通知
      • マージブロック有効化
      • 少しずつテストを追加していく
    • メンテナンスがつらい → Jenkinsおじさん問題 → クラウド型がおすすめ
• Beyond CI
  • リリースまで自動化 → CD
• What CD?
  • CDのDは、Deliveryなのか、Deploymentなのか
    • Delivery: 常にリリース可能な状態を維持する。リリースには人間の意思が介在する
    • Deployment: 自動でリリースまで実行される
    • 広義のCD: ビジネス価値を継続的にデリバリーしていくこと。書籍『継続的デリバリー』はこの意味で使っている
  • DeployとReleaseの違い
    • Deploy: 本番環境に配置する
    • Release: 配置したコードがトラフィックをさばく
• Why CD?
  • No CD, No feedback loop
• Why not CD?
  • アーキテクチャの問題
    • 疎結合にする、モダン化などの努力
  • 組織の問題
    • 明確な答えは無い
    • 『エンジニアリング組織論への招待』参照
  • ダメなら、早めにあきらめる
  • 開発の初期に早めにCI/CDを入れる。「最初からクライマックスだぜ！」
• Beyond CD
  • カナリーリリース、ブルーグリーンデプロイ
  • リリース間違ってもリトライできる → 心理的安全性
  • CI/CD Makes programming fun!
  • さらなる自動化に向かう？　CI/CD自体の設定、モニタリング、デプロイ環境構築など
  • さらに「最初からクライマックス」に

参考

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

仮面ライダー電王 Blu-ray BOX 1

【15-C-4】ゲームQAを支える技術～前処理・後処理は大変だが役に立つ～

※スライドは追って公開されるそうです

デブサミ2019【15-C-4】ゲームQAを支える技術～前処理・後処理は大変だが役に立つ～ #devsumiC - Togetter

太田さんのセッション。AI技術を使ったゲームQAの話。

• ゲームQAと狩野モデル
  • 当たり前品質
  • 一次元品質はゲームではあまりない
  • 魅力品質
• ゲーム内AI、ゲーム外AI（開発、運用支援、データ検証、性的コード解析、テスト）
• AI for QA
  • 当たり前品質
    • データ検証
      • コリジョンチェック、ソシャゲのキャラの性能評価など
    • ガチャの確率
      • 法規制もあり、受け入れテストとして実機で検証する必要がある
• ガチャ確率確認ツール
  • OCR(Google Vision API), C++
  • 機械学習ではない
    • Google Vision APIのOCRは学習できない
    • ビルドパイプラインに組み込めない（3rdからバイナリとキャプチャ画像だけもらえる）
  • 標準的OCRだと難しい
    • フォントを作りこんでいる
    • キャラ名、アイテム名が一般的でない単語
    • レイアウトや背景
  • 偽陽性が多い、偽陰性はほとんどない
  • OpenCVで前処理をがんばる
  • 標準的フローに則る。検出できなかったりしてもオペレータがリカバリできるような流れ
  • OCR 本来は95%くらいが損益分岐点
    • ツール的に、90%くらい出れば手動の1/3〜1/4くらいの時間でできる
    • 70%を下回るなら、全手動のほうが早い
  • 行間を空けるとかの前処理で改善
• 排出率確認ツール
  • まわして出てきた画像
  • Airtestでキャプチャを取る作業は事前にやっておく
    • 10連ガチャでも、個々のカードに切り出しておく
    • 同キャラマージ表示（x3とか）とかがあると難易度が上がる
  • 外部委託なので、機械学習は難しい
  • 学習なしでできるか？ → 特徴量比較のみでやってみる → 分類数が多くなると無理
    • 誤分類はNG、過分類はある程度は許容できる
    • 1000overの微妙に違う「石」の画像
      • やっていると人間も学習するので見分けられるようになった
      • dot by dotの判定ならいける？ → ポストエフェクトがあるので無理
  • k-meansベースの方式で改善
    • お手本分類の重心を取る
    • 一部手動と割り切る
    • レア度の高いものは標本が少なくて過分類になりがち
    • 手作業が1/10に。分類作業を含めても1/10なのでかなり効率化できた

参考

前処理大全[データ分析のためのSQL/R/Python実践テクニック]

【15-B-5】Site Reliability Engineering at Google

デブサミ2019【15-B-5】Site Reliability Engineering at Google #devsumiB - Togetter

Googleの中井さんによるSREの話。

• Googleは当初から運用もSoftware Engineerで構成。目的はサービスを安定して提供し続けること
• 50%ルール。50%は開発にあてて、運用業務は残りで行なう
• SREのバーンアウト防止
• 50%ルールをおびやかすシステムに対しては、開発チームに運用作業の返却、もしくは運用要員の提供を要求する権利がある
• 安定稼働を組み込むための技術支援もSREチームの業務に含まれる
• SREの運用範囲は全システム/アプリでない。インフラ、ミドルウェア、重要度の高いアプリだけ見てる。
• 上記の範囲でも、すごく安定しているアプリケーションは見ない
• SREチームの究極のゴールは、自分たちが運用するシステムをなくすこと
• SLO (service level objective): 「安定」の共通認識
  • Webリクエストに対し、n%のsuccess、m%は200ms以内にレスポンス、x%は1000ms以内、等
  • モニタリングする
  • エラーバジェット = 1.0 - SLO
    • 期間内(3moとか）のエラーの許容量
    • バジェットがなくなる可能性が生じたら抜本的な対策を講じる
      • 開発を巻き込んでやる。新規機能のリリースは止める
• デザインレビューの提供
  • 設計段階でSREチームを交えてデザインレビュー
  • 運用まわりの設計が共通化・標準化できるので、SREチームとしても運用しやすいシステムになりwin-win
• Toil（労力のかかる作業）の削減
  • バーンアウト防止
    • Software Developerにつまらない作業をさせない → 50%ルール
  • 運用作業・障害対応の自動化を促進
• 障害対応のプロセス
  • 問題解決が最優先、他人に頼ることを本人のスキル不足とは認識しないことを徹底
• ポストモーテム
  • 重大問題の解決後に実施
  • Google Docsでみんなで一斉に、要因、反省、改善策を書き出す
  • 個人を避難する内容は絶対に書かない。個人のミスを誘発するシステムを設計したSREチームの責任という認識
  • 社内の全エンジニアに内容を公開
    • 障害対応により得られた知見を共有
    • 障害対応の実地訓練にも活用（再現シナリオとして使う）
• SREトレーニングコースがCourseraにある
  • ポストモーテムの書き方とかもある

たぶんこれ

www.coursera.org

所感

運用は運用専門の部隊（だいたい外部委託）がいて、という状況からSREできる人だけ入れれば解決するわけではなさそう。（QA部門における）テスト自動化と似たような話が繰り返されそう。

参考

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

The Site Reliability Workbook: Practical Ways to Implement SRE

【15-B-7】無意味なアラートからの脱却 ～ Datadogを使ってモダンなモニタリングを始めよう ～

デブサミ2019【15-B-7】無意味なアラートからの脱却 ～ Datadogを使ってモダンなモニタリングを始めよう ～ #devsumiB - Togetter

Datadogの池山さん（実は珍しい名字だそう）。アジア圏の最初の社員。

• 犬のロゴかわいい
• でも社員はネコ派が多い
• "Cattle, not pets"
  • ペットのようにひとつひとつ細かく見て分析するのではなく、家畜のように群れとして管理できる
• 14 days free trialがある

www.datadoghq.com

日本語ドキュメントも完備

docs.datadoghq.com

参考

入門 監視 ―モダンなモニタリングのためのデザインパターン

おまけ

今日読んだ（というか書かれた）個人スポンサーはいいぞという話。来年は検討しようかな…

blog.evangelism.jp

*1:テストがなければ0%ですけれど

モリカトロン 新宿テストLab プレオープンイベントでゲームAIの講演を聞いてきました

ゲームAIを専業とするモリカトロン株式会社様がこの度、AIを応用したテスト（いわゆる第三者検証）を請け負う『モリカトロン新宿テストLab』を立ち上げるということで、ご縁があり12/7のプレオープンイベントにご招待いただきました。

モリカトロンの森川幸人氏と、スクウェア・エニックスの三宅陽一郎氏による、ゲームAIに関する講演内容を中心に書かせていただきます。

morikatron.com

モリカトロン株式会社は、『がんばれ森川君2号』『ジャンピング・フラッシュ*1』などで知られる森川幸人氏を中心に昨年立ち上げられた、"日本初のゲーム専用AIの会社"で、モノビットエンジン株式会社を含む「モノビット・モリカトロン ホールディングス株式会社」の傘下*2の会社です。

「ゲームAI」と「第三者検証」、簡単には結びつかない言葉かも知れません。ですが、まずゲームの制作に関わるAIの適用範囲がとても広く（後述の森川氏・三宅氏の講演参照）、その中にテスト自動化への利用があります。ここ2〜3年、CEDECなどでいくつも事例が発表されています。

モリカトロン様も、独自の自動化ツール開発を行ない、ただし、それをツールとして売るのではなく*3、手動テストのエキスパートと組み合わせて効率を上げた形で提供できる「第三者検証」という形を選択されたようです。

自動テストは、どうしてもリグレッションテストのウェイトが大きくなり、新規のバグ発見には余り効果が出ないものです。単純な、機械でもできる種類のテストは自動化し、人間はより高度な探索的テストなどに注力するのがセオリーであり、そこまでパッケージングしたサービスが「モリカトロン新宿テストLab」ということでしょう。

前置きが長くなりましたが、以下、イベントの講演内容のメモです。

開催挨拶

モリカトロン代表取締役の本城氏ご挨拶。上と重複する部分もあり割愛しますが（すいません…）、「あらゆるゲーム制作に役立つAI」のひとつとして、品質管理に活かす事業を、というのがはじまりだったそうです。

続いて、同取締役の成沢氏より。元スクウェア・エニックスでプロデューサーをしていた際、現場では様々なツールが開発され、ゲーム制作に利用されていることを見てきており、プロデューサー目線で見ても役立ちそう、他にも転用できそう、と思っていたので、今回のようなツールやサービスを広げて行きたい、とのこと。

20分でわかった気になる ゲームAI講座

モリカトロンAI研究所所長 森川幸人氏の講演。ゲームAIは門外漢なので、間違ってメモしていたらごめんなさい。

• 第三次AIブーム（deep learningあたり）以降、AI関連の話が多く来るようになったので会社にしたのがモリカトロン
• 『がんばれ森川君2号』は第二次AIブーム。このときは学者の中でのブームだったが、第三次はGoogleなども参入してカスタマーに広がっており本物ではないか
• AIの外科手術医。ゲーム制作の後工程になって「AIで面白くできないか」などの依頼が来て、キャラクタの行動判断などをAIに載せ替えたり
• AIモデルにはいろいろなモデルがある。deep learningだけでない。ふさわしいものを選別する必要がある
• ニューラルネットワーク：脳の仕組みを数理モデルにしてみたもの
  • パーセプトロンは第一次AIブーム
  • モリカトロンの由来は森川＋パーセプトロン
  • 脳のサイズアップ → 知能が増える、という仕組みは生物と同じ
• 正しいAI、楽しいAI
  • 正しい：医療、金融、囲碁、自動運転 → これらは、ほぼほぼAIに置き換わるはず
  • 面白い：ゲーム、小説 → 「面白い」の本質がわからないので難しい
• 中のAI、外のAI
  • 中のAI：キャラの行動判断、経路探索など。それなりに進んでいる。ゲームごとに特徴的
  • 外のAI：メタAI、イベントの進行、QA、デバッグ。これから必要となってくる。どのゲームでも共通的に使える、発展できる
• 中のAIの例
  • キャラのパラメタ、ショップの売り物
  • カードデッキの最適化：組み合わせが増え、人間がやる限界に来ている
  • キャラの行動判断：人間の発想に限界があるのでAIに期待できる
  • ユーザにあわせた会話を自動生成：ユーザごとにカスタマイズされた会話、歌とか
  • 経路を設計する
  • 世界やステージの自動生成。世界観を指定すれば、AIが生成してくれる
  • キャラクターを自動生成。属性を入れたらAIが自動生成。萌キャラ生成サイト（中国）
  • 仮想アイドルを自動生成
• 外のAIの例
  • ユーザに合わせた「接待」をする。ユーザに合わせた難易度調整。敵の数や強さとか。メタAIと呼ばれるが、森川さんとしては「ディレクターAI」と呼びたい
  • 品質管理、バグ摘出
• 正しい・楽しい × 中・外 のマトリクス
  • 正しい側の、中・外の中間に「データ解析AI」がある。まずここから新宿テストLabでは扱う
• 現在、まずは汎用的なツール化をしているところ
• AIが得意なこと
  • 画像認識。見分ける。人間でも意外と難しい例：文鳥とイチゴ、フクロウとりんご、チワワとマフィン、トイプードルと唐揚げなど
  • レンブラントの偽物をつくる
  • コピーライティング
  • キーワードから文を自動生成してくれる
  • ウェザーロイドAiri（まだ動きは人間モーキャプ）
  • フェイク・オバマ
  • AIアナウンサー（中国）
• 苦手なこと
  • 大阪弁のような、同意味の言葉、一般常識がないと読み取れない
  • 全部ひらがなの文。「せいじかのおしょくじけん」「うみにいるかのたいぐん」は一般的な知識の下地がないと間違える
  • 雑談が難しい
• その他の事例
  • Grand Theft AutoをAI自動運転のシミュレータに使う。ゲーム → AI → 現実世界。GTAにあるまじき安全運転
  • 先読み。二人の人物が写ってる写真から、その後、ハグするか握手するか殴り合うとかを予測
• 手書き数字の類推。1文字を元に、同じ特徴の1〜10を作り出す

見覚えのある事例もあったのですが、全部のリンクを探しきれておらず、このまま公開します。追々時間があったら追加していくかも知れません。

デジタルゲームの調整・デバッグ・品質管理における人工知能技術の応用

続いて、株式会社スクウェア・エニックス 三宅陽一郎氏の講演。こちらも事例のリンクを探しきれておらず。

デジタルゲームの調整・デバッグ・品質管理 における人工知能技術の応用 from Youichiro Miyake

www.slideshare.net

• ゲームの中のAI
  • メタAI
  • キャラクターAI
  • ナビゲーションAI
  • ここ15年くらい研究され、使われている
• ゲームの外のAI
  • 開発工程を助ける
  • バランス調整
  • 可視化
  • シミュレーション
  • データマイニング
• 時系列では、ナビゲーションAI、キャラAI、メタAI（2007ごろ)、外のAI（2015ごろ）の順にできてきた
• 中のAIは、ゲーム機内で動かすものという制限、ゲーム固有のものである等、あまりノウハウが外に出せない
• 外のAIは共通化、社外での研究開発もできるので、最近盛り上がってる
• QA、品質保証。テスターをAIに置き換える動き。ソシャゲの複雑化、オープンワールドのテストなどは、人間がやる限界を超えている
• 中：人力。Scripted AI。人力＋AI技術
• 外：今はまだ、ほぼ人力だが、これにAIを入れていく
  • 出ている事例では20-30%をAIに置き換え。セガさんのオートリプレイで40%くらい置き換えて一億円くらいの効果
  • 50%くらい置き換えられるようになるのでは
  • ゲームの中に手を入れるのでなく、ゲームの外（ユーザ視点・操作）からのI/Oだけでテストするようになる。自動プレイング
• ニューラルネット、機械学習、強化学習
  • ニューラルネットワーク：どの敵から攻撃するか、学習させる
  • 強化学習：行動の結果を取って学習
  • 遺伝的アルゴリズム：集団をかしこくする。『GA Racer』『アストロノーカ*4』
  • NEAT: ニューラルネットワーク＋遺伝的アルゴリズム
    • DeNAさんの『FINAL FANTASY Record Keeper』の例 → 強化学習を利用した自律型GameAIの取り組み ~高速自動プレイによるステージ設計支援~ #denatechcon
    • ゲームのデバッグに向いてる
  • 機械学習：ユーザのログから学習する。『FORZA motorsport』
• 『Assassin's Creed Origins』
  • オープンワールドのマップ検証。オブジェクト500万個の位置関係を検証するAI、placement metrics。夜間に検証して翌朝レポートしてくれる
  • なんとなく安心して出荷できる
  • 負荷テスト、telemetry、負荷が高いところをヒートマップにしてレポート
• 『Thief』
  • ベテランプログラマがつらさを知っていたので、AI testを作った。コードレベルでなく、ゲームのコンテキストレベルのテスト
  • UE4のBlue Prinntで状況を作って、テストを書く。キャラクタAIの行動が正しいかをテストできる
    • Playerが障害物の陰に隠れたとき、回り込んで発見できる、みたいなテスト
• 『Horizon Zero Dawn』
  • 人力でビジュアライゼーションのテスト
  • テスターさんの行動ログと見つけたバグの集約、ヒートマップ、クリックすると動画再生
  • 統計情報を可視化してくれるAI
  • 夜は自動テストAIがオープンワールドを探索
• 『Battlefield』
  • AI向けの荒い解像度の画像を入力にして、AIが行動判断、ゲームコントローラーに出力
  • 強化学習
  • たぶんこの話 → AIエージェントに「バトルフィールド 1」のプレイを教えるには？
• 離脱率
• マッチングが正しく行われているか。選択アルゴリズムの補正。勝率を50%に近づける
• 『Halo 4』
  • 実際にプレイヤーが死ぬ場所のヒートマップを作る。テレメトリでレベルデザイナの意図通りの難易度になっているかを検証できる
• まとめ
  • 中のAI：コンテンツ。作品を作っている（作品の一部である）。自律的、より動的なコンテンツ
  • 外のAI：サイエンス。動的なコンテンツを外から抑え込む
    • ゲーム向けは、先行研究が少ない、アカデミックな知識を援用する場合が多い、個別課題が多い、統一的に解決するには研究期間が必要、共通フレームワークがない
    • 共同研究しやすい、直接競合しにくい

三宅氏はちょうど"SIGGRAPH ASIA"でも講演されており、こちらに記事が出ているので参考になるはずです。

www.gamebusiness.jp

モリカトロンではこれをやります！

最後に、モリカトロン 桑野氏より、新宿テストLabのサービスについてのお話。

• JSTQBのテスト手法を用いた、ゲームデバッグ＆テスティング
• バグを出すことに特化した、エキスパートによる専門チームの設立
• エキスパートチームによるインディーズ支援
• QAエンジニアを配置、開発初期から自動化を見据えたご提案
• モリカトロン独自の自動化ツールの開発
• テスト工程に必要な各種ツール開発

所感

AIや機械学習をテスト自動化に活かす試みは多方面で進んでいますが、元々難しいと聞いていたゲーム分野での現状をまとめて聞くと、これまでなんとなく他人事のように思えていた事例が、とても現実的なものに感じられました。

研究開発費だけでなく、エンジンを内製していないととても真似できない話が多いのは確かなのですが、自動リプレイ＋ビジュアライゼーションだけでも実現できれば、十分価値のある情報が出せそうだということなどです。 少し、数年前のモバイルアプリのUIテスト自動化と状況が似ているかも知れません。

まだまだ、完全自動化という段階ではないとは思うのですが、冒頭に書いたようにうまく機械と人間とで役割分担することでうまくまわる箇所は多いのではないかと思います。 その点、このモリカトロン新宿テストLabの取り組みは現時点での最適解かも知れず、半年、一年後にまたお話を伺いたいです。

*1:先日発売された「プレイステーション・クラシック」に入っているそうです！

*2:持株会社化および組織変更はつい先日ですが、元々モノビット系列で立ち上がった会社と伺っています

*3:具体的に聞いてはいませんので、売ってくれるのかも知れません

*4:森川さんが開発

Android Test Night #5 Androidテスト全書の回 に行ってきました #android_test_night

11月に一般販売が始まった『Androidテスト全書』の著者さん達によるトーク回ということで、年甲斐もなく「ブログ・Qiita枠」で申し込んで参加してきました。

testnight.connpass.com

『Androidテスト全書』は、技術書クラウドファンディングのPEAKSで企画・制作されたAndroidアプリのテスト自動化を中心とした書籍で、11月初旬より製本版の一般販売が開始され、15日で限定セール分が完売してしまったという人気の書籍です。 セールは終わっていますが、製本版・電子版とも下記ページから購入できます。

Androidテスト全書

• 著者： 白山 文彦,外山 純生,平田 敏之,菊池 紘,堀江 亮介,
• 製本版,電子版
• PEAKSで購入する

本書はざっと通読しており、特に以下の観点でおすすめできる書籍です。

• 自動テストの書き方にとどまらず、なぜテストを書くべきなのかといった、「手段」から一歩引いたところから丁寧に書かれている
• JUnit、Mockitoといった基本的なテスティングフレームワークによる基本的なテストの書きかただけでなく、非同期、RxJavaなどに対するテストの書きかたも押さえられている
• UIテストに関して、Espresso、Appiumそれぞれにページが割かれ、差別化されている
• CI/CDの導入も丁寧にかかれており、Firebase Test Labにも言及されている
• JUnit 5への移行、Local Unit TestとInstrumentation Testの統合（Jetpackへの統合）など、少し先にこうなっていくという事項にも言及されている

トークセッション

本会は、SFにいる白山さん（冒頭にビデオレターで登場）以外の著者の方々と、編集の日高さんによるトークで進行されました。

著者のおすすめポイント

• 堀江さん：ツールの使い方とかでなく、CI/CDとは、というところから書いた
• 菊池さん：公式にはまだJUnit 4なのに、JUnit 5を動かせるのが楽しい。個人的にそうゆうのが好きなので紹介した。Parameterized Testは便利で使える。この分量が大きくなってしまって章立てを変えた
• 平田さん：Appiumまわりは、本書のために会社でUIテストやりたい人を募って実際に導入した成果を書いている。さらっと書いてるところも実際は大変だったりした
• 外山さん：UIテスト導入まわりでは、『システムテスト自動化 標準ガイド』（通称「ギア本」）から、最低限押さえておいてほしい点のピックアップもしている。Espressoに関しては、ドキュメントからだけではわからないところもソースを読んだり試したりした結果を書いてある

システムテスト自動化 標準ガイド CodeZine BOOKS

苦労したところ

• 菊池さん：本が出たあと、Gradle JUnit Pluginの変更がどんどん入ってつらい。ただ、本書の記載内容が使えなくなったわけでなく、便利なアノテーションとかが追加された等。執筆期間にGoogle I/O 2018を挟んだので不安だったが、大きな変更はなく安心した
• 堀江さん：仕事との兼ね合い、子育てもあるので時間がつらかった
• 平田さん：執筆中にAppiumのバージョンアップ（1.8 -> 1.9）、uiautomator2 driverのBetaが取れたのはよかった
• 外山さん：Kotlinを使うかどうか悩んだ。執筆当初はコンパイルが通らないところがあり、Javaで書いた。電書版直前くらいに試したらKotlinもコンパイルが通るようになっていた
• 日高さん：読むターゲットの選定。初心者なのかバリバリやってる方か。テストのことをちゃんと伝えたい、わかりやすく書きたい。改訂版の予定はまだないが、売上がよかったらぜひやりたい

PEAKSについて

• PEAKSで書いた書籍を技術書典で売るときにTシャツを作ってもらえた
• 表紙はなぜこうなったのか？
  • 永野さん@PEAKS：わからない
• 永野さん@PEAKS：本書は、他の本に比べてクロスレビューが活発だった

自分以外のセクションでおすすめ

• 外山さん：非同期テスト細かく書いてある、CI/CDとかあまり詳しくなかったので勉強になった
• 平田さん：自身がiOS寄りなので、4・5章が特に、視点が違って面白かった
• 菊池さん：2年くらい前、AppiumでAndroid 4系をテストしようとして辛かったのが、今はよくなってること。Circle CIのManual Approvalsで手動でワークフローのトリガを設定できること
• 堀江さん：1章、テストをなぜ書くのかなど
• 日高さん：企画段階では250ページ、完成400ページ。これでも削ったところもある。技術の変化が早いので古臭くならないようにした。例えばインストール手順のようなWebで得られるところは割愛している。深夜2時に原稿があがって、その時間から相互レビューがはじまるくらい皆書いていた。編集者は、毎回、頭をリフレッシュして読み直すのが仕事

日高さんの編集について

• 堀江さん：編集前160ページのセクションが60ページくらいに減った
• 菊池さん：そこまで減らなかったけど、ごっそり入れ替えとかの指示があると、そこからの辻褄合わせとか大変だった。趣味で小説書いたりしてたので、細かい言い回し等には気を使うほうなるので、その辺りの指摘はそのままにしたところも
• 平田さん：社内でUIテストを導入しつつ書いたので混乱した部分もあったが、羊さんがヒカリエまで来て話したりした。指摘箇所に理由をつけてくれるので納得感がある
• 外山さん：著者脱稿して80%くらいの完成度と思っていたら、その後が大変だった。でも読みやすくはなってた。抽象的でなく具体的に書くべき、みたいな指摘とか

普段どこに気をつけてテストしているか

• 平田さん：QAがやってることを自動にできないかと相談されるが、マニュアルテストをそのまま自動化することは運用まで考えるとROIが良くないので、そこから話す
  • UIテストの安定性。CIに乗せると落ちたり
  • どこまで自動化するか
• 外山さん：課金などのシステムが出すDialog、テストはできるけどGoogle都合で変わるので大変だけど、大事なので押さえたいところ
• 堀江さん：CI/CDで、自動と手動をひとつのフローに乗せるべきか。Circle CIでは手動テストの完了をトリガにワークフローを進めてリリースりたりできるので活用している
  • ZOZOにもSWET(SoftWare Engineer in Test)のような組織はあってUIテストは書いてるけど、CI/CDに統合はされていない
  • 手動テストの人がちゃんと探索的テストに注力できるようなフローにする
• 菊池さん：エンジニア自体が少ないので、UIテストには工数をかけられていない。コストとのバランス

テストを書いたコストがペイしたと思った経験

• 平田さん：自動テストでバグを見つけるのはよくない*1。テストがある安心感と、正しく動いていることが確認できることが良い。安心してリリースできるのが大事。テストが落ちるのは環境的な問題が多い

現場で実現するために大事なこと、チームプレー

• 外山さん：自動テストは銀の弾丸ではないので、Unit/UIテストの仕切りが大事。QAが「全部自動化してほしい」と言ってくることもあるが、認識合わせが大変
  • 日高さん：そのときのキーワードは工数？
  • 外山さん：工数だけではなく、Unitでやるべきだけど構造上できないのでUIでやったり、事情を汲んでいる
• 堀江さん：CI/CDがないところに途中から導入したとき。困っていないか聞いて回って、SDKバージョンを上げるのを躊躇するみたいな話を聞く。テストをたくさん書くより、効果的なところから導入していくようにしている

ライブラリ等のバージョンを上げていくか

• 菊池さん：ライブラリ全般、無理にバージョンを上げる必要はないと思っている
• 外山さん：テスト系ライブラリはわりとカジュアルに上げる

会場からの質問

QAがテストを書くのか

• 外山さん：そうしたいが、まだできていない。Excelにシナリオを書けばテスト実行できるくらいにしたいけど、それを作るとコストが見合わないのでできていない
• 堀江さん：会社に受け入れテストを自動化している部隊がいたが、最近まで知らなかったし、経緯もよくわからない。今後連携していく

テストを書くタイミングについて

テストファーストだと仕様変更で書き直しになる。完成してから書くべきなのか？

• 変わらないところを中心に書くのがいいのでは。永続化まわりとか
• UIのほうはあとまわしにして、Unit Testはテストファーストで書く

GUIでテストを作れるツールについて

• 日本に限らず、増えてきてはいる。どのように使うかによっては使えると思うので、徐々に使えるとは思っている。精度次第？
• Firebase Test LabのRobo testは、だんだんかしこくなってる。単純なアクティビティ遷移でクラッシュみたいなのは検出してくれる

テストピラミッドの各層でしかできない検証について

• Unit Testから入って、CIを導入してから、UIテストにかかればいいのでは。CIは入れるべき

プロダクションのライブラリやSDKバージョンを上げることについて

ライブラリやSDKのバージョンを上げるという話があったが、そのときに問題を検出できるように考慮したテストの書き方はありますか？

• 特にその目的で考慮していることはない
• Firebase SDKを上げたときにビルド失敗はあった。レポートを社内に展開したりはした
• ライブラリのバージョンは、上げてもすぐ元が消えるとかある

テストコードの保守性・可読性

本質的でない部分が多くなったり、そもそも何をテストしたかったのかわからなかったりする。工夫はあるか

• チームが日本人メインであれば、テストメソッドの名前を日本語にすることは有効
  • Instrumentation testのほうは日本語使えない
• 前設定のコードが多くなるのであれば、Mockitoとかのライブラリを使って簡潔に書けるようにする
• テストコードの中を、Setup, Exercise, Verify, Teardownにちゃんと分けて、メソッド抽出したりもする。仕様変更などでSetupがごっそり変わることもあるが、分けられていれば対応も容易になる

註：このあたりの用語は、『xUnit Test Patterns』から。テストダブル（Mock等）のパターンも参考になります。

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

テストのリファクタリングに使う時間はトータル何%？

• 共通化をするくらいで、そう多くはない

(AACの)Repositoryのテストについて

Mockを使うUnit Testでは仕様変更の対応が不安。Repositoryまで統合したテストもするべきか

• OkHttpのMockWebServerを使った統合テストは有効
• Swaggerとか使ってモックサーバを立てる

既存プロジェクトに対してテストをどう書くか

• データ層から進めていく
• セオリーだと、Integration Testなど外側からテストを書いて保護していくが、これは大変。一部アーキテクチャを組み替えながら進められるのであれば、それがいいと思う

所感

会場で質問をされた方の中に「本書を読んでテストを書き始めた」という方もいました。それだけの力のある本が、いい時期に*2書かれたのではないかと思います。

今回のトークセッションでは、著者および編集者の皆さんの熱量（本書に対するものと、テストに対するものの両方）を感じ取ることができ、また共著の大変さを思い出し、改めてじっくり再読しなければ、という気持ちになりました。

本書が広く読まれて（売れて）、改版や、また他分野のテストに関する書籍の出版につながるといいな、と思います。そして、テストを書いてCI/CDすることが当然という世の中が早く来てほしい。

ともかく、著者・編集者、ほか関係者の皆さん、お疲れさまでした。ありがとうございました。

*1:自動テストはリグレッションテストが中心になるので、新規のバグ発見はほとんど期待できないということを踏まえて

*2:ツール・フレームワークの成熟度合いや、Jetpackまわりなど、個人的にそう感じています

Gotanda.unity #8 in ワンダープラネット株式会社 @渋谷 に行ってきました #gotandaunity

五反田で開催されないと定評のある『Gotanda.unity #8 in ワンダープラネット株式会社 @渋谷』に行ってきたので雑なメモと、拾えただけのスライドを貼っておきます。

gotanda-unity.connpass.com

LT #1 シンプルStateMachine

@k-wth さん

docs.google.com

• ステートマシン"1号"、シンプルなうちはよかったが、Stateの入れ子など複雑化し、バグの温床に
• シンプルな"2号"を作った

LT #2 シェーダー芸・入門から1ヶ月の道のり

@nimu026 さん

docs.google.com

• 8月のJAPANLAND花火大会＠VRChatに触発されてシェーダ芸を
• Shurikenでなく、GPUパーティクル？　シェーダ芸？
• Compute ShaderはVRChatに持ち込めない
• phiさんのシェーダ芸
• Vertex Shaderでもなく、Fragment Shaderでもなく、Geometry Shader
• Geometry Shaderで動かしてFragment Shaderで塗る
• ひたすら写経したり改変したり

LT #3 NCMBでオートログインとセーブデータのバックアップ

@azumagoro さん

docs.google.com

• 個人開発ゲーム。v1はローカル保存、v2からNCMB
• JsonUtilityでシリアライズ。EasySaveではList<>を保存できない
• masterから取得できるデータはkeyだけ持っておく（節約）
• NCMBの課金体系が変更されて痛い

LT #4 ObservableパターンからはじめるUniRx

@torisoup さん

niconare.nicovideo.jp

• Observerパターン
• ObserverとSubject、印象が逆なので注意。Subject側が管理してる。Observerは監視・管理はしていない

LT #5 PUN2触ってみた

@otyugen59 さん

speakerdeck.com

• Photon Unity Networking
• PUN2が8/25リリース
• PhotonRx（とりすーぷさん作）
• コールバックが変更されているのが一番影響大きい

PUN は 開発者の Tobias はパンと発音してたけど、日本ではピーユーエヌって読む人が多い気がする

— やまさん(S.Yama) (@syyama_net) 2018年9月26日

LT #6 ここが楽しい/しんどいLive2D CubismSDK for Unity

@traitam さん

docs.google.com

• v2.1とv3.0で互換性がない
• "うちの子・推しを動かせる"のが一番楽しいところ
• ドキュメント、情報発信者が少ない（Editorの話はあるけど）
• 畑を耕さないと

LT #7 Tilemapのアップデートについて

@RyotaMurohoshi さん

speakerdeck.com

早速ブログ記事も

mrstar-logs.hatenablog.com

• 2018.2から、Hexagonal Tile
  • Point top/Flat topがある
  • コンポーネントは同じもので、propertyで切り替えられる
• Isometric Tile
  • クォータービュー
  • まだベータ
  • オクルージョンできる。高さがある

こういうのやりたくないですか！#gotandaunity pic.twitter.com/1H6NBl5qH8

— むろほし (@RyotaMurohoshi) 2018年9月26日

• Let's 人柱！

LT #8 スコープファンクションでコードの見通しを改善する

@yashims85 さん

speakerdeck.com

• 関数に切り出すほどでもないもの*1
• Kotlinの文脈で出てくる
• 引数にselfを渡して、Lambdaの中でプロパティをセットするなどして、selfを返す
  • Also(that => {that.x=0;... return that} とか
• 一時変数が減ってコードの見通しが良くなる
• Null安全

LT #9 4画面出力とレシート印刷で作る体験型デジタルサイネージ

@ksk1030 さん

speakerdeck.com

• マルチディスプレイ
  • ディスプレイごとの設定、リフレッシュレート、アス比
  • UnityのindexとOS上の番号が一以しない。ケーブル挿す順で変わる？
• レシートプリンタ
• Windowsタッチパネルのエッジスワイプを抑止したい→物理的に抑止した

LT #10 Scene操作系のエディター拡張Util2セット

@takumi_hanzawa さん

Scene操作系のエディター拡張Util2セット from Takumi Hanzawa

www.slideshare.net

• マルチシーンエディティングで、アクティブを切り替えるのを2クリック→1クリックに
• シーンの読み込み履歴。ヒストリーウィンドウで1クリックでロード

所感

LT10本、Unityの扱う領域の広さをあらわすように、幅広く、話の被りもなく、とても面白い回でした。

聞いた話が役に立つ日が来るのか？と言われると、まず無い、と言い切れるトークが多かったのですが、それはそれ。役に立つ話を聞くばかりが勉強会ではないと思っているので、このノリは引っ張ってほしいところです。

なかでも、マイノリティな技術の孤立無援っぽい話は共感するところもあり、それでも「畑を耕さないと」「Let's 人柱！」といった前向きな言葉がよかった。

また次回は2ヶ月後ということで、何かネタがあればまた登壇も検討しようかという気持ちになったと同時に、前々回のフォローアップ記事をまだ書いてないことを思い出したり…

関連資料

Unityゲーム プログラミング・バイブル

*1:個人的には「関数に切り出すほどでもないもの」は関数に切り出すほうが好きです。テスト書きやすいし

フォトグラメトリでバ美肉(1.5) Qlone

フォトグラメトリツールの紹介・比較をしていくつもりはないのですが、例外としてひとつだけ。iOSおよびAndroidで動作するQloneというアプリについて。

www.qlone.pro

対象は小さい物体に限りますが、ガイドに従ってスキャニングし、クラウド上で3Dモデル生成までやってくれるアプリです。アプリ自体は無料で使えますが、生成された3Dモデルをobjなどの形式にエクスポートするのに課金が必要です。

フォトグラメトリについてや注意事項などについては、前回の記事を参照してください。

スキャニング

撮影には、専用のマットの印刷が必要です。これはアプリから直接AirPrintか、pdfファイルを取得して自分で印刷します。被写体をマット上に置いて撮影するのですが、A4サイズのマットで高さ10cmくらいのフィギュアが限度です。

A3サイズで今回の被写体（高さ17cm）がなんとか収まりましたが、それでも上部のえんぺらあたりがキレイにスキャンできませんでした。

また、被写体の向きを変えて（フィギュアを倒して）もう一度スキャンすることが推奨されていますが、A3マットの場合スキャン中に数回（恐らくメモリ不足で）アプリが落ちたので、今回は1回だけスキャンしています。

これで、148,343頂点、581,760ポリゴン、テクスチャは2048x2048が1枚です。

エクスポート

エクスポートは、スキャンしたモデル単位にアンロック権を購入する形式で、1モデル¥120から無制限¥2,400まで。obj, stlのほか、iOS 12から使えるUSDZ形式*1にも対応しています。

なお、アンロックはモデル単位ですが、アプリ内でモデルの複製を行なうと権利もコピーされます。

また、Sketchfabへのエクスポートも可能です。アンロックしていないとダウンロードできない設定、アンロックしているとダウンロード可能設定でアップロード・公開されるので注意。 SketchfabのProアカウントでは試していないので、privateにできるかは未検証です。

エクスポートしたモデルをBlenderで見るとこんな感じ。テクスチャは余りキレイではないものの（これは撮影環境の問題も大きい）、メッシュはそれなりに取れています（うまく辻褄を合わせている、が正しい気もしますが）。

胴（頭足類なので）の上のほう、えんぺら周辺のメッシュが荒いのは、恐らくA3サイズマットでの限界なのだと思います。

リサイズツール

Qloneにはある程度の加工ができるツールも実装されています。例えば、編集 - RESIZE - Simplifyでポリゴン数の削減もできます。

削減前1（148k頂点、582kポリゴン）

削減後1（62k頂点、174kポリゴン）

かなりメッシュの大きさにばらつきがありますが、自動でやってくれます。3DF Zephyrのリトポロジー機能と違って触手の先などのエッジはキープされるようです。

削減前2（148k頂点、582kポリゴンのはずですが表示がおかしい）

削減後2（34k頂点、100kポリゴンくらいのはずですが表示がおかしい）

その他のツール

テクスチャのペイント、スカルプティング機能もありますが、やはりスマートフォンでの操作には限界があると思いますので、素直にPCのツールでやるほうがいいでしょう。

ほかに、ボクセル化の機能もあります。

所感

意外とメッシュは取れていて驚きました。モデル単位の課金というのも使いやすいですね。PCでのリトポロジーやレタッチ前提で、メッシュのアタリが取れるクオリティでいいといった条件では十分実用的ではないでしょうか。

ただ、大きめの被写体にはそれなりのサイズのマットを印刷して用意する必要があることと、大きくなるほどアプリが落ちやすい*2のが難点です。

参考

いかレスラー

*1:SafariでリンクするだけでAR表示もできるアレ

*2:スキャンを試したのは数週間前なので、すでに改善されているかも知れませんが

フォトグラメトリでバ美肉(1) 3DF Zephyr

たくさんの写真から3Dモデルを作り出すフォトグラメトリ(Photogrammetry)があれば、モデリングができなくても絵心がなくても、フィギュアからVRChatやVRM向けのアバターを作ってバ美肉*1できるのでは？ ……などと甘い考えのもと、試してみた結果を晒します。

結論と注意事項

いきなりですが、結論として、2つの理由からフィギュアからフォトグラメトリしたモデルをアバターに使うことはないでしょう。理由は、クオリティ（コスト）の問題と、権利的なものです。

クオリティ（コスト）面

前提として、今回の作例は、かなり雑なライティング・雑な撮影・ろくにレタッチしない、という三重苦のもので、正直ソフトメーカーさんに申し訳ないレベルのものです。

少し頑張れば、背景オブジェクトやプロップ的なものには十分使えるものが私にも作れるとは思います。が、アバターとなるとさらにリギングして動かすための工数もかかるので、もう「素直にモデリングを頑張るべきでは」という気持ちになりました。

誤解してほしくないのは、フォトグラメトリがクオリティ低いのでないということです。今回くらい雑に作ってもこのレベルの成果物が得られるというのはすごいことなので。

権利面

フィギュアはほぼ間違いなく誰かの著作物です。使いかたによっては、単にキャラクターのIPだけでなく、そのフィギュアを作ったメーカーの権利をも侵害することになります。

特撮界隈では改造怪獣とか昔からあるわけですが*2、同じノリでフォトグラメトリで得たモデルを素体として改造してーというのも、イラストにおけるトレースと似たようなものですし、やはり避けるべきでしょう。

結論は結論として、以下、作例として進めていきます。

3DF Zephyr

3DF Zephyrにはいくつかエディションがありますが、Lite Steam Editionをサマーセールで購入しました。解析できる写真枚数に500枚という制限がありますが、建造物や空撮などしなければ十分でしょう。フィギュア程度なら、Free版の50枚でも十分なはず。

store.steampowered.com

チュートリアルやマニュアルはこちらに。

https://www.3dflow.net/technology/documents/3df-zephyr-tutorials/

バージョン4.009をインストール後、こちらのブログにある、座標系をY Upにする設定だけ行ないました。初期値については、Zephyr 4.xでは英単語になっていました。

manabuokajima.hatenablog.com

写真を撮る

写真は、フィギュアを台に固定して、その周囲を回りながら細かく撮影していきます*3。一般的な室内では足元に影ができてしまうため、曇天の屋外での撮影が良いようです。

Zephyrのマニュアルによると、撮影は以下の要件を満たすことが好ましいみたい。

• ISO感度: 低め
• 絞り: 高め (f/8 - F/16)。広い被写界深度が得られる
• 焦点距離は固定
• 各写真の間に重複があること (70-80%)
• 各写真の角度をできるだけ保つ

本作例は、室内の蛍光灯ひとつの下という劣悪な環境で、iPhone Xで撮影しています。カメラアプリは"Adobe Lightroom CC"のマニュアルモードで、Sec: 1/10, ISO: 40, WB: 蛍光灯 の設定。

また、簡易なレフ板（段ボール板にアルミホイルを貼ったもの）を使用しましたが、フィギュアを丸テーブルに載せていることもあってあまり有効に使えていません。

低密度点群生成

3DF Zephyrを起動し、ワークフロー > 新規プロジェクト で写真を取り込み、低密度点群を生成します。デフォルト設定で2〜3分。

下方にある茶色の点群はフィギュアを置いた丸テーブル、中央付近に、ほとんど見えませんがフィギュアがいます。上方に円形に散らばっている青い四角錐は写真の撮影位置を示しています。

この点群を生成したときの写真は94枚、うち63枚が有効でした。1/3ほどの無効写真はランダムに点在したのではなく、ダメな方向からの写真は複数枚まとめて無効となることが多いです*4*5。結果、その角度のディティールは大幅に損なわれます。

この段階で、周囲の不要な点群は処理対象から外すことができます。グレーの立方体が処理対象となる「境界ボックス」で、この外にある点群は無視されます。また、もっと柔軟に、不要な点群を選択して削除していくこともできます。

高密度点群生成

続いて、ワークフロー > 高密度点群生成 を実行します。デフォルト設定で10〜15分くらい。

前掲の岡島さんブログによると、高密度点群の時点では何も触らないほうがいいようです。

メッシュ抽出

ワークフロー > メッシュ抽出。2〜3分。

背景（部屋の壁や家具）が丸テーブルの周囲にバリ*6のようにメッシュ化されてしまったので、これを削除します。

近づくとこんな感じ。うちに美少女フィギュアがなかったので、被写体には"美味しそうなイカ"フィギュアを使用ました。バーチャル美味しそうなイカ肉！（タイトル回収）

この時点で、頂点: 39,084、三角ポリゴン: 77,823

これを削減します。手段はZephyr上でも複数、外部ツールもいくつかありますが、それらは改めて検証したいので、今回はZephyrのリトポロジーツールを使います。

ツール > メッシュフィルター > リトポロジー を、factor: 5.00、repert: 10 で適用*7。

結果、頂点: 8,933、三角ポリゴン: 17,497 まで削減できました。VRChatアバターの制限が20,000ポリゴンなので、パスできるはず。

見比べると、触手の先やえんぺらなどのエッジが欠けて（丸くなって）しまいましたが、今日のところはこのまま進みます。なお、テクスチャのぼやっとした感じは後工程でほぼ気にならなくなります。

ポリゴンメッシュはこんな感じ。

リトポロジー前

リトポロジー後

テクスチャ付メッシュ作成

ワークフロー > テクスチャ付メッシュ作成 でテクスチャが貼られます。本例では、最大テクスチャサイズ: 2048、最大数:1 としました。

スケール/回転/平行移動

ツール > ワークスペース > オブジェクトのスケール/回転/平行移動 という機能があるのですが、スケールは単位が、平行移動（原点座標）は、そもそもの基準点がわからないため、Zephyrで調整するのはあきらめました*8。

ここでは回転だけ行ない、Y+を上方向、Z+を正面方向に設定します。テーブルの面を使って、ツール > ワークスペース > 平面を選択して上向きベクトルを定義 で上方向を指定すると楽です。

テクスチャ付メッシュを出力

出力 > テクスチャ付メッシュを出力 で、.objもしくは.fbx*9ファイルにエクスポートします。

エクスポート時のオプションに"ローカル表示基準システム”(local rendering reference system)がありますが、これは、

• off: ワークスペース上のスケールと座標がモデルに反映される。ただしスケールの単位が何かわからないし、原点がどこかもわからないので、人類にはコントロールは難しい
• on: ワークスペースのスケールと座標が無視される。サイズはすごく大きい（xyz各100倍くらい）、座標はモデルの中心になる

3DF ZephyrのWebサイトには

if you are using geographical coordinates, you may need also to check “Local Rendering Reference System” as well.

とだけありました。空撮でないのでgeographicalな座標がないから上記の振る舞いになってる？のでしょうか。

リギングするならBlender等で調整しますし、今回はUnity直送ですがUnityで調整すればいいので*10、どちらでも構いません。

Unityにインポート

エクスポートしたfbxをUnityにドラッグ＆ドロップ。試しにVRChatのHome Kitにある部屋に配置してみました。

いかレスラーの身長を設定*11に忠実に242cmとしたのですが、胴が（頭足類なので頭部の上は胴です）天井を突き破ってしまいました。本編および本物のぬいぐるみ（着ぐるみ）を見た感じ、もう少し小さくていいような気がします。

なお、向かって左はスマートフォンアプリ"Qlone"で作ったモデル、右は野良犬祭2でDiGINELさんが持ち込んでいた撮影ブースで撮影してもらったリアルアバター（60,000ポリゴン・テクスチャ8192）。

Qloneについてはこちらを参照。

とりあえず今回はここまで。次回以降、リギングとかリトポロジーとかディライティングとかやっていく予定です。飽きなければ。

補足

以下、おまけ。

フィギュア撮影の難点

これまでに掲載したスクリーンショットからも、触手の間、下側、また足元などのクオリティが低いことが見て取れたはずです。これらは撮影環境の悪さが大きいのですが、フィギュア相手ではよほどライティングを頑張らないと足元の影の影響は残るでしょう。

今回はそれだけでなく、右後方はメッシュもテクスチャもおかしくなっていました。この方向からの有効な写真が無かったことが主な原因でしょう。

またアオリ（ローアングル）で撮れていないため、下側のメッシュには穴が空いていたりします。

上下逆にして撮ってみる

回避策として、被写体を上下逆に置いて撮影、フォトグラメトリ処理したモデルを結合させるのがいいのかな、と思っています。試しに撮ってみた例が以下。

吸盤のモールドまでバッチリですね。

なお、被写体を三脚の上に立てての撮影も試みましたが、いかと部屋の壁の色が近いこともあって、肝心の被写体が壁に溶け込んでしまいました。上例の丸テーブルのような拠り所も必要なのではないかと。

その他の作例

先日、小石川後楽園の円月橋を片面だけ撮影してきたものをSketchfabに上げています。片面だけなので少し角度を変えると破綻しますが。これで元写真67枚です。

Engetsukyo bridge by nowsprinting on Sketchfab

参考

manabuokajima.hatenablog.com

いかレスラー

*1:バーチャル美少女受肉の略。またたく間に広義から狭義までゆらぎのある言葉になったが、発祥についてはこちらの記事が詳しい https://www.vtuber-housou.com/babiniku/

*2:それが無ければジラースとかミレニアムファルコンとか存在しなかったわけですが…

*3:フィギュアを手に持ったり、台を回転させたりしての撮影したものは使えません。背景も含め特徴点を取るので、動かないことが要件なのです

*4:上のスクリーンショットでも、円形に並んでいる青い撮影点が二箇所途切れているのがわかるはず

*5:原因は恐らく、背景に特徴点が少なかったり、明度によるものだと思われます

*6:バリって英語のBurr、バリ取りはDeburringなんですね

*7:ちなみに［フィルターを適用］ボタンは編集対象のメッシュを上書き、［フィルタを有効にする］ボタンはコピーを作って適用してくれます。わかりにくい！

*8:スケールはZephyr Pro/Aerialなら設定できるようです

*9:マニュアルにはPro/Aerealのみと書かれていましたがLiteでもできました

*10:Transform - Scaleは、ライティングや物理を入れるときには1（等倍）であることが望ましいのですが、今はまだ置いてみるだけなので

*11:劇場公開時のパンフレットより「242cm（アンドレ・ザ・ジャイアントより大きい）」

Unity #Zenject完全に理解した に行ってきました

株式会社ミクシィさんで開催された『Unity Zenject完全に理解した』に行ってきたメモ。

connpass.com

配信アーカイブもあります。すばらしい。はじめ機材トラブル等ありますが解消します（ネタバレ

www.youtube.com

Zenjectとは、オープンソースのUnity向けDI(Dependency Injection)フレームワークです。 Zenject以前に「DIをよく知らない」という方は、まず、とりすーぷさんの『インタフェースの使い方』から見るのがいいでしょう。ここで、DIというものがなぜ必要か、なにを解決してくれるものか、がわかるはずです。

もし『インタフェースの使い方』が何を言っているのかわからないのであれば、今日のところはUnity仙人さんの『Zenjectはじめの一歩：ゲームデータをScriptableObjectでInject！』だけにしておくのがいいのではないでしょうか。

この手のツール・フレームワークは、手段から入ってしまうとマズロー*1の言う

ハンマーを持つ人にはすべてが釘に見える

状態に陥りがちです。

Zenjectのような強力な手段を乱用すると、結果的にそのデメリットだけがプロジェクトに残ってしまうことになりかねません。（完全に、とは言わないまでも）ある程度は理解した上で導入していくことをおすすめします。

ほんこれ #Zenject完全に理解した pic.twitter.com/rHE8trh2br

— デコシ (@Ash_Yin) 2018年9月6日

ゲーム案件にZenject導入した経験を語る

かせ(@KaseliaePenguin)さん

実際のプロダクトにZenjectを導入した経緯（目的）、試行錯誤したこと、どの範囲に適用すべきか、適用する上での注意点など盛りだくさん。

• SceneContextを4階層（System, Data, Env, Logic）にしてそれぞれの扱う範囲を明確化し、切り替え（本番とデバッグの置き換え等）を制御
• Bind時のAsSingle(), AsCached(), AsTransient()の違い
• [Inject]を書いたフィールドのバインドはnew()の後に行なわれる
• SceneContextの理解が大事
• InjectするものにはInterfaceを切り、InterfaceをInjectすること
• Bindはリフレクションを使うので遅い
• 真価は運営フェーズに入ってからのはず

speakerdeck.com

文脈を操る 美しきZenjectプロジェクトからの眺め 〜Contextの扱い方と活用方法〜

Mikito Yoshiya(@mikito0521)さん

4種類あるContextの階層構造と、またそれを入れ子にできる話、実際にリリース版とデバッグ用のContextを切り替える例など。

• Contextを意味のある単位に分割して切り替える
• ProjectContext, SceneContext, SceneDecoratorContext, GameObjectContext
• それぞれ入れ子にできる
• IDisposableを実装すると、Contextが破棄されたタイミングでDispose ()を呼んでくれる
• 大事なのはInstallerの設計。Contextとの組み合わせ
• 依存がわかりにくくなるので、SceneContextは二階層くらいにしておく。小さいものはGameObjectContextにまわす

文脈を操る美しきZenjectプロジェクトからの眺め 〜Contextの扱い方と活用方法〜 from Mikito Yoshiya

www.slideshare.net

インタフェース完全に理解した

とりすーぷ(@toRisouP)さん

C#のInterfaceの話。設計の話のほか、拡張メソッド、明示的な実装を書けるといった話。

• Interfaceには必ず利用者がいる。利用者側のPackageに置く。利用者側でコントロールできる
• 拡張メソッドに実装を書くことができる。traitっぽく使える
• structにInterfaceをかぶせる（実装する）ことができる
  • IEquatable<T>を実装すると、Equals()の振る舞いを自分で書ける
• 明示的な実装。InterfaceName.MethodName()と書ける。すると、Interfaceにキャストしないと呼べない

niconare.nicovideo.jp

Zenject完全には理解できなかった〜実運用におけるアンチパターンとその回避策〜

のたぐす(@notargs)さん

実運用で問題となるアンチパターンの話。Zenject自体への依存を下げるMethod injectionや、処理負荷を考慮した適用範囲の話など。

• ZenAutoInjecter
• Method injection: フィールドでなく初期化メソッドに[Inject]を指定できる
• MonoBehaviorをInjectするとき、FromComponentInNewPrefab()でなくFactory経由で行なう
• 頻繁に使うものはプールする、そもそもDIしない
• pure C# classにのみ適用するほうがいい
• Zenjectはハイリスク、ハイリターン

docs.google.com

Zenjectの機能をご紹介　〜テストの巻〜

@nozomin770 さん

Zenjectを適用したプロジェクトのEdit mode testで使うZenjectUnitTestFixtureおよび、Play mode testで使うZenjectIntegrationTestFixtureの話。

※スライドupされたら貼ります

Zenjectはじめの一歩：ゲームデータをScriptableObjectでInject！

Unity仙人(@lucifuges)さん

クラス設計など行なう前提でなく、データをScriptableObjectで持ち、それをScriptableObjectInstallerで切り替える話。

docs.google.com

所感

実際のプロダクトにZenjectを導入した経験談なども語られ、とても勉強になりました。皆さん、ただ「便利だよ」でなくデメリットにも言及されており、とても地に足の着いた内容だと感じました。 また、ContextやInterface、テストなど、それぞれフォーカスされた箇所が異なるセッションで構成されていたのもよかった。

自分ではまだ、DIが生きるほどの規模のものを作っていないのですが、今回の知見を取り入れて良い設計を目指していきたい。

参考

みなさんご参加ありがとうございましたー。Zenjectは中々国内記事が少なくこうやって知見が溜まるのは大変ありがたいので、どんどん公開して集合知集めていきたいですね。
僕もUNIBOOK10にZenject書いたのでよかったらどうぞ(宣伝)https://t.co/VZNB1IMUBA
#Zenject完全に理解した

— いも@efb~相手は死ぬ~ (@adarapata) 2018年9月6日

Unityゲーム プログラミング・バイブル

*1:心理学者のアブラハム・ハロルド・マズロー。欲求5段階説の人