@旿圭 我仔细看了植物大战僵尸里面的设计，它的做法似乎比较巧妙；按照我观察的结果，投手抛出物体到其达到最高点之前不修改抛物线，在后半段下落的时候每步检查僵尸位置并减少对应的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的蓝图我一开始也看不懂啥意思
@别再bu开心 不会，本地储存的数据会一直保留，直到用户更换浏览器、删除对应文件或者重装系统为止，所以可以利用本地储存来设计初次进入游戏检测系统。（当然，使用无痕模式、隐身模式的话本地储存会在关闭浏览器时清空，所以开发的时候可以利用这个来调试
@高高M 一些可能的原因：
@别再bu开心 本地储存是把内容存储到设备上，方便下次重新加载；辞典是运行时对象，数据存储在内存里，游戏关闭则丢失修改后的数据。相同点是这两个都以键值对的形式存储数据，不同点就是存储的位置和主要用途不同
@用户217642500 第三步这里关掉了多行文本，那就无法正常进行滚动显示，因为滚动只能上下不能左右。此外，滚动的条件还有一个就是文本的实际内容超过了实例的边界，这样才能执行滚动。
又测试了一下，如果关闭多行文本的话肯定不能使用滚动显示，即使手动添加newline也不能实现换行。
除非文本实例的上下大小比一行文字还要小，这样确实可以保证能滚动，但是这样就没有滚动的意义了。
最后，如果一直不行可以尝试换个浏览器，有些浏览器的渲染效果可能不会完全相同。但是根据你的描述，我觉得最有可能的就是文字内容太少，没有超过实例的上下边界，因此滚动看不出来
