88 lines
4.1 KiB
Markdown
88 lines
4.1 KiB
Markdown
|
# 世界数触发区域配置解释文档
|
||
|
|
#worldtree
|
||
|
|
|
||
|
|
> 首先这个文档是早期文档, 后期可能会有改变, 仅供参考
|
||
|
|
|
||
|
|
## 前请提要
|
||
|
|
|
||
|
|
此文档是属于世界树的区域配置模块, 从游戏角度来说其中涉及了:
|
||
|
|
- 玩家移动区域时触发的事件
|
||
|
|
- 玩家在不同区域移动时的移动速度
|
||
|
|
- 不同区域内拥有什么类型的怪物的配置
|
||
|
|
|
||
|
|
> 本文主要分析实现这个过程需要的配置项与如何配置
|
||
|
|
|
||
|
|
## 框架与思路
|
||
|
|
|
||
|
|
首先触发区域是一个需要画的区域, 在 godot 中可以用画区域的节点实现. 非常方便.
|
||
|
|
|
||
|
|
因为以上的三点内容都需要基于世界位置区域划分, 所以配置的第一步就是画区域.
|
||
|
|
|
||
|
|
然后基于不同的区域类型我们分成了三种区域
|
||
|
|
|
||
|
|
- 地形区域
|
||
|
|
- 怪物区域
|
||
|
|
- 事件区域
|
||
|
|
|
||
|
|
### 地形区域
|
||
|
|
地形区域目前核心就是一个类型, 每个类型都有不同的移速修改, 具体修改多少移速是写死在脚本内部了, 比如丛林-0.3, 丘陵-0.5等等
|
||
|
|
这个配置是最简单的
|
||
|
|
|
||
|
|
### 怪物区域
|
||
|
|
这个区域核心在于需要为每个区域配置不同类型的怪物.
|
||
|
|
|
||
|
|
还有一个名称配置, 需要用于给玩家显示用的.
|
||
|
|
|
||
|
|
> 目前我们的项目中没有配置怪物, 所以短期我们只需要配置一个ID即可.
|
||
|
|
> (将来如何配置和处理我们在下文会讨论)
|
||
|
|
|
||
|
|
### 事件区域
|
||
|
|
这个区域比较复杂,我将以包含的方式去描述
|
||
|
|
- 事件配置
|
||
|
|
- 事件基础概率
|
||
|
|
- 事件触发失败时增加的概率
|
||
|
|
- 事件A 比如奇遇
|
||
|
|
- 0.2 概率
|
||
|
|
- 事件B 比如遭遇敌人
|
||
|
|
- 0.5 概率
|
||
|
|
- 事件C
|
||
|
|
- 0.3 概率
|
||
|
|
- 标签 这里的标签类似GAS的标签系统暂未实现 实现后类似:(陆地/海洋, 战斗/奇遇/探索)
|
||
|
|
- 名字 神秘海域
|
||
|
|
- 描述 这是一片神秘的海域
|
||
|
|
- 备注(开发者看得) 这是一个测试用的,看看就好
|
||
|
|
- 选项A
|
||
|
|
- 名称 探索
|
||
|
|
- 行为配置 (消耗) 比如消耗时间(这里不需要配置)
|
||
|
|
- 结果A
|
||
|
|
- 概率 0.4
|
||
|
|
- 名称 获得xxx物品
|
||
|
|
- 行为配置 (结果) 比如获得物品,获得经验等等
|
||
|
|
- 结果B
|
||
|
|
- ...
|
||
|
|
|
||
|
|
> 以上就是一个省略了很多的例子, 不过有一个完整的配置链路比如 `事件C=>选项A=>结果A`
|
||
|
|
> 其他的因为都差不多所以不写了. 这是抽象的具体的看游戏项目.
|
||
|
|
|
||
|
|
## 聚焦游戏项目
|
||
|
|
- 区域配置包含组件类型
|
||
|
|
- 不同的区域类型的配置流程
|
||
|
|
- 配置的可复用性(随时保存任意层次为成资源文件)
|
||
|
|
|
||
|
|
## 未来可能的问题与拓展方案
|
||
|
|
- 问题1: 因为我们是基于预制体编辑的, 所以一旦预制体发生改变, 那么就极有可能美术与策划同时编辑预制体从而产生文件冲突.
|
||
|
|
- 解答: 有两种解决思路, 一种是只有一个人编辑游戏场景, 一个人编辑区域预制体, 两者不相关联. 另一种思路就是这两者都由一个人处理, 也就是说区域配置完全交给一个人去做.
|
||
|
|
- 问题2: 这么编辑嵌套过于多, 配置的时候容易眼花缭乱, 容易配置错误和配置不方便
|
||
|
|
- 解答1: 目前我的配置下来感觉是能用的, 但是不是很好用. 因为我没有把中间配置存储成文件,快速调用. 这个工作可能需要策划去判断什么东西可以复用,什么东西无法复用. 可能把这个处理好了就能方便的去配置
|
||
|
|
- 解答2: 程序这里当然可以去研究一下如何实现一个编辑器,
|
||
|
|
把这个配置流程简化成类似`GameMaker`那样的配置方式,
|
||
|
|
但是目前不知道这样做是否满足需求, 毕竟做什么需要成本的.
|
||
|
|
这里如果需要做需要策划提供issure,交流讨论,
|
||
|
|
程序这里我猜测大改需要花费两天到三天来实现这个简化的编辑功能.
|
||
|
|
这里我还担心目前的功能可能在后期变动,从而会导致编辑器功能需要维护,
|
||
|
|
从而加重程序工作量,这里都需要加入考量(以前猜过坑).
|
||
|
|
同时这个解决方案是个万能解可以把问题1一并解决,
|
||
|
|
把美术配置与策划配置完全的分离.
|
||
|
|
|
||
|
|
|