Chroma is a 3D puzzle game with a series of challenging obstacles based on color and movement.

In Chroma, the player is able to attach colors to any of the faces of their cube by first having that face make contact with a colored tile. The player can then move with that color attached to their cube, but if any face with a color touches the floor or wall, it is lost. The player must then pick up the color again. The ultimate goal of any level is for the player to transport every color to its matching receptacle. Once the colors are placed on their receptacles, the level is solved and the player can move forward. The player’s ultimate goal is to defeat the Dark Cube, a being that has come to the cube planet and sucked away most of the color. As the player completes levels, they slowly bring color back to the world.

Role & Responsibilities

Producer & Programmer

  • Lead the team in daily scrum as Scrum Master and managed team tasks
  • Programmed the game’s final boss fight and level ending cinematics
  • Created and programmed the player avatar’s facial expressions
Development Info

  • Unity
  • Team of 9 (5 Months)
  • UC Santa Cruz
UC Santa Cruz
Download Chroma

Download Chroma
Work Overview

For Chroma, I served as the team’s producer. I also had various programming responsibilities and helped where I was needed on the project.

My programming responsibilities include coding the final boss battle, creating effects for end of level cinematics, making facial behaviors for the player character, and creating the credits menu. I did all of this in C#. As the team’s producer, my main job was maintaining our Scrum development methodology by leading daily scrum, leading the team in planning sprints, and managing our scrum board tasks.

A well-organized and productive team

As the producer, I wanted my team to be well-organized and productive. We used Scrum as our development methodology and I used its many characteristics to keep Chroma’s development on track. Our development was split into sprints 2-3 weeks long. This helped keep us organized and split Chroma’s development into portions that were easier to understand and execute upon. We also used burn-down charts each sprint to keep track of ideal work hours. This definitely helped with our productivity. I feel like I did a decent job at organizing my team, but I didn’t do a perfect job. It was our first time using Scrum and my first time as a producer so we definitely had our roadblocks. Over all though, I thought we were pretty efficient with our time.

Complete tasks assigned to me

I didn’t have a specific programming role on the team because of my primary role as producer. As such, I helped were I was needed. I just wanted to complete the programming tasks I was assigned and I was able to do so. Though it wasn’t easy, I‘m proud of myself for being able to balance being both a producer and programmer.

Boss Battle

After the player completes all the levels in the game, they must defeat the game’s antagonist, the Dark Cube. I programmed the Dark Cube’s behavior and the rules for the boss fight against him. Chroma’s central theme is bringing color back to a world devoid of it. The player’s final challenge is using color to defeat the Dark Cube. The player attaches colors to themselves and launches at the Dark Cube, hitting him with those colors. When the player hits the Dark Cube with all the colors, they defeat him. The logic for the Dark Cube’s behavior and the rules for the boss fight are descripted in the Movement, Collision, and Face sections below.

Dark Cube Movement

This code controls the Dark Cube’s movement. During the boss battle, the Dark Cube moves in a circle around the main area of the level. He stops at different set positions for the player to hit him with a specified color. I give a very strong hint to the player as to which color they must use, by changing the Dark Cube’s outline to that color. The challenge is not to guess which color to use, but to successfully hit the Dark Cube with it.

Dark Cube Collision

This code manages what happens when the player hits the Dark Cube with a color. When the player collides with the Dark Cube, by launching into him, this code checks whether the player has a color attached to them. If they do, the code then sees if that color matches the color the player is supposed to currently hit the Dark Cube with. If so, the Dark Cube takes damage, if not he mocks the player with an evil laugh. When the player hits the Dark Cube with all the colors, this code ends the boss battle.

I programmed the entire cinematic sequence for when the Dark Cube is hit by a correct color. When he is hit, the camera pans to him as he flashes and shakes. The Dark Cube then changes the color of his outline to tell the player what color they must use on him next.

Dark Cube Face

This code handles the Dark Cube’s various facial animations. I wanted to give the Dark Cube some personality since he is the only other sentient being in the game besides the player’s cube. This script monitors the Dark Cube’s state and plays different facial animations accordingly. For example, when the player fails to hit the Dark Cube with a correct color, He will laugh at the player. His eyes change to reflect this. The Dark Cube also has other facial animations such as blinking, leering, and a hurt animation when he gets damaged.

Download Movement Code

Download Collision Code

Download Face Code

Level Ending Cinematics

As the player progresses through Chroma, they slowly learn the game’s backstory. The game presents this backstory in the form of six pictures. Chroma has six worlds, each with a collection of levels. Each world has a picture that reveals part of the story. At the end of a level within a given world, the player gets a piece of that world’s picture. When the player completes the world, they get the full picture. My responsibility was to code the logic that reveals picture pieces to players at the end of each level. I describe how I did this in the Picture Projector Code and World Picture Code sections below.

Picture Projector

In Unity, there is an object called a Projector. Projectors can display images on objects similar to how an actual projector displays things in real life. At the end of each level, I use a projector to display a picture piece on the level itself. Since levels are made of blocks, the faces on the blocks form a grid. In code, I display the picture piece on the top of a level and reveal it one block face at a time.

World Picture

Chroma has a main menu where the player chooses which world to go to. On the level select interface for each world, the player can see the picture pieces they’ve unlocked. It was my job to reveal these pieces to the player every time they come back to this menu. The code below handles that functionality. A grid of blocks is the canvas for the pictures and the code uses a projector to display picture pieces based on what levels the player has beaten or what world they currently have selected.

Picture Projector Code

World Picture Code

Cube Face

The cube is the player’s avatar in Chroma. I was responsible for creating its facial animations in order to give it personality and charm. The cube has different facial animations that it plays based on things that happen in the game. For example, when the player loses a color, the cube gets a sad face. These facial animations are a collection of images that I play using code. The code monitors the cube’s state and plays the appropriate animation. The Dark Cube’s facial behavior uses this same logic.

Credits Menu

Since Chroma uses blocks so much, I wanted the credits on a giant rotating block. I thought it fit well with the game’s theme and was unique. The block for the credits is just a normal level block that I scaled up and rotate using code. As the block rotates, I swap out the textures on the block’s faces. Another cool thing that I did was have it so the player can pause or fast-forward the credits. I also wanted the player to be able to rewind the credits, but that was much harder to do and I ended up running out of time to implement it.

Credits Menu Code

Scrum Master

Project management was my primary focus during Chroma’s development. My goal was to make sure my team adhered to the guidelines of Scrum as much as possible. The Scrum board was the main way that we stayed organized and it was my job to manage it. I also lead the team in planning sprints, where we broke down game features into tasks and assigned them ideal work hours. I recorded everything we planned into documents called sprint plans. After a spring was over, I also lead the team in doing a sprint retrospective. We determined what went well and what we could improve upon. I also formed these discussions into documents called sprint reports.

Chroma Scrum Documents

A complete and fully-playable game

For my teammates and I, this was the biggest game project that we had ever worked on up till this point. It was a culmination of all that we had learned. I’m really glad that we were able to produce a finished product that was fully playable from beginning to end. It was the first game that I worked on that I felt could actually be released to the public. I’m proud of myself and my team for what we accomplished.

Chroma not on app store

From the beginning, Chroma was meant to be a mobile game. My team and I had plans to release it on the Apple app store and Android marketplace after graduation, but those plans did not pan out. We were going to continue polishing the game after graduation to meet app store standards, but unsurprisingly, life got in the way. Some of my teammates got jobs, some of us went to grad school, and most of us moved away from each together. It was too difficult to maintain development over a long distance and with new obligations. I still regret not getting the game out there, but I’m still proud of the work we did.

Some problems sticking to Scrum conventions

Since Scrum is a development methodology, its job is to make a team’s development as efficient as possible. However, it only works if developers follow its conventions. It was our first time using it and we weren’t used to the structure of having to make user stories, track ideal work hours, or create detailed plans. Sometimes people wouldn’t update their tasks on the Scrum board or keep track of their work hours. I was guilty of this on a few occasions, and I was the producer who was supposed to enforce Scrum conventions. At times it seemed like Scrum was getting in the way and it’d be easier to just code without distractions. However, we only felt this way because we were used to heroics, which is when developers jump into a project with no plan and try to code everything on pure willpower and talent alone. It works for a while, but it’s not sustainable. As producer, I take responsibility for the team not always following Scrum conventions as closely as it should have.

Being a producer was a new experience

Up until this project, I had been a developer on team projects. I was used to being in the trenches making stuff. Being a producer is a totally different experience. I had to have a wide view of the project instead on a narrow focus. Also, I often helped delegate tasks instead of doing them myself. The most important thing I learned during this experience is that a producer serves the team, not the other way around. My job was to make my team run as smooth as possible by removing blockers and catering to team needs. It’s really hard to do this, because I don’t have direct control over my teammates and I can’t predict what issues might pop up. What I did do was try to mitigate risk as much as possible. It was my first time as a producer and I certainly learned a lot about the non-developer side of making games.