再次断更了很久

再次断更了很久啊，回想一下，中间发生的事情太多以至于也不知道从何说起了。

先说项目吧，第二个里程碑结束后，第三个里程碑遇到了巨大的需求变更，因为受到了Slay the spire的启发，最终的需求文案中将游戏流程改为了类似的外围Roguelike。在我的感觉有点Project Love的即视感。当然这个倒不是关键，但是类似的遗物系统的加入，着实让我受到了不小的打击。

原本的数值框架，是根据当前有的需求，在考虑了怎样方便的在表格中配置后，设计出来的。主要思想是把所有可能变化的数据，设计了一个最小单位，称作辅助配件，·这样，所有的数值变化都可以认为是N个辅助配件的叠加。在所有的数值表上，任何变化（包括初始化），只需要在对应的字段填值即可。当然，因为分为叠加和相乘，所以每个变量都会有两个字段。而根据最新的需求，因为遗物的加入，则需要允许几乎所有的数值都可以变化，导致之前的设计就完全不可能使用了。

当然这只是个表面问题，单纯问题的解决倒不是最主要的打击点。主要是我开始发现，在数值架构这个问题上，单纯的由程序根据策划当前版本需求设计数据结构是不可能的。首先，策划会要求使用Excel，这个要求实际上是需要把所有结构化数据全部放入一个二维结构里。在策划对于自己的体系没有一个清晰的了解，我这边也没有相关经验的情况下，如果这次也是按照之前的方法，就很有可能出现后面再加入新需求，还得改数值架构的情况。

于是，我就开始考虑其他人是怎么做的。

这个需求对于国内MMO手游来说肯定是已经解决了的，所以问题就是他们是怎么解决的。

当然……答案其实我也差不多能猜到……所以还是想看看有没有更好的方案。

最佳方向其实是看看Slay the spire……所以……就看了……

打开目录，发现大部分的容量都被一个.jar包占据了……右击打开压缩文件，从库文件看是用的一个叫做LibGDX的框架。Google之，原来是个Java写的框架……那……原谅我怀着罪恶的心态学习一下了。

先看了看LibGDX，下下来构建了一个项目，把解压出的资源放入对应路径，代码用jd看了看，再修复了各种奇葩的问题，尝试运行……好吧，竟然跑起来了。

突然很想帮他们移植一个手机版本……

从架构上来说，首先，他们的数值是全部写死在代码里的，一个遗物一个类。遗物的抽象类中有很多回调函数，可以允许你在切面上进行操作。比如一个遗物是下一张牌提升伤害，他们的写法就是在打出牌的回调里，把这张牌的伤害硬加上去了……而整个项目的几乎所有位置上，都充斥着类似

if(有某个遗物){
    做某事
}

这样的代码。

回调的方法本身没什么问题，虽然我更希望直接注册全局事件，这样耦合更低。但是这种使得几乎所有模块都和各种具体的遗物强耦合的写法实在是令我无法接受。同样，写死所有参数的方式，对于后面程序与策划的解耦合，也是一场巨大的灾难。

这个问题，不是个纯技术问题，换句话说，不可能由我一个人，或者任何一个程序员一个人来解决，这种无力感在年前的很长一段时间都沉重地压在我身上。

在1月底的时候，我突然接到运营那边的消息，说ICEY的所有版本需要紧急修改，一个是需要加入公示信息（写明版号文网文什么的，国产游戏打开都有），还有个是需要根据送审版本，把犹大的名字改掉，时间呢，是2月之前。

哦，2月之前啊，我看看屏幕左下角。

2018-01-31。

好的，我加油。

另一边，其实策划同学也已经感觉按照现在的构想，数值这边确实是很有压力的。于是也一直在积极招人。很快，我就看到了一份非常令人激动的简历。所以，确实大部分时候，一个人是否合适，光看简历已经能基本确定了，有点玄学。于是年前一周，晓浩入职。

因为制作人年会的关系，我也算是蹭了两次心动年会了。我们之前年前基本上就是大家一起吃一顿，还从来没搞过正经的年会。今年，我觉得还是很有必要可以开始准备了，只要开始了，肯定会越来越好的嘛。

唱歌跳舞就算了，想想就觉得如果准备节目那绝对是大家与我和争争两边的双重地狱。除了节目，年会还能干吗呢？嗯……抽奖……

花了一下午写了个抽奖游戏，拜托冬哥给大家都画了一幅大头照，自己玩玩感觉效果不错。

结果……效果真的不错……谁不想要哪个奖品，就一定会抽到他，哈哈，声控抽奖，节目效果满分。

年会上也宣布了今年的年终奖，大家一起过个愉快的新年吧。

年后回来。

晓浩在几次主动找我的聊天中，其经验与能力很快展现了出来。很快，我就看到了全新设计的数值框架。问题解决。根据他自己的意愿与实际能力，肖哥和我一致希望他直接担任产品经理和项目经理，他本身也很有动力。于是，我们开始具体执行了。

结果，遇到了之前从未考虑过的新问题。

因为之前的经历和经验，我虽然依然在寻找主程，但是已经不作为确定性的条件了，基本是抱着至少这个项目，大概率自己来带的觉悟。

结果，第一次跟晓浩沟通具体需求实现问题上，就发生了问题。

当时我只拿到了一份数值属性说明，晓浩来找我确认这样出是否可以。在我看来，我在完全没有拿到其他文档，甚至连是否有其他文档都不清楚的情况下，单凭这一点信息，是无法确认的。虽然单纯的把这个数据结构实现出来是完全没有问题，但是仅仅是这样做完全没有意义，我理解的确认，是需要确认这部分实现，在整个框架下是否可行，以及是否有充足的可扩展性。不然的话，我永远会担心这块。

就这个问题，以及产生问题的原因，我和晓浩进行了大量的交流，甚至一度状态有些紧张。第二天，我开始渐渐发现问题的根源：理论上，因为晓浩是产品经理和项目经理，所以产品的需求实现与项目的进度保证都应该是他的责任，但是因为我具体的负责了项目，那么，我是一定会自己去保证的，从这个角度来看，我和晓浩的合作是一定会产生冲突的；而交流的问题，因为客观上我和晓浩的实际职位与项目组内职位发生了错位，面对一个同时是自己上级和下级的人，即使晓浩已经理解这个问题，还是不免产生大量的客观冲突。

这个问题想要解决，不外乎两种方法：硬怼和换人（当然换的人是我XD）。

硬怼可以解决问题，但是不解决根本问题，客观上来说，只要我负责项目具体内容，那么我不自己来保证项目是不太可能的，更加严重的，这样做明显会严重的影响晓浩的心情与能力发挥。而换人，当然问题就是怎样找到合适的人了。

因为年后回来以后就和争争商量了重点要放在招人方面，也开始有一些简历收到。

最终，还是依靠晓浩推荐了他原来和合作伙伴，徐哥过来。他们之前已经有五六年的合作经验，也有了不少已经上线的项目，从理论上说，确实是解决当前问题的最好方案了。

因为很早以前晓浩就对服务器这边提出了一些担忧，正好这个阶段我也没法在客户端这边进行继续的工作，于是开始跟诸谦一起推进服务器这边。目前已经把大部分的流程都走通了，就等实际需求过来，设计好协议就可以用了。

目前的计划来看，我后续主要是作为PMO负责人对项目进度进行监督，服务器在没有明确负责人的情况下，需要负责推进以及对各部门进行技术支持——使用各种技术解决大家的问题以及提升效率。

从下个月开始，项目就需要开始进入快速推进了，以完成六月底的CJ版本计划。

结果只说了项目……