I used Direct3D and HLSL to produce multiple graphical effects in a single demo. My first goal was to create a deferred shading system which I did with 3 render targets (depth, normal, material/specular power). I also rendered the ambient lighting of objects to the back buffer at the same time I wrote to the G-buffer. My lights have an inner radius, outer radius, and falloff instead of normal attenuation as suggested by a friend. This controls each light's radius much better than relying on attenuation. I encountered a problem when oversaturating the color on lights when doing attenuation normally and using my previous light radius calculations. I implemented Killzone 2's method of optimization which included using the stencil buffer on medium to large lights (relative to the screen) to render only the pixels effected by the light. This can get rid of rendering any pixels for lights in the middle of a room that don't touch anything. The process is not cost effective on small lights.
Once the G-buffer from deferred shading was in place, I had access to a normalized depth buffer, and I was able to create crepuscular rays from light sources at far distances. I followed the CryEngine2's method and did 3 radial blurs of 8 samples each (for 256 virtual samples) on the depth buffer to produce this effect. I was also able to create a depth of field effect with the depth from the deferred rendering's G-buffer.
Since I was first doing this graphics demo for lighting, I also tried out volumetric light, quickly discovering the amount of sampling required to produce good effects. Essentially it uses plane-sliced sections of the light volume, but each pixel can have a different starting offset and a different number of samples. I also put functionality for rotating spot lights along their look direction and a "cookie" mask for projecting colorful textures. This allowed me to create a disco scene, which pleased me very much.
Networked Tank Game
I used Winsock to make a reliable UDP network for a tank game. The game would continue sending important messages, like if a shot was fired, until it received a conformation for that message. Things that updated often and were sent, like position, did not need to be sent reliably. This was taken into consideration to lower the bandwidth used. The receiving client would predict the current position of networked players based on current information and new information received. Servers broadcasted out to clients, and there was also a pre-game chat available.
"Smart Objects"
For an AI class final project, I worked with a teammate to create a simulation with "smart objects". These were essentially objects in a scene which would have information inside them to describe both how they would satisfy an AI user and how the user should use or operate the object. We used a bit of fuzzy logic to have each AI determine action it would take, which each AI unit having a list of needs and a quantifier for how much they needed something. With all the surrounding objects, each unit would calculate the benefit of using a particular object. When the unit reached the object, the object would instruct the AI what to do. In our simulation, we had 2 teams of 8 against each other with cover points and randomly spawned health packs. Each unit had one of three weapons. The sides would battle each other, while taking cover and sometimes picking up health, picking up a better weapon, or switching to a better cover point that was free of units.
A* Pathfinding
I implemented A* pathfinding with "rubberbanding" and Catmull-Rom splines. "Rubberbanding", as coined by professor Steve Rabin, takes 3 nodes on the final path and removes the middle node if there are no obstructions in the rectangle spanned by the first and last node. This process removes unnecessary nodes created by A*. The Catmull-Rom spline then adds detail and smoothing to the path for the character movement.