Список основных изменений:

• Обновлен сервер. Переписал серверную часть на Python и перенес на другой хостинг для большей стабильности и контроля.

• Добавлена поддержка новых AI-провайдеров. В настройках теперь можно выбрать OpenRouter и LLMost в дополнение к Gemini.

• Переделана система экипировки. Теперь предметы из инвентаря можно перетаскивать на слоты персонажа. Также были даны более строгие инструкции AI, чтобы он всегда выдавал и экипировал полный комплект стартовой брони.

• Улучшены стартовые промпты. Добавлена логика "пролога", чтобы начало игры не было таким внезапным, а имело краткую предысторию прибытия персонажа в стартовую локацию.

• Переработаны статус-эффекты. Все эффекты вынесены в отдельный JSON-файл. Это упрощает их добавление и редактирование в будущем.

• Исправлены баги:

  • OOC-окно: Теперь клик по плашке "OOC" в диалоге GM корректно отображает всплывающее окно с текстом.

  • Карта: Исправлена проблема, когда новые метки могли появляться поверх уже существующих.

  • Улучшена обработка ответов от AI, чтобы игра была более устойчива к ошибкам форматирования JSON.

Вот такое обновление. В основном работа над ошибками и подготовка базы для будущих нововведений.

Спасибо, что играете.

Здравствуйте и добро пожаловать на 52-ю страницу «Капитанского дневника». Я капитан Марек, и на этой неделе я поделюсь некоторыми подробностями о своей недавней работе по оптимизации транспортных средств и симуляции океана. Это немного более техническая тема, поэтому вкратце скажу, что из-за проблем с амфибийными транспортными средствами мы оптимизировали транспортные средства и симуляцию океана, и теперь вы сможете наслаждаться игрой с частотой кадров на 10–15 % выше! Читайте дальше, если хотите узнать, как были достигнуты эти успехи и какое отношение это имеет к амфибийной технике.

Рендеринг транспортных средств

Транспортные средства в Captain of Industry смоделированы в 2D. Для этого есть много причин, в основном связанных с производительностью и сложностью реализации (поиск пути в 3D становится очень сложным и происходит очень быстро). Однако игра выполнена в 3D, поэтому для каждого кадра необходимо вычислять высоту и 3D-ориентацию всех транспортных средств на основе их 2D-положения.

Расчёт положения транспортного средства не представляет особой сложности:

1. Вычислите двумерные координаты четырёх «угловых точек» транспортного средства на основе его двумерной позы (положения и поворота). Эти четыре точки обычно находятся там, где расположены колёса или где заканчиваются гусеницы.

2. Преобразуйте эти двумерные точки в трёхмерные, вычислив высоту рельефа в каждой точке. При этом учитываются такие исключения, как пандусы для транспортных средств, где транспорт движется по альтернативной поверхности, а не по рельефу.

3. Проведите трёхмерную плоскость через эти точки.

4. Вычислите трёхмерную позу (положение и поворот) на основе полученной трёхмерной плоскости.

Проблема с амфибийными транспортными средствами

Когда мы разрабатывали машины-амфибии, одним из препятствий, очевидно, был океан! Я имею в виду возможность того, что машины будут плавать по волнам. Дело в том, что наш океан полностью смоделирован на графическом процессоре (подробнее об этом в выпуске № 35), и центральный процессор вообще ничего не знает о поверхности океана.

На столе лежали два решения:

1. Загружайте сгенерированные текстуры океанских волн из памяти графического процессора в каждом кадре и заставляйте центральный процессор вычислять высоту океанских волн в четырёх угловых точках каждого транспортного средства. Это довольно просто реализовать, но передача данных из графического процессора в центральный требует немалых затрат, а работа центрального процессора, необходимая для вычисления высоты волн, значительна (сотни инструкций).

2. Пусть графический процессор вычисляет высоту океанских волн в точках расположения транспортных средств. Центральный процессор загружает в графический процессор список двумерных точек интереса, а вычислительный шейдер эффективно вычисляет соответствующую высоту океанских волн. Это будет значительно быстрее, чем предыдущее решение.

Зная, что первое решение приведёт к значительной дополнительной нагрузке на процессор, мы выбрали второе решение, и я за него взялся.

Когда я писал вычислительный шейдер для оценки высоты волн, мне пришло в голову, что у нас уже есть текстура высоты рельефа на графическом процессоре для рендеринга рельефа. Почему бы не использовать её? И почему бы не создать ещё одну текстуру высоты для специальной поверхности транспортного средства и не использовать её? Это позволило бы нам полностью отказаться от выборки высоты транспортного средства на центральном процессоре.

И это, друзья мои, то, что мы часто называем «кроличьей норой». Из задачи, на которую отводился один день, внезапно вырастает проект, на который уходит целая неделя!

Но прежде чем я прыгнул в эту кроличью нору, я выполнил домашнее задание и проанализировал производительность вычисления положения транспортного средства на центральном процессоре. Я подумал, что если на это уходит менее 1 % времени обновления симуляции, то оптимизировать это не стоит. Я провёл анализ и, держитесь крепче, вычисление положения транспортного средства заняло около 10 % времени симуляции!

Увидев этот результат, я понял, что оптимизация этого кода определённо стоит дополнительных усилий. Поэтому я написал код, который позволяет эффективно хранить текстуру поверхности транспортного средства на графическом процессоре и использовать её вместе с текстурами океана и ландшафта для полного преобразования 2D-поз транспортных средств в 3D на графическом процессоре. Последний вычислительный шейдер принимает 2D-позы и смещения углов транспортных средств для всех транспортных средств и вычисляет окончательные 3D-позы.

Тестирование показало, что вычисление положения 270 транспортных средств занимало около 1 мс, а теперь на центральном процессоре это происходит практически мгновенно (требуется лишь скопировать в память небольшой массив).

И самое приятное то, что вычисление 200 поз на графическом процессоре требует так мало ресурсов, что мы можем вычислять в 10 раз больше обновлений транспортных средств без замедления работы, в то время как центральный процессор будет линейно замедляться с каждым дополнительным транспортным средством.

Возможно, вам интересно, почему процессор работает так «медленно». Дело в том, что каждое транспортное средство выбирает четыре точки, а для интерполяции каждой точки требуется четыре значения высоты, то есть 16 значений для каждого транспортного средства. Поверхность транспортного средства хранится в словаре, поэтому добавьте к этому 16 обращений к словарю и множество операторов if и вызовов методов. Кроме того, используются тригонометрические функции и множество арифметических операций. Для более чем 200 транспортных средств это даёт значительный результат. Очевидной неэффективности не было, просто много обращений к памяти и математических вычислений (я почти уверен, что узким местом была память).

Стоит отметить, что из-за задержек при передаче данных с центрального процессора на графический транспортные средства теперь отстают на несколько тактов моделирования. Я написал интеллектуальную систему минимизации задержек, поэтому, если ваш компьютер обрабатывает результаты достаточно быстро, задержка может составлять всего один такт, а в худшем случае — до четырёх тактов.

Оптимизация океана

Транспортные средства-амфибии создавали ещё одну проблему, связанную с океаном. Теперь, когда мы можем моделировать транспортные средства, «парящие над волнами», в настройках рендеринга появилась возможность отключить реалистичную симуляцию океана и просто использовать плоскость с анимированными текстурами. Проблема в том, что, хотя анимированные текстуры придают низкодетализированному океану некоторую глубину, трёхмерная сетка представляет собой просто плоскую поверхность. Как только вы размещаете на ней транспортные средства, иллюзия глубины исчезает, и она выглядит как плоская поверхность.

Итак, у нас было два варианта:

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

2. Попробуйте оптимизировать смоделированный океан и убрать из игры опцию «плоский океан».

Вам это не напоминает кроличью нору? Проблему с потенциально высокой сложностью и неопределёнными результатами? Да, и что мы делаем перед тем, как нырнуть в кроличью нору? Анализируем! Я хотел узнать, насколько медленнее работает смоделированный океан.

Согласно моим тестам, на рендеринг смоделированного океана уходило в 10 раз больше времени, а на менее мощных графических процессорах этот показатель мог быть ещё выше.

Когда я представил свои выводы на совещании и сказал, что, по моему мнению, стоит стремиться к более высоким показателям, Джереми мягко напомнил мне, что мою реализацию симуляции океана, безусловно, можно оптимизировать, и дал мне несколько советов. Так что все за работу, мы выбираем второй вариант!

Я не хочу вдаваться в технические подробности, но должен упомянуть, что наш океан использует так называемое обратное быстрое преобразование Фурье (ОБПФ) для эффективного моделирования и суммирования сотен синусоидальных волн различной частоты и амплитуды. Кстати, эту же технологию используют в кино и так называемых «ААА»-играх.

IFFT должен выполняться в несколько этапов, в нашем случае 8, и моя первоначальная реализация вызывала вычислительный шейдер для каждого этапа. Это естественная вещь, поскольку каждый этап должен завершиться до начала следующего. Однако, как указал Джереми, эти этапы могут быть “объединены” в один вызов вычислительного шейдера. Это возможно благодаря функции GroupMemoryBarrierWithGroupSync , которая позволяет всем потокам в группе потоков ожидать друг друга, чтобы их промежуточные результаты могли быть повторно использованы на следующем этапе. Как вы можете себе представить, синхронизация групп потоков выполняется намного быстрее, чем вызов нового вычислительного шейдера.

Объединённые ядра IFFT позволили нам ускорить работу в 4–5 раз, но я чувствовал, что можно добиться большего. Моей второй целью было сократить объём работы на кадр. Мы по-прежнему выполняли четыре IFFT на кадр, а это большой объём работы. Я хотел реже выполнять фактическое моделирование и просто использовать линейную интерполяцию между кадрами — по сути, то же самое, что мы делаем для моделирования игры, но для океанских волн.

Я не буду вдаваться в технические подробности, но отмечу, что я решил моделировать океан 10 раз в секунду и просто интерполировать промежуточные значения. С точки зрения реализации мы храним три набора данных: два интерполируемых и один вычисляемый, и они чередуются циклически. Организовать всё это было непросто, но и не так сложно, как может показаться.

Самым большим преимуществом этого метода является то, что отдельные вычисления IFFT могут быть вызваны в разных кадрах, что дополнительно снижает нагрузку на каждый кадр в 3-4 раза. Что еще более удивительно, так это то, что чем больше кадров в секунду вы получите, тем меньше будет нагрузка на каждый кадр. Для систем, которые запускают COI со скоростью 40 + кадров в секунду, будут кадры, в которых IFFT даже не выполняется на графическом процессоре.

Вот окончательные результаты тестирования. Если рассматривать только нагрузку на вычислительное ядро графического процессора, то старое IFFT занимало 0,8 мс на кадр, а после всех оптимизаций — 0,05 мс на кадр. Это ускорение в 16 раз!

Я протестировал это на пустой карте Нью-Хейвена, и старый плоский океан выдавал 352 кадра в секунду, старый причудливый океан — 301 кадр в секунду, а тот же океан после оптимизации — 343 кадра в секунду. Таким образом, новый океан не такой дешёвый, как старый, но разница невелика, поэтому мы решили убрать старую опцию из игры.

Окончательный ориентир

Подводя итог, можно сказать, что для того, чтобы машины-амфибии заработали, мы оптимизировали расчёт положения транспортных средств и рендеринг океана. В конце игры на McRib с 270 транспортными средствами общий FPS вырос с 54,8 до 61,5, то есть на 12%! Вот более подробные цифры:

Путевые точки поездов

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

Путевая точка поезда работает точно так же, как станция, с точки зрения расписания поездов, но к ней нельзя прикрепить модули. Однако для неё не нужно больше места, чем для самого железнодорожного пути, поэтому её можно построить на параллельных путях без дополнительного пространства. Более того, путевые точки можно размещать даже на эстакадах. Путевая точка будет доступна в базовой игре.

Атомный локомотив

В последнем выпуске «Капитанского дневника» я вкратце упомянул, что в грядущем дополнении «Поезда» появятся новые локомотивы, и многие обсуждали самый необычный из них — ядерный локомотив. Я видел много предположений о том, насколько он будет большим и будет ли ему нужно топливо или вода, поэтому позвольте мне прояснить ситуацию.

Атомный локомотив состоит из трёх частей: служебного вагона (часть A), вагона с ядерным реактором и турбиной (часть B) и вагона-конденсатора (часть C). Длина всего локомотива составляет 25 плиток (50 метров), что эквивалентно пяти тепловозам первого уровня.

В блоке A находится экипаж из двух человек. В блоке B расположен защищённый ядерный реактор и паровая турбина, которая вырабатывает электричество для всех ведущих осей. Чтобы локомотив был автономным и не нуждался в дозаправке водой, в блоке C происходит конденсация отработанного пара с возвратом воды в реактор.

Поскольку вода циркулирует по замкнутому контуру, единственное, что нужно дозаправлять, — это ядерное топливо. Для этого необходимо заменить весь реактор. Самое интересное, что реактор нужно менять только раз в 100 лет!

А если по какой-то причине вам недостаточно локомотива, состоящего из трёх секций, можно присоединить несколько пар секций B-C к одной секции A.

Русское сообщество по игре в ТГ
https://t.me/captainofindustryru

ДС
https://discord.gg/GXxWHqG9M8

Всем привет!
В предыдущем посте анонсировал скорое открытие бета-тестов. В общем, открыл доступ всем желающим и хочу рассказать детали:

- Игра для Windows.

- Тестовый билд весит чуть больше 900 МБ.

- Еще не сделал автоматический выбор языка исходя из языка стима или системы, поэтому в меню (нажать на Esc) есть выбор языка)

- По умолчанию качество стоит на "Ультра". Насколько мозгов хватило, постарался оптимизировать. Но, если на каком-нибудь устройстве будет низкий fps, смело пробуйте самое низкое качество, если нормально, то поднимайте до удобоваримого компромисса)

- Также по умолчанию стоит синхронизация с fps монитора (V-Sync). По идее, если не проседает сильно, то это оптимальная настройка, но можно в настройках поиграть и вообще не ограничивать ничего.

- Так же, если реально есть проблемы с производительностью, можно поиграть с "плотностью травы" и "качеством океана".

Так же рекомендую ознакомиться с управлением.

Игровой процесс:
Вверху находится основной интерфейс:

Первое, что можно открыть, это "Чертежи":
Там будет доступен первый тип корабля, первая пушка, парус и ядра.

Не все элементы можно разблокировать, там, где кнопка более темная - на более поздние тесты. Можно разблокировать: 3 корабля, 6 парусов, 3 пушки, 2 типа амуниции.

С ядрами, да и в принципе с амуницией есть нюанс. Если вы построите корабль и нажмете на "Поднять паруса", то высветится сообщение, что нет амуниции. Разблокированные ядра, книппеля и т.д. можно купить, зайдя в опцию "Торговать" справа сверху экрана.

"Верфь". После разблокировки элементов строительства в Чертежах, можно строить корабли. Изначально у вас немного золота, дерева, веревок. Так что сильно не разгуляешься. Значит, самое время что-нибудь заработать.

Небольшое отступление, если я сделал кривую экономику и у вас закончились ядра и золото и вообще все ресурсы, потому что еще не выиграли ни одного сражения, или просто получили мало награды, можно начать игру сначала. Для этого в папке с игрой заходим в папку Leonardo's Island_Data, потом StreamingAssets, и удаляем loc.li, prefs.json и содержимое папки Ships:

Игровые режимы:

Вокруг верфи - потопите всех ботов и получите свою первую награду!)
Случайные сражения - онлайн битвы 4х4. У меня столько друзей для тестов нет, поэтому надеюсь совпасть с кем-нибудь во время этих тестов и посмотреть производительность, если все ок, тогда будут битвы 8х8, 12х12 - время покажет.
Случайные регаты - 5 человек, у кого корабль длиннее быстрее.

ВАЖНО! ожидание в лобби максимум 45 секунд. Если максимальное количество игроков не набралось - все равно событие начнется. Минимум игроков для события: 2.

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

Так, вроде ничего не забыл. Надеюсь, ничего не намудрил с билдом для плэйтеста.

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

Длительность бета-теста?
До 22-23 декабря примерно.

Обратная связь:
https://steamcommunity.com/app/4237730/discussions/0/7055062...
Также, если добавите скриншоты того, что нравится, того, что нет, багов и т.д - буду признателен!!!
Плюс, есть файл ExceptionLogs.txt, если что-то конкретно пошло не так, напишите мне здесь комментарий, я вам отвечу почтой, можно будет этот файлик скинуть мне на почту) Файл собирает ошибки вылеты игры.

Немного скриншотов:

В рамках немецкой кампании готовится к внедрению новая миссия — «Сражение у Эль-Газалы», открывающая главу «Второе наступление Роммеля». Автор сценария и дизайнера миссии — ведущий разработчик Александр Жиляев (Tyrion).

Операция началась 26 мая 1942 года после того, как Эрвин Роммель добился от Верховного командования увеличения численности подразделений и материально-технической поддержки. Британские войска к этому времени подготовили укреплённую оборонительную линию — от населённого пункта Эль-Газала на севере до форта Бир-Хакейм на юге. В ходе подготовки к наступлению Роммель применил тактику дезинформации: движением колонн военных грузовиков и фронтальными атаками итальянской пехоты он создал у противника впечатление главного удара в северном секторе. В действительности же основные силы африканского корпуса совершили обходной манёвр с юга, обойдя линию обороны в её наиболее уязвимом участке.

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

Ключевую роль в отражении контратак сыграла немецкая противотанковая артиллерия — в частности, 88-мм зенитные установки FlaK 18/36, которые в условиях пустыни проявили высокую эффективность и мобильность. В итоге британские силы, не выдержав потерь, были вынуждены начать отступление на восток. Сражение, в котором, по свидетельствам участников с обеих сторон, исход балансировал на грани, завершилось решительной победой Африканского корпуса и создало условия для последующей осады Тобрука.

Что такое GZM сейчас и с чем его едят?

Где скачать GZM 11, где пообщаться с сообществом GZM и как сыграть по сети?

Серия постов про проект GZM 1945