Akeit0 さんprozolicさん、参加してくれてまじてまありがとうございました。来てくれた方も。
ちょっと自分の配信の能力が低すぎて申し訳ないかんじでしたが、色々話せたしコメントとかももらえて楽しかったえす
ハダシA@hadashiA
(予定) 今日 20:00頃から、 @Akeit0_ さんと popopoで雑談します。 最近は js/lua ランタイム実装とかをやられている、エクストリームC#/Unity 探求者としてかなりの域に達してる方です。いろいろ教えてもらうで
日本語
ハダシA
3.5K posts
@hadashiA ACTはアクションゲームのことを指している認識であってますか？
その場合どのようなアクションゲームを想定されてるかコンテキスト合わせたいですが、
絵がないと成立しないゲームに関しては、だからMV*で作るのは難しいよね、に帰着するように思います
日本語
元の文章の意図としては、「状態を持つものがすべて「モデル」」だという主張はしていません。
DOMの話に関しては、Web開発は座標や回転などの情報をモデルとして持つことはほぼないかと思います。
これに対して例えば「フィールド上のある座標領域に10秒留まったら1点」のようなゲームがあったとすると、もしモデルとビューを分ける設計にする場合には、座標はモデルとして扱うことになると思いますが、この座標情報は当然ビューにも必要であるため、その境界が曖昧になるということです。
その上でどうするべきかを記事の後半に書いている流れです。
ハダシA@hadashiA
そんなことを言ったら DOM とか UIのクリックイベントとかもすべて「モデル」ということになってしまうとおもうんやけどな MV* の文脈での モデルって、プレゼンテーションとドメインロジックの分離するってことなので、状態を持つものがすべて「モデル」ではないし、物理はアプリのドメインじゃなくね
日本語
@harumak_11 その場合、ACTは画面に絵がでなかったら ゲームとして成立しないと思うんですが、絵もドメインロジックというかM として扱わないといけない、となってきてしまうんでしょうか。どうもこの辺りに考え方の違いがあるみたいです
(簡素でもVに絵が必須、なら物理も同じではと)
長々とすいません。。
日本語
@harumak_11 うーん、コントローラによるイベントを音声入力におきかえるのと、 衝突したとかのイベントを 別のものにおきかえるのとで、なにがそんなに違うのかがよくわからなかったです。その例はゲームとして成立しないよね、というのはわかりますがが。。物理はドメインロジックじゃない、に戻ってしまうかも…
日本語
差し替えても正しく動くとは、例えばGUIをデバッグ用の文字列出力に置き換えて、コントローラによるイベントを音声入力によるイベントに切り替えてもゲームが遊べる=ビジネスロジックが保たれるということです。
物理エンジンを差し替える話ではなく、つまり「衝突したというイベントを発生させる物理ボタン」に差し替えてゲームが成立するかという話になるかと思います。
日本語
@harumak_11 言葉の定義の問題になっちゃうかも( あくまで自分の意見てことになっちゃう)かもしれませんが、 すべての起点がモデルになってる=MV* ではないと思います。UI でも キーストローク/スクロール/ジェスチャー とかはVからしか発火しえず、 それをどうするかという問題設定も含まれると思いました
日本語
その設計には同意しますが、それはもうMV*の思想ではないから、MV*の思想をゲームに適用するのは難しいという旨の記事になっています。
以下は以前書いた記事ですが、インゲームにおいてViewという概念ではなくActorという概念にしているのはその為です。この設計においてはそのようなイベントをActor起因のイベントとして整理しています
blog.sge-coretech.com/entry/2025/12/…インゲームは柔軟な初期設計に
日本語
@harumak_11 長年いろいろ困った末に 双方向バインディングが廃れて 単方向制御フローのあれこれが発見されている (逆方向がないのならもっと単純) なんじゃないかなあとは
日本語
@harumak_11 うーん、差し替えても正しく動く、というのはどういう意味なんだろう。物理を差し替えても、「衝突したら1点」みたいな仕様がアプリ固有のものであってその部分が分離できてるのであればいいのでは。やはりビューだけが知っているイベントというのは普通にあって、MV*でも逆方向をどうするかというのが
日本語
@harumak_11 毎フレームの座標がドメインロジックとしてモデル側に必要だったとしても 、 物理エンジンがビュー(というかエンジン側)にあってコンポネが自律的に座標を変える構造である場合、 コンポネ側からしかクリックイベントが発火し得ないのと同じように、座標変化もビュー起因のイベント、と考えてしまいま
日本語
@harumak_11 (あくまで自分の考えとして、、)
モデル側でも必要かどうか、というのは、ドメインロジックで扱うかどうか、で決まりますよね。すべてのイベントがモデル起点なわけではなく、一般に外界のイベントはビューからも発生するもので、物理エンジンもその範疇ではないでしょうか
日本語
そんなことを言ったら DOM とか UIのクリックイベントとかもすべて「モデル」ということになってしまうとおもうんやけどな
MV* の文脈での モデルって、プレゼンテーションとドメインロジックの分離するってことなので、状態を持つものがすべて「モデル」ではないし、物理はアプリのドメインじゃなくね
su10@ハイパーカジュアルゲーム開発@su10_dev
> Unity で言えば、例えば MonoBehaviour の Transform や Rigidbody は、モデルでもありビューでもあるということです。前セクションの例で言えば、衝突判定は（少なくともUnityエンジン搭載のものを使う場合は）ビューと密結合せざるをえないじゃないか、という話です。 これ自分も思ってたわ。
日本語