|Frog Game||Spherical Harmonics Environment Maps|
|Website Content Generator|
In Autumn quarter of my last year at UW, I took a class called Characteristics of Games, taught by Skaff Elias and Richard Garfield. We analyzed a number of different attributes of all varieties of games, giving us a new framework to use to think about games and game design. Towards the end of the term, we played a game in class on the whiteboard. After playing through the game, the four teams picked one way to modify the game as a final project. For instance, one team turned it into a gameshow. I convinced my team to turn it into a video game. Microsoft had recently come by UW to demo XNA and had given out trial subscriptions to let us run our games on the Xbox, so I thought we'd give it a shot. We had three CSE seniors on the team, so we had enough programming power to pull it off. In the end, we spent about a week straight of late night programming, including learning XNA, and made what I think was a fairly respectable showing for it.
I learned a lot about making games from this. We demoed the game in-class on my 360, which was really telling about how important it is to get other people to play test your games. Becuase we had such a time crunch, we ended up not having any sounds. When we demoed the game, we found that the silence really detracted from the gameplay. I had never realized sounds could have so much effect! Since we had such a short time to make the game, that certainly wasn't the only problem, but that stuck out for me and I'll remember it when I make games in the future.
Note: when we made this, we were developing it with the XNA 2.0 beta. To deploy it to the 360, we had to port it to XNA 1.0. Now, XNA has reached version 3, which doesn't have an automatic solution-patcher, as Visual Studio does for previous versions of Visual Studio. I haven't explicitly rewritten it to use the latest APIs, but the quick project I made appears to work with XNA 3.0 on Windows.
The game is for 4 players (or teams). Each player has a unique color, with one frog in each of the four rows. The rows are numbered 2 through 5. Players takes turns advancing their frogs to the goal spaces at the right side of the board. The first to get all their frogs to the goal wins!
To take a turn, roll the 5 dice. Then, select which frog to use. For each die that shows the selected frog's number, the frog will be able to advance 1 space. 6s are wild, and thus always add extra movement. 1s are Zonks: they don't match any frog, and if you get 3 Zonks, your turn is forfeited! Zonked! After selecting the frog, it is fixed for the remainder of the turn. It is then up to you to either accept the current move, or to try to roll any non-Zonked dice for additional spaces. You can continue rolling as long as you like: matching numbers will continue to accumulate, but Zonks lock the dice. If you get 3 Zonks, all your moves that turn are forfeited.
Only one frog can be in a space at a time. What happens when if you land on an occupied space? The 3 kinds of spaces determine what happens:
|Water spaces cannot be landed on at all. If your frog lands here, it will be moved to the space to the left, all the way until there's a space it can land on.|
|Lilypad spaces knock the opponent frog back one space to the left.|
|Rock spaces knock your frog back one space to the left.|
The first frog to reach the goal space in its row will cause the goal to slip to the right, adding an extra water space.
|Platform||Windows / D3D10|
During my first semester in my Master's, I read up on PRT techniques. A key part of this and many similar techniques is to simplify expensive surface integrals by exploiting basis functions like Spherical Harmonics (a.k.a. SH functions). SH functions come up in quantum mechanics and chemistry: you may know them as the electron orbitals. You can use SH functions to speed up dynamic environment lighting by storing the lighting as SH coefficients. This is explained in more detail in this paper.
I decided to implement this as an exercise, as well as to try out DX10. This program displays a sphere illuminated by the Grace Cathedral lighting used by Ramamoorthi's Environment Map paper. Since I was familiarizing myself with DXUT and DirectX 10, I wrote a series of object wrappers for the API boilerplate code, with the idea that I would be able to reuse it. It would be overkill if my only goal was to implement the paper, but building that functionality helped me learn the APIs.
|Platform||Windows / DX7|
Fluoresce is a space shoot 'em up game. There are an endless number of waves of enemies that get increasingly harder, and you can collect powerups and buy weapons and ammo at a shop between waves. This was written in C++ using DirectX 7. This started out as a game I wrote during a game programming summer camp I had at DigiPen. It was written using a proprietary thing called Fun Project. I was irritated that I didn't get to learn how to actually code the games, so I made it a goal to replicate the game as best as I could, solely in C++. During my highschool programming class, I was given the opportunity to work on my own project, as the class was originally intended for beginners. So, I grabbed a C++ / DirectX book (actually a pdf), and set to it. This is the result.
A cautionary note: I wrote this with DirectDraw and DirectInput from DX7. These are old technologies, so the game does not run very smoothly.
This is a small 3D engine that displays a rotating mesh. This was done as a project for my 10th grade programming class. The scene itself is not terribly interesting, and it's the same every time. The program rotates a camera around the object, transforming it into the camera's viewing space, and then calculates the diffuse color given that the camera is shining a light on the object. Then it draws the triangle using scanlines. It's not perfect, as I only had part of a semester to work on it. It still served as an excellent introduction to 3D vector/matrix math, scanline rendering, z-buffering, and Gouraud shading.
If you would like to run it, I should warn you: I used MS J++ and I didn't make a real UI for this. It doesn't rely on any obsolete J++ features, fortunately, so the source can be compiled with the standard JDK. I only had a test class that did some math tests and then drew a hardcoded scene to the screen on an infinite loop (Keep in mind this was in 10th grade, so I didn't know how to make unit tests and use Swing). The window it uses doesn't show up in the taskbar, so if you run this, it's best to run it from an IDE like eclipse, as you can easily kill the process that way. I'm keeping it as it is for posterity's sake.
This was built as the final project for CSE 326. This project demonstrated the most common unweighted graph search algorithms. I programmed this with my partner, and then did a bunch of enhancements to it. The original requirements were to simply read in a maze from a text file, then spit out another file with a path from the start to the finish, along with some statistics. I added a GUI to view the maze and the paths found. I also modified the algorithms so you could step through the process, much like a debugger lets you step through lines of code. My partner added a routine to generate random mazes based on a number of input paramets such as maze size and complexity.
Back when I had a Nokia cell phone, I played a game on it called Snake. It's a clone of a classic game known by a couple of different names, such as Nibbles from MS-DOS, Rattler Race from Win95... The basic idea is that you control a snake that travels around the screen eating apples that appear in random positions. As you eat more apples, your tail grows longer. You must avoid hitting yourself or any walls. The old Nokia version was no more complicated than that. Some versions included wrap-around edges, walls in the middle of the playing field, bonus apples, to name a few. I had tried to make a version of Snake using TI-BASIC on my TI-89. The program proved to be so slow that the head could only move a grid cell or two every second. I had seen some far more complex programs written for calculators run faster, so I decided to learn how to make one.
All of the TI-8x graphing calculators have microprocessors on them capable of running arbitrary machine code. Assemblers had been written for all the varieties, but someone had written a GNU C compiler for producing programs for the TI-89 and above. I had a little bit of C experience, having taken a summer programming camp, so I used this a learning opportunity to expand my C skills. I also familiarized myself with a selection of libraries for TI-89 programs, such as graphics packages that handled flipping the LCD pixels quickly to create an illusion of grayscale.
I actually wrote Snake two times (that's why you'll see a file called Snake2 in the source). The first I created to just get the functionality of the TI-BASIC program I had first written. Then I decided I could do more, and I revamped the graphics and added a level editor. I added a font engine that would draw characters based on a sprite font I made instead of the built-in characters to match the feel I wanted to give the game. I threw in a number of special effects like fade-in/out and special wall graphics. The best way to see it is to load it on a TI-89 or an emulator such as Virtual-TI.
|Platform||Windows / .NET Framework|
I used to use PHP to keep my webpage layout consistent and make it easier to update. Without some footwork we only have access to static content on DGP servers, so I decided to write a program to autogenerate the content for my page based on same layout files. I just run this program when I make a change and it spits out brand new static .html files. I had just been looking into ASP.NET MVC, so I was heavily influenced by their design. I started with a simple program that looked for hard-coded tags, iterating until eventually I had files with combined C# and HTML, MVC separation, and master files to simplify maintaining consistent layout.