Constant resource drain for strategy game

Question

So I have a factory that builds a unit over time. The unit costs mass. Mass is stored as a floating point variable, and is constantly generated over time. Example, I have a resource node that gives 5 mass a second. That means each step you take 5 mass * deltaT and adds that to total mass. When mass it displayed it is rounded to the nearest integer, and gain/loss indicators are displayed to the tenth.

This works fine and well for factories draining mass and resource nodes gaining mass over time. However, I am unsure how to handle it when mass gets to 0. Do I skip the step? These seems like the best choice because that creates and automatic queue for requesting available resources. However I currently don't account for all the gain at once. I look at the gain/drains unordered, which could lead to a broken queue. Example I have two factories that both need .3 resources, and one node that creates .5 resources each step. Then factory 2 builds twice as fast as factory 3, soley because factory 2 always gets priority on the mass. It might be that because I will have many factories and nodes thare all adding at different rages that stuff may average out, but I doubt it.

Could I also force all factories to stop building for a step? That sounds complicated, and very poorly written. I am considering to changing my system to ticks, but something still has to have priority for requesting mass, and I am not sure the best way to do it.

Answer 1

I agree with Petr: There is no set way to do it. How you want to do it is a matter of how you want to design your game.

In this circumstance, however, I think it's immediately obvious the sort of mechanic you're trying to get at: you just want things to produce as fast as possible, within the amount of mass you have available.

Producing within capacity

I'm going to take a leaf out of Supreme Commander's book, since you're doing a system very much like theirs: If you're producing above capacity, the neatest way to deal with it is have production slow down across the board. Lowering production capacity is actually pretty simple.

A production speed mechanic

Each update step, your factories don't just produce a set amount: they operate by a production speed, which determines how much progress they make in each step and how much mass they use up. When you're producing at 75% capacity, your factories make 75% as much progress each step and use up 75% the mass compared to 100% capacity.

To calculate the production speed, before building anything at all, you should query your factories to determine the total resources that would be used this step at full capacity. Then you perform a simple calculation:

production speed = (total mass capacity / mass required this step)
if (production speed > 1.0) production speed = 1.0

Let's say you need 125 mass this step to produce at full capacity, but only have 100 mass this step. This equation provides you with a production speed of 0.8 (the decimal representation of 80%). When you tell your factories to actually perform their building, you hand them this value to tell them what speed they're building at: and now your production is slowed down across the board.

Alternatives

You could also begin shutting down factories temporarily until production capacity frees up, and it could be very interesting to see that happening to factories farther away from generators when at extremely low capacity.

Multiple resources?

Up to you how you handle this; there are a lot of options. The simplest one is probably to calculate a production capacity for each resource and then pick the lowest one, such that your weakest resource becomes a bottleneck for all the rest.

Answer 2

Although I like Jonathan Hobbs' answer I think a queue system is even simpler:

Queue<Factory> queue = ...;
int numFactories = ...;

Update()
{
    int resources = GetAllResourcesForThisStep();
    for(int i = 0; i < numFactories; i++)
    {
        if(queue.Peak().RequiredResources <= resources)
        {
            Factory f = queue.Pop();
            resources -= f.RequiredResources;
            queue.Push(f);
        }
        else
        {
            break;
        }
    }
}

This will probably work on average in the same way as Jonathan's implementation. However Jonathan's solution might give problems if the workspeed is set very low and my implementation could have a factory with a very high resourcerequest for this frame have it block other factories for several frames.

Answer 3

Well, i'll expand on John's idea, since we discussed this a bit in chat.

edit: This solution is actually only preferable if the consumableAmount is relevant to how often the factory should get a batch of resources. If it's all the same, then you can indeed just use a queue.

My solution: all factories listed in a priority queue. Priority is increased as a factory is suffering from starvation. Starvation, priority, set to zero when factory has consumed resources. Top priority is always going to get the next batch of resources.

On determining which factory gets what resources, in some kind of pseudo code:

iterator i = factoryqueue.start()
bool starvation = false
while(i.next())
  if(i.ready)
    if (!starvation) 
      if (i.consumeAmount < resource.count) starvation = true
      else 
        i.consume(resource)
        i.priority = 0
    if (starvation)
      i.priority += 1

This way your factories will make 1 product each in turn, if you want to adjust by taking in to account the consumeAmount so that cheaper products are made more frequently, you could increase priority by 1/consumeAmount for example.

Answer 4

Strange question.

My problem is that if the resource hits 0 I don't know what to do. Should I make a queue of some sort? Should I skip an object's step. What?

What you need to do, depends on a game logic you create. You can do a queue, you can skip. Depends on how you think your game should behave. Correct me, if I wrong on your question.

Answer 5

I am developing a similar supply system in my own game, so I have also been thinking about how to resolve the supply-lock issue, and favoritism. To illustrate the problem, I'll create a simple example:

If you have a list: [producer1, consumer1, consumer2, consumer3] and you update in order, starting at supply = 0, you'll get this:

producer1 produces 5 mass. You now have 5 mass
consumer1 wants 3 mass. Success, you now have 2 mass
consumer2 wants 3 mass. Fail
consumer3 wants 3 mass. Fail
[next tick]
producer1 produces 5 mass. You now have 7 mass
consumer1 wants 3 mass. Success, you now have 4 mass
consumer2 wants 3 mass. Success, you now have 1 mass
consumer3 wants 3 mass. Fail
etc...

consumer1 gets all the fun, while consumers 2 and 3 starve until consumer 1 has been satisfied. Depending on your game, this may not be desirable. I know in my game, it's not. When I get around to it, I'm going to create a queue where consumers that have been fed in one tick will move to the back of the queue for the next tick, which I believe is what Roy T. is getting at. The example above would look like this:

producer1 produces 5 mass. You now have 5 mass
consumer1 wants 3 mass. Success, you now have 2 mass. <-- Move to end of queue
consumer2 wants 3 mass. Fail
consumer3 wants 3 mass. Fail
[next tick]
producer1 produces 5 mass. You now have 7 mass
consumer2 wants 3 mass. Success, you now have 4 mass  <-- Note the order change
consumer3 wants 3 mass. Success, you now have 1 mass
consumer1 wants 3 mass. Fail
etc...

This way, everyone will get their fair share of the resources.

I also plan to implement an additional queue to be used as a priority queue so that the user can select certain structures to have resource priority. The priority queue will always be served before the standard queue. Make sure that all producers are updated first, then consume all resources second, otherwise the queue will break down when you produce resources part way through a tick and some consumers have already been starved.

So to recap: Update the producers, then the priority queue, moving fed consumers to the end of the priority queue, then update the standard queue, moving fed consumers to the end of the standard queue.

Answer 6

You can keep a number of the total resource demand per tick for all constructions. If one resource storage hits less than this required amount, then all construction would stop completely until the storage has gathered enough to support at least 1 tick of production. Then production can resume.

So instead of storing production rate as a float, it is binary - either your factory produces at full speed or it doesn't.

That being said, this approach is essentially the same as Jonathan's answer, for the production rate special cases 0.0 and 1.0 - an arbitrary float f with 0.0 <= f <= 1.0 is probably more elegant as you don't get jerky storage amount movements, but the logic should be a bit simpler.