Як я можу створити ефективну схему взаємодії об’єктів ігор із архітектурою на основі компонентів?

Це питання дизайну ... Я впевнений, що це можна було б узагальнити більше, але мені важко з цим. Мене цікавить дизайн для взаємодії ігрових об'єктів - ось мій приклад (2D-головоломка-платформер).

Скажіть, гравець намагається просунутися через рівень. Є багато вогнів, які можна вказувати в різні боки. Ось приклад того, як ці легкі об’єкти можуть взаємодіяти ...

• Одне світло проектує платформу, яка дозволяє гравцеві перейти пробіл
• Одне світло зменшує коефіцієнти тертя всього, чого він торкається, інший збільшує його
• Одне світло знімає ефекти всіх вогнів, через що платформа зникатиме, коли світло вмикається, і змінюють модифікатори тертя
• І т.д. ...

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

Також підключення аудіо до цих взаємодій? Схоже, підключення аудіо до системи було б подібно до підключення будь-якої іншої властивості, наприклад, видимості або руху / зіткнення програвача.

Очевидно, як додано більше компонентів, було б непогано, якби була надійна система, яка могла б обробляти нові з невеликими модифікаціями, але я не знайомий з тим, як робити це для розробки.

Інша інформація: Двигун, який я використовую, - це двигун XNA, який називається IceCream .

В об'єктно-орієнтованій системі єдиний реальний відповідь на питання про те, який найкращий спосіб зробити X - це те, що ви повинні просто зробити це найпростішим вперед способом, про який ви можете придумати, щоб щось запустити і працювати, а потім змінити це, коли легше вираження стає очевидним. Захоплення себе вибором правильного шаблону перед тим, як писати будь-який код, - це хороший спосіб позбавити себе неправильної відповіді від руху; нехай всі думки про візерунки та компоненти розплавляються і просто виконайте ці кроки, починаючи з того, де ви є сьогодні (якщо припустити, що ви реалізували легкий компонент):

1. Додайте код до легкого компонента до платформ проекту. (Розробіть це.)
2. Скопіюйте цей компонент у новий компонент, видаліть дані платформи та додайте код, щоб зменшити тертя відповідних об’єктів. (Розробіть це, переконайтеся, що №1 все ще працює.)
3. Скопіюйте цей компонент у новий компонент, видаливши "новий" код та додайте матеріал, щоб відключити ефекти інших компонентів. (Розробіть це, тоді переконайтеся, що №1 та №2 все ще працюють.)

У цей момент у вас (ймовірно) з'явиться тонна дублювання коду. Витягніть загальний код у функції або інший клас (можливо базовий клас) або все, що здається доречним. Тільки тому, що ви почали з "легкої складової", хоча це не означає, що LightComponent є відповідною базою; можливо, що будь-який код, що складається з легкого компонента, насправді не є "компонентом" сам по собі, і, можливо, це буде найкраще представлено набором функцій або навіть окремим класом, який агрегується у ваші нові компоненти (як змінна-член ).

Загалом кажучи, коли об’єкт типу A взаємодіє з об'єктом типу B, ви хочете мати деякий ефект C. Це називається "подвійне відправлення", і це дуже важко зробити елегантно на мовах, схожих на С.

Ефективний, але важкий у обслуговуванні спосіб - це лише купа комутаторів, а також заяви, залежно від типів ваших об'єктів. Ви будете почувати себе брудно писати це, але це зробить роботу.

Шаблон для відвідувачів є більш надійним рішенням , яке приховує неприємне перемикання типу, але може бути clumbersome встановити.

Зазвичай будь-який тип комутатора типу у вашому коді є запахом, але тут ви намагаєтесь узагальнити поліморфізм, який зазвичай перемикає функції на основі одного типу, щоб перемикати функції на основі двох типів. Поліморфізм є основою ООП, тому це не запах.

Дозвольте мені побачити. Це просто те, що я готував собі в голові, поки писав, тож шкода, якщо я щось пропускаю.

Отримайте всі світлові вузли на розумній відстані навколо вашого чувака.

На кожне світло ви подаєте багатокутник, що представляє його область ефекту для об'єкта framebuffer. Таким чином, конус світла створив би конус одного типу пікселів у вашому FBO. Візуалізуйте кожен тип вузла в проходах з відповідним пріоритетом. Ви можете кодувати інформацію в кожен піксель, так як зелений канал може бути тертям, червоний - гравітацією, синій та альфа - чимось іншим.

Розумні методи поєднання кольорів можуть створити цікаві ефекти. Кожен рівень може мати свої власні правила змішування. Ви також можете додати фрагменти затінення для психоделічних динамічних ефектів, таких як пульсуюча гравітація тощо.

Нарешті, просто перевірте, до яких пікселів торкається вашої мандуди, і робіть перерахунок растрової карти, коли ви наближаєтесь до країв попередньо обчисленої області.

Грубий етюд, зроблений за 2 хвилини, ніби ілюструє мою ідею:

Редагувати: На практиці це означає, що вам потрібно лише світлий компонент, що випромінює певний колір. Правила, пов'язані з тим, який колір робить те, що може бути десь іншим цілком. Ви можете кодувати багато даних у 32 біти, у яких є піксель pr. Крім того, у вас може бути кілька FBO, що містять різні атрибути, які не впливають один на одного. У вас може бути один ФБО сили тяжіння / тертя та один FBO зіткнення 1bit. Якщо ви виберете це, вам, звичайно, доведеться позначити, до якого ФБО має відображатися ваше світло.

Шаблон спостерігача - одне з найкращих рішень. Повідомлення буде надіслане лише тим об’єктам (компонентам), які його справді цікавлять. Тому отримувач повинен підписатися на це повідомлення / тип події.

Існує багато реалізацій сигналів / слотів. Наприклад, у C ++ є бібліотека сигстотів

Для отримання додаткової інформації читайте про Qt-сигнали та слоти .