Сетевая игра. Принцип построения.
 

Решили с товарищем замутить игру наподобие Crimsonland(стрелялка - вид сверху), но только с мультиплеером.
Собственно, вопрос: как правильно организовать этот мультиплеер?


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

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

В идеале - C++.
Как вариант - Java(не путать с JS).
Java с AS3 очень похожи, поэтому это будет наиболее логичный вариант.

Никаких доп. оболочек. Даже про ту, что вы пишете, с ExternalInterface - можете забыть.
Вы парни я смотрю отчаянные - можете и с++ рискнуть на сервер) Яву и C# тоже вполне можно.
Советую сделать втупую - клиент рендерит то, что сервер пересылает ему каждые н миллисекунд и отправляет команды управления. Там бывают ещё разные синхронизации, но они сложные и для вашего случая неудобные (напр. https://developer.valvesoftware.com/..._Networking:ru).
Читать программирование сетки. Вообще похоже читать надо будет ещё мноого. Было бы неплохо сделать не сетевую игру для начала, чтоб понять, с чем связались.

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

Скажу по собственному опыту. Я сейчас заканчиваю сетевую игру, игра пошаговая и из игровых команд там только сделать ход, атаковать и применить магию. Но при этом общее число команд (исходящих и входящих) состоявляет порядка 35. То есть они реализованы дважды на сервере и на клиенте. А версий протокола было порядка 15, так как я не достаточно хорошо продумал архитектуру и несколько раз переделывал. Но объем переделок резко сократился, когда был готов игровой движок и стало понятно как что и где.

Пишите сервер на java. Мой сервер в режиме эхо сервера выдерживает порядка 4500 подключений и обрабатывает от них около 100000 сообщений в минуту. так что скорости java вам вполне хватит. Я мог бы вам дать ссылочку на опенсорс проект моего сервера, но вы же все равно будете писать свой с блекджеком и шлюхами :)

Добавлено через 1 минуту
ну и напоследок, просто в обязательном порядке документация на протокол. Без нее будет тяжко

ramshteks а можно мне ссылочку для ознакомления? :)

https://github.com/ramshteks/javabyc...teks/java/cozy

Ух ты, спасибо большое. Собираю ссылки, так как планирую свою игрушку написать (в целях самообучения, не больше).

сохраните ссылку на меня, потому что толковой документации на сервер нет и если соберетесь использовать мой, то вам понадобится консультация =))

Я так и сделал :)

В грубом приближении все верно, только никакой дополнительной оболочки в клиенте (кроме самого флеш-клиента) не нужно. Флеш замечательно сам поддерживает сетевое взаимодействие. Скорее всего обмен данными будет организован у вас через сокеты. Во флеше они есть.

Ну вот мы добрались с ТС до нашей игрушки, наконец )
Вы вот тут советуете для начала оффлайновую версию сделать, чтобы понять с чем связались, но мы решили пока вообще раскурить сетевое взаимодействие:
написали сервер на шарпе - висит слушает подключения, все в разных потоках, все как надо... вроде ));
написали клиентскую часть на АС3 - рисует красные кружочки (свой и чужие), перемещает "свой" кружочек и отсылает инфу о его положении на сервер, который затем рассылает ее всем активным клиентам;
теперь запускаем сервер на компе1, на нем же клиентскую часть и коннектимся - все отлично, запускаем клиентскую часть на компе2 и коннектимся - все норм, но когда дело доходит до перемещений, то на компе1, на котором запущен сервер, все норм, а на компе2 перемещение "чужих" кружочков происходит с задержкой.
Собственно, вопрос - в какую сторону копать? И чего не хватает для понимания ситуации? кода может?

от сетевых лагов нет лекарства
можете вот тут глянуть
http://gafferongames.com/game-physic...orked-physics/
http://habrahabr.ru/post/135306/

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

Советую забить пока на лаг. Только посмотреть, почему же оно стало заметно, если эти компы в одной локалке, разницу должно быть сложно глазом заметить. И сделайте, что перемещение своих кружочков происходит тоже только по информации от сервера.
Моветон - это сервер с одним потоком. Проблема 10к существет только для веб серверов. 5к одновременных подключений к одному серверу - число для хороших серверов, хороших админов, которые их настраивают и очень хороших программистов сервера. Ваше первое число юзеров, которое должно держать - 100, 1000 - для не супер сервера - это хорошо, вам хватит.

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

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

Расскажите это эрлангистам. Там каждая функция в отдельном потоке. Не то же самое, что тред, но каждый поток может выполняться на отдельном ядре а то и на разных машинах.

Для вашей игрухи советую использовать протокол RTMFP (p2p).
Я считаю это лучший вариант как по скорости так и по затратам.. Не нужен сервер вообще.

По вопросам движка RTMFP писать мне в личку. ))

2 -De-, 5000 соединений и по 100000 сообщений в минуту в одну и в другую сторону от сервера на двух потоках это по вашему хорошо или плохо? Больше я просто не смог протестить, потому что ноут начал висеть

gloomyBrain отделить бизнес логику от логики ядра(поддержка соединения, отправка и прием сообщений) имея всего два потока можно без проблем, при этом не имея проблем с синхронизацией

Котяра, спорить даже не буду. Хотя сравнивать языки вроде Java и c# с эрлангом немного не корректно, я считаю, так как концепции совершенно разные на мой взгляд. Хотя помнится мне сервер на ерланге(erlyvideo) совершенно не справлялся с той нагрузкой, с которой справлялся сервер на джаве(wowza). К сожалению этим тогда занимался не я, я был лишь свидетелем того, что скрипя зубами, поборники идеи Эрланга, после потраченного времени на настройку эрливидео, покупали лицензию wowza, потому что после испытаний wowza выяснилось, что она работает на ура, в отличии от падающей под нагрузкой erlyvideo. Вполне возможно это лишь проблема erlyvideo а не эрланга, но все же есть над чем задуматься.

ramshteks, ни о чем. Что за сервер? Для веб серверов вон 10к описываются, ноут по идее вот где-то как у вас. Но если это игровой сервер, с сложной логикой у игроков и взаимодействием с БД, то скорее всего не в сетку упрётесь. Как у вас оно на восьмиядерный сервер масштабируется?

2 -De-, хороший вопрос, ушел думать. Ноут на котором проверялось пятилетней давности и в момент покупки не был самым новым. Отдельные треды создаются только на тяжелые синхронные запросы(вроде к бд или к файловой системе). Легкие же запросы от пользователей не требующие запросов до бд тред не создается. Хочу сказать, что проект на который я сейчас работаю, функционирует на базе сервера работающего по такой же логике. даже в пик(около 6000 юзеров онлайн) он не особо то и загружает выделенный сервер(всмысле машину)

Дык, сперва был один поток, потом стало два, теперь уже вроде и три не предел %)
А вообще интересно, что за игра, хтоь в общем? Обновления мира (ну вот примерно как у авторов топика) есть?

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

Автор темы что-то не хочет участвовать в переписке.. ))

они игру пишут, им не до снобской трескотни =)

Может и себе замутить игру.? )) Кто со мной? )

Пишите сами все, зачем с кем-то делится прибылью?

Ну мне нужен серверник и графический дизайнер... ))

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

Правильно считаешь ))

К сожалению, не получается достаточного времени уделять игрушке (
А почему именно так? Вообще интересно, как именно общение клиента с сервером должно быть реализовано: типа, клиент только отправляет инфу о нажатых клавишах, сервер же все обсчитывает и возвращает результат, а клиент отрисовывает? И еще вопрос: когда должен происходить обмен информацией с сервером? с какой-то заданной периодичностью сервер рассылает текущее состояние игры или же по поступлению команд от клиентов? Или пересылать не состояние игры, а изменения, как посоветовал gloomyBrain? Есть какое-то правило или как всегда для каждого случая нужно искать свой вариант? ))

А вот админы Destiny были не в восторге от того, как посоветовал gloomyBrain. Ну и ладно. Почила она в бозе.
Предполагается, что синхронизировать изменениями сложнее, чем пересылкой состояния.
Может накапливаться ошибка на тех же Number.
Но вы не сдавайтесь. Это кошерно.

zxcv, потому что это простой (главное) и надёжный способ. Иначе вы получаете веселуху с коррекцией состояния от сервера. Т.е. иначе на клиенте вы на пинг впереди сервера. И возможны ситуации, когда необходимы поправки от сервера, а их делать - долго и сложно. Например на клиенте ваш боец выстрелил первый и убил, но сервер считает чуток иначе. Или ваш боец занял клетку первым и не пропустил врага. Или подобрал лут первым. А так - на сервер идут команды, клиент сам ничего не предполагает, только рисует что сказали. Минус у такой системы - лаг между отправкой команды и видимым действием. Для шутеров такое достаточно критично. Для стратегий - не особо (т.к. интерфейс не тормозит, выделяете юнитов итп. без задержек). Старкрафт первый по-моему так где-то работает)
Скорее для каждого случая искать свой вариант.
Вот ещё байка: в казаках было настолько много юнитов, что передача их индивидуальных положений убивало сетку. Потому передавали действия юзера, типа как у него камера повёрнута и какую рамку он мышой обвел.
Передача всего состояния проще, но может перегрузить сетку. Передача изменений чревата рассинхронизациями (и тут из надёжных вариантов только не использовать вообще чисел с плавающей запятой =) Гибридные могут быть способы, типа раз в н секунд шлётся состояние, а не изменение, чай за н секунд сильно не разъедутся) Или если есть числа с плавающей запятой, то они - только абсолютное положение. Короче весело %)

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

dimarik, я конечно не слишком глубоко знаком с о своей гениалогией, но вопросы кошерности мне по национальному признаку не интересны. Могу лишь порадоваться что для вас это критерий.

А где можно поподробнее почитать про синхронизацию в первом и втором starcraft-е?