博客园_Badkeeper‘s Home

利用PythonQT，定制服务器启动工具

2012-01-03T10:54:00Z

在开发过程中经常需要修改游戏服务器的各种配置参数，以方便在冒烟环境，开发环境和预发布环境中进行调试。我们以前使用ini文件进行服务器配置，所以经常需要关掉服务器，修改ini文件，然后再重新把服务器拉起来。最近有点时间，就开始考虑做个服务器启动小工具，能方便服务器在不同环境下的部署。

开始想用QT来写这个小工具，但发现建立一个QT工程其实有点小麻烦，后来干脆使用PythonQT来做。一个100多行的小脚本就能满足需求，以后交给其他人扩展功能也很方便。

主要是想做两个功能

1：可以方便的对服务器在不同环境下进行部署

2：可以在服务器启动时设置系统时间，因为经常需要测试一些时间性的业务。比如元旦节的活动。以前都是通过改操作系统时间来测的，这样每台机器就只能启动一个服务器了，如果想测两个不同时间的业务，就要多找一台机器。

下面是代码，可以很简单的修改成自己需要的工具

#!/usr/bin/python
 #-*- coding: utf-8 -*-

"""
ZetCode PyQt4 tutorial 

In this example, we create a skeleton
of a calculator using a QtGui.QGridLayout.

author: Jan Bodnar
website: zetcode.com 
last edited: October 2011
"""

import sys
import time
import threading

from PyQt4 import QtGui,QtCore

from xml.dom.minidom import parse,parseString
import os

version = u"服务器启动工具 V0.1"

class CommandThread(threading.Thread):
    def setCommand(self,command):
        self.command = command
        
    def run(self):
        os.system(self.command)
 
class Example(QtGui.QWidget):
    
    def __init__(self):
        super(Example, self).__init__()
        
        self.initUI()
        
    def initUI(self):
        label1  = QtGui.QLabel(self)
        label1.setText(u'选择服务器执行文件')
        label1.move(20,20)

        label2  = QtGui.QLabel(self)
        label2.setText(u'选择服务器启动配置')
        label2.move(20,80) 
        
        label3  = QtGui.QLabel(self)
        label3.setText(u'选择服务器启动时间')
        label3.move(20,150)  
        
        self.label4  = QtGui.QLabel(self)
        self.label4.setText(u'差异时间')
        self.label4.move(120,365) 
        
        self.text_serverbin = u"未选择文件"    
        self.label_serverfilename = QtGui.QLabel(self)
        self.label_serverfilename.setText(self.text_serverbin)
        self.label_serverfilename.move(20,50)
        
        btn_selserverbin = QtGui.QPushButton('...',self)
        btn_selserverbin.setGeometry(270,45,20,20)
        btn_selserverbin.clicked[bool].connect(self.event_selserverbin)
        
        self.dlg_selserverbin = QtGui.QFileDialog(self)
        
        #配置选择
        combo_serverConfig = QtGui.QComboBox(self)        
        xml_file = "./Data/Config/ServerConfig.xml"
        doc = parse(xml_file)
        serverConfig = doc.getElementsByTagName("serverConfig")
    
        for config in serverConfig:
            descript = config.getAttribute("description")
            index = config.getAttribute("index")        
            combo_serverConfig.addItem(descript,index)
       
        combo_serverConfig.move(20,100)
        combo_serverConfig.activated[int].connect(self.event_selserverconfig)
        self.serverconfigindex = 0
       
       #日历
        timer=QtCore.QTimer(self)
        timer.start(60000) 
        self.connect(timer,QtCore.SIGNAL("timeout()"),self.event_update)
        
        self.cal_serverdate = QtGui.QCalendarWidget(self)
        self.cal_serverdate.setGridVisible(True)
        self.cal_serverdate.move(20, 180)
        self.cal_serverdate.clicked[QtCore.QDate].connect(self.event_selserverdate)
        self.seldate = QtCore.QDate.currentDate();
        
        self.time_servertime = QtGui.QTimeEdit(self)
        self.time_servertime.move(20, 360)
        self.time_servertime.setTime(QtCore.QTime.currentTime())
        self.time_servertime.timeChanged.connect(self.event_selservertime)
        self.seltime = QtCore.QTime.currentTime();
       
    
        btn_start = QtGui.QPushButton(u'启动服务器',self);
        btn_start.move(180,420)
        btn_start.clicked.connect(self.start_server)
        btn_close = QtGui.QPushButton(u'退出',self);
        btn_close.move(260,420)
        btn_close.clicked.connect(self.close)
        
        self.setGeometry(300, 300,350,450)
        self.setWindowTitle(version)    
        self.show()
        
    def event_selserverbin(self, clicked):
        self.text_serverbin = self.dlg_selserverbin.getOpenFileName(self,
                        "Open EXE", "", "EXE Files (*.exe)");
        
        self.label_serverfilename.setText(self.text_serverbin)
        self.label_serverfilename.adjustSize()
        
    def event_selserverconfig(self,selindex):
        self.serverconfigindex = selindex
    
    def event_selserverdate(self,date):
        self.seldate = date 
        self.update_deltaTime()   

    def event_selservertime(self,time):
        self.seltime = time 
        self.update_deltaTime()                        
   
    def event_update(self):
        self.time_servertime.setTime(QtCore.QTime.currentTime())
        
    def update_deltaTime(self):
        currentDateTime     = QtCore.QDateTime()
        currentDateTime.setDate(QtCore.QDate.currentDate());
        currentDateTime.setTime(QtCore.QTime.currentTime());
        
        selDateTime         = QtCore.QDateTime()
        selDateTime.setDate(self.seldate)
        selDateTime.setTime(self.seltime)
        
        self.label4.setText(u'差异时间: '  +
            str(currentDateTime.secsTo(selDateTime)) + u'秒')
        
        self.label4.adjustSize()
    
    def start_server(self):
        serverfilename      = self.label_serverfilename.text()
        serverconfigindex   = self.serverconfigindex
        
        currentDateTime     = QtCore.QDateTime()
        currentDateTime.setDate(QtCore.QDate.currentDate());
        currentDateTime.setTime(QtCore.QTime.currentTime());
        
        selDateTime         = QtCore.QDateTime()
        selDateTime.setDate(self.seldate)
        selDateTime.setTime(self.seltime)
        
        command = str(serverfilename)
        command += ' -c ' + str(serverconfigindex)   
        command += ' -t ' + str(currentDateTime.secsTo(selDateTime))
        
       # print command
        commandTD = CommandThread()
        commandTD.setDaemon(True)
        commandTD.setCommand(command)        
        commandTD.start()
    
def main():
    app = QtGui.QApplication(sys.argv)
    ex  = Example()    
    sys.exit(app.exec_())


if __name__ == '__main__':
    main()

上面的小工具在启动服务器时是阻塞式的，一旦服务器启动，小工具就会处于假死阶段，直到关闭服务器。

可以使用Thread库，建立一个线程来启动服务器即可。

最后使用py2exe ，把上述脚本编译成EXE后就可以在团队内部发布了。

本文链接

新的工程模式完整的数据集中式 2

2011-02-04T02:56:00Z

其实在一个MMORPG的项目中，经常会遇到这种问题，服务器作为主控方，掌握了绝大部分数据的修改权利，通常对于不同类型的数据包，需要专门定义协议，然后在数据改变的时候同步给客户端（在《武林至尊》中，我们把这种数据主要分为资产和FOV数据两种）。在客户端的逻辑模块，根据服务器发过来的消息包修改本地数据。而客户端的其他模块（UI，渲染）需要定期扫描客户端逻辑模块的数据变化（也可以由逻辑模块主动通知），然后再将部分数据转换为自己模块内部的本地数据（脚本数据，渲染数据）。

服务器端掌管着数千个客户端需要得到的数据集，如果在上图中，把客户端本身也看出一个控制器，我们可以想象这样一种抽象结构，主要的数据都集中在服务器端，上千个客户端就像控制器一样联接在数据中心上，通过网络来存取数据。在客户端本地，它自己又是一个比较小的数据中心，它的每个功能模块连接在数据中心上，通过函数调用来存取数据。

在一个C/S结构的项目中，数据的变化应该主要包含几种方式：

数据在A端被修改，B端需要知道这种变化
数据在A端被修改，B端不需要知道这种变化
数据在A端和B端同时被修改（不是严格意义上的同时）。双方互不关心变化
数据在A端和B端同时被修改（不是严格意义上的同时）。以其中一端为主，另外一端需要通过各种机制进行数据纠正。
数据在A端，B端定期或事件型触发对数据的请求。

无论是哪一种情况，数据都可以归纳为3种类型。

数据有原稿和拷贝，原稿的拥有者可以修改和读取最终的数据结果，拷贝方的拥有者只能读取结果，无法修改结果。
数据有两份，分别由拥有者读取和修改，双方之间在一定时间内互不影响。
数据只有一份，拥有者都可以进行修改和读取。

其中2，3情况在客户端设计时经常会遇到，1情况则在服务器设计时大量出现。

让我们来考虑一种新的设计模式 - 包含了网络端的数据集中式。

首先要定义数据层的定位和功能

数据层能够定义数据，并且定义数据的类型，是原稿还是拷贝。对所有数据，数据层都应该提供数据在最小粒度上的置脏功能，但对于数据的划分粒度，则应该根据业务逻辑来决定。例如背包数据，可以认为所有数据是一个完整整体（最终会导致每次背包的数据变化是全量更新），也可以认为一个背包格的数据是一个整体（增量更新）。粒度的划分难以建立统一的标准，通常要考虑到数据量的大小和数据本身的各种特性。

数据层应该为数据的最小粒度单元提供读写功能，当然也应该为最小单元之上的整合单元提供一些辅助型的读写功能，否则最终代码的实现上会非常繁琐。

数据脏标志的写功能，不应该暴露到数据层之外，避免在上层应用上无意间调用。脏标准的读取功能是否暴露可以根据实际需求来决定。如果认为所有数据的变化都应该由数据层主动通知给其他模块的话，就无需暴露。如果有由外围模块扫描数据的情况，则需要暴露。

如果要保留脏标准的读取功能，则应该暴露数据变化的次数。之所以要这样要求，是因为无法保证只有一个模块会关心一个对应的数据，例如A B模块同时关心一个数据，那么数据只要一脏，A B就无法停止更新了，A在读取数据时不能将数据改为不脏，B也同样不能这样做。

对于数据层来说，最重要的功能应该是如何管理数据的原稿和拷贝。考虑到原稿和拷贝通常在不同的网络终端上，数据层应该提供从原稿方将数据变化同步到拷贝方的功能。这种同步和解析的执行应该是自动和透明的，无需上层关心。例如可以将不同的数据设置不同的标志，数据层定期扫描原稿方数据的变化标准，如果发现有变化的数据，就将这些数据统一压到协议中，然后一次性同步给拷贝方。

细化上述设计的话，主要有两点需要扩展。

首先数据的同步应该分为不同的频道，每个频道有流量控制和频率控制，以免数据的变化过快时导致模型的崩溃。每个数据在定义时应该指定所属的频道，一些控制型的数据可以注册到高频率的频道中（减小网络延时导致的体验感问题），一些数据量大的资产数据，可以注册到低频率的频道中。

其次数据的同步流应该一种自解释功能，或者说应该提供一个通用协议，可以把任意数量的，不同类型的数据按任意顺序组织起来，一次型同步给数据的拷贝方。类似于一个文件流的概念，先有一个文件头，后面是文件的具体内容。这样可以让数据层在每次扫描时，只对一个拷贝方放送少量的网络包，避免出现大量小包，导致TCP/IP头占用大量流量的问题。

--未完待续

本文链接

工程结构的层次图和基本职责

2011-01-23T06:23:00Z

个人还是偏爱在设计初第一步使用模块层次图来描述一个工程的基本结构。因为层次图可以在较浅的层面上对整个工程进行全面考虑，比较容易在一开始就确定细化设计的重点，并且通常层次图也可以对整体工程的子工程划分起到启发作用。但模块层次图无法具体体现出单层中各个模块之间的交互和依赖关系，也不能提供程序代码的层次划分关系，不能单独使用层次图对开发进行指导。

工程层次结构如图

图中的分割线表示多平台支持的分界线，通常分割线所在层次越高，开发难度就越高，分割线可以选择在网络协议层之上，或者在业务逻辑层之上不再支持跨平台实现。

具体情况要根据需要多平台支持何种业务来定。例如客户端在Windows平台上，服务器在Linux平台上，可以选择业务逻辑层之上不再支持

多平台实现，如果客户端在Windows平台上，逻辑服务器在Windows平台上，后端服务器在Linux平台上，也可以选择在网络协议层之上就不再支持

多平台实现。

跨平台支持层：提供跨平台的类型定义和函数定义，例如对int64，int32等的定义，以及对sprintf等函数的定义。

需要注意的是，由于该层存在的主要目的是使上层开发中，无需关心所面向的平台，因此在其之上的

各层开发中，需要调用某些平台的特有API时，应该将该API定义在《跨平台支持层》中，并且对该API

提供其他平台实现方案。该法则要保持到上图的分割线处。

实用工具层：提供内存监管，日志，时钟，Profile等，无需在这层提供多线程工具等平台差异较大的功能。

网络协议层：提供所有网络协议的定义，压缩，存储，生成，解析等功能

业务逻辑层：提供所有业务逻辑，并提供对网络协议的存取接口。

PS：其实网络协议层和业务逻辑层之间的关系比较难以确定。首先网络协议层在定义协议时是否需要使用到逻辑层中的各种定义和枚举。如果是，则协议层依赖于逻辑层。其次是逻辑层是否应该定义如何存取协议的接口，如果是，逻辑层依赖于协议层。而在部分项目中，逻辑层本身不是跨平台的，如果协议层依赖于逻辑层，则协议层本身无法跨平台。最后我选择了以下方式：协议层在下，逻辑层在上。协议层中不要出现任何逻辑层中的定义和枚举，应该保持其自身的独立性。在协议定义时，可以选择使用int替代枚举，选择比逻辑层长的，通用的字符串长度替代逻辑层中的某种字符串长度。协议层本身应该只关注如何进行内存转储并在网络上传输，无需关心其内容的实际含义，也不需要对其内容的逻辑合法性进行检查。

引擎层：该层提供渲染，音效，网络等具体功能的封装和实现。无需考虑跨平台需求，只需对每种平台实际需要用到的功能单独提供模块即可。

应用层：该层实现客户端，服务器，编辑器和其他工具，无需考虑跨平台。但应该尽可能考虑在不同应用程序中，复用下层模块。

本文链接

新的工程模式完整的数据集中式 1

2011-01-23T05:13:00Z

数据集中式的想法一开始出现于《RUN》，当时RUN作为一个带有物理逻辑的休闲游戏，有很多对物理，动作模块的过程型数据进行累计，计算的得分逻辑，并且通过得分逻辑对UI和特效进行显示控制。一开始的时候，没有统一的设计方式，只是完全的根据游戏逻辑的需求，将不同的逻辑分成不能的控制单元，然后相互访问。这种交叉式访问的工程结构，导致数据离散在不同的文件中，一个数据可能会被重复记录多次，并且控制单元间相互耦合度很高，一个控制单元的修改和扩展，会导致很多其他单元需要跟着一起变动。鉴于上述问题，RUN 当时做了一次重构。重构的目的是剥离控制单元之间的耦合，解决数据和数据计算的重复问题。重构的方向是定义一个数据中心（data center）。统一保存逻辑数据。所有逻辑数据都拥有存取接口，并且对一部分特殊数据，采用链表方式保存，便于对这些数据的变化历史进行记录和相关逻辑（例如每做一次得分动作都记录在链表中，后面可以统计出Combo）；数据中心本身只提供数据的存取和历史查询接口，不需对数据的来源和使用具体逻辑负责。数据中心之外有可以注册多个控制器，每个控制器负责一个相关完整的游戏业务逻辑。控制器负责修改数据中心的一部分数据，但不需要将数据的变化通知给其他关心的控制器。每个控制器都会定期的访问数据中心，看看自己关心的数据是否有变化，如果有的话，就根据这些变化执行相应的工作，并且将结果重新放回数据中心。

这样将系统逻辑拆分成多个相互独立的控制器后，逻辑模块的耦合度被大大降低了，一个模块的改动，通常不会影响到工程的其他部分。这种模型的缺点是当很多控制器对数据的访问频率很高，而控制器间数据的依赖程度不高的情况下，反而会降低整个工程的执行效率。

后来这个模型在制作《武林至尊》时没有被继承下来，主要是因为第一次涉及MMORPG类型的项目，无法在一开始预估出逻辑模块间的数据依赖程度，如果数据依赖非常高，将数据集中起来无疑比较好，如果依赖程度不够高，那么上述模型反而是一种过设计。因此《武林至尊》在初始设计的时候，采用了一种将消息集中的方式。结果类似于上图，不同的是，数据没有集中起来，而是放到了每个控制器的内部，便于快速访问。中心处集中的是由每个控制器抛出的消息。

控制器在启动时会在中心点注册自己关心的消息，当中心点有新的消息时，会根据注册信息派发给相应的控制器。

消息集中模型当然有自己的优缺点，但这不是本文想讨论的内容了，以后会专门针对这种设计来扩展一些想法。

《武林至尊》在制作到后期时，我又突然对数据集中模型开始关注起来，因为这个时候对于MMORPG这种工程有了新的认识。上面讲到的两种设计都是针对客户端如果架构的，但其实网络游戏中，服务器端扮演了一个更为重要的角色。通常在设计时，都习惯将服务器端和客户端分开在思考（很大程度上是由于一般情况下，是由两个人或者两个部门来分别开发的），但在这个项目中，由于对服务器和客户端在设计方面的全权把控，让我得到了很多宝贵的经验。其实在最开始设计消息集中模型的时候，考虑过将服务器端抽象成一个网络远端的控制器，将网络消息和客户端本地消息统一起来进行设计，但在实现过程中发现由于网络消息本数据量和数据复杂度和客户端消息之间有非常大的差异（试想一个Win32消息和一个玩家背包数据的区别），这种设计最终没有被付诸实现。但从数据交互的角度来看，服务器端和客户端的控制器之间的差异就没有那么明显了。例如我们考虑玩家背包数据的变化这样一个案例。

服务器端需要对玩家背包数据进行修改，然后将数据通过网络传输到客户端。客户端的逻辑模块（控制器）在得到数据后会对本地数据进行修改，然后UI模块（控制器）通过得到数据变化的通知，重新从客户端内存中取出数据，根据数据进行显示上的变化。在这个过程中，有3个模块对数据进行了修改和访问。让人感兴趣的是，如果忽略掉服务器和客户度是两个独立的进程，数据放在不同的物理内存中（当然正常情况下，也不在一台物理机器上）这个差异，我们可以认为是3个模块在对同一块数据进行修改和访问。

--待续

本文链接

技能系统设计笔记 7

2009-12-14T12:54:00Z

记录时间：2009年12月14日更依赖于事件的技能设计方案如果我们将技能事件的定义和功能扩展，会发现其实远程技能，近程技能的共通点。前期设计中，我们只考虑了事件的瞬时性，换句话说，我们认为只有瞬时发生，并只发生一次的逻辑才属于技能事件。如果我们在事件上加入时间，变化性等特点，可以惊喜的发现原来近程/远程技能的逻辑是如此统一。我们可以尝试用新的事件结构来描述近程和远程技能就像上面所描绘的一样，近程技能和远程技能在设计上达成了统一。近程/远程技能在技能控制，时序更新，事件触发和结果派发的各个关键点上的逻辑达成了一致，它们之间的差异性被转移到事件本身中。采用这种设计，技能的...

博客园_Badkeeper‘s Home

利用PythonQT，定制服务器启动工具

新的工程模式 完整的数据集中式 2

工程结构的层次图和基本职责

新的工程模式 完整的数据集中式 1

技能系统设计笔记 7

新的工程模式完整的数据集中式 2

新的工程模式完整的数据集中式 1