Last night in bed, as I was thinking about things that still need to be done for my next game before I can really start diving into it, I began thinking about the scripting engine. Another Star just hard-coded all scripting in C#, but, for one, there’s no way I’m scripting scenes in C++, and two, it’s really tedious to hard code script even in C#.

As I thought about the scripting language and how I could store all the script in files, I came up with the idea of packing all the scripts in one file. In the file header would be a table of all the individual scripts with their locations and sizes within the file, so I could load only what I need at a time.

And, since I want the language to be case insensitive anyway, I figured I could probably save some space by reducing each character to just six bits. Six bits gives enough for only a subset of ASCII. 64 characters, to be exact. And you want to convert lowercase letters to uppercase letters (or vice versa) so you don’t waste an extra 26 of those precious characters on just letters. With six bit characters, you can do what’s called packing. This is a form of data compression where you shove four six bit characters into three bytes, where normally each ASCII character would need a full byte each. Reduces the file size by exactly 25% right off the bat. Well, not counting the file header and such, but that’s only a minute portion of the file.

Granted, there’s really no need to save 25% by compressing a text file. I mean, really now. It’s highly unlikely that all the scripts in the entire game combined together will amount to much more than a megabyte or two, if even that. But it’s something I could do if I wanted to, nonetheless.

Then, I began to wonder if I could compress it even further. Five bytes per character! Eight characters would fit into every five bytes! Mwa, ha, ha, ha! I’m a madman!

Thing is, it can be done, and it can be done without a lot of “shifting” like in old-timey standards such as Baudot code.

Click here to continue reading and find out how!

I love C#. I really, really, really love C#. I got into the language because I wanted to develop for what then XBox Live Community Games (now known as XBox Live Indie Games), and Microsoft’s C# library XNA was the only way to do that. Once I got the general hang of it, using C# was the first time since fiddling around with QBasic as a kid that I actually enjoyed programming. I rarely felt like I had to “fight” the language to get things done, the way I usually do when working with C++. Sure, the language has its faults and quirks, and the lack of control over the garbage collector can be more than a little annoying, but it really is an all-around magnificent language to work in and so I love it to death.

However, the current state of support for the language is a bit irksome to me. Another Star was coded completely in C#, built on top of a custom engine that interfaces with system APIs by way of a library called OpenTK. OpenTK always annoyed me a little, often depreciating entire sections of the library before the parts meant to replace it were even implemented, let alone completed.

Just as Another Star was heading to release, a new major version of OpenTK finally came out, and it changed up the way a lot of the engine’s user input worked (keyboard, mice, gamepads, etc.). Trying to “correctly” implement these new designs has proven frustrating, as things I relied on have been removed without any real replacement. Some of these changes even led directly to bugs in Another Star; especially the Linux version. Bugs in the library also make it really difficult when trying to fix things, because I can never tell for sure whether something isn’t working because of my code or someone else’s. Or, for that matter, if I can even fix it.

I knew, even before working on Another Star, that I would probably have to move to another C# library in the future. I continued to look for a suitable replacement, but never really found anything I liked. The closest I got was a C# wrapper around the widely used C/C++ library SDL2, but it was little more than that: a wrapper. The syntax is pretty much just straight up C, without any attempt to translate it to C# conventions, at which point I feel like I might as well just code directly in C++.

So I finally gave up and that’s exactly what I’ve been doing. The past month or so, I’ve been hammering out the beginning of a game in C++, the programming language that I’ve always had a loathing for (and, at times, outright hate). C++ is nearly forty years old at this point, and in that time has accumulated a lot of cruft. It’s gotten a lot of updates over the years to keep it relevant, with varying success, which has made it—at least, in my opinion—very ugly language, especially to look at.

But the fact of the matter is that virtually all the important API libraries are written in C++. If I don’t want to build my game on top of somebody else’s code, this is my only recourse.

I already regret my decision.

There’s a lot of programmers out there that are big fans of “self-documenting code”. That is, code that is easily understandable without comment lines explaining it. Robert Martin, in his book Clean Code: A Handbook of Agile Software Craftsmanship, even goes so far as to say:

The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration.

The philosophy here is “your code should speak for itself”. After all, a programming language is a language, right? We don’t need asides just to get through a block of pure English text, do we?

The thing is, programming languages are not one-to-one equivalents to a human tongue. For that reason I follow a different philosophy, as you can probably tell from this sample of some C++ code I wrote:

Some of you out there who are programmers are probably cringing right now looking at that. Take, for example, the c = file->peek() line at the bottom. Anyone with experience in C++ would recognize at once what I’m doing. Really, anyone familiar with file input/output in general should understand what I’m doing just from the “peek”. I’m looking ahead one character in the file, without advancing the file reader, and storing the value in the character variable named “c”.

Yet despite that, the line is proceeded by a comment: “Peek at the next value.” It describes the obvious. Some would say it’s useless and redundant. But I purposefully took the time to type it out there anyway. As you can probably see, I’ve even done it more than once.

I strongly believe code should be well-formatted, organized, and easy-to-read, but also extensively commented. Why? There’s several reasons.

1. It keeps me focused. I type out what I’m trying to do right before I go about it, so I have a good idea how I need to format the code to best accomplish whatever task is at hand. When you look at my comments, you’re not just seeing what I’m doing, you’re seeing the entire thought process behind it.
2. It helps me keep my code organized. I can easily skim through the comments to find the chunk of logic I’m looking for, without having to dig too deep into the code itself.
3. It makes it easier for me to find mistakes. Occasionally I can spot a bug by just running through the comments and seeing the thought process doesn’t line up. I’m missing a step! Other times, I’ll actually find bugs by seeing that a comment doesn’t match the code that follows it. My implementation is wrong because I goofed and wasn’t following the logic that I’d stepped through in the comments.
4. Building on point 1, it reminds me what I was thinking when I wrote the code. A lot of times I’ll wonder, “why did I write it this way?” Then I’ll go back over the comments and remember. It’s saved me rewrites before, especially when I’ve forgotten that I already tried what I might think is the “better” way and realized it won’t do what I need it to.

According to Google’s C++ coding style standards, when writing comments you should “assume that the person reading the code knows [programming] better than you do.” I for one don’t. I assume that the person reading my comments is an idiot. Because I will be reading them later.