AsADesigner(2011.5)

2011.5.9
看了一下骑宠的文档,极其让我郁闷.
第一,复杂了设计框架,新定义了一类对象,却又没多大用处.
第二,复杂了游戏玩法,又要从蛋糕里挖一块儿出来给坐骑,还是很小一块.就像宠物装备一样,可弃.
除了提供或许可能能够捞钱的地方外,看不到设计目的.
张老大:规则是越简单越好.越简单的规则,可塑性也就越强.
从实现来看,功能应该是具有复用性的.设计同样如此.
反思以前的设计,为什么那么多明明可以做成通用的结构,非得分开?因为个人或领导的喜好问题?
例如角色宠物怪物NPC他们本质有什么区别?
例如为什么法宝骑宠飞剑宠物不能以物品的形式存储?
例如任务为什么要根据分类分别写代码而不能根据同一整套底层支持进行配置?
我相信,这些问题如果想通了,做好了,策划也就从中解放出来了.
设计系统,真的不是什么难点,也不值得炫耀.任何一个能够逻辑思考的人,培训个半年一年就差不多了.
3位老同事的共同声音:系统策划的活儿迟早是(有游戏经验的)程序的地盘.
能设计出具备可玩性的基础框架,或者有意思的关卡,或者让人感动或大笑的剧本,那才叫游戏设计师.
2011.5.12
战斗系统,我跌了个大坑.
尤其是在连击这个地方.如果保护和其他游戏的设计完全一样,那么连击就不存在现在的问题了–取不到上次的伤害.这个是非常致命的.
这就是刻意创新的代价.
金字塔,或许是另一个坑.
现在回想制作金字塔的目的:这玩意到底是需求本身呢,还是需求分析呢?还是两者皆是?
好吧.现在貌似是最后一个答案.但这样好不好?
我仍然不是程序的底子.和程序过金字塔,结果变成了”程序是按XXXX方法实现的,所以要把金字塔的对应部分进行修改”
和程序探讨程序框架?这不是找死么?
那金字塔应该是什么?
今天我的答案:金字塔应该不用管实现,而是系统化地阐述需求.
这不是偷懒–事实上,策划的结构和程序的结构真的是两码事.
我想:或许我们项目需要一个专业的需求分析师.当然,毫无疑问,很难找.