Topic: Warehouse controls

Don't forget the system for globally (actually, on an economy basis) controlling desired stock levels, which already works (mostly; sometimes it seems a bit suspicious to me, but oh well) to control production.

And I agree with the sentiment of some others that this shouldn't be undertaken as a radical change. In other words, it does make sense to formulate a radically different vision of the future as the 'ideal state of the future'. However, once this is done, one should identify small steps towards this goal, so that it can be reached step by step, as developer time is available.

Otherwise, we'll end up with a KDE 4-like situation

Top

Quote

Mmmh. But isn't micromanagement a central part of the game? Sure, you think globally, but you tweak options locally: make roads better by avoiding three part roads and replace them with two two part roads. Stop workers here, drop soldiers there. I can't follow the argument that micromanagement is not the aim of the game. It must work effectively and one should not have to repeat itself, but having the tweaks is nice.

But back to the topic: what must be changed in the blueprint to get it to triaged state? Let's get more concrete.

Top

Quote

ixprefect wrote: What's the opinion on trying to balance warehouse contents automatically?

I remember having played WL (months ago) where such a regime was the default. All wares were distributed evenly among the warehouses. One negative effect was, that your roads became clogged often after building a new warehouse, because hundreds of trunks, water etc. suddenly were on the road.

Personally I dont like this concept. It takes away much of the planning that makes up for the fun in this game.

I like to build functional areas around a warehouse according to the geography the map supplies. (house building materials, food production, Metal industry) to keep transportation to a minimum. Then I connect these areas with high capacity long distance roads. If I succeed it usually leads to a very high productivity.

Even distribution (even of the conditional sort) would not be rewarding players for a thoughtful planning of their economy. It would probably help the AI, though.

Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top

Quote

WAREHOUSES

Why not have the global economy configuration screen have both a global total for the amount of each ware, and a minimum for each warehouse? The "Temporary global limit" column could be removed. The algorithm for storing a ware would be that if the nearest warehouse has less than twice (it can't be just the minimum number, or you run into the idiocy of sending the same ware both ways and causing traffic jams) the minimum amount of that ware, it is stored in the nearest warehouse. If not, it is stored in the nearest warehouse with less than the minimum amount of that ware. If there are no such warehouses, it is stored in the nearest warehouse. This, algorithm would, I think, provide necessary amounts to build quickly far from the production center, while still avoiding the traffic jams of trying to equalize wares completely.

Also, altering production priorities is fine, but the desired amounts should be selectable for ALL wares, and probably even for producers. The economy should NOT continue producing things after the global maximum is reached, just because a programmer has decided to override the wishes of the player. Stopping production of logs when you have 5k or of iron ore after you have 1k is very useful. If nothing else, it gets rid of a lot of congestion.

SHORTAGE QUEUING PROBLEMS

The original Settlers was deliberately restricted to relatively small maps, so that the queue-based destination system for when the economy is in shortage wasn't as amazingly bad. This game, however, is Widelands. We have huge maps, and this system for shortages is idiotic on large maps.

Consider the case where we have two identical production centers, 20 minutes travel time apart, and the economy is in shortage. Fish is produced at one center, and then chooses a destination randomly. It then spends traveling to the other center where it becomes a ration, then spends 20 minutes traveling back to the other center, where it becomes iron ore, then travels back to the other center and becomes iron, then travels back to the other center and becomes an axe. Production shuts down, because the road is jammed with identical goods traveling back ways back and forth on the same road. Currently, this situation can only be avoided by having only one production center, or by scrupulously avoiding having any goods go into shortage.

There are quite a number of reasonable ways this could be fixed. The one which could reuse the most code from the current system is probably queuing with destination trading of wares in transit. The way this would work is for all wares to be assigned under the current system, but as soon as a destination is selected, this ware is flagged to be checked for destination trading.

I'll call the original ware A, and it's destination A'. What we do if check to check all other in-transit wares B of the same type as A. If A is closer to B's destination B' than B is and B is also closer to A' than A is, we send A to B' and B' to A. Then we flag both A and B to be checked again for destination trading. (Probably the distance comparison would use uncongested travel time.)

This would eliminate the roads jammed with the same ware heading in both directions, which are currently a common sight in the game.

MILITARY DISCUSSION

Currently, as soon as a military building loses a unit, a replacement unit is sent if available. This unit may be coming from the other side of the board. You're actually much better off if you have almost enough units to fill your buildings, but not quite enough, because then by lowering staffing levels on nearby buildings, you can get replacement units to the building that is about to be destroyed quickly. On the other hand, if you are severely understaffed, the replacement units will rush off to fill buildings on the other side of the board that have no need for new units at this time.

In any case, the user interface is very clumsy. What we WANT to do is to get a replacement to the building under attack as soon as possible. We DON'T want to be fiddling with occupancy levels all over the economy, until the idiotic AI finally agrees to do what we want to do.

The way I would implement this much more straightforwardly is to have a unique priority number for each building. When a new building is built or a building is attacked, it is bumped to the top of the priority list, and this number can also be changed manually. Warehouses get a the lowest priority. Training buildings get the highest (though only for trainable troops) by default, though this could be configurable. When a military building loses a unit, one is the sent from the nearest military building/warehouse with a lower priority. The highest level unit available is sent. This building then attempts to replace its unit. This system would leave the oldest, lowest priority buildings with only one troop in them when there is a shortage of available troops.

When a building is full, it would upgrade its lowest level troops one at a time by finding the nearest lower priority building which has a troop of a higher level, and having that troop travel it, and releasing its lowest level troop. The lower level building would then replace the troop it lost, as normal.

I would actually prefer to not have troops be able to be in warehouses at all, and to have their production from wares by warehouses take significant time, but that's change isn't required in order to implement a military building priority system. Also, under the current system in which injured troops recover their full health almost immediately, injured troops should do nothing other than to stay in their current building whenever possible.

Top

Quote

Lobsterninja: will you update the blueprint according to the discussion here?

Top

Quote