Devlog 7

[题图：塞尔达-荒野之息，图片作者Jeremy Fenske]

上周末，也就是清明节，去上海看Dota2亚洲邀请赛了！所以停更了一周，我跟你讲！现场的气氛就是不一样！如果喜欢Dota2的话，有机会一定要去看一次现场哦！然后是正经日志。

首先对上次的日志做下补充：

上次的日志中，提到了制作了从google spreadsheet导入数据进游戏的工作流，经过之后的实践，发现了两个问题：

1.google spreadsheet的发布有延时，根据查阅，googel的发布逻辑是5分钟一刷，也就是说新改好的表格，有可能不能及时刷新，这样unity里自动down下来的表格就还是旧的。对这个的比较好的解决方案是使用google api从客户端主动“拉”表格，然而杯具的是google api需要.net 4.5，而unity目前只能用3.5。于是这只能等将来unity更新.net库了。那么我现在只好就先不改了，实在赶上半天不刷的情况，干脆自己手动导出一下就好了。算不上太大的问题。

2.ods解析库，原本使用的那个非常不靠谱，一会儿丢数据，一会儿错位的！网上又很少ods的库，一度想要自己写……最后总算找到一个还不错的叫做Aspose.Cells，接入进来终于搞定了。

之所以要这么早期就制作正式的数据接入，是因为当建设原型做到一定程度时，就要实现多种不同砖块的建设，我不希望在制作多种砖块时从界面选择到砖块表现都还用硬编码的方式去做，这样的话，回头废弃的代码会很多，如果前几年我大概还会这样做，不过现在感觉可以直接以正式的方式去“数据驱动”地继续了。

所谓“数据驱动”其实就是游戏内的所有对象和行为都是由数据表格来完全控制的，程序直接实现的只是抽象的行为，而具体对象则基于外部表格创建出来。举个例子，我的建设按钮部分的UI，在游戏没有运行时是这样的：

除了负责两层建设按钮的空面板外，什么都没有。

然后我有这样一个砖块表：

游戏运行时，会基于这个表格构建起所有砖块从UI到地表表现，以及将来的各种参数和逻辑行为。

因此当运行起来后，UI是这样的

这样如果我要增减砖块，改变砖块行为时，只需要调整表格，不需要重写代码也不需要重新编译，就可以实时调整了。即使是游戏发行之后，也可以为玩家即时更新数据平衡方面的hotfix，而无需更新程序版本。

这大概算是数据驱动编程的一个典型例子了。那么到目前为止的进度看这个动图吧：

动图是1920*1080全屏录制的，缩小以后有些模糊。另外左上角的文字是尝试使用TextMesh Pro制作的像素中文字。效果比较满意。

目前进行的建设，只是建设到“蓝图”层而已，所以画面上是虚的，下周将会继续建设流程，将出现工人，在玩家设定的蓝图上，进行真正的地砖铺设。那么下周见吧。