Судя по голосовалке, больше всего юзеры интересуются программерской стороной вопроса. Очень странный результат голосования, честно говоря, не ожидал. Сложно начать трогать эту тему, потому что: Углубляясь в детали программирования, в особенности на каких-то конкретных языках, часто это превращается в нудятину для тех, кто новенький программист, и конечно же для тех, кто вашпе не программист. Разработка любого приложения всегда многогранна, поговорить можно о многом, начиная от архитектуры приложения и его интеграции с окружающим миром, заканчивая оптимизациями на уровне инструкций процессора в вашей пекарне, чтобы работало быстро. Сложно понять, что именно интересно каждому из вас. Игры бывают разных жанров, онлайн/офлайн, на разных платформах. Отсюда своя специфика и свои вопросы/проблемы, свои подходы к их решению. Поэтому будем идти от общего к частному. Новенькие должны понять общие моменты, понять с чего им начинать что-то изучать. Те, кто не программист, просто примерно поймут что за херня происходит, немножко расширят горизонт знаний. Ресурс ДД.ру все-таки имеет какой-то образ, и публиковать здесь материалы с обсуждениями, которые сюда не вписываются, странно. Поэтому определимся с тем, насколько глубоко будут затронуты вопросы именно программирования. Вопросы игровых механик наоборот, мне кажется требуют более жарких дискуссий, это больше соответствует данному ресурсу. Ну да ладно, постараемся взглянуть на все темы хотя бы в малой степени, а там как получится. Последнее время в голове у меня фоном крутятся мысли о серверной части онлайн игры, допустим браузерки, хотя как вы увидите дальше в последующих публикациях, серверная часть не так уж и отличается и для десктопных онлайн игрулек типа ла2, вов, eve, скайфорж и прочих. Давайте об этом и поговорим, надеюсь будет интересно. Ниже картинка, с котором все начнется, прошу прощения за качество, нет денег на хороший софт типа OmniGraffle, да и нет времени сидеть рисовать, думаю отруки тоже неплохо: Первое, на что хочется обратить внимание - это веб-сокеты, WebSockets. Сегодня об этом и поговорим. Между компьютером игрока и сервером устанавливается соединение. В целом это канал передачи данных в обоих направлениях, однако есть нюансы, которые полезно знать новичкам. Если вы откроете браузер и в строке адреса введете именованный или IP адрес, то браузер попытается установить подключение с передачей по протоколу Http, который предполагает тупое строгое взаимодействие запрос-ответ. Т.е. ввод адреса - это подключение с последующим запросом страницы, соответствующей адресу. На этот запрос браузер ждет ответ, и пока сервер не ответит, браузер хз че рендерить вам на экране. Сервер обрабатывает запрос и начинает отправлять вам ответ, по мере получения ответа, браузер приступает к отрисовке контента. Как только браузер получил ответ и догрузил контент по сторонним ссылкам (а это тоже отдельные подключения к другим серверам и Http запросы на получение файлов, вместо страниц), он отрисовал вам контент и замер, дальше никаких взаимодействий. Сервер ничего не может вам отправить, по протоколу Http ответ приходит только для конкретного запроса. Другими словами, чтобы обновить страницу, или получить другую страницу, или получить часть страницы, или нажать на кнопку и перейти в другую страницу - инициатором является запрос, т.е. браузер, т.е. вы. Согласитесь, хуйня, неудобно. Как тогда сделать, чтобы вы зашли на страницу в браузере, где есть другие игроки или целый игровой мир, и без вашей инициативы получать от сервера актуальное состояние этой страницы, мира с игроками? Как сделать так, чтобы без ваших действий, но при наличии действий других игроков, вам приходили данные от сервера и контент перед вами изменялся? Ответ в протоколе взаимодействия с сервером. Очевидно, Http запрос-ответ не подходит. Какой протокол тогда? Это веб-сокеты, WebSockets, и его поддержка есть во всех современных браузерах. Открыв веб-сокет соединение с сервером, вы открываете полноценное двустороннее подключение, с момента активации которого сервер может спокойно отправлять вам десятки/сотни/тысячи пакетов данных, даже если вы его об этом не просите. Протокол WebSockets весьма прост и экономичен с точки зрения трафика. Для разработки браузерки лично я вижу 2 варианта кодинга на клиенте в браузере - WebAssembly и JavaScript. WebAssembly, если в общем, то это технология, с помощью которой можно писать код для браузера на том же С++ и иных ЯП. Но мне кажется пока не стоит его использовать, т.к. он не распространен вообще и его будущее туманно. JavaScript давно и успешно занял свою нишу в браузерах (и не только), надежен, кроссплатформеннен, в принципе быстр за счет ребят из google и их V8 движка, развит, и по-моему на пенсию собирается не скоро. При этом на JavaScript есть огромное кол-во средств отрисовки контента, 2D/3D-движки, обработчики команд клавиатуры, мыши и т.д. В JavaScript коде на стороне браузера, веб-сокеты можно использовать с классом WebSocket. Примеры можно посмотреть здесь - между прочим рекомендую этот ресурс тем, кто желает изучить JavaScript. На стороне же сервера вы тоже можете использовать этот протокол, однако сложность его использования (кодинга под него) зависит от используемой платформы и близости к библиотекам уровня ОС в выбранной вами платформе и языке программирования. На стороне браузера у вас нет выбора, протокол реализован браузером, обычно он супероптимален и имеет много оптимизаций, просто используйте и все. Если же взять ваш серверный код, то тут все зависит от вас. Для выбранной вами платформы скорее всего будет готовое решение, которое бери и используй, но если вы такой же задрот и параноик велосипедист как я, то будете делать свое решение. Почему? Во-первых, потому что хочу, во-вторых, потому что стандартное решение будет универсальным, чтобы обеспечить поддержку протокола по стандарту, а там много лишней хуйни, в итоге куча абстракций, куча ненужного кода, куча хероты, которая тратит ценный ресурс вашего сервера - ЦПУ. Нам так не надо. Нам надо получить веб-сокет фрейм (сетевое сообщение), декодить его, вытащить из него сериализованный пакет, декодить сам пакет, отправить пакет в игровой сервис, чтобы он его обработал. Если онлайн игра предполагает тысячи игроков одновременно, то считайте ваш сервер уже high load и должен держать эту нагрузку. Наш сервер итак много тратит ЦПУ для вычислений игровой логики и объектов в игровом мире, не нужно дополнительно загружать его тупой работой по обработке сетевых пакетов. Стандартное готовое решение сразу съест уйму ресурсов, их останется меньше на полезные расчеты. Конкретно для веб-сокетов подойдет очень широкий спектр ЯП и платформ. С++, Java JVM, C# .NET (Core в том числе), JavaScript (Node.js), Go, Rust, Python и прочие. Скорее всего язык и платформу надо выбирать исходя из того, можно ли на нем написать игровую логику, которая вам нужна. Если ваша платформа и ЯП умеют в сокеты ОС (низкоуровневые объекты для работы с байтами, получаемыми и отправляемыми через сетевые устройства), то ваша платформа и ЯП уже подходят и видимо есть готовые решения, ну и вы сами можете их реализовать. Если ищете готовое решение, найти можно подходящую либу на том же github.com, перечислять не буду. Если вы не понимаете как найти для вашего выбора языка программирования, значит вам есть чему учиться и работу в этом направлении нужно сделать обязательно, причем самому. Если хотите писать свое (как я), то на Java могу посоветовать Netty, для C# могу посоветовать DotNetty (порт Netty на платформу .NET Core/.NET Framework). Почему Netty? Потому что это протокол-ориентированный фреймворк, который позволяет писать обработчики протоколов; если хотите, можно придумать свой протокол и реализовать его в нем. При этом во фреймворке уже есть шикарный бэкграунд утилит и классов. Для Java Netty уже есть решение для WebSockets, правда оно универсальное и не идеальное. лучше написать свое. Для C# DotNetty реализации нет (пока что), портирование в не очень активной стадии. Но фреймворк как база - просто шикарен. Ну и для справки, Netty находится в топ 10 веб-фреймворков в мире Linux по производительности обработки запросов. Для Go вот пример. Для Rust и других языков ищите по ключевым словам <ваш язык программирования> WebSockets. Так. Как работает сетевое взаимодействие, мы примерно разобрались. Теперь о сетевых "пакетах". Ох, какое же знакомое слово для тех, кто умел в ла2, и умел в ботов в онлайн-играх. В сетевую карту сервера, а в последствии в сокеты ОС, данные от браузера приходят не отдельными пакетами, а целой порцией байт определенного размера. Это такая оптимизация сетевого взаимодействия, чтобы не слать по 100 байт херни, а в течении пары миллисекунд подождать, и если было запихано 1000 пакетов по 100 байт, то все 1000 одним сетевым сообщением отправить. Таким образом среди 100 кбайт данных за раз, принимая сообщение на стороне сервера, вы просто хз с какого байта начинается пакет и на каком заканчивается, с какого начинается второй пакет и так далее. В случае с ла2, насколько я помню после изучения серверной Java части лет так 7 назад, пакеты имеют идентификаторы (id), и каждый пакет с определенным id имеет фиксированный размер. Т.о. при получении порции байт в сокет, мы читаем первый же байт как id пакета, все с этого момента мы уже точно знаем где он закончится и где начнется новый, читаем id второго пакета и знаем, где закончится он. Это типа свой особый протокол, придуманный хз когда и успешно используемый корейцами. Вроде бы в браузерке мы тоже так можем, но нет, браузеры не предоставляют возможность кодить прямое соединение с сервером посредством сокетов (не путать с веб-сокетами). В случае ла2, десктопный клиент открывает обычное сокет соединение уровня ОС с сервером, и общается с сервером по своему описанному выше (примерно конечно же) протоколу. Но в браузере есть веб-сокеты, о которых мы говорили выше. Что же они такое. Вот еще раз даю ссыль на описание и ссыль на официальный стандарт. Веб-сокеты - это такой протокол, в который вы отдаете допустим 10 байт сообщение и говорите, что это единственное сообщение без продолжения, протокол выделяет еще несколько байт, и первые несколько байт сообщения использует для кодирования размера вашего пакета, применяется ли к нему маска и какая (типа защита сообщения), а после уже пишет ваше сообщение (с применением маски, если она используется). Кому интересны детали протокола - прошу изучить инфу по ссылкам. В качестве итога - это экономичный универсальный бинарный (байтовый) протокол, который просто расставляет знаки препинания между пакетами данных, чтобы читающая сторона из 100 кбайт байт говна могла разобраться, где какой пакет записан. Что касается браузера и JavaScript, то в будущих темах обсудим какие 2D/3D движки стоят внимания, что они дают, что нам от них надо; обсудим как вместе с этим использовать веб-сокеты. На этом пока остановимся и определимся, стоит ли развивать эту тему и куда именно. Надеюсь причины акцента на сетевое взаимодействие понятны. Пожалуйста, пишите свои мнения, что вам кажется водой и о чем не надо писать многабукав, и на что делать акцент. Стоит ле разжевывать так подробно. Интересна ли эта тема дальше, или ну ее нафиг и давайте говорить Могу в рамках этой темы озвучить необходимые оптимизации и методики для быстрой работы веб-сокетов. Оптимизации, которых нет в универсальных готовых решениях, из-за чего пострадает производительность игрового сервера. Лично мне очень хотелось бы обсудить вопрос broadcasting'а сетевых пакетов - это когда 100 игроков находятся в одном игровом пространстве, подлежащем нотификации через пакеты об изменениях в это пространстве, но чтобы каждому из 100 на отдельное подключение не кодировать пакеты, их можно кодировать за 1 проход, а потом просто слать по сетевушкам, это очень экономно. Что скажете? Хуйня?
Комментируйте, задавайте вопросы. Если в теме по вашему мнению нехватает каких-то деталей, то спрашивайте, добавим. Если я о них не знаю, обсудим в комментах, разберемся, добавим к теме.
Игру не делаю. Думаю как бы делал, если бы взялся. В этой теме я описываю клиент-серверное сетевое взаимодействие, лежащее в основе онлайн игр. Описываю как я его вижу. Другие могут видеть иначе и знать больше - они расскажут свое мнение. Новенькие же могут понять базовые моменты, от которых оттолкнутся. Сегодня статья про веб-сокеты. Через какое-то время, например, про механики или что-то другое, хз.
я бы еще развернул тему потоков данных. Например записывать ивенты пользователей в кафку, а потом стримить эти данные на основе игровой логики на других пользователей по средством какого-нибудь стримминг фреймверка, по типу Flinka. А может заюзать акторов...
Мда. Зачем это здесь, тут же про тлен и безысходность.. Новичкам вообще нихера не информативно(и мы бы на спец форумы топать), а тем кто с опытом неинтересно. Ну если хочется поподымать ЧСВ, наверное ок
Довольно таки субъективное мнение (как и любое другое). По теме, мультиплеерные игры по типу мобы имеют схожий принцип, правильно? Мы принимаем пакеты от игроков, пересылаем их другим игрокам (если они соответствуют определённым критериям) = все видят что происходит, так? (я понимаю что это вопрос о самой очевидной вещи, но всё же)
В теме я написал, что больше соответствует этому ресурсу тема игровых механик и психология игроков. Программирование вообще тут странно видеть, поэтому нет кода в теме, есть только "общие" положения, которые призваны всего лишь дать понимание в целом.
Как минимум для тебя такие темы будут полезны. Нет, рассылка пакетов так не работает. Озвученный тобой принцип лежит в основе p2p, в сетях типа торрентов. В игровых проектах это работает не так. Ну это же странно, если игроки (их игровой клиент) друг другу отправляли данные, ты бы не смог защитить их от хаков. Нет. Сервер отправляет данные каждому игроку отдельно. Чтобы сервер понимал, кому какие пакеты с какой информацией слать, программная модель игрового мира соответствующим образом организуется, чтобы слать пакеты о например передвижениях игроков в каком-то объеме или игровой комнате. Но при этом какие-то игроки могут находиться в разных точках игрового мира, но состоять в пати, соответственно информация о ХП, мане, наличию баффов отправляется пакетами только нужным игрокам, даже если в противоложных точках мира, при этом чужие игроки вне пати рядом с одним из игроков из пати не получают эти пакеты. За все это отвечают модели пати, модели игровых пространств, игровых комнат. Скорее всего каждый отдельно взятый игрок в игровом сервере попадает и в определенное время исключается из списков рассылки пакетов по определенным группам определенных моделей игровых объектов. Честно говоря тут каждый сам принимает решение как это программировать, но думаю есть какие-то общеизвестные оптимальные методики. И оптимизацией к этому всему как раз служит broadcasting, массовая рассылка, когда сервер формирует пакеты для какой-то группы, а не для игрока отдельно, потом рассылает готовые пакеты одни и те же каждому игроку отдельно. Это дешевле, т.к. на если надо отправить 10 одинаковых пакетов 100 игрокам, то без броадкастинга нужно закодировать 10 пакетов по 100 раз, потом отправить 100 раз, вместо того чтобы закодировать 10 пакетов 1 раз и одно и то же отправить 100 раз.
Предлагаю отвлечься от сокетов, и поговорить о более принципиальных вещах, так сказать законах природы - которые никогда не позволят нам создать более-менее серьёзную ММО в реалтайме. И поговорить об этом - в разрезе функционирования современных сетей, начиная от юзера, и заканчивая сервером игрового клиента. Ибо только познав граничные условия - пределы возможностей - можно будет понять - куда двигаться дальше. Два основных ограничения - которые сегодняшней наукой непреодолимы принципиально - это скорость света, и расстояния - которые свету необходимо преодолеть, сиречь - длина магистральных оптиковолоконных трасс. Поговорим о максимальной непрерывной длинне оптоволокна - в котором сигнал может распространяться без коллизий, и оборудовании прямого и обратного преобразования электрооптического. И о времени - уходящем на эти преобразования. Давайте прикинем предельную сложность объекта "персонаж"- взаимодействующую с окружающим миром и другими персонажами, в разрезе нотаций биг-О, порисуем графики роста зависимостей сложности персонажа, пропускной полосы интернет-канала, взаимодействия с окружающим миром, и психологического комфорта для игроков из разных точек мира(тобишь свяжем с пингом и физиологической скоростью реакции). ЗЫ. Но если мы тут говорим о браузерке - то многое из этого нафиг не упало, т.к. там взаимодействий реального времени нет, соответственно и задержки в 1-2-5 секунд, легко компенсируются.
Звучит как стеб. Если бы ты предложил обсудить сетевые задержки и их влияние на реалистичность игры, то ок, можно было бы обсудить. Например, когда игрок нажимает на атаку другого игрока скилом Х, то пока сервер проверит, можно ли вообще нанести удар этому игроку, пройдет время, и для игрока, нажавшего кнопку, но действие произошло позже, вообще хз, херня а не комфортная игра. Как решать такие проблемы - да, интересно. Ты об этом? Или к чему мысли о "скорости света" да еще с привязкой к возможности разработки "серьезной" ММО, зачем? Мы не можем симмулировать реальный мир, не хватит не только вычислительных ресурсов, сам принцип вычислений в ЦПУ не даст возможности симмулировать реальный мир. Поэтому игровой мир и объекты в нем представляют собой модели, моделирующие поведение и возможности, которые важны для игры, но опускающие другие возможности, доступные в реальном мире.
Тут есть 3,5 землекопа, которые в теме и с десяток людей, которые поймут всё это. Остальные ходят сюда за тленом, брухлями, шовинистом и филипом плейном. Хочешь благодатную аудиторию, живых и умных комментов - создай цикл статей на Хабре к примеру, аля "Игорьразработка для самых маленьких". Если будет написано доходчиво, толково и интересно - будет спрос. Как пример там есть цикл статей "Сети для самых маленьких", очень годный. А ролевантной инфы по тем же вебсокетам в сети предостаточно, на тех же хабре и стаковерфло.
Спасибо, годно, но больше не надо. Хотелось бы гайда общей картине игростроя и как в него можно войти, как гейдизайнером или погромистом.
Это дельное замечание. На Хабре формат статей другой. Повторюсь, я ищу диалог. Для хорошей статьи на Хабре нужен готовый материал, решение, с замерами, аргументами, опытным использованием в продакшене. Да и статьи на Хабре пишут для привлечения в нимания в себе. Мне это нахер не нужно, ни там, ни здесь. У меня нет цели кому-то доказывать что-то и растить ЧСВ, я достаточно осведомлен в вопросах программирования, поэтому темка кажется обучающей. Но по другим темам геймдева я нихера не знаю и рассчитываю на диалог, в котором мои мысли дополнят, или обосрут, или опровергнут с аргументами - в итоге хочется какую-то сухую выжимку знаний. А здесь в принципе от нескольких человек можно получить годную инфу по механикам тем же, мысли о том, что цепляет их, по честному. Ну вот как-то так. Что касается веб-сокетов, то в свое время я не сразу узнал что это. В данной теме много воды, это очевидно даже мне, но первый блин комом, кому-то может пригодится и сэкономит время.
честн говоря Вы сударь херню сморозили, как Саб-Зиро при фоталити. Я считаю что такие люди как автор свет несут в пучины говна Королевства, они как мисионеры несут культуру и просвещение, нам, немытым черножопым дикарям, которые только могут кидаться в друга помётом или кидаться говном в вождя племени.
Мне кажется не годно. Гайда нет. Если хочешь войти в геймдев онлайн игрулек погромистом, то данная тема, мне кажется, полезна. Там очень много чего интересного, и сетевое взаимодействие - малая часть.
я тут подчерпнул для себя кое-что интересное, я учусь веб-программера, и так я полунуб в прогерстве, в этой я что-то понял для себя. А вот для совсем нуба в прогерстве ваша статья я думаю будет совсем непонятна.
Целью должно быть не изучение языка, а выполнение какой-то понятной практической задачи. Тогда ты не будешь хаотично смотреть на язык без его понимания, а будешь искать возможность решить подзадачи/задачу, понимая почему именно так в твоем языке это делается. Туториалов по ЯП много. Найди один и не смотри на сам язык, смотри на решаемую задачу.
У меня таки есть два вопроса. Перший: на сколько сложен будет рерол с веб-прогера на игро-прогера ?Второй вопрос: что перспективнее веб-пространство или игрострой?
1. Смотря что ты умеешь в веб и в какой игродел собрался. Если речь про онлайн игрули, то все не так плохо. Если только фронтенд, то надо запариться и подтянуть скил на серверную часть. Браузерную часть свояешь видимо легко. Если только бэкенд, то наоборот, серверная тебе будет понятна, браузерная - подтягивать. Если ты фуллстек разраб, то для базы тебе хватит, по моему мнению. Если игродел тебя интересует например под магазины типа АппСтора, то тогда конечно запариться надо, если ты не знаком с ЯП и платформой. 2. По кол-ву вакансий на том же hh, веб разработка более востребована всегда, потом сервисная бэкэнд+десктоп разработка (энтерпрайз тема), потом геймдев. По $ все иначе, геймдев вакансии более оплачиваемые, потом веб, потом энтерпрайз. Это что сейчас и в среднем, есть конечно исключения. Какие у кого перспективы, хз. Есть еще разные рынки. США, Китай и т.д. С геймдев темой на другие рынки заходить наверное проще. Веб и энтерпрайз разработка вряд ли, только внутри страны, может быть иногда в международной компании.
Мне было интересно прочитать. Так что не хуйня. Непонятен момент. Насколько тормозное соединение по WebSockets, что это делает невозможным создание реал-тайм игр в браузере? Или всё зависит от канала связи?
Ну вообщем ты меня обрадовал, потому-что я буду стремиться к фуллстеку в дальней перспективе ибо хочу в фриланс и конечно сесть на трахтор.
Затем, что многие до сих пор грезят нереализуемыми(принципиально причем) фантазиями о каком-то прорыве в ммо, тешат себя надеждами на VR. А по факту - есть вполне конкретные физические пределы - которые вчерне можно посчитать уже сейчас, сегодня. Чтобы четко понимать - вот это вот возможно, а батлы тысяча на тысячу - уже нет. Без разного рода замедлителей времени или иного рода квантования игрового процесса. Я понимаю - что объяснить экспоненциальный рост нагрузки на сервер в зависимости от количества скиллов неподготовленному игроку непросто - но почему бы не погрузиться в базис математики ? Сетевые задержки - многие просто не понимают основ, откуда они возникают и почему неизбежны в существующем интернете так-же, как дождь или восход солнца. Другие не улавливают взаимосвязи между пингом и лагами. Третьи не видят и не понимают взаимосвязи между разным пингом у разных игроков и балансом игрового взаимодействия как между игроками так и с мобами. Часто эти вопросы вообще непонятны игрокам. Обсуждать можно и то, и другое. Ты же хотел вопросов и тем к обсуждению)
Дело не в тормознутости. WebSockets используют обычное сокет соединение, которое контроллирует ОС, это обычное TCP/IP соединение, самое обыкновенное. Быстрее него например UDP, но он имеет узкую область применения, здесь не подойдет. Короче, WebSockets - это протокол передачи данных уровня приложения (поверх физического уровня TCP/IP) в котором на твои "полезные" 100 байт данных в пакете протокол добавляет не больше 8 байт своих для расстановки знаков препинания между фреймами (пакетами). Это очень экономно. Экономнее формат как в ла2, но на стороне своего сервера так сделать можно, в браузере реализовать протокол из ла2 нельзя, но там есть экономные WebSockets. В браузере можно сделать игру реал-тайм с использованием WebSockets. Откуда мысли, что так сделать нельзя?
Тут понимаешь как, чтобы дать тебе ответ на твой вопрос - сначала следует заметить, что ты его даже не задал. Т.е. ты видимо не понимаешь - что качественность соединения - понятие многомерное, и его трактовка - зависит от целей используемого соединения. Попробую раскрыть тему немножко, совсем навскидку. Наиболее частый параметр которым меряются в интернетах - это мегабиты в секунду, что он означает - интуитивно понятно, но вот качество этих мегабит - бывает очень, очень разным. Ньюанс первый - про который мало кто даже задумывается, редко у кого из пользователей коннект синхронный. Т.е. если у тебя 100 мегабит на скачку, это не значит - что у тебя 100 мегабит на отдачу. Зачастую аплоад ниже, и порой в разы. Ньюанс второй - под пингом - подразумевают скорость с которой пакет доходит от отправителя к получателю, но тут кроется ньюанс, и не один. Во первых - никто вам не обещал, что ваши кадры данных - будут идти в правильном порядке, и ситуация когда второй кадр приходит сильно позже 22-го, вполне нормальна для современной сети. Но пока все кадры составляющие пакет не будут собраны - пакет никуда не уйдет дальше, ни на обработку, ни на передачу. Отсюда вытекает второй ньюанс, реальное время между получением пакетов - различается, и иногда очень значительно. В игровом процессе же это может вызывать очень "веселые" вещи, например пули из автомата у вас будут вылетать с разной частотой))) Ньюанс третий - к качеству соединения отношение имеющий опосредованное. Пока ещё код пишут люди, и у нас, у человеков, очень и очень всё хуево с многозадачностью. В основном из-за примитивных мозгов - с детства не умеющих в два и более потоков. А так-как мы сами этого не умеем, то и алгоритмы наши - зачастую линейные, лишь в самых очевидных случаях приспосабливаемые для распаралеливания. В связи с этим - очень часты ситуации - когда сотня игроков на малой местности, начиная активно совместно играть - способна полноценно перегрузить неслабый сервак. Особенно если есть взаимозависимые умения, вроде цепных молний, или разного рода заражений/аур/мин с контрспособностями вроде отражающих дамаг, преобразующих дебафы в бафы - в общем всё то, что усложняет игровую механику делая её интересной. Как это связанно с пингом - когда у нескольких игроков нестабильное соединение, то сервер отправляя им данные или получая их от игроков - вынужден буферизировать целый ряд расчётов, запросов и ответов. В арифметической прогрессии увеличивая время на обработку этих висняков. А заодно увеличивая и время реакции на действия остальных игроков. Т.е. начинает лагать сам сервер. Это всё - очень и очень общие слова, надеюсь понятные. К слову - agar.io вполне себе реалтайм игра, с кучей игроков, в браузере.
Базис математики? Зачем? Сетевые задержки? Влияют, да. Есть методики нивелирования их для реалистичности игры. Есть игровые механики, которые позволяют другим игрокам не прерываться от игры, если кто-то отсоединился из-за качества связи - например Дота 2 и ддос на игроков. Ты вопрос задай конкретный, его и обсудим.
Затем, что наша школа, нас учит хреново, многие даже на ноль делить не умеют, в лучшем случае вспоминая пределы. Да о чем говорить - я тут сегодня опросил 5-6 человек, как оказалось - никто не в состоянии объяснить (потому что им не объясняли, а они не задумывались) что же такое - результат деления. Для многих - это так и остается 15:5 = три яблока каждому. Крайне ограниченные, да. Практически никем не используемые. Особенно ради игрового баланса. Назови мне хоть один шутер - в котором бы были использованы коэффициенты выравнивания пинга. Да у меня к тебе вопросов то нет - может только один, встречал хоть одну игру ммо жанра, с географически разнесенными серверами -локациями ? Мб не игру, крупный проект с распределенной БД высоконагруженной ?
Ну, вот такое ощущение сложилось от прочтения твоих и DemiChron-овских постов) Был неправ, исправлюсь! P. S. Пока писал ответ, вспомнил, что есть такая говноигра в браузере, как "танки онлайн", там реал-тайм бои.
Мне кажется ты находишься на стандартной позиции любого романтически настроенного разработчика, которому дают некую задачу, интересную, и он начинает фантазировать как можно ее так запилить как никто другой. Зачем разносить на разные сервера разные локации? Чтобы отдельный сервер мог быстро произвести все вычисления для игроков в этой локации? Блин, это все уже от идеализации идеи, игры, идеализации вплоть до полной симуляции реального мира со всем многообразием объектов и возможностей в нем. Конечно, в каждой игре игрок имеет какую-то цель. Если тебе нужна симуляция реального мира, то ок, да, хуй пойми как это делать, действительно есть фундаментальные ограничения. Мощнейшие компы мира трудятся над расчетами взаимодействия пары тысяч частиц, принимая во внимание все особенности известных физических взаимодействий. Куда там до реалистичной онлайн ММО игры. Если тебе нужна игра, цель которой предоставить фан игрокам, то достаточно упрощенных моделей (не 3D, а физ-мат моделей), по нужным свойствам примерно идентичным реальным, по остальным свойствам очень простым. Если тебе нужна такая ММО, то тебе не нужны распределенные высоконагруженные системы. Тебе не нужен онлайн в 1кк игроков. Бля, да любому начинающему геймдевелоперу и его проекту хотя бы онлайн в 10 игроков. Да. "Браузерка" не означает пошаговая, с чего вдруг? Браузерка не может быть динамичной? Просто с точки зрения производительность в браузере из 2D/3D доступны разве что WebGL, который затопчит даже хорошее железо быстрее, чем хорошо написанный десктоп клиент игры, наподобие ла2. Вся разница.
Зачем? Зачем тебе выравнивание пинга? Т.е. если я захочу заддосить твой игровой сервер, то мне достаточно подключаться к нему через самодельный прокси, который будет вводить нужную мне задержку - тем самым твой сервер будет ущемлять других игроков и увеличивать их пинг, чтобы всем игралось одинаково херово? По-моему все гораздо проще. Не надо приравнивать игроков. Игровой мир живет сам по себе, параллельно, асинхронно. Задержки по информированию кого-то конечно плохо, но это проблемы того игрока. Что касается реал-тайма, то. Предположим, что ты кодишь свою ла2. Встречаются 2 игрока на поляне. Ты хочешь динамики и реал-тайм. О чем ты хочешь сказать? Что игрок 1 нажимает на скил Х, на сервер уходит пакет, сервер обрабатывает действие, вносит изменение в состояния объектов, отправляет пакеты двум игрокам с изменениями для отрисовки. И типа для второго игрока пройдет на самом деле дохера времени, т.е. задержка отправки пакета от игрока 1 к серверу + задержка сервером по обработке ситуации + задержка отправки пакета игроку 2? В онлайн играх есть методики борьбы с этим. Во-первых в таргет механиках сервер при получении таргета шлет несколько дополниельных пакетов, что можно сделать с этим таргетом, т.е. отсечь варианты невозможных действий. Пока таргет висит, сервер может досылать пакеты с обновлением возможных действий. Во-вторых, при нажатии на кнопку скила, на сервер отправляется пакет о начале анимации и намерении вызвать скил, сервер может пробрасывать пакет о начале анимации всем другим, кто находится рядом и должен увидеть эту анимацию; пока идет анимация, сервер ведет расчеты (это очень быстро) и отправляет пакеты как кастующему так и таргету о том, что урон нанесен и конец анимации, окружающим же игрокам просто пакеты о конце анимации. Если сервер по какой-то причине понял, что урон нанести нельзя, то шлется пакет кастущему клиенту, анимация просто прерывается, урона нет - выглядит херово, но так делают, и самое интересное, что такое бывает редко. При такой методике, или схожих методиках, достигается реализм реал-тайма, плюс сама механика, предполагающая время каста способствует скрытию недореализма от глаз игроков, и при этом играть то комфортно! Если сетевые задержки какого-то игрока высоки, это проблемы этого игрока. В среднестатистическом, этой проблемы лет так 5-7 уже как не существует. А такие игры как ла2 вообще клепались во времена Dial-up и Accorp 56k с трафиком по телефонным линиям.
Почему три яблока каждому - это плохо? С учетом того что у нас тут в мире культ потребления и народ уже даже не пользуется школьной арифметикой, дабы оценить свою перспективу дожить до следующей зарплаты (не говоря уже о накоплениях). Вообще, википедия на этот счет говорит, что деление = отношение, только это отношение чего, делимого к делителю? Если у тебя есть какие-то тайные знания на этот счет, то было бы интересно почитать. Автору топика за простыню спасибо, но вообще на хабре есть несколько статей по разработке сетевых браузерок с вебсокетами, было бы хорошо оставить на них ссылки в тексте. И пользуясь случаем, спрошу, какие вы знаете 3d браузерки на webgl, которые не вешают браузер и не потребляют 99% CPU.
С хабром согласен. Я все-таки от здешних больше ожидаю интересных дискуссий на другие темы, не на темы программирования. Сейчас просто первой вышла эта статья, т.к. голосовали почему-то за программерскую сторону вопроса. Вот отобъет желание WebGL хз, думаю 3D в браузерах пока не популярно и не на такие широкие массы. Плюс браузерки часто нужны как кроссплатформ и на ПК и на мобилу и на планшет, а на последних двух 3D из WebGL смерть мучительная.
Черт, я нифига не понял. Не владею этой школой магии. Но за попытку почитать неведомый трактат поставил сам себе +.
Такие статейки надо с рисунками или гифками. Хуевая тема для диалога на дд ру. Надеюсь другие темки, где можно обойтись текстом, и где больше людей будут как бы с мнением, будут интереснее и понятнее.
Про рисунки и гифки это точно подмечено, нужно больше сисек и вареников, это больше элехтората привлечёт
Чо? Слыш эта, ты чо на раЕне тут делаешь? Семки есть? А если проверю?.. З.Ы. Кот, конеша, постарше некоторых местных и, несомненно, окружен аурой неземной охрененности... но не настолько, чтобы заводить детей на 5 лет старше своего рождения)
Да забей, технически не подкованным, вроде меня, ты хоть комикс нарисуй, мы нихрена не поймем. Тема то годная, вона как техномаги набежали обсуждать. Но а ты это, если там иллюзию накастовать надо будет или взлом разума заюзать - обращайся) Нет, воду не заряжаю - это чушь.