Black Bird
 

Посоны, привет!

Как уже некоторые знают - я получил работу в нехилой компахе на свою специальность. Теперь у меня универ и работа.. дальше я прихожу почти ночью домой, делать что-то большое нет сил и сильно не хочется.. Да и профита мало. Поэтому, все старые проекты, которые я делал и не закончил под большим вопросом. Тем не менее - у меня все зашибись, теперь есть деньги и почти все, что я хотел.

Сейчас немножко времени прибавилось и появилась возможность сделать какую-нибудь небольшую игрушку. Поэтому, не долго думая, я сразу решил разобраться с сетевой частью!

За ночь и сегодняшний день сделал "онлайновые" самолетики. По ходу изучения примеров у меня накопился такой огромный ящик вопросов.. и некому задать.



Самый большой вопрос, который возникал почти во всех местах, связанный се сетью: КАК ПРАВИЛЬНО?

Собственно на данный момент есть клиент и сервер.
Сервер может обслуживать сразу ряд клиентов. Работает реалтаймовое подключение игрока в мир и проработан дисконект. Сами самолеты летают на физике Bullet. Сама физика считается на клиентах! Сервер имеет только ряд функций по модерации игроков (кик, дисконект, репозиция игрока и тп) а также предоставляет подключаемым клиентам данные о других игроках. Нету никаких "угадываний нажатий клавиш", клиент предоставляет серверу свою позицию, а сервер раз в некоторое время отправляет всем клиентам информацию. Все это дело оформлено на UDP. Первое впечатление после работы с сетью: оху**ь.

Собственно не получилось решить самую главную проблему.
Дома стоит роутер на четыре компа. Каждый имеет свой такого плана 192.168.1.2. Поэтому работает только локальная сеть. Как все это дело можно оформить и не в локале? Пните в нужном направлении и сегодня вечером уже можно будет полетать, пострелять!

PS. Squid просто исчез!?

Ответ: Black Bird
 

Нужно иметь белый внешний IP, и пробросить на роутере порты (порт). Потом поднять сервер и коннектиться по внешнему ипу.

Ответ: Black Bird
 

уже неправильно, на клиентах можно считать только не геймплей-специфик части. считаем все на сервере :)
кстати, сервер ты на чем писал?

пс. скрин, как всегда, зачетный :)

Ответ: Black Bird
 

Поддерживаю.

Сервер должен отвечать за все просчёты влияющие на геймплай и доступность информации. Клиент же должен получать ТОЛЬКО ту информацию которую должен (если чужой корабль ушёл в инвиз, то слать инфу о его позиции НЕЛЬЗЯ, т.к. простой чит сниффа (симулируем пакет от сервера типо "противник 42 вышел из инвиза", и мы снова его видим).
Таких читов может быть куча и повсюду. Например если пытаешься стрелять во врага, и что-то стоит на пути, если проверку будет делать клиент и слать пакет стрельбы серверу, а сервер будет тупо стрелять - то тут wallhack легко реализовать.
В политике сетевых отношений, Клиент - это лох, который всё выполняет, раб, и лишь просит разрешения на то или иное действие, которое не факт что выполнится. А Сервер - это босс, он всё решает, и лишь он всё знает.
Сервер должен быть устойчив на любой спам, и любую ересь от клиентов и ещё других приложений. Должен качественно уметь отсоединять клиентов, и сообщать об этом также качественно. Проблемы большие будут на каждом шагу.

Сеть, это большой лес. Писать сервер на каком-нибудь блице, я настоятельно не рекомендую.

Клиент - это рендер.
Сервер - это мозг.

Насчёт соединений, есть возможности обхода NAT'а, но это не просто, блицом этого не реализуешь. Можно конечно сделать сервер отдельно, который будет обходить NAT, и паралельно с сервером запускать игровой клиент (как в HL, там на деле запускается dedicated сервер, как процесс, и скрывается консоль), тот кто хостит игру, на деле запускает сервер, и такой же клиент как и все другие игроки, и сам к себе коннектится.
Пока нету возможности обойти программно NAT, можешь забиндить сервер на прослушку любого IP (хз как в блице), далее запускать сервер на определённом порту, выбери какойнибудь 20ххх, далее, идёшь в настройки роутера, и там устанавливаешь port forwarding на свой комп, указывая порт сервера.
Для теста попробуй сам к себе зайти, но у клиента устанавливай внешний IP. Узнать его тут.

Ответ: Black Bird
 

Пропарился с роутером пол дня, ничего хорошего не получилось.
Сервер и клиент написаны на блитце. Не думал, что так все плохо будет с сетью. Намеки на организации архитектуры понял.
Блин, неужели все зря.

Ответ: Black Bird
 

Hamachi :)

Или как сказал МоКа Port Forwarding:
Нечто похожее на это:


Проверить открытость порта из вне можно тут:
http://www.canyouseeme.org/

Ещё бывает, что проблема не в твоём роутере, а у провайдера. Тогда при создании сервера надо чётко указывать ip на котором происходит слушание пакетов. Это можно делать например в RakNet (для Blitz3D есть? А на Blitz3D ли ты пишешь?)
Ещё посмотри у своего провайдера услугу "внешний ip". С такой штукой можно хостить что хочешь без запар вообще.

2-3 недели назад был

И да, рад тебя видеть! :)

Ответ: Black Bird
 

Читал статью какого-то мощного чувака, что все просчеты выполнять только на сервере. Сервер посылает каждому клиенту его данные, тогда будет синхронно, причем что бы исключить рывки при передвижении, нужно передавать не координаты объекта, а кнопки которые он нажал, а они уже обрабатываются клиентом! Короче это жесточайший гемор, я как то баловался танчики писал, что - то получалось, но я так и не осилил работу без глюков. При плохой связи, например получается, что кнопка как-бы заедает... При хорошей связи все окей. Мой совет будешь писать, держи клиент на удаленном сервере VPS, подключай 3G модем и тестируй, добивайся работы без лагов. Тот кто говорит, что на 3G нельзя добиться хорошей работы онлайн - это бред. Я играл в WOW с пингом 400.

Ответ: Black Bird
 

Ты видимо очень не внимательно читал, т.к. всё напутал.
Клиент шлёт изменение состояния клавишь, всё примитивно просто: игрок зажал вверх, игрок отпустил вверх, и т.п.
Сервер далее считает всё исходя из инпута, далее выдаёт игрокам уже координаты объектов. Выдача данных должна быть в виде снимков мира, в весьма постоянной переодичности.
Синхронности это никакой не даёт - клиент будет отставать сам от себя в ДВА пинга.
А действие других игроков в адрес тебя, будет на сервере обрабатываться с разностью в ТРИ пинга..
Поэтому есть разные методы синхронизации, сам термин называется dead reckoning.
Есть два метода - интерполяция, и экстраполяция. Первый подрузумевает плавное применение данных от прошлого до последнего данного в наличии. Как поняли тут будет задержка - отставание от сервера в ДВА С ПОЛОВИНОЙ пинга.
Поэтому есть экстраполяция. Это попытка предсказывания следующих данных на основе прошлых. Зная направление движения объекта и скорость - не сложно вычислить его будущую позицию. Но это не просто, нужно использовать сплайны.
Дальность предсказывания должна равняться ровно одному пингу между принимающим данные и сервером.
Даже собственные данные, применяются не сразу, а только как достигнут сервер на самом деле, но ещё не пришли на клиент - получается, что сам свои данные будешь силой задерживать во времени в размере своему пингу.
Таким образом все клиенты будут пытаться симулировать мир максимум приблизительно как на сервере в данный реальный момент.
Также отсылая например данные о выстреле на сервер, если это моментальный выстрел (не летящий снаряд), то сервер принимая данные, должен вычислять в прошлом, назад в размере на один пинг от посылающего, т.к. когда он посылал пакет с выстрелом, то основывался на состоянии мира в тот момент на клиенте, но сервер получит пакет позже на один пинг, поэтому он вежливо берёт данные из прошлого, и делает вычисления там.
На сервере нужно реализовывать машину времени, длиной в максимум секунду (имхо), с наличием всех времени зависимых данных на каждый тик за последнюю секунду. Например если у нас UPS (update per second) == 30, то сервер должен хранить времени зависимые данные со всех этих 30 тиков.
Такие данные как положение персонажа - времени зависимые. Или например жив или мёртв - тоже времени зависимое, т.к. игрок Х может умереть от выстрела игрока А у которого пинг 30, а игрок Б тоже убил у себя игрока Х, но пинг у него 200. Убили они его в реальном времени почти в один момент, но игрок Б чуток раньше (на 50 мс например). Но сервер получит сперва пакет от игрока А, и обрабатывает его в прошлом на 30 мс. Далее через ещё 120 мс после обработки, прийдёт пакет от игрока Б, который если вернуться на 200мс назад, убил игрока Х, который чуть позже также был убит игроком А, но ведь игрок Б раньше это сделал, а из-за пинга мы получили данные позже. Но ведь игрок Б - сделал это раньше.
Вот такой пример-парадокс. И таких парадоксов будет уйма, постоянно! Работать с сетью - это большой геморой, и приступать к кодингу сервера, без долгого штурма пачек бумаги и брэйнстормов с друзьями - тупо нельзя, иначе потратите время, потом переписывать будете.

Да и чтобы создать лаги - не нужно 3G, это очень просто симулировать, реализовав очередь при отсылке и приёме от сервера, внеся туда немного хаоса.

Ответ: Black Bird
 

Интересно а есть ли готовые движки для C++ на основе ГеймОбъектов как в BlitzMax?

Ответ: Black Bird
 

Это ты к чему и что за ГеймОбъекты?

Ответ: Black Bird
 

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

з.ы.

Ответ: Black Bird
 

В BlitzMax реализовано в виде объектов. Какая то хитрая система синхронизации, я уже не помню, баловался года 2 назад, но мне понравилось.
Имею ввиду сетевые движки для c++

Ответ: Black Bird
 

BlitzMax/mod/brl.mod/blitz.mod
Все исходники там

Цикл без задержек должен жрать 100% системы. ( while(True){} напиши в плюсах ) Если в цикле вызывать пускай даже незначительный Delay то управление быстрее перейдёт к остальным процессам в ОС и "жрать" программа на блице будет как положено.

На счёт пурика не согласен. Я считаю, что пурик дырявая неюзабельная кулебяка. Ничего стоящего на нём ещё не видел. Его внутренняя организация - чистой воды хулиганство. Для сервера рекомендую C#, Java ну или BlitzMax (благо он имеет весь нужный функционал) Если тупо потренироваться то можно и Blitz3D.

Ответ: Black Bird
 

Насчёт пурика - поддерживаю.
Рекомендую C#, ну или Java. Но по мне так с C# проще работать, и он в некоторых моментах конкретно лучше, а в некоторых (имхо менее значительных, хуже). Плюс msdn документация очень удобная.

Кстати, EVE сервер на пурике расписанный ;)

Ответ: Black Bird
 

серверу евы приписывают самые разные языки, от пурика до эрланга )