I think I've got most of the rendering-speed improvements I'm going to get without activity-level changes. Here's how it breaks down:

* 26% of the total time is spent in display.flip now (likely only possible to optimise that by reducing window size or something changing in SDL/Pygame, either is possible, but I'd prefer to give kids as much "overview" as possible (changing size is easy, and at 800x600 percentage goes to 13%, it's just annoyingly small at that size), and we probably can't get too much more out of SDL as long as it has no hardware support),
* 5% in the rendering code (1.5% is spent in the actual blitting of images),
* 2.5% in the simulation code (1.7% of that is packing updates, that should be reducible somehow),
* 2% in (GUI) event-processing (might speed that up with a binary search tree or even a straight coordinate-round-and-lookup)

The rest of the time is spent in a wait function that throttles to 15 FPS. On my (rather powerful) workstation that's 62% of total time for the one processor. That is to say, multiply the percentages above by ~3 to get their relative weight in real work being done.

[Update] Yay! Performance on the B4 as a client is perfectly fine. Haven't tested as a server yet, but the load for the server is pretty minimal, so I don't anticipate too many differences there. Next up is getting game definition transmission (and setup) and game store/restore/checkpointing working.

Part of that is dealing with "user left" events so that people can decide to either continue (potentially migrating the server) or just exit and store the state (likely checkpoint the "someone left" point anyway to let you go back just in case).