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