我在这里看到好几个关于godot制作小游戏的帖子，大部分只言片语停留在表面。我在这个帖子给大家统一做一些科普，因为我并不是游戏开发行业的程序员，所以我在b站的视频，每个都做了技术和原理的讲解，github上也将工具核心的模板进行开源。原因就是希望你们能动起手来，理解问题本质知道问题在哪，因为我做这个只是因为在老李直播间跟老李打了个赌仅此而已。所以我很可能哪天我就不玩godot，我就跑路了。但也能留下一点资料和线索让你们继续，所以我并不反对你们使用我的代码或者资料或者无所谓什么东西，都可以，都没关系，我也并不在乎。接下来我根据大家最关心的几个事情进行解答。
1. Godot官方并不支持小游戏，所以做小游戏做不了一点。
首先我要说，微信小游戏这个环境本来就是抽象的环境，抽象的环境就要用抽象的工具。论抽象程度上来说，Godot肯定比不上cocos/laya这种。毕竟人家专门就是适配这种抽象环境而生的。根本没法比。所以如果硬要比你也要跟unity比，但unity做小游戏也没好到哪里去，可能还不如我们现在适配的Godot。因为unity是将il2cpp，将你的C#编译为cpp，再将cpp链接到引擎wasm，所以你使用unity也一样抽象，你会看到unity的方案就是给你一个工具帮助你切wasm，把wasm切成好几份，来适配小游戏环境。而且unity也并不官方支持小游戏，而是tx派了一两个人自己弄的，论tx的抽象程度和他们弃坑程度究竟咋样我也不想多说了对吧，大家懂得都懂。这里指的unity而不是团结，团结在这块儿更抽象，我稍后再讲。
2. 我现在想用godot做游戏，项目马上开始了，能不能做给个准话。
那我问你你懂js嘛，懂微信这种抽象环境吗？懂如何分包如何加载，如何调试嘛？不懂就算了，如上所说，微信小游戏是个抽象的环境，这也就是为什么cocos在小游戏环境当中有绝对的统治力。不光是开发快而是几乎所有坑大家都踩过。我们没有也没有精力对接你们所有人，所有你们只能靠自己，如果你不懂，我劝你还是放弃。
3. 能使用C#吗？不能为什么隔壁团结和unity就可以？你能不能适配C#的godot到小游戏环境？
不能，godot4至今未能支持C#的web导出，据说在等.net 9 提供wasm的动态链接入口。如果微软不同意，就永远不可能。如果微软同意，那不好意思，无论工具箱那边作者怎么想，我这边是绝对不可能也甚至在官方社区强烈表达过不要让.net进入web领域！
目前来说团结就是干过这个事的之一，抽象程度简直一绝！
.net 的C#在很长一段时间是绝对不可能也没必要出现在web或者小游戏领域的，先不说.net的运行时巨大，你根本就上不了小游戏平台，空项目都有可能100m的空间了，而小游戏算上用户空间，最多就给你100m了，我问你你准备怎么部署你的游戏？难道你让你用户等待下载你那破游戏下载100m？然后每次进游戏都要下载？然后下载了100m可能可有玩的内容几乎没有？
然后我再来说说团结，团结为了适配小游戏环境，把blazor的C#解释器拿过来适配，一来是不用和wasm一起打包，二来能减少包的大小毕竟il了肯定会造成体积膨胀。但是呢，抽象的事情就来了，这个C#解释器性能只有js的1/10，特殊情况可能比js慢50倍，可以说非常魔幻和抽象的。这就是使用C#的代价。因为除了windows和安卓，ios这种情况下，无论你怎么做，这个C#解释器都是不带jit的，苹果禁止你使用jit！所以你既没有gds快更没有js快。你们自己斟酌吧
再来，小游戏上的游戏对内存要求很高很高，在ios上，你可使用的内存只有1gb，这中间因为wasm的特殊性，你的所有资源文件并不在磁盘而是在wasm上一个紧凑的内存文件系统中。你的资源+引擎必须的内存+C#的运行时占用内存。配合上因为C#和引擎进行交互不可避免存在内存复制的损耗。抽象程度可以说雪上加霜，而gds根本不存上上述这些问题。尽管gds也没有jit，但是他所有的数据结构都是Godot提供的内存分配和内存管理，gds里面只是持有这些数据的指针，反而内存占用比C#小的多得多。就这团结还要收你15w每年的去水印费，还吹牛逼。我也是没想到的。如果这里有愿意吃这口shit的就去吧。
总结：
如果你开发小游戏，请参考以下排行
cocos >= laya > godot > unity > 团结
1. Godot官方并不支持小游戏，所以做小游戏做不了一点。
首先我要说，微信小游戏这个环境本来就是抽象的环境，抽象的环境就要用抽象的工具。论抽象程度上来说，Godot肯定比不上cocos/laya这种。毕竟人家专门就是适配这种抽象环境而生的。根本没法比。所以如果硬要比你也要跟unity比，但unity做小游戏也没好到哪里去，可能还不如我们现在适配的Godot。因为unity是将il2cpp，将你的C#编译为cpp，再将cpp链接到引擎wasm，所以你使用unity也一样抽象，你会看到unity的方案就是给你一个工具帮助你切wasm，把wasm切成好几份，来适配小游戏环境。而且unity也并不官方支持小游戏，而是tx派了一两个人自己弄的，论tx的抽象程度和他们弃坑程度究竟咋样我也不想多说了对吧，大家懂得都懂。这里指的unity而不是团结，团结在这块儿更抽象，我稍后再讲。
2. 我现在想用godot做游戏，项目马上开始了，能不能做给个准话。
那我问你你懂js嘛，懂微信这种抽象环境吗？懂如何分包如何加载，如何调试嘛？不懂就算了，如上所说，微信小游戏是个抽象的环境，这也就是为什么cocos在小游戏环境当中有绝对的统治力。不光是开发快而是几乎所有坑大家都踩过。我们没有也没有精力对接你们所有人，所有你们只能靠自己，如果你不懂，我劝你还是放弃。
3. 能使用C#吗？不能为什么隔壁团结和unity就可以？你能不能适配C#的godot到小游戏环境？
不能，godot4至今未能支持C#的web导出，据说在等.net 9 提供wasm的动态链接入口。如果微软不同意，就永远不可能。如果微软同意，那不好意思，无论工具箱那边作者怎么想，我这边是绝对不可能也甚至在官方社区强烈表达过不要让.net进入web领域！
目前来说团结就是干过这个事的之一，抽象程度简直一绝！
.net 的C#在很长一段时间是绝对不可能也没必要出现在web或者小游戏领域的，先不说.net的运行时巨大，你根本就上不了小游戏平台，空项目都有可能100m的空间了，而小游戏算上用户空间，最多就给你100m了，我问你你准备怎么部署你的游戏？难道你让你用户等待下载你那破游戏下载100m？然后每次进游戏都要下载？然后下载了100m可能可有玩的内容几乎没有？
然后我再来说说团结，团结为了适配小游戏环境，把blazor的C#解释器拿过来适配，一来是不用和wasm一起打包，二来能减少包的大小毕竟il了肯定会造成体积膨胀。但是呢，抽象的事情就来了，这个C#解释器性能只有js的1/10，特殊情况可能比js慢50倍，可以说非常魔幻和抽象的。这就是使用C#的代价。因为除了windows和安卓，ios这种情况下，无论你怎么做，这个C#解释器都是不带jit的，苹果禁止你使用jit！所以你既没有gds快更没有js快。你们自己斟酌吧
再来，小游戏上的游戏对内存要求很高很高，在ios上，你可使用的内存只有1gb，这中间因为wasm的特殊性，你的所有资源文件并不在磁盘而是在wasm上一个紧凑的内存文件系统中。你的资源+引擎必须的内存+C#的运行时占用内存。配合上因为C#和引擎进行交互不可避免存在内存复制的损耗。抽象程度可以说雪上加霜，而gds根本不存上上述这些问题。尽管gds也没有jit，但是他所有的数据结构都是Godot提供的内存分配和内存管理，gds里面只是持有这些数据的指针，反而内存占用比C#小的多得多。就这团结还要收你15w每年的去水印费，还吹牛逼。我也是没想到的。如果这里有愿意吃这口shit的就去吧。
总结：
如果你开发小游戏，请参考以下排行
cocos >= laya > godot > unity > 团结
