Resupply

TOE resupply is based on a batch system. When a vehicle resupply is scheduled for “7 hours from now” the time is converted into a batch number. If two riflemen or two tigers are scheduled for delivery within a few seconds of each other, they are grouped onto the same “docket”.

A docket specifies “1 rifleman was requested to replace the one bobn spawned” or “5 new riflemen for initial supply” etc, and a batch is the list of dockets scheduled for a particular delivery window.

Each docket is assigned a number, which is based on the resupply time when the request was made. Nominally, resupply time is 7 hours, but this can go up depending on RDP delays. If there is a 10% RDP penalty, your resupply time is 7.7 hours.

The time between dockets – the docket rate – is nominally 15 seconds. So requests for vehicles in 150-164 seconds would be placed on batch number 10.

The twist is that rate at which the batch processor pulls tickets off the queue can be variable. It can pull batches off the queue faster or slower. For example, if we implemented “slower resupply further from your DivHQ” the resupply times would remain the same, but by waiting 20 seconds between batches instead of 15, the equipment would arrive more slowly.

This two pronged approach will mean that the population-based supply adjustments – which will affect the rate at which the batch processor takes tickets off the queue – will not undo RDP bombing affects. The two compliment each other.

The result is a more even distribution and scaling of effect between increases and decreases in player population, the epic raids of peak play won’t be total annhilation to the low-peak population and the low-peak heroic raids won’t be a fart in a thunderstorm to the guys logging in after them.

4 Comments

I need a graph to understand that.

Sounds good. Lets play it up and see how she fares.

BTW, the WW2OL Dambusters thank you for the much needed adjustment, our command element is getting giddy like schoolgirls… Ok so maybe just Charlie. At any rate, a S! to a fellow DB.

Now if you wouldn’t mind devising a method of getting strategic/logistic targets in game…

exactly. Or the algorithm that drives the graph so we can map the abstract line and extrapolate.

I understand the *words*, but I’m interested in how the [(number of full resupply equipment as expressed by ticket or batch) * (function of rdp resupply time expressed as percentage of N where N = 1.28.3 (queu timer)) + (number of New Tier equipment modifier) / (f=function of population of server as a percentage of N* where N* equal estimated average server population in 1.28.x changing by (insert time function e.g. hourly) * (modifier for continuously changing population hourly base modifier number per ‘season’ e.g. summer out-of-school vs. full winter in-school)]

Its a real equation. Just without the standard naming convention at the top placing Alphanumerics only into it, I left the word logic.

THAT is what I am very much interested in seeing. The alphanumeric equation the computer will use with variables defined for the above…and the sample graph showing the differences in equipment availability under a dry-run.

I love the precision it suggests. I just wonder at the base principles, because we could ‘game’ this in dry-run equations and look for key variable or derivative equations that would show us a ’tilt’ or sudden overbalance.

Your server population can swing greatly in reaction to available equipment – so the time slices used to determine equipment ups or downs (you will pull equipment suddenly from the list if the population crashes as a result of a server … discontinuity?

As well, the RDP percentile modifier may have unusual characteristics in a short period of time….especially at low-pop; based upon whatever population slicer function you use to measure a ‘change’ in population…especially as RDP gets ready to change Tiers.

This is a lot of words to say, “Have you run the numbers?” and “Can we see them?”

:)

Thanks for looking into this.

RDP is a very important function in a WWII sim, however it can not be the basis for air activity. The problem with RDP effecting play “7 hours from now” is that it does not give any immediate gratification to those performing the bombing and limits game play options for future players without them understanding why. These is demoralizing to both participants and since this is above all “a game”, it has an overall negative effect on game play.

Since most players do not fly, the general population finds RDP even more frustrating because it occurs so far removed from their basic gaming vicinity. It would be much more understandable to these players if they could see an impact on local resource targets.

How close are you to implementing regional targets that can have a more immediate effect on brigade level performance?

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

You may use these HTML tags and attributes:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: