This is my first major project with Unity, which I’ve created within 30 days for the yearly SomethingAwful game development competition. Judging is still pending but I think I did alright. As seen in the trailer, it ribs from dual stick shooters, more notably Super Stardust; however, in the sense of gameplay, I was trying to look at Doom more of an inspiration than Geometry Wars/etc. The other big things about this project is the random generation of levels and loot drops. Level generation is pretty simplistic (take a look at my blog post about it!) but I think it was the right approach to take; that is, have a set goal in mind how the gameplay should flow, and design level generation around that. I’ve spent some nights looking over procedural generation wikis on various algorithms before the start of the competition, but the only concept I’ve used from any of them is using the random function. Loot drops was an interesting problem; not the part of actually implementing them, but balancing them. I’ve worked in a system that reads formulas from a settings file that anyone on the team could modify and balance on their own, as I was the only coder on the team. I’ve also implemented a system that would look for a new version of the settings file on my web server to download and use automatically. Only did that as I quickly got tired of uploading builds after builds of balance changes.
I’ve got into this strange tangent out of the adoration I had for Bastion. I’ve had the game on day one of the Xbox Arcade release, but gladly bought it again on the official PC release. When I’ve begun to install it, I’ve seen an installation dialog for XNA. I’m a bit of a fan of hacking on code, so I put the game through a .NET/C# decompiler I’ve written in college and fixed the generated code to the point where I can compile it again to have the same game. Out of this, I had ideas of modding the game by adding some roguelike mode or maybe even multiplayer; I’ve eventually opted to do something useful, like porting it over to Mac/Linux. Majority of my work was spent on MonoXNA, which was skeleton code at the time as it was going through some refactoring. It was very interesting work, as I’ve tried to do everything as a clean-room implementation solely for the open source XNA projects. I’ve modified the rendering pipeline enough to be as exact as possible as Microsoft’s implementation of XNA, and implemented my own Effects system for shaders, which comprised of XML files with GLSL code in them that compiled down to some binary spec I’ve made up. That might’ve been a bit overdoing it, but it was an interesting system that had some auto generation of GLSL code. My biggest accomplishment, though, was reverse engineering Microsoft’s compression format for XNB content files. I’ve known it was some compression format used on the 360 development kit, and eventually found some hint that it was based on Lz77 variant Microsoft developed called LZX-D. Thankfully, they’ve had some documents up on it, and I’ve been able to toy with libmspack code enough to decompress XNB files. I’ve written a C# implementation afterwards and had my code committed to MonoXNA, which found its way to MonoGame and other XNA implementations. I’ve done a bit of work for MonoGame a little but I’ve eventually went back to my own projects.
First graphics project I’ve done during college. I was taking a beginner’s graphics course at the last semester of my degree, which went over math and basic OpenGL and such. The final project was to be of some game, using what we learned of 3D graphics and OpenGL. I always use these sort of venues to challenge myself and set off to do something beyond that I know. I actually did have some idea of a game I wanted to do for a long time, but I did not plan ahead enough to actually get to that part. I’ve opted to implement a rendering process that was beyond the class materials, like deferred rendering. It was a bit much at the time, while piling on skeletal animation on top of that when I barely understood matrices, but it was something I was able to accomplish. I can’t say it was a beautiful piece of code I’ve made, but through the fumbling of FBOs and such gained me a firm grasp on the deferrred rendering concept. Right now I’m trying to write a new engine based on Irrlicht (for its simplicity in its codebase), modified with a component based architecture and a deferred rendering pipeline.