[同步] 从C/S构架开始谈起 by coollen

[同步] 从C/S构架开始谈起 by coollen
2010年07月21日
　　Client-Server 毫无疑问，这大概是互联网游戏发展到现在的主旋律了。如果把浏览器看做是一个通用的客户端的话，B/S和C/S其实并无本质的区别。好吧，算我一开始就跑题了吧。
　　我其实只是想以更简单的方式讲述客户端和服务端的关系。和大部分网页应用一样，玩家发起一个动作，客户端向服务器提交请求，服务端再将结果反馈，可能只是反馈给一个客户端，也可能会反馈给其他客户端。而其他客户端收到信号，并以某种形式（图形、文字、声音）通知给正在操作客户端的玩家，由玩家做出反映，然后经由网络通知给服务端。如此反复不断……
　　这就是消息的传导路径，它是所有玩家在游戏世界中产生互动的根本。所有复杂的操作都是经由类似这样的消息传导产生的结果。消息携带着各种数据，在服务器和所有的客户端之间就像电流一样（其实也就是电流）以一定的游戏规则传播着，就如同水塘中的一个涟漪传导到水塘的各个角落，然后激起反过来的水波以相反的方向传导回去激起更多的涟漪。
　　请求 or 命令
　　想要实现某个玩法或者功能，大部分消息都是这样的两种方式：请求和命令。请求是指客户端主动向客户端发送消息，请求执行某项功能。命令是在服务端主动向客户端发出一系列指令让客户端去执行，来表现某些效果。
　　想当年的MUD，它的消息大部分都是用客户端请求-服务端反馈的方式。而现在的大多数游戏都是混合使用的，特别是WOW，采用了非常多的组合来实现各种各样的功能。
　　脚本+引擎
　　随着脚本功能的不断扩展，现在很多游戏的服务端都采用了脚本的方式。其实这是一个性价比的问题。大家都知道，使用脚本会更加依赖硬件的性能，但是能大幅提供开发时候的效率。对于一家有实力的大公司来说，可以使用延长开发周期而提高单台服务器的承载玩家数量，从而减少成本；而一个小规模的工作室，则需要关注开发时期的工作量问题。
　　另外一方面，脚本那灵活的代码风格，与C风格比起来更适应开发过程中对需求的变化。在我所经历过的多个项目之中，这一点相当重要。游戏策划在每提出一个新玩法或者新系统的时候，往往一开始只能提出一个雏形。一个成熟的玩法或者系统，都需要经历过几次变动之后，才会最终发布到游戏版本中去。
　　对于我来说，我毫无理由拒绝使用脚本，以及享受它带来的乐趣（所谓的乐趣就是一边品位着红酒，一边在我的Apple上敲入代码，无所谓是去北疆的火车上，或者是我老家的别墅房顶上）。
　　不仅如此，我自己编译了一份Python，（貌似我之前没有说我用的脚本是Python），为的是多学习一些东西，以及可以自己做一些Python层面上的自定义。我想过这样一种模式，在程序中使用两种不同的逻辑模块，一种是Python模块，一种是C模块，两种模块都可以用来写游戏逻辑。不过这样的方式需要归纳出一个能够支持这样做的底层系统。
　　
　　消息系统：网络模块
　　网络模块是一个Python的扩展，实际的位置位于二进制程序代码中，是一个非常基础的底层模块，我给他起了一个名字：Low Level Event（在代码中称为LLE模块）。之前我说到过希望能够实现C模块来共同编写玩法代码，所以在二进制程序中提供了一个机制，让C代码层也可以获得网络消息的处理机会。
　　LLE模块有reg函数来实现注册网络消息的功能，使用者如果需要处理某一条消息，则在使用之前需要将它注册。当然，同时也提供了unreg函数来实现相反的功能。发送网络消息的功能对应send函数。网络参数打算使用类似pickle模块的方式来打包/解包，暂时没有实现，考虑使用json。
　　多平台的支持是个比较痛苦的过程，对于我来说最关键的是代码中多了宏判断，这使得代码可读性变差了。（这个有啥办法还请高人提点）
　　结束语
　　世界上本来是没有结束语的，文写的字多余了，就成了结束语。这周在自己的server上试验了几个开源的PHP应用，聊天室，相册，代理，文档管理系统等，感觉非常新鲜。简单看了下PHP脚本，第一感觉代码不太美观，其他不太了解。
　　这篇写的非常粗略，也比较笼统，这将会在后面详细深入到代码中得到改变，抱歉。