【Archived】Mario Forever GDCSharp Dev

dasasdhba

基于 Godot 4.x C# 的一次新的尝试。这次尝试会尽可能遵循面向对象的一些方法和规范，并尽可能优化各种工作流。
对我来说这个项目更有价值的部分是跟具体做什么游戏没什么关联的基础工作，至于再往上的实现我可能就懒得做了

到目前为止探索的也差不多了，有以下尝试值得注意：
1. 利用插件实现 Code Generator，从而发展出一套类似 GM 的比较方便的资源引用模式，只是稳定性感觉还是不怎么样。
2. 利用插件实现 Aseprite 管理素材，这还是能方便很多的。
3. 做了个 Overlap 套件，封装了 Godot 底层物理碰撞，对我这种更喜欢实时重叠测试的人来说挺方便的。
4. 做了一些不怎么依赖 Godot 的结构尝试，实践下来的感觉是可以优化把 Godot 当编辑器的人的体验，但是开发体验还是不怎么样。
5. 其他技术探索，状态机和行为树之类的，挺折腾的，还是具体问题具体分析吧。
总之，这个项目就暂时归档了，我未来也不一定会做基于 Godot 的标准模板了，因为做那些自己根本没有的需求实在是没有动力。

项目地址：https://github.com/dasasdhba/mf-gdcsharp-dev

dasasdhba

https://github.com/viniciusgerevini/godot-aseprite-wizard
一个 Aseprite 插件，其中将 aseprite 文件直接 import 为 SpriteFrames 的功能非常棒。虽然 Godot 4.1 上经常报错，但报错都是诸如什么找不到 *.png 的 Loader，难绷，总之锅全都 Godot 背。如果基于这个插件打造素材工作流的话就有机会使用 Aseprite 软件直接处理动画素材文件。（虽然我不太喜欢它直接导入 aseprite 文件这点，不如自动生成一个纯净的 tres，然而只能手动。）
有个问题是，这插件生成 SpriteFrames 是不能分动画去生成的，虽然说妨碍不大吧，毕竟 Aseprite 本身也不是分动画的所以本来就不现实。但我倒是完全可以考虑魔改甚至重构这插件以满足我的需求，比如我完全可以基于多个按照规范命名的 aseprite 文件来共同生成一个 SpriteFrames 资源，虽然这样搞的话有重复素材估计就只能重复了，毕竟图像资源是通过 aseprite 导出的，想再集成一个 TexturePacker 有点太困难了。

还有个问题是我需不需要把这个插件相关的内容给 push 上去，毕竟我如果只是拿它来生成 SpriteFrames 文件，那这插件以及所有 aseprite 文件删了都没事。目前的想法是还是 push 上去比较好，毕竟按这个搞法的话被动生成的 SpriteFrames 以及相关 Texture 这个本身要作修改都应该通过 Aseprite 软件上修改源文件来达成，挺矛盾的。

dasasdhba

之后也会考虑探索基于 Tiled 的工作流，说实话我觉得一个游戏引擎本来就不该去做六边形战士，明明 TileMap 这一块有 Tiled 这个巨人在，干嘛还非得自己折腾，最后搞半天大概率都没人家专用软件好用。再加上之前还计划了一些代码和 tscn 生成器的事情，感觉我这次这个项目整体上只是把 Godot 当个 API 库，工具人以及 tscn 编辑器在用，笑死。

dasasdhba

做了一套还原 Game Maker 的  Draw 的玩意，还是这套好用啊。
不过 Surface 估计没法还原了，这没办法（

接下来得考虑考虑怎么设计一套统一的 Sprite 的管理方式。