Attribuer des tâches

Dans un RTS où les travailleurs sont chargés par exemple de construire un mur, comment les travailleurs décident-ils des murs à construire?

Le joueur décide quels murs doivent être construits où, mais il n'affecte pas de travailleurs individuels à des carrés de murs individuels. Dans de nombreux jeux RTS, les travailleurs effectuent simplement des tâches qui sont près d'eux, mais dans mon RTS, je veux utiliser la stratégie de tâches explicites sur des carrés spécifiques comme stratégie principale, donc je ne veux pas que les travailleurs stupides se regroupent quelque part et quittent les tâches plus loin. loin non fait.

J'utilise l'exemple de mur de construction; cela pourrait être l'extraction de pierre, la construction d'une route, la collecte de bois ou autre chose. L'essentiel est que l'utilisateur choisisse où, mais pas qui.

Les travailleurs ne peuvent travailler que sur des carrés adjacents à des carrés accessibles; les carrés sur lesquels ils travaillent peuvent être infranchissables jusqu'à ce que le travail soit terminé.

Les travailleurs 1 et 2 doivent miner les carrés A, B, C et D.

Ils peuvent déplacer un carré par tick de jeu, et extraire un carré prend 10 ticks.

Comment décidez-vous quel travailleur mine quelle case?

Il semble évident que 1 devrait extraire A et 2 extraire C.

1 est à 4 cases de A, donc vous aurez fini de l'explorer en 14 ticks. Où dois-je aller ensuite et pourquoi?

Et s'il y avait un autre carré - E - à extraire directement au-dessus de B?

Quelle est la logique qu'un travailleur utilise pour décider où procéder ensuite?

Marquez le nœud de ressource comme occupé ou limitez le nombre de travailleurs par lesquels une arborescence peut être utilisée. Si un ouvrier est chargé de se rassembler à un certain moment, ce que vous lui dites vraiment, c'est de récolter l'arbre disponible le plus proche.

Deux voies principales pour cela: Une approche réaliste serait d'évaluer et de marquer les ressources non avant leur arrivée. Pour éviter les problèmes de files d'attente étranges, donnez aux travailleurs une portée de vision pour évaluer les arbres. Cela permet au travailleur d'approcher un nœud de ressource particulier tout en marchant vers le correctif. Cela donne une optimisation limitée.

Cependant, de nombreux RTS (SC et SC2) n'ont pas de travailleurs évaluent un nœud jusqu'à leur arrivée. Cela amène les travailleurs à se promener jusqu'à ce qu'un nœud de ressource soit trouvé. Cela permet d'obtenir plus de compétences / récompense d'optimisation, (Avez-vous déjà vu de superbes répartitions de travailleurs?) Cependant, la plupart de vos joueurs vont tout encadrer, cliquer et être ennuyés qu'ils se rendent tous au même endroit en premier.

L'implémentation exacte variera en fonction de la façon dont les ressources sont regroupées. Dans AoE, les arbres et les poissons sont des étendues continues, donc les cueilleurs peuvent se retrouver assez loin au fur et à mesure que le jeu progresse. Mais dans des jeux comme SC et Red Alert, les ressources sont situées dans des correctifs discrets. Un travailleur n'a donc qu'à regarder autour de ce patch particulier.

MODIFIER après votre modification: ne pas trop insister sur les inefficacités des travailleurs. Tout RTS auquel je peux penser a des inefficacités de travail. Des choses comme les divisions des travailleurs découlent du fait que le joueur gère mieux ses travailleurs que le jeu. Je pense que vous prenez peut-être un point de vue de programmeurs à ce sujet et non des concepteurs. Le problème de gauche à droite peut être résolu simplement en modifiant les nombres et en ayant des nœuds récupérables dans un nombre discret de trajets. L'inefficacité des travailleurs vous frappe, car vous connaissez le système derrière. Cependant, si vos testeurs de jeu ne le remarquent pas, ne vous attardez pas trop longtemps.

Solution et réflexion:

Solution: vous pouvez faire placer les nœuds de collecte dans une file d'attente lorsque vous cliquez dessus, puis au fur et à mesure qu'un travail monte au sommet d'une file d'attente, recherchez la valeur de file d'attente de tâches pondérée pour les travailleurs, puis trouvez le voisin le plus proche avec la meilleure valeur de file d'attente de tâches pondérée ( valeur de file d'attente).

Dans votre exemple, la valeur optimale de la file d'attente pourrait être 0 (ce qui implique aucune tâche en cours). Ajoutez 1 à la valeur de la file d'attente pour chaque carré qu'ils doivent parcourir (temps de déplacement) et 10 pour chaque tâche (temps pour effectuer la tâche). Supprimez 1 de la valeur de la file d'attente de chaque travailleur pour chaque unité de temps qui s'écoule (si la valeur de la file d'attente de départ est 10, après 3 unités de temps, la valeur de la file d'attente sera 7). Ensuite, vous trouvez le voisin le plus proche (dans le cas où plusieurs travailleurs ont des valeurs de file d'attente équivalentes) pour trouver le travailleur qui devrait effectuer cette tâche.

Donc, pour votre exemple, en supposant que les nœuds de collecte apparaissent dans la file d'attente des tâches dans l'ordre alphabétique (AD) et qu'aucun mouvement n'est effectué pendant que la file d'attente apparaît:

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

Inconvénient de le faire comme ceci: très informatique.

Pensée:

Comment votre jeu va-t-il gérer le blocage des ressources? c'est-à-dire s'il existe une grille 4x4 où chaque nœud est une ressource, les travailleurs peuvent-ils obtenir les 4 nœuds intérieurs? Sinon, assurez-vous que les travailleurs ne restent pas inactifs là-bas en essayant de les atteindre, mais peut-être leur attribuer une tâche différente et affecter l'un des travailleurs rassemblant l'un des nœuds extérieurs aux nœuds intérieurs une fois que le nœud extérieur est terminé (mettez dans une file d'attente de tâches pour le travailleur).

essayez d'avoir un système de poids, que si l'arbre est collecté, calculez une sorte de pénalité d'empilement et aussi une sorte de bonus de distance. (combien de temps faut-il pour se rendre du point A-> B au bois, etc. souhaitable, puis utilisez celui dont le poids est le plus faible.

bien sûr, cela nécessite un réglage fin. mais l'idée est simple.

Chaque emploi doit avoir a) une importance b) le statut de l'affectation (nombre de travailleurs affectés)

Un travailleur pourrait alors décider de l'emploi qui lui donne le plus de «récompense» à la fois. La récompense est calculée par l'importance divisée par le nombre de travailleurs affectés divisé par le temps qu'il a besoin d'investir (marcher et faire le travail). Si votre travailleur peut se spécialiser dans des travaux (par exemple, couper du bois), il préférera en fait des tâches qu'il peut accomplir efficacement. Les emplois ne doivent bien sûr être attribués que s'ils peuvent être poursuivis au bon moment (par exemple, les ressources nécessaires doivent être disponibles).

Pour éviter que certains travaux soient annulés pendant longtemps (par exemple, parce que c'est loin). L'importance devrait augmenter avec le temps. En cas de récolte, l'importance devrait également dépendre de la quantité de ressources de ce type disponibles / nécessaires pour le moment (par exemple, unités produites divisées par unité demandée dans une période donnée).

Pour éviter que les travailleurs ne changent leur emploi trop rapidement, ne les laissez changer leur emploi actuel que si la récompense s'améliore considérablement (par un seuil donné). Vous pouvez également appliquer les coûts doublés pour la marche initiale au travail, lors du calcul de la récompense par valeur de temps. De plus, vous devez laisser recalculer le travail optimal des travailleurs les uns après les autres, pas tous en même temps.

De plus, ajoutez un peu de hasard aux récompenses calculées. Cela entraînera une meilleure répartition des travailleurs dans différents emplois (de cette façon, ils ne font pas que "tous" faire le même travail). Mais cet effet est déjà réduit en recalculant en série le prochain emploi optimal pour un travailleur et en adaptant le nombre de travailleurs déjà affectés (plus de travailleurs sur le même travail réduisent la récompense attendue).

L'algorithme doit peut-être être un peu adapté, si vos emplois ne peuvent être attribués qu'à un seul travailleur. Si tel est le cas, procédez comme suit: Un travailleur choisit le travail avec la récompense la plus élevée par temps (importance divisée par le temps individuel nécessaire). Si un autre travailleur peut faire le même travail avec une récompense attendue plus élevée à chaque fois, il donne le coup d'envoi au travailleur actuellement affecté. Le nouveau travailleur "au chômage" essaie alors de trouver un autre emploi. Dans votre exemple, cela pourrait ressembler à ceci:

• "C" a une très grande importance. Et l'ouvrier 1 s'assigne au "C", même s'il est plus loin.
• Le travailleur 2 est assigné ensuite et a une récompense plus élevée par temps pour "C" (moins de marche). Ainsi, il libère le travailleur 1 du travail et se fixe sur "C". Cela n'a pas coûté du temps, car nous sommes toujours dans la même tranche de temps de simulation. L'utilisateur ne verra donc pas cette réaffectation du travail.
• Le travailleur 1 cherche alors un autre emploi. Le travailleur 1 ne lance pas le travailleur 2 de "C", car sa récompense par temps n'est pas meilleure. Il est donc affecté à "A" ou "B" (selon l'importance). Encore une fois, c'est toujours dans la même tranche de temps de simulation.