Все привет.Не так давно решил сделать простую много пользовательскую игру,просто для опытов =).В игрушке есть несколько пользователей которые бегают по карте и стреляют друг в друга.Погуглив я нашел пример реализации простого TCP сервера, рассчитанного на одно подключение. Сразу возник вопрос,как сделать его "много пользовательским"?Какие функции в sdlnet есть для этого,как устроен сам процесс взаимодействия между клиентами и обработкой данных на сервере и отправки данных по другим клиентам? Я уже понял как происходит обмен данными между сервером и клиентом и на оборот,но это все получается с одним подключенным клиентом. Как мне это видится-на стороне клиента уже есть некая карта с определенным идентификатором,на сервер кидаются координаты пользователя и идентификатор карты,ну а так же всякие координаты пуль и тп,сервер это все добро принимает ,обрабатывает неким магическим образом и всё это обработанное добро отсылается другим подключенным пользователям и на их стороне это все наносится, перезагружается карты и тп.
Слишком много вопросов, в связи с отсутствием представления и опыта.
Но выбрал ты задачку не простую, т.к. в ней будет задействована суть true-realtime игр, тем более action-like где синхронизация и экстраполяция очень важно, а на сервере нужна будет машина времени для хранения недавних данных для вычислений в прошлом.
Чтобы и этим голову не забивать, сделай лучше ОЧЕНЬ простое приложение затрагивающее сперва чисто азы сети.
Начни с простого API. Представь у тебя есть хранилище данных (сервер), и есть клиент. Попробуй сделать так чтобы клиент мог создавать данные (например крафтинг), смотреть свои и чужие созданные вещи, а также смотреть все вещи с фильтрами.
Как только сделаешь это, уже отпадут вопросы с общением между разными приложениями. Но там нужно будет разобраться с поточностью и синхронизацией.
Такой тип приложения будет иметь "пост-взаимодействие" с данными других клиентов.
Следующее, сделай чат с комнатами - тут с взаимодействием между клиентами станет на много понятнее.
Далее сделай PvE тип TDS, и лишь потом, перемещайся к PvP TDS.
Таким сценарием будет проще изучить с азов к сложному.
Спасибо за добрый совет,приму к сведению!!!
1) TCP и Realtime несовместимы.
2) Придется делать на UDP и писать свой оверхед для проверки пакетов
3) в SDLnet нельзя управлять блокировкой сокетов. Сокет всегда ждет до тех пор, пока данные не будут получены. Из за этого придется порождать по отдельному процессу для каждого подключения, где учавствует receive.
jamesryuji
> TCP и Realtime несовместимы.
Практика показывает об обратрном. Хотя бы взять игры на HTML5, где используется WebSockets которые основываются на TCP. Что уже отвергает "не возможность" реализовать realtime игр / приложений на TCP.
Примеров куча, также если создавать серьёзный MMO, то совмещают протоколы и разделяют по ответственности.
jamesryuji
> в SDLnet нельзя управлять блокировкой сокетов. Сокет всегда ждет до тех пор,
> пока данные не будут получены. Из за этого придется порождать по отдельному
> процессу для каждого подключения, где учавствует receive
Если это так, то автор на данном инструменте не сможет разрабатывать MMO-like серверное решение, а всё что нужно, это клиентский dedicated серверный процесс, который будет создаваться для каждой игровой сессии. Тут проблемы с NAT'ом. Такое решение используется давно многими проектами, правда сейчас стараются двигаться дальше. В CS, HL, UT и др. подобных проектах использовали такую модель.
Вброс:
UDP не нужен, это рудиментарный орган для старых 28К модемов и рваных телефонных проводов с потерей пакетов 90%. С повышением качества сетей UDP со временем вымрет как говно мамонта.
ТС: делай FPS на TCP никого не слушай. Потом еще освоишь и приструнишь Nagle и Ack delay, так как они не приспособлены для игр, и всё будет в поряде. IPv6 возможно скоро станет популярен и NAT будет не проблемой.
ЗЫ: единственно UDP понадобится для вещания, для чего он и нужен.
Тема в архиве.