m1615690513 发表于 2023-7-24 11:35
将HTML内容嵌入到Canvas中是相对简单的，只需要在GameCanvas的上层添加一个UI容器（DOM）来承载HTML内容 ...

您好楼主，我已经跑去unity并且已经实现自己想要实现的功能了
rpgmaker固然简单，但是局限性还是太大
感谢楼主半年前的回复

RuanZhongNan 发表于 2023-7-19 11:24
兄弟，有github仓库么？我手痒了，想写vue3组件了。

目前仓库为游戏本体仓库的独立分支，暂时为私有仓库，暂不公开。

恩凡 发表于 2023-7-20 20:08
大大您好！我刚好遇到了一个相关的问题，请问您可以指点一二吗？
https://rpg.blue/thread-493806-1-1.html ...

将HTML内容嵌入到Canvas中是相对简单的，只需要在GameCanvas的上层添加一个UI容器（DOM）来承载HTML内容。

然而，在实现中确实需要考虑一些问题，例如事件传递和冒泡。Canvas本身无法直接捕获和处理DOM事件，所以原来的Canvas将事件注册到全局document对象上。

所以你还需要考虑来自GameCanvas已经定义的全局事件（例如document上的事件）。你需要思考新增的UI容器是否需要支持这些全局事件。如果需要，你可以将这些全局事件传递给UI容器，让它能够相应地处理这些事件。这包括在全局事件处理程序中判断事件的目标元素是否属于UI容器，并相应地处理事件。

除此之外你还需要考虑DOM与Canvas风格的一致性：
大致可以从以下几点来做：
1. 字体和字号：确保在Canvas中嵌入的HTML内容的字体和字号与Canvas中的绘制一致，以保持整体视觉风格的统一。

2. 颜色和背景：根据Canvas的整体配色方案，调整嵌入的HTML内容的颜色和背景，以使其与Canvas保持一致。

3. 边框和阴影效果：如果Canvas中有特定的边框或阴影效果，尽量在嵌入的HTML内容中进行相应的模拟，以使整体效果更加一致。

4. 响应式设计：确保嵌入的HTML内容能够适应Canvas大小的改变，保持响应式布局，以提供一致性的用户体验。

嵌入HTML开发在现代前端开发中的应用旨在帮助前端开发人员更好地参与到RMMV（RPG Maker MV）的开发和建设中，而不是鼓励普通的JavaScript程序员学习HTML和CSS并从头开始独立开发。

通过嵌入HTML，前端开发人员可以利用他们已经掌握的前端技术知识和工具来与RMMV进行集成，为游戏添加自定义的UI和交互元素。这样可以提高开发效率，并且能够充分利用现有的前端生态系统和资源。

对于普通的JavaScript程序员来说，学习HTML和CSS去实现嵌入式开发可能是一个额外的负担，并且可能并不必要。他们可以专注于他们已经熟悉的JavaScript开发，通过使用RMMV提供的API和扩展机制来实现游戏逻辑和功能。

大大您好！我刚好遇到了一个相关的问题，请问您可以指点一二吗？
https://rpg.blue/thread-493806-1-1.html
谢谢！

兄弟，有github仓库么？我手痒了，想写vue3组件了。

rfvtgbzxc 发表于 2023-6-30 12:09
想了解一下，前端做UI的话，这两个问题楼主认为是否算问题，是否有解决方案：
1.要做美观很麻烦，对比现在 ...

非常感谢你的回复,也非常感谢你的点赞。

事实上，我倡导在适当的情况下使用HTML进行开发，而不是用HTML代替原生Canvas/WebGL。简单来说，我们应该根据简单易用、方便的原则来选择使用方式。尽管使用HTML可能会带来一些性能提升，但是由于受到多种因素的影响，我建议我们可以忽略这方面的提升，而将注意力放在它们各自的特性上。这个项目的初衷是扩展RMMV的开发生态，吸引拉拢现代前端开发人员，并使这部分群体能够轻松开发RMMV的UI界面，无需深入学习RMMV和PIXI.JS。（也是作为我们自己Conquest项目中重要的一环）

另外，我还想补充一下关于UI、游戏逻辑和游戏中产生的动画之间的概念关系。以下是我个人的浅显理解：

UI（User Interface，用户界面）是指玩家与游戏进行交互时所看到和操作的界面。它包括各种可视化的元素，如按钮、菜单、指示器等，以及与之相关的布局、样式和交互设计。UI的目标是提供清晰、直观和易于操作的界面，使玩家能够方便地控制游戏和获取相关的信息。

游戏逻辑是指游戏中的规则、事件和逻辑流程。它处理游戏中各种操作和事件的发生，包括玩家输入和游戏状态的变化。游戏逻辑负责判断游戏胜负条件、控制游戏进程和计算游戏中的数值等。它通过编程算法和条件判断来实现游戏的核心逻辑。

在游戏中，UI和游戏逻辑之间有密切的关系。UI元素往往是玩家与游戏进行交互的媒介，它通过按钮、滑块等交互元素接受玩家的输入，并将输入传递给游戏逻辑进行处理。游戏逻辑则根据玩家的输入和当前游戏状态进行相应的计算和判断，同时还会更新UI来反馈给玩家游戏的变化。

游戏中产生的动画则是在游戏逻辑过程中通过UI展示给玩家的视觉效果。这些动画可以包括角色的移动、攻击、跳跃等动作，以及特效、场景切换、过渡效果等。这些动画通过游戏逻辑根据当前的游戏状态和规则进行控制和展示，以增强游戏的可玩性和视觉效果，给玩家带来更加沉浸的游戏体验。

综上所述，本工程的目的就浮出水面，让那些操作界面可以交给HTML DOM来实现，那种与游戏逻辑紧密相关的内容则采用PIXI.JS原生实现更好。其目的将操作界面交给HTML生态，而PIXI.JS则可以专注于游戏动画效果的设计上，这样就可以充分利用了HTML和PIXI.JS各自的优势。

想了解一下，前端做UI的话，这两个问题楼主认为是否算问题，是否有解决方案：
1.要做美观很麻烦，对比现在常见二游的UI，前端的组件库在插值动画、各种变换方面很难写。
  例如原神的圣遗物界面，是一个绕角色旋转的圆环，不提角色本身和圆环间的遮挡关系，这种3D空间内一组元素的绕轴旋转，近大远小的效果是难靠CSS和dom的位置元素实现的。
  又例如选中各种物品时，物品一瞬间的发光效果和持续纷飞的粒子特效，mog插件中使用了大量sprite来绘制，而用前端的dom来实现，性能消耗恐怕不小。
2.要表现复杂的内容也很麻烦。例如绘制条形图、饼图等，这些在前端中都是直接使用echarts来绘制，本质上还是一个canvas，想写一些效果绚丽一些的填充，最后还是难免自定义着色器。
本质是，一些要使用大量精力去设计CSS才能达到的效果，在原生绘图环境下是非常容易达成的。
前端的UI在数据交互和模块化管理上很优秀，可以适应各种复杂的数据表单和高频变更的开发需求。但是动效方面很差，如果存在有优秀动效的库的话，前端做UI就优势很大了
另外看到老哥发布的是基于MIT的开源项目，点赞~

也算是一种解决方案思路吧，期待后续

闪电超重火炮 发表于 2023-6-30 08:07
不会，你想多了

我深感谢你对这个问题的关注，并对你提出的观点表示尊重。对于UI和游戏逻辑的分离模式的讨论，不同的人有不同的见解和经验，因此也存在各种不同的实践和成功案例。

实际上，对于每个具体的项目和情境，可能需要根据需求和实际情况来确定最佳的开发架构和技术选择。在游戏开发中，UI和游戏逻辑之间的分工可以因情况而异，有时强调分离，有时则紧密耦合。

因此，我要再次强调，将UI和游戏逻辑分离的做法的有效性和性能优势是需要综合考虑众多因素的。我非常感谢你的观点和问题，这促使我对这个话题进行更深入的思考。

因素参考：
应用复杂性：应用的复杂性对于分离UI和游戏逻辑的可行性和效果有很大影响。如果应用有较简单的UI和较简单的游戏逻辑，则分离的收益可能较小；而对于复杂的应用，分离能够更好地管理和优化UI和游戏逻辑。

性能需求：性能需求是决定是否采用分离模式的关键因素之一。如果应用对帧率、动画效果或图形渲染要求较高，分离UI和游戏逻辑可能能够提升性能；而对于简单的应用，分离可能不会带来明显的性能改进。

浏览器支持与兼容性：将UI使用HTML DOM渲染，游戏逻辑使用WebGL/Canvas等技术，需要考虑目标浏览器的支持与兼容性。不同浏览器可能对技术的支持程度有所差异，这可能会影响分离模式的实施和性能结果。

设备能力：不同设备的性能和能力也会对分离模式的效果产生影响。较强大的设备可能更能充分发挥WebGL/Canvas等技术的优势，而较低性能的设备可能无法获得明显的性能提升。

开发与维护成本：分离UI和游戏逻辑可能会带来一定的开发与维护成本。需要投入额外的精力来处理不同技术之间的交互、数据同步和通信等方面的工作，并确保整体的一致性与协调性。