Комментарии 13
Так, на уровне идеи:
Можно решить проблему выедания пользователем ресурсов тем, что сделать их платными (за операцию/единицу памяти или за операцию/единицу памяти сверх лимита, и т.п.). При этом платой может быть какой-нибудь внутриигровой ресурс, который пользователями же и будет добываться в игровом мире, эдакое топливо для бота. Что-то по примерной аналогии с gas в Ethereum.
При этом для разработчика такой системы возникнет много интересных задач на подумать, как всё это дело отбалансить, а для игроков потом — как оптимизировать свой код и сколько тактов из него выделить на добычу топлива.
Именно так игра сейчас и работает — игрок начинает с 20 CPU, и потом постепенно за каждый достигнутый в игре уровень получает +10 CPU. Одна единица CPU означает 1 миллисекунду выполнения, доступную скрипту на каждом такте.

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

Один и тот же код может исполняться разное время из-за недетерминированной работы v8 и ОС. Идея газа как раз в том, чтобы платить только за реально используемые ресурсы. Т.е. если ваш код простаивал из-за того, что другой процесс использовал ресурсы, вы не платите за это.

Что в таком случае взять за метрику «реально используемых ресурсов» в рамках виртуальной машины JS?

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

Интересно, можно ли это как-то применить к V8, потому что в нашем случае нужна именно она.

Но в случае Ethereum есть полноценная ВМ, на производительность которой более-менее пофиг, поэтому вставить инструментирование легко.

Не заставляйте v8 исполнять код — пусть генерирует байткод. И вот его вы можете исполнять уже сами. В таком случае гранулярность будет измеряться не во времени, а в «инструкциях». Можно даже ограничить скорость работы виртуального cpu до 100 килогерц (как обещали в dcpu-16). После окончания ресурса можно обрабатывать инструкции очень медленно.

Можно ли в таком варианте понять к какому скрипту относится выполняемая инструкция?

Конечно, храните сопоставление
scriptID => scriptByteCode, currentOffset, memory[]
Больше скажу — в таком виде можно раздавать скрипт клиентам (нескольким для кворума) и снимать нагрузку с сервера.

Я в свое время для песочниц создал guest.js (код, кому интересно) – это V8 + libuv. Без доступа к внешнему миру (fs, http), все общение только по IPC. В разы легче так как не подключает библиотеки и баиндинги к ним, как это делает nodejs.


Но, сегодня я бы делал упор на песочницы на основе WASM. Они дают более предсказуемое поведение, чем все эти пляски с черным ящиком v8.

Игра изначально платная. Бесплатного варианта на сайте не нашел. Ну увидел этих 20CPU бесплатных.
ИМХО развитие игры тормозит то, что не каждый сможет или захочет даже бесплатно что-то писать, а уже тем более сразу оформлять подписку на то, чего не знаешь уже точно мало кто будет. Роликов в ютубе мало, развитие игры таким образом при такой ценовой политике будет около нулевое.
А откуда информация, что игра бесплатная? Она была и остается платной, продается через Steam, бесплатно доступна только однопользовательская демо-песочница на сайте, где можно попробовать, как всё это выглядит. 20 CPU дается новому игроку, а не бесплатно. Делать игру free-to-play планов нет.

По поводу развития — игра существует уже 4 года, на недостаток интереса к проекту не жалуемся.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.