WWE 2k - MyFaction

Role

Lost Boys Interactive partnered with Visual Concepts to build MyFaction. I started as backend server programmer, then led architecture decisions, led a programmer team for a sub‑mode, and served as the backend SME.

Milestones

First Year Launch - Code and Architecture

This was the ground work for the launching of the MyFaction mode in WWE 2K with the game title WWE 2K22. As the primary backend server programmer I had to do a lot of the initial leg work to get a service up and running. While not as complex as some other online modes there was a LiveOps component where designers needed to make live updates to content for players. Additionally much of the game logic and rules were server driven.

Lots of ground was covered. Some highlights of what I did for the MyFaction mode:

• Prototyped client (C++) to server communication for mode.
• Use a code first approach for database access (SQLAlchemy ORM with Alembic schema migrations).
• Authored tech designs and implement the backend systems for majority of systems. Any other backend systems I then authored or guided the design and handed off to a co-developer.
• Integrated an administration website for LiveOps and Customer Service
• Set up local server for developers using Virtual Box.
• Led load testing initiative using Locust.io.
• Integrated metrics and observability using Prometheus and authored Grafana dashboards.
• Introduced integration testing using pytest.
• Loot table system for packs contents.
• Created a two tier caching solution involving Redis, included coordinated invalidation and key versioning features.

Multiplayer and Automation

The core of MyFaction having existed the next titles were spent developing new player features, primarily live events and multiplayer features. I assisted again with the initial tech designs and worked on training developers to assist with implementing features.

Multiplayer introduced new complexities. We had to ensure correct start state of player for matches and do post match processing that involved each team's combined outcome. Using Redis as a shared match session I was able to create a simple system that traded and synced data between players. Game clients also had an option to poll this system for syncing basic data before matches.

As the MyFaction project and team matured, automation was more important. I could not, and should not, do manual processes to keep dev servers up and running. This was doubly so for processes that only I could do. In the first game I had improved a deployment script provided by co-developers. I worked with the DevOps team to get this in a Jenkins pipeline for auto deploys. We set up a auto deploy on check in for a bleeding edge dev environment server. I iterated on this script and pipeline to make it so it was also then the deployment to other game servers. These pipelines have since been used to deploy to servers reliably and extended to include other online team's deployments.

Faction Wars Mode Reboot - Team Lead

For one cycle I helped lead a team of programmers to implement an overhaul of the Faction Wars sub game mode. Previously a simple tower mode (random match after match) it was redesigned into a pick your path. Unlike previous work this was a full stack implementation by the team I was leading. UI/UX, game client, game server, database.

I lead the team in tech design planning allowing team members to take ownership of features and growing their technical writing skills. I lead the team in poker planning sessions and work with production to task out and plan features and deliveries. I also implemented features full stack, writing C++ code for the game client and continuing with backend server coding.

This was also the first time we would make game assets, the level maps, in the game editor tool and then use that asset on the game server. I created a new data pipeline that could take an asset by schema and route it to a code class that would then parse and transform the data into the database. After this was proved as viable pipeline an initiative was started to convert most server data assets to be game editor assets allowing designers to work with the same common tools the rest of the team used.

Fun fact, there is no perfect way to layout a DAG of nodes but it can be easily side stepped by using spring physics instead.

Tech Designs, Dev Tools, Team Growth

As the team got more familiar with building full stack features I continued to train developers on backend programming. While I didn't have time to implement all the code like I did in the first years I was still the subject matter expert on backend systems and the original game systems. I was able to author many more tech designs to meet designer requirements and guide overall backend system growth to keep it as maintainable as possible.

Over the years I also helped the team adopt best practices in regards to dev tools and coding standards. Python specific ones were enforcing code formatting, setting up uv with pyproject.toml settings, requiring tests on new features, formalizing profiling of server code, and lock files for dependencies. Other improvements included getting tests run after every check in and more automation with Jenkins pipelines.

For local development using the server I migrated the setup from VirtualBox which was hard to support for many people to instead Docker (using Docker Desktop) and using Docker Compose to better simulate our service architecture (separate hosts for game server apis, redis, database, and web page host).

IDE setup and virtual environment were formalized into setup scripts and integrated into the team wide setup tool, ensuring all developers that worked on the server could stand up a local server and start programming or even testing with in minutes.