|
TCP сеть
Всем привет.
Пробую изучить ТСП протоколы в блитсе, чтоб делать сетевые игри. Для элементарного понятия делаю банальный и простой чат. Командой HostNetGame(UserName$) создал комнату, а с другого компа зашел в нее при помощи StartNetGame() Первая проблема что пересылаются пустые сообщения, но это не столь важно, главная проблема, что прога жрет весь ресурс проца. И немного подвисает. А когда закрываешь ее то еще некоторое время она не отвечает. Проц (пентиум 1.8 одноядерный, но думаю не в этом дело) Вот немного кода. Это выдрано из главного цикла: Код:
Repeat |
Ответ: TCP сеть
Перед Forever поставь Delay 50 - не будет грузить весь проц.
Я директ плеем не пользовался никогда, но по-моему надо перед принятием сообщения еще проверять и его тип - NetMsgType() Код:
If RecvNetMsg() Then |
Ответ: TCP сеть
Епти как все просто. Сенкс...
|
Ответ: TCP сеть
Рас уж я создал эту тему то спрошу еще кое что:
1. Почему SendNetMsg имеет 99 разных типов? 2. Могу ли я в нормальной функциональной игре использовать только 1 тип? 3. И вообще, какая разница между разными типами? 4. Когда в справке блитса есть 2 отдельных категории DirectPlay и TCP. То это 2 совсем разных вида подключения? 5. Если 4 - да. Какой из них проще/лучше? 6. Какая команда мне поможет осуществить поиск рабочих серверов? (тоесть созданных игр, что то вроде кнопки Refresh в контерстрайке) 7. Когда на форуме редактируеш сообщение, то тема апается? Ну пока что вроде все. Заранее сенк. |
Ответ: TCP сеть
Вредный советик:
Если не хочешь мучаться, то используй RakNet (wrapper) Я пробую делать шутерок (сервер на BMax под Linux и Win, а клиент на B3D под Win) используя RakNet. Связь установлена. Просто теперь нужно обдумывать логику игры. |
Ответ: TCP сеть
Сенкс. Советик кульный. Но я считаю что сначала лучше самому освоить хоть на елементарном уровне логику: TCP, UPD, DirectPlay, а потом юзать библиотеки, потому что я не имею ни малейшего представления как в играх устроена сеть.
|
Ответ: TCP сеть
Не советую использовать Direct функционал для сети, это мало чего тебе даст в будущем, кроме как немного опыта в понимании сетевой игровой логики.
НО, тот же TCP будет намного лучше, но в блице им заниматься, это имхо большой изврат, многое приходится делать руками, очень не удобно, постоянно дублировать кучу всего. Те же пакеты, тебе для каждого придётся писать свой паковщик в бинарник (или текст, если трафика ваще не жалко, и пофиг на скорость коммуникации), и распаковщик в данные. Стабильность тоже очень низка. TCP - лучше, хоть и более низкого уровня абстракции. Вообще почитай описание в чём "прикол" того же TCP, и в блице он не столь низкого уровня как в более серьёзных языках. Другое дело, в сети очень важна логика самого взаимодействия и модели сетевых игр. Например есть peer-to-peer (p2p), когда каждый клиент соединяется с каждыйм другим клиентом. Клиенты считают у себя каждый всю логику, и лишь сверяют на соответствия, и при необходимости синхронизируют. А есть Server <> Client, когда все клиенты соединяются с сервером, и сервер считает игровую логику, а клиенты только визуализируют. Далее есть другая абстракция в сетевых приложениях, писсимистичная или оптимистичная консистенция. Что отличает то как ты работаешь с данными и временем. Учитывая такой фактор как пинг, и время задержки, клиенты могут тупо считать свою логику, и интерполировать данные которые приходят к ним. В p2p весьма сложно реализовать "честную" коммуникацию, т.к. в тех же шутерах, пинг в 200, имеет большое значение, и как узнать что тот клиент на самом деле попал, когда у другого он в другом месте. Поэтому тут важно делать очень много логических махинаций. Фиксированный цикл, с временным шагом, просчёты в прошлом и т.п. Есть оптимистичная консистенция, используется в сервер <> клиент архитектуре. Когда клиенты предсказывают (экстраполируют) данные вперёд на длительность их пинга. Стараясь этим симулировать игровой мир таким же как в реальном времени на сервере. Но отправляя данные на сервер например о выстреле, сервер всёравно должен возвращаться в прошлое на один пинг, и делать все вычисления в прошлом (тот же снимок состояния по времени, как и на клиенте когда он выслал сообщение). Крч это весьма геморно, и требует МНОГО практики и размышлений. Поэтому сетевых реалтайм игр очень мало от разработчиков любителей. И предупреждаю, что там будет намного больше подводных камней, чем вы можете предположить.. |
Ответ: TCP сеть
Блин, обрадовал:) Но большое спасибо за информативный пост.
Как я правильно понимаю TCP и есть: Клиент==>Сервер. Также я понимаю что ДиректПлей можно оставить и заняться чем то поважней. А протокол UPD это р2р? (где то слышал что для игр используется именно UPD). Также я слышал что протокол TCP гарантирует то что пакет обязательно придет от клиента к серверу или на оборот, но жертвует при этом скоростью. Сможет ли это гарантировать отсутствие этой проблемы: Цитата:
Ну и хотел добавить. Сейчас крутые разработчики поставили столь высокую планку на игры(особенно на соло прохождение), что разработчикам любителям не осталось ничего, кроме как радовать людей интересными и уникальными идеями реализованых в виде мультиплеера. Что я и пытаюсь сделать :) Вопросы в силе: Цитата:
|
Ответ: TCP сеть
Я так понял что это пользовательские типы - сделаны чисто для удобства, то есть сам определяешь: тип 1 - например передвижение, тип 2 - сообщение чата, тип 3 - выстрел и т.д.
Надо писать отдельную программку которая будет отслеживать состояние всех запущенных серверов. Тема апается, ага:) |
Ответ: TCP сеть
Цитата:
На главном сервере (создателя игры) хранится список онлайн серверов. Если кто-то создаёт сервер - посылается сообщение об этом новом сервере. Он вписывается в список серверов. Игрок проверяет этот список запущенных серверов. |
Ответ: TCP сеть
Цитата:
|
Ответ: TCP сеть
Цитата:
Цитата:
|
Ответ: TCP сеть
Протокол не имеет никакого отношения к модели коммуникации.
Протокол лишь реализует то как данные посылаются, а модель реализуется уже разработчиком. Хочешь посылаешь данные на сервер (c<>s) и он с ними работает и рассылает другим, а хочешь посылай данные другим игрокам (p2p). TCP - гарантирует доставку в посланной последовательности, и сохранности данных. Это реализуется разными механизмами, которые работают на операционной системе основываясь стандартам IEEE (не помню какому конкретно, википедия подскажет). Они созданы для того чтобы реализовать всю стабильность протокола. Учитывая их более сложное устройство и необходимость заботиться о большем колличестве вещей, они немного проигрывают в скорости протоколу UDP. Но UDP не имеет никакой гарантии, при этом этот протокол "слепой" - он не держит никаких соединений и т.п. Идентификация соединений также весьма затруднительная задача, и реализовать её нужно будет тебе самому. Когда тот же TCP, устанавливает соединение и поддерживает его на низком уровне. Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
ЗЫ, почитай статьи про сеть в интернете. |
Ответ: TCP сеть
та блин на сокетах пиши, самое чоткое дело, 13-й символ для идентификафии конца сообщения, первый символ - тип сообщения, остальное тело можно передавать в евент, ну там запрогать обработчик как надо. Сам юзаю, работает чотко, правда приходится протокол придумывать, но это не проблема.
|
Ответ: TCP сеть
Протокол свой нужно полюбому придумывать, готовых универсальных решений нету. Всё зависит от жанра, метода, протокола и т.п.
|
| Часовой пояс GMT +4, время: 03:13. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot