0014-06-25

GTMF大阪のメモ GTMF大阪のメモ - Nao_uの日記 を含むブックマーク はてなブックマーク - GTMF大阪のメモ - Nao_uの日記 GTMF大阪のメモ - Nao_uの日記 のブックマークコメント

Unityの新しいUIの説明。 Unityの新しいUIの説明。 - Nao_uの日記 を含むブックマーク はてなブックマーク - Unityの新しいUIの説明。 - Nao_uの日記 Unityの新しいUIの説明。 - Nao_uの日記 のブックマークコメント

3Dに置ける、レイアウトもやりやすい、エッジも残せる、

サービス&デバイスの会社に生まれ変わる

モバイルファースト、クラウドファースト

XboxLive会員数4800万人

標準化への投資、オープンソースを歓迎

dgsl fbxを確認、3Dモデル表示の標準化とVSへの組み込み、Pixの統合

cocos2dがWindowsストアアプリに対応

unityで作るWindowsストアアプリ

広告をゲームの中のビルに張るなど、自然に世界に入れこむことも可能

開発者登録、個人で年間1800円

学生支援、起業家支援 → 開発者の囲い込み

XboxLive 専用のサーバが30万台

ID@Xbox

-----------------------

turn10で傷がつくのをサブスタンス

サブスタンスデザイナーに恵比寿を統合

steamでは買うな、私たちの商売が成り立たなくなる

物理ベースの3Dペイントソフト

-------------------------------

Wwiseのモバイルでの導入事例 Wwiseのモバイルでの導入事例 - Nao_uの日記 を含むブックマーク はてなブックマーク - Wwiseのモバイルでの導入事例 - Nao_uの日記 Wwiseのモバイルでの導入事例 - Nao_uの日記 のブックマークコメント

Klabの人、射得b裏慣れてる印象

モバイルとコンシューマの性能差の垣根はだいぶ減ってきてる

UIがかっこいいからWiseを使いたかった

Web系の会社の人はプレゼン慣れしてる印象

スマートフォンゲームでコンシューマーと同等のクオリティを。

 フローの効率化

 サウンドチームがイメージした演出を、よりスムーズにゲームに反映させる

  (伝達のコストや差し戻しのコストを減らすため!)

なぜWwiseか?

 →他のドルウェアより細かく調整できる

 →開発予算合わせたライセンス携帯があった

 →XboxOneで仕様経験があった

Wwise導入前に難儀していた…

 開発側で実装が難しいこと

単にならすだけならいいんだけど、

 →ループ回数指定

  同時発音数、再生挙動聖女、イントロ付きループBGM,

  フェードイン合うと、ダッキング、ランダム再生処理

 BGM停止時にフェードアウト、三秒くらいで、→ このページに遷移する時は1秒くらい、とか

  特定SEをならす時はBGMを50%に、

  →複雑な演出を組もうとするほど、開発とサウンド官の伝達コストが増える

サウンドからの細かい要求に答えようとすると工数がとても増える

Wwiseゲームエンジンの拡張なしに、そういった要求に応えられた

※イベントを渡して、イベントに対して何をするかをサウンドが直接実装する!

 これ、SLinkである程度実現できてそう。

オーディオファイル管理の煩雑さ(大量のエクセルシートで共有してたような情報)

 →一つのオーディオデータから複数の差分を作る機能が充実している(ランダムでピッチを変える、など)

※ファイル管理がWwiseの機能でとても楽になる

エフェクトが充実している、(リバーブ、ゲイン、ディレイ、ピッチシフトなど)

圧縮設定を数値で設定可能、音質の劣化が通常のmp3に比べて低い、圧縮もデコードも優秀

基本フロー

 →イベントとバンクを用意して開発に渡す

  →開発側で、受け取ったバンクとイベントをUnityに追加して、サウンドマネージャにイベントを追加

  →指定のタイミングでイベントを再生する

ステージごとに違う環境音をならす、BGMと同期して鈴を鳴らす、みたいな細かい制御

※イベント発行と、そのイベントに寄って起こることを分離。プログラマは圧倒的に楽になる

フィーバーモードになると、ショットSEが変化して、断続的にピッチが上がるなどの演出が入っている

 →フィーバーの開始と終了のイベントを呼ぶだけ。

  (フィーバーの中でショットSEをどうするかはWwise側でうまいことやる)

ポーズ時の処理

 →SE停止、BGM音量50%、ちょっとこもった音にする、をWwiseで完結

チャージショット時にBGMを一瞬小さくする、などもWwiseでできる

今後に向けて、インタラクティブミュージックを導入したい

 →Wwies側の機能でできるので、サウンドだけでそのあたりも実装できる

サウンド側でそういうことを考える余裕が出る。お遊びを入れる余裕もできる。

※→サウンドも、プログラマも余裕ができる、これが一番大きい?

 →なぜ、サウンドミドルウェアはここまで幸せになれるのか?

アセットバンドル対応したい

閉じてるし、完成度も高い。

 →もはや、個別の開発会社が用意すべき物じゃない

  →ファーストパーティはどうすべき?

   →個人的には、自前で持ってる方がいいと思う。同じ物を作るにしても、そのコストに見合う価値はあるんじゃないかと。山本さんはどう思うかしらないけど。

プラチナの人が質問

 →CPUパフォーマンスはどうだったか?

  →特別なチューニングは行っていない、細かい情報は出せない

   →サウンド周りによって問題は出なかった、という認識

ライターの小野

 →タイトルの開発規模はどのくらいだった?

  →小規模、スタートアップ時期は数名から、現在も小規模の範囲。

Wwise導入にかかったのは一週間程度だった。

クリエイティブなところの質問

 →作曲とかSE、効果音について、

  →リアル寄りにするのか、そうでないのか →殴られた音も、リアルではないポコっと言うような音にする、とか。

エフェクトとサウンドは似てる。

ミドルウェアとしての完成度が高そう

サウンドとエフェクトの違いは、モデルとの連携。

サウンドでも位置の追従などはあるけれど、エフェクトよりずっとアバウトで住むことが多い

ここまでのものを個々の開発会社が同じ物を用意しようとするのは現実的ではない!

ゲームエンジンや3Dモデルの描画システムとの連携が重要

モーション

NIGOROロゴ、マイクロソフトのID@Xboxで見た!

-------------------------------

ガンスリンガーストラトスでも、続編を作る時にプログラマとのやり取りのコストが問題になっていた。

ワンショットは問題ないが、特定SEがなっている時に他のSEの音量を下げるなどが大変で、結果としてWwiseを導入

(DX9)独自言語でウーバーシェーダーを作って、マテリアルの組み合わせを調査して、

組み合わせにあったシェーダーがなければ動的生成していた

→DX11でダイナミックシェーダーリンケージを使おうとしていた

(新規タイトルを作るなら問題ない、っていってるけど、数ms遅いってことじゃ?)

------------------------------------------------------------------------------

ナックの話。 ナックの話。 - Nao_uの日記 を含むブックマーク はてなブックマーク - ナックの話。 - Nao_uの日記 ナックの話。 - Nao_uの日記 のブックマークコメント

市松模様の仮部屋

セグメントを30秒で走り抜ける長さに(クラッシュバンディクーにあわせる)

セグメント中に7〜8個のチャレンジを入れる

※このチャレンジを表にしてたりするせいで、ゲームが単調になってるんじゃないか、とか思った。

 バランスが良すぎて意外性がない。延々同じことをやってる感じになる。これは良くない!気持ち悪い

朝礼、少人数、スタンドアップミーティング

アウトソーシング

アジアベンダー4社

アセットのファイル名と工数が描かれたアセットリスト、発注書

現場のアーティストと相談しながらわかりやすい発注書をかく

製作仕様書、アウトソース向けに教えなくていい情報を消したもの書

アートワークガイド、世界観の説明や設定方法のドキュメント

クオリティバー、完成品3Dモデル、命名規則とクオリティのラインを住めす

QAシート、PMとのメールのやり取りなども

フィードバックシート、アクセルごとにシートに分けたエクセル、できるかぎり画像を多くして誤解が少ない要に

→ここまでトライアル

トライアルが終わるとベンダー評価

 →クオリティ、得意分野、理解力、コミュニケーションなどを評価

インターナルチェック、アウトソーシングを活用して行けるのかをチェック

 →何を発注するのか、発注形式の見直し、発注のの精度やレミィーのタイミング

 →フィードバック、ゲーム制作と発注作業の両立、フィードバック精度や時間のかかり方の検証

 →コミュニケーション、メールのやり取りや問題点の洗い出し

アウトソーシングに必要な準備

 →業務の標準化、独自ツールや個人に頼らない

 →クオリティの意識統一

グラフィックス概要

CG映画の要な柔らかい質感表現、統一されたライティング

ライティングを直接光と間接光似分ける、拡散反射と直接反射に分ける

直接光はディファードレンダリングを採用

半透明はフォワード+

パーティクルはフォワードでやっていたが、負荷が高かったので球面調和勘数に圧縮してこんピュートシェーダーで。

Gバッファ、法線は16bitXYで2chに圧縮 法線の精度が必要な絵作りで、法線マップにBG5がつかえるので。

ライト透過率、反対からの光をバッファに入れてる(クリスタルなどで使う)

ライティングはいくつかの今ピューとシェーダーの組み合わせで実装されている

カスケードは4段

アーティストによってポイントライトやラインライトなどが置かれている

環境光:

AO: SSAO + プリミティブのAO + 高さオクルージョン(ワールドAO?)

空間にSHを並べる、容量削減のために不均等なグリッド。

空間を再帰的に8分割

2x2x2mのグリッド

前計算で作ったキューブマップをスクリーンスペースで適用、

 +ローカルリフレクション

キューブマップ、どう切り替えてる?

単純にAIwokakerutokuzumu

色残しAO カラー ^(2-AO)   通常のAOとブレンド、肌などは100%色残しAOを使用、

GPUはハイエンドだが、CPUは若干落ちる

→オクルージョンかリング(CPU)

→ジオメトリ員スタン寝具

→並列化

荒い深度バッファとバウンディング箱をCPUで描画してカリング、テクスチャが20枚くらいあってグラフィックコマンドを作成するコストを削減

最悪でもCPUはトントン、(2msくらい)、GPUは減る一方。ライトの影響範囲も同じようにカリングしてる

頂点シェーダーに64個arrayで投入できる、

ポストエフェクト以外はインスタンスを前提、PS4ではよほどの理由がない限りやったほうがいい

4000個のパーツを100ドローコールで賭けてる

レンダリングを一フレーム遅延させた

 →レイテンシが99msになった、改善したい

部分常駐テクスチャ、しぇーだーぱいぷらいんの効率化、

GPUが50%しか活用できてない、

開発中のイテレーション速度がわるい、1GBのデータがあって読み込みに5分くらいかかってた

チーム運営やアウトソーシングなどについて踏み込んだ話が出ていて、とても実務的・実践的な話で興味深かった。