博客园-Minds book of my CS Road

Linux下使用PPP上网

Sat, 13 Nov 2010 23:31:00 +0800

家里的上网是用运营商的宽带,需要连接宽带,win下傻瓜式地就完成了,mac下也很容易地,

到了我的xubuntu,则大致会复杂一些,记录如下,以备忘.

启动拨号上网

初次时

# sudo pppoeconf

根据设置提示,一路进行即可(在xubuntu下成功配置)

后续时

使用plog来查看状态.

如果启动失败,则可sudo poff (-a) 如果有多于一个则需要-a,

然后sudo pon dsl-provider启动即可.(在xubuntu下成功配置)

本文链接

折腾Amazon Web Service(AWS) Free Tier

Sat, 13 Nov 2010 12:35:00 +0800

老早就知道amazon从11.1起就推出试用一年AWS服务的，到了1号也就兴冲冲的去注册，去折腾，不过最后因为信用卡没有验证通过就此暂时搁置，不过，这也扣掉了我1刀。

今天没事，也想着重新来申请下，于是又去要求amazon来验证我的账号，这又扣掉了我1刀，不过，还好总算是通过了，于是也就根据这篇博文中的内容创建了一个instance，如果你想要折腾下amazon的服务，这篇文章可是必读。

因为我们公司也使用amazon的服务，所以登录配置什么的还是一切顺利，不一会儿也就搭起来了一个Django的小demo,为后续自己的继续折腾做好准备。

最后简单说下需要注意的事项：

美国西部的服务器应该是比较靠谱的（我后续的使用主要是面向美帝），从国内还是非常快的，我的ssh访问基本没有延迟
获得登录的key pair时注意登录时要用ec2-user作为登录名，而非root，linux下的ssh用下载的pem文件即可，如果在win下则可使用Puttygen来转换为Private key来登录
登录后，使用sudo可以获取root权限
因为是redhat(fedora)所以yum还是很好使的，记得yum search/yum install就没有什么大问题
当然还是要注意流量的，否则超出免费的部分amazon会从你的信用卡中扣钱的

那么AWS究竟能干些什么？

翻墙（具体putty和ssh怎么翻，网上一大堆）
跑跑web应用
折腾目前最好的云服务
向别人炫耀（囧）

你不妨也去折腾吧！

EDIT:

据说Amazon在验证信用卡时只是冻结了1刀，而非扣除，在验证通过后会解冻。当然我还没确认，确认后再更新本文。

参考：

本文链接

关于MySQL的实战一：基本的注意事项

Fri, 12 Nov 2010 00:58:00 +0800

最近一直在和Mysql的调优打交道，遇到了不少的问题，一些和自己预期的不太一样，当然一些性能上的问题甚至导致游戏当机了若干个小时，在不断的学习和总结中对Mysql也有了一定的熟悉，无论是在数据库层面，还是在应用层面都有了更深的认识，不防记录于此，供朋友参考和自己备忘。

此篇是基本篇，是在实际中遇到最常见的问题。

一、数据库层面

对于像游戏的这种heavy write类型的数据库，InnoDB是更优于MyISAM型的，所以在开始不妨将数据库的引擎设置为InnoDB，至于InnoDB与MyISAM的区别，可参考文档。

除此而外，在设置数据库的buffer时也不能太大，例如我们的亚马逊服务器是8G内存我们设置了2G作为buffer，而connection数也不能太小，1000左右基本能够满足一般的并发要求。

在实际中可能还会遇到，例如出现 “InnoDB: Error: cannot allocate 2147500032 bytes of…”而不能启动mysql，则说明mysql设置的buffer太大，将其调小就可解决。

有时也会出现，“Incorrect key file for table '/tmp/#sql_4681_11.MYI'; try to repair it”这样的错误，这是因为/tmp/目录已经磁盘满了，无法写入，通常可以将mysql的目录指向一个大一点的磁盘区间即可。

如果你的应用和我们类似要支持像德语这样的字符集，则Mysql最初就必须设置为utf8，否则后面你会死的很惨（大堆的问号？？？），最好在配置文件中已经设置好。

最后就是要时常的备份数据，信息化社会的今天，数据是最重要的，备份以保证数据的安全，从而避免可能出现的数据丢失等。

二、应用层面

应用层面如果用一句话来概括，即是：对于并非紧急重要的查询，可用简化的查询来实现逻辑上的替换。一个实际的例子是我们最近10W用户的PopCool,它是一个挑战类竞技游戏，其中有一处的逻辑的最初设计是显示最新的10名玩家，因为我们用户的挑战记录在Game表中，用户的信息在Player表中，并且Game表中分别有指向Player表的两个外键，所以最初要实现这个逻辑的查询为（取自slow query）：

SELECT `games_game`.`id`, `games_game`.`mini_game_id`, `games_game`.`user_a_id`, 
`games_game`.`user_b_id`, `games_game`.`score`, `games_game`.`challenge_time`, 
`games_game`.`is_challenged_back`, T3.`id`, T3.`sns_id`, T3.`name`, T3.`sex`, 
T3.`img_url`, T3.`status`, T3.`level`, T3.`top_score`, T3.`top_score_level`, 
T3.`coins`, T3.`neighbor_num`, T3.`last_login_time`, T3.`reg_date`, T3.`last_bonus_time`,

 `player_player`.`id`, `player_player`.`sns_id`, 
`player_player`.`name`, `player_player`.`sex`, `player_player`.`img_url`, 
`player_player`.`status`, `player_player`.`level`, `player_player`.`top_score`, 
`player_player`.`top_score_level`, `player_player`.`coins`,
 `player_player`.`neighbor_num`, `player_player`.`last_login_time`, 
`player_player`.`reg_date`, `player_player`.`last_bonus_time`
 FROM `games_game` INNER JOIN `player_player`
 ON (`games_game`.`user_b_id` = `player_player`.`id`) 
INNER JOIN `player_player` T3 ON (`games_game`.`user_a_id` = T3.`id`) 

WHERE (`games_game`.`user_b_id` = N  AND `games_game`.`is_challenged_back` = N 
 AND NOT (`games_game`.`user_a_id` = N ))

上面的SQL显得有些冗长，但是不难发现有两个INNER JOIN连表操作，当Player表有10W+数据时，查询的效率可想而知。于是我们做出如下的调整：我们使用最近登录的10个用户替换之前的10位最近玩家的信息，于是查询就变成了：

Select player_player.name, …, from player_player order by last_login_time DESC limit 10;

而其中并不涉及连表操作。当然请注意，使用的前提是：不影响产品的整体功能和用户的体验，对于此例，最新用户显示的只是供当前玩家挑战的可选玩家，所以求其次的最近登录玩家并不会影响用户的体验。

推而广之，产品的实现可不用过于拘泥于产品的设计，合理的平衡二者能够起到意想不到的效果。

P.S 因为这个改变，游戏玩家的反应好了很多，游戏的响应和速度有了明显的改善。

另一方面，在应用层面，要尽量使用整形而非字符型，同样是我们的PopCool,因为我们游戏所处的是VZ,它的用户id是20位左右的字符串，所以，我们最初在查询时使用的是这种字符的匹配，而后面的优化时，因为我们的自增主键id是整形，我们对于同样的查询使用整形后，查询的效率有了明显的提高。

另外，在应用和数据库之间可使用Memcached来进行缓存，Memcached的操作是比较容易的set,get,delete等，但是设置一个好的过期时间显得比较重要和需要技巧，如何既能保证数据的有效性又能尽大可能地提高性能，这通常需要你对自己的产品有十分深入的理解。我们的PopCool中涉及到排行，而排行对时间的要求并不高，所以我们设置期过期时间为1小时，基本算是比较恰当的了。

凡此等等，要注意避免一些常见的慢查询，当然使用slow query和explain来分析也是非常重要。

最后，不妨可以阅读下MySql performance tips以避免常见的性能问题。

本文链接

骑行沙河

Sun, 29 Aug 2010 20:12:00 +0800

原本的十三陵打折成了沙河，那倒也不妨碍什么，因为同是水库，因为名气的不同，这个应该人会少很多吧，所以鉴于路途原因也就走到了这里。

沿着京藏高速（G6）骑着我那破旧的自行车悠闲地骑着，说是悠闲是相比于每天早上骑车上班时的速度和紧张，不远不近，一会儿也就到了。

不知道路，但循着网上的说明也算是进来了，一路望去是绿色的死一般的水，还有那一望就到尽头的河。路是沙石的，走起来不是很舒坦，但一想这么小的地儿，也算是一个水库？

说是，已经拐了个弯，这才发现自己受骗了，前面竟是曲折的河道，一时也看不到尽头是哪。沙石路更难走了，这时旁边有正在植树的人（我本是想在人前面加个词的，或者将人改为另一个词，但竟也想不到合适的），黝黑的臂膀，在下午的阳光照射下更显油亮；河道旁也有三三两两成堆的人，不知道在做什么。再往前走时，一旁的“黑人”在那里为新植的树木浇水，河道里的“黑人”在水管的另一头关切着什么；我走过时，那河道里的“黑人”不注地盯我看，我每次冲河道看时都能看到他的眼睛，那刻我想那“黑人”也应有个和我一般大小的儿子吧，那儿子也应该在上大学吧。我的父亲呢？他也同样的，假使被河道中“黑人”的儿子看到了，也会称为“黑人”吧，当然父亲除了黑还有那白，那是头顶那稀疏的白，而这白是被母亲讽刺过很多次的，母亲总说我的头发可别跟了父亲了。父亲属龙，算算今年59岁了，也算是人生的末期了，倘若天上某个神在每个人去世时来给此人总结时，我想父亲的总结会很简单，连一页都用不了，简单的就像我此刻面前无数的荷叶中的一支，不曾开过花，冬天到了便死去，只是很用心地生成了莲子，于是有了我。

我思绪很低沉地走着，又一个弯，竟然看到了水里的水鸟，或许是鸽子吧，至少很像，一纵而过，在离水面不远的地方。我吹了声口哨，于是若干只水鸟也就飞起而过。路开始好了许多，当然还是沙石路，车子在其上沙沙的，耳边是知了的声音，我开始唱歌，蓝莲花、知足、海阔天空……。

路开始向入口的方向蜿蜒，我在马路不远的一处停了下来，这地方是不错的，面前是朱自清口里所谓田田的（什么叫田田呢？）荷叶，还有浓重的荷花香，我坐在草地上开始码自己的心情。

下午出发之前，在微博上说了句，“下午要去十三陵”，如此看来，凡是看到的朋友都是受骗了；当然我依旧对十三陵充满着一些憧憬，那时，我想这种快乐我不能独享，定是要带着我的老婆的（准），这无比惬意的风，还有浓烈的荷花香。

本文链接

关于Social Game的两个调研报告

Sun, 29 Aug 2010 12:47:00 +0800

在昨天的阅读时间里，下载了两个比较有意义的文档，一个是CNNIC的《2010年中国网页游戏调查报告》，一个是PopCap的《2010 Social Gaming Research》，二者都对Social Game领域进行一定的数据分析，所得的数据也相比于小公司的个人数据总结和一些媒体的数据预测更加有意义些，所以本文就简单对这两个报告中的一些结论加以列举和分析，希望对一些从业人员会带来帮助。

首先看到的是PopCap的报告，这个调查报告的目标有几个：

Social Game玩家（定义为每周至少玩一次）在互联网用户中的比例（美国和英国only）
Social Game玩家的行为和偏好
建立起一个典型Social Game玩家的特征

调查方式是采用对1202个美国和英国的在线用户进行在线问卷调查，其中被调查对象为每周至少玩15分钟游戏的玩家。调查时间为2010/1/7-2010/1/12.

根据这些调查目标，该报告得出的结论包括：

用户特征方面

24%的互联网用户每周至少玩一次Social Game
55%vs45%的男女玩家比例
用户的平均年龄是43岁，20%是30岁以下，21%是30-39岁，20%是40-49岁，而剩余的38%是50岁以上（其中，美国用户的玩家平均年龄更高）
生活状况方面，单身无小孩的用户占28%，孩子在家的已婚用户占28%，孩子不在家已婚的用户占17%。
工作状况方面，全职工作的占41%，13%是退休的，11%是SOHO族，9%的兼职和9%的无职业者
学历方面，43%的美国用户接受过高等教育。
收入方面，34%的美国用户年收入小于35000刀，17%年收入处于35000-49000刀之间，21%是50000-75000刀，而23%是75000刀以上。（而美国2008年人中等年收入是52000）

一般游戏用户（包括所有游戏）行为方面

69%的美国用户在玩Social Game的同时也玩其它的视频游戏（英国这个比较更高）
在各种不同游戏类别用户所花的时间里面，Social Game占39%，休闲游戏占30%，hardcore游戏（通常是指玩家花费大量空闲时间所玩的游戏类型，如魔兽）占31%
在游戏设备上，49%依旧是PC和laptop，15%的手持游戏终端，13%的手机

社交游戏用户行为方面

玩社交游戏的年限，56%用户至少有一年的玩龄，26%少于6个月，17%是7-12个月
玩社交游戏的频率，34%一天多次，30%一天一次，31%一周2-3次
每周在社交游戏上花费的时间，33%一周花费1小时以下，38%花费1-5小时，28%6个小时以上
一次玩社交游戏的时间，23%的用户每次花费16-30分钟，27%的用户花费31-60分钟，22%花费1-2小时
玩社交游戏的原因，53%的是为了乐趣和兴奋，45%是缓解压力，43%是为了竞争性，32%喜欢这样的脑力锻炼，24%更好的和好友保持联系
在使用终端上，71%使用PC，50%使用laptop（有些玩家PC和laptop都使用），9%使用手机，三者用户之间有重叠
过去三个月玩游戏的数量的变化，35%表示增加了，10%减少了，55%保持基本相同
由于社交游戏而减少的活动，27%表示阅读时间减少，26%表示在家看电视和电影的时间减少，24%表示是上网冲浪的时间减少，21%表示减少了自己的一些爱好的活动，21%用户表示减少了运动，28%用户表示社交游戏没有影响自己的正常社交活动

社交网络使用和行为

玩社交游戏的平台：83%在facebook，24%在myspace，7%在Bebo
登录社交网络用于玩游戏目的的玩家，使用登录facebook等社交网络49%的时间是为了玩社交游戏
用户在社交网络上的时间分配，39%的时间用于玩社交游戏，15%玩非社交的游戏，17%聊天和留言等

用户玩的游戏

如何发现新的社交游戏，38%来自社交网络的广告，38%来自于朋友推荐，35%来自于正在玩该游戏的朋友的相关新鲜事等提示，27%搜索引擎
影响对社交游戏选择的因素，60%朋友的推荐，46%以前玩过的类似形式游戏，32%玩在社交网络推广的游戏
用户玩的社交游戏的数量，平均为6.1个不同的社交游戏，39%的用户玩3-5个游戏

虚拟货币

挣取，花费和购买虚拟货币，53%挣取过或者花费过虚拟货币，28%真正购买过虚拟货币
实际购买虚拟货币的可能性，32%用户表示会或者可能购买，其中9%很可能

社交游戏关系

与同一游戏玩家的关系，62%是真实世界的朋友，56%是在线朋友，37%在线陌生人
对关系的影响，1/4的用户认为社交游戏的关系会对自己的真实关系有影响
与同一游戏玩家的交互，22%玩家表示只在玩游戏时才交互，23%表示是他们与其他玩家主要在玩游戏时才交互，42%表示玩游戏时的交互只是很少的一部分交互

社交游戏对重新建立关系或者新建立关系的作用

30%用户表示社交游戏能够让他们与自己的老朋友、同学、同事重新联系，或者与陌生人建立关系

提高社交游戏用户体验的建议

增加选择性7%
创新、奖杯、奖励6%
提高游戏的趣味性5%
提高游戏质量3%
提高游戏的互动性2%
提高美术质量1%
提高可用性和易用性1%
更多真实世界的体验1%
等

在PopCap的调查中，一些真实（较小的样本可能导致与事实有一定的偏差）的调查结果纠正了我对于社交游戏的一些看法，甚至与我上篇博文中的一些观点有些冲突，觉得比较有意义的一些观点是：

社交游戏的游戏属性应该是最重要的，社交功能次之（趣味性，易玩性，社交性）
社交游戏玩家更加倾向于在特定的社交网络中玩（对平台的依赖性）
游戏互动上，玩家更多还是喜欢和自己认识的人一起交互（邀请机制需要加强）
社交游戏的玩家在游戏上投入时间较短，充值比例较低，游戏玩家年龄比我预期的略高（支付能力的提高）

下面我们再看看CNNIC的报告（此报告的全称是《中国网页游戏用户调研分析报告》，其调研的主要目标是网页游戏，并且认为社交游戏是网页游戏的一种，其它两种包括大型网页游戏和单机网页游戏）。

根据CNNIC报告中的文档说明，此次调查主要是基于1）电话调研2）二手资料研究3）专家、企业访谈，发布报告的时间是2010-5。

此次调研的主要结论包括：

中国网页游戏规模已经达到1.05亿，社交游戏用户达9209万
19岁-30岁玩家占64.5%
有收入人群比较为77.1%，其中收入为1K-3K的最多为43.7%
朋友介绍与搜索引擎是最主要的获取渠道，占71.5%
手机已成为第二大终端，达48.7%
社交游戏用户每天登录的用户比较较高，达53.5%
社交游戏中的付费用户占19.2，比例较低
网页游戏与社交网站关系紧密，如果没有游戏功能，表示肯定会离开社交网站的社
交网页游戏用户比例为27.4%
社交网页游戏用户以男性为主，占整体社交网页游戏用户的 65.3%。女性用户占比
为34.7%。

与PopCap对美国和英国的调研结果来看，不难看出与中国市场的差别还是比较大的，例如玩家的男女性比例，年龄结构，收入结构，学历结构，付费比例等。

正如CNNIC报告中分析所说：

（中国）网页游戏用户以白领为主，且有收入人群占到 77.1%，该人群拥有稳定的收入和良
好的付费能力，对网页游戏厂商而言是最具价值和付费潜力的用户群。但另一方面，这
样的人群付费行为较为理智，对付费产品的选择较为谨慎。因此，要扩大盈利能力，一
方面在于游戏内容的吸引力，另一方面需要利用用户自身的价值挖掘广告潜力，提升游
戏产品在营销中的价值。

中国的市场特征和用户主体具有一定的鲜明特征，如何吸引住用户，提高付费比例则显得十分重要了。

最后以一条新浪微博作结，昨日在新浪微博中看到的Zynga成功理论，我给了其如下的注解：

箴言！以爱情作比，第一条是所谓的第一印象，第二条是所谓的爱情维系永葆新鲜，第三是培养和建立一种良性的婚姻土壤，如此作为用户的新娘自是对你死心塌地。

@puting：根据Zynaga，一个公司的成功取决于下面三个因素： Ability to drive new users （吸引新用户的能力） Ability to create an engagement loop （互动平台的创建能力） Access to an open communication channel （开放式交流渠道）http://sinaurl.cn/G785N

本文链接

社交游戏（Social Game）开发简单教程与粗略总结之基础篇

Sun, 29 Aug 2010 00:49:00 +0800

为了使得整个系列文章的逻辑性更加严密，本文旨在介绍一些社交游戏的相关基础，当前的市场状况，发展情况，以及对未来的展望。当然文中的一些数字与表述可能不太准确，在不影响传达数字表意的前提下，读者可对数字做一些上下浮动的估量，或许会更准确些。

引入

当无数人在谈论微博时代的到来和中国SNS去泡沫化之时，依附于SNS平台之上的社交游戏也开始展露出头角，在互联网的大蛋糕上寻找着自己的那块cheese，而随着年利润达若干亿美元的zynga高调地宣称自己的玩家过亿时，大家才真正开始注意起这个不起眼的蓝海来，当然如今已是大红海了（下文会详细的说明）。

当facebook定义了SNS时，zynga也定义了社交游戏，随后便是数不尽的跟随者，如myspace,orkut，开心网，如playdom,6waves，五分钟等，当然也只有facebook和zynga赚的盆满钵满，跟随只能有残羹剩饭的份，但是那已是相当诱人的了。

与其它游戏形式的关系

那么社交游戏又是一种怎样的游戏类型，它与传统游戏、网络游戏、网页游戏有什么不同，下面对这几个问题加以分析。

社交游戏，即social game，从组词来看它由soical和game组成，game决定了其只是游戏的一个类别而已，与其它游戏类别也并无大的差别；而关键是social，也即说明社交游戏是基于社会关系之上的一种游戏新类型，其建立在依附的SNS平台庞大的用户群之上，在具有某种社会关系的玩家之间，基于一定的社交元素来保证与这些玩家之间的互动，最终将游戏的趣味娱乐性本质延展至社交层次。所以说，除了需要具有游戏本身的趣味性、娱乐性等基本元素外，将用户的游戏行为导向为社交行为则是一款社交游戏能否成功的根本因素，例如风靡的“偷菜”，许多玩家偷的已不是菜，而是一种社交目的，如暧昧，亲昵，友谊等。

当然你也许会说，网游也具有同样互动的因素呀，且不闻借某款游戏来赢得一辈子幸福的同学也不在少数哈，还有大量的公会，还有“贾君鹏，你妈喊你吃饭”，这不是社交吗？我不否认这种网游建立起的关系的存在和普遍性，但相比于建立在已有大量关系基础上的社交游戏，网游的社交性显得少了许多。试想，你去玩偷菜时，你的邻居列表都是自己所熟知的人，其中不乏自己喜欢或者厌恶的人，你不是更有欲望去他们地里做些什么动作吗？当你去偷菜时只是为了简单的得到经验和升级吗？显然，网游这方面具有先天的单薄性。总之，网游的社交性相比于社交游戏更显松弛和单薄。

同样，有很多同学或许也称开心网上的游戏为网页游戏，所以有必要区分下这两个概念。从词的范畴来说，网页游戏与社交游戏定义的角度不同，前者是基于游戏的呈现载体，而后者是基于游戏的功能目的，其从属关系可从下图简单说明。

其中相交的部分即是定义的角度相同时二者的重合关系，换句话说，以社交为目的的网页游戏即是社交游戏，而以网页形式为呈现载体的社交游戏也是网页游戏，当然，网页游戏也可只是单机版，而同样社交游戏也可出现在ipad，ps等载体上。

作为本小节的结束语，社交游戏从传统游戏的追求游戏的乐趣与娱乐的基础上，延展至追求一种实际社会关系的某种影响上，而马斯洛的五种需求层次之中的“社交需求”也正解释了为什么社交游戏会得到强劲的发展的原因。看图不说话。

市场状况

市场容量的分析通常由第三方的咨询公司来给出，这里引用相关的新闻（或者“所谓的”新闻）来给个直观的感受：

美国社交游戏的市场在2012年超过20亿美元
zynga今年收入将达8.5亿美元，明年将达10亿美元
日本社交游戏市场规模将达10亿美元
据艾瑞统计，2008年中国休闲类社交网络市场规模为1.9亿元，较2007年的1.2亿元增长64.0%。2009年达到3.7亿元，并在2012年达到16.1亿元。这个增幅是每一个淘金者都会看红眼的。

除此而外，我们可以看看下面艾瑞关于社交游戏市场规模的一些预测，虽然各个版本的数字有一定的差异，但总体趋势是相同的。

本图引用自http://www.iresearch.com.cn/View/121267.html

而在CNNIC的2010年中国网页游戏调查报告有如下一段研究发现：

中国网页游戏用户规模达1.05 亿，其中社交类网页游戏用户规模最大，达到9209
，大型网页游戏用户规模2384万，网页单机游戏用户规模3791 万。

19岁到 30 岁用户构成网页游戏最大用户群体，比例为64.5%。

网页游戏用户的有收入人群比例较大，为77.1%，其中平均月收入在1000元到 3000
的用户比例最大，占到总体用户的43.7%。

朋友介绍与搜索引擎是网页游戏信息获取的主要渠道，比例均为71.5%。

推荐朋友可以阅读下CNNIC的报告。

营利模式

社交游戏在营利上也采取与当下免费网游同样的策略，即游戏本身免费，而以出售道具或者增值产品来获得收入，当然随着游戏本身的发展相应的营利模式也在不断拓展，例如植入广告，周边产品的开发。具体可用下表来总结：

营利方式	典型示例	备注
道具出售	开心农场的道具	如种子等
植入广告	tikiisland中的可口可乐广告	还有开心网的相关广告植入等。
周边产品	泡泡鱼的淘宝店	不过似乎销售不是特别理想。

当然，社交游戏的社交性决定其必须依附于具有大量用户的SNS网络，如国外的facebook,myspace，国内的开心网，人人网等，平台商自不会看着你独自享用这样的赢利机会，于是人人网，facebook等平台相继收取30%左右分成来压榨开发商的利润空间，这也是之前不久zynga与facebook之间以生掐架的原因。

除了平台商的分成外，如果开发商使用第三方的支付系统，仍需向其提供10%左右不等的分成。

当然上面是说开发商自己开发，自己运营所涉及到的额外支出，如果开发商是通过第三方的发布商来在某个平台上进行发布（原因是开发商的人力和财力所限，或者发布商与平台商的关系等），那么发布商通常要分去50%左右的分成（如plinga在VZ上发布游戏），所以到头来能够回到游戏开发商的收入已是少之又少了。

市场发展情况

正如文首说所的，社交游戏市场已经从蓝海变成了血腥的红海，而随着EA对playfish，Disney对playdom以及zynga对若干公司的收购，整个社交游戏市场已经开始了新一轮的格局调整，在此过程中竞争力差的公司会相继出局，遗留的只能是那些有大量资源（流量，高质量产品）的开发商、发布商等。

在如今的市场环境下，大量的开发商不再试图去创新，而是所谓的“山寨”（当然我们公司也逃不出），zynga出了款挖宝的游戏，国内的厂商开始也开发；playdom出了款城市建造的游戏，国内连忙跟进，于是市场上充斥了大量的同类型的城市类游戏。更为可怕的是，其它领域在市场格局调整时的惨剧也同样在社交游戏上上演——恶性的竞争与拷贝，这点在社交游戏上更为突出。从技术角度来讲，社交游戏前端通常采用flash，而拥有网络的任一个人都可将其下载，使用反编译工具查看相关的源码，如果下载反编译的是一个公司，那么后果可想而知，原厂家用6个月心血开发而来的游戏，你（或者某个厂家）只用几周调通前端写个后端即可，当然技术的话题可留作本系列文章的技术篇中细说。

在市场不断成熟的条件下，开发商的日子并不好过，特别是话语权低的小开发商，你不断要受到平台商的无理压榨，甚至随时删除你的游戏，也要小心同行的恶意拷贝，在受尽压榨的处境下充满中成为另一个中国zynga的美好梦想，当然或许仅是梦想而已。

未来的展望

一次去中关村买移动硬盘时，发现了一个有趣的事情，我循着海龙各个商贩的展台过时，看到的是各个店员“忙时则招揽生意，闲时则偷偷菜”，甚至我询问生意的声音也没能把沉迷的店员从泡泡龙中拉出来。

市场仍在向好发展，社会对社交游戏的认可也越来越高，对于购买道具也越来越习惯和接受（应该感谢QQ的市场培育），而且购买渠道也十分畅通（各个第三方的支付系统），相信社交游戏市场在剧烈的调整下正在逐步走向成熟和稳定，并且会构成游戏中的一个重要的分支。

当然，未来社交游戏的属性也会有一定的调整，除了更少的急功近利和恶性竞争，还需要建立起一定的行业标准，以及协调与各个利益方的关系，这样整个社交游戏产业才能更好的、保持良性的发展。

最后说一个小故事，说，某一天，大家都在公司上班，为成为中国的zynga在努力，突然一个同事震惊地要我们去看个东西，原来是在人人上看到了一款与social city完全一样的游戏（叫A游戏吧），美工UI等完全相同（显然是直接拿人家的），不同的只是语言和开发商署名，我们在好奇版权问题时，这时一个同事冒出个句，“人人网是山寨，A游戏也是山寨，山寨上的山寨，山寨中的山寨，严格的审核不是自己抽自己？”于是我们大呼经典继而继续努力。

最后附一张世界sns的布局图，当然或许太过粗略，也不完全符合实际，但是欣欣向荣的形势还是看得见的。

本图摘自http://www.mapsofworld.com/images/world-social-network-map.jpg

更多参考

本文链接

社交游戏（Social Game）开发简单教程与粗略总结

Sat, 28 Aug 2010 18:43:00 +0800

这系列文章原名是《社交游戏（Social Game）开发相关教程与总结》，但在看过@唐彬森、@侯锐等社交游戏一线的打拼者时，自己的总结肯定是粗浅的，体会也是表面，所以更为了现在名字。如果您是在该领域有半年以上的经验，你大可直接跳过本文。

加入社交游戏开发的这个领域也已经快2年了，期间也在项目的开发、运营、推广等方面亲身从事着一些工作，接触了部分业内的成功人士，同样也遇到了数不尽的问题，从绕弯中学习提高效率，于是心生出要总结下相关的开发等方面的经验，一者是对自己过往的总结与反思，另者也为其他相同领域的同仁作为交流之资。

那么，显然一篇是谈不完的，所以会分为若干个部分，逐渐呈现出来，初定了如下几个方面的内容：

基础篇
开发篇
1. 开发基础教程
2. 与平台的结合之facebook
3. 与平台的结合之opensocial
4. 部署与性能调优
运营篇
推广篇
心得与体会
补记

当然在行文过程中，可能会对部分章节做出调整，毕竟当下对未来的计划总不是最优的，只有当有实际的上下文时才会知道是否有调整的可能和必要。

上面就是一个引子，引出未来计划要完成的一些博文内容，当然也会成为一个索引性的文章，后续本文也应该会置顶，期待和各个朋友交流与沟通。

最后，做个小广告，我们公司在清华东门外的东升大厦，正在大量吸纳相关的优秀人员，如果亲爱的朋友你有兴趣，不妨将你的简历寄给我，我们一定会给予足够的重视，希望在这个“圈地”时期的产业里也有你的身影。

本文链接

我们的游戏终于回来了

Thu, 26 Aug 2010 21:54:00 +0800

和德国鬼子开始交涉，最终的原因是可恨的：

我们没有和他们分成（必须分他们三成）
我们没有用他们指定的支付（第三方支付也需要分成）

合约签了，支付换了，最终我们又回来了，28个小时的当机时间给我们带来的是多么大的影响，现在还很难评估，但是随着VZ上另一款city游戏的上线，竞争更加激烈了，moon city的兄弟们加油了！

分享下我的城市，呵呵。

本文链接

VZ平台靠谱吗？

Thu, 26 Aug 2010 10:35:00 +0800

从昨天晚上起，我们的游戏居然直接从VZ上被拿掉了，赤裸裸的，没有任何征兆，没有任何说明。

我几近愤怒，但也只能如此了？

当此时，我只想知道最终的原因，并保留下步交涉的权利和计划。

龟缩于平台之上的我们，只能任人鱼肉吗？

附图借用户之言表达对VZ的不满。

本文链接

Dig into code base and Refine the trac feeds

Tue, 01 Jun 2010 00:21:00 +0800

Dig into code base and Refine the trac feeds
   The passed week was very busy to me, since the graduation reply. I'm happy that I am about to graduate from the 19 years schooling career, which is really long. A new start to me, and a new start since then.

   Following the last week's plan, I went on the refinement of Trac feeds plugin and have made the following tuning:
fault tolerance

   The main work went to the fault tolerance, and the UI refinement was rejected at last since it's hard to make a balance between good UI and complex implementation.

   And besides that, I started to read the source code of touch screen. Since it's based on Django, I follow the approach of the common Django apps, i.e. urls -> views -> models->templates.

   Let's begin the journey.

core/urls.py
After digging into the urls.py, it's easy to know each installed plugins will be shown in loalhost/ or localhost/display/, which dispatches the request to display function at core/views.py.

core/views.py
To simplify the analysis, I will omit some files and logics.

Let's focus on the display function, which render the django dict variables to the corresponding template display.html. The rendered dict includes:
'screens':PLUGIN_MANAGER['ScreenManager'].plugins
rc = RequestContext(request, processors=[plugin_processor, settings_processor])
'screen_animations':PLUGIN_MANAGER['ScreenAnimationManager'].plugins
RequestContext will make the plugin_manager and each plugin's setting available to the template.
and also the screens(plugins) and corresponding animation will be available.

Then let's go to the template.

core/display.html
In this file, it will load the needed javascript/css to make the infrastructure.
{% for key, screen in screens.items %}
   <div id='{{screen.hash}}' class='screen'>
   {% with screen.hash as screenHash %}
   {% include screen.template %}
   {% endwith %}
   </div>
   {% endfor %}

And the above code snippet will include each screen's specific html into the main html.

Screen's specific html
Each screen's specific html will decide what content will be put in the screen(plugin) and how it can be shown and also you can write the control commands(key events and etc.) to ease the navigate.

This portion should obey the conversion which is defined by the touch screen.

Summary
Till now I only get a big picture of the architecture of touch screen, and some details are still in front me which needs to catch, including:
other control approaches(twisted and so on)
the complex class hierarchy
the plugin system
the menu system
thread syncing mechanism

And after reading some codes, I found some not-so-good codes, e.g. the main html(display.html), in which lots of jquery plugins are included in and most of them are not used in most of the plugins. And also when I try to read the codes of some screen examples, and I found some jquery plugin codes, and I try to figure out which plugin this function belongs to but finally I found it's really difficult to locate the function. IMO, we can refactor the main html and remove the not-necessary jquery codes and include them in the specific plugin template if the screen html really needs it.

plan
I will finish my graduation reply this Thursday and will have plenty of time to work on GSoC.

My plan will base on my proposal and also will make some adjustment from mentor's advices.

For the new week, I will:
read codes
understand the plugin system
understand the menu system
understand the twisted interface
do some preparation for this ticket http://trac.osuosl.org/trac/touchscreen/ticket/12

本文链接

博客园-Minds book of my CS Road

Linux下使用PPP上网

折腾Amazon Web Service(AWS) Free Tier

关于MySQL的实战一：基本的注意事项

骑行沙河

关于Social Game的两个调研报告

社交游戏（Social Game）开发简单教程与粗略总结之基础篇

社交游戏（Social Game）开发简单教程与粗略总结

我们的游戏终于回来了

VZ平台靠谱吗？

Dig into code base and Refine the trac feeds

core/urls.pyAfter digging into the urls.py, it's easy to know each installed plugins will be shown in loalhost/ or localhost/display/, which dispatches the request to display function at core/views.py.

Screen's specific htmlEach screen's specific html will decide what content will be put in the screen(plugin) and how it can be shown and also you can write the control commands(key events and etc.) to ease the navigate.This portion should obey the conversion which is defined by the touch screen.

core/urls.py
After digging into the urls.py, it's easy to know each installed plugins will be shown in loalhost/ or localhost/display/, which dispatches the request to display function at core/views.py.

Screen's specific html
Each screen's specific html will decide what content will be put in the screen(plugin) and how it can be shown and also you can write the control commands(key events and etc.) to ease the navigate.

This portion should obey the conversion which is defined by the touch screen.