Visualizer

 
standing poster.png

Download the game here!


Project Description:

Visualizer is a first-person, horde-based, rhythm shooter. The player, hired by club dSync, takes on the role of a specialized exterminator to help the club get rid of its infestation of data beings known as “Ghost Frequencies”. These “ghosts” are ethereal manifestations of audio frequencies normally imperceptible to the human ear. However, since the player is equipped with a specially designed suit and technology, they are able to see these ghosts in the real world. These ghosts have begun tampering with the audio waves in club dSync in such a way where patrons have become sickened and no longer frequent the establishment. In a last effort to reclaim their spot as the best club around, club dSync has hired the player to infiltrate the club and use their special equipment to find the source of these invaders and eliminate them for good.

Development Info:

  • PC

  • Developed originally as a team of 4 (2 Designers and 2 Artists), eventually expanded to on-board 9 new team members at the start of the Spring 2019 semester

  • Development span of approximately 1 academic year (September 2018 - Current)

  • Developed in Unity 2018

  • Utilized Agile, Scrum, and QA techniques to guide development

My Roles:

  • Lead Level Designer

  • Systems Designer

  • Technical Designer

  • UI Designer

  • Sound Designer

  • Team Management

Team members:

  • Art:

    • Jennifer Carlin (Lead Lighting, Environment, UI) (Original Member)

    • Isaac Singer (Lead Character, Animation) (Original Member)

    • Monica Almodovar (Environment)

  • Design:

    • Simon Estabrook (Lead Systems & Technical Design) (Original Member)

    • Thomas Sullivan (Systems & Technical Design)

    • Michelangelo Demo (VFX Design)

    • Graham Pannier (Sound Design)

    • Jacob Olsen (Level Design)

  • Programming:

    • Alexander Rader (Lead AI, Audio, Gameplay Programming)

    • Aaron Hamilton (Audio Programming)

  • Production:

    • Cody Douglas (Lead Producer)

    • Brandon Schlossberg (Producer)

 
 

Premise:

The idea behind Visualizer stemmed from a particular scenario I often try to recreate while I play a game. If I chose to put on my own music while I play a game I will notice myself emulating the flow of the song in the game and I often try to time cool combos or abilities in the game to a big beat drop in whatever song I am listening to at the moment. When I am able to execute one of these maneuvers it feels extremely satisfying, and it is that exact sensation that I wanted to try to emulate in Visualizer’s design. I essentially wanted to make a game-loop that revolved around timing the player’s actions to the beat of music.

In terms of the game’s setting and lore, the “ghost frequencies” that the player is exterminating are based in a real life audio production theory. The theory states that the higher and lower end frequencies in a music track that are outside the human hearing ranges; if not EQ-ed out of the track during the mixing process, will reduce audio quality (though only to an extremely minimal extent). These frequencies are often also called ghost frequencies since humans cannot hear them, but speakers will still try to process them and waste time and energy on playing the sounds which will reduce the quality of the rest of the track ever so slightly since the speaker will have to process more data at once.

A “chibi” version of our most basic enemy, known as the “Drifter”

A “chibi” version of our most basic enemy, known as the “Drifter”

 
A screenshot of each of our five unique enemy types next to their corresponding nest icons. From left to right is the “Drifter”, the “Strider”, the “Impeder”, the “Brutilizer”, and the “Ranger”.

A screenshot of each of our five unique enemy types next to their corresponding nest icons. From left to right is the “Drifter”, the “Strider”, the “Impeder”, the “Brutilizer”, and the “Ranger”.

Senior Capstone Development:

The development cycle for Visualizer was driven largely by Champlain College’s Senior Capstone course structure. The Capstone process is as follows, seniors from the Game Art, Game Design, Game Programming, and Game Producing majors place themselves in teams of about four students, ideally at least one student per discipline is on each team. From here, the four team members spend the beginning of the Fall Semester concepting, prototyping, and testing ideas over the course of a few weeks. With a final idea eventually chosen, the teams spend until around Thanksgiving developing a vertical slice of gameplay that shows off the game intent. Before the Thanksgiving break each team will have completed their vertical slice and the “cut” process begins. Here each team pitches their game concept in front of the Champlain game studio, including faculty, peers, and underclassmen. After the game pitches, what is known as “demo night” begins. For demo night, each team sets up their game at a station and the game faculty play tests each team’s vertical slice. Once this concludes, the faculty lock themselves in a room and deliberate upon which games have the most potential to go forward into full production in the coming Spring semester. After this point, the seniors are then notified which games made it through and which games were cut. Those who were on a team which had their game cut were then on-boarded onto the game teams who made it through. The rest of the semester is then spent ironing out the new teams and beginning the process of taking on new team members so come the Spring semesters, the new, larger teams would be able to move into a full production cycle to develop the remaining senior games to as close to a shippable product as possible.

For an overview of how this effected our team (Little Lizard Studios) over the course of both the Fall and Spring semesters check out our team reel below:

My team found ourselves in a bit of a unique position in the Fall semester since we did not have what was considered a standard team since we had two designers and two artists, with no dedicated programmer or producer on our team. This meant that we would not only need to fill the roles in which we were studying; but we would also need to wear the hats in the areas in which our team was lacking and we would need to scope our project accordingly.

Fall semester [Systems & Level Design]:

Stage 1: Planning

Once we had decided that our “Rhythm Shooter” prototype had the most potential of our three basic prototypes, and would be the most feasible and adaptable for the skills sets of the team we began planning to build out the skeleton of our game. We wanted the Vertical slice for “Visualizer” to blend together elements of games like “Crypt of the Necrodancer” and “Doom”. We took inspiration from how “Crypt of the Necrodancer” imbued every aspect of the levels and environment in the game with the music; making elements move or flash on beat. The most important aspect of this was trying to make the player not only predict, but feel the beat. With this driving the atmosphere of the game we drew from “Doom” to develop our weapon/enemy behavior and interactions. In "Doom”, each enemy feels unique and distinct from all other enemies and as such requires a specific type of reaction or behavior from the player to counter each enemy. For our vertical slice, we aimed to set our game in a night club as this was the most conducive environment to play with a musically influenced level design. We also planned to have three distinct enemies and two unique weapons at the player’s disposal. We also wanted to develop a combo system the would build up when the player shot on beat and if it ever got high enough the player would gain the ability to either use a dash or an area of effect blast ability to reward skilled play. In terms of the vertical slice game loop, we wanted to pit players against a few easy waves of enemies and then take the elevator to the next level, where they would defeat yet another set of waves of increasing difficulty.

VDD_Visualizer.png

We recognized and were very cognizant of the difficulties of tying elements of our game to the beat of the music and we designed both “Visualizer” and our development road-map with that in mind. I had prior experience with creating music visualizers in Unity and reading audio samples via microphone or file input so I had a basic idea of how we could go about creating a rudimentary beat detection system. That being said however, we wanted to allocate plenty of development time to polishing and refining this behavior to account for issues that would inevitably come up in our QA sessions.

With no dedicated programmer on our team, Simon Estabrook and I were very meticulous about how we were going to split our design and programming related tasks to account for this. We decided that I would take, the game loop, weapon functionality, sound, and level design tasks while Simon would take AI, player movement/abilities, UI, and beat detection programming tasks. We also developed a back and forth design discussion whenever we had questions or concerns when it came to making a systems or overall game direction decision. We figured that this was the most effective means of task delegation as we would be solely in charge of the design direction and our respective tasks would have enough cross over that we would both constantly be in the loop of what the other was working on and any issues were very quickly addressed. However, since we also had no dedicated producer on our team we also needed to do some team management in terms of sprint planning and road-mapping which our small team handled more as a collective with each of us taking on that role when needed.

Stage 2: Vertical Slice Development

By the time we were ready to start building out our “Rhythm shooter” prototype we had rudimentary player movement, a combo system, AI, and beat detection implemented. We were then ready to start building out our play area as we continued to refine these features. I spent a significant portion of time blocking out our first level to get a sense of scale and shape language so that I could establish a strong pipeline with my environment artist that would make building out future levels faster and more efficiently.

Level 1: The starting area, where the player would have time to get their bearings on movement, abilities, and shooting before being put into combat.

Level 1: The starting area, where the player would have time to get their bearings on movement, abilities, and shooting before being put into combat.

From the start of development, we knew that our vertical slice AI would be a bit basic on account of a lack in AI programming experience on the team. Taking this into account, I started playing with areas of verticality that the player could climb up on and use to get a moment of pause before our AI swarmed them. Additionally I included areas of cover like bars and counters that the player could use to kite enemies and maintain a distance.

Level 1: The blockout for the main room, areas in blue represent couches, counters, and stairs, while the areas in green represent plant beds, decorations and other non-gameplay influencing assets.

Level 1: The blockout for the main room, areas in blue represent couches, counters, and stairs, while the areas in green represent plant beds, decorations and other non-gameplay influencing assets.

With a play area established we dove into polish mode we had a basis to make changes around. We knew how the first level was laid out and we would be able to make design decisions with that style of game flow in mind. My focus then shifted from level design to designing and programming the basic weapon functionality for our two primary weapons. At this point our player movement and our AI behavior was really starting to come together and we needed to implement proper weapon behavior since our prototype was currently utilizing projectile based weapons which made shooting an enemy on beat extremely hard since the player would have to constantly factor in bullet travel time. It was a quick an easy decision to move to hitscan weapons; entirely removing the travel time element from our shooting which caused us to immediately see a huge uptick in play-ability in our testers.

We wanted our vertical slice to feature a pistol and a shotgun however we wanted more weapons as a a stretch goal so I needed to create our weapon manager with that in mind. I worked to create a script that was modular enough to allow new weapon creation with relative ease. Simply adding a new weapon object and name into a list in the inspector would create and add a new weapon to the player’s arsenal (though each new weapon added would simply default to the pistol’s functionality and would need its own method to be created if it were to have a unique function). I also took extra care in setting up each weapon’s functionality to be as customizable as possible to allow for rapid iteration on the design and balance side of things. For example, we had full control over number of pellets the shot gun would fire and the X and Y spread distance using an invisible boundary box I created. This was especially useful when consulting our balance spreadsheet which we used to make sure player/enemy health and damage were in spots where we wanted it and in a place for both designers to be able to easily reference when making adjustments.

At this point, with our weapon manager created, we had all of our basic systems in place and in a testable spot. We were now ready for implementation of our character models, animations, and environment art as we continued to polish our systems and mechanics. We jumped back into level design to finish level 1 and populate it with our new assets, as we implemented our character models/animations and as much feedback as we could.

One of the biggest challenges early on with “Visualizer” was communicating the beat to the player. We went through a few iterations of our beat detection system before landing on a solution that worked surprisingly well. In our earliest rendition of our prototype we were trying to isolate the drum frequency in Nirvana’s “Smells like teen spirit” which seemed to only occasionally detect the proper beat. Through some research we realized that it would be impossible to detect our beat like this. Given this, we instead chose to detect the beat in real time using a song’s bpm and effectively “hard coding” in that value to drive gameplay. Though we did want the flexibility of using other songs in our game so we created a basic framework for detecting a songs beat by using a “click track” that corresponds to the song as a metronome of sorts to help our code keep the rhythm of the song.

With a more established beat detection system we were better able to play the game, however we still needed to communicate game elements to the player. We wanted to try to make our UI as diegetic and unobtrusive as possible and lean into our inspiration “Crypt of the Necrodancer” a bit more. We wanted to have level elements pulse to the beat in an attempt to immerse the player in the song and the environment to try to make them feel the beat rather than see it in a visualizer or UI bar. Below is an example of how we tried to do this:

We not only included a visualizer on the club walls, but we swapped out environment materials on beat and made the player’s reticle pulse on the beat as well.

We not only included a visualizer on the club walls, but we swapped out environment materials on beat and made the player’s reticle pulse on the beat as well.

In addition to visual feedback, we had a dire need for audio feedback as our game was all about sound. In the Fall semester, we worked with a contract artist to help us compose a song and a click track to be used in the game. While we had a solid base for our programming to work off of, we still desperately needed to communicate to the player if they were shooting on or off beat. Over the course of many iterations I developed our on and off beat sounds for both the pistol and the shotgun by remixing and combining different sound files to sound more like a laser gun that either fired properly or misfired. One of the biggest challenges I faced in doing this was designing the sounds, not only for the weapons, but for the enemies and other miscellaneous sounds in the game; was removing the sense of realism. We were very careful to design our enemies and setting in such a way where we would not be associated with any real life events with setting our game in a night club. Because of this I faced the unique challenge of making a shotgun for example, sound simultaneously like a shotgun but be mixed enough to read like a sci-fi gun instead. Outside of this I also faced the challenge in distinguishing the on and off beat sounds as some players thought the off beat sound was the on beat sound and some players thought the opposite. I eventually came to a balance where they read properly; with the help of some particle effects.

By the point where we had most of our SFX in the game, the semester was closing in and we needed to get our final gameloop ironed out. This meant adding a second level. Learning from the mistakes I had mad in the first level, I created a much more open floor plan to allow the player the freedom to dodge or run away from enemies.

Level 2: A birds eye view

Level 2: A birds eye view

In the previous level, I had noticed players getting stuck or hung up on corners of objects and it made traversing the level very difficult and punishing. This was especially true given that we had been using our beefiest enemy, the “Brutilizer”, in tandem with our two weak enemies the “Drifter” and “Strider” in level 1 which was not meant to house difficult fights. In opening up the design in level 2, the player was able to make better use of their dash ability, kite enemies to pull off a strong AoE attack, and avoid the Brutilizer’s projectiles.

Level 2: I provided the player with two raised platforms each with multiple exit points that the player could use to pick off enemies from a distance and take a moment to release some tension.

Level 2: I provided the player with two raised platforms each with multiple exit points that the player could use to pick off enemies from a distance and take a moment to release some tension.

Old Level 2 (1).jpg

In creating the second level, it highlighted the biggest flaw in our game at the time; the game loop. The player, upon entering the level needed to shoot the play button by the stage to start the game, and then upon completing the four waves, they needed to exit the level in a different elevator than the one they entered, almost none of which was effectively communicated to the player, barring the play button mechanic.

Tutorial.PNG

In addition to creating levels one and two, I developed a tutorial in which the player walked down a one way hallway, leading to the elevator we have been using for scene switching and general progression. Along the way the player is stopped by walls that contain a checklist of items they must complete, like “Shoot on beat 5 times” or “Use the Dash ability”. Only once all of the wall’s requirements have been met is the player allowed to shoot the play button at the base of the wall to delete the wall and allow the player to progress to the next wall. This both taught the player how all of our game mechanics worked, and developed a design language with the player that read “Play button = Start” and “Elevator = Finish”.

It was at this point, where the vertical slice for “Visualizer” was ready to be shown to the faculty. This was the start of the game at the end of the Fall semester or 2018:

Spring semester [Level Design]:

On-boarding:

Once we made it through the cut process, we needed to then figure out what the best method would be for on-boarding new team members. We knew we would be getting an additional nine team members bringing us to a total of thirteen people on Little Lizard Studio’s development team. We now had 2 Programmers, 2 Producers, 3 artists, and 6 designers. We were fortunate enough to be able to select team members who’s specialties played to “Visualizer’s” strengths rather well. Realizing this, combined with the unwieldy team size of thirteen we decided to delegate ourselves into strike teams. The four original team members had been promoted to leads in their discipline which meant we had two lead designers and two lead artists, so for the sake of representing other roles we appointed a lead programmer and producer. Us leads then determined that the work on the game should be done in terms of art, systems design, level design, feedback (including SFX, VFX, and UI) , and general programming. This encompassed all members on the team and gave each person a defined role which allowed us to assign tasks easily and focus on certain areas of development that were in need of assistance.

With all of the new talent coming on to the team it meant that while I would still need to wear many hats I was able to pass off some of my responsibilities on team members who specialized in certain areas and could put more time into certain aspects of the game than I could. With a sound designer and audio programmer now a part of our team it meant that I could give that role to those teammates. With Simon heading the systems strike team it meant that I would be able to focus much more in depth on level design and maintaining our game loop. In order to keep things from becoming too isolated we also held weekly lead meetings where we would discuss the current state of the game and what needed to get done to reach our next milestone.

While this all sounded great I still made sure to be as involved with the overall production as possible. A large part of my job in the Fall semester was running QA sessions for “Visualizer” in the Champlain QA labs which allowed me to watch the game progress each week and quickly identify areas that needed to be addressed. With this responsibility being taken off my shoulders as well I became a bit nervous that we would lose that “watchful” eye on our game as had happened with a few of my other projects on team sizes of roughly 5-9 people, much smaller than the size of Little Lizard Studios. Because of this, I tried to stay as proactive as I could with keeping on top of the team and the game’s development in order to avoid the project flopping.

A new Direction [Level Design]:

A new team meant a new scope and as such we spent the first few weeks of the Spring semester listening to the feedback of our new members and discussing where we all as a collective wanted to take “Visualizer”. We ended up deciding we wanted to revamp the existing two levels we had and turn them into a full fledged campaign mode finishing with a boss fight. Supplementing this, we also wanted to shoot for an endless, playground mode. In terms of systems design, we wanted to expand from 2 to 5-6 weapons and from 3 enemies to 5-6. We also wanted to scrap the combo system in favor a currency system that awards the player “bytes”

A sketch of our NEW level 1

A sketch of our NEW level 1

A sketch of our NEW level 2

A sketch of our NEW level 2

In these early meetings, we discussed integrating our enemy spawns with a nest behavior to give us level designers more control over the flow and pacing of a level and help give the sense that the “ghost frequencies” are infecting and invading club dSync. In tandem with this we designed a basic corruption system that would spread throughout the level over time to further emphasize the theme that the player is fighting back against some force behind these enemies and this odd corruption. We decided to push for such ambitious changes since we anticipated that a lot of our AI behavior would need to be refactored by our AI programmer to be a bit more intelligent and performative.

We ultimately settled on five campaign levels, each with progressively more corruption than the last; with level being entirely corrupt as this is where the lich boss resides. We wanted the corruption to be an integral part of the game experience, using it as a means to block off certain areas of the level or used as a somewhat of a puzzle that will require the player to think creatively about how to navigate around it. We wanted to tie nests to the corruption to make it clear to players that the two were directly correlated and we tied them together in the sense that if a player destroys a nest, the corruption in the vicinity around it will also be destroyed. In addition to this, we used the nests and other areas of static corruption as spawning points for the spreading that overtakes the level. Since we did not want to inhibit the player’s movement too much, I developed a destruction mechanic that allows players destroy any object we want them to, in this case, corruption:

This destruction mechanic has overtime become a means of the player interacting with the world beyond simply destroying objects. This mechanic has come to signify the player’s progression. During the tail end of the Fall semester it became obvious that “Visualizer’s” game loop was suffering and this destruction system was the perfect way to let it shine in a unique and intuitive way. When we updated our tutorial with fresh new walls and checklists (to reflect the changes made to the game’s systems over the Spring semester), we decided to forgo the play button entirely in favor of having the player shoot and destroy the walls in the tutorial themselves after completing its tasks.

Additionally, during the Fall semester, we had quite a bit of trouble getting players to find and shoot the play button to start each level trying everything from particle effects and animating it. We eventually decided it was not worth the effort to push this mechanic so hard if we are only getting diminishing returns. So instead we decided to refactor our elevator and play button into a more streamlined gameloop. Previously, players in the elevator were asked to press the enter key to go to the next floor and then shoot the play button once on said floor in order to start the level. This took too long and was often confusing to players so instead I decided to make the level start after a short delay upon exiting the elevator and have the doors lock behind them. In addition to this I eliminated the second elevator and asked players to return to the same elevator in which they came from, to reduce confusion. Perhaps the most interesting change in gameloop however is the implementation of panels into the elevator. With five levels, a hub, a tutorial, and an endless mode, there were a lot of places for a player to go and wanting to reduce the amount of UI menus and navigation the player is required to do I set up as system that manages levels directly from the elevator within the game. If the player shoots one of the eight panels it breaks and takes the player to the corresponding level. However, if the player has not unlocked a campaign level for example the button will be deactivate and the player will not be able to shoot it.

 
Continuing the pink = shoot motif, the panels in the elevator are neon pink

Continuing the pink = shoot motif, the panels in the elevator are neon pink

 

I felt as though the transition from tutorial immediately into the campaign mode with no period of rest was a bit overwhelming for new players. So, continuing to ease out the gameloop a bit more, I created a hub level which the player would be taken to upon completing the tutorial. I limit the use of the elevator panels to just the “Hub” button as to teach the player how to use the elevator. Upon spawning in the hub the player can choose to once again enter the elevator and either begin the endless mode or the campaign. Alternatively, the player can stay in the hub and visit one of the shooting galleries specially set up with re-spawning training dummies that the player practice using the five different weapons on in a completely devoid of danger.

An overview of the Hub blockout

An overview of the Hub blockout

An interior view of the preliminary Hub blockout

An interior view of the preliminary Hub blockout

With the new gameloop and game modes decided, we needed to figure out how to split the level design work in the most effective manner. Initially both myself and my other level designer began working on the campaign levels as we had worked out a plan for each subsequent level in terms of which enemies will be introduced when and what the challenge or puzzle is for each level.

However, we eventually realized that the endless mode, in how much time and care is going to need to be put into both building out and balancing it, we needed to start right away. Early on we had the idea that when the player started the endless mode it should feel a bit different or even slightly off to the player since it was supposed to represent the boss’s malevolence succeeding in taking over the club. As such we wanted the walls of the hub to dissolve and reveal the endless mode level, making it feel like it was there the whole time. Since this was looking to be a rather complex but flashy undertaking I jumped at the opportunity to work on it. However, I continued to work as somewhat of an overseer for the campaign providing input and feedback to help guide development and assure we were heading in the right direction as best I could.

To see the endless mode final product in action, check out my reel below:

In the beginning, the basic flow we had designed for endless mode went as follows, the player beats the tutorial, enters the hub, and upon shooting the appropriate panel in the elevator, the walls of the hub dissolve as the boss laughs in the player’s ear and the endless mode level is revealed. Beyond this, our plan for endless mode was relatively non-existent. We knew that we wanted it to be wave based with each consecutive wave getting harder and we wanted the player to be able to utilize the weapon upgrade machine the systems team had created for the campaign, but this was about it.

Initial sketches and size comparisons for the tutorial, hub, and endless mode; detailing the level to level progression to start the gamemode.

Initial sketches and size comparisons for the tutorial, hub, and endless mode; detailing the level to level progression to start the gamemode.

Upon meeting with the level design strike team and the systems design strike team, just about everyone on the team had a loose understanding of what endless mode was going to be and what the vision for it was. We knew we would need to modify our spreading corruption system to have built in randomization functionality that would allow it to continue spreading beyond the points we had preset. Additionally we wanted the main method for enemy spawning in endless mode to be this corruption which required a bit of retooling on the enemy spawning side of things as well. I could already tell that members of my team were already starting to get a bit lost with how the whole gamemode was intended to work. So, I created a flowchart that outlines all of the functionality in endless mode which my team could reference if they were unsure of how something was intended to work.

Unfortunately we had to largely simplify this spread sheet due to time constraints. The biggest change being that we removed the nest mechanic entirely for the sake of time. The original intention was to have the mega nest create nest “special” nests containing only our difficult enemies (like the Brutilizers or Impeders) so that the player would then need to destroy the nest to stop these enemies from spawning; giving the player a bit more control and agency over the pacing of play. We also cut out the middle man of the mega nest and simply drove all enemy spawning locally from the corruption.

In addition to the alterations to the spawn behavior we did not include the checks during play to see if the player finished a wave before the song ended and we did not get around to giving remaining enemies a buff when the song loops. However we were very careful to build in a “lull” period between songs so the player would have time to explore, clear corruption, and use the weapon upgrade machine. We also played with gameplay tension in our song track during this point in time as well. The song that plays between waves is known as a “Shepard’s tone” which is an auditory illusion that makes it sound as though the song in endlessly increasing in tension. We were worried that the break in gameplay would feel too relaxing and we wanted to do what we could to maintain this sense of doom over the player through our music.

Realizing that this gamemode would be a huge undertaking and would require a significant time investment on both the level and system design side of things, I needed to get to work immediately. The plan was to block out the main room in accordance to the earlier sketches I had done. I wanted to get this room entirely finished before touching any of the side rooms so the systems design and audio teams had a space to prototype and test things. I spent a good deal of time figuring out the sizing of the main room to accommodate for four additional rooms the would branch off of it while being as small as possible for performance reasons.

With the main room complete, I passed it off the the systems team as I continued the 7-8 week undertaking of creating and populating the four additional side rooms with environment assets, jump nodes, and navmeshes.

Over view of all of endless mode

Over view of all of endless mode

In the end we did end up including a progression element into the gamemode. However, we altered it slightly from our original flowchart plan. While we had a save system in place that tracks the levels the player has completed, which guns they have unlocked, and how many “bytes” they earned, we ultimately decided to not lock off the side rooms behind campaign progression. I instead opted to develop a system of purchasing doors leading to new rooms and hallways using “bytes”. Each door the player purchases causes the remaining doors to go up in price to accommodate for the amount of bytes the player is earning in each wave. This too saw a return in the destruction system, reinforcing the themes we had established in the tutorial and elevator to symbolize progression.

With this in place, I worked with the systems team to create a new spawn behavior for our pick ups. As I mention in my reel I wanted the flow of endless mode to be cyclical since the player would be ever running from enemies and corruption. While the player has the ability to destroy this corruption and fight back against enemy spawning, they will eventually need to move to a different room or else risk becoming overwhelmed.

We modified the pick up spawns to help with this. We now had the option to control a pickups spawn rate over time, incrementally increasing the spawn timer each time the player uses the pick up. Health was to be the most precious resource in endless mode and with the timers on certain health pickups continually increasing, the player would have to use them very carefully and purposefully. To compound with this, and help make gameplay even more varied between play sessions, we included the ability to randomize a pool of specified pickups. We could now specify how many pickups in a specified list would not spawn and then randomly choose which remaining pickups in the list would be created on play. This meant the player never knew where a health pick up would be (aside from a few purposefully placed ones) and this would encourage exploration of the level.

We also created pick ups for each of the four additional weapons; the shotgun, the railgun, the burst rifle, and the katana and placed them in each of the side rooms to give the player another reason to explore the level outside of access to additional health pickups and space to play.

With the sheer size of the endless mode being larger than our five campaign levels combined, we were rather worried about performance issues, especially considering we planned to continually spawn corruption and enemies. To help combat this I split the endless mode into five separate scenes, each containing one room, as shown below:

Each bubble represents the boundaries of each of the five scenes.

Each bubble represents the boundaries of each of the five scenes.

From here I created a system that deactivate the hub area and additively loaded in each of the five endless mode scenes into the hub level to help cut down on loading times. This functionality would also give us the ability to temporarily turn off and on rooms that the player had not purchased. However we instead ended up only using the system to reduce loading times in favor of utilizing occlusion culling to selectively render out anything that was not in the camera’s view.

Splitting up the endless mode into five unique scenes also posed a dilemma in terms of AI navigation as we are using a navmesh to control enemy movement which needs to be baked into each scene. I toyed around with the idea of baking the navmesh before splitting up the level but in favor of future level iterations, I opted to go with a different solution as the navmesh would have to be re-baked every time I made a change in a room. Because of this, I decided to bake the navmesh separately in each of five scenes and use carefully placed jump nodes to allow the AI to travel between rooms once spawned which works almost almost flawlessly, with the transition between rooms only being noticeable to the player if looking for it.

Postmortem:

I would like to take a moment to say I could not be more proud of my team or happy with how the game turned out, thank you to everyone who helped make this game a reality. I have worked on so many different aspect of development in this project like QA, Systems Design, Technical Design, UI Design, Level Design, Team Management, Gameplay Programming, Sound Design, and so much more. I am extremely proud of all of the work both my team members and I have done in “Visualizer”. To my knowledge, we are the first senior Capstone team to make it through cuts with no programmer, to which I am extremely proud, given how technically challenging “Visualizer” proved to be.

I was very worried about team dynamic issues at the start of the Spring semester as I have been on large teams before and have has the misfortune of seeing these issues take their toll on the game we were working on and I desperately did not want that to happen again. Fortunately, being in our senior year the new team members for the most part, were very professional and showed a lot of enthusiasm for the project putting their own stake in it’s success. This made things go much more smoothly throughout development and made my job managing the team and the game’s direction much easier. Team dynamic issues aside, I was still worried about the project crashing and burning as communication can often fall short in large group settings and people can get lost and ideas can be forgotten rather easily as I have also witness before. I made it my secondary job to keep a watchful eye on the team and the game each week to make sure we were all clear on what we were working on and how it contributed to the game’s overall vision. Fortunately, I had the assistance of the other three original team members in doing this, and the early on-boarding/debriefing/planning sessions we held for the new members also helped unify the team vision and keep everyone on track.

However that being said, with the Spring semester being the last one in college for all of the team members, things were a bit stressful and hectic which often made team management a bit harder. While we did a great job overall with managing the team and the game, I did feel as though I was not as proactive as I wanted to be since I was so entrenched in building out the endless mode level for weeks on end on top of managing my other classes and personal life. As such, we found our road-map for the game a bit warped come a few of the final deadlines since work needed to be delegated in other areas of the game and people were spread thin which threw a wrench in our timeline and made hitting milestones more difficult. We also had a number of issues with bottlenecks slowing down work in other areas of the game which ultimately led to us finalizing our boss fight and endless mode in crunch time with less testing than I feel comfortable with. I feel like the bottle neck and other road-mapping issues were the biggest hurdles the team faced since everyone on the team did fantastic work and we were very proactive with fixing issues or bugs when they came up. We simply needed slightly better time management to allow for us to polish the game just that much more, and ideally hit a few of our stretch goals like a sixth weapon and additional enemy type.