Coming off of our game jam, we needed to immediately begin brainstorming ideas for our real game.  The GMAP project schedule was extremely accelerated compared to our own CS one, which is why we had to form our team and start working even before the academic quarter began.  After pitching various ideas to each other and to faculty members individually, we settled on one that the whole team was on board with: a 2v2 minigame-completing race, where each challenge is complicated by interference from The Rift, a magical entity that both physically separates the two teams and causes adverse in-game effects for them.  In order to gain advisor approval, a game concept must boast a unique selling point, and The Rift was ours.  The GMAP Team put together an official pitch presentation, and we received permission to start working on Trials of the Rift.

​

But there was a caveat.  The advisors were having trouble "visualizing" the game, so they asked us to produce a prototype for it...immediately.  This fell entirely on the CS Team, to create something demonstrating base functionality (using default assets) as quickly as possible.  I had learned from CS-451 that I wanted to be the System Design Lead on our team, so I spent an evening whiteboarding with the other two coders most-experienced in Unity.  The result was a giant UML diagram, augmented with liberal comments and sketches of how the Unity scene would be constructed.  Once the prototype's design was complete, we passed it off to the other programmers to actually code it.  This would allow them to become more experienced with Unity as well. 

 

Within Unity, it is trivial to set up characters who can move and shoot.  We concentrated our efforts on The Rift's behavior and implementation of the minigame gauntlet instead.  To get Rift crossing to work as intended, we relied heavily on Unity's tagging system, which let us determine when objects of specific types were colliding with each other.  Anything tagged "Spell" needed to be able to cross through The Rift as if it weren't even there, but when a "Player" contacted The Rift, they would meet a solid barrier instead.  Prolonged contact would steadily increase a pressure variable, and when it reached a certain threshold, The Rift would momentarily "open" and allow that Player to cross over to the other Room.  This would also start a countdown timer; during the countdown, any other Players could cross The Rift instantaneously (without needing to build up pressure first), and when the timer expired, any Player not in their same-colored Room would be automatically teleported back.  Why would anyone want to make use of this mechanic?  In this game of racing to complete team-based Objectives, we wanted Players to have a way to "mess with" their Opponents, by crossing to their Room and either interfering with the Objective there or just attacking the other Players directly.

​

A second reason to cross The Rift is to steal the Opponents' Room.  As the teams raced to complete their Objectives, one could potentially pull a few Rooms ahead of the other.  If both members of the trailing team managed to cross over and then push both members of the leading team back over The Rift (so both red Players are in the blue Room, and both blue Players are in the red Room), the Room colors would then switch to reflect their new occupants.  More importantly, the Players would then take over the Objective in their new Room...and their Opponents' progress in the race along with it!  This feature would allow the losing team to perform a major upset at virtually any time...if they could successfully pull it off.  The prototype was only 1v1, and did not have a "win" state to speak of, but (through the use of a Color enum shared by both Players and Rooms) we implemented Room stealing anyway...because it was cool.  (This mechanic was ultimately deemed "too confusing" and cut from the game, much to the whole CS Team's dismay.)

​

The Objective we could implement the most quickly was to defeat a number of Enemies.  The AI was very simple as well: each Enemy would randomly pick a Player in their Room and slowly move towards their position.  One hit from a Player's spell would destroy the Enemy and increment a counter.  When a Room determined it no longer had any Enemies in it, the door at the top would unlock and allow the Players to enter the "next" one.  This would eventually load a new Objective, but for the prototype, we just respawned the Enemies, reset the counter, and changed the floor color to simulate progress.

 

One last thing to mention: The DarkMagician.  This special Singleton class served two purposes: first, it took on normal GameController functionality, things like spawning the new Objectives when it was time, and (eventually) checking for the win condition and acting on it.  But we also had the forethought to set up the DM as a place to house all of the really cool or experimental features in the game, like the Room stealing.  We really liked the idea of a DarkMagician pulling all the strings to control the game, and we all know that programmers really are wizards, and our code may as well be magic.  It worked so well thematically that we eventually adopted "The Dark Magicians" as our CS Team name.