This post was written by Shaun.

My job is menial. I write code that does things that other people have written code to do a million times before. Reinventing the wheel eight hours a day can be frustrating, but so is making your bed when you know you’re just going to mess it up again. It isn’t often that I get to actually apply knowledge I’ve gained on my own to my work, and so it brings joy to my heart on the rare occasion it does happen. It is my turn to blog apparently, so I will describe one of those occasions here!

Quite awhile ago, my young friend Bradley and I were talking about making an adventure game. Like just about everything we talk about making, we got so mired in ideas that we lost sight of just what it was we actually wanted to make in the first place, and never got around to it. One of the problems with adventure games though is that you have fudge perspective on a 2D screen. Well I suppose that’s a common problem to many video games, but it was particularly a problem for us because it seemed likely I would have to write the code for it and I’m ridiculously lazy. When Brad proposed things like creating grey scale bitmaps to specify the depth at any given point in a scene, I would shudder. That sounded like a lot of work frankly, and work is a four letter word. So is word, and also four. Whoa!

Anyway, this planted a seed. A “thinking seed” as I like to call it in Shaunese (I’m an amateur wordsmitherist). As luck would have it this seed sprouted into a beautiful opportunity for me to look smart at work, which is important if you want to get paid.

I am going to be intentionally vague on what the actual work needed to be done. This is so I don’t get fired. Basically, we needed a way to determine perspective in a two dimensional context. Sound familiar? Of course it does, I was talking about it two paragraphs ago.

What I ended up doing for work is what I would do now if I were to face the same problem that past Shaun and past Bradley faced. I created a quick user interface to specify regions on this 2D image. You would outline each region where the scaling of an object as it proceeds away from your point of view is fairly uniform. You would then within these regions specify the largest a given object would be, and the smallest by drawing two rectangles (one big, one small) inside this region. It doesn’t really matter what kind of object, as long as it doesn’t change size. You repeat this process until your entire image has these perspective regions outlined.

Then on the back end you just create a vector for each region based on the two object size boxes it contains. When you are trying to figure out how big to draw your object, you pass it’s coordinates to a function which figures out which region you are in, and the nearest point on the perspective vector. You use the length from the point on the perspective vector to the end of the vector where the bigger of the two boxes were to create a scaling coefficient. Multiply the dimensions of your object by the scaling coefficient and bingo bongo you’ve simulated perspective on that guy!

So easy! Anyway, it was a lot of fun for me to be able to do something like that at work, knowing that it applied to a problem I had run up against elsewhere. Granted it is still a problem that’s been solved many times before, but at least this time the code to solve it wasn’t a Google search away. Maybe now I should make an adventure game?