Блок-сущность (англ. Block entity, ранее тайл-сущность) — блок, имеющий дополнительные данные, связанные с ним, помимо его ID.
Блоковые сущности имеют дополнительные данные об определённых блоках, типы которых варьируются в зависимости от блока. В некоторых случаях, эта информация служит для лучшего отображения модели, такие как книга на столе зачаровывания. В других случаях, она используется для хранения предметов внутри объекта. Блоки-сущности можно двигать поршнями. [ Только для Bedrock Edition ]
Этот список содержит блоки, имеющие такие данные.
Доброго времени суток, уважаемые модмейкеры. В данной статье я предоставляю свой перевод гайда с сайта shadowfacts по работе с TileEntity (1.12.2). Исходный туториал значительно доработан и кроме того адаптирован для версии 1.7.10. Исходники разобранного примера на GitHub: 1.7.10 и 1.12.2. Приятного чтения.
Изначально туториал содержал метку «Перевод», однако оригинальное содержимое сильно переработано, описана синхронизация и дополнительно добавлена информация для версии игры 1.7.10. Всвязи с этим я позволил себе убрать метку, однако ссылку на исходную статью оставляю.
Это первый туториал из серии статей о TileEntity.
В Майнкрафте класс Block используется для представления не просто единичного блока в мире, а блока как типа. Инстанс (экземпляр) Block содержит свойства для каждого экземпляра вашего блока, существующего в мире. Если мы хотим что бы наш блок содержал уникальные данные для каждого отдельно взятого экземпляра нам нужно использовать TileEntity.
Существует распространённый миф что TileEntity плохо влияет на производительность — это не так. Они могут негативно влиять на производительность если они реализованы не умело, как в прочем и любые другие объекты.
Тайлы бывают двух типов: обновляющиеся (ticking) и не обновляющиеся (non—ticking). Обновляющиеся тайлы обновляются каждый игровой тик (обычно 20 раз в секунду). Они влияют на производительность интенсивнее и требуют аккуратной реализации. Не обновляющиеся тайлы существуют для простого хранения данных. Ну а теперь подробнее по реализации:
Все создаваемые тайлы обновляются автоматически, что значит метод updateEntity() вызывается каждый тик. Отключить обновление можно переопределив canUpdate() и вернув в нём false ( true по умолчанию).
Разделение: клиент и сервер
Сразу отмечу что изменение данных, хранимых в тайле должно происходить только на серверной стороне. Перед их изменением мы должны удостовериться, что действия происходят на сервере. Делаем мы это потому как в Майнкрафте клиент и сервер полностью разделены и некоторые методы вызываются для обеих сторон.
В многопользовательской игре множество клиентов подключены к одному серверу. В этом случае разделение между сторонами очевидно, но в одиночной игре всё немного сложнее. В многопользовательской игре сервер, к которому происходит подключение, отражает физический сервер и все отдельные подключенные клиенты являются физическими клиентами.
В одиночной игре клиент и сервер тоже разделены даже несмотря на то, что они исполняются на одном компьютере (на одной JVM, но в разных потоках). В одиночной игре клиент подключается к локальному, приватному серверу, функции которого схожи с физическим сервером. В этом случае серверный поток отражает логический сервер, а клиентский поток отражает логический клиент, так как обе логические стороны выполняются на одной физической стороне.
Поле World#isRemote используется для проверки стороны, на которой происходит выполнение (будь она логической или физической). Оно равно true для физического клиента в многопользовательской игре и для логического клиента в одиночной игре. Это поле равно false для физического сервера в многопользовательской игре и для логического сервера в одиночной.
Хранение данных TileEntity между сессиями обеспечивается NBT. Данный формат используется для хранения данных в виде пар ключ-значение, которые легко сериализуется в байты и сохраняется на диск. Вы можете ознакомиться с классом NBTTagCompound для представления о типах данных, которые он может хранить. Ванильный код содержит множество хороших примеров по сохранению и чтению сложных структур данных.
В рамках статьи я покажу как создать простой тайл без обновления, предназначенный для простого хранения данных. В конце дополнительно описана организация синхронизации данных с клиентом при их изменении на сервере.
Прежде чем мы создадим тайл, мы добавим класс, который упростит их создание в будущем.
В первую очередь создадим класс BlockTileEntity:
Туда идут: сундуки,сейфы,шкафы,лампы,факела,поршни,плутоний,уран ну и т.д
0
0
0
0
0
Чего, я тебе не изменял. ;D xD
Редактировалось 1 раз(а), последний 2016-03-07 22:23:36
Как не нужно писать большие сервера
Те, кто мог видеть мою прошлую статью (а она довольно related к данной теме), знают, что вот уже больше полутора лет я разрабатываю собственную реализацию сервера Minecraft, рассчитанную, в первую очередь, на высокие нагрузки. Тем не менее, в своей работе мы используем так же и стандартный сервер (Bukkit) для нескольких мини-серверов, просто чтобы было разнообразие. И вот, столкнувшись с очередной версией сервера, которая стала раз в 5 хуже предыдущих, я уже не выдержала, и решила написать эту статью.
Статья больше похожа на рассказ, чем на обучающий материал, так что вряд ли вы почерпнете из неё полезных навыков кодинга, но, надеюсь, кому-то она покажется интересной или даже полезной. Но если вы ходите увидеть кучу кода и примеров, то не открывайте статью, она не об этом. Об этом, надеюсь, будет следующая статья.
Вам не нужно знать ничего о майнкрафте и особенно о его сервере, в данной статье я хочу просто рассказать, как работает оригинальный сервер Minecraft, а так же его «обвязка» — Bukkit, рассказать, почему такая система не работает и не должна. Я не претендую на идеальные знания о разработке серверов и не утверждаю, что мой сервер написан правильно и лучше всех. Я просто делюсь своим опытом, основанным на двух годах работы с сервером от всем известной Mojang и на полутора годах разработки своего сервера. Вся представленная здесь информация является моим личным мнением, а статья предназначена для расширения кругозора или даже обучения и может быть интересна как новичкам, так и продвинутым профессионалам.
Вы спросите, в чем же тут проблема? Так многие делают: основная логика приложения в одном потоке, это очень удобно программировать, не нужно заботиться о синхронизации и прочих проблемах параллельных приложений. Проблема тут в том, что если на сервере больше 40 человек, вместо стандартных 20 циклов он делает уже 15, если 70 человек, то 10, если 100 — то проседает до невероятных значений. Это при том, что у меня вообще-то мощный 6-ядерный Core i7 и 64Gb оперативной памяти! И куда мне теперь деть эти ресурсы, если из 12 потоков заняты от силы два?
Не буду пустословить, приведу пример: На сервере 223 игрока, при этом радиус видимости выбран достаточно маленький, в памяти находится 46577 чанков, 524 «срочных» блока, 87 блоков редстоуна и поршней, 11240 Entity предметов, 4274 Entity животных, 19 тележек и лодок, 717 других Entity, игроки, которые тоже являются Entity и требуют соответствующей обработки. Количество тайлов и обновлений света мой сервер не выводит в информации (мне это не нужно), но можете поверить, их много.
Одна лишь обработка животных ужасно тяжелый процесс — они регулярно выполняют поиск пути, поиск других Entity вокруг, у них есть AI (в последних версиях довольно продвинутый), поэтому обработать 4 тысячи животных — уже большая работа.
Обойти 3 миллиона блоков (примерно столько обрабатывается случайных блоков при таком количестве чанков) — тоже не тривиальная задача.
11 тысяч предметов надо сдвинуть, сделать некоторые другие действия, отправить обновления об их положении игрокам и прочее.
И всё это нужно успеть сделать за 50 миллисекунд, иначе все начнет тормозить, ведь скорость рассчитывается в циклах. Если сервер делает меньше циклов в секунду, чем должен, то, например, мобы начинают ходить медленно и рывками. Плюс расчётов в циклах очевиден — если сервер подвиснет или произойдёт огромная сборка мусора (сервер ведь на Java), то не получится так, что тележка, едущая на полной скорости на следующем цикле превратится в быстро движущийся маленький объект, и придётся рассчитывать её движение по более сложным алгоритмам.
При этом есть ещё и Bukkit! Bukkit — это такой «враппер» для ванильного сервера. Он добавляет API для создания плагинов, он супер-удобен для разработчиков плагинов и сделан действительно качественно. Но, грубо говоря, всё становится только хуже. Если игрок присылает пакет, что он немного сдвинулся или повернул голову… создаётся событие и посылается по всем плагинам, которые его обрабатывают. А при этом функция обработки движения и так довольно сложная. При ломании блока или установке происходит то же самое, а так же при около сотни других действий, которые создаёт игрок или сам сервер, включая махание рукой, смена состояния редстоуна, перетекание воды, спавн моба, AI, тысячи их… То есть, как бы система хорошая, но создаёт кучу дополнительных вызовов при обработке всего.
К счастью, некоторые разработчики плагинов научились вытаскивать тяжелую логику своих плагинов в отдельный поток. Яркими и хорошими примерами служат плагины OreObfuscator и Dynmap. Первый «чистит» посылаемые игроку блоки от лишних данных, чтобы игрок не мог читами смотреть сквозь стены. Он делает это в отдельном потоке, складывая пакеты в очередь и обрабатывая их отдельно от логики сервера. Второй генерирует динамическую карту для браузера, тоже очень качественно сделан. В общем, хвала им, что не нагружают основной поток ещё сильнее.
Так же есть плагин, который уменьшает количество вещей, которые обрабатывает сервер за цикл. Объединяет лежащие рядом предметы, выгружает мобов, ограничивает обработку чанков. Это очень круто, ни один сервер не обходится без этого плагина — NoLagg.
Как делать правильно (по-моему) Мы долго мучились со всем этим, когда полтора года назад наш онлайн вырос до 100 человек, а скорость работы просела до 0.5-1 цикла в секунду. Мы пытались делать оптимизации сервера, правили код, пытались убрать как можно больше лишнего, изменили в некоторых местах работу не по циклам а по секундам (например, в печи. В Bukkit это потом тоже добавили… через несколько месяцев). В конце концов мы достигли ужасной нестабильности сервера и решили плюнуть на всё это.
Единственным вариантом, который сможет обеспечить нам комфортный онлайн такого количества игроков, какой мы хотели, был масштабируемый сервер. Не думаю, что нужно объяснять, что поток у процесса сущность не масштабируемая, может работать только на одном ядре процессора одновременно и его производительность ограничена производительностью ядра. Ядра в процессорах сейчас довольно производительные, но и работы много, да и процессоры сейчас делают многоядерными, не то время, чтобы не делать что-то многопоточным.
Разделить уже существующий сервер на несколько потоков не представляется возможным. Многопоточное программирование — штука тонкая, сложная, требующая большого знания кода, с которым работаешь, и в существующее приложение практически не встраиваемая. Код надо писать с нуля.
Так родился сервер, в основе которого было заложено как можно больше потоков: мир делится на куски по 64х64 чанка и каждый такой кусок обрабатывает чанки в одном потоке, один поток для обработки срочных блоков, один поток для редстоуна и поршней, один поток для мобов, один поток для предметов, один поток для тележек, один поток обрабатывает другие Entity и прочую информацию о мире, один поток пересчитывает свет, четыре потока по разным частям света сохраняют мир на диск, один поток рендерит карту, один поток занимается обслуживанием сервера и команд консоли, обновляет статистику. Для игроков используется система, которая позволяет обработку пакетов ставить либо на отдельный поток для каждого игрока, либо на пул потоков, либо на отдельные потоки для каждого игрока. При этом всё можно разделить на ещё несколько потоков: обрабатывать один и тот же тип объектов хоть в 20 разных потоках. А так же Netty (NIO) в качестве сетевого движка, в отличии от стандартного I/O.
Разработка стабильной версии такого сервера, не обладающего всем функционалом, стоило примерно 8 месяцев работы одной меня без обладания опытом. Весь код рассчитан на асинхронный доступ ко всем данным. Но оно того стоило — совсем недавно мы поставили рекорд в 559 человек, которые не просто стояли в одном месте, лагали и снимались на фрапс, а проходили очень большой ивент с редстоуном, и при этом чувствовали себя комфортно.
Мораль сей басни такова: если вы рассчитываете на то, что ваш проект будет хоть сколько-нибудь популярным и думаете, что хоть чуть-чуть теоретически возможно, что на сервере будет хоть сколько-нибудь много человек… не поскупитесь на создание масштабируемой архитектуры.
Жду ваши гнилые помидоры, предложения по улучшению этой статьи, а так же предложения по тому, что бы вы хотели увидеть в следующей статье, которая когда-нибудь будет.
Поток мыслей может содержать орфографические ошибки, т.к. писалось на одном дыхании.
Что такое тайловое текстурирование — общие принципы и использование Статьи редакции
Как создавать тайлы и зачем это нужно.
Этот обучающий материал посвящён тайловому текстурированию: как создаются и применяются тайлы и почему это одна из важных основ в геймдеве — акцент будет на применение в разработке игр.
Не стану детально описывать пайплайн в конкретных программах, а сосредоточимся на общих принципах работы и ответах на возможные вопросы.
В одном из своих обучающих материалов я уже упоминал метод тайлового текстурирования, но рассказал о нём поверхностно — тогда основная тема касалась оптимизации UV-развертки.
Tile — произносится как «тайл», переводится как «плитка», а означает повторение. Повторяющуюся текстуру используют для текстурирования больших поверхностей: грунта, стен, домов, модулей и иногда мелких объектов. Такой вид текстур позволяет добиться высокого качества и при этом уменьшить количество применяемых материалов в игровой сцене.
Бесшовные текстуры — это и есть тайлы, но иногда их так называют. Паттерны на краях текстуры продолжают друг друга, чтобы избавиться от швов и сделать повторяемость менее заметной.
Tile Atlas или атлас тайлов — несколько тайлов на одной текстуре. При использовании атласов приходится жертвовать числом полигонов, чтобы использовать оверлапинг — наложение UV-островов на один участок текстуры. Атласы создают ради того, чтобы снизить количество материалов, чаще всего используются в мобильных играх, где требования к оптимизации более высокие.
Tileset или тайл сет — подразумевается сет модулей, из которых делают уровни. Эти модули используют общие тайловые материалы или тримы, поэтому их можно назвать сетом одного тайла.
Оптимизация. Известно, что файлы игр состоят примерно на 60-80% из текстур, а возможно и на 95% — всё зависит от конкретного проекта. Однотипные, бесшовные текстуры часто используются повторно на различных моделях, тем самым позволяя экономить место на жёстком диске, снижать время загрузки и обращение к видеопамяти. Повторное использование материала в сцене вместо создания нового снижает количество Draw Calls — вызовов отрисовки.
Сокращение времени на разработку. Опытный левелдизайнер может создавать новые и уникальные локации, используя одни и те же модели и текстуры. Разумеется, это занимает меньше времени нежели создание каждой сцены с нуля.
Повторяемость ассетов. Если в игре часто использовать ассеты повторно, то через несколько часов геймплея визуально игра станет скучной. Этим особенно страдают игры с большим миром, например TESO, да и вообще вся серия «Свитков». После нескольких походов по пещерами можно увидеть все возможные тайлсеты, и новые локации не вызовут никаких впечатлений, так как они почти идентичны во всём, кроме проектировки уровня.
Зато большая часть Тамриеля (Мира вселенной The Elder Scrolls) умещается в 95 гигабайт, что по сравнению с новыми играми не так уж и много.
Сложный пайплайн для инди и новичков. При создании своего примера, я потратил больше дня на подбор скачанных текстур для одной очень простой модельки, при этом получилось так себе.
Основная трудность для меня была в том, что я не знал, что хочу визуализировать, не хватало предварительных артов или референсов, а если я и знал, что мне нужно, то нужных текстур не находил. Потратить ещё кучу времени на создание своих текстур исключительно для примера я не решился.
А теперь представьте те же сложности в масштабах игрового проекта или большого ассета. Для реализации качественных тайл сетов понадобится хоть какой-то опыт, время или деньги на покупку готовых.
Обработка фотографий в 2D редакторе — в Photoshop или в специализированных программах. Для создания полноценного PBR-материала не достаточно одной текстуры цвета — необходимы маски метала, шероховатости и карта рельефа (Metallic, Roughness, Normal Map). Всё это нужно либо рисовать вручную, либо генерировать из той же фотографии, что, конечно, даст результат, но не лучшего качества. По этой причине способ считается устаревшим.
Для генерации существуют отдельные программы — например бесплатный materialize или Bitmap2Material — который по сути является набором нод из Substance Designer. Ещё есть онлайн-сервис NormalMap-Online, он может создать Normal, AO, Sepcular из любого изображения. У всех этих генераторов похожий принцип, цвет используется как маска, карта нормалей получается вдавленной в тёмных местах и выдавленной на светлых, в некоторых случаях из этого можно получить приемлемое качество.
Моделирование и запекание. Художник создаёт геометрию на прямой плоскости при помощи скульптинга или моделирования. Геометрию окрашивают ID-материалами или через Vertex Paint. Далее это запекается на обычный плейн в текстуры: Normal, ID map, Curvature, Ambient Occlusion.
Остальное создаётся вручную. ID Map помогает отделять друг от друга элементы на плоской текстуре. Metallic, roughness и базовый цвет можно создать в Substance painter, в Blender через нодовый редактор, в Photoshop или даже внутри игрового движка, смешивая текстуры по ID-маске.
Hand Paint — создание текстур вручную, рисование в Photoshop или в других 2D-редакторах. Как правило, этот метод подходит для стилизованной графики, так как добиться реализма мазками кисти крайне сложно, если вообще возможно. Для создания стилизованной графики с PBR можно комбинировать с методом запекания.
Процедурные редакторы. Благодаря нодовым редакторам можно создать, а затем в любой момент отредактировать, что угодно, изменять не только цвета, но и каждый паттерн в отдельности, создавать множество вариаций одного материала.
Ноды — это что-то вроде визуального программирования. В каждой программе они реализованы по-разному, но суть везде похожая: первая нода создает простой паттерн или шум, вторая нода его редактирует, а третья — добавляет цвета. Конечно, при создании реалистичного материала тремя-четырьмя нодами не обойтись.
Лучшей нодовой программой для создания тайлов и не только, считается Substance Designer, так как она, её инструментарий и библиотека нодов были созданы для этой задачи.
Tile Entities Часть I:Основы
Доброго времени суток, уважаемые модмейкеры. В данной статье я предоставляю свой перевод гайда с сайта shadowfacts по работе с TileEntity (1.12.2). Исходный туториал значительно доработан и кроме того адаптирован для версии 1.7.10. Исходники разобранного примера на GitHub: 1.7.10 и 1.12.2. Приятного чтения.
Изначально туториал содержал метку «Перевод», однако оригинальное содержимое сильно переработано, описана синхронизация и дополнительно добавлена информация для версии игры 1.7.10. Всвязи с этим я позволил себе убрать метку, однако ссылку на исходную статью оставляю.
Это первый туториал из серии статей о TileEntity.
В Майнкрафте класс Block используется для представления не просто единичного блока в мире, а блока как типа. Инстанс (экземпляр) Block содержит свойства для каждого экземпляра вашего блока, существующего в мире. Если мы хотим что бы наш блок содержал уникальные данные для каждого отдельно взятого экземпляра нам нужно использовать TileEntity.
Тайлы бывают двух типов: обновляющиеся (ticking) и не обновляющиеся (non—ticking). Обновляющиеся тайлы обновляются каждый игровой тик (обычно 20 раз в секунду). Они влияют на производительность интенсивнее и требуют аккуратной реализации. Не обновляющиеся тайлы существуют для простого хранения данных. Ну а теперь подробнее по реализации:
Все создаваемые тайлы обновляются автоматически, что значит метод updateEntity() вызывается каждый тик. Отключить обновление можно переопределив canUpdate() и вернув в нём false ( true по умолчанию).
Разделение: клиент и сервер
Сразу отмечу что изменение данных, хранимых в тайле должно происходить только на серверной стороне. Перед их изменением мы должны удостовериться, что действия происходят на сервере. Делаем мы это потому как в Майнкрафте клиент и сервер полностью разделены и некоторые методы вызываются для обеих сторон.
В многопользовательской игре множество клиентов подключены к одному серверу. В этом случае разделение между сторонами очевидно, но в одиночной игре всё немного сложнее. В многопользовательской игре сервер, к которому происходит подключение, отражает физический сервер и все отдельные подключенные клиенты являются физическими клиентами.
В одиночной игре клиент и сервер тоже разделены даже несмотря на то, что они исполняются на одном компьютере (на одной JVM, но в разных потоках). В одиночной игре клиент подключается к локальному, приватному серверу, функции которого схожи с физическим сервером. В этом случае серверный поток отражает логический сервер, а клиентский поток отражает логический клиент, так как обе логические стороны выполняются на одной физической стороне.
Поле World#isRemote используется для проверки стороны, на которой происходит выполнение (будь она логической или физической). Оно равно true для физического клиента в многопользовательской игре и для логического клиента в одиночной игре. Это поле равно false для физического сервера в многопользовательской игре и для логического сервера в одиночной.
Хранение данных TileEntity между сессиями обеспечивается NBT. Данный формат используется для хранения данных в виде пар ключ-значение, которые легко сериализуется в байты и сохраняется на диск. Вы можете ознакомиться с классом NBTTagCompound для представления о типах данных, которые он может хранить. Ванильный код содержит множество хороших примеров по сохранению и чтению сложных структур данных.
В рамках статьи я покажу как создать простой тайл без обновления, предназначенный для простого хранения данных. В конце дополнительно описана организация синхронизации данных с клиентом при их изменении на сервере.
Прежде чем мы создадим тайл, мы добавим класс, который упростит их создание в будущем.
