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.
Hello all, Leigh Estes, aka RiotSchmick, here. I’m a software engineer at Riot Games, working in the Service Availability initiative. Today I’d like to discuss the beginnings of one of the products our initiative owns, the public Riot Games API, including why we built it and how we think we’re doing in light of those goals.
Thinking inside the container means building inside one as well. Today I’d like to open up the box on how my team is currently combining Jenkins and Docker to serve Riot Engineering teams. In the most recent post, I promised I would soon discuss the actual build slave and Jenkins configuration directly.
Hi, I’m Jim ‘Anodoin’ Merrill, and I work on test automation efforts for League of Legends, focused specifically on the in-game experience. I currently serve as the tech captain to the Build Verification System Development (BVS-Dev) team. In large part, our team builds tools for automated testing and helps teams write better tests.
In my last post I talked about how the internet is far from ideal for real-time applications like League of Legends and how the resulting latency and packet loss make for frustrating real-time game experiences. The next logical question is, “OK, Peyton, what do we do about it?”