Over the semester of my Networked Games class, I worked on a group project that was to be a multi-threaded and easy to use networking framework, primarily for use with games. I volunteered to be one of two leaders, even though I was the only first-year grad in the class. Throughout the term, I worked primarily on the framework, personally designing and implementing most of it myself; while most of the other students worked on small features and demos to showcase them. Eryu, another programmer, was a great help in working on the framework. Together we practiced pair programming and debugged many issues.

Some of the features of our framework include:

• Automatic C++ Structure Serialization
• Three threads with intermediate buffers
• Composition-based Architecture
• Smart Pointers to handle memory management and reduce CPU load
• Peer to Peer networking with a 3-handshake connection protocol
• Unreliable, Reliable, and Sequenced UDP
• Optional Huffman Tree Compression

Also during this class I got hands-on  experience with building and using prediction, dead reckoning and convergence to smooth player movement in an imperfect networked environment.

Files

• Read the Flyer

The Summoning was developed at USC with a team of four students in my Game Design class. After testing a few core mechanics we chose ones we liked, which we then expanded to turn into this game. Throughout the project we continued to run many playtests as we incrementally changed rules to ensure our game provided a fun experience.

The first prototype was made with just normal playing cards and plastic beads, but I was lucky enough to have a great artist who I worked closely with to get a great look for the game. By the last playtest, we had a complete set of custom cards.

Though the core mechanics focus mostly on luck, the real fun of the game consists of the intricacies of the interpersonal relationships caused by who you decide to attack, and who you make your friends. The rules of the game create a very circular style of gameplay because there is a shared resource which fills up faster as a player gets stronger. This aspect of the shared resource allows for weaker players to come back when it seemed they were going to lose.

We also created an undead state so that no participant ever stops playing until there is an absolute winner; and to accent the importance of choosing your attacks carefully, continuing the dynamics of the interpersonal relationships. Playtesters found the undead state to be "one of the coolest parts". It helped to alieviate the frustration of losing because it offered them a chance for revival while also giving them the opportunity to impact the game, weakening players and, in some cases, choosing the victor.

Files

• Read the Manual

Through the development of Petrified, my team followed a complete game development process which was split into three stages: comprehensive design, implementation of design, and playtesting and bug-fixing. The project was done as my Major Qualifying Project (MQP) at Worcester Polytechnic Institute, which was essentially my senior capstone project. In it, over a six month period I led a group of three students to design and develop a multiplayer survival-horror game.

Throughout the project I held several roles. I worked as a designer, project manager, programmer, and technical artist. During the first stage, I worked with my teammates as a designer to create a comprehensive design document. In the second stage, we used this document to instruct our development. During the second and third stages, I ensured that we stayed on schedule, made sure that we knew at all times what was left to do, and what we could cut if we began to run short on time. I also worked on the code of the game as well as with our artist helping him to get assets into the game and critiquing and giving artistic input on what he was working on.

The third stage involved running a lot of official playtests, which provided us with a great deal of feedback on our game. People seemed to really enjoy it, and we actually had to kick out people at the end of the playtest period because they had been there the whole time, and would have otherwise kept playing long into the night.

The college's officials happened to agree with these playtesters, and so we were honored with the Provost's MQP Award for our project, an award which is only given to the best senior project from each department.

Below, you can watch a video which demonstrates some of the gameplay featured in Petrified as well as read a description of the game.

[youtube]-0K1ULcTap4[/youtube]

Petrified is a multiplayer survival-horror game. In each round of Petrified, up to fifteen players can join in as Mortals, while one additional player is selected to be the first Watcher; the Watcher must seek out the Mortals, moving only when they are not looking, until it is ready to strike. Each attacked Mortal becomes a new Watcher, cursed to seek out more Mortals until all are converted or day finally dawns. The Mortals must try to evade and defend until dawn, though their struggle will grow ever more desperate as more and more players fall and join their opposition.

Intersection-based testing is used to detect future collisions so that the boid ships can avoid any planets in their path. Originally I wrote a collision handling system so that boids would collide with each other gracefully, though later decided to remove it because it looked cool to have the swarms flow around the planets, like water in a stream; rather than have the ships bouncing off each other.

Rules:

• Every ship that hits a neutral planet will attack it, decreasing its population.
• If you attack a planet with 0 population, you take control of the planet
• You can send your ships between your own planets to redistribute your forces
• Occupied planets will grow in population over time

Controls:

• Left click to select a planet
• Left drag to create a selection box
• Right click to send ships from selected planets to the planet under the mouse
• 0..9 Change the percent of ships to send in a dispenser (0 is 100%)

Files

• Executable Download
• Visual C# 2005 Solution Download

There was only an hour left until midnight, but I had finally thought of something to do for Valentines Day. My girlfriend loves the video game character Kirby, and I remembered that in the Kirby games there is a angel power-up that makes him look like Cupid. Although this was a last minute idea, and I had only a little previous experience with JavaScript, I was able to pull it off in and still manage to catch a little sleep before the big day.

The final product was a website with a little Kirby angel flying around the screen trying to shoot your mouse cursor with a bow and arrow. In the off chance that he does hit, the arrow gets lodged in the cursors for a time.

I packed him up into a homemade e-card, and sent it off to her. She loved it.