WindCould
Posted: 三月 30th, 2010 | Author: 达达尼昂 | Filed under: 网络日志 | 1 Comment »
几周过去,基本已经适应了新的工作环境和工作节奏。
节奏
终于不必今天写策划文档明天做后天测大后天上线了…
了解、分析、借鉴、创新,可以花时间写一份至少自己能够满意的案子。
客户端
从手机无端WAP到电脑客户端MMO,随着开发环境的变化,设计理念和思路也相应发生了改变。
很多之前很难实现的东西,现在客户端都可以帮助实现了。(眼泪哗哗的…)
客户端是强大的,但也是“不老实”的,关键数据的服务器检测是必须的。
哪些是客户端可以做的,哪些是服务器需要做的,这些都需要了解。
而在数据传输的过程中对网络环境的要求以及检测的时候对服务器的资源消耗问题也都是需要考虑的。
记录几篇文章,学习下——
《游戏策划需要了解的程序知识》
《策划需要了解的引擎结构》
数据架构
现在的游戏早已不是单服务器了。
数据是怎么存储的?大区?频道?区域?系统?
数据是怎么交换的?不同的服务器数据能读取到吗?读取耗资源吗?
哪些计算可以客户端帮忙计算,哪些必须服务器进行验证?
恩,需要了解的东西太多了。
蚊子写的文章,记录学习下——
游戏策划需要了解的网游数据结构(一)
游戏策划需要了解的网游数据结构(二)
脚本
脚本可以做很多高效率的事情。
在时间管理上,有个2分钟原则。
就是说,如果一件事在2分钟内可以解决,那么任何时候都要立即处理掉而不是拖延它,因为为了考虑怎么安排处理所花的时间或许已经超过了2分钟。
而脚本呢,如果能由策划更快捷地直接写作,比之花时间向程序进行说明然后才进行开发要来的更快。
同时,由策划写脚本来实现一些游戏系统,可以更好的使最后的系统表现和“设计原型”更加吻合。
倒腾过WOW插件,不过,迟早得跟着M学写Python。:)
关于Python的资料就不列出来了,很多的。
当然,更关键的是,我非常认同《可爱的Python》里说的一句话——你不必等完全学完一种语言才开始运用它。
解决实际问题是为了掌握知识的根本。
用户体验
当我第一次了解到用户体验、了解游戏策划中的用户体验设计时,我才知道,原来游戏应该这么设计的。
当我欣喜于此时,才发现,其实N久以前已经有N个人在游戏设计中提到了用户体验…(或者可以这么说,脑子里蹦出的这个概念也是N次无意识接触的一次聚焦吧..有点绕口…)
知道了用户体验,就忍不住去分析生活中碰到的各种各样的产品设计理念。
最近,已经到了“令人发指”的状态,举例说明……
马桶
冲水按钮。
家里的马桶有2个按钮,2个按钮对应的水排量不同,主要是为了节水用。不过,2个按钮尺寸区别不大。可能是整体区域有限,如果区别过大会导致小按钮过小吧。改进方案:用不同颜色标示大小或者直接在按钮上用凹凸字来区别大小。
公交车
重复刷卡提示。
上海公交车一卡只能刷一次,如果多次刷卡不会扣费但会提示“不能重复刷卡”。
前天坐123路公交时发现有个问题,卡只要贴到感应器时间超过2秒就会进行重复刷卡提示。我刷的时候就碰到了,提示音吓我一跳,还以为余额不足或是卡消磁了呢。但后面刷卡的人有60%都出现了重复刷卡提示,这让我觉得此车的刷卡系统肯定是有问题的。
因为按照大家平时的习惯,单次刷卡肯定会把卡贴到感应器听到扣费提示音后才移开,而如果是想刷2次的话,会有一个离开感应器再贴过去的过程。
虽然不清楚感应器的工作原理,但或许可以这么改进一下:连续感应,如果没有离开感应器的操作则不扣费、不提示;延长重复刷卡间隔时间,间隔时间内不管刷多少次都不扣费、不提示。
电梯
警报按钮。
公司写字楼的电梯设计有问题…
出现紧急情况的警报按钮居然在开门按钮和关门按钮之间…
我已经经历了2次按错按钮的情况(都不是我按的),那个警报声还是蛮精神的…
这个设计明显低端了,改进方案嘛,很简单,学其他电梯的,将警报按钮单独放到楼层按钮的上面。或者原设计者是怕如果有1.1米以下的小孩单独进入电梯发生意外够不到警报按钮的情况?但对此这栋办公用的写字楼,应该没有小朋友独闯吧。^^
提问:为什么Office2007默认界面是淡蓝色底色呢?
天之虹昨日发了篇博文,决心要进行一些调整。
这显然是他深思熟虑后的决定。
作为读者,当然自私的拿出钱老先生的“鸡蛋理论”,希望能看到更多的优秀译本。
作为朋友,亦希望天之虹能主导出一款成功的产品。
作为未曾谋面但受他馈赠两份译本的我,只能在此祝福他好运。
友情推介:
《游戏设计的艺术:一本透镜的书》
http://www.youxihun.com/bbs/thread-7640-1-1.html

最新评论