General Architecture

Each card has its own small Python script associated with it. We’re able to call Python from C# and pass along C# object references. 

We also have markup in the C# code, and a separate script that generates fake Python that we use for autocomplete when the Python script writers deal with these alien C# objects. Without this bit, they wouldn't know what methods they were allowed to call on the C# objects without reading the code directly.

Finally, we wrote a plugin for Visual Studio Code that gives designers direct access to available methods. This gives them handy references for stuff like game events they might want to reference, and quick access to all other script files.

Within each card script, designers call out events they’re interested in. For example, if a card needs to make you draw a card whenever anyone takes damage, then you can have the script listen for when damage is dealt and add modifiers. 

This is a very simple 2-line script file:

## EventDoDamage

game.Draw()

Note that “game” here is a reference to our C# game state that was passed to Python.

Everything Is A Minion On Cards

A foundational aspect of our scripting system is how we handle card storage. Designers store everything on cards - kind of like that joke about how everything in League is a minion, everything in LoR is stored on cards. For example, the Nexus is actually a card, and it stores the history tracking we mentioned earlier. When a unit is played, the Nexus has a script that listens and increments the count on its own storage, and those values can be referenced by other cards.  

You’re saying those tiny things store WHAT?

This is a hugely critical piece of how LoR stores data. Designers can synthesize entirely new gameplay mechanics without requiring engineers to build anything new, because they can trigger off of any change in the game state, store any value in card storage, and have access to all of the basic blocks of game state manipulation that engineers do (moveCard, doDamage, attachScript, etc).

Story Time: Making the Transition 

Switching an underlying game system is a massive undertaking. Our new scripting system definitely lived up to our expectations, but the transition had a couple bumps along the way. 

One story that really demonstrates the complexity of shifting an underlying system happened around three years ago during a big internal playtest. We had just wrapped up getting a build of the game working with Python, but those code paths were only taken when there were actually Python scripts to load. This was done so that it wouldn’t impact the playtest, which was still running on the original League block system. We kicked off a deploy of the block script build, and walked over to visit the playtest presentation in person, confident that the build was stable and the Python-based system was separate on our testing environments. 

Imagine this - the presentation wraps up, right, and a crowd of Rioters are heading back to their desks to play, when someone says, “hey, uh… everything is broken.” Total nightmare material. This made no sense, because nobody had actually made any changes - we had just done a rebuild and redeploy of existing content we had tested already.

So what happened? 

We have a set number of shared build nodes that we reuse, and try to only clean up what’s strictly necessary to avoid copying over duplicate assets every time. The Python builds had been running on a couple of them because we were iterating earlier, but once the Python build had run on the node, it effectively infected it, leaving the Python scripts behind. The block script-based rebuild/redeploy we did for the playtest happened to run on the nodes that had been polluted by the Python build. So some of the cards were loading Python scripts, and some of the cards were loading block scripts, and some did both so nothing would happen. 

Once we remoted in and realized there was both Python and block data, it just took a few hours to patch up and the playtest went on. But it was definitely a spooky event that demonstrated the complexity involved when transitioning over an underlying system in a live game. 

Our biggest takeaway? While it can be an elegant solution to use the existence of new data to control which system is activated, sometimes just having a good ol’ toggle is an important safeguard when replacing a legacy system. 

Taking a Look at Teemo

Teemo and his related Puffcap mushroom cards presented complex technical challenges that really highlighted the impact of our new scripting system. 

This set of cards is based on a gameplay system that exists almost entirely in our Python scripting environment. Designers are able to quickly iterate on these kinds of ideas - like Puffcaps being objects placed on existing cards instead of individual cards placed in a deck. We built up a Python library of Puffcap functions which defined a really clear API for how cards could plant mushrooms into an opponent’s deck. The Puffcap’s representation in the game, how to add them, and what they do are all defined within the Python scripting system.

Iterating on Shrooms

We had a couple Puffcap iterations as Teemo’s shrooms became cooler and cooler over time. As we moved from spells in our block system to spells in Python, designers were increasingly able to resolve bugs themselves instead of requiring engineering time. 

The Puffcap cards were originally planted in your deck by Teemo or his followers, and when you drew the cards, they’d cast a spell and you’d take damage. The Teemo level 2 card doubles the number of existing Puffcaps in a deck - which is simultaneously very exciting and very dangerous - so the Puffcap cards had the ability to crash entire games if enough were placed into a deck. With the new Python scripting language, we were able to port over the Puffcap system smoothly and simultaneously do some code cleanup, making it possible to switch the Puffcaps from individual cards to traps on existing cards.