Minecraft(我的世界)中文论坛
标题: 【个人翻译】#nextstep - 如果Bukkit没能挺住的话
作者: linnaea 时间: 2014-9-8 11:58
标题: 【个人翻译】#nextstep - 如果Bukkit没能挺住的话
本帖最后由 linnaea 于 2014-9-8 23:18 编辑
译注：这篇文章的翻译参照的是9月8日的版本的，该文档可能会变动，因此不保证准确性。
源地址：https://docs.google.com/document ... 90CO41ejsvA/preview
9月8日快照：http://soft.lyn.moe/sponge/nextstep-20140908224900.odt
另见：http://www.mcbbs.net/thread-337101-1-1.html
我们目前正在以社群的形式讨论在当前的形势下我们能做些什么。参与讨论请至IRC服务器 irc.esper.net 端口 6667 频道 #nextstep（http://webchat.esper.net/?channels=nextstep）
本文档由#nextstep里的一些人依据社群共识编辑。请仔细阅读后再加入讨论，因为你的想法很可能已经有人提过了。
现况调查结果: https://docs.google.com/forms/d/1lQ0eXyfaEHJPutFPAtNQk2XQteqHSKT4OJXWGFNfVio/viewanalytics
已达成共识的话题- 使用净室实现的服务器？
- 不使用。因为就我们目前所知道的，没有一个使用Java的净室Minecraft服务器。因为不是净室所以EULA限制依然适用。
- 太多的开发者都看过Minecraft的源代码了，所以根本没可能做一个净室实现。
- 使用现成的Mod平台？
- FORGE。因为社群已经建立起来了，可以省掉从头再来的麻烦。
- 使用什么API？
补充净室实现：
需要两组人，其中一组人分析一个软件系统的功能，并写出相应的规格文档，文档提交给律师做检查，检查通过后交给另外一组人，这组人按照规格文档重新写出与原软件系统功能和规格一致的软件。要求第二组人与第一组人不得有任何联系，且第二组人不得接触原软件系统。
作者: 52Dora 时间: 2014-9-8 12:04
总感觉有点像机翻...
作者: 1076132565 时间: 2014-9-8 12:06
好复杂的感觉...
作者: linnaea 时间: 2014-9-8 12:10
我语文不好别在意
作者: linnaea 时间: 2014-9-8 12:26
本帖最后由 linnaea 于 2014-9-8 12:28 编辑
目前最流行的观点
目前最多人支持的点子是从头构建一个新的抽象化API（不使用原生的Minecraft对象），API会有点像Bukkit的，但是将构筑在Forge和（大概）Glowstone之上。
- Forge是一个客户端/服务器结构的API，在修改游戏的玩法的mod中很流行，并且已有一个较大的社群。
- Forge没有抽象化API，所以如果Mojang做了太多或者太大的修改，使用Forge的mod会不能兼容各Minecraft版本。在Forge上建立一个API的话就可以解决这个问题。
- 使用这个API的Forge插件依然可以使用Forge的其它部分，就像是Bukkit插件可以使用NMS一样，但是Forge的功能会强很多。
- 不，使用这个抽象层的话就像是使用Bukkit API而不使用NMS。因为目前这个抽象层的规格还没有出来，所以没法和NMS比较。Forge其实就是用的NMS，而在Forge之上再抽象的话这个API的功能只会更少。（甚至可能会有很大的局限性）
- Glowstone是一个独立的Minecraft服务器实现，不像Bukkit/Forge/Spigot/Canary之类的，它不使用Mojang的服务器代码。
- 有人说不管最终社群选择了哪个API，我们都能用Glowstone来实现这个API。
- 目前Glowstone实现了Bukkit API，因为Glowstone不使用私有的Minecraft服务器代码。
- 换到一个独立的对Minecraft服务器的重新实现对很多人而言并不是一个可行的选项，因为他很可能会缺少最新版Minecraft里的绝大多数功能，这对于很多服务器来说都是个大问题。
- 这只是个臆测，Spout还在活跃开发的那段时间，某些功能出现在Spout里的时候那些功能还只在Minecraft的每周快照里。这会受开发的活跃度和新功能的复杂性的影响。
- 我们可以从头写一个API，但是有人认为我们可以利用Spout或者Canary的API，这样可以给所有人省点事。但是利用这些API并不代表我们会从上述的两个项目中使用多少现成的代码。
作者: linnaea 时间: 2014-9-8 13:27
目前提出的所有方案
注意：部分评论是由相关项目的开发者发表的，因此可能有偏见。
- 使用Bukkit的竞争项目：
- 换用Canary
- 包含官方的服务器所以违反服务条款（大问题）
- 社群非常小
- 3段式BSD许可
- 有人想把Forge加到Canary里去，Canary Lib可以用来构建一个类似于Cauldron的系统。（Canary团队已经在评估这一方式）
- API的文档非常完备
- 有抽象化的API，和Bukkit类似
- Bukkit有的功能大部分Canary都有，而且还有一些很多人很想要的功能
- 开发团队已经建成了一段时间了
- 有些在Bukkit上很流行的插件已经有相应的Canary版本了
- 换用Minecraft Forge（再加个抽象化API进去）
- 超大社群，各种mod都在用（加分项）
- 与Bukkit设计理念不同，Forge通过钩子尽可能地将NMS部分暴露出来，而Bukkit将NMS部分全都藏在一个抽象化API之后。
- 客户端也必须装Forge（大问题）但是按照LexManos的说法，（大概）到1.8之后就不是必须的了，1.7可能也会跟进。
- 某些类型的使用的Forge项目每次更新Minecraft都会不兼容。（大问题）
- Forge没有也不会提供抽象化API，所以每次Minecraft更新作者都必须更新
- 有srgname反混淆可以处理一部分这种问题，但是并不像Bukkit那样可以写一次然后就再也用不管了
- 大型的项目才有这个问题，一些小mod只要使用Forge API就好了
- 性能和Bukkit和Forge相去甚远
- 可以解决但是需要时间和人里，主要是费时间
- 我们把Spigot的那些修改用起来如何？
- 用现成的提高性能的项目？
- 我们需要知道我们能不能把性能提升到现在这代服务器的水准，否则的话这些东西并不能增加什么价值。
- 或许可行，但是我们得先取得许可。还有一个问题就是这些项目的修改有多激进。
- 对开发者并不是非常友好
- 被部分（读作“许多”）认为“难以上手”
- 不像Bukkit那样，Forge缺乏处理拉取请求的一套
- 如果社群够大的话，或许我们可以给LexManos施压？
- 缺乏文档，当然也可以解决
- 社群编写的教程再各大论坛都有，虽然和官方的权威性比不上
- 缺少Bukkit里的一些功能，虽然也可以解决
- 换用一个独立的净室实现：
- 换用Glowstone
- 已经存在一段时间了，而且其实蛮完备的
- Minecraft的新功能基本上都是缺的，毕竟是一个独立、从头写出来的服务器实现（大问题）
- 可以用Bukkit API（加分项）
- Bukkit API可能存在授权协议的问题和限制（大问题）
- 与Forge不兼容（大问题）
- 换用MCServer
- 使用C++
- 目测超快（加分项）
- 除非能有一个Java接口，不然现有的Java代码全得推翻，然后用Lua重写（大问题）
- 支持各种版本的协议！从Minecraft 1.2开始到Minecraft 1.7.10都能连接（加分项）
- 与Forge不兼容（大问题）
- 换用Craft.net
- 换用Spout
- 开发不活跃。现在改名为flow-engine在Github上的flow账户下继续开发。我们必须为Spout和flow-engine中的一个创建一个分支。
- Minecraft的新功能基本上都是缺的，毕竟是一个独立、从头写出来的服务器实现（大问题）
- Spout只是个客户端/服务器引擎，要玩Minecraft的话还得装插件
- 由于设计架构关系，BukkitBridge兼容模块有（巨大的）性能问题。
- 除非我们想自己做个客户端，不然Spout的客户端部分得删了。或许我们还得把Minecraft的插件合并进来。
- 与Forge不兼容（大问题）
- 在现有的API（Forge或者Canary）上重新实现Bukkit API
- BukkitForge
- 用Forge
- 有段时间了，但是从1.5.2开始被放弃了（大问题）
- 依然包含Bukkit API，可能存在授权协议的问题和限制（大问题）
- 从头写一个Minecraft服务器并实现某个API
- 换用TridentSDK
- S最近才开始的项目，如果我们想从头开始的话这是一个不错的选择
- 并不是个好的想法，项目太不成熟
- 我们自己写一个
- 工作量超大（大问题）
- 应当和现有的API基本保持兼容
- 可以自己选一个协议。GPL？LGPL？MIT？
- 发展的自由度最大
- 考虑将现有的Bukkit插件映射到新的API上，兼容性最好能超过90%？
- 能和Forge整合吗？
- 对社群开放、透明
- 在运行时动态修改程序来注入Bukkit和CraftBukkit的代码（也就是说不在GPL协议的程序里捆绑Mojang的服务器，而是在Mojang的服务器运行时动态地注入进去）
- 考虑到现在Bukkit的授权情况，风险非常高（大问题）
- 可以用Bukkit API（加分项）
- Bukkit API是Mojang所有的，大概不算是加分项
- 使用安装程序修改Mojang的服务器代码（也就是说不在GPL协议的程序里捆绑Mojang的服务器，而是提供一个安装程序，用户可以使用这个程序来构建他们的服务器，并应用上我们提供的和他们自己的补丁）
- 考虑到现在Bukkit的授权情况，风险非常高，虽然没上面那个高（大问题）
- 我们可以放弃绝大多数的Bukkit代码，然后我们自己写一个实现，官方服务器其实已经有很多我们需要的东西了，我们需要做的就是加个API上去，工作量应该不是很大，至少比从头写一个好
- 不知道这个主意咋样，保留Bukkit API然后重写CraftBukkit？
- 反正比捆绑官方服务器合法
- 可以用Bukkit API（加分项）
- 等着官方的API
- 要等不知道多久（我们已经等了2年了，现在还在等）（大问题）
- 可能会比Bukkit强大，但是不能和Forge比，Forge可以修改客户端，而官方API不行。
- 可能会是我们见过最没用的API，看看现在指令方块能干啥吧，多半是给Realms用的。估计和现在的API的可扩展性完全不能比。
- 考虑到最近Mojang的动作，搞不好是为了把大家都赶去Realms的伎俩（阴谋论）
- 在现有的官方服务器上构建一个插件API
- 说不定每周快照都能用
- 更新速度飞快（大问题）
- 局限性非常大（大问题）
作者: linnaea 时间: 2014-9-8 14:09
本帖最后由 linnaea 于 2014-9-8 23:05 编辑
备注
- 考虑到现在Minecraft社群里基本上所有东西都是用Java的，一个用Java的服务器应该会有最高的支持度。
- 使用现有的官方服务器是最简单的方法，然后我们可以分发我们的补丁来向官方服务器里注入我们的代码，这样可以允许有经验的用户使用Reflection修改官方服务器来添加API里尚不支持的东西。
- 原版客户端必须能连接。因为我们在寻找Bukkit的替代品。
提问
- 只支持一个版本的客户端还是同时支持多个版本的客户端？
- 除非我们打算自己写服务器，不然不是个事
- 真的不是个事，我们跟着每个Minecraft版本更新协议。Mojang估计会不断地在协议里做这样那样的小修改，多版本支持几乎不可能。
- 当前的Bukkit和Minecraft服务器并不支持多版本，估计没多少人会真的在乎这个事情。
- 项目的所有权？怎么运行这个项目？谁来监督？谁来管理？我们该怎么解决这个问题，并且以一个适当的方式合作？
- 自顶而下给予授权？
- 所有使用这个API的插件，如果公开发布的话，必须向所有的最终用户提供他们的插件和修改。私用插件和修改将使用另外一套许可条款。这样我们可以防止开发者对用户挑三拣四。对最终用户并没有坏处。
- 不好说，每个服务器都希望而且必须有自己的特色，我不希望每个玩家都能复制我的游戏模式，那可是我花了三天不眠不休才写出来的新游戏模式。
- 许可协议呢？
- 3段式BSD，LGPL，Apache 2.0，MIT之类的
- 要不要放一个贡献者许可协议（CLA）？
- 所有贡献者提交的代码的著作权将被转移给项目
- 我们需要一个记录的方式
- Git、Mercurial、SVN之类的版本控制系统来追踪每个成员对代码的修改
- 如果要提交拉取请求的话必须要接受CLA？
要求
- 支持原版客户端
- 有抽象层。这样就算哪天Mojang从Minecraft里删除了Player对象，插件和mod也不会出现不兼容的情况，因为他们使用的是抽象出来的Player对象。
- 建立一个接受贡献的方式
- 绝对不要用GPL（可能LGPL也不要用），省得再面对一次这种情况
- 用MIT？
- <asie> 要我说的话LGPL加一个禁止任何人闭源的CLA
需要考虑的方面
- 单元测试！
- 作为一个原企业级的开发者，我觉得我们不能不加测试就开始做一个这么大规模的项目。我们需要一个不错的测试包，这样可以保证不管是最新版还是稳定版都是可以用的。
- 最好是客户端和服务器统一的系统，这样就不需要管理多个系统了
- 高质量的文档，让社群能快速上手。
- 真的必须要提供最新的文档，这样用户才能快速的学会服务器的工作方式。
- 最好还有迁移指南，以及从旧系统迁移的贴士。
- 插件和mod的集中地。
- 为什么要这个？
- 受信任的插件来源
- 互相审阅代码
- 需要可扩展的基础设施，估计得花不少钱，应该是Bukkit被转到Curse后来又被Mojang买去的原因
引文
除非有说明，均是从#nextstep上引用：
- <LexManos> 对，在1.8里我会完全重写FML的登陆过程。最终目标是允许原版客户端连接Forge服务器。之所以不在1.7.10里做是因为客户端的工作流程以及我不希望在一个版本破坏协议的兼容性。
- <LexManos> 我有一条规则，在同一个Minecraft版本里mod不能出现和Forge的兼容性问题，但是新版本Minecraft里我可以随意破坏和旧的mod的兼容性。
- <LexManos> 要给modders提供一个功能最多的mod平台，一个面向原版客户端的不断演化、调整的接口是必须的。如果有人说我能在保持不疯掉的情况下做一个超大的抽象层而且还能提供现在的所有的modder所用到的所有功能的一半的话，那个人脑子一定有病。所以理想情况下应该是有两个项目。Forge是一个底层的API，给所有人他们想要的东西，而Bukkit是一个抽象API，给一般用途的插件提供一个稳定的平台。所以Bukkit和Forge才和谐共处了那么长时间。如果现在我们不得不给Bukkit的抽象层找一个替代品的话，我是不反对的。我希望的是不管谁开发这个抽象层，或者是协助我开发这个抽象层，都能与我合作的比Bukkit团队更加紧密一些。这就是为什么在这场惨剧之前我在和Blood合作使Cauldron更容易维护和开发。
API对比
作者: 1.3806 时间: 2014-9-8 15:05
MCPC+的职能已经有了
那些以前的插件怎么办
作者: linnaea 时间: 2014-9-8 15:06
我在翻译另外一篇文档，还有5页
作者: linnaea 时间: 2014-9-8 15:50
100%不兼容现有的Bukkit插件
http://www.mcbbs.net/thread-337101-1-1.html
作者: 1076132565 时间: 2014-9-8 19:38
看来得入正了
作者: linnaea 时间: 2014-9-8 19:40
不需要的
作者: leejuly29 时间: 2014-9-8 22:49
太感谢了，看了你的翻译，让我更了解插件服的现况
期待Sponge 服的出现 :)
作者: REN0011 时间: 2014-9-10 13:19
bukkit挺不住那就完了。
作者: serve~me~right 时间: 2014-9-11 13:18
你才几天就水道快6级了，哭晕
作者: 1076132565 时间: 2014-9-11 17:45
妥妥的
作者: serve~me~right 时间: 2014-9-13 09:03
啊啊啊啊，就6级了，啊啊啊啊