一般的游戏的开发人员都是是怎么更新游戏和服务器的？（原理）

服务器结构探讨 -- 最简单的结构
所谓服务器结构，也就是如何将服务器各部分合理地安排，以实现最初的功能需求。所以，结构本无所谓正确与错误；当然，优秀的结构更有助于系统的搭建，对系统的可扩展性及可维护性也有更大的帮助。
好的结构不是一蹴而就的，而且每个设计者心中的那把尺都不相同，所以这个优秀结构的定义也就没有定论。在这里，我们不打算对现有游戏结构做评价，而是试着从头开始搭建一个我们需要的MMOG结构。
对于一个最简单的游戏服务器来说，它只需要能够接受来自客户端的连接请求，然后处理客户端在游戏世界中的移动及交互，也即游戏逻辑处理即可。如果我们把这两项功能集成到一个服务进程中，则最终的结构很简单：
client ----- server
嗯，太简单了点，这样也敢叫服务器结构？好吧，现在我们来往里面稍稍加点东西，让它看起来更像是服务器结构一些。
　一般来说，我们在接入游戏服务器的时候都会要提供一个帐号和密码，验证通过后才能进入。关于为什么要提供用户名和密码才能进入的问题我们这里不打算做过 多讨论，云风曾对此也提出过类似的疑问，并给出了只用一个标识串就能进入的设想，有兴趣的可以去看看他们的讨论。但不管是采用何种方式进入，照目前看来我 们的服务器起码得提供一个帐号验证的功能。
我们把观察点先集中在一个大区内。在大多数情况下，一个大区内都会有多组游戏服，也就是多个 游戏世界可供选择。简单点来实现，我们完全可以抛弃这个大区的概念，认为一个大区也就是放在同一个机房的多台服务器组，各服务器组间没有什么关系。这样， 我们可为每组服务器单独配备一台登录服。最后的结构图应该像这样：
loginServer gameServer
　| /
　| /
　client
该结构下的玩家 *** 作流程为，先选择大区，再选择大区下的某台服务器，即某个游戏世界，点击进入后开始帐号验证过程，验证成功则进入了该游戏世界。但是，如果玩家想要切换游戏世界，他只能先退出当前游戏世界，然后进入新的游戏世界重新进行帐号验证。

1、服务器端区分连接终端类型和平台版本不难，主要是数据接口的设计和负载能力

比如米聊，对所有终端内部的通信、存储、转发机制是样的

那你核心还是服务器端的技术储备和能力

2、Talkbox的通信机制实现起来不难，但还是前面的这个问题，就是服务器端的技术，同时语音的压缩和播放是否有自己的或者适合的引擎，因为Talkbox可以做到每秒2K的数据量超过移动网络的话音通信质量

3、游戏的跨平台，建议还是使用跨平台的引擎

Cocos2D之后衍生的Cocos2D-X要到年底才能比较完善的支持多平台（主要是目前Android平台Cocos2D-X还是需要用JAVA和C混编，要求比较高）而3D也有类似的可选择产品

4、是否有必要上来就考虑夸平台，这是个疑问

目前我们真的还没有看到哪个产品上来就提供网络游戏多平台支持的，因为各个平台目前盈利模式和收费渠道有所不同，所以你很难直接用iOS上的费率要求Android用户也认账，除非是直接针对海外市场

而目前iOSAndroidWP7这些平台上最成功的网络游戏还没有超过10万人在线的，前面问题中100万1000万的这个前提至少半年甚至1年内不存在

5、回合制游戏，我们要求做弱联网就是GPRS下必须可玩，如果一定是长连接，请评估自己通过优化后能得到的最小数据通信量

如果做手机网络游戏只能WIFI环境，或者断线后游戏进程没有等待或者恢复机制

那基本上不太可能或者真正的或者持续的成功6、目前北美Grossing前30名，无论iPhone还是iPad，传统概念的网络游戏几乎都是不存在的，只有弱联网的棋牌、农场、经营类，我们不认为MMO、大型联网游戏、3D网络游戏短时间内会有足够的市场空间

Android平台由于70%的终端还是里程碑时代的性能，所以建议产品选型的时候慎重，考虑跨平台同步实现的时候慎重，网络连接的带宽需求设计慎重

1、想出一个点子点子是启动游戏的引子，是一个游戏的源头。
这个点子首先在大体上应该是个类似于故事的东西。然后这个故事需要有一个目标。
2、分镜头脚本设计理解一个游戏最好的方法是使用分镜——创造一系列能体现游戏每个关卡或者不同的场景与目标的。每个分镜用一两幅来描述正在发生什么。
3、考虑细节做完分镜头脚本设计，就可以开始写游戏设计的细节。从这个步骤就开始变得复杂了。你将需要思考每一个可能的细节，并记录下来。
4、攥写设计文档用类似于脚本的形式记录你在上面两节所思考出来的东西。攥写文档看起来像是例行公事，但是攥写过程可以让你整理思路，以使你剔除那些一看就知道很白痴的想法或者添加一些其他的有趣的游戏元素。

Hilo是由阿里巴巴集团开发的一款 HTML5 跨终端 游戏 解决方案，可以帮助开发者快速创建 HTML5 游戏 。有以下特征：独立模块设计，支持多种模块范式的包装版本;面向对象程序化开发;多重渲染模型，其中包括 Canvas，DOM 和 WebGL 等;兼容多台台式机和移动浏览器；使用 Flash Shim 来支持 IE ;支持物理扩展： Chipmunk；支持骨骼动画扩展： DragonBone！
1、Hilo 支持多种模块范式的包装版本，包括AMD，CMD，COMMONJS，Standalone多种方式接入。另外，你可以根据需要新增和扩展模块和类型；
2、极精简的模块设计，完全面向对象；
3、多种渲染方式, 提供DOM，Canvas，Flash，WebGL等多种渲染方案（目前已经申请专利）；
4、全端浏览器的支持和高性能方案，独有的Flash渲染方案，即使在低版本IE浏览器下也可以跑起来“酷炫” 游戏 ； DOM渲染方案能显著解决低性能手机浏览器遇到的性能问题；
5、物理引擎支持——Chipmunk，支持自扩展物理实现；骨骼动画支持——DragonBones，同时内建骨骼动画系统——Tahiti（目前内部使用）；
6、案例丰富，框架成熟，已经经历多届阿里巴巴双十一，年中大促互动营销活动考验；
舞台Stage是一个各种图形、精灵动画等的总载体。所以可见的对象都要添加到舞台或其子容器后，才会被渲染出来。

Stage构造函数接收一个参数properties，此参数包含创建stage的各种属性。

舞台Stage上的物体的运动等变化，都是通过一个定时器Ticker不断地调用Stagetick()方法来实现刷新的。

舞台上的一切对象都是可视对象，可以是、精灵、文字、图形，甚至DOM元素等等。Hilo提供了一些基本的可视类供您使用，比如添加一个到舞台上：

要想舞台上的图形、精灵动画等对象能响应用户的点击、触碰等交互事件，就必需先为舞台开启DOM事件响应，然后就可以使用Viewon()来响应事件。

接下来，您就可以开始利用hilo提供的各种可视类来创建各种图形、精灵动画，尽情发挥您的创造力，开始您的HTML5 游戏 之旅吧！

Hilo对于开发H5 游戏 的开发者和对Web端渲染感兴趣的小伙伴来说值得一看，Hilo有诸多案例可供参考，如果你想继续深入了解它，可移步官方文档或者Github一探究竟！

---