小团队策划设计手游社交系统的一些思考与经验

作为小团队的策划，很多时候，在做手游社交系统的时，决定不了要做什么、怎么做。在与领导的沟通中也会存在各式各样的分歧与意见，最后领导不耐烦了，留下一句：“照着XX游戏的社交系统抄就是（对）了！”然后大步离去，留下呆在原地的你。道理我都懂，但该怎么做，或者怎么做才是正确（正当）的方式呢？

一、绕不过且必须解决的首要问题：我们做社交系统的目的是什么？

拿到任务时，我们不要怕不能慌，先弄清楚我们做社交系统的目的是什么？在纸上写一下，大体目的如下：

1.为玩家提供主要的交互平台和方式；

2.满足（硬凑）某些已完成模式的玩法需求；

3.迎合运营的口味。

其实以上三点，只有第一点为玩家提供主要的交互平台和方式是主要的，其他的属于很次要的，大概知道有这么回事就行。注意，在明确了我们做社交系统的目的，提供玩家主要的交互平台方式时，应该尽量避免自嗨，比如社交系统中的聊天系统，一想到聊天，有些策划就立刻觉得大有文章可做，频道聊天、公会聊天、队伍聊天等等，如果再复杂点，可以设置成玩家世界聊天需要付钱的：哇塞，一个付费点被挖掘出来了，真棒！实际呢，实际上最后游戏中，可能看到的都是各式各样的广告，一个良好的交互平台设计产生了不好的结果。因此，在明确做社交的目的时，如何避免自嗨，是每个小团队的策划所要考虑的。



二、明确目的以后，确认第二的问题：在有限的条件下，我们的社交系统到底该怎么做？

什么是有限的条件？这是专门针对小团队来说的，有限的资金，有限的人力，以及有限的团队能力。

那有了这些限制，我们怎么做我们想要的社交系统呢？

首先、不考虑任何限制，将我们需要的这块社交系统用思维导图画出来，根据我们的游戏类型，明确到底有哪些我们需要的社交系统。


其次、当我们将我们需要的社交系统列出以后，将所有的功能标记优先级，哪些是必须要做的，哪些是可以做的，但当前进度下不做，以后再说的，哪些是可做可不做的。

最后、标记好优先级以后，再将上述有限的条件搬进来，评估下，有限的条件下，是否有优先级高的，来不及做，比如时时同步，时时推送，强联网下的合作等等，需要调整成优先级，向后延期的；是否有当前条件无法实现，比如，在既有的引擎中无法添加一些第三方的框架插件，导致部分社交活动需要换一种方式去做的。这样一条条过滤下来，才是我们最终要做的社交系统。

相关阅读： 游戏中的社交特点：游戏需求决定是否社交