next »

[Pineapple]

It might be named "Zenith". I haven't decided yet. It's going to be a CRPG. But that's not important right now because nothing exists of it yet except some lore and design ideas.

Some time ago I posted a devlog for a game called "Kingdoms". Life tore me away from the project before I could get much more done than planning. It was a very ambitious idea. (I likely would never have finished it.)

Well, in the intervening two and a half years, I have continued to develop that idea, and especially the fantasy setting in which the game was to take place. One of the more important things that I've learned in that time is how I simply haven't got the tools to achieve what I want to on any reasonable timescale. In the past, I've done most my game development with a language called BlitzMax. It's a good language and I learned a lot using it, but it has its shortfalls and its limitations and it really is not up to the task.

And so I went looking for something that was up to the task.

I found a language I love to work with, but found its libraries lacking as they pertain to game development. That's why, since May, I have been working on mach, a library for the D programming language. The library does a lot, including gamedev. I am expecting that this library will constitute the toolbox I need to develop this Game That Doesn't Exist Yet, and to develop more after that. In fact, here you can see some of what it's already capable of.

I thought that to start stirring some interest in my project, I could talk about the library I've been developing and what makes it awesome, and about some of the things I've learned along the way. I've been making games since I was a kid: I've made games using lots of different languages, using lots of different engines and frameworks and libraries, and I've even made one or two of my own. So I feel like I've gained a lot of experience regarding what makes a gamedev tool awesome to work with, and what makes you feel like you're working against the tool more than with it.

[Pineapple]

One of the biggest things that makes game programming from scratch so unappealing when compared to using an engine like Unity or Unreal is the boilerplate. The sheer immense amount of boilerplate. Lines and lines and lines of it. You really can't write any kind of application without it involving some kind of boilerplate, but with games it gets particularly nasty. Especially when you want to do something complicated enough to be interesting.

This is where libraries such as mach come in. They help make it so that normally complex series of tasks such as initializing a window, initializing a rendering context for that window, loading an image, creating a texture from that image, and telling the application where and how to render the image can be expressed as concise, digestible chunks that are easy to write and easy to understand.



Taking away all the comments and blank lines, that program is only 24 lines of code. The rather substantial amount of boilerplate necessary to initialize everything that makes this possible and to correctly tear it down again afterward is handled automatically, and normally obtuse operations like loading an image file as a texture or checking an event queue for keypresses are repackaged in terms that are much easier to work with. What's more, the differences between platforms are accounted for, too: That code runs on both Windows and OSX without any extra fangling.

In my experience, game programming becomes a joy when something simple can be expressed simply, and not before.

Code:

import mach.sdl;
import mach.math;

class Pineapple: Application{
    // This is a texture; textures are things we draw onto the screen.
    Texture pineapple;
    // And this a vector to be used to determine where to draw that texture.
    Vector2!int pos;
    
    // This happens when the program starts.
    override void initialize(){
        // Make a window on the screen such that its upper-left corner is at
        // (300, 300) and its lower-right corner is at (600, 600).
        window = new Window("Pineapple!", Box!int(300, 300, 600, 600));
        // Load a texture to draw onto the window,
        pineapple = Texture("pineapple.png");
        // And initialize its position at the center.
        pos = (window.size - pineapple.size) / 2;
    }
    
    // This happens when the program quits.
    override void conclude(){
        // Free the texture from memory, now that we're done with it.
        pineapple.free();
    }
    
    // This is the main loop!
    override void main(){
        // First clear the screen to black,
        clear();
        // Then draw the texture,
        pineapple.draw(pos);
        // And update the window to show what was just drawn.
        swap();
        // Finally, update the position of the texture depending on what
        // keys are being pressed.
        pos.x += keys.down(KeyCode.D) - keys.down(KeyCode.A);
        pos.y += keys.down(KeyCode.S) - keys.down(KeyCode.W);
    }
}

void main(){
    // This is what makes the application start when the program is run.
    new Pineapple().begin;
}

[Pineapple]

Today, in things you may not have known that library programmers have to think about:

Almost all text everywhere is encoded as either ASCII, Latin-1, or UTF-8.

ASCII is pitifully limited and, though simple and convenient, is not even capable of fully representing American English because of unsupported punctuation and words borrowed from other languages with differing alphabets. But because of that simplicity and convenience, we do still use it a lot.

Latin-1 is better, and can adequately represent a few dozen European langauges.

And Unicode, of which UTF-8 is one encoding, is able to fully represent an unthinkable number of written languages, with additional scripts still being considered for introduction into the standard. (Also, all valid ASCII is also valid UTF-8, which is nice.)

But, sometimes, someone goes and represents text in some other way. UTF-16 is a particularly problematic offender.

The difference between UTF-8 and UTF-16 is subtle, but very important. They are both Unicode formats, meaning that they map to the same very large set of characters. They are both variable-length encodings, meaning that the number of bytes it takes to represent a character can differ. The defining difference is that UTF-8 is a series of bytes (or chars), and UTF-16 is a series of shorts (or wchars (or wide chars)).

The important difference is that, despite a rigorously defined standard, everyone seems to have their own idea regarding how to encode and decode UTF-16 text. Some applications acknowledge that UTF-16 is a variable-length encoding, and some handle surrogate pairs incorrectly (which are characters that take two units, or wchars, to represent, instead of one), or don't handle them at all. The encoding is further affected by the fact that a system's endianness can affect how UTF-16 is represented; often a preceding character called a BOM, or byte order mark, is included to help decoding algorithms recognize whether the encoding is in fact UTF-16BE (big endian) or UTF-16LE (little endian). But not everyone bothers to include a BOM.

And all these programmer errors, inconsistencies, and general deficits have led to discussions such as this one on Stack Overflow, in which the accepted answer explains that, yes, UTF-16 should be considered harmful.

What a big joke, eh? And so we should all be relieved that there's no good reason to worry about UTF-16 or to have our code support it, right? Well, no. It turns out the NTFS file system, and by extension Windows, still represents file names as UTF-16. If you want to have multilingual support for your application on Windows, it has to know how to UTF-16 encode and decode file paths.

Which is why I was recently working on adding UTF-16 support to mach, and you can see that code here.

[Pineapple]

Perhaps the single-most important milestone in any gamedev library's life is the completion of a first actual game using it.

So I made Sweeper, a minesweeper game.

This library still has a long way to go, but after nearly a year of work wow is it incredible to think how far it has come.

[Pineapple]

Today I'm writing about something that nearly every game programmer has used: Vectors.

Vectors are fantastically useful. They typically represent a point in two- or three-dimensional space, but they don't necessarily have to represent a point in space and they don't have to be two- or three-dimensional. That representing-a-point-in-space thing should immediately strike you as a useful thing to have: In games, quite a lot of things need to have positions on the screen and/or in a 3D scene, and vectors are how those positions are best represented. But they're also useful for pretty much any geometric algorithm you can think up, and there are a lot of standardized operations like dot products and cross products and scalar products and maybe one or two things that aren't products that help to make those algorithms relatively simple to express and to compute.

Though nearly every game programmer has used vectors, not so many of them have gone to the trouble of writing their own vector code and understanding exactly how everything fits together. (And why would they? There are so many vectors out there already.) But that's not the way I'm thinking about the code I'm writing, and so I've gone and done the obnoxious thing and just implemented a vector type from scratch. It combines all the best features I found in the vector implementations given by things like Unity and GLSL and Cinder in a nice sleek package.

It's turned out to be more than 1,200 lines just for this vector type! What makes it so interesting, though, is that it can represent vectors of any dimensionality and with any signed number type representing its components. And you can see its source, documentation, and tests, if that's the sort of thing that interests you, here: https://github.com/pineapplemachine/mach.d/blob/master/mach/math/vector.d