Перейти к содержимому


Фотография

Дневники разработки 1


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 4

  #1 Warrior Отправлено: 02 Март 2020 - 08:50

Warrior

    Создатель

  • Команда WoSB
  • 615
  • Регистрация:
    12.03.2016

*
Популярное сообщение!

Приветствую!

 

Цикл статей "дневники разработки" посвящен тем вещам, которые скрыты от ваших глаз, но очень важны, чтобы все работало.

 

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

Это будет интересно для тех, кто знаком с программированием и/или геймдевом, и всех интересующихся данной темой, а возможно, и кому-то еще   :) 

 

 

Дневники разработки #1: Скрытые проблемы

 

Открытый мир

 

   Мир содержит в себе огромное количество динамических объектов, который вы когда-либо можете увидеть. Сейчас это около: 1800 кораблей NPC, 2800 собираемых объектов, 90 фортификаций и башен, и конечно, корабли других игроков, количество которых в море обычно составляет 60% от онлайна. Что нужно сделать на сервере, для того, чтобы вы увидели любой из этих объектов в своем клиенте? Их нужно подгрузить, и затем, обновлять их состояние, пока они в зоне видимости. А еще нужно обрабатывать разные виды взаимодействия между ними: корабли могут сталкиваться и вести перестрелку, лут может быть собран, фортификации могут подвергаться обстрелу и т.п.

   Представим, что у нас есть 1000 кораблей, и простейший метод, позволяющий проверить, что они могут взаимодействовать. В общей сложности, обнаружение "каждый с каждым" потребует около n²/2 проверок, при n=1000 получается 500 тысяч проверок, а если добавить кораблей... при 2000 получается уже 2 миллиона. То есть, количество проверок быстро возрастает, и со временем может превысить технические возможности.

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

 

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

   Однако, когда происходят бои между гильдиями (например, ПБ), собирается большое количество кораблей всего на нескольких секторах, которые ведут перестрелку, поэтому, большое количество ядер все еще может являться проблемой. Так что, нужно использовать и другие хитрости. Например, для ядер реализован механизм предугадывания столкновений: в момент выстрела орудия, на сервере производится выборка всех кораблей, в которые физически может попасть ядро (например, в корабли позади, оно никогда не попадет   :) ). В этой выборке проверяются и все прочие условия (наличие мирных флагов, флагов портового боя и т.п.).

   

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

 

Огонь!

 

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

   Похожим образом устроены и прочие вещи.

 

 

Рендеринг воды

 

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

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

 

kToSneATU6I.jpg

 

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

 

c06-matLKu8.jpg

 

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

   KztbFBKRtMA.jpg

 

 

 

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

 

tOQWe-yRJYs.jpg

 

 

Читы

 

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

 

   В целом, их можно разделить на 4 класса по принципу действия: спидхак, редактор памяти, модификация и ассистент.

   Спидхак: меняет системный таймер таким образом, чтобы изменить скорость процессов в клиенте игры

   Редактор памяти: позволяет получить доступ к переменным, в том числе, изменить их. В основном, это позволяет получить игровые деньги, зафиксировать количество здоровья, модифицировать параметры персонажа и вообще все, что можно модифицировать.

   Модификация: собственно, модификация клиента игры, в результате которой может меняться код. Например, появляется возможность видеть сквозь стены или аимить с использованием функций самой игры.

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

   

   В большинстве оффлайн-игр работает практически все вышеперечисленное. В онлайн-играх все сложнее.

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

 

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


  • 17
О проекте: https://forum.worldo...а-тестирование/
Набор в QA: https://docs.google....ctWpwQ/viewform
Каждый получает ту реальность, которую заслуживает.

  #2 BECEJIuU_RODJER Отправлено: 02 Март 2020 - 19:09

BECEJIuU_RODJER

    Боцман

  • Ветераны альфа-теста
  • 959
  • Регистрация:
    03.12.2018
  • Гильдия:ЛЕВ

Большое спасибо за приоткрытие завесы и познавательный экскурс в глубины разработки игр. Думаю, эти статьи будут интересны и познавательны многим (особенно тем, кто считает что игры и разное п.о. делаются по щелчку пальцев) . Лично мне было интересно читать. Ждем продолжения цикла статей в таком же духе. 


  • 1

  #3 ✔355/113⚓РАТ №1✔ Отправлено: 03 Март 2020 - 04:46

✔355/113⚓РАТ №1✔

    Навигатор

  • Забаненые
  • 1 424
  • Регистрация:
    02.03.2018
  • Гильдия:[☠]

Статью прочитал, мнение о статьи имеетсяя, но вряд ли будет кому-то интересно.


  • 0
Каждая ошибка, допущенная во время переписки  в чате или на форуме, приближает кончину языка, на котором говорили твои героические предки.
 
 

 

 


  #4 Misa Отправлено: 03 Март 2020 - 14:24

Misa

    Пират

  • Альфа-тестеры
  • 18
  • Регистрация:
    06.03.2019
  • Гильдия:Хмм

Доброго времени суток, Warrior спасибо большое за познавательную статью и за проделанную работу по игре и улучшению ее, не смотря на многие трудности с которыми вы сталкиваетесь! Дай Бог вам килограмм терпения, вагон желания и самое главное Здоровья! Вы проделали огромный путь! проходя шаг за шагом! Главное не опускайте руки, мы с удовольствием играем и поддерживаем ваш проект, не смотря на какие то проблемы в игре или недоработки, так как верим и самое главное знаем что вы всегда  готовы стараться и исправлять все то что игроки пишут в ЦПП о каких либо проблемах и багах! Удачи вам во всем! И не опускайте руки! Статью считаю познавательной и нужной! Всех вам Благ в Дальнейшем!
P.S. Как говорится ПОПУТНОГО ВЕТРА ВАМ!)
 


  • 1

  #5 Cyril_Sneer Отправлено: 04 Март 2020 - 12:37

Cyril_Sneer

    Пират

  • Альфа-тестеры
  • 14
  • Регистрация:
    14.07.2019

Интересная статья, надеюсь что время для написания продолжения, не смотря на плотный график, найдётся. 


  • 1
Изображение


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных