Creating An Immersive Experience in League of Legends

The content described here in absolutely no way previews, hints, nor in any way whatsoever represents any development going on at any of my past employers' studios.  This is an original direction and vision for lore and game IP that is based only on my experience as a video game player; it is not based on any specific content or methods of development experienced at any studio.

One of the reasons I've been a League of Legends fan since the beta was to see how the game realized or failed the potential I saw in it.  The game, like many others, offers a fantastic opportunity for lore, story-telling, and immersion in the multiplayer space.

Since I'm not currently working for its developer or any competitors, I can finally write this out for fellow lore dorks dissatisfied with the video game industry's trend of story-telling.

A Game's Lore Framework

Because I get paid to do engineering and not writing, I've come to call this a "framework".  A lore framework is the space within which stories and events must be told to make sense of or contribute to the overall purpose or functioning of the universe.  This overall functioning is usually based on a creative director's vision or by the successful past works in the universe.

A story about how an orc and a human got along
despite a game where orcs were at war against humans.

In WarCraft III, a common lore element is redemption.  Redemption and internal conflict are a part of the most notable plots and characters in the WarCraft lore framework.  A harmony with the framework exists in WarCraft III when Thrall the orc makes nice with Jaina Proudmoore the human daughter of a naval fleet commander, despite their pasts, for a greater good.  A conflict with the framework exists in World of Warcraft when the player can in no way support nor interact with the opposite faction, because this flies directly against the elements of redemption and internal conflict.

Can I be like Thrall and Jaina
or does that quest bang mean "no"?

The League of Legends Lore Framework

A very interesting (and awesome) lore opportunity arises with the DotA-based game.  On launch day, there are no known actors.  There is no universe; there is a map.  The lore is haphazard and champion-based, with the world map only being relevant because it represents a champion's origins. With a few retcons to rectify some haphazard origins, this trend would pave a path that the game continues down -- to its 100th champion Jayce -- today.

Let's look at a successful, practical parallel to give us some perspective.

A Similar Lore Framework's Results

Monopoly is a multiplayer game with a single board.  Based on chance, players move to points of interest that provide opportunities or immediate consequences for their money.  The player with the most money is considered to be winning.

No one knows what Baltic Avenue is, what it looks like, or its history.  As people play, however, they naturally infer that it is something like a poor residential area or slum compared to Park Place and a personal connection to the landscape is formed based on nothing other than the gameplay.  Go ahead and bet on Baltic Avenue's history not being in the manual; even if it were, what would that matter?   Few people read the manual anyway -- much like mainstream players do not read game-external publications that are sometimes in no way relevant to its game and, more a fault of the system than of the authors, eventually are deemed non-successes by executives or senior management.

Thanks to the accessible and natural immersion of the player in the game mechanics, consumers that play Monopoly might immediately understand "That's the Boardwalk of Los Angeles" or "Don't go too fast, you'll go to jail.".  Furthermore, this identifies the consumer as a fellow player of what might be considered a subculture, reinforcing something of a community for the product.  Finally, there is a positive regard for fellow consumers of Monopoly simply due to its sheer popularity: if you don't get those references, you might be considered uncultured!

This is where you live, right? 
Just under here, Mr. I've-Never-Heard-of-Monopoly?

Thanks to that same immersion, developers of games easily draw connections between the original Monopoly landscape and that of any other world -- all by just honoring the lore framework established by the game's mechanics.

It's to the point that you could probably come up with a Monopoly variation right now.  Is there one for Pokemon, My Little Pony, or tech companies?  If you understand your own universe well enough, chances are that one indeed exists right now -- in your head, at least.

Analysis of the Gameplay Basis

For the sake of brevity, this segment has been posted to its own entry.

A Summoner-Based Lore Framework

Riot Games deserves a shout out for something it's done since its early days.

In pretty much every single forum post, their employees address their users as "summoners".  By doing this, users become attached to the role they play in the game and are unified regardless of currencies or tenure.

I don't care what team I'm on;
in my head
my robes are dark red.

Sadly, that's where this attachment ends.

Let's take advantage of that opportunity (how many game companies before Riot referred to their users as their in-game equivalents?) to further strengthen the role of summoners in the League of Legends IP.  As we roll out the lore framework for the game, summoners will be the main focus.  As a bit of a (common sense) bonus, this focus also embraces the Riot Games mission statement.

- A "Summoner" is an individual that summons champions. [Gameplay equivalent of user]
- Summoners rarely, if ever, take part in combat themselves. [Gameplay]
- Summoners mostly, if not always, interact with champions through summoning. [Gameplay, UX]
- A huge population of summoners exists. [Technical, Gameplay, UX]
- A huge number of matches exist. [Technical, UX]
- Champions have strong relationships with or against city-states in the game world, Valoran. [Gameplay]
- Champions have strong personalities conveyed through splash art, voice-overs, and in-game visual presence (animations, models, etc.). [Gameplay]
- Summoners summon champions at the The Institute of War. [Pre-existing Lore]
- The Institute of War was created to moderate war in the interest of environmental stability. [Pre-existing Lore]

Actionable Ideas from Our Lore Framework

With our understanding of our lore framework, even laying out those few elements may inspire some ideas.  It's time to meet with our team and discuss feasible possibilities, then make one of them a reality.

A Guiding Element from the Lore Framework

After sharing and explaining your list of elements with the team, you hit up the whiteboard and scrawl the conclusion that is going to guide them in satisfying the common lore dork like you.

 

In the League of Legends, you will immerse your players by having champion selections affect the in-game world.  You ask your engineering gal to get data on champion usage over the last week or two, look at who was the most popular and most victorious champion, and tell your artist what their city-state is all about.

Implementation

1. On the Sunday night of every two weeks, get champion usage data from the last two weeks, ranked from most used to least used.  Iterate toward multiple factors and observe what happens, but we can simply start off with the following.
- champion name
- percentage/number for selection of that champion
- percentage/number of wins on that champion
- percentage/number of losses on that champion

2. On Monday, go over the numbers with your team and decide which city-state and their champion can be considered "most victorious" over that time period.  Reasons can be arbitrary, but document them; you'll be sharing those reasons with summoners as a record-keeper of the Institute of War's history.  Also document that victorious city-state; this is the beginning of the known history of the League of Legends.

3. After deciding which city-state is "most victorious", complete 2-week development on the following.  At the minimum, have an artist do the first.  Iterate to see what people actually respond to and use, and discontinue any features or methods that have diminishing returns.
- [1 junior-mid artist, 1-2 weeks] A summoner icon representing that most victorious city-state.
- [Agreement from Marketing and Design, 1 Engineer] Change of price of champions from that most victorious city-state to the maximum in the range (6300 IP at this time), and change of price of champions from least-victorious city-states to minimum in the range.
- [Web developers, 1 Community resource or Writer] A website containing the most victorious city states over time, the most victorious champion
- [1 Community resource or Writer] A forum post reporting the victorious city-state thanks to the summoners that supported their champions, explaining the criteria -- and whether or not they've changed -- as if from a record-keeper at the Institute of War.  Communication that the city-state will be rewarding the top summoners contributing to their glory; perhaps even a listing of those summoner names for notoriety.
- [1 Data Specialist and a Community resource or Writer] A list of the top X% of summoners that won with the city state champion -- the ones essentially responsible for the city-state's "victory" -- and an email to those summoners with a code for their city-state summoner icon.
- [?] City-state skin?  Forum avatar?  Voice-over that treats summoners with particular respect because of their contributions to the city-state? 

4.  At the end of the 2 weeks of development, deploy the summoner icon, send out the emails, post up the forum posts or website.

Maintenance, Measurement & Iteration

Congratulations!  You've used existing technology to create an immersive experience in the League of Legends universe!  That's the claim, anyway.  It's time to see whether or not your strategy is working.

Testing the Hypothesis

Among our leap-of-faith assumptions is that players want an immersive experience in League of Legends.  The advantage of starting small (with a single summoner icon, email, and forum post, for example) is an easily gauged answer within a matter of weeks. 

If that top percentage of summoners all redeem the codes emailed to them and set their summoner icons to that city-state icon, it is a strong indicator that they care about such tokens toward immersion.  If the forum consists of pages of posts from players wondering why they did not receive a summoner icon, it is a strong indicator that they care about such immersion.

If player match histories or the bi-weekly data numbers suddenly show a huge shift in champion selection that reflects city-state influence, you are well on the way to giving "Influence Points" and the "DEMACIA" battle call a whole lot more meaning.

The Future

Using the implementation above, the most important city-states will get summoner icon work that must only be done once per city-state.  Eventually, if all city-states are represented, all city-states will get summoner icon work done that does not require further investment.  The worst-case cost of this work is linearly proportional to the number of city-states that exist in the game.

Likewise, by exercising the strategy from this lore framework, champion developments are potentially funneled to the number of city-states as well.   Instead of future development scaling with the number of champions, costs are based on interactions with a summoner and based on the single city-state relationships of the champion being considered for development.

With the eventual completion of development for all city-states, summoners can start receiving their rewards directly after the period of judgment.  There's no more need to develop a Noxus icon three months in; it's already there.

Hand out the benefits to the elite % of summoners on the day of, or soon after, the judgment period.  Suddenly everyone's participation in the League of Legends becomes a conversation of champions, city-states, and lore -- all with the summoners at the root of those conclusions.

Measuring Up to Other Games

There's no reason games can't achieve the lowest common denominator.
(Comic from penny-arcade.com)

This is another entry in and of itself, but a good lore framework will provide elements to strengthen three major aspects of a game's universe.

- A macroscopic immersion in the game universe.
- A microscopic immersion in the game world.
- Story-telling and development around the character.

This implementation offers the player a macroscopic enjoyment by making each match (the microscopic experience) relevance throughout League of Legends history.  There is also a small-scoped impact in particular strategies, such as if IP prices change around summoner victories for a city-state.  Finally, the summoner gets to feel as if he or she is being rewarded for a devotion to a set of champions and a distinct sense of identity is formed that positively reinforces that identity and the identity of other summoners within League of Legends.

Conflicts

It is possible that selection of champions will be considered disruptive to game design.  The composition of teams may change, custom games may be started so summoners can select champions that earn a city-state's favor, or the already-existing behavior around champion selection might change in a way we don't foresee.

Good.

The Seven Deadly Risks

One of my favorite takeaways was from Tim Chang at GDC 2012's "Pitching Secrets Revealed" session. He enumerated the seven risks of a pitch -- things to cover if you want to look really good when pitching your idea. I loved this clean wrapping of general risks because the considerations of a pitch are -- or should be! -- the same considerations for rolling out actual development.

I mentioned these risks in a previous post when talking about how I chose which idea to go with for my first independent project. They're listed below with a bit of commentary.

1. Team

Have you considered who's going to actually implement your idea? There's a reason recruiting agencies exist -- good talent is hard to find. Thoroughly think through your idea such that you know what personnel can feasibly carry your idea across a finish line.

2. Execution

How is what you want actually done? Do you know how other, similar ideas were done and where they failed or had difficulties? This is a universal risk that, though unpredictable, benefits from proactive mitigation.

3. Technology

Does your game's engine exist? Who provides back-end services to handle your grand features?

If all your idea's required technologies don't exist, guess who has to build that! If they're all available and ready for your team, guess who has to hook them up to your product -- doubtlessly without any bugs whatsoever from those technologies, right?

4. Market Risk

That isometric facebook game probably sounded like a fantastic idea! You know your demographic and are going to be successful once you give that niche market what they want in six months. Oh, Farmville came out after your first month.

By the time your product ships, your users could care less about your product and more about clicking cows and super meatboys. Understand the trends of the space your product is in and whether or not that shift can be mitigated or predicted.

5. Regulatory

Especially when releasing abroad, a change in laws can really hinder your product. At GDC 2011, I met a Shanghai native that told me bones, skulls, and pandas were all present in some of his other games... but World of Warcraft has had to rework loading screens, models, and various other regulatory costs.

6. Competitive

Just because your idea is great doesn't mean someone else won't do it better and before you do.

7. Scalable Business Model

Your product has released and you are doing fantastic. Your investor is wondering: how is your business model going to scale such that your company doesn't topple over? Even if you haven't hit your wave of success, there are lots of great talks from GDC 2011 where small developers learn -- the hard way -- that going from 6 to 12 to 24 people brings about huge changes in culture and communication.

Overall, this was a fantastic panel to attend. I recommend watching the whole thing on the GDC Vault, especially if you are an independent developer. In my case, having a catchy "7 Deadly Risks" helped convey exactly what my considerations were for my first project -- and I'll formally be considering them in my larger, future project.

Building A Small, Independent Project

I have the opportunity to build something for a month or two, so here's a very high-level description of how I approached that.

1. Scope an idea to feasible size and requirements.
2. Evaluate technologies for implementing the idea.
3. Resolve barriers to implementation.
4. Implement idea.

Scoping an Idea to A Feasible Size, Enumerate Requirements

Everyone, including me, has lots of ideas. If caution isn't exercised, one could iterate forever on those ideas.

Here are the ideas that I went through for examples of how they didn't end up as my project.

• "The game idea" that is in the back of my head, much like that one that's in the back of your head if you're the type to read this piece. Definite risks: team, execution, technology (engine, specifically), market, regulatory, competitive. Possible risks: scale of business model.
  
• A player-to-player feedback tool to evaluate a player in any game. Definite risks: execution, market, regulatory. Possible risks: competitive, scale of business model.
  
• A set of game design apps that distill popular implementations, exposing the simple game designs that lie underneath. Definite risks: execution, market, scale of business model.

In the end, it made sense to have a single instance of the third idea since that was most feasible and quick to implement. Feature sets are reduced to simply the main interactions between the software and the user, the back-end data storage (if any; this could be luxury), and a way to get some money to keep me going.

Discovering and Identifying Technologies

GDC 2012 was my opportunity to find out what technologies could be used for whatever idea I implemented. I'd like to note a specific question I was often asked that implied I had things backward.

"Danny, what game are you going to make?"

I hadn't concretely selected which idea I was going to implement. How do you know that a technology has not been developed that solves the largest, most difficult part of your most monstrous idea? To commit myself wholly to a specific idea -- and then set out to see how new technologies could be fitted to it -- made little sense and would have felt limiting.

As of this writing, I have no regrets with my chosen order. HTML5 was being pushed the most heavily; I see much prototyping potential and can appreciate its contrast against previous platform-limited technologies.

Removing Obstacles Between Potential and Action

The organizations at GDC were also useful for gauging how projects get started -- specifically, how startups are finding their first steps. I never even knew there was a way to simply ask for money if you could properly pitch a great idea.

Due to my current circumstances and my small-scale project, I do not need funding. Even if I did, I would say -- from what I saw at GDC -- that investment is currently nearing the end of its initial wild-hype stage. Investors know what they want from game pitches and even the newer player-driven organizations have gone through lessons in investing (I'm specifically thinking of http://indie-fund.com/ and their move away from open submissions). It still seems relatively easy to get funding, but not as easy as perhaps it was a year ago.

Doing this small-scale project is a great proving grounds, and -- if at all successful -- would make for a more confident impression on investors in my future, larger projects.

Action

Every week, I am holding myself to feature milestones and abiding by what I'm reading in The Lean Startup, which I've found refreshingly in line with my general disagreements in the industry. The focus is on feature and implementation delivery, not on deadlines or planning.

Here are my milestones as they stand.

• Decision on which technologies to use. Decision on project, scale, feature set, and market space for 1-month implementation and deployment. Week of 03-05 to 03-11, the week of GDC.

• Prototype of general behavior. Week of 03-12 to 03-18.
• Single, final implementation of general behavior. Prepare implementation for ship on markets. Hypothesis: friends will download and install the app. Week of 03-19 to 03-25.
• Validate hypothesis or course correct. Add menu, which offers image changing, payment option, and exit -- with some form of metrics for usage, frequency of selected options. Hypothesis: users will change the image, users will pay to help out the developer. Week of 03-26 to 04-01.
  
• Validate hypothesis or course correct. In menu options, add ability to change background sound and interaction sound, metrics. Hypothesis: users will change the sounds. Week of 04-02 to 04-08.

If this turns out well, I hope it leads to a humble startup. If this doesn't turn out well, then I'll at least have the experience of trying an independent project. That experience will only strengthen my skills in a future job and the product itself will show my chops are good enough for a gig.

What I also want to share is this experience, and its decisions, with anyone who is interested. I get questions about various game development practices and aspects -- such as Scrum methodology -- and this is a great chance to let people simply ask me about them. If that sounds like something you'd like to see in the world, feel free to support me on kickstarter. You can see what goes down without leaving your job or having to start your own projects/company!

If you're from my hometown, El Monte, or from another "poor" city, I'm especially interested in informing you. There's a lot out there that you simply will not see in our cities, that I would have never seen if not for the fantastic input from experienced individuals. It's my turn to pass knowledge on; my potential company will be the way I do so.