Створення стін в іграх на основі плитки: що мені не вистачає?


25

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

Важливо: персонаж МОЖЕ стояти на плитці, яка має стіни, незалежно від їх форми.

Загальна річ для всіх трьох варіантів: мапа плитки буде "зберігатися" в одновимірному контейнері на основі std :: вектор (або подібний). Причини цього (приголомшливо) пояснюються у відповідях на інше питання.

Контейнерні класи в іграх на основі плитки.

Назад до стін.

А) Простий підхід.

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

Перший підхід

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

Б) Розумний (?) Підхід.

Замість того, щоб дозволити гравцям подрібнити всю карту, я збираюся перемогти їх. Кожна стіна має дві половинки, які прикріплені до краю плитки зсередини. Отже, щоб зробити єдиний "стінний блок", мені доведеться створити два об'єкти Half-Wall з двох сусідніх плиток.

Другий підхід

Плюси: це симетрично !!! Крім того, не потрібно змінювати поточних характеристик двигуна. Мінуси: більше клопоту, більше предметів і, звичайно, «шапки». Як ви бачите на малюнку, куточок в основному буде плакати за «шапкою» об’єкта. Я насправді крутий з цим, це не так складно додати. Гей, у мене вже є план тонких стовпців, зроблених із чотирьох з'єднаних кришок. Солодке. Але все ж я хвилююся щодо можливих проблем із полем зору та лінією зору.

В) Загальний варіант капітального ремонту.

Або я можу просто створити межі та куточки як окремі контейнери для ігрових об’єктів. Ось так.

Третій підхід

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

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


2
A.2: Як А, тільки те, що лише дві сторони - наприклад, Північна та Західна - можуть мати стіну. Ось такий підхід використовує X-Com.
Мартін Сойка

@Martin Sojka Це залишає дірку в південно-східних кутах. І все-таки може бути корисним розглянути модель C таким чином, кожна плитка може мати комбінацію трьох різних стінових елементів, північний, західний та північно-західний кут.
aaaaaaaaaaaa

Так видно стіни, я це беру? Не просто блокуючи краї плитки. Для чого потрібні дві половинки у варіанті В? Чому б не одна стіна, наполовину зміщена на іншій плитці?
Річард Марскелл - Дракір

@eBusiness, якщо ви просто дозволяєте стіни на півночі та заході, ви можете імітувати стіни на півдні та сході, просто поклавши стіни на півночі та заході плитки під них.
Тетрад

Я б запропонував піти з C. Це те, що я роблю в цьому jemgine.omnisu.com/wp-content/uploads/2011/06/gnomecolony.png, і це працює досить добре. Єдина проблема - саме південний / східний край карти. Вам доведеться щось з цим зробити.
Блекі

Відповіді:


14

Я використовую ваш метод "B".

Щоб не потрібні «ковпачки», просто продовжте кожну стіну «1/2 товщини стінки» в обох напрямках. Це створить стіни, що перекриваються там, де вони зустрічаються, але ваші діаграми вже підказують, що це не проблема.

Так, у способі "B", фото №3, горизонтальна стінка трохи пошириться ліворуч, а вертикальна стінка трохи подовжиться вгору.

[Я тут новий, щойно зареєстрований. Я щось пропускаю, оскільки не можу побачити кнопку "Додати коментар" до вашого початкового повідомлення. Це привілей людей з вищою репутацією? Або я не помічаю очевидного? Вибачте, що додали це як "відповідь".]


1
Це відповідь, і я вважаю, що це 100 (?) Рівень репутації для коментування. Ласкаво просимо до SE Gamedev! :)
Качка комуністична

2

Ви зазначали, що персонаж може стояти на плитці, що містить стіну, але ви розглядали, як кожну плитку вважати самою стіною? Навіть половина плитки як стіна в горизонтальному чи вертикальному стилі?

Плюси: обчислення та розташування тривіальні, зіткнення тривіальне, коли всі обчислення та зіткнення просто базуються на координатах розміщення стін.

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

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

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


1

Вибачте, але третій спосіб - це дійсно спосіб думати, ну, ви вже маєте можливість це зробити, так що давайте зможемо рухатись далі й думати про інших двох!

Річ у тім, що стіна - нульова ширина, двовимірна (висота * довжина, у тривимірному світі) квадратна перегородка з двома ящиками. Ви повинні розглядати їх як такі, але ви можете використовувати більш просте рішення, коли будувати підземелля (особливо, якщо інші люди можуть будувати частини).

Здається, це 2-грі зверху вниз, де стіни мають "ширину", тому їм потрібен цей куточок (ваш об'єкт "шапка"). Це винятково "графіка", хоча я б ішов з якоюсь такою:

2D карта з плитками (тобто тип плитки та інше).

2D карта з 2 стінами, напр. знизу і праворуч (ліва стінка буде «правою стінкою» у плитці зліва від цієї).

+ Логіка, яка малює всі стіни та "шапки" тощо.

Таким чином розділяючи логіку та графіку. Ви можете зробити "інтерфейс", доглядаючи за такими речами, як SetWall (ThisTile, LEFT, NOWALL) -> встановивши праву стінку плитки зліва від ThisTile на "NOWALL" ...

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

++

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.