Одна і та ж логіка гри у двох окремих графічних бібліотеках

Яка філософія коду / структура абстракції / дизайн програми дозволить використовувати гру як з 2D, так і з 3D графікою (окремо) БЕЗ необхідності перекодувати логіку гри?

Ми говоримо про те, щоб взяти один і той же код, змінити мінімум речей (наприклад, обміняти назви файлів для двовимірних активів з іменами на тривимірні активи) і, можливо, підключити декілька спеціалізацій базового класу на генеричні / шаблони.

Поставити це в реальному контексті, де це має сенс: уявіть собі багатокористувацьку гру з локальною мережею, де є один чудовий 3D-клієнт з високим рівнем продуктивності для гравців, які мають справді хороші геймерські установки, і більш скромний 2D-клієнт для старого запилені ящики, які хтось знайшов на своєму горищі. Але це все та сама гра - реєструються ті ж події (хтось підхопив монету), використовується той же мережевий протокол, світи пропорційні тощо.

Щоб помістити його в контекст MVC: Контролери точно такі ж (натискання клавіші "Вгору" встановить прискорення гравців на 3,5 одиниці в секунду), Погляди абсолютно різні (2D проти 3D), а Модель така ж за винятком всього, що безпосередньо пов'язане з графікою (перевірка зіткнення навколишнього середовища виконується кожні 5 секунд, і він використовує той самий алгоритм. Зауважте, що це означатиме, що існує 2-координата Z для всіх ігрових об’єктів у 2D-версії, але це просто ігнорується або відображається користувачеві іншим способом, наприклад, тінню, яка відображається далі зліва, коли гравець знаходиться в повітрі).

Що робить цю захоплюючу тему тим, що це змусить розробника мати дуже чітке уявлення про структурування його даних та про те, як відбувається управління. Зауважте, що це не означає використання нічого іншого, крім графічної бібліотеки, наприклад SDL, D3DX або OpenGL. Немає ігрових двигунів!

Оскільки це здебільшого теоретичне запитання, я залишу його мови програмування, але якщо ви хочете навести приклад, ви можете використовувати будь-яку мову, яка вам подобається, C ++, якщо ви хочете пройти цілу свиню, або навіть Brainfuck, якщо відчуваєте аж до виклику (Будь-які конкретні відповіді будуть вдячні, як і будь-які абстрактні!).

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

Подумайте про локалізацію рядків: замість жорсткого кодування рядка "Інвентар" у вашій грі ви замість цього зателефонуєте у свою бібліотеку локалізації (можливо, побудовану на замовлення), яка б виконувала деякі процеси та повертала належний рядок, залежно від контексту гра.

Таким же чином, всі дзвінки до вашого графічного двигуна здійснювались б через вашу обгортку.

Роблячи це, ви обмежуєте / обмежуєте, які команди ви можете дати своєму графічному двигуну. Ось кілька важливих:

1. Малюнок (графічний об’єкт) у (розташування)
2. Змінення (альфа, обертання тощо) властивості (графічний об'єкт)
3. Переміщення (графічний об’єкт) до (розташування)
4. Скласти карту (ім'я рівня / структура даних)

І деякі інші, які ви знайдете, працюючи над своїм проектом.

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

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

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

Сподіваюся, що це допоможе розпочати роботу =]

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

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

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

Найкраще було б встановити конкретну кількість кутів огляду для 2D-клієнта (8 чи 16 або подібний) та розробити весь вміст, щоб він відповідав цим обмеженням. На жаль, якщо у вас є рівні та об'єкти, призначені для перегляду лише з певного кута, це може виглядати досить дивно всередині клієнта 3D.

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

Я думаю, ти майже відповів на власне запитання:

Щоб помістити його в контекст MVC: Контролери точно такі ж (натискання клавіші "Вгору" встановить прискорення гравців на 3,5 одиниці в секунду), Погляди абсолютно різні (2D проти 3D), а Модель така ж за винятком всього, що безпосередньо стосується графіки.

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

Це в основному сенс моделі MVC, тим більше, що вона стосується настільних та веб-додатків: може бути декілька клієнтів, які отримують доступ до одних і тих же даних (наприклад, веб-інтерфейс, мобільний клієнт та настільний клієнт для електронної пошти).

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

Для цього можна використовувати більш-менш складні методи програмування. Єдине, що вам потрібно - це спосіб отримати "зайві" дані, які потрібно відобразити для кожного ігрового об'єкта. Найпростіший спосіб - нульові додаткові дані потрібні! Якщо ігровим об’єктом є "Майстер", намалюйте Майстра.

Якщо вам потрібні складніші методи, розгляньте поліморфізм, шаблон пам’яті, хеш-таблиці, пустоті * покажчики тощо. Не перешкоджайте інженеру (більшість цих методів надмірно розроблені).