Ну, у нас уже есть нейросеть, можно ею устранять коллизии на месте, а от сервера будет поток кривых-косых моделек, составленных из некого универсального набора в нашем компактном клиенте… Вопрос производительности, можно ли устранять их достаточно быстро?
Про Flash William_Godwin написал выше, и тут я согласен — так вообще делать нельзя =) Для ММО с графикой такой подход не имеет смысла: в клиенте есть и интерпретатор и данные. Если их разделить, данные придётся подгружать в кэш и держать его — он займет то же самое место. Только схема взаимодействия усложнится, а это производительность. Клиент точно так же обновится после патча перед запуском, как все и делают.
Возможно, он хочет сделать много игр под копирку с одним клиентом, разными серверами и разным набором, собственно, данных: моделей, текстур, объектов. Ну будет тогда у него пять игр и клиент на 1 Гб, который будет докачивать еще по 25 Гб за каждую. На пяти играх сэкономится 4 при общем объёме данных в 125. Экономия Века! ^_^
Вся графика сегодня это векторные вычисления, а последний этап выведения данных на экран — растеризация все равно пользует много именно векторных вычислений. Суть в другом. Если мы хотим модель она должна где-то у нас быть в памяти GPU в виде буфера\массива вертексов. Как она туда попала вопрос второй. Сегодня уже сеть такая штука как мешшейдеры, которые может даже способны будут создавать объекты прямо на GPU по команде\схеме CPU. Но апять же тут нужна аппаратная поддержка того же Vulkan.
Ну ладно, допустим, что у нас есть много универсальных элементов, как вот в «марширующих кубах»:
Но в таком случае у вас появляются проблемы с LOD-ами, анимациями и т.п… Кроме того, миры, состоящие из огромного массива данных сложно передавать по сети всем игрокам, особенно, если игрокам позволено вносить крупные изменения в сам мир. Вообще это такой, не то чтобы парадокс современного интернета, но проблема: мощности вычислений растут на много быстрее, чем каналы передачи данных к пользователям.
Мне лично хочется видеть вот именно такие рассуждения под рассуждениями другого человека — осторожные и содержащие собственные доводы. Спасибо. Я тоже пока не понимаю, как можно избавиться от клиента, если только это не набор консольных команд и текстовые ответы сервера, как в MUD. Я тоже пока не понимаю принципиальную разницу между скомпилированным клиентом и закачкой своих игровых ресурсов в универсальный интерпретатор, типа Flash. Не утверждаю, что её нет, но пока не понимаю. И это точно не облачный гейминг, то есть не трансляция видеопотока на экран через интернет, потому что Раф об этом чётко говорит в первом абзаце.
Голдберг говорит, что у вас должна быть возможность выстрелить в атакующего вас, промахнуться, попасть в дерево и увидеть, как дерево загорелось. Вы также можете во время боя попасть в дамбу, пробив в ней дыру, оттуда хлынет вода и потушит огонь. В следующий раз, когда вы войдёте в игру, дамба будет всё ещё разрушена.
И тогда уже напрашивались параллели с Dwarf Fortress. Если они реально двигаются в эту сторону, но на уровне мультиплеера и с социально-геймдизайнерскими наработками Рафа, прекрасно. Но, опять же, пока мне не очень понятно, как универсальный тонкий клиент этому помогает. Как он помогает более простому распространению, мультиплатформенности и прочим штукам, понимаю. Как простая графика высвобождает существенную часть ресурсов, понимаю отчасти, хотя тут тоже, скорее, вопрос передачи данных, потому что Вальхейм прекрасно продемонстрировал возможность улучшения низкополигональной графики современными эффектами даже средних GPU. Но, как я уже сказал выше, какие-то вещи я лично готов принять на этом этапе на веру (хотя не требую того же от других, разумеется).
Не успел отредактировать — допишу:
я могу себе представить третий вариант в виде конструирования объектов из базовых элементов на клиенте, без моделей, с помощью серверных команд. В текстовом и схематичном виде это элементарно, но в виде сложных комплексных моделей я не понимаю, как можно сохранить производительность оперируя миллионами объектов в реальном времени. Возможно, какие-нибудь реализованные в железе специальные инструкции могли бы помочь, навроде векторной графики или трассировки лучей. Можно ли обойтись уже имеющимися? Тут мои полномочия — всё =)
Я что-то не очень понял… Клиент — это кэш объектов, необходимых серверу для быстрой отрисовки на клиенте. Можно унифицировать протоколы и серверы, чтобы быстрее разрабатывать, но клиенты в разных играх будут разными и всё равно большими. Так как на компе клиента происходят вычисления по выводу на его экран, логично разместить эти данные как можно ближе к этому экрану!
Раф же говорит, что игры не должны быть большими и что он готов принести в жертву графику, окей. То есть, меньше моделек, меньше объектов, простые текстуры, схематичная графика. Что вообще не вдохновляет. Можно ставить крестики в клетках «Морского боя» и представлять себе бой флотов, только как-то не хочется. Либо имеется в виду поток отрисованной графики с сервера, как в облачном гейминге Nvidia, а это задержка 100-200 мс на пересылку до клиента, потом ещё столько же на вашу реакцию, а потом ЕЩЁ раз столько же на пересылку обратно на сервер — да это просто неиграбельно! К тому же не секрет, что графика в игре серьёзно превосходит пережатый видеопоток в качестве.
Я могу себе представить третий вариант в виде конструирования объектов из базовых элементов на клиенте, без моделей, с помощью серверных команд, но не уверен, что это возможно, подскажите, может кто в теме.
Самая спорная часть заметок Рафа — боюсь с этого момента мы можем услышать совсем не то, о чём думали поначалу.
Всё ждал, когда же начнётся маркетинговый булшит… А вот и он.
Статья в стиле «учёный изнасиловал журналиста», только тут «программист изнасиловал геймдиза».
Столько искажений реальности на абзац я уже давно не видел.
Общее впечатление: либо Раф сознательно врёт, либо он совершенно не понимает техническую сторону вопроса (как и его разработчики). И то и другое — плохо.
Ну, тут 2 варианта: либо лошади в БДО это какие-то сверх выносливые монстры, либо мир по диагонали плюс-минус 6-8 Км.) Понятно, что магия, условности, он это же в конце концов лошадь!))
И да, если за такую продолжительную поездку ничего не случается, то мир, получается довольно статичный и не пытается увлечь игрока событиями, на которые он может натыкаться в процессе путешествия. Тут же суть не просто в «большой мир», а в том, что передвигаясь по нему можно сгенерировать целое приключение, если мир, конечно, динамичный.
С другой стороны есть бдо без телепортов. И там можно из конца в конец пересечь мир за 15 минут. На хорошем коне. Без него, наверное, за 30-50. И после пары таких поездок начинаешь остро чувствовать насколько мир маленький. А телепорты «сбивают ориентировку» и даже в небольшом мире могут дать ощущение пространства.
Не совсем так, хотя разницу и трудно объяснить. Клиент ммо игры содержит гораздо больше, чем просто графику. Там есть еще и геодата (чтобы игрок под тестуры не проваливался), некоторые вещи вроде освещения, которые трудно просчитывать на сервере.
Но из-за того, что игроки любят все взламывать и исследовать, нельзя оставить в клиенте ничего, имеющего отношения к взаимодействию с миром.
Браузерные игры при этом отдают вам свой клиент каждый раз при подключении к серверу. Ну, есть кэш, который хранит часто-используемое, но некоторые его чистят каждый раз как запустят браузер.
Вот только никто в целом не мешает совместить это, сделав в клиенте возможность докачки нехватающих компонентов на лету. Тогда клиент просто будет организованным хранилищем ресурсов на вашем винчестере и будет служить просто ускорению входа в игру, если он у вас есть. Где-то я даже видел игру, в которую можно было начать играть, скачав только 25% клиента.
Еще Раф пишет про замечательный пример незаскриптованного взаимодействия кошки со спиртным. И это действительно работает в Dwarf Fortress — там и не такое возможно. И грешит на графику, мол, у нас есть красивые, но пустые современные игры. Только вот реализовать пьяную кошку в текстовом формате (да еще и на английском языке, где нет падежей русского и каких-то безумных штук, например, корейского) — это одно. А нарисовать анимацию пьяной кошки, пусть и в лауполи формате — это другое.
С другой стороны вычислительные мощности сегодня действительно огромны. И вполне вероятно, что вот такие вот нескриптованые пьяный кошки, с несколько меньшей детализацией: например, уличные банды, курсирующие по своим районам и устраивающие различные события в зависимости от времени суток, встречи с другими бандами и игроками (которые тоже могут быть в банде или милиции) — это то, что сделает мир живым. И такие взаимодействия действительно позволят перейти на новый уровень в ММО. Только вот с клиентом и всей остальной речью это мало связано.
«Унитаз» — очень популярное слово в наши дни. И да, мы сами виноваты в этом больше других после того, как начали называть используемую нами технологию «унитазной». Но что, чёрт возьми, это значит? (Прежде всего, это точно не направление канализационной системы).
Первым делом предлагаю взглянуть в лицо фактам: унитаз не являются чем-то новым. Они использовались ещё тогда, когда мы ходили в ведро, используя довольно примитивные емкости. Сегодня вместо одного ведра мы используем канализационную систему с большим количеством унитазов, которые мгновенно подключаются и отключаются по требованию. В том, как всё это видоизменилось, можно увидеть очень красивое техническое решение, но суть осталась прежней.
Что унитаз означает для нас на самом деле, лежит в сути этого понятия.
Давным-давно, когда я начинал создавать унитазы, они состояли из ведра. Вы использовали обычное ведро, чтобы подключаться к разными выгребным ямам, даже к тем, которые были выкопаны в разных «местах» (тогда мы это называли «ямаbases», но не суть).
Суть в том, что когда ведра работали таким образом, мы могли менять и развивать систему в любой момент, не заботясь о том, что пользователь использует для подключения. А пользователи могли подключаться откуда угодно, потому что любой имел необходимую емкость для подключения.
И это ещё не всё. Такой упрощённый подход к канализации позволял использовать наработки для сотен ведер. ведра постоянно обменивались, даже содержимым.
Результатом этого был взрыв «творчества». По большому счёту, в современных унитазах есть крайне малое количество возможностей, которые не были изобретены и реализованы в то время. Мы продолжаем потреблять те же идеи до сих пор.
Сегодня унитазы работают совсем иначе. Для каждого унитаза пишется своя структура с нуля, в которой канализационная схема фактически «хардкодится». Унитазы настраиваются под совершенно конкретный коллектор. Большинство популярных канализационных систем имеют предел одновременных подключений, который ниже, чем тот, что был у старых ведер и выгребных ям в середине девяностых. Частично из-за того, что эти унитазы изначально проектируются для одиночных или достаточно скромных семейных потребностей.
Более того — унитазная индустрия до сих пор размышляет в категориях «домашние унитазы», или «мобильные унитазы», или «общественные кабинки».
Но это ведь очень странно для современного мира. Унитазы становятся всё более персистентными. Они становятся всё более социальными. Они стараются связывать всё со всем. Игроки жаждут «кроссплея». Они хотят играть на всём, что подходит.
Японские унитазы им в помощь!!! Идеи Рафа уже победили в современном мире.
Я даже придумал новую веху для Рафа — «увеличение посещаемости ммозга в 200 миллионов раз».
Ни для кого не секрет, что аудитория унитазов огромна, например только в России более двухсот миллионов унитазов, необходимо, я прям настаиваю — НЕОБХОДИМО, к каждому унитазу подключить экран и контент выдавать прям на главную ммозга, на таких вот Рафов.
С моим текущим разрешением на ноутбуке и зрением, я не вижу практически ничего) На второй мне показалось, что это удочка, но потом присмотрелась и вроде просто блик какой-то. В общем, угадыватель из меня никакой. А так я очень жду от обновления какое-нибудь развитие готовки.
Да ладно — сейчас три материала в подписке не выведены на публику с прошлой недели. :) Я не настаиваю на том, что их надо выводить или они того заслуживают, просто «успеть» на них можно прямо сейчас. :)
Оставь его! Если внезапно всплывет материал о твоей любимой игре, или который ну вот очень понравится — потратишь, а если нет, можно вложить в последнюю тему в этом месяце (если успеть xD)
у меня совершенно противоположная ситуация, за всё то время как ввели систему импульсов, успел потратить 4 импульса и то за один раз. В остальное время попадал уже на «опубликовано эргами»))
Вполне возможно, что только пресная вода будет использоваться для полива растений. Могут сделать плодородные земли только у пресных источников, ну или тащи акведук для орошения своих полей. Как вариант, рыть колодец
Возможно, он хочет сделать много игр под копирку с одним клиентом, разными серверами и разным набором, собственно, данных: моделей, текстур, объектов. Ну будет тогда у него пять игр и клиент на 1 Гб, который будет докачивать еще по 25 Гб за каждую. На пяти играх сэкономится 4 при общем объёме данных в 125. Экономия Века! ^_^
Ну ладно, допустим, что у нас есть много универсальных элементов, как вот в «марширующих кубах»:
Но в таком случае у вас появляются проблемы с LOD-ами, анимациями и т.п… Кроме того, миры, состоящие из огромного массива данных сложно передавать по сети всем игрокам, особенно, если игрокам позволено вносить крупные изменения в сам мир. Вообще это такой, не то чтобы парадокс современного интернета, но проблема: мощности вычислений растут на много быстрее, чем каналы передачи данных к пользователям.
По поводу более простой графики — меня это как раз устраивает, и, с учётом сказанного Эриком Голдбергом в недавнем интервью, кое-что объясняет:
Голдберг говорит, что у вас должна быть возможность выстрелить в атакующего вас, промахнуться, попасть в дерево и увидеть, как дерево загорелось. Вы также можете во время боя попасть в дамбу, пробив в ней дыру, оттуда хлынет вода и потушит огонь. В следующий раз, когда вы войдёте в игру, дамба будет всё ещё разрушена.
И тогда уже напрашивались параллели с Dwarf Fortress. Если они реально двигаются в эту сторону, но на уровне мультиплеера и с социально-геймдизайнерскими наработками Рафа, прекрасно. Но, опять же, пока мне не очень понятно, как универсальный тонкий клиент этому помогает. Как он помогает более простому распространению, мультиплатформенности и прочим штукам, понимаю. Как простая графика высвобождает существенную часть ресурсов, понимаю отчасти, хотя тут тоже, скорее, вопрос передачи данных, потому что Вальхейм прекрасно продемонстрировал возможность улучшения низкополигональной графики современными эффектами даже средних GPU. Но, как я уже сказал выше, какие-то вещи я лично готов принять на этом этапе на веру (хотя не требую того же от других, разумеется).
я могу себе представить третий вариант в виде конструирования объектов из базовых элементов на клиенте, без моделей, с помощью серверных команд. В текстовом и схематичном виде это элементарно, но в виде сложных комплексных моделей я не понимаю, как можно сохранить производительность оперируя миллионами объектов в реальном времени. Возможно, какие-нибудь реализованные в железе специальные инструкции могли бы помочь, навроде векторной графики или трассировки лучей. Можно ли обойтись уже имеющимися? Тут мои полномочия — всё =)
Раф же говорит, что игры не должны быть большими и что он готов принести в жертву графику, окей. То есть, меньше моделек, меньше объектов, простые текстуры, схематичная графика. Что вообще не вдохновляет. Можно ставить крестики в клетках «Морского боя» и представлять себе бой флотов, только как-то не хочется. Либо имеется в виду поток отрисованной графики с сервера, как в облачном гейминге Nvidia, а это задержка 100-200 мс на пересылку до клиента, потом ещё столько же на вашу реакцию, а потом ЕЩЁ раз столько же на пересылку обратно на сервер — да это просто неиграбельно! К тому же не секрет, что графика в игре серьёзно превосходит пережатый видеопоток в качестве.
Я могу себе представить третий вариант в виде конструирования объектов из базовых элементов на клиенте, без моделей, с помощью серверных команд, но не уверен, что это возможно, подскажите, может кто в теме.
Самая спорная часть заметок Рафа — боюсь с этого момента мы можем услышать совсем не то, о чём думали поначалу.
Статья в стиле «учёный изнасиловал журналиста», только тут «программист изнасиловал геймдиза».
Столько искажений реальности на абзац я уже давно не видел.
Общее впечатление: либо Раф сознательно врёт, либо он совершенно не понимает техническую сторону вопроса (как и его разработчики). И то и другое — плохо.
И да, если за такую продолжительную поездку ничего не случается, то мир, получается довольно статичный и не пытается увлечь игрока событиями, на которые он может натыкаться в процессе путешествия. Тут же суть не просто в «большой мир», а в том, что передвигаясь по нему можно сгенерировать целое приключение, если мир, конечно, динамичный.
Но из-за того, что игроки любят все взламывать и исследовать, нельзя оставить в клиенте ничего, имеющего отношения к взаимодействию с миром.
Браузерные игры при этом отдают вам свой клиент каждый раз при подключении к серверу. Ну, есть кэш, который хранит часто-используемое, но некоторые его чистят каждый раз как запустят браузер.
Вот только никто в целом не мешает совместить это, сделав в клиенте возможность докачки нехватающих компонентов на лету. Тогда клиент просто будет организованным хранилищем ресурсов на вашем винчестере и будет служить просто ускорению входа в игру, если он у вас есть. Где-то я даже видел игру, в которую можно было начать играть, скачав только 25% клиента.
Еще Раф пишет про замечательный пример незаскриптованного взаимодействия кошки со спиртным. И это действительно работает в Dwarf Fortress — там и не такое возможно. И грешит на графику, мол, у нас есть красивые, но пустые современные игры. Только вот реализовать пьяную кошку в текстовом формате (да еще и на английском языке, где нет падежей русского и каких-то безумных штук, например, корейского) — это одно. А нарисовать анимацию пьяной кошки, пусть и в лауполи формате — это другое.
С другой стороны вычислительные мощности сегодня действительно огромны. И вполне вероятно, что вот такие вот нескриптованые пьяный кошки, с несколько меньшей детализацией: например, уличные банды, курсирующие по своим районам и устраивающие различные события в зависимости от времени суток, встречи с другими бандами и игроками (которые тоже могут быть в банде или милиции) — это то, что сделает мир живым. И такие взаимодействия действительно позволят перейти на новый уровень в ММО. Только вот с клиентом и всей остальной речью это мало связано.
«Унитаз» — очень популярное слово в наши дни. И да, мы сами виноваты в этом больше других после того, как начали называть используемую нами технологию «унитазной». Но что, чёрт возьми, это значит? (Прежде всего, это точно не направление канализационной системы).
Первым делом предлагаю взглянуть в лицо фактам: унитаз не являются чем-то новым. Они использовались ещё тогда, когда мы ходили в ведро, используя довольно примитивные емкости. Сегодня вместо одного ведра мы используем канализационную систему с большим количеством унитазов, которые мгновенно подключаются и отключаются по требованию. В том, как всё это видоизменилось, можно увидеть очень красивое техническое решение, но суть осталась прежней.
Что унитаз означает для нас на самом деле, лежит в сути этого понятия.
Давным-давно, когда я начинал создавать унитазы, они состояли из ведра. Вы использовали обычное ведро, чтобы подключаться к разными выгребным ямам, даже к тем, которые были выкопаны в разных «местах» (тогда мы это называли «ямаbases», но не суть).
Суть в том, что когда ведра работали таким образом, мы могли менять и развивать систему в любой момент, не заботясь о том, что пользователь использует для подключения. А пользователи могли подключаться откуда угодно, потому что любой имел необходимую емкость для подключения.
И это ещё не всё. Такой упрощённый подход к канализации позволял использовать наработки для сотен ведер. ведра постоянно обменивались, даже содержимым.
Результатом этого был взрыв «творчества». По большому счёту, в современных унитазах есть крайне малое количество возможностей, которые не были изобретены и реализованы в то время. Мы продолжаем потреблять те же идеи до сих пор.
Сегодня унитазы работают совсем иначе. Для каждого унитаза пишется своя структура с нуля, в которой канализационная схема фактически «хардкодится». Унитазы настраиваются под совершенно конкретный коллектор. Большинство популярных канализационных систем имеют предел одновременных подключений, который ниже, чем тот, что был у старых ведер и выгребных ям в середине девяностых. Частично из-за того, что эти унитазы изначально проектируются для одиночных или достаточно скромных семейных потребностей.
Более того — унитазная индустрия до сих пор размышляет в категориях «домашние унитазы», или «мобильные унитазы», или «общественные кабинки».
Но это ведь очень странно для современного мира. Унитазы становятся всё более персистентными. Они становятся всё более социальными. Они стараются связывать всё со всем. Игроки жаждут «кроссплея». Они хотят играть на всём, что подходит.
Японские унитазы им в помощь!!! Идеи Рафа уже победили в современном мире.
Я даже придумал новую веху для Рафа — «увеличение посещаемости ммозга в 200 миллионов раз».
Ни для кого не секрет, что аудитория унитазов огромна, например только в России более двухсот миллионов унитазов, необходимо, я прям настаиваю — НЕОБХОДИМО, к каждому унитазу подключить экран и контент выдавать прям на главную ммозга, на таких вот Рафов.