Menu
▾
▴
Re: [simspark-devel] Timer
|
From: Khashayar <kh....@gm...> - 2009-11-26 17:14:45
|
Dear Sander and Hedayat First of all I would like to mention the point that only 'fair games' as Hedayat said is not enough, and we need to do sth to reduce the disadvantages of our platform sensitivity to timing difficulties like network delays. I deeply believe that we do need a timer that gives each agent the same, predetermined amount of processing time for each time step in *any* (network / system) conditions. I remember this problem affected our team (Scorpius) greatly in Graz competitions, Although as Hedayat mentioned this small effect will take place for both teams during competition but because we hadn't handled it before (and it's really hard to handle!), that caused our agents to fall down in their Max speed of walking during the matches on server which had never happened on our systems before. Overall, i think that we should consider this (timer) problem even if it may seems fair or ignorable! On Thu, Nov 26, 2009 at 3:39 AM, Hedayat Vatankhah <hed...@ai...>wrote: > 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 lis...@li...https://lists.sourceforge.net/lists/listinfo/simspark-devel > > > > ------------------------------------------------------------------------------ > 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 > > -- Best Regards Khashayar |
