Latest Posts

Topic: main roads becoming normal again

kaputtnik
Avatar
Joined: 2013-02-18, 19:48
Posts: 2441
OS: Archlinux
Version: current master
Ranking
One Elder of Players
Location: Germany
Posted at: 2018-04-20, 22:28

ypopezios wrote:

I'm on windows myself and not willing to install a virtual box for C++, nor to write actual code without debugging it.

It's always the same: From time to time some one explore widelands and get ideas to make it better. This is good, and all will participate from such ideas.

The ball is no more on my field, sorry. By the way, if such a small change is too much for the active developers of Widelands, we may as well abandon all hope for any changes whatsoever.

In the end the person who has good ideas is frustrated, because his idea(s) didn't get implemented in a short time.

If i count right there are 58 open bugs for build 20. And there are only two main c++ developers. I think no one can expect that a c++ developer will stop to work on already open bugs and start to work on a good idea (which may raise new bugs).

From my point of view all energy should be spend to get a new release. There are many things fixed and enhanced in the current development build, but there are a lot of other open bugs to solve. Working on a new idea have at least to wait until we have the new release, imho.

If a c++ developer is fond of a new idea, he may grab it and work on it. But there is no guarantee for this. The other way around is: Make it yourself. If you can't do that, or not willing to do that, you have to wait. If you are willing to work on your idea, you're welcome to ask every question and each developer will help. That's how OpenSource projects work.


Fight simulator for Widelands:
https://wide-fighter.netlify.app/

Top Quote
ypopezios
Avatar
Joined: 2018-04-19, 23:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-04-20, 22:53

I actually agree with everything said about timing. I never asked or even implied that the idea should get implemented in whatever short amount of time (although it's a fact that the specific change is small). But the obstacles raised so far had nothing to do with timing, so my frustration has nothing to do with it and I have to once again reject an unfair accusation. But it's too much having to defend the basics and on top of all that being accused about every imaginable reason, including my frustration for being treated like that. Maybe you are right, it was my fault to bother you, sorry.


Top Quote
king_of_nowhere
Avatar
Topic Opener
Joined: 2014-09-15, 17:35
Posts: 1668
Ranking
One Elder of Players
Posted at: 2018-04-20, 23:02

ypopezios wrote:

king_of_nowhere wrote:

it penalizes a road for working properly

Maybe you thought that the queue is considered after removing the ware. This is not the case. A carrier who takes a ware, always takes a minimum of 1 coin for it, plus some for the length of his road. Let me describe again the basic idea in isolation: As time passes, all carriers lose coins. But carriers who are not idle, get rewarded with coins for their work. Therefore, if the calculations for increasing and decreasing the wallet are chosen fairly, a properly working road will receive plenty of coins to avoid demoting indefinitely. Only underutilized roads will get bankrupt and demoted.

ok, then it may woek just fine. It would need playtesting, though. I am afraid of how much CPU it would consume on a large map, but that's not something I'm qualified to comment on.

king_of_nowhere wrote:

if the economy does not need pack animal, do not demote roads ever

It has already been explained somewhere else that it is a feature of the game to not use animals unless they are really needed. This is the reason they all stay in HQ in the beginning of the game.

Well the game's idea of "being really needed" is very different from mine.


Top Quote
ypopezios
Avatar
Joined: 2018-04-19, 23:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-04-21, 03:19

king_of_nowhere wrote:

Well the game's idea of "being really needed" is very different from mine.

Something is really needed when it can make a big difference. And an animal in a road can start making a big difference when the time it is used is longer than the time it is idling. But this information is not available in the current model of carriers, so the game tries to simulate it with a light algorithm, where the "magic" condition is "busyness > 500". Someone could simply reduce that number and promote roads sooner. Similarly, the new algorithm simulates it with the condition "wallet > (1.5 * animal_price)". Reducing animal price would again promote roads sooner. There is no perfect way of choosing those numbers. Since the two algorithms don't use actual measurements of road utilization, their definitions of when an animal is really needed are equally imperfect. The same is the case for when to release an animal.

The difference between the two algorithms is rather on how accurately they serve their imperfect definitions. The current algorithm does it through busyness, while the new algorithm does it through coins. Current way of calculating busyness is very simple, but also very weak, especially in an environment as variable as a dynamic transportation system. And I suspect that calculating busyness cannot be done in a way both simple and accurate. Calculating coins is almost equally simple. And I claim that it is very accurate.

king_of_nowhere wrote:

I am afraid of how much CPU it would consume on a large map, but that's not something I'm qualified to comment on.

The qualified answer is that the difference between the two algorithms in CPU consumption is really negligible. You won't begin noticing any difference in any map of less than ten thousand roads. But if you ever approach that point, other things will be delaying the game much more.


Top Quote
ypopezios
Avatar
Joined: 2018-04-19, 23:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-04-21, 05:09

There is another reason that the wallet model is superior.

Consider a problem which has been mentioned earlier in this thread, that of the promotion of a long road consisting of many segments. We like to think of it as a single road, that all of its segments should get promoted at the same time. But this is an illusion. Each segment may have potentially different traffic, cause each flag may get connected to more roads with variable traffic. In the effort to increase the efficiency of a long road, breaking it into segments is not a real solution, it is merely a hack (and all the intermediate flags spam the ground and limit the building options). The real (and also more realistic) solution would be to increase the number of carriers.

The thing is that the codebase supports any number of carriers per road, not just two. But good luck if you try to implement scaling promotions with the busyness model (even if the game starts supporting utilization data), cause you will have to define pairs of thresholds and checks for them for every possible level of promotion. And if later you'd like to add another feature that affects transportation, you'd realize that you have a maintenance nightmare. While if you follow the way of the wallet, you don't have to do anything, just keep accumulating coins and buying new carriers whenever you can afford them.

All in all, the wallet metaphor is not merely a superior model. By simplifying both the understanding and the calculations, it opens up new options for enhancing the game, in ways which were previously too complicated to consider. For all those options, the first step is the implementation of the wallet. Although Widelands' economies are designed without money, utilizing it internally makes perfect sense.


Top Quote
teppo

Joined: 2012-01-30, 08:42
Posts: 423
Ranking
Tribe Member
Posted at: 2018-04-21, 07:34

ypopezios wrote:

In the effort to increase the efficiency of a long road, breaking it into segments is not a real solution, it is merely a hack (and all the intermediate flags spam the ground and limit the building options). The real (and also more realistic) solution would be to increase the number of carriers.

Unfortunately, I must disagree. Emitting flags can be painful sometimes, since the flag itself removes building spaces from the map. Therefore, the player must sometimes choose between more efficient road and few more buildings, if the map is made in that manner.

I have sometimes made my main highways to mountains / other waste area just because of this effect. Adding more carriers makes this aspect go away.

Building a working transportation system is one of the challenges the player faces. If a segment could have infinite amount of cost-free carriers, one aspect of the game would be lost.


Top Quote
GunChleoc
Avatar
Joined: 2013-10-07, 14:56
Posts: 3324
Ranking
One Elder of Players
Location: RenderedRect
Posted at: 2018-04-21, 08:29

I am having problems with my development machine at the moment, so I can't paste the code right now to see if it compiles. If you want to experiment with this on Windows, this is what you can do:

  1. Download Bazaar Explorer, get the source code and create a branch: https://wl.widelands.org/wiki/BzrPrimer/
  2. There are ways to compile Widelands under Windows, but it does take some more effort than creating a Linux build: https://wl.widelands.org/wiki/BuildingWidelands/#building-under-windows

If compiling under Windows is too much bother, you can also push your branch to Launchpad and start a Merge Request. This will then trigger our Continuous Integration environment, which will mean that you will also get Windows executable files from AppVeyor: https://ci.appveyor.com/project/widelands-dev/widelands

I'm sorry you felt accused of something by me, I did write from memory, because I didn't have time to work through the code myself. If this subject is what you would enjoy working on, do go ahead and if it makes things better, we will include it in a future version.

Edited: 2018-04-21, 08:30

Busy indexing nil values

Top Quote
king_of_nowhere
Avatar
Topic Opener
Joined: 2014-09-15, 17:35
Posts: 1668
Ranking
One Elder of Players
Posted at: 2018-04-21, 10:32

In early game, when every resoource counts, those algorithms are good. And yes, I am also convinced of the superiority of the wallet model now. In later game, when producing pack animals is not an issue, I would just like more roads to stay promoted. So I definitely would add options to manually choose to promote roads, or to manually deactivate the demoting mechanism


Top Quote
ypopezios
Avatar
Joined: 2018-04-19, 23:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-04-21, 15:15

king_of_nowhere wrote:

I am also convinced of the superiority of the wallet model now.

I definitely would add options to manually choose

Glad to hear that I managed to communicate the merits of the wallet, especially after the initial kicks from the knee-jerk reactions. Manual options can always be added later and even get toggled per game, if all players agree on it (or if it's part of the scenario). After all, the creation of a strategy game is about providing strategic options on top of a decent simulation that takes care of the non-strategic details.

teppo wrote:

If a segment could have infinite amount of cost-free carriers, one aspect of the game would be lost.

This is rather a side-effect for special maps, not something the model should care about. And there are ways of re-introducing the said aspect without flags. But without noticing it, you hinted the best answer to your concern: All that is needed for the challenge to not go away, is for the carriers to not be cost-free. The challenge should be at the strategic level, not at painfully designing roads down to the tile level. Highways can be made expensive in other ways too. Placing flags is a counter-intuitive way, no matter how common it is in Widelands. It is also a nightmare for AI. Flags should be only on cross-roads (or stations for very long roads). We should think more in cost terms. With the proper cost, even changing the landscape to improve building options should be possible, enabling more strategies and also making more maps playable, including some randomly-generated ones. Back to reality, let's see if we manage to make a small improvement to the existing road-model, and later we can worry about revolutionizing it, by redesigning flags. Still my point is that the right solution for small improvements is the one that also facilitates later bigger improvements.

GunChleoc wrote:

I'm sorry you felt accused of something by me, I did write from memory, because I didn't have time to work through the code myself. If this subject is what you would enjoy working on, do go ahead and if it makes things better, we will include it in a future version.

As I wrote, no hard feelings. Everyone helps the way he/she believes that the ratio results/effort is worthy. Frustration has also its place in the denominator, but it should be of less importance. Therefore, I will consider if I should get more involved or not. I certainly enjoy writing algorithms more than coding C++... But for now I believe that I did enough to make this thread move a few steps forward, not just a few posts bigger.


Top Quote
teppo

Joined: 2012-01-30, 08:42
Posts: 423
Ranking
Tribe Member
Posted at: 2018-04-21, 20:12

ypopezios wrote:

And there are ways of re-introducing the said aspect without flags.

Such as? Promoted roads become wider and consume more space? Gold needed to pave the roads?


Top Quote