社交游戏框架讨论及其基于Django的方案介绍
2009-12-14 01:14 Tower Joo 阅读(5402) 评论(21) 编辑 收藏 举报社交游戏框架讨论及其基于Django的方案介绍
本博客所有内容采用 Creative Commons Licenses 许可使用. 引用本内容时，请保留 朱涛, 出处 ，并且 非商业 .
点击 订阅 来订阅本博客.(推荐使用 google reader, 如果你的浏览器不支持直接订阅,请直接在 google reader 中手动添加).
点击 下载pdf阅读 (如果浏览器不支持直接打开,请点击右键另存)
摘要
社交游戏是新出现的一种新型的基于浏览器的游戏形式, 通常具有简单, 易玩, 互动性高等特点.
本文主要简单介绍了下社交游戏的一些基本知识, 并且探讨了两种不同的架构方式,最后 简单谈了下基于 Django 的社交游戏框架的思路和实现.
引入
"今天你偷菜了吗?" 当这句话成为隔壁大妈每日的口头禅时, 你就能够设想出来这款游戏的火爆程度.
自从<<开心农场>>开始风靡中国的 开心网 , 人人网 , QQ 时, 五分钟 (开心农场的开发公司)也在 facebook 上取得了一定的成就.
近期我也踏上了 social game 的这个行业, 并在游戏的架构方面做了一定的工作, 这篇博文会在大的层面 和大家探讨下 social game 游戏的架构设计(本文不会细节到出现商业机密泄露的程度, 请不要向我索取 游戏框架的源代码.)
背景介绍
什么是社交游戏? 这是我们首要了解的问题. 我给出的定义是: 社交游戏是基于社交平台( facebook , 人人网 ) 的相关资源(好友关系等)之上建立起的以用户互动为基础, 以购买道具或者植入广告为赢利模式的 网页游戏.
从全球的行业来看, 世界上的巨头有 playfish, zynga, 中国的开拓者有 五分钟 等.
社交游戏是最早出现在 facebook , myspace 这样的SNS网站上作为独立或者由网站自己开发的小型游戏(相比 于传统网游), 到今年 五分钟 成功地将开心农场做到极致, 社交游戏才为中国的网民所熟知.
如果你了解 EA 花了多少钱收购了 playfish , 也了解 zynga 和 五分钟 的季度收入, 你就会知道目前这个市场有 多大.不妨去google下吧.
与传统网游相比, 社交游戏有如下几个特点:
- 用户互动性高
- 用户归属感强(通常是自己圈子里的好友)
- 用户沉溺的可能性较小(当然更多取决于个人)
- 准入门槛较低(不需要太多的烧钱)
- 平台分成很高(像 facebook , myspace , 人人网 的分成会占到整个游戏收入的很大一部分)
- 迭代开发周期短(更好地响应用户的需求)
了解了社交游戏的基本的知识,我们来看本文的重点: 社交游戏的架构.
社交游戏的架构
因为社交游戏是内建于sns平台的一种应用,所以,它需要依赖于整个sns平台, 会调用sns平台的API, 整体架构如下:
上面架构图是基于 facebook 的, 人人网 与 facebook 的架构完全相同(基本上是完全拷贝).
下面的讨论中会主要集中在上图Your Server这个模块的架构, 与sns平台的接口的通信可以参考特定 平台的相关文档.
另外社交游戏是一种网页游戏, 所以它具有网页游戏架构的所有特征.
通常社交游戏有两种技术方案, 一种是前端基于flash, 一种是前端基于javascript, 后端可以任意选择 技术方案, 如PHP, java, Python 等.
从目前来看, 基于flash的架构方案因为其良好的用户UI和较好的用户响应在整个市场上占据更多的 份额,如<<开心农场>>等. 但是因为flash容易被破解, 所以通常很容易会被后续公司所克隆.
基于flash的架构方案
此架构方案比较重要的一块是 AMF , 这是flash的一种通信协议(二进制), 主流的后端语言都对这种 协议有支持,如 pyamf (for Python ), AMFPHP (for php)等等.
而 AMF 是一种RPC的调用, 后面提到的基于javascript的方案可以认为是REST的方式, RPC和REST的差别 可以参考 Web Service实践之REST vs RPC.
这种方案需要重点强调的是关于flash通信加密的问题, 记得不久之前园子里有人写过开心农场的外挂. 所以 安全性是很重要的一块内容.
可以参考的文档有:
- Flash应用安全规范
- How To Decompile Actionscript Code In Swf (了解下如何被别人反编译也是预防基础)
- 关于flash封装JS代码的一些TIPS
基于javascript的架构方案
相比于基于flash的架构方案,这种方式最大的不同是前端与后端的通信使用的是ajax/json的方式, 每次通信都是异步地使用ajax来调用后端的RESTful的URI, 并且使用json作为通信交互数据格式.
这里面需要注意的几个问题是:
- 安全性(来自前端的请求都是需要在后端验证的)
- 性能(优化ajax请求,对于静态的内容只请求一次)
- lazy loading(尽量将请求后置, 只有当用户真正请求时才去load)
基于javascript的方案可以认为是REST的方式, RPC和REST的差别可以参考 Web Service实践之REST vs RPC.
两种方案的比较
用户体验方面
目前我们的项目同时有两种方案的产品在研发之中, 相比而言, 对于一个新立项的项目, 我更倾向于使用flash, 因为 无论是从用户体验等各个方面,它都有更好的表现, 而且这种简单易操作的界面通常能够更加赢得用户的青睐.
但是通常第一次的load时间会比较久(或者可以称其为pre-load的一种思路).
技术层面
但是如果单就技术层面而言,我更加倾向于使用javascript的方式, 基于REST的架构在扩展性方面会有 更多优势.
关于Django的后台方案
最后我再谈谈,基于 Django 的后台解决方案.
使用 Django 作为后台的方案有如下的好处:
基于 Django 简单地进行一些封装,使其更加适合社交游戏的开发, 如何封装, 就看个人的 经验和能力了. 祝好运!
结论
文中没有提到一些比较隐私的数据,当然这些数据你也能够从某些途径获取(如收入, 和平台的 分成比例等), 也没有谈具体的架构细节(我希望某一天可以开源和大家分享), 但是整体的架构思路应该还是很清楚的.
作为一个优秀的社交游戏产品,无论 前期的游戏策划 , 中期的游戏开发, 和 后期的游戏推广 ,各个环节的 成功才能铸就一个成功的游戏.
当别人问你"今天你偷菜了吗?", 我则想问 "今天你了解social game吗?"
期待和朋友们交流.
后记
后面可能还会谈一些关于社交游戏安全性的一些内容, 所谓 防人之心不可无, 害人之心不可有, 防范的工作还是要做好的.
