留白篇

国外游戏设计

良好的判断力来源于经验，而经验来自错误的判断。

尝试，失败，再尝试，直到成功。

团队合作能让平凡人取得不平凡的结果。

手游后台开发

借助现有的框架组件来一点一点完成一些游戏业务功能。

1、下载、安装基础套件

主要包括TSF4G-BASE、TCONND、TALKERAPI以及TCAPLUSAPI
推荐下载一个大的整体Apollo发布包。

2、从零开始写echo服务器

tapp

游戏后台作为一种守护服务类进程组，当中每个进程必须在后台一直运行并提供服务。tapp作为后台服务进程开发框架，作为一种典型的reactor服务模型，提供了方便与开发与运维的特性，游戏业务侧不需要任何开发就具备了这些能力，同时集成了tbus、tdr和tlog等组件，可以很简单就能使用起来这些接口。这点会在下一节中以开发一个简单的echosvr为例。逐步揭开公共组件的面纱，一览无余地呈现给大家。

还是回到本节主题，继续介绍tapp。tapp作为一个后台服务框架，大家可以看到，它的主循环运行过程是这样的：

可以看出来，主循环的工作就是在单线程中不断去处理“后门控制命令，进程停止命令，配置热更新命令，主逻辑，定时任务”模块逻辑。这里面每个操作都是按照这个主循环的顺序依次来执行的。每个模块逻辑的迟顿都会延缓其它模块的执行时机。所以可以理解，对时间精度敏感的定时任务其实不是真正意义上精确的定时器。

tbus

tbus作为进程间通信中间件，基于共享内存的全双工无锁消息队列，api使用简单直观，运行效率高，并能够屏蔽物理机器的部署，无论如何部署都不需要修改业务代码。tbus类似于udp，是有边界的通信方式，不需要关注tcp的流式通信带来的粘包分包问题，使用起来比较简单。同时与udp相比，它还不受包长65535的限制，它能发更大的包（理论上2^32 - 1 Bytes）。最重要的是，还能保证包有序性和可靠性（机器不宕机的前提下）。集成于tapp以后，tbus使用更加简单，只需要启动时指定–bus-key 以及 –id以后，业务代码只需调用tbus_send 和 tbus_recv接口就可以实现可靠高效的进程间通信了。

tlog

tlog借鉴log4c，除了实现了常规的记录日志到文件及日志级别过滤以外，同时支持日志记录到tlogd集中管理。集成到tapp之后，可以不指定日志配置文件，tapp会生成默认的配置，几乎只需要直接调用tlog_log api就可以记录日志。如果有更进一步日志设置的时候，再参考tlog文档，这样至少开发时，可以在不用去专门定义日志配置的情况下使用。

tdr

tdr是huyu研发中心数据表示中间件，采用c/c++开发，支持网络编解码（标准说法是序列化反序列化）、XML数据输入输出、数据可视化、对象关系映射等功能。目前最常用功能是使用tdr工具生成c++/c#代码进行网络编解码，以及接入tcaplus（研发中心自研的分布式内存数据库）时，需要按照tdr数据描述语法定义xml格式的schema。

这里再给一个tapp框架的结构图。

3、echosvr实战

每一个迭代的实战都按“目标、编码、编译、运行、知识要点”这样的步骤来跑，但是只在第一阶段迭代清晰贴出所有代码，以后每个迭代只列出关键部分代码，新增代码前缀+，删除代码前缀-，修改代码前缀。

至此，游戏开发入门篇就结束了，在入门篇中，从tsf4g-base基础库开始，介绍了如何基于tapp框架，开发一个使用tbus消息队列通信的echo服务进程。紧接着介绍了使用tconnd接入层组件完成与手机端进行通信的具体介绍和详细步骤。包括介绍了简单的tconnd功能到配置，echosvr服务层talker api接入和联调客户端工作（这其中talker层内部使用tdr进行消息协议到打解包，进一步为游戏业务透明化了打解包逻辑）。