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 a team of 13 at the start of the Spring 2019 semester

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

  • 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)

 
 

Conception Overview:

When I play high intensity games one of my favorite things to do while I play, is to listen to upbeat music and challenge myself to perform certain game actions to the beat of the song. When I do this, I often notice myself emulating the flow of the song inside the game. I try to time cool combos or abilities to the time of a big beat drop or movement in the song. When I am able to successfully execute one of these maneuvers, it brings me some of the most satisfaction I have ever felt while playing a game, especially if the action I did was flashy. This is the essence of what I wanted to emulate in Visualizer’s design. I wanted to make a game-loop that consistently delivered this rush of dopamine and sense of accomplishment throughout the whole game.

Conception (Ghost Frequencies):

In terms of the game’s setting and lore, the “ghost frequencies” that the player is exterminating are based in real life audio production theory. The particular theory that interested me regards the higher and lower end frequencies in a music track that are outside the human hearing ranges. If these frequencies are not EQ-ed out of the track during the mixing process, will reduce the overall audio quality of the final product (though only to an extremely minimal extent). These frequencies are often referred to as “ghost frequencies” since humans cannot hear them. Despite being inaudible however, speakers will still try to process that frequency data. This spends both time and energy on playing these sounds, reducing the amount of resources allocated to the frequencies of the song human can hear.

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 Overview:

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 the semester developing a vertical slice of gameplay that shows off the game intent. At this point, the “cut” process begins. Here, each team pitches their game concept in front of the Champlain game studio (i.e. the game faculty, other capstone teams, and the underclassmen game majors). After the game pitches, what is known as “demo night” begins. It is here where the game faculty play tests each team’s vertical slice. Once this concludes, the game faculty deliberate upon which games have the most potential to go forward into full production in the coming Spring semester. Those who were on a team that the faculty did not deem strong enough, were then dismantled and members were on-boarded onto the remaining teams. The following Spring semester is spent integrating the new team members and moving from vertical slice development into full production. Throughout this semester, teams are required to reach certain development milestones such as green-light, alpha, beta, and release.

For an overview of our team’s development (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 as we did not have what was considered a standard team. We only 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. This was perhaps one of the biggest factors leading to the scope of our project.

Read More about the game’s development here:

Click here: Fall Semester [Vertical Slice Development]

Follow Visualizer’s development from early stage planning to a vertical slice.

My responsibilities were:

  • Prototyping (Create game vision and develop prototype to prove concept)

  • Level Design (Create 2 levels and a tutorial)

  • Systems Design (Enemy and weapon balance)

  • SFX Design (Create and program all in game sounds minus music)

  • QA manager (Conduct weekly QA and bug tests to help guide development)

  • Gameplay Programming (Create weapon functionality, game loop/progression, and other miscellaneous tasks)

  • Team management (Maintaining the game’s vision, Road-mapping, Spring planning)

Takeaways:

I learned to wear many hats. I constantly found myself learning new skills to help cover the team’s areas of weakness and work with my teammates to overcome challenges we have not faced before. I learned how to take a concept and develop it into a vertical slice to prove our idea to an audience outside of our team. I gained valuable practice in time management, planning, and road-mapping a project’s development over long periods of time; accounting for time needed to iterate and fix bugs.

Click here: Spring Semester [On-Boarding & Full Production]:

Follow Visualizer’s development from the vertical slice phase through full production up until release.

My responsibilities were:

  • Lead Level Designer (Create endless mode level, hub level, tutorial, and manage the level design strike team and the story mode’s development)

  • General programming (Refine game loop/progression, destructible objects, other miscellaneous tasks)

  • UI design (Refine all game menus)

  • Team management (Working with the other leads to manage our strike teams, the game’s vision, and road-mapping)

Takeaways:

I gained valuable insight into what it means to be a lead. I had been a “lead” on projects before but nothing near this scale and my duties never required me to lead others like this project has. I learned firsthand how to develop ideas with a team, create a unifying vision for those ideas, and monitor the development of others’ work through the lens of said unifying vision; all as I worked myself. I learned how to delegate responsibilities and work in a small group of leads to help manage a larger collective of developers to all work toward one vision.

Postmortem:

I could not be more proud of my team and all of the blood, sweat, and tears we poured into Visualizer. I am so 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 aspects 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 to have been a part of Little Lizard Studio’s development team working on Visualizer. To my knowledge we are the first senior Capstone team to make it through the cut process with no programmer. I hold this achievement close to my heart, given how technically challenging Visualizer proved to be.

At the start of the Spring semester I was very worried about team dynamic issues. I have been on large teams before and have seen firsthand how these type of issues take their toll on a game. 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. Not to mention people can find themselves directionless and ideas can be forgotten rather easily. As I mentioned earlier, I made it my secondary job to keep a watchful eye on the team and the game each week. This helped make sure we were all clear on what we were working on and how it contributed to the game’s overall vision. Fortunately, the early on-boarding/debriefing sessions we held for the new members helped unify the team vision and keep everyone on track. When things did get out of hand the original three team members were right by my side in helping steer things in the right direction.

However that being said, with the Spring semester being the last semester of college for all team members, things were a bit stressful and hectic. 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 in terms of managing the overall development. I found myself suffering from tunnel vision as I became very entrenched in my own doings. I spent weeks on end just focusing on building out the endless mode level and managing my other classes and personal life. As such, we found our road-map for the game to be a bit warped around the time of the final few deadlines. We found ourselves needing to delegate work to other areas of the game as people were spread thin on account of a few lapses in planning. This threw a bit of a wrench in our timeline and made hitting milestones more difficult, which also lead to more cuts within the game. In addition to this, we also had a number of issues with bottlenecks in our pipelines, slowing down work in other areas of the game. Ultimately this led to us finalizing our boss fight and endless mode in crunch time with less testing and polish than I felt 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/project management to allow us to polish the game just that much more.