资源包的前置工作
我们知道,做资源包绝非把图片胡乱塞进去就可以了。因此,我们需要对做资源包的工作流进行简单的了解
从原版客户端提取参考文件
用原版 jar 取得 assets/minecraft 的大部分结构,再用工具补齐隐藏音效、字体、语言等资源。
只塞你要改的文件
永远不要把整个原版资源包硬塞进去,这太赤石了。你的包里只需要放“被你覆盖或新增”的资源。
创建可被游戏识别的资源包骨架
根目录放 pack.mcmeta、可选 pack.png,资源放进 assets/命名空间/...。
分模块测试
字体、语言、音效、blockstates、items 映射这些杂七杂八的文件建议分别测试。毕竟游戏里f3+t相比于mod的开关游戏还是太方便了。不要一次改太多,否则资源包报错的内容一个个排查会很恶心。
建议:把每一个功能做成独立小包测试,再合进主资源包。这样比直接对一大坨草莓塔动手动脚更省心。
提取原版资源包
原版资源包是最好的老师。基本上,你只要看到原版怎么命名、怎么引用,后面的 JSON 就不会跟盘古开天一样的捏造。
普通贴图和模型
找到对应版本的游戏 jar,用压缩软件打开。大部分贴图、模型、方块状态都能在 assets/minecraft 下找到。
隐藏音效与补充资源
音频并不总是在 jar 中直接全数展示。可以使用音效提取工具补齐 sounds、sounds.json、也可以自行用修改后的编译文件修改语言资源。
再次强调:真正做自己的资源包时,不需要把所有文件夹都复制进去,除非你有特殊爱好。
图集配置目录。控制哪些贴图会被打进不同的 atlas;普通材质替换一般只需照原版结构保留。
方块状态目录。每个方块 JSON 根据朝向、含水、连接状态、红石强度等状态选择要渲染的模型。
装备定义目录。新版中盔甲、鞍具、翅膀等装备渲染会参考这里的配置。
字体配置目录。放字体 provider JSON;可引用 TTF 或 textures/font 中的 bitmap 字体贴图。
物品模型映射目录。1.21.5+ 的重点目录,用来决定物品在不同组件、命名、展示上下文下使用哪个模型。
语言目录。放 zh_cn.json、en_us.json 等语言键值;可用于改物品名、UI 文案、容器标题和自定义语言。
模型目录。储存方块、物品和父模型 JSON,通常由 blockstates 或 items 指向。
粒子描述目录。控制粒子使用的贴图列表和资源定位。
后处理效果目录。用于部分屏幕效果或实体视角效果;普通材质包可先只作为参考。
原版内置资源包目录。第三方资源包通常不需要向这里新增内容。
原版着色器目录。包含 core、include、post 等渲染文件;和 Iris/光影包不是同一套体系,入门阶段建议少改。
音频目录。放 .ogg 音效文件;真正的事件名、音量、随机池通常还要配合 sounds.json。
长文本目录。包括终末之诗、致谢名单、闪烁黄字等文本资源。
贴图目录。资源包最常修改的区域,包含方块、物品、实体、GUI、字体、粒子、盔甲纹饰等 PNG。
我也不知道这是啥玩意。头部数据?真没看懂。
可用于自定义路径点样式。
完整逐文件夹请查看画面右侧的“资源目录”侧边栏。
使用原则:资源包读取靠路径和命名空间。minecraft:item/… 这类写法最终都会映射到 assets/minecraft/... 下的具体文件;如果只改钻石剑贴图这种简单的行为,只需要改png文件就行,不需要也没必要复制完整原版 tree。
pack.mcmeta-让游戏识别你的资源包
一个最小可识别资源包,需要根目录存在 pack.mcmeta 和 assets 文件夹。图标则使用同级的 pack.png。
{
"pack": {
"pack_format": 46,
"description": "请输入文本",
"supported_formats": [1, 99]
},
"language": {
"zh_koneko_belown": {
"name": "自定义中文",
"region": "KonekoBelown",
"bidirectional": false
}
}
}
| 字段 | 作用 |
|---|---|
pack_format | 资源包推荐版本。文档示例中 1.21.4 使用 46。 |
description | 资源包描述。可以使用 \n 换行,也可以使用 \u00a7 表示 Minecraft 颜色代码符号。 |
supported_formats | 兼容版本范围。示例 [1, 99] 是为了避免游戏显示红色不兼容提示。 |
{
"pack": {
"description": "请输入文本",
"min_format": 74,
"max_format": 99
},
"language": {
"zh_koneko_belown": {
"name": "自定义中文",
"region": "KonekoBelown",
"bidirectional": false
}
}
}
新版结构用 min_format 和 max_format 取代旧式 pack_format / supported_formats 的写法。维护 1.21.11 资源包时,建议把旧版和新版分开,不要强行混用。
注意:.mcmeta采用的是json语法,所有标点符号均为英文符号。资源包无法识别时,优先检查 pack.mcmeta 是否是合法 JSON。
自定义字体
字体不仅能换字形,还能把小图标、小抄、UI 提示塞进文本系统里(感谢 @药水棒冰 的梧桐加减法资源包提供了此灵感)。核心文件在 assets/minecraft/font 与 assets/minecraft/textures/font。
我们在这里先介绍ttf和bitmap
TTF 字体
适合替换文字显示风格。字体文件放在 assets/minecraft/font/font.ttf,再由字体 JSON 引用。
bitmap 字体
适合把某个字符渲染成图片。图片放在 assets/minecraft/textures/font,通过 chars 绑定字符。
{
"providers": [
{
"type": "ttf",
"file": "minecraft:font.ttf",
"shift": [0, 0],
"oversample": 5,
"size": 8,
"skip": ""
}
]
}
{
"providers": [
{
"type": "bitmap",
"file": "minecraft:font/lizi.png",
"chars": ["例"],
"height": 256,
"ascent": 20
}
]
}
常用参数怎么理解
oversample 控制字体清晰度,越高越清晰但负担也更高。size 控制渲染大小。shift 是水平和垂直偏移。bitmap 的 height 控制图片渲染高度,最大不能超过256.ascent 控制基线位置,且不能大于 height。
自定义音效
音效文件一般放在 assets/minecraft/sounds 下,格式使用 OGG。替换原版音效时,文件名和路径要对上原版引用。
找到原版音效位置
例如唱片 cat 的替换路径可对应到 assets/minecraft/sounds/records/cat.ogg。
控制音频时长
替换唱片时,音频长度最好不要超过原唱片长度,否则超出部分可能无法完整播放。
按用途选择声道
需要听声辨位的声音,例如唱片机、生物、活塞、音符盒,通常应导出为单声道。双声道更像背景音乐,容易贴耳播放。
可以用 Audacity 一类音频工具剪辑、转 OGG、导出单声道。不要只改扩展名,格式本身必须正确。
语言文件
语言文件位于 assets/minecraft/lang,常用简体中文文件为 zh_cn.json。它可以改物品名、方块名、界面文字,以及你在游戏里看到的任何能根据语言切换而变化的文本,也能配合 bitmap 字体显示图片。
{
"item.minecraft.diamond_sword": "钻石剑",
"item.minecraft.netherite_sword": "下界合金剑"
}
{
"item.minecraft.diamond_sword": "钻石剑 例",
"item.minecraft.netherite_sword": "下界合金剑 子"
}
只要 例、子 已经在 bitmap 字体中绑定到图片,语言文件里的对应字符就会渲染成图。容器 UI 小抄、物品名称旁边的小图标,都可以用这个思路实现。
{
"pack": {
"pack_format": 46,
"description": "请输入文本",
"supported_formats": [1, 99]
},
"language": {
"zh_custom_pack": {
"name": "自定义中文",
"region": "KonekoBelown",
"bidirectional": false
}
}
}
新增语言的现实问题:自定义语言文件最好覆盖原版语言的所有键,否则缺失内容可能回退到英文。Mod 语言也需要另行处理。
红显制作
以 @XeKr 为代表的创作者制作的红显资源包,是生电,储电,以至于几乎所有的红石玩家都所钟爱的内容。资源包创作者以其惊人的智慧和想象力,让玩家见识到了,mc并不是一定要靠f3才能获得那高深莫测的数据。以红石粉为例,power 有 0–15,四个方向有 none、side、up 等状态。
看状态
在游戏里用 F3 对准红石粉,可以看到 north、east、south、west、power 等值。
写条件
在 blockstates/redstone_wire.json 中用 when 判断状态,用 apply 应用模型。
叠数字
额外按 power 匹配 dust_0 到 dust_15 模型,就能显示信号强度。
{
"apply": {
"model": "minecraft:block/dust_0"
},
"when": {
"power": "0"
}
},
{
"apply": {
"model": "minecraft:block/dust_1"
},
"when": {
"power": "1"
}
}
这个示例的效果是将不管是爬墙,单点,还是链接,只要信号为指定数目,就渲染指定的信号强度的固定模型。然而,我们需要的肯定不止于此,因此,我们需要继续对每个状态的红石粉进行语句判断索引模型。这个就交给你们自己搞了因为我懒得粘贴。
负尺寸模型与自发光模型
负尺寸模型常用于描边:正尺寸外壳渲染正常面,负尺寸外壳显示反向面。自发光则可用模型元素的 light_emission 控制视觉亮度。
在 Blockbench 处理模型
用描边插件(如Outline Creator)或复制外壳方式生成 outline 元素。
更改描边元素的负尺寸大小
负尺寸的不同大小会改变可见面的大小,形成描边相对地变宽变细的视觉效果。
按元素添加 light_emission
在模型 JSON 的目标元素中加入 light_emission,例如描边 15、本体 10。
{
"from": [1, 1, 4],
"to": [5, 1, 4],
"rotation": {
"angle": 19,
"axis": "x",
"origin": [19, 8, 10]
},
"shade": false,
"light_emission": 15
}
边界:light_emission 主要影响模型自身的视觉亮度,不等于真正给周围环境打光,也不一定会被手持光源类 Mod 当作光源识别。
原版 CIT 与特殊命名材质
1.21.5 之后,物品模型映射能力增强。许多过去依赖 OptiFine CIT 的效果,可以开始用原版 items 映射和 component 判断实现。
物品模型映射
入口在 assets/命名空间/items/。它决定一个物品在什么条件下使用哪个模型。
模型与贴图
实际模型放在 assets/命名空间/models/,贴图放在 assets/命名空间/textures/。
{
"model": {
"type": "minecraft:model",
"model": "minecraft:item/netherite_sword"
}
}
{
"model": {
"type": "minecraft:select",
"property": "minecraft:component",
"component": "minecraft:stored_enchantments",
"cases": [
{
"model": {
"type": "minecraft:model",
"model": "minecraft:item/enchanted_book/bane_of_arthropods_1"
},
"when": [
{ "minecraft:bane_of_arthropods": 1 },
{ "minecraft:bane_of_arthropods": 2 },
{ "minecraft:bane_of_arthropods": 3 },
{ "minecraft:bane_of_arthropods": 4 }
]
},
{
"model": {
"type": "minecraft:model",
"model": "minecraft:item/enchanted_book/limit/bane_of_arthropods_5"
},
"when": [
{ "minecraft:bane_of_arthropods": 5 }
]
}
],
"fallback": {
"type": "minecraft:model",
"model": "minecraft:item/enchanted_book/enchanted_zip"
}
}
}
{
"type": "minecraft:select",
"property": "component",
"component": "custom_name",
"cases": [
{
"model": {
"type": "minecraft:model",
"model": "minecraft:item/netherite_spear_koneko"
},
"when": "矛爷冲击!"
},
{
"model": {
"type": "minecraft:model",
"model": "minecraft:item/netherite_spear_undyne"
},
"when": ["正义之矛", "Spear of Justice"]
}
],
"fallback": {
"type": "minecraft:model",
"model": "minecraft:item/netherite_spear"
}
}
实现思路:附魔书用 minecraft:stored_enchantments,普通附魔物品多用 minecraft:enchantments,特殊命名则检查 custom_name。复杂物品需要你跟套石山一样多层条件嵌套。这种亲自拉史的方式很折磨,真的很折磨。这就是为什么我很敬佩那些给武器写上全部附魔显示的创作者。