Stampede: Racing Royale

During my time as a Junior Games Programmer at Sumo Digital, I worked on Stampede: Racing Royale, a chaotic kart racer with 60 player battle royale style elimination. I worked as both a Gameplay Programmer and a UI Programmer and was responsible for implementing various features including, the challenges system, maintenance mode, and some full screen effects during gameplay.

Challenges System

The challenges system was to be an integral part of the economy of Stampede: Racing Royale and requires interconnected frontend and backend systems, which should track a players progress across various metrics, provide an accurate representation of this in the UI, and correctly synchronize the challenge information between the client and the server.

The challenge system began with placeholder UI elements and no backend system supporting tracking player progress. There was no functionality to select, claim, progress, or reroll challenges, and many art elements were not quite as the design specification had specified. All the challenge titles and descriptions were using placeholder text rather than retrieving all the relevant challenges from the backend on the server.

The development of the challenges system required a lot of planning and collaboration with various roles across the project. I have learned a great deal from both technical and collaborative standpoints. The following points summarize what I have learned and will take forward from this experience of having planned and developed the frontend UI for the challenges system.

• The processes involved with creating frontend UI systems.
• The processes involved in text localization.
• The importance of task estimations.
• A better understanding of roles across the project.
• A better understanding of the backend processes.
• The importance of team collaboration and syncing.

The development of the challenges system was a great learning experience and going forward I believe that from what I have learned, this will ensure more efficient, more effective, and more collaborative development of features in the future.

Challenge Reroll System

I also worked on the reroll system. Rerolling was a major part of the challenge system and enables players to reroll both daily and weekly challenges. The purpose of this was to give players the option to opt for different challenges than the ones that they received. There were limits to how often players can reroll challenges and rules regarding what challenges can be rerolled, but ultimately the goal of the system was to add more depth and stability to the games economy.

I created a new popup which was intended to handle the entire challenge reroll system. I added a few placeholder challenge elements and the UX was functional and fluid. After spending more time trying to improve the functionality of this reroll popup, I quickly learned of its limitations. As I wanted to update the popup display to show a new screen which would present the newly rerolled challenge to the player, this was not feasible especially when referring to the original design specification.

Due to this, I opted for an entirely new view and state which would be self-contained and handle all the reroll logic and the simple addition/removal of various UI elements. Around this time, I also received help from the art team on its design. The design of the reroll screen was improved after I changed it from a popup system. The UX was still the same, however, the UI had been improved.

Then, I made further improvements to the design of the reroll screen. This required further discussion with the design team due to confusion surrounding the cost, frequency, and general rules regarding challenges and rerolling them. I then updated the UI further, and following the backend hookup, was able to display the correct reroll information and have challenges reroll properly by pulling from a list of pre-defined challenges on the server.

From developing the challenge reroll system, I have learned a lot about the importance of reading and understanding both tech briefs and design specifications before starting development on a feature implementation. I also learned the importance of creating an open dialogue throughout feature development with the design team to ensure that everything is being created as intended.

Maintenance Mode

The next system I got to work on was maintenance mode, which was a system that was intended to inform players of planned server maintenance by providing informative UI with a smooth UX that properly handles their socket connections and logs them out when server maintenance begins. The intention was for any RPC requests that are made to the Nakama server to be intercepted and handled accordingly.

The problem was that when maintenance mode is entered on the backend Nakama server, there is currently no method of informing the user that server maintenance has started. There is also no system to log the player out smoothly, instead, the player simply cannot communicate with the server and as such, cannot navigate the home UI as normal, resulting in missing UI and text elements.

I began outlining the various aspects of the frontend that would need to be handled to properly inform players of planned maintenance times, when maintenance starts, and on attempted reconnection to the server, and the fact that server maintenance is still ongoing. I used Postman to quickly change the maintenance mode for testing.

I then began to experiment with showing popups on the home screen after the initial fetch had been performed. Using the data from the backend, I then began locating all the relevant RPC requests throughout the codebase and showing the relevant server maintenance popups if the metadata in the response had been updated.


Showing a full-screen popup on attempted reconnection to the server was another issue that I managed to fix. After experimenting and testing different solutions, I was able to show a screen on a failed reconnection to the Nakama server while in maintenance mode.


The development of the maintenance mode system required a great deal of planning and communication with backend programmers considering its level of complexity. I learned the most from a technical standpoint regarding the Nakama server, socket connections, and the general networking conditions of the game.

Sticky Bomb FSFX

I then got to work on the fullscreen effects for the sticky bomb power-up after moving to the gameplay team. The purpose of the sticky bomb FSFX was to provide additional visual feedback to the user when they have picked up a sticky bomb. The FSFX was designed to disorient the player and simulate the racer's visuals to ensure a more immersive experience. The effects of the FSFX would slowly fade away when the sticky bomb became detached from the player unless it explodes prior to then.

At the time, the sticky bomb did not provide enough feedback to the player when they were stuck. As a result, the effect of the sticky bomb was dampened and its power lessened against all other power-ups considering the racer could very easily win the mini-game and have the sticky bomb detached from them simultaneously. To solve this problem and ensure a more immersive experience, I added a FSFX for when the sticky bomb was stuck to the player.

After making all the relevant changes, I ran a full profile of the FSFX to ensure that the FSFX did not prove too expensive considering that the game would be played on mobile devices with hardware significantly inferior to that of a PC. As such, I profiled both the CPU and GPU usage with and without the FSFX active.


For this, I profiled the game in the editor and as a standalone build, and I found that in each instance, the CPU frame times for the FSFX were averaging around 0.01ms where the average frame times were 14ms. The average frame times on the GPU with the FSFX active was 3.4ms and about the same when inactive, with slight spikes upon activation and deactivation. Of all the post-processing effects that were active while the sticky bomb FSFX was active, this FSFX only accounted for 3.42% of all processing time for all active effects. So overall, the sticky bomb FSFX did not appear to have any noticeable impact on CPU or GPU processing, outside of the slight spikes more so on CPU processing when the effect is activated/deactivated.


Having developed the sticky bomb FSFX, I have learned a lot regarding implementing new FSFX to the game. I also learned various ways in which to optimize and profile a FSFX and some further considerations when adding a new effect into the game. This was also one of the first time that I had worked this closely with artists on implementing a feature into the game, so a lot was learned regarding the process of communication and collaboration when implementing a new FSFX.

Feel free to drop a comment below.