假如设计一个mc的mod……(从计算机学生的角度考虑大致的流程)

和朋友讨论自己小服务器的一些规划,因为我有想要在cocricot外增加miniaturia并且同时使用两者的打算,想起了之前也想自行添加更多的玻璃方块,聊天话题就转到了mod的设计上。

大体上,这个mod该怎么设计呢?

我的想法,大概还是基于「如果已有的mod可以实现,尽量不添加」吧,一个原因是因为添加mod对于一个mc服务器来说大概是不可逆的——至少不能保证删掉mod后服务器还能正常运行。

所以第一步可能是收集需求,整理计划和清单,看一下服务器上的玩家们都分别有哪些要求,不管是从方块,玩法或者环境交互的角度。

如果真的认为需要一个新的mod的话,第二个任务就是确定这个mod的实现目标,比如说,这里可以是「设计一个添加方块的mod」。

接下来的的步骤,一般来说,相当于软件工程的开发,可以再进一步分为三个小步骤:

  1. 第一步是看这个mod是否可以尽可能普适,来满足以后的各种需要,这一步可以和计算机科学的抽象联系起来。

    有很多IT人士可能觉得这是多此一举,尤其是把YAGNI奉为信条的人士,这算是一种观念分歧了。但是,作为一个自己开mc服并且希望自己玩的爽而且以后能方便添加各种可能性的玩家来说,我不认同YAGNI的思考。

  2. 第二步是考虑mod该怎么实现,并且设计mod大致的代码结构和功能,比如说,对于添加方块这一件事情,是应该固定硬编码id给每个方块,以牺牲扩展性换来快速开发和简单的实现吗,还是提供一些可扩展性,但是相应的,会带来更长的工期呢?这种代价是否有必要的呢?

    和上一步其实有点类似,但是不同的地方大概在于需要进一步讨论每个功能该用什么样的技术来实现。相似的,在这一步,一些技术上的探索,比如解包现有的mod的jar文件来分析它们的实现方法,或许也是有必要的。

    因为mc里面加mod是一个不可逆的过程(至少无法保证加了删除是绝对安全的),所以一般来说也会希望这个选择能够充分满足之后的需要。

  3. 第三步就是具体的代码实现,这一步就没什么好说的了。

整个流程下来,大概算是一个简单的小型项目的生命周期了,也许可以从这里窥探出计算机专业的一种思维方式吧。


假如设计一个mc的mod……(从计算机学生的角度考虑大致的流程)
http://inori.moe/2023/09/10/what-if-a-mcmod/
作者
inori
发布于
2023年9月10日
许可协议