Як зберігати рівень shmup?


12

Я розробляю 2D shmup (тобто Aero Fighters ), і мені було цікаво, які існують різні способи зберігання рівня. Якщо припустити, що вороги визначені у власному XML-файлі, як би ви визначили, коли ворог породжує рівень?

Це базувалося б на часі? Оновлення? Відстань?

В даний час я роблю це, грунтуючись на "рівні часу" (кількість часу, на якому працює рівень - пауза не оновлює час). Ось приклад (серіалізація була зроблена XNA):

<?xml version="1.0" encoding="utf-8"?>
<XnaContent xmlns:level="pekalicious.xanor.XanorContentShared.content.level">
  <Asset Type="level:Level">
    <Enemies>
      <Enemy>
        <EnemyType>data/enemies/smallenemy</EnemyType>
        <SpawnTime>PT0S</SpawnTime>
        <NumberOfSpawns>60</NumberOfSpawns>
        <SpawnOffset>PT0.2S</SpawnOffset>
      </Enemy>
      <Enemy>
        <EnemyType>data/enemies/secondenemy</EnemyType>
        <SpawnTime>PT0S</SpawnTime>
        <NumberOfSpawns>10</NumberOfSpawns>
        <SpawnOffset>PT0.5S</SpawnOffset>
      </Enemy>
      <Enemy>
        <EnemyType>data/enemies/secondenemy</EnemyType>
        <SpawnTime>PT20S</SpawnTime>
        <NumberOfSpawns>10</NumberOfSpawns>
        <SpawnOffset>PT0.5S</SpawnOffset>
      </Enemy>
      <Enemy>
        <EnemyType>data/enemies/boss1</EnemyType>
        <SpawnTime>PT30S</SpawnTime>
        <NumberOfSpawns>1</NumberOfSpawns>
        <SpawnOffset>PT0S</SpawnOffset>
      </Enemy>
    </Enemies>
  </Asset>
</XnaContent>

Кожен елемент Ворога - це в основному хвиля конкретних типів ворога. Тип визначається в EnemyType, тоді як SpawnTime - це "рівень часу", який має з’явитися ця хвиля. NumberOfSpawns та SpawnOffset - це кількість ворогів, яка з’явиться, і час, який проходить між кожним нерестом відповідно.

Це може бути гарною ідеєю або там можуть бути кращі. Я не впевнений. Я хотів би побачити деякі думки та ідеї.

У мене є дві проблеми з цим: нерестовий нерест правильно та створення редактора рівнів. Що стосується редактора рівня - це зовсім інша проблема (яку я, мабуть, опублікую у майбутньому: P).

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

Отже, якісь ідеї? Коментарі?

Спасибі заздалегідь.

Відповіді:


4

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

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


4
І як бонус, якщо змінити швидкість прокрутки, або глобально, або для частини рівня, вона буде тримати пізніших ворогів у правильних нерестових позиціях, бо якби це було на часі, вороги нерестилися б у правильних місцях.
AttackingHobo

2

Я пропоную вам вивчити код PowerManga як орієнтир. Вони мають два типи рівнів: бічні прокручувальні (тирійські) рівні, де речі розташовані на певній відстані від початку рівня, а інші речі генеруються випадковим чином, та "нерухомі" рівні (à la galaga), де розбирається лише одна хвиля після того, як попередній закінчив свою схему.

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

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

HTH.


Я вже використовую криві Bezier для зберігання рухів противника (що також серіалізується в xml). Я в основному використовую XML, оскільки і .NET, і XNA мають вбудовану підтримку серіалізації / десеріалізації. Сценарій LUA звучить добре, але він потребує більше роботи. Однак я завжди планував його використовувати, тому після того, як закінчу якийсь базовий двигун, обов'язково вивчу його. Фінальт, ідея нересту хвилі після попередньої звучить цікаво.
пік

2
XML чудово, якщо він створюється інструментом, а не редагується вручну. Хоча мови сценаріїв можуть бути корисними для спеціальних випадків (наприклад, боси), це зовсім окрема проблема визначення стандартних шаблонів атак, чи не так?
bluescrn

0

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

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

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

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

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