Чи відповідає SpriteKit схемою MVC?

Зараз я працюю над проектом iOS під назвою Old Frank, який намагаюся слідувати схемі дизайну MVC.

Суть у цьому полягає.

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

Тепер, якщо я правильно розумію MVC, ви не можете використовувати багато функцій, які SpriteKit може запропонувати, якщо ви хочете слідувати за MVC. Наприклад, будь-яке SKAction, виявлення зіткнення тощо.

Чи не в залежності від моделі, де розташовані ігрові об’єкти, і як вони повинні реагувати при дотику до інших об’єктів? Чи не залежно від моделі визначати місцеположення з часом?

Чи є якісь частини SpriteKit, які вважатимуться нормальним для використання як "перегляд" у MVC, крім рендерінга?

— Скайлер Лорен
джерело

"Я намагався слідувати схемі дизайну MVC" - чому?

— Пол Д. Уейт

@ PaulD.Waite Мені подобається ідея тримати свою модель окремо. Це теоретично полегшує перенесення або відтворення на іншій платформі. Це також полегшує управління наполегливістю, що було найбільшою причиною до цих пір.

— Скайлер Лорен

Готча. Щоб досягти мети стійкості, модель пам’яті може бути більш застосовною, ніж MVC. Ваші спрайти можуть бути автором, і вони будуть нести відповідальність за створення репрезентативного стану своєї держави та відновлення себе з цього представництва пізніше. Ваш контролер сцени може бути тим, що вимагає від них представлення.

— Пол Д. Уейт

Це також може призвести до того, що ваші ігри збереження можуть бути використані на іншій платформі, хоча я підозрюю, що це стосується можливостей роботи з портами під час роботи з ОС Mac / iOS, як SpriteKit.

— Пол Д. Уейт

@ PaulD.Дорого дякую за ваші коментарі, я розгляну шаблон пам’яті як інший зразок, який слід розглядати у майбутньому. Два питання приблизно одного проекту так, але не пов'язані між собою. Здивований, побачивши, що інший переїхав на stackoverflow і трохи більше пізніше сьогодні перегляне його відповідь =)

— Skyler Lauren

Відповіді:

Ваше питання хороший. У мене було саме таке питання щодо SpriteKit, і мене дуже збентежило відсутність інформації в Інтернеті про це. SpriteKit, здається, заохочує вас помістити весь код Model-View-Controller в той самий клас (ваш підклас SKScene), що мене дуже бентежить. Як ви коли-небудь будували гру будь-якої складності, використовуючи цю техніку? Поєднуючи ігровий стан (рахунок, numLives тощо), з кодом контролера, як touchesBegan / Ended, і перегляд візуалізації всіх у тому ж класі стає дуже важким для управління поза простими іграми.

Я погоджуюсь, що використання шаблону пам’яті для наполегливості - це гарна ідея, але я також думаю, що перехід до дизайну MVC може бути корисним. Зараз я переношу свою гру в архітектуру MVC. Мій сучасний підхід полягає в тому, щоб моя модель (ігрові об’єкти) управляла PhysicsBodies, підклас SKScene виступав в якості контролера, а окремий клас виступав як перегляд для налаштування та надання візуальних аспектів SKNodes в сцені. Я лише частково проходжу процес, тому не можу точно сказати, чи буде це гарний дизайн, але, здається, він буде набагато кращим, ніж мати підклас 10 000 рядків SKScene.

— Джон Клівленд
джерело

Дякую за вашу відповідь / коментар. Вам здається, що використання функцій SpriteKit також не відповідає дизайну MVC. Чи не соромтеся, напишіть мені skyler@skymistdevelopment.com якщо у вас є питання про те , як «я» з допомогою MVC або хочете піти більш докладно , як «ви» використовуєте MVC з SpriteKit =)

— Скайлер Lauren

Ніщо не змушує вас вводити більшість коду в клас SKScene. Насправді, я вважаю, що при використанні SpriteKit, більша частина логіки потрапляє до Вузлів набагато природніше, ніж до сцени, оскільки Вузли є головною справою SpriteKit. Сцена трохи більше, ніж "Контролер" для обробки оновлення та введення для вашого Вузольного дерева. Хоча модель "MVC" все ще не відповідає SpriteKit, оскільки Вузли мають тенденцію "M" і "V".

— Attackfarm

Простіше кажучи, загальним дизайном в іграх SpriteKit є сцени, шари, вузли та дочірні вузли.

Ви можете перетворити кожну частину в дискретний клас, який інкапсулює всі частини, властивості та методи.

Наприклад, клас Background, який має шаруваті зображення, частинки, різні властивості, такі як швидкість кожного шару, що рухається, та публічні методи для запуску та припинення прокрутки фону.

У цьому дизайні ви збираєте ці дискретні класи, які роблять свою роботу в сцені, яка в основному обробляє запущене оновлення:, фізику, події дотику тощо.

— Джеремі
джерело