Przypisywanie zadań

W RTS, w którym pracownicy mają za zadanie np. Zbudować ścianę, w jaki sposób pracownicy decydują, które ściany zbudować?

Gracz decyduje, które ściany mają zostać zbudowane, ale nie przypisuje poszczególnych pracowników do poszczególnych kwadratów ścian. W wielu grach RTS pracownicy po prostu wykonują zadania, które są blisko nich, ale w moim RTS chcę używać strategicznego wykonywania wyraźnych zadań na określonych polach jako głównej strategii, więc nie chcę, aby głupi pracownicy gdzieś się grupowali i pozostawiając zadania dalej nie zrobione.

Korzystam z przykładowej ściany budynku; może to być wydobywanie kamienia, tworzenie drogi, zbieranie drewna lub cokolwiek innego. Najważniejsze, że użytkownik wybiera gdzie, ale nie kto.

Pracownicy mogą pracować tylko na kwadratach sąsiadujących z dostępnymi kwadratami; kwadraty, nad którymi sami pracują, mogą być nieprzejezdne do czasu zakończenia pracy.

Robotnikom 1 i 2 nakazuje się wydobywać kwadraty A, B, C i D.

Mogą przesunąć się o jedno pole na tyknięcie gry, a wydobycie kwadratu zajmuje 10 tyknięć.

Jak decydujesz, który pracownik wydobywa który kwadrat?

Wydaje się oczywiste, że 1 powinien wydobywać A, a 2 powinien wydobywać C.

1 jest 4 kwadraty od A, więc skończę kopanie w 14 tyknięciach. Gdzie mam iść dalej i dlaczego?

A co jeśli byłby inny kwadrat - E - do wydobycia bezpośrednio nad B?

Jakiej logiki używa pracownik, aby zdecydować, gdzie kontynuować?

Oznacz węzeł zasobów jako zajęty lub ogranicz liczbę pracowników, z których może korzystać drzewo. Jeśli robotnik jest przydzielony do zbierania w pewnym momencie, tak naprawdę im mówisz, aby zebrać najbliższe dostępne drzewo.

Dwie główne ścieżki: realistyczne podejście polegałoby na ocenie i oznaczeniu ilości zasobów przed ich przybyciem. Aby uniknąć dziwnych problemów z kolejkami, daj pracownikom zasięg widzenia w celu oceny drzew. Pozwala to pracownikowi zbliżyć się do określonego węzła zasobów podczas przejścia do łatki. Daje to ograniczone możliwości optymalizacji.

Jednak w wielu systemach RTS (SC i SC2) pracownicy nie oceniają węzła, dopóki nie dotrą. Prowadzi to robotników do błądzenia się do momentu znalezienia węzła zasobów. Pozwala to na większą nagrodę za umiejętności / optymalizację. (Widziałeś kiedyś niesamowite podziały pracowników?) Jednak większość twoich graczy po prostu zaznacza wszystko, klika i denerwuje, że wszyscy najpierw wybierają tę samą lokalizację.

Dokładna implementacja będzie się różnić w zależności od sposobu grupowania zasobów. W AoE drzewa i ryby są ciągłymi obszarami, więc zbieracze mogą znaleźć się dość daleko w miarę postępu gry. Ale w grach takich jak SC i Red Alert zasoby znajdują się w dyskretnych łatkach. Pracownik musi więc tylko rozejrzeć się po tej konkretnej łatce.

EDYCJA po edycji: Nie stresuj się zbytnio wydajnością pracowników. Każdy RTS, o którym myślę, ma nieefektywność pracowników. Rzeczy takie jak podziały pracowników wynikają z tego, że gracz lepiej zarządza swoimi pracownikami niż gra. Myślę, że podchodzisz do tego z perspektywy programistów, a nie projektantów. Problem pozostawionego pojedynczego kleszcza można obejść jedynie przez ulepszenie liczb i umożliwienie zebrania węzłów w dyskretnej liczbie podróży. Niesprawności pracowników są dla ciebie rażące, ponieważ znasz system, który za tym stoi. Jeśli jednak twoi testerzy gier nie zauważą, nie zatrzymuj się zbyt długo.

Rozwiązanie i myśl:

Rozwiązanie: kliknięcie węzłów gromadzących może zostać umieszczone w kolejce, a następnie, gdy zadanie wznosi się na szczyt kolejki, znajdź ważoną wartość kolejki zadań dla pracowników, a następnie znajdź najbliższego sąsiada o najlepszej ważonej wartości kolejki zadań ( wartość kolejki).

W twoim przykładzie możesz mieć optymalną wartość kolejki równą 0 (co oznacza brak bieżących zadań). Dodaj 1 do wartości kolejki za każde pole, które musieliby pokonać (czas podróży) i 10 za każde zadanie (czas na wykonanie zadania). Usuń 1 z wartości kolejki każdego pracownika za każdą upływającą jednostkę czasu (jeśli początkowa wartość kolejki wynosi 10, to po 3 jednostkach czasu wartość kolejki wyniesie 7). Następnie znajdujesz najbliższego sąsiada (w przypadku, gdy wielu pracowników ma równoważne wartości kolejek), aby znaleźć pracownika, który powinien wykonać to zadanie.

Na przykład, zakładając, że węzły zbierające wyskakują z kolejki zadań w kolejności alfabetycznej (AD) i żadne ruchy nie są wykonywane podczas wyskakiwania kolejki:

(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.

Minusem robienia tego w ten sposób: wysoce obliczeniowym.

Myśl:

Jak twoja gra poradzi sobie z blokowaniem zasobów? tzn. jeśli istnieje siatka 4x4, w której każdy węzeł jest zasobem, czy pracownicy mogą uzyskać wewnętrzne 4 węzły? Jeśli nie, upewnij się, że pracownicy nie tylko bezczynnie tam próbują się do nich dostać, ale może przypisać im inne zadanie i przypisać jednego z pracowników gromadzących jeden z zewnętrznych węzłów do wewnętrznych po ukończeniu zewnętrznego węzła (wstaw w kolejce zadań dla pracownika).

spróbuj mieć jakiś system wagowy, który, jeśli drzewo jest zbierane, obliczyć karę za układanie w stosy, a także pewien bonus odległościowy. (ile czasu zajmuje przejście z punktu A-> B z drewnem itd.). Następnie możesz wykonać algorytm, który sprawdza najbliższe drewno i sprawdza jego wagę, a następnie porównuje, czy jest pożądane. a następnie użyj tej o najniższej wadze.

oczywiście wymaga to drobnych poprawek. ale pomysł jest prosty.

Każde zadanie powinno mieć a) znaczenie b) status przydziału (liczba przypisanych pracowników)

Pracownik może wówczas zdecydować się na pracę, która daje mu największą „nagrodę” na czas. Nagrodę oblicza się według wagi podzielonej przez liczbę przydzielonych pracowników podzieloną przez czas, który musi zainwestować (chodzenie i wykonywanie pracy). Jeśli twój pracownik może specjalizować się w pracach (np. Rąbaniu drewna), tak naprawdę woli zadania, które może skutecznie wykonać. Zadania należy oczywiście przypisywać tylko wtedy, gdy można je kontynuować we właściwym momencie (np. Potrzebne zasoby muszą być dostępne).

Aby uniknąć cofania niektórych zadań przez długi czas (np. Z powodu ich dużej odległości). Znaczenie powinno rosnąć z czasem. W przypadku zbiorów ważność powinna również zależeć od tego, ile zasobów tego rodzaju jest obecnie dostępnych / potrzebnych (np. Wyprodukowane jednostki podzielone przez jednostki zamówione w danym okresie).

Aby uniknąć szybkiej zmiany pracy przez pracowników, pozwól im zmienić obecną pracę tylko wtedy, gdy nagroda znacznie się poprawi (o określony próg). Podczas obliczania wartości nagrody za czas możesz również zastosować podwojone koszty początkowego przejścia do pracy. Ponadto powinieneś pozwolić na ponowne obliczenie optymalnej pracy pracowników jeden po drugim, a nie wszystkich jednocześnie.

Dodatkowo dodaj trochę losowości do obliczonych nagród. Spowoduje to lepszą dystrybucję pracowników do różnych prac (w ten sposób nie tylko „wszyscy” pójdą do tej samej pracy). Ale efekt ten jest już zmniejszony poprzez szeregowe przeliczenie kolejnej optymalnej pracy dla pracownika i dostosowanie liczby pracowników już przydzielonych (więcej pracowników wykonujących tę samą pracę zmniejsza oczekiwaną nagrodę).

Algorytm może wymagać nieco dostosowania, jeśli twoje zadania można przypisać tylko do jednego pracownika. W takim przypadku wykonaj następujące czynności: Pracownik wybiera pracę z najwyższą nagrodą za czas (ważność podzielona przez potrzebny indywidualny czas). Jeśli inny pracownik może wykonać tę samą pracę z wyższą oczekiwaną nagrodą za czas, uruchamia aktualnie przypisanego pracownika. Nowy „bezrobotny” pracownik następnie próbuje znaleźć inną pracę. W twoim przykładzie może to wyglądać tak:

• „C” ma bardzo duże znaczenie. I pracownik 1 przypisuje się do „C”, nawet jeśli jest daleko.
• Pracownik 2 zostaje przydzielony jako następny i ma wyższą nagrodę za czas za „C” (mniej chodzenia). Wyrzuca więc pracownika 1 z zadania i przypisuje się do „C”. Nie kosztowało to czasu, ponieważ wciąż jesteśmy w tym samym przedziale czasowym symulacji. Dlatego użytkownik nie zobaczy tego ponownego przypisania zadania.
• Pracownik 1 szuka następnie innej pracy. Robotnik 1 nie wyrzuca robotnika 2 z „C”, ponieważ jego nagroda za czas nie jest lepsza. Jest więc przypisany do „A” lub „B” (w zależności od ważności). Znów jest to wciąż ten sam przedział czasowy symulacji.