Right now on the game project, I’m working on something that I think is going to be pretty cool once it’s done, but it’s going to take me a while to get it done, or even to get it to the point where it’s worth me writing about it here. So I thought I would break up this interlude by writing a bit about the tools I’m using to develop the game, in case anyone is interested. I’ve mentioned some of these already in passing but in this post I’ll try and flesh out the full picture a bit more, and also say a bit about why I chose the tools I did (since they probably seem an odd choice to a lot of people).
For testing the game while I develop it I’m mostly using Google Chrome, since that’s what I have on all my machines anyway. I’ll test it on other browsers (Firefox, Safari, etc.) at some point and check that everything works as it should, though I’m trying to steer clear of relying on obscure or browser-specific features as much as possible.
As well as a browser, it’s also necessary to have a web server installed for testing purposes, because the game expects to load its data files from a server via HTTP rather than from a local disk. So I have Apache, the most widely used web server in the world, installed on all my machines. On Linux I installed it through the normal package manager; on Windows and Mac I’ve installed XAMPP, which does a great job of packaging up Apache plus some other useful software and making it easy to install and use.
I’m storing the code in a Fossil repository. I wrote a whole blog post about Fossil when I first discovered it, so I won’t say too much here. I still like its philosophy of storing all the code along with wiki pages and a bug tracker in a single compact file, while the Fossil executable itself is also a single file that can be dropped onto any system without going through a complex installation process. I probably wouldn’t use Fossil to co-ordinate a huge software project with multiple authors, but for a personal project like this one it’s ideal.
I’m using Fossil’s wiki facility to make notes as I go, covering things like the binary file formats used for models, and the exact process of authoring content for the game engine. Hopefully I’ll manage to keep this up going forwards as I know from past experience how useful it will be later on! I haven’t used the bug tracker system yet but I might later on if it becomes useful.
So that the code is automatically synchronised between all my machines, I keep the Fossil repository file in my Dropbox. I also keep many of the asset files in Dropbox, though I haven’t checked them into Fossil as it’s not really designed for working with large binary files, and putting them in there would just bloat the repository file and cause it to take longer to sync. I’ve used this workflow, for want of a better word, on various projects for the last few years and found it works pretty well for me.
I think that pretty much covers the coding and testing side of things. The other major aspect to the game is creating the assets (3D models, landscapes, animations, textures, icons, and so on). My primary 3D software is Blender. As I said in the first post of this series, it’s free, it’s very powerful (people have made entire animated movies using it), it runs on almost anything, and it’s got a great community behind it. Its biggest downside is probably the steep learning curve, but since I’m already mostly over that after using it for my previous 3D dabblings, there was no reason not to use it for this.
Even when making 3D games, some 2D image editing is still usually required for preparing textures, making heads up displays, that kind of thing. Gimp has been my paint program of choice for years now. Apparently it’s got a horrible interface compared to Photoshop, but then I’ve never really used Photoshop so I guess you can’t miss what you’ve never had. In any case, Gimp has never let me down so far in terms of features. I’ve only used it once so far for this particular game, for tiling the ground textures into a single image (the “snap to grid” feature was very helpful here), but I’m sure I’ll be breaking it out again before too long. My other favourite image editor is Inkscape, which handles vector graphics rather than bitmapped. In the past I’ve found it great for designing icons and stuff like that.
I think that’s pretty much all my tools covered now. If you’ve been following along, you’ll notice that all of them are free to use and the majority are open source, which is no accident. I’m not a free software zealot who demands that all software must be freely licensed, but there are some good practical reasons why I much prefer using open source tools wherever possible.
Firstly, I don’t have to pay for them. I’m not a complete cheapskate, but at the same time I have a family to support now and better things to do with my limited money than pour it into (for example) Adobe’s pockets for a Photoshop subscription when Gimp meets my needs perfectly well.
Secondly, they tend to be cross-platform. That’s important for me because I regularly use all three major operating system platforms (Windows, Linux and macOS) so I much prefer tools that work on all three of them, as all of the tools I’ve described in this post do. I like it this way; it means I’m not locked into one particular platform and am free to switch whenever I want without having to throw away the time I’ve invested in learning this stuff and start from square one with a whole new suite of software. For example, last year it made sense for me to get a MacBook (I needed a Mac for a project and didn’t own a decent laptop at the time) and, even though I hadn’t used one since high school, I was able to install all my preferred free tools and get up and running with it very quickly.
Thirdly, they’re not going anywhere. With commercial software there’s always the worry that the company will go out of business or will discontinue their product after I’ve come to rely on it. Sure, I could continue using an old version (unless it’s a subscription service *shudder* ) but it might not keep working forever, or might keep me locked into an older operating system and unable to upgrade. That’s much less likely with open source, because even if the original developer disappears, someone else from the community can step up and take over maintenance. (I could even do it myself in some theoretical world where I have time for such things 😉 ).
So yeah. While I could probably make my game more rapidly if I switched to some expensive all-singing-all-dancing commercial Windows-only solution, I’m happy with the approach I’m taking, and it also fits well with my desire to understand everything and be able to tinker with the low level code if I want to. I hope you found this at least somewhat interesting or informative. Next time I’ll be back with a proper progress report to share with you.