突然发现，RGSS3默认脚本也会卖萌？

taroxd

moy 发表于 2014-5-25 19:02
japanese?只是提供个方法?然后告诉你“哼，你们这些破解汉化的，看到没，这是日本软件！”
不嵌套到底是 ...

真·有病

1. \V[\V[1]\V[2]]

复制代码

然后咱破解汉化的应该这么玩
[pre lang="ruby" line="1"]def chinese?
  return true
end
alias japanese? chinese?[/pre]

DeathKing

taroxd 发表于 2014-5-25 15:58
应该是和exp一样，因为很重要所以要写两遍……

　　是的，为什么不使用while来处理，直至处理完毕呢？于是，不要怕，大刀阔斧地改吧！于是我们立马注释掉了#232和#233，添加上我们的代码：

　　正当我们心满意足地欣赏我们的杰作时，你突然想到下面的自指会让我们陷入无穷尽的循环中。

　　你轻蔑地说：“啧！哪里有这么蛋疼的人，写得出这么蛋疼的指令？”而当你冷静下来，你会觉得，即时是嵌套两层，也是非常少见了，嵌套多层更是比“使用奇怪的自指”罕有。

　　一方面，我们希望让系统的复杂度保持足够的低，换句话说，我们不太希望”变量存放的地址是另一个变量的地址，而另一个变量里面存放的是另一个变量的地址“这种type ***之类的数据存在。这类功能有更简洁、明了的表达方式，不用让我们的思维兜圈子。这样来说，默认脚本提供了一次嵌套，已经能囊括99%的情况了。

　　至于Hash和Array的效率问题。Array的IO操作都能在O(1)时间内完成，这是由于Array可以通过索引快速计算出元素的地址。而Hash依赖于哈希函数hash()（或者称为key()）的定义，如果有碰撞，hash还得处理碰撞，如拉链法就得额外增加一个链表遍历的开销，开放寻执法得额外增加一个开放寻址的开销。

　　Hash与Array的相比，优势是很明显的：Array只能以整数（索引）为Key，而Hash可以以任何对象为Key（原理上是将对象映射为整数）。另外，假设为了寻找字符串“target"，使用数组无序存储，则需要花O(n)的时间去遍历Array，而是用Hash，可以将时间复杂度降至O(1)。

　　RM最大的开销来自于图像的描绘，在Ruby层面上的计算开销是很少的。就RM数据的规模来说，Hash和Array对效率的影响并没有那么严重。根据实际情况和方便程度决定使用Hash还是Array即可。

moy

DeathKing 发表于 2014-5-26 00:10
　　是的，为什么不使用while来处理，直至处理完毕呢？于是，不要怕，大刀阔斧地改吧！于是我们立马注释掉 ...

果断好评了
DK君怎么看待默认脚本里调用的一层套一层的方法？如果是你的话，你会希望这种分割的工作细分到多少层或是多细截止？

DeathKing

moy 发表于 2014-5-26 00:31
果断好评了
DK君怎么看待默认脚本里调用的一层套一层的方法？如果是你的话，你会希望这种分割的 ...

大概是哪个地方？

如果不是递归调用，方法调用的深度大概再3~5层应该就够了。这种情况下，逻辑已经被分得足够细了，没必要再细化。

taroxd

DeathKing 发表于 2014-5-26 06:17
大概是哪个地方？

如果不是递归调用，方法调用的深度大概再3~5层应该就够了。这种情况下，逻辑已经被分 ...

比如说 apply_critical 这个方法，只有一次被调用，然后我记得调用它的方法也只有一次被调用。（我现在没有环境，有可能会记错~）
就是方法拆的很散吧。

我觉得这个风格很适合我们自定义脚本呢~ 也很适合子类覆盖。说实话我挺喜欢这个风格的

moy

taroxd 发表于 2014-5-26 07:42
比如说 apply_critical 这个方法，只有一次被调用，然后我记得调用它的方法也只有一次被调用。（我现在没 ...

=-=是啊，估计也是考虑到肯定有喜欢改暴击方式的人，所以把暴击的实现单独拉出来了。
我就看到人问暴击怎么改，想要根据技能加倍数或者其他方式。
我自己的是根据幸运敏捷有加成。便利呢~