Descent of Champions

Andersen Pinckney

Burlington, Vermont

15 0

Descent of Champions is a round based arena brawler where players compete in combat based objectives to earn the audience's favor. The audience is made up of live spectators who use their devices to engage with gameplay systems, earn currency, and influence the match to create an epic battle! ...learn more

Project status: Under Development

Game Development

Groups
2020 Intel University Games Showcase

Intel Technologies
Intel Integrated Graphics

Docs/PDFs [5]Links [8]

Overview / Usage

Project Overview

Equip giant rocket gauntlets to beat up hordes of robots for the audience’s favor. You better know how to fight, because wealthy spectators will invest in creating chaos for their personalized entertainment.

Descent of Champions is a round based arena brawler where players compete in combat based objectives to earn the audience's favor. The audience is made up of live spectators (real people watching the game) who use their phones to engage with gameplay systems, earn currency, and influence the match to create an epic battle.

Descent of Champions was made in 10 weeks by 8 developers for the Ubisoft Game Lab Competition.The competition required that we adhere to a theme, “spectacle” and fulfill the mandated criteria. The mandate for the competition required that teams stream their game and allow spectators to influence at least 1 gameplay system.

Approaching the Project

In the beginning phases of the project, the most difficult part was figuring out how to combine the theme and the mandate into a context that works for the game. For our team, spectator integration was our primary consideration as we wanted a complete experience for everyone participating. We settled on wealthy spectators creating chaos in an arena of 3 players fighting robots and completing round based objectives.

We took this idea forward with a design thinking mindset. We wanted the participation of spectators to be meaningful for everyone. This meant a tailored spectator interface, the ability to showcase individuality, and having the lowest possible barrier to entry. We also knew that the spectators would be made up of the Twitch viewer audience, which meant keeping to what we defined as the core pillars of Twitch: horde mentality, fast actions, and chat.

None of these goals would be accomplished by using a Twitch API as there would be limited individuality, no tailored interface, and a medium barrier to entry as you need a Twitch account to fully interact. We also knew that making an app that works with the game would be out of the question as well. An app would provide a tailored interface and provide plenty of custom features, however the barrier to entry is extremely high. At the competition we would be able to pre-download the app, but in any practical application spectators would be required to go through many barriers before they could interact with the game.

After much thought and consideration, we created a custom website from scratch that authenticated Twitch steamers and set up a lobby for their stream when they went live. This means that as soon as you start playing the game live, the entire front end of the spectator interface is set up automatically and your viewers can join by using our IP, DescentofChampions.com (url has been disabled, but the game can still be played locally).

Development Team

James Van Nuland - Producer, Scrum Master

Andersen Pinckney - Product Owner, Lead Designer

Richard Hardy - Technical Designer, Gameplay Designer

Scott Aquino - Programmer, Gameplay, Systems

Mark Botaish - Programmer, Combat, AI

Tyler Chapman - Programmer, Full Stack Development

Isaac Mills - Artist, Character, Animation, Iconography

Nick Kline - Artist, Animation, Character, VFX

Our developers are looking to be hired! Scroll down to the "Other Links" section to click on developer portfolios!

Methodology / Approach

Developing Smart

As a team, we used agile methodologies and scrum to develop our game at a super quick pace in just 10 weeks. To be fair, we used what Clinton Keith from the Scrum Alliance refers to as “Scrum but…” as we made some modifications like lightning sprints that fit into a 2 day period. For the majority of our production cycle, we used 1 week sprints that approached our problems in an iterative process. This allowed for multiple crucial changes -- like reshaping our arena from a circle to an oval -- that made our project better.

In addition to developing with scrum, we made use of testing our game at the QA lab each week. Champlain College has an in house QA lab populated with students. Each week developers will test each other's games and give valuable critique and feedback. We also made sure to test the game with external groups so the same eyes wouldn’t see the game every week. Closer to the competition deadline, we set up the game as a showcase at the Champlain College open house. This gave our game hundreds of fresh eyes, plenty of feedback to iterate on, and helped us stress test the game with numbers similar to the competition.

With the help of Ubisoft, we received 2 mentors, Karl and Viro. Our mentors made sure to give us harsh (but fair) feedback on the progress of our game. They pushed us to iterate on core features until gameplay felt perfect. For our team, one of the best moments of our development process were our mentors saying, “wow, this is actually pretty fun”. We attributed two banners in the middle of the arena to Karl and Viro.

Detailed Documentation

We created Descent of Champions for our Production II course at Champlain College. Part of the course requires that we make documentation. In addition to adhering to the course requirements, we wanted to flush out documentation to make our pipelines quicker. We established a technical standard with conventions that we followed throughout our development period. This standard was set by our Technical Design Doc (the final version can be viewed in the Documents and Presentations section).

Descent of Champions has a lot of visuals going on at once; enemies, spectators, UI, VFX, and more. Even for powerful Intel processors, we needed to make sure the game was highly performant. The art played a huge role in how we optimized our game. This meant lots of planning ahead of time to define our art direction, colors, and style. You can see our Art Bible (attached in Documents and Presentations) with details on our art pipeline, values, and style. We used this as a document to help us plan what features were most important and guide our visual process.

The most iterative document was the Game Design doc. There may actually still be features highlighted and crossed out on it, but that document helped guide the team throughout the process. We changed lots of features to better match the game direction and fit our overall vision. One of the bigger changes since the beginning was removing coop reviving and a health bar. We replaced that mechanic with a self revive feature where players mash ‘X’ when they get downed to revive themselves. We wanted to reduce clutter on the UI and give players the ability to revive themselves to keep the fast paced action in the game.

If you are browsing the document attachments, we've included 2 example prototype documents that went over the functionality and requirements of an ability (ground smash) and an enemy (laser enemy). These documents are what we used to outline our more vital features because most of the team would work on them. The documents go over visuals, functionality, game states, and references.

Art Direction

As we mentioned briefly above, the art direction was incredibly important for our game feel and performance optimization. We used specific colors and palettes to highlight players and objectives while still making the environment relevant. When we designed our players, we wanted them to have bright colors and lights emphasizing their movement. Like a stadium, we have colored spotlights to help draw attention to the player’s actions. Objectives have brighter emissions on relevant objects and use gold in all of their textures. Golden grunts are the perfect example of how to stand out.

It was important that our enemies had darker tones. We found that since the laser enemies are ranged they are often not in the player’s immediate focus. We decided to make the laser enemy brighter in color so it would be easier for the player’s to find in the chaos. It is also important that spectator interactions are noticeable in game. When wealthy spectators spawn enemies, there is a giant money symbol underneath the robots so players know spectators are flexing hard.

Environment should be mostly in the background to the player except for spectators and round events. The hologram audience of spectators will change colors and display name tags when a spectator emotes. When a round changes to enraged grunts or party mode, the lighting in the arena changes and flashing messages appear on the jumbotron. When the arena moves to the next round, there is lots of screen shake and the floor has an eye-catching dissolve effect.

The Jumbotron

The Jumbotron was one of the most focused and iterated elements of design. The visual in game was not only important for players to see their current score and progress, but spectators needed visuals for how the game was progressing. We placed the Jumbotron front and center so everyone could establish a point of reference. The Jumbotron is enormous and takes up a large portion of screen real estate, but it is not distracting as we made it static behind the arena. The most important score elements are color coordinated so players and spectators can find game stats quickly.

We value the spectator's individual contribution to the game, so we have a large chat stream that takes up the Jumbotron in a cycle. This way players can see the spectator interactions in real time. This section of the Jumbotron is dynamic and can also display events that are triggered by spectators, or the end of round timer.

Audio Design

One of our friends, Noah Matson, volunteered to make music for our game. With the help of him and many free sound libraries, we were able to put together complete audio for our game. One of our goals since our first year of school was to get a professor to voice over a game. We had help from a professor, Daniel Buckstein, who voiced the announcer in our game! The announcer voice plays for round events, and has tons of quips that react to gameplay.

A Custom Website

Our proudest feature of Descent of Champions is our spectator website. We mentioned before that we wanted a fully customized interface for spectators. With a custom website, we lowered the barrier of entry to just an internet connection and a mobile device. With our website, we allowed spectators to individually influence the game with a virtual currency used to spawn robots, trigger events, and flex on players with emotes and a chat.

Did we mention that our website supports emojis?

One of our programmers, Tyler Chapman, dedicated time to fully implementing emojis in Unity. Here is how he described his process of implementing emojis.

First, I found a website with a full emoji list to download. I removed all the data aside from sprites then copied everything with an img tag then pasted it into excel. From there, I aligned the columns to simulate a sprite sheet, then created an image from the columns and sliced the image into a sheet.
Next I imported the sprite sheet into Unity and used text mesh pro’s support for inline graphics by creating a sprite list. One main issue was that the way the inline text works is it replaces known text with an image. Along with the images I found on the other website, it gave all hex values for each emoji. I then used a quick python renaming script to rename each image from the individual sheet to the corresponding hex value. Now that I had a way to receive and relay an emoji, I needed to convert the emoji’s I was getting server side to what was expected in Unity.
In PHP, I was receiving emojis as surrogate pairs, which is a way to encode unicode characters in a UTF-16 encoding scheme. I needed a way to grab all of these, then convert them to their corresponding hex values in order for the text mesh pro object to convert the text properly to an image. To do this, I used a match all regex I found online, when a surrogate pair is found. I then used a PHP library to convert the surrogate pairs to hex, then sent the altered message to be displayed in Unity on our Jumbotron.

So how did we go about implementing this custom website?

First of all, none of us had any idea on how to make this website. Our full stack developer, Tyler, didn’t actually know full stack until he started this project. Here is an outline of how we connected our website to Unity.

Tyler started by learning full stack and got a basic connection working with PHP.
Next we quickly learned that Unity web requests were inefficient and slow. It would continually pull data causing breaks in the program and freezing the game.
We searched for a new solution and found out about websockets. Websockets are not compatible with PHP, so we found a library called Ratchet. Ratchet allowed for websockets and PHP to work side by side.
Our next step was setting up an actual web-server with Apache, MySQL, PHP, and a few more programs.
During this time, we started prototyping what our economy would look like and drew wireframes for implementation.
Tyler started implementing basic art for the website then connected everything to a server. To test spectator mechanics before implementation, we were able to use cheats in the game to simulate what spectators would do. Once the server was established, we could use our devices to test the game.
At this point, Tyler had made emojis work for the game so spectators using their devices could use their full emoji keyboard.