EAE6320 – Final

The final assignment/project for this class was to make a simple game with the code base that we have established in this class.

In my game, you are a cat that is trapped in a room with a laser pointer bouncing around with mirrors. The cat must stop this madness by finding the source of the laser. To do this you must collect mirrors by finding the last mirror that the laser beam has reflected off and collect them in order until you can collect the source of the laser.

Controls are, WASD for forward/backward and left/right movement. QE for left/right rotation. All you have to do is collect all the mirrors and the laser emitter. The game doesn’t end so you can move around the level if you wish.Final


As a user of the engine code I wrote earlier in class I learned or rather experienced some difficulties when making the game.

A large portion of my time went into trying to get the camera to work properly. This took so much time because I was using the Math library given by JP which wasn’t exactly fleshed out for general purpose usage. Specifically I needed to find the forward vector of an object (or the camera). To do this you take a the vector (0,0,-1) and apply the object’s transform to it. The problem was that the object’s rotation was stored as a quaternion and there was no function to rotate a vector using a quaternion. So I had to search online and write my own. This was tricky because the rotations weren’t behaving the way I expected them to. Eventually I got it to work, however, later JP pointed out that I could use the basis vectors of the local_to_world transform(which is part of the math library) to get my forward vectors.

The second biggest hurdle was making the level. We have no level editor of any sort and because all the assets are exported centered on origin, I had to do this tricky business of making the level in Maya and then copying the coordinates and rotations¬†from Maya into my code. Obviously this doesn’t work so well in practice and takes a while to get things in the right places.

We spent a lot of time in class towards the asset build pipeline. But I don’t know if there was any benefit from it in the end. I found that each time I had to add a new asset I would have to manually add things in 4-5 different places. Often if I missed one of these locations, my assets won’t show up in game and then I’d have to debug what went wrong. The asset building makes a lot of sense to me, but it didnt work so well in this class. Each of the individual builders worked fine but the whole pipeline didn’t work as a coherent system.

We also spent a lot of time doing the same things on the two Graphics APIs. I think this was really cool for the first half of the class where we had to come up with interfaces and good design. But for the second half it was really just doing the same thing in two different places. I don’t think it was the most effective because it quickly became the matter of just getting things to work rather than learning how to do graphics or learning to do it the right way.

Regardless I definitely learned a lot in this class. Personally I welcomed the structuring of the solution into different projects and setting up build dependencies. Doing the graphics interface for the first time was challenging as well. Loading binary assets was also interesting, though sometimes I felt it was taken too far. I also started using namespaces a lot in this class. This affected my coding style.

That’s all folks.