Обсуждаем следующее предложение: Я так это понимаю:
1. Есть приложение "боевой модуль" (которое работает отдельно от dosbox), оно запущено у обеих сторон. БМы связаны отдельным tcp-коннектом.
2. Игра в начале боя выписывает данные в файл, допустим combat.in.
3. БМы читают файл и позволяют провести бой.
4. БМы выписывают результаты в combat.out, игра читает его, подставляет результаты боя и продолжается как обычно.

Всё правильно?

Да. Или даже более чем у двух сторон, чтоб можно было транслировать бой союзникам, например, но это лучше уже на моей стороне кнопочку "пригласить зрителя". В принципе все так.

Не очень понимаю специфику языка, на котором написан орион (vbasic, да?), но если удобнее файлами, можно и файлами, звучит гуд (я представлял, что можно встроить в код запуск внешней аппы, в которую параметрами полетят все нужные данные, а по завершению считать её return примерно в том же формате). Получить бы хотя бы минимальный интерфейс для обмена данными с игрой, а дальше дело нескольких месяцев переписать боевую часть на чем нибудь высокоуровневом, вроде питона или юнитей.

Нужен свой сервер, чтобы все БМы к нему подключались. Написан он на C под DOS (есть windows-версия, но патч 1.50 для досовской, чтобы работало везде, где портирован dosbox). Соответственно запускается ORION2.EXE внутри dosbox, который суть виртуальная машина DOS и не даёт доступа к winapi. В итоге чтобы запустить внешнюю программу, надо либо модифицировать dosbox, либо делать патч для windows 95 версии. Проще обойтись файлами. Экспорт сделать несложно, могу на днях. В виде json. Импорт чуть сложнее, надо смотреть код синхронизации, но принципиальных проблем быть не должно. По поводу питона или юнитей, у меня нет опыта написания игр на них, а у вас? Графика в орионе довольно изощрённая, не так просто её воспроизвести, даже если использовать оригинальные ресурсы.

Касательно идеи в целом. Мне кажется, что сам по себе боевой модуль был бы интересен, как отдельная игра. Выбираешь корабли (из списка или дизайнишь) и проводишь бой. Основной объём работ составит написание интерфейса и воспроизведении игровой логики. Что мешает начать это писать без импорта/экспорта?

На питонподных языках есть достаточно опыта (порядка 2-3 лет), если не брать во внимание, что я не заканчивал свои проекты (пилил игры особо их не продумывая с точки зрения геймдизайна, с уклоном в сторону написания фич, потом переключал свое внимание на что-нибудь новенькое.). На юнити тоже не составит труда перекатиться. Про графику уже задумывался, вроде там были наработки еще со времен заброшенного ремейка ориона, думаю можно будет воспользоваться их трудами, если не получится, не думаю, что у меня возникнут непреодолимые сложности с расшифровкой формата.

Начать писать ничего не мешает, в принципе, так и планировал сделать, но для начала хотел прощупать почву, можно ли будет организовать взаимодействие всего этого супа с игрой, я это точно в разумные сроки осилить не смогу. В отрыве от основной игры мне боевая ее часть не слишком интересна, я руководствуюсь в основном практическими целями, такими как предоставить в мультиплеерные партии дополнительные удобства для играющих, возможности опционального подключения новых механик, и выноса логики ИИ в тот же lua.

В json идеально, да.

Что-то есть тут, не знаю насколько рабочее. Принципиальной проблемы быть не должно конечно, формат известен. Сложность в алгоритме рисования масштабируемых элементов (стеллары, трактора, лучи), остальное простая анимация. Пример экспорта пришлю на днях. Если вы в самом деле сделаете работающий боевой модуль, то импорт тоже сделаю. Ну и по механикам могу подсказать.

Ок, тогда буду ждать примера экспорта в этом топике. Сюда же закину адрес репы, когда будет на что смотреть. И по механикам, я думаю, можно будет тут же обсуждение вести.

Загрузил файлы, combat.json и SAVE1.GAM

Джейсон немного избыточный, чтобы не фильровать. Структура верхнего уровня такова:

combat_info
Глобальные переменные боя.

combat_ships
Таблица пар ship_id, ship (это id боевого корабля, которому соответствует глобальный с айди overmap_ship).

config
Содержимое конфига, для справки по мощности оружия и т.п.

players
Таблица пар player_id, player, там свойства игрока, включая таблицу techs, где пары tech_id, tech_status. tech_status = 3 означает, что тех известен данному игроку.

Edit: корабль-планету с айди 0 следует пока игнорировать, для её обработки информации недостаточно. Главная проблема в том, что планету можно бомбить во время боя, поэтому нужна не только информация о защитных постройках, но и вся вообще информация о колонии, что в луа пока недоступно.

Correct, excessive and incomplete at the same time. Care to point out what's missing?

Not required, I put my trust in you.

Принял, поймал.

Судя по недостающей инфе (например данных по урону), которую я в пушках ожидал увидеть, это игра все из конфигов (подгруженных в память) прямо на ходу считывает, опираясь на "type"? Надо бы тогда подумать, как организовать подгрузку ваших конфигов с 1.50, либо тоже в json запихивать, либо с аппой мудрить костылить c чтением и локом конфигов сервера (для сингла энивей придется я так понимаю из юзерского .cfg читать), либо чисто стандартными обходиться (такое я думаю не проканает, рано или поздно захочется подгружаемых конфигов, так что лучше заранее какую то избыточную гибкость начинать писать).

Еще такой вопрос возник, далеко не приоритетный, скорее даже пока из разряда теоретических, как задел хороший на возможности расширения механики игровой:
Можно ли будет кораблям третьей/четвертой/n-ной стороны влепить в интерфейс игры кнопочку спрашивающую желание присоединиться к бою и отправлять вместе с жсоном в боевой модуль? А потом ещё и импортить назад в игру корректно? Без поддержки данной опции ИИ хотя бы.

Я пока формат ковыряю и архитектуру думаю. О ближайших успехах сообщать/показывать наверное через месяц-два начну.

Конфиг уже есть в json. Инфа про пушки есть в json.config.weapon, например если type=fusion_beam то надо смотреть json.config.weapon.fusion_beam.min_damage, там же max_damage и т.д. Игра на самом деле берёт из внутренних таблиц, эти таблицы отмаплены патчем на конфиг.

Когда в 1.50 играют несколько сторон, конфиги у них синхронизируются и становятся одинаковыми. Так что самое простое его всегда выгружать, как я и делаю. Единственная проблема сейчас, что джейсон большой и поэтому медленно выписывается (несколько секунд). В перспективе надо ускорить, но это на стороне патча проблема.

Влепить кнопочку в интерфейс -- запросто. Но чтобы она заработала придётся постараться. Если делать в рамках интерфейса игры, то даже не возьмусь, т.к. код боя и так еле работает, править его это ад. А если делать только для боевого модуля через экспорт, то наверное можно извернуться.

Дело ваше конечно, но рекомендую начать с совсем простого типа полётов нестреляющих серых квадратов, чтобы итерацию сократить.

По сетевой архитектуре имхо обычная звезда -- служебный сервер и боевые модули все коннектятся к нему.

Смотри, я вижу это так. В саму игру внедряется код, инициирующий перед стартом боя игрокам находящимся в системе, где происходит бой интерфейс кнопочку-вопрос: "в системе такой то начинается бой. Участвуют столько то кораблей такого то класса с каждой стороны. Принять участие в битве? Да/Нет". Дальше игрок жмакает кнопку "Да", и его корабли в json улетают, чтоб их по прошествию боя тоже можно было из боевого модуля заимпортить в игру.

Собственно, так и делаю, я имел ввиду более заслуживающие внимания результаты.

С сетевой архитектурой то все вроде понятно, а вот расширяемость всю желательно заранее продумывать, чтоб потом масштабных правок не приходилось вносить.

Некуда ставить 3ю сторону, поле-то маленькое, а тем более 8ю. Ну это так, придирки. Мне кажется фича сама бесперспективная. Событие редкое, а кодить много.

Если что-то вызывает сомнения давай здесь брейнштормить. Имхо текущий конфиг можно взять за основу и всю расширяемость он покрывает.

Prоpеrties likе fiеld sizе etc thеre arе up to extеrnal applicatiоn only, moо2 behaviоr considеring em have nоthing tо do with it.