Monthly Archives: October 2014

Where’s My Steam Key!?

Help get Another Star on to Steam! We're 36% of the way to the top 100!

Some of you are probably reading this because you bought Another Star in the latest Indie Royale bundle, or are thinking about it. When you buy the game through Indie Royale (or pretty much any other retailer selling the game), you also earn access to a key to redeem the game on Steam.

Here’s the thing, though: you can only get the key if it actually exists. And for that to happen, the game has to get through Greenlight.

Another Star has been stuck on Greenlight for months now, making little traction. But with the spotlight of the latest Indie Royale bundle, and thanks to the efforts of a great many of you, the game has begun to surge forward. Now, here’s you come in!

First off, if you have not yet voted for the game, please got to Greenlight right away and do so.

Second, please go and tell your friends about the game. Encourage them to up-vote the game on Steam. Social networking sites like Twitter and Facebook are great for this. On my own Twitter account, I’ve even got tweets especially tailored for retweeting in mind that contain a lot of helpful information about the game and its Greenlight campaign.

Another Star is by no means a perfect game, but it’d be a shame to see it wither away, stuck in Greenlight limbo forever.

Besides, the sooner it gets greenlit, the sooner you get your well-deserved Steam keys!

Of Bundles And Another Star

In case you haven’t noticed, Another Star is part of the latest Indie Royale bundle. The Debut 20 Bundle, to be exact.

Bundles have become a really controversial issue among developers. When the concept of indie bundles as we know them began with the first Indie Humble Bundle back in 2010, it was really well received. But the first Humble Bundle was a novelty. Now bundles have become as commonplace as sliced bread, with dozens of sites and brands dedicated to selling them.

To many, bundles are a waste of time for developers (with the usual exception of the flagship Humble Bundles that sometimes manage to break the million dollar mark). Many of these bundles go for less than a single game by itself, which in turn must be further cut down and shared by all the companies involved. Thousands of sales are likely to result in only a few hundred dollars at most. The devs then have to provide support for hundreds of copies of a game from which they received less than a dollar each, and post-purchase support is one of the single most frustrating and time-consuming tasks in the entire development and lifetime of computer software.

When Indie Royale contacted me about putting Another Star in a bundle, I was hesitant. It was fairly short notice, I felt it was too early to put it in a bundle, I knew the returns would likely be small, and I knew it could bite me in the rear end with an onslaught of support emails I’d have to respond to.

But I also really needed the publicity. After thinking it over, I changed my mind and accepted.

As of yesterday, Another Star had only sold 64 confirmed copies. (It’s actually sold at least one more copy than that, but FireFlower Games uses a monthly reporting format instead of a daily or realtime one. I haven’t gotten the report for October yet, but someone noted they bought it during a recent sale.) As of writing this, that number has increased by eightfold. As already noted, this doesn’t translate into much as far as dollar amounts go. I don’t think I can discuss exact numbers, but I haven’t made very much despite almost 500 copies of the game being sold so far today. But I knew that going in.

Now for the flip side. The bundle has been on sale for six hours now. In that time, I’ve gotten roughly a hundred up-votes on Greenlight. That’s more than the past three months combined. The last time I broke one hundred up-votes in a single day was in the first week of the Greenlight campaign, and the day isn’t even over yet. I seriously doubt a steady pace of 100 votes every 6 hours will keep up through the entire two weeks of the bundle deal, but if I can manage just 200 votes a day, that’ll get me into the top 100 games on Greenlight, which puts Another Star that much closer to getting on Steam. Being on Steam is not some kind of magic bullet, especially these days with so many indie games available through the service, but the importance of being on that storefront cannot be understated.

It’s too early to say whether participating in this bundle was a good idea or not, but I hope it was. If it nets me enough to finally earn a payout from Desura, I think I’ll be content if nothing else.

Regardless, the game is in the hands of 500 more people today. I hope they enjoy it.

A Five Bit Scripting Language

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!

Goodbye, C#

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.

Comment Everything

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.

(Emphasis mine.)

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:

Well-commented C++ code.

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.

Maintenance Complete

The site move is (mostly) complete at this point, so everything should be up and running okay. Let me know if anything doesn’t seem to be working properly.

Note that the site’s email addresses might not be working entirely properly for a few weeks. They should, but if your support email bounces or something, it’s definitely because of the move. If you need to get in contact with me and can’t get through, leave a message here and I’ll give you an alternate email address to use for the time being.