关于逆推设计的一个比喻

来上海后,经常听到”设计目的”这个词。很多时候,我们在讨论一个新的玩法、机制的时候,都会先被质问设计目的。
但很多人在讨论中往往会陷入这样一种逻辑错误:设计A能够实现目的1,所以设计A是实现目的1的必要条件。
而实际上,能够实现目的1的设计方案有很多,比如ABCDEFG,但为什么要选择A,或者说当下为什么要先做A,才是真正需要讨论的。

认识到这点之后,我立刻对从前诸如“你觉得XXX的设计目的是什么”这样的逆推问题,有了新的认识。
继续阅读关于逆推设计的一个比喻

C#几对修饰符的比较(三)implicit与explicit

这几天写序章剧情战斗模版时,出现一些让人感觉很难受的类型转换的情况.
简单说就是从一个正常情况下全是class A实例的池子里,取出object b (b实际上也是A类型的),赋值给一个class A的变量a.这时,就需要把b再强制转换回class A.

这个过程虽然没什么问题,但是让人感觉很蛋疼. 究其原因,应该是因为从池子里取出object的方法为了追求其普适性,而把返回值设为了object.
现在产生了这种不太自然的情况,让我开始怀疑这种追求普适性的做法是否是正确的.也许我应该用泛型或者重载处理下?
继续阅读C#几对修饰符的比较(三)implicit与explicit

终于知道在比较时为何要把值放在变量前面了

之前看程序的代码,总是发现他们在做if判定时,往往习惯把常量放在比较符号前面,把变量放在后面.例如if(null != myVariables).

从直觉上讲,这种写法是有些别扭的,但这种有些别扭却又十分刻意的处理,总是让人忍不住去思考其原因.之前一直没想明白,以为这可能是某种可以提高运算效率的技巧.
~~比如判断myFunc()==null,肯能就要先算出myFunc的值再和null比较,而把null写前面,就不用计算myFunc()了.~~

当然,事实并非如此. 继续阅读终于知道在比较时为何要把值放在变量前面了

游戏序章战斗模板DEMO设计案(上)

之前讲过要基于Ellan Jiang大神的Unity游戏框架做一个以有限状态机实现的流程控制机制为基础的序章剧情战斗模版DEMO。

因为现在实习公司的序章剧情战斗(注意不是新手引导)完全是程序将整套写死的代码嵌入实现的。也就是说,任何关于序章剧情战斗本身的流程或细节变动,都需要程序开发。我的第一感觉就是,“这么做有问题啊”。

继续阅读游戏序章战斗模板DEMO设计案(上)

C#几对修饰符的比较(二)override与new

override和new都是用于实现多态的修饰符。

貌似比较通用的译法分别是重写和覆盖,也有分别叫覆盖和隐藏的。个人更倾向于前一种译法,不过也不用在这太纠结。

  • 用法上,二者的区别在于:

    override专用于虚拟(virtual)方法、抽象(abstract)方法和接口(interface),不能用于实方法;
    而new则用于实方法,也可用于虚拟方法,但不能用于抽象方法和接口。

继续阅读C#几对修饰符的比较(二)override与new

C#几对修饰符的比较(一)const与readonly

const修饰符用来声明常量字段或常量局部变量;readonly修饰符用来声明字段是”只读”的。

二者的作用相似,都是修饰声明一个常量。但在实现方式上有所区别,因此也有很多特性区别,导致它们的实际应用场合也不同。

二者根本的差别在于:const修饰的是静态常量,readonly修饰的是动态常量。

继续阅读C#几对修饰符的比较(一)const与readonly