Войти
ПрограммированиеФорумСеть

Как обновлять онлайн клиент? по типу доты и фортнайта.

Страницы: 1 2 Следующая »
#0
10:01, 25 мая 2018

Знаю следующие виды обновления:

1)
  - Создается манифест - который содержит все имена файлов и их хеш суммы.
  - Клиент качает серверный манифест, сравнивает со своим и качает только измененные файлы.
  Качаются только измененные или недостающие файлы.
  Манифест качается только если версия клиента не совпадает с версией клиента на сервере.

2)
  - Сервер содержит дифф патч файлы, например .pak файлы.
  - Клиент качает все патчи, которых ему не хватает до текущей версии и применяет их по очереди.
  Если клиент слишком сильно отстал по версии, то обновлять придется довольно много, а может даже проще скачать полную версию.
  Знаю что в старой warcraft 3 использовался подобный подход, но там патчей было очень мало и редко, так что там это было приемлемо. В современных играх патчи выходят чуть ли не каждый день, неделю точно.

Есть другие методы? что использовать? Склоняюсь к 1му варианту, но проблема его в том, что с ним не получится использовать .pak файлы, но так уж они нужны?

Как назло удалены и дота и фортнайт, не могу проверить используют ли они .pak файлы (или аналоги) или используют отдельные файлы для каждого ассета?
Хотя по идее можно на клиенте иметь .pak файлы, а на сервере отдельные файлы, и потом на клиенте их впаивать в .pak файлы, но че то как то по моему лишнее.

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


#1
11:57, 25 мая 2018

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

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

P.S. можно сделать гибридную версию: бить большие пакеты на несколько мелких, объединяющих связанные данные (например, пакет с графонием, пакет с музыкой, etc).

#2
13:27, 25 мая 2018

Tiendil
> сейчас можно делать частичную докачку или докачку по требованию
Таких понтов у меня точно не будет. Всё будет стандартно. Может быть когда нибудь в какой нибудь поздней продвинутой версии.

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

Вообще в ue4 есть типа какой то там patching, но я пытаюсь понять что он вообще делает и у меня пока это плохо получается, насколько я понял он не умеет обновлять .exe и .dll, он обновляет только Content, но это не точно.

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

#3
20:07, 25 мая 2018

Итак во первых в очередной раз убедился что фортнайт полное дерьмище, но не суть.

В ue4 нет патчинговой системы нормальной с акумулятивными патчами, есть что то типа DLC. Судя по всему в фортнайте используется 1 единственный патч, который соответсвенно постепенно растет, но это не точно. Что они будут делать если он вырастет, не понятно.

Вывод: использовать 1й вариант, но попробовать раздробить контент на мелкие pak файлы, выделить статический контент отдельно, часто или потенциально изменяемый отдельно. И обновлять это всё по манифесту.

А пока что я выяснил что в ue4 есть pak чанки, судя по всему это как раз то что мне нужно для дробления контента на мелкие порции, но это не точно.

#4
2:45, 26 мая 2018

Э-э-э... лучше качать только изменившиеся байты. Зачем файлы качать целиком?

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


> И нужно ли криптовать
Нет.
Ни манифест, ни файлы. И https не нужен для файлового сервера.

Но:
- сервер могут нагрузить скачиванием обновлений - типа DDoS атака такая.

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


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


А ещё:
1. файлы на компьютере игрока не всегда могут быть нужной версии (например, игрок взял и удалил какой-то файл).
2. результат установки может быть не совсем таким как ожидалось (например, игрок нажал 'reset' во время установки патча).

#5
3:46, 26 мая 2018

ELena_Shloemovich
> 1. файлы на компьютере игрока не всегда могут быть нужной версии (например,
> игрок взял и удалил какой-то файл).
> 2. результат установки может быть не совсем таким как ожидалось (например,
> игрок нажал 'reset' во время установки патча).
Тут как раз используется кнопка - починить клиент. С сервера получаем манифест и проверяем все файлы, качаем недостающие.

Тут еще суть в том, чтобы использовать по максимуму готовый функционал, а именно pak файлы в ue4.

Вот еще статья, пока читаю: https://www.gamasutra.com/view/news/181455/Indepth_A_simple_syste… e_content.php

Пока могу лишь сказать что по байтам мало кто обновляет.

UPD: по статье - одна вода, ничего нового, не сказали как с бесконечными патчами бороться, объединять их или что.

В общем пока не разберусь в этой статье: https://docs.unrealengine.com/latest/INT/Engine/Basics/AssetsAndP… ngAndChunking
дальше делать нечего. А статья капец какая сложная... ничего не понятно.

#6
17:44, 26 мая 2018

gamedeveloper01
> Пока могу лишь сказать что по байтам мало кто обновляет.

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

По вашей ссылке на гамасутру написано как это решено в Q3 engine.
Движок кваки предпочитает загружать новые файлы из .pk3 архива патча.


Может быть UE 4 тоже так умеет?


gamedeveloper01
> не сказали как с бесконечными патчами бороться, объединять их или что.
Периодически :D
Пять последовательных патчей, потом кумулятивный, пять последовательных, снова кумулятивный.

#7
8:31, 27 мая 2018

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

FBuildPatchInstaller
FHTTPChunkInstaller

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

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

#8
11:28, 27 мая 2018

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

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

#9
17:31, 27 мая 2018

Вот еще статья приоткрывающая завесу тайны над ue4 чанками: https://www.unrealengine.com/en-US/blog/optimizing-battle-breaker… d-downloading

И кстати я почти наверняка выяснил, что патчи скачиваются по HTTP, а не по TCP, и это как я понял общепринятый подход. Ну а пока, я всё еще выясняю общую картину обновления клиента в ue4.

#10
22:17, 29 мая 2018

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

Остаётся один единственный выход, но думаю не самый плохой. Итак:
- Использовать обновление клиента с заменой всех изменившихся файлов на новые, без кумулятивных патчей.
- Использовать pak файлы, но необходимо разделить контент на разные паки (Chunks), которые можно выделить таким образом, чтобы:
  - более менее статический контент был отдельно от часто изменяемого.
  - можно либо все юзабельные предметы сделать в одном чанке (тогда придется обновлять весь чанк при изменении или добавлении предмета), либо делать одтельный чанк для каждого предмета, либо делать чанки по 10 предметов и статичные порядковые номера для предметов (не очень красиво), либо делить предметы на какие то группы по какому то признаку и делать чанки для этих групп. Для начала можно первый вариант.
  - короче смысл в том, чтобы в итоге большинство паков не изменялось с выходом обновлений, а если будут изменяться, то паки должны быть достаточно небольшими.
  - каждый изменившийся или новый пак будет скачиваться целиком, без бинарных дифференциалов, хотя может быть в будущем можно и добавить подобное, но не факт, что нужно.
- Сделать свой TCP или HTTP сервер для билда клиента, со следующими свойствами:
  - В корне каталога будет манифест со всеми файлами и их (хеш суммы?, или дата изменения?, или guid?), скорее всего хеш суммы.
  - Собственно все файлы клиента.
  - Каждый файл будет качаться индивидуально, по очереди: сначала посылаем запрос на скачивание одного файла, потом следующего и так далее, по принципу обычного файлового сервера.
  - При первой установке или обновлении, не важно, клиент качает сначала манифест, смотрит каких файлов у него нет, и качает все файлы по очереди.

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

UPD: только я это написал и возник прогресс по поводу создания сборки при помощи BuildPatchTool, а не через редактор. Через редактор как раз ничего не работает, но тулса вроде сделала какой то высер, попробую капнуть глубже.
UPD2: пока что тесты BuildPatchTool проходят успешно и я выяснил в том числе, что патчи которые он генерирует не копируют целиком измененный pak файл, даже если он один большой, а копирует лишь 6 MB, что хоть и много для небольшого изменения в 1 букву в маленьком ассете, но вполне нормально, если учесть что весь pak файл занимает 500 MB. То есть, грубо говоря эта тулза умеет дифференциально-бинарно или что более вероятно она просто умеет извлекать из своих же pak файлов только измененные ассеты, пихать их по нужным чанкам и сравнивать с предыдущей версией, короче довольно сложный функционал. Теперь нужно запилить HTTP файловый сервер на шарпе (так как подобный сервер для этих патчей в ue4 не предусмотрен, я конечно попробую юзнуть UnrealFileServer, но по моему он не для этого) и дальше протестировать BuildPatchInstaller. Позже еще попробую обновить UE 4.19.1 -> 4.19.2, есть вероятность что создание патчей заработает в редакторе, там в патчноутах есть кое какой плагин, который возможно как раз и используется самим редактором, баг в том, что в 4.19.1 версии этого плагина в файлах нет, хотя в редакторе он подключен, походу инсталлер движка просто его не скачал при установке.
UPD3: также вроде как выясняется, что эта тулза не генерирует отдельные патчи, она просто делает 2 вещи: обновляет общий список чанков для последней версии (добавляя или изменяя чанки) и создает новый манифест для новой версии.

#11
3:48, 30 мая 2018

А там разве нет исходников buildpatchtool чтоб поглядеть как она работает?
А вообще, спасибо что держите в курсе дела и не скупитесь на подробности - интересно читать. Наверное у близов с их новым casc'ом что пришёл на смену mpq походу такой же подход. Хотя mpq был вполне себе интересен [для своего времени?] структурно :) И реализация формата от ладислава зезулы вполне неплохая, хотя автор мудак тот ещё.
Да и сейчас формат терпим, если камулятивные обновления приемлимы для той или иной игры

#12
18:12, 31 мая 2018

Krakean
> А там разве нет исходников buildpatchtool чтоб поглядеть как она работает?
Есть, но чтобы понять как именно создаются патчи нужно разобрать тонну кода, там его достаточно много и он не такой простой. У меня нет такой задачи понять как именно создаются дифференциальные патчи в ue4, главное понять как это использовать.

На данный момент пока выяснил такие вещи: BuildPatchService и FBuildPatchInstaller в частности предназначены для установки и скачивания чанков, но не предназначены для скачивания манифестов, то есть ему нужно передавать уже загруженные манифесты в качестве параметров: текущий манифест и новый манифест на который обновляем. Можно конечно вручную сделать HTTP запрос и скачать новый манифест, но есть еще FHTTPChunkInstaller.

А вот FHTTPChunkInstaller может загружать новый манифест с сервера, и в качестве компонента для загрузки чанков использует непосредственно BuildPatchService и FBuildPatchInstaller. Но на данный момент следующая проблема: этот класс является частью плагина HTTP Chunk Installer, и судя по всему он предназначен для использования непосредственно самим клиентом (а не лаунчером), но это пока не точно, и возможно я разберусь как его использовать лаунчером. Этот плагин в том числе на сколько я понял может докачивать необходимые чанки уже во время запущенной игры, этот функционал меня мало интересует, но мне пока не понятно, каким образом он обновляет клиент во время его запущенного состояния, если обновился сам бинарник этого клиента... тут нужны тесты, я пока только настраиваю и разбираюсь с параметрами этого класса. Если окажется, что он не умеет обновлять бинарники в запущенном состоянии, значит это нужно как то делать через лаунчер, и скорее всего этот класс должен как то уметь работать и через лаунчер.

В фортнайте при запуске игры мы всегда видим сообщение: Обновление, это скорее всего как раз и есть запуск FHTTPChunkInstaller, который проверяет обновление клиента. Но я пока не понял, обновляется ли фортнайт через лаунчер, или только самим клиентом. Я мало в него играл и сразу удалял и не доходил до момента когда обновление бы происходило через лаунчер, всегда оно происходило через запуск клиента. Возможно при обновлении бинарников FHTTPChunkInstaller самостоятельно перезапустит клиент или что то подобное или может как то сделает hotreload, пока не понятно.

Попробую настроить FHTTPChunkInstaller и попробую запустить обновление через клиент, потом посмотрим как это можно сделать через лаунчер. Вообще, для меня дикость - обновление клиента через сам клиент, это может для кого то и удобно, но как по мне это не нужно ни разработчикам ни самим пользователям, взять ту же доту, там такого бреда нет, там всё итак хорошо обновляется без этого бреда. Хотя возможно это необходимо например для консолей, в которой запускать лаунчер не получится. И если у меня получится разобраться как это использовать то может я тоже сделаю как в фортнайте.

#13
18:49, 31 мая 2018

gamedeveloper01
> Как назло удалены и дота и фортнайт, не могу проверить используют ли они .pak
> файлы (или аналоги) или используют отдельные файлы для каждого ассета?
Не совсем дота, но Сурс - он и в пустынях Сурс.

+ Показать

Как видно из структуры - Сурс хранит свои ресурсы в VPK-архивах, которые по сути есть многотомные ZIP со свистелками.
Судя по обновлениям - скачиваются файлы целиком. Если добавляется новая текстура - скачивается новый tf2_textures_dir.vpk и один из tf2_textures_nnn.vpk. (обрати внимание на даты в первом столбце)
Так что таки первый вариант с почти что .pak файлами.
#14
19:08, 31 мая 2018

Delfigamer
> Судя по обновлениям - скачиваются файлы целиком. Если добавляется новая
> текстура - скачивается новый tf2_textures_dir.vpk и один из
> tf2_textures_nnn.vpk. (обрати внимание на даты в первом столбце)
Тоже не факт, может быть такое, что эти даты - это просто даты изменения на локальной машине. А изменяются эти файлы не целиком а по бинарным дифференциалам. В стиме же вроде как есть своя патчинговая система на дифференциально-бинарных патчах, на сколько я знаю, вполне возможно что для доты и кс она тоже используется.

В том же ue4 для скачивания создаются специальные HTTP чанки, которые вроде не превышают 1 MB, размер колеблется, и BuildPatchTool может создать сотни таких чанков для одного только pak файла. То есть для этой системы даже не важно один у тебя pak или разбито на много мелких, всё равно для обновления используются специальные чанки и на сервере располагаются именно эти чанки, а не pak файлы. Затем только измененные чанки скачиваются и затем как я понял система изменяет pak файл на основании этих новых чанков и создаётся новый pak файл - обновленный, пропатченный, и заменяет старый, но это пока не точно. Но сам pak файл целиком не качается. Вполне возможно что и в доте и в cs что то подобное.

UPD: сейчас вот что думаю... Ведь я изначально хотел использовать исключительно Steam для аккаунтов в своей игре, я не хочу реализовывать собственную регистрацию пользователей и техподдержку для них, и уж тем более я не хочу реализовывать собственную систему пополнения счёта на аккаунте. В том числе я не хочу разбираться как выложить игру на другие платформы: консоли, android, ios. Тут еще со стимом разобраться надо, до других платформ вообще времени не будет. Соответственно, раз будет использоваться только Steam, то :
- Не понадобится собственный файловый сервер для клиента и обновлений, стим предоставит место для этого и скорость скачивания в стиме тоже халявная.
- Не понадобится лаунчер. Хотя многие онлайн игры в стиме выкладывают в стим только свой лаунчер, а дальше уже через лаунчер используют свои аккаунты и сервера для файлов. Но так как у меня нет цели распространять игру не через стим, то я могу не делать лаунчер вообще. А сделать по типу доты или контры, которые обновляются через стим и запускаются сразу через стим, без лаунчера.
- Я не смогу и мне не понадобится использовать ue4 патчинговую систему, так как в стиме своя система для патчей и обновлений, на сколько я знаю.

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

Страницы: 1 2 Следующая »
ПрограммированиеФорумСеть

Тема в архиве.