游戏策划 Game Design » 工作笔记

反打金工作室

达达尼昂 — Mon, 19 Jul 2010 13:38:41 +0000

上周BD的同学专门过来介绍了下打金工作室的情况以及相关的应对措施。
（才发现，原来做讲解的DF兄就是拓展时咱黄队的队长…）
之前跟踪D游戏也有一段时间，眼见着外挂、打金工作室在D游戏中的横行泛滥到最近的销声匿迹，也一直想说说这方面的东西。
今天一并做个小结，自己也再整理下思路。

*********写完了又删掉了*********

不说太细了，简单的1234吧。

1、没有哪个游戏能从技术上完全的封堵住打金工作室以及外挂。
2、任何一个游戏都能从运营上有效抑制打金工作室以及外挂。
3、但是，在不伤害游戏本身，甚至使得打金、外挂行为能以良性的状态存在于游戏之中并伴随游戏健康发展，则更大部分需要策划来周密的设计。
（这个是我之前考虑较少的，我认为非此即彼，打金和外挂必须是“切吧剁吧”。不过，现在转变了思路，应该可以容忍一部分人在游戏中的“盈利行为”，只要这些利益是他付出了相应劳动并且不会破坏其他玩家的游戏体验。）
4、打金工作室的收益=（产出-成本）*（1-风险）
减少产出：增加绑定货币，同时随着游戏等级增加，所产出货币的“非绑定比”下降；
增加成本：前期自产自足，非绑定货币产出在游戏中高等级；非绑定货币的产出采用活动副本等外挂难以完成的方式；
增大风险：技术上的严密监测+运营政策上的高压+法律范围内允许的其他手段；

BTW：最后还是说说D游戏吧~
D游戏之前也是外挂横行、打金猖狂，现在回过头再分析，从上文第4条开始慢慢解剖——
产出：由于单一的经济系统以及单一的产出方式，游戏币以及能获得游戏其他任何物品，玩家对于游戏币的需求非常之大；而在游戏设计上，使用外挂的收益是大于不使用外挂的(万恶的运镖)；
成本：由于反外挂这块没有进行足够的优化，加上游戏中的硬通货(师门材料)均在低等级区域产出，导致打金成本极低；
风险：小人之心一把（不过事实上也是），可能是考虑到游戏初期的ACU问题，运营方在打击工作室及外挂上很长一段时间是非常的不积极；
较高的产出，极低的成本，较低的风险，在打金工作室看来，D游戏实在是片“沃土”….
现在，服务器列表红的变黄、黄的变绿，但是游戏中再也看不到蚂蚁搬家式的外挂角色了。
（一度我以为D游戏就这么被外挂给废掉了，外挂问题根本解决不了，现在看来，真的要封外挂打击工作室，技术上是绝对没问题的，问题就是怎么样在初期就设计好，以免出现“杀敌一千自损八百”的情况咯。）

未完待续
那么，作为设计者究竟应该怎么做呢？应该这么做——
（内容回复后可见）

Worknote[20100328]

达达尼昂 — Sun, 28 Mar 2010 16:34:21 +0000

几周过去，基本已经适应了新的工作环境和工作节奏。

节奏
终于不必今天写策划文档明天做后天测大后天上线了…
了解、分析、借鉴、创新，可以花时间写一份至少自己能够满意的案子。

客户端
从手机无端WAP到电脑客户端MMO，随着开发环境的变化，设计理念和思路也相应发生了改变。
很多之前很难实现的东西，现在客户端都可以帮助实现了。（眼泪哗哗的…）
客户端是强大的，但也是“不老实”的，关键数据的服务器检测是必须的。
哪些是客户端可以做的，哪些是服务器需要做的，这些都需要了解。
而在数据传输的过程中对网络环境的要求以及检测的时候对服务器的资源消耗问题也都是需要考虑的。
记录几篇文章，学习下——
《游戏策划需要了解的程序知识》
《策划需要了解的引擎结构》

数据架构
现在的游戏早已不是单服务器了。
数据是怎么存储的？大区？频道？区域？系统？
数据是怎么交换的？不同的服务器数据能读取到吗？读取耗资源吗？
哪些计算可以客户端帮忙计算，哪些必须服务器进行验证？
恩，需要了解的东西太多了。
蚊子写的文章，记录学习下——
游戏策划需要了解的网游数据结构（一）
游戏策划需要了解的网游数据结构（二）

脚本
脚本可以做很多高效率的事情。
在时间管理上，有个2分钟原则。
就是说，如果一件事在2分钟内可以解决，那么任何时候都要立即处理掉而不是拖延它，因为为了考虑怎么安排处理所花的时间或许已经超过了2分钟。
而脚本呢，如果能由策划更快捷地直接写作，比之花时间向程序进行说明然后才进行开发要来的更快。
同时，由策划写脚本来实现一些游戏系统，可以更好的使最后的系统表现和“设计原型”更加吻合。
倒腾过WOW插件，不过，迟早得跟着M学写Python。:)
关于Python的资料就不列出来了，很多的。
当然，更关键的是，我非常认同《可爱的Python》里说的一句话——你不必等完全学完一种语言才开始运用它。
解决实际问题是为了掌握知识的根本。

用户体验
当我第一次了解到用户体验、了解游戏策划中的用户体验设计时，我才知道，原来游戏应该这么设计的。
当我欣喜于此时，才发现，其实N久以前已经有N个人在游戏设计中提到了用户体验…(或者可以这么说，脑子里蹦出的这个概念也是N次无意识接触的一次聚焦吧..有点绕口…)

知道了用户体验，就忍不住去分析生活中碰到的各种各样的产品设计理念。
最近，已经到了“令人发指”的状态，举例说明……

马桶
冲水按钮。
家里的马桶有2个按钮，2个按钮对应的水排量不同，主要是为了节水用。不过，2个按钮尺寸区别不大。可能是整体区域有限，如果区别过大会导致小按钮过小吧。改进方案：用不同颜色标示大小或者直接在按钮上用凹凸字来区别大小。

公交车
重复刷卡提示。
上海公交车一卡只能刷一次，如果多次刷卡不会扣费但会提示“不能重复刷卡”。
前天坐123路公交时发现有个问题，卡只要贴到感应器时间超过2秒就会进行重复刷卡提示。我刷的时候就碰到了，提示音吓我一跳，还以为余额不足或是卡消磁了呢。但后面刷卡的人有60%都出现了重复刷卡提示，这让我觉得此车的刷卡系统肯定是有问题的。
因为按照大家平时的习惯，单次刷卡肯定会把卡贴到感应器听到扣费提示音后才移开，而如果是想刷2次的话，会有一个离开感应器再贴过去的过程。
虽然不清楚感应器的工作原理，但或许可以这么改进一下：连续感应，如果没有离开感应器的操作则不扣费、不提示；延长重复刷卡间隔时间，间隔时间内不管刷多少次都不扣费、不提示。

电梯
警报按钮。
公司写字楼的电梯设计有问题…
出现紧急情况的警报按钮居然在开门按钮和关门按钮之间…
我已经经历了2次按错按钮的情况(都不是我按的），那个警报声还是蛮精神的…
这个设计明显低端了，改进方案嘛，很简单，学其他电梯的，将警报按钮单独放到楼层按钮的上面。或者原设计者是怕如果有1.1米以下的小孩单独进入电梯发生意外够不到警报按钮的情况？但对此这栋办公用的写字楼，应该没有小朋友独闯吧。^^

提问：为什么Office2007默认界面是淡蓝色底色呢？

产品设计的主要问题[GameDesign半年工作总结之四]

达达尼昂 — Sun, 07 Feb 2010 17:14:13 +0000

产品设计的主要问题[GameDesign半年工作总结之四]

因为是和其他策划一直在外租的房子，所以，我们在下班后经常讨论些问题，包括关于产品设计上的问题。
应该说在近半年的开发过程中，我们都能隐约觉得设计上存在一些问题，但是具体的问题是哪些却不能很明了的指出。或者说，某些地方明白存在什么问题但很多却无法给出相应的解决方案，有些是因为经验不足、有些是技术原因，还有些是项目时间安排的原因。

曾见到有人在网上看过一些资料、泡过几个论坛，就敢声称会写“完整”的策划案甚至是商业立项书，但写出来的东西有什么用呢？
下面列出的主要问题我将标题加粗了，恬不知耻的说，有的在入行前自己似乎也能“侃侃而谈”。
但现在写到这些，我知道，如果要真正的解决问题，每一点都需要长时间的积累和实践。
我想说的是(也是Luo之前和我们说的)，很多事情只有自己亲身经历了才有最深切的体会。

在开始正文前最后说明一下：
本来此篇博文准备放在《项目失败的教训》里的，但由于众所周知的原因，《教训》一文成为了incomplete版本，而以下内容也剥离出来了。
OK，开始正文吧。

———继往开来的分割线———

由于项目是WAP MMO RPG，故部分内容仅适合手机（网页回合制）网游。

1、对于手机平台的限制性了解不够。
毫无疑问，手机有它方便快捷、随时随地娱乐的优点，但其限制性也非常的大，设计时需要非常注意这些。
具体说了，手机平台的主要限制存在于以下方面：操作性、网络传输、流量限制、浏览器及其他。

操作性：手机用户需要关注小小屏幕上的内容，并在巴掌大的键盘上进行操作，加上有可能在使用手机还在做别的事情，这就要求操作必须尽可能的方便——页面跳转合理、UI设计合理——最后使得操作按键数减少、次数减少。

网络传输：虽然WAP机制对网络的要求并不是特别高（偶然短时间断线也可以继续玩），但由于国内通信网络还不是特别稳定，数据传输还是存在一些延迟的，普通页面打开需要1s~8s。
而网络限制也直接导致了PVP的种种技术问题（即时计算、延迟、断线），即时的PVP几乎无法实现。
参考其他WAP游戏以及与WAP类似的webgame、SNS APP，大多省去了中间的过程，直接给一个战斗结果。（我们几个策划认为玩家没法自己操作战斗会比较无趣，不过想想那技术限制的种种，真的要即时PVP似乎可以称得上“痛苦”，而对于玩家来说，“结果”似乎是更重要的事。[这个在后面会提到]）

流量限制：由于目前包月流量的价格还是比较高的（特别是超出限额之外的流量费简直高的离谱），玩家对于流量还是非常敏感的。
刚入行时，被告之流量分成是盈利的一种。当时我并不知道这个比例是什么样的，但我清楚上海移动GPRS流量包月费用在5￥-200￥(30MB-5G)不等。对于正常浏览网页而言，100MB以内（甚至是10MB）的流量是远远足够了。我猜这个“流量分成”的所得应该非常的小，待后来自己分析认为，对于道具收费游戏而言，这个所谓分成实在是不值一提。
精简页面元素、优化页面代码使得页面体积缩小，一来使打开速度更快，另一个也可以消除玩家在流量方面的顾虑。
实话实说，我们游戏在这方面是很失败的。虽然很早就意识到这个问题，也老早就让QA把这个问题列到了Buglist并标记为B级，但自从某次发版本降为C级后就一直Delay到最后一个版本。对此，我很纠结也很无奈…
PS：在此基础上可以分析出，对于手机网游而言，在每月的上旬和中旬做推广效果会优于下旬（节假日除外）。

浏览器：对于手机单机游戏而言，不同机型平台的适应性是非常大的一个问题。虽然对于WAP而言没有这个限制，但因为cookie等其他方面的原因，对于WAP浏览器却也有要求。某些山寨机的默认浏览器以及某些著名浏览器的低版本都会造成无法登陆、无法选择下拉菜单或者无法自动跳转等情况。对此，我相信开放同学（主程）有话说，好吧，让开放同学发言——“上KJava做个微型浏览器”，好吧，开放同学发完言请坐下。这不失为一个好办法，不过一些主流的浏览器还是必须得适应它的。

其他：由于目前可以使用firefox、opare来访问WAP网站（手机客户端方面，可以使用手机顽童模拟），所以存在“手机用户”和“电脑用户”的区别。就用户质量而言，电脑用户由于网速优势导致游戏收益远大于手机用户破坏了游戏平衡，且又基本属于非付费用户，基本可以判定为低质用户。为了杜绝“劣币驱逐良币”的情况发生，就需要降低电脑用户的收益或者干脆禁止电脑用户进行游戏。（在针对手机用户和电脑用户的处理上，不同运营商也采取了不同的办法。腾讯的话，直接限制了电脑用户的接入，保证了游戏内用户的相对较高的公平性；而当乐及其他WAP网站，则对电脑用户做出了获取经验*40%的调整。）
那么，问题之关键就在于如何区别是手机用户还是电脑用户。这个和程序同学讨论过，简单的方法是通过访问IP来判定，复杂一些的办法没听大明白（技术稍微复杂些、实现难度也大点）。程序同学一直不太愿意使用检测IP的办法，说是因为玩家可以通过代理来规避，不过我认为会这么“复杂”设置的用户是很少的，而且这部分用户已经显然不处于设计中的用户群范畴了，可以单独进行处理。
以上是对于手机用户和电脑用户进行的一些技术和设计上的调整。而在游戏运营中，还发现玩家使用了类似“按键精灵”类外挂，较大破坏了平衡性。
一年前写过一篇《webgame防止刷小号的解决办法》的文章，下面的改良办法也主要从设计而不是技术的角度去进行改良。
主要说来就是，减少直接杀死怪物获取的经验、金钱，增大其他办法（比如日常任务、环式任务）的经验、金钱获取。

上面是开发过程中个人认为手机平台的主要限制说明及改良。

2、对于玩家的需求理解不透。
由于对用户群的了解不够，导致设计的玩点与玩家的需求出现较大偏差。

先看看手机游戏用户群的一些特点吧，低龄比例大、低收入人群占比列大、文化层次较PC游戏低、沿海二三线城镇比例大、其他娱乐方式受限。
他们玩手机游戏是为了什么呢？绝大多数，打发时间、追逐游戏内成就、游戏娱乐、交朋友。
那么，什么样的游戏适合他们呢？操作简单、规则简单、游戏背景易认知、良好的交互系统。
参考CDhe老兄写的《阈值与游戏》一文，个人认为，大部分手游用户的阈值还是非常小的。
现在依然能够想象当年在WIN95上一玩玩一天扫雷、在WIN98上一玩玩一天MUD的情形。因为在当时，这些东西都足够新鲜、足够好玩。（不过，放到现在，就远没有以前那么大的吸引力了。至于经常有报道说广大公务员同学依然喜欢在上班时玩扫雷、空当接龙就另当别论了）
大部分手游用户还没有客观和主观条件来接触PC游戏，更别提Console游戏了，他们在“电子娱乐”这方面的口味远没有PC网游用户这么“刁”。

操作简单：减少每一次不必要的操作。
规则简单：规则的简单是指容易理解，简单不代表单调，相反，玩家总是会津津乐道于变化带来的趣味性——由随机性带来的趣味性让我想到了最经典的随机事件（博彩），以前还不理解为什么“箱子”那么赚钱，现在明白了…
游戏背景易认知：对于WAP游戏而言，游戏表现只能依靠有限的文字和极少量的画面来展开，因此游戏背景、故事情节对于提高游戏的代入感和粘度尤为重要。前文已经提到了手游用户群体的整个文化水平，对于大多数人而言，三国故事、西游传说以及流行网络小说都是他们所熟知的，选择这些他们更容易理解和接受。
良好的交互系统：网游之于单机的乐趣就在于人人交互比之人机交互的优点。对于手游用户而言，交互应该更注重反馈和利益。
反馈：即时反馈当然最好，不能即时反馈也需要给个提示或者留个印记。（以QQ好友印象为例，被添加印象时右下角会有系统消息提示，并在个人资料处进行记录。）
利益：可将玩家之间不同的交互行为分为合作和竞争，最终体现在利益的分配。玩家总是趋利的，一种交互行为（可以是合作亦可为竞争）如果能带来丰厚的收益必定能大大催进交互的发生，而无用的交互行为则会被玩家遗忘。当然，这种利益并不仅仅是游戏里面的某些“数据”表现，它也可以是心理上的满足（如特殊称号等）。
不过，手游玩家对于“实际利益”是非常敏感的，比之其他方面(称号、名称、Avatar)他们更在乎的就是“数值”，他们需要自己能力更高、更强，升级更快，非常的符合奥林匹克精神。
如果组队没有一个强力的Buff、杀怪共享，相信没人愿意组队，因为在WAP里面组队实在是——看不见摸不着的。
如果农场被偷不涨经验，那满世界喊话加好友互偷的行为也不会发生。
这些，都是游戏里面的真实情况。

以上每一处都只是稍微点了一下，没有详细展开说明(如果展开要说的东西实在太多)。
为了更好的满足玩家的需求，不仅需要我们以“玩家”的身份去进行体验，还需要从心理学的角度去分析、思考、设计。
以LJ同学某次开会提出了的大部分手游玩家所表现的“特征需求”为例。
这个“特征需求”是——贪小便宜的需求。
为了满足玩家“贪小便宜”的需要，专门设计了商城礼包及其他充值送礼等内容。
这么说似乎有些露骨，但游戏设计上的确是这样。
并不仅仅是商城设计、运营上需要满足这种“特征需求”，在内容设计也需要让玩家觉得他(在某种程度上)主宰了游戏，千万不能让玩家有被游戏玩的感觉[特别是合成、强化系统，详情不言]。

挖掘和满足玩家需求不是三言两语能说完的，只能说明确了这个方向，朝之而努力吧。
从某种意义上说，电子游戏和其他互联网产品并没有太大区别，只是电子游戏满足了用户娱乐的需求，而其他产品满足了用户别的需求而已。

3、产品定位的摇摆不定。
产品在研发之初没有明确的目标用户和定位，而在设计之中又经历了针对红海和蓝海两种截然不同的市场进行的内容开发，最终导致了游戏“四不像”、没有特色。 (更关键的是，本已设计出的系统所达到的效果与预期相差的太多。)
上一篇博文已经提到关于产品战略上的“摇摆不定”，而在具体的单个项目的定位上也都出现了问题。

下面将TJY和CXL两个项目拿出来展开说下。

CXL：先说CXL吧，它的情况还好点。它的特色系统主要有2点：1是嘻哈搞笑的故事情节，这点在JG同学这位super文案的强力输出之下还算不错，虽然有玩家表示对白过长、情节不够有内涵，但都被JG同学无视之；2是以庄园为特色的交互系统，但由于完整的庄园系统推出的较晚，而且与其他游戏系统的耦合性不是非常好，加之测试时间太短太短，所以，没有达到预期的效果。

TJY：与CXL相比，TJY比较伤心。它经历了SHY-ZHAN-TJY整整三个大的阶段。

SHY：最开始项目命名为SHY，报给移动评审的。很多规范都是按《移动梦网WAP业务规范》来做的，包括UI、用词规范等等内容，规范里面很多羁绊、很多脑残，但没办法。我现在有点怀疑WAP游戏网站是否必须按这份规范来。因为，这份规范是我们策划偶然得到，由下而上(而不是由上至下)交给上级后按这个规范做的…
这个阶段的SHY还没有像CXL一样的鲜明特色，如果说有，就是副本系统。
N个月以后，我终于能勇敢的指出，这款游戏的副本系统是比较失败的一个系统了…（系统本身倒没问题，但系统本身所要达到的目的和效果需要改进的太多太多。）
我们提到WOW或者DNF的副本系统非常棒，不是仅仅因为那个区域叫“副本”而已，它的精髓在于副本内的独立性、巧妙的关卡设计、个性的BOSS AI以及良好的操作感。而对于WAP游戏而言，这所谓的副本只是一个噱头，是为了副本而副本的。我们之前需要用副本表现的空间层次感可以用别的方法来实现，而副本中独特的BOSS AI直到最后也还没有精力去设计——这实在是个锦上添花而非雪中送炭的功能。

ZHAN：这段时间依然沉浸在之前构想的副本系统中，并衍生出了众多副本系统（塔式、天关、挖宝）。然而遗憾的是，每个系统做出来后都没有严格的测试，BUG太多，好了这里不是要说这个。除了副本，还有PVP系统，这个也是SHY向ZHAN转型的根本原因——此时，ZHAN已经定位为PVP向的游戏。但是，前文已述的“平台限制”以及战斗系统本身设计的薄弱，使得PVP系统非常非常的单薄。(换言之，游戏的特色系统是设计最弱的一个环节。)
由于人员、时间的关系，游戏虽然开放到60级，但只有前30级是丰满的，30-60的内容太酱油。
***省500字***

TJY：在ZHAN上线后，由于营收效果很差，对产品本身产生了怀疑。几个回合下来，被告之要做成女性向的游戏，改名为TJY。如果做个新的游戏，应该大家不会有太大意见(现在看来，做新游戏的效率比之老游戏可要高)。庞大的游戏系统相互关联，之前已运营的老玩家数据还需要保留，所以设计上根本无法放开手脚。别说大的系统更变，就是一个数值的变化都会导致页面500频发，无法进行游戏。

上面这是产品内容上的定位，在《项目失败的教训》一文中提到过营收方式的内容，在此阶段，也经历了很多营收方式上的变更。
更多的营收方式当然是好，可是，这些都是占用工时的啊！ #_#
和程序员同学花了整整两周时间来制作“直扣点功能”，由于要求来的突然，基本上是前一天出设计文档后一天就要制作、测试，每天晚上基本上都发邮件将第二天的设计内容说的详详细细才回家。
【很忙碌的两周，但也开始习惯于进行时间管理了。】

最后功能全部制作出来，内容上没有什么大问题，但是，扣费方式上却和预期差太多。
由于别家SP的通道扣费是一次确认甚至是零次确认(这个就不多说了，意会)，而我们的需要二次确认，效果完全不能比。
到了11月底，所有的通道扣费都被移动叫停了，这意味着之前设计的功能点，有些会被弃用、有些功能效果大大降低…
虽然我在博文中说此举从某方面反而会促进游戏品质的提高，但对于公司而言无疑是雪上加霜的。

至此，TJY(也就是SHY、ZHAN)在经历了几次折腾之后，基本上完成了它的历史使命…

小结：产品的定位，不仅仅在于内容上的定位，也在于营收方式的定位，都需要在设计之初就定好，且不能反复变更，更不能进行相互矛盾的设定。同时，不仅要考虑技术、设计上的问题，还要考虑政策风险…

4、缺乏合理的项目规划。
测试时间过短，导致游戏经常在上线后才发现BUG。
而大量新功能在整个游戏系统还没有完好模块化的时候就频频加入，进一步导致了BUG出现的概率。
此外，各种游戏开发内容之外的东西也干扰了游戏的正常流程。
具体内容，在此不做详谈。

***略500字***

以上就是个人总结的所参与的WAP产品设计存在的主要问题。
说的不完全，某些地方或因认知而有所谬误，望诸位朋友甄别、斧正。
写的内容虽然涉及了很多方面，但都比较浅，实在因为经验有限，诸位见笑。
不过语句比较口语化，应该不算难懂，如果能给大家有所参考就再好不过了。

接下来，希望能进入某一方面的专精工作吧。
Last,thanks for watching!

项目失败的教训[GameDesign半年工作总结之三]

达达尼昂 — Sat, 30 Jan 2010 10:53:06 +0000

项目失败的教训 [GameDesign半年工作总结之三]

博客闲置了半个月，不过人可是一刻也没闲着。
玩了一些游戏、分析了一些系统、写了一些案子，另外还规整了一份简历。

项目失败是件令人伤心的事情，不过，待我回过头再看时，种种现状综合到一起，发现失败似乎是必然的、不可逆转的。（噢，任何“异议”是没有效果滴…）
项目的失败，应该说是每个创业公司必然经历的一个阶段，迈过去了能产生一个飞跃，迈不过就只能打886了。
无论怎么说，仅仅因为项目失败而导致才开半年的公司就倒闭了，管理层面的问题肯定是非常大的。

但这不是我今天要说的问题。一来所处的位置（策划）决定了我了解的信息肯定是具有很大局限性的，不可妄言；二来，本着“向前看”的原则，更希望记录一些贴近自己工作内容的经验教训，以期在今后自己能够在责任范围内进行相应的改进。
至于创业失败、公司管理以及其他游戏设计层面之上的一些东西，心里记住就好了。
不过，许怡然先生已经总结出了《网游创业失败全攻略》，我发现我们是一条条的匹配上去，而有些教训我们没有出现不是因为别的，只是，还没发展到那个阶段…#_#

OK，今天博文的前戏也太长了点，开始正文吧。

———杯具的分割线———

项目失败的定义：实际营收与预期不符
这个是我个人目前的观点，小纠结了一会儿。
放在SP处的游戏已经1个月没人管了。没有任何内容的更新、没有维护任何BUG、没有GM的线上活动，但期间我偶而登陆游戏，还能看到很多新人、很多老人，以及，一些交易骗子…
在我离职前最后进入管理的时候，近一周的用户留存率稳中有升(比一个月前好玩了)，新增日注册用户数量和之前差不多，而最近几天依然还有人不断充值。
但这些都没用，项目始终是失败的。
虽然从上到下都知道，我们需要的仅仅的时间，然而，时间不仅仅是时间。
艾泽拉斯地精一族的口头禅就说的很清楚了——“Time is money,friends.”

营收的关键：营收方式、营收周期
先说营收方式，这个是盈利的根本，没有正确的营收方式再谈营收周期就有点扯了。
比如你可以把钱存到银行让钱生钱，但如果你把钱埋到土地里面，再怎么春种秋收怎么浇水施肥都是没有，施再高级的化肥也没用。
确定了营收方式，接下来就需要考虑营收周期了。营收方式、营收周期都是需要的，两者是缺一不可的。
打个比方，你把钱存到银行，如果存的是定期，到了规定日期就可以获得本金和利息。如果想提前用钱，利息只能按活期算。
上面是银行储蓄，开公司做游戏呢，也得定个日期，只是如果想提前拿钱的话，别说利息，本金只怕也够呛。

下面，看看几个与营收相关的复杂的分类吧（主要是针对手机WAP业务而言）。
<由于我只是策划而非运营，以下内容只是自己的一些归纳，或许存在某些谬误或不全，欢迎各位朋友斧正。>
营收方式大类：买断（相当于项目外包）、运营（游戏免费，增值服务收费）、门票（按进入游戏次数收费）
运营方式：自主运营、联合运营，联合运营又分独家、非独家
运营下的收费内容：虚拟道具、增值服务、GPRS流量分成
支付方式：移动充值卡、其他平台充值卡、短信支付、渠道直扣(又分为二次确认、一次确认以及，零次确认…#_#)
很复杂，很乱对吧，一乱就出问题了。

由于缺乏运营经验，公司对各种营收方式、运营模式都做了规划和尝试。
问题就在于，所有的营收之关键在产品的质量。但在整个团队全都缺乏相应经验而且研发人员并不是非常充裕的情况下，依然立项过多、分散兵力，导致产品质量存在严重问题。

具体说来如下：
不同运营方式下的产品其设计侧重点不一样甚至是相互冲突，而为了符合不同运营商(特别是移动梦网这种恶心寡头)的特定“规范”更是需要设计不同的UI及其他细节，这些都大大增加了策划和程序的工作量。
游戏运营之后的服务器不稳定，以及不同SP的接口制作问题，加上上面增加的工作量，打乱了整个工作计划，开发节奏的错位导致了产品质量一直存在严重问题。而相对于产品质量的问题，运营短板可谓是更加的无可奈何…（未完待续）

———以上为1月30日所写内容|以下为2月5日所写内容———

之前一直想把内容展开些写，所以前面从整个产品战略和公司人员搭配上说了些东西。
但是，就如同CDHE老兄的留言那样——写的太全会有些顾虑，半遮半掩又写不尽兴。

好吧，此文就此“搁浅”吧。
把思路解放出来，没说完的内容放到下一篇博文一起写吧。

（未完无续）

未说完的内容请访问：产品设计的主要问题

游戏策划工作流水账[GameDesign半年工作总结之二]

达达尼昂 — Sat, 02 Jan 2010 14:41:01 +0000

游戏策划工作流水账[GameDesign半年工作总结之二]

过去几天为一些“很重要的”事情而忙碌着，或许不久就能见分晓吧。

废话不多说，继续这半年游戏策划的工作总结。

————分割线————

整整半年过去了，经历了一款WAP MMO RPG游戏从立项到商业运营的的完整流程。

这几天太多“杂事”耗费了大量的精力，就不展开，只记录些流水账罢了。

09.7~09.8
撰写部分游戏系统设计文档、部分数值工作、UI设计以及任务设计等。
养成良好的工作习惯，熟悉SVN进行版本管理、习惯用Outlook进行交流与沟通、养成对Buglist的关注。
放弃不必要的“纠结”，提高工作效率。

09.9
填写各系统所需的大量数据以及部分数值设定。
进一步了解Power Designer的结构，以及其与游戏设计之间的关系，习惯以一个程序员的角度去思考设计案。
（现在任何一个想法冒出来以后都会首先考虑可行性，但我发现这是一个问题。首先，由于自身对程序的了解还远远不够，也许自认为比较难以实现的设计在程序员那会有解决方案；再次，有些设计本身是没有问题的，只是受限于平台、程序员水平或是工期。所以，今后得在创新性和可行性之间多“纠结纠结”。）

09.10
项目管理，大目标拆分、小目标落实，周安排、日验收。
10.1过后有两周客串了下PM的角色，“伙同”两名程序完成了若干赢利点相关的小功能设定。
在学着进行时间管理后，发现自我安排能力有了不少提高。
但是，才发现安排好自己是简单的，安排好别人是困难的，而安排好整个项目是更困难的…
这个需要了解各系统的难易、各开发人员的能力、习惯及心态，还有，整个公司的规划..@_@
好吧，不管前紧后松还是前松后紧，Debug的时间一定一定不能少。

09.11
游戏上线后的运营分析以及数据调整。
分析运营数据，找到玩家在什么时候离开，进行优化，提高留存率。
同时，在大量玩家涌入后会出现设计时意想不到的事情，特别是数值方面需要进行优化调整。
//***
我得承认自己有一定的“完美主义”倾向，希望做一款没什么瑕疵的游戏。
但游戏上线后我发现我错了，游戏有没瑕疵不是我认为的，而是玩家认为的。
深深的体会到，游戏不仅需要好的设计更需要好的修改。
***//

09.12
为提高用户体验，优化游戏前期的指引。
好吧，我承认之前认为某些游戏的新手指导非常非常的“二”，但现在的情况是，自己最后设计出来的指引，更“二”。。。
（咱们公司最最淡定的JiangGe同学也首次表扬人，对前面的设定表示肯定，说“很有感觉”。）
的确，将AVG融合到WAP中的设定确实让人眼前一亮。WAP没有即时的反馈、没有视觉的冲击，AVG能够给予一种心理上的冲击以及更强的代入感。
//***
游戏的上线，也让我对游戏设计有了全新的概念。
游戏不仅仅是有gameplay就OK了，更需要的是用各种各样的设定（当然也包括gameplay方面的设定）去满足玩家的心理需求。特别是对于WAP游戏，没有WII那样的体感享受、没有PC甚至是次世代游戏的视觉享受，只能更加注重玩家心理上的需求。
而玩家的真正需求，需要从玩家的文化水平、消费水平、年龄、职业、操作习惯、硬件情况以及同类产品进行分析。唔，似乎写了很多点，但还觉得远远不够。这个需要积累分析、再积累再分析，听说腾讯有类似的研究院，挺好。
***//

好吧，我承认工作内容很杂，其实还有些没写…
比如，写软文、做活动、写页面、修改SQL数据库、远程管理…

————分割线————

流水账，没什么营养，希望这几天过了有心境再整理一下吧。

游戏策划常用工具[GameDesign半年工作总结之一]

达达尼昂 — Mon, 28 Dec 2009 16:21:44 +0000

游戏策划常用工具[GameDesign半年工作总结之一]

所谓工欲善其事必先利其器，合理灵活的运用工具，将会使工作效率大大提高。

以下是工作半年来陆续用到的各类软件：

文档处理、文本编辑、文件比较

Microsoft Office 2007
这个就不用多说咯…值得一提的是EXCEL&VBA。

UltraEdit-32文本编辑器
之前一直用Notepad，后来改用UltraEdit。初用时还不习惯，后来发现打开大文件和进行大量数据替换，UltraEdit的速度快得惊人，被折服了。
UltraEdit 是一套功能强大的文本编辑器，可以编辑文本、十六进制、ASCII 码，可以取代记事本，内建英文单字检查、C++ 及 VB 指令突显，可同时编辑多个文件，而且即使开启很大的文件速度也不会慢。软件附有 HTML 标签颜色显示、搜寻替换以及无限制的还原功能，一般大家喜欢用其来修改EXE 或 DLL 文件。

Beyond Compare(文件比较)
Luo推荐的一款软件，刚开始研究。可以对两个文件内容进行比较，将不同之处高亮显示。
Beyond Compare是一款不可多得的专业级的文件夹和文件对比工具。使用他可以很方便的对比出两个文件夹或者文件的不同之处。并把相差的每一个字节用颜色加以表示，查看方便。并且支持多种规则对比。

游戏流程、游戏结构、游戏建模

Microsoft Office Visio 2007
不用多说，画流程图必备的。
（当然，有时候程序员同学会不仔细看Visio文件，此时还需要白板+白板笔…）

MindManager (思维导图)
明晰游戏结构、理清各系统关系，头脑风暴，MindManager是个不错的选择。

Power Designer
好吧，我承认，当第一次打开Power Designer之后，我对游戏设计有了一个全新的概念。
游戏的骨架从平时看到的画面中剥离出来，各个表结构的关联、各个字段的作用，通过Power Designer看得再清晰不过了。
利用PowerDesigner可以制作数据流程图、概念数据模型、物理数据模型，可以生成多种客户端开发工具的应用程序，还可为数据仓库制作结构模型，也能对团队设计模型进行控制。

图片处理、UI设计

Adobe Photoshop
地球人都知道…

Image Optimizer
一款非常小巧的图片压缩软件，压缩后的画质基本上无影响，但大小可以缩小50%以上。

UIDesigner
由腾讯CDC制作的一款UI设计软件。目前属于内测期，可以给开发团队发邮件索要该软件。
当然咯，关于UI设计，也见过达人用EXCEL做的超棒的例子，所以，软件不是最重要，关键看怎么个用法。

数据库、远程管理

db2mysql
顾名思义，一款将Access数据库文件转为MYSQL文件的软件。
当处理4W条以上数据时，软件会有短时间无法响应，建议大量数据分批转换。
（游戏策划要填的数据真多，对吧…）

MySQL Query Browser
一款MYSQL可视化操作的软件，可以直接执行SQL语句及导入SQL文件等。
（仅支持WIN…刚接触时觉得很方便很喜欢但现在很不喜欢了，因为，导入时老出错。。。因为WIN平台的原因…）

SSH Secure Shell Client
话说有时候程序太忙，或是为了提高效率，自己也客串一下，使用SSH进行远程管理。
最开始觉得敲命令太麻烦，更喜欢MySQL Query Browser，后来发现敲命令太方便了…于是成为SSH的死忠…

————分割线————

上面是这半年经常用到的各类软件，或有遗漏稍后补上。

PS:值得悲哀的是，上面大部分给的链接都是D版软件地址…这也是没办法的事情咯…

GameDesign半年工作总结

达达尼昂 — Mon, 28 Dec 2009 15:26:32 +0000

时近年关，工作亦满半年。
做个总结，不求分享经验，但求列出教训给自己以后的工作一个“警示”。

————分割线————

第一篇：【游戏策划常用工具】
第二篇：【游戏策划工作流水账】
第三篇：【项目失败的教训】
第四篇：【产品设计的主要问题】

Avatar

达达尼昂 — Wed, 25 Nov 2009 15:00:00 +0000

昨天夜晚写出了Avatar的文档。

由于项目时间的关系，先期只能做一个简单的系统。

部件、层次、坐标、着色、叠合、呈像。

有个设想是，玩家可以将手机拍摄的图片上传后作为自己的AVATAR。
不过，和程序沟通后，在无客户端的情况下，实现难度太大（无法较好获得图片信息）。
[如果以后Kjava的话，就方便多了。]

转一条news:Adobe借Flash插件下载大规模推电影《Avatar》
《阿凡达 Avatar》

EXCEL不等于如何表示？

达达尼昂 — Tue, 17 Nov 2009 16:04:15 +0000

EXCEL不等于如何表示？
很简单。
A不等于0，记为【A<>0】。

起因是先设置了怪物掉落，后面将掉落的武器全部换为卷轴，需要将之前设定的武器ID改为卷轴ID。

由于非武器装备没有改变（即在新的一列中为“空”），故，需要再建一列，将所有【不等于0】的掉落替换为卷轴ID。

设TOOL_ID为A列、JUAN_ID为B列、新建列为C列。

则结合IF函数表示为：
C=IF(B<>0,B,A)

Mysql常用语句

达达尼昂 — Fri, 13 Nov 2009 14:25:44 +0000

MySQL Query Browser

http://dev.mysql.com/downloads/gui-tools/5.0.html

查找
select * from 表名 where id=?[and name=？] [or name=?];

添加
insert into 表名(字段名1,字段名2) values(值1,值2);

更新
update 表名 set 字段名 where id=?[and name=？] [or name=?];

删除
delete from table where id=？[or name=? (and name=?)];

注意：
1、LINUX下大小写敏感
2、字符串
3、敏感字加‘’

————-游戏策划分割线————-

–创建数据库
　　mysql> create database 数据库名称
　　–创建表
　　mysql> create table 表名 (
　　列的名字（id）类型（int（4））primary key(定义主键) auto_increment（描述自增）,　　……，　　）；
　　–查看所有数据库
　　mysql> show databases 数据库名称;
　　–使用某个数据库
　　mysql> use database 数据库名称;
　　–查看所使用数据库下所有的表
　　mysql> show tables;
　　–显示表的属性结构
　　mysql> desc 表名;
　　–选择表中数据的显示
　　–* 代表选择所有列，
　　mysql> select * from 表名 where id=?[and name=？] [or name=?];
　　mysql> select id,name from 表名order by 某一列的名称 desc(降序，asc为升序)
　　–删除表中的数据
　　mysql> delete from table where id=？[or name=? (and name=?)];
　　–删除表
　　mysql> drop table;
　　–删除数据库
　　mysql> drop database;

游戏策划 Game Design » 工作笔记

反打金工作室

相关日志推荐

Worknote[20100328]

相关日志推荐

产品设计的主要问题[GameDesign半年工作总结之四]

相关日志推荐

项目失败的教训[GameDesign半年工作总结之三]

相关日志推荐

游戏策划工作流水账[GameDesign半年工作总结之二]

相关日志推荐

游戏策划常用工具[GameDesign半年工作总结之一]

相关日志推荐

GameDesign半年工作总结

相关日志推荐

Avatar

相关日志推荐

EXCEL不等于如何表示？

相关日志推荐

Mysql常用语句

相关日志推荐