2015-06-07 - Domestic Flights

Recently I had the chance to go on a short domestic flight. Most of the flights I’ve been on have been long international flights and by comparison this flight was amazing. A little bit of security at the start and then it’s just get on plane, get off plane, go home. No serious security officers scrutinising you. No customs agent prying at you. Nice, simple, and easy.

Even the flight itself was great. I personally enjoy flying, but there’s only so long that it feels comfortable to sit in a tiny seat. With this flight they had barely finished serving snacks when it was time to land.

Good times.

2015-05-24 - Shakespeare Wasn’t a Programmer

There’s a line in one of William Shakespeare's plays that goes something like “A rose by any other name would smell as sweet”. The idea being that what you call something doesn’t impact what it is. A rose doesn’t change its smell because you call it something else. This is not the case in programming where something’s name determines what it is.

There are lots of named things in a program and the names chosen are used to give meaning to their usage within the program. A variable name describes what data it holds. A function name describes what it does. It’s possible to have identical variables with identical data that are differentiated because of their name. An account object may have two floating point values, one named “Credits” and one named “Debits”. They could be stored using the same pattern and contain the same value but because of their names we know they are different.

Going even further without a type a variable is just a set of bits. It’s possible to take a floating point value and treat it as an integer or as a series of characters. The type is required to give meaning to the data stored but that type can be changed and the meaning of the data along with it.

That’s the problem with working in a medium where you’re making everything.

2015-05-03 - Branching Storylines

I am a big fan of stories in games. Some of my favourite games are so because of their stories. That’s why it bugs me that there’s a trend in games towards having very open stories. Games where the player is given a lot of control over what happens. They can choose to go here or to not go there. They can choose to save the village or to burn it down. The player is partially responsible for writing the story and that makes it difficult to have a really strong story.

The problem is that these choices make alternatives. A character could be dead in one version of the story but alive in another. The player could be evil in one story while they could be a saint another. It’s difficult to have a strong story when everything in it is so fluid. Now I do understand the reasoning for this. Players like to feel that their actions have impact. That they’re doing something and not just following along.

Personally I would prefer it if the choices where limited and fairly obvious. That way the player still had impact in the story but at the same time there aren’t too many alternatives. That way it’s easier to polish the story and make sure it’s solid while at the same time allowing the player to go through all the possible stories.

That still leaves the problem of endings though. It’s difficult to make a sequel to a game with multiple endings without picking one or just making up a new one that’s a combination of all of them. As I said it’s hard to have a strong story when everything is so fluid.

2015-04-19 - Character Encoding: Endianness

Data is stored on computers as a series of bytes and the order in which these bytes are saved is based on the endianness of the system. big endian systems store the most significant byte (MSB) first while little endian systems store the least significant byte (LSB) first. For example consider the number 305,419,896 which is 0x12345678 in hex. Every two digit hex digit is a byte so in a big endian system the byte 0x12 would be saved first while in a little endian system 0x78 would be saved first.

If the same system saves and loads the data then everything’s fine. If the value is saved on a little endian but read on a big endian system it would get the incorrect value of 2,018,915,346. The same would happen going from a big endian system to a little endian system.

Endianness is not specific to character encodings but it is one of the places where it’s most noticeable as text is commonly sent between computers. Because of this programs are often designed to read and write both ways so endianness is no longer a function of the computer being used but dependant on how the program saves the data.

UCS-2 and UCS-4 solve this problem using a Byte-Order-Mark (BOM). The character U+FEFF is placed at the start of the file to indicate the encoding and endianness of the file. U+FFFE is an invalid character so if it shows up at the beginning of a file then it can be assumed that the alternative endianness should be used. Big-endian is assumed if no BOM is present and the format is not otherwise specified.

The BOM allows Unicode text to identify it’s own characteristics so that there’s no external information required to display the data correctly.

19 20 21 22 23