この前は2.5D化の中でスプライトシェイプを利用して足場を作ったが、タイルっぽく足場の構築なんかも出来ると便利そうだなぁ、ということで 2Dではなく3Dでタイルをマイクラみたいな感じに配置できるUnityTile3D のように、３Dオブジェクトを配置できると便利そう。 少なくともこれはライセンスはMIT Licenseなので利用上特に制約はなし。 ただ、この動画にある2DTilemapExtrasは使い勝手が別物と思われる。 今回作りたいのは2.5Dの世界で3Dはないこともあり、普通にパッケージマネージャーからDL出来るExtrasの方を試してみる。 パッケージマネージャーを開いて歯車から高度なマネージャーよりEnablePreviewPackagesをチェックすると出てくるので、 通常の2DTilmapと両方インストールすると使える。 タイルマップ まずは普通に矩形の2Dタイルマップを作成する。 どの方向にタイルマップをセットするかはTilemapの親のGridでXYZの箇所で選択可能。 画面上のOpenTilePaletteでパレットを開いて利用するオブジェクトを選択する。 手持ちに立方体がないので、Assetストアでcubeで検索して無料のAssetをダウンロード 2D PixelArt：3Dなのか2Dなのかよく分からないのでインポートしてみたが、2D画像なので今回使うものではない CubeWorldBrickBlocks：キューブ状のオブジェクトなのでこれを利用 タイルパレットでGameObjectBrushに変更、Cellsでオブジェクトとしてキューブをセット。 描画ツールでブロックが置ける。 コライダー キャラクターとの衝突判定はタイルマップコライダーを設定してもダメだったので、 設定している3Dブロックのプレハブに対してボックスコライダーをセット。 （一応ボックスコライダーに対してコンポジット設定を入れたが、複合コライダーは有効なのかまでは未確認） これが出来るとボックス的なオブジェクトも配置できるので2.5Dの世界を作りやすくなる。

0.0 はじめに Unityでゲームを作っていると規模が大きくなるにつれ起動速度が遅くなる場合があります。私の経験した症状はアプリ起動後、Unityのロゴが出た後、最初のシーンの画面が出るまでに10秒以上かかるというものでした。 この症状を改善させるうえで分かったこと、行ったことをまとめておきます。 1.0 症状 アプリ起動するとUnityのロゴが出ますが、その後、最初のシーンの画面が出るまでに10秒以上かかる。 2.0 原因 起動時に音データを一度に読み込んでいた。この処理に時間がかかっていた。 (音データが多くなればなるほど多くの時間がかかっていた。) 3.0 対策 音データをバックグラウンドで読み込む設定に変更することで解決しました。 4.0 解決方法 音ファイルを選択、Inspector（インスペクター）に表示される Load in Background にチェックを入れるだけです。 5.0 注意 この設定により音ファイルがバックグラウンドで読み込まれるようになり、スタート時の先読み込みが無くなります。このため未読み込みの音の再生時に若干のタイムラグが発生することがあります。BGMなど最初のシーンで再生する必要がある音は Load in Background の設定を外しておきましょう。

はじめに TimeLineを設定したPrefabをAssetBundle化するときに問題があったのでメモ Signalとは TimeLine上で任意のタイミングでイベントを発行したいときに使用するものです。 また、EmitSignalでSignalを指定するために、Create/Signalで事前にアセットを作成しておく必要があります。 SignalReceiver こちらのコンポーネントで、シグナルがあったときに呼び出す関数の設定ができます。 問題 UnityEditor上では問題なく関数が呼び出されたのですが、AssetBundle化してAndroid実機で確認したところ、 呼び出されないという問題がありました。 解決策 SignalアセットをTimeLineが設定されているPrefabと同じ階層に入れて、そのディレクトリにAssetBundle名を指定してビルドしたところ問題が解決しました。 SignalReceiverも同じ階層のPrefabにアタッチした方が良さそうです。 最後に こまめに実機確認する事は大切ですね?

はじめに: Genvid SDKについて Genvidは、動画ストリーミングとブラウザを介したインタラクティブな体験を組み合わせた「大規模インタラクティブ・ライブ・イベント」（Massive Interactive Live Events）を実現するSDKです。 https://www.genvidtech.com/ja/mile%E3%81%A8%E3%81%AF%EF%BC%9F/ ゲーム技術をベースに、リアルタイムで進行する動画番組に対して、動画視聴者が能動的に参加できるシステムを提供します。 コンテンツ内のキャラクターが次に何をするかを投票で決めたり、ミニゲームをプレイしてポイントをため、特定のキャラクターを応援するなどの活動を経て、物語が変化していきます。 MILEは、Unityを使いFacebook上で配信されている「Rival Peak」と、Unreal Engine 4を使った「Project Raven」があります。 『RIVAL PEAK』が示す次世代の視聴者参加型デジタルエンタテインメント https://news.yahoo.co.jp/byline/onokenji/20210326-00229353 Genvid SDKの導入については、Genvidディベロッパーサイトの日本語マニュアルからご確認ください。 https://www.genvidtech.com/for-developers/ 視聴者の操作が反映されるまでカウントダウンする ストリーミング動画コンテンツに視聴者インタラクションをつけようとした場合は、視聴者が何らかの入力をしてからコンテンツ側に反映され、それが動画で見えるまでにタイムラグが発生します。 「コメント連動」などで視聴者インタラクションを実装する場合、視聴者がコメントしてからその操作が反映されるまでにラグがあり、またコメントはどんどん流れてしまうので、「操作した感」「参加している感」がどうしても薄まってしまいます。 Genvidは動画コンテンツに視聴者が参加できる仕組みとして、動画の上に操作を表示する「オーバーレイ」を使用します。 加えて、「現在ブラウザー側ではどの程度の遅延が発生しているか」を数値として取得できますので、これを使えば「視聴者の操作がいつ反映されるか」を正確にカウントダウン表示できます。 以下はUnityを使った簡単なデモです。ゲームをキャプチャしたものではなく、ブラウザに配信されているストリーミング動画をキャプチャしています。 左上の緑色のボタンは動画の上からブラウザ上でHTMLのボタン要素を重ねて描画しています。 （分かりやすいように設定で６秒の遅延を加えています） ボタンをクリックすると、そのクリック操作があと何秒で「ストリーミング動画上で」描写されるのかを正確にカウントダウンします。 これにより、動画視聴者に「自分の操作がちゃんと反映されたのか」という不安を解消できます。 IGenvidClient.streamLatencyMS を活用する 具体的な実装方法を見ていきましょう。 ブラウザ側のGenvidのクライアントスクリプトから、フィールドstreamLatencyMSからストリーム遅延 (ミリ秒)が取得できます。 IGenvidClient.streamLatencyMS https://www.genvidtech.com/doc/SDK-1.32.0/reference/web_sdk/js/genvidClient.IGenvidClient.html ボタンを押してGenvid Eventを投げる簡単なスクリプトで解説します。 サンプルコード var genvidClient; let delayToColorSwitchS = 0; fetch("/api/public/channels/join", { method: "post" }) .then(function (data) { return data.json() }) .then(function (response) { genvidClient = genvid.createGenvidClient(response.info, response.uri, response.token, "video_player"); genvidClient.start(); }) .catch(function (e) { console.log(e) }) dropBomb.onclick = function () { genvidClient.sendEvent([{ "key": ["dropBomb"], "value": "1" }]); //delayToColorSwitchSに秒単位でボタン押した瞬間の遅延を保持 delayToColorSwitchS = genvidClient.streamLatencyMS / 1000; } setInterval(function () { if (delayToColorSwitchS > 0) { dropBomb.textContent = Math.ceil(delayToColorSwitchS); delayToColorSwitchS -= 0.01; } else { dropBomb.textContent = "DropBomb"; } } , 10); 仕組みは単純で、ボタンが押された瞬間に現在の遅延を保存し、setIntervalを使ってその値を減算＋画面表示に反映します。 （他フレームワークとの組み合わせでもっと簡潔に書けると思います） 各処理について説明します。 Genvid Clientの初期化 まずはGenvid Clientの初期化です。これはサーバー側のコンテンツからデータを配信する「Genvid Stream」を含まない実装のため、最小限の手続きで初期化を行っているものです。 var genvidClient; let delayToColorSwitchS = 0; fetch("/api/public/channels/join", { method: "post" }) .then(function (data) { return data.json() }) .then(function (response) { genvidClient = genvid.createGenvidClient(response.info, response.uri, response.token, "video_player"); genvidClient.start(); }) .catch(function (e) { console.log(e) }) また、フィールドdelayToColorSwitchSを後の処理のために用意します。 ボタン操作に合わせてsendEventを呼ぶ 次に、html側で定義しているボタン「dropBomb」のクリック操作に、GenvidClient.sendEventを紐づけます。 この時、ボタンをクリックしたタイミングでフィールドdelayToColorSwitchSにそのときの遅延秒数を保存します。 dropBomb.onclick = function () { genvidClient.sendEvent([{ "key": ["dropBomb"], "value": "1" }]); //delayToColorSwitchSに秒単位でボタン押した瞬間の遅延を保持 delayToColorSwitchS = genvidClient.streamLatencyMS / 1000; } 送信している配列は、あらかじめGenvidサーバー側でJSONスキーマを使って設定しておく必要があります。手順については以下のポストをご確認ください。 フィールドに保存した遅延秒数を監視してカウントダウン 最後に定期実行であるsetIntervalを使って、秒数のカウントダウン処理を行います。 setInterval(function () { if (delayToColorSwitchS > 0) { dropBomb.textContent = Math.ceil(delayToColorSwitchS); delayToColorSwitchS -= 0.01; } else { dropBomb.textContent = "DropBomb"; } } , 10); 応用方法 今回は単純なボタン操作のカウントダウンに使用しました。 応用として、ボタンが押せるタイミングのインターバル調整に利用したり、カウントがゼロになったタイミングでオーバーレイ側にも何らかのアニメーションを表示して動画と同期した演出をするなどの活用もできます。 動画と同期した動きをブラウザ側でもレスポンスよく出すことで、動画視聴者が「コンテンツに参加」している感覚を強めることができます。 ぜひいろいろと試してみて下さい。

新しくアプリをリリースするためにまずテスト広告を付けて実機で実装するために(ストアにリリースするために使うゲーム画面の画像を撮るために)手間取ってので書いておきます。 ・開発環境 ・Unity2019.1.5F1 ・Windows8.1 ・Android ・Mobile Ads Unity ・やったこと まずunityで作ったプロジェクトに広告を入れるためにMobile Ads Unity 6.0.0を入れてビルドしてみましたが、エラーが出ました。 コンソールに大量のエラーが出て色んなのが出て自分ではわかりませんでした、がSO-DATAという事を書かれてたのでももしかしたらUnityバージョンがAdsに合ってないのかな？と思いAdsのバージョンを5.4.0を入れなおして再度ビルドしたら成功しました。 ・まとめ Adsを提供してるgithubにそういう事を書かれてるんだろうけど英語で理解できませんでした。 今後GoogleAdMobを入れる時はUnityバージョンとAdsバージョンを確認して合うのを入れるという感じが良いと思いました。 確認した段階では unity2019とMobileAdsUnity5.x.x(5.4.0確認済み) Unity2020とMobileAdsUnity6.x.x？(未検証) だとエラーなくビルドが通るみたいです。

Unity設計入門の目次はこちら はじめに 今回は、MVPの実現方法として、ViewがModelを監視して、毎フレーム自分を書き換えていくという監視型Viewの考え方について、Unityでの有効性を検討していきます。 監視型Viewとは ViewはModelを読み出す権限を持っています。そして毎フレームにModelの状況を監視します。 そして、Modelに変更が生まれた時点でViewを書き換えます。 監視型Viewの実装 Modelが内部状況をpublicかつ読み取り専用な変数として提供します。ViewはModelへの参照を持ちます。Viewは直前のModelの値を常にキャッシュしておき、Update()で変更を検知します。 監視型Viewが不適切だといえる理由 ModelにもViewにも属さないデータの行き先が用意されていない これは、第2章その1で挙げた問題点です。詳しくはそちらの記事をご覧ください。 監視Viewはデータ出力における演出関係の変数の行き場がないという問題を完全に無視しています。 それだけでも監視型Viewがゲームでは使いづらい概念であることが分かると思います。 ゲームではModelの変化以外の要因でも見た目が変わることがある 監視型Viewは根本的に「ViewはModelを映す存在である」という発想に立っています。 しかし、ゲームではこの発想が常に正しいとは限りません。例をいくつか挙げてみましょう。 キャラの着せ替え画面で閲覧しているときに、時間経過で勝手にキャラが回転する。Modelで保持しているキャラの服装は変化しない レースゲームにおいて、離脱した後に、元の場所に復帰するときにアニメーション演出が発生するが、Modelで保持しているゲーム上での車の位置は変わらない(マリ〇カートで崖から落下した後、カートがジュゲムに戻してもらえるなどを想像してください) などと言った場合、Modelとは無関係に見た目が変わります。 しかし、監視型Viewはこれらを感知する手段がありません。 なぜなら、プレイヤーの入力は全部Presenterに投げていて、ViewからPresenterに問い合わせをすることは禁止だからです。 監視型ViewはModelだけを見る存在です。 これを解決するためには「ModelにView変更用のフラグを用意する」などModelの純粋性を破壊するようなことをせざるを得なくなります。監視型ViewはModelが変更されないのにViewが変更されるような処理に弱いのです。 毎フレーム監視するコードはパフォーマンス・可読性ともに良くない 毎フレーム監視している場合 直前フレームで値が何だったかをViewに覚えさせる(Viewのコードが単純に複雑化する) 毎フレームModelの情報に従ってViewを更新をする(パフォーマンス的に劣る) のうちどちらかをしないといけません。 また、UIの仕様がややこしくなっていくにつれて、2フレーム前のキャッシュだったり、3秒前のキャッシュだったりを管理する必要が生まれてきます。(典型的にはキーの長押しなど)この手のデータは、「単純なView」という原則を著しく破壊します。なぜなら、フレームという低レベルの仕組みを強く意識したコードになるからです。 なお、どうしても監視型Viewを使いたい場合には、UIの規模が大規模にならないうちはパフォーマンスへの影響は微々たるものなので、どちらかと言うと毎フレーム機械的に再生成してViewを薄く保つことを勧めます。 Viewの検証にModelを使いたくなるので、独立したテストが難しい 監視型Viewをテストするには、毎フレーム値を提供しなければなりません。 こういうプログラムをModelとは別にテスト用で提供するのはそれなりに手間がかかってしまいます。 結果、ModelとViewの独立性が下がってしまうことを許容してでも、動作確認にModelを使ってしまい、保守性を下げてしまいます。 ModelがViewを意識してしまう Viewを小さくしようとすると、どうしてもModelはViewで加工の手間が小さくなるようにView寄りのデータを提供したくなります。結果的に、Modelとは関係ない「カードの表示アイコンの色(RGB)」とか「設定画面のチェックボックスの成否」とかをModelに定義していしまうことが起こりやすいです。 Modelの純粋性が下がることのデメリットはここまで強調してきた通り「Viewを意識した項目のテストはViewを起動しないとできない」という点で現れます。 ViewがModelを監視するロジックが複雑化する Modelの変数を監視する、とひとくちにいっても、かなり複雑化します。ゲームならなおさらです。 例えば、ボードゲームを作る状況を考えてみましょう。この手のゲームでは、Modelは「各マスに存在する駒」を二次元配列として提供していたと考えるのが自然だと思います。 ここで「駒が1マス進む」というイベントが発生したとします。すると、ViewはModelの変更を検知するわけですが、「二次元配列のどのマスのインスタンスがどのマスに移動したか」を調べるのは、結構ややこしいことになります。二重forや大量のキャッシュなど、容易に複雑化を生みます。そして、Viewにややこしいロジックが存在すること自体のデメリットもあるので、非常に悪い設計を生みやすいです。 どういう場合に監視型Viewが適しているのか 「絶対に演出などを目的とした変数・条件分岐を追加しないと決めているシーン」に利用する分には全く問題は発生しません。 メリットは以下の2つです。 Presenterはデータの流れが1方向になり、理解が容易になります。 Presenterのデータ加工コストをViewに持たせることができるのでPresenterが楽になるでしょう。(なおこの加工が複雑だった場合、Presenterで書いた方がマシですので、監視型Viewによる実装はやめましょう) 具体的に役に役に立つ場面としては 3D機能などを目当てに業務用ツールをUnityで作成する場合 プロトタイプとして演出以外を先に作ってしまって、そのあと改めて演出を含むシーンを新規作成する場合 では有用な実装方法になる可能性があります。 特に3D機能を持つ業務用アプリに関してはOpenGLやDirectXを触って作成するよりUnityの方が開発コストが低くなることも多いように思います。 おわりに Unityにおける監視型Viewは不要に巨大なViewを招きやすいようです。 やはりゲーム開発は本質的に複雑であることを痛感させられました。