Recently, I learned how to implement the super-awesome pathfinding algorithm called A*. Given a start point and a goal, A* will find the shortest possible path to the goal while evaluating as few paths as necessary.
Not satisfied with leaving such a juicy algorithm to rot in a classroom, I set out to build a game.
I chose to create a Cat and Mouse game where the player tries to reach a goal while running away from evil baddies. Sound familiar? Well I've made it before:
Warp Chase was the first videogame I ever made. And by "made", I mean copy-pasted from a game programming book and added some levels. Oh shame. At the time, I did my best to add some personal spirit to the title, but didn't know enough concepts to program any of the gameplay that I had imagined.
Lucky for me, this kind of game lends itself perfectly to A*, since baddies need to be pretty movement-efficient to chase the player effectively. I set forth to fully realize the gameplay I couldn't quite grasp before.
Implementing A* was an interesting exercise in itself. I spent a few days experimenting and optimizing my implementation. Ultimately, I cut my processing time for a long A* search from 117 milliseconds to under 4. The biggest gains came from two places: First, I evaluated visited nodes by looking up values in a 2D array, rather than wastefully looking through each nodes list of visited previous nodes. Second, I implemented my own priority queue using a heap, which saved a lot of time on sorting.
From a gameplay standpoint, the escape mechanic was fun for a while, but I quickly grew bored of it. A* was just too intelligent to waste on such shallow gameplay.
I wanted strategy.
While finishing the implementation for the Escape part of the game, I stumbled upon a very interesting bug. Effectively, the bug allowed the player to create walls that could trap unsuspecting baddies. Very interesting indeed.
A few experiments and 9 levels later, I found that the trap mechanic allowed me to make some modestly interesting puzzles. I won't spoil the levels here though. Go play the game!
In this assignment I wrote a variant of the Midpoint Algorithm to draw lines. You can also toggle attributes such as color, anti-aliasing, and line weight.
Here's a cool Wireframe renderer. I wrote Matricies that handle all the transforms from Object Space to Screen Space, and everything in between. I threw in my animated robot dude for good fun, and a slider that moves between a pure perspective and orthographic projection. With a perspective projection, objects farther away seem smaller and converge at a vanishing point. On the other hand, orthographic projection has no vanishing point at all.
I wrote the programs using a Java-based work environment called Processing. It's very easy to get started making cool stuff. Check it out.
Last semester, I took a Computer Science course about concurrent programming using the Agents. For my final project, I was put into an eleven-person programming team and tasked to design a way for robots to assemble kits in a Factory in 6 weeks. I have put together a walkthrough video of our results:
The five of us in my CSCI 201 class worked on the system design and backend. The other six people were in CSCI 200 class and coded the GUI components.
Our team was very strong, and chose to go well beyond the requirements for the assignment. We chose to make both the machines and the intelligence (making decisions for the machines) operate on separate threads, accurately simulating how a real factory would behave. There are approximately 43 threads in this program.
I decided to try pair-programming with one of my team mates on this project, which turned out to be the best idea ever. We designed pseudo-code for key parts of the system in a single night, and comprehensively worked through the code on paper (and an excel spreadsheet) to insure that the logic worked out. From there, coding was trivial.
The most difficult part of the project for me was designing the behavior for the Factory's FeederController. During runtime, the FeederController cycles through four major part-feeding states. At any time during any of those states, the Feeder could be interrupted with a command to feed a new type of part (or parts). The challenge was designing a system intelligent enough to appropriately respond to new commands under any circumstance.
Unit Testing was an unexpectedly lengthy ordeal, eating up a couple days of my life and 1700 lines of virtual paper. In hindsight, such a comprehensive Unit Test was absolutely necessary. I discovered several behavior-breaking bugs that would have been impossible to detect after integration with the rest of the team. In fact, after integration, my tested components of the system worked almost exactly as expected, and suffered significantly fewer problems than the horror stories I heard from other teams in the class.
While the resulting Factory simulation doesn't look as cool or flashy as the games on my website, it was a worthwhile team experience that dealt with some very difficult programming designs. Additionally, the tools I gained experience with, Subversion, Team Wikis, and Unit Testing, will be indispensable on future programming projects.
During the Fall 2009 semester, I took a 3D animation course that let me dabble in modeling, texturing, animating, and lighting 3D objects. I've put together a quick reel of some of the more interesting stuff I worked on.
The two big subjects the course introduced me to were animation and lighting. I really enjoyed animating in Maya; it breathed some much-needed life into my (otherwise static) creations. The lighting process is sort of a mixed bag. My 3D objects looked absolutely stunning when lit correctly, but the actual process of lighting an object well took a lot of practice and patience.
Overall, I learned some powerful techniques in this animation course that will serve me well in future 3D game projects.
This semester, I took a General Education class on Modern Japanese Literature. One of the cornerstones of the course was writing a lengthy research paper about one of the topics discussed in class. Happy to push my luck, I proposed to the professor that I build a game instead of writing a paper. I figured that creating a simple game to satisfy the assignment would only take a few days to make, and it would give me an excuse to work with Antonio Cade, a fellow classmate taking the course, and an excellent artist.
Our professor was intrigued with the idea, but only let us go ahead with it the project if we still wrote a 5-page paper to turn in with the game. Not too bad. That makes about 2.5 pages for each of us, and I could easily fill that space with discourse about the game design process. In fact, that's exactly what I did.
The game is pretty open-ended. You play as Godzilla, and can walk anywhere on the map. Beware that everything you walk into crumbles beneath your mighty feet. There are two ways to "win" the game. Either violently destroy all the buildings, or disappear into the ocean, never to be seen again. The point of the game is to reveal what the players think Godzilla should think and do. In actuality, understanding what Godzilla is about is a pretty sophisticated topic. The paper portion of the assignment discusses those issues in depth.
Antonio ended up writing the more "researchy" portion of the paper, while I wrote about the game design and vision. Frankly, writing about the game design process was one of the most fun things I have ever done in a writing course. The paper occupies the rest of this blog post. See if you can find where I stopped writing and Antonio began. ;)
I took a Fine Arts Design course this semester to contribute to my minor in 2D Art For Games. The course had me do a lot of sketching and painting with a solid watercolor paint called Gouache. The stuff was slick, better than printer ink.
These pieces are created by painting two sheets of bristol paper with black and white paint. The shapes are then cut out of one sheet and glued onto the other. The result is crisp, clean, and delicious.
The course put a huge emphasis on the process of drafting art. All of our assignments began with several pencil thumbnails, the best of which became ink drawings, then full size drawings, and ultimately a final painted product.
We also had our fair share of technical painting exercises. I will never look at gray the same way again.
My only frustration with the course was that I could not submit any of my final drafts as a computer image (not even printed). The final piece needed to be assembled by hand.
Of course, that didn't stop me from coloring my sketches in Photoshop to determine color schemes. :)
The final product, a 14 by 17 inch poster.
The last class assignment was to redesign a CD album cover. I chose one of my favorite indie composers.
I liked the pattern in the original cover, and decided to expand upon it with imagery that the music triggered in my mind. To keep in line with the technically raw nature of the music, I repeated the simple primary colors and strong angular lines found in the pattern. Materials used were colored pencil, and drops of paint for the stars.
Overall, this art class gave me great practice in design and composition. I learned some useful skills for designing color schemes that will be essential for my digital art projects.
