Разработка многопользовательских онлайн-игр

[orcpochta]

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

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

Начну, пожалуй, с малого - с игрового чата.

Как реализуется обновление таблицы пользователей в онлайне? Каждый раз, когда список пользователей меняется, по сокету кидается вся таблица пользователей (если 200 пользователей в пределах актуальной видимости чата, то по хмл-сокету летает хмл-ка порядка 50(+-) килобайт), или же это какие-то систематические интервальные рассылки? Или если не вся таблица, а конкретно, кто пришел или ушел, то боретесь ли вы с коллизиями, могущими возникнуть в случае, если кому-то что-то не дошло?

Добавлено через 8 минут
А можно ли предположить, что если сокет жив, то пакет гарантированно будет доставлен до адресата? Если да, то можно гонять не всю таблицу, а только инфу о том, что кто-то пришел или ушел, а в случае разрыва соединения при повторной установке сокетного соединения получать всю таблицу пользователей как при инициализации чата. Где при такой схеме могут возникнуть коллизии, связанные с неполучением данных адресатом? Какие еще могу возникнуть проблемы?

[etc]

Нахождение пользователя в чате — бесполезная для БД инфа, её можно тупо сунуть в memcache. Соответственно никакой нагрузки на базу.

[orcpochta]

Сообщение от etc

Нахождение пользователя в чате — бесполезная для БД инфа, её можно тупо сунуть в memcache. Соответственно никакой нагрузки на базу.

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

[etc]

Ну само собой приходящих кидать через команды типа addUser/removeUser. Чтобы что-то не доходило — я такого не помню. К тому же, tcp гарантирует доставку, в отличие от udp.

[-De-]

Сообщение от orcpochta

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

пока пост не захватят (но флейм смотрю тут суров, разве что холивар про архитектуру полезет)

Если можно слать изменение - надо слать изменение (про список). http://en.wikipedia.org/wiki/Delta_encoding какбэ
Стоит таки ознакомиться с http://en.wikipedia.org/wiki/Transmi...ntrol_Protocol
Протокол гарантирует доставку данных неповреждёнными и в правильном порядке (ну или сокет помрёт). Но т.к. мы работаем с потоком, то не факт, что данные придут одним куском (в случае XMLSocket это проблемы флэша и можно считать, что данные придут одним куском (не забудьте отделить их на сервере при помощи '\0'), в случае Socket надо об этом помнить и клиенту). Обычно чтоб узнать, жив ли юзер, юзер шлёт на сервер раз в н сек пинги (по протоколу возможна ситуация, когда взорвут соединение, через н лет восстановят и если по сокету никто ничего не слал, то сокет нормально продолжит работу).

[etc]

Сообщение от -De-

пока псто не зохватят

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

[orcpochta]

Сообщение от etc

Ну само собой приходящих кидать через команды типа addUser/removeUser. Чтобы что-то не доходило — я такого не помню. К тому же, tcp гарантирует доставку, в отличие от udp.

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

[etc]

Сообщение от orcpochta

- по сути должна работать нормально, да?

Само собой. Я бы сказал, что это так и работает везде.

[Котяра]

Вообще всегда так схема и работает (на зависимо чат это, или местоположение орков на локации или курсы валют на форексе)
При подключении сервер шлёт ( по запросу) текущее значение всех данных модели.
Затем посылает только апдейты модели.
Во всяком случае, это наиболее приемлемая схема по трафику итп.
т.е. имеем классический MС-V сетевого уровня.
клиенты - виды
сервер - контроллер
сервер - модель (БД или место в памяти или ещё что)

[orcpochta]

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