Шукаєте деяку інформацію про дизайн програмування для атак та типів атаки в грі

Отже, я починаю вводити атаку на наш 2D-простір RTS (Це в Unity, тому він керується компонентами). Спочатку це було так само просто, як "ворог у дальності, завданий збиток". Однак буде декілька "типів" зброї / атак, пов'язаних з їх конкретним кораблем або структурою. Так само, як і інші фактори, пов'язані з попередньою сильною шкодою, наприклад типом збитків, а можливо, інерцією в майбутньому.

У вас, хлопці, кожен підрозділ і тип структури мають свій атакуючий тип. Значить, ви створюєте сценарій для кожної одиниці / структури, яка визначає тип атаки, пошкодження, ефекти, дальність, частинки, спрайт ... тощо. І додаєте це як компонент?

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

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

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

Якщо це недостатньо зрозуміло, дайте мені знати.

Редагувати: Чудові відповіді, дякую.

Розширене запитання:

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

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

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

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

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

Тут я намалював вам картину.

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

Ваш проблемний простір такий:

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

Я б структурував рішення таким чином:

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

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

// components
var bulletStrength = { strength: 50 };
var inertia = { inertia: 100 };
var target = { entityId: 0 };
var bullets = {};
var entity = entityManager.create([bulletStrength, inertia, target, bullets]);

var bulletSystem = function() {
  this.update = function(deltaTime, entityId) {
    var bulletStrength = this.getComponentForEntity('bulletStrength', entityId);
    var targetComponent = this.getComponentForEntity('target', entityId);
    // you may instead elect to have the target object contain properties for the target, rather than expose the entity id
    var target = this.getComponentForEntity('inertia', targetComponent.entityId);

    // do some calculations based on the target and the bullet strength to determine what damage to deal
    target.health -= ....;
  }
};

register(bulletSystem).for(entities.with(['bullets']));

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

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

Розгорнута відповідь
Ось як я підходив до нападу бластера з таким підходом . Я дозволю іншим відповісти за себе.

Я б змусив своїх підрозділів реалізувати інтерфейс або клас IAttacker з базовою статистикою / методами атаки. Коли IAttacker атакує IDamageable, він створює свою специфічну атаку, передаючи себе та свою ціль (IAttacker і IDamageable, або, можливо, колекцію ідентифікаційних матеріалів). Attack захоплює необхідні статистичні дані від IAttacker (щоб уникнути змін під час оновлення чи чогось подібного - ми не хочемо, щоб Attack змінював свою статистику після того, як вона вже була запущена), і якщо вона потребує спеціалізованої статистики, кидає IAttacker на потрібний тип (наприклад, IBlasterAttacker) і отримує спеціалізовану статистику таким чином.

Дотримуючись такого підходу, BlasterAttacker просто повинен створити BlasterAttack, а BlasterAttack піклується про інше. Ви можете підкласировать BlasterAttack або створити окремі FastBlasterAttacker, MegaBlasterAttacker, SniperBlasterAttacker тощо. Код атаки для кожного однаковий (і, можливо, успадкований від BlasterAttack): Створіть BlasterAttack та передайте себе та мою ціль (и) в. BlasterAttack деталі. .