The Topic

League of Legends is a multiplayer online battle arena style game. After its release from beta in 2009, it quickly became the most played game in the world (by number of repeat users). The game is extremely intricate and involves (on Summoner’s Rift, the specific game map targeted in this project) a 5 versus 5 team battle where the aim of the game is to destroy the other teams nexus, or base, before they destroy yours.

The reason this game is so closely followed is because of the intense amount of information that can take place within one game as well as all of the different combinations of items, champions and various other elements that players choose per match. This amount of information makes League a perfect candidate for visualizations, which if utilized to the right degree can allow an individual to inspect certain key aspects of their game, in order to improve from the ground up as well as just highlighting any key interests they may have on certain areas of their game as a whole.

The Problem

Currently the statistics, if visualized at all, are far too generalized and do not really offer one the opportunity to better their game on an individual and focused level, but rather just tell if they have been doing reasonably well or not (which they could tell from the general outcome of their games mind you). Thus our visualization is aimed at any players looking to find any individual statistics for their games, the roles they played in the games (top lane, mid lane, jungle or bottom lane) as well as the areas on the map and the times certain key events are happening to them, on average or on an individual game basis. These statistics, as stated earlier could be used to get better at the game, for interest sake, or just to brag to your friends.


What We Want To Do

We want to make a visualization that enables competitive players to analyze how they are performing relative to the map. Being able to visualize where you are getting kills and where you are dying can help improve your play style and as a result improve your chances of winning.

Using the data provided by the Riot API (match history, player data, player events, etc.) we can also create overlays that can help optimize how you play your role. Points can be generated to show where the player spends the majority of their time, how efficiently they are killing minions in the jungle and what route they decided to take to clear these camps. Scatter plots can help to visualise the position of kills and deaths for any given player and give them valuable insight into their play styles.

As League of Legends is an objective based game, our visualization will show which events took place leading up to the objective, this will give insight into why you successfully took any particular objective or failed to do so.

Through the use of our visualisations, we hope to help players getter a better idea of how they play the game and what steps they can take to become better players.

Related Work is one of the most widely used information bases for any league based statistics, news and champion information[1], in general LoLKing is the go to place for anything League. That being said, their mass of visual statistics are in the forms of charts and graphs, as well as being more focused on teams rather than players. Their match history does not provide any map based visualization, firstly, and secondly no medium to compare performance based on Role or individual match.

Below you can see examples of their individual statistics and just how it has no map based visualisations. That being said, their use of colour is a good way of showing an increase or decrease in personal LoLking score (a general metric of how well or bad you are playing presently) or your match history. [2]

Here is an example from Riot's official League of Legends page. This uses pie charts to demonstrate information and it is difficult to grasp the intricate details from such a representation.[6]

Another example we found was that of a visualization of the movement of players (random players) on the map for 10 000 games, whilst this shows something on the map and would be interesting for a player to see, it provides no meaningful statistics to an individual and shows too little information. Here is what it looks like, for interest sake:[3]

The next example shows something closer to what we were looking for. The heatmap shows regions where player deaths (when they are defeated by an opponent) occurred on the map and the amount (darker red) of deaths, as well as the time-span for these amounts[4]. While being closer to what we envisioned, the graphic still had no individual value, you may be able to see where you are likely to die, but not where you as an individual had been dying or what role you were playing. That coupled with the fact that the heatmap isn’t easy to read on the background (poor colour choice) and that it is in no way dynamic or interactive lead us to believe that this kind of visualisation could be done better.

So as you can see from the above examples something personal and graphic, as to the locations on the map where events had occurred for that player was required.

Visual Queries

The following visual queries are what we believe our visualisation support and allow users to make.


  • How many kills, deaths and assists were I involved in this game (or a group of selected games)?
  • What are my amount of kills and death for a particular game?
  • How much income do I make per game and how many creeps do I kill?

  • The interface does well to answer these questions and using visual cues it helps guide the users eyes to the appropriate section of information, through the use of colours and offsets in the interface representation.


  • Where did the kills events occur on the map during a specific match and at what times?
  • Where am I dying or killing most champions when I am playing a specific role.
  • What objectives (such as Dragon and Baron kills, etc. and at what times)?
  • How much times am I spending in which parts of the map?

  • Kills/deaths/assists:
    The amount of kills deaths and assists you get and where these events occur is the most important visual query as it is the direct indicator as to how well you are doing and in what areas these good or bad plays are happening. Addressing areas where you die a lot is an easy way to get better quickly.

    Objectives (Baron and Dragon):
    Knowing at what times these objectives are taken and by whom as well as the activity around the area of these objectives is extremely important as the buffs these monsters provide your team are key to victory and people tend to fight stupidly around these areas, addressing these silly fights and poor execution is a good call for any league player. The most important thing would be to know if you are doing well in the fights around the objectives or poorly (which can be shown by kills/deaths/assists around the pits)

    It is important to know where you are spending majority of your time on the map during a specific role, for example, if you are playing Jungle you may be ganking (trying to help your team) too much or too little and knowing these times spent in the areas of the map can really help your jungle clear times and overall play in the jungle. This is just one example from one role as to the importance of knowing where you spend your time.

    Gold is used to purchase items which make your champion stronger and itemizing properly is a key part to victory, one incorrect item choice can be the difference between a win and a loss, as such it is extremely important to know how much money you are making and how much of that money is coming through farming (creep kills).

    The map is the true form of the visualisation. It displays information of the matches dynamically by generating points to plot on the fly when a user clicks on the desired matches from the interface. The map uses an array of shapes with different colours to distinguish between key events in the matches. This allows a user to quickly and easily identify the respective event. We believe that the map is very effective at visualising the data that a player would want to see about his/her own matches.

    Design Iterations

    Our design followed a procedure of 3 iterations, involving refinement over each iteration. We had an extremely general principal to work with. We knew that we wanted a application to display the relevant statistics (kills, deaths, assists, ward placements and kills) and a map to display where they occurred. (Click the picture headings to display/hide them. They have icons next to them.)

    First Design

    The initial design was a very rough mock-up of the interface that we wanted to use to display the concept in order to decide whether it was worth going forward. The basic layout was decided here and this was kept throughout all the designs. The box on the right displays the list of player match history in separate boxes with a summary of their statistics for each respective game displayed in the boxes. The summary would be the most important information that a player needs to see about each match. These include:

  • Player Kills
  • Player Deaths
  • Gold Per Minute
  • Player Assists
  • The map on the left is used to show the kills and deaths of players based on the specific matches which data they would want to see of. This is added to the map when a box is clicked once and removed when the clicked box is clicked again. The map features a time slider that would allow events during specific times to be shows, for closer inspection.

    Various checkboxes will allow matches that are displayed to be filtered by specific requirements.

    • Main View

    When the map is selected, the background is faded out and an expanded map with much more detail is shown in full, to allow a person to really take in the information surrounding the activities and events that took place on the map for the games that are selected.

    • Extended Map View

    Second Design

    We started getting really excited about our design and though about what we could do to assist visual queries. Firstly, we added a most obvious feature which would be to search for a player to get that player's data. The design for this page was simple and the combination of the colours and text allow aid in helping people easily understand how to use it.

    • Search Screen

    The main interface was given a major overhaul. Since this is the screen with the most information, we needed to use good practices to allow people to easily satisfy visual queries. Each box on the right represents an individual match, as mentioned before. For the status of a won or lost game, a differentiation of typical green and red colours for each respective box is used. The player champion icon is displayed to allow players to better remember prior matches and information was laid out in a cleaner, better way.

    The biggest change was the introduction of texture to allow differentiation of matches that are selected and that are currently supplying information to the map or not. When the box is selected, a diagonal texture is used to distinguish it.

    • Main Interface

    The idea of the focused map is improved on the second iterations and here we decided to add filtering rules to the map, as well as move the time slider from the main interface to here. It makes more sense to have the time slider in the setting that is larger, where more information can be seen and understood.

    Filters were also added, giving additional flexibility to have more match specific features or events turned on or off, as opposed to just having the match history affected. During this design phase we found that the API Riot provides developers in order to access these statistics had some limitation in terms of the data that we could pull. We initially planned on having ward placements and kills in the visualisation with specific timings, because they can provide players with very insightful information, but unfortunately the geo-data on these are not provided as we had originally believed.

    • Extended Map View

    We received a lot of positive criticism on this design when we presented it to our class for evaluation. Some of the suggested changed seemed to have less to do with the visualisation and more to do with adding additional features. Video games are a popular topic. :D

    We did get useful feedback on the visual aspects, though. This included the ability to add more than one player to compare, the making items appear in the timeline, toggling between multiple selected games and a single one, using non-distracting texture and colour on the map, etc. These were well considered and implemented for the final design.

    This being said, there were some features/ design changes that we decided not to implement due to restrictions in time and complexity. These features, such as comparing players will be considered for future designs when it is more feasible to implement them.

    Third Design

    This design stage actually went through many fine changes and decisions as we decided to add and remove things where we felt it necessary.

    The search interface had a big change. We redesigned it to be more welcoming to players of League of Legends and also fixed one big flaw that we had forgotten about: choosing which region a player plays in. We made some usability changes like preventing a player from submitting a blank name and also animating the search button to indicate that the application is polling the API and generating the statistics.

    • Search Screen

    We took the critique from our peers seriously and decided to redraw the map provided by Riot for use with their API[5] (the design 2 map). Tracing it from scratch and using scalable vector graphics, this not only allowed us to dull the colours and make it much more appropriate for placing images on top of it, but also for resizing it without quality loss. We utilized colour shifts and texture to indicate water, jungle and etc.

    • Main Interface

    Our final implementation of the map, populated with the user data utilizes a scatter plot like approach across the map instead of a heatmap, for more readability. We believe that this combined with the colour code as well as shapes to represent the different fields, marked by the key at the top provides the user with the clearest version of the data they are seeking (from this they can easily query where they are dying the most, killing the most etc). Textures and colours are also used to indicate the “Jungle” region as well as the “River” and are done so in such a manner as to not occlude any data or overly clutter the map in any way. If you hover above the individual points more detailed information about the event is available such as the time the event occurred and the exact coordinate of the event. We chose a dark blue for kills as it can be seen as a positive colour (a lime green was an option but didn’t read well in the jungle regions) and bright red for the deaths as it appeared most negative and would invoke the sense of a bad occurrence off the bat. A fuscia colour being chosen for assists came as it was a sort of intermediary colour, whilst being positive is still not as advantageous as kills. Even at high volumes of data, we believe this implementation holds its value and provides the user with meaningful data.

    The Dragon overlay will display the events (kills/deaths/assists) around a particular area around dragon pit (same principle for Baron) for a certain period of time and will show the dragon key in colour if the dragon went to your team and greyed if it went to the opposition and will grey all the other data selected. As such, players can get an idea of how well or poorly they are making decisions around important objectives.

    • Extended Map View
    • Extended Map View (Dragon overlay)

    Strengths and Weaknesses

    Firstly we believe that our visualization provides the user with a lot of information regarding their individual play and how the play with each role, where they are doing well, or poorly and helps overall to better their game. Secondly with the ability to compare to their other roles and other people they can really get down to what they should be doing with what role. With our visualization we believe that the user can get a real feel for their match history rather than seeing what they already know from the post game statistics (kills, deaths etc) by putting into context of the map itself as well as putting it into context with other players. The one weakness is that with large amounts of data the map becomes cluttered and occlusion can occur and we needed to find a way around this.

    So we decided that with checkboxes which could turn data on and off and only displaying the data for the specified time we could minimize noise on the map and give the user the data they wanted to see. Coupled with a good colour scheme for the points we believe our visualization overcame the clutter and provide a meaningful portrayal of the data.

    As far as difficulties during the project, we found that pulling data from the API was extremely effective but we needed to sift through the data and decode it quite a bit before it became useful and this took some time and effort. This combined with finding a way to effectively display this large quantity of data in a small area whilst maintaining as much meaning as possible was quite the challenge.


    We believe that through our efforts after receiving feedback on the second iteration we have addressed most of the key points that have been brought up about the various aspects of the application. The design has benefited tremendously.

    As much as we believe that our visualization has a lot of potential to be a meaningful source of information and statistics for all players looking to get better at the game or just see how they are doing in general, there is always room for improvement. In the future a potential switch to a heat map type structure for heavily cluttered map could provide promising results. We also believe there is a place for this visualization on a forum such as LoLKing or somewhere of the sort considering that we, as avid League players see a definite benefit from a Visualization such as this.

    Team Work

    Teamwork was divided up among the 3 members of the group in the following manners:

    Name Tasks Assigned
    Calvin Mills Report and concept design
    Eugene de Beste Implementation of idea and design of app/report
    Mark Grivainis Design and code support

    Overall, the team worked well together. Perhaps not enough effort was put in when there was time and some did more conceptual design than implementation and vice versa, but the team worked well with a good range of creativity and effort.