我在做一个类似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的河流)

灯笼菜刀王

1, 6边型地块如果有方便的计算模板套用,  例如判断某一坐标3格范围内的公式, 我是很想用的, 如果有可视化的地图编辑器那就更好了, 毕竟6边型地块能有更多的空间互动关系,  而且, 图块不用限定6边型, 方形图块也可以摆出6边范围 , 像这样
□□□□
□□□□
□□□□
次行错开半格即可

2. 战争迷雾分两种


一种是开图式, 走过后就会消除迷雾


一种是火纹式, 在单位视野内敌人才会现身

两种都有需求, 笑

3, 没理解你说啥, 反正会代码的不在乎是什么变量, 不会代码的也分不清是什么变量, 感觉无所谓, 笑

4, 随机生成的地图我也有做, 不过我是用于"非正式关卡", 就是派一队成员出去远征, 然后随机产生战斗, 地形敌人种类都是根据一定的词条随机生成。

随机生成的地图有个缺点, "对于作者不可控", 因此, 这种地图无法保证合理性和难易度, 不太适合需要严谨计算的战棋。

我的情况是因为题材是舰娘, 战斗场景为海面, 海面宽阔障碍少很正常嘛, 笑, 而且我并不追求难度, 不在乎玩家刷级和虐菜,  此外我的战斗支持随时撤退也不会GAMEOVER,  所以没这个顾虑才用之, 而且也不会用于正式关卡, 笑

5, 这种类型的变量和开关是很方便的哦, XP有相关脚本传送门
不过嘛, 比较尴尬的地方是, 该脚本使用有门槛(需要会写表达式), 而能到达这个门槛的, 基本自己就能搞定这类情况了,笑
所以要做这种, 还是需要参考事件化模式, 尽量避免让用户自己去写表达式, 笑

6, 范围触发, 咱也有写过这种功能的脚本 传送门

7, 你有用过XP的话, A1234可以视为最下层,也就是地板,, BCD视为放在地板上的东西, 但是MZ不像XP可自由摆放到任意图层, 它们的"图层关系"是固定的
XP的自由图层当然有其优点, 可画出更复杂层次的地图, 但是缺点也很明显, "不够傻瓜",  使用需要有图层相关知识, 入门的门槛较高, XP画一张地图所需的时间是后继版本的数倍。
而XP之后的版本都取消了这个自由图层可见如今的市场方向, 笑。 "专业"和"易用", 两者可很难兼得哦

8, 多层远景, 这个需求是挺高的, 其实战争迷雾, 天气等也算是额外图层呗, 然而和上面一样, 这算是"进阶需求", 在不影响"易用性"的前提下再来考虑比较好, 毕竟, 有这种需求的高级用户, 总是有办法自己搞定的, 笑

9, XP,VX,VA使用ruby(应该叫RGSS, 基于ruby的游戏功能特化语言)是为了降低学习门槛,  MVMZ用JS是为了兼顾网页, 算是"时代需求", 笑,  如果要用别的语言, 建议使用方便兼顾移动端的语言, 能大众化,降低学习门槛更好XD

10, 我的话, 先做系统, 再补素材, 然后填数据库, 平衡数值, 最后再来填剧情, 毕竟咱属于玩法优先派, 笑

11, 对应需求自然是有的, 咱也有类似的(海陆空潜 4种维度), 当然该功能需要可选, 不过最重要的是方便使用且尽量不要搞得臃肿, 这是RM系列相比unity的优势之一咯, 笑

12, 咱并不喜欢3D, 不如说, 需要3D干嘛要在RM上吊着呢, 转头入unity不好么, 笑, 当然, 如果你能把3D编辑搞得和2DRM一样方便直观, 那也是不错啦

13, 本站几乎每个月都有"重装机兵系统"的相关需求帖子, 笑, 能像定义宝箱一样, 方便的定义载具单位,需求应该蛮大的

Rinice

灯笼菜刀王 发表于 2024-9-5 23:37
1, 6边型地块如果有方便的计算模板套用,  例如判断某一坐标3格范围内的公式, 我是很想用的, 如果有可视化的 ...

十分感谢。以及您这边除了上述提到的内容外，有没有其他的，rpgmaker里面没有内置，但实际上需求量很大的功能，或者那种特别急迫且大众的功能想在未来版本中使用的？
至于第三条，变量是指的事件里面的系统变量，只能输入整数。我的意思是如果系统变量能输入小数点或者传递字符串，甚至说存储图片或者文件，能不能有帮助

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

灯笼菜刀王

Rinice 发表于 2024-9-6 00:08
十分感谢。以及您这边除了上述提到的内容外，有没有rpgmaker里面没有内置，但实际上需求量很大的功能，或 ...

这里是一个只用XP且很早以前就不做常规RPG的制作人, 笑, 对于目前主流的MVMZ有啥需求不是很清楚, 等之后的人来说吧~

至于你说的系统变量, 从XP开始都可以输入任何实例(只不过XP需要用脚本栏输入, 其他版本在变量设置里就有脚本框可直接输入)

rfvtgbzxc

Rinice 发表于 2024-9-6 00:08
十分感谢。以及您这边除了上述提到的内容外，有没有其他的，rpgmaker里面没有内置，但实际上需求量很大的 ...

仅回复层主第一点，看到问六边形地图计算模版这事，有点心动，几年以前写过一个。当时游戏设计上要求六边形地图的点、边、面上都能放置单位，且它们之间各有交互。
例如要能计算边的最长路径，而且路径上经过的点不能有敌方的单位。
例如要能获取一个面附近所有的面上的所有的点，这些点如果有单位，给予某种debuff。

为了保证性能，又方便地做到这些查询，写了一套底层的数据结构和一个类似jQuery的查询执行器。可以链式地对一批点/边/面按自己的要求查询/处理周围的点/边/面，并反复处理直到完成目标，类似于

1. 
   
2. //--------------------------------------------------------
   
3. // 获取玩家可定居的点
   
4. // 要求：玩家所有的道路附近的点,且这些点以及附近不能有任何人的定居点、城市
   
5. //--------------------------------------------------------
   
6. function available_points(player_index){
   
7.         return sQuery("edge",$gamePlayers[player_index].own_roads).near_points()
   
8.         .not(function(point_id){
   
9.                 if($gameCities.hasOwnProperty(point_id)){
   
10.                         return true;
    
11.                 }
    
12.                 for(let pt_id of sQuery("point",point_id).near_points().get_list()){
    
13.                         if($gameCities.hasOwnProperty(pt_id)){
    
14.                                 return true;
    
15.                         }
    
16.                 }
    
17.                 return false;
    
18.         }).get_list();
    
19. }
    

复制代码

贴个链接，https://github.com/rfvtgbzxc/Katanisland-web
六边形地图设计思路：https://www.mubu.com/doc/Km3myHlOS0
架构上相比现在的前端架构很落后了，不过六边形地图的核心没什么变化，而且这个虽然是js写的，但是命名风格和ruby很像，当时学着mv的api写，mv又是学着rmxp时代的命名风格，分享一下。

Rinice

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

很棒的思路，但关于六边形区块我有一些疑虑：
1.这样的话美术资源可能不好对齐，因为美术资源是四边形的，虽然六边形很漂亮很科技，但是如果使用像素风开发可能会导致边缘对接出问题，而且素材库里的四边也要改为六边，除非说改为伪3d或者3d，不是用单个平铺的图层来展现。您这边是怎么做到美术资源对齐六边形的？
2.上下左右的操作逻辑会出问题，因为多了两个维度，会让电脑玩家或者手柄玩家感到不方便，而对触屏端来说这样的操作也没有太大提升。
优点是看上去能更漂亮，但缺点过于明显，除非能找到其他弥补缺点的方法或者发掘这种操作的更多优点，否则我很难去使用六边形区块作为默认区块

至于点和线边上放置单位，除非说点和线上的单位是特殊的，和面上的单位类型不同（强类型），否则我不太理解为啥有这个需求

505681468

↓ 胡说八道 ↓

插件开发用户和编辑器用户在游戏开发中的路子应该不太一样

但是作为插件开发者，我觉得两者在rm中都会遇到一个问题
-> 插件的数据库的配置

一些不在rm原生范围内的功能，例如解谜游戏线索
这些跟角色、道具、技能无关的就不好往rm数据库中的备注塞了

如果插件引用的数据库层级过深，那将会是一个噩梦
就算接受了配置的困难，插件数据库的可读性也是难以凑合

rfvtgbzxc

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

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

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

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

灯笼菜刀王

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

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


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

流浪杰哥

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