On Thu, Jan 17, 2013 at 12:34 PM, Michael T. Pope <[email protected]>wrote:
> 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.
>
LOL, cool,thks.
Also thks for the more in-depth description of your AI-testing routine.>
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.
>
Agreed that the test code should not be too entwined with the program it is
testing (which is why using Interfaces are a good common ground).
Disagree on not letting the unit testing influence the design of the main
code; from my experience doing so tends to lead to better code since it
forces less monolithic, more modular code that minimizes coupling and
duplication and encourages small classes/methods with single responsibility
(as it greatly helps to create tests as well).
>
> > 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:-).
>
Those last design comments were about the 0.9.2 codebase; which im still
more familiar with (even the parts i barely if ever touched), given all the
time i spent away. Having simplified the design was indeed a great
accomplishment.
However, its still my opinion that the removal of the PseudoRandom
interface and use of Random (and subclasses) directly is a mistake (for all
the reasons already given).
> >>[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 [...]
>
Meant as of right now, as a way to test changes to the AI, by running both
codebases and comparing results.
Not being possible to reliably reproduce a game progress from a standpoint,
we are left with the approach you use, that of running several games and
analyzing the results from an average perspective (which is costly in time
and not too accurate).
But i can work with that.
> 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.
>
Agreed.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/freecol-developers
