Mayanagari Design Breakdown
--
Mayanagari is an open world action mobile game (akin to the GTA series) set in Mumbai, India. It tries to capture the dream like city with all its density, diversity, drugs, and deception.
It is an enormous game being worked on by a relatively small team of thirty odd people. Being a part of such a project meant that everyone had to play multiple roles and take ownership of many parts of the project.
Therefore, I played the role of Systems Designer, Tools Programmer, and Technical Artist. This article goes over my various contributions to this project. Keep in mind that all this work wouldn’t have been possible without the amazingly talented team at Hypernova Interactive.
My Role as a Gameplay Designer
As a gameplay designer, my focus was on the features that relate directly to the gameplay (obviously). This includes combat AI, wanted system, and vehicle controls.
Combat AI
Being an open world action game that also has a single player campaign, the game needed a robust combat AI system. This system should be able to work in an open world setting as well as in scripted encounters where writers and designers have complete control.
Since our game had to run well on the mobile platform, the combat AI couldn’t be extremely complicated or deep. But making the AI look dumb was also not an option.
We looked into older games like GTA Vice City, GTA San Andreas for the simplicity of their AI enemies. Along with that we also looked at Halo 1 and 2 which also used relatively simple AI characters to craft a variety of different combat experiences.
Our solution to this problem was to let the AI characters have simple behaviours. They can only move to a position and shoot at a target. However, the complexity emerges from a combat director that commands the enemies to move in certain formations and selects which enemies can attack at any given time (rather than all of them attacking independently).
The combat director makes the enemies look coordinated, faking a sense of communication between characters hence making them look more intelligent than they actually are. It also gives several hints to enemy characters to mimic a sense of problem solving.
These encounters can work anywhere on the map, and this system ensures a consistent difficulty level for the player according to what we as designers want.
Wanted System
Since our game was inspired from the GTA series, we also needed the world to fight back if the player causes too much chaos. We also followed GTA’s footsteps by having police AI and a wanted system.
Our wanted system needed to be more arcadey to emulate Indian action films with over-the-top action scenes. So, our system is designed like a hidden minigame. This minigame gets harder and harder as the player fights back the police.
This is one of the most complicated systems in the game since it operates in conjunction with the combat system, enemy AI, vehicle AI, save system etc.
We tried to emulate high intensity car chases and action sequences during police chases, with cop cars ramming into the player’s vehicle and trying to stop them from the front. Numerous iterations were made to fine tune the moment-to-moment gameplay of this system.
Vehicle Controller
India has many classic vehicles that we wanted to show off in our game. This meant that each vehicle had to feel distinct, feel analogous to their real-life counterparts, while also being fun to drive in the game.
We researched extremely thoroughly about vehicle engines, gears, wheels, and various other parts of a vehicle that affect how it handles. We used real life specifications of vehicles and then tuned them to suit our game’s world.
This resulted in SUVs that can actually climb rocky hills, sports cars being very fast and drifty, and trucks feeling exceptionally heavy. The auto-rickshaw is also a part of the roster of vehicles in the game. This vehicle is extremely nimble but surprisingly fast.
Each vehicle has multiple parts attached to its body. These parts can be damaged separately, broken, or detached from the body of the vehicle (e.g. doors, windows, numberplates, etc.)
As the vehicle designer, my role also included setting up and tuning the damageable vehicle body parts to make them believable. Certain parts like the wheels also affect the handling of the vehicle when damaged.
Other Features
I frequently collaborated in other systems as well, especially the ones that interacted with AI and vehicles. The most prominent systems include Player Combat, Quest System, and Point of Interest System (A way for AI characters to gather around and do activities).
With the help of our QA team and developers, we also regularly spent a lot of time fixing bugs and glitches. Even if the features themselves worked perfectly fine, they usually ended up breaking when interacting with each other. Having decent technical knowledge, some bugs were directly fixed by me to take off some load from the development team.
My Role as a Technical Artist
In the team, I also played the role of the technical artist, primarily due to my knowledge and experience with shaders. Most of my work in this role was revolved around writing shaders and certain tools to make artist workflows faster.
A Unified Shader
I wrote a shader that works for all objects and characters on the map, giving the entire game a unified look. A big problem with the default mobile shaders in Unity was that things look extremely flat in shadows.
The shader helps add dimension to objects that also shows up in shadows, while also being light enough to run on mobile without much of a difference in performance.
A different variant of the shader was made to support trees that sway with the wind.
Colour Swapping Vehicles
Vehicles in the game can swap colours. This was done using a custom shader to apply skins and a supporting system that allowed changing vehicle colours at runtime.
My Role as a Tools Programmer
Along with my other roles, every now and then, I would create small custom tools in Unity to help other designers with their work.
These tools were made to speed up the workflows of several designers and artists by handling a lot of the tedious and repetitive work that is a common thing in large projects.
Public Events
To get some user feedback on the game as we were working on the project, the team conducted several public playtests. Everyone in the team was a part of those playtests.
Our responsibility was to let different people (gamers and non-gamers) play the game in front of us. We analysed their gameplay to see which parts of the game were confusing, too difficult, or too easy. We also noted points where the player was most engaged so we can capitalize on that more in the rest of the game.
We also took direct feedback from the players, after the playtests. These notes and feedback were used to improve the game further.
