DOTS
Unmanaged memoryを使おうとすると必然的に設計されるもの
ゲーム実装を意識：position/rotationは省メモリなので無駄にしても許されるだろう
64bit CPU時代の設計
32bit CPUの時代index/versionに16bitしか使えない時代だとこの設計は無理
かなりちゃんとしたテストが作れる
安原 祐二（Unity）
ECSはまだプレビュー。使いやすくなってから使えばいい
仕事で使うのは待つのが賢明
使う段階になったらこれを聞いてほしい
面白い
前半 おもろい メモリの戦い
これがわかればDOTSはかなり攻略できる
ユーザのPCでUnity登場時2005年よりRAMは増えている
1GBぐらいは当たり前になってる
富豪的に解決する
メモリはアドレスを保持するので複雑
2つに参照されたアドレスがあり、1つがいらなくなったので解放する。でももう一つが使ってる。はい死んだ！
C#はリソースをGCが解放する
Managed Memory
解放を呼ばせない
開発者はGCを嫌うが、ないと事故が起きる
他のやり方あるんじゃねぇの？
DOTSはUnmanaged memoryを開発している
NativeContainer
Unmanagedメモリを保持する仕組み
プログラマーがdisposeを呼ぶ
GCの仕事をプログラマがやらないといけなくなる
事故が起きるのでは？
いいえ。NativeContainerの生存期間はアルゴリズムできまる
ゲームの弾がいつ消滅するかはわからないが、アルゴリズムならタイミングが分かる
ん？ゲームだとそれはわからないこともあるのでは？
プレイヤーが操作できたらわかんない
「呼び忘れがあったらきづける」「実行前にわかる」「実効したらエラーをだしてくれる」
なぜ？
ネイティブコンテナの実装はstructのポインタを渡す
モチベーション
チャンク
ある物体がn個のコンポーネントで計算されているとする
この物体専用の領域K（DOTSでは16KiB）にm個入れてみる（n=3, m=4）
実際のメモリイメージは並び替えてこう
あまりの部分は許容する
違う物体も考えてみる(n=4, m=2)
物体のことをアーキタイプという
専用の領域はアーキタイプごとに確保される
削除するときは上書きする
削除で順序は動くのでメモリマネージャを通してアクセスする必要がある
マネージャはどこに持っているか管理している
このようなデータをどう処理するか？
Systemを記述する
3つ
処理対象チャンク
例：BとDをもつチャンク
入出力は？
例：Bを入力、Dを出力
処理
例：B→処理→D
右上のプログラムでBDをつかっているので実際に使われるチャンクはBD, ABCDの２つ
チャンク自体の順序は一定なので、チャンクごとに並列実行できる
入出力決まってるので実際にはこうなる
このようなSystemをたくさん定義してつなげていく
左のif文はレアケースでバグる（100万人プレイしたら300人バグった！）
Systemもifは中でかけるが、入出力が確定しているのでSystemごとのテストが楽！
関数やクラスを小さく切り出すのと違うの？
ところで、「他のオブジェクトを追いかけたりする」には参照が必要では？
Entytyがその情報を持ってる。ただし参照ではない
5のオブジェクトにアクセスしたいならテーブルの5番目にアクセスして情報を取得する。これはO(1)でlookupできる
参照された状態で削除されたら違うオブジェクトになるじゃん！
実は読み込み時にはバージョンを指定している。削除のときにはEntityの中のバージョンを更新することで解決する
Entityは64bit
5を削除時にはバージョン2になる。5のバージョン1はもうないのでマネージャは要求に対してもうないと返す
後半 30:00- Unity Physics
Unity C#で物理シミュレーションを実装する
deterministic
入力が同じなら出力は同じという性質
マルチスレッドで並列で動かしても結果が同じ
シングルスレッドなら昔からできていたらしい
statelessでstateは入力のみなので実現できる
シミュレーションループ独立
高速
メモリに乗りづらくしても（チャンク分離）今より早い
ポリモーフィズムとかいらない
データ志向だとsystemの名前に意味がないような気がしてきた
input / outputの型だけ意識する
現時点（0.2.4）では気配りが全然足りないので使いづらい
ハマり4つ
実装は全部オープンなので見られる
コライダーだと転がる
慣性テンソル 34:20〜
MonovihaviorとかGameObjectとか使えない