Здравствуйте, уважаемые тыжпрограммисты, перед мной стоит задача заправить 100500 принтеров (зачеркнуто) переписать ядро сервера с php (который не справляется с генерацией из-за большого количества циклов с еще большим количеством if()) на более-менее производительный язык, но чтобы я не поотстреливал себе ноги с помощью тысячи и одного способа, как на c++. Ядро игровое, рассчитано на 10-20 игроков, но проблема в том, что это minecraft с огромным количеством блоков, которые нужно по одному генерировать.
Учитывая достаточно абстрактную постановку вопроса/задачи, единственным верным ответом будет - вынести узкое место на c++ или go и оставить все как есть.
По отстреливать себе ноги кучей циклов и if'ов сможете абсолютно в любом языке.
Оптимизируйте текущий код или пишите на том что знаете.
Как вариант берите за основу любой кастомный и его допиливайте аналогичное есть и для покет версии.
Почитал комент автора. Если проблемы в генерации чанков то просто сгенерьте заранее весь мир сразу а игрокам просто подсовывайте готовые чанки подгружаемые из бд или файлов. Когда то давно на своем сервере именно так и делали, после вайпа за пару часов генерировали весь мир заново ограничивая радиусом мира.
Я взял за основу pmmp. В данный момент постоянно меняется генератор мира и очень медленно генерируются чанки. Генерировать их заранее - не вариант, ведь тогда придется долго ждать, пока можно будет тестировать. Но после релиза приму к сведению. Хотя тогда будет проблема в хранении большого мира. Думаю, что это решится генерацией определенной области вокруг игроков, а не только спавна, ведь огромные площади будут пустовать. Ну и генерацией области перед игроком в случае долгого движения. Как говорится - сам спросил, сам ответил.
Никита Лазарев, ставь ограничение на генерацию по радиусу и генерь, будет очень быстро. Проблем с полной генерацией тоже быть не должно ибо делать очень большой мир просто нет никакого смысла и из этого вытекает что объемы будут тоже не очень большими, темболее что игроков всего то 10-20.
У нас мир занимал что то около 30гб( с учетом остальных миров конечно же) всего на 50-120 игроков. Естественно крутилось все на ssd. Чтобы ограничения мира были не обрубками подбирали сиды для генерации островных типов мира, т.е. по большей части граница мира была водой.
Дмитрий Александров, у меня ядро, предназначенное для ванильного геймплея. Поэтому ограничение даже на 10к блоков сильно урежет возможности игроков, ведь новые структуры спавнятся как раз каждые 10к блоков. Ну и на нашем хостинге всего 30 гб места (впс), а ведь кроме сервера там и сайт. Пока что попробую переписать legacy код генератора с кучей циклов. Ну и 10*10 чанков генерируются около минуты, это совсем ни в какие ворота не лезет
UPD. Ну конечно же, для одного блока выполняется 18 умножений, не считая всего остального.
А вообще, если вы столько же циклов и ифов напихаете - то может никто и не справится. Проблема или в реализации алгоритма, или в самом алгоритме. А уж в яп - в последнюю очередь.
К сожалению, блоков в одном чанке 16*16*256. Каждый нужно сгенерировать, чтобы не было блоков с id == 0, иначе будут краши. Один игрок генерирует максимум 24*24 чанков. Максимальная скорость игрока - примерно два чанка в секунду. Чтобы игрок мог стабильно двигаться нужно сгенерировать как минимум шесть чанка перед ним, пока он не дошел до крайнего чанка. При этом нужно догенерировать уже сгенерированные чанки, добавляя на них объекты. Сами оцените объем вычислений. На данный момент ядро, написанное на php (оно мне досталось от других разработчиков) не справляется с этим объемом вычислений. Меня интересует не слишком сложный в изучении и применении ЯП, на котором это можно делать достаточно эффективно.
Никита Лазарев, все что вы описали не отменяет оптимизации и пересмотра алгоритмов. Самый "пример в лоб" - не генерировать чанки, а подставлять из пресетов какой то +вносить легкий рандом. В общем, из личной практики - прежде чем переписывать на другой ЯП, стоит 1000500 раз посмотреть на свой алгоритм и подумать, где его можно оптимизировать. Потому что реализация "в лоб" того же алгоритма будет ОЧЕНЬ не факт что быстрее.
Простой
