Skip navigation

Monthly Archives: December 2014

For our game engineering final, we had to use everything we had learned so far in the semester, and build a game using all that. I decided to remake a simpler version of my thesis game, 404Sight. It is a firs/third person runner inspired from Mirror’s Edge, with the eagle vision from Assassin’s Creed. The player uses their ping ability to reveal parts of the environment, using which they get have to get to the end as quickly as possible. I chose this game because I knew how all the mechanics worked, and wanted to see how simply I could replicate them in an engine I made from scratch. For my final, I decided to remake our first level, called the hallway. It’s straight path to the end, but the way is littered with fast and slow tiles. To reveal the tiles, use left click. Movement is through the WASD keys. You can rotate the player character around by using Q and E, but the movement axes are fixed for now. One of my goals for next semester is to get a third person camera implemented. The game exits when you make it to the end. The game name in the top left is a 2D Sprite. Another thing I want to implement is a timer, using a spritesheet. I learned so much in this class, about how to setup pipelines, which made it easier for me to add assets to my game, and I had negligible graphics programming knowledge before taking this class. Now I feel I know atleast the basics, and can now go deeper into graphics programming, and be able to render something that looks much better. I also delved a bit into making plugins for Maya, as I modified the Maya plugin given to us by the professor, changing the way it exported multiple meshes. I also added sound, which is the music that plays in game in 404Sight (The real one). Here are a couple of screenshots of my game:

game1 game2

In the debug build (both release and debug are linked below), you can press F1 to toggle debug lines. The debug line I have right now changes size based on the player’s speed. This helped me debug whether I had the intended interaction with each tile. You can find the debug build here. The release build is here.

Whats game development without a little crunch? Similar to the IGF week, this as another crazy one. We couldn’t get a lot done Tuesday, as everyone was waiting for everyone else to finish whatever they were working on, so as not to cause conflicts. But who CARES? Thursday, though was a whole different story. We got the new open level thing working – relatively bug free- at about 6PM. We had also reverted the ping to an older version, the one before the active reload. We also added the sounds and music that was made for the game by Keaton Anderson. Got the checkpoint-progress thing also working, and did a massive lighting build, which showed us the power of swarm. All in all, it was long week, and we left the lab at about 2AM. It was the same four people as last time, me, Tony, Kyle, and Matt. Matt worked on a video loop that we should on EAE Day, while Kyle added a new skysphere and some post process settings, which made the game look amazing. But as per tradition, I spent the morning of EAE Day fixing some last minute bugs, and getting a final build ready for the day. EAE Day itself was a massive success, and our game was well received. I also spent the next couple of days fixing some of the big bugs we found on EAE Day, in order to get this build ready for another IGF submission. Here is the video loop from EAE Day, showing the old trailer, as well as some sick new gameplay footage:

As was expected, not a lot got done over thanksgiving break, which was a nice break for everyone. The week after that, after battling the CS department, I finally got Unreal Swarm working. In case you don’t know/remember what it is, its a task distribution system, which distributes lighting builds among all machines in a swarm. What this simpy means, is that our lighting build times are going to be much MUCH faster now, which means that future level changes can be incorporated much more quickly now. Another amazing thing that happened was that we got a decal attached to the ping now, which makes it a billion times more visible, and it looks amazing. I worked with Joe and Vinod to get it working with the current ping that we have. We’ve also decided to try a more open approach to levels, and instead of linear levels one after the other, we will have levels interconnected to each other, allowing players to complete them in any order. What this means is that the current level system that we had is going to be completely replaced with a new system to accommodate this change. We added more functionality to checkpoints, and now in addition to saving the player’s last location, they also measure the player’s progress through the open level system, and decide when to unlock the last level. We’ve been working to get thee changes in, and are on track for EAE Day next week.

For this assignment we had to implement sprites in our game. Sprites can be used to display messages to the player, as well as UI elements. To do so, I implemented a sprite class. Since sprite are always drawn on top of everything, we draw them last, and with the depth buffer off. The sprites are also alpha blended with whatever is behind them, unlike meshes. To accomplish both of these, we change the render state of our device to disbale the depth buffer and enable alpha blending, then draw the sprites, and the undo the render state changes. The hardest part of this assignment was to make sure that the sprites don’t appear stretched, no matter the resolution. It took  some thinking and trying a bunch of different things before I could get that part working. Here are a couple of screenshots showing the sprites with two different resolutions:







The blue numbers on screen are drawn using a spritesheet. To change the numbers, press any number key from 0-9 to see the corresponding umber show up. This currently works with only the number keys that are above the letters on a keyboard, and not with with numpad. Here are a couple of PIX screenshots to show the render state of the device when drawing a sprite:

pixsprite1 pixsprite2


Here is another screenshot showing the PIX instrumentation:



Time Taken:
Reading/Understanding what to do: ~0.5 hrs
Getting the Sprite Class working: ~1.5 hrs
Adding new shaders: ~0.5 hr
Getting spritesheet working: ~0.5 hr
Making the sprites not strecht on resolution changes: ~1.0 hr

Total Time: ~4 hrs

You can download the working exe here.

Your browser may say that the file is malicious. This is because some browsers do not allow sharing executables from unknown sources. However, the file is perfectly safe to run.