2026:11:14
文書の過去の版を表示しています。
11/14日記
ゲーム開発
- フレームワーク作り直すの構わないんだけど、やるとするとCryPic.リリース後だなあと思った。
- 作り直し案はいくつかあって、以下を検討中。
- Unityでできてるフレームワーク作り直し（修正箇所はほぼ決め打ち可能
- MonoGameで作り直し（ゲーム部分はUnityから移植ができそうだが、リソース読み込み等は新規作成
- Godotで作り直し（実装からやり直し
- DXライブラリで作り直し（実装からやり直し
- １．についてはすぐ動く。むしろ適当に改修してもいい。現状はリソースの持ち方とプログラムの関連性に問題があるだけなので、プログラムの改修ではなく最低限リソース再配置だけで動くのはメリット。
- ２．については一番有用な選択肢。もともとUnityに依存しない（引き剥がしやすい）形で実装してあるので、ゲーム部分は楽に移植できそう。ただリソース周りは実装しなおしのため、そこにどんだけ時間をかけられるかがポイントだと思う。
- ３．は１．と再度同じことする。できはするんだけど、結構Unityの上で動かすのを面倒なことしていたのもあって、あまりやる気にならない。ある程度リソースの持ち方も検証したんだけど、シーンごとに管理するのが面倒そうでどうしたもんか。
- 少なくとも、あまり期待できない移植のためにゲームエンジンの上で独自フレームワーク動かすというのは、リソースの扱いが便利な面もあるけど実装そのものが面倒かつトリッキーになるのがわかったので、もう一回はやる気がしない。それであれば２．か４．を選ぶ。
- ４．は最後の選択肢って感じ。実装自体はできるけど、全部実装しなおしになるので。しかもC言語で。
- C言語自体はメガデモ作るときも書くし音楽ツール作るときも書くので言語の習熟度合いに問題はないんだけど。
- いずれも動くものを移植するのに手間かからなさそうだが、リソースの仕組みが違うので要新規作成
プログラム
- WSLでコンパイルして動いた記憶がある。
- Addressablesを使わなかった理由のひとつが「同期読み込みができない」ことだったんだけど、これなら使ってみても良さそう。
- 特にCryPic.フレームワークはあえて非同期で処理しないことにしているので、非同期処理がコア部分に関わると厄介なのですよ。
- 今までバタバタして調べきれてなかったため、今更調べてたどり着いたという状態。
音楽
- これ使ってみようかしら。
2026/11/14.1794643289.txt.gz · 最終更新: 2026/11/14 17:01 by machiaworx