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

灯笼菜刀王

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

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

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


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

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

Rinice

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

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

小秋橙

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

倒不如用WOLF RPG 編輯器做

Rinice

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

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

xiaoruis

非常期待