Here’s a little glimpse at what I’ve been working on lately:
As noted in the video, I want to stress that this isn’t necessarily going to be my next game. Right now, it’s just something I’m toying around with. You can read more about the earlier Timeline prototype (and even download a playable version of it) on this page.
A couple days ago I was helping someone with getting high-resolution sprite recolors up and running. In the process I went back to one of my old projects for example sprites to explain the ways I’ve done it in the past. Then I ended up playing around with the project to see how far I’d gotten in it.
For what little is there, it’s actually fairly playable. The game was basically a mix between Civilization and Advance Wars. Sadly, it never got out of the prototyping stage.
Because some people were interested in it, I decided to upload the demo. You can read more about the prototype and try it out here.
Who knows, maybe I’ll come back to it in the future if there’s enough interest in it.
One of the things I decided late into the production of Another Star was that, in the future, I would stop skimming on production tools. In Another Star I hard coded virtually everything in the game, other than the maps. I never really liked working on tools, so I always looked for work-arounds to weasel my way out of making them. But as I got closer and closer to finishing Another Star, things got more and more tedious to change.
The one bright spot was that I’d made a map editor. No big deal; I’ve made dozens of them over the past twenty or so years I’ve been programming games. But it really did make a difference, as simple as it was. Tweaking maps was a simple affair whenever I ran into an issue, even moreso because the map editor ran in-game and all I had to do was press a single key to toggle in and out of it. I almost—almost—tried hard coding the maps. I’m so glad I didn’t.
In any case, as a consequence of this I’m finally getting around to something I should have worked on five years ago: a 2d animation system for sprites.
I actually did the bulk of predesign work for this back in 2009, but never got around to actually programming more than a couple buttons and a file menu. But for my next game, I really wanted it to look good, and I knew I’d need more than some basic grid-based sprites to pull it off. I’m hoping that this application, dubbed “Flipbook”, will do as much good for future projects as that map editor did for Another Star. And, to top it all off, I’m actually sort of enjoying working on this.
I’m trying to make Flipbook as easy and natural to use as possible, because I’d like to release it in some form, even if it’s never properly finished. I don’t expect it to be popular or anything, but it uses a fairly generic sprite system, so I think more than a few people could probably make use of it for their own projects.
In fact, I’d like to share several things I’ve developed, both for this project and Another Star. I’m planning to release these through the Vision Riders website starting here in the near future, but in the meantime you can read up on my latest draft of the underlying sprite system and its file structure. It’s not quite finished or finalized yet, but you should get a general idea of how the thing is supposed to work.
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.
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.
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.
Among people who enjoy Another Star‘s look, one of the first things that gets their attention is the CRT effect that simulates the way old tube television sets look. It’s easily the most praised graphical feature of the game. It’s also one of the few things in the game that I didn’t program myself.
Even though I’ve tried my best to credit the original creators of the shader (cgwg, Themaister, and DOLLS), and adhere to the GPL license their work was released under, it’s still something I feel bad about because people are always complimenting me on it even though I had very little to do with it at all.
As I begin prototyping my next project, I’m seriously considering doing another game that uses the look of old tube sets. However, while you can see I’m currently still reusing the same filter from Another Star, if I decide to stick with it this time I’m going to go through the trouble of making my own from scratch. It’ll let me get a little closer to the look I really want, and I won’t feel so bad about hogging all the glory.
After completing Another Star, I thought about expanding my fake “emulator” engine that the game ran on, and doing another project. I’d like to add some of the features that Another Star is missing, such as actual palette swapping for example.
Another thing I thought about adding was real-time sound. In Another Star, all the music and sound effects are prerendered and then played back, but this past week I toyed around with programming a six-channel FM synthesizer from scratch. Thus, not only graphics, but audio would also be emulated. Behold!
(The screenshot is a test mockup, although it belongs to the same game idea/project.)
The programming is not particularly efficient at the moment. If you listen closely, you can hear the tempo wobble from time to time as my computer struggles to render just five of the six audio channels. Still, I thought it was quite an accomplishment, reading countless articles online about how sound and FM synthesis works, and then applying it to an actual, working program over the course of a week. I honestly didn’t understand much about sound waves work until now.
That said, I’m not sure if there’s much use for it. The only real appeal is that it’s rendering audio in real time. There’s not really any reason not to use audio files for music and sound effects in games. So, in the end, this week was probably nothing more than a waste of time.
Ludum Dare is an online “game jam” and competition where participants from all over the world make a game of their own from scratch in 48 hours or less (or 72 hours, for the more informal version that goes on at the same time). There are some basic rules, a theme to work with, and everyone just goes at it. It takes place a few different times over the course of the year, and I honestly didn’t plan to take part at all.
But then the theme was announced to be “minimalism”. Early on, as their interpretation of the theme most people seemed to using the simplest graphics possible. But I began to wonder what other possibilities there were and started reading up on the minimalism movement. While most people are familiar with it as an art movement, it also covered various other forms of design, most notably architecture. In architecture, minimalism wasn’t just about making things as simple as possible, it was also about finding multiple visual and functional uses for a single element in the design. I was already stewing on jumping in and trying the event out, but learning about this was where inspiration really struck.
I decided that I was going to make a mini-RPG where all the graphics came from a single 128×128 pixel sprite sheet divided into 8×8 pixel tiles, and only a palette of 16 colors were allowed. Oh, and the 16 colors had to all be 8-bit (3 bits each for red and green, and then 2 for blue). I was looking forward to this!
Of course, an RPG is a bit of a daunting task to finish in just 48 hours. There’s an overworld, dungeons, towns, shops, battle screens, enemies, status menus—all sorts of elements that have to come together to make an adventure. But who said I’d need all of these things? Minimalism was the theme, after all, and the less there was in the game the less I’d have to find room for in the cramped sprite sheet. I’d just shave the game down to the bare essentials. A tiny handful of enemies to fight, twelve or so screens worth of simple map to explore, and a basic menu system. Even battles can be streamlined to the bare essentials. Many people do RPGs for Ludum Dare, it’s not like the idea is unusual. So, Saturday morning, I was all ahead full.
But come Monday evening—the end of the relaxed 72 hour version of the challenge—I just barely had the thing playable. It was my own fault for using a game engine that wasn’t quite as complete as I thought it was, but even as the deadline neared I could still have pulled it off by greatly reducing the scope of the game to just the six or seven screens of map that were finished and tapping “fight” to automatically win battles. That’s minimalism, right? It counts. With a few lines of dialog here and there it could have even been a fun ten minute game.
But I didn’t want to do that.
No, I’d fallen too madly in love with the idea. Just how much game could I cram into those handful of 8×8 pixel tiles? The font alone took up almost a quarter of the space on the sprite sheet, so whenever I want to add something, I have to jumble things around, find things that can be taken out, find things that can be reused elsewhere in different ways. And yet I’ve already got a world map with forests and deserts and mountain ranges. I’ve got caves and forest paths and castles to explore. I’ve got not just one character, but a little party that fights together as a team. Even with these few things to work with, I think I could make an engaging “full” game.
I’m tempted to put Junction aside for awhile and just keep running with it. With a month or so of work, I’d probably have a pretty cool little game that’d be worth a dollar or two. I think I’ll toy with it a little longer before committing to it, or putting it aside until later.
Today I played Junction from beginning to end for the first time. There were a great number of hiccups along the way, but it was possible. After tweaking some things, I’ll be sending a build of the game around for feedback.
My completion time was 2 hours and 57 minutes. Granted I already know all the solutions to the puzzles, but I was hoping it would take just a little longer. Still, it matches my original 4-6 hour estimate (when taking into account puzzle solving). Not a bad length, I guess.
