EDITOR’S NOTE: This is part of a series, start here.

I’ve been back at it for a week or so already but as you can tell, I haven’t really worked on this thing for six months. I got burned out on it and had to go off and do something else completely different for a while. I switched to working on a mobile game with pixel art owls that involved flying. Then I got burnt out on that, so now we’re back here. I made the right choice, I think, because when I walked away from this game for a while I got a lot of new ideas for it. Also, Godot has improved a number of things that make development a lot more pleasant.

The biggest difference is in the way I’m using Godot. Working on the mobile game gave me a way better understanding of what the engine does and where it’s strengths are. My initial plan was to have almost the entire game in a Godot module written in C++, and the game engine was basically going to provide a fancy GUI. This may or may not have been for reasons related to wanting to do it in C++ whether or not that was the best tool for the job. Godot is actually good at a lot of things, and now that I know what they are I’ve broken things up a little differently.

I’m now using GDNative. It’s a lot less cumbersome to work with than a full on Godot module, but provides almost all of the same advantages, at least for what I’m doing. The big difference is that instead of having to place all my module source code inside a copy of the Godot source and then recompile the entire thing every time I make a change, I just compile a DLL, copy it to the Yoriith project directory and the (unmodified) engine will pick it up. It requires a little bit of configuration on the Yoriith side, but nothing crazy, and the advantages are huge. I used to have to check out two copies of the Xoth code, one as a submodule in the Godot source tree and another on its own so I could compile and test it by itself. Now everything is one place and it’s a whole lot cleaner to run. Interestingly, GDNative doesn’t specifically require you work in C/C++ (the way a Godot module does), and there are a number of language bindings available. I noticed someone wrote one for Go, and, well, I thought about it, but I think I’ve got enough of a handle on C++ at this point that I don’t want to… go …there.

In the past week I’ve made a ton of progress, namely in the form of getting skeletal game creation and loading working, which essentially amounts to creating and listing SQLite databases. In an example of letting the Godot engine (via GDScript) do the things it does well, I have GDScript code get the list of files in the correct user directory and name the new database file. This means Xoth only needs be supplied with the full path to the database file you want to use, rather than doing all the directory listing and such, which is obnoxiously hard to do in C++ in a reliable, cross-platform way. In GDScript it’s like ten lines of code.

I also did some UI work, and I’ve got a functional main menu and the start of the actual game UI. I’ve got a skeletal setup that lets you move between the different screens, like navigation, trade, ship control, etc.

Story-wise I decided to go with my earlier idea that “The Company” in this fictional universe is Randolph-Carter Incorporated. I made them a logo which shows up when you launch the game. I also decided that the “OS” the ship runs is “GE/OS”, a play on an obscure window manager for the Commodore 64 and the version is 3.23, which is a date from The Call of Cthulhu. Mistkatonic University developed part of the OS, the way that UC Berkley developed their own version of UNIX.

← Xoth Devlog Pt. 7 Xoth Devlog Pt. 9 →