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

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

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

3eR0.1ive
> Парень вообще-то полностью прав.
То есть у вас сервер шлёт координаты всего что есть на экране в области видимости 30 раз в секунду, а клиент просто тупо ставит все в эти координаты?

#16
13:01, 21 мар 2012

Easy
> То есть у вас сервер шлёт координаты всего что есть на экране в области
> видимости 30 раз в секунду, а клиент просто тупо ставит все в эти координаты?
Не надо утрировать, интерполяция, и иногда экстраполяция есть, но это далеко не логика игры.

Правка: Ну и шлет он только о важных объектах информацию, не о всем подряд.

#17
14:53, 21 мар 2012

Логику можно разделить на несколько слоёв.
Корректное разделение никогда не портит архитектуру, а лишь делает её более адаптивной к изменениям и динамике поведения приложения.

Интерполяция и экстраполяция, как сказал 3eR0.1ive, не имеет ничего общего к игровой логике.
Игровая логика - это принятие решений, влияющих на игровой процесс и взаимодействие с другими игроками / окружением (в онлайн играх). Любая логика которая затрагивает игровой процесс и может влиять не только на собственный опыт но и процесс других игроков, то эти действия и вся их логика должна обрабатываться на сервере. Иначе как уже в нескольких десятках топиков на этом форуме упоминалось: будут проблемы с попытками ломать игровую логику, и делать решения на клиенте в обход логики приложения, например отсылать / блокировать, разные сообщения от клиента к серверу, тем самым придётся с ними бороться, что в итоге выльется в ещё больший объём работы, нежели просто реализовать всю ответственность на сервере.
Физика, которая имеет лишь визуальный характер - не является игровой логикой.
Даже UI по сути - это не игровая логика. Вот операции которые с ним производятся, и взаимодействие разных элементов UI - это уже логика, но опять она не обязательно имеет отношение к игровой логике. Например перемещение предметов в инвентаре - относится к игровой логике, а изменение визуальных настроек окна инвентаря через тот же UI, не относится к игровой логике. Тем самым первое, решается сервером, а второе клиентом.

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

akaAngeL
> Видимо ты не имел дело с написанием онлайн игр)
Онлайн игры можно писать на HTML + JS (Ajax), С++, других яп / скриптах и т.п., как p2p, сервер <> клиент, более сложные модели и т.п. Это всё на столь разные области, что обобщать их это немного наивно.
Понимать как что-то устроено с логической точки зрения, можно и не имея с этим прямого дела. И когда кто-то говорит что делать как-то иначе, а не как он, это значит не правильно, ну что тут скажешь. Видимо вы разрабатывали свой продукт влоб, и у вас клиент имеет ответственность, хорошо если пока не ломают. Потому что в крупных проектах, где крутятся деньги в игре, то тут уже сразу будет куча народу, желающих получать то что другие покупают, но за бесплатно.

#18
14:57, 21 мар 2012

3eR0.1ive
> Easy
> > То есть у вас сервер шлёт координаты всего что есть на экране в области
> > видимости 30 раз в секунду, а клиент просто тупо ставит все в эти координаты?
> Не надо утрировать, интерполяция, и иногда экстраполяция есть, но это далеко не
> логика игры.
> Правка: Ну и шлет он только о важных объектах информацию, не о всем подряд.
Тебя послушать, логики вообще нет на клиенте. Path Finding у вас где реализован? По-хорошему естественно на сервере. Но достаточно много примеров, когда он реализуется на клиенте, причем достаточно успешных примеров. Например (извиняюсь за каламбур) LOL. В том же баттлфилде каждая пуля - обьект, и стреляет то она на клиенте, сервер всего лишь проверяет могла бы она попасть в цель или нет.

#19
15:02, 21 мар 2012

MoKa
> Логику можно разделить на несколько слоёв.
> Корректное разделение никогда не портит архитектуру, а лишь делает её более
> адаптивной к изменениям и динамике поведения приложения.
> Интерполяция и экстраполяция, как сказал 3eR0.1ive, не имеет ничего общего к
> игровой логике.
> Игровая логика - это принятие решений, влияющих на игровой процесс и
> взаимодействие с другими игроками / окружением (в онлайн играх). Любая логика
> которая затрагивает игровой процесс и может влиять не только на собственный
> опыт но и процесс других игроков, то эти действия и вся их логика должна
> обрабатываться на сервере. Иначе как уже в нескольких десятках топиков на этом
> форуме упоминалось: будут проблемы с попытками ломать игровую логику, и делать
> решения на клиенте в обход логики приложения, например отсылать / блокировать,
> разные сообщения от клиента к серверу, тем самым придётся с ними бороться, что
> в итоге выльется в ещё больший объём работы, нежели просто реализовать всю
> ответственность на сервере.
> Физика, которая имеет лишь визуальный характер - не является игровой логикой.
> Даже UI по сути - это не игровая логика. Вот операции которые с ним
> производятся, и взаимодействие разных элементов UI - это уже логика, но опять
> она не обязательно имеет отношение к игровой логике. Например перемещение
> предметов в инвентаре - относится к игровой логике, а изменение визуальных
> настроек окна инвентаря через тот же UI, не относится к игровой логике. Тем
> самым первое, решается сервером, а второе клиентом.
>
> Я честно сказать, именно ММО игру, чтобы она была коммерчески успешна не писал.
> Но я достаточно поработал как с ММО проектами, так и с другими где разделение
> на логику и ответственно ещё важнее, т.к. не корректная абстракция может
> привезти к серьёзным проблемам (реалтайм система по контролю и мониторингу
> пациентов, пик был около 4к пользователей), возможность ломать систему
> происходят переодически, при этом неудачные.
> Один госпиталь попытался писать своего клиента для взаимодействия с нашим
> сервером, с попытками получения кучи информации, которой не должен получать.
> Например страничные списки, попытка получения всего списка сразу, и т.п. Такие
> решения клиент никак не может принимать, и это должно быть чётко определено.

Я опять скажу: что тут противоречит тому, что написал я? Логика клиента != логике игры.  Спор сводится к тому, что мы говорим об одном и том же, но с разных сторон.

#20
15:07, 21 мар 2012

akaAngeL
> Но достаточно много примеров, когда он реализуется на клиенте, причем
> достаточно успешных примеров. Например (извиняюсь за каламбур) LOL.
Примеров много.
И приведённый пример, вычисляет путь на сервере. Я уже писал в другом топике совсем недавно, как это проверить и доказать.

2 + 2 = 4
Это уже логика, согласен, но не игровая.

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

#21
15:13, 21 мар 2012

MoKa
> И приведённый пример, вычисляет путь на сервере. Я уже писал в другом топике
> совсем недавно, как это проверить и доказать.
ссылку.

А вообще оффтопим жестко.

#22
15:15, 21 мар 2012

MoKa
> 2 + 2 = 4
> Это уже логика, согласен, но не игровая.
А магазин и инвентарь, по-твоему игровая логика?

#23
15:43, 21 мар 2012

akaAngeL
> Path Finding у вас где реализован? По-хорошему естественно на сервере.
Не согласен, что "По-хорошему естественно на сервере"
Path Finding штука не самая легкая, поэтому серверу считать ее не надо.
Для защиты от от взлома достаточно проверить построенный путь, а это намного легче.

Вообще достаточно многое можно спихнуть на клиент, валидируя на сервере.
Еще пример движение игрока. Допустим, клиент шлет координаты своего движения серверу.
x1:y1, x2:y2 и т.д. Для простейшего контроля спидхака на сервере, можно просто проверить длину пути и посмотреть время, затраченное на него.

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

Хотя возможно в моих примерах есть дыры в защите, которые я не заметил

#24
16:26, 21 мар 2012

akaAngeL
> Тебя послушать, логики вообще нет на клиенте.
Есть, но неигровая.

akaAngeL
> В том же баттлфилде каждая пуля - обьект, и стреляет то она на клиенте, сервер
> всего лишь проверяет могла бы она попасть в цель или нет.
Откуда и инфа? Там скорее всего стреляет и на клиенте и на сервере, но попадания отсылаются только от сервера.

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

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

Иначе вас будут хакать.

#25
16:27, 21 мар 2012

akaAngeL
> ссылку.
"пожалуйста". ЗЫ, гугл индексирует геймдев весьма шустро, так что гугл осведомлён о таких вещах.
http://www.gamedev.ru/code/forum/?id=159544#m10

akaAngeL
> А магазин и инвентарь, по-твоему игровая логика?
Она влияет на взаимодействие с другими игроками, и изменение состояния собственного персонажа, что меняет игровой процесс. Следственно да, это прямым образом относиться к игровой логике. Глянь на основные примеры, перемещение предмета по ячейкам, осуществляется сервером, клиент лишь просит переместить предмет с ячейки X в ячейку Y. Проверить снова просто, при лагах поперемещай вещи в том же LoL, WoW, LA2 и т.п. крупных популярных проектах.

dakka
> Path Finding штука не самая легкая, поэтому серверу считать ее не надо.
Эта штука намного легче многих других с точки зрения затрат ресурсов. Поэтому если в игре нужен поиск пути, считает его сервер, т.к. это большая ответственность.

> Для защиты от от взлома достаточно проверить построенный путь, а это намного
> легче.
Проверить путь, может быть легче чем его проложить (зависит от метода поиска пути), но при этом создаёт те же дыры.

> Вообще достаточно многое можно спихнуть на клиент, валидируя на сервере.
Спихивай, и строй кучу проверок и валидаций на сервере, что лишь сделает логику более статичной и не адаптивной. Для обновления этих "общих" алгоритмов, изменениями на сервере не обойдёшься как это обычно в сильно развивающихся проектах сделано. Объём работ огромный. Для реализации общего механизма, придётся его разрабатывать на сервере, затем на клиенте, разрабатывать пакета, затем на сервере разрабатывать валидацию с кучей проверок. Что с точки зрения производительности не факт будет быстрее.
Когда можно придерживаться обыкновенного правила: сервер думает, клиент визуализирует. То при небольших изменениях игровой логики, меняется только сервер, при более больших, сервер и модифицируются пакеты, при самых больших и редких изменениях уже и клиент модифицируется, лишь коррекция модификаций, что является малым объёмом работы.
И в итоге в 2-5 раз меньше работы, с порой лучшей производительностью и отсутствием шанса взлома игровой логики.

> Еще пример движение игрока. Допустим, клиент шлет координаты своего движения
> серверу.
> x1:y1, x2:y2 и т.д. Для простейшего контроля спидхака на сервере, можно просто
> проверить длину пути и посмотреть время, затраченное на него.
Ты предлагаешь слать координаты постоянно?
Ты что-нибудь уже ММО писал, не локальной сети, а хотя бы с 128 игроками?
Слать координаты каждый такт это тупо расходовать траффик. Когда вектор перемещения может быть статичным, то достаточно серверу знать что игрок движется в определённом направлении.
Разная скорость игрока может зависеть от игровой логики, например шмотом, баффами (что ещё хуже), или всякие там например кувырки и т.п. Ты будешь это всё-всё проверять, это же сколько условий будет в проверке, чтобы знать возможную скорость перемещения? Плюс мелкие спидхаки легко возможны, на 20% так точно. По элементарной причине: сервер не будет жёстко считать, т.к. есть постоянно меняющийся пинг, что создаёт не постоянность данных. Тем самым делать проверку что скорость ДОЛЖНА быть например "20", когда у сервера был лаг, и он прислал уже свою новую позицию весьма далеко, ты его кикнешь? Или ты сделаешь на сервере степень отклонений, и поправки, что опять внесёт шанс спидхака как минимум на 20%.
20% скорости во многих играх, могут быть решающими.

Слать координаты - это давать право клиенту решать где он находиться, это нельзя делать ни в коем случае.
Слать нужно лишь Input, точнее "запрос/команду" собственному персонажу, в виде: "идиZ(-1 / 0 / 1)", "идиТуда(х,y)", "стрелятьТуда(x,y(точка в пространстве))", "стрелять(0 / 1)" - 1 зажал, 0 отжал, и вектор основан на том куда смотришь. Вот куда игрок смотрит, уже должно обновляться клиентом постоянно, в виде вектора или точки в пространстве, при этом тут нужно делать проверу на сервере, весьма простую на то чтобы клиент не реализовал autoAim. Многие игры от этого ОЧЕНЬ страдают, и редко когда могут защититься.
Таким образом, имея сетевой интерфейс "запросов" подчинённым сущностям, возможности чита просто нету. Всё что ты можешь читить, это визуальные хаки (валлхаки и т.п.), и это до тех пор, пока сервер чётко не шлёт только то что нужно, если шлёт лишь видимые данные, то проблемы этой не будет.

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

Дыры появляются сразу же, как только клиент что-то решает.


3eR0.1ive
> По поводу поиска пути, да делать на сервере, клиенту просто отсылать позиции,
> ну и интерполяция-экстраполяция для нормального визуального отображения.
>
> Вообще тут просто нужно разделить всю механику на 2 типа:
> - собсно игровая механика, которую нельзя давать считать клиенту
> - эффекты, все на клиент (причем под эффектами я понимаю даже расчет полета
> пули на клиенте, но только для визуализации, пакет о самом попадании
> есстественно сервер пришлет)
>
> Иначе вас будут хакать.
Блин, почему я так кратко и чётко выражать свои мысли не умею!? :D

#26
16:43, 21 мар 2012

3eR0.1ive
> Там скорее всего стреляет и на клиенте и на сервере, но
> попадания отсылаются только от сервера.
Стреляет на клиенте, проверяется возможность попадания на сервере (строится конус + расчеты баллистики).
>Откуда и инфа?
Давно еще читал разговор с создателями.
> По поводу поиска пути, да делать на сервере, клиенту просто отсылать позиции,
> ну и интерполяция-экстраполяция для нормального визуального отображения.
>
> Вообще тут просто нужно разделить всю механику на 2 типа:
> - собсно игровая механика, которую нельзя давать считать клиенту
> - эффекты, все на клиент (причем под эффектами я понимаю даже расчет полета
> пули на клиенте, но только для визуализации, пакет о самом попадании
> есстественно сервер пришлет)
>
> Иначе вас будут хакать.
Это же совершенно логично.

#27
16:53, 21 мар 2012

MoKa
> Проверить путь, может быть легче чем его проложить (зависит от метода поиска
> пути), но при этом создаёт те же дыры.
можно по подробней, в чем дыры?

MoKa
> Ты что-нибудь уже ММО писал, не локальной сети, а хотя бы с 128 игроками?
вот как раз сейчас пишу и обдумываю "за и против".
И давай спокойно разговаривать. А то у тебя такой тон, что как будто я тебя иголкой тыкаю каждый такт :)

MoKa
> Ты предлагаешь слать координаты постоянно?
с интервалом 0,5 сек например.
Допустим с "проблемой 20% спидхака" понятно.
Но если просто слать инпут, то можно получить проблему реактивного управления:
Игрок нажал бежать. Вдруг видит, что впереди лава. Он отпускает кнопку, но сервер команду не получил (из-за загруженности или большого пинга) и персонаж еще бежит. Персонаж упал в лаву, хотя игрок заранее остановился.
Даже если просто не упал, а управление тормозит за тобой - это уже может раздражать.
Что делать для таких случаев?

#28
17:20, 21 мар 2012

akaAngeL
> Это же совершенно логично.
Видимо мне нужно брать пример с 3eR0.1ive, и писать также кратко как он. Т.к. я писал абсолютно тоже самое..

dakka
> можно по подробней, в чем дыры?
Например при наличии дин. объектов, и генерации пути с учётом обхода. Обход будет строиться в реальном пути на близкий радиус. Реализовать возможность бегать всквозь. Это как один пример. Далее по геймплаю уровень может состоять из разной проходимости областей. Изменение пути влияет на логику. Например если в игре есть лава, на которую наступать нельзя, и отдаётся приказ идти через уровень, обычно поиск пути будет идти напрямую (пример игры в WC3, где нужно пробегать уровни аккуратно и быстро). Модифицируем алгоритм поиска пути на клиенте, помечая лаву как не проходимую. В итоге у нас идеальный поиск пути с обходом лавы. Примеров может быть много, зависит от игровой логики.

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

dakka
> с интервалом 0,5 сек например.
Для разных жанров это будет сильно варьировать от 0.1 сек до 1 сек. Поэтому нужно определиться с твоим жанром.

dakka
> Но если просто слать инпут, то можно получить проблему реактивного управления:
> Игрок нажал бежать. Вдруг видит, что впереди лава. Он отпускает кнопку, но
> сервер команду не получил (из-за загруженности или большого пинга) и персонаж
> еще бежит. Персонаж упал в лаву, хотя игрок заранее остановился.
> Даже если просто не упал, а управление тормозит за тобой - это уже может
> раздражать.
> Что делать для таких случаев?
Тут на "помощь" приходит оптимистичная консистенция синхронизации. Скорее не на помощь, т.к. реализовывать оптимистичную консистенцию в синхронизации это имхо, в 90% случаев лучший вариант.
Суть такова, что клиент всегда экстраполирует данные на один собственный пинг наперёд . Как собственные данные так и данные с сервера.
Важные решения такие как например стрельба и т.п. сервер вычисляет в прошлом, назад длиной в один пинг.
Таким образом, задержка о которой ты говоришь, равна пингу игрока, при этом на экране у него экстраполированные данные. Когда клиент захочет остановиться, у него на компе он будет немного обгонять данные с сервера, и поэтому на реакцию окажет влияние минимум 30-80 мс. Что практически никак не влияет на опыт игрока. При этом интересный факт, что когда игрок играет, степень задержки обычно постоянна, восприятие игрока и его реакция адаптируется к его собственному пингу основываясь задержкам действий. Таким образом например игроки с пингом в 30, не могут быстро адаптироваться к игре с пингом в 120. И наоборот. Что делает их реакцию, и принятие решений, автоматически учитывать пинг автоматически.
Но говорить о 50 мс, имхо это слишком..

При этом если ты передаёшь на сервер данные с интервалом в 0.5 сек (что очень редко), то этож как клиенты другие будут это дело экстраполировать? У них ты уже будешь давно в пропасти, и затем через 0.5 + (два пинга), резко портнёшся на край обрыва обратно..

Какой у тебя жанр и основные элементы перемещения игроков (мышка / клавиатура), это action или больше rpg игра?

#29
18:19, 21 мар 2012

MoKa
Жанр: MMOTPS с прокачкой, напоминающий http://www.realmofthemadgod.com/
Игроки бегают по карте (WASD) в реалтайме. Колижены учитываются только со статическим окружением.
Война идет только с мобами (PvE),
ЛКМ - стрельба: игрок кликает на точку на карте, снаряд из оружия "мгновенно" летит до цели (учитывается статическое окружение на пути стрельбы) и "взрывается"(наносит урон всем попавшим в радиус поражения вокруг точки попадания)
Т.к. геймдизайном задано, что более крутой - это тот у кого шмот лучше, реакция игрока не самый важный элемент геймплея. (Получается больше РПГ, чем экшен)
Хочу подчеркнуть, что задача боевки проверить не реакцию игрока, а его шмот и тактику (не лезть в пекло)

Задумка была следующая, главное на клиенте показать плавную картинку и отсечь наиболее наглые виды читерства,
поэтому движение передается координатами с интервалом 0,3-0,5 сек. Сервер следит, чтобы сквозь стены не бегали и скорость сильно не увеличивалась, думаю те 20% спидхака могут быть и не так критичны.

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

Что посоветуешь?

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

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