My name is Jonathan McCaffrey and I work on the infrastructure team here at Riot. This is the first post in a series where we’ll go deep on how we deploy and operate backend features around the globe. Before we dive into the technical details, it’s important to understand how Rioters think about feature development. Player value is paramount at Riot, and development teams often work directly with the player community to inform features and improvements.
Hello, David Rook here. I’m the product owner of application security at Riot Games. In an effort to provide the best and most secure game experiences to League of Legends players, we’ve been running a bug bounty program for a few years now. When it comes to finding bugs in our live services, we wanted to ensure that we were listening to researchers all over the globe.
Over the past several months I’ve published six articles that discuss using Docker and Jenkins to containerize a build farm. Recently, I went on the road to tell the story at DockerCon 2016 and gathered a tremendous amount of amazing feedback. In fact, the best part of this whole experience has been the conversations we’re having with folks encountering similar challenges. In this short post, I’d like to accomplish two things: share the video of my DockerCon talk, and respond to requests we’ve received to consolidate my articles into a single place.
Over my last two posts, I’ve talked about the challenges facing real-time applications like League that arise from the internet’s architecture, and how Riot is tackling some of those challenges by creating our own network. In this post, I’d like to look forward - what’s next, and how can we collectively get there? This topic has inspired a lot of reflection on my own experience building networks, and has galvanized my perspective that things are changing for the better.
Hello all, Leigh Estes, aka RiotSchmick, here. I’m a software engineer at Riot Games working in the Service Availability initiative. Our first article on the API covered our goals, the responsibilities of the Developer Relations and Developer Platform teams in the API ecosystem, and some high-level details about the technology we used in building our API solution.
Hi, my name is Jeff, and I work out of the Riot St. Louis office on the Always Available Friends team. We recently released the League Friends app for Android and iOS to give players a way to connect with their League friends outside of the game.
Greetings! My name is Andrew McVeigh, and I'm a software architect at Riot.
We're in the latter stages of re-engineering the League of Legends client. We're calling this the League client update. In this post, I’ll outline the software architecture of this update and provide some background to the choices we made by pointing out some of the limitations of the current (original) client. The journey to our final architecture has been technically fascinating, and I’m excited to be able to share it with you!
In late 2013, Riot’s map team started to work full-tilt on updating Summoner’s Rift, the flagship map for League of Legends. It was an enormous task: not only did the team need to upgrade the map’s look and feel while preserving the bits that players loved, they needed to do it without increasing the minimum required hardware spec. Looking back, now more than a year after the launch of what we called the Summoner's Rift Update, or SRU, I think the team did an amazing job. The map is more vibrant and engaging, and it better supports the competitive integrity of the game.
Back in 2014, the Riot Direct team started a journey to provide a better League of Legends experience through network improvements. We started to look at the internet not as an inexhaustible resource, but as a limited system that had to be managed and scaled correctly.