Minecraft基岩版开发Wiki:格式指导/版本

From Minecraft基岩版开发Wiki

所有版本页面应符合以下布局,使版本页面的格式能保持前后一致。

版本[edit]

Demo-1.1此阶段是基岩版的前身,称为“携带版”并采用此作为前缀;从1.2开始采用“基岩版”前缀。

对于正式版,通常应该采用x.x.x的三位数格式进行命名(例如携带版0.14.0),特殊情况例外(例如基岩版1.2.6.60)。

对于测试版,分为以下两种情况:

  • 0.8-0.16的测试版,采用x.x.x.a/bx四位数格式进行命名,其中a代表realms测试版本(例如携带版0.15.0.a2),b代表常规测试版本(例如携带版0.16.0.b1)。
  • 1.0及以后的测试版,采用x.x.x.x四位数格式进行命名,同时为了方便搜索不再在标题上区分alphabeta(例如基岩版1.2.0.2)。

此外部分测试版也存在类似于Java版的发布候选版本,但是为了保证统一性并不会应用在格式命名中。

具体版本号数字按照游戏主菜单左或右下方给出的为准。其余版本根据实际情况与共识另行规定。

简介[edit]

在此部分之前应当使用{{version nav}},模板中的{{{edition}}}无需翻译。

若页面中包含了未确定官方中文译名的游戏内名称,应在消息框部分添加{{trans|un}}

在消息框的下方应该添加{{te|update}}。若该版本所有更新内容都符合技术性的要求,则不需要添加{{te}}

在模板后应有带有常规描述的简要介绍。此描述应包含此更新的发布日期、正式名称(若有)、此版本的平台(Java版、基岩版等)和对应的开发阶段,以及对此更新的简要介绍。如果这是开发版本,应说明这是哪个更新的开发版本。

简介示例[edit]

新内容和更改[edit]

新内容更改这两个段落因为相似而在指导中合并,在实际的页面中要分成两个单独的段落。版本的主要更改应通过以下两个段落呈现:

  • 新内容:版本中添加的任何新特性,也包括在开发版本中的特性。
  • 更改:版本中对旧特性的任何更改,也包括在开发版本中的更改。被移除的内容应在此处列出,而非在单独的部分中列出——除非实在有很多。

如果此版本是正式版或包含很多特性,每个段落都应包含下列子段落:

  • 方块:与方块有关的特性。
  • 物品:与物品有关的特性。
  • 生物:与生物有关的特性。
  • 非生物实体:与非生物实体有关的特性,如盔甲架矿车
  • 世界生成:与世界生成有关的特性。
  • 游戏内容:与游戏机制有关的特性,如成就、状态效果、游戏模式和有关视觉效果的更改。
  • 命令格式:与方块/实体标签或命令有关的特性。
  • 常规:常规特性,如选项、闪烁标语和图像的更改。

如果特性还未在开发版本中出现,这些特性应归在单独的计划新内容计划更改段落中。

被编号的更新或测试版本中的每一个特性都应该使用要点列表进行描述。对于任何新内容而言,这个列表应大体上全面,包括有关该特性的任何主要详细信息,但也应尽可能简明扼要,以便于阅读。大多数新内容应使用8个及以下(应很少超过12个)的要点描述。任何更改,以及罕见的在它们自己的页面上没有被描述的新内容,都应该包括所有相关的细节,甚至是次要的细节——尽管它们应该尽可能简短而不丢失任何信息。

有正式名称的更新页面,如水域更新,应当仅列出单独的新内容,而不描述其用途或行为,并尽可能简要地总结所有更改。

技术性[edit]

所有的更新内容都必须满足“技术性”的前提,在编辑页面时应删去更新日志中不是技术性更新的部分。

技术性更新内容应满足以下要求:

  • 新增内容(例如加入新的方块、物品、生物群系等)。
  • 命令的新增或修改。
  • 大多数原版游戏内容的更新都应该删去,它们属于游戏玩法或特性的更新而非技术性更新。但如果更新对技术性方面有较大关系或影响的仍应该写在版本页面中,如影响数据驱动的修改、涉及到算法逻辑的修改。
  • 有关图形渲染算法、代码框架(例如GameTest框架Molang)、UI本地化以及游戏底层代码架构等内容。
  • 官方更新日志中明确注明的技术性内容。

未确认特性[edit]

除非信息来源充分,否则不建议添加此部分。此段落仅限正在开发的版本使用,只能包含以下特性:

  • 不在这个版本(或任何特定版本)的计划或即将到来中;
  • 在版本开始开发时已被以下内容证实:
    • 一张能说明开发者为特性做工作的截图;
    • 或开发者的叙述表明他们计划加入此特性 - 不仅仅是应答别人的想法。

此段落应由这些特性并未确认会在<版本>中出现,但他们被开发者在<版本>的开发过程中提及或展示。主条目:提及特性开头。

每个特性都应包含:

  • 特性的名称或简要描述;
  • 非细节,而是如何识别此特性(这些属于提及特性);
    • 此段落的目的是使读者能识别未确认的特性,并说明理由 - 而不是介绍特性的细节。
  • 一个简要的解释说明特性何时被提到以及为何未确认,加上能说明的参考。

修复[edit]

版本页面中漏洞的修复也应该是技术性的,不符合技术性的漏洞修复不应当出现在版本页面中。

漏洞编号应使用{{bug}}模板,例如:{{bug|MCPE-61166}}