Latest Posts

Topic: main roads becoming normal again

Tibor

Joined: 2009-03-23, 23:24
Posts: 1377
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2018-04-25, 13:22

ypopezios wrote:

king_of_nowhere wrote:

There's a reason this issue was never takled in the thrree years since I raised the issue: once you start checking the requirements, it opens a can of worms.

Apart from lack of developers, the only other reason was the bad model. Incorporating advanced requirements in it, is simply impossible. And incorporating everything at once is even more impossible. But strong models (and determined programmers) are not afraid of worms. And they have proven their effectiveness in critical software for real-life environments, which are much much harder to deal with than the limited predictable environment of a game.

in fact such critical real-life software can be few orders of magnitude simplier than game like this...


Top Quote
ypopezios
Avatar
Joined: 2018-04-20, 00:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-04-25, 14:02

Tibor wrote:

in fact such critical real-life software can be few orders of magnitude simplier than game like this...

Whether you like it or not, Widelands is a relatively simple system. For sure more complicated than the average game, still just a toy in comparison to software I have worked with. But this is enough, it's obviously a waste of my time to talk about such things here. You don't have to agree with the theory behind the algorithm. Just give it a chance to see if it works in Widelands.

EDIT: To be fair, the AI part of games like Widelands has the potential to be as complicated as real-life software. But its implementation is usually of average complexity, which justifies its poor performance. Still the rest of the system is relatively simple.

Edited: 2018-04-25, 14:35

Top Quote
Tibor

Joined: 2009-03-23, 23:24
Posts: 1377
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2018-04-25, 14:14

I am just curious - that complicated software was written in Java?


Top Quote
ypopezios
Avatar
Joined: 2018-04-20, 00:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-04-25, 14:47

Tibor wrote:

I am just curious - that complicated software was written in Java?

It's not a matter of language. Any Turing-complete language can be used to write the same things as any other Turing-complete language. Usually the choice of the language for a particular project depends on the available libraries for it. But many other factors should be considered, like hardware performance, which is very applicable to real-time games like Widelands. As a general rule, the more complicated a software is, the higher level of language fits with it. C++ is low level, Java a little higher than that, Lua higher than both, and so on. Can we now return to this thread's topic?


Top Quote
Tibor

Joined: 2009-03-23, 23:24
Posts: 1377
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2018-04-25, 14:53

One of disadvantages of game like this is shortage of test and metrics.

For example:

You are working on road algorithm - fine. But if it was "real world" software we would have a test /metrics measuring road performance (average delivery time or something like that...) . And we would have some "performance test" with current code and after your change. And exact numbers would say if you change is indeed improvement.

But as this is only the game, it is enough to convince enough shareholders that the fix is improvement and it will be accepted.

EDIT: I wrote this post before seeing the above post...

Edited: 2018-04-25, 15:00

Top Quote
ypopezios
Avatar
Joined: 2018-04-20, 00:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-04-25, 15:24

Tibor wrote:

One of disadvantages of game like this is shortage of test and metrics.

If we decided to, we could implement all kinds of tests and metrics inside the game. And we could even feed them back to the game, making it take better decisions (or even update its algorithms on-the-fly). But metrics can be heavy for both CPU and memory.

Tibor wrote:

You are working on road algorithm - fine. But if it was "real world" software we would have a test /metrics measuring road performance (average delivery time or something like that...) . And we would have some "performance test" with current code and after your change. And exact numbers would say if you change is indeed improvement.

Theory and practice have to go hand-by-hand as much as possible. None of the two is enough on its own. Printing some numbers will help us confirm theory more than any test could do. But after that stage, testing should certainly take place, to test the completeness of the algorithm, i.e. edge cases. If testing discovers missing things, playing with constants isn't the right approach. We should go back to theory, revise it to consider the missing things, then go again through the rest of the stages. This is one aspect of how quality-software is developed. Concerning the suggested change, if we wanted hard proof that it is an actual improvement, we could design special test maps and scenarios to directly compare the two builds. But I can guarantee that the improvement will be observable in "naked eyes".


Top Quote
Tibor

Joined: 2009-03-23, 23:24
Posts: 1377
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2018-04-25, 16:23

In serious software you dont need to add hooks into code, but can use http requests, command line communication, db queries and whatever. This adds freedom to testers and testing.

The game like this has only GUI that is impossible to test properly. Until the test will be able to recognize what is going on the screen - though we are not far from that due to advances in AI I believe....

But enough, if you will be able to implement serious performance measuring of impact on overall game (will be strongly dependent on type of a map) it would be great...


Top Quote
ypopezios
Avatar
Joined: 2018-04-20, 00:22
Posts: 220
Ranking
Widelands-Forum-Junkie
Posted at: 2018-04-25, 18:00

Tibor wrote:

In serious software you dont need to add hooks into code, but can use http requests, command line communication, db queries and whatever. This adds freedom to testers and testing.

In serious testing, you need to be as close to the real thing as possible. Queries of any kind are less reliable, unless the game freezes during them. Not to mention that queries are merely a parameterized hook. You are right about the "freedom to testers" part, but testers don't consist the center of the software universe. It would be nice if we had all kinds of measurements in Widelands, but we certainly don't depend on them. The fact that you are more familiar with a powerful tool, doesn't mean that it has to be used in every occasion. There are simpler tools that can do the job just fine. Implementing queries in Widelands is fully possible, but it would be an overkill.

Tibor wrote:

But enough, if you will be able to implement serious performance measuring of impact on overall game (will be strongly dependent on type of a map) it would be great...

We can start with simpler things, like two warehouses connected with a variety of roads, having them transfer wares to each-other. If the improvement there is not enough to convince someone (which I doubt), we can design more complicated things, up to full maps. We are not as limited as you make it sound. At this point there is another thing that worries me. Have you realized what is wrong with the old algorithm? Or are we talking here about fuzzy improvements which are beyond perception?


Top Quote
Tibor

Joined: 2009-03-23, 23:24
Posts: 1377
Ranking
One Elder of Players
Location: Slovakia
Posted at: 2018-04-25, 18:22

In testing you need data. Widelands provides close to none. Printf are fine for development and some limited testing only.

When working on AI I had worked on many great improvements that at the end had minimal impact on overall performance. Moreover the AI can provide at least some absolute metrics (size of territory, number of soldiers and few others), here it will be difficult to come with some overall metric....But partially we can measure transportation time of individual wares as you suggested. Or we can measure number of wares being transported (the lesser the better). Or number of full flags.... Or number of carriers unable to transport because target flag is full....

In fact I dont care about this algorithm change, but there are guys who understand it and discuss it. For me it would be nice to see some overall number confirming that the fix improves situation, but if not - I will not oppose the merging if all other will be satisfied..

EDIT: Also input queues on productionsites works as buffers against traffic slowness, so this also must be considered when evaluating the speed up from the fix...

Edited: 2018-04-25, 18:26

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

Tibor wrote:

Printf are fine for development and some limited testing only.

Sure, we are still on development. The numbers we need for this stage are not to show the performance of the algorithm, they are just to see if the code works as expected, i.e. if the variables have the expected values, especially those coming from other files.

Tibor wrote:

When working on AI I had worked on many great improvements that at the end had minimal impact on overall performance.

There are many times when small improvements have a big impact after they get combined with other small improvements. If those improvements are great, they are worthy to have. With future improvements, they will finally affect performance. Of course this is a general idea. But if we finish with this small change, we could go through some of your AI stuff and give you some insight, if you feel like that.

Tibor wrote:

But partially we can measure transportation time of individual wares as you suggested. Or we can measure number of wares being transported (the lesser the better). Or number of full flags.... Or number of carriers unable to transport because target flag is full....

All those are good. We don't need all of them for a conclusion in this case, but they don't hurt either.

Tibor wrote:

In fact I dont care about this algorithm change, but there are guys who understand it and discuss it.

Where are those guys and those discussions? Why not on this thread? Or are they waiting to see the final thing before appearing?

Tibor wrote:

For me it would be nice to see some overall number confirming that the fix improves situation, but if not - I will not oppose the merging if all other will be satisfied..

I could provide you with number confirmation, as long as you give me your definition of what consists improvement in this case. Cause since you don't care about this algorithm, I suspect that you don't fully understand the involved improvements.

Tibor wrote:

Also input queues on productionsites works as buffers against traffic slowness, so this also must be considered when evaluating the speed up from the fix...

I'm not sure if this affects the algorithm. Unless a full buffer didn't stop requests, it is kind of irrelevant to traffic, cause nothing is routed there anymore.


Top Quote