20 年前当我为了谋生编写计算机游戏时这个行业还非常简单我写游戏公司包装并出售这些游戏(在用于 PC CD-ROM 和 CD-ROM 驱动器出现的前游戏是用盒式磁带发行 —— 您能相信吗？)我老板赚了不少钱我赚钱也比大学生用大多数合法手段挣到钱多而且我玩过我喜欢所有计算机和街机游戏游戏行业中生活还真不错！

　　但是我觉得厌倦了所以加入了 Real Business开始从事企业应用许多年过去了我又回到了游戏行业天哪这个行业变化可真大！

　　这个行业中主要变化是每个游戏(或者说几乎每个游戏)现在都可以称为在线游戏了随着在线访问大量增加游戏和游戏基础结构开发和部署也复杂多了

　　在线游戏行业内部状况

　　无论以怎样详细程度描述在线游戏行业都要花费很长时间而且我希望将重点放在发展问题上而不是关注其历史为了给后面讨论提供个背景环境我想花点儿时间谈谈该行业状况

　　这个开发、发行和运营游戏行业越来越复杂了在我以前编写游戏时代码开发人员执行所有开发任务而现在游戏美术方面越来越多地由美术工作室来承担游戏开发商差异也很大从具有个好创意新公司到大型娱乐公司(他们希望通过电影、演员和品牌综合运用来开发游戏让现有媒体资产产生更多收益)

　　游戏可以由开发游戏公司、专门游戏发行商或游戏合并者来发行游戏开发业越来越像电影业了这个行业中有大型公司也有小型独立开发商他们有时候是合作伙伴有时候是竞争对手

　　计算机游戏有许多区别类型游戏内容或游戏风格都有很大差异:从角色扮演游戏(role-playing gamesRPG)到极限运动游戏；从战略游戏到第人称射击(first-person shooter)游戏最后到 high-twitch 游戏(high-twitch 是种需要快速反应才能得高分或者持续几分钟不被打败游戏)

　　划分游戏类型种常用思路方法是根据玩家人数:

　　单玩家游戏(single-player game)需要游戏时间往往相当短适合临时游戏玩家Patience 和 Tetris(Windows 上免费版本称为 Tetrus)这样游戏和纸牌游戏往往属于这类它们也可以称为回合制游戏(turn-based game)—— 这些游戏多玩家版本中交互常常只是为了获得高分

　　在多玩家游戏(multi-player game)中个服务器托管了 2 到 64 位玩家这些游戏般具有特定长度游戏时间常常需要玩家保持定紧张程度个例子是 Battlefield 1942

　　大型多玩家在线游戏(massive multi-player _disibledevent=>UPS 努力客户现在可以跟踪他们订单许多进行网上购物人希望能够根据交付号链接到发送产品站点

　　履行订单

　　些数字产品可以用电子方式交付比如海报、屏保和代码非数字产品(T 恤衫、印刷海报、杯子和 CD-ROM)需要进行实物运输

　　客户服务

　　客户服务必须和前面提到几乎所有功能联系在起从而帮助玩家解决问题如果问题和游戏本身相关客服代表可能需要重新设置玩家配置文件、调整他帐号、检查他订单所需功能可能非常多提供方便客户服务可以避免玩家由于失望而放弃游戏这需要提供各种联系思路方法包括网上聊天、电子邮件和电话

　　聊天

　　在这个场景中我两次提到了聊天 —— 在等待玩游戏玩家的间聊天以及玩家和客户服务人员的间交流您还可能希望提供电子邮件尽管这个场景中没有考虑这个功能这些功能都归入 “协作” 范畴

　　支付

　　支付就是您如何收钱 —— 这可不是儿戏第次购买游戏、购买和游戏相关其他产品、购买游戏时间、游戏续订以及可以想到任何事情这些都需要进行支付

　　游戏相关信息数据库

　　这包括对所有游戏玩家都有意义通用信息:游戏指南、常见问题、来自其他玩家窍门技巧等等除了提供目录外还应该提供搜索和选择功能还可以提供为具体类别玩家定制信息比如新手或有经验玩家在理想情况下用户可以指定他感兴趣范围或者他所属玩家群体然后就会自动地看到为这类用户定制新信息这就涉及个性化以及和个人目录集成

　　奇怪是在这个列表中似乎只有第项是游戏开发人员真正感兴趣对于大多数游戏开发人员来说其他项目都很无聊是没有创造性枯燥工作最好让别人去做

　　用图形表示解决方案概况

　　现在可以创建个解决方案概况图(见图 1)从而以具体形式表示解决方案所需关键功能下图包含基本版本所有功能性需求

　　图 1. 解决方案概况图



　　查看原图(大图)

　　现在主要功能目了然了

　　显然在线游戏基础结构具有在线游戏市场特有些需求这是由使用设备类型和这个行业中常见业务模型决定

　　但是许多其他功能看起来很眼熟它们和电子商务基础结构很相似在过去几年中许多公司已经实现了这些组件比如基于互联网贸易、客户自助服务、基于社区工具从 dot-com 时代开始直到现在大量现成解决方案已经成熟了成为经过充分测试稳定产品

　　在这种情况下可以把游戏看作具有在线游戏行业特点业务应用

　　建立解决方案概况的后就该执行这种基于模式方式中下步了

　　步骤 3:确定业务模式

　　仔细查看解决方案概况图(图 1)就会发现解决方案中存在以下业务模式:

　　玩家和游戏本身进行交互在各种模式中这种交互最适合表示为 Self-Service 模式(也称为 User-to-Business这个模式处理内部用户和外部用户和企业事务和数据进行交互般情况)

　　买家可以搜索并选择产品目录中产品以及对所选产品下订单这些功能涉及用户、后端系统和数据库(产品目录)的间直接交互这可以表示为 Self-Service 业务模式

　　用户可以通过网上聊天和电子邮件相互交流或者和客户服务代表交流这是 Collaboration 业务模式(也称为 User-to-User这个模式处理用户的间交互和协作)

　　公司在两个帐号管理中在线接收信用卡信息个是游戏续费另个是购买产品时订单管理这可以表示为 Extended Enterprise 业务模式在线使用信用卡这个功能已经很成熟了已经集成在许多产品中但是我们目前采用这个模式并考虑它会导致哪些变化和扩展(也称为 >Business-to-Business这个模式处理区别企业业务流程的间交互和协作)

　　履行订单功能是游戏公司和其他组织的间边界；在这个场景中送货工作很可能交给 FedEx 这样快递公司去做在某些情况下整个履行订单功能都可以外包比如和 Amazon 这样公司合作

　　步骤 4:确定集成模式

　　那么如何将这些功能集成在起呢？在般情况下会使用 Access Integration 模式；实际上这看起来也很适合这个场景这个集成模式描述了支持访问个或多个业务模式常见设计尤其是这个模式支持来自多个渠道(或设备)访问并集成支持致用户界面所需常用服务

　　对于客户服务人员来说Access Integration 也是合适模式在解决客户问题时他们需要访问许多区别应用

　　图 2 给出修改后解决方案架构图其中包括集成模式

　　图 2. 解决方案概况包含业务模式



　　查看原图(大图)

　　步骤 5:确定复合模式

　　既然已经确定了集成模式现在看下复合模式复合模式是常见集成模式和业务模式组合

　　看看解决方案概况中包含模式然后和复合模式包含模式进行对比注意其中几个复合模式似乎都适用:Electronic Commerce、Portal 和 Account Access 复合模式都涵盖我们需要所有模式

　　但是Portal 模式涵盖范围最大 —— 它通常将多个信息源和应用聚合起来向用户提供单无缝个性化访问它列出以下这些必需模式我们解决方案概况中包含所有这些模式:

　　Access Integration 模式

　　Self-Service 模式

　　Collaboration 模式

　　Information Aggregation 业务模式(也称为 User-to-Data它允许用户访问和操作来自多个信息源数据)

　　模式描述进步介绍说明这个模式是合适下面引述 Patterns for e-business: A Strategy for Reuse 中 Adams 对这个模式描述:

　　设计门户目通常是将多个信息源和应用聚合起来向用户提供统无缝个性化访问……用于门户应用复合模式由个 Access Integration 模式和至少个业务模式组成其中 Access Integration 模式帮助实现单点登录、多种设备支持和个性化等功能