IDCG, второй подход к снаряду

Год спустя я таки за это взялся. [старый пост: http://snownoise.dreamwidth.org/159753.html]
Напомню, что идея здесь – сделать стретегию, в которой игроку приходится принимать решения на основе неполной, устаревшей и потенциально ложной информации.

А всего-то для победы над прокрастинацией потребовалось понять, что нужно не морочиться с графикой, моделями, C# и Unity, а взять python с Qt и ваять игру не в графике, а в клиент-серверном варианте.
То есть можно спокойно пилить логику, не уча при это ненужный (лично мне) C# и не заморачиваться, опять же, на дизайне и интерфейсе.
А для отладки логики пока можно использовать клиент из говна и палок :)
К тому же при такой реализации можно заранее предусмотреть роль мастера, который будет устраивать игрокам отдельное веселье :)))

Архитектурно я прихожу к тому, что в этой игре "всё есть файл". Ой простите, пингвин укусил. "Всё есть сообщение".
То есть вся, вообще вся информация, которую получает игрок и то, что он видит на карте это сообщения, доставляемые кораблями. Конечно, не всё он видит в своей очереди. Например, отчёт системы о делах будет показан при клике на эту систему (причем, это будут данные, актуальные именно на момент отправки отчёта). Иконка корабля на карте? Эта информация тоже пришла как сообщение, невидимое игроку в общей очереди.
Отдал приказ? От игрока ушло сообщение.
Корабль-разведчик открыл новую систему? На карте она тоже появится только посте получения сообщения!

Так что получается, что для того, чтобы хоть что-то, даже в минимальном запускаемом варианте сделать, нужно написать систему, которая умеет маршрутизировать и обрабатывать кучу писем. Ничего сверхсложного, на самом деле, главное препятствие - лень :)
Ну и разумеется, для нормальной отладки логики должна быть система отслеживания того, как всё это генерируется и ходит. Message Tracking.


КДПВ из Master of Orion 3.
Несмотря на то, что это самая провальная игра серии, я ориентируюсь именно на неё :)))