Overview

Mortal Kombat: Onslaught is a fighter-collecting auto-brawler RPG with asynchronous PvP multiplayer from NetherRealm Studios. The Unreal-5-based mobile game continues where Mortal Kombat 11 left off, where the evil sorcerer, Shinok, starts drafting a plan to take over all realms. Gameplay consists of selecting four fighters in your collection, and having them auto-fight against either waves of enemies, another player’s party, or a boss and a few goons. When a fighter is fully charged, the player may manually trigger a special attack through a drag-and-drop interface indicating the range of said attack; though this may be set to auto-trigger on full meter if the player so chooses.

As the Online Engineer, I was responsible for:

• developing the Typescript backend server,
• drafting an Unreal interface (via C++) to connect with the backend server’s REST API,
• constructing NW.js desktop tools to add test bots and user profiles into the backend server, and
• maintaining Vue web tools adding and modifying events and messages, hosted by the backend server itself.

My position paid most critical attention in fighter customization (e.g. stats, equipped items, etc.), player inventory (e.g. rewards, gear, unlocked fighters, etc.), managing live events, and recording battle results (e.g. win or loss, number of special moves triggered, achievement progress, etc.)

Backend Development

The Online Engineer position at NetherRealm Studios exists between an intersection between Game Designers, UX Designers, and UI Engineers. Take the Gong button as an example: the Gong builds up common currencies over time, up to a certain limit. When the players taps the button, they are given the however many currencies they have accumulated over that period.

The feature was first presented to me as a wiki game design page describing the functionality and intent behind the feature. For the first draft, I collaborated with a Systems Game Designer and “owner” of the feature, and created a series of spreadsheet (CSV) interfaces that allows the designer to specify data related to the feature — such as reward accumulation rate and upper limit — based on player story progression. A simple import button is provided for the game designer, making it easy for them to convert the data to an encrypted Unreal asset. Then a Perforce hook script uploads the Unreal asset to the server, thus updating it on every submit.

When the UX Designer, who have also reviewed the wiki page around the same time I have, was able to put the final interface together, the UI Engineer and I collaborated to determine what data the server API should provide. This was done by accessing the WB Games NY servers, which itself allows developers such as myself to add a middle Javascript/Typescript layer to read and aggregate the data in a way friendly to the UI Engineer. I would draft a C++ code that receives these computed server data so the Unreal developer can construct their user interface swiftly, without the need to know or customize the in-game specs.

Other in-game features I’ve worked on had a similar dynamic as well, including the daily login rewards screen that appears as soon as the game boots up, and for any rewards the player missed due to an event expiring, an auto-redemption player message with rewards as attachments. I’ve also implemented the Chasm battle mode, which lifts its code from Story mode, but removes cutscenes and allows players to re-obtain rewards on replaying a level (albeit, a limited number of them per day.) Lastly, I’ve added achievements and quests related to aforementioned features, such as how many times Gong has been tapped per day, how many Chasm battles were won, total, etc.

Tools Development

As someone responsible for drafting the backend server’s REST API, I was also responsible for constructing test tools for both QA and developers to test certain features. These desktop (using NW.js) and web tools came in the form of Vue.js interface that receives and sends data to the dev backend server. For example, to simulate a user specific problem, I designed a simple desktop interface to select and copy a user’s data from the production server, into the dev server. I also collaborated with a game designer on upgrading our existing bot generator: a tool to add a series of test user profiles that the QA and game designer can play against. The upgrade includes streamlining the poor user interface by hiding optional stats into pop-ups, and adding new features like specifying where the bot will place its heroes on the starting board. Finally, I maintained the backend server’s web tool for adding live events and messages to the game.

Hurdles

While bugs did commonly arise during the development of Mortal Kombat: Onslaught, the largest hurdles in development came from features that were implemented “as designed,” but had poor user experience and required rewriting. Take the Daily Login Rewards, as an example. In the original design document, any new rewards received in a menu or battle would show a results screen indicating what has been claimed. As such, the original Daily Login Rewards menu sent a request to the server when the “Kontinue” button have been tapped to retrieve what rewards were claimed, then when a response was received, to display the results in a results pop-up.

This implementation tested poorly: it failed to take into account that, one, the screen is literally the first thing that shows up after the loading screen, and two, the Daily Login Rewards menu almost always had more than one tab to “Kontinue” through, meaning the player needed to sequentially wait for each server request-response connection per tab. It was a dragging startup screen that kept the player from playing the game: an optimization was in order.

A group discussion was held between the UX designers, UI programmers, game designers, and of course, us online engineers in resolving this issue, and we suggested the following accepted solution: to give the player all the daily login rewards on logging in (which is part of the loading screen process,) and update the existing C++ interface to download the results of the login process. The solution went further to minimize the UI programmer’s work by having the C++ interface “pretend” like it’s requesting to the server, when in reality, the results were already stored locally on the device. While this still required some changes from UI programmers — the old code was still kept for covering difficult edge cases, and the “pretend” workflow had a few differences with the original implementation — it only took them a few days to update the feature with the new optimization. Once the optimization was implemented, complaints about the daily login rewards faded quickly.

Conclusion

The Online Engineer position serves to assist and accelerate the game designer and UI programmer’s job by reviewing and specializing in the backend server API, and constructing an easy-to-use interface for both to upload or receive data. The position, while only requiring small team to run, still involved active communication between other team members to understand and verify a feature’s implementation, and correcting mistakes when they come. The primary satisfaction and reward from working in this position was helping improve the developers/designers experience in the development of the game.