Project1

标题: 我在做一个类似rpgmaker的游戏框架，想咨询一下各位踩过的雷 [打印本页]

作者: Rinice 时间: 2024-9-5 22:04
标题: 我在做一个类似rpgmaker的游戏框架，想咨询一下各位踩过的雷
本帖最后由 Rinice 于 2024-9-6 15:35 编辑

我在做一个类似的战旗游戏框架，也是地图可编辑的，所以想参考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的河流)

作者: 灯笼菜刀王 时间: 2024-9-5 23:37
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-6 00:08
本帖最后由 Rinice 于 2024-9-6 00:22 编辑

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

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

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

作者: 灯笼菜刀王 时间: 2024-9-6 00:27

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

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

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

作者: rfvtgbzxc 时间: 2024-9-6 11:33
本帖最后由 rfvtgbzxc 于 2024-9-6 11:43 编辑

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

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

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

//--------------------------------------------------------
// 获取玩家可定居的点
// 要求：玩家所有的道路附近的点,且这些点以及附近不能有任何人的定居点、城市
//--------------------------------------------------------
function available_points(player_index){
return sQuery("edge",$gamePlayers[player_index].own_roads).near_points()
.not(function(point_id){
if($gameCities.hasOwnProperty(point_id)){
return true;
}
for(let pt_id of sQuery("point",point_id).near_points().get_list()){
if($gameCities.hasOwnProperty(pt_id)){
return true;
}
}
return false;
}).get_list();
}

复制代码

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

作者: Rinice 时间: 2024-9-6 12:21
本帖最后由 Rinice 于 2024-9-6 12:25 编辑

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

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

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

作者: 505681468 时间: 2024-9-6 14:55
↓ 胡说八道 ↓

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

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

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

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

作者: rfvtgbzxc 时间: 2024-9-6 17:35

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

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

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

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

作者: 灯笼菜刀王 时间: 2024-9-6 18:03
本帖最后由灯笼菜刀王于 2024-9-6 18:05 编辑

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

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

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

作者: 流浪杰哥 时间: 2024-9-6 18:08
就像RM一样可视化编辑，编程语言用C#如何？或许也可以试试仓颉？

作者: 灯笼菜刀王 时间: 2024-9-6 18:20
本帖最后由灯笼菜刀王于 2024-9-6 18:30 编辑

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

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

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

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

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

作者: Rinice 时间: 2024-9-6 23:11

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

经过初步推演，为了保证我的代码能在2026年之前实际运行，我决定放弃六边形，以及边和点上的实体。

六边形绝对会增加资产的复用难度和美工的工作量，而且我的视角不是垂直的，是和rm一样四十五度角向下，并且多个方块会拼合的模式，这就导致六边形很难做出一个完美的矩形建筑物(文明一个方块就是一个建筑物)，至于点和边的特殊实体，我完全可以单独开个格子代表点线面,制作难度大，制作需求小，不划算orz

作者: 小秋橙 时间: 2024-9-9 17:16

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文件】，但是两者都不好解决【为数据库现有条目增加深层对象类型的元数据】的问题，伤脑筋。

作者: tseyik 时间: 2024-9-9 19:33
倒不如用WOLF RPG 編輯器做

作者: Rinice 时间: 2024-9-10 00:34
本帖最后由 Rinice 于 2024-9-10 08:58 编辑

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

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

作者: xiaoruis 时间: 2024-9-10 20:19

非常期待

欢迎光临 Project1 (https://rpg.blue/)