Hellgate | 架构计划

2018-07-02 本文已影响0人 mrzhqiang

背景

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

正文

系统架构
进度计划

系统架构

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

基本模式

此项目基于 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 结束，再开始计划。

时间安排

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

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

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

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