参赛规则

报名及参赛方式

在规定的时间内认真填写并提交报名表即可。当我们收到报名表、确认信息有效并录入数据库后,即视为报名参赛成功。点此前往报名页
目前的报名开始时间是北京时间 2020 年 7 月 9 日(星期四)12:00:00,报名截止是北京时间 2020 年 8 月 17 日(星期一)11:59:59,24 小时制。
参赛的基本单位是团队,团队人数限 1 到 5 人,也就是说可以一个人参赛。记得给你的队伍起个响亮的名字。
参赛团队应当在从报名开始到报名截止的一个多月时间内开发出一个 Mod。
报名信息在提交后可以修改!有鉴于此,我们建议参赛团队先提交报名表再开发 Mod,以免因报名表提交不及时而错失参赛资格。

Mod 主题

不限,但有两个可选的主题:「夏」与「茶」。
符合这两个主题的 Mod 可参与两个特别奖的评选。「符合主题」的标准是「自圆其说」,换言之你自己解释得了就行。
这样设计的目的是为了鼓励创作,而非追加限制。

Mod 开发、展览及评比环境

注:视情况而定,某些 Mod 有可能会更新,届时我们会尽快发布通知,还请时刻关注本页面。
  • Java 8u252 (AdoptOpenJDK build)
  • Minecraft 1.15.2
  • Forge 31.2.0
  • 中式工坊(ChineseWorkshop)1.15.2-2.4.5
  • Just Enough Items (JEI) 1.15.2-6.0.2.12
  • MumbleLink 1.15.2-4.4.1
  • 简单权限管理(SimplePermissions)1.15.2-0.1.1
  • 幻灯片放映机(Slide Show)0.1.0
  • 储物抽屉(Storage Drawers)1.15.2-7.0.2
  • The One Probe (TOP) 1.15-2.0.4
  • 传送石碑(Waystones)1.15.2-6.0.2
  • 以及所有参赛 Mod。
如果我们能成功办完这一届,我们可以在下一届时考虑一些不一样的东西,比如 Fabric。

Mod 的一些硬性要求

  1. 参赛 Mod 过去没有在任何地方公开发布过,无论是源码形式还是打包发布的形式。
  2. 参赛 Mod 必须是自由或开源软件,且托管在一个公开的 git 仓库里,比如 GitHub、GitLab、Gitee、Coding。 届时我们会克隆仓库并以距离报名截止日期最近的提交(commit)为基础自行构建 Mod,并以构建结果作为展示与评分的标准。 强制要求开源的目的是促进学习与交流,以及为我们发布参观用整合包扫清障碍。
  3. 参赛 Mod 必须能通过建筑的形式展示。参赛团队需要在展示服务器内建造一个「展馆」来展示最终作品。这个展馆是评分的主要依据,请务必发挥想象力说服评委们给你打高分。
  4. 参赛 Mod 不能使用 Mod 制作器制作,但可以使用类似 Data Generator 之类的程序和/或脚本来自动生成 JSON 资源等。
  5. 参赛 Mod 可以使用网上现有的开源代码、图像、音乐等资源,只要参赛 Mod 也遵守了这些资源的 License。
不符合这些硬性标准的 Mod 将失去评奖资格。Mod 开发茶会执行委员会保留这些规则的解释权。

一些不算是硬性要求,但是请务必注意的事情

  • 如果你(们)的 Mod 涉及到了对其他文学或艺术作品进行加工创作(即二次创作),请务必确认这些作品是否允许你(们)进行二次创作。 视具体情况而定,对其他作品加工而来的衍生作品有可能会因为不符合它们的使用授权,而违反上文中硬性规定的第五条。
  • 虽然没有硬性规定你(们)能使用多少网上现有的开源代码,但我们推荐你(们)将引用的开源代码的比重控制在 30% 以下。 我们建议你(们)使用构建工具自动包含相关代码,而非将他人代码直接复制进来。
  • 强制开源的出发点是在保证参赛作品的著作权(版权)归属于对应的参赛队伍的前提下,我们可以根据 license 的要求使用这些 Mod。 因此,在报名成功后,参赛作品随便发到什么别的地方都是没问题的。

评分方式及标准

在报名截止时间到后,我们会将所有的参赛 Mod 做成一个服务器开放参观,并以这个服务器为评委小组的参考。 参赛选手应在服务器内为他们的作品搭建一个「展馆」。是的,如果你觉得这个评分方式似曾相识,我们的确是在向 BTM 致敬。

评委给 Mod 打分时主要参考的方向有:

  • 完成度:给玩家和评委的第一印象是不是「已完成的作品」。
  • 稳定性:会不会在展览的时候把服务器和/或客户端崩了。
  • 用户交互:Mod 的用户交互是否友好,例如「玩家看不看得懂」和「GUI 的排版是否整洁」。
  • 可玩性和/或实用性:「这个 Mod 可以玩出什么花样?」
  • 美观度:「这个 Mod 好不好看?」
  • 代码质量:Mod 的代码是否值得新人学习。
视具体的奖项不同,评委可能会更关注或忽略某一个或某几个方向,也有可能会关注上面没有列出来的点。 举例来说,虽然「先锋」更关注代码质量,但为了代码质量而牺牲用户交互是不可取的。「旅行者」最关注玩法上的创新,但稳健的底层代码可以保证稳定性。