Troll Game Jam

I tend to really like game jams because I always learn a lot of things during the 24-ish hours of non stop development, so when a friend told me he is organizing a small LD like competition, my coder senses went all tingly.

I’ve long been an advocate of diversity, so just for the fun of it I wanted to see if I can do a game based on Qt that could run on anything (anything as in every platform that supports Qt), so this time around I fired up QtCreator and started making the game.

Interestingly enough, it took around 6 hours to implement a standard game of snake and another 6 for the rest of the gameplay,  and I say that because everything is made in C++. When I started game development I transitioned to interpreted and JITed languages because pushing pixels in C++ was a very long process, even with existing frameworks, maybe it’s the development experience I’ve gained over the years, but that no longer seems to be true, so it’s definitely something that I’ll explore in the future.

Back to the game though, the idea was to create a game so buggy that it becomes a challenge to play it. I think I’ve managed to do that to some degree, however if you don’t want to take my word for it, you can download it here

lase shooting snakes

The classic game of snake with lasers

I’m calling it a troll game jam because the unofficial focus of the jam was trolling the other opponents, and since at least for now I’m the only one with a playable prototype, I think I might have lost that round, but on the other hand something pretty fun came out of it.

Android support soon to follow.

Icon Misfortune

Around 60-70% of the tasks that you will receive as a programmer will be simple and very easy to do. Generally, you can suppose that the rest will be the same, the difference however is that they will generate bugs, and I’m not talking the kind that will turn out to be tasks themselves, rather about the ones that will spawn out of nowhere and persist for no apparent reason.

Let’s say for instance that you receive an icon set that needs to end up in a ribbon menu, the project used some other form of UI toolkit so you need to create a managed buffer, dump the raw image data in there and set that as a data source for the ribbon because in this case it’s better for everyone if small resources are embedded in a dll. And you do this and it works, only every icon looks normal except one. So each icon is 32×32 and they also get forcibly resized by the api to a 32×32 image when they get set and yet just one of them is 42×42.

Of course a quick debugging session revealed that the culprit was the DPI which is where the fun just started because of course everyone swears that unless otherwise specified WPF bitmaps are created with a default 96 dpi and that DPI settings only have a getter, so they are locked there and that’s where they will stay.
This is where you start to learn new things, remember the raw image data I was dumping in the stream? As it turns out, the PNG standard says that width and height aren’t enough to describe the dimensions of a picture, you should also save the DPI and to make everything perfect, if you go down to section 13.6 you see this little gem:

Non-square pixels can be represented (see pHYs Physical pixel dimensions), but viewers are not required to account for them; a viewer can present any PNG datastream as though its pixels are square.

Well guess what because of this tiny detail, every viewer I used showed the image as a normal 32×32 picture, except for that ribbon button.

Of course editing an image header to solve a little misunderstanding due to inconsistency isn’t really that much of a story in itself, but the way you get there usually is.