- kvakvs
- Постоялец
"Они у тебя еле двигаются" они тяжлые )), шутка, нет это просто семпл, с целью выжать по максимуму.
"но если стремится к кваке" ну шутер, там да, прийдется чаще. Делал аркадную стреллялку с отправкой не чаще 500мс, к сожалению не удалось провести бесплатно, забросил.
Но рпг мне представляется несколько иным жанром, в котором нет таких условий, когда ты прокачивался месяц, а тебя такой же лёлик завалил из-за угла за 1 сек. , как было написано выше про линэйж2.
В рпг наверно главное прокачка и длительные бои, в несколько секунд, даже может десятков секунд, в которых есть возможность ретироваться, если видишь, что вот-вот откинешься.
Damp
> Ну а аренда выделенного сервера с такими каналами, давно конечно прайсы не
> смотрел, но думаю не ниже 1000$ /месяц будет.
Однако же, если пишешь онлайн игру для коммерческого проекта, нафига его хостить у себя в городе, ещё и по таким ценам.
А дедики помню стоили за бугром от 50 до 150$ в месяц, а если проект только начинается, вполне можно купить виртуал сервер и не париться о трафике на первых порах.
Damp
> Kloun, рассуждения от части верны если речь о udp
я про TCP говорил. если считаешь, что не верны - расскажи почему (лично у меня все нормально работает согласно моим рассуждениям)
> для tcp в интернете интервал даже в 200мс думается фантастика при... да даже
> при 200 человек.
задержка не зависит от количества человек на сервере (может зависить, если она определяется "тормознутостью" сервака, либо забитостью канала, а чтобы забить канал, как я уже показал, надо под 100 сообщений в секунду каждому клиенту). Задержка определяется как правило скоростью канала клиента.
и во-вторых, я говорил не про задержки (про них упомянул, что для рил-тайм - это большой головняк), а про количество трафика
> . Канал легче всего забить таким мелким венегретом, вот тогда и появятся
> задержки.
сепециально для таких случаев работает алгоритм нэйгла
> Я всеже остаюсь при своей мысли "чем реже посылаешь, тем всем будет легче" ))
правильно. не надо посылать больше, чем это действительно не обходимо, но и не надо экономить в ущерб качеству.
зы.
если хотите ММОРПГ с большим количеством народа - речи не может быть про размещение сервака у себя дома.
Ладно, так мы окончательно автора запутаем )
Я бы наверно так сказал: было бы логично определить минимальный временной интервал, за который в игровом мире могут произойти действительно значимые изменения, он и может определить необходимое количество отправок.
>было бы логично определить минимальный временной интервал, за который в игровом мире могут произойти действительно значимые изменения
Мне кажется, что логичнее было бы отсылать каждый тип данных с определённой (или не определённой) частотой. Например, положение игроков надо слать часто (большая частота). Положение мобов можно чуть реже (низкая частота), а вот сообщения чата слать только при необходимости (неопределённая частота).
Если всё это ещё собирать в группы пакетов - получится вполне приемлемо, имхо.
Что же касается трафика - даже если сервер будет слать данные чаще, чем раз в секунду - трафик вполне будет на приемлемом уровне, имхо. Скажем, возьмём с большим запасом, что средний размер пакета 100 байт (а для среднего пакета это немало) и пакеты идут с частотой 10 раз в сек - получим трафик менее 10 Мб на одного клиента в час...
Средний размер пакета - потому что, например, 9 раз в секунду может отправляться по 20 байт, а один раз - сразу килобайт. Если интересует именно трафик - так будет считать правильнее.
Что же касается ширины пинга (задержки) - я согласен с Kloun, пинг как правило определяется не скоростью сервера, а лишь каналом клиента и кол-вом "хопов" между клиентом и сервером. Для сервака и 10 Тб в час отдавать не проблема, если железо нормальное и канал толстый...
slava_mib
> Мне кажется, что логичнее было бы отсылать каждый тип данных с определённой
> (или не определённой) частотой. Например, положение игроков надо слать часто
> (большая частота). Положение мобов можно чуть реже (низкая частота), а вот
> сообщения чата слать только при необходимости (неопределённая частота).
зачем положение слать переодически? 1 пакет - скорость + направление движение. и слать только в моменты "начал движение", "завершил движение"
(если речь конечно про ММОРПГ. в шутерах не прокатит )
>если речь конечно про ММОРПГ
если поинт-анд-клик - да. тогда вообще можно слать "идти от ... до".
>зачем положение слать переодически?
Но тут есть ещё один геморой, который с первого взгляда не виден - кто-то может начать идти пока ты его не видишь (скажем, когда он начал идти, ты был слишком далеко). Если не шлёшь положение периодически - получается он будет стоять на месте (для такого клиента), хотя на самом деле (на серваке) он идёт. А проверять на серваке "слал ли я этому клиенту то, что тот клиент идёт туда-то" - это вообще сервак сдохнет на одних проверках. Потому проще слать, чем не слать... 
slava_mib
> Но тут есть ещё один геморой, который с первого взгляда не виден - кто-то может
> начать идти пока ты его не видишь (скажем, когда он начал идти, ты был слишком
я это по-другому решил =)) пространоство делится на зоны. клиент видит только свою зону и смежные. вход в зону - событие на сервере. дальше думаю понятно =))
но вобщем у меня скорее "поинт энд клик". (бои не рилтайм)
Ага, от управления многое зависит.
Самый простой вариант кликами, действительно 1 раз отправил откуда-куда и куришь )
Чуть сложнее стрелками, слать откуда, направление и состояние кнопок, если были нажатия.
И самое такое требовательное когда есть мышь, тут уже только действительно периодически слать, при событиях клавы и мыши. К состояною клавы еще добавляется средняя угловая скорость, которую перс получил от движений мыши с момента последней отправки. Если допустить, что во время перемещений у персонажа может быть "люфт" в 1-2 его корпуса, что для рпг чаще всего можно, то тоже можно не так часто, пару раз в сек )).
>пространоство делится на зоны
у зон тоже хватает проблем. и это решение, опять же, именно только для "поинт энд клик".
В ММО обычно проще всего посылать от клиента серверу один раз данные о движении и дальше создавать предикшн вольюм, выйдя из которого клиент вновь отправит данные о своем перемещении.
Т.е. ситуация:
начали движение -> ушел пакет с положением и вектором скорости на сервер и всем видящим этого персонажа он оттранслировался, клиент и сервер начинает симулировать движение по этим данным
изменили направление движения -> вышли из предикшн вольюма (который обычно весьма небольшой) -> отослали пакет на сервер, начали оба симулировать по новым данным
повернули немного голову во время движения (вышли из предикшн вольюма по направлению взгляда, если это отображается в данной ММО, как это делается, например в ВоВе) -> отослали новые данные на сервер
сервер увидел, что мы вбежали в поле зрения другого игрока -> сервер отослал этому игроку данные о нас и нам о нем, дальше мы можем все симулировать на обоих клиентах и сервере
ну и т.д. еще можно раз в какое-то время (например раз в 5 секунд) проводить принудительную проверку положения каждого игрока, чтобы вносить необходимые корректировки, ну и это поможет найти кучу проблем с синхронизацией на стадии разработки.
На гамасутре есть статья, которая описывает подобную технику.
динамическая видимость, - зло : )
лучче статическая, тупо по квадратам (1, 9, 25)
пересёк границу, сработал триггер
указанные наборы квадратов можно симулировать чуть ли не в разных процессах
хотя как это сделано в ВоВ для меня загадка,
там границу между серверами бывает чётко видно когда одна из зон в дауне, но в штатном режиме на этой границе можно спокойно рубиться, посылать через неё стрелы и т.п.
Sh.Tac.
ИМХО полностью зависит от задачи. Можно делать статической разбивкой всего игрового пространства на квадраты/зоны и тупо оповещать обо всех событиях в видимых зонах, можно по набору зон просто оптимизировать перебор сущностей необходимых для разных операций (определение видимости других персонажей и прочее), можно делать динамическую разбивку пространства (квадтри тот-же), чтобы эффективнее обрабатывать инфу в густонаселенных местах.
А в ВоВе, насколько мне известно, отдельные игровые сервера только под отдельные местности: 3 материка, TBC-контент, баттл-группа и инстанс-сервер(а). Если у кого есть точные данные по этому вопросу - поделитесь, интересно.
Sh.Tac.
> там границу между серверами бывает чётко видно когда одна из зон в дауне, но в
> штатном режиме на этой границе можно спокойно рубиться, посылать через неё
> стрелы и т.п.
Это где же разные сервера граничат вживую? Всегда между серверами порталы или телепортационные границы. А визуальное продолжение сделано в виде кусков коридоров или пещер, до границы видимости. Иногда когда сервер тормозит, можно пробежать за портал и увидеть тупик.
Если уж падает сервер нортренда к примеру, то все в зоне отключаются, неважно в каком месте континента.
P.S. да, у меня точные технические данные ;) не просто данные наблюдений.
откуда интересно такие данные)))))
Тема в архиве.