【已弃坑】Mario Forever - ZL Constructor - Alpha 1
本帖最后由 电童·Isamo 于 2023-7-24 20:31 编辑本引擎旨在还原MF手感,同时将godot的运动单位pix/s转用为pix/frame,更易于惯用CTF的老开发者开发
(当然,出于Godot中大量node可能会导致的游戏的流畅性下降,不可能做到所有行为均node化,但我会尽最大努力去把每个物件的对应行为抽象成操作这一行为的node来供开发者使用)
因个人开发需要,加上引擎架构混乱,故本工程弃坑,新工程将在另一个帖子中进行公示
这里依旧保留Alpha1版本的下载,以备不时之需
下载地址(键入:azr4):
Alpha 1:点我下载
本帖最后由 电童·Isamo 于 2023-7-24 20:27 编辑
通知:
由于Godot4.0对老电脑兼容性不够友好,决定暂时停止Z Editor的开发,转回Godot 3.x引擎的开发
重写一个新的引擎,暂定名ZL(就是Z Lower的缩写,Z Editor的低配版)
本贴开发进度更改为ZL Editor的进度
待Godot4.1发布并兼容GLES3后再复坑
(虽然我知道4.1很香但是想要4.1需要一两年时间,而且需要4.1能支持GDScript1.0,或者需要一个近乎完善的GDScript 1.0 -> GDScript 2.0转换器)
果咩
7.24追记
写追记的时候,4.1已经发布了(其实4.2的测试版也已经出来了),但是由于Godot过于激进式的更新,导致4.1的优化不如4.0,且本人已经打算重新制作一个基于4.0特性的架构,因此本帖锁帖,将在新帖中开贴记录引擎开发日志
本帖最后由 电童·Isamo 于 2022-9-7 00:19 编辑
9.7 凌晨 更新心得
目前工程进展得很顺利,
照着并对比自己更早一些时间写的Xeno Engine,这个引擎的代码架构更加清晰,使用更为方便,功能更为强大。
至少,得益于godot的高度自由性和、godot的类的高度封装性和gdscript的高度简易性,有些在CTF上做上去很难的东西,在godot上却只需要几行代码即可完成,
显得十分舒畅。
感觉好久都没有写过这么让人写完还想写的代码了(笑
本帖最后由 电童·Isamo 于 2022-9-8 23:14 编辑
9.8 更新日志
今天在编写的时候突然发现之前写的大量的get_overlapping系方法+for循环内加is检测的配合,大大降低了代码的可复用性。为了解决这个问题,我写了五个可能会比较实用的方法来负责操作is的检测,再将is筛选后的数据返回。虽然说还是无法避免for i in Array的结构,但是至少代码的复用性高了许多,简洁性也有了一定的改善。
针对这个方法,我也是把以前写的同类代码进行了修改,运行后,改之后的代码跟改之前的相比,效果基本一致。
不过今天晚上写这个方法还是比较肝的,有点累了,准备上床了。 本帖最后由 电童·Isamo 于 2022-9-16 23:37 编辑
9.14更新日志
写到一半突然推倒重做,主要还是因为推倒前的ZL结构太混乱了,没布局好,导致在编写过程中不停地出现一些结构性问题。
虽然说,推倒重做后的ZL引擎的一部分代码还是直接来自推倒前的,但是我也会尽量会以新的方式再写一遍之前写过的代码
毕竟,代码敲百遍,其意自会现嘛(( 9.26 更新日记:
今天唯一一个比较遗憾的是没能按时更新Godot教程,但让我弥补这个遗憾的,则是我发现了Godot中只需要非常少量的代码就可以修复站移动实心会导致玩家错位的bug。
与此同时,我要感谢Storm Engine提供了优化音效实现效果的思路,使用AudioStreamPlayer2D节点来播放音效,该节点可以让播放的音效的音量能够根据该节点距离镜头中心的远近来进行调节,距离越远则越不会让人耳听见该音效。
同时,接下来打算大改一大堆的对象场景,工程量还是比较大的
10.4 更新日志
明天假期就结束要返校了。之前在学校写的代码,虽然看着还是一坨屎,但是我这次不管了,至少比之前写的效率高了不少(X
要是真有需要优化的地方,那就等到你们反馈了我再去优化吧。
说回正题,这次我终于把平台给加进去了。之前都是打算先把怪物处理完毕以后再写平台的,这次我觉得应该先把平台给写好,之后再慢慢填坑。这样的话也可以给之后要加的敌人提供一个不错的要考虑方向嘛,省的后面搞出事(((
顺便,前一阵子也测试了一下Audio的fade,突然发现之前写的有很多问题,其中最突出的有两个:一个是,缓存一个fade音乐用了四个数组,占用变量声明空间,虽然声明不同的变量解决了变量名理解性的问题,但也给后期维护带来了隐患;另一个是,缓存的fade音乐,只是直接粗暴地被append进了数组,而对于已经在fade缓存区的音乐来说,却直接被函数的return给断掉了,这就导致以较高的频率切换音乐时,如果是渐变切换音乐的话,就会导致有些音乐本应播放的却还没来得及播放,同时也会导致有些音乐来不及淡出播放而产生一系列新的问题……。于是我前天大改了Audio的方法的fade:只用一个数组来缓存,但是该数组是个二维数组,其中的内数组代替了之前的四个数组,直接将之前四个数组内的元素浓缩到这若干个内数组之内了。同时,调用fade的方法也进行了更改,在当前缓存区内存在音效时会直接覆写已有信息然后再被return掉而非直接被return掉。现在,新的fade方法可以以较高的频率安全地平滑切换音乐了。
真的很累啊这几天,下星期回去每周四周五下午就要开始泡图书馆了QwQ
本帖最后由 电童·Isamo 于 2022-10-17 13:40 编辑
10.17
突如其来的疫情,让一切都又回到了线上。
在这段时间里,我也是用godot成功做出了可以通过无限拖动角落节点来定义的流体(水、岩浆),算是对自己的一次挑战,也算是对自己的一次突破。
而实际上,我的初衷是希望能够通过节点来让开发者更加直接、清晰、尽可能少地利用底层去规划、架构自己的游戏。
所以,我决定接下来对所有需要定义区域的物件都尽可能利用节点+area的形式来定义一个物件的影响范围,让开发者更加简单直接地规划、架构自己的关卡。
10.22
突然发现自己写的还是太臃肿了,于是我……
第三次重写√ 本帖最后由 电童·Isamo 于 2023-7-23 23:11 编辑
7.23
转眼间就到2023年的7.23了,总算是把TeamCE那边的事情做完了。
前两天看到das在他的BE的帖子下面发了他关于新引擎新的架构设想,我就跟他私底下进行了一番探讨与交流。
但是,交流完之后的我还是很迷茫,然后就想起来这个帖子了。
不管怎样,das那个架构我还是蛮期待的,只是因为可能理解起来比较抽象,而且对我这种本身抽象思维能力就不好的人来说那就更加不明所以了,所以我最终还是选择了直观清晰简洁的节点树的架构……
然后突然又想起来自己不管是三次元还是二次元都一直在咕咕咕,没有时间做引擎以及自己的作品了。不过,既然Godot 4出来了,那我干脆就直接用Godot 4重新写一个MF on Godot吧
名字已经想好了,虽然也挺……不明所以的,但也只是个代号,顶多影响logo的制作罢了……
嗯,就先写到这里吧
页:
[1]