Elegant Design: An Applied Example

Published January 12, 2017 by Michel Mony, posted by Orymus3
Do you see issues with this article? Let us know.
Advertisement

Foreword

Learning to make content for games is a journey that never ends, but trying to break in for the first time is a difficult process. When I started several years ago, I came across too many theoretical articles on content creation for games and too few applied examples. To this end, I've put together this brief article on elegant design, but decided to do so from the vantage point of an applied (theoretical) example. Disclaimer: at the time of writing this article the suggested card effect had never been released by the developers, but by the time of its release a very similar effect was added, possibly proving the legitimacy of the process. Enjoy! On Elegance The title of this article states that "Elegant" Content will be designed here. So, what exactly IS Elegance in design? To answer this question I find no better alternative than to quote Mark Rosewater, Head Designer for the Magic the Gathering team over at Wizards of the Coast: In the words of Rosewater: How big should a piece of text be if you want it to be elegant? The answer is as big as it needs to be - and not a word more. Elegance requires taking a holistic view of writing. Every word, every sentence, every paragraph is a piece of a larger puzzle. It's not enough to understand the impact of a single element. Elegance requires simplicity. Simplicity requires a single purpose of thought. This means that elegance starts before you write a single word. A good sculptor must know his image before he picks up his chisel. There are many ways for you to explain an idea. The most elegant one though is not through definition but by example. By connecting your idea to one already known by the reader, you're leaving the work of teaching to someone in the past. Education is hard. Comparison is easy. A common barrier to elegance is the belief that only one way will work. Often a writer is unable to abandon a beloved piece of prose even when evidence demonstrates otherwise. If something doesn't add to the larger sense of the piece, you have to learn to let it go. But remember: "If I had more time, I would have written a shorter letter." - Marcus T. Cicero Choosing our Game I was just as lost as you are. I mean, for the most part, I thought I understood what the above meant until I actually started to implement it and figured these were all pretty words... The truth is that these words are perfectly accurate, but without a proper example to ground them into a process they're meaningless to a beginner -- so let's change that shall we? Now that we have a rough understanding of what it means to design elegantly (but have yet to see it applied to truly understand what it really means), we need to pick a framework (a game) to which we will apply this knowledge. For this example, I chose the relatively modern board game/miniature game "Star Wars X-Wing Miniatures". If you are not familiar with the product, I would recommend a quick read of the core principles of the game. They can be found on the game's website, or I could just give you the link now couldn't I? Now, I'll assume you have not read through that documentation and cover the basics. It's important to note that the more you know about the core game, the more you'll understand this article, but that understanding of the game is not mandatory to understand how elegance will be applied to design as a whole, though some of its subtleties might be lost on you. The Framework - Core Mechanics / Components X-Wing Miniatures, at its core, is a game of ships moving, attacking, and getting destroyed. Each ship comes with stock capabilities ("stats": attack, defense, life/shields), specific maneuvers it can do (moves) and specific actions it can perform (boost, focus, barrel roll, etc.) Each ship also comes with a set of customizable "slots". These slots can be filled with upgrade cards before the game starts, which effectively constitutes the player's list. For example, the Millenium Falcon allows the player to bring 2 "CREW" upgrades along, so you could bring Chewbacca and Luke aboard Han's favored craft to recreate some of the greatest Star Wars moments if you wanted. Upgrades come in various types, and each ship fields a unique combination of them: Astromech: Much like the famed R2D2, these are droids you can attach to some crafts to add some special abilities Salvaged Astromech: Similar to the Astromechs, but faction-specific to the Scum and Villainy (think Boba Fett & Friends) Torpedoes: Expendable ordnance. Fire and forget! Missiles: Pretty much the same as torpedoes, they're just "different" Cannon: Repeated-use secondary weapons. They tend to pack a punch. Turret: Repeated-use secondary weapons. These tend to fire "out of arc" (360 degrees) Bomb: Expendable ordnance, dropped from your rear, and only trigger when someone moves over them, or at the end of a combat round. Crew: Having them on your ship grants abilities. System: Having this equiped to your ship grants abilities (it's just like a crew or astromech in a different package). Modification: Once again, grants special abilities. Modifications are special in that every ship can field one. Illicit: Tend to be "single-use" abilities. Elite: Grants special abilities. Unlike others, these are not physical additions to the ship, its armament or its cargo (crew). Rather, this depicts the pilot's skillset (but, mechanically, this is just the same). Title: Provides a branching upgrade for the craft itself. These are ship-dependant. The Process As this article is focusing exclusively on content creation, we'll assume there's a framework in place (as per the above). In other words, you're not a designer creating a new game. Rather, you're a designer adding to a previous game's success. This could be a board game or digital product (TCGs for example). The example provided here will fit most competitive-driven scenarios. It would not apply to games such as a single-player experience where you're adding new levels, but most of it may just as simply carry over. I chose this particular example given that my experience as a fresh designer, and that of many colleagues to come locally, was related to this type of content so it is a much easier example for me to work from. What to make When designing content, you generally have a frame in place. This frame is determined by theoretical elements of the game. Whether they become a part of the end product or not is irrelevant: these are the building blocks you have to work with. For example, in X-wing, one might argue that the core building block is the Tie Fighter, which for a long time was the most cost-efficient unit and one of the simplest. Looking at it allows one to reverse-engineer parts of the game economy quite efficiently: The unit is costed at 12 points, and does not have any upgrades, and boasts fairly average/poor stats (aside from defense). When creating a new ship, it helps to bear in mind a few of these beacons so as to avoid creating something that does not make sense, even beyond just the game balance itself. As a junior designer or a designer in charge of adding content to a pre-existing game for which a specific sandbox has already been established, it is important to leverage these building blocks to ensure coherence. One then needs to commit to an idea. This can be done in two different ways: A - Determine a mechanic that the game requires, and then define how this can be articulated in terms of flavor or B - Come up with a flavorful idea and then break it down into its mechanics. Method B tends to work great when the game is just starting, especially if there aren't really any player base yet. Method A requires more insight into the metagame and is usually best employed when having access to player data or a large pool of playtesters to observe. For this essay, I've decided to cheat a little. I've actually employed method A but will present it as though I had come through method B. The reason for this will be explained further. For some reason, as a designer, I have determined that it would be great to add some form of cheap kamikaze ship to the game. I then proceed to write down my objective: Objective: A kamikaze ship that incapacitates a larger ship. The reasoning is that, from my experience of playing and analyzing the game, there is unused design space, but more importantly: a piece missing that could help everything else fall into balance (or closer to a more balanced state). Think of it like looking at a game and realizing something is "OP" (overpowered) in the eyes of a credible majority, or identifying it on your own however subtle, and finding a clever way to address this by introducing a new option for the player pool that, in turn, will have an effect on the metagame, and hopefully minimize the 'OP' strategy in some meaningful way. How I go about making it When using method B to design (top-down design), I need to translate a concept into game mechanics. This is a very fun and challenging process. It effectively requires one to consider mundane text and convert it, leveraging all of the game's mechanics to have an effect that makes as much sense from a mechanical standpoint as it does from a flavor standpoint. Our original objective was: Objective: A kamikaze ship that incapacitates a larger ship Translating this into game terms, I can break it down into keywords to be further refined into mechanics: Kamikaze: The action of attempting to collide with an enemy to cause harm, and be destroyed in the process Incapacitate: The action of causing irreversible damage Larger ship: a ship which has above-standard stats, most likely, sustainability. I can further break down Kamikaze as follows: - Requires collision between this object and another to trigger - Has a one-time trigger to cause harm - Self-destruction is the end result I can also break down Incapacitate into a game effect: - Deals damage Note: Sticking to dealing damage alone would not be irreversible. Several game effects can repair the damage. More importantly, we need to ensure that this effect has a higher or at least similar potency against larger ships than smaller ones, and damage alone would tend to scale the opposite direction (1 damage against a small ship representing a much larger % of their total hull than it would on a larger ship). Furthermore, I should break down effects that I feel would be irreversible and work well with larger ships. One of the things larger ships tend to have that smaller ships don't is upgrades, so I chose this effect: - Destroy an upgrade card At the time of writing this article, there was no game effect that effectively allowed to remove a ship's upgrade card as a result of an attack. By the time of publishing, however, such a game effect was created (fate?). The above effects can be brought together as a list of conditions and effects. An exhaustive explanation of this ability could read as follows: "When this ship collides with an enemy ship, if this ship's current Shields value is higher than the enemy, destroy this ship. Then, deal 1 damage to the targeted, and choose one of its crew upgrade cards. Remove that upgrade card from the game". Applying Elegance There's no denying the above game ability fits the original objective. It fits the criteria set forth in the original description of the intended effect. Elegance does not challenge this, rather, it simply asks whether there's a way to achieve the same result without being overly specific and exhaustive (optimize). For example, I've included a condition that requires for the Shields of the ship to be higher than that of its target, the intent is to convey that one couldn't ram another ship if their shields could protect them. If the ramming ship has higher shields, it could effectively tear through the opponent's shields with its own and attempt to ram against the hull. To be elegant, however, one might have decided that the added complexity of this clause was insufficient to justify it being included. Or perhaps, it could've been simplified to focus on the effect. For example: "When this ship collides with an enemy ship, destroy this ship. If the target has no shields left, choose a crew upgrade card from the target and remove it from the game. Otherwise, removed all shields from the target". The above revision retains the idea of shields, but assumes a slightly different interpretation: by ramming in the opponent, its shields are lost. If there weren't any shields left to protect the ship, instead, a crew dies. This removes some of the mathematical computation that players would need to consider when using the card, and already makes it a bit more elegant in that regard. One might argue this is still unnecessarily complex... "When this ship collides with an enemy ship, destroy this ship. Then choose a crew upgrade card from the target and remove it from the game." Simple and effective. The concept of shields vs shields is entirely lost, but the core idea of ramming remains prevalent. One (such as the designer himself) who was aware of the history behind this ability might feel like the idea is missing something, that it does not feel sufficiently 'true', but the game effect does benefit from being clear and concise. More importantly, if the intent was indeed to minimize the potency of an 'OP' strategy, the shield clause would make this card's usage very circumstantial, whereas the latter implementation makes this a great fit. Note that I've listed "crew" upgrade card in the above game effect. This would support the original concept as it could be translated as someone dying aboard the enemy spacecraft due to the harsh collision. With the 1 damage, one could reason that this could've been a localized hull breach that caused the crew's death. The effect makes sense, but it may not make sense within the game. For this, we'll need to take a look at the metagame. On Metagame, or seeing the game holistically Seeing the game holistically is an art. It requires to play and look at a lot of players to see what stands out. If the game has the benefit of having a competitive scene, then the designer should really be observing (a lot) before making any hasty decisions. Information will never come from any 2-3 games where something happened, but rather, from the plurality of these experiences and how they shape the game. In a popular game such as X-Wing, players that are allowed a certain level of control over their custom lists will eventually start to polarize their choices around significant archetypes. At various levels (casual, softcore, midcore, hardcore and competitive) players will start to field several similar lists, that is, lists that have more in common than they have different. This alone would probably be worth an article of its own, but once a designer has started to understand what 'works' and how it is played by players, and what the associated feelings are (is it fun playing? is it fun playing against? is there any frustration when strategy A doesn't or does work? etc.) he can start listing the issues that the game likely needs to address. This doesn't happen overnight, and some of it might remain hidden to the untrained eye. More importantly, a game that has periodic content releases such as X-Wing deals with a shifting metagame, that is, if they release only every year, then the metagame goes through several phases: Last year's metagame New year's 'infancy' stage New year's 'mature' stage Anticipating next year's stage At each of these stages (and sometimes in-between) players click on 'new things' they hadn't considered before, and start leveraging that, which is identically met by how other players have discovered new things, or have adjusted their former strategy to compensate for new ideas. In a perfect world, this constantly changes, but in the real world, there are periods where it goes stale (and the massive introduction of new content is required to keep things moving forward, even if it means only nudging players in the direction of formerly underutilized strategies). At the time of writing this article, a new wave had just gone out, and the metagame revolved around several poles, two of which, though very interesting and fun, demonstrated some 'OP' cases or at least, the potential to be. To be fair, the metagame for this specific wave was still in its infancy, but it proved a very interesting ground for analysis. Put simply, the two problematic poles were: - The empire has gained access to a new crew (very expensive "Palpatine") which granted them the ability to change one die's result to any specific result every turn (which tends particularly well with 'aces' that dodge enemy fire and are basically glass-cannons). By further increasing the survivability of the Empire's aces, and making them deadlier, lists that fielded Soontir Fell soon became near unstoppable (at least, at first!) - The infamous 'TLT' (Twin-Laser Turret) becomes available. Put simply, this is a turret (which can fire in any direction, in a game where facing is critical) which has the greatest weapon range (and is the only turret to do so), Add to that that though each attack is limited to 1 damage (which is generally what most turret attacks would do to begin with against aces) this turret attacks twice, and is a perfect counter to aces as it tends to force their opponent to spend whatever defensive measures they have against the first attack (Palpatine for example) and simply get hit by the second. It is also an upgrade that fits the 'tank' class of ships (Y-Wing most notably) and based off its two attacks, is the most reliable damage source in the game. No criticals, no strokes of luck, but just an ongoing barrage of attacks from a list like the 4 Y-Wings which packed as much as 8 attacks per turn (and half of these would generally go through defenses). It is a very strong strategy because it works against aces and tanks alike. - The 'Autothruster' is a simple modification that improves defenses against attacks made from long range (range 3) or attacks made 'out of arc' (turrets). Basically a response to the TLT. As I said, I cheated a bit when planning this article because, as a player and avid designer, I already identified that this wave of content (unlike most previous waves) introduced specific cards that could really annihilate entire lists in a blink of an eye. While most previous waves did so by having several pilot abilities and upgrades work together, Palpatine, the TLT and the Autothruster all severely impede other strategies and act as direct counters. There's nothing inherently wrong with that, and to be fair, most of them are fun to play with or against and, as time has proven, relatively well balanced, but it called for a 'universal' response. I figured that what the game was essentially lacking is a card that allowed players to try and identify what was the core threat in their opponent's list, and eliminate it, to see if the rest of the list could still hold. Instead of allowing anyone to field a list that had a 'combo' you couldn't do anything about, it tests the opponent's ability to build something that can survive that deliberate sabotage attempt. As a result, destroying an upgrade outright felt like it made a lot of sense. Stapling that effect to a kamikaze cheap ship such as some kind of custom Z-95 made a lot of sense as well, though as history has demonstrated, the official design team found a similar way of going about it but at the crew upgrade card level and without the need to lose a ship (which is probably more balanced). Refining the Concept: tying the content to the metagame The above explains the situation we are in, and what needs to be addressed, but asks a question: What (if any) type of upgrade card should we limit this effect to? Our original solution mentions 'crew upgrade card' which does fit the Palpatine case, but it entirely forgoes the TLT and AT. That leaves us with two outcomes: A - Target a specific scenario (kill crew for example) and hose that strategy, but risk allowing the other two spin out of control. or B - Lose a bit of context and flavor, but allow this solution to work across the board. Note that solution B may prove equally or more dangerous to pre-existing staples of the game. If the 'rest of the game' relies on missiles for example, and that this card could effectively be used to destroy any missile before it fires, or any potent crew, etc. it could very well make this particular card the new metagame staple and unbalance the game, unless it isn't necessarily cost-efficient. For the purpose of this essay, we'll let elegance win, assuming that the designer has identified all potential use cases and costed the upgrade appropriately, knowing that, under most circumstances, trading this particular ship against any upgrade wouldn't be worth it, unless the latter is 'OP'. The end-result would be that this card shouldn't see too much play, but remain a valid answer to TLT, Palpatine, and AT. As the card gets released, it sees a lot of play because it is new, and during this period, a lot of TLT, Palp or AT players see a lot more losses than usual, eventually reconsidering the value of their strategy. A number of these players stop using these lists, or tweak them a bit to add a post-kamikaze end-game, which in turn makes the list less efficient (and less OP) but more versatile. As a response, players' interest in this kamikaze card decrease slowly, but the metagame effect has already rippled through lists and much fewer players rely upon the TLT PALP and AT uber lists, and occasionally get crushed as a result. Those that use the kamikaze find other uses for their card and either bait their opponent or try to identify the opponent's new powerful upgrade that they can't counter otherwise and kamikaze on it. After a few months, some people use our new card, but not so much, and they don't tend to dominate the scene, but more importantly, we see much less TLT, Palpatine, and AT, though we still see them, and they're still good when they show up. We've just created fear for players that couldn't be countered before that they might be now, and this fear alone has helped move the metagame towards a more balanced direction. It doesn't mean a sudden TLT list couldn't show up at an event and that none of the players there would have a kamikaze, landing them a sudden win, but it greatly diminishes the likelihood of this happening and brings the game closer to being 'skill-based' where every player decision matters more than the list they are playing. It also results in the creation of a card that comes with a huge baggage of player decision and opponent guessing. The player needs to figure out what to destroy, and the opponent needs to guess what that might be, assess whether this is something he's willing to live with or react. Our final effect: "When this ship collides with an enemy ship, destroy this ship. Then choose an upgrade card from the other ship and remove it from the game." By comparison, the card released a few months later: latest?cb=20160210233157 A short aside on Design Space I've hinted at metagame analysis as being its own art, but haven't really mentioned 'design space', and yet I feel it is critically important to Elegance in design. Put simply, design space is the art of knowing the player's capability to consider different information. For example, a game like X-Wing focuses primarily on 4 stats (Attack, Evasion, Hull, and Shields) and then applies movement patterns, etc. All of these things require some concentration on the player's part so that they can understand, internalize and remember the rules all the while remaining open to new streams of content (such as cards, which tend to be rule-breakers and individually require brain space of their own). If too much design space is occupied by the core mechanics, the game cannot expand, and if the new content is too complex, then the game quickly reaches a point where it is impossible to understand everything at any given point and very hard to play a game without having to refer to the rules, or a lengthy read of some cards, etc. Games such as Magic the Gathering used to field a number of very complex cards, which when put on the table inevitably led to players stopping everything else, reading the card 2 or 3 times, asking a number of questions, and this basically halted the game because these cards simply required too much attention, or in other words, exceeded the design space. That's not to say a game doesn't have room for complex mechanics, but rather, that design space is like a budget, and it needs to be spent wisely. A clever designer will allow for complexity where the tradeoff between complexity and fun is balanced. In general, the core precepts of the game (those most likely played by the majority of players over the course of their games) will be kept simple, so that the majority of the game flows naturally, and will allow for uncommon situations (though not necessarily rare) where a pause is warranted to refresh the players' memory on some of the concepts less used. In X-Wing, one of these concepts is the simultaneous rule of fire. Most pilots in the game have a unique pilot skill level which determines in which order they play, and in the case of ties, the player with initiative (determined at the start of the game) will play or attack first. Simple: follow the numbers, and if there's a tie, remember how that tie was broken at the start of the game and always resolve the order in this manner. This is elegant because every player is expected to understand the order of numbers 1-10, and a simple (and single occurrence) action determines tie breaks. That being said, sometimes a ship with the same pilot skill as another might destroy it when attacking, and it may be hard to internalize that pilots from the same pilot skill wouldn't play at the same time. In these particular scenarios, a specific rule is invoked (the simultaneous rule of fire) and the damaged pilot is marked as dead for all intents and purposes except for the fact it is allowed to fire at its regular turn, as though it hadn't yet been destroyed. How often does that rule actually come into play? Unclear, but most likely in under 10% of the games. The rule is elegant because it does cover something that the designers felt had value, yet it doesn't get in the way of the actual game and keeps it simple (for the majority of people, they won't struggle with a specific sub-phase in combat). It is ok to sacrifice elegance if design space allows it. It can allow for some 'noise' to make things a bit more organic and realistic, but it is critically important for the designer to bear in mind the extent of this finite resource and how much of it they're willing to invest in mechanics. A designer's ability to apply elegance to their core mechanics and content is what allows them to withhold design space for later use and is the key to longevity in a content-driven game. Article Update Log - May 16 2015 - Original Article - September 5 2016 - Revisited (post Boba Fett crew release)
Cancel Save
0 Likes 0 Comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!

When I started in game design I read a lot of theory and really lacked tangible examples to ground my knowledge into. Today, I give you a brief look at what elegance means by actually creating a full-fledged example to help aspiring designers.

Advertisement
Advertisement