Jill

For no reason in particular I've been spending the past few week or so (very on and off, mind you) forcing myself to actually learn Godot and... I like it. A lot, actually.

I think in the past I've been fighting against it. I've been lying to myself and saying that I don't like it and don't click with it when in reality in all my previous attempts I haven't actually wanted to learn it. I've jumped into it, failed to do one thing, then threw up my hands and said "Engine sucks!"

Now that I'm actually trying though, I'm having a good time. I figured that I'd just play around with it and explore it and just follow my impulses and it's actually quite nice.

Note that all my thoughts here are based on about a limited amount of experience, and I'm still learning the intricacies of the engine.

Nodes and scenes

I've actually always liked this element of Godot. I don't have any real complaints here. It takes getting used to but I do like it, despite that. The scene system in particular reminds me of how Psychonauts does stuff. From what I've seen Irrlicht may be a closer comparison but I've never actually used Irrlicht, so I only know it second-hand from some work I did prying open Bugsnax, so I could be wrong.

Game UI

I've not played much with the 2D facilities of Godot. It still irks me to have the UI be part of the scene like with Unity but at least:

• The scene system means that it can be much cleaner than even Unity prefabs would be
• There's an actual dedicated screen for working with 2D elements rather than trying to clumsily do everything in the same editor

Not 100% sure how I will be linking my UI to game elements. Signals would seem like the obvious option but with the UI needing to be part of the actual scene, I don't really know how you'd do it that way without having to rewire all the signals for every single scene. That's dumb.

Programming

This is still the place I'm incredibly conflicted. In the past I've been very annoyed trying to wrangle Godot's C#/.NET support. I still plan to do that, I really would rather not write the core systems of my game in GDScript, but for this attempt at learning Godot I've been mainly using GDScript to force myself to learn it. It's... fine actually. The fact that there's a documentation viewer directly integrated into the script editor is amazing when writing GDScript. It's a good editor.¹

If I do end up moving to Godot, one of the biggest annoyances is definitely going to be translating my existing base to Godot. I have a good thing going. I'm using a forked Source-style movement asset for all my core player movement and I've got a lot of shared utility classes and extensions that I'm used to working with. Gonna be real pain to try and rebuild all that from the ground up, probably the biggest blocker for me right now.

Hopefully, starting with GDScript and familiarising myself with the API will help me then do what I actually want to do and grasp the API on the C# side as well. I think the ideal way to use Godot (for me at least) is going to be using C# for core systems and architecture while using GDScript for smaller scripts, especially one-offs.

Speaking of which, I absolutely adore Godot's signals system. It's such an elegant solution to a problem that I've often had in Unity. It makes it a breeze to connect systems together and the way it encourages you to set things up is quite good.

Level building

I've yet to figure out what I would like my workflow to be when it comes to building 3D levels in Godot. In Unity, my favourite tool was SabreCSG because I'm a huge Source Engine nerd. (SabreCSG was partially supplanted by its "sequel", RealtimeCSG, but RealtimeCSG doesn't work on Linux for some reason² so Sabre wins). This tool, buggy as it can sometimes be depending on the Unity version, has served me very well.

The natural equivalent to this appears to be Qodot. Qodot lets you load in Quake map files (created with Trenchbroom) and utilise them to construct the geometry of your Godot levels. This is actually quite cool and it works decently enough. You set the texture directory in Trenchbroom to your Godot textures folder and make sure the same directory is set in Qodot and it can auto-map the textures in the .map to actual materials of the same name in Godot.

This is all well and good, and it's definitely better than trying to use whatever the hell you're actually meant to use to build levels in a modern engine, but I've got a lot of problems with Qodot's implementation of it.

Specifically, why can't I just build my levels inside Godot? I'm already trying to learn a whole new engine, I don't really like that I've also got to learn Trenchbroom as well just to build levels. I'd really rather just have a Godot plugin that lets me build levels CSG style like with SabreCSG. I've only got one monitor and I've already got enough shit open, I don't really like needing to constantly go back and forth. Hell even if I did have a seperate monitor for Trenchbroom to live in it'd still be annoying as hell to swap between them. One of the things I love about the workflow I have with SabreCSG is that it makes it so unbelievably easy to iterate and change stuff with little effort. I just select a brush and manipulate it or add a new brush and move it and size it into place. With Qodot I have to tab over to Trenchbroom, do whatever I need to do, save the map, then tab back into Godot, select my Qodot node and hit build. Then repeat if I then want to tweak it more. Not good.

Plus, it almost feels like the whole thing is one big workaround for itself. The core of the tool, actually laying out the geo and then hitting the button in Godot to build it, works just fine. But everything else is kinda... ehh? The texture auto-mapping is good but raises some issues. If I've got 2 or 3 materials that share the same base texture, then I'd need to have a seperate copy of each texture for Trenchbroom's sake because Trenchbroom obviously can't read Godot's material files.

I don't really know how to work with entities with Qodot. Admittedly, I've not tried to figure it out extensively. I've just been using Trenchbroom to build geo then placed my entities in Godot directly. I've read the docs on how to do it properly but I haven't actually tried doing it because I think it seems like kind of a pain to set up and yet another case where I just find myself wishing everything was done in Godot instead of needing a gap to be bridged between two completely seperate applications.

I really hope someone makes something like SabreCSG but for Godot. It'd alleviate a lot of pain.

Asset management

I don't have much to say in this regard. It's largely the same as Unity and just as easy to import stuff. It did take me a bit to realise that there's an actual import settings window, I'm used to that stuff all being managed in the inspector. It's good though, it makes it a lot easier to manage stuff when the inspector window doesn't get stomped because you selected something in the file system.

One thing that is majorly helping Godot win me over against Unity is how it allows embedded creation of some assets from within the inspector, without having to tie stuff to files. If something needs a texture, then you can click it and hit "New [TextureType]" and make a noise texture or something, and that texture will simply exist in the space of that object, you don't need to create a whole new asset for it. That's super handy and there's quite a lot of spots in Unity where I'm annoyed at needing to clog up my assets folder with one-time-use items.

That being said, there's some places where it's just as annoying as Unity in this regard. I'd like to be able to do this with scripts as well - one problem I've often had with Unity is that I'm forced to make one-off scripts for singular objects in my game and it feels wasteful and clogs up my scripts folder. Godot... doesn't seem to do much to help this. Especially when it comes to linking signals - I adore Godot's signal linking system and it's super useful but if I want to link to another node I'm usually forced to then attach a script to that node, which means I'm forced to save a whole new script file in my project directory for a script that will in all likelihood contain a single function. It'd be a lot nicer if such scripts should be tied directly to the node in question rather than being in their own file.³

The fruits of my labour

I don't have a ton to actually show. All my work has been scattered about in this incredibly basic 2 room test project. The geo is made in Trenchbroom and imported with Qodot. I'm using an MIT licensed FPS controller thing I found in AssetLib but I can't actually find it on there anymore for some reason.

Incredibly early on I became quite enamoured with Godot's volumetric fog. It's still quite wild to me that you can just... turn on such good looking fog with a single checkbox.

Of course, I couldn't resist seeing what a massive thick fog volume looks like in motion:

This is somewhat inspiring. I feel like there's something that I could do with this... exactly what, I'm not sure yet.

While messing with the material editor I accidentally made FIREBLU, so that's horrifying.

I also found that by abusing the smorgasbord of settings Godot gives you for materials you can do some quite interesting stuff

And also early on (so you can finally see this room without the billions of things cluttering it) I made the bricks uncomfortably fuzzy.

Aaand... that's kinda it for stuff I have to actually show. Much of my efforts so far have been aimless fiddling just to try and familiarise with everything. I'm trying to figure out a suitable project that I could build or rebuild on Godot to help with the process. HouseGame maybe? Not sure. Everything is so reliant on those base scripts I mentioned. It'd be a good excuse to get to work on porting them over, I suppose. Otherwise perhaps the Wolfenstein test thing would be more suitable.

1. If their integrated script editor had actual C# support that'd probably solve a lot of annoyances when it comes to using C# in Godot. A lot of my annoyances with their C# handling actually seem to spur from the fact that, despite their tutorials including both C# and GDScript examples, it can often feel like the C# support is very "begrudging", and that I basically have to learn the GDScript and translate that to C#.

2. For some reason, RealtimeCSG is dependent on a native library. The dev apparently doesn't have a Linux system so cannot build it for Linux. Okay, fine, Linux nerds can probably build it themself. Except for some reason, the code for this library isn't public. Devs on RealtimeCSG have somewhat dodged around the issue and while I think they do want to work on it, it's incredibly slow going and unfortunately that isn't helpful for me.

3. This might be possible somehow?? I've seen it happen once but at that time I didn't actually want it to do that and it ended up being detrimental because I actually wanted that script to be in its own file (because having it be embedded on the node meant that I couldn't use the class defined in that script elsewhere when doing static typing). Not been able to figure out how to replicate it. Since writing this I have been informed that this is doable via the "built-in script" checkbox when making a new script. Handy!