Re: [simspark-devel] Timer

[Hedayat V. <hed...@ai...>]

Hi Sander,
Just some notes (maybe not directly related to the main discussion; 
sorry for that):
1. It is possible to make running full 6 vs 6 (or more) games possible 
for everyone without a new timer: the proposed Sync mode (in which the 
simulator will proceed to the next cycle when all of the connected 
agents tell it to do so) could enable teams to run games on any system 
successfully. This could be at least a temporary workaround while we do 
not have a new timer.
2. The latest code is less sensitive to small network delays than 
before, and it is more fair.
3. IMHO we should not desire strictly equal conditions for all teams 
during the whole game; since it doesn't happen in real world too. Small 
hardware/network delays and other such things might happen in real 
robots too. However, these should happen really "random" with the same 
probability for both teams. It should not affect one team more. I'm not 
sure if it needs a new timer; if the simulator could provide some 
advantage for one team during a game, it is probably a bug somewhere in 
the current code, or in the game cluster setup.
So I think the timer should be fair, but it does not necessarily mean 
that all agents should always receive exactly the same thinking time. 
The thinking time could vary during the game, but it should happen for 
both teams almost equally.


Thanks,
Hedayat


On ۰۹/۱۱/۲۵  05:43, Sander van Dijk wrote:
> Hello fellow 3D-ists,
>
> During the competitions in Graz this year we discussed the future of 
> our league in the roadmap discussion (see Sahar's mail on the 3D list 
> from 24th of July for a full summary). The most important point was 
> that next year we want to double the amount of players and play 6 vs 6 
> games. There is already good work under way to make this possible 
> (e.g. multi threading (Hedayat) and possibility for different (maybe 
> faster) physics engines (Andreas, great stuff!)). However I think the 
> most important thing (I even think crucial thing) is missing: a good 
> timer.
>
> There are 2 reasons I think this needs high priority:
>
> 1. To have fair games. The last few years there was already some 
> discussion about fair timing. Especially in China things seemed to go 
> wrong, where in the same game one team seemed to be more affected than 
> the other team. With more agents this will only get worse, especially 
> I expect when we throw more computers into the mix (multiple computers 
> per team for instance). There is an argument that can be made for 
> limiting the think time by real time and hardware constraints, but at 
> the moment it is too uncontrolled. With network traffic, thread 
> scheduling, et cetera, the amount of processing time an agent gets is 
> basically random and some agents/teams may be disadvantaged.
>
> 2. To have reproducible games. Hereby I don't mean that games should 
> be deterministic, some noise is needed (though again, in a 
> controllable way), but games run on one system should be representable 
> of games played on another system (and especially on the same system 
> at a different time). Herein also lies the reason I think a better 
> timer is crucial and even more important than the other improvements 
> being made:
>
> � Without a good timer teams may not be able to prepare for the 
> competitions, especially if they don't have access to a cluster of 
> high end machines like we will hopefully have, simply because they 
> cannot play full 6 vs 6 games that reflect games at the competitions.
>
> So what I think we need is a timer that gives each agent the same, 
> predetermined amount of processing time for each time step. This 
> possibly reduces simulation speed to less than real time, but at least 
> anybody then can run a full match on any system and all other 
> improvements become less pressing if you only consider ability to play 
> a game (but of course in the end we do want real time). In Austria we 
> said 'don't complain if you don't contribute' and I would like to go 
> ahead and implement something like this, however I am missing the 
> time. But hopefully I convinced you that this is one of the (if not 
> *the*) most important issue for next year and I can put down some 
> points to perhaps guide to a solution:
>
> - We used to have a system which did mostly what I said above: the 
> Spades middleware system [1], however it didn't make the transition 
> from spheres to humanoids in 2007. What was the exact reason, does it 
> have unwanted properties or is it a lack of knowledge about it? I 
> think Joschka can shed some more light on this probably?
> - What properties do we want the timer to have? Do we want to limit 
> CPU cycles which might give teams using e.g. Java a disadvantage 
> compared to assembly hackers, or computation time which might make the 
> timer still too machine-specific..
> - How does timing in the 2D simulation work, can we learn something 
> from that, or even just copy it?
> - And most important: who will work on this?
>
>
> Cheers,
> Sander
>
>
> [1] http://spades-sim.sourceforge.net/
>
>
>
> -- 
> Adaptive Systems Research Group
> Department of Computer Science
> University of Hertfordshire
> United Kingdom
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>    
>
>
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>