Не правда. Если не придираться к словам, то в TCP все, что было отправлено, будет получено. Именно для этого он и создавался. В случае неполучения пакета TCP отправляет его повторно.
Нет , повторный и последующие пакет тоже может не дойти по TCP если он не дошёл то вернётся ошибка , по UDP ошибка не вернётся.
Quote (zodiak)
В UDP же этот механизм нужно делать самому. И для его реализации тоже будут затраты сетевого времени.
так я написал если пакеты посылаются часто в равный промежуток времени тогда для UDP легко сделать проверку тех пакетов которые теряются и приходят вне очереди! шлём n пакет на сервер шлём n+1 пакет на сервер шлём n+2 пакет на сервер шлём n+3 пакет на сервер пришла команда от сервера что пропал пакет шлём n+2 пакет на сервер если там важная информация тогда шлём n+4 пакет + n+2 если важного ничего нет (например промежуточные координаты , которые сервер сам вычислил методом интерполяции по n+1 и n+3) тогда просто шлём n+4 пакет
В TCP при этом будут жестоки задержки - послали запрос на передачу пакета - ждём пришёл запрос , если сервер готов - посылаем пакет ждём ответ от сервер что пакет дошёл посылаем запрос на второй пакет...
если не дошёл тогда снова посылаем запрос Если так передавать движение то игрок помрёт от задержек!!!
Если у нас одиночное событие - например клиент посылает команду раз в несколько минут в произвольный промежуток времени то тут TCP выгодней.
Пулемётов на самолётах нет , если только их пилот с собой незахватит и под седенье не положит ... есть авиационная пушка наверно она находится тут http://s1.ipicture.ru/uploads/20120717/RQHTxrQ1.jpg
Фонарь пилот врядли сможет открыть в полёте чтоб пострелять ...
Тогда встает вопрос - что делать с нагибаторами, которые при отправке пакетов могут выставить неверное время отправки команды?
Простенькая проверка на сервере сравниваем полученое время от клиента с временем на сервере. Если отправленое время будит опережать время на сервере , тогда переносим игрока в локацию "тюрьма" и там его пытаем Если время запаздывает больше положеного (например у нас стоит граница в несколько секунд , а пришла команда что игрок начал движение час назад) - выкидываем этого игока в меня с окошком "соединение разорвано".
Сервер проверяет возможность выстрела (у игрока А достаточно патронов, между А и Б нет стен и т. д.), а затем вычисляет попадёт ли А в Б и сколько нанесёт
Пусть у нас есть такая ситуация: -Клиент посылает команду (скажем, идет вперед)
бьём по рукам такому разработчику ММО игры Например у нас движение по прямой: игрок кликает мышкой куда ему идти на сервер отправляется начальное время , начальные и конечные координаты и сразу начинает движение не дожидаясь отклика от сервера
сервер вычисляет есть ли другие игроки рядом и если есть то им отсылается эти параметры начальное время , начальные и конечные координаты
другие клиенты начинают отрисовавать движения , но с немного большей скоростью вначале , чтоб на конечной точке совпало время прибытия самого игрока и у других клиентов. Получается что другой игрок как бы побежал...
Передвижние по алгоритму А* с обходом препятствий - путь вычисляется на первом клиенте и передаётся начальное время и массив координат точек пути Всё тоже самое но остальные клиенты проверяют путь первого игрока чтоб не было читов (сервер путь и колизии вообще не должен вычислять)
Размер начального спрайта , размер комнаты , период синусоиды ? с массивами - например подсчёт времени при генерация произвольного массива из xx элементов yy раз.
Но нет никакой проверки на сохранность пакета. Быстнее, но ненадёжнее и небезопастно. К тому же пакеты легко перехватить. Если нужно гарантировать доставку и безопасность пакета то лучше TCP, если скорость то UDP. Ах, да это всё ИХМО.
Конечно это справедливое высказывание , но немного поясню - в реал тайме важна скорость (UDP) Пропал один два пакета - фик с ним , движение интерполируется по соседним отчётам , важная информация при пропадания отчёта может быть послана снова - если есть обратная связь (какой пакет пропал) В каждом пакете высылается номер пакета - это итак понятно. В итоге всёравно имеем быстрей чем TCP.
Теперь о птичках - TCP как ни странно тоже не гарантирует передачу данных! Грубо говоря отличие в том что TCP идёт 2 подтверждение что слушатель готов принять пакет и что пакет дошёл . Хорошо для редких пакетов , и скорость до 3 раз ниже. А в реалтайме несколько пакетов в секунду отсылается и не прырывно - вичислить что пропало легко.
Перехватить одинаково легко и TCP и UDP - шифровать пакеты надо
Pesets есть в интернете статьи с интерполяцией и апроксимацией с примерами в реалтайме для игр... Если в двух словах: То нужен протокол UDP , клиент жёстко синхронизован с сервером (посылает данные часто с постоянным промежутком времени). Пакеты обрабатываются (пропущенные отчёты апроксимируются , те что пришли не в своём порядке надо переставить). Если пропущен один или два пакет , то данные ещё можно апроксимировать , если больше - тогда соедининие рвётся. Ну и методом интерполяции в клиенте вычисляется движение других игроков по этим же отчётам.
GM 8.1 появился недавно года два назад и был переписан с нуля на С++ , до этого были другие версии и ини были на делфи ... и первые версии GM 8.1 были "глючные" , например баг с русским шрифтом они полгода исправляли ... Да и дело не в том что кто круче , появился бы какойнибудь старенький движок вроде HGE и уделал бы любой конструктор в тестах
Конструкторы Construct Classic &&. GM 8.1 созданы для быстрого обучения создания игр , а не для скорости. Для создания не большой казуальной игры они оба хорошо подходят, для создания МММОРПГ - они оба не подходят.
А вот если игра средней сложности , тогда неплохо провести объективные тесты между ними - сколько спрайтов могут отрисовать , сколько частиц , какая скорость обработки вычислений и тп Составить табличку со сравнительными характеристиками , добавить дополнительную информацию (стоимость , размер , дополнительные библиотеки...ну и исходники тестов , чтоб любой желающий сам мог потестировать) Пользователь посмотрит таблицу и выберет то что ему объективно нужно.
А в итоге только обсуждается "сферический конь в ваккуме"
Клавиши управления в бою 1 - переключение камеры на космосамолёт , с его панелью (если он есть) 2 - переключение камеры на турель 3- переключение камеры на мышку ( дополнительно появиться окно перемещени на глобальной карте ) M- включение глобальной карты (выключение любая клавиша 1, 2 или 3) Планируется бой космических флотов - игрок сможет брать непосредственное управление любой единицей при желании.
Зачатки редактора F2 вход в редактор Все объекты "замораживаются" на экране и готовы к редактированию. зажатая клавиша alt - перетаскивание объекта зажатая клавиша Ctrl и клик ЛКМ - добавление объекта (если он выбран на панеле справа) del и клик ЛКМ - удаление объекта ПКМ на объекте открывает окно свойств объекта (самих свойства на панеле пока нет , их буду "вбивать" как разработаю ГУИ ) Планируется сохранение/загрузка координат объектов и их свойств в dat файле. В будующем dat файл с картой можно будит передавать на сервер , от туда его может получить другие игроки. Почти как в ММО
Пробел - перезапускать комнату
PS. Сейчас буду заниматься долгим и нудным ГУИ, надеюсь он получиться.
До нового года ГМ ШТМЛ5 - представлял собой кусок ошибок (было бета тестирование) и сейчас если неошибаюсь идёт бета тестирование , но уже там много доработали и порезали баги ... а первые версии были в сентябре , а констракт 2 уже к тому времени был. Даже одно время пытались побороться с крякерами , но крякеры победили - в этом плюс ГМ
Не важно какой инструмент круче - важно подходит он или нет под конкретные задачи.
http://ru.wikipedia.org/wiki/Тип_92_(авиационный_пулемёт)
