Войти
ПрограммированиеФорумОбщее

Создание MMORPG сервера для клиента написаного на Unity3d (3 стр)

Страницы: 1 2 3 4 Следующая »
#30
19:38, 21 мар 2012

Пример отличный привёл, но в то же время он очень специфичен.

Там чистый PvE, и никакого взаимодействия между игроками. Каждый клиент обсчитывает собственного игрока, и шлёт серверу лишь данные о происходящем. При этом сервер их тупо рассылает другим клиентам.
Сервер считает мобов и рассылает клиентам. На мобов может влиять клиент, и "убивать" их (принимать решение), для этого видел читы в интернете, как убивали всех вокруг мобов. Опыта конечно за это не давалось, т.к. там ещё и сервер логически обсчитывал данные для валидации, но минимально, не награждая убивающего за убийство без стрельбы. Да минимум проверить это количество выстрелов не может быть меньше убитых мобов (это самый простой пример проверки). При стрелах что летят сквозь доп. проверки.

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

Сервер не считает кучу всего, а тупо доверяет клиентам, следственно в интернете куча хакков на эту игру.

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

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

Дело твоё, если тебя это устраивает, то это твой путь. Если ты рассчитываешь на долго растущий проект, то ставь ставку на ответственность сервера нежели клиентов.

Да и не MMOTPS, а MMOTDS.
Тоже работаю над этим жанром, но в почти чистом PvP с контролем туррелей и дронов.

#31
13:06, 22 мар 2012

С хаками в RotMG я знаком, я и не предлагаю повторять полностью их тактику.
Меня сейчас интересуют движение и атака.
MoKa
> Подобная политика между сервером и клиентом, делает клиентов
> рассинхронизованными,
что ты под этим подразумеваешь?
я поиграл внимательно с двух клиентов. Все что заметил - это запаздывание перемещения одного игрока на клиенте другого, в остальном все одинаково.
Если рассматривать с точки зрения движения - не вижу ничего страшного. Все отлично.

Теперь с точки зрения PvP и движения
(проверку кол-ва выстрелов, скорости, урона не рассматриваем, т.к. такие вещи я собираюсь на сервере проверять, а урон вообще считать именно на сервере, чтобы с генератором случайных чисел на клиенте не мудрили).
Клиент_1 атакует точку и заявляет, что тут есть клиент_2. Сервер может хранить кратковременную историю движения игрока и проследить по этой истории верность утверждения (ведь клиент также судит по этой истории). Конечно, если учитывать реакцию игрока, то тут полный феил, но, как я говорил, в бою у меня побеждает шмот, поэтому у меня главное, чтобы оружие не било на километр по площади два километра.
Я соглашусь, что в некотором пределе (твои 20%) возможность мухлежа сохраняется. Однако, считаю, что настройками я добьюсь снижения этого уровня до "незаметного". Игра - не ответственный техпроцесс, минимальные ошибки здесь допустимы.
Ввиду этих размышлений хочется увидеть обоснованные претензии по вопросам постройки партийного взаимодействия в PvE,  и даже наличия PvP.

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

#32
14:16, 22 мар 2012

dakka
> Также нельзя забывать, что реалтайм игра - проект нагруженный и для того, чтобы
> было больше людей сервер должен больше их тянуть, а, соответственно,
> неоправданная нагрузка на сервер тоже не к чему. Т.е. из двух зол надо выбирать
> поменьше в каждом конкретном случае.
ММО, изначально подразумевает огромный объём данных для обработки. И выбирать "меньшее зло", это по сути не выбор, а безысходность. Если присмотреться ко всем современных ММО, ты увидишь как там упростили и т.п. почти на каждом шагу, и на сколько геймплай там конкретный в каждом аспекте, просто потому что иначе будет совсем иначе. Многие идеи просто невозможно реализовать основываясь одной или другой сетевой политики.

dakka
> Ты же пока категорично настаиваешь, что проект с организацией типа RotMG -
> проект без будущего (по крайней мере я так понял мысль твоего высказывания).
Будущее есть, и очень не плохое, но только как PvE игра, без взаимодействия между самими игроками, если они не реализуют просчёты на сервере.

Насчёт рассихронизации. Возьми два листка бумаги, разрисуй шкалу времени, с секторами каждые 50 мс. Далее предположим у нас есть клиент_а с пингом 200, и клиент_б с пингом 75.
Теперь зарисуй начальное положение как если бы они не двигались долго, двух персонажей.
Затем основываясь политике в RotMG, клиент считает свою позицию сам, и шлёт серверу, сервер же рассылает остальным.
Получается что если клиент_а начнёт бежать вперёд, то на протяжении 275 миллисекунд, на клиенте_б он будет всё ещё стоять. И лишь потом начнёт идти.
И тут клиент_б решает стрелять в клиент_а, на 250мс (пока он ещё стоит), выстреливает, и у себя попадает. НО. Сервер получает пакет лишь спустя 75мс. А это уже 325мс спустя начальную точку. За это время клиент_а уже ушёл совсем далеко. На сервере же он уже как идёт последние 125мс, что тоже не мало, и хватает для уворота.
Ну допустим ты хранишь состояние мира на определённые отрезки времени (каждые 30мс (это 30 снимков в секунду)). Ну предположим клиент_б выстреливает на 250мс, сервер получает пакет спустя 75мс, на 325мс, и возвращается в прошлое округляя на отрезок снимка на 60мс что будет восьмой снимок на 240мс. В это время на сервере клиент_а уже начал чуток идти но клиент_б в это же время ещё этого не знал, т.к. получил данные о начале перемещения только на 275 миллисекунде. А клиент_а на 240мс уже давным давно убежал.
Так что получается, клиент_а у себя увернулся на все 240мс, на сервере он также увернулся на 40мс, а клиент_б у себя ведь попал!

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

Если нету ответственного, ты не сможешь реализовать толкового взаимодействия.
Не думай что это я настаиваю на эдаких "голяках", это не я. Это сетевой мир, такой он есть, и с этим нужно считаться. Поэтому многое не реализовано онлайн, всё в разы сложнее чем кажется.

#33
14:32, 22 мар 2012

MoKa
> Насчёт рассихронизации.
Вообщем, если закладываться только на PvE, то можно и на клиенте, если нужно еще и PvP, то все на сервере.
Да, теперь стало понятно, спасибо.

#34
14:46, 22 мар 2012

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

#35
13:56, 31 мар 2012

Вот сервер http://www.smartfoxserver.com/ и статья как сделать онлайн игру с помощью этого сервера на Unity 3D http://it-profity.ru/sozdanie-onlayn-igr-v-unity-3d-s-pomoshhyu-s… tfox-chast-1/
Свои мини игры можете выкладывать на http://m-gamer.ru

Прошло более 7 месяцев
#36
16:06, 29 окт 2012

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

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

#37
17:30, 29 окт 2012
Изображение

Воскрешение топика прошло успешно. В вашу группу добавлен 1 скелет-маг.

#38
20:22, 29 окт 2012

San4es
Ты и не догадываешься на сколько современные читеры и хакеры продвинулись..
Также, ты собираешься тратить тысячи $ для тупо обновления клиентов? Почему тысячи $ потому что доставить даже по 50мб миллионам пользователей - это не такая простая задача, и для неё обычно используется CDN который естественно не бесплатен.

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

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

Да и некрофилией попахивает..

#39
10:51, 30 окт 2012

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

#40
11:12, 30 окт 2012

а вот про синхронизацию клиентов друг с другом действительно ничего не знаю. это думать надо

#41
13:43, 30 окт 2012

Простая матиматика: 50 Мб, раз в неделю, на 1,000,000 пользователей.
Будет 50 * 4 * 1,000,000 Мб = 195,312 Gb. За месяц. Если использовать Amazon S3 -  То стоить это будет: 14,403.15 $ за месяц.
А т.к. это большой объём данных, то его нужно доставлять используя CDN - а это например Amazon CloudFront и тут мы смело эту цену увеличиваем так добротно. Почему, да просто потому что доставлять такой объём данных с тех же дата центров и инфраструктур что и твои игровые сервера - тупо сожрёт твой трафик, и твоя ММО обрушиться от недовольных пользователей с 2,000 мс задержки..

Далее это ещё раз повторяю не решает проблем.

San4es
> А мне кажется что
Тебе только кажеться, коммерческий опыт и практика успешных компаний показывает об обратном. Анализируй их решения и выбранные пути, и причины таковых, так будет проще.

#42
17:44, 30 окт 2012

Ок, как поступает Близзард, например? Как работает battle.net?

#43
19:02, 30 окт 2012

Крупные закачки, у них идёт гибритная связка CDN + Torrent'ы, пиирами являются сами закачивающие. Также они практиковали не редко такую методику: если ты качаешь триалку, то скачивается там около гига самого важного, игра уже будет запускаться, и в общем играбельна, при недостатки более качественной медии или вообще локаций, они будут позже догружаться. Там всё гибко, таким образом контент доставляется по пути.
Но снова, Blitzzard - огромная компания, и их прибыль с разного рода продуктов очень большая. В WoW 10 баксов в месяц (верно?), а это покрывает много чего, не только трафик но и сервера и т.п.
В Diablo 3 немного другая ситуация - там вливают деньги в игровой рынок для купли / продажи за реал, только нету возможности их от туды выливать обратно. Следственно это огромный накопительный банк.
Деньги у этих компаний есть, поверь мне.

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

#44
1:27, 2 ноя 2012

Да, ты прав, делать физику и игровую логику на клиенте реально невозможно в первую очередь из-за временных коллизий событий на разных клиентах.
Я вот только не понимаю, зачем крутые фирмы выбирают крутые движки для своих крутых игр, такие как CryEngine и UDK? Ведь в этих движках и физика и игровая логика рулит, не только графика. А крутую графу в принципе и в Unity можно сделать если сильно постараться, понаписать кучу плагинов (например Terrain в юнити желает оставлять лучшего). А еще клиент написанный на таких движках должен только рендерить и ничего больше лишнего, вот как из этих движков убрать все лишнее, чтобы и не просчитывалось и не компилировалось и места занимало меньше? Я пока не понял, нафига в SandBox'e Weapon equipment и как его оттуда выпилить и запилить какой нибудь другой инструментарий который будет другое делать создавать другие ассеты?

А вот как сделать сервер просчитывающий физику, это вопрос требующий крепкого продумывания Мое соображение такое: можно прикрутить Bullet к нему и он должен быть кластерной системой.

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

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