d********w
发帖数: 363 | 1 总体不难，但是也是高密度面试，希望能考察抗压能力，对游戏热情很重要。
1. 设计游戏，攻击对方减血，随着时间推移，血会逐步恢复（比如游戏每玩３０秒，
血加１），设计服务器，客户端如何maintain状态，
涉及到
１ scalable，可能你有几十万个客户端同时在线，服务器如何存储
２ low latency,用户体验上不能太长时间等待（本地cache？）。
３ 如何efficient传输数据，在什么时候触发动作
４ 灾难恢复，如果用户突然断掉窗口，服务器如何处理掉线了，数据如何恢复。
５ 逻辑还不能出错，因为血是在一个范围内的[0,100], 不能一直攻击对方，或者一
直加血。
２. rotate matrix by 90 degree in place
3. 写个小crawler，爬取某个指定页面，可以制定爬取深度，递归
４.high performance: online采用大量cache server，数据库sharding水平扩展，
offline采集挖掘日志。
5. 云计算，使用AWS的一些组件 EC2，scalable,他们自己也在搞zCloud
6. 如何设计用户欢迎的游戏？采用日志分析的方式，a/b test,迅速迭代，我记得他们
CTO讲过degrade system也是中策略保持基本服务的可用性。
7. 2个鸡蛋100层楼的问题 | b***u
发帖数: 12010 | 2 太有意思了.
真可惜z没理我。
我应该把怒鸟全三星的截图发过去的。
【在 d********w 的大作中提到】
: 总体不难，但是也是高密度面试，希望能考察抗压能力，对游戏热情很重要。
: 1. 设计游戏，攻击对方减血，随着时间推移，血会逐步恢复（比如游戏每玩３０秒，
: 血加１），设计服务器，客户端如何maintain状态，
: 涉及到
: １ scalable，可能你有几十万个客户端同时在线，服务器如何存储
: ２ low latency,用户体验上不能太长时间等待（本地cache？）。
: ３ 如何efficient传输数据，在什么时候触发动作
: ４ 灾难恢复，如果用户突然断掉窗口，服务器如何处理掉线了，数据如何恢复。
: ５ 逻辑还不能出错，因为血是在一个范围内的[0,100], 不能一直攻击对方，或者一
: 直加血。
| n**0
发帖数: 136 | | i*******6
发帖数: 107 | 4 比起FLAG来讲确实题目都很有意思啊...
写点想法下来：
1. 肯定是客户端本地做大量的数据和计时工作，periodically把结果通过消息发给服
务器的模式。
scalability: 存储可以考虑用hash，每个游戏角色肯定有一个unique id，直接从消息
里面取出来做key,然后把value update一下。
latency：除了改善网络和服务器的处理速度，我能想到的就是尽量把计算伤害什么的
在客户端本地做完，直接发消息告诉服务器“id xxx 要扣 id ooo NNN点血”。
efficiency: 那肯定需要自定义一些服务器和客户端都懂的协议了。触发动画动作一般
在收到服务器回复后做出。
fault tolerance： 服务器周期性的ping每一个客户端？似乎不是什么好主意...
logical:本地客户端会进行一个初步的过滤，比如如果血满了就不要每30秒发一条“+1
血”的消息了，对方已经死了也就不能打伤害了。当然服务器每次update数据也都要
double check一下，尤其是在N打1的时候。
2. 如果是顺时针转的话，先把矩阵沿着对角线翻转，然后把每一行反转。
3. 主要是判断重复页面，可以考虑在内存中maintain一个bit vector。 |
|
