SpriteKitはMVCパターンに従っていますか？

私は現在、Old Frankと呼ばれるiOSプロジェクトに取り組んでおり、MVCのデザインパターンに従っています。

その要点です。

GameObjects(model) <- Scene(controller) -> Sprites "SpriteKit" (View)

MVCを正しく理解していると、MVCをフォローしたい場合にSpriteKitが提供する機能の多くを使用できなくなります。たとえば、any SKAction、衝突検出など。

ゲームオブジェクトが配置されているモデルと、他のオブジェクトに触れたときの反応はどうでしょうか？時間の経過とともに位置を決定するのはモデル次第ではありませんか？

レンダリング以外にMVCの「ビュー」として使用しても問題ないと思われるSpriteKitの部分はありますか？

あなたの質問は良いものです。私はSpriteKitについてまったく同じ質問をしましたが、これに関するWeb上の情報の欠如について非常に混乱しています。SpriteKitは、すべてのModel-View-Controllerコードを同じクラス（SKSceneサブクラス）に入れることを推奨しているようです。その手法を使用して、複雑なゲームをどのように構築しますか？ゲーム状態（スコア、numLivesなど）をtouchesBegan / Endedなどのコントローラーコードと組み合わせて、すべて同じクラスでビューのレンダリングを行うと、最も単純なゲームを超えると管理が非常に難しくなります。

mementoパターンを使用して永続化を支援することは良い考えであることに同意しますが、MVCデザインに移行することも有益だと思います。現在、ゲームをMVCアーキテクチャに移行しています。現在のアプローチでは、モデル（ゲームオブジェクト）でphysicsBodiesを管理し、SKSceneサブクラスをコントローラーとして機能させ、シーンとしてSKNodesの視覚的側面を構成およびレンダリングするビューとして機能する別のクラスを使用します。私はプロセスの途中にいるだけなので、これが良いデザインになるかどうかは確かではありませんが、SKSceneの10,000行のサブクラスよりもはるかに優れているようです。

簡単に言えば、SpriteKitゲームの一般的なデザインは、シーン、レイヤー、ノード、子ノードです。

各パーツを、すべてのパーツ、プロパティ、およびメソッドをカプセル化する個別のクラスにすることができます。

たとえば、レイヤー化された画像、パーティクル、各レイヤーの移動速度などのさまざまなプロパティ、およびバックグラウンドのスクロールを開始および停止するパブリックメソッドを含むBackgroundクラス。

この設計では、独自の作業を行うこれらの個別のクラスを、更新、物理、タッチイベントなどの実行を主に処理するシーンにアセンブルします。