Much more needs to be written so that students can start coding right away.

Write a client implementation example where studens define their own subpackages and use absolute imports to avoid name clashes during tournament or local games. Something like:

student_git/my_player.py
student_git/utils/ _ _ init _ _ .py
student_git/utils/utils.py
etc...

where my_player.py is the file that you have to run to start a game.

pelita should be regularly tested on (at least) WindowsXP, Windows Vista, Windows 7, MacOSX (Snow Leopard and Lion?), Linux (Debian unstable).

Expose the noise parameters of the UniverseNoiser class, noise_radius and sight_distance. One idea is to add them as keyword arguments to the GameMaster.

Right now TkApplication.read_queue has a poll timeout of 50ms: this effectively makes the tk viewer much slower than it could be. setting it to 10 or even 5 ms makes the visualization much faster. Best would be to have it configurable has maximum_framerate, so that you can dinamically set it.

Currently, all serialisation checks are done immediately before sending the message.
As the sending of messages is done in a separate thread, there is no way to inform the sending thread that something did not work.
Serialisation should therefore be checked inside ActorReference before the sending of objects (and maybe we should even convert them already there, and restrict the messages which are handled by JsonSocketConnection to strings).

The introductor screenshot does not display nicely on 1024x768 laptop screens, make it smaller!

This is probably very complicated and may not be worth the time invested. But one possible solution to the timeout problem[*] would be to run every get_move in it’s own thread, having some kind of advanced data structure in the background to deal with synchronisation and sharing issues. If a thread does not return in time, it is simply abandoned (not killed) and a new thread is started and relevant information copied.

[*] The timeout problem occurs when a client does not want to return in time and still runs even when the next round should have been started.

This description was removed with: c6ccd85

Re-introduce this when the new documentation goes online. Put it in the development section.

Sometimes the BasicDefensePlayer just stands at the border and does nothing. More so with the new mazes.

we need to inform the user that a player has caused a timeout. Perhaps by writing big red letters onto the screen.

in spite of being correct, the layout descriptions in the user docs are way too detailed. thre's no need for the user to know that the layouts are stored in __layouts.py and in which way we autogenerate the names. there's not even need for them to know that we have text files ase input. They can get all layouts with get_available_layouts, that should be anough of an explanation. The section where it is exlained how to manually create a layout in a sting or in a text file is ok.
it would be a pity to throw away this documentation, which I think belongs somehow in the developers documentation, which we don't have right now.

Right now when the maximum number of rounds has been played, no one wins. The team with better score should win.

def f(a): pass
f(**{u'a': 1})
TypeError: f() keywords must be strings

Happens at least on the Python 2.6.1 default on Snow Leopard. The above construct is unfortunately needed quite often with the json serialisation code.

the tk interafce should display the name of the layout, for example the file name or the variable name

The timeout mechanism for players must be documented. How long do they have to compute, what happens if they go over that time and how to detect if that happens.

like this base64.b64encode(zlib.compress(json.dumps(obj, default=self.encode)))
factor 25 for a maze 20x5.

Add 'say' command for debugging and fun

Add a property returning the direction in which the agent is moving

The documentation for these two is out of date in the sphinx docs. This must be checked and brought up to date.

The maze name or origin (file, string?) should be displayed in the viewers. In the TKViewer preferably in the lower left window, opposite the turn/round info.

Some of the demos in demo don't seem to work properly. They should be checked.

Please be careful.

Tk code is not nice and might have some performance issues as well. Needs more polishing and cleanup of unused parts and a better handling of canvas items.

Got SIGINT. Exit!
Got SIGINT. Exit!
Traceback (most recent call last):
File "./run_game.py", line 19, in
server.run_tk()
File "C:\cygwin\home\berkes\pyschool\pelita\pelita\simplesetup.py", line 205,
in run_tk
self._run_save(main)
File "C:\cygwin\home\berkes\pyschool\pelita\pelita\simplesetup.py", line 172,
in _run_save
self.server.join(3)
File "C:\cygwin\home\berkes\pyschool\pelita\pelita\messaging\actor.py", line 3
47, in join
return self._actor._thread.join(timeout)
File "C:\Python26\lib\threading.py", line 655, in join
self.__block.wait(delay)
File "C:\Python26\lib\threading.py", line 258, in wait
_sleep(delay)
File "C:\cygwin\home\berkes\pyschool\pelita\pelita\utils\signal_handlers.py",
line 33, in keyboard_interrupt_handler
exit_handler()
File "C:\cygwin\home\berkes\pyschool\pelita\pelita\utils\signal_handlers.py",
line 29, in exit_handler
os.killpg(os.getpgrp(), signal.SIGTERM)
AttributeError: 'module' object has no attribute 'killpg'

zbyszek@ameba ~/python/pelita (git)-[develop] % python demo.py
No handlers could be found for logger "pelita.threading"
Trying to establish a connection with local actor 'pelita-main'...
Starting actor 'pelita-main'
Trying to establish a connection with local actor 'pelita-main'... ok
ok
^C
Server received CTRL+C. Exiting.

Pressing ^C again has no effect.

Kill $PID works.

The number of rounds, i.e. the game time is not exposed to the players. We should refactor this so that it is stored in the universe instead.

To avoid changing the items in the actor queue, we must deepcopy (or serialise) every item before placing it there so that there are no references to it which may change the queue.

Currently, there is a problem when applying deepcopy on a socket connection. The connection is copied all right but there is a problem with closing it afterwards. This needs to be investigated before.

Students should use the command line interface. We should update the documentation to refelct this fact.

The maze.has_at method is deprecated in favour of Free in maze[0,1]. Refactor the tests and rest of the code to use this api instead and remove has_at.

update UML diagrams (sequence and class) to refelct the actual implementation

There are two scripts to commit docs to the gh-pages branch on github: commit-doc.sh and commit-doc-tree.sh. I suggest to delete commit-doc.sh and rename commit-doc-tree.sh to commit-doc.sh. The tree one is much more elegant. Also the tree script will need at least a string about what it does.

The documentation about this should move from README.md to Sphinx.

property that returns True when the agent starts on left side of maze:
useful for example in:

    forbidden = west if self.on_left_side else east
    if self.maze_nodes[pos] in self.border_nodes and action == forbidden:
        return stop

Currently the 'Game Over' text is just printed onto the canvas. This looks a bit unprofessional. Ideally we want a white outline, 3-D or a faded background. At least something that looks a bit better.

The torunament should be able to run in fully automatic mode. We'll probably need to write a python script (and not a shell script), so that we can leverage import semantics. Think about client isolation (each client on a separate process) and client crash (server should not be affected).

commit-doc-tree.sh should check which sphinx version was used to generate the docs the last time, and abort of the current version of sphinx is older than the previously used one. One way to do this, is to write the sphinx version to a file and read that file upon generation.

See also: https://github.com/Debilski/pelita/issues/26

we have to remove references to pacman-specific terms in the docs. For example, in the start page we have:
"In its own half the bot is a destroyer (equivalent to a ghost). In the enemy half, the bot is a harvester (equivalent to a pacman)."
There's no need to say that a destroyer is "equivalent" to a ghost. What does it mean "equivalent"? Most users will not know where we are coming from.

In our first design (look at feature/bottleneck branch first commit SHA: 3e747b2), every position in the 2-D Maze would contain a TypeAwareList of instances of MazeComponents (Food, Free, Wall). While this gives extreme flexibility, it also turned out to severely slow down the deepcopying of the Maze, which is needed when we send the universe to the players. The game was basically not playable on a realisticly sized layout. We didn't notice that before because we were always testing on small layouts.

Just using strings instead of objects as an internal representation (SHA: 185d7ed) already makes the game something like 30-times faster. Using a multicharacter string instead of a list (SHA:???) gives another 2/3-fold speed increase.

This is all good, but the Maze now has an inconsistent API, that coudl lead to confusion. On the one hand, you access the MazeComponents with a OO interface (Maze.pos_of, Maze.get_at, Maze.remove_at, Maze.has_at). On the other hand, just accessing Maze values, like in Maze[0,1], would return the string representation of the MazeComponents.

We agreed that the string representation should remain an internal implementation detail of the Maze class, and that access to the Maze should be mediated by an OO API. The question is what API?

Code exists already (game over text), should be generatlized for top and bottom menu.

The end of game string (draw or win) has two issues that need to be resolved:

• The font is hardcoded, this should perhaps be a function of the window size
• The string is always displayed in full length. This should be reformatted to [...] depending on how many characters fit on the screen.

in the docs, we need to define what manhattan distance means ( I personally prefer either "l1 distance" or city block distance) and make clear (maybe with a smal cartoon?) the difference with the distance on the maze (which takes into account walls and other obstacles).

Currently, unknown json of the form

{"__id__": "pelita.json.someclass", "__value__": some_serialised_value}

is left unparsed, i.e. it is returned as a plain dict. This may lead to subtle bugs. On the other hand, blocking on wrong "id" values may lead to false negatives.

sometimes the eyes of the harvester are upside down

The tk interface currently has destroyers animated as pacman with yellow eyes. A ghost character would be better.