Створення безперебійного дворівневого багатокористувацького рівня?

Нещодавно з'явилася дискусія про те, як створити багатокористувацьку гру з двома прокрутками, яка може мати дизайн циклічного рівня (подумайте про Starbound та про те, як їхні світи циклічно).

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

Щоб додати цю ідею та виправити проблему, я придумав наступне: створити спускову зону (червоний квадрат на зображенні), де гравці зможуть побачити "зону клонування" (зелений квадрат). У цьому зеленому квадраті об’єкти з протилежної сторони тригерної зони будуть скопійовані у відповідну зону клону (можна побачити фігури A & B). Коли гравець потрапляє на початковий край "зони клонування", вони передаються в інший бік карти.

У цьому прикладі Гравець 2 подумає, що бачить програвача 1, однак насправді бачить його клона і навпаки.

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

Ця система з усіма цими тригерами звучить занадто складно і схильна до помилок.

Ви можете обернути позицію гравця за допомогою модуля з чимось подібним playerPositionX = playerPositionX % mapWidth

Таким чином , коли ваш гравець досягає скидається назад в 0.playerPosition == mapWidthplayerPosition

Це рішення може бути поширене на всю систему візуалізації.

Канонічним рішенням є використання порталів . У вашому прикладі є лише один рівень, за винятком порталу, що з'єднує лівий і правий кінці.

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

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

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

Хороша річ у порталах, що це дуже потужно. Двигун збирання використовував його для імітації багатоповерхових рівнів, незважаючи на те, що він не був "справжнім" 3d двигуном. Деякі сучасні двигуни також використовують портали для створення неевклідових просторів; Портал та Антикамбер - помітні приклади в 3D.

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

Кожен гравець обмінюється даними, але має свою власну перспективу. Їхні вікна заселяються по-різному в залежності від того, де вони стоять у світі.

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

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

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

По-друге, для візуалізації ви будете робити модуль на позиції. Отже, ліва частина екрана - "База", а права - "Основа + Розмір". Таким чином, ви переглядаєте свій світ на що-небудь в цьому діапазоні. Ви фактично шукаєте діапазон модулів, який відображає його назад 0...Width.

Підступ під час пошуку полягає в поверненні об'єкта в положення Baseліворуч. Це перетворюється на локальні координати екрану, тому сам рендерінг не повинен турбуватися про модуль, лише пошук.

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

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

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

Тож якщо ваш фактичний світ шириною лише 10 одиниць, гравець і гра не знають цього. Для гравця світ нескінченний - і якщо гра запитає, що знаходиться в позиції 15 - основна функція переведе цей запит, modulo10 і дасть пакувати предмет у позиції 5.

Тож для всієї логіки гри та всього іншого це так, як у вас нескінченний великий світ, де просто трапляються копії всього.

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

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