Register for resource extraction

Started by
11 comments, last by JoeJ 4 months, 1 week ago

In the Age of Empires and Starcraft model if a worker sent to gather stone or crystals finds several workers already working at the assigned resource patch he will have to move to the closest neighboring resource patch. Warcraft 3 workers stand in line and enter the mine in the order of arrival at the mine. Basically in both cases the workers need to register with the resource patch. In addition the AOE model has the resource patch keeping count of the number of workers currently assigned to it. As if getting the worker to travel back and forth between the resource tile and the HQ wasn’t challenging enough.
Is what I’m saying correct?

My project`s facebook page is “DreamLand Page”

Advertisement

Seems you look at this from a kind of global AI system, which knows about a need for resources to build stuff, then asserts certain units to obtain the resource, and both the units and the resource are dictated and controlled from this global, higher level AI. The ‘top down’ way of thinking.

But i think of it again from a more local perspective, where units at the bottom level have a behavior, and at a higher level the sum and interaction of all the behavior emerges higher level order, so we observe the same higher level AI ideally. The ‘bottom up’ way of thinking.

In detail, i see no need for any logic associated to the resource patch. Instead the units just need to be able to wait. A unit wants to collect resources, follows the path, but then another unit blocks its way. The behavior we need here is to figure out if the other unit is friendly. If so, we ask about the goal of the other unit. If it's the same goal, our current unit may be happy and go idle until the way becomes free. This way many units unique automatically, without any need for a external god logic to handle this.

So i would implement all logic in the units, observe how it works out with one, two, and dense crowds of many units. Ideally it makes sense and remains predictable to the player.
But no idea if that's the way how those RTS games were made. I assume they used both those top down and bottom up approaches for various things.

>If it’s the same goal, our current unit may be happy and go idle

but it‘s not the same goal, the goal is to have the workers distributed evenly between the resource patches, there will be several resource patches sitting next to each other. What you‘re describing is closer to how Warcraft 3 does things.

>and both the units and the resource are dictated

If done right the unit should be independent. The unit and the resource patch talk when the former checks the number of other units currently working on the resource patch and when it registers if there is enough room.

My project`s facebook page is “DreamLand Page”

Calin said:
the goal is to have the workers distributed evenly between the resource patches, there will be several resource patches sitting next to each other.

Sounds you're more interested in the higher level distribution / assignment problem.
This can become difficult combinatorial stuff. I guess WTA is a good example.
I assume RTS games use related algorithms, but that's just a guess. If so, key surely is to find approximate but fast solutions. You may need to limit it anyway, to prevent AI becoming too strong.

You should try some RTS games if you’re interested. It’s not the same as looking at the source but we’re programmers we can make some educated guesses about what is taking place under the hood just by seeing the game in action.

My project`s facebook page is “DreamLand Page”

Calin said:
it‘s not the same goal, the goal is to have the workers distributed evenly between the resource patches, there will be several resource patches sitting next to each other. What you‘re describing is closer to how Warcraft 3 does things.

This is not what I've seen in any RTS game, including AoE or Starcraft.

As JoeJ wrote, it is more local.

Very often the unit has an order in the form “Mine resources at x,y”. This runs a larger behavior tree.

After validating the work, the first step has a subtask, “navigate to x,y”. That's where the player clicked.

The next subtask is “mine resources”. The logic will probably be in a loop that includes many options, what to do when full, what to do if the unit is attacked while mining and also what to do when done, but also this:

  • If resources exist here, mine this tile.
  • Else find a nearby tile with the resource and meeting whatever criteria you've got, navigate there and continue the loop

Those extra rules about avoiding others doing the mining are all part of the individual unit's logic. For units that moved while collecting, the patterns were often based on which neighbor had the most resources, preferring them in a specific directional order. The biggest preference was to continue on the path, then when you reach the end, prefer the diagonals in a specific ordering, which causes the diamond pattern some games used.

The units really don't register with the map, instead the units are each doing their own, relatively simple behavior logic. Done well, the simple pieces of logic driving each actor will appear to have complex emergent behavior.

Thank you for sharing frob

My project`s facebook page is “DreamLand Page”

It's been a few years since I've been on the various projects, but really the logic for Grey Goo (an RTS) wasn't all that different from the logic in The Sims or Littlest PetShop (a pet sim) or from Ark. In each case you've got units on the world drawing from a small set of behavior trees.

Individually some games had more reusable logic than others, but in each case it's just building up small sets of behaviors and actions out of building blocks. It doesn't matter if it's a T-Rex, a Sim, a pet, a Mech, or a Howitzer, each one doing their state machine to patrol, explore, harvest, or similar behavior loops. The logic for a Sim to “go to work” is not all that different from a Harvester's “go harvest resources”.

I am still amazed by how a simple set of well-picked rules and local decision making can cause very complicated behavior.

In all these cases the rules only say something about local situations. By combining several, you suddenly find complexity you'd never expect due to rule interactions.

This topic is closed to new replies.

Advertisement