Because The Trip was a multiplayer game, I chose to pursue a research topic on dynamic split screen. I devised a system that would maintain a single screen when the players were together and divide into smaller screens when they separated. A similar approach can be seen in games like Lego Indiana Jones 2 and Lego Harry Potter Years 1-4. The main difference, is that the system I devised was capable of tracking more than two players and dividing into more than two separate screens.

This topic was difficult for a variety of reasons. The main issue was that there was little to no previous work on how to handle many of the issues I was running into. Very few games use dynamic split screen in this fashion and they don't exactly publish their code for inspiration. I had to devise many of my own techniques. I opted to go for clarity and simplicity over efficiency in some cases to eliminate many extra issues that would have distracted from the main goal. Therefore in many cases the code is deceptively simple. Additionally, as the requirements for the code as well as my own abilities with object-oriented programming reasserted themselves during the game the code changed its structure.

I believe that my own research made but a dent in the overall topic. I was only successful in creating smooth camera transitions in a limited number of scenarios. However, I was successful in many other ways: I defined the problem and presented it as a possible solution to the restrictions local co-op games place on camera behavior and world navigation. I identified several areas that would need to be further explored to provide a fully robust camera solution. Finally, I explored some possible methods for accomplishing this form of dynamic split screen. While insufficient on their own to provide a stable system, they can provide a lot of guidance for future exploration of the topic.

I was responsible for programming all camera behavior, the design and programming of particle emitters, and the behavior of all weapons and game items, fueling, projectiles, and help text. By making good use of inheritance and interfaces, I was able to effectively minimize the amount of repeated code, simplify classes, easily add new features, and fine tune game balance. This made for classes that were small and contained a minimum amount of code necessary for a designer while parent classes contained any common code and handled any of the more complex code that interacted with other systems.

One of my goals when architecting the game logic was the allow room for expansion. I knew we couldn't implement all the features we wanted for the capstone deadline, but I didn't want to make it impossible to add them at a later date. I found that while sticking to this thinking made for extra work creating interfaces and modularizing functionality, it allowed me to add new features much faster as well as tweak them during balance and testing.

At the same time, an eye was open for speed and efficiency in performance. Techniques such as sharing a single manager for all the instances of an object (for example, all flare guns use the same projectile manager and particle system) and avoiding object instantiation and asset loading during runtime were used to enhance performance.

This project really allowed me to explore my love of game programming. It was very satisfying designing and implementing the architecture for the game logic for The Trip.

Below, I've highlighted some of the main systems I worked on and indicated where more details can be found in the TDD. Samples of source code can me made available upon request.

Help Text

This system was designed and implemented in less than a day. It was designed during crunch time with minimum interaction with other systems and demonstrates a system that is highly modular, easily expanded upon, quickly implemented, and improvised from existing functionality. The details are described in section 4.6.13.1 in the TDD.

Particles and Emitters

The particle system in the game engine was derived from the 3D particle system available at the XNA Creator's Club. It provided most of the base functionality for particles but I added a lot of additional functionality.

I added extra methods that passed various parameters to the engine so that the engine didn't have to recalculate variables that were being explicitly set engine-side. I also added the ability to fire multiple particles in a single shot (4.4.12.3 of TDD) and created a class that represented a pre-initialized pool of emitters that would regulate themselves, isolating that responsibility from other classes. Additionally, I added an interface for trackable objects that could be added to objects that needed to have emitters attached to them. this way, the emitters would handle updating themselves according to whatever object they were attached to, rather than having each object with an emitter attached have to worry about carrying the emitter with it (4.6.4 of TDD).

I also designed all the particle emitters currently visible in the game. This included the particle settings, textures, and behaviors of the emitters.

Weapons

Each projectile weapon could implement a child class of projectile manager allowing for individual weapons to have unique visual effects and behavior during firing and impact. Meanwhile, the parent class would initialize all the emitters specified, handle bullet movement, collision detection, and recycling back into the bullet pool. This minimized the amount of exposure designers needed to have with the system. Weapons are explained in section 4.6.6.4 of TDD.

Avoidable Lights Manager

The ALM was responsible for removing the game logic surrounding enemy-light interactions from other systems. Any object that wanted to have a light that the enemies would be afraid of could register the light with the ALM during construction. It only needed to specify when a light was on or off and the ALM would handle any other interactions the light would have. This made it easier to add non-peripheral lights to the game (such as the light using during a panic moment) and add non-point lights as avoidable lights. The ALM is described in section 4.6.11 of the TDD.

Health Interfaces, Damage Per Second Mods

The DPS system was responsible for tracking damage per second effects on creatures. While it was only used on enemies to do damage, I wrote it open-ended so it could be used on entity implementing the ICreatureWithHealth interface and also do healing over time too if it became necessary. DPSMods are stored and updated by whatever class they are most conveniently associated with. However, they are managed separately from whatever entity they are attached to. so a creature does not need to know they are on fire. This is described in detail in section 4.6.12 of the TDD.

Peripherals

In designing the properties of peripherals in the GDD, I deliberately categorized the peripherals into portable, deployable, and weapons. I did this because I anticipated a need to devise separate classes for the different types that would share various behaviors.

I then used these designs to create the classes for the peripherals, separating them into this three groups so as much code as possible could be deferred to parent classes. This made the classes very short and they contained almost no code that was not directly related to how they would function in the game. The classes contained all the basic parameters about fuel consumption, projectile speed, light range, etc. They also contained the specific behavior that is unique to the peripheral.

The Trip was the largest project I worked on at RIT. It was a unique experience for many reasons:

1. I got to use HeatherWiki cooperatively. In the past, I was the only one who used HeatherWiki on a project. Because of the extensive amounts of documentation required for The Trip, all the documentation in the first phase was maintained by HeatherWiki. It was rewarding to see others use it and appreciate how it helped make life easier. It also made it easy for us to share our works with artists and others who were assisting us.
2. I worked with an outsourced artist. On previous projects, the art was produced by members of team. On this project, our team acquired the services of an outside artist. The artist, Sam Sawzin, was very talented and creative not only by bringing our ideas to life but providing invaluable creative input. However, we had to work with an artist who was not a programmer. My experience with Spellcraft helped me in this area and it was good to practice speaking to artists in nontechnical terms.
3. I did my own game audio. On previous projects, other team members were responsible for audio. On this project, I took charge. Since I didn't have the skills to create much of my own music or effects, I had to find alternatives. Sifting through the limited amount of freely-available sounds and audio samples on the internet, I also learned to use Audacity to modify sounds I choose to work with.
4. I couldn't balance the way I normally do. This was the first game that was a multiplayer game. It also had adaptive AI. The AI was developed by Jay as part of his research. Because it was his research, I couldn't go into the AI code and modify it and adjust parameters to tweak balance myself. I also couldn't play-test myself.

Because the AI was adaptive, balancing was particularly difficult. Normally, I will implement a feature and play the game adjusting parameters until I am satisfied. In this game, that was much more difficult. This meant I had to make sure that code was easy to adjust and I could clearly articulate changes that needed to be made. This was a valuable learning experience.