xianliticn
fb217bf343
All checks were successful
Build and Deploy Qingshuige / build-deploy (push) Successful in 46s
38 lines
3.5 KiB
Markdown
38 lines
3.5 KiB
Markdown
---
|
||
title: 浅论 Godot：成也社区败也社区
|
||
date: 2024-05-21T01:02:00.000+08:00
|
||
author: 线粒体
|
||
---
|
||
现在做游戏用的引擎也是比较多了，像Unity和虚幻这类，都是常用的，网上有大把大把的资料。最近正在准备开发游戏，自然要选一选引擎。过去我常用Unity，这几年不用，手生了，想着不如趁机用点新的。于是就发现了开源游戏引擎[Godot](https://godotengine.org/)。有中文文档，支持C#，跨全平台，还免费，实在是好。于是兴致勃勃下载，新建项目一条龙。然而体验了一会，感觉还是不尽人意。
|
||
|
||
|
||
|
||
## 支持C#，但没完全支持
|
||
|
||
Godot用的是自己开发的脚本语言，叫GDScript，跟Python和Lua差不多，不过针对游戏开发专门优化过。这个GDScript和引擎的集成度是比较高的，毕竟是官方首推的编程语言。不过我对C#很熟悉，所以并没想着去学GDScript，而是直接使用C#编写脚本。
|
||
|
||
|
||
|
||
然而这时候问题就来了：GDScript直接可以在引擎编辑器内编辑代码，但C#只能在外部编辑器（如VSCode）内编辑。这还没什么问题，毕竟Unity也是用外部编辑器的。但是Godot对VSCode几乎没任何集成。比如说Godot有个概念叫“信号”，就像C#里的事件一样，一个游戏对象可以监听另一个游戏对象的信号。当使用GDScript监听的时候，可以直接生成监听用的函数，而且有内置GUI管理这些函数。然而换上C#，完全不能自动生成，你得自己把方法名和参数一个一个敲上去，还必须和信号源上设置的一模一样，相当于没有任何自动代码补全。这种情况下，出错的概率可想而知。
|
||
|
||
所以实际上Godot最好的甚至唯一适合的开发语言是GDScript，其他语言的体验简直折磨。
|
||
|
||
## 版本控制相当简陋
|
||
|
||
Visual Studio现在集成Git，体验很不错；Unity用Plastic SCM，专业性是到位的。然而Godot没有内置版本控制系统，只有几个版本控制的实现插件供用户下载。
|
||
|
||
|
||
|
||
|
||
我下载了GitPlugin，即Git的版本控制插件。易用性实在是感人，就像搭积木一样，什么都得自己配置。不像Visual Studio，直接登录GitHub，一键上传；Unity的Plastic SCM也是一键上传。这GitPlugin光是连接仓库就花了我半小时，什么SSH公钥私钥、GitHub的token之类的东西，简直要命。好不容易配置好，又特别容易出错。而且最搞笑的是这个插件的推送和拉取都是阻塞的，也就是说推送或拉取的时候，你的编辑器是无响应的，只有成功后才能恢复响应；但你并不知道超时时间是多少，有时候无响应一分多钟还不好，只能强制关闭整个编辑器。
|
||
|
||
拼阳寿的Git我是向来不用的。
|
||
|
||
## 总评
|
||
|
||
Godot主要的优点就在于灵活、轻量，就一个exe可执行文件，装就装，删就删，没包袱。而且用的库基本都是开源的，不用担心产权问题。构建也利索，没有那么多杂七杂八的事。
|
||
|
||
社区的东西虽然灵活，但易用性上毕竟不如商业软件。我对Godot总体的感觉就是专门提供给游戏开发爱好者或者小工作室用的引擎，有那个时间去折腾，不追求太多稳健性。这就像Mac和Windows、iOS和Android一样，你很难说哪个好哪个坏，只能说适合不同的人群。
|
||
|
||
我最终还是选择复习我的老本行Unity，社区引擎，等我有空再折腾吧。
|