Ага, в настройках канала надо чатик указать и всё

В сетевой игре у нас нет "настоящего времени", есть история и её симуляция. Клиент симулирует мгновенно, сервер - с отставанием. Нужно, чтобы симуляция на сервере и клиенте приводила к примерно одинаковым результатам (может быть, не идеально одинаково, но "достаточно одинаково")

Вижу три варианта:

1) Написать два разных языка/рантайма на клиенте и сервере. Придумать некий стандарт, "абстрактную виртуальную машину", которая будет проигрывать историю. Воплотить её на разных технологиях два раза: и на клиенте, и на сервере. Сказать, что конкретная реализация написана корректно, если для одной и той же истории она выдает те же результаты, что абстрактная машина из стандарта. Это чертова гора головняка, написать в точности один и тот же код на разных языках - непросто.

2) Написать симуляцию на одном и том же языке. Это означает либо отказ от браузера (и тогда писать можно на чем угодно). Либо написание на универсальном языке (или сервер на JavaScript, или клиент на WebAssembly).

3) Объединенный вариант: на универсальном языке написать интерпретатор какого-то простого скриптового DSL, единственная суть которого - переключение состояний. Тогда вместо стандарта будет готовая реализация: скрипт написан корректно, если работает на свежей версии интерпретатора DSL.

Заметки про третий вариант:

- Если сам по себе JS/V8 работает достаточно быстро (когда включается JIT), то интерпретатор, написанный на JS должен работать чудовищно медленно. Значит, остаётся только Wasm.

- Интерпретатор DSL сам по себе может быть ценностью, потому что может дать возможность делать какие-то вещи, недоступные для обычного языка. Например, обращать время для всего промежутка между сэйфпоинтами (в строго однопоточном случае с обратимыми операциями - для многопоточности нужен happens-before и это ужас).

- DSL на самом деле может быть простым подмножеством какого-то языка типа JavaScript, и тогда "прямое" выполнение может работать очень быстро - прямо на интерпретаторе первого уровня. Тормоза случатся только про ревинде, но к сожалению это должно происходить очень часто - примерно половину времени.
Выглядит сложно. Я начинаю догадываться, чем занимаются все эти игропрограммисты, не зря свой хлебушек жуют.

Ну «экстраполяцию придумал не Ромеро»... но. Я помню как я отключал гц на пиратском «эмуляторе» сервера для айона)) потому как восточный стиль бэкэнда для ммо это server-first и full-approve включая геодату. Та ещё жопа сажу я тебе) зато узнал как заставить jre жрать сильно больше 200гигов оперативки угу.

вот поэтому есть некие сомнения в использовании жабы для этого. Если есть контроль над памятью, то можно сделать delete сразу всему тому, что больше не нужно в моменте

хотя адепты GC сразу же скажут, что GC быстрые и памяти много и она дешевая. Но при этом надо понимать, что все те же операции что на сервере - нужно произвести еще и на клиенте, а там убогий браузер с V8 на куске говна вместо компьютера

Не осталось больше никакого вашего Олега, лишь оправдания

Так это в смысле «помилования» от Олега тут употребляется😂😂😂😂

Олег, а что ты хочешь сделать? какие машины, какова цель?
Если тебе нужно "точно повторить" список "рандомных" событий, то тебе нужна одинаковая реализация рандома и проинициализировать их с одинаковым seed - все, все последующие вызовы next() будут одинаковые.

Сетевой шутер вроде Overwatch или CoD Warzone

Ого

Ответа про рандом два:

а) Источник истины - сервер. Если ты на клиенте симулировал какой-то один исход рандома, а с сервера тебе прислали другой - это значит, что клиент ошибся.

б) В киберспортивных играх должно быть как можно меньше рандома, желательно - никакого. Всё происходящее должен контролировать сам игрок. Например, сейчас Valorant очень ругают, что часть пушек использует рандом в конце спрея - до какой-то типа 20-й пули ты контролируешь рекойл мышкой, а потом пули летят куда попало. Это очень плохо, это мешает и оказуаливает геймплей.

в CS всю жизнь был рандом, и ничего, золотой стандарт

Отличное видео про архитектуру риплеев в Overwatch.

https://www.youtube.com/watch?v=W4oZq4tn57w

(Кроме того, в самом начале там уточняется терминология, которая используется в видео Тима Форда простыми словами.)

Я бы сказал не сомнения а уверенность подкреплённая опытом. Это можно делать на жабке, вопрос - зачем?

Жабка приятная и чуть ли не самое важное - быстро компилируется
Я из тех людей, которые меняют один символ и перезапускают все тесты, и делают так пока программа не запустится. В плюсах это может быть мучительно (хотя если применить все методики сокращения объема компиляции сразу...)

еще, я не умею в C++ (но придется научиться, похоже). Язык полное говно. Самое печальное, то там много вещей, о которых непонятно как узнать, что они вообще существуют, а они - ключевые. Типа, как сделать чтобы результат функции не копировался в вызывающий код, а передвигался - из синтаксиса никак не понять

Про "обращаемый язык", про который писал вчера. У меня была наивная мысль для каждого листа AST сделать обратную операцию и отмотать историю.

Сейчас погуглил, это целая научная проблема. Пока нашел хороший кейворд для гугления - "инверсная семантика", а во-вторых есть мастер тезис про обращаемые объектно-ориентированные языки. В отличие от простого Janus, с разбора которого начинается тезис, автор пытается построить полноценного обратимого ООП-монстра. Мне такое, конечно, не нужно, но это может оказаться хорошим гидом по граблям.

https://arxiv.org/pdf/1707.07845.pdf

Мартин Клеппманн (один из самых крутых специалистов по CRDT) выпустил цикл коротких лекций про распределённые системы

https://www.youtube.com/watch?v=UEAMfLPZZhE&list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB

А тебе не кажется, что привязав чатик к каналу стало хуже? До того тут царил такая обаятельная атмосфера тлена и разрушения. Ну иногда накидывали.
А сейчас автоматом вываливается и принудительно задаётся некоторый вектор.

ХЗ. Разлинковал пока.

Мне очень не нравится, что сюда копируются все сообщения из канала

И вообще, эта фича с дискуссиями выглядит какой-то недопиленной, сообщения из ответов теряются