Чи я, і як, відокремлюю питання про вхідні та ігрові об’єкти?

Напевно, у кожній грі розробнику доводиться якось мати справу з введенням даних, це можуть бути прості події клавіатури та миші, події на дотик або щось таке, як акселерометр. Це введення безпосередньо опосередковано впливає на предмети в грі. Іноді один і той же вхід може впливати на різні об'єкти. Зараз я думав над тим, як це моделювати. Я бачу це два різні підходи.

• Нехай ігровий об’єкт сам обробляє це, підписуйтесь на події та називайте його власними методами. Це має перевагу в тому, щоб дозволити самим ігровим об’єктам вирішити, які входи викликають яку дію. Недоліком, здається, є те, що вхідний код змішується з "основним" ігровим об'єктним кодом. Крім того, ігрові об'єкти не знають про стан решти гри, а іноді, можливо, не можуть діяти під час вхідних подій. Це не здається правильним.

• Запропонуйте загальному контролеру вхідного сигналу піклуватися про всі вхідні дані та приймати рішення щодо того, хто може обробляти яку подію. Це, мабуть, краще розділяє проблеми, але чітко з'єднує клас вводу-контролера з ігровими об'єктами. Це якось потрібно знати, хто хоче отримати яку подію та в якій державі. Це теж не здається правильним.

Які стратегії ви використовуєте для вирішення цього питання?

Я рекомендую відокремлювати вхідні події від ігрових об’єктів, щоб ви могли швидко змінити / оновити методології введення, не потребуючи редагування та налагодження 10 класів об'єктів. Приклади перемикання з керування лише клавіатурою на клавішу миші + клавіатури або просто переназначення клавіш.

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

Використовуйте контролер входу для відстеження стану входу:

Up press event   -> dir = up
Down press event -> dir = down

Щоразу, коли змінюється стан введення, оцініть, чи готові ігрові об'єкти бути зміненими:

set dir  ->  if gamestate != paused && battlemode == false
             ->  character.changeDir(dir);

Реалізуйте загальні методи на своїх ігрових об'єктах, які можна викликати контролером введення або іншими ігровими об'єктами, якщо це потрібно:

changeDir (dir)
setSpeed (walk/run)

Я рекомендую підхід MVC. У MVC ігрові об’єкти мають лише турбуватися про моделювання ігрової системи та надавати інтерфейс високого рівня, наприклад, move_left. Тоді є об’єкт контролера, який турбується про відображення вводу для викликів моделі. Він не тільки дозволяє легко змінювати елементи керування, він дає хороший інтерфейс для AI, вони просто ще один контролер.

У вашому другому варіанті я розділив вхідний контролер на дві частини, таку, яка обробляє фактичний сенсор пристрою, клавіатуру, акселератор, що б ви не могли кинути на нього, щоб він відобразив їх у загальний набір входів. Потім мати другу частину, яка відображає загальні входи на конкретні входи для гри. Скажіть клавіатури вгору картами стрілок на введення1, потім торкаючись до верхньої частини сенсорного екрана, також карта вводиться1, а тепер ви пишете другий фрагмент, який відображає вхід 1, щоб перейти. Тепер ви можете зіставити будь-який пристрій вводу-виводу, а також збережені відтворення або AI-входи в цю загальну систему введення і мати невелику ігрову частину, яка завантажує те, що input1 означає для моделі.

Я б запропонував, щоб ваша гра ( Модель ) визначила список можливих подій введення (реалізованих у вигляді перерахунків або об'єктів із базовим інтерфейсом). Речі , такі як MovingRightStarted, MovingRightStopped, FiredWeapon1, Escapeі т.д. ...

У грі визначається структура даних (наприклад, a queue), яку ваш вхідний код ( контролер ) може заповнювати подіями введення.

Тоді ваша гра може запитати структуру даних, щоб отримати вхідні події.

Таким чином, ви можете підключити різні типи контролерів для живлення моделі:

• Тільки клавіатура
• Клавіатура + миша
• Джойстик
• Сенсорний екран
• Штучний інтелект

Ви просто маєте їх підштовхувати події введення до моделі.