Monster Guys

Overview

Monster Guys is a platformer game with combat elements developed for mobile devices, where a giant group of silly hunters compete in obstacle runs and in monster hunting. It was planned to be a live-service game, but development was canceled after Sync Games shutdown.

Sync Games

Gameplay Programmer / Designer

May – Sept 2022

Unity

Introduction

When development for Smash Monkeys (a 2.5D racing platformer live-service game, on which I worked as a QA Tester) was wrapping up, we were tasked to brainstorm ideas for a "Monster Hunter"-style game for iOS and Android phones. I proposed an idea where teams of 3 would have to fight a monster and themselves to claim the last killing blow, and at the time, it seemed everyone was on-board with this idea.

However, in middle of development, the idea had been changed for something more standard or "familiar". It was basically a combination between Fall Guys and a extremely basic iteration of Monster Hunter. Since the project didn't even hace a code name, we internally were calling it Monster Guys (and what a good name it was!).

Anyway, since I already had a good knowledge of C#, the team asked me to work on the prototype as both a programmer and a designer. I was very excited. After months as a QA Tester, I really wanted to be promoted as a Game Designer (specifically a Technical Designer), and I got to work immediately. I worked on the Player Controller, and the Monsters AI, and I also fixed some technical issues with some of the assets provided.

Sadly, the company shutdown and all projects were canceled. Because the prototype went nowhere in the end, we were allowed to copy the project and do whatever we wanted to do with it. Maybe I could revisit the prototype at some point in the future, but for now, it sits as a neat showcase of cool ideas.

Using a Finite State Machine (FSM), we separated movement functionality, special abilities such as the aerial dash, and ragdoll and death states. I already had prior experience implementing this pattern, but I had never built one specifically for a player controller. In this case, the controller needed to be usable by both players and bots, which required an inversion of dependency based on the type of input received. Additionally, since our controller was based on the Kinematic Player Controller package, I had to integrate and use the necessary methods to make sure it updated correctly.

Dinoco's AI, the only monster implemented in the project, was also built on top of this same foundation, which made its behavior much easier to implement and extend.

Admittedly, the implementation was basic and somewhat rushed, but it was good enough for a prototype. If the project had not been cancelled, the code would have been refactored or even rebuilt from scratch.

Handling Characters through States

Code Snippet: Dinoco Charge State

The main idea was to implement a health system for characters, monsters, and certain destructible elements. To achieve this, I created a HealthController class that handles core functionality such as taking damage, healing, health change and death events, and updating a Canvas when one is assigned. This base class can then be extended or customized to add entity-specific behavior, for example players, who feature health regeneration that activates after taking damage.

To add more visual feedback to the interface, the health bar changes color dynamically using a gradient (red, yellow, green) and is composed of two separate bars, one representing the current health value and another showing the amount of recently received damage.

Health Controllers

A ragdoll is a combination of colliders, rigidbodies, and character joints connected to different parts of a character’s body. I configured these components so that when players were launched into the air by monsters, the resulting ragdoll behavior was as exaggerated and amusing as possible, using only six collision-enabled body parts. At the same time, we wanted characters to recover smoothly and get back on their feet, which required interpolating from the ragdoll pose back into an animation.

While working on this interpolation, we had to deal with some issues:

The character models initially contained many unnecessary bones in their rigs. For a mobile game expected to spawn a large number of characters, performance would have dropped significantly once multiple characters entered the ragdoll state and required bone interpolation. I worked closely with the 3D artist, who also handled rigging and animation, to reduce the bone count as much as possible, going from around 60 bones down to just 20.
Due to these model changes, all ragdoll setup work had to be transferred from one model to another. This process was extremely tedious, so I created a script to copy ragdoll components and reassign them automatically to the corresponding bones of a different model.
Depending on the character’s final pose, the interpolation back to animation could look unnatural. To solve this, we created two separate recovery animations, one for getting up while facing upwards and another for facing downwards.
For the interpolation itself, bone positions and rotations had to be adjusted in LateUpdate, since the Animator applies its changes in Update. Before starting the interpolation, I cached the ragdoll pose and then performed a Lerp between the Animator’s updated pose and the cached ragdoll pose. This approach resulted in very smooth transitions between states.

Ragdolls and Bone Interpolation

What I Learned!

My time at Sync Games was great and very insightful! I did learn a lot about how a live-service operates, how production is handled, how the programmers went about implementing new features and solving issues, and how much testing had to be done as a QA Tester. Spending most of my time talking to the lead programmer about code, tools, and other interests is what made me pursue more programming knowledge.
I learned that mobile gamedev is very delicate about memory and CPU usage. This sounds obvious, but seeing it by yourself truly shows everything in great detail.

For example, something that I didn't include in this page is that I had to program something to hide elements any elements that could obstruct the vision of the player controller. My initial solution was to set transparent any objects detected between the controller and the camera through a single raycast, but transparency is expensensive, dropping performance is older phones whenever the objects were made transparent.

Little things like these, or the bone interpolation really shows how much you have to optimize and keep in mind.
I improved a lot since Noise Hunters. The prototype's code was more manageable, had better use of interfaces and inheritance, and looked cleaner (even though it was rushed).