MIXCITY ARENA
Lead Game Designer | Gameplay Programmer
Role
Lead Designer | Gameplay Programmer
Presence
From early prototype to current state
Engine
Unity
Type
Profesionnal
Genre
MOBA | Tower Defense
Platform
PC
Status
In development
Website
ABOUT
Mixcity Arena is a 3v3 MOBA game taking place in a futuristic world, where athletes from all types of sports fight each other in an arena.
Mixcity Arena revisits classic MOBA games, adding tower defense mechanics. In Mixcity Arena, you can upgrade your towers and buy special minions to help you in lane.
Mixcity Arena offers accessible gameplay with innovative and entertaining experiences.
MY ACHIEVEMENTS
On this project, I was Lead Game Designer for the whole prototype and early alpha phase, and then switched to Gameplay Programmer.
As a Lead Game Designer:
-
Shaped the basis of the game following the direction of the Creative Director.
-
Led a team of 3 designers from prototype phase to alpha phase.
-
Wrote and kept up to date the GDD and other technical documentation.
-
Lightened programmers’ work by prototyping some game design features on Unity using C# in order to test them before developing them.
-
Increased players possibilities by designing new content such as champions, items and new mechanics.
-
Game is still under development, so gameplay details about my work as a Lead Game Designer can't be shared.
As a Gameplay Programmer:
-
Developed most of the champions of the game, taking into account client/server interaction.
-
Increased player possibilities by developing some gameplay elements such as a bush invisibility system.
-
Assets integration (models, animations, FX)
-
Created new game modes such as 1v1 and a 2v2 game mode.
-
Increased player onboarding by fully developing the game tutorial (system and content).
-
Bugfixing most of gameplay's oriented bugs.
UNIT DESIGN & PROGRAMMING
As a Lead Game Designer, my team and I designed the champions in the game.
Then, as a Gameplay Programmer, I developed most of the champions, including the following one, Malia.
Developing Malia was a challenge, as it required extending several base classes to support its unique mechanics.
This included implementing skill resets triggered by other skills and adding a health bar extension to display Kata points.
The complexity was further increased by the client/server architecture, requiring careful synchronization to ensure consistent behavior across the network.
Kata - Passive
Malia's skills generate Kata Points for 7 secondes.
When Malia reaches 5 Kata Points, her base skills' cooldown are reset.
Ayumi ashi
Malia dashes in the the targeted direction, dealing damage to all enemies she hits. The skill can be used again in the following 4 seconds.
Generates 1 Kata Point if a champion is hit.
Kiai
Malia shouts and gains a shield for 5 secondes.
Generates 1 Kata Point.
Mae-geri
Malia deals damage to the targeted enemy, stuns it for a short amount of time and slows it.
Generates 1 Kata Point.
Hangetsu
Malia dashes in the targeted direction, stopping at the first enemy hit. Malia can reuse this skill within 6 secondes, up to 3 times.
Each subsequent use deals increasing damage and generates 1, 2 then 3 Kata Points.
Another particularly challenging champion to develop was Irina, who can switch between two stances, altering all her skills and basic attacks, allowing her to switch between ranged and melee auto attacks.
To implement Irina, I had to rework the skill initialization system, which initializes skills when a champion spawns, to also initialize her second set of skills.
Additionally, I had to modify the skill level-up system, which was originally designed to upgrade only the current skill. For Irina, it had to simultaneously level up both her active and alternate skills.
Irina's stance also affects her idle and running animations, requiring proper synchronization across clients to ensure all players correctly recognize her current stance
BUSH INVISIBILTY SYSTEM
As a Gameplay Programmer, I implemented a bush invisibility system that dynamically manages unit visibility based on team presence.
Bushes work as follow:
- If only units from one team are inside a bush, they are invisible.
- If units from multiple teams are present, they are visible for to each other.
This system ensures that players hidden within bushes remain invisible unless an enemy unit is also present.
To efficiently track multiple teams within a bush, I used a bitwise enum flag, allowing efficient combination and comparison of team values using bitwise operations.
All logic is handled server-side, and the invisibility effect is applied through our Network Status Effect system, which synchronizes the status with clients by adding or removing the invisibility effect accordingly.
Below is a snippet from the Bush script I implemented:
CODE SNIPPET - Bush.cs
TUTORIAL
I developed a fully custom tutorial system from scratch, designed as a structured sequence of steps, guiding the player through essential mechanics (ex: "Move here", "Defeat this unit", etc...).
At the core of this system is the TutorialManager script, responsible for initialization, event management, and step progression. It manages two key components: ITutorialBackgroundTask and ITutorialStep, both implemented as Serialized Interfaces for more flexibility.
-
ITutorialBackgroundTask handles persistent tasks that run independently of the current step.
-
ITutorialStep represents a single tutorial step, implementing functions such as Init, Update, Complete, Replay and SetContext, allowing for reusable and easily configurable tutorial steps.
Thanks to its Serialized Interface structure, this system is easily configurable and extendable.
It allows for easy modifications, such as adding or removing steps or even creating entirely new tutorial.
Additionally, this system is also gameplay-independant, making it reusable across multiple games. The only gameplay-specific elements are the implementations of the ITutorialStep and ITutorialBackgroundTask interfaces.
Code snippets demonstrating some of the code I wrote for the TutorialManager and a TutorialStep, as well as videos of the tutorials are available in the private part of my portfolio.
NEW GAME MODES
As a Gameplay Programmer, I was reponsible for implementing two new game modes: a 1v1 and a 2v2 game mode.
The goal was to extend the existing gameplay systems without modifying any of the core mechanics of the original 3v3 mode, ensuring stability and preventing regressions.
I achieved it by primarily subscribing to existing events to integrate new mechanics seamlessly, and creating new ones when necessary. Since adding new events to existing code has a low risk of introducing bugs, this approach was the preferred solution.
These modes had to be implemented with client/serverc architecture in mind, for all actions and interfaces elements.
Code snippets showcasing my implementation of core mechanics for these modes are available in the private part of my portfolio.