我在做一个类似rpgmaker的游戏框架，想咨询一下各位踩过的雷

Rinice

我在做一个类似的战旗游戏框架，也是地图可编辑的，所以想参考rpg maker的系统。
但我之前接触的是xp的框架，对新版本一些有用的特性不太熟，而且感觉一些开发在使用rpgmaker的时候还是需要用到相当一部分的插件。所以来p1咨询各位了
事先说明，我了解真的不多，所以如果有问的不恰当的，或者说法有问题，见谅，十分感谢orz
问题目前有如下内容：
1.你们考虑过六边形的地块吗？你们认为如果有一个六边形地块作为地图的rpgmaker，和现在的地块系统比，它的优点和缺点可能会是什么？（比如画起来困难，无法直接使用小键盘的上下左右键控制角色行动）
2.你们对战争迷雾系统的需求高吗（假设是选择开放的，和卷轴式地图一样）？
3.当前的rm的变量系统你们觉得有什么可以改进的地方？加入double全局变量，或者加入字符串类型的全局变量的话，可能比现在更舒服吗？
4.你们认为生成式的地图（不使用预先绘制好的地图，而是绘制各个单元，再使用代码使用随机种子生成地图，类似minecraft）和普通的地图相比，有没有存在的需求？
5.如果事件系统里可以使用函数化表达且不用额外写脚本，比如：开关6的值锁定为(开关3*开关2)%5的值，对现在的开发逻辑会不会有改善？
6.如果现在有一个对象，它叫区域，它由地图中数个连续的tile方块组成，并且事件可以检测到进入区域或者区域里发生的所有事情（而不是只能绑定一个格子），这个区域只要是连续的可以是任何形状，会对开发有什么帮助
7.现在的地图的A1234，BCD层的作用是什么？我是否可以理解为A层的所有元素都是在一个图层上的，而BCD层的元素每层都和其他层的元素不交互？那如果将这个逻辑取消，制作者可以增加任意元素到任意层，就像ps的画布一样，会不会优化创作者的体验？
8.接上条，场景地图中除了基础的ABCD层外，有没有必要增加其他“非方块”图层？我看囧魂的制作团队四块二茶会中的《我是个宝箱，你呢》里面，除了基础的图层还有一层拿来渲染树叶。这个应该是使用了事件生成或者脚本的吧？那么如果把这个做成系统自带的一部分，会不会对创作者的体验更好？
9.脚本相关，如果没猜错的话应该是c或者Ruby写的?如果脚本语言使用别的语言来写，抛开学习成本不谈，你们有没有更亲睐的语言？
10.在开发过程中（尤其是大型项目），你们有没有一个固定的开发流程？如果有的话，是什么样子的？比如说是先设计完整剧情，再实现前端的画面素材？
11.操控角色和npc的高度参数和可拖拽视角（伪3d/真3d都可以）如果开发，会让开发者有更多的可能性吗？（比如在一个荒野地图上，飞行高度高的怪物无法被飞行高度低的角色击中，或者更“真实”的高低差）
12.接11条，如果引擎从单纯的二维贴图变为3d或者伪3d素材，脑测会对开发流程产生多大的影响？有没有拓宽开发者自由度的可能性？
13.对载具有特殊需求吗？
14.好像没了orz 总之先问这么多
给各位回帖的提前磕俩大头，这对我真的很重要，代码写到一半，逻辑端因为底层逻辑的不自洽得推倒重来，尤其是任务系统（类似囧魂的长线任务）和地图系统（原本是按照诡镇奇谭那种美式桌游来的，每张地图牌就是一个场景，后来因为技术上搞不定，才改成了rm的方块地图），现在卡在这了
p.s.如果发错版了请告诉我去哪里合适

编辑:补充三条
15.对”默认之外的战斗”的需求有多大？我这边的战斗系统和rm那种接触进入战斗不一样，是直接在地图里进行战斗的。这种战斗类型在rm受众里欢迎程度如何？创作者们乐于使用这种战斗方式吗？
16.rm对自由破坏建筑和制造掩体的需求大么？这里是指的自由破坏而不是播片，而且是大型建筑，如大楼，工厂厂房这种。用我剧本里的战斗举例，一个角色在地图中战斗，可能随便放一个技能就把整个建筑打飞了，或者是随手从大楼的承重柱里用蛮力像抽龙筋一样把钢筋抽出来拧成钢棍，然后大楼整个塌了。这个时候，内部地图自动变化，且里面的可交互元件也自动变了，无需特殊设定的那种。并且大楼或者掩体有血量，甚至说可以临时砌墙或者用其他东西堵门。这种系统有需求吗
17.创作的时候，除了格子本身，对地图的点和边有没有特殊需求？比如说有特定的对象，不能在格子里，只能在格子之间的边或者点上(类似于文明5和6的河流)

xiaoruis

非常期待

Rinice

小秋橙 发表于 2024-9-9 17:16
作为非常类似 RPG Maker 的 github.com/ckcz123/mota-js 项目参与者，我的回答是：
1. 正六边形和正三角 ...

十分感谢！没想到居然遇见了h5魔塔的开发，有幸在平台上玩过很多使用您的框架开发的作品！
这里的项目使用的kotlin开发的后端，和java是一家，前端目前还没动，目前的规划是使用js+vue+three.js开发

tseyik

倒不如用WOLF RPG 編輯器做

小秋橙

Rinice 发表于 2024-9-6 23:11
经过初步推演，为了保证我的代码能在2026年之前实际运行，我决定放弃六边形，以及边和点上的实体。{:4_11 ...

作为非常类似 RPG Maker 的 github.com/ckcz123/mota-js 项目参与者，我的回答是：
1. 正六边形和正三角形作为可密铺的正多边形，在战棋里肯定会很受欢迎，尤其是正六边形在射程和杀伤半径的计算方面要更接近现实中的圆。
但如果 RPG Maker 本身地图是正六边形的格子，那么操作起来肯定是会有一定的麻烦，需要仿照八方向的移动逻辑（比如说如果up和down能单独生效，那left和right就必须与up或down之一叠加才能生效，反之亦然，具体取决于11楼所说的【方格错开摆放】是行与行错开还是列与列错开。
2. 战场迷雾（临时散去和永久散去的）的需求肯定会有的。
3. RPG Maker 变量系统我觉得最大的可改进点是使用字符串而不是正整数作为索引，至于数据类型其实已经很自由了（主要指基本类型，因为数组和对象有引用问题比较麻烦）。
4. 生成式地图在战棋中感觉只适合用于布景的观赏性而不是地形的游戏性。
5. 我不确定【锁定】功能如果刻意在编辑器层面提供给不会脚本的人，难度和副作用会有多大。但是临时用其他开关、变量配合四则、比较、逻辑运算组成表达式对某个开关/变量赋值我觉得是可行的，需要提供s[n]和v[n]两个语法糖。
6. 异形占位的事件需求肯定是有的，不过不一定非要连续。另外【检测其中发生的所有事情】有点宽泛，对rpg来说感觉应该是每走一步检测是否进入或离开该区域。
7. rmmz的地图共有6层（0~5），其中0~3是图块（mz可以像xp一样自己选择放在哪一层而不像2楼说的一样是自动的，mv则需要用第三方编辑器），4是16种阴影，5是256种区域，楼主说的A1~A5还有B~E是素材的编组。为了防止BUG，一般不建议使用autotile以外的A组图块，而应该只用B~E组，同时B~E组如果作为事件行走图使用则该事件页的优先级不应该设为【在人物下方】。
8. 地图中除了基本的6层以外，还可以使用parallax远景图（文件名开头加上感叹号就是地板效果），或者使用ExtraImage以及无限图层之类的插件。
9. RPG Maker MV 和 MZ 两代都基于 HTML5 技术，脚本语言是 JavaScript（简称js，和Java无关），跟之前几代的Ruby（评论区有人说了确切地说是RGSS）不同，js和json文件都是暴露在外的，可以使用有workspace功能的文本编辑器来方便地编辑。关于更青睐的语言，其实安全性方面我肯定是最青睐Java的，但是限定在脚本语言的话估计也只有lua和Python可以代替js了。
10. 大型项目开发流程取决于人员分工，一般来说至少需要【程序员】和【其他】两个人，人越多越难互相交接。
11. RPG Maker作为90°逻辑俯视地图（尽管楼主在12楼说rm是45°斜俯视但那只是行走图下对齐带来的视觉效果），肯定是可以给每个格子附加z值的，然后就可以做【角色可以走到相邻的[z-n,z+m]高度的格子】的效果（n>m），射程系统也可以基于此设计。
12. 关于视角变换，老实说很不现实，我在 mota-js 项目中做过逻辑3D地图，但也只有三个截面的视角。rm这边不知道能不能用three.js之类的库。
13. 载具系统本身的特性官方语焉不详，所以论坛里都没什么人敢用，生怕出BUG。
15. 默认的Scene_Battle肯定是不适合做战棋的（最多最多只能做轨迹系列的微型战棋），建议砍掉。
16. 非常不建议，rm的设计是【可改变的地形都是事件，通过开关或变量等条件触发改变】，只有这样才会写入存档，所以如果要做很多可破坏地形就要用很多事件。
17. 【格子与格子的左边】、【格子与格子的上边】、【格子与格子的左上角点】是有一一对应关系的，所以……只要约定整个地图的四条边以及这四条边上的点不可用，就能开始动手了。

补充：不是很喜欢2楼对于进阶需求的二极管观点【只有不会用的和看不上的】，人的技术力分布应该是个连续谱。
对于7楼说的【插件全局参数配置问题】，我倾向于【有限多个数据直接放在js文件的开头让用户自己打开修改】、【大批量的格式化数据用外部json/csv文件】，但是两者都不好解决【为数据库现有条目增加深层对象类型的元数据】的问题，伤脑筋。

Rinice

rfvtgbzxc 发表于 2024-9-6 17:35
1.六边形的特点就是有六条边，这个特性是一定要被凸显出来的，不论是直接让素材+渲染都使用六边形的面片 ...

经过初步推演，为了保证我的代码能在2026年之前实际运行，我决定放弃六边形，以及边和点上的实体。六边形绝对会增加资产的复用难度和美工的工作量，而且我的视角不是垂直的，是和rm一样四十五度角向下，并且多个方块会拼合的模式，这就导致六边形很难做出一个完美的矩形建筑物(文明一个方块就是一个建筑物)，至于点和边的特殊实体，我完全可以单独开个格子代表点线面,制作难度大，制作需求小，不划算orz

灯笼菜刀王

Rinice 发表于 2024-9-6 12:21
很棒的思路，但关于六边形区块我有一些疑虑：
1.这样的话美术资源可能不好对齐，因为美术资源是四边形的 ...

6方通行不是非要用六边型格子的,  像三国志11那样,  用方格错开摆放也是具备6边通行的逻辑

□□■■□□
|□■☆■□□
□□■■□□
而这种逻辑下, 方向处理就比较简单了, 左右正常移动,上指定右边格子,下指定左边格子即可, 要到另一边格子无非就是多按一下左或右


15, 地图上战斗和切换战斗画面为可选就是了, 火纹,机战切换画面看表演比较爽, 而皇骑, FFT这种就是直接地图开干, 主要还是看"地图炮"滥不滥, 笑 , 咱是两种模式都有, 玩家可自己设定要看表演还是地图上简化演示

16, 场景破坏物是必须的, 像宝箱一样可以简单的设置成特殊单位, 除了破坏外, 最好还能修复(像咱上面那个敌人去修复补给塔那样), 这样能玩的花样比较多, 笑

流浪杰哥

就像RM一样可视化编辑，编程语言用C#如何？或许也可以试试仓颉？

灯笼菜刀王

rfvtgbzxc 发表于 2024-9-6 11:33
仅回复层主第一点，看到问六边形地图计算模版这事，有点心动，几年以前写过一个。当时游戏设计上要求六边 ...

其实我说的计算模板是像 四方格子距离公式: (x1 - x2).abs + (y1 - y2).abs < 4 ?  这样, 能用一套公式简单的判断距离关系, 主要是用于敌人AI的设计, 毕竟我是通过穷举敌人行动范围来排比出最佳行动坐标, 需要大量的做距离判断, 如果每一次都需要一格一格的判断距离, 那20岁高龄的XP可能吃不消, 笑


▲因为咱的系统较为复杂,敌人行动时判断条件较多, 所以可以明显看出敌人行动回合的卡顿,摊手, 目前咱尽量的以简化的方式来做判断了, 饶是如此, 还是会卡上一两秒, 还没敢让敌人也能判断支援位置, 阵型位置, 光环位置呢

rfvtgbzxc

Rinice 发表于 2024-9-6 12:21
很棒的思路，但关于六边形区块我有一些疑虑：
1.这样的话美术资源可能不好对齐，因为美术资源是四边形的 ...

1.六边形的特点就是有六条边，这个特性是一定要被凸显出来的，不论是直接让素材+渲染都使用六边形的面片还是地面上展示六边形的网格效果，还是其他方案，一定会让玩家感知到。在这个前提下，这个项目的六边形地面实际素材是一张六边形图片，并直接将六边形的边缘用厚线条标明了，通过这种厚线条的重叠来规避一两个像素的对齐误差。以一种很粗暴的方式避免了你说的对接问题。然而你期望的很可能是无缝式的六边形图块，外加整个地图都是这样的图块，到这种程度建议就不要用四边形的图片去模拟六边形了，直接生成六边形mesh，然后自己写shader，将素材贴上去，在mesh层次位置的最小单位不是像素而是浮点数，这样精度足够就没有对接问题了。

2.六边形地图一般没直接手柄操控角色的，其实像rm这样强行划分格子移动，然后假装成按像素即时移动的的也少，一般格子划分出来以后，就是类战旗的操作模式，以回合为单位，用光标去指示移动。六边形设计本身就是特殊的，与玩法绑定，如果你脑补的是整个地图都是六边形构造而成，角色又跟着wasd移动的话，肯定感觉违和。不论是从操作还是渲染都觉得别扭。

3.贴的项目是一个桌游，画面是一个略缩版的世界大地图，六边形边上可以放置道路，点上可以放置城市，军队，面上是这个地区的特征（森林、山脉等），可以放置强盗，商人，不同单位能占据的点位是不同的。