在游戏中加入支付 SDK : 豌豆荚开发者中心
在游戏中加入支付 SDK
配置游戏服务器端回调地址URL
游戏客户端使用申请好的Appkey_id,secretkey
游戏客户端使用doLogin方法调用豌豆荚登录
登录成功(onSuccess)后，游戏客户端提交用户信息(uid,nick,token)到游戏服务器
游戏服务器提交uid,token到豌豆荚服务器进行验证，验证通过后游戏完成登录
游戏客户端创建订单，设置游戏订单号(order.out_trade_no)，发起支付(pay)
玩家完成支付,返回游戏客户端
只有支付成功的订单，豌豆荚服务器通知游戏服务器回调地址，包含order.out_trade_no
游戏服务器端验证回调信息中的签名，使用RsaTest项目中的公钥既可，验证通过后发放游戏道给游戏客户端并返回success字符串，处理失败返回fail字符串
游戏客户端开始使用道具
复制 wdjpayplugin.jar到游戏项目中的libs目录，复制 assets_wdj347.apk 到 assets 目录中，按照Demo提供的方法调用接口既可。
以下是集成 SDK 时您特别需要注意的问题：
集成 SDK 中有任何问题，请工程师加入豌豆荚 SDK 技术支持群
包名的命名原则为：公版渠道包名 + 后缀「.wdj」，如 com.yourgame.wdj
支付后发货后回调的流程为：「用户支付成功」-「CP 服务器接收豌豆荚服务器回调」-「发送成功，返回success，不成功回fail，等待下次回调」，严格禁止未发货即响应回调的行为，这也会直接导致后续的财务结算异常
每个 Appkey 仅能用于一个游戏。如果有多个游戏需要嵌入 SDK，请分别为每个游戏申请单独的 Appkey 及 ID，否则会导致登陆及支付失败。
项目请设置AndroidManifest.xml 使用 android:minSdkVersion=+ android:targetSdkVersion=+编译，能够在Android2.3上运行。
请仔细确认部分的所需文件。
请确保调用SDK方法和处理回调方法在主线程中进行，。
SDK 初始化
在 onCreate 方法里调用 PayConfig.init(this, appkey_id, secretkey) （其中 appkey_id 为您申请的支付 ID， secretkey 为安全密钥），完成支付 SDK 的初始化。
[注] 此步骤必须在启动游戏的时候调用，否则后面任何请求都会出现异常。
豌豆荚账户接口
接口用法细节请参考 PayDemo 例子代码
账户接口定义：
public interface WandouAccount {
// 默认登录接口
public void doLogin(Activity act, LoginCallBack callback);
// 注销登录，callback 参数已经废弃，不会有回调，请传入 null
public void doLogout(Context appContext, LoginCallBack callback);
// 切换账户
public void reLogin(Context appContext, LoginCallBack callback);
调用方需要实现 LoginCallBack 接口，当登录/注册成功时调用该回调方法：
public interface LoginCallBack {
// type==3 正常登录；type==4 新注册
public void onSuccess(User user, int type);
public void onError(int returnCode, String info);
举例：登录
account.doLogin(PayUnity.this, new LoginCallBack() {
public void onSuccess(User arg0, int arg1) {
//登录成功
public void onError(int arg0, String arg1) {
// 请不要在这里再次触发doLogin登录，会产生错误。
// 如果用户放弃登录，回到游戏界面后，应该通过点击游戏界面中的按钮重新登录。
举例：切换账户
account.reLogin(PayUnity.this, new LoginCallBack() {
public void onSuccess(User arg0, int arg1) {
public void onError(int arg0, String arg1) {
// 请不要在这里再次触发doLogin登录，会产生错误。
// 如果用户放弃登录，回到游戏界面后，应该通过点击游戏界面中的按钮重新登录。
在游戏初始化界面提供 进入游戏 的按钮调用 doLogin 实现触发登录。同时在进入这个界面(onCreate)时也可以主动调用一次doLogin 方法。
登录信息服务器端验证
方法：GET，大小写敏感如果 token 有效，则返回字符串 true ，无效则返回 false
编码：UTF-8
登录账户 uid
user.getUid()
登录账户验证信息
user.getToken()
游戏AppKey_id,数字类型
// 验证接口
String uidCheckUrl = &/api/uid/check&;
// 生成验证连接（GET）方式 需要将参数 url 转码
String url=uidCheckUrl+&?uid=&+user.getUid()+&&token=&+ URLEncoder.encode(user.getToken())+&&appkey_id=&+appkey_
备注：请使用 GET 方式访问接口，token有效期在15分钟以内。
如果验证时返回false,请务必提供原始token内容和uid给我们协助调查。
初始化订单
WandouOrder order =new WandouOrder(String subject, String desc, Long money);
传入开发者订单号
order.setOut_trade_no(“订单号”);
其中订单号由开发者自己定义，长度为 50 个字符，
必须填写，如「梦想海贼王」，也就是所谓 order name
必须填写，不超过7个汉字长度，如「1000元宝」
单位是“分”
out_trade_no
开发者的订单号
初始化支付实例
WandouPay wandoupay=new WandouPayImpl();
wandoupay.pay(Activity act,WandouOrderorder,PayCallBack call);
wandoupay.pay(PayUnity.this, order, new PayCallBack() {
public void onSuccess(User arg0, WandouOrder arg1) {
// 成功逻辑
public void onError(User arg0, WandouOrder arg1) {
// 失败逻辑
推荐直接使用支付宝方式测试，最低支持1分钱。不提供测试环境、测试账户。
服务器回调
在订单支付成功后会立即以 POST 方式回调开发者提供的回调 URL
签名使用 RSA 验证 ,详细代码参见内server目录中的文件，我们已经提供服务器端 Java，PHP，C#，C++ 进行RSA验证的例子，请参考完成。
公钥使用上述例子的即可,安全性请参考RSA数字签名原理
订单支付失败不会回调
订单处理成功，返回字符串success, 以PHP为例 echo "success"; 即可。失败返回fail字符串。
POST回调参数
以PHP为例，($_POST['content'])
签名类型（RSA）
值固定 RSA
其中 Content 参数，内容以JSON形式给出。
豌豆荚订单id
单位是（分）
chargeType
ALIPAY：支付宝
SHENZHOUPAY：充值卡
BALANCEPAY：余额
CREDITCARD : 信用卡
DEBITCARD：借记卡
购买人的账户id
out_trade_no
开发者订单号
创建订单时候传入的订单号原样返回
只有充值卡充值的时候才不为空
游戏服务器在收到回调通知后，应该首先进行签名验证，再进行业务处理。当游戏服务器没有正常返回 success 时，豌豆荚服务器会多次通知游戏服务器，24小时后放弃通知。对于24小时后的订单，可以进入豌豆荚后台发起手动回调。如果是已经处理成功的订单，后续收到的豌豆荚通知，也应该返回 success。
服务器回调联调
如果支付订单后没有收到豌豆荚服务器回调通知，首先请检查：
配置的URL是否正确，可在里编辑，会立刻生效
检查客户端appkey是否正确
查看游戏服务器的access log。
在里查询订单详情中的回调时间
确认以上没有问题后，可以在里查询失败订单发起手动回调。
进入，点击 联运游戏，之后可以批量查询订单详情。
提示 Make sure you call PayConfig.init() in onCreate(Activity) correctly.
原因：因为没有在 Activity 的 onCreate 方法中初始化支付 SDK。请在 onCreate 方法里调用 PayConfig.init(this,appkey_id)，完成支付SDK的初始化。
提示:java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare
原因:没有在ui主线程调用接口，可以使用Activity.runOnUiThread方法调用。
问题:希望豌豆荚服务器IP列表
解答: 60.28.207.131-60.28.207.158
125.39.223.131-125.39.223.158
问题：横竖屏幕设置
解答：如果游戏是横屏的，豌豆荚收银台会自动为横屏。如果游戏是竖屏，则收银台是竖屏。只有游戏能够自动横竖屏变化，收银台才可以随着变化。
问题：透传字段，自定义字段？
解答：直接用使用out_trade_no 字段，最多50个字符，可空可重复。如果数据放不下，请在自己服务器存储信息。
问题：已经返回success，还有豌豆荚回调通知？
解答：必须在2s内返回，超时后，豌豆荚会不断通知，24小时后放弃。
问题：登录验证的作用？
解答：验证玩家身份，确保玩家道具等数据安全。
问题：createRole在哪里调用？一定要调用吗？
解答：玩家登陆后创建角色是调用。可选调用，不要求。
问题：编译后assets中的apk会被自动删除？
解答：如果遇到这个问题，请在编译脚本(bat或sh)或build.xml(参考android ant手册)中增加复制apk到assets目录的命令。
问题：没有单独的RSA秘钥？
解答：没有单独的。全部游戏使用均使用zip包中例子的一个RSA公钥。我们已经提供服务器端 Java，PHP，C#，C++ 进行RSA验证的例子，请参考完成。
问题：部分玩家反馈登录不了？
解答：如果只是少数玩家一直反馈登录不了，其他玩家却可以。可以先确定一下玩家登录时是否正确收到token，如果没有则建议玩家切换不同的网络再尝试。经我们调查在部分地区网络DNS解析存在问题。
问题：测试反馈游戏order name 不正确?
解答：请参考 ，传入正确的subject 和desc 参数。
游戏自己维护升级，在后台上传新版后，可以找到下载链接。
目前已经确认支持 Adobe Air 、Unity3D 、Cocos2d-x 等游戏引擎。
需要打包的资源库如下：
wdjpayplugin.jar 豌豆荚支付 jar 包到 libs 目录(不可缺)
assets_wdj*.apk 到游戏 assets 目录(不可缺),* 号为版本数值
请确保在 Android UI 主线程中调用 SDK 的接口， 必要时可以使用Activity.runOnUiThread方法。
AndroidManifest.xml 声明部分
-keep class **.R
-keep class **.R$* {*;}
-keep class com.alipay.android.app.** {*;}
-keep class com.wandoujia.** { *;}
-keep monsware.cwac.parcel.** { *;}
-keepattributes InnerClasses
Adobe Air 接入官方文档
Android主线程调用方法例子
new Handler(Looper.getMainLooper()).post(new Runnable() {
public void run() {
// 这样确保是在主线程调用，也可以处理UI更新
//((TextView) findViewById(id)).setText(str);
如果您需要更多帮助，请在此提交，我们将在 1 个工作日内回复。
获得帮助或提供反馈
邮件支持：
企业 QQ：400 652 8705豌豆荚为什么要推出游戏社区？是否能做得起来？
在升级的版本中带有游戏社区的功能。目前仅针对部分游戏做了社区化，而且在相关游戏页面也没有引导，看起来是初测。界面设计采用了微博化，原来用户只是来这里安装游戏而已，现在却要在这里交流游戏。以我观察，豌豆荚做社区的决心是很大的，可能不仅是游戏社区，以后可能会拓展到其他类目下的社区：一，符合产品定位：内容发现（发现优秀游戏攻略，发现优秀玩家）二，流量很充分：方便人群过滤三，有人负责这个产品，刚从豆瓣离职的 @ 加入了豌豆荚，Lebanner 原来负责豆瓣社区产品。因为我现在也遇到类似问题，也在同样担心是否能做得好的问题。原来的豆瓣小组更倾向于不做人力运营，用产品机制去引导用户，让其自振荡。这个游戏社区的运营上会有哪些点值得注意？
按投票排序
想不到还真有人注意到了。。。先说说背景，和豌豆荚关系不大。我去年底从豆瓣离职，之前一直在负责豆瓣社区的产品（小组小站日记相册线上活动等），后来豆瓣业务扩展，小组的体量比较大，就分拆为一个单一的产品线，由我来负责业务增长和产品方面的探索。在这个过程中，尤其是小组的移动化改造上，我遇到了一些关键问题：1、小组这种以BBS为基本形态的产品，如何在保留原有 重内容 价值的基础上进行移动端轻量化的改造；2、小组这种以文字为主要互动方式的产品，如何在保留原有用户习惯不被破坏的前提下扩展新的互动方式；3、最重要的，在失去了PC端搜索引擎这个人群过滤入口之后，移动端的泛社群产品要如何吸引用户 —— 豆瓣小组里有无数旅行相关的内容、摄影相关的内容、宠物相关的内容、kill time的内容……甚至宗教内容、医学内容，在PC端人们随便搜点东西就会看到豆瓣的链接，而在移动上，除了产品名之外，你搜啥都不会发现有豆瓣小组的存在，明明你需要的内容这里可能都有。和我们在同时间做探索的百度贴吧，也是一样，种种努力都成效甚微，在移动上的体量与PC端的地位完全不匹配。其实不止是小组，整个豆瓣在移动端都面临同样的问题，既有优势如何延续、新的市场如何开拓。限于个人能力，在豆瓣的时间里我没有找到解决这些问题切实可行的办法，虽然团队也做过不少尝试，有的上线了，有的开发完由于各种原因根本没上。所以在看到自己的界限后，我选择离开了豆瓣。（详见 ）再来说豌豆荚为什么要做这件事。离开豆瓣后就是一方面反思自己，一方面看新的机会。其实在和豌豆荚接触之前，我就已经知道了还有其他同类产品也有把业务从分发扩展到社区的打算，但是几次聊下来都觉得目的相似但动机和心态不同，不是同路人（比如现在可以更新下百度手机助手，他们在应用详情页加了点东西）。最后谈到了豌豆荚。在和现在的老板
交流的时候，他向我阐述了他对内容消费的生命周期的看法，即“内容发现 - 内容查找 - 内容获取 - 内容消费 - 内容管理 - 内容分享” ，并表示豌豆荚想做的事就是要覆盖这个周期的所有环节。当时我就震惊了，因为他的这个观点和我自己的看法几乎完全一样，我之前基于豆瓣的分析总结出的是“内容的主动发现（查找、排行） or 被动发现（他人的推荐） - 内容消费 - 内容管理 - 内容交流 - 内容分享（循环到被动发现）” ，甚至我在离开豆瓣前留给豆瓣的建议也是：豆瓣在图书、音乐、影视的所有服务中唯独缺少内容（的获取）和消费，使得整个链条断裂，这是导致豆瓣整体价值难以突破（并重心不断向社区方向倾斜从而整体失调）的关键原因，豆瓣应想办法将内容消费也放到自己的服务体系下（就像豆瓣FM那样）。所以，既然双方都想到一块去了，我也就没理由不加入了。豌豆荚现在正在做的事，就是把自己提供的内容，从应用和游戏，扩展到更多的内容类别，在全内容上覆盖到发现、查找、获取、消费、管理这五个环节。而我在豌豆荚要完成的事，就是补上最后一环：内容分享。不仅让人们可以在豌豆荚一站式完成内容的获取，还可以在豌豆荚内完成与其他人的内容交流，让人们的分享，成为他人内容发现的方式。这件事说起来容易做起来难：1、用户对豌豆荚既有的认知难以段时间改变，反而会成为社区产品启动的障碍；2、豌豆荚作为企业，整个思考方式和做事习惯都是工具导向的，而社区产品与工具产品的设计规划完全不同；3、百度搜索的无敌是贴吧成立的大前提，内容搜索是豌豆荚的目标，而不是已经有的成果。其实，移动领域的泛兴趣社群产品（也就是在移动时代接管BBS的产品）至今尚无成功案例，LOBI、LINE CAFE、LINE BAND、CELL、Mightybell、Moot、Discourse、Branch……死的死残的残。按照我对社群产品的理解，这些独立的泛社群产品之所以做不起来，归根结底是人群过滤器的缺失（详见 ），也就是产品本身具备满足社群内互动的功能，但不具备一开始把相同爱好的人聚集到一起的能力（来往现在拼命推扎堆，纯粹是拿钱和人力硬砸），以及把社群内容对外输出的能力。而豌豆荚在这方面有一丝机会，因为豌豆荚在做内容入口的同时，等于就掌握了人们的兴趣图谱，掌握了兴趣图谱，也就具备了把相同爱好的人聚集到一起的可能。这是我选择在豌豆荚继续做社群产品的根本原因（其实我也好想做点别的产品阿- -）。同时也是豌豆荚为什么能做这件事。具体来说怎么做的呢。首先我们并没有一开始就铺到全部的内容类别，而是只针对手机游戏，理由是这个人群足够大、交流需求足够强，并且竞品相对较弱（发现没有，手游的爆发也一年多了，市场上尚未出现能够比肩当年端游爆发时17173那种规模和影响力的手游网站），我个人有四年多的游戏网媒和社区的经验，手游也是爱好之一，相对更熟悉一些。而在手游领域，也是先开了几个版块试水，这是为了有重点地积累种子用户，因为豌豆荚的情况不同于豆瓣，豆瓣凭借庞大和优质的用户群，任何UGC产品都能在一夜之间完成Startup。当然产品形态上还是选择了社群这种模式而不是其它（针对游戏的交流，确实还有很多其它方案），也经过了很多权衡，不细说了。现在上线的这个版本，功能极其简单（或是简陋），基本设计也还有不少不足，这是为了能够早点接触用户，因为时间更宝贵。接下来我们会遵循以下的 insights 来设计和完善产品：1、移动端的社群产品，设计上要足够轻量；2、移动端的社群产品，在文字之外会有新的内容生产方式、传播方式和消费方式；3、移动端的社群产品，入口会变得多样化；4、移动端的社群产品，互动的重要性高于内容的价值性。假以时日，当走过某个阶段后，我们会尝试将这个社群产品从游戏，扩展到更多兴趣领域，直至覆盖全兴趣。至于是否真的能够成功……未来的事谁知道呢，我们都不是上帝，尽人事、听天命，足矣。时代在发展社会在进步，但是人们的需求不会改变，改变的永远是满足需求的产品，我相信社群产品的价值和它的未来（详见我的豆瓣小站：
不过还没写完），虽然前面还有巨大的未知地带，虽然周围都是探路者的尸体，但这种摸黑往前爬的感觉真的非常刺激，因为到处都弥漫着人类开疆拓土的原始本能。—————————————————————————————————————最后想说的是，我们 非·常·缺·人 ！无论是产品经理、设计师，还是运营人员，无论你是前端后端还是移动开发，无论你是自荐还是推荐，只要是对移动时代的泛社群产品感兴趣，都欢迎来投递简历，我们一起玩 &(_ _)& 投递地址是hi.成功入职即送
WiiU / PS4 / XBOX ONE / Google五儿子 / iPad / PFU HHKB Pro2 任选其一!
我看这条路还是比较难走的。理由如下：1. 豌豆荚的产品形态在用户的心中，他一直是做分发的。而且豌豆荚大量的用户是没有豌豆荚账号的，用户使用豌豆荚的目的不是来游戏社区，而是下载。下载完了，用户会转入到游戏中去消费，用户继续留着豌豆荚游戏社区理由不成立。不能说用户下了某个游戏，就能很快将下载某个游戏的用户都拉到一个这个游戏的社群里面。2. 游戏社区也是SNS的一个形态，我们说SNS有三层，用户属性、关系链、内容和应用。游戏社区应该算一个内容驱动型产品，做内容SNS需要持续有高品质内容的产生，内容的产生需要高素质的游戏用户愿意在豌豆荚进行原创和分享，在移动设备上，这个真的太难。3. 在关系链上，游戏的关系链是经过了长时间在游戏中形成的，或者是其他关系链型产品导入的（比如微信、QQ）。豌豆荚做为一个可以说是没有关系链的产品，要做社群，想仅仅通过下载就形成关系链，几乎很难看到成功的可能性。也许游戏的关系链会输出，但他们会选择输出在其他关系链强的产品上，不会回流到豌豆荚这样的分发产品上。
这是一个必然的趋势。首先，豌豆荚产品是什么定位？平台！在互联网时代，不是平台性质的感觉都挺凄惨的，渠道要钱，推广要钱，各种要钱，而一个平台节省的成本不要太多…平台可以实现聚集用户，提供给用户足够多的选择。豌豆荚做游戏社区也是基于这个目的，希望能够增加黏度。今年有太多的人都在做手游媒体，也就是游戏社区，腾讯在做，金山在做，还有很多创业的公司都在做，不过我觉得做得起来的没有一个，原因如下：1：手游开发周期短，生命周期也同样如此，做社区是个慢热过程，聚集用户到让用户记住社区的这段时间足够一款手游从火爆走向死亡。2：有个玩意叫贴吧，人流量大，妹子多，创建速度快得一b，有了优先选择为嘛要选择一个没什么人的社区？端游聚集人气靠激活码，手游靠什么？3：手机这玩意敲字本来就不容易，本身就让用户有阻碍感，用户都是碎片时间用户，手游这玩意也是多看少操作，尽量傻瓜化，这样玩意有什么可讨论价值？
外部压力：豌豆荚、91、360手机助手都是以PC端为核心的手机助手，有移动端但移动端在现有竞争格局下只能依赖自有pc端导量。而现在小米、oppo、华为等随着价格战的进一步加剧，必然更加重视从手机的服务中获取收入，而应用商店又是眼前的金矿岂有不挖之理。而手机厂商做应用市场有着天然的优势，假以时日必然将360、豌豆荚等驱逐出去。这对助手们简直就是釜底抽薪。内部动力：因为外部因素不能攻就只能守了，把现有用户通过多种手段粘住就成了这类助手们的头等大事。豌豆荚此前已经宣称转型移动内容搜索，估计效果不大，现在优酷、乐视、搜狐都是全网搜，通过内嵌的浏览器直接提供别的视频网站的内容，根本没必要跑到豌豆荚里搜，至少我是一次都没用过，哈哈。搜别的内容的路走不通，用户还是只下应用找游戏，那个与核心需求相近的功能来试试。自然就想到了游戏社区的事了。
现在几乎每个手机游戏分发平台都有考虑过做手机游戏社区这个事情，比如360在前些时间做过一个游戏盒子的项目，后来数据不好停掉了。我认为主要是几个方面的考虑吧：为了抓住游戏公会：公会对于游戏发行来说，是一个快速拉高付费用户数量和充值金额的方式。中国最早做手机游戏公会的是当乐，后来当乐相关的很多人去了UCweb的九游和百度多酷，所以目前市场上在公会这个方面竞争最厉害的就是UC和多酷两个公司。360和豌豆夹等都想过用类似的方式拓展业务，但是实际操作过程也是非常困难的。拿UC来说，公会运营已经是非常成熟的一个体系，围绕在UC周围的公会人员也有几百个，不少公会可以每个月贡献500-1000万的流水，很多游戏UC给公会的价格折扣很低，有的甚至可以到4折左右，首冲等还可以到3折。公会确实给UC和多酷的手机游戏平台业务占了相当大的比例。公会需要有一个社区的产品形态来招揽用户和交流。用户交流的需要：这个点上，我自己始终认为是个伪命题。用户为什么需要一个手机游戏交流平台的角度我就不说了，楼上很多人都说过。下面主要说说这个事情为什么不可行，仅限个人看法：形成一个垂直社区的前提是需要有相当数量的人，对于一个问题可以保持相对长的热度和时间，另外这个问题也就是讨论的主题需要有一定的深度，用户在讨论过程中，形成了一定的社交关系。现在除了豌豆夹还有很多独立做手游社区的公司，我个人都是看衰的，主要是：在端游时代，可以出现17173是因为，很多端游产品一群用户一玩就是好几年，这种忠诚度是手机游戏产品很难比拟的。手游行业用很短的时间走完了页游和端游的行业发展历程，又是手机游戏行业的特质决定了绝大多数的游戏生命周期都很短，而且产品深度不够，热度衰减很快。大家打开几个现有的手机游戏论坛看看里面的内容就可以知道，真正有价值的讨论内容很少，大部分内容都是涉及资源的，比如来拿礼包，获得奖励等等。很多手机游戏论坛产品的数据其实都是靠资源来拉的，用户拿完资源以后，其实不会真的在里面讨论什么，用户很难真正形成社区。也许这就是为什么楼上说的，在手机游戏行业没有出现类似17173的强势品牌的原因，核心在需求上。
只能说从商务角度来说，虽然和豌豆荚等产品接触不多，也是混迹在应用圈，但是侧面了解到，从游戏分发角度出发，豌豆荚似乎在游戏分发这方面，所占的市场份额并没有在应用类那么明显的优势，有朋友说是属于第二梯队。当然，这个和豌豆荚自有的风格有关系。和360
百度（91系）、应用宝三家比起来，360和腾讯强大的流量入口，百度（91）多年的积累，在引流量方面，豌豆荚似乎缺少过硬的流量入口，因此，开发自己的游戏社区，对于增加流量入口（毕竟无线就是玩流量），增加豌豆荚本身的分发能力，有着一定的作用。虽然去年市场分发排名豌豆荚第三，但是，以应用本捆绑腾讯旗下全部游戏应用首发的推广方式，想进入前三是分分钟的事情。想办法增加流量入口，吸引用户，是不得不做的一件事情。个人看法，班门弄斧之处，见谅~
在所有豌豆荚提供的内容中，游戏论坛以各个游戏为单位，的粘性相对最高，活跃度也高，还可以交叉营销。有粘性就有回流，有回流就有活跃，有活跃就有下载，不是吗？为了玩好游戏要去论坛交流找攻略的用户是高质量用户啊～而且不只是豌豆荚，应用宝也在策划这个事儿
借用我们老大的一句话——在当前的游戏市场竞争格局下，平台的力量大于渠道，渠道的力量大于媒体，媒体的力量大于内容。解释起来，就是facebook、微信这样的平台，因为有社交关系，有超高流量，对用户的影响力大于豌豆荚、91手机助手这样的分发渠道；豌豆荚、91手机助手这样的分发渠道，对用户影响力大于口袋巴士、着迷网这种手游攻略媒体；最后，由于目前市场上大量的手机游戏内容生产同质化，媒体总体的话语权对玩家影响力大于游戏本身，尤其是在游戏刚刚上线，知名度不高的时候。所以，豌豆荚作为渠道层面的代表，会拼命往平台方向延伸，并且把自己下载工具的流量，转化为真实的用户ID，做成类似Steam的东西。（不知道啥是Steam的网上搜搜呗）
看到豌豆荚除了应用之外，还能搜索视频。就隐隐感觉这厮开始抢移动入口的野心逐渐暴露了。。。游戏也是同理吧？
大家的答案都好宏伟。1.为什么要做？目的：提高手游的分发能力，因为手游分发挺挣钱的；那如何提高手游分发能力，无非就是把游戏的下载量、下载用户、人均下载这个数据搞上去嘛，那方式就有很多了，做社区做内容只是其中的一种手段而已，产品形态发展到现在就必然进阶到如此了（豌豆荚早就在做用户的profile页、看好友在玩什么，这些已经是社区了），一般的人工运营页、分类、搜索、猜你喜欢等等推荐方式都做过了嘛，总归想点新法子嘛~~另外，社区其实是有服务的概念在里面，传统的商店模式是：生产-&发现-&下载；现在多了一环：生产-&发现-&下载-&服务（反馈/讨论），算是形成了一个闭环，因为社区的内容是可以帮助生产者改进产品的；2.能不能做起来？不知道，真不知道。
难度太大，1 手游轻度，导致游戏后服务需求偏轻度，尤其是国内流行的游戏类型，很多挂机刷刷刷充值就完了。2.手游生命周期偏短，大多数游戏很难聚集人下来就散了。3.流量持续来源是个问题。但是，对于平台来说，这一块或多或少可以增加粘性，至少从讲故事来说还是很有意义的，实际作用个人觉得寥寥。
3g（game、gamble、girl）爱好者，在互联网人流中付费率最高，也就是用户质量最好！girl这个被微信、陌陌这些社交app攻占了；gamble的话，大陆不可能大张旗鼓地做；game嘛，有做分发平台了的，但全平台的社区化仍不足。但我相信，豌豆荚根本没想过以这种方式把game作为盈利池。主要看中的还是以game的名义，聚集用户呗~
社区社群可以做，但不是传统的做法。你想想，除了给亲人朋友发短信，以及花个时间在手机上打字也只有微信QQ这样强关系链的产品值得用户去做。移动端玩内容等于给自己添堵，手游互动还是礼包活动这种简单粗暴靠谱。兴趣图谱的关系网还是太弱，当然弱有弱的玩法，就看能不能创造这个需求出来。
平台上来讲，uc已做的很完善，豌豆荚会不会借鉴uc的玩法？
正在做游戏社区，不明觉厉，每个公司做的目的都会有偏差。至于做不做的起来，对于作为围观的群众来说，希望能够做起来吧，因为我们外人对于这个问题真的无力分析，外界的任何因素都不应该固定到某个公司的某个产品，如果非要从市场来说，现在这类社区何其多，谁做都合理，至于能否做起来，只能送上衷心祝愿了
用户对豌豆夹的认知已经定格为应用分发中心了，如果做游戏的话，建议另起一灶，做些关联，否则只会破坏豌豆夹的品牌影响力
现在游戏实在是太多了，人很更容易相信朋友的推荐，社区就是为了打造的这样的一个熟人体系吧。简单点说就是我朋友在豌豆荚上下载了某款游戏并参与了排名，我发现了以后我也想试试，看能不能比他的排名更高。
仿制 Google Play ， 没错的。用户对豌豆夹的认知已经定格为应用分发中心了，如果做游戏的话，建议另起一灶，做些关联，否则只会破坏豌豆夹的品牌影响力
这种明显的是目光短浅啊 .... " 应用分发中心 " 是自我设限。
已有帐号？
无法登录？
社交帐号登录}