Карта плитки / виконання місцевості з різною висотою сусідніх плиток


10

Ахой!

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

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

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

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

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

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

Якщо хтось може пролити про це на мене, будь ласка, допомога буде дуже вдячна :)

Оновлення

Я включив зображення для подальшого роз'яснення того, що я хочу досягти:

2.5D карта плитки

Зображення запозичене з Як створити нахилену (висоту) ізометричну плитку

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

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

У мене була ідея, що кожна плитка місцевості може моделюватися з 8 вершин, де 4 основні вершини покривають фактично саму плитку, а решта 4 вершини використовуються для моделювання бортів / стін кожної плитки. Дві проблеми, які я бачу з цією реалізацією, полягають у тому, що а) карта світу по суті збільшується вдвічі і б) враховуючи, що не всі плитки включатимуть "стіни", деякі плитки закінчуються надлишковими вершинами, які не використовуються.

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

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

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

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

Дякуємо за прочитане!

Відповіді:


2

Якби я був ти, я би заглянув у вокселі, точніше - рендеринг кубів типу Minecraft . На відміну від висотних карт, вони можуть обробляти навіси, печери, будинки з декількома поверхами тощо.

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

Цей підручник - це чудове пояснення того, як це зробити в C ++ за допомогою Ogre3D. Я припускаю, що вам доведеться пройти трохи нижчий рівень у OpenGL.

Створивши кубики, ви хочете розгладити краї, щоб створити вид рідкої місцевості, показаний на вашому зображенні. Я вважаю, що PolyVox (також у C ++) робить це; Ви можете поглянути на їх код. Я думаю, ви в основному робите в 3D те, що показує зображення у 2D: середнє розташування навколишніх кубів, щоб знати, де розмістити кожну вершину.

Редагувати:

  • Створіть грані для кубиків, що прилягають до води, так, ніби водяна плитка порожня, і виведіть обличчя води прозорим.
  • Обличчя на «краю» можна генерувати так само, як звичайні обличчя, якщо ви вважаєте, що вокселі поза межами світу порожні.
  • Фізика: Ви, ймовірно, можете подати відведену сітку своєму двигуну фізики як статичний об'єкт.
  • Редактор карт: Ви хочете редагувати основні дані вокселів, а не саму сітку! (Сітка повинна відображати дані, тому редагування вокселів має спричинити зміни у вашій сітці.) Якщо ви не знайомі з нею, ви можете знайти модель, перегляд, контролер (MVC).

Якщо у вас є додаткові запитання, сміливо залишайте коментар. Ласкаво просимо на gamedev.SE!


Це дуже складне рішення, що для відносно простої проблеми. Безліч ігор зробили те, що задає ОП, без складності вокселів.
Шон Міддліч

Я згоден, вокселі можуть бути складними. Будь ласка, посилайтесь на ці ігри? Мені цікаво почути, як вони це зробили.
Ваккідев

Я бавився з ідеєю використання вокселів. Чи передбачає це реалізація, що всі куби мають одиничні розміри, або міг би бути видавлений один куб? Я здогадуюсь, що світ потребує збереження у шарах, щоб вода та інші плитки могли «перекриватися» уздовж площини y.
Капітан Редмуфф

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

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

6

Це: http://30.media.tumblr.com/tumblr_m06qv6OREt1r2qjpao1_500.png - приклад карти, яку я робив деякий час тому.

У мене був XML, що представляє карту та різні типи плиток. Кожен тип мав би кілька атрибутів:

  • Висота
  • Позиція
  • Тип злиття: який би тип об’єднання робив би цю плитку ALL(якщо вона повинна зливатися з будь-якою плиткою навколо неї), EQUAL(зливатися лише з плитками одного типу), NONE(ніколи не зливатися).
  • Висота злиття: Максимальна висота для схилів (добре для навісів), скажімо, ви хочете, щоб плитка зливалася лише з плитками на однаковій висоті або різницею 1, значення було б одне.

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

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

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

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

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


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