Разделяет «внутренний» движок (который отслеживает состояние игрового поля, получает приказы о перемещении от фронт-эндов, генерирует случайные числа для разрешения сражений, отправляет обновления фронт-эндам, занимается сохранением и восстановлением определенных игр,. ..) из "front-end", которые в основном предоставляют пользовательские интерфейсы для всего этого.
PyGame - это одна из подходящих технологий для клиентского интерфейса, но вы можете реализовать несколько внешних интерфейсов (например, PyGame, браузерную, текстовую для отладки и т. Д. И т. Д.). Бэк-энду, конечно, может быть наплевать на PyGame или другие технологии пользовательского интерфейса. Python подходит для большинства внешних интерфейсов (кроме тех, которые должны быть в Javascript, Actionscript и т. Д., Если вы пишете внешние интерфейсы для браузеров, Flash и т. Д .;-) и определенно подходит для внутреннего интерфейса.
Запускать back-end и front-endы как отдельные процессы и обмениваться данными настолько просто, насколько это возможно - для пошаговой игры (как я полагаю, это), XML-RPC или какого-то еще более простого варианта (полезные нагрузки JSON) лучше было бы вернуться туда-сюда по HTTP POST и ответить на них, скажем).
Я бы начал с серверной части (вероятно, с использованием JSON для полезных нагрузок, как я уже упоминал), в качестве простейшего сервера WSGI (возможно, с небольшим количеством werkzeug или тому подобного, чтобы помочь с mdidleware) и простой командный клиент для отладки. На каждом шаге я бы тщательно обогащал серверную часть (серверную часть) или клиентскую (интерфейсную), избегая слишком больших ИЛИ одновременных «шагов». Я бы не использовал «тяжелые» технологии или какие-либо большие фреймворки, делающие магические вещи за моей спиной (никаких ORM, Django, SOAP, ...).
Убедитесь, что вы используете хороший репозиторий исходного кода (например, hg, или, может быть, svn, если вы знаете, что будете делать все это в одиночку, или базар или git, если вы уже знаете их).