码农成长日记

今天正式开始编写我们的游戏引擎GDE-X。 对于一个游戏来说，我们可以把其认为是一个状态机——实际上游戏中不同画面、场景等的变化，就是一个有限状态机状态间的相互切换。大致可以理解如下： while(not exit){    switch( state )    {        case state1:        do_state1();     

<br />今天看到优快云上有一篇google的首席JAVA架构师访谈，主要谈到软件开发过程中的API设计。<br /> <br />总结之，有如下观点：<br /> <br />1。 关于测试API：在实现API之前编写它的测试用例。 <br />2。 不用API写代码，就不可能看出API有什么问题。<br />3。 API设计有一条基本原则：疑则不用。 <br />4。 你对API越来越有信心，代码也就越写越长。<br /> <br />结合到最近我做的系统设计中的API设计，颇有体会。<br /> 

<br /> <br />概述：<br /> <br />在分布式系统中，经常需要采集各个节点的日志，然后统一分析。<br />本文提供一种简单的方案，本文采用开源日志项目 + 统一数据库结构的方式，在各个开发环境中，提供统一的配置及调用方法，所有的日志均记录在日志服务器中，可以追踪查询任意一个系统节点上任意应用的任意线程的运行状况。<br /> <br /> <br />考究现在比较流行的apache的开源日志项目log4j以及它在其他平台的衍生产物（log4net log4py等）。其由appender

介绍了如何构建复杂工作流的底层脚本架构

<br />最近负责一个项目的系统架构设计，刚开始粗粗给了个草案。经过一次修订后带着草案稿去找了一下公司首席科学家 传说中的“老天”，促膝长谈一整天，虽然被批判得一无是处，但是我却觉得异常之爽，顿时觉得在系统架构设计上已经渐渐扫盲开始进入正轨。<br /> <br />极度欢迎有理由的对我批判，越狗血淋头越过瘾。。（是不是有些犯贱了，哈哈）<br /> <br />结合项目实际情况，总结一下一些改进建议和以后值得注意的地方：<br /> <br /> <br />1。 平台API先不用考虑。我原先第一版就在

架构设计学习资料

<br />对于系统设计，最近有一些小小的领悟，现总结部分经验，开一个话题，今后持续更新。<br /> <br /><br />2010-11-19<br />1. 系统设计初期要符合初期需求，不要过度考虑华而不实的扩充，会导致初期开发迷惑及任务膨胀<br />2. 系统设计不是需求的再描述，必须拍板关键的技术选型<br />3. 调用关系不要出现三角关系<br />4. 系统设计必须从能够从设计层面识别程序模块<br />5. 分层系统适用于从上到下，再从下到上的过程，中间层必须是封闭的，否则就是星型系统

一起欣赏架构之开篇语

浅析autonomy的videologger

浅析autonomy的videologger ——2

<br />由于MSN本身协议开源，于是基于其开发各种插件或者应用成为可能。<br />本文旨在设计&展示如何用.NET搭建一个公共的MSN平台。其基础功能包括：<br /> <br />1. 提供一个MSN机器人发布接口，任何用户可以使用该接口令MSN机器人向其他联系人发布信息。<br />2. 提供一个MSN发布接口，任何用于可以使用该接口发布自己的MSN信息。<br /> <br />当然该平台也可以在MSN协议允许的基础上扩大功能，这是后话。<br /> <br />为了使用的便捷性我们的接口使用W

<br /><br />1. 基础模型尽量符合通用（不一定是简单）的原则，这样才能建筑起强大的上层建筑。如果基于该模型构建上层建筑过程很复杂，考虑设计中间层。<br /> <br />所以在设计底层的时候应该是想一个尽量简单的规则，能够衍生出各种复杂的上层。就像数学里，公理尽量简单明了，可以严谨的用于论证复杂的上层情况，如果上层应用很复杂，再归纳出定理。<br /> <br />2. 在访问临界区不是特别频繁的情况下，进程间互斥锁可以只用规范一个命名。<br /> <br />使用一个锁来锁住整个临界区，实

一般游戏都是基于 “场景驱动”的。所谓场景驱动就是由玩家在游戏中具体位置、具体状态、具体行为触发游戏逻辑。如在某地图中，进入某个门，就到下一张地图；如在某地图中，选择和某人对话，就触发战斗等…… 请看下面来自武林群侠传的截图：由驱动级任务（RPG场景、养成模式场景）来驱动子任务（战斗、小游戏、菜单）等。   在我们的GDE-X引擎中，也采用这种设计理念。

最近工作中需要设计一整套系统，其包括 B/S形式的WEB服务、数据库等，而且包括要设计应用层私有通信协议的C/S的结构的程序模块，涉及到与外界数据库交互、与外界模块交互。 由于我实在是设计上的小白，也对数据库、WEB这块事基本不太懂，在自己大体上对整套系统划分模块之后，对于系统与数据库交互，或者系统内部数据库建设方式存在很多疑惑点。 于是我怀着好奇心，和我公司一DB专家聊了一小会。

因为之前一直做C++，没有特别研究过Java、C#中的Interface概念。在看设计模式的时候，也弄得一知半解的。 今天在做GDE-X过程中，我想定义一个类似于 c++的纯虚函数的，派生类必须实现的函数。然后我发现在C#中，使用abstract（纯虚函数）和Interface（接口）都可以实现这个概念，于是甚感迷惑，请教了一下同事，终于弄懂了设计上的不同概念。 如果光从实现上

在之前的设计中有提到，游戏过程就是一个有限状态机。而之前状态机我们已经实现，我们在此之上实现之前提到的驱动级任务及临时任务的概念。 我们可以认为 地图及场景切换 是我们的驱动级任务。而战斗、弹出窗口、小游戏等是游戏中的临时任务。 对于我们的游戏引擎，必须能够方便的添加新的场景、随时启动子任务。而这一切在基于我们的引擎开发的时候不应该再要考虑架构上的资源管理、内存管理等问题。

<br />SmallGameLib是我自己这两天学习silverlight，通过对昨天编写的“气球人”游戏代码重构及解偶，开发出一个超级轻量级的小游戏开发包，<br />现在功能还非常薄弱，不过架构已基本形成，可以使用它进行一些超小型游戏的快速开发。<br /> <br />本文主要对该游戏开发包进行架构介绍与分析，为广大尚未入门的游戏开发者提供一个构建属于自己的游戏框架的思路。与此同时，我将继续完善这个框架，并且使用这个框架开发更多的示例游戏。<br /> <br />1。 为什么需要开发包？<br /

<br />这次我们来基于java设计并实现一个简单的任务池。<br /> <br />什么叫任务池？<br />实际上就是一个任务流水线，可以将各种待完成的任务发布到流水线中。由任务池统计管理并且调度，来保证任务的完成。可能会有这样的疑问：我对每个任务都单独起一个线程，让其独立完成不就可以了么？对于小批量、快速、占用少量资源的任务可能这样没有问题，但是对于大规模、多并发的任务，这样的结果是会造成系统性能极其低下，并且还很可能造成资源需求上的溢出。<br /> <br />如何用有限的资源，调度并完成任务，

跨JAVA WEB工程远程更新方案设计<br />版本：V0.1<br />作者：CG背景<br />需要在JAVA跨WEB工程，基于HTTP协议可靠的传输大规模数据。<br />原因：在使用数据库远程连接的时候由于远程数据库连接本身的不可靠性（服务器端经常断开与JDBC的连接），而造成事务不断回滚而造成数据始终无法传递。所以需要设计一个可靠的、通用的远程更新方案。方案流程 <br />技术选型及实验结果<br />l         序列化、反序列化实验<br />使用第三方JAVA包xstream-1.

<br />在以后的系统设计经验谈中，我将对各条“经验”进行具体的解释。<br /> <br /> <br />1。 在任务调度模型中，管理者到执行者的指令级的调度未必可靠，（调度链路可能挂了，而执行者没挂）所以在调度模型中管理者的设计尤其复杂。<br /> <br />典型过程模拟：<br />1。 管理者A调度执行者B执行一段指令。<br />2。 执行者B正在执行，但是和管理者A的通信链路挂掉了。<br />3。 管理者A没有收到执行者B的反馈，认为它可能任务超时了。<br />4。 管理者A需要调度

<br /> <br />2010-12-1<br />1. 抽象的模块划分图是示意图，在系统设计中应该有配套具体的模块关系图对其进行解释。<br />2. 环形调用关系的出现有时是不可避免的。尽量不要出现。<br /> <br />2010-12-2<br />1. 在复杂调用系统中，应该明确同步阻塞关系。<br />2. 在Interpreter模式中，若需要崩溃恢复，不能使用冻结脚本虚拟机并恢复的原理，因为运行环境很可能变化了。而应该是缓存住之前耗时操作，重新执行。<br />3. 在设计版本升级流程

架构设计收获