March 27, 2025  |  Written by Tyler Parrott

While we didn’t start working on Jump to Lightspeed until late 2022, the seeds for its design were already planted during the initial design of the game line. The first three sets, we knew, had to be dedicated to building the foundations of the player experience, introducing core mechanics and play patterns while staying fairly simple and accessible. But we had some big ideas we wanted to explore, ideas so big they’d require their own dedicated expansion.

This is where Year 2 would come in: take the foundations laid by Year 1 and develop them in focused, exciting ways. The mechanical themes of Jump to Lightspeed and Legends of the Force arose from mechanics originally created during the Spark of Rebellion design process, each a top-down (theme-first) mechanic intended to emulate a certain iconic element of Star Wars™. For Jump to Lightspeed, that was pilots. We immediately put it down as a mechanic we wanted to explore, and the dilemma presented by Wedge Antilles (Star of the Rebellion) meant that we wanted to get to it sooner rather than later.

Wedge in Spark of Rebellion was a bit of a conundrum. We knew we wanted him in the set; he’s an important supporting character in the original trilogy, and his prominence in the Legends expanded universe meant he had a passionate collection of fans. But we didn’t know how we were going to mechanically represent piloting in the game yet beyond general strokes. Were our pilots going to be units or upgrades? Would there be a pilot keyword, or just a Pilot trait for cards to reference? Would we make one recurring mechanic to represent pilots, or multiple different mechanics that reinterpreted the concept in different ways across multiple sets? These were all questions we were unable to answer with the time available to us, especially when it would only matter for one card.

With so much uncertainty surrounding Wedge, and knowing that it would only be a matter of time before we encountered other pilots we wanted to make cards for, we decided to make figuring out our first pilot mechanic a priority. That meant making a whole set for it, so we could have the maximum amount of “complexity budget” available to us while also giving us a whole set’s development cycle to explore possible designs.

Navigating Possibilities

Going into the design of the piloting mechanic, we knew we had to fulfill two important (and often contradictory) goals. One, the mechanic had to make a pilot card feel like a pilot—it had to represent a character (with that character’s name in the title bar) that would in some way upgrade a Vehicle unit’s capabilities (probably by attaching to it). Two, it had to be simple to understand and accessible to play with. Accessibility is one of the core tenets of Star Wars: Unlimited, and an important way for the game to be accessible to a newer or more casual audience is by staying simple. So, while there were a lot of ways to make a mechanic that simulated a pilot flying a starship, we had to do it in a way that we could easily write on a card and that wouldn’t result in a lot of rules questions when pilots interacted with other card abilities.

We considered a lot of mechanical possibilities for how to execute on the idea of representing a pilot. The simplest option was that pilots were just upgrades—like any other upgrade, but only playable onto Vehicle units. But most people didn’t like the fact that making a character into an upgrade deemphasized their autonomy, so we quickly moved off of it. Then, there was the idea that a pilot unit already in play could “jump into” (attach to) a Vehicle, but that introduced a lot of sequencing challenges that mostly didn’t result in fun gameplay.

The most obvious solution, of course, was to make pilot cards function as two-in-one cards: either they could be played from your hand as a unit, in which case they operated as a unit, or they could be played as an upgrade, in which case they attached to a Vehicle unit and operated as an upgrade. This was, conveniently, how some previous Star Wars card games had handled pilots, and it was extremely intuitive. However, every version we tested had some dilemma that we had to resolve.

The first dilemma was one of vulnerability: if a pilot was played as an upgrade, it would be vulnerable to all of the upgrade removal that we had designed in the first three expansions. Why would a player play an expensive pilot on their Vehicle only for it to get defeated by a 1-cost event like Confiscate? One possible solution was to make them not have the upgrade card type, and we actually considered making a new Pilot card type to make them immune to upgrade removal while also helping to carry some of the mechanic’s rules.

The second dilemma was one of complexity: how were we going to communicate which abilities were granted to the attached Vehicle? One option was to grant all abilities, but that cut out desirable design space and was challenging to fit into reminder text. Another option was to write out “Attached unit gains…” but that would double the amount of text on units who wanted to have an ability while they were a unit.

The third dilemma was one of power: would pilots grant additional stats to their attached ships at all? Stats are such an important element of what makes a card strong, and if pilots couldn’t grant additional stats, it would be difficult to justify playing them at all. If they did grant stats, what stats would they grant and how would they communicate it? We could make them grant their printed stats, but that would result in some extremely powerful upgrades that would end the game very fast if left unanswered and result in a blowout if they were answered.

The fourth dilemma was one of theme: many of the most iconic ships in Star Wars can only be flown by a single pilot. Could we have a one-pilot-per-ship limit? If so, what about the larger transports and capital ships that did have multiple pilots?

What we ended up going with was a compromise between all of these. Making a new card type was generating a lot of nonintuitive complexity without sufficiently solving our concerns, even though it made the text on the cards much cleaner. We elected to make the Piloting cost different from the unit cost so that we could have Pilot units appear all along the cost curve, but we could limit the board impact of their pilot mode (also keeping down the cost, and therefore risk, of the upgrade). We wrote out the full necessary text to make each pilot function as an upgrade so that the card’s text would work without needing to add any additional arbitrary rules. In many cases, this limited our opportunities to give abilities to pilots’ unit versions, but since we wanted pilots’ primary use case to be as upgrades, we were willing to make that sacrifice.

We quickly found that some kind of graphic design treatment would be necessary to help players parse which abilities were relevant when the card was a unit and which were relevant when the card was an upgrade, and so we overlaid elements from the upgrade card frame to provide a clear reminder that the card was an upgrade while attached. This conveniently gave us the opportunity to have upgrade stat modifiers on the cards, which we could make distinct from the unit’s stats and therefore better modulate the card’s balance. We ultimately balanced both halves of each Pilot independently, with the understanding that we wanted the Pilot upgrades to be the cards’ primary use case and the unit to be a backup plan. And because the cards were so flexible, we had to ensure that neither half was entirely comparable to a normal card on its own. The flexibility of being able to decide during a game which version of the card you’re going to use is an important but mostly invisible advantage that we had to compensate for.

When it came to the “1 Pilot per Vehicle” limit, we found that trying to hard-code it into the rules was a nightmare for comprehension (how would anyone even know the rule existed?) but a huge boon to gameplay. Limiting each ship to having only one Pilot upgrade by default meant that we could make the pilots stronger and more exciting, and it also meant that choosing which pilot to put on a given ship mattered in a meaningful way. The solution was to apply the “limit” when playing (or deploying) a Pilot onto a Vehicle unit. Limiting the pilot while it was entering play resulted in all of the same interesting game decisions, but didn’t add new rules infrastructure to the game that players would need to learn for an extremely narrow possible game state. Therefore, if you can find a way to use a card ability to attach or move a Pilot onto an already-piloted Vehicle, then congratulations! You found a way to avoid the “1 Pilot per Vehicle” limit. Enjoy your creativity and take down your opponent with a very large spaceship.

Epic Space Battles

While the design of the set began with pilots—and figuring out how they would work was the initial goal of the set’s design—it was too complex to be the set’s primary mechanic. Additionally, it required a certain set infrastructure to even work well in draft, and that informed what quickly became the set’s primary identity: epic space battles!

Since most of the Star Wars narrative revolves around its characters, we knew that most of the game’s units would be ground units and therefore most of the combat would occur in the ground arena. We quickly concluded that a 3:1 ground-to-space ratio would be ideal for a normal set’s construction, and we also made an intentional decision to make the ground units slightly stronger than the space units. Since the space arena would be less populated than the ground arena, and therefore units in that arena would be less at risk, we wanted to make sure that they weren’t as efficient and players still felt rewarded for playing the characters they wanted.

Once we had established those norms during the first year, we knew that one extremely easy way to create a unique game experience for the fourth set would be to simply change the ratios. So instead of being 25% space units, Jump to Lightspeed is 50% space units! This alone gives the set a strong “space battles” identity. The fact that all of the token units are space units—and many of the ground units are also pilots—means that, in practice, actually more than 50% of the conflict occurs in the space arena. This makes Jump to Lightspeed play in a fundamentally different way than all of the sets around it and lets the fans of Star Wars’s vast collection of cool spaceships lean into a favorite part of the franchise.

Where Else Can We Go?

As we transitioned into working on the sets of Year 2, we quickly found that (as expected) we would not be able to work on expansions the way we had worked on Spark of Rebellion and Shadows of the Galaxy, which were co-designed and co-developed by me, Danny Schaefer, and Jeremy Zwirn. So, with Jump to Lightspeed design beginning while Shadows of the Galaxy’s development was wrapping up, we began distributing the work between the three of us. I inherited the bulk of the design identity of Twilight of the Republic, which I was most passionate about, and Jeremy inherited the design identity of Jump to Lightspeed, while Danny helped new team members get on board and design the Twin Suns format. 

With a set themed around space battles, featuring a new (but incomplete) “Piloting” mechanic that we knew would headline the set, Jeremy led an R&D period to explore other mechanical designs that he had a passion for, and which felt like they could fit into the set. The first was a new mechanic that he’d been ideating on since we developed the game’s core mechanics, while the second was a mechanic he’d designed for Star Wars: Destiny that we had already started exploring in Shadows of the Galaxy.

The first mechanic, called “Mobile,” came from the set’s space battles identity. This game has two arenas, and the theme and our designs thus far had treated them as mutually exclusive. But what if they weren’t? What if you got to choose which arena you played your unit into? Thus, the first draft of the set included a keyword that allowed a space unit to be played to the ground arena. (It didn’t make sense for a ground unit to be played into space, but a TIE Fighter or an X-wing could pretty easily be justified fighting in a ground combat as aerial support.)

Mobile offered some extremely fun gameplay, but it was also a lot to comprehend strategically. Each card in a player’s hand already has an alternate use—it can be played or put down as a resource—and this keyword now added a third mode. On its own, that might have been fine (after all, having options is fun for many players), but combined with Piloting, which was also a “two-in-one” mechanic in the set, it meant that players were regularly looking at a hand of cards where almost every card could be played in three different ways, and the interaction between the two meant that each pilot actually had a secret fourth mode (resource, ground unit, upgrade on a space unit, upgrade on a ground unit). The strategic complexity quickly became paralyzing for even experienced players, which wasn’t a great sign for a game designed to be accessible. It also had some thematic baggage, because the two arenas are not scaled the same. If a TIE Fighter is roughly a 1/1 or a 2/1 in space, but that TIE Fighter was played into the ground arena, then it could be taken out by a Battle Droid…and that felt extremely off, thematically. Between the strategic complexity and the thematic baggage, we felt it was better to shelve the mechanic for a future set where it could have more space (pun intended) to work with.

The second mechanic, indirect damage, obviously did make it into Jump to Lightspeed. Having played with it in Star Wars: Destiny, we knew it would make for fun decision points for both players while being generic enough as to fit into almost any set. What we learned during the development of Jump to Lightspeed is that when both players are actively jockeying for an advantage in the base HP race, dealing indirect damage resulted in some very challenging and interesting decision points. This meant that its best home was going to be in draft, not Premiere, and so we developed it primarily for that format.

A big part of making indirect damage work within the set’s infrastructure was to add synergy pieces, such as more incidental damage effects (like Twin Laser Turret) and more rewards for enemy units being damaged (like AT-DP Occupier). The mechanic was most fun when the decision of where to place indirect damage was difficult, so we wanted to make it as contextual as possible with card abilities and a variety of unit stats. Additionally, the interaction with Shield tokens (where a Shield could absorb a lot of indirect damage with no penalty) meant that we had to make the damage unpreventable or else the mechanic just wouldn’t work in a fun way.

Swarms in Space

After introducing unit tokens in Twilight of the Republic, we were eager to make more of them, especially for iconic elements of Star Wars. Thus, X-wing and TIE Fighter tokens were in the set from the beginning. This also allowed the set to have a slightly louder presence in the space arena and would make it play very differently from the set immediately before it, even though the theme also dictated 1/1 villainous TIEs and 2/2 heroic X-wings.

However, unlike the Battle Droids and Clone Troopers before it, TIE Fighters and X-wings are a prominent element of multiple eras and appear in multiple factions. We couldn’t very well say that a generic TIE Fighter belonged to the Galactic Empire but not the First Order, for instance, and having cards of both factions in the set was important for the set’s thematic makeup (this set features the sequel trilogy factions more prominently than in previous sets). Therefore, we elected to embrace the genericness of these spaceships: if anyone could conceivably fly an X-wing, then the generic X-wing token should be factionless.

But, as you’d know from looking at the set, TIE Fighters and X-wings are only half of the story. We made a big fanfare about not including Experience or Shield tokens in Twilight of the Republic, as a means of exploring new design space and limiting complexity. By the time we got to Jump to Lightspeed, there was some desire among the design team to push the boundary in the opposite direction.

Could we make a set that used four different tokens? It would certainly change how we printed them, a fairly simple logistical challenge but one that had to be answered. It would also increase the barrier to entry to the set for new audiences, as it would make them half as likely to have the requisite tokens if they were playing casual constructed or draft with their friends. However, it would give players access to new, space-themed Experience and Shield tokens to better personalize the visuals of their play experience (I love reimagining tokens for a new set), and Experience and Shields would already be quite available in public play spaces. Ultimately, we knew that this wasn’t something we’d be doing in every set going forward, but it would be valuable to experiment with putting lots of different tokens in a set. Therefore, we moved forward with all four tokens in Jump to Lightspeed to see where the design space was worth it, and to eventually see what the audience thinks about it.

There’s a lot going on in Jump to Lightspeed, and we’re really excited to see many of the Year 1 heuristics change with the refocus on the space arena for the first time. Getting to design and play with pilots has been surprisingly fun, so I’m looking forward to hearing what the audience thinks of them!

May you feel inspired to try something new!