On Thu, 17 Jan 2013 01:45:19 AM Pedro Rodrigues wrote: > Would it be possible to share those scripts? It would be a good starting > point for my own changes.
I was afraid you were going to ask that. They are pretty embarassing ATM. I will clean up and document them shortly. > Regarding the starting configuration, which parameters do you consider > important? Difficulty level is pretty obvious. The ruleset even more so, but I only test the freecol set ATM as it is a superset. The shape of the map has a large influence. I like to get in at least 10 runs for each test configuration, and occasionally do 20, but cut the games off at 1700. ATM each run of 10 games takes about 4 hours, which means I tend to start the following in the late evening: 1. `Small' map, default map algorithm, Very Hard difficulty, 10 games 2. Caribbean map, Normal difficulty, 10 games <and now it is morning again, so I can see if the patches in the overnight run caused a regression, perhaps allowing a checkin before going to work> 3. Robustness run with 0.9.x game 4. Robustness run with 0.10.0 game <and now I am back from work> The robustness runs load the game, play 1 move, save, quit, repeat until 1700. This is hard on the AI's ability to plan, but they are good for shaking loose serialization problems. A pretty small test set alas, but repeatability is vital. > MockPseudoRandom is a subclass from random, OK, you are right, I am ignoring the test suite. Matter of taste. IMHO the test suite should not be too entwined with the program it is testing, so I do not like to let it influence the main code much. Tail wagging the dog. > a sync of the > existing client and server classes could also have been easier with this > architecture, i believe. Actually part of the point here was to make sure that the client *never* does any (game changing) random number generation. Having done that, any routine that takes a Random can now be moved to somewhere in ..../server. We have more urgent issues however. > Looking at the 0.9.2 release (the last stable one with PseudoRandom), i see > that the implementing classes (one for the server, one for the client) used > several different RNG methods, which could be one cause for such problems. > > However, i must admit i didnt touch that code ever, so i may be > over-simplifying the issue More like over-complicating it with respect to where we are now! The client routines are *gone*. Hooray! All RNG happens in the server... oh yeah, there is also the test suite:-). >>[Can FreeCol be fully deterministic?] > > That was my expectation with passing a starting seed to freecol (not > tested), sorry to hear it wont work. Well, its not completely impossible. We could do it by rewriting the c-s message passing to not use a new thread for each interaction. FreeCol is structured so that the clients can make independent and asynchronous requests to the server. This is generally a good thing, especially for performance. Unfortunately for determinism, some requests call the RNG, so if thread A runs slightly faster than thread B you get one result, and if B is faster than A, you get another. So another way of fixing it would be to hunt down all the cases where an AI fires off a request that calls the RNG but does not wait for the result but goes on generating more requests. At least now that AIs have their own RNGs (seeded from the server) they can do their own random-decisions without influencing each other. It is just the gameplay decisions in the server that can be raced for. Now, we are going to rewrite the c-s message passing, because we want to get rid of DOM. But that keeps getting put off. What we really need to be working on are the Bugs and Pending Features trackers, with the aim of releasing 1.0. Cheers, Mike Pope ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
