Командування впорядкування архітектури карликової фортеці

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

1. Ідіть до дерева
2. Поріжте дерево
3. Доставте деревину на склад
4. Переходьте до іншого дерева
5. і так далі..

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

Я боюся, як це стане безладно, коли я створю більше таких замовлень:

Будувати будинок

1. Переходьте до складу
2. принести деревину на будівельну ділянку
3. повернутися до складу
4. Донесіть камінь до будівельної ділянки
5. оживити будівельний спрайт

Посадка

1. Переходьте до складу
2. принести насіння на фермерську ділянку

Заварювання

1. Переходьте до складу
2. Принесіть рослину нерухомо
3. оживити пивоваріння спрайт

Отже, моє запитання полягає в тому, як я можу запровадити систему впорядкування команд, як карликова фортеця і уникати коду спагетті одночасно? чи є якісь структури даних, які мені потрібно вивчити? Чи потрібно розміщувати послідовність команд в окремому файлі xml?

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

Різання деревини

• Я перевозять дрова, і на складі? Так : киньте його
• Я несу деревину? Так : піти на склад
• Я на дереві? Так : подрібніть його
• Ні всім вище : ідіть до дерева

Переваги цього:

• Дуже простий у виконанні
• Гнучка - ви можете вільно розкладати цей список, додавати елементи, видаляти предмети, комбінувати елементи
• Немає штату - ви можете запустити цей список зверху для будь-якого гнома в будь-якому штаті, і гном просто зробить правильну річ ^TM

Недоліки:

• Легко застрягнути в петлях, оскільки немає стану і не обізнано про застрявання

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

Якщо ви можете зробити послідовності досить загальними, коду спагетті не так багато.

У разі доставки, наприклад: WorkTask працює з WorkPlan. Робочий план говорить про те, який тип ресурсного підрозділу потрібно вибрати, з якого будинку, використовувати анімацію прогулянок, використовувати яку робочу анімацію, час на роботу та всі подібні деталі. Отже, врешті WorkTask може виглядати так:

1. Знайдіть% resource1% на карті
2. Перейдіть до цього місця за допомогою% animation_1%
3. Робота на місці, використовуючи% animation_2% за% time%
4. Візьміть% req_resource1% у% req_count1% кол
5. Перейдіть до% home%, використовуючи% animation%
6. Почніть% animation_6% всередині% time_2%
7. тощо.

Ми успішно використовуємо описаний підхід. У нашій грі є ~ 15 завдань. Деякі основні моменти:

• Завдання дають одиничні дії (іти туди, увійти, вийти, перейти сюди, залишитися, працювати, піти)
• Дія закінчується або Готовим, або Скасованим станом і передає його Завдання
• Все жорстко закодовано (не потрібно писати аналізатор, методи інтерфейсу, зворотну сумісність)
• Кожне завдання реалізує абстрактний клас завдань за допомогою декількох загальних методів (створення, виконання, збереження, завантаження)
• Як правило, одне завдання на модуль, але подібні завдання є в одному модулі
• Дуже схожі завдання знаходяться в одному класі та керуються кількома ІФ (доставити додому або доставити до підрозділу)
• Кожне завдання потребує належного блокування та розблокування ресурсів (fe, якщо одиниця гине на будь-якому кроці, ресурс, який він заблокував, повинен бути звільнений)

Отже, це в основному проблема топографічного сортування.

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

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

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

Ви також можете додати пріоритети до вузлів, і завдання може полягати в пошуку такого впорядкування серед усіх замовлень, які заповнюють залежності, які мають перші вузли пріоритетності, які виконуються першими.

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

Тепер як її вирішити - http://en.wikipedia.org/wiki/Topological_sorting