EDITOR’S NOTE: This is from a series of journal entries about an as yet unreleased video game. I am continuing to work on this as we speak. I realized I had written a lot in the process and it’s kind of an interesting testament to my long, circuitous but possibly-interesting-to-watch thought process. These entries are unedited and presented the way I wrote them.
September 19th, 2017 is a significant date, for two reasons. First, it was Talk Like A Pirate Day. I participated somewhat half-heartedly, if I recall. The other reason is that according to the git repository, that’s the day I started developing this game. This is sort of a weird place to start a journal, six months on, but better late than never, I suppose. I want this journal to serve two purposes. One, it’s for posterity. I figure someone might eventually find this interesting. The other more pressing reason is to record design decisions I make as I go for later reference. I thought about doing a big game design document, but every time I sit down to write one, I think of something else I’d rather be doing, like literally anything. So instead I’ve decided to do this in journal format, which should work better for the way I’m developing this thing anyway.
So what the hell is this thing? Well, it’s a game…about space. I know, super original idea. That said, I think I have something kind of new and interesting to bring to the table, and I’ve always wanted to do something like this. I’ve got kind of a big picture view of what I want the MVP to look like and a bunch of other scattered ideas that will hopefully take shape as I go.
The game is an open-world, procedurally generated space trading and exploration sim, entirely experienced through your ship’s computer. Said computer’s interface is inspired by the computers in 70s and 80s sci-fi movies. Think Alien, Aliens, Blade Runner, A New Hope, etc. These interfaces were intended to look futuristic, but reflect the limits of what you could get a computer to display at that period in time, which was, in large part, text and some very primitive vector images. Black screens with light colored, mono-spaced foreground elements. I shy away from the word ‘retro’, but I guess it’s sort of apt. The core visual design principle for this thing is that anything that goes in it should not look out of place on a computer in one of the aforementioned movies.
As far as mood and tone, I want something very sparse and austere. I want it to feel…Lovecraftian, not in the “everything has slimy tentacles” way that the term is often (mis)used, but in the “you are a tiny, completely unimportant spec of dust in a cold universe that super doesn’t remotely give a shit about you and you can’t possibly understand and if you did you’d instantly go insane” way. That’s not to say I wouldn’t throw some subtle (and maybe not so subtle) references in occasionally. Maybe there’s a Weyland Yutani super-corporation in there somewhere called Randolph-Carter.
Yoriith and Xoth both come from the Cthulhu Mythos, but were not inventions of Lovecraft himself. The former has an extra “i” that I added because I’m like that.
Here’s a very brief history of the development process to date. My original plan was that the game would be entirely 2D because it consisted only of UI. Because I know it pretty well, I decided to use Go and a library called Ebiten. I went down this path for a while before realizing that many of the interfaces I wanted to make had 3D elements, and that it was going to be exceedingly difficult to achieve what I wanted with Ebiten.
Somewhere around Thanksgiving I decided that I’d take my design ideas and what I’d learned so far about the game idea and do the thing in C++. That meant I would have to relearn C++, as the last time I touched it was something like twenty years ago. It’s changed a lot since then. I thought I’d try to stay “as close to the metal” as what I knew and could learn would allow. On the flight from Portland to New York to see my parents for Thanksgiving (and throughout that week) I worked my way through Bruce Eckel’s Thinking In C++. I learned Java from Eckel’s Thinking In Java way back when, so it seemed the right choice. I had some familiarity with the language already, but as I suspected, the real learning I had to do was around the tools. My only real exposure to a modern C/C++ toolchain had been gcc for use in compiling things under Linux now and again. The last time I had written an actual program in C++ the compiler was made by Borland and it may or may not have supported OS/2 Warp.
Once I regained the barest grasp of the mechanics of a C++ program and the tools to compile one, I foolishly started playing with SDL, then GLFW. Before too long I decided that maybe I was trying to stay a little too close to the metal, and that it would likely be a very long time before I could really achieve what I wanted in a way that it wouldn’t just be a buggy mess. I went shopping for game engines that could handle the graphical side of what I wanted to do. I landed on Godot, which is very full featured, well-documented and has a big community around it. Like many game engines, the engine is written in C++, which does all the heavy lifting, and one writes their game logic in a scripting language. Version 3 came out right as I started working with it. It had C#/Mono support, so I decided I’d give that a shot as I know C# reasonably well. After a few weeks of work I found that the implementation of C# was just a little too green for my patience. Godot has its own scripting language called GDScript, which is almost, but not completely unlike Python. It’s very easy to pick up. Godot allows you to write custom modules in C++ and compile them into the engine. This game requires a ton of math that has to be done very quickly, so the scripting language wasn’t really suitable for that. I decided to do the simulation/data portions of the game in C++. Then I’d do the “visual logic” portions in GDScript, which required about nine minutes to learn.
My primary target platform is (a little begrudgingly, as I’m a Linux grouch) Windows, because that is what most people use to play (non-console) video games. I really didn’t want to use Visual Studio for a variety of reasons. Fortunately Godot uses SCons, a very nice cross-platform build system. I could use Microsoft’s command line compiler and linker to build on Windows and gcc to build on Linux. I’m supporting Linux not because I think there’s a huge market for that, but because I want to be able to use it for development of at least the “engine” portion, which I’m calling “Xoth”. Xoth can be compiled two ways. It will compile as a Godot module, but it can also be compiled standalone for development and testing. My iterative (read: hacky) approach would make having to recompile/relink the module to Godot and restart it every time I made the smallest change was really tedious, so this seemed a reasonable workaround.
TL;DR - After many false starts, Yoriith is being developed with Godot 3 using a combination of C++ and GDScript.Xoth Devlog Pt. 2 →