这里会显示出您选择的修订版和当前版本之间的差别。
两侧同时换到之前的修订记录前一修订版 | |||
知识库:发行:在线章节:产品的生命周期 [2024/09/10 12:57] – [总结] 邪让多杰 | 知识库:发行:在线章节:产品的生命周期 [2025/06/24 22:31] (当前版本) – 邪让多杰 | ||
---|---|---|---|
行 1: | 行 1: | ||
====== 为什么要了解游戏行业 ====== | ====== 为什么要了解游戏行业 ====== | ||
- | 为什么要讲这些? | ||
- | 就是为了给读者树立一个O。 | + | 为什么要讲这些?就是为了给读者树立一个 |
- | 本章比较轻松,属于闲聊,聊一聊游戏行业,聊一聊一些经验,继续后续的章节之前,让大家心中有个概念,就像下棋一样,对市场有了概念,就有了大局观,就能<color #22b14c>降低犯宏观层面错误的概率</ | + | 本章比较轻松,属于闲聊。在进入后续章节前,我们先聊聊游戏行业和一些经验,让大家心中有个概念。就像下棋一样,对市场有了概念,就有了大局观,就能 |
- | 作者自己是在进入游戏行业第七年以后,才开始对整个行业有了初步的了解,稍微理解了整个行业是怎么运转的。 | + | 作者自己是在进入游戏行业第七年以后,才开始对整个行业有了初步的了解。所以希望把这些经验传递给萌新们,**不要埋头苦干,也要抬头看看**,了解一下自己在行业内处于什么节点,了解一下别人是怎么工作的。 |
- | 所以希望把这些经验传递给萌新们,不要埋头苦干,也要抬头看看,了解一下自己在行业内,处于什么节点,了解一下别人,是怎么工作的。 | + | 如果您已是一位经验丰富的游戏人,那本章尽可跳过或随意翻阅。 |
- | + | ||
- | 如果在读这里的读者,是一位经验丰富的游戏人,非常清楚游戏行业的大体运转逻辑,那么这个章节你就可以跳过,随便翻翻也行。 | + | |
====== 游戏产品的生命周期 ====== | ====== 游戏产品的生命周期 ====== | ||
行 16: | 行 13: | ||
{{: | {{: | ||
- | 这啪一上来,简单的模型就甩出来了。 | + | 一上来,一个简单的模型就甩出来了。 |
- | 小伙伴一个躲闪,甚至还发现了奇怪的东西混在了模型里面,这是许多小伙伴不认识的东西,**长尾团队**,干嘛的,可以吃吗?为什么多杰称他们为:“**法师**”。这个模型是不是太简单了? | + | 您可能还发现了模型里有个奇怪的东西:**长尾团队**。他们是干嘛的?为什么我称他们为“**法师**”?这个模型是不是太简单了? |
- | <color # | + | 别急,书本不像游戏可以动态调整难度,我们得考虑到萌新,从最简单的开始讲起。 |
- | 接下来,我将采用讲故事的方式去讲一遍流程,大家且听且看。 | + | 接下来,我将用一个故事来贯穿整个流程。 |
- | <color # | + | ---- |
- | <color # | + | ==== 故事的开始:立项与Demo ==== |
- | <color # | + | // |
- | <color # | + | //张三呢,重点学校毕业,高材生,游戏行业摸爬滚打多年,希望能做出自己喜欢的游戏。// |
- | <color #ff7f27>张三说:“懂行就不忽悠了,我抄《一氪随缘》,我觉得他创意很好,但商业化气息太重了,现在的玩家都喜欢独立游戏,所以我要改成独立游戏,再搞点RogueLike进去。”</color> | + | // |
+ | // | ||
+ | //张三说:“懂行就不忽悠了,我抄《一氪随缘》,但要改成独立游戏,再搞点RogueLike进去。”/ | ||
- | <color #ff7f27>李四与张三虽然有出发点的不同,但他们聊了一整个晚上,最终决定搭伙开一家公司,共同开创一个新的未来。</color> | + | //李四与张三虽然出发点不同,但最终决定搭伙开一家公司。/ |
- | <color #22b14c>古人云:“文无第一,武无第二”,游戏作为一个文化产业,自然就有这样的特性。当文人通过各种“主观”角度去观察一个项目时,就会得到自己的观点,且这种观点不可能被别人所完全理解,这在认知模型里我们讲过。</ | + | 古人云:“文无第一,武无第二”。游戏作为文化产业,自然也有这样的特性。当人们从主观角度去观察一个项目时,观点往往难以统一。 |
- | + | ||
- | <color # | + | |
+ | 虽然明面上没有,但客观现实中,游戏立项也分了 **文理派**。 | ||
< | < | ||
- | - **个人实现的上一层**,就是人生梦想,到头了。 | ||
- | - **数据驱动的上一层**,是搞钱,无穷无尽。 | ||
- | 文派通常来源于“**灵感**”,属于有梦想的年轻人,或者经济压力不大的人,诞生了无数好玩的独立游戏,偶尔有爆款,也能带来不错的收益,但大部分,都死于创作阶段。 | + | * **文派 |
+ | * **理派 (商业化驱动)**:通常拥有“**祖传家产**”(比如成熟的数值模型)。项目开始前就能预估收益,核心是统筹资源,创造最大价值。其上一层是 **搞钱**。 | ||
- | 理派则通常拥有“**祖传家产**”,这份家产又大概率是“**祖传数值**”,所以在一个项目开始之前,就已经可以预计到未来的收益,剩下的就是把每一份资源统筹好,创造出最大价值即可。 | + | 没有文派,玩家就玩不到奇异的闪光点。没有理派,游戏公司就无法发展壮大。而 |
- | 没有文派,玩家就不会玩到奇异的闪光点。 | + | // |
- | 没有理派,游戏公司就无法发展扩大,最终做出极致品质的3A大作。 | + | // |
+ | // | ||
- | 而文理综合的学派,是可遇而不可求的武学宗师,几十年难遇一人。名字我不用说,大家心里都有自己认可的他。 | + | 这是立项最初的 **Demo 阶段**,虽然容易被忽略,但至关重要,因为此时的试错成本最低。 |
- | 你很有可能是刚刚听到这种在立项上文理分派的说法,其实也是我刚刚想出来的,在我们内部的培训课程上,叫做< | + | //等过了这个阶段,时间就上了一把枷锁。所以要好好享受这个阶段,尽可能长时间地揣摩想要设计的内容。// |
+ | // | ||
+ | //一个月后,新的Demo诞生。张三和老赵继续研发,李四则拿着Demo出去寻找投资。// | ||
+ | // | ||
- | 不管怎么说,项目总有一个来源,甚至可能因为玩家嫌弃策划做得太烂,打算自己做的情况发生(真的有),所以这都是闲聊,不是在传授一种固定的模型,大家看看也就看看,忘了,也就忘了。 | + | 这是一个游戏最初的 **Demo 阶段**,其主要目的之一是用来拉投资。一个有趣的点是,大多数投资人都会对你的项目表示“十分的感兴趣”,但愿意立马投资的,又几乎没有。 |
- | 我们继续。 | + | ---- |
- | 改编不是乱编,戏说不是胡说。 | + | ==== 故事的发展:融资与发行 ==== |
- | 立项找准方向,走路不怕夜路。 | + | //有了钱,李四走起路来,腰板都挺得格外地直。团队迅速扩张到11人。// |
+ | // | ||
- | <color # | + | 对于游戏的研发商(CP),找到一个靠谱的发行,不仅能获得资本加持,还能得到更专业的商业化指导。 |
- | <color # | + | //幸运的是,这次项目做得不错,许多发行都慕名到公司拜访,李四最终选定了其中一家。// |
- | <color # | + | 一个游戏产品,开发到一定阶段后,就需要出去找发行公司。当然,有的公司会选择自己发行,我们把这种行为叫做“**`自研自发`**”。 |
- | <color # | + | // |
+ | // | ||
+ | //李四说,发行有时间窗口,发行商的小哥哥说了,错过了这个窗口,下半年就大作井喷了,我们只有2个月时间。// | ||
+ | // | ||
- | <color # | + | ---- |
- | <color # | + | ==== 故事的高潮:测试与上线 ==== |
- | <color # | + | //新的宣传片做好了,游戏在一次展会上公开,玩家蜂拥而至。运营、市场、商务团队开始联动,为上线预热。// |
+ | //很快,游戏来到了 **不计费删档测试** 的那一天。// | ||
+ | // | ||
+ | // | ||
- | <color # | + | 游戏上线前,会经历一系列测试。我们常说的 **游戏上线** 或 **公测**,很多时候就是指 **不删档计费测试**。 |
+ | 这个阶段,发行的各个职能都会参与进来,包括:**`运营`**、**`客服`**、**`商务`**、**`市场`**、**`产品`** 和 **`数据分析师`**。 | ||
- | <color # | + | // |
+ | // | ||
+ | // | ||
+ | // | ||
- | <color # | + | // |
+ | //上线了,没炸服!// | ||
+ | // | ||
- | <color # | + | // |
+ | // | ||
+ | //张三与李四,从此走上了人生巅峰。// | ||
- | <color # | + | 游戏上线后,最简单的扩张逻辑就是:如果从单个用户身上赚的钱,能够大于买这个用户的成本,这个游戏就可以通过投放广告疯狂扩张。 |
- | <color # | + | ---- |
- | <color # | + | ==== 故事的结局:长尾与落幕 ==== |
- | <color # | + | // |
+ | // | ||
+ | // | ||
- | 这是一款游戏最初的Demo阶段,这个Demo通常是要拿来拉投资的,所以这个阶段Demo长成什么样,就显得十分得重要。 | + | * **公会渠道**:通过各种方式笼络高价值用户,工作人员与玩家称兄道弟,引导消费。 |
+ | * **私服渠道** (打折服):名义上是私服,实际上是官方合作。通过大额折扣,吸引老玩家回归(例如,原本1000元的道具,现在只要6元)。 | ||
- | 除非是明星制作人,或者成功项目背书,不然很难凭借着PPT就能融到钱,如果不是关系户的普通老板,就需要这里跑,那里跑,全国跑,到处寻找愿意投资的人。 | + | 这本质上是 **快速透支游戏的生命,达成最后的产品“收官”**。 |
- | 这里还有一点十分有趣,<color # | + | // |
+ | // | ||
- | 这个阶段,就是一个项目的做Demo阶段,而融资,则是附带着讲一讲的小故事。 | + | 一个项目上线后,剩下的就是更新版本、更新活动。当游戏运营价值降低时,就会选择关服。而在游戏的末期,通过公会或私服渠道再捞一笔,也是一部分游戏收尾的方式。这种渠道,我们一般称为“**长尾渠道**”。 |
- | <color # | + | 故事到此结束,希望大家对游戏的生命周期有了粗浅的了解。 |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 李四又开始了全国四处奔波,但这一次不是拉投资,而是找发行。 | + | |
- | + | ||
- | 作为游戏的研发商,很多时候没有精力与经验去处理发行的事务,而找到一个发行,不仅能获得资本方面的加持,还能得到更实际,更专业的商业化方面的开发指导。 | + | |
- | + | ||
- | 当然,这是一个双向的过程。发行期望找到一个靠谱的研发,而研发也期望找到一个靠谱的发行,怎么样去评估对方?对于李四来说,这是个问题。 | + | |
- | + | ||
- | 经历过找投资的阶段,李四渐渐习惯了这种“我对你很感兴趣,但我就是不行动的”的态度。私下里,李四在自己的日记本上,记录为 “渣男行为”,但似乎整个行业都是这样,所以李四只能想尽办法去旁敲侧击。 | + | |
- | + | ||
- | 幸运的是,这次项目做得不错,当包出现在市面上后,许多发行都慕名到公司拜访,通过多方对比,李四终于选定了其中一家。 | + | |
- | + | ||
- | 一个游戏产品,开发到一定阶段后,就需要出去找发行公司,当然,有的公司会选择自己发行自己研发产品,我们把这种行为叫做:“< | + | |
- | + | ||
- | 研发通常也会有一个缩写来称呼,叫做:CP,但发行却没有,这很奇怪。 | + | |
- | + | ||
- | 当然,这可能取决于公司习惯。并不是所有的公司都喜欢喊英文缩写。 | + | |
- | + | ||
- | 在这个阶段,双方要敲定游戏代理费,区域,发行计划等等,双方也要评估对方是否有能力做好与自己的合作,有一些是无需技术的,有一些,就需要对方掌握一定的技术,如果无法鉴别出来,就会给自己留下隐患。这个到后面的细节中会深入讲解。 | + | |
- | + | ||
- | 产品找到了发行,就等于完成了与别人合作的最后一关,游戏就进入了快速调优,整改,商业化,装备上线的阶段。 | + | |
- | + | ||
- | 我们继续。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 一旦一个游戏确定了发行计划后,才算是与玩家见面并排上了日期,这时候,工作的重头渐渐地从研发转到了发行。 | + | |
- | + | ||
- | 注意故事中出现的职位,有< | + | |
- | + | ||
- | 不同的发行方式,有不同的侧重,在故事当中,走的还是正规作战,所以有宣发新闻,也有社区维护,还有提前预热。 | + | |
- | + | ||
- | 而一般来说,游戏的测试也从2个维度去考虑,删档与否,付费与否。而从很早很早以前开始,游戏上线就变成了游戏公测,那时候的玩家还会奇怪,这游戏都上线了,咋叫做测试呢? | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 而一些公司,也会把这个叫做公测,然后再安排一次正式上线的阶段,以这个“名头”来进行再次推广。 | + | |
- | + | ||
- | 这里萌新要了解的,就是参与的人,发生的事,什么时间节点会有哪些事情出现,当然,后续会细讲。 | + | |
- | + | ||
- | 我们继续。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 每种品类都有自己的数据,其他人的数据也不好参考,但好在渠道与发行的反馈都还不错,这是一个A级产品,所以李四也比较放心。 | + | |
- | + | ||
- | 对于张三与老赵,他们依旧忙碌的按照要求开发,为了节省策划的时间,项目组又来了两个测试人员,组了质量(QA)部门,专门来测试游戏的BUG,验收功能。 | + | |
- | + | ||
- | 预热活动再一次爆发,很快,游戏就要迎来了正式上线。 | + | |
- | + | ||
- | 所有的人都在加班加点的赶工。 | + | |
- | + | ||
- | 研发赶bug,赶内容。 | + | |
- | + | ||
- | 发行赶素材,赶新闻,赶攻略。 | + | |
- | + | ||
- | 一切蓄势待发,只求全力爆发。 | + | |
- | + | ||
- | 常规的游戏上线,会经历几次测试后才上线,主机、PC、手机、小游戏平台会有细节差异,但宏观上都差不多。 | + | |
- | + | ||
- | 而一个项目经历了多次测试后,就会迎来最终的上线日期。 | + | |
- | + | ||
- | 此时,一定会有改不完的功能以及极其有限的时间,所以是两个公司最忙的时候。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 游戏上线后,就会涉及到数据。 | + | |
- | + | ||
- | 最简单的过程,就是< | + | |
- | + | ||
- | 反之,作为大部分游戏,是买不起广告的,只能不断地更新版本,去渠道申请新的资源推荐位置。 | + | |
- | + | ||
- | 当然,买广告这个行为也分为三六九等。付费好的游戏,自然能买高价的,量大的广告,而付费差的游戏,因为受到题材、画面的影响,也有可能买到便宜的广告,最终看是否能回收,但总归市场是有一个相对平均的价格的。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 一个项目上线后,剩下的就是更新版本,更新活动。 | + | |
- | + | ||
- | 不断的想办法再一次扩大用户群体,召回老用户。通常作为一款手游,过个几年,也逐渐没有了运营价值,那么游戏就会选择关服。 | + | |
- | + | ||
- | 而在游戏的末期择通过公会渠道或者私服渠道再捞一笔钱,也是一部分游戏收尾的一种方式。玩家通过廉价的方式“爽到了“,官方也在游戏的最终死亡前发挥一下余热。 | + | |
- | + | ||
- | 这种渠道,我们一般称为:“< | + | |
- | + | ||
- | 好了,我们的故事就到此结束,通过这个故事,大家也应该粗浅的了解了一个游戏的生命周期。那么在接下来的内容中,我们将对每个环节展开再分享一番,希望能够让萌新们更加全面的了解游戏行业的现状,那些所谓的“常识”。 | + | |
===== 立项环节 ===== | ===== 立项环节 ===== | ||
- | 如果你能有幸做项目做到50 岁,那你可能会经历至少6次立项。 | + | <note warning> |
- | 每一次立项,都直接决定了未来几年你是否白忙活。 | + | **立项**,说白了就是 **决定方向**。它不是一个瞬间的节点,而是一个过程。如果你感觉立-项很爽快,报应就一定会在后续的过程中呈现。 |
- | <color #ed1c24>立项定生死,是行业内广为流传的话语。</ | + | 在立项这个时期内,最重要的是回答这个问题:“**如何确保我的方向尽可能对?**” |
- | 那到底什么是立项? | + | 这里的“对”,我定义为:尽可能的 **利益最大化**。当然,这必须在符合当地法律法规和人文风俗的前提下。立项时,很重要的一点就是思考 **局限条件**,把局限条件都带上,找到可以实现的、具备性价比的方向。 |
- | 有关于立项的模式,我们后面会讲,本章的就闲聊,聊到哪是哪,希望给萌新们多传递一点概念,心里好歹知道立项这么回事。 | + | === 可行性分析 === |
+ | 在软件开发工程里,会有一个阶段叫“可行性分析”。也就是说,立项这个阶段,它要产出一个东西,我认为,这个东西应该是 **一份证明**。 | ||
+ | < | ||
+ | 要证明方向没错,也要证明团队能做到。如何证明?需要用逻辑解释得通,再去和各个岗位的人交流,让他们质疑你的观点,寻找漏洞。 | ||
- | **立项**说白了,就是决定方向。 | + | === 常见误区 === |
+ | 立项是需要 | ||
+ | * **渠道偏好**:**`独立游戏`** 适合 **TapTap**,**`三国类`** 适合 **华为渠道**,**`传奇类`** 适合大多 **硬核渠道**。 | ||
+ | * **政策导向**:**封建迷信**、**暴力血腥**、**宫斗**、**耽美**、**拜金主义** 等题材都存在风险。 | ||
+ | * **市场格局**:自己没有固有用户,新立项一个 **`MOBA`**,期望吃到小部分市场,几乎一定会失败。 | ||
+ | * **品牌效应**:**`腾讯`**、**`网易`** 等企业拥有大量自有用户,可以做一些付费水平没那么高的游戏。如果我们自己来做,就会陷入买不起广告的困境。 | ||
- | 方向不止一个,有花钱的方向,**产品的方向**,**人员组织的方向**等等。 | + | 想要在这条路上行驶,就需要在立项之初就全盘地考虑这些问题,而不是仅仅觉得:“我这个玩法好玩”,就认为它能成功。 |
- | 像前面讲的故事,立项的源头分文理,从个人的情感角度出发,可以立项,从**市场分析的结果角度**,可以立项。 | + | === 立项从什么时候开始? === |
+ | 很多优秀产品的立项,从 **制作人忙完** 就开始了。 | ||
- | 但立项不是一个瞬间的节点,而是一整个时期,是一个过程。 | + | 吃饭、上厕所、睡觉前,平时就会去思考、推导,甚至设计Demo。这个时间窗口,是整个游戏的生命周期内 |
- | + | ||
- | 万事开头难,但立项总是很爽快的。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 在立项这个时期内,最重要的是: | + | |
- | + | ||
- | < | + | |
- | + | ||
- | **对**,是一个相对的词语,什么才叫做“对”? | + | |
- | + | ||
- | **李四**认为:赚钱才是对。 | + | |
- | + | ||
- | **张三**认为:口碑好才叫对。 | + | |
- | + | ||
- | 说点带个人情感的话,其实**多杰**认为,立项不以盈利为第一目标,就是对投资人的不负责,除非你的投资人说:“我投资的是你的情感,而不是未来产生收益的预期”。 | + | |
- | + | ||
- | 我估计,正常的投资人都不会有这样的想法。 | + | |
- | + | ||
- | 所以,回到我们的话题,什么是**尽可能对**? | + | |
- | + | ||
- | 我这里的定义是:尽可能的**利益最大化**。 | + | |
- | + | ||
- | 这道题变成了: | + | |
- | + | ||
- | < | + | |
- | + | ||
- | 别嫌弃我啰嗦,其实策划本应该是一个很严谨的工作。 | + | |
- | + | ||
- | 特别的,从工作交流的语言上,我们就知道有多么大的歧义,说准一个词,让交流的双方都理解同一个意思,真的太难了,所以要严谨。 | + | |
- | + | ||
- | 利益最大化也有一个缺点,如果只考虑到这个点,最终就会驱动着策划设计出“黄赌毒”产品,这是万万不行的,我们的任何设计,都要符合当地的法律法规,照顾当地的民族情感,人文风俗。 | + | |
- | + | ||
- | 基于这一点,就要加很多**附加条件**,比如:**符合当地法律法规**,**尊重当地民族情感**,**人文风俗**等等。 | + | |
- | + | ||
- | 其中有两个**附加条件**十分重要,也是立项时,大部分人忽略的。 | + | |
- | + | ||
- | * 有多少人,办多少事。 | + | |
- | * 有多少钱,办多少事。 | + | |
- | + | ||
- | 也许经过盘算,最具备性价比的,就是做一个3A大作,需要启动资金1个亿美金。 | + | |
- | + | ||
- | 虽然它有性价比,但没钱,没人,就做不了。 | + | |
- | + | ||
- | 所以在立项时候,很重要的一点就是思考**局限条件**,把局限条件都带上,找到可以实现的,具备性价比的方向。 | + | |
- | + | ||
- | 在软件开发工程里,会有一个阶段叫:“可行性分析”,这个阶段是要产出一个**可行性分析报告**的。 | + | |
- | + | ||
- | 也就是说,立项这个阶段,它要产出一个东西,**多杰**认为,这个东西应该是:< | + | |
- | + | ||
- | 对,就是**证明**,补全则是: | + | |
- | + | ||
- | < | + | |
- | + | ||
- | 要证明方向上,我没选错。 | + | |
- | + | ||
- | 要证明,我真的能做得到我所设想的一切内容。 | + | |
- | + | ||
- | 如何证明? | + | |
- | + | ||
- | 其实就是要用到本书的所有理论方面的内容,再加上个人的实践经验,才能尽可能的去说明有概率盈利。 | + | |
- | + | ||
- | 然而,这个概率是主观的。 | + | |
- | + | ||
- | 所以它“不靠谱”,我们不用在意概率真的多少,这个过程需要的是:“< | + | |
- | + | ||
- | 然后,再去和别人说,让他们质疑你的观点,看看是否有什么漏洞,这里的别人,要多,要各个岗位,不要只在自己的小圈子里问,这样大家认知范围差不多,很难得到框架之外的反馈。 | + | |
- | + | ||
- | 立项,它还是一个需要**眼观六路,耳听八方**的事情,我举个例子。 | + | |
- | + | ||
- | **独立游戏方向**的游戏,它适合**TapTap渠道**,**三国类**的游戏,它适合**华为渠道**,**传奇类**的,它适合大多**硬核渠道**。 | + | |
- | + | ||
- | 而这些适配性,我们可以观察到,也可以通过渠道商务或运营的交流中得到,甚至可以通过其他成功经验的公司口中得到。 | + | |
- | + | ||
- | 所以有很多研发,< | + | |
- | + | ||
- | 再举个例子,假设某个渠道,未来1年打算在某个方向做大量尝试与推广,你立项的时候,是否要考虑这样的信息去成为他们的**种子项目**? | + | |
- | + | ||
- | 立项考验的,恰恰就是本章的内容,一个人是否对整个游戏行业有较为全面的认知。 | + | |
- | + | ||
- | 再举个例子,如果一个制作人足够了解公会与买量,他立的项目根本不用上渠道,直接通过广告投放,就可以打出不错的成绩,而这样的游戏,因为不用上渠道,就会有它自己的特性,比如不需要**社区维护**,不需要考虑大量免费用户的口碑等等。 | + | |
- | + | ||
- | 继续举个例子,政策会一直引导我们去做更加适合这个社会的游戏,从长远的来说,**封建迷信**的,**暴力血腥**的游戏,会被禁止,属于不合适的。 | + | |
- | + | ||
- | 而近期来讲,非官方的消息就会说**宫斗类型**的游戏,宣传**耽美类型**的游戏,强调**拜金主义**的游戏,也是不合适的。 | + | |
- | + | ||
- | 如果在立项的时候不考虑这些,就会做到一半发现与政策不符合,只能被迫终止,或者转战海外市场。 | + | |
- | + | ||
- | 再看,《**王者荣耀**》在中国已经是人人皆知的游戏了,但它的成立来源于大用户群体的支撑,如果自己没有固有用户,而是新立项一个**MOBA**,期望吃到小部分市场,那就会失败得很惨,甚至在找发行阶段就遇到困难。 | + | |
- | + | ||
- | 并且实话实说,这么想的制作人还真不少,每年都有若干款类似产品出现。 | + | |
- | + | ||
- | 同理的例子,还有。 | + | |
- | + | ||
- | 有一些产品类型,它的付费能力并不强,它们的成立来源于**品牌用户**的廉价,比如**腾讯**、**网易**、**雷霆**等企业拥有大量自有用户,就可以做一些付费水平没那么高的游戏,也能轻松达到高流水。 | + | |
- | + | ||
- | 但如果我们自己来做,就会陷入买广告买不起,**新用户不知道去哪里弄**的困境。 | + | |
- | + | ||
- | 立项的坑千千万。 | + | |
- | + | ||
- | 想要在这条路上行驶,就需要在立项之初就全盘地考虑这个问题,而不是仅仅觉得:“我这个玩法好玩”,就认为它能成功。 | + | |
- | + | ||
- | 更多的**维度**,以及这些维度该如何去检查,我们后续会有专门的章节讲解,这里就和大家介绍一下立项。 | + | |
- | + | ||
- | **本小节重点**: | + | |
- | + | ||
- | < | + | |
- | + | ||
- | 就像盖大楼一样,只有足够全面的防御性检查,才能支撑大楼盖得高高的。 | + | |
- | + | ||
- | === 立项从什么时候开始? === | + | |
- | + | ||
- | 有许多项目,都是公司做出规划后开始。 | + | |
- | + | ||
- | 但也有更多的优秀的产品,从制作人忙完就开始。 | + | |
- | + | ||
- | 制作人忙完是什么意思? | + | |
- | + | ||
- | 吃饭,上厕所,睡觉前,不需要任何来自上层的项目指引,平时就会去思考,去推导,甚至去设计Demo。 | + | |
- | + | ||
- | 从此时开始,就有一个时间窗口,这个时间窗口,是整个游戏的生命周期内成本最低的,没有枷锁的。 | + | |
- | + | ||
- | 举个例子,假设一个制作人手上有项目,平日里下班了,就开始规划新的项目,那么他可能会有1年以上的时间去思考项目的构思。 | + | |
- | + | ||
- | 如果制作人不浪费掉这以年份计算的时间,那么将会在未来的项目中,替团队省出百万以上的成本。 | + | |
- | + | ||
- | 在有限的条件下,这个时间窗口还能出现在公司决定立项以后。 | + | |
- | + | ||
- | 有时候公司会采取一种策略,先告诉制作人要立项,让制作人独立准备一段时间,此时,项目组的其他人员还在忙其他事情,那么,整个项目的成本就只用计算制作人的。 | + | |
- | + | ||
- | 就一个制作人,或者按照我们的标准配置,加一个美术一个程序,成本不会太高,同样的资金的情况下,能够给予项目更长的时间去思考,去选择方向。 | + | |
- | + | ||
- | 说这么多,就是希望读者在面对一个项目时,不管你在什么岗位,都要有成本意识,人员成本的意识,要理解到什么时间段可以赶,什么时间段可以慢。 | + | |
- | + | ||
- | 最终科学合理的,尽可能最大化的利用好项目资金。 | + | |
- | + | ||
- | 毕竟, | + | |
- | + | ||
- | <note warning> | + | |
===== 开发环节 ===== | ===== 开发环节 ===== | ||
+ | 面向萌新介绍开发环节,应该包含三种信息: | ||
+ | - **结构**:人员结构,物料结构。 | ||
+ | - **流程**:工作流程,有哪些人会参与其中。 | ||
+ | - **经验点**:关键技巧和注意事项。 | ||
- | 面向一个萌新,应该如何介绍一个开发环节? | + | === 团队结构与基础流程 |
- | + | 最小的开发单元是:**策划、程序员、美术**。 | |
- | 我理解应该告诉你三种信息: | + | |
- | + | ||
- | - **结构** | + | |
- | - **流程** | + | |
- | - **经验点** | + | |
- | + | ||
- | 结构就是人员结构,物料结构,有哪些人会参与其中。 | + | |
- | + | ||
- | 我们以最小单元来讲解。 | + | |
- | + | ||
- | 策划、程序员、美术,这是最小的单元。 | + | |
{{: | {{: | ||
- | 我们从图中左上角的策划开始看,策划一般自己会出一个策划案,大多时候,策划案是给策划自己看的。因为太冗余,太长,太繁杂,有时候也会在策划内部会议上,或者三方会议的情况下进行沟通讲解。然后为了方便团队协作,策划案通常又会被拆分为美术需求与功能需求两个文档,又或者直接嵌入在原始策划案中,分别交付给美术与程序。 | + | **基础流程如下:** |
+ | 1. | ||
+ | 2. | ||
+ | 3. 程序首先会去做 **功能框架**,同时期美术进行 **资源设计**。 | ||
+ | 4. 当美术交付了美术资源后,程序拿美术资源进行整合,调试。 | ||
+ | 5. 程序交付整合好的功能给策划 **验收**。 | ||
- | 策划、美术、程序会齐聚一堂,进行三方会议,充分的了解彼此之间的信息,最重要的目的,就是**消除认知偏差**。 | + | //有的地方是并联,有的地方是串联,如果单纯的顺着去做,就会浪费掉很多事情,出现人等事,事等人的情况。// |
- | 通过认知模型我们可以知道,任意两个队员之间对于同一个事物的理解是有非常大的偏差的,所以这种**消除认知偏差**,或者说是**理解误差**的会议,特别重要。 | + | === 核心岗位划分 === |
- | + | 为了管理流程,就需要更细分的岗位。 | |
- | 经过了开会后,大家都去干各自的事情了,在不细分的情况下,流程如下: | + | |
- | + | ||
- | - 程序首先会去做功能框架 | + | |
- | - 同时期美术进行设计 | + | |
- | - 当美术交付了美术资源后,程序拿美术资源进行整合,调试。 | + | |
- | - 程序交付整合好的功能交付给策划验收。 | + | |
- | + | ||
- | 大多数开发团队,都遵循着这个流程进行开发。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 所以我们就要引入新的岗位:**制作人/ | + | |
- | + | ||
- | 许多人分不清策划、产品经理、项目经理之间的关系。 | + | |
- | + | ||
- | 其实没有一个定数,作者自己会这么去理解: | + | |
- | + | ||
- | * **产品经理**:等同于策划,出创意,完善细节,填表的。 | + | |
* **项目经理**:管理进度,安排生产流程,验收节点。 | * **项目经理**:管理进度,安排生产流程,验收节点。 | ||
+ | * **产品经理/ | ||
- | 当然,也有人有不同的意见,他们认为: | + | **策划内部又可细分为:** |
- | + | * **系统策划**:研究生态,系统结构。 | |
- | * **产品经理**:负责项目细节的,研究体验的。 | + | |
- | * **策划**:负责项目结构,研究宏观的。 | + | |
- | + | | |
- | 我个人更愿意遵循市场大流,区分为:**系统策划**,**体验策划**与**执行策划**。 | + | |
- | + | ||
- | * **系统策划**:研究生态,系统结构。 | + | |
- | | + | |
- | | + | |
- | | + | |
- | + | ||
- | 当然,填表工具人是玩笑,数值策划是一个项目的核心,这个后面会重点讲,这里不多深入。 | + | |
- | + | ||
- | 这些岗位没有定数,每个项目的情况都不同,很多小团队都是一人身兼数职,但我们得知道自己兼了哪些职位。越大的团队,则会拥有更细致的岗位分类,这里我们就不展开,对于萌新来说了解这些徒增烦恼。 | + | |
- | + | ||
- | 有了这些岗位,上述的图就需要改改,最终的程序整合流程中,他整合了美术资源与程序框架,但其实还会有许多策划填写的表格。 | + | |
- | + | ||
- | 为什么通常我们策划会称呼自己为:“填表工具人”? | + | |
- | + | ||
- | 举个例子: | + | |
- | + | ||
- | 我要一根香肠。 | + | |
- | + | ||
- | 经过三方会议后,这个需求会变成: | + | |
- | + | ||
- | 我需要一个香肠制造机器,其中,策划可以控制材料来源,形状,软硬度,颜色。 | + | |
- | + | ||
- | 那么,这里就存在一个最简单的模型: | + | |
- | + | ||
- | 香肠 = 工厂(原料,形状,软硬度,颜色) | + | |
- | + | ||
- | 为了让策划可以随心所欲的通过改变参数去制造不同的香肠,程序员就会给策划提供一张表,让策划自己填着玩,否则每次策划改动需求,就会让程序改一次代码,项目成本就会陡增。 | + | |
- | + | ||
- | ^ 香肠名字 | + | |
- | | 五毒香肠 | + | |
- | | 五香香肠 | + | |
- | + | ||
- | 你看,通过这张表,策划自己填写,完了录入到程序中,在其他队员不用协助的情况下,策划自己在限定的范围内随意修改,就能搭配出各种好玩的东西,这就是填表的过程。 | + | |
- | 再看美术,当拿到策划的美术需求文档时候,美术就要去画界面,设计原画,设计场景,设计动作,特效等等。如果是一个3D的项目,还要做3D模型。那么多的活,自然就会催生出更专精的岗位划分,通常一个极简的美术团队,结构如下: | + | “填表”的意思是,程序会把功能做成一个“机器”,然后提供一张配置表,让策划通过修改参数来创建不同的内容,而无需每次都改代码。 |
+ | ^ 香肠名字 ^ 原料 ^ 形状 ^ 软硬度 ^ 颜色 ^ | ||
+ | | 五毒香肠 | 蝎子,蜈蚣,毒蛇,壁虎,蟾蜍 | 长条椭圆 | 0.6 | 黑绿色 | | ||
+ | | 五香香肠 | 八角,茴香,桂皮,丁香,花椒 | 长条椭圆 | 0.4 | 红色 | | ||
- | | + | === 美术与程序团队 === |
- | * **原画**:将策划的描述变成可以看见的画面。 | + | **美术团队(极简版):** |
- | * **3D建模**:将原画的设计,以3D模型的方式实现出来。 | + | |
- | * **动作**:让2D或3D的模型动起来。 | + | * **原画**:将策划的描述变成可以看见的画面。 |
+ | * **3D建模**:将原画的设计,以3D模型的方式实现出来。 | ||
+ | * **动作**:让2D或3D的模型动起来。 | ||
* **特效**:让动作都带一些效果,比如抬手的时候有星光绽放。 | * **特效**:让动作都带一些效果,比如抬手的时候有星光绽放。 | ||
+ | * **技术美术(TA)**:会点程序又懂视觉艺术,负责把视觉效果做到漂亮。这是瑰宝,行业内稀缺的复合型人才。 | ||
- | 同样的,创业小团队里,超人们总是身兼数职。毕竟多一个人多一份成本,一个完整的美术团队,需要很多很多的开销。这里面也有取巧的方案,如果主美合格,有的团队也会用外包的形式,解决大部分美术资源的需求。这个又是更深入的话题了,萌新只用了解美术团队的构成,以及一般美术们会做什么。 | + | **程序团队(极简版):** |
+ | * **主程**:管理程序部门的,框架搭建,活路安排、验收。 | ||
+ | - **客户端程序**:负责写游戏的表现方式的,我们熟知的UE,Unity就是客户端程序员的工具。 | ||
+ | - **服务端程序员**:负责游戏的联网方面的逻辑,做网游必不可少的岗位。 | ||
- | <color # | + | {{: |
+ | 简单说,萌新要理解,一个游戏里,哪些部分是 **客户端处理** 的,哪些部分是 **服务端处理** 的。通常来说,客户端处理的,都是表现类型的。而服务端处理的,都是计算类型的。之所以把数据逻辑放在服务端处理,一个是要云端存储数据,另一个是要防止作弊。 | ||
- | 上面这个岗位,如果遇到了要尊重,这是瑰宝,行业内稀缺的复合型人才,通常项目性能怎么样,视觉效果能有多好,很大一部分来源于这个岗位的功劳。 | + | ===== 发行环节 ===== |
+ | 发行环节,存在着一个很重要的角色,就是:**发行商或 `发行人员`**。 | ||
+ | //最初,游戏研发团队将游戏开发到一定阶段后,就会在市场里寻找代理商,期盼着找到一个好的代理商,给一笔丰厚的代理费,利用他们丰富的经验帮助自己调优产品,再花费巨额的宣传费用,让自己的游戏天下皆知。// | ||
+ | 正如所有的事情一样,**现实总比理想残酷**。 | ||
- | 再看程序部这边,这边就简单了。 | + | === 第一步:找到研发 (BD) === |
+ | 这个市场上,并没有一个平台聚拢研发与发行双方。负责这个环节的人是 **`引进商务`** (BD),他们的工作是: | ||
+ | - **拓展**:拓展人脉渠道,不断地到处跑,认识新出现的研发商。 | ||
+ | - **参展**:参加各种各样有关于游戏研发的活动,拿到Demo。 | ||
+ | - **发展**:维护好已认识朋友的关系,以便第一时间拿到产品。 | ||
- | | + | === 第二步:评测 === |
- | * **客户端程序**:负责写游戏的表现方式的,我们熟知的UE,Unity就是客户端程序员的工具。 | + | 负责这个环节的人是 |
- | | + | |
- | 在不细分的情况下,程序员的岗位就相对简单,一般就分个前后端,在游戏行业,前端就是客户端,开发效果,UI,引擎相关的。后端就是服务端,比如你抽卡,那个概率,就是由后端程序员编写。 | + | // |
- | 这里面有一个非常简单的逻辑,需要策划明白,我们就以香肠机器为例子: | + | // |
+ | //为此,李四迫不及待想要与对方达成合作。// | ||
+ | // | ||
+ | // | ||
+ | // | ||
+ | // | ||
+ | 有时候,时间是一把 **黄金钥匙**,能够解开许多问题。 | ||
- | {{: | + | === 第三步:商定方向 === |
+ | 中国有句话:“**丑话说在前头**”。 | ||
+ | 在合作之前就把事情聊得清清楚楚,比合作后产生具有经济成本的矛盾要好得多。 | ||
+ | // | ||
- | 简单说,萌新要理解,一个游戏里,< | + | === 第四步:合同 === |
+ | 这是许多人的信息盲区。 | ||
+ | **代理费通常包含两种成分:** | ||
+ | - **版权金 (Copyright Fee)**:购买游戏版权的费用,属于买断,不需要偿还。 | ||
+ | - **预付款 (Advance Payment)**:提前支付给研发的利润。将来游戏产生流水后,会从研发应得的分成里 **优先扣除** 这部分。 | ||
+ | // | ||
+ | // | ||
+ | //这样,既满足了制作人爆炸的自信心,又满足了运营总监的成本控制需求。// | ||
- | 了解了三个部门分别做什么,我想萌新的大脑里也有了一个大概。因为本章节只是简单科普,所以就不进行更多的讲解,开发环节的具体模型与流程,我们后续会说。 | + | **付款节奏**:比如`433`、`334`,指的是分期付款的比例。分批付款的意义在于风险控制。 |
- | ====== | + | === 第五步:调产品 |
+ | 行业内有一句话:“**一分做,九分调**”,说的就是调产品的重要性。 | ||
+ | 理想的调优循环如下: | ||
+ | - 预设计,预埋点 | ||
+ | - 测试 | ||
+ | - 分析数据 | ||
+ | - 找出问题 | ||
+ | - 解决问题 | ||
+ | <note important> | ||
+ | **调优的核心流程:** | ||
+ | 1. **初次体验与建模**:团队一起玩,记录问题。对于含糊不清的问题(如“剧情没人看”),将其转化为可统计的数据模型(如“剧情跳过率”)。这事必须由策划来主导。 | ||
+ | 2. **测试与快速迭代**:每一次测试都是宝贵的攻坚战。要最大化利用测试获取数据,当晚修改,第二天就能看效果。否则就要等到下一次测试,浪费数月时间。 | ||
+ | 3. **盲调**:当没有测试机会时,只能根据理论和经验进行“玄学”猜测。我们的目标就是 **减少盲调的覆盖面积**。 | ||
- | ===== 发行是什么? | + | === 第六步:预热 |
+ | “丑媳妇始终要见公婆的”,我们的公婆就是玩家。 | ||
+ | // | ||
+ | 为什么要预热?为了 **利润最大化**。尽可能提前的去宣传一个产品,就能以低成本的方式尽可能的累计粉丝。 | ||
+ | **预热期间,发行一般能做些什么?** | ||
+ | - 社区运营 | ||
+ | - 广告投放 | ||
+ | - 自媒体运营 | ||
+ | - 新闻 | ||
+ | - 参展、参赛 | ||
+ | - 社群热点制造 | ||
- | 回到问题的维度: | + | === 第七步:上线 === |
+ | 上线是最紧张、最激动的时刻。当游戏上线后,客服、运营就忙起来,需要处理玩家的问题。 | ||
+ | // | ||
+ | // | ||
- | <color # | + | === 第八步:长尾 === |
- | + | 如何发挥游戏最后的剩余价值? | |
- | 发行环节,存在着一个很重要的角色,就是:**发行商或< | + | |
- | + | | |
- | 如果是**自研自发的公司**,那么就是**发行部门**,如果是**独立的游戏代理公司**,则整个公司被称为发行。 | + | //长尾渠道的特性,就是快餐,一个游戏可以快速发布一个魔改版本,然后过一段时间,关服再发布一个新版本。/ |
- | + | //玩家也就爽那么几个月,弥补了正式服的遗憾,开发商也赚到了最后一笔钱。/ | |
- | 但不管是哪种,都是由**发行人员**来参与,发行人员则指的是发行这个周期里参与的所有人员,在偶尔的时候,又特指运营人员。 | + | |
- | + | ||
- | 这到底是什么样的一个发行过程? | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 正如所有的事情一样,**现实总比理想残酷**。其中会有许多故事发生,我们现在从发行商的角度,看一看整个事情是怎么运转的。 | + | |
- | + | ||
- | ===== 第一步,找到研发 ===== | + | |
- | + | ||
- | 在这个市场上,并没有一个平台聚拢研发与发行双方,所以作为一个发行商,想要找到可以被代理的产品,就需要自己出去找研发商,找别人放出来的测试产品,如果对产品感兴趣,再去联系对方。 | + | |
- | + | ||
- | **什么人?** | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | **做什么事?** | + | |
- | - 拓展 | + | |
- | - 参展 | + | |
- | - 发展 | + | |
- | + | ||
- | **拓展**,拓展人脉渠道,不断地到处跑,认识新出现的研发商,不断地加群,不断地认识新的朋友。 | + | |
- | + | ||
- | **参展**,参加各种各样有关于游戏研发的活动,认识更多的同行朋友,最终认识到新的研发朋友,拿到他们的Demo。 | + | |
- | + | ||
- | **发展**,已经认识的朋友,要发展关系,让双方变得更加熟络,当研发商做出Demo后,就可以凭借良好的关系尽快的拿到产品,供给自己的团队去评测。 | + | |
- | + | ||
- | ===== 第二步,评测 ===== | + | |
- | + | ||
- | 引进商务会不断地把每个月新出现在市场的新产品放到团队中,也会把过去评测过,但有了重大更新的产品再次交给团队。 | + | |
- | + | ||
- | **什么人?** | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | **什么事情?** | + | |
- | - 评测 | + | |
- | - 沟通 | + | |
- | - 会议 | + | |
- | + | ||
- | **评测**,一个很复杂的过程,多杰见过许多人评测了很多年,也弄不清评测的维度。 | + | |
- | + | ||
- | **沟通**,如果评测团队觉得一款产品看起来不错,就还要评测研发出这个产品的团队如何,是否健康,是否能够维持下去,以及是否与发行团队能达成一致,毕竟发行是2个团队的事情,如果不能再沟通上能够强有力的达成一致,那么这款产品注定不会有好的结果。其最终目的,就是找到合适的合作伙伴。 | + | |
- | + | ||
- | **会议**,如果产品与团队都经过了考验,那发行团队的内部还要再一次进行会议,所有人都要参与进来,决策最终是否要代理这款产品。 | + | |
- | + | ||
- | 就像前面说的立项定生死一样,一个发行公司的评测环节也决定了这个公司的生死,所以很多发行公司都有几十人的团队去评测同一个产品,以尽量确保评测一个产品的“安全性”。 | + | |
- | + | ||
- | 反过来,我们从研发的角度看一下这个问题,还记得之前李四遇到的情况吗? | + | |
- | + | ||
- | 每家公司都表示对这个产品有意向,但就是没有一家签订契约。 | + | |
- | + | ||
- | 对于大多数制作人来说,都会遇到这种情况,其实与制作人做对抗的,不是对方**“不及时”**处理问题,而是这件事情本身对于任何一家发行公司来说,都是抉择起来十分困难的,许多许多次会议才能确定的。 | + | |
- | + | ||
- | 而这个过程中,公司也通常会有机制去防止因为“个人情感驱动”而签约一个产品的情况,自然的,也就有“冷静期”。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 有时候,时间是一把**黄金钥匙**,能够解开许多问题。 | + | |
- | + | ||
- | ===== 第三步,商定方向 ===== | + | |
- | + | ||
- | 如果双方合作,什么时候把方案定下来最好? | + | |
- | + | ||
- | 那就是合作开始之前。 | + | |
- | + | ||
- | 中国有句话:**“丑话说在前头”**。 | + | |
- | + | ||
- | 这个道理大家都懂,基于认知模型我们可以知道,两个人,两个团队之间的思想差异是无比巨大的,天与地的差别。不要害怕什么方案泄露,比起这个,如果不在合作之前就把事情聊得清清楚楚的,那么在合作以后,就会产生许多具有经济成本的矛盾,每一次不确定方案的再次讨论,都是双方可见的“亏损”。 | + | |
- | + | ||
- | 通常,以作者自己的经验来讲,我会基于自己的知识,也就是本书所讲的内容,整理出一个《XXX诊断书》,从各个时期的OPF表开始分析体验,再基于经验看看是否有一些会导致运营事故的设计。 | + | |
- | + | ||
- | 总之,我会给出一个较为全面的,从产品结构到体验,到数值,到生态,付费等各方面问题的报告。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | ===== 第四步,合同 ===== | + | |
- | + | ||
- | 这里就要详细给大家说说了,是许多人的信息盲区,产生误解最多的地方。 | + | |
- | + | ||
- | 市场里经常流传着,**发行商拿九成,研发商拿一成的故事**,如果是外行人或者刚入行的人听起来,就觉得这个市场太黑暗了,游戏制作商被剥削等等。 | + | |
- | + | ||
- | 当然,双方都是创业者,都很聪明,对吧? | + | |
- | + | ||
- | **细节的算账**,因为实际上也涉及不多,所以就在这里稍微讲解一下,本书不做单独的篇章展开。 | + | |
- | + | ||
- | 通常来说,签约合同时,会有两种成分: | + | |
- | - 版权金 | + | |
- | - 预付款 | + | |
- | + | ||
- | 而付款的节奏,又有:433,334等说法。 | + | |
- | + | ||
- | 还有付款的比例,则有:1: | + | |
- | + | ||
- | 如果知道的朋友,忽略这段内容就好。 | + | |
- | + | ||
- | 不知道的朋友,就跟随我的步伐,我们逐一理解。 | + | |
- | + | ||
- | **版权金**,顾名思义,就是我购买你游戏版权的费用。这笔钱不需要任何代价,属于我买断的。 | + | |
- | + | ||
- | **预付款**,就是我提前支付给你一部分你的利润,如果将来产生了流水,就会从你应得的部分里优先扣除掉的那一部分。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 制作人想:**“我这产品那么厉害,你就给这点钱给我?”** | + | |
- | + | ||
- | 运营总监想:**“谁也不知道将来的事,你就这样想开高价?”** | + | |
- | + | ||
- | 这不,在这样的碰撞下,就产生一种模式。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 再看付款节奏,这里其实每家公司不同,甚至每个项目都不同,作者也会根据实际情况调整。有时候金额不大,也会一笔款付清。这个数字,说的就是每次付款的比例。如果我说1117,意思就是前三次付款都付一成,最后一次付九成。 | + | |
- | + | ||
- | 第一次付款,通常在合同签订后的几天之内。 | + | |
- | + | ||
- | 第二次付款,通常在游戏测试完成,准备上线之前。 | + | |
- | + | ||
- | 第三次付款,通常在游戏上线,确保无重大事故后。 | + | |
- | + | ||
- | 有时候,双方敲定的版本内容希望有合同约束,那么就会变成四次付款,其中一次就是在合同所指的内容完成后,付款给研发商。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 举个例子,张三代理李四的产品,张三说:“37分成,334付款,总价1000万,版金300,预付700。” | + | |
- | + | ||
- | 这是什么意思? | + | |
- | + | ||
- | 张三打算给李四1000万代理费。 | + | |
- | + | ||
- | 合同签约时候,张三会给300万。 | + | |
- | + | ||
- | 当付费测试结束后,张三需要再给300万。 | + | |
- | + | ||
- | 当游戏上线,且无重大运营事故后,张三需要给后面的400万。 | + | |
- | + | ||
- | 而此时,预付款是700万。 | + | |
- | + | ||
- | 也就是说,如果游戏在第一个月产生了5000万的流水,那么根据分成比例,应该给李四5000万 * 0.3 = 1500万左右(实际上会更少,有其他费用)。 | + | |
- | + | ||
- | 因为之前付过700万,所以这里实际上要给李四结算1500万 - 700万 = 800万元。 | + | |
- | + | ||
- | 很容易理解。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 这里的说法,**对,也不对**。要看你遇到什么样的代理商,以及是什么样的产品,什么样的时期。 | + | |
- | + | ||
- | **签约好了合同,付好了钱,就要进入下一个阶段。** | + | |
- | + | ||
- | ===== 第五步,调产品 ===== | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 这种说法有时候灵,有时候不灵,具体看当前产品的各种因素的权重,如果其他因素权重不高,对于产品的成功没有决定性的影响,那么就全靠调产品的能力了。 | + | |
- | + | ||
- | 调产品,也是许多团队的难题,核心还是缺钱与缺方法论。从宏观的角度看,钱好解决,所以对于大部分团队来说,缺乏的是调产品的经验与方法论。 | + | |
- | + | ||
- | 我们整本书几乎都在说与调优产品有关的内容,所以这里就稍微讲解下大概的。 | + | |
- | + | ||
- | 正如前文所说**文立项**与**理立项**区分一般,这调产品,也分为**文调**与**理调**。 | + | |
- | + | ||
- | 两者不是对立的关系,而是统一使用的关系。 | + | |
- | + | ||
- | 调产品,理想的情况,可以这么去划分几个阶段: | + | |
- | - 预设计,预埋点 | + | |
- | - 测试 | + | |
- | - 分析数据 | + | |
- | - 找出问题 | + | |
- | - 解决问题 | + | |
- | + | ||
- | 如此循环。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 所以,那些数据都是宏观的,我们来执行调优的策划,应该关注更微观的数据。比如**关卡流失**,**系统参与率**,**界面点击路径**,**剧情跳过率**,**注册成功率**等非常细节的数据。 | + | |
- | + | ||
- | 结合上述的阶段,接下来我讲述一下整个流程。 | + | |
- | + | ||
- | 当我们拿到一个较为全面的产品时候,会先大体玩一遍,这一次玩,是带着目的的,因为有一些事情,只有第一次玩的时候才会发现。 | + | |
- | + | ||
- | 我们会弄一个《体验记录表》,然后大家一起记录自己玩的过程中遇到的各种问题。等玩得差不多了,就一起开会进行一次汇总。 | + | |
- | + | ||
- | 体验这个东西,它是主观的,有一些问题,大家一看就知道,不会产生歧义,直接给出解决方案,把问题停留在“文科”层面,也就是凭借个人主观的感受与记忆就能解决。 | + | |
- | + | ||
- | 有的问题,则比较头疼,是含糊不清的,所以就需要转化体验为模型。 | + | |
- | + | ||
- | 举个例子: | + | |
- | * 张三说:**“剧情没人看啊。”** | + | |
- | * 李四说:**“剧情很多人喜欢看的。”** | + | |
- | + | ||
- | 这种问题,如果之前没有统计过,那确实就会成为一个争论的问题。 | + | |
- | + | ||
- | 此时,就会建立一个模型,多少人在剧情对话框的地方点跳过。 | + | |
- | + | ||
- | 最终,统计出来数据,非剧情类的游戏,会有88%~96%左右的人选择跳过剧情,经过一次测试,我们就很清楚,原来大部分人是不愿意看剧情的。 | + | |
- | + | ||
- | 其中,把体验问题转化为可统计的问题的过程,就是调优环节中非常重要,但被许多人遗漏的环节。 | + | |
- | + | ||
- | 这事谁来做? | + | |
- | + | ||
- | * 策划:“当然是数据来做。” | + | |
- | * 数据:“我又不知道你怎么设计的,我咋知道你想看什么数据?” | + | |
- | * 程序:“你们给个埋点,我埋就是了,别找我设计。” | + | |
- | + | ||
- | 从经验看,这事必须策划做,而且不是某个策划,是整个参与项目的策划团队来做。只有每个策划,才知道自己负责的系统,有哪些含糊不清的地方,可能会出问题的地方。 | + | |
- | + | ||
- | 当然,成熟的发行公司发行了多款项目后,这种预建模的能力就相对成熟了,也许发行公司的产品人员就能做好这份工作。 | + | |
- | + | ||
- | 拆解一个游戏,然后对这个游戏的各个细节的地方做预期,当有了预期,就结合预期做埋点设计。 | + | |
- | + | ||
- | 接下来,就是测试。 | + | |
- | + | ||
- | 每一次测试,都是十分宝贵的资源,一个不成熟的制作团队或者发行团队会忽略测试的价值。而对于有经验的人来说,最大化的从每一次测试中获取利润,是我们的职业追求。 | + | |
- | + | ||
- | 我们产品/ | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 过了新手引导,还要统计用户对每个玩法的参与率,如果是非线性的内容,不论是玩法与抽卡,还要统计每条线路对用户未来留存影响。 | + | |
- | + | ||
- | 我们的目的,就是基于用户的体验细节,尽可能的完善每一个小点。 | + | |
- | + | ||
- | 此时,除了预先设计的模型外,通常我们还能发现一些意料之外的问题,如果埋点足够细致,我们就有幸分析这些问题。结果总是令人头疼的,因为只有少部分问题是我们立马就能知道的。 | + | |
- | + | ||
- | 还有许多问题,需要猜的,这就和程序员遇到BUG一样,需要大胆假设,小心求证。 | + | |
- | + | ||
- | 为什么要预先建模,就是为了现在做准备。如果预先建模了,当测试的第一天快要结束时,我们就有已经分析好了大部分数据。 | + | |
- | + | ||
- | 当晚,可以立马修改对应的方案,补充对应的埋点,然后更新出去,第二天就能查看修改的效果,或者分析前面说的意外问题。 | + | |
- | + | ||
- | 反之,如果在测试期间,我们没有快速响应的能力,这个问题的排查验证就需要等到下一次测试,这个时间可能跨度是好几个月,十分的“浪费钱”。 | + | |
- | + | ||
- | 想必看到这里,读者应该能明白了测试的价值是多么的高,并不是那么儿戏,不是什么:“先测测看看”。是一场需要精心规划的攻坚战。 | + | |
- | + | ||
- | 测试完毕,慢慢分析,有的问题小改即可,有的问题大改才能完成。此时已经没有了继续测试的机会,所以问题修改后,我们没有机会马上验证。如果有什么问题依旧没有头绪,就需要进行“玄学”猜测,想要让这种主观的猜测变得靠谱点,就需要结合我们的理论,再配合参与者本身的经验,这就是大部分团队所不得不面对的黑暗时光:盲调。直到下一次测试的来临,才能再一次得到想法的验证。 | + | |
- | + | ||
- | 减少盲调的覆盖面积,就能尽可能的省钱。 | + | |
- | + | ||
- | ===== 第六步,预热 ===== | + | |
- | + | ||
- | 中国有句话:**“丑媳妇始终要见公婆的”**,我们的公婆就是玩家,测试始终有个极限,调优也有极限。调优只能解决部分问题,但一个产品,基于它的题材,美术,玩法就有它的局限性。 | + | |
- | + | ||
- | < | + | |
- | + | ||
- | 有的公司,会设置一个门槛,产品数据调不到一个水平线,就绝对不上线,因为他们不缺产品,上线不合格的产品就是浪费手里的用户资源,也会给用户带来的不好的体验,损坏品牌。 | + | |
- | + | ||
- | 这并不是什么故意签约,把同类产品打入冷宫的做法,有很多不理解的研发,就会这么去形容发行公司,实际上作为一个商业主体,最主要的目的就是**创造利润**。 | + | |
- | + | ||
- | 手里一堆产品,同一时期上线一个产品,那么谁的数据好,就上谁,不然就是对不起股东,对不起投资人,属于决策者的失职。 | + | |
- | + | ||
- | 不管我们的产品是谁来代理,总有要上线的时刻,所以就来到了预热环节。 | + | |
- | + | ||
- | 为什么要预热? | + | |
- | + | ||
- | 其实也很简单,为了**利润最大化**。 | + | |
- | + | ||
- | 假设某时刻,有x个网民在网上冲浪。我希望通过某种渠道影响到y个网民。就构成了 y/x 的占比。 | + | |
- | + | ||
- | 在市场宣传的层面,在某时刻,花钱越多,覆盖的人群越多。但是有一个性价比曲线,并不是无止尽的花钱能带来最大化的利益。 | + | |
- | + | ||
- | 有一个y的最优值 y’。 | + | |
- | + | ||
- | 那么,加上时间t后,就得到到一个 y’1,y’2…y’n 的累加结果。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 这就是预热的妙处,并且随着预热的人数变多,如果稍微做一点裂变的活动,就很容易让游戏被全网所知,这就是预热带来的好处。 | + | |
- | + | ||
- | <color # | + | |
- | - 社区运营 | + | |
- | - 广告投放 | + | |
- | - 自媒体运营 | + | |
- | - 新闻 | + | |
- | - 参展 | + | |
- | - 参赛 | + | |
- | - 社群热点制造 | + | |
- | + | ||
- | 社区运营需要一定的用户基数才有效果,并且游戏没有开始,其实没啥好吹的。 | + | |
- | + | ||
- | 广告投放需要与正式上线的游戏对拼,不划算,当然,如果某平台的投放机制对预约有优惠,则适合在上线前的1周投放,比如TapTap,谷歌市场。 | + | |
- | + | ||
- | 自媒体运营,是许多小众文化产品的绝杀之地,他们通过在核心圈子内经营,就可以聚拢到足够忠诚且具备规模的玩家群体,二次元就是这样发展起来的。 | + | |
- | + | ||
- | 参展、参赛,这是大作喜欢参与的战场,作者只做过一两次评委,没有以开发者的身份参加过,所以也没啥经验可以分享。 | + | |
- | + | ||
- | 这里就到此为止,大概了解就行,需要细化的后续会专门讲解。 | + | |
- | + | ||
- | ===== 第七步,上线 ===== | + | |
- | + | ||
- | 上线啊,是最紧张的时候,也是最激动人心的时刻。 | + | |
- | + | ||
- | 不管你做的准备有多么的充分,此时都是最繁忙的时候,因为一个追求卓越的项目组,它永远有做不完的事情,总觉得哪里都能再优化一点。 | + | |
- | + | ||
- | 比如一张新闻稿的样式,措辞,比如游戏内的调优,比如广告视频的音乐,比如服务器的负载等等。 | + | |
- | + | ||
- | 但从规划上,到了这一步,又没啥可做的。因为它属于最终的检查步骤,没有固定套路,有啥做啥,随机应变,尽快处理,就是这个阶段要做的。 | + | |
- | + | ||
- | 当游戏上线后,客服,运营就忙起来,需要处理玩家的问题,如果没有运营事故,是最幸福的,也是实力的象征。 | + | |
- | + | ||
- | 但如果出现了运营事故,那之前准备的各种运营事故的公告文本,就有了作用,要第一时间向玩家群体反应情况,并及时的更新,以便玩家觉得有问题没地方反馈。 | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | <color # | + | |
- | + | ||
- | 上线后,依然是分析数据,市场投放,调整产品,出新版本的循环。直到团队认为这个项目不再值得维护为止。 | + | |
- | + | ||
- | ===== 第八步,长尾 | + | |
- | + | ||
- | 这是一个很神奇的阶段,作者曾经在论坛里问过同行,一个游戏运营到了后期,如何发挥好最后的剩余价值。 | + | |
- | + | ||
- | 当时没有人回答,后来自己在工作中,也摸索出了一些路径。 | + | |
- | + | ||
- | 简单来说,如果一个产品要出第二代,有忠实的玩家,那么<color # | + | |
- | + | ||
- | 但如果这个产品没有第二代了,团队希望它能给自己再次带来更多利润,那么就按照前面讲过的,重新以私服、变态服的形式,在长尾渠道中发行N次,注意,是N次。 | + | |
- | + | ||
- | <color #00a2e8>长尾渠道的特性,就是快餐,一个游戏可以快速发布一个魔改版本,然后过一段时间,关服再发布一个新版本。</color> | + | |
- | + | ||
- | <color #00a2e8>玩家也就爽那么几个月,弥补了正式服的遗憾,开发商也赚到了最后一笔钱。</color> | + | |
- | + | ||
- | 当然,也有一些游戏,会出现在长尾渠道业绩很好的情况,这样的产品就会较为持久的在长尾渠道运营。 | + | |
====== 总结 ====== | ====== 总结 ====== | ||
- | + | 到了这里,我想萌新应该对游戏的生命周期有了一点点理解。 | |
- | 到了这里,我想萌新应该对游戏的生命周期有了一点点理解,其实很多内容就算我讲了一大段故事,也只能有个非常模糊的概念,实际情况还是要深入到工作环境中区了解。 | + | 不管您从事什么样的岗位,了解整个行业的岗位情况,了解游戏的生命周期,是一件非常重要的事情。 |
- | + | 许多同行对其他岗位的 **“埋怨”**,几乎都来自 **信息不对称**。 | |
- | 不管您从事什么样的岗位,在什么样的团队,发行又或是研发,美术又或是程序,了解整个行业的岗位情况,了解游戏的生命周期,是一件非常重要的事情。 | + | <note warning> |
- | + | 而另一个层面,被其他同行“忽悠”,也是源自这种信息不对称。 | |
- | 许多同行对其他岗位的**“埋怨”**,几乎都来自**信息不对称**。 | + | 如果打算投身这个行业,这些行业的基本信息就显得十分的重要。 |
- | + | 毕竟谁也不想被同行“忽-悠”,是吧? | |
- | <color #ed1c24> | + | </ |
- | + | 受限于作者的认知,能力有限,只能做出这样的介绍,如果最终未能达到 **“让萌新大概了解行业”** 的效果,还请大家见谅。 | |
- | <color #ed1c24>如果打算投身这个行业,这些行业的基本信息就显得十分的重要。</ | + | |
- | + | ||
- | 毕竟谁也不想被同行**“忽悠”**,是吧? | + | |
- | + | ||
- | 受限于作者的认知,能力有限,只能做出这样的介绍,不知道最终是否能达到**“让萌新大概了解行业”**的效果,如果不能,等得到大家反馈后,会在再版时进行修改,还请大家见谅。 | + | |
---- | ---- | ||
> // | > // |