ゲーム開発 に所謂なアプリケーション設計パターンをおいそれと適用するのは難しい - @hadashiA
アドベントカレンダーでもなんでもない記事 0日目です。 Unityで長らくゲーム開発をやっているけれど、Web界隈などで色々と発達しているアプリケーション設計パターンをおいそれと持ち込めば良いわけではないと感じているので、それについて考えてみようと思う。 ここでいう設計パターンていうのは、たとえばUIとかをつくるフレームワークの競争で発達してきた MVC派生 や ReactとかのElmアーキテクチャに影響を受けたものたち、はたまた、Webサーバ(HTTPサーバ) を書くときに 「良し」とされている 、DDD的な考え方の上での、抽象レイヤと実装レイヤの分け方を教条化するクリーンアーキテキクチャとかなんかそういうの。 追記: ゲームでも「ドメインロジックとプレゼンテーションの分離」はした方が良いと思っている。全体としては狭義でのMVPとかは自分もやってる。 こういった者達は、先人のアイデアや言
Unity界最速DIコンテナVContainer が速い理由の解説 - @hadashiA
拙作の Unity用DIライブラリ、VContainer の v0.9.0 では、ILコードをコンパイル時に生成することによるメタプログラミングの高速化が足されました。 Unity用DIライブラリ VContainer の 0.9.0 を撒きました。 コンパイル時IL生成による高速化機能をマージしました。(オプション) IL生成でさらに 当社比 3-6倍くらいは速くなりました。これできっと Unity用 DIコンテナでは完全に最速になったんじゃないかな-と思います。https://t.co/YkHXXgP7nD pic.twitter.com/NFUxvLVzKd— ハダシA (@hadashiA) 2020年7月26日 この機能をつかうと、Zenjectのデフォルトとの比較でディタ上では50倍くらい、IL2CPPでは20倍〜くらい速い結果になっています。 また、グラフのとおり VCont
Vcontainer v0.2.0 に ECSサポートが入りました - @hadashiA
先々々週 あたり、Unity(ゲームエンジン)で使える 自作DIライブラリを公開しました。 github.com 高速でコードサイズが小さく、GCゴミが少ないところが特徴です。 Zenjectと比較すると、ZenjectがDIの宣言によってあらゆることをコントロールしようとしているのとは対照的に、VContainer は DI宣言内ではできることを限定しつつ、DIのスコープ自体をコントロールするAPIを提供していたり、アセットやシーンのロードのしかたをアプリ側の自由にさせるといった、 Unityや基盤部分にDIを従属させるような考えかたをしており、 Unityのどのプロジェクトにもフィットしやすい 大根おろしに醤油をかけたもの的な存在を目指しています。 そして先日、v0.2.0 (という控え目なバージョン)に ECS (Entity Component System) のサポートを入れてみ
VContainer v0.0.1 - Unity用の速くて軽いDIライブラリをリリースしました - @hadashiA
github.com Unity (ゲームエンジン) で動作する自作DIライブラリを公開しました。 特徴は、 速くて薄くて軽い GCゴミがとても少ない コードファーストでスコープを切れる機能 (Autofac の影響) MonoBehaviourに依存しないカスタムクラスをUnityのライフサイクルに割り込ませる (Zenjectの影響甚大) 独自の PlayerLoopSystem のサブシステムを利用しているので、不特定タイミングでつくったスコープの IInitializable とかも動作する。 コンテナがイミュータブル なのです。 Zenject と比較すると、メソッドチェインをつなげるとなんでも宣言できる(Fluent API) は最低限に、使い方の迷いようがなく透明度の高いAPI を心掛けています。 APIの比較表をつくりました Scopeの親子関係はある程度(ていうかかなり)
やってる
アドベントカレンダーでもなんでもない記事 0日目です。 Unityで長らくゲーム開発をやっているけれど、Web界隈などで色々と発達しているアプリケーション設計パターンをおいそれと持ち込めば良いわけではないと感じているので、それについて考えてみようと思う。 ここでいう設計パターンていうのは、たとえばUIとかをつくるフレームワークの競争で発達してきた MVC派生 や ReactとかのElmアーキテクチャに影響を受けたものたち、はたまた、Webサーバ(HTTPサーバ) を書くときに 「良し」とされている 、DDD的な考え方の上での、抽象レイヤと実装レイヤの分け方を教条化するクリーンアーキテキクチャとかなんかそういうの。 追記: ゲームでも「ドメインロジックとプレゼンテーションの分離」はした方が良いと思っている。全体としては狭義でのMVPとかは自分もやってる。 こういった者達は、先人のアイデアや言
Unity 特有のパフォーマンス劣化の落とし穴 2018歳末ふりかえり - part 1 - @hadashiA
今年、Unty製プロジェクトのパフォーマンス改善をやる機会があったんですが、世の中のかっこいい事例に出てくるような、ハードウェアやVM/コンパイラの気持ちになったミクロなチューニング、フレームワークの制限を回避するための大胆な再実装…… そういうかっこいい作業、には思ったよりならず、なによりもまず先に、Unityを使っているが故の落とし穴から這い出る一本道の作業が多めになってしまった。 それというのも、Unityは非常に、そこそこのものを最小手順で 確認/動作できる、誰でもかんたんにモノをつくれる、という部分を大事にしているから、「パフォーマンスを考えると普通はこうなっていてほしいよね」といった部分が犠牲になっている、あるいは手が回っていない、という部分が実際まだまだあるように思えた。 simple よりも easy を取っているというやつだろうか。 仕事でやっていたプロジェクトは、まずコ
Unity Technologies によるオンライン対戦FPSゲームの実装にふれてみた - やってる
Unity（ゲームエンジン）とGoogle が パートナーシップを結んだぜ、みたいなニュースが記憶に新しいですが、 先月末くらいに、彼らのオンライン対戦FPSのサンプルコードについての詳しい解説動画が上がってました。 FPS Sample Game Workflows | Unity ちなみに、このゲームのソースコードは、 アセットも含めて全て Github で公開されています。 Unity-Technologies/FPSSample 動画のなかでも、とくにこれが興味深いです。 Deep dive into networking for Unity's FPS Sample game - Unite LA - YouTube UDPを使ったオンライン同期のサーバサイドの実装、とくに同期の詳細なメカニズムについて、ここまで噛み砕いた説明を見たことがなかったので、僕にとってはなかなかインパク
Unity に mruby 組み込んでる - @hadashiA
実験的に、Unityにmrubyを組み込んで使ってみてる。 基本的には Unity内のコードは全て c# で書くわけだけど、ゲームの基盤部分もすべてc#で書くだけに、それとは別に、ゲームのコンテンツ部分だけを集中して記述できる分離された薄いレイヤがあると便利だ、という話がある。 たとえば、ゲーム内のキャラクタの会話や演技、そういった設定たちが、再コンパイルせずに実行中にホットリロードで変更を確認しつつ開発を進められると嬉しい。 そこで、 mruby を使ってみようかなと思い立った。 もちろん、なにもmrubyを組み込まなくたって、構造化されたただのデータ(たとえばyamlとか…) なんかでも充分、ゲームの内容を表現することはできそうだ。 しかし、それはそれで、決して安い買い物とも言えないような気がする。 複雑なデータ構造は、invalidでないことを完璧に保証するつまらないコードを書くのが
将来は標準のDOM APIを使うのがより身近になると思ってる - @hadashiA
最近、標準のDOM APIは別に悪くない、と考えるようになった。 そう考えて劇的に何か変わるかというと、現時点ではライブラリを使うことに慎重になるという気分的なものかもしれない。 気分が変わった結果として、僕は直近のプロジェクトのごくふつうのWebページでは、標準のDOM APIを直接さわる形に変更した。フレームワークは使わずRxJSのみ使っている。結果、パフォーマンスと細かいUIの挙動とコードの透明度が改善された。 標準のDOM APIは、べつに不必要に冗長なところがあるわけではないし、扱っているものが特別プリミティブ過ぎるとも思わない。むしろ、意図しない動作が入りずらく、インターフェイスが明示的にできている点なんかは優れている。 欠点があるとすれば、あらゆるスコープから好きなNodeの書き換えが禁止されてない点、クライアントサイドでのレンダリングのサポートが弱い点、何をするにもまず検索
RxJSでMVVMやってる - @hadashiA
Rxは、すごくUIを書くのに向いているのではないだろうか。アプリケーションの状態を山盛りの変数で管理することから解放され、状態から状態へ変換する関数を書けばよくなるから。 非同期処理を同期っぽく書きたいならawait でいいじゃん。UIイベントを宣言的に書きたければ 2-wayバインディングがあれば良いじゃん。という話では終わらず、その辺の問題解決に加えて、値の発生器を全て同じ宣言にまとめられ、状態変数がなくなるところが書いていて楽しいところです。 // たとえば、、 Observable.fromEvent(searchBox, 'input') // 検索窓に字が打ちこまれたら .debounce(500) // 0.5秒ごとに .map(e => e.target.value) // 入力されたテキストを .filter(q => q.length > 0) // 1文字以上の場合だ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
