对于3d视频游戏来说，游戏引擎的性能是至关重要的。玩家在体验一款游戏时，游戏的流畅度是最基本的要求。与单机游戏不同，网络游戏更需要考虑性能问题，因为无法像单机游戏那样，控制游戏元素的复杂度来达到效率的要求。大量玩家涌入同一片区域，同屏出现大量的游戏角色是无法避免的，因此游戏帧率的大幅下降，系统资源的大量消耗也很难避免，这是网络游戏引擎最难处理的问题之一。
这里要讲一下游戏帧率的控制，通常玩家在玩游戏抱怨游戏客户端卡有两个意思，一是游戏平均帧率很低，二是游戏的帧率非常不稳，导致了卡顿。实际上游戏平均帧率低，对玩家心情的影响远不及卡顿造成的影响。平均10帧的游戏，虽然已经很糟糕了，但是依然能玩，但是频繁的卡顿给人的感觉就糟糕透了，平时40帧左右的游戏忽然因为加载个什么东西卡了一下，帧率掉到了零点几，然后又恢复到40帧，这种卡顿给人的感觉就是烦透了。
游戏引擎首要解决的性能问题就是卡顿的问题。要解决卡顿的话需要做到以下两点：
第一，不要在主线程去加载资源，最忌讳的操作就是打开文件，这个操作会挂起当前线程，也就是说会让渲染线程停顿。把所有的资源加载操作全放在加载线程去做，毕竟加载线程随便停顿也没什么关系，对主线程的渲染没影响，主线程只需要每帧判断资源是否已经加载上来就可以了。一但发现已经加载上来了，就可以用这个数据去渲染了。
第二，也是最重要的一点，把加载的操作摊到多帧去做。通常角色走进人堆里以后，或者在战场上魔法漫天飞的时候，服务器会传来大量消息需要处理，最典型的就是创建消息，无论是创建角色还创建特效，就算是采用多线程加载的方式，在一帧内创建对象，通知线程加载底层资源，那么多消息的处理依然会不可避免地造成卡顿。这里有一个非常好的解决办法，就是这些处理消息的操作不要一帧内做完，而是分摊到多帧完成。
一般说来，处理网络消息的过程是这样一个循环：
while( 消息队列中还有消息 )
{
从队列中取出第一条消息;
处理这条消息;
将这个消息从队列中删除;
}
在一帧当中，循环遍历整个消息队列，将这一帧收到的消息一个一个处理一遍。
这样做忽略了最重要的效率问题，当你因为游戏卡顿在焦头烂额地优化资源加载时，不放考虑修改一下消息队列的处理。
在这里，我可以加入计时：GetTickCount()
初始时间 = GetTickCount();
while( 消息队列中还有消息 )
{
从队列中取出第一条消息；
处理这条消息；
当前时间 = GetTickCount();
经过时间 = 当前时间 - 初始时间;
if( 经过时间 > 20 )
{
break;
}
}
如果这一帧的处理时间超过了20ms，则把剩下的消息放到下一帧处理。通过这种计时的方式，你会发现游戏的流畅度简直有了天翻地覆的变化！在优化之前，有个几个人在用群攻魔法攻击大量的怪物，这些家伙忽然涌入到视野中，帧率便一下掉到了零点几，游戏出现了非常严重的卡顿，这种状态持续了很短一段时间，帧率又迅速回升上去。而现在，经过修改以后，你会发现那些家伙很平滑地出现在视野中，没有一丝的卡顿。如此效果简直是奇迹一般，而这一切仅仅是修改了几行代码而已。
现在考虑这么做所带来的问题。如果消息量非常大，而机器又慢，平均帧率又很低的话，那麻烦可就大了：每帧处理的消息量还没有收到的消息量大。这可是个很严重的问题，这会让客户端的表现与实际情况严重脱节。在这里，就需要有一个机制，保证消息在积攒超过一定数量时，能得到及时的处理：
初始时间 = GetTickCount();
while( 消息队列中还有消息 )
{
if( 消息队列中的消息数量 > 300 )
{
一次性处理所有的消息;
}
else
{
从队列中取出第一条消息；
处理这条消息；
当前时间 = GetTickCount();
经过时间 = 当前时间 - 初始时间;
if( 经过时间 > 20 )
{
break;
}
}
}
这样就解决了消息越积攒越多的问题，当消息越攒越多时，会一次性处理所有的消息。但这样也会带来一个问题，那就是在帧率比较低的机器上，当需要处理的消息特别多时会出现周期性的卡顿。卡顿的原因就是那步一次性处理所有消息的操作。优化的目的就是要避免这样的卡顿，而对于低端机器来说，这样的优化不但没有起到效果，反而加重了卡顿现象。为了弥补这个方法带来的弊端，就要对那个经过时间20ms做点手脚：
static 时间阈值 = 20; //注意时间阈值是static的
if( 消息队列中的消息数量 > 100 )
{
++时间阈值;
}
else
{
--时间阈值;
}
if( 时间阈值 < 20 )
时间阈值 = 20;
if( 时间阈值 > 40 )
时间阈值 = 40;
初始时间 = GetTickCount();
while( 消息队列中还有消息 )
{
if( 消息队列中的消息数量 > 300 )
{
一次性处理所有的消息;
}
else
{
从队列中取出第一条消息；
处理这条消息；
当前时间 = GetTickCount();
经过时间 = 当前时间 - 初始时间;
if( 经过时间 > 时间阈值 )
{
break;
}
}
}
这里增加了时间阈值这个静态变量，替代了之前代码中的20，使之成为一个由当前帧消息包数量决定的一个可变的值。当前帧消息包的数量超过一个值时，就将这个时间阈值加一，否则减一。这么做的效果就是，消息包来得越多，每帧用于处理消息的时间就越长，也就是说消息处理耗时的比重在逐渐上升。这样就能很大程度上降低消息数量超过上限的可能性。
最差的情况，如果这样做依然有周期性卡顿的话，这台机器真的就不适合运行这个游戏了，退一步讲，不作这个优化的话，这台机器玩这个游戏也依然会卡得要命。：）
当然，时间阈值的范围，和消息包的数量上限可以调整，以适合于不同的游戏。