I’m a happy graduate of Digipen Institute of Technology, class of 2009. Originally, jdmassey.net was intended to show off my work and resume. Now that I’m gainfully employed it’s freed up the site to be more personal in nature. A lot of what was on the old site is gone, but it is fun sometimes to look back at the old game projects. So, I’m keeping the pages from the old site that were dedicated to my senior, junior, and sophomore year projects (in that order). The original site was made around the time I graduated, so the tone and style are that of me ca. 2009, retained for authenticity.
Parabellum
Parabellum is my senior DigiPen project. I made this game on a team with Derrick Readinger and Jason Kilkenny. The video above is one of our final project. The game is much more of a casual game than our teams’ previous efforts. There aren’t any dangerous enemies or technical platforming sections. The mouse cursor moves the avatar, a snakelike creature, through the world. In the center of a world is the seed of a tree that has withered and needs to be rejuvenated. By moving about the world and collecting fireflies, then delivering the fireflies back to the tree, the player heals the tree and restores life to the world. There are red fruits in the world that make the player grow in length when eaten. Earlier designs of the game offered more actual reasons to want to grow yourself, but even in the current design it’s helpful – it makes it easier to collect fireflies, and just plain looks cooler.
Visually the game turned out very nice. The world is covered in dark fog that is repelled by objects that can emit light. Fireflies do, of course, and there are also plants in the world that emit light when the player moves near them. We were able to use our entire engine from the previous year that we built for Dusty. For Parabellum I added a few features to the renderer, namely post-proc effects like bloom. Parabellum uses deferred shading, which I think was a good decision considering the game design. It allowed us to have all of the fireflies emit their own light and render holes in the fog without too much extra work. Unfortunately there are a few graphical features we weren’t able to get in that would have really looked nice. Firstly I would have liked to have actual terrain beneath the player instead of just scrolling textures. Having terrain in the background that was lit by all of the game’s light sources would have looked really nice. Secondly, I would have liked to have nicely textured and animated fog. All we really did for the fog was darken the things underneath it. I got about halfway towards some kind of animation using perlin noise but that didn’t get far enough to see the light of day.
What really makes the game visually appealing is our spline system. The technique for rendering is pretty simple. We use a basic triangle strip mesh with multiple subdivisions, then send the spline’s control points to the shader and use the bezier formula to form a spline out of the mesh points. With just that one technique we’re able to achieve all of the vector graphics style effects in the game, from the springy seaweed to the awesome jellyfish. Of course the main tree uses it as well, and Derrick wrote the system for creating the splines and animating both the spline growth and the little leaves that grow out on the sides. It was all hard-coded, but it looked good!
I was responsible for the game’s level editor. It was the first editor I wrote that had do and undo, the most indispensible tool of any kind of editing software. Its capabilities were basically just placing entities and lights within the world. Derrick used it to make the level we presented with our final. It was actually a fairly significant amount of code when all was said and done, but the structure turned out well, and it was all in-engine. We only had to run a separate game state from the main game state to run it.
My other main contribution to the project was our organic ship growth system. Originally our game was supposed to be focused on combat and arcade-style action (whatever that means.) By destroying other ships you would gain their essence and by doing that your ship would grow out based on a rule system. The basis for our rules is L-Systems which are used mainly for modeling growth of organic things like plants. They seemed like a natural solution. However L-Systems by themselves lack certain pieces of information necessary to maintain a hierarchical structure and remember relationships between generations, so I expanded it into what I rather uncreatively called M-Systems for Modified L-Systems. The main part of M-Systems that made them usable for heirarchical relationships is that depth information is saved with each node. The generation strings are saved in a heap-like ordering such that an element’s parent is always the element before it with a depth equal to the child’s depth minus one. From that it’s possible to construct a tree from an M-System string, and back from a tree to a string without any data loss.
The system itself worked just fine. You can sort of see it in action in the previous video, and actually it’s still in use in the vinal version where you simply grow out in a chain. The fact that we were only able to demonstrate extremely simple rulesets belies the problem with our design – making interesting ship designs with procedural techniques is really hard. Especially without artists. I’ve learned that lesson many times thoughout my DigiPen career. Procedural content always seems so wonderful when first conceived, but its implementation is has rarely been better than hand-made assets. The procedural textures in Dusty were definitely my best use of procedural asset generation. Despite the fact that the system wasn’t really used, I am happy with how it turned out. It was actually pretty fun to write.
I’m happy with how the game turned out in the end. It felt like a unique idea that could have been even more awesome had we had more time to work on the other things we wanted to get into the game. Maybe we’ll revisit it sometime in the future.
Above is a quick video of the parabellum alpha build. The game as it appears in this form and style didn’t really exist until a few weeks before alpha. This is the point where the game turned in the right direction and we found a style and game feel that we wanted to continue building upon.
This video is the Parabellum Pre-Alpha build. Here we’re still foolishly trying to fit combat and shooting into our game. With the ship growth and mouse cursor controls it really doesn’t make a whole lot of sense. I’m glad we didn’t try to stick with this because it probably wouldn’t have ended up being much fun.
Dusty
Dusty is my junior game. It’s a quirky little shooter where you play a UFO flying above the surface of a planet destroying buildings beneath you, all the while escaping winding missiles and fast-flying bullets from enemy tanks and planes! Actual gameplay isn’t quite as exciting as high-concepts would have you believe, but all things considered, the content-to-work ratio on this project is actually pretty high.
The planet itself is a geosphere with 3D Perlin noise applied to it. I wrote the function to generate a geodesic sphere from an icosahedron and then used the noise generator to deform the mesh to look like terrain. After deforming the sphere, a procedural texture was applied to it to make it look purdy. In the end it ended up looking a bit like a golf course. It would have been nice to get some scorch marks or something in there but alas.
Actually, the original idea for this game was terrain deformation. After applying noise to the planet, the player could use his laser and bombs to deform the planet and burn away the water, with the ultimate goal of burning the planet down to its core. There’s a video down below that shows this build in action. When this was our main build, the planet was procedurally textured with a volume texture so that the layers of planet strata were visible as the terrain was being destroyed. It looked quite slick. Some HDR would have made it look really awesome. Unfortunately, since team Clock was a two-man team, we opted to remove deformation in favor of a technologically easier solution that we could actually complete on time.
We programmed an entirely new engine for this game that turned out pretty good – good enough to carry over to our senior game. I programmed the main engine architecture. It’s a simple system that has two basic parts. First is the array of engine modules – the main components that provide engine functionality (i.e., the renderer, physics engine, etc). These modules are registered at runtime and then the engine takes care of initialization, the game update loop, and shutdown. The second feature of the engine is the game state stack. Game states are simply collections of state functions and a bit array denoting which engine modules are active in that state. States can be pushed and popped at any time, and when the state stack is empty, the engine shuts down.
The renderer was probably my largest project. I built everything from scratch just because that’s what I like to do, so I created a custom mesh data and file format to represent 3D meshes, and a corresponding tool to parse .X files exported from Max with Panda and convert them to our binary format. All rendering is done with shaders which can be loaded and applied to entities at runtime. The renderer also has multiple buffers for rendering debug info such as lines and text and can render sprites which are mainly used for the UI.
The planet is textured entirely procedurally. The world position of each texel was calculated by converting from texture coordinates to 3D polar coordinates, and the height of the texel relative to the water was used to determine what type of terrain the texel was on. Apply perlin noise to add some randomness, and you got yourself a planet. I also programmed the refraction water shader. It isn’t very accurate at all but it looks good, which at the end of the day is all that really matters.
My memory controller was a simple module for managing individual object allocators. Types could be registered with the memory controller at runtime and assigned Ids. Objects of the registered type could subsequently be allocated by giving the memory controller the Id of the allocator to allocate from. Addionally, I included functionality for managed calls to new() when object allocation wasn’t entirely appropriate.
Entities were managed with the entity controller which handled creating entity objects and serializing their components. The entity model we used is a component aggregation model. The entity class simply contains an array of pointers to its components and updating the entity is simply a matter of updating all components in its array. We decided to avoid having to check for null entity components and created a null entity to accomplish this. Any entity that does not have a given component will have a pointer to the null component in that component’s position in the array of pointers. That way, we could avoid inefficient if-checks by simply implementing the null component’s functions to do nothing. The serializer wasn’t very robust – just an if-else series using component name strings to check for which component to serialize. It was improved during development of Parabellum.
During the previous summer I implemented a simple gui console using DirectX. We added it to Dusty though it didn’t see much use.
Aside from main engine things, I implemented a number of utilities, including a file reader that automatically buffered file data for faster reading and was capable of reading sequences of data for much easier text file parsing. It was used to implement an ini file parser. I implemented all of our math libraries, including 2- 3- and 4-D vectors and 3- and 4-D matrices, our perlin noise generator, and a few geometric computational functions.
Silhouette Apparatus
Silhouette Apparatus is my sophomore game. It’s both wonderful and terrible at the same time. You can click on the image below to see the large version. That one screenshot pretty much sums up the game. It’s an admittedly fun romp wherein you are armed with an arsenal of extremely overpowered weapons and a grapple beam. Your goal: swing your way to the end of the level. You can view a gameplay video that demonstrates the major aspects of gameplay above. It should tell you all you need to know about playing Silhouette Apparatus.
Looking back on this game creates somewhat bittersweet memories. The engine is what one might expect from a team of DigiPen sophomores (read: all kinds of messy), but hey, it gets the job done. Our TA actually said it was one of the better designed engines in our class. Because of the timing, none of us really had any background in linear algebra or basic computer graphics. Considering that I think we did a pretty good job.
We built the engine first semester of the year, while we were all concurrently taking our first linear algebra course. As soon as I had my mind blown by being shown that matrices could rotate things, I went off and built us a 2D keyframed skeletal animation system. After building a model using our myriad tools, we loaded that model into an animator tool (written entirely in win32) that I wrote for animating. If you watch the video you can see different examples of the avatar’s animations and the little green spiders. Not only that, but I also added very light procedural animation support, so the avatar’s arms and legs moved realistically while she was aiming and swinging. There’s a short section in the video where Elysium (our avatar’s never-uttered name) is hanging and the reticle is moving around to show her arm following the reticle. Probably my proudest accomplishment of the year.
As is typically the case, the build we turned in was really a tech demo that needed more polish to be a really great game. SA does have a lot of potential though. I wouldn’t mind revisiting it sometime in the future.