背景
前面已经讨论了文字页游的【准备工作】，接下来需要考虑使用什么样的架构，针对这种架构应该如何执行。也就是设计 系统架构，制定 进度计划。
正文
- 系统架构
- 进度计划
系统架构
- 基本模式
- 项目结构
- 设计思路
- 代码风格
基本模式
此项目基于 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 的开发流程。
- 将
master分支作为主干，它是 稳定的 版本。 - 将
develop分支作为成长，它是 开发中 版本。 - 将
release/*分支作为发芽，它是 测试中 版本。 - 将
hotfix/*分支作为痊愈，它是基于master的 修复中 版本。 - 将
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 结束，再开始计划。
时间安排
一般来说，不可能在上班期间进行开发，因此需要在休息时抽点时间，而自己并不善于维持长久的热情，可能会导致开发变得遥遥无期。
为了鞭挞自己，这里大致进行一下时间安排：
- 工作日，每晚至少推进一个小时。
- 周末，每天至少完成三个功能。
以上时间安排，统统建立在 有心情、有热情、有时间 的基础之上，当生活不美满时，顾不上兴趣。
总结
果然自己还是一时的热度，做了三五天的准备和计划，到当前这一步竟有些疲乏和不耐烦。
网友评论