Обсудим Количество игроков

У меня AMD Athlon X2 2.4ггц, 4600+, бюджетный и старенький=), 3GB ОЗУ. При кол-ве плагинов - 40 (среди них авторизация, работы, экономия, магазины, анти-читы, чат-плагины, factions и многие др. по мелочи) тянет 17 человек (больше не пробовал), при чем с запущенным MineCraft, правда тогда CPU на 100% грузит)) Все говорю верно, без преувеличения, это норм?)
Интересно, скок еще эта машинка вынесет, если я не буду при этом в MineCraft'e?
P.S. Винда XP

 

На 25 наверное потянуло...

С ГУИ ещё поди? Да?

 

Не, запускаю командной строкой, если ты об этом.

 

если сделать ограниченный мир в 4 чанка то думаю 100 человека и даже больше на 4 гигах уместятся6)
будет МАЛЕНЬКИЙ КИТАЙ!

 

Хм.. а ты подал идею. Может секрет как раз и кроется в том, чтобы создать ограниченный мир, ведь мало людей уходят очень далеко от спавна. Создать мирок на 2048*2048 и пусть людишки бегают.

 

2048 это тоже много
это кажется будет 3 гаризонта. полчается что сервер будет обрабатывтаь одноременно 3 участка.
нужно не дальше 1 горизонта участок

 

О боже, наконец это поняли))

 

как его ограничить?)

 

тупо сделай пустые чанки вокруг

 

каким оброзом?) топориком 4толе удалять?)

 

Используйте плагин WorldBorder.

 

есть такой
а можно карту заного создать и задать ей свои размеры допустим 3000х3000 ?

 

а можно и форлдгвард

 

Да, в этом в общем и есть смысл плагина!

 

есть плагины, например WorldBorder

 

= ?

Не слышал, не?

 

сори, я открыл тему, потом написал спустя пол часа не обновляя)) поэтому не видел постов)

 

=)

 

На 1 гб - 40 человек. Вполне нормально.

 

@xDiP, я считаю, что вы неправы в некоторых аспектах, и вот почему:
1. Java. Java ни в чем не виновата, наоборот, это удобный язык со встроенным GC. Пусть не без недостатков, но, если я не ошибаюсь, на x86 и x86-64 в Оракловской реализации JVM есть поддержка JIT, что, в общем-то приравнивает, или хотя бы близко приближает Java к традиционным компилируемым языкам.

2. Карта. Да, вот тут вы правы, хотя, опять же, лишь частично.

2а) Чанки. Вы хотя бы представляете себе, сколько памяти занимает один чанк? Один чанк - это 16x16x128 = 32768 записей о типе блока, о метаданных блока, об освещенности (хотя я не залезал в дебри новой системы освещения в 1.8). Так же не стоит забывать о tile entities, если они имеются, и о прочих флагах, которые я забыл упомянуть. Со всей разнообразной обвязкой, на каждый чанк приходится около мегабайта. Вроде бы немного, тем более, что чанки сжимаются при передаче - но если вспомнить, что вокруг пользователя всегда загружена область радиусом 7 чанков, плюс еще буферная зона для того, чтобы оптимизировать обращения к жесткому диску - в итоге, округляя вниз, около 200 чанков на Player. То есть, один человек будет отъедать как минимум 200 мегабайт памяти сервера просто засчет чанков вокруг него. Разумеется, из-за того, что люди не очень часто играют на multiplayer-серверах по одному, потребление будет меньше, но приведенных вами двух гигабайт явно недостаточно.

2б.1) Цепи из редстоуна реализованы как простые конечные автоматы: на каждом тике сервера каждый зажженый торч проверяет, нет ли питания у блока, к которому он прикреплен, каждый диод проверяет, есть ли изменение сигнала - ну и все в таком духе, так что это действительно начинает тормозить только при большом количестве цепей.

2б.2) Касательно физики жидкостей ничего точно сказать не могу, но, полагаю, все выглядит примерно так: если меняется блок рядом с water, и в него может влиться вода, то туда устанавливается moving_water; а для каждой moving_water (если их больше 0) проверяется, есть ли рядом с ней свободные ячейки - если да, то в них тоже устанавливается moving_water. После тика все "старые" moving_water превращаются в water, после чего пересчитывается количество moving_water. В любом случае, активная нагрузка создается только когда существует moving_water/lava.

2б.3) Все item, лежащие на карте - это на самом деле entity. У них есть своя физика, пока их чанк загружен в память. Действительно, это тормозит сервер, тут вы правы - но точное значение, при котором сервер начинает тормозить определяется исключительно характеристиками сервера.

2в) Сундуки не могут тормозить сервер, поскольку они не производят активных действий. Печи, однако, действительно могут тормозить сервер при их огромном количестве: для каждой печи на каждом тике нужно проверить smelting time, ну и если там что-то жарится, то увеличить smelting time ему. Полагаю, это оптимизировано словарем активных печей, однако это не факт - не рассматривал реализацию вблизи - поэтому с уверенностью говорить не могу. Двери и поршни являются элементами redstone-цепей; помимо этого, двери также должны реагировать на нажатие - но это не является причиной.

2г) Если вы застали переход с хранения Alpha в Beta, то вы, возможно, знаете о McRegion. Это метод и формат хранения чанков, применяемый с Beta-версии Minecraft. Его идея в том, что чанки, запакованные gzip, хранятся в агрегирующих файлах, которые называются регионами и сохраняют по 1024 чанка каждый. Таким образом уменьшается нагрузка на диск, а бинарный формат и жесткая структура региона позволяет очень быстро находить нужный чанк. Прочие данные, например, данные об игроке, хранятся в так же бинарном формате NBT и так же быстро читаются, что позволяет обходиться без тяжелых SQL, даже таких, как SQLite.

3) Ну тут я постараюсь кратко посчитать предельный поток данных, который серверу нужно пытаться выдержать. Пусть N игроков идут равномерно прямолинейно параллельно сетке чанков, на двойном расстоянии видимости друг от друга. Скорость передвижения игрока в Minecraft составляет около 4 кубов в секунду. Значит, 15N чанков будут грузиться каждые 4 секунды. Один чанк, как я подсчитал в параграфе 2а, занимает около одного мегабайта, но с компрессией, пусть будет около 150-200 кб. Тогда каждому игроку раз в 4 секунды нужно отправлять 3 мегабайта данных. Игроков у нас N; значит, предельный трафик будет составлять 3N/4 Мб/с. Уже при 10 игроках это составляет 7 МБ/с, что является значительной цифрой (56 МБит/c). Разумеется, все игроки не будут так ровно идти, но загружать чанки с нуля они все равно будут, значительно реже, в среднем, раз в 10, как подсказывает практика и развернутые логи загрузки и отдачи чанков на загруженном сервере. Приняв во внимание эти обстоятельства, можно вывести примерное правило большого пальца: если хочешь поднять сервер на N человек, обзаведись каналом в N/10 МБ/c или 4N/5 МБит/c, что, в общем-то согласуется с вашим мнением.

4) Честно говоря, мне тут и комментировать не хочется. Java - кроссплатформенная штука, как на Windows, так и на Linux и на Solaris она будет работать одинаково - by design. Это дело каждого, что выбрать, но коли уж поднимать мощный сервер - то лучше под него отдать максимально возможное количество ресурсов. Каждый волен выбрать, что он хочет и что он больше знает.

5) Без комментариев.

Послесловие.
Мне хотелось бы подытожить данный поток мыслей вот каким фактом. В minecraft server используется три потока: один для чтения с консоли, другой для сети, а в третьем крутится обработка мира. Вдумайтесь: в 50 миллисекунд сервер должен уложить обработку действий всех игроков, просчитать весь AI, сделать такт редстоуна, для каждого entity проверить физику и коллизии, а так же обновить время, свет и прочие радости жизни. При этом это все происходит в одном потоке, без использования других ядер и процессоров. Выходит, что мошный i7-980X не может выдержать без лагов и 300 человек на 4 серверах по 75 человек на сервер.
Команда greencubes.su, по их словам, проделала отличную работу и написала свою реализацию сервера, с б/дж., ш. и многопоточностью. Мне хотелось бы верить, что господин Дженс Бергенстен проделает такую работу с оригинальным minecraft-server.