游戏系统开发笔记（四）——游戏程序简介
游戏程序还是其他什么功能的程序从开发者角度来说，差别都不是很大。真正区别比较大的地方应该是在于产品设计上。
不过不得不说，游戏是软件世界里最大型和复杂的一类应用之一，代码规模基本上都在百万行这个数量级上。所以实现起来是需要一些架构上的精心设计以及对程序语言和编程技巧的灵活运用的，否则很容易会在开发过程中出现传说中的软件危机神马的... 对于一款商用软件来说，首先要解决的是可行性问题，然后要解决的成本问题，软件技术到了这里就变成可用性和开发效率平衡的艺术。
当然往简单了去说，网络游戏的程序无非还是一个简单的C/S架构软件，就是在基本网络通信功能的基础上客户端加一些界面逻辑、服务端加一些游戏逻辑，然后每个客户端通过给服务器发请求来和其他客户端交互。
下面从程序结构上简单介绍下网络游戏：
我见过的程序主要是两类，一类是功能型的专门用来解决某个问题，通常结构就是：
INPUT -> ALGORITHM -> OUTPUT ，基本上就是纯算法的东西
还有一类是自成一体的应用程序，要实现多个模块的功能，并且也要兼顾开销问题等等，通常会设计成这样：
WHILE(COND) DO DO STH. END
为了让这个软件看起来正常点，在循环内部通常会有一些阻塞操作（比如read）或者直接调用sleep挂起线程来减少无谓的性能开销。
游戏程序自然用的是第二种，我们称之为GameLoop。
扩展一下，一个简单的游戏服务器差不多就是这个样子：
GameInit(); //初始化各项资源数据
while(GameState != GAME_EXIT)
{
FLUSH_NET_EVENT(); //处理网络消息
FLUSH_TICK_EVENT(); //处理定时事件
GAME_SLEEP(); // 按一定帧间隔跑循环，时间多出来要sleep过去，要是计算量过大时间超了就直接跑下个循环。
}
Release(); // 清理、记录等工作一些典型的游戏功能的例子，比如角色移动的过程，程序上大致分这么几步：
1、A玩家客户端得到按键消息，并转换成游戏世界坐标里的一个移动的目标点后发往服务端
2、服务端收到消息后先堆在网络消息队列里等候处理（这时候可能当前帧已经处理过网络消息了，但是下一个逻辑帧还没开始）
3、服务端pop队列并开始处理这个移动消息（FLUSH_NET_EVENT）
4、服务端经过验证后改变服务端上角色位置信息，同时发移动消息对应客户端同意移动。
5、服务端发移动消息转发给其他客户端，通知其他客户端上的“A玩家”移动到目标地点
6、其他客户端收到服务端发来的“指示”后，表现出一个移动的图像效果
当然，实际游戏里要考虑更多的东西，比如障碍啦、寻路啦、位置同步、延迟的感受啦、同步的数据量啦之类的东西，是需要在上述过程中进行优化才行。
再比如一个玩家打怪的过程：
1、玩家客户端点击怪物，客户端根据鼠标点击位置（或者角色位置）判断玩家是要执行什么操作
2、发消息告诉服务端我要打怪啦
3、服务端等FLASH_NET_EVENT
4、服务端验证这个请求，判断是否具备打击条件
5、服务端通知玩家客户端和其他玩家客户端进行打怪这件事情
6、服务端根据玩家的技能信息对这只怪物进行伤害判断和结算
7、客户端收到“打怪指示”后表现一个打怪的动画
具体实施同样会有一些优化的地方，上述这种流程实际上是比较依赖服务端的做法，有些游戏动作元素强，这么做则可能会带来一些延迟问题，需要把更多的事情交给客户端自己去完成。这么做主要问题就是很难使得多个客户端有比较好的同步效果，也容易滋生外挂。
在跑这些流程的过程中，可能有一些操作是需要定时执行的，那么就注册一个定时事件，在时间已经满足要求的逻辑帧里把它拿来运行一下。
当然，现在这年头只是联机移动和战斗，基本上已经很难称之为游戏了，势必要有内容丰富的玩法、道具、NPC系统等等等。其中大多数功能放到这个流程里其实都没什么特殊性，只需要不断的累代码就可以做到了。
另外值得一提的是，游戏产品对数据有很大的依赖性，就算只是做一个简单的弹幕游戏，也是要设计许多关卡、不同的子弹有不同的外形、飞行速度、杀伤力，BOSS的血量等等等。要把这些东西都揉进代码里是很不现实的，必须向办法将逻辑和数据剥离开来，通过一种简单的方式来关联。
所以现在大型游戏一般都有会许许多多的数据表，有的设计装备、有的设计道具、有的设计技能、有的设计NPC、有的设计数值、任务等等。按照之前所描述的分工，一般是程序和策划约定一个双方都可接受的方式（其实一般还是程序向策划妥协）来填写数据表，程序也按这套规范来解析数据文件。这样，在游戏程序刚启动的时候，就把这些数据加载到内存，并通过解析形成程序易用的数据结构，然后开发起来就会顺手很多啦。