Development Tools

Today we're going to show you a little sneak peak at the development tools we're using while working on sphereFACE.

We don't use any off-the-shelf engines, and we like to build our own tools for most jobs, or use open-source software where it's available to solve our problem. This post is going to go into some detail about some key processes of our work, and give you some insight into our philosophy and methods.

In our previous Kickstarter update we briefly mentioned a model editor we designed to make working on sphereFACE in-game ship and weapon models a lot more straightforward. It allows our developers to create our unique style of vector art in realtime. It generates code that can be plugged in to the game at compile-time, thus getting the best efficiency rather than loading models at run-time from the filesystem.
And speaking of resources; unlike most games that have an installer, and expand to an entire directory in your filesystem, our games are packaged as monolithic binaries. What this means is that we compile all of our resources into the executable binary itself, as raw binary data. When we're talking about resources, we mean fonts, textures, shaders, music and sounds. Compiling them straight into the executable rather than having them as separate files has multiple advantages:

  • It allows faster loading of assets because the operating system's file paging system will page them in exactly when they're needed by the code.
  • It saves memory, because we don't have to load and unpack them from disk into memory separately.
  • It allows faster startup because we don't have to find the files, check they exist and verify their contents, and go through a separate loading step on startup.
  • It means we don't have to worry about the install getting corrupted if certain files are accidentally moved around or renamed - the executable itself will work from anywhere, and renaming it doesn't cause problems.
  • It allows more reliable cross-platform operation, because we don't have to worry about different filesystem conventions on different operating systems - for instance, paths are specified with slashes pointing in different directions for Windows and Linux / OS X, and Linux filenames are case sensitive while the other two are not. Because we're all about accessibility, we want to make sure the game runs equally well on all operating systems.
  • It means the game can be distributed just as one file, with no installation - you can just download it to your desktop right away, and run it right there - or pop it on a USB drive to share it with your friends. The ultimate in DRM-free!

So why doesn't everyone do this? Well, it works better for smaller games such as ours - because we use mostly procedural design, don't have to store dozens of gigabytes of assets. But the real reason is probably that it's quite hard work to set this up; we've created a customised build process that allows us to treat any binary file as an object that's compiled and linked just like our normal source code into the binary, and it took us a while to work out the best way to do this on all three platforms.

Compiling binary resources into the executable

And as we like to compile shaders in to the binary as well, we go through an extra checking step with those. You see, shaders are only loaded at runtime, and compiled on the GPU, so it's often hard to test them for correctness without firing up the whole game. However, we've developed a separate shader verification tool that acts as multiple compile steps, and verifies each stage of a shader - the vertex and fragment shaders separately, and the linkage between them - so it can tell us quickly during compile whether our code is OK or not. It does this by actually checking and building the shader on the GPU right there on the spot, outside of the game.

And while we're showing some screenshots of our IDE, here's what our development environment looks like:
Code::Blocks is a cross-platform open-source IDE

Unlike a lot of game developers, we eschew proprietary Microsoft products such as Visual Studio in favour of open-source tools; our IDE of choice is Code::Blocks which runs equally well on Windows, Linux and OS X allowing us to develop seamlessly on those platforms. The compiler we use is the open-source GCC, on Linux natively, on OS X via Homebrew, and on Windows via the awesome MinGW-w64 project (to which we also contribute code back). We're very proud to be using only cross-platform open-source tools and supporting the FOSS community.

We also get the reward of having a far more powerful and efficient compiler, with good C++17 support and far more efficient optimisation than any of the competing Microsoft tools are capable of - and the bottom line of that is that our games run faster and smoother on your computer!

We also heavily rely on Git for revision control, and this gives us excellent tracking of contributions over time, how our codebase grows, and how productive we are on different days of the week.

Code changes per hour of the day on the sphereFACE project so far - you can see we're all night-owls here!

In our next update we'll be talking about languages and internalisation, and the unique solutions we've come up with for addressing the challenges of bringing our games to as many countries as possible!

Regards,
VoxelStorm Team