Seeking Feedback Re: Presentation on 2D Game Development in Unity

In a few weeks I’m going to be doing a presentation on 2D game implementation in Unity, and I’d like to run my plans past you. Nothing here is set in stone, so feel free to suggest changes to any aspect you think ought to be different.

Currently my plan is to use checkers as the example game. I’ll put the game together, and make the assets (art, scripts, etc.) available prior to the event, so that people have them when they arrive. The presenter at a previous meeting did this, and it worked very well; most of the attendees downloaded the assets in advance, and having them already in place enabled everyone to hit the ground running.

The presentation itself will have three major areas:

  1. Setting up a 2D game board. This has a practical and a theoretical component. Practically, we’ll cover some basic things like getting sprites into the IDE and instantiating a board at runtime, along with some notes on areas where I’ve tripped up so that others can learn from my mistakes. 😉 From a theoretical perspective, we’ll discuss how Unity doesn’t have the notion of space-by-space movement, as is common in board games–and how work at this stage can enable one to set that up.
  1. Movement in 2D. Mostly practical, this will focus on Unity’s 2D physics tools and how they can be used to do things like check for open spaces and opposing pieces. I’m also planning a (very) brief discussion of other approaches, like using multidimensional arrays to track what’s in what location.
  1. Rules enforcement. Here the discussion becomes more theoretical, talking about different ways to do things like keep track of turn order. We’ll use the pre-made scripts as examples.

If you were attending this sort of presentation, would all three of those topics interest you? Does one of them interest you more, or less, than the others? Are there things I’m not planning to talk about that you think I should?

The Case Study: Without Further Ado

Here it is!

On the page for Over the Next Dune you’ll find links to versions of the game for PC (Windows 64-bit), Mac (universal), and the Unity web player.

The change log since Wednesday is brief:

– Problems with the “Attempt Rescue” button are fixed; it will now appear and disappear reliably in weird scenarios (e.g., an adventurer drags a searcher over another adventurer).

– “Quit” button implemented. (One doesn’t feel the lack of this within the IDE. Lesson learned!)

– A bug wherein the “End Turn” button wouldn’t appear when the last adventurer escapes while all other adventurers are captured has been fixed.

There are also some bugs I’m aware are still present:

– Terrain can extend beyond the bounds of the board. This has no gameplay effect, but is visually weird. Unfortunately fixes for this are, depending on who you ask, either quite involved or flatly unavailable.

– When three adventurers conduct two rescues simultaneously–that is, they rescue two different adventurers from two different searchers with a single press of “Attempt Rescue”–things don’t work right. I know where the problem is, and just need to get the time to solve it. Fortunately, this situation is very rare.

– The rules screen doesn’t look right in the Windows builds. It’s fine in the web player version. Not having a Mac myself, I don’t know what it looks like there. 😉

You’ll see that the game has gone through a name change. “Over the Next Dune” just wasn’t relevant to the new theme. I’m not satisfied with the new name–“Through the Jungle”–and am going to put some thought into a better one now that I’m not constantly thinking about other issues. 😉

Please feel free to leave feedback as a comment to this post, or by email at (the name of this blog, all as one word)@gmail.com. Please don’t leave comments anywhere else; if they’re in those two places I’m sure not to miss any, and it’ll always be clear what version a comment applies to.

At the moment I’m particularly curious about:

1. Difficulty. How often did you win, out of the games you played? Did you find the challenge too great, too low, or about right?

2. Theme. What do you think of the new traversing-a-deserted-island theme?

3. UI. Are the buttons big enough in play? Too big?

4. Bugs. If you encounter a bug that’s not listed above, please let me know!

The Case Study: Change Log

Following up on last time, the change log as I get ready for Friday:

1. The rules are now available through main game screen. (As I expected, this was a simple thing that took a long time. 😉 Unity’s UI system is definitely something I need to put a lot more practice into.)

2. There’s now a turn counter.

3. Searchers now correctly report locations for players to re-enter the game, even when overlapping with other searchers. (This turned out to be completely trivial, but I had to get a bunch of practice with Unity’s 2D physics engine before I could understand the problem and how to fix it. Here’s what happened:

The game needs to determine whether there’s anything in each of the 16 spaces around each searcher. It doesn’t matter what the thing is; if there’s anything in a space, that space is no good for re-entering.

In order to make that determination, the game used Physics2D.Linecast to send invisible lines from the center of the searcher to each of the 16 spaces. Each space got three lines: one that would respond if it hit a player, one if it hit a searcher, and one if it hit the edge of the board. If any of those lines reported that they’d hit something, that space gets marked as occupied.

Unfortunately, this system had a critical logic error. When searchers overlapped, the lines looking for searchers would hit something—the other searcher—instantly, as soon as they left their point of origin. The space would be marked occupied, but the line hadn’t actually gotten that far!

The fix was to send the line from the space to be checked to the space to be checked. Physics2D.Linecast, it turns out, allows one to have the same point as both the start and the destination; it will send a fractionally tiny line at that location, and if that line hits something it will report back normally. Using those fractionally tiny lines made it possible to check just the intended space. In the end, the entire fix was changing one word in one line of code:

hit = Physics2D.Linecast(start, surroundingSpaces[j], searcherLayer);

was changed to

hit = Physics2D.Linecast(surroundingSpaces[j], surroundingSpaces[j], searcherLayer); )

4. The rules now include players leaving trails in the sand, and the searchers following those trails.

5. Various smaller bug fixes, mostly relating to the UI.

So far so good; we’re on track for Friday!

The Case Study: Where We Are Now

By request, some screenshots. 🙂

4-27-15 - OtND Main Game Board

The main game board. One issue with Over the Next Dune in physical form was that it was difficult to manage searchers that overlapped each other; players had to lift and replace searchers to see where the arrows on the covered searcher(s) were pointing, always making sure that everyone got back where they belonged. The PC version easily fixes that by using see-through sprites that reveal arrows that would otherwise be hidden, as with the two searchers in the upper left. Transparency is expensive for board games, but it’s trivial on the computer.

4-27-15 - OtND In Play

An example of the game in play. One adventurer tried to go up the left side of the board, but left a trail (some of which can still be seen in the lower-left corner) and got caught by the highlighted searcher. It’s up to the remaining adventurers to mount a rescue.

The “main menu” button in the lower-right was inspired by a game fair where local designers are invited to demo their games. Players in that environment tend to wander from game to game, often leaving things unfinished. I wanted to make sure that players who come upon a game in progress are able to get back to start.

Actually, now that I think about it the rules should also be accessible from here; as I have the game set up now they can only be read by quitting the game and returning to the main menu. That shouldn’t be necessary.

One thing that’s missing here is a turn counter. I’ve been torn between wanting it to look nice, and wanting to hurry up and get that important feature implemented. Having a deadline should get me over that, one way or the other. 😉

4-27-15 - OtND Rules Screen

The rules screen. Again inspired by the game fair, I decided to boil the rules down as far as I possibly could so as to be within tolerances for someone who’s curious, but not yet invested. Detailed rules for those interested in the nuts and bolts of the game are to be available in a separate window.

Oddly, I’ve found that the rules screen works perfectly fine when I build for the Unity webplayer, but breaks when I build for Windows. That’s not going to be a fun bug to track down.

Nor is it the only bug:

– When searchers overlap the game sometimes incorrectly reports that there’s nowhere for a rescued adventurer to appear.
– UI buttons appear over the win and loss splash screens.
– Splash screens snap into view rather than fading in.
– And more. 😉

The Case Study: Alpha Version on May 1

Court deadlines impose a certain amount of discipline on a lawyer. It’s not possible to iterate forever; at X time on Y date, you must file. That limit forces attorneys to prioritize, to use their time wisely, and ultimately to make arguments and advance their clients’ causes.

I appreciate the value of iteration, but I also think the discipline created by deadlines–even self-imposed ones–is valuable. So: on Friday of next week, May 1, I’ll post the PC implementation of Over the Next Dune. It will be as bug-free and complete as I can make it in that time. Doubtless there will be more to do thereafter, from both technical and gameplay perspectives, but it’s time for the “feedback” part of the feedback loop to get underway in earnest.

If you’re looking to play the game early, the print-and-play version is available. I promise that the PC version looks . . . well, it at least has colors. 😉

Theory: Doing RPS Right

Rock-paper-scissors (“RPS”) dynamics are sometimes held up as fundamental to game design, a core principle that makes balance possible. Taking rock-paper-scissors too far, however, can lead to reductive games that are only interesting during character selection. It’s vital to understand that what’s interesting and valuable isn’t the RPS, but the interesting decisions a good RPS setup can contribute to.

The Story So Far

To my knowledge, the popularity of RPS comparisons in game design started with an article on Sirlin’s old website. It’s worth reading the article in full (and I’d love to see it preserved on the redesigned site), but his core argument went something like this: rock-paper-scissors, as we all played it as children, has little to no strategy because there’s no basis for preferring one move over another. The opponent is probably choosing more or less at random, so there’s no way to predict what he or she will do, and you’ll just have to play randomly, too. However, it’s possible to inject strategy into rock-paper-scissors by giving each move different payoffs; if rock is worth 2 points and everything else is worth 1, you know that both players want to play rock, and you can use that knowledge to craft a plan.

Sirlin followed up with another article, this one on how RPS is implemented in fighting games. Again, it’s excellent and well worth your time (and also worth preserving). While I can’t trace the spread of its ideas, I can say that this article was extremely influential among fighting game players, and that in the years since its publication I’ve seen its arguments and conclusions repeated many times. I think it’s fair to say that after this article, RPS was off and running.

Today, RPS has become ingrained in game design thinking. However, saying that RPS with differing payoffs can be interesting doesn’t mean that it’s always going to be executed correctly. In particular, it’s not great when the only meaningful RPS decision is made early.

RPS Done Right: Interesting Decisions that Support More Interesting Decisions

Go back to Sirlin’s second article for a moment. He describes a series of situations in which both players make a choice, and one of them just loses. Attack beats throw, period, with the attacker doing damage and the thrower accomplishing nothing. It’s a hard counter, just what we would expect from RPS: rock doesn’t sort of beat scissors, it SMASHES scissors and gets ALL THE POINTS.

However, that decision isn’t the be-all and end-all of the match. Rather, a match will involve many such choices. Indeed, much of the interest of the game comes from the choices building on each other: “last time he went for the throw and got me, I think he’ll try that again even though it doesn’t do as much damage as an attack.” Evaluating moves becomes a multi-layered process, as one judges not just their value in the abstract (rock is worth 2 points) but also how the opponent seems to be responding to those values (this opponent is being tricky by playing lots of paper).

We see the same building of decisions in other good RPS games. Starcraft, for example, has units that beat other units—but players build many units over the course of a game, and can expect to skirmish several times before the match is decided. As a result, players will make a number of important and engaging building decisions. Over the course of a game one might shift gears in response to what the opponent is building, feint, condition the opponent to expect one thing before building something else, and otherwise make interesting choices throughout the game’s duration.

Magic has only one RPS decision, but it still uses that choice as a springboard for more decisions later. It does this by incorporating RPS into an important, but not definitive, early choice.

It used to be said that there were three broad strategies in Magic, and that they interacted in RPS fashion:

Aggro (“aggression”) beat Control, because it won before control could lock down the game.

Control beat Combo, because control stopped combo from assembling its Rube Goldberg victory condition.

Combo beat Aggro, because aggro didn’t stop combo from assembling the Rube Goldberg machine.

While the model spoke in definitive terms, however, making the right choice at deck selection (e.g., playing aggro against someone who was playing control) never actually decided the game. Rather, it provided an advantage which had to be carried through in play. The player on the winning side of the RPS decision still had to manage random card draws and the opponent’s resistance, which could still be potent even coming from a position of disadvantage. Making a good RPS choice thus offered advantage but guaranteed nothing, and so the game’s in-play decisions remained meaningful.

RPS Done Wrong: One and Done

For a contrast to Starcraft, Magic, and other good RPS implementations, consider a fighting game where some characters beat other characters RPS-style. That might be balanced. If Ryu beats Zangief, Zangief beats Dhalsim, and Dhalsim beats Ryu, then everyone has about an equal chance of losing and the game is fair.

However, that game has only one important decision: which fighter to choose. It’s all downhill after that, as one plays out the inevitable result of the character select RPS. None of the decisions in the actual game are very interesting, because Ryu is just going to clobber Zangief no matter what their players do.

Weighted RPS mechanics, then, are not an inherent good. They can in fact be very dangerous, locking in results and turning the rest of the game into going through the motions. If RPS is going to be used, it’s critical that the game not hinge on a single, early RPS choice, but rather that the RPS decisions create further interesting decisions as the game goes on.

This problem is not strictly theoretical. Several miniatures wargames have wrestled, or are wrestling, with the problem of an early RPS choice that dominates the game.

Minis games’ RPS issues revolve around how in-game armies are built. Broadly speaking, minis games have a system wherein heavy armor (tanks, flying tanks, whatever the game’s setting has) is largely invulnerable to infantry; infantry is good at dealing with anti-armor specialists; and anti-armor specialists destroy heavy armor. As a result, games can be decided as soon as the players show each other their armies; if one player has way more tanks than the other player has anti-armor specialists, the tank player will pretty much have the run of the field. It’ll be particularly egregious because that game will probably still take two hours to finish; two hours is a long time to have no interesting decisions.

We’ve seen a number of solutions to this problem over the past decade: allowing pieces to serve in more than one role so that players can always use all three of rock, paper, and scissors, for example, or trying to opt out of the RPS situation entirely by flattening the differences between armor and infantry. I’m sure we’ll be seeing more in the future. Even if the problem is entirely solved, however, its persistence over many years will stand as a reminder that leaning on the RPS tripod can leave a designer flat on the floor.

Keep Your Eyes on the Prize

Rock-paper-scissors isn’t the ultimate in game design; it isn’t even a good summation. What it can be, if done right, is a source of fascinating choices for players. The key to using RPS well is to always keep focus on the decisions, asking whether the RPS is making them more interesting—or less relevant.

Something Completely Different: Context-Sensitive Fighting Game Controls

File this one under “projects for a 25th hour in the day” . . . .

Years ago I saw a really excellent post—I can’t remember whether it was on Shoryuken’s forums or elsewhere—regarding the challenges of learning fighting games. The poster argued that one of the major issues for new fighting game players is that the buttons aren’t labeled in a useful way; they have thematic names that don’t express what they should actually be used for. At the time it was difficult to resolve that in a satisfactory way, but it strikes me that this problem could definitely be addressed with current technology.

The concern goes like this: most fighting game characters have attacks that serve defined tactical purposes. By and large they will have a long-range strike that controls the opponent’s movement; a quick and unpredictable attack that probes for weaknesses in the opponent’s defenses; a slow but powerful smash that’s meant as the last move in combos. One of the major hurdles for players who are new to the genre is recognizing that the moves available have these specific uses.

Part of what raises that hurdle so high is that the various attack buttons aren’t labeled “control,” “probe for weakness,” and “smash.” They’re “medium kick,” “light kick,” and “heavy punch,” which sound thematic but don’t do anything to explain how they ought to be used. New players thus find themselves without the information necessary to make decisions about which attack to throw out, and are obliged either to button-mash or to figure it out on their own. Either way, it’s a substantial barrier to clear before they can start to get full value out of the game.

Moreover, the knowledge a new player gains from one character isn’t transferable to another. Millia controls with kick and probes for weaknesses with crouching kick; Ky controls with slash and probes for weaknesses with kick. Picking a new character means starting from about 50%; the new player (hopefully) knows that different moves have different applications, but has to figure out which move is for which use all over again.

When controllers just had whatever markings they had, and the labels needed to be appropriate for all characters, this was a very difficult problem to solve. However, today we can do context-sensitive controls. Imagine something like this:

The controller is a tablet or smartphone. Instead of being labeled light, medium, and heavy kick, buttons have descriptive labels appropriate to the character. Not only is there a button marked “control opponent’s movement,” it’s the correct button for that character. New players immediately see that each attack is for a specific purpose.

What’s more, the buttons change. If the opponent jumps, attacks that aren’t useful in that situation have their buttons greyed out—the attack will still work, but it’s clear that that’s a bad button to press right now. Attacks that are useful will stay their normal color and will get new labels, like “anti-air.” In single player mode, the game can be paused so that players can look down at the controller and find out what might be useful to do.

Fighting games are, I feel, one of the hardest genres to get into—but also one of the most rewarding. Context-sensitive control labeling would make it a lot easier to access both what a specific character can do and how new players should think about their moves generally. And it’s so doable now . . . if there’s time . . . .

The Case Study: Now with Rules Enforcement

I’m happy to report that as of today Over the Next Dune’s PC implementation is fully rules-enforced! Everything you can do in the board game you can do in the PC version, and everything you can’t do in the board game the PC version prevents.

As I coded the last rule (players leaving trails and searchers following them) I realized that one element of the rule wasn’t satisfactory: how searchers deal with encountering multiple trails at once. In the current board game searchers that encounter trails leading in different directions follow the center-most trail relative to the board as a whole. That works, but it’s arbitrary. Nothing about being in the middle of the board makes a trail more of a priority; if anything, following those trails might tend to keep searchers in the middle of the board, when the whole point of the trails was to draw the searchers toward players on the edges.

I’ve now changed the rule so that searchers prefer to follow trails that are closer to the players’ finish line. My thinking is that that will encourage the searchers to chase players closer to the goal, hopefully leading to some exciting photo finishes. It will also help keep the searchers relevant by encouraging them to move upward as the game goes on and the players start to occupy the upper portion of the board. A small change, then, but I expect it to be a beneficial one.

Coding a board game isn’t always easy, but I’ll say this for it: it forces me to look at each rule in isolation. When working on a game as a whole it can be hard to drill down and say “is this little part as good as it could be?” Having to program all those little parts creates opportunities to ask that question.

Theory: Maintain Theme from Beginning to End

The second edition of the Star Trek CCG (“2E”) hit on the brilliant approach of dividing its cards by the narratives they participated in rather than by in-character citizenship. Unfortunately, 2E then shoehorned those thematic factions into mechanics that often didn’t reward thematic play. Flat experiences often resulted, with each one a reminder that a game must follow through on its theme, from beginning to end.

2E’s great insight was that players should be “Deep Space Nine” players instead of “Federation” players. One benefit of that approach was that characters could be subdivided by show rather than by in-character rules; as a Deep Space Nine player one would have access to Deep Space Nine’s main cast without needing to worry about whether Captain Sisko, of the Federation, would work with Garak, a Cardassian. They worked together on the show, they ought to work together in the game, and now they clearly could. Divvying up characters in this fashion solved a lot of problems.

Approaching the game by show instead of by in-universe political affiliations also opened up a tremendous opportunity to reinforce the Star Trek theme: different factions could interact with the game’s mechanics in different ways, each appropriate to their respective stories. Overall the game would be a funnel design, with all players trying to be the first to score 100 points. How they got to that point, however, would depend in part on what the faction was about within the narrative.

Many of 2E’s cards reflect this effort to make the factions’ play look and feel like the stories they appeared in. The Next Generation, which emphasized building bridges with other cultures, gets cards that benefit the player while also extending a helping hand to the opponent. Deep Space Nine often had themes of frontier survival, and thus its cards allow players to protect their resources.

"Disadvantage into Advantage" is a classic Next Generation card that benefits both players; "Medical Teams" shows off the Deep Space Nine theme of seeking safety in dangerous places
“Disadvantage into Advantage” is a classic Next Generation card that benefits both players; “Medical Teams” shows off the Deep Space Nine theme of seeking safety in dangerous places.

Even when playing a faction ostensibly based on an in-universe political group rather than a show as a whole, the designers still import a great deal of story feel into the experience. Players taking on the role of the Dominion, a repressive civilization that served as a Deep Space Nine antagonist, have cards that slow the game down for everyone. Decks based on the hyper-mercantilistic Ferengi accumulate face-down cards as wealth, which they can then use to “buy” various advantages.

So far, so good. The factions were thematic, both in the people available to them and in what their cards do. If the mechanics kept pushing the theme, we might well be looking at the definitive Star Trek game.

Frustratingly, the mechanics didn’t.

Much of the fault can be laid at the feet of the scoring system. 2E is a race to 100 points. All of the themes have to work within that context—and some of them just don’t make sense there.

Take, for example, The Next Generation decks built around mutual understanding and helping others, expressed through cards that benefit both players. If those cards actually provided any significant assistance to the opponent, the race would probably be unwinnable for the Next Generation player. It’s hard to take first in a sprint when you keep turning around to give other runners a push, after all. Hence, what those cards usually do is provide a benefit that looks symmetrical, but which only the Next Generation player will be in a position to use. The “help” offered to the opponent is more like a booby-prize, and the theme of cooperation is undermined.

On the opposite side of the spectrum, playing the Dominion feels weird when the goal is to complete missions and build up toward a goal. The Dominion was staid, reactionary, intolerant; its role on the show was to object to change so strongly that it resisted new ideas with violence. Yet, in 2E the Dominion has to progress, and progress along the same axis as a Next Generation crew that spends its time learning from other cultures.

The primary means for getting points—completing missions—was also a problem, in several respects. First, the missions tended to be things the characters might do in-universe: investigate a mysterious space probe, respond to a distress call, etc. As a result, while most cards were driven by narrative the actual stuff one did with the cards was all about in-character simulation. That led to odd, athematic moments like Klingons participating in amnesty talks or organizing a cargo rendezvous; I’m sure there are Klingons who do those things, but they don’t fit the role of the Klingon Empire in the story, and after playing a bunch of cards meant to “feel Klingon” it was unfortunate to then use them to do un-Klingon-feeling things.

Are these what a game about the Klingon Empire should involve?
These missions are worth points for Klingon players, but they don’t reinforce any narrative theme relating to the Klingons.

Second, the interaction between missions and the people carrying them out didn’t build narrative the way the individual cards did. Star Trek, like any good story, involves character development. However, the missions don’t capture character development in any way. Missions and characters are both static in the game; if the characters can’t complete a mission, the solution is not for them to grow as people but rather to go get some other (also static) crewmembers who already have the requisite skills and attributes. Reading the cards one gets the feeling of the stories told on the show, but actual play doesn’t feel like a story at all.

(Perhaps it feels like a bad story, where we never transition from Act I to Act II because the main characters never get invested and just wander away when the going gets tough. That, of course, isn’t much of an improvement.)

Third and finally, the fact that players bring their own missions twisted certain faction themes based on interaction. The Maquis in the fiction were separatists who wanted to defend their territory, but 2E players naturally tended to stick to their own missions. As a result, the signature Maquis card is one that “defends” an opponent’s mission, locking him or her out of it. It seems that the Maquis in the game developed an expansionist streak.

Romulan decks also suffer from the BYOGalaxy dynamic. The Romulan Star Empire is always spoiling for a fight—but the Romulans are portrayed as cunning counter-punchers who rarely make the first move. Most opponents will never offer the provocation the Romulans are looking for, of course, because they’re content to stay amongst their own missions. Romulan players therefore have to go roaring over to the opponent’s side of the table Klingon-style.

In the end, then, 2E feels like Star Trek during deck-building, but loses that feeling in play. Themes are baked into the cards, but the funnel of missions and racing to 100 points turns some of those themes into mirror universe versions of themselves.* Even where a faction’s theme survives the funnel, the actions players take during the game feel less like being a Starfleet captain and more like being a quartermaster.

2E thus gave with one hand and took with the other; players would put down cards that felt very Star Trek, but then would have to use those cards in ways that undermined the theme of the game. The result was a game that started strong, but didn’t fully capture the Star Trek experience. Hence, all these years later, 2E stands as an object lesson that a game needs to deliver on its theme throughout the player’s engagement with it.

* You knew I was going to reference the Mirror Universe!

Theory: Dividing Cards by Narrative Instead of In-Universe Rules

About a decade ago Decipher—at the time an important player in CCGs—launched the second edition of its Star Trek game. When it did, its designers made two critical design decisions. One was superb; the other tended to undermine the first. Today we’re going to talk about the good decision: separating factions by narrative rules rather than in-universe ones.

In both of its editions the Star Trek CCG featured cards representing people from the Star Trek universe. Players assembled a crew by playing cards, and then flew about the galaxy completing missions. Each mission was worth points, and the first player to 100 points won.

The Star Trek CCG’s first edition (“1E”) divided its personnel according to Star Trek’s fiction. Romulans could only work with other Romulans as a rule; Cardassians were found in crews with other Cardassians; the Dominion kept to itself, running fully Dominion-staffed vessels. Federation citizens, including most of the main cast of the Star Trek TV shows, were happy to team up—Captain Kirk and Mr. Tuvok were both members of Starfleet, after all—but generally speaking the game prevented them from teaming up with non-Federation citizens, like Klingons or the Bajorans.

Looking at this from an in-character perspective, it all makes sense. The average Romulan might well never even meet a non-Romulan, so it’s perfectly reasonable for him or her only to be found on Romulan starships. Most Klingons in space are members of the Klingon military, which is presented as all-Klingon on the show; a player taking the part of the Klingon Empire might therefore reasonably have an all-Klingon crew. The Dominion is an insular society which does not welcome outsiders aboard its spacecraft. As for the Federation personnel, there’s no in-universe reason why Captain Sisko wouldn’t team up with Captain Picard or Captain Janeway, but there’s probably some Starfleet regulation about giving a Kazon the run of the ship.

However, the in-character approach had three critical problems. First, it did a lousy job of imitating the shows. The Next Generation had citizens of other interstellar nations appear as allies as often as they appeared as enemies, if not more; at various points its major characters worked with the Klingons, the Romulans, the Cardassians, the Bajorans, and even a Borg. Deep Space Nine doubled down on that idea, putting its Federation crew in constant contact with the Bajorans, the Ferengi, and later the Klingons and Romulans. Captain Sisko and his faithful team even worked with the deadly Dominion from time to time. By restricting characters’ ability to work together, 1E created a Balkanization that had nothing to do with the source material.

These two characters not only worked together every day, the character on the left viewed the one on the right as the messiah of her religion. Nevertheless, in 1E they could not normally be part of the same crew.
These two characters not only worked together every day, the character on the left viewed the one on the right as the messiah of her religion. Nevertheless, in 1E they could not normally be part of the same crew.

The second problem grows out of the first: 1E lost touch with the themes of Star Trek. Any given episode of Trek will involve a sci-fi problem—a moon that has to be put back in its orbit, computerized tools attaining sentience, etc.—but the point is always a human lesson: one about learning to work with people from other cultures, or how we might confront real-world issues.

Separating the characters into political affiliations and then enforcing that separation made it difficult to address those themes. The game couldn’t say much about finding common ground because it prevented groups from interacting!

Third and finally, 1E tended to elide the differences between shows. Since nothing in-universe would stop the Next Generation and Deep Space Nine crews from mixing and matching, nothing in the game did either. Nor was it particularly difficult to get luminaries from the original series and Voyager into the mix. Ultimately this led both to thematic weirdness (“Captain Sisko doesn’t seem like he’d approach this mission based on a Next Generation episode the way Captain Picard did, but the cards don’t allow for that”) and gameplay problems (the Federation could create high-powered crews, and so other factions had to be given similar power in other areas, creating difficult-to-balance asymmetries).

With the second edition of the game (“2E”) Decipher took a different tack: it replaced in-universe political affiliation with out-of-character narrative grouping as the arbiter of who could work together. Thus, rather than being a “Federation player,” one might be a “Deep Space Nine” player, able to play all of the characters who were a part of that show’s main cast or who were regular guest-stars no matter what planet they came from or what government they worked for.

2E fixes the problem with the "DS9" icons to the left of the text box; since both characters have the icon, they can easily be played in the same deck even though they work for different in-universe governments.
2E fixes the problem with the “DS9” icons to the left of the text box; since both characters have the icon, they can easily be played in the same deck even though they work for different in-universe governments.

Although it might seem simple in retrospect, that single move did much to resolve 1E’s problems. The constant cultural intermingling seen on the shows was easily incorporated, so the game became a better simulation. People who didn’t seem to have much in common could team up again, restoring some much-needed thematic power. Finally, the Federation got some reasonable sub-divisions, which took pressure off of the designers.

2E began with a single, brilliant idea: a game about TV shows could be based, not on the fictional universe’s rules, but on the audience’s experience as they watch. Running with that concept helped 2E resolve many of the issues which had plagued the previous edition. Unfortunately, it did not avoid every land mine—as we’ll discuss on Wednesday.