紧接着一次又一次的重写以及需求不断改变,直至今天,部分很早以前敲定的方案仍在发生改动。其实我一早之前就已经在各种技术方案中反复敲打与斟酌,取舍并尝试。当打算继续坚持项目时,第一版已经编写并敲定的文档又全部放弃了。如今,Genex已经走过了很多个Demo版本,并且每个版本都使用了不同的技术与架构。

用户界面

由于眼馋WPF的灵活,我一头扎进了WPF的学习中。与其说是学习,倒不如说是捣鼓。在用户界面设计上说我是个旱鸭子毫不为过。我尝试利用WPF编写了一些控件,以及布局了GenexUI的浮动界面,并在内部展示了Demo。在沾沾自喜的同时,不仅担忧起WPF的复杂性来了。首先对Genex来说,并不需要过于花俏的界面;其次是WPF大大降低了我们的效率,更不用说我们参与该项目的几个人都毫无这方面经验,恐怕难以驾驭。于是,在经过一段调整期之后,最终还是把它抛弃了。

逻辑与表现

我曾经纠结过这个问题。如果我编写了一个用于管理数据的类,它不涉及表现。但同时我希望把这些数据在一套UI上呈现出来,这就涉及到了一个耦合的问题。目前为止,仍然无法很好地处理两者的交互。当然,winform并没有像WPF中的绑定机制那么好用,这是个遗憾。

游戏资源管理器的设计

最初的设计是完完全全把硬盘上指定目录中的相关文件从一棵TreeView上显示出来。后来在经过一系列菜单功能开发之后,发现并不是那么理想。比如说你需要把某个节点代表的文件剪切到另外一个节点中作为子节点,那么在这种情况下,你想的可能会是直接把所要剪切的节点加到目标节点的最后,但忽略了一点,如果下次重新加载这棵树的时候,那么新加的这个节点是否还会在原来的位置不改变顺序?这个细节体验并不值得推荐,即使你有时候会无视它。在接下来的设计中,我将考虑重写这棵树,并且把所有添加到资源管理器列表树中的节点都使用配置文件进行保存。

关于地图编辑器与事件

前两周曾经有一个比较激烈的讨论,是关于如果提供地图编辑器,并且编辑器以一种什么样的形式出现。因为在现在这个阶段,并不曾涉足到关于地图编辑器的具体细节,但我觉得事先做好准备应该不至于是坏事。我们归纳过两种方案:

1)是通过N层完整图进行重合,如此一来,在实际中的显示问题容易解决,也方便美术发挥。
2)通过图块进行拼凑,这样可以很规范地设计地图元素,每一个图块表示一个符号,也表示了一个单位的图形,包括了显示、障碍等地理元素。

我更倾向第一种方案。反观使用图块方式,在一定程度上限制了地图的样式与多样化。关于事件网格,有伙伴称可以自定义网格的大小,虽然不可否认这是一个比较大胆的想法,不过实现难度在以后可能要好好推敲。

那么,脚本编辑器呢?

不得不说脚本编辑器成为了整个框架的灵魂模块。如何设计脚本框架则决定了成败。之前在脚本语言之间做过争辩和取舍。后来认为LUA可能更适合用在游戏中,并且更能让用户接受。那么暂且就这样定下来吧。

GenexUI是一个”IDE”

游戏的shell在最初就已经确认会用C++进行编写了,但最上层的编辑器UI则是用了C#。GenexUI提供了非常多的面板进行游戏的开发和脚本编写(至少这些都已经陈列在计划中了)。当然,如何把这个编辑器打造得更灵活和强大是如今最伤脑筋的问题之一。不过我相信随着不断的推敲,很多真相会逐一浮出水面。