Hi, I’m Tony Albrecht, an engineer at Riot, and I’m a performance junkie. This is the second part in a series on how to optimise your code. In Part 1, Measurement and Analysis, we learned how to find and analyse performance bottlenecks in our sample code. We surmised that the issue was due to slow memory access. In this article we’ll look at how we can reduce the cost of memory accesses and thereby speed up our program.
Articles tagged: game
Hi, I’m Tony Albrecht, an engineer at Riot, and I like profiling and optimising things. In this article, I’m going to walk you through profiler basics and analyse some example C++ code as we profile it on a Windows machine. We’ll start at a very high level and delve deeper and deeper into the bowels of the CPU step by step. Once we identify opportunities for optimisation in this article, we’ll implement changes and explore some real-world examples from the League of Legends codebase in a future article. Let’s begin!
Hi, I’m Rick Hoskinson, an engineer on the League of Legends Core Gameplay Initiative, and I’m here to talk about how we gave ourselves the power to turn back the hands of time in League of Legends. In this series of blog posts, I hope to give you a glimpse of what that work looked like, juicy technical challenges and all.
Taking the League of Legends game server from a nondeterministic process to its current state required almost a full year of effort from multiple engineers. As a side benefit of this effort, we holistically improved the codebase’s robustness, discoverability, and maintainability. We removed swaths of dead or redundant code and created new opportunity spaces for gameplay exploration.
Hi, I’m Rick Hoskinson, an engineer on the Deterministic Disaster Recovery team, and I’m here to talk about how we gave ourselves the power to turn back the hands of time in League of Legends. In this series of blog posts, I hope to give you a glimpse of what that work looked like, juicy technical challenges and all. In this first post, I’ll introduce the problem and how we chose to solve it.
Hi, I’m Tony Albrecht and I’m one of the engineers on the new Render Strike Team under the Sustainability Initiative in League of Legends. The team has been tasked with making improvements to the League rendering engine, and we’re excited to get our hands dirty. In this article, I’ll provide a run-down on how the engine currently works - hopefully this will be the foundation on top of which I can later discuss the changes we make.
With the current scale of a game like League of Legends, it can be hard to remember the humble beginnings: a small group of developers too busy shipping a game and putting out fires to think about fine tuning systems, pipelines, and processes. And while we’ve changed a lot, our priorities remain the same: we’ll always put player experience before tech and process. Sometimes that leads to tech debt, and as we grow, it's important that we look for ways to improve the quality of our work as well as the way we work. Not every step forward has to be revolutionary.
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.
League of Legends has more than 125 champions, each with their own set of unique animations. (One of my faves? Sion’s dance, shown below—just one of his 38 animations.) These movements help to bring the champions to life: from determined movement to powerful spell casting to tragic deaths. (I see that last one too often.) As we’ve continued to introduce and rework champions, the total amount of animation data has become a larger burden on resources like run-time memory, patch sizes, and storage space.