类别归档:游戏开发

RSS feed of 游戏开发

最后更新于 .

发现想抽时间写博客实在是太难了,不过我觉得今天这一篇还是很值得写一下的。

熟悉我的同学应该都知道,我之前做了一款《矩阵危机》的产品,使用的是帧同步的技术。

简单画一下V1架构图:

  • Gateway

    网关服务器。

    负责客户端连接的接入,使用协议TCP。

    使用C++编写。

  • KcpProxy

    Kcp协议的代理服务器。

    客户端默认使用Kcp连接服务器,如果失败会自动回退到Tcp。

    使用C++编写。

  • RoomServer

    房间服务器。运行战斗逻辑,每个房间同时仅能运行一场战斗,帧率为15帧/秒。

    房间服务器与Gateway间通过Tcp连接,每个房间建立一个一条独立的连接。

    使用Python编写。

整个架构还是比较清晰的,但是里面有个极大的问题:性能

因为python的性能实在是太差了,对于RoomServer每秒15帧这种cpu密集型的业务场景完全不适合。

至于python的性能有多差,我当时做过一个简单的测试,同样的业务代码,c++是python性能的10倍左右。

可能直接说这个数字大家也没什么感觉,但是要知道换算成服务器的话,那就是10倍的服务器量,10倍的成本。

所以这也是要做架构升级的原因。

而升级的方案也有多种,其中一个方案如下:

其核心逻辑是将CPU密集的RoomServer放到Gateway中去,而额外多出来一组RoomController负责对Gateway和Room进行控制。

RoomController可以继续使用python实现。

这样的方案虽然解决了性能问题,但是却导致gateway的功能过于耦合,不是好的设计方案。

还有一个方案就是将RoomServer直接使用C++重写,每个Room开一个线程 ...

最后更新于 .

本来下午一直在纠结用什么设计关卡地图的事,中间还考虑过使用excel,但是发现很难用。后来美术随口说了一句,用瓦片地图怎样?我说那个只能固定格子来排列吧,他说可以不用的。我这才去试了一下,果然可以。

Tiled 有如下几个很方便的功能,跟大家分享一下。

  1. 对象层创建的对象,位置是可以不严格按照格子来定位的。

    这里有几种选择:

    1. 将地图的属性中的格子大小调小。比如我们认为1米对应100像素,那么一个1.8米的人就是180像素高。

      如果我们认为对齐的精度只要到10像素即可,那么就可以将格子大小调整为10x10。

      之后选择 视图 -> 捕获 -> 对齐网格,或者移动对象的时候按住ctrl,就可以实现对象位置自动对齐网格了。

    2. 就是希望自由定义位置,那就什么也不用改。

  2. 对象支持类型以及属性

    这样对编程就非常方便了,代码可以通过对象不同的type来区分大类,之后再以对象name来区分小类,然后再通过属性获取具体的数据。

    对地图编辑也非常友好,因为不同的类型可以设置不同的颜色,这样编辑的时候就非常清晰了。

    值得一提的是,对象类型是不绑定在单个地图上的,所以如果需要创建多个地图的话,是可以公用对象类型的。

  3. 对象支持模板

    这个也是对于编辑多张地图非常重要的事,非常幸运的事,tiled支持了它。

    1. 首先要在 视图->视图和工具栏->模板 这里打开模板。
    2. 之后随便创建一个对象,比如一个hero。再其上点击鼠标右键,选择保存为模板hero.tx ...

最后更新于 .

一. 简述

我们用最精简的模型来描述一下帧同步。

客户端检测服务器的逻辑帧 -> 拿到逻辑帧 -> 进行处理 -> 处理出结果 -> 完成本次逻辑帧处理 -> 表现层将处理结果渲染到屏幕上 -> 结束

客户端检测用户操作 -> 打包成action -> 上报到服务器 -> 结束

在此基础上,客户端可以通过缓存帧,平滑帧,预测,插值,等方案优化表现层的效果及手感,但是底层模型是一样的。

比如缓存帧就是客户端检测到新的逻辑帧之后不立即处理,而是先缓存到一个队列中,等到满足一定数量之后,才对队列popFrame进行处理。

而平滑帧,则是在缓存帧的基础上,将popFrame的操作做成定时操作,从而抵抗网络波动导致逻辑帧到达的时间间隔不一致问题。

帧同步游戏一定要分为逻辑层和表现层。

表现层怎么折腾都可以,但是逻辑层必须保证确定性。

那么哪一部分属于逻辑层呢?

拿到逻辑帧 -> 进行处理 -> 处理出结果 -> 完成本次逻辑帧处理

打包成action -> 上报到服务器

所以,平缓帧的实现方案中,才能用普通的 ...