[simspark-devel] Timer

[Sander v. D. <sgv...@gm...>]

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