高手讨论→RM里你们在乎程序效率吗？

九夜神尊

忘了是哪位高手说的，RM的内部结构不是最优的。

那时候我还不懂，只是记住并知道这么回事。

在我写自己的系统的时候，写到了人物属性的取得。
这个模块我想大家都很熟悉，防御 =武器防御+帽子防御+盾防御+衣服防御。

但是，每次获取防御力都要经过这么一次运算，然而结果却大部分相同。显然程序效率低很多（当今的电脑似乎可以忽略）。

不过我想，RM作者最初不会没考虑到，而是为了让使用者容易上手。如果把每个属性保存成一个变量，每次读取的时候，直接
调用，在换装备的时候，再改属性。虽然效率会高很多，但是新手却很难上手。

不晓得各位高手对程序效率怎么看待的，就我本人而言，一个程序在我能力下，有优化的空间，我就觉得这程序没完成。

不过像我说的，属性的获取我倒是决定不优化，因为优化后会与现有大部分脚本脱节。

以下是我的一个感叹

血条，每次都要描绘么？

不，只需要在HP 或MAX_HP有改变的时候重新描绘

每次改变都要重新描绘么？

不，血多了就描绘一段红色把黑条盖住，血少了就描绘一条黑色把红条盖住

然而最后要吐自己的是：在乎效率就别用RUBY

potatoking

考虑到现在机子的效率
还是把更多的精力投入到游戏设计上比较有爱啊...

applesnake

RM以牺牲效率和灵活性来换取简单性。越灵活的系统效率会越高，但是使用会更复杂。灵活性和复杂度并非简单线性关系，增加一个维度的灵活性的同时复杂性会随之成几何级数的增长——对比2D游戏和3D游戏的绘图过程就可见一斑。
对于现在的计算机游戏逻辑的处理的开销几乎可以忽略，除非超大型的循环、遍历或复杂的物理，AI计算。
脚本本身具有很强的针对性，而RM又是在这个基础上做了进一步的强化——针对多数2D RPG。所谓需求决定实现，所以RM的体系结构并不适用于构造过于复杂图形子系统。
对现有体系结构中的图形和特效的处理需要专业背景和对RM体系结构的深入了解，一般的使用者无法做到。建议：一般使用者不要在RM中使用脚本构建过于复杂的图形子系统，因为这超出RM框架本身包括图形库的能力。

wubugui

对于一般程序已经不在乎效率了，在乎易读。

九夜神尊

回复 熊的选民 的帖子

现在在实现任意几何图形范围内对象索取。

紫苏

回复
并不只是寻找交集，如果坐标是连续的，就得进行距离检查。比如把“重叠“定义为“距离小于5.0“

    ...
熊的选民 发表于 2010-10-23 05:53

换汤不换药，数组转换为散列表后，想如何实现元素的二元关系都行，普通情况下是判断相等，你这里可以判断距离

熊的选民

回复 九夜神尊 的帖子
期待能用上你做的4叉树系统

   

九夜神尊

托紫苏大人的福，我已经开始对4叉树研究了。
已经研究出来最快速度获得指定范围内的对象了。

熊的选民

回复 紫苏 的帖子
并不只是寻找交集，如果坐标是连续的，就得进行距离检查。比如把“重叠“定义为“距离小于5.0“

   

紫苏

主而rm脚本的效率又不高，用高级数据结构的额外支出可能还抵不上带来的收益。
熊的选民 发表于 2010-10-9 15:32

Ruby 有本地接口，可以用 C 来写数据结构。

忽然想到一个问题。假如有m个子弹和n个敌人，都储存在数组中。如何在最短时间内找出所有重叠的子弹-敌人对 ...
熊的选民 发表于 2010-10-23 03:43

这个就是求交集的算法了，目前最常见的做法是把其中一个方位向量的数组转换为散列表，然后迭代另一个方位向量数组，判断当前元素是否在之前转换的散列表中。
见：http://rpg.blue/forum.php?mod=viewthread&tid=157558
不过这个也是限制在你用无序的数组保存方位的假设上。如果是有序结构或四叉树，一次遍历就完事儿了（当然，如果用了有序或四叉树结构，那可能就不会这么做碰撞检测了，而是在插入/移动节点的时候就判断）。