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?”
Hey, everyone! I’m Bill “LtRandolph” Clark, a League of Legends gameplay engineer. Many Rioters in engineering focus on the delivery of awesome content directly to players—a couple of my recent favorite examples include the newest champion, Jhin, and the support item reworks. My team, on the other hand, works to make that process faster and easier.
We have a simple goal: to allow Rioters on gameplay projects to create twice as much content for any given LoL patch. That’s easy to say, but it’s a challenging task.