Chuckles

Systems Designer DigiPen Team of 4 September 2022 - August 2022

Level Designer Unity

Overview

In the side scrolling run and gun game Chuckles, players encounter several clown/circus themed opponents for challenging boss fights. The game is reminiscent of games such as Cuphead and Terraria as it focuses on boss battles instead of level content, but features brief levels to transition from each primary boss set piece to the next. The levels are used as methods of teaching the player new mechanics to prepare themselves for the next challenge.

I was the sole designer of the game, as the other 3 team members were programmers. Given the small size of the team, all team members needed to work in disciplines other than their own. Due to this, I programmed quite a bit in addition to the design work.

Skills Honed

Github

Unity

C#

Level Design

UX

Team Leadership

Systems Design

Task Delegation

Gameplay Design

My Contributions

Designed four unique and interesting boss battles.
Designed four basic levels to tutorialize mechanics and to prepare the player for boss encounters.
Designed and produced prototypes for all of the bosses, as well as design documentation.
Helped other team members prioritize which tasks needed to be completed.
Programmed the attack patterns of the bosses.
Worked with the scripts of other programmers and integrated my own scripts to interact with theirs.
Added all of the in-game UX feedback.

Design Work

Utilizing all game mechanics in harmony

The biggest challenge of the game from a design standpoint was implementing the game's platforming mechanics into the mix, rather than just making it a generic run'n'gun or platformer. For much of the game's production, the game mechanics were used only in isolation rather than coming together as a cohesive whole.

Adding platforming to boss encounters The game's archetypical head and hands boss originally started as a simple encounter with the player fighting him in an enclosed space. The player could jump against walls tacked onto the side of the arena, but these served no real design purpose. In the next draft, this boss raised his hands at low health to force players to jump up to attack them. This forced players to use the mechanics but without any real engagement. I changed the boss further by adding platforms falling to his hands when they were raised. The boss also interacted with platforms by destroying them with hand attacks. Although this was a significant step in the right direction, I still wanted more out of it. I changed the arena into a vertical shaft the boss could climb to escape the player, forcing them to climb up after it as a tower of platforms rained down. With all of this, the game's platformer elements felt fully integrated rather than an afterthought.

Tutorializing new mechanics in player engagement curves With the game's small scope, my first attempts at levels were all trying to focus on one particular mechanic, since they wouldn't get focused on anywhere else in the game. However, focusing on one mechanic for an entire level often meant the challenge would scale at too fast of a rate for the game's small scope. Not every mechanic needed its time in the spotlight, and the levels served better as tutorializations of new mechanics in upcoming encounters as opposed to legitimately difficult tests in their own rights. I found it better to avoid player frustration and to use the levels to highlight the polished content of the game, the bosses. Attempting to engage players by making every individual section of gameplay be a challenge to overcome was not as exciting as providing peaks and valleys in engagement that ended in the more impressive boss set pieces.

Working with other team members

The team had a unique distribution of roles. I was the only designer. The three other team members were programmers. This provided unique challenges for everyone to learn to do things outside their specialty. Because of my design background, I more quickly recognized problems needing attention, pointed them out, and assisted the programmers in learning what to prioritize.

Bringing the work of team members together During early work on the project, the team members all seemed content on their own designated parts of the project with no concern for how it would benefit the rest of the project. By having a meeting with a class instructor, we were able to get back on track and improve communication. As the person creating the primary content players were going through, the levels and boss fights, I was the one fitting in content made by other team members. I made it clear to them which of their content would be used or cut. This helped them to better prioritize what they should be working on, rather than continuing to fine tune elements that would either be irrelevant or unnecessary.

Emphasizing the importance of feedback and gamefeel The programmers I was working with did not understand the importance of feedback as much as designers I had worked with in the past, so I had to regularly add feedback to in-game actions where the programmers hadn't left any. As the sole designer, I expected to be in charge of this department, and I would make sure that all in-game actions had sufficient feedback to make it clear to players what had just happened. Enough content was being added that it was becoming impossible for me to add feedback to everything in the game myself, so I had to began teaching other team members where it needed to be added. Communication was key as I shared design principles with other team members. This was most prominent with the menus. I could add a basic fade in/fade out when levels ended, but not in a way that worked with scripts made by other programmers. I needed to involve them in reworking these fade transitions of scripts they had already written.

Helping the team decide scope For much of the project, especially in the starting half of the game's production during the first few months, I had to wait for mechanics assigned to other team members. As designing things around features that were not yet implemented proved very difficult, I had to base my design on mechanics that were already present while allowing some leeway for changes that could potentially happen. As time went on, it became clear to me that these features probably weren't going to be produced due to lack of workflow and one of the key team members lacking enough time. Since I would not reasonably have time to design around mechanics that would be added so late in development, I needed to try to help other team members prioritize what need to be worked on and advocate for necessary cuts to the game's mechanics. For example, it was a longstanding plan to add multiple weapon types to the game, but when they didn't come soon enough, I managed to compromise and add only one additional weapon type.

Post Mortem

Things that went right:

The boss reworks utilized the game's mechanics well, helping the game come together as a cohesive whole.
The engagement curves of the game were fine tuned to have peaks and valleys rather than constant challenge and engagement.
The game's scope downsized and the team was able to laser focus on priorities for game completion, utilizing everyone's contributions.

We took longer than we should have to bring our work together for the sake of the project and communicate better.
The game was overscoped and we could have realized what we weren't capable of earlier on in the project.

Set up work and communication pipelines between disciplines as strong as you can early in game development.
Create communication taskboards to show what everyone's currently working on to hold people accountable and so that everyone can keep updated on what content is currently in the game, rather than a possibility coming in the unknown future.
Make sure your game mechanics come together as a cohesive whole with all of your mechanics contributing, rather than being several disjointed pieces. Identify what makes the game fun rather than having mechanics for the sake of having them.
Not every level's purpose is to challenge the player, it is necessary to give less stressful sections of gameplay to make the more important ones stick out.

Things that went wrong:

What I've learned from this experience: