Open xehonk opened 11 years ago
I had the server running faster, it was already implemented, yes. I will add a command-line-switch to do this.
The reason I took it out was that the Online Server I'm using right now is too fast and it would be moving trains too fast fast. With all that said - the server is running on a frame-based algorithm, just like the client, so it moves trains once a frame. If the speed is increased so much that a train can pass through an entire tile on the map then problems can start occurring, because then a train that's higher up in the list might move through two tiles when really it should've been blocked by the next train that also wanted to go to the same tile but is lower in the list, so it is moved later...
Thinking back the server should have been written in plain Lua and not in the engine, but I needed the thread ability that Löve offers and didn't want to reinvent the wheel. Other threading solutions didn't fit my needs.
I ran into that problem as well. I simply decoupled the length of a simulation step from the duration of the frame and eliminated all waiting - that way I get to 500ish matches within 10 to 30 minutes. (It takes about that many matches to get repeatable results.)
diff of main.lua:
199c199
< timeFactor = 1
---
> timeFactor = 1000
232c232,233
< dt = love.timer.getDelta()
---
> --dt = love.timer.getDelta()
> dt = 1/timeFactor
234c235
< countSeconds = countSeconds + dt
---
> --[[countSeconds = countSeconds + dt
238,239c239,240
< end
<
---
> end--]]
>
247c248,249
<
---
> timeUntilMatchEnd = 0
> timeUntilNextMatch = 0
291c293,297
< stats.generateChart()
---
> --stats.generateChart()
>
> if #aiList > 0 then
> log.matchResults()
> end
329,331c335,337
< if dt < 1/15 then
< love.timer.sleep(1/15 - dt)
< end
---
> --if dt < 1/15 then
> -- love.timer.sleep(1/15 - dt)
> --end
Wow, thanks for the diff! Then the only problem left is that trains that are higher in the list will always have an advantage. I cannot think of a simple way to solve this, though. I could simply not allow the trains to pass into the next tile, but each one might need a different time until it has reached the next tile... and so each train would run for a different time, which would make the game very, very complicated.
With my diff above, the trains always go the same distance, no matter what the timeFactor is (which pretty much makes the timefactor useless ;p)
Anyway, it's easiest to make the distance a train travels each step constant (and for best performance as large as possible without introducing problems) instead of depending on the elapsed time. My idea was just to remove all sleeps from the codepath and pretend that each frame takes a certain time (say 66ms) anyway. That'd avoid problems in the simulation while still running as fast as the pc could handle.
are there any updates on this ?
Related comment from hajo4, posting here for reference: "This would be a combination of "challenge" and "random": choose one map, then for each AI from the ai-folder, make a number of runs on this map. (Interactive: wait for user to press "reload" / "next AI", Automatic/fixed number: 1,2,3... runs for each AI, then auto-advance. ) Maybe with option to auto-"speed up" all the runs.
Log results into a text-file, e.g. min/max/avg. time, trains bought, passengers delivered/remaining, etc. Also, log of error-messages.
This could be used for ranking all the AIs, i.e. see their performance (time/passengers/money) on a certain map (e.g. TinyTown1).
Also, to find bugs."
For comparing different AIs, single games are pretty useless (there is huge variation from game to game).
Please consider creating a server-mode that just runs matches as fast as possible and logs to a file/db. (It should be possible with the current code without too much work, I was able to hack something together for my own usage.)