Color Match Game

With friends or against the computer, players scramble to reach the platform matching the majority color of the display screen. Fail to make it, lose a life. Last one standing is the winner!

A lot of my previous work has been on the asset creation side of the pipeline. For this project, I wanted to execute on a game that was simple in scope and manageable for one person. Most of my study and research would be focused on what makes for an engaging gameplay loop in a small arcade-style format. Before ever bringing the art and assets into production, I knew it would be important to cement the player experience and focus on the fun factor and gameplay. After all, whether it’s an animated film or a video game, if the story, gameplay, or user experience is lackluster, no amount of sophisticated art will save the project.

Concept

The major inspiration of this project comes from minigame compilation games, titles like Mario Party or WarioWare. Since each game is meant to be part of a greater collection played and learned in one sitting, it is paramount that the concept is short, easy to explain, and accessible by players of all skill levels. I have a case study where I talk about what I think is core to making a good minigame here. A general idea that I thought would be good for this project comes up in many of these games. It usually involves multiple people trying to reach a platform that matches a chosen color or pattern in the allotted time. I thought this would be possible in scope for me, and I had some ideas of how I could innovate on it and add gradual difficulty as a means of progression.

Initial concept drawing

Instead of a single chosen color, a screen would instead be made up of numerous squares that settle on a final mixed up grid. Players count the colors and move to the platform that is matching to that majority. As the rounds continue, there are three ways to increase difficulty. These are to expand the grid size (2x2 up to 8x8), expand the color pool, and add more platforms. I thought this would be a great foundation for an interesting game loop to bring to life in Unreal Engine.

Executing the Game Loop

Color screen in action with tie-breaker tile exaggerated for demonstration

The shader for the color screen is implimented with HLSL to assign various RGB colors from an array into each individual scaled UV coordinate. Exposed parameters change the UV X and Y size, the length of the color list to pull from, and a random seed value to allow this shader to have its “difficulty” ramped up at a chosen scale across other blueprints. At the end of a generation interval, a render target reads the color at each square. It has its resolution scaled to match the UV size so that each square is considered a pixel to iterate over. These readings increment a TMap that will then decide which platform matches the majority index and is considered “correct.”

But what if there’s a tie? In the video above, all four squares are different. One color will be chosen to be assigned to a color patch. The color patch is then translated to seamlessly cover a square of another color tied to the majority. The demo has the patch pulled out to visualize, showing that blue is overridden by yellow, and yellow is now the most present color.

Something I had not considered in my planning was pause functionality. Here, you see the color patch scaled to cover the entire color screen, so that there is no way to cheat. A pause limit per game is also added to stop pause buffering.

Multiplayer

The previous design work I’ve done for games has been for single player experiences. For this project, I had to rethink the structure and reference management of my workflow. Essentially, at the start menu it is determined how many controllers, player or AI, need to be created to start the game. Each one is given its own character reference, color assignment, UI, and all of this is held in arrays of respective references. For various checks during the game loops, the ordered array allows for things like correctness checking and life removal to be done to the appropriate character. When the character dies, all of its data in these arrays is set to 0, so that the game loop knows to skip interactions with these classes. To handle menuing, there is a floating Menu Actor that can be possessed to pause and handle settings. By decoupling menu controls from the characters, it ensures that only one pause state can ever exist, and can handle freezing player control for the AI and other human players.

For a much more exhaustive look at troubleshooting and minute feature-tooling, I have a series of blogposts here that show in the moment thoughts and problem solving.