Yes, that code would have to be changed, but I don't think that will
affect the rest of the system. Turning code like

  for peer_id in range(1, self.num_players + 1)

into just

  for peer_id in range(self.num_players):

would be nice, and storing things like the Player and ShareExchanger
objects in lists will also be nice.

The only problem I see is that the Runtime does not currently know how
many players there will be, and some things are built incrementally in
a random order. For example, players connect to each other in random
order and so BasicRuntime.add_player is called in random order.
Teaching ShareExchangerFactory.identify_peer to stop doing that would
probably not be too hard.

Some parts of the code will get more complicated with ids ranging from zero to
n-1, since zero cannot be used with the current shamir interpolation method. But
the simplicity gained by changing to zero based ids might outweight this :-)

Players are currently numbered 1, 2, ..., and while this is natural from
a users perspective, it makes much of the code more complicated than
necessary. This is because I chose to use the player IDs as indexes into
various dictionaries.

We should instead number the players 0, 1, ..., and then use lists
instead of dictionaries. That will make the code easier on the eyes.