Separar el motor de "back-end" (que realiza un seguimiento del estado de la placa, recibe órdenes de movimiento de los front-ends, genera números aleatorios para resolver batallas, envía actualizaciones a los front-ends, se ocupa de guardar y restaurar juegos específicos, ...) desde los "frontales", que básicamente proporcionan interfaces de usuario para todo esto.
PyGame es una tecnología adecuada para un front-end del lado del cliente, pero podría implementar múltiples front-ends (tal vez un PyGame, basado en navegador, basado en texto para depuración, etc.) . El back-end por supuesto podría preocuparse menos por PyGame u otras tecnologías UI. Python está bien para la mayoría de los front-ends (excepto los que necesitan estar en Javascript, Actionscript, etc., si escribes front-ends para navegadores, Flash, etc ;-) y definitivamente está bien para el back-end.
Ejecute back-end y front-ends como procesos separados y comuníquese de la manera más simple posible - para un juego por turnos (como creo que es), XML-RPC o alguna variante aún más simple (JSON las cargas que van y vienen a través de HTTP POST y las respuestas a ellas, por ejemplo) parecerían mejores.
Comenzaría con el back-end (probablemente usando JSON para cargas útiles, como mencioné), como un servidor WSGI sucio (tal vez con un toque de werkzeug o similar para ayudar con mdidleware), y un cliente de línea de comandos de depuración simple como la suciedad. En cada paso, estaría enriqueciendo el lado del servidor (back-end) o el lado del cliente (front-end) evitando cuidadosamente hacerlo demasiado grande O cualquier "paso" simultáneo. No utilizaría tecnologías "pesadas" ni grandes frameworks haciendo cosas mágicas a mis espaldas (sin ORMs, Django, SOAP, ...).
Asegúrate de utilizar un buen repositorio de código fuente (por ejemplo, hg, o svn si sabes que lo harás solo, o bazar o git si ya lo conoces).
Gracias, me has dado mucho para seguir adelante ... – Evan
@Evan, de nada! –