Сообщений в теме: 35

[Юля]

Скажите пожалуйста а возможно ли приобрести исходный код игры? Или будет ли это возможно в будущем? :oops: :?

[Terminus]

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

[Spose]

А у меня была возможность поюзать исходный код Но я не стал вредить людям Кстати Терминус, мое предложение на счет 3Д двига остается в силе!

[Vogd]

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

[Terminus]

Смогу, но это будут довольно общие советы, ориентированные на TCP/IP, и без исходников

[Vogd]

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

[BitRate]

Мну бы тоже не отказался прочитать эту статью 8)

[sokol_jack]

И я поддерживаю.
А то раздел "Статьи" давно не обновлялся. :wink:

Даешь статью!

[BitRate]

Даешь статью и много-много пива :shock: 8)

[Terminus]

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

P.S.: Сайт тут может полежать пару дней за неоплату, так что без паники...

[Vogd]

О чем хотелось бы знать:
1) сервер для каждого пользователя создает свой поток или все в цикле?
2) где юзается TCP, а где UDP?
3) есть ли процессы, которые инициализируются и на сервере и на клиенте, а далее развиваются одинаково без передачи данных, только в ключевых моментах происходит синхронизация?
4) на чем построена база данных с сейвами персонажей?
5) передаваемые блоки данных кодируются? сжимаются? если да, то какими алгоритмами?
6) расскажите о подводных камнях? о вещах, казавшихся очевидными, из-за чего их потом пришлось переделывать...

[Terminus]

Ну так я, пожалуй, на все вопросы и отвечу тут...

1) На одного клиента - один поток. Это особенность функционирования библиотеки Indy. При количестве клиентов в 2-3 сотни это не страшно. При большем может быть плохо . Хотя это все вопрос производительности...

2) У нас юзается только TCP. У нас практически нет данных, которые являются "необязательными", т.е. тех, которые могут не дойти, и ничего страшного не произойдет. Есть несколько исключений, но они происходят так редко, что организовывать ради них отдельный канал передачи данных нецелесообразно.

3) Нет, таких параллельных процессов нет. Есть только данные, которые расчитываются на сервере, и на клиенте (например, характеристики персонажа, значение ползунка жизни над головами персов). Такие значения, будучи изменены читерами, никак не повлияют на процесс игры и вызовут только глюки у клиента.

4) Сами аккаунты хранятся в MySQL (в непубличном варианте сервера, который пока не выкладывался). А вот предметы инвентаря/банка думаем хранить в файлах, т.к. иначе база грозит вырасти до безумных размеров... Да и на запросы уходит весьма конкретное время.

5) Во-первых, отключен Nagle-алгоритм. Во вторых, для минимизации затрат трафика на заголовки TCP-пакетов, от сервера к каждому клиенту уходит не более 10 физических TCP/IP пакетов в секунду. Исключение - пакеты с пингом. Реализовано это следующим образом. У сервера есть исходящий буфер (на каждого клиента). В секунду от сервера может уходить до нескольких сотен игровых пакетов, но они не отправляются сразу, а дописываются в конец буфера. Раз в 100ms сервер отправляет накопившееся сообщения в виде одного TCP пакета. Причем если размер пакета превышает 50 байт (или 100, не важно), пакет сжимается ZLib'ом. В будущем добавлю шифрование. По понятным причинам я не могу назвать конкретный используемый алгоритм (хотя когда то уже упоминал), но могу сказать, что юзается библиотка DCPCript (кажется так). Соответственно, клиент, принимая большой пакет, раскладывает его на множество мелких игровых и обрабатывает со скоростью 500 в секунду.

5) С этим сложнее... Таких явных подводных камней вроде не видно... Главное - отрубить сразу Nagle, а то я очень долго не понимал, почему при минимальной активности персов начинает рости пинг.

[Vogd]

Гм.. довольно исчерпывающе, спасибо. а что с передачей данных с клиента на сервер? тоже не чаще 10 в сек?
И еще, весьма интересна зависимость между
- скоростью соединения,
- количеством игроков,
- пингом,
- размером игрового пакета.
То есть какой должен быть размер пакета, чтобы при N игроков и известной скорости соединения пинг был не выше 200, чтобы не лагало. Для клиента этот вопрос понятное дело.
Это не простой вопрос, поэтому ответ устроит приближенный:)

[Terminus]

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

Я расчитываю на трафик в пределах 2-3KB в секунду. Можно попробовать посчитать, что это означает на практике... Итак, самый большой поток данных идет во время движения персонажей, т.е. "труба" наступает тогда, когда мноэжество персов начинает бегать вокруг. Персы двигаются, насколько я помню, со скоростью 3-4 клетки в секунду (максимум, при нулевой загрузке). Ну, будем считать по максимуму, 4... Один пакет сведений о перемещении юнита занимает 6 байт. А мы имеем условный предел в 2.5KB. Из этих 2.5 надо сразу отнять размер 10 TCP/IP заголовков. Ну, путь они по 100 байт (с двухкратным запасом). Итого - 1KB на заголовки. Осталось 1.5KB для данных. Один пакет - 6 байт, значит в наши 1.5KB влезает 250 пакетов. Это эквивалентно примерно 50-60 игрокам в зоне 70x70 клеток вокруг игрока. Если учесть, что реальная средняя скорость передвижения будет ниже, что на заголовки можно отпускать не 1KB, а 0.5, что модем 33'600 вполне пропускает и 3KB, допустимый порог еще возрастает

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

Ну вот разве что так . Подробнее трудно...

[BitRate]

Спасибо за ответы 8)

[Terminus]

Осталось только добавить, что трафик сильно зависит еще и от того где именно сосредоточены игроки. Т.к. если игрок забредетв какой-нибудь дальний уголок мира, трафик будет такой же, как будто на сервере никого больше и нет...

[Vogd]

ага, спасибо!

[Vogd]

Здрасте! А у меня еще вопросы родились, которые в интернете что-то не очень хорошо освещены, я уже дня три как ищу ответы на них... Только в этот раз по графике. Вы разобрались с тем как сделать бутерброд Res=Src1*Mask+Src2*(1-Mask), если Mask - отдельная текстура? Вроде блендингом можно, но Вы вроде пытались сделать через расширения, так вот, можно ли такое сделать, но не через шейдеры, а через ARB_texture_env_combine? и еще... с PBuffer'ом проблем не было? и откуда Вы брали glext.h wglext.h, а то в моих не все описания функций... Спасибо.

[Terminus]

С бутербродом разбираться не пришлось, потому что такие преобразования у нас не используются . Была идея выводить таким образом тайлы, на я не стал разбираться.

С PBuffer'ом была только одна проблема - нужнсделать glShareList (кажется так), чтобы списки текстур на всех контекстах были идентичны. А то модель будет выводиться в буфер, а текстура - нет.

Указанных файлов у меня нет, ибо пишу на Delphi

[Vogd]

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