Recommendations for developers are written here and useful tools are mentioned.
Ниже написаны некоторые пункты, которые по возможности следует соблюдать в процессе любой разработки. Я сам следую или стараюсь следовать им, когда это уместно, и надеюсь мои мысли найдут единомышленников и изменят что-то в лучшую сторону.
Да, да, да. Многие забывают (или не думают) о том, что горы мусора или неоптимального кода это не только их проблемы, но и всех кто будет скачивать и использовать их творение. Я замечал невероятно много моментов, где в модах чуть ли не зип-архивами лежали неиспользуемые файлы, текстуры 16x16 весили по 5КБ, json файлы были растянуты и на пару с кодом Java там могло быть много повторений и лишних элементов. Вы можете сказать: а в чём проблема-то? разве это критично? И я отвечу: в целом, это не такая уж проблема, пока речь не заходит про масштабы сотен и тысяч файлов, где лишние 4КБ в каждой картинке превращаются в лишний Мегабайт размера мода. Да и сам по себе лишний код немного замедляет выполнение ввиду лишних операций или большего количества шагов сканирования файла. Я люблю оптимизацию, и даже порекомендовал бы использовать примитивы вместо функций где это возможно, но это личное дело каждого.
Итого: 1.1. По возможности не оставляйте в собранном проекте лишние файлы/архивы. 1.2. Оптимизируйте Json при сборке проекта. Вот пример 100% безопасной минификации Json (удаление лишних пробелов):
// ========== JSON MINIFIER ==========
afterEvaluate {
processResources {
doLast {
def outputDir = destinationDir ?: outputs.files.singleFile
fileTree(dir: outputDir, include: '**/*.json').each { file ->
try {
file.text = groovy.json.JsonOutput.toJson(new groovy.json.JsonSlurper().parse(file))
} catch (Exception ignore) {}
}
}
}
}1.3. Если ты новичок, вырабатывай привычку писать код без лишних if-else, меньше вложиков:
if (False) return;
...;вместо
if (True) {
...;
}Импользовать циклы + списки для обработки большого количества элементов, или enum-ы.
1.4. Можно также оптимизировать размер картинок - стоит использовать хороший графический редактор и/или дополнительно оптимизировать содержимое:
- Я использую Paint.NET графический редактор, он достаточно эффектино записывает картинку
- Часто я дополнительно оптимизирую их программой PNG Gauntlet, которая также немного чистит код картинки (P.S. Требует тестирования, иногда (редко) текстура ломается после сжатия, так что будьте внимательны).
Думаете, говнокод не будет оказывать заметного влияния на производительность? А если все будут так думать? А если модпак содержит сотни модов? Не буду много писать, просто можете скинуть свой код нейронке и спросить как можно его оптимизировать без потери функциональности, вожможно, вы откроете для себя много нового.
2.1. Если вы делаете World generator / decorator - постарайтесь сделать его так, чтобы он выполнял поставленные задачи используя минимум ресурсов ПК (ЦП, ОЗУ). Вам не сложно, а всем приятно. Например, что явно ПЛОХО для генерации мира:
- Сложные условия размещения (проверка больших областей, проверка большого количества типов/видов блоков (алгоритмы, массивы))
- Неоптимальные попытки генерации (например, вы хотите размещать структуру на поверхности, но ваш метод ищёт дёрн от 0 до 255 высоты. Это плохо!), т.е. те, которые заведомо будут неуспешными (не та высота, не то измерение, не тот биом, итд).
- Каскадная генерация (когда при размещении элемента он затрагивает ещё незагруженный чанк) или загрузка дополнительных чанков. Иногда это нужно, но если без этого можно обойтись - лучше обойтись.
2.2. Для этапа инициализации допустимо импользовать чуть более ресурсоёмкие операции, если это имеет смысл, т.к. она выполняется только 1 раз. Например, если вы хотите сжать код/базу данных по своему алгоритму для экономии размера мода, и развернуть при загрузке - ОК. Самое главное сохранять баланс между размером и оптимальностью выполнения.
2.3. Создавайте как можно меньше тикающих (tickable) объектов. Конечно, никто вам не запрещает делать умную траву, но есть же более хорошие способы реализации этого, правда?..
2.4. Не стоит перекачивать простые элементы излишней логикой / визуалом / функциями. Не спорю, иногда это уместно - но в таком случае нужно делать это качественно. Например, не создавать много частиц вокруг особых блоков/мобов, по возможности не перегружать NBT данные сущностей, если они не эксклюзивные | генерируются натурально в мире в значимом количестве. Также не стоит делать слишком сложный AI мобам, всё равно в рамках Minecraft они все будут деревянные.
Ну или по крайней мере отделить самописный код от того ужаса, что генерит МК (также сможете избежать рандомных багов и обнулений).
Если вы не сильны в коде или не знаете как по-нормальному реализовать код - используйте нейронки. Конечно, бесплатные сейчас врад ли напишут хороший код, но зато смогут подсказать возможные способы решения задачи или дать идеи по реализации. ВАЖНО: всегда думайте своей головой и фильтруйте то что пишет ИИ. Иногда они не понимают задачу, иногда несут дичЬ. Это не панацея.
Какие БЕСПЛАТНЫЕ нейронки я могу посоветовать:
DeepSeek-R1 на офф сайте (chat.deepseek.com) - может переварить много кода, понятно ответить на вопросы, сделать перевод или переписать код. Минусы: жертвует точностью во благо эффективности, иногда пишет фигню если запрос сформулирован неточно.
ChatGPT-5 mini там где он доступен (duck.ai). Удельно более эффективный код, но чтобы его добиться нужен очень точный промпт. Не умеет доступно объяснять. Часто ошибается с импортами. Менее гибкий чем остальные. Уже контекстное окно и лимит на длину чата.
Grok-4 тоже неплох (arena.ai). Хороший баланс точности и понятности. Минусы: относительно низкий лимит запросов в сутки.
...