| 個人檔案^Cynthia.相片部落格清單 |  工具  說明 |
|
^Cynthia.游离在游戏与游戏业，计算机与计算机业的错落空间 26 September 我的Space又复活了！吼吼吼~~~一年了，终于又想写点东西了……
 今天又刷夜，感觉时间不够用了，本来还说复习完英语写写软工的文档，可根据那个谁谁谁曲线今天竟然让我复习600多个单词……！现在这点才开始背新的，估计这一晚上就晃过去了……
眼瞅着就十一了，说实话我真的是非常非常地兴奋！这一年就没怎么好好的歇过几天。年初的时候在做那个网游，做到一半就有项目来了，3个游戏一直做到现在还没做完。其间还穿插创新杯比赛，从3、4月份开始忙活，五一歇了有两天吧……下个星期那日子可不能浪费！
说起这个创新杯，我真觉得没咋激动人心。估计是因为今年取消渲染比赛了，用的不是D3D，做出来的东西感觉大家的还都是差不多。我向往的应该是想到一个游戏的好点子那时的兴奋感吧。
最后好歹拿了个第二名回来，感觉奖品的分量有点轻。
今哥们终于来放飞了，他属于不见黄河不落泪型。真希望他赶快适应这里的环境，吹了瓶之后就能觉出来咱这一小撮人为啥聚到这一块了。
还有就是该想想下面该做什么游戏项目了。中小规模的，激动人心的，一炮打响的，实时渲染的，CG结合的，这个到底是什么呢？ 26 July 网游的十条建议一：好友名单分布系统
记得一个朋友说过，他对某款网络游戏已经厌烦了，唯一不舍得就是他在游戏里认识的一群朋友，所以说交友系统很大程度上延长了一款网游的寿命，拥有多张好友名单对玩家来说是一笔精神财富。我想这个系统是 ：当玩家激活某个任务，服务器首先读取他的好友名单，然后分布在他将要面对的任务剧情里，玩家在任务里有机会遇到挂着好友的名字的NPC或者怪物，一定会让玩家欣喜不已。举个例子说，我曾经有一次希望朋友把一部国外黑白片看完，但她觉得这部电影很没意思，于是我就找到该电影的字幕文件，把文本里几个不重要的人名改成她和她所认识的几个名字，结果非常有效，她在好奇和恐惧中看完了这部电影。虽然只是一场恶作剧，但也表明这的确是一种吸引人的好办法。 二：房屋的记数统计 一般游戏里总是喜欢通过网络做些统计调查，不过玩家一般没多少耐心参加，这个系统是在游戏里的房屋或者特定的地方安插上计数器，记录这个地点玩家的流量，由此产生的数据，可以判断出玩家的喜好和习惯，由于这个计数是隐性的，不会被玩家察觉，所以得出的数据是真实的，比传统投票方法要科学很多。另外把投票系统放到游戏里，参加活动可以得到少额奖励也是一个好办法，不过应该限制一人一次。 三：房屋有奖记数 假设游戏中有一间房屋，玩家可以自由出入，当第100名访客进来的时候突然得到了一份小额奖励，第1000名进来的访客得到中额奖励，之后类推，房屋1天记数一次。这就是目前商业活动中经常流行的有奖计数活动，虽然非常俗套，但玩家还是喜欢这种稍微带些博彩性质的活动，前提是不要触及国家禁令。另外网游中会经常出现规划区域不符合玩家习惯，采用这种办法也可以吸引部分玩家。 四：宠物心情系统 宠物有自己的心情指数，当玩家坐在地上休息的时候，宠物在旁边会根据心情做出不同的行为，心情指数高的时候它会围着主人转，或者做出友好的动作，心情平静的时候也会发呆发困，愤怒的时候它会撕咬你或者倒地扮装死状等，宠物的心情指数可以单独成为一个系统，也可以取自目前网游流行的宠物忠诚度系统。
假如两个玩家各自带着宠物在路上聊天时，他们两个宠物也会跑到一起，做些友好的动作，但如果两个宠物心情都不好，会发生打架现象，多个宠物聚在一起甚至会引发一场作模作样的小会议。 六：宠物感情系统 目前网络游戏都非常注重女性玩家群体，拥有大量女性玩家自然会吸引大量男性玩家，很容易引领一款网游的良性发展。关于吸引女性玩家的因素，我认为目前最有效的办法是休闲小游戏和可爱的宠物系统，现在先谈一下增强宠物系统的办法。虽然很多网游都有情侣系统的设定，但目前关于宠物情侣系统还是空白，如果游戏中的宠物也会恋爱结婚，会让游戏的方式更加丰富，由此会引发一些有趣的现象，例如一对男女的宠物发生感情，从而引发主人之间的感情，或者同时喜欢两个人，却只能和一个人结婚，为了弥补这种遗憾心情，让自己的宠物和另一个人的宠物结成连理。总之会产生各种有趣浪漫的事情，自然会受到女性玩家的欢迎和关注。 七：增加休闲竞技为主的娱乐室 这个是提出游戏中的PK系统应该往多元化发展，目前网络游戏PK大多是武斗，甚至可以说血淋淋的，由于玩家素质问题，引发战场上脏话满屏，很令女性玩家反感，但PK行为已经深入人心，最终形式还是要以武斗为主，但作为一款优秀的网络游戏应该加入新的PK方式，好的办法就是在游戏里开放一间娱乐室，里面的竞技项目是休闲小游戏，就是让玩家通过小游戏来一决胜负，并有完善的奖励惩罚规则，这种PK办法暂且就叫它文斗吧。对外宣传上也可以称此游戏拥有文武双全的PK系统。 八：增加生产活动的趣味性 目前网络游戏大都有挂机生产的系统，内容涉及畜牧养殖开山伐木，经常看到一群玩家侧夜苦干，现在我想谈一下生产过程过于枯燥的问题。由于目前很多网游都有生产系的设定，玩家也习惯了这种特殊的游戏方式，但从普通心理的角度来看，这段时间不可避免会让玩家产生注意力转移，因为生产活动枯燥无聊，玩家会跳出来观看电影，或者玩其他网络游戏，我觉得一款好的游戏是不该让玩家注意力离开太久的，我觉得应该有三种工作方式： 1：就是平常的挂机生产，这是玩家已经习惯的方式，保留是应该的。 2：手工劳动方式，速度应该比挂机要快，发现稀有物品的几率也较大，目前以劳动为乐趣的游戏当中，最好的是《牧场物语》，这个游戏里面的劳动都是要用手工完成的，通过辛苦劳动获得的报酬会让玩家很开心，目前这个游戏在国内很流行。可以借鉴一下其玩法，作为一种候补的劳动方法供玩家选择，但并不推荐用于3D游戏，因为很难想象在3D环境下劳动是什么样子，所以增加生产乐趣才是解决之道，方法就是农活时间可以让玩家跑到娱乐室消遣，为了追求真实，玩家角色必须留在农场，但可以借助某个道具把灵魂俯在宠物身上到娱乐室消遣。 3：第三种方式就是直接在农活上做文章，例如挖矿可以和俄罗斯方块结合起来，伐木可以和推箱子结合起来等等。 不管用何种方式，让生产活动摆脱枯燥才是最终目的，现在提出一些改进的设想，仅供参考。
九：在游戏中召唤自己 十：不同线路的玩家同时配合才能完成的任务 举个例子说，如果一组《魔力宝贝》服务器分十个线，有两个玩家是好友关系，玩家A在魔力3线，玩家B在魔力7线，虽然他们都站在法兰城银行，但彼此看不到对方，但从他们的好友名单上可以彼此看到对方所在线路，并可以进行聊天交流。由于发生了数据交互，这就理论上证明可以实现不同线路的玩家共同做一个任务。虽然这本身并没有什么意义，甚至可以说非常无聊，但从目前网络游戏来看，为了满足高等级玩家的需要，制作公司总是想尽办法推出新任务供玩家挑战，由于任务雷同会遇到制作瓶颈，我想采用这种方式可以成为增加难度的一种新途径，对玩家来说也是一种新奇的玩法。联想到多年前有款世嘉MD游戏要通过关机再开机后才能引发剧情发展，虽然这种特别的设定被玩家争议了好一阵子，但事隔多年，还会被人记起，所以偶尔出一些特别的玩法会起到意想不到的效果，细想下来会出现很多特别的玩法，在这里仅提供一种思路供参考。 16 July 如何用正确的方法来写出质量好的软件的75条体会 [转]1. 你们的项目组使用源代码管理工具了么？
应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。 2. 你们的项目组使用缺陷管理系统了么？ 应该用。ClearQuest太复杂，我的推荐是BugZilla。 3. 你们的测试组还在用Word写测试用例么？ 不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。 4. 你们的项目组有没有建立一个门户网站？ 要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。 5. 你们的项目组用了你能买到最好的工具么？ 应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。 6. 你们的程序员工作在安静的环境里么？ 需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。 7. 你们的员工每个人都有一部电话么？需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。 8. 你们每个人都知道出了问题应该找谁么？ 应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。 9. 你遇到过有人说“我以为…”么？ 要消灭“我以为”。Never assume anything。 10. 你们的项目组中所有的人都坐在一起么？ 需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。 11. 你们的进度表是否反映最新开发进展情况？ 应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。 12. 你们的工作量是先由每个人自己估算的么？ 应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。 13. 你们的开发人员从项目一开始就加班么？ 不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。 14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？ 不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。 15. 值得再多花一些时间，从95%做到100%好值得，非常值得。 尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。 16. 登记新缺陷时，是否写清了重现步骤？ 要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。 17. 写新代码前会把已知缺陷解决么？要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。 18. 你们对缺陷的轻重缓急有事先的约定么？ 必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。 19. 你们对意见不一的缺陷有三国会议么？必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。 20. 所有的缺陷都是由登记的人最后关闭的么？ Bug应该由Opener关闭。Dev不能私自关闭Bug。 21. 你们的程序员厌恶修改老的代码么？ 厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。 22. 你们项目组有Team Morale Activity么？ 每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。 23. 你们项目组有自己的Logo么？ 要有自己的Logo。至少应该有自己的Codename。 24. 你们的员工有印有公司Logo的T-Shirt么？ 要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。 25. 总经理至少每月参加次项目组会议要的。 要让team member觉得高层关注这个项目。 26. 你们是给每个Dev开一个分支么？ 反对。Branch的管理以及Merge的工作量太大，而且容易出错。 27. 有人长期不Check-In代码么？ 不可以。对大部分项目来说，最多两三天就应该Check-In。 28. 在Check-In代码时都填写注释了么？ 要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。 29. 有没有设定每天Check-In的最后期限？ 要的，要明确Check-In Deadline。否则会Build Break。 30. 你们能把所有源码一下子编译成安装文件吗？ 要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。 31. 你们的项目组做每日编译么？ 当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。 32. 你们公司有没有积累一个项目风险列表？ 要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。 33. 设计越简单越好越简单越好。 设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。 34. 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。 35. 你们会隔一段时间就停下来夯实代码么？ 要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。 36. 你们的项目组每个人都写Daily Report么？ 要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。 37. 你们的项目经理会发出Weekly Report么？ 要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。 38. 你们项目组是否至少每周全体开会一次？ 要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。 39. 你们项目组的会议、讨论都有记录么？ 会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。 40. 其他部门知道你们项目组在干什么么？ 要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。 41. 通过Email进行所有正式沟通 Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。 42. 为项目组建立多个Mailing Group 如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。 43. 每个人都知道哪里可以找到全部的文档么？ 应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。 44. 你做决定、做变化时，告诉大家原因了么？ 要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。 45. Stay agile and expect change 要这样。 需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。 46. 你们有没有专职的软件测试人员？ 要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。 47. 你们的测试有一份总的计划来规定做什么和怎么做么？这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。 48. 你是先写Test Case然后再测试的么？ 应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。 49. 你是否会为各种输入组合创建测试用例？ 不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚，你是否有时间去运行那么多test case。 50. 你们的程序员能看到测试用例么？ 要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。 51. 你们是否随便抓一些人来做易用性测试？ 要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了，不方便的永久了也就习惯了。 52. 你对自动测试的期望正确么？ 别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。 53. 你们的性能测试是等所有功能都开发完才做的么？ 不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。 54. 你注意到测试中的杀虫剂效应了么？ 虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。 55. 你们项目组中有人能说出产品的当前整体质量情况么？ 要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。 56. 你们有单元测试么？ 单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了——可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。 57. 你们的程序员是写完代码就扔过墙的么？ 大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。 58. 你们的程序中所有的函数都有输入检查么？ 不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。 59. 产品有统一的错误处理机制和报错界面么？ 要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。 60. 你们有统一的代码书写规范么？ 要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。 61. 你们的每个人都了解项目的商业意义么？ 要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。 62. 产品各部分的界面和操作习惯一致么？ 要这样。要让用户觉得整个程序好像是一个人写出来的那样。 63. 有可以作为宣传亮点的Cool Feature么？ 要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。 64. 尽可能缩短产品的启动时间要这样。 软件启动时间（Start-Up time）是客户对性能好坏的第一印象。 65. 不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。 66. 你们根据详细产品功能说明书做开发么？ 要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。 67. 开始开发和测试之前每个人都仔细审阅功能设计么？ 要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧” 68. 所有人都始终想着The Whole Image么？要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。 69. Dev工作的划分是单纯纵向或横向的么？ 不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。 70. 你们的程序员写程序设计说明文档么？ 要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。 71. 你在招人面试时让他写一段程序么？ 要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。 72. 你们有没有技术交流讲座？ 要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。 73. 你们的程序员都能专注于一件事情么？ 要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。 74. 你们的程序员会夸大完成某项工作所需要的时间么？ 会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。 75. 尽量不要用Virtual Heads 最好不要用Virtual Heads。 Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对Resource Manager的。 14 June 游戏的大忌---看《极品飞车》最近玩了玩EA的《极品飞车地下狂飙2》这款游戏，有些看法不吐不快，什么游戏是一款垃圾游戏？ 个人感觉《极品飞车》就是。 先不说它和《GT赛车》、《SEGA拉力》的比较，也暂且不谈游戏画面、音效等，仅从我实际的上手感受来看，它犯了几个我最不能忍受的错误： 1-------没有整体游戏操控的归一性，连贯性。这我没有想出啥好词来形容它，意思就是：几乎所有的游戏，玩家从初上手到适应，一直到最后游戏的结束，只要游戏模式没有改变，就应该有且只有一种游戏规则和操控感受（也就是手感），但是《极品》一看就是为了为了迎合现在的漂移热，面对大量的《头文字D》Fans，可怜手中的物理子系统（可能和最最早的游戏引擎也有关系），整不出啥花花来，于是乎简单生硬的修改几个参数，让你的爱车可以在专门的“甩尾赛”里做出各种诡异的动作。诸如：在一档的情况下如果你按左或右2秒，那么你就只能原地转圈了，反方向打轮也没用，只能刹车，停住重来；一次我以30迈的速度过弯，迎面来了一辆20迈速度的蜗牛车，于是乎我在1秒内做了一个原地540度的Drift！你可能会问：30迈的速度也叫赛车？实际上在所谓“甩尾赛”里你是不可能上3档的（稍后说明），大概就是一堆蜗牛在围一个圈圈扭屁股之类的……原本“漂移”真正的意义，油门全开Drift4档过弯的情景你是不可能看到的，并且由于“甩尾赛”和平时车辆的手感是完全不一样的，让人很难适应（还有“直线加速赛”）……感觉被耍了； 2-------抓狂的一点，切记，永远不能让玩家产生无尽的重复性的挫败感。还是“甩尾赛”，它是以通过甩尾翻倍分数，看分数得胜。但是，整个过程你不能接触任何异物……明白我的意思了么？当你费劲巴拉的甩出一个“优异的甩尾！”“超炫！”“令人惊讶！”10000分的高分时（有一场需要175000的分数才行），眼瞅着墙壁刹车刹车看你以1迈的速度慢慢“摸”了一下墙壁，0分，你是啥感觉？！由于其物理的极不合理当你数次甩尾数次“摸”了一下前面的蜗牛车时，0分，你又是啥感觉？！在这个过程重复了100遍后，我当时就想让制作群里的人拿车给我原地表演一下原地30迈撞飞（游戏中景象），他要做不出来我就拿汽车拍他脸！气煞我也！！！ 两点致命伤，足以掩盖其所有的优点。 不知是游戏引擎的原因，总感觉一款游戏1代做好了，2代3代就能越来越好，难不成从《极品1》开始，就奠定了它的命运？？ 21 May 谨以此篇感慨一下过去和现在，没讨论未来最近状态不佳，胡思乱想到了原来高中的生活...... 高一时就想玩游戏，本打算中考直接去学动画完事，我爸不干，上了北医附中； 记得第一次期中考试，我数学14分，全年级倒数二三十名，这下麻烦就大了；但是在这里，我郑重地得感谢两位老师：一位是我的班主任牛老师，还有一位语文倪老师；那时候觉得倪老师离我很近，想说的话在周记里可以畅所欲言，老师留的题目我几乎没写过，全写的动画啊游戏啊盗版啊之类的...于是乎我的语文成绩最好时年级第15名；但是后来语文老师换了，要知道习惯很难改变的，语文就... 413分，我想考个本科，立即复读。 倒是一点也不痛苦，是我学的最高兴的一年。嗯，大概流程是：第一学期期中，我上课认真听讲课下作业加复习；期末，我上课认真听讲课下作业再玩游戏；第二学期期中，我上课认真听讲和玩游戏；高考前，我在玩游戏。每天中午我骑车去双安商场买一个币打穿《合金弹头2》，正好回来上课（到最后我可以用各种非常变的方法打穿它来愉悦观众）。高考嘛，因为有了一次经验，加上一点运气和99%的实力，我513分来了工大（我一直深信要不非典的话我不会这么高）。 大学的我是决定要努力学习的，我对游戏的欲望已经逐渐消失殆尽。但是我发现，我不可能做那些我不愿意的事，但是对于我喜欢的，我可以把它做得很好。对于大学本身的课程，我失望了。要不是在放飞，我可能会重蹈覆辙。 高中多少次在父亲的责骂声中立志：“我以后就做游戏给你们看！！！”今天已经走出了这一步。 我感谢大家的支持和帮助，曾有一段时间我是真的不行了，现在想起来，这种感觉很奇妙。 现在的我，自我感觉工作学习和感情样样顺利，高兴啊！ Ps：大学前本人的装备：DC x1，SS x1，WSC x1，GBP x1，GBL x1（夜光GB），GBC x2（出租车上丢了一个），GBA x3（n次想好好学习给卖了，结果没过多久换了新的=_=） 这算放荡么？算么？不算么？那只是在玩游戏没什么想法啊！不算吧？
|
||||||||
傳送私人訊息
訂閱 RSS 摘要
告訴朋友
新增至 Live.com
新增至您的朋友網路
註冊通知
牛老师嘛，我印象最深的就是，当时和我一起有个同学天天玩GB，牛老师知道，只有一种方法能阻止我们：把GB放她那，每天中午午休时去老师那取；于是乎就出现了别人去班主任那问问题我去玩GB的滑稽场面；那时我们几乎天天翘课，我们可以在历史课的时候骑车二十分钟去玩游戏，体育课的时候陪某某逛鼓楼买东西，无聊的课甚至愿意在操场转上20圈...总的说翘了怎么也有200多节课吧，只是有一次他太过了，竟然一个星期不来上课在家复习，被判为处分...再后来，为了升级家里的PC,我考进了重点班完成任务......再利用时间去玩CS，这时候已经高三了......直到高考。|
|
