断断续续开发了近半年的游戏终于在Dena上成功上线了。运行两个月以来，注册用户也超过3000了。小小得意一把。经过和设计人员一起工作，对于社交网络游戏，也从单纯的技术，体会了一些游戏的要素。
1.需要什么技术
Dena使用的是Google Opensocial的平台，其API也基本和标准Opensocial一样。所以，今后无论是在Dena开发下一个产品，还是移植到国内支持Opensocial的网站（如校内网），在理论上都是相当方便的。
对于Opensocail的应用开发，主要是两种，一种是基于REST，通过OAuth认证实现第三方服务器上的应用，貌似地嵌入社交网站网页。另外一种，则是使用Javascript，Flash等，直接嵌入到社交网站中。除了实现方式不同，对于负荷也有很大差异。前者，需要在客户，社交网站，第三方网站频繁接力，而第三方网站需要用到社交信息，还需要在后台发出REST请求。而后者可以大大简略，在客户端和社交网站之间就可以直接完成。显然，对于规模较大，页面较多的游戏，比较适合。而后者，单一页面，简单游戏（想偷菜一类）就最方便了。
我们的游戏是一个简化版的网游，所以使用的是前者。这也带来了负荷的瓶颈，所以需要其他技术的辅助。
对于此有两方面的思路，
一个是内部系统的优化，包括负载平衡技术，系统缓存技术，数据库镜像等。目前实际的情况是，一台硬件负载平衡，一台静态素材服务器(Nginx),三台动态网站服务器(Apache)，一台系统缓存服务器(Memocache),三台DB服务器（一共是四个实例， A_100%写 B_20%读 C_40%读 D_40%读，其中A,B共用一台）。
对于社交网站的用户Avantar,nick name等，如果每次通过OAuth+REST向社交网站请求，社交网站会崩溃，我们的服务效率也很慢。但是这些保存到缓存，又牵涉到客户数据，像Dena就要求最多缓存24小时。当然就算Dena不要求，也是需要选择合适的缓存刷新频率的。太快，Cache的效果不明显，太慢，会导致缓存垃圾数据过多或者数据陈旧。目前做法是，社交网站的个人信息保持24小时，游戏固定内容（比如关卡数据等）保持一周（另外也提供专门的API刷缓存，实现版本数据更新），还有一些特殊，客户会修改的数据，实现修改数据的时候更新缓存。
另外一种思路，是先用最低配置，随着负荷提高，方便的服务器扩充。我们这次租用的是Amazon。另外可选项，像Google,Azure也不错。
2.社交游戏的要素
我们的游戏内容本身很老套，有角色选择，战斗布阵PK，宠物练级，地域探索，装备物品，合成物品，接受任务等。这些基本游戏功能不再详述，谈一些社交游戏特有的要素
1）工会组织 对于网游，工会组织是一个重要概念。它可以很大的提高集体活动的趣味性以及玩家的成就感。我们提供了玩家自定工会，并可以邀请其他人加入。
2）互赠礼物 和现实社交一样，互赠礼物，发送消息也是必要的。
3）朋友邀请 为了尽快提高用户群体，必要的朋友邀请奖励是个好方法
4）信息交互 像BBS这种，也是让不熟悉的玩家变得熟悉的好方法
5）商品购买 时间所限，我们没有完成玩家互相的买卖，但也从单纯的买卖中，加入了投资的概念，强化了卖出行动。在Dena中有Gold和Mobile Coin的概念。Gold是我们自己管理的，而Mobile Coin则是需要实体货币充值。简单可以比作欢乐豆和Q币的关系。玩家有很多种，比如会有愿意直接购买Q币，获得特别道具的。也有喜欢自己获取，反感直接用实体货币购买的。程序设计上，既要让前者能够享受到VIP的对待，又要让后者不能感到到处碰壁。
6）审查制度 Dena提供 Check NGWords的API。并且要求对BBS这种玩家可以自由输入的，一要做NGWords的Check，二要把信息保存到Dena服务器上，以便随时审查。我想如果移植到国内，应该审查更甚吧。
3.写在最后的
一个优秀的游戏需要自己的特色，从这点来说这款并不优秀。但是其实再简单的功能，为了提高游戏性，都需要反复推敲。很多方面超过了我们能力所及，所以邀请了专业的游戏设计师帮忙调校各种参数。而像故事情节，角色定义，收获道具的Flash动画特效等等，无不在细节去提高用户体验。而在做游戏过程中，大块大块的删除，修改功能也比通常开发多得多。所以，这有需要更多的耐心和勇气。另外，刚上线那会儿，到处是恶意修改URL寻找漏洞的，所以千万不要小看玩家，里面藏龙卧虎的，一定要用完全的方式来严谨的设计。