Призначення завдань


10

У РТС, де перед роботами покладено завдання, наприклад, будувати стіни, як працівники вирішують, які стіни будувати?

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

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

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

введіть тут опис зображення

Робітники 1 і 2 повідомляються шахтним квадратам A, B, C і D.

Вони можуть рухати один квадрат за гру-галочку, а видобуток квадрата займає 10 кліщів.

Як ви вирішите, який робітник мінить, який квадрат?

Здається, само собою зрозумілим, що 1 повинен бути шахтним A і 2 - шахтним C.

1 знаходиться в 4 квадратах від А, тож закінчив видобувати його в 14 кліщів. Куди я повинен йти далі і чому?

А що, якби був видобутий ще один квадрат - E -, який буде видобутий безпосередньо над B?

Яку логіку використовує працівник, щоб вирішити, що далі робити далі?


Я замість цього спробую вдачу на SO: stackoverflow.com/questions/18634701/assigning-worker-tasks - якщо мод може бути таким люб’язним, щоб закрити / видалити його?
Буде чи

1
Перехресне повідомлення - це не дуже добре. Що ви тут зробили - це витрачати час на всіх, хто відповів вам нижче. Це дуже корисливий спосіб використання сайтів SE.
MichaelHouse

Відповіді:


6

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

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

Однак у багатьох RTS (SC та SC2) працівники не оцінюють вузол до їх прибуття. Це лідерів робітників блукати, поки не буде знайдений ресурсний вузол. Це дозволяє отримати більше нагород за навички / оптимізацію (коли-небудь бачите дивовижні розбивки робітників?) Однак більшість ваших гравців просто збирають усі, клацають і дратуються, що всі вони спочатку йдуть в одне місце.

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

РЕДАКТУВАТИ після редагування: Не наголошуйте надто на неефективності працівників. Будь-яка РТС, про яку я думаю, має неефективність працівників. Такі речі, як робочі розколи, виникають у тому, що гравець краще керує своїми робочими, ніж гра. Я думаю, що ви, можливо, на це поглядаєте програмісти, а не дизайнери. Лівий випуск сінг-сигналу можна вирішити лише за допомогою налаштування номерів та встановлення вузлів у дискретній кількості відключень. Неефективність працівників викликає до вас велику увагу, оскільки ви знаєте систему, яка стоїть за нею. Однак якщо ваші ігрові тестери не помічають, то не зупиняйтесь занадто довго.


Я відредагував питання, щоб уточнити, що в моєму РТС гравець вирішує, яку ресурсну плитку збирати, і тип завдання кожного працівника, але не повинен мікро-керувати, який робітник куди йде.
Will

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

2

Рішення та думка:

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

У вашому прикладі оптимальне значення черги може бути 0 (не маючи на увазі поточних завдань). Додайте 1 до вартості черги для кожного квадрата, до якого вони мали б подорожувати (час подорожі) та 10 для кожного завдання (час, щоб виконати завдання). Видаліть 1 зі значення черги кожного працівника за кожну пройдену одиницю часу (якщо початкове значення черги 10, то через 3 одиниці часу значення черги буде 7). Тоді ви знайдете найближчого сусіда (якщо у багатьох працівників є еквівалентні значення черги), щоб знайти працівника, який повинен виконати це завдання.

Отож, для вашого прикладу, якщо припустити, що збираючі вузли спливають із черги завдань в алфавітному порядку (AD), і рух не робиться під час появи черги:

(values in format [total] = [preexisting value] + [current task distance])
A Pops: 
    queue value of 1: 4 = 0 + 4 
    queue value of 2: 19 = 0 + 19
    Assigned to 1.
B Pops:
    queue value of 1: 24 = 14 + 10 (distance to B from A) 
    queue value of 2: 9 = 0 + 9
    Assigned to 2.
C Pops:
    queue value of 1: 25 = 14 + 11
    queue value of 2: 20 = 19 + 1 
    Assigned to 2.
D Pops:
    queue value of 1: 36 = 25 + 11
    queue value of 2: 41 = 20 + 21
    Assigned to 1.

Недостатньо робити це так: високо обчислювальна.


Думав:

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


так, деякі площі ресурсу можуть бути (тимчасово) недоступними.
Will

1

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

Звичайно, це вимагає тонкої настройки. але ідея проста.


1

Кожна робота повинна мати а) важливість; б) статус завдання (# призначених працівників)

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

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

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

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

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

  • "С" має дуже високе значення. І працівник 1 призначає собі "С", навіть він віддалився.
  • Робітник 2 призначається наступним і має вищу нагороду за "С" (менше ходьби). Тож він відкидає працівника 1 з роботи та призначає себе "С". Це не коштувало часу, оскільки ми все ще знаходимось в одному і тому ж відрізку моделювання. Таким чином, користувач не побачить цього переуступки завдання.
  • Потім працівник 1 шукає іншу роботу. Працівник 1 не знімає працівника 2 із "С", оскільки його винагорода за раз не краща. Тож він присвоюється "A" або "B" (залежно від важливості). Знову ж таки, це все ще знаходиться в тому ж відрізку часу моделювання.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.