@旿圭 我仔细看了植物大战僵尸里面的设计，它的做法似乎比较巧妙；按照我观察的结果，投手抛出物体到其达到最高点之前不修改抛物线，在后半段下落的时候每步检查僵尸位置并减少对应的x方向分速度，再配合僵尸的体型一般较大、投掷物碰撞体积较大，很容易实现最终看似精准锁定的效果。
简单写了一个我认为其中难度较高的部分，就是在下落时进行速度微调，从而实现僵尸运动速度较快时也能保证碰撞。
图太大了论坛可能看不了，所以再上传了一下：https://zjxdiu.github.io/zjxmain.github.io/2023-07-15%2012-26-25%2000_00_05-00_00_30%2000_00_00-00_00_30.gif
（这里还有视频格式的：
http://zjxdiu.v6.navy:4921/shared/share/%E5%85%AC%E5%BC%80%E5%86%85%E5%AE%B9/evkworld_example_1689395731.mp4
https://pan.baidu.com/s/1VVdI17WCGUHSQ_ppyvVUbg?pwd=bsqk
事件：
前言：
接触唤境编程以来，已经有至少3人在此方面有疑问，加上我自己也没有深入研究这个内容，因此写下这篇技术讨论帖子，希望有需要的人可以得到帮助。
一、游戏内的计时器
在各类游戏中，我们时常能见到计时器的身影：技能冷却、死亡复活、关卡限时，各个地方都需要用到计时功能。一般来说，计时器根据时间数字变化方向可分为正计时和倒计时，根据功能可分为秒表、限时器、倒计时等。
在唤境中，引擎为对象提供了“定时器”能力，这一能力的具体教程请参考官方视频：
https://www.bilibili.com/video/BV1Qb411u7Nw
二、计时精度
在不同场景下，我们对于计时的精度是不同的。一般来说，秒级的精度足够一些节奏较慢、对时间不敏感的游戏使用了；0.1秒级的精度则适用于一些战斗游戏中技能的冷却计时，毫秒级的精度则在音游中应用较多。
为保证内容统一，本文后续均以毫秒级精度为默认（后面也会介绍如何手动调整至所需精度）。
三、计时器制作方法
1.定时器能力法
这是一种最简单、最方便的一种方法，即利用游戏内的定时器能力进行计时。它具有精度较高、操作方便、上手简单等特点，这种方法也是我最为推荐的。
事件写法也很简单，这里贴出我的实现方法。 
计时模式是用于判断正计时还是倒计时，从而用不同的方式展示计时时间。
核心思路：
①首先用户输入并确定一个毫秒数（也可以用事件指定）；
②点击按钮后，将毫秒数写入全局变量；
③随后启动定时器，设定时间为（毫秒数/1000），因为定时器的预设时间是秒为单位；
④定时器运行中时，通过表达式和运算来展示计时时间；
⑤计时结束后自动停止并输出信息（图中内容用于后续分析）。
很明显，这个思路简单易懂，而且很容易通过标签来区分多个定时器，从而实现多个技能冷却时间同时更新的效果。如果需要将精度下降，只需要在定时器表达式处加一层floor，同时配上合适的倍率乘除即可。
floor(对象.定时器.currenttime("timer")*10)/10 //将精度设为0.1秒级的写法
问题：实际上这种方法基本上是完美的，不过仍然存在一些精度上的问题；根据测试结果，定时器能力在面对不同预设数值时，产生的误差也不同。根据一般实验经验，相对偏差5%以内可认为是正常误差，在此条件下测试发现定时器设定为203ms及以下时相对偏差大于5%。若将精度调整至0.1秒级则近乎完全无法出现显示误差。
不过，在预览模式（帧率为75fps）的情况下，误差基本上都在15ms以内，可认为是1帧的误差。
结论：在时间超过205ms后，此方法的误差几乎不可计，是一种理想的实现方法。
2.系统时间表达式法
此处仅以正计时为例。
这种方式是利用系统内置的时间表达式进行计时。唤境内提供了几种类型的时间表达式，例如unixtime、wallclocktime等，这两个表达式都精确到了毫秒级（区别在于后者会被自动换算至秒级，不过小数部分仍然保留了）。那么根据这些表达式就可以很容易制作一个计时器。
以下是参考事件表（仅考虑正计时，禁用部分为使用unixtime的方法）。
核心思路与上个类似：
①指定计时毫秒数；
②循环输出计时结果，同时判断是否到时间了；
③到时间时立即停止计时，通过动作组输出信号，分析结果。
分析：
根据测试结果，这种方法的误差相比于上一种定时器方法来说会偏低一些，而且在时间非常短（小于200ms）时，计时偏差不会随着时间变短而提高。
但这种方法有其独有的问题，那就是偏差不可控。在定时器方法中，同一个预设时间下的计时误差是趋于稳定的，如果追求完全精确还可以使用事件判断并校正误差。但在系统时间表达式方法中，低计时时间下的偏差是不稳定的，例如测试中使用20ms计时，有时候可以0%完美计时，有时候则差25%之多。
3.帧速率法
此处仅以正计时为例。
与上一种类似，这种方法仍然利用了系统内置的表达式。不同的是，这一次我们从获取原始时间换成了获取帧间隔时间。有关帧率、帧间隔等内容，可以参考我之前写过的教程：https://bbs.evkworld.cn/topic/1911。
核心思路：
①指定计时时间；
②计时开始后，每帧为变量加上一个dt（帧间隔）；
③判断变量达到预设时间后停止计时，发送信号、进行分析。
虽然相似，但这里运用的方式更巧妙：由于唤境的设定，非触发器条件会每帧执行一次，因此我们利用这一点制作了帧间隔敏感的计时器。
dt表达式用于获取上一帧的帧间隔，因此若游戏运行在60fps下，则每秒会执行60次事件，就会加上60次dt；而每个dt都接近16.667ms，至少加上的60次dt一定刚好等于1秒。因此，游戏无论运行在何种帧率下，这种方法都能保证每秒的计时数据都加上了1秒。
分析：
根据测试结果，这种方案似乎是最可靠的。因为它引入了帧间隔，消除了大量的不稳定性，若帧率维持稳定，则几乎每一个预设时间都有其稳定的误差，也就是说可以很轻松地进行误差校准。并且该方法相对于前两种来说，本身的误差也更小，是在计时精度要求极高的情况下最为推荐的方式。更为优秀的是，它产生的误差一般为负值，这对于延迟校准来说显然是一件好事。
不过，这种方法也并非完美。由于引入了帧速率，因此误差会随着玩家帧率变化而改变；如果玩家实际运行的帧率过低，则误差会较大。此外，当计时时间极其短，甚至小于帧间隔时，计时器将完全无法工作（在0秒处即停止），因为从计时开始到结束的时间还不够1帧。
四、方法对比
1.性能对比
实际上我很少关注这些东西的性能，因为即使每帧进行运算、刷新，消耗的性能对于现代CPU来说仍然是九牛一毛。不过我们仍然有必要关注性能，因此我在每个方法的测试中引入了CPU时间的监控。
实际测试结果如下：（仅采用正计时，默认时间单位ms）
注：由于笔记本CPU性能调度策略等问题，不同方法的测量误差可能较大；因此对10s预设使用每次重启游戏的方式进行测试，连续测试3次取均值。
测试结论：在实际游戏中，1.4%的CPU单核占用差距其实可以忽略不计；三者均拥有较好的性能，无需担心计时器的运行会对游戏性能造成影响。
2.横向对比
总结上述研究内容，我们可以得到以下对比表格。
每一格以1为相对高分，包含主观部分。
经过标准化后，再计算NCEF（标准消费者经验指数），则可以得出以下结果：
需要注意的是，此处的NCEF算法未经校准，且表格内包含较强主观因素，因此不能代表实际推荐程度；请根据实际情况使用合适的加权数自行计算并选择。
五、总结
经过了一晚上的探索，我认为收益良多；计时器只是游戏开发中微小的功能，但仍然有足够多的内容值得摸索。其实还有一种通过时间组件来制作的方法，不过我没有足够的时间来尝试，并且认为它的效果与直接使用系统表达式基本一致，因此不作额外尝试。
@申申如也92 创意工坊需要自己想思路，我的想法是可以把编辑器放进游戏内，或者独立出来，然后将编辑的数据存入数组，再用json导出到输入框中，用户复制这个字符串就可以分享了，其他用户只需要粘贴这个json就能玩到这个自制关卡。主游戏需要用相同的方式读取json，然后生成关卡内容。
但是自定义物品啥的基本没戏，画板都很难做。
DLC也可以添加，但很难实现steam游戏的那种模式，最多就是做做番外这种免费DLC。
作为存档保存到本地就好，可以每次触发自动保存和退出存档的时候进行储存，把地图上每个图块的内容存在数组里，下次加载存档的时候再一个个设置，像minecraft就是这么干的
刚解决了这个问题，因此将我的解法思路发出来，以供参考。
提示：由于本人编程能力一般，这个方法应该还有更优解
背景：
使用唤境制作跨平台或PC游戏时，经常会遇到需要使用键盘操作的情况；如果能为玩家提供更改按键绑定的功能，则游戏的可玩性会进一步提高。
比如说PC游戏经常会用W A S D四个按键代表前进、向左、后退、向右四个方向的移动，但有些玩家可能会希望使用↑ ← ↓ → 四个方向键来代替控制。这时候如果能把对应功能的按键改为玩家想要的键，那么玩家的体验会提高。
问题：
我使用辞典来存储每个按键对应的编码，且游戏至少有10个按键，未来可能更多；
现在，我希望玩家每次更改按键时，游戏都会检查更改后的按键是否与原有按键冲突，如果冲突则将提示框标红、弹出通知等进行提醒；
核心问题就是，如何检查新输入的按键是否与原有按键冲突。
以下是我的解决思路：
1.每次输入新按键时，使用动作组刷新按键提示框颜色和按键文本；
2.用一个检查动作组来检查按键是否有冲突；
3.检查用的动作组采用递归方法：
输入一个参数，指定从第几个按键开始检查，将这个按键的编码写入静态局部变量；
循环，从指定的下一个按键开始，逐一比对指定的按键；
若发现冲突，则立即将后者标红，同时改变“对比冲突”的变量值，将信号传递出去；
收到信号后，将动作组最开始被指定的按键标红；
重置信号；
若指定的按键编号不大于总按键数，则将指定的编号+1，然后重新执行这个动作组（递归）。
事件图如下：
一些想法和问题：
1.只检查用户按的那个键的可行性？
由于两方面的影响，我采用了这种看似低效的方法：一是事件内选中的局限性，只检查用户按键的话，要么全部标红，要么自己一定被标红，要么只能标红后面的不能标红自己；二是我的编程习惯，在性能影响不大的情况下，能全部刷新的我都会全部刷新，这样可以尽量避免响应失败的问题。
2.反向检查的可行性？
反向检查是我曾经尝试过的方法，即检查时首先标红自己，然后检查后续按键，每次检查时都先标红，若不冲突再取消标红；理论上是可行的，但是中间会有一些无用功，而且并不能节约变量或者动作组的使用数量。
补充：效果图
@用户216158212
看我的帖子：https://bbs.evkworld.net/topic/3366/
暂时解决方法就是手动把域名里的cn改成net
@风信子hyacinth 虽然我对tilemap研究不多，不过还是提出一下个人的见解。map是用于快速制作网格地图的，最好能将地图中的各种常用元素添加到同一个map对象中，而不是每种元素单独放一个map然后叠加，根据我以前的经验这对性能有很大影响。
如果需要添加一些关键物品（比如地图宝箱），但这些东西又并非在地图中大量出现，我认为正确的做法是单独将其作为精灵生成在地图上，碰撞等事件单独编写，这样做的话性能会较好
因群里有成员对这方面存在疑问，所以写一篇文章详细解释下游戏内性能相关。
需要注意的是，本人对于唤境中这些内容的最具体理解未必到位，因此可能出现一些技术细节上的错误，希望大佬能指出错误，感激不尽！
为了保证一般开发者也能看得懂，文章会尽量避免非常专业和硬核的描述，相应地就会降低严谨性。如果有兴趣深究，请查找更专业的资料。
此外，本文并非是针对唤境游戏的性能优化而写的，如果您的引擎或者制作的游戏出现卡顿，请前往b站查看小嗦大佬的教程
传送门：https://www.bilibili.com/video/BV1wg411E7oF
接下来是正文：
通常情况下，我们会通过几个方面来评估一个游戏运行的性能表现，分别是帧率、帧生成时间、CPU占用、GPU占用、内存占用、显存占用等。
游戏之所以能呈现动态的画面，是因为它会以一个很快的速度生成画面，每秒几十张甚至上百张，其中每个画面就被称为一 “帧” 。因此，帧是游戏画面在时间上的最小单位。
于是，我们有了帧率的概念。帧率，就是每秒钟游戏生成的帧数量。很明显的，帧率越高，我们肉眼感觉到的画面就越流畅，反之则越卡顿。当帧率为0时，游戏就停止在一张静态的图片上。
一般而言，当帧率达到60时，人眼观察到的画面就可以称为“比较流畅”了。
有了帧率的概念，我们就可以引入帧生成时间的概念了。
游戏引擎每生成一帧画面，都需要消耗一定的时间，这个时间就称为帧生成时间。
帧生成时间波动是造成瞬间卡顿的原因之一。设想一个极端情况，在运行的某一秒里，游戏花了0.9秒来渲染第一帧，然后在剩下0.1秒里渲染了剩下的59帧。这时候的平均帧率还是60，但是你在玩的时候就会明显感觉到游戏发生了一次剧烈的卡顿，因为这0.9秒的时间内游戏处于静止状态。
帧生成时间和间隔的定义，严格来说并不是完全一致的，但本文并不是进行画面技术研究，所以暂且认为它们是同一个概念。
在计算机中，CPU负责通用计算，也就是任何计算理论上都可以由CPU完成。在游戏中，控制游戏系统运行、通过公式计算数据、运行函数等都是由CPU完成的。最开始的时候，游戏画面的渲染也是由CPU完成的，但后来人们发现CPU难以胜任这一要求，于是将这个工作交由GPU完成。有关这一段历史的发展，详见https://www.bilibili.com/video/BV1Hb41177JB
对于现代电脑和手机来说，它们的CPU性能都相当强大，可以完成非常密集的运算需求。但它们的性能也不是无限的，而且在手机、笔记本电脑上，CPU是耗电量非常大的元件。所以，CPU会直接影响游戏的性能表现，降低CPU的占用率也可以有效提高游戏运行的效率，以及在低端设备上成功运行的可能性。
前面提到了，GPU是用来替代CPU来完成画面渲染工作的硬件。所以，GPU是离游戏实际画面最近的硬件，因为游戏画面就是由它生成的。
GPU负责的内容就是渲染画面，例如显示图片、文字等。
对于唤境来说，由于唤境只是2D游戏引擎，因此对于现代GPU来说压力比较低，但还是存在运行效率过低的情况。
有关GPU运行解析的内容请见官方教程https://evkworld.cn/wiki/58
显存，又称显示内存、显卡内存、图形内存、视频内存等，是显卡用来储存图像信息的临时空间。
对于集成显卡（例如手机）而言，显存就是从内存中分出来的部分；对于独立显卡（例如高性能电脑）而言，显存是单独集成在显卡中的一个存储器。所以，当游戏在手机上运行的时候，游戏会同时消耗两份内存空间，一部分用于程序运行，另一部分充当显存。因此，如果您的游戏在电脑上运行很正常，而在低端手机上就无法运行或者特别卡顿，则有可能是因为游戏消耗了较多的显存和内存。
唤境引擎并没有提供性能监控相关的组件和能力，但可以通过表达式获取到性能数据。
所有相关表达式都在系统部分中。
表达式：fps
刷新频率：每秒1次
返回值类型：整数
建议使用方法：直接通过表达式获取帧率即可。
表达式：dt
刷新频率：每帧1次
返回值类型：单精度浮点数，即6位小数
（当测量单帧间隔时会返回10位小数）
其它：引擎内描述为“时间间隔”
建议使用方法：先将数据乘以1000，然后使用roundto()将其化简到1-3位小数，最后加上单位“ms”（毫秒），即可得到友好的数字展示。
表达式：cpuutilisation
刷新频率：每秒1次
其它：引擎内描述为“CPU在游戏中消耗的时间”
返回值类型：双精度浮点数，即18位小数。
建议使用方法：先将数据乘以100，然后使用roundto()将其简化到1-2位小数，最后加上百分比符号“%”，即可得到友好的数字展示。
表达式：gpuutilisation
刷新频率：每秒1次
其它：引擎内描述为“GPU在游戏中消耗的时间”
返回值类型：9位小数。
建议使用方法：与CPU占用相同。
表达式：imagememoryusage
刷新频率：每帧1次
返回值类型：9位小数。
建议使用方法：直接通过表达式获取即可。
光了解了上面所有的信息，但如果不会用，那就都是白搭。接下来，我会一步步解释如何制作游戏内的性能监控悬浮窗。
1.打开游戏项目，新建对象：一个文本、一个精灵和一个按钮，精灵的贴图替换成一张长方形图片即可
2.新建几个全局变量，“启用测量”、“悬浮窗x”、“悬浮窗y”。其中，第一个是布尔类型变量，是必需的；后两个是数值类型变量，不是必需的。
后两个的初始值不建议设为0，应该根据你选择的默认位置来设置。
3.新建一个图层组“悬浮窗”，设置为全局图层组，然后将精灵、文本和按钮拖入该图层组中，调整文本和精灵的大小及属性，文本选择左对齐、上下居中对齐，大小跟精灵差不多一样大就行
4.为文本添加拖拽和定时器能力，为精灵添加绑定能力
5.新建一条全局事件表，名称为“性能监控窗口”，或者任何你喜欢的名字。
6.开始写事件。可以参考我下面的这种设计方案。
核心思路：
（1）当“启用测量”变量为“真”时，显示文本和精灵，否则隐藏；注意，不要重复触发，可以加入一个触发器（例如“仅触发一次”）来解决；
（2）制作好看的文本排版；
（3）避免每帧检测和每帧改变文本；
（4）（可选）实现悬浮窗的拖动，以及位置记忆。
文本内容供参考：
"帧率：" & fps & newline & "CPU：" & roundto(cpuutilisation*100,1) & "%" & newline & "显存：" & imagememoryusage & "mb"
7.在每个你希望有监控悬浮窗的场景下都新建一个叫做“悬浮窗”的图层组，不需要放入任何内容，因为你之前已经选中了全局事件表。
然后将刚才写的全局事件表应用于每个你希望有悬浮窗的场景。
8.检查效果
9.可额外优化的内容
提示：只需要使用一个能力即可解决。
提示：绑定能力。
通过这一篇文章的解析和教学，你应该对唤境游戏的性能及其监控方法有了一定的了解。
在多数情况下，唤境游戏其实并不需要这么多高级的技术细节，但这类功能可以给你的游戏添砖加瓦，起到锦上添花的作用。
文章撰写仓促，部分内容做不到非常细致和详尽，也可能有错误，欢迎大佬前来指正！
额外优化内容答案：
（1）给文本和精灵分别添加“边界限制”能力即可；
（2）在启用测量为假的时候，给精灵添加一条动作：“取消绑定”
@孤獴网络独立人 方法比较多，这里写一下我的思路：
①我自己使用过的：主条件为当任意触屏开始时，然后用“正在触摸对象时”条件取反，这样可以做任意对象数量的点击判断；
②点击鼠标时，悬停于对象时取反，原理大致同上；
③点击鼠标时，按覆盖点选中需要判断的对象（鼠标操作.x，鼠标操作.y），然后比较两值，如果 对象.pickedcount = 0 ，则认为没有单击图片
（原理是，pickedcount表达式用于获取满足条件的选实例数量，所以前面通过覆盖点选中后如果该值还是0的话说明鼠标处没有这个对象）
最后是我用过的事件
补充一下，根据我的使用情况，“正在触摸对象时”这个条件是上升沿判断触发，所以前面主事件的条件最好使用“触屏开始时”，而不是触屏操作的“点击时”。
@旅的途中beat 有幸用过unity和虚幻4，说实话唤境的界面已经足够友好了，unity我进去连新建场景都找不到，虚幻4的蓝图我一开始也看不懂啥意思
@redial_later 唤境近期状态不佳，用于跳转的网页目前是挂了，所以是一片空白的；有一个比较简单的解决方法，把这个网页链接复制出来，得到一个类似于“https://www.evkworld.net/g/123456”的链接，其中123456是作品ID；然后手动输入链接“https://g.evkworld.net/123456”，后面的123456换成刚才的作品ID，然后就可以正常加载了
补充一下，如果只是想测试自己发布的游戏，也可以手动进入唤境创作者中心（https://developer.evkworld.net/），左边的版本管理里面找到自己的游戏，点h5的打开游戏就能进入了
@youke2003 第三行这里的动作有误，点击按钮的时候不是再加载一次XML，而是直接使用表达式获取值即可。例如你想设置文本内容，就直接使用设置文本的动作，其中的内容填写你这里的表达式
@程宇游官方制作账号 不支持热更新，实际上热更新技术是限制比较大而且不好实现的，唤境目前无法对客户端实现。不过网页版本会自动同步最新版本。
或者如果针对PC版本，我写过一个批处理程序可以实现近似的自动更新技术。大概就是将这个批处理作为一个启动器，每次打开的时候检查是否有新版本，如果有则自动下载解压并替换文件。当然这个文件早就找不到了，但大概只需要一点简单的cmd、curl和7zip命令就能实现
@昼辞怎么又在摆烂 简单做的话试试“固定位置”能力（官方教程：https://evkworld.net/learn/254）
如果要做更复杂、兼容性更好的，建议每次初始化场景的时候单独设置每个UI的位置，可以使用表达式获取画布大小等（参考手册“系统”：https://evkworld.net/wiki/117）
@鸢犴 官方已经下架了所有下载方式，暂时不能从官方渠道获取了；理论上来说应该等官方开放，不过如果需要的话可以在网上找。也因为这个原因我没办法直接分享链接。
也可以加我QQ，确实需要的话请私聊回复（
@烂鱼冉遗 花了几个小时写了一个符合我思路的事件，需要的话可以参考。
首先说明一下，这些代码我自己完全没有测试过，不保证可用性；但按我的理解来说应该可行，最多就是推出可能需要换成删除、数组写入后需要等待0秒防止异步问题之类的。
先来看一下系统设计思路：
左边是音效播放结束检测，右边是需要播放新音效时的流程。
然后，首先写音效主体动作组：
这个动作组对于队列已满的处理是调用另一个动作组，所以写这个：
然后处理已播放完的音频：
这样整个系统的功能基本上就完成了，当然我自己能看出来一种问题，就是如果同一帧里刚好出现音频播放结束和需要播放新音频的事件时，可能会导致数组长度变化（也是异步导致的问题）；如果真的有这个现象，可以在每0.3秒的检查里加一个数组宽度的检查，如果超出设定值则重置宽度。
场景初始化需要单独的事件：
@阿郁 我也只是网上搜索然后翻译一下，我对安卓开发基本没啥理解的
所以可能这些方案没啥用，不过希望能帮到你
@阿郁 双清就是恢复出厂，不过如果换软件也不行的话可能这样就没啥用了，换个设备再试试；这种问题我自己没有遇到过，而且直觉上来说应该跟你的事件关系不大。
stack overflow上查了一下，这个问题的原因很可能是唤境服务器打包的时候发生的，所以重新进引擎再打包一次看看（记得打包apk，然后网页浏览器、唤境app和下载的apk都试一下）
然后还是说一下我发现的一个问题吧，第7行这里在检查是否存在之后应该先用获取事件获取值，如果不获取的话很可能itemvalue是空内容。
另外第6行这里，在写入本地储存的键值后进行检查是一个好方法，但是由于唤境的本地储存组件写入操作都是异步进行的，因此在执行写入动作后建议间隔一段时间再检查是否成功，否则3-6行代码可能会反复执行多次。当然多数情况下不会产生问题。
具体可见官方教程：https://evkworld.net/learn/291
