Hellgate | 架构计划

背景

前面已经讨论了文字页游的【准备工作】，接下来需要考虑使用什么样的架构，针对这种架构应该如何执行。也就是设计 系统架构，制定 进度计划。

正文

• 系统架构
• 进度计划

系统架构

• 基本模式
• 项目结构
• 设计思路
• 代码风格

基本模式

此项目基于 Play framework 建立，因此也采用 MVC 的开发模式，将代码层次分为：模型、视图、控制器。

从 HTTP（暂不考虑 HTTPS） 的角度来说，每个会话都应该是异步的，而这也是 Play framework 的默认设计。

从每个访问接口乃至接口对应的方法来说，也应该是一种异步实现，这将需要我们努力维持底层的良好设计。

项目结构

Play framework 目前采用的是 Scala 的 SBT 构建工具，在 SBT 多项目构建 中，提供了很好的思路。

• util：Java 项目，公共，依赖第三方模块，通用的逻辑处理。
• core：Play 项目，核心，依赖 util 模块，重要的底层实现。
• framework：Play 项目，框架，依赖 util 模块，扩展的框架特性。
• service：Play 项目，服务，依赖 core 和 framework 模块，异步的流程整合。
• rest：Play 项目，接口，依赖 service 模块，基本的 RESTFul API。
• root：Play 项目，整体，依赖 rest 模块，并聚集 util、core、service、framework、rest 模块。

如图，这是大致的勾勒：

其中，util 对于项目来说不是很重要，但也不希望自己造轮子，于是一些第三方工具就放在这边。core 模块允许以阻塞的方式连接数据库和访问其他接口。service 必须设计成 纯异步 的工作方式，以备 rest 调用时，可以调度到不同的工作线程。framewrok 扩展了 Play 的一些特性，是对用户体验更好的优化。root 着重于渲染 Web 页面，不关心业务。

具体做法可以参考：Play 子项目教程。

设计思路

一般来说，从整体到局部，自上向下的开发方式，可以很好的把控局面。从 HTTP 接口到控制器，再从控制器到服务，从服务到核心……这样的层层递进，以需求驱动设计，完全避免了对未知需求的过度设计。当然，这种方式有个很重要的前提：需求清晰，目标明确。

我们需要做的是一个文字页游，它有实物可以效仿：好玩吧-地狱之门。

因此从接口入手，逐步分析它的结构、功能，这就像沙漏一样，从上方已有的 “沙子” 逐渐填满下方的空白。但这也意味着对整体需要有一定的把控，不能单单通过表面来演变内部细节，相同的地方需要抽象，特殊的地方需要实现，基于 Java 的接口而不是基于 Java 的类编程，这样便很好地移除了具体实现对程序的影响。

只要接口设计得当，未来即使需要改动实现，也不会造成代码的大幅度调整。

代码风格

好的代码风格意味着良好的可读性，通过阅读 okhttp 源码能够身心愉悦，那么如何拥有同样的风格呢？

下载 java-code-style 压缩包：

双击对应系统的脚本文件：

你便可以在 IDEA 中得到：

进度计划

• 开发流程
• 版本计划
• 时间安排

开发流程

基于 git 版本管理，自然遵循着 git-flow 的开发流程。

1. 将 master 分支作为主干，它是 稳定的 版本。
2. 将 develop 分支作为成长，它是 开发中 版本。
3. 将 release/* 分支作为发芽，它是 测试中 版本。
4. 将 hotfix/* 分支作为痊愈，它是基于 master 的 修复中 版本。
5. 将 feature 分支作为进化，它是 探索中 版本。

这五大分支可以规范开发流程，保证工作有序地进行。

版本计划

• v1.0
• v1.1
• v1.2
• v1.N

v1.0

这是最艰难的一个版本，千里之行始于足下，迈出第一步总是需要莫大的勇气。

在 1.0 版本之前，有一个小任务是要构建 通行证 体系，借着这个体系，打造一个类似暴雪 战网 的社交系统。当然，我们不会做得太复杂，有基本的功能就行，主要还是以 方便开发 为主。

• 基本内容
  好玩吧-地狱之门 的基调和其他游戏差不多，items（道具）、monster（怪物）、magic（技能），这三个基本内容应该最先设计，特点是利于扩展、便于导入。

• 世界观
  所谓的世界观其实是指：地图、职业、任务、等等，在这些宏观词汇之下，还包括：安全区、野外、副本，战士、法师、弓箭手，剧情、活动、循环，……。

• 核心内容
  有玩家存在的地方就有江湖，有江湖就有斗争，不论怎样的斗争都需要保证一个公平。这就涉及到职业之间的平衡，当然不可能保证绝对的平衡。法师是输出，在面对低级敌人时，总能够像割草一样玩耍；战士是肉盾，即使遇见高手，也不会轻易丢失性命；弓箭手介于两者之间，更可以提供一些辅助状态。
  各个职业的战斗方式不同，因此算法逻辑也不大一样，对于伤害的计算需要一个通用公式和三个职业公式。通用公式基于道具和属性，是简单的数值加减；职业公式基于技能等级，是分类的数值百分比。当这些界限能够清晰划分出来时，代码实现起来就轻松多了。

v1.1

关注业务逻辑的时候，没有必要频繁调整界面，所以能简化显示就绝不多余优化。但用户体验绝对是最重要的，一旦完成核心业务逻辑，就必须转移关注点，花在 打磨界面 上的时间，必须是 代码逻辑 的两倍以上。

由于 v1.0 尚未开始，这里也无法说明太多，总之一切等 v1.0 结束，再开始计划。

v1.2

结合自己对游戏的理解，将一些元素加入进来，需要等 v1.1 结束，再开始计划。

v1.N

此处一片空白，有待 v1.2 结束，再开始计划。

时间安排

一般来说，不可能在上班期间进行开发，因此需要在休息时抽点时间，而自己并不善于维持长久的热情，可能会导致开发变得遥遥无期。

为了鞭挞自己，这里大致进行一下时间安排：

• 工作日，每晚至少推进一个小时。
• 周末，每天至少完成三个功能。

以上时间安排，统统建立在 有心情、有热情、有时间 的基础之上，当生活不美满时，顾不上兴趣。

总结

果然自己还是一时的热度，做了三五天的准备和计划，到当前这一步竟有些疲乏和不耐烦。