Latest Posts (10 found)
Playtank 3 days ago

Game Balancing Guide

This post is all about what game balancing is and how to do it. Just remember that every game has its own unique needs and challenges, so cherry-pick whatever sounds reasonable for your game. This post will become a “living” post of sorts, added to over time. Tell me about your own balancing tools and tricks at [email protected] or in a comment. Sections in this post: Before we get into the balancing itself, we need to know who we are balancing for. Paradoxically, this doesn’t have to be your target audience per se. A player who bought your game but never installed it is still part of your target audience; but they are not part of your balance targeting. Some players simply don’t care for your game at all for one reason or another, or lose interest after a while. These matter to game balancing because they are inevitable. One element of your balancing is who you are not balancing for. There are two very broad types of player attrition: the burn and the churn . Players who touch your game and get burned, like on a hot stove, never to touch it again. Knowing who you are willing to burn means that you can plan for it and exclude any balancing fixes that cater to that group. Pleasing the burned only wastes time. Burned players will never come back. It can be because the genre or gameplay doesn’t appeal to them, because it didn’t match expectations, or for many other reasons. What’s important to understand is that this is fine . You’re not making a game for everyone. Your multiplayer action game is not going to appeal to a fan of turnbased singleplayer games and no amount of balancing will change this. Churn rate is the rate at which players stop playing your game. In the best of worlds, you are able to collect data that tracks when players are churned. In a puzzle game with linear progress, for example, if many players stop playing halfway through the fifth puzzle, that could be an indication that they don’t understand how to proceed. Or if many players stop playing after dying four times against the second boss, it may mean that it’s not clear enough or too hard. Players churn after giving your game a chance. You can win churned players back or delay the churn by understanding your audience. One goal of good balancing is to keep these players playing. In his book, Introduction to Game System Design , Dax Gazaway employs measurements that are very practical and useful for when you want to figure out your design target. The book has more measurements. For this post, I’ve stuck to those that can be quantified. Understanding how a new game works is an acquired taste. Many a gaming console has been purchased to play Grand Theft Auto and EA Sports FC exclusively. A gamer today can be someone whose hobby is to play Fortnite or League of Legends , and who hasn’t spent more than a handful of hours in total even trying other games. Gazaway expresses interest in challenge as a ratio of failures against successes. A game that can be measured as 20 failures against 1 success (20/1) is clearly a lot harder than one that is measured as 1 failure against 100 successes (1/100). A player that starts getting frustrated after failing twice against each success will be burned by the 20/1 game. But so would a player that thrives at 10/1 while playing a 1/100 game. Not to mention that a game that suddenly goes from 5/1 to 20/1 is likely to churn some of its players. Free-to-play advocate Nicholas Lovell talks about the Starbucks Test , which he paraphrases from then Natural Motion CEO Torsten Reil as, “Can you play your game and have a meaningful experience in the time it takes for a barista to make your macchiato?” This is the very bottom of the time investment rung, where you can fit a play session within your other daily phone activities. On the opposite end, you have games that take many hours, even several days, to finish. According to Midia Research , “[c]onsole gamers spend – on average – 10 hours gaming per week, while PC players spend a little less (9.7 hours).” Gazaway talks about session time vs total time . A single-player roleplaying game may take 80 hours to complete, but you can play sessions of variable length. It may even pass the Starbucks test, letting you jump in and defeat a monster before they call out your name. If you are making your game for middle-aged gamers in the west with stable income, you can expect them to pay more than a kid with no personal bank account, or to a young student in a third-world country. Income inequality is sadly universal. Deciding to charge €69.99 for your game will exclude everyone whose ceiling is €5, for example. Simple mathematics. They’re burned before they even start the game. They don’t get to the stove. Even if they’d give the demo a chance, they could still never afford your game. This needs to be mentioned here, because we tend to forget that the money and the balancing are actually strictly related, even if all it affects is the point of entry. The first step to balancing is setting points of reference . This is the foundation for everything you will do, and can live in a bullet point list, a spreadsheet, a design spec, or some other form. In the excellent book Game Balance , by Ian Schreiber and Brenda Romero, game balancing is divided into three “metaphorical dials that are coming together” to create the sense that a game is balanced. Think of difficulty as how much pushback the game has against your success . This can be expressed as a ratio of success. For example, if you want the average player to win 75% (or 1/3 in Gazaway’s failure to success ratio) of the fights they start on the first try, but only 25% of bossfights (3/1), you can see if those numbers check out by collecting data from play tests. The number of things in your game . Enemies, ammo, loot, levels, coins, dialogue lines, health points, and so on. Quantities are often adjusted for practical reasons more than balancing and must then be balanced accordingly, for example how many enemies that can be rendered at any given time, or how many weapons you have budgeted time for delivering. When to press the key. How fast you need to move and when you should stop moving. For how long an interstitial “hurt” animation plays before returning controls to the player. The duration of the progress bar on that new building you are constructing. Timing is about duration as much as the moment. As has been discussed before , the lack of common language around game design means that we often resort to references to other games. This makes it really hard to talk about balancing with any consensus. Therefore, the first thing we need is everyone’s buy-in. Everyone working on the game, that is. We may want our game to be as difficult as Dark Souls , feel as good to play as Super Mario Odyssey , and take about as long per match as PUBG . These are fairly concrete and measurable comparisons where we can apply a more scientific approach. If it takes us about 10 attempts to kill a boss in Dark Souls , that gives us a number to balance against. Just don’t make the mistake of copying. If you have those 10 attempts against a boss with you, take that number and consider it. Test lower, test higher. Look at it from quantity and timing angles as well. These are inspirational and communicative references, not your rulebook. They say something about how the referenced game works, not how your game should work. It’s also common to set up antithetical references. We don’t want a match to take as long as a full Battlefield 3 Conquest match, or we don’t want timing to feel as punishing as in Ninja Gaiden , or the UI to be as confusing as in Crusader Kings II . Whatever it is, it needs to tap into this same common pool of references. References shouldn’t be limited to games. It’s common to refer to movies, comics, TV shows, books, documentaries, historical events — anything that can act as an antithetical to what you have in mind. Same goes for balance references, of course. The key to references is that everyone on the team can understand them. A designed reference is something you come up with in the team that becomes true for you . It can be a pillar, such as “Character-based play,” that lets you tap into your own project to figure things out. Someone changes something, and you can then go back to check if the thing actually is character-based play. If it’s not, it’s failing, and you may have to rebalance or redesign it. Just like the spend ceiling mentioned before, there are limitations you must contend with. When you print a deck, it has a certain number of cards. A Switch console can only push a certain number of textures per frame at 60 frames per second. The worst part with limitations is that they are extremely inflexible. If you break the card count on a print plate you need a whole second plate, even if all you are after is a single card. Similarly, rendering just a few more textures per frame will make your game run slower. Technical, practical, and financial limitations are important to know before you set your other references. Measurable goals for what you want the experience of play to be. This can be session lengths, more or less pushback, or specialised metrics like how many seconds should be the maximum allowed to pass between game launch and the first kill (“seconds to kill”). Set these goals very broadly. This will make it easier to make exceptions to them the same way a bossfight against an enemy that has a lot of hit points immediately changes the “seconds to kill” dynamic. Many action games have an average lifetime for enemies around five seconds. Maybe you want your enemies to be tougher or smarter, so you state that you want average enemy lifetime to be 15 seconds. This is a type of content goal, where you state how much screen or even CPU time something is intended to get. With many games content-driven or even content-locked by design, this should be more of a consideration than it is. It’s helpful to use an object or variable as an anchor for the central mathematics of your game. Health points is an effective anchor. If you set a player character’s health to 10 and you let this serve as your anchor, you set the damage weapons deal and armor prevents, what ratios you want between gold and health, and how effective the conversion of mana to health points should be. This would turn health points into the main dial for almost all balancing in your game. You can also speak of multiples of health points as measures of difficulty. An easy enemy may have half of the player character’s health, while a tough enemy has ten times the same. When you do this for an object, it can be the game’s default pistol and the experience of playing with it. Which is how John Romero writes about testing new Doom levels: all of them needed to be playable from a pistol start. The pistol is then the anchor for Doom ‘s balancing and all the various numbers that affect the pistol, such as ammo pickups placed in the level, damage, fire rate, etc., will affect the play experience of every single level in the game. A range is a floor and a ceiling and all the numbers between. If you have a numeric anchor, like 10 health points, it should probably represent the bottom of the range in a progression-driven game. However, an object anchor like the pistol could represent an average for multiple ranges. You may have ranges representing distance, damage, armor, gold value, durability, ammo, and so forth. Ranges are a good way to incorporate limitations. If you know that your frame rate will limit the rate of fire for your firearms, for example, you can set the ranges accordingly. A handy thing with ranges is that you can use them in random generation. For example, if you determine the extremes (see Set Extremes, later) you can test with random values within that range when you run your tests. One way to set references that I’m personally very fond of is to use words instead of numbers. To fuzzify the numbers. If you have the concept of range in your game, you can talk about it as Close, Far, Long, and Distant, for example. When something needs to be changed, you bump it on this ladder rather than changing the numbers directly. This makes it easier to talk about the balancing in relative terms. It also lets you determine which ranges you want to have without having to get stuck discussing the numbers. If you need more nuance, you can add more rungs on the ladder. Game economy design is basically a science in itself. But a good way to start building a virtual economy is to tally all of your sinks first. These will show you how much virtual currency even has the potential to flow through your system. If this number is capped or particularly low, you should limit how many sources you have based on player time investment, difficulty, and other targeting goals from the previous stage. Make sure that the player can always afford something , but also make sure that they can never afford everything until your reference goals are reached. When you set out to create a system of balancing that has numbers at its foundation, you always need to start from somewhere. One way to start is to simplify everything down to one of four value systems: 1s, 3s, 5s, or 10s . Start from just 1s or 10s, then introduce some 5s, and finally some 3s. This way, you will quickly have the gut-level foundation for your balancing. To refer back to health, one mana could be worth five health points, while one gold is worth three in the form of a health potion that heals three points. Another way to create base numbers is to use a Fibonacci sequence . A Fibonacci sequence is “a sequence in which each element is the sum of the two elements that precede it.” If you start from 1, this gives you 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, etc. This sequence can often come in handy, and you can play with the principle of the sequence as much as the sequence itself, for example to set item prices with a good initial spread. Perhaps if your health potion costs 25, then you could price the following item tiers 50, 75, 125, 200, etc., using the same rule of summing up the two preceding numbers to get the next price. If points of reference are there to give us something to anchor our balancing to, points of differentiation are where we design the game. A focus on diversity. Ways to mess with your points of reference and give players something to strategise around. Greg Costikyan wrote about this on Linkedin, in the context of combat systems, saying that “The key is multiple points of differentiation, to create interesting strategic choices for players. If it’s all about DPS, it’s boring.” His examples include things like reload times, costs, damage, damage type, combined effects, and more. Ways to add more ranges and more points of differentiation between one gun and the next. Destroy them, disable them, put them on timers, require resources for their use. Take things away. Once the player is used to something, try removing it and seeing what happens. It can be the worst thing you did, or it can give room for you to create a needed change of pace. Like when the enemies in Batman: Arkham Asylum start mining the gargoyles Batman is using to hide. In game theory, a dominant strategy is one that always trumps other strategies, while a dominated strategy is one that is always trumped by everything else. Players will naturally gravitate towards dominant strategies as their understanding of a game evolves (at least if they are accepting of learning new rules), and will bounce away from dominated strategies. This is not necessarily a bad thing. You may want the starting pistol to be a dominated strategy, same as the BFG 9,000 is a dominant one, but other restrictions of usage means that you will never stop using the first and can’t rely entirely on the latter throughout the game. Many games restrict features by requiring transference. You are highly unlikely to find the best mod in Warframe , if it’s even possible, so instead you engage in the act of combining mods to convert them into better ones in multiple tiers. A process that costs resources at every step along the way. Going back to the Game Balance book and its three dials, most of these systems use time as the essential anchor. You need to play to collect more of the resources you need for the crafting, and there are rarely any guarantees, which means you need to put even more time into it. Controlling when a difference is introduced is a key element of time balancing. If you find the best weapon in the game right out the gate, players are unlikely to ever switch, and if you provide access to it too late, many players will never see it at all and many who do see it may be less inclined to change their winning strategy. You can also control how easily a difference is accessed. Players may have to complete a special quest or spend an expensive amount of resources or time. Perhaps most commonly for Massively Multiplayer Online Role-Playing Games (MMORPGs) and similar genres, where you will have the squeeze the best possible mileage out of every piece of content, changing a color and making something deal a different type of damage (red for fire, blue for lightning) modifies things enough to keep the player playing. Patterns you don’t want the player to fall too deeply into can be altered by diminishing returns. Enemies may start wearing more body armor if you kill many of them, forcing you to switch things up. The following list will serve as a living document, with tools added over time. (Sporadically, I must add.) Make sure to only change one thing at a time, and to document what you changed. This makes it easier both to know what you did, what made the ultimate difference, and to write changelists once you publish it to your players. Sometimes, you have a solution or feature that just works . In a first-person shooters, you’re shooting, aiming, and reloading and shooting again, constantly. Same with card games; you’re drawing and playing and drawing. If a segment of your game isn’t working as well as another, repeat a solution that worked before. Keep a record of go-to solutions for future use. If you get stuck on something you decided on, try doing the exact opposite in your design and see if that takes you anywhere. Maybe you added more health to the enemies because the combat was too short, and it made them feel like bullet sponges. Trying to decrease their health instead and then increase the spawn rate could be the solution you seek. Touch, but don’t taste, is when you have a really cool feature that’s so restricted that players never use it, or they save it for a “later” that never happens before the end of the game. If you see this pattern in your game, you can give the players a bite instead. Let them play with the feature without any risk of losing anything, to teach them that the feature is worth using. First one’s free. If you feel that something lacks depth or isn’t interesting enough, you can try to add an additional dimension. Maybe your dialogue system with the Yes and No response options is making for bland conversations. Add a third option that plays against both Yes and No. Rock, paper, and scissors, is a metaphor for the related variation. Sometimes when an action feels like it doesn’t have enough “oomph,” you can add more feedback to it. Tell the player that the thing is in fact happening. Particle effects, cheer sounds, camera shake, stop frames, easing functions leading into or out of the action. Think of the sounds the Halo energy shield makes as it starts and finishes recharging. If your game has many moving parts that are active at the same time, it can be helpful to divide them into separate stages of interaction. Games that are maths-heavy, such as some styles of role-playing games, will often divide their “buffs” into stages. Something that lasts for 30 minutes is a “prebuff” that you can activate when you are expecting something to turn tough, while the one that lasts for just 30 seconds is something you use in the midst of combat. This division serves as a subtle way to structure the player’s buff cycle. If you see players doing something over and over again, even though it’s the wrong thing to do, you can try to make it viable to play the way they are playing. This is the territory of Coyote time, auto-aim, and other mechanics that try to predict game effects from player intent. This balancing tool is almost cliché at this point. Double or halve. You want the thing you are doing to make a tangible difference, so you double it or you halve it depending on whether it needs an increase or a decrease. When you feel that something needs a bigger impact than doubling or halving it yields, you can try multiplying or dividing it by ten instead. This is a much more drastic move and will rarely be used except as a method to find your extremes. If players are unaware of interesting features in your game, you can make them excited for it before they get to play with it by putting the door before the key. Dangle the treasure, the lever, or the new enemy in front of them, so that they will actively seek out how to get to it. Whether by finding an actual key or by understanding that they need to go up to get inside the locked room somehow. Metroidvanias are fantastic at this. An exercise you can use when numbers feel off is to decrease or increase by a lot (doubling/halving or by ten) until you find the lowest low and highest high. Then you construct a range out of those two values, and you start testing with different values within that range to try and find a sweetspot. It’s a good way to get away from pure feel and narrow it down. Probably the most common trap in balancing is to create a cool new thing and immediately feel a need to make it worse. To “nerf” it. This is a reminder to not do that, but to try to capture why the thing feels cool and to extend the same coolness to as much of the game as possible. Targeting : who you are balancing for. Points of Reference : what you are balancing against. Points of Differentiation : the exceptions you are making to your points of reference. Tools : various methods and techniques that you can use when balancing your game. Refusing : players that don’t want to learn anything new at all, regardless of how you package it. They want things to behave a certain way. Gazaway’s example is how Wii Bowling managed to attract people who didn’t really play games, because it was close enough to real bowling for the rules to transfer readily between the different media. They don’t want new rules, but they can transfer what they already know. Resistant : players that are willing to learn some new things to be able to engage with games in a genre they like or a series they follow, but tend to not leave their comfort zone. The aforementioned Grand Theft Auto and EA Sports FC players. Neutral : where you’d categorise most “casual” players. Willing to learn new rules to play a specific game, but more as something that goes with the territory than something to be actively sought. Accepting : players that don’t just reluctantly embrace new rules but dig deeper and even learn more than they may need to. This is the space for many “hardcore” players, that stick to a genre and explore it deeply with character builds and clever solutions. More likely to try something new that they still recognise. Enthusiast : people that read game rulebooks for fun. They will probably move on to the next game once they have understood this one.

0 views
Playtank 1 months ago

Definitions in Game Design

“We’re making an ARPG with survival and roguelike elements,” begins the pitch. “It also has some light platforming, is made with Godot, and intented for release on Steam in Early Access.” For the business-minded person in the crowd who just played Path of Exile 2 , they may focus on the ARPG bits or conjure up mental images of lucrative microtransactions. One who recently finished Subnautica may catch on to the survival bits, for good or bad. One who bounced off Hades 2 for some reason could be negative about the roguelike element. Another may latch on to the idea of platforming and think that there’s no point to go up against some other popular platforming game that’s about to hit stores around the same time. Someone may dismiss it simply because they said “early access,” or because they have opinions on the choice of engine. This pitch has managed to confuse everyone in the room, using seemingly standard terms. The genres and abbreviations we take for granted seem just as watertight and solid as any formal academic definition, but they really are not. In fact, I want to argue that attempts at general definition harms game design . Definitions can and should change from one game to the next. Asking someone to define something in general terms derails the creative conversation we could be having instead. Let’s look at definitions of game design, to hash out what I’m trying to say. And as usual, if you disagree, please do so in comments or to [email protected] . Why is there no definition of game design ? In fact, the definitions are legion. We simply can’t agree which one to use. Not even at the university level. Faculties across the world use different ways to talk about game design. One university may talk about game design as level design, while another involves scripting, and a third uses boardgame design as the springboard. So let’s look at some ways that great game designers have tried to concretise the language around our work. “Creativity is concerned with the invention of something new and different,” said Chris Crawford in 1989, in his famous ‘whip speech’ at the Computer Game Developers Conference. I was seven years old at the time, so can’t say that the prospect of developing games had had a chance to form yet at the time, but it’s an incredibly inspiring talk to watch today . But before wielding a bullwhip on stage, Crawford also wrote one of the earliest and most lucid texbooks on game design, The Art of Computer Game Design , published in 1984. A book that thinks a game needs three things: representation, interaction, and conflict. “[A] game is a closed, formal system that subjectively represents a subset of reality,” writes Crawford. Closed : “By closed I mean that the game is complete and self-sufficient in its structure. The model world created by the game is internally complete; no reference need to be made to agents outside the game.” Formal : “By formal I mean only that the game has explicit rules. There are informal games in which the rules are loosely stated or deliberately left vague, but such games are not typical.” System : “The term system is often misused, but in this case its application is quite appropriate: a game is a collection of parts that interact with each other, often in complex ways. It is a system.” Subjectively represented : “ Representation is a coin with two faces: an objective face and a subjective face. […] The distinction between objective representation and subjective representation is made clear by considering the differences between simulations and games. A simulation is a serious attempt to represent accurately a real phenomenon in another, more malleable form. A game is an artistically simplified representation of a phenomenon. The simulations designer simplifies reluctantly and only as a concession to material and intellectual limitations. The game designer simplifies deliberately in order to focus the player’s attention on those factors the designer considers important.” Subset of reality : “[N]o game could include all of reality without being reality itself; a game must be, at most, a subset of reality. The choice of concerns within the subset provides focus to the game.” Game design concerns itself with all of these elements. But Chris Crawford also define games by what they’re not. “Games provide [an] interactive experience, and it is a crucial factor of their appeal.” Games Versus Puzzles : “Games can include puzzles as subsets and many do. Most of the time such puzzles are a minor component of the overall game, because a game that emphasizes puzzles will rapidly lose its challenge once the puzzles have been solved.” Games Versus Stories : “A story represents a series of events in a time-sequence that suggests cause-and-effect relationships. […] One important difference between games and stories is that a story presents its facts in an immutable sequence, while a game offers a branching tree of possible sequences and allows the player to make choices at each branch point and thus to create his own narrative.” Games Versus Toys : “Games lie between stories and toys in manipulability. Stories do not permit the audience to control the sequence of fictional events. Games allow the player to manipulate some of the facts of the fantasy, but the rules governing the fantasy remain fixed. A toy is much less constrained; the toy-user is free to manipulate it in any manner that strikes his fancy.” “Conflict arises naturally from the interaction in a game. […] If the obstacles are passive or static, the challenge is a puzzle or an athletic challenge. If the obstacles are active or dynamic, if they purposefully respond to the player, the challenge is a game.” If an “intelligent agent” is trying its best to stop you from succeeding, reacting to your interactions, it’s a game. “A game, then, is an artifice for providing experiences of conflict and danger while excluding their physical realizations. In short, a game is a safe way to experience reality.” Crawford’s book is well worth reading still to this day. Though its examples may feel dated, what was true for Star Raiders is still true today. Unfortunately, like an example of how much game design knowledge has been lost through the years , few game designers use these terms today. One game designer who discussed the lack of a shared game design vocabulary early on is venerable Looking Glass alum Doug Church in his essay, Formal Abstract Design Tools , from 1999. This essay takes an example game — Super Mario 64 — and extracts “tools” from its design that can then be used more generally. The first tool is Intention : “Making an implementable plan of one’s own creation in response to the current situation in the game world and one’s understanding of the game play options.” This is a seemingly clear device that defines how Super Mario 64 plays. The second is Perceivable Consequences : “a clear reaction from the game world to the action of the player.” Another strong staple of Nintendo games in general. What’s important to note here is that these tools are examples of what you can take with you from another game. In the essay, they are then applied to other games theoretically. You can certainly use them if you want to share some of the design sensibilities from Super Mario 64 with other games, but the point is to show you how Formal Abstract Design Tools can be devised and used across game design to generalise concepts that games can share. This is further illustrated by the tool Story : “The narrative thread, whether designer-driven or player-driven, that binds events together and drives the player forward toward completion of the game.” A tool that can easily be generalised, and also serves as a reminder that stories drive the player’s motivation. What’s fascinating with this essay is that it’s a framework and conceptual starting point. It even states directly that “this article was not intended to be exhaustive or complete,” and that “[i]t’s a justification for us to begin to put together a vocabulary.” Still an insightful essay, and could’ve been a starting point for real work in this area, but now instead serves as a reminder that we’re several decades further along and still haven’t figured out how to talk about game design. The quest for abstraction was never completed. The next design treatise is often referenced by game educations, and it’s the MDA Framework, where MDA stands for Mechanics , Dynamics , and Aesthetics . The paper itself was written by three game design heavyweights, in Robin Hunicke, Marc LeBlanc, and Robert Zubek, and was developed between 2001 and 2004. It begins with a lofty ambition: “We believe this methodology will clarify and strengthen the iterative processes of developers, scholars and researchers alike, making it easier for all parties to decompose, study and design a broad class of game designs and game artifacts.” There are a few key concepts in the MDA framework that are not too dissimilar to Doug Church’s sample tools. One is that “the content of a game is its behavior — not the media that streams out of it towards the player.” In other words, games are “systems that build behavior via interaction.” This is a foundational assumption. Many types of games are bought, played, and then shelved as completed (or not) by their players. Those types of experiences are not what the MDA framework is primarily addressing. With this grounding in mind, mechanics “describes the particular components of the game, at the level of data representation and algorithms.” It’s the conclusion of the paper that “all desired user experience must bottom out, somewhere, in code.” Dynamics “describes the run-time behavior of the mechanics acting on player inputs and each others’ outputs over time.” A layer that is greatly affected by the sum of both mechanics and aesthetics. “Seemingly inconsequential decisions about data, representation, algorithms, tools, vocabulary and methodology will trickle upward, shaping the final gameplay.” Aesthetics “describes the desirable emotional responses evoked in the player, when she interacts with the game system.” The sum total of everything, in a way, but also how we choose to represent it. These three components can be considered “separate, but casually linked,” and should be used as lenses through which you can look at your game design. An important aspect of this is that players will generally see the aesthetics first, while developers often obsess over the mechanics. This difference in view is important, and the framework urges you to bridge it by switching your game design perspective to one focused more on aesthetics. One way to do this is by employing Marc LeBlanc’s “ 8 kinds of fun ,” sometimes referred to as LeBlanc’s Taxonomy. A setup that looks at what combination of eight key emotions you are trying to emphasise. Greg Costikyan, another veteran game designer, suggested in 2002 that “[t]o understand games, to talk about them intelligently, and to design better ones, we need to understand what a game is, and to break ‘gameplay’ down into identifiable chunks. We need […] a critical vocabulary for games.” This piece hits off with “if it isn’t interactive, it’s a puzzle, not a game,” based on Chris Crawford’s musings in his early book on game design, The Art of Computer Game Design, from 1980. So interaction is what separates a game from a puzzle. But interaction in itself isn’t good enough. There also needs to be decision making; “interaction with a purpose.” To make decisions relevant, you need goals . Ways to succeed or fail and choices to make along the way. But those goals cannot be trivial to achieve, or you may get bored instead. To make the goals non-trivial, we need struggle . “We want games to challenge us,” writes Costikyan. “We want to work at them. They aren’t any fun if they’re too simple, too easy, if we zip through them and get to the endscreen without being challenged. […] That isn’t to say that we want them too tough, either. We feel frusrated if, despite our best efforts, we wind up being slogged again and again.” The last concept Costikyan identifies is endogenous meaning . To describe what it is, he uses Monopoly money as an example. “Suppose you’re walking down the street, and someone gives you $100 in Monopoly money. This means nothing to you; Monopoly money has no meaning in the real world. […] Yet when you’re playing Monopoly , Monopoly money has value; Monopoly is played until all players are bankrupt but one, who is the winner. […] Monopoly money has meaning endogenous to the game of Monopoly .” To summarise Costikyan’s essay, a game is “[a]n interactive structure of endogenous meaning that requires players to struggle toward a goal.” The game designer’s job is then to complete that whole. Next up is Nicole Lazzaro’s excellent Why We Play Games: Four Keys to More Emotion in Player Experiences . Lazzaro further elaborates on the MDA Framework’s type of thinking, particularly in what the framework refers to as Aesthetics. “Games are structured activities that create enjoyable experiences,” starts the paper. “They are easy-to-start mechanisms for fun. People play games not so much for the game itself as for the experience that game creates: an exciting adrenaline rush, a vicarious adventure, a mental challenge; and the structure games provide for time, such as a moment of solitude or the company of friends.” To write Lazzaro’s paper, her game design consultancy XEODesign “went off in search of emotion and found Four Keys to releasing emotions during play.” Each such key is “a mechanism for emotion in a different aspect of the Player Experience.” The first key is The Player: The Internal Experience Key . “Generate Emotion with Perception, Thought, Behavior, and Other People.” In the text, it’s also called “games as therapy.” A player that plays because of this key is playing to clear their mind, feel better, avoid boredom, or being better. “Games with this Key stimulate the player’s senses and smarts with compelling interaction.” The second key is Hard Fun: The Challenge and Strategy Key . “Emotions from Meaningful Challenges, Strategies, and Puzzles.” It achieves this through emotions such as Frustration and Fiero (“an Italian word for personal triumph”). “Games with this Key offer compelling challenges with a choice of strategies.” The third key is Easy Fun: The Immersion Key . “Grab Attention with Ambiguity, Incompleteness, and Detail.” Also referred to as “sheer enjoyment of experiencing the game,” dipping into senses of wonder, awe, mystery, and so on. “Games with this Key entice the player to linger, not necessarily in a 3D world but to become immersed in the experience.” The fourth and final key is Other Players: The Social Experience Key . “Create Opportunities for Player Competition, Cooperation, Performance, and Spectacle.” Crucially, both inside and outside the game itself — community can meet the emotional goals of this key just as much as in-game features. Teamwork and camaraderie. Rivalry and competition. Schadenfreude and amusement. “Multiplayer games are the best at using this Key, although many games support some social interactions through chat and online boards.” The paper provides a more clear description of each key, but what’s incredibly useful with these keys overall is that many games can benefit from supplementing a focus on one of them with additions of another. For example, if your game is highly competitive (“Other Players”, “Hard Fun”), it can still be nice to have a change of pace organising inventory or fiddling with other menu bits between sessions (“Easy Fun”). Jesse Schell’s The Art of Game Design: A Book of Lenses is one of the most commonly mentioned books on game design. If there was any such thing as a standard volume on game design, this would probably be it. It’s an excellent book and has two major elements that makes it useful (in my opinion). First of all, the chapters themselves frame many key elements of game design. First comes the chapter The Designer Creates an Experience , which clearly emphasizes that the game “enables the experience, but it is not the experience.” This is an important thing to understand if you want to grasph Schell’s perspective on game design. From there, the book goes both broad and deep. The Venue where you play the game plays a role. The Game itself, the Elements , Theme, and Idea it’s composed of. That it’s improved through Iteration and made for a Player and made to create an experience in the Player’s Mind based on the Player’s Motivation . To achieve this, there are Mechanics that must be in Balance . There can be Puzzles , Interface , Interest Curves , you can tell a Story , allow Indirect Control , and build a World . As you can tell, it’s a very complete view. This also doesn’t list the many more practical pieces of advice that the book goes into, such as how to make a Profit , the value of Technology and Playtesting , and what Documents you may need to write and how. The second thing the book provides is just over a hundred “lenses.” Each lens is something you can look through when you analyse your game. They’re available in a deck of cards that you can get fairly cheaply and that has great utility whenever you need inspiration in your game design work. An example lens is the Lens of Balance, which tells you to ask the questions “Does my game feel right? Why or why not?” The struggle to find a good game design language is the subject of Anna Anthropy and Naomi Clark’s book A Game Design Vocabulary as well. It takes a more high level approach than Schell’s book, perhaps most similar to Greg Costikyan’s article mentioned earlier. “You’d think 50 years would give game creators a solid foundation to draw from,” writes Anna Anthropy in the introduction to the first chapter. “You’d think in 50 years there’d be a significant body of writing on not just games, but the craft of design. You’d think so, but you’d be disappointed. […] I see evidence that what both creators and critics desperately need is a basic vocabulary of game design.” First are Verbs and Objects , and the relationship between them. Such relationships determine the Rules of the game you are making. Verbs are actions. Objects are things that can perform or be affected by actions. Perhaps a Hero, controlled by the player, can Shoot and an Enemy can Die. Suddenly, you have also added choices. If there are two enemies on your screen and you must pick which one to shoot. Given that the game is made up of Rules divided into Verbs and Objects, then Scenes are the “units of gameplay experience that unfold during and create the pacing of a game as it’s played.” Many tabletop role-playing enthusiasts swear by scenes in this way, where scenes have beginnings, things at stake, and ends. Both like and unlike directing a movie. More specifically in Anthropy’s vocabulary, “[t]he purpose of scenes is to introduce or develop rules, to give a chance for the game’s cast — its verbs and objects — to shine, and a chance for the player to understand something new about them.” Finally, Context “is what helps a player to internalize those otherwise-abstract rules that make up our game.” Spiky things are dangerous, red barrels explode, and nazis are (in fact) the baddies. Context affects many things, and is where much of a game’s content comes in. But it’s also what determines how we compose the scenes for our game. However. This is only half of the book. The second half, written by Naomi Clark, looks at a game as a conversation between the game and the player. It dives more into the difference between authored and emergent stories, and how games can both be a vehicle for the former and provide unique room for the latter. Another way to look at and talk about games is by breaking them down into their mechanical components. In the book Building Blocks of Tabletop Game Design , Geoffrey Engelstein and Isaac Shalev have compiled a selection of tabletop game mechanics in encyclopedic form. This book starts from Game Structure , calling out games that are cooperative, competitive, team-based, solo, and more. It goes from there into Turn Order and Structure , talking about claim turns, roles, random turn order and many more. Then Actions (meaning player actions), in some of its many forms. Resolution , for handling outcomes when the outcomes are contested. Game End and Victory collects some favorites (and criticised but common ones, like Player Elimination). Uncertainty then deals with topics like short-term memory limits and push-your-luck mechanics. In its broader sections, the book then compiles details on Economics , Auctions , Worker Placement , Movement , Area Control , Set Collection , and general Card Mechanics . Many tabletop designers swear by these terms. They may say they’re designing a “worker placement set collection game,” for example. Most of the time, these mechanics are known quantities and designers can talk about them in terms of how well they fit with a game’s themes or other mechanics. It’s also a handy way to make experiments. For example, “worker placement with a common pool of workers” makes sense as a mechanical idea, and gives you something to build on top of. These are not quite definitions per se but descriptions of game elements that are common enough to be generalised. You should read and explore the craft of game design as much as you can. But you shouldn’t strive to define it in general terms. As you can see in the previous examples, even when there is overlap, there is never any real consensus. Games and game design are nebulous things and we all find different things important. Once you design your own games you should make up your own terms too. Don’t put effort into complying with definitions you didn’t make and don’t discuss what definitions mean or which definition is right. All of that time will be wasted compared to the time you put into figuring out what your game is about. Make up your own words that can inform how you want to design games. But by all means, do so by taking inspiration from the wealth that is out there, and use the work of great designers to inform your own designs.

0 views
Playtank 2 months ago

Game Economy Design

Hey there, I’m Keelan. For the better part of my career in the games industry I’ve worked as what’s known as a Game Economy Designer. Game Economy Design predominantly concerns itself with the relationship that the resources within your game have with the mechanics of your game. If this sounds like a very nebulous definition, it’s because game economy design (and really, economics) is perhaps better thought of as a lens through which to understand your game than anything else. Still, I want to do more than wax philosophical about the nature of high-minded economic principles like utility and feedback loops. Yes, there will be some of that in this blog post, if only because I think it’s important to understand the abstract concepts before getting our hands dirty, but rest assured that I’ll be demonstrating some of the tools and methods I use to perform Game Economy Design. These tools and methods help us to measure and balance the distribution of resources within our game by taking a number of key economic concepts into account: If it’s true what Frank Lantz, Director of NYU Game Center wrote, that “Games are basically operas made out of bridges”, then Game Economy Design concerns itself with the tempo of the music and the points of slack and tension among the bridges. So, what do Game Economy Designers measure and how do they measure it? Let’s discuss. Systems flows describe the directionality of resource exchange such as from gold to weapons when you buy an item in a merchant system, whereas points of interactions describe the act of buying and selling. System flows and points of interaction can range from simple to complex depending on the scale of the system (consider that a collection of systems is also a system) and on the kind of player experience we want to create. On the one hand, we may want to tie player progress to a number of interdependent systems with varying complexity such as items, upgrades, player stats, level ups and skill trees. On the other hand, we may prefer taking a more straightforward approach to system interactivity in a purchase flow – a player doesn’t want to jump through hoops to enjoy something they’ve spent money on (or do they? See: Battle Passes). Common components of system flows in games include the following*: *but are limited by my desire to voluntarily express them in a spreadsheet. Progression curves are the mathematical models governing how our gameplay experience changes over time. How many experience points should a player need for each level up? How much damage should a player do over time? How should enemy HP grow over time?  This is where some level of algebra is helpful as we’ll be defining these curves as pen-meets-paper (or data-meets-spreadsheet). Some of my favorites include: Utility describes how much we value something, ideally in a way that we can compare against other things. While the economic concept of utility is fascinating to discuss in the abstract (consider the myriad of factors that determines how much value we place on a bottle of water – time, place, and presentation to name a few), mathematically representing utility in economics is quite the headache. Luckily for us, we’re measuring the economy of a game and not that of say… the consumer car market .  When it comes to measuring utility within our game, we might be happy enough to look at transference rate within a system. From a game balance perspective, we may look at the amount of stats provided relative to the gold cost of our weapons. However, in the interest of better understanding the player perspective we might alternatively be interested in knowing the number of enemies a player must defeat to afford the weapon. Even better, we could try to understand the time-investment (“farm”) required for the player to defeat those enemies and acquire that weapon. Once we’ve arrived at a metric of time, we’re truly thinking about our game from a game economy perspective because ‘time’ is a universal resource that governs much of the player experience. Another common ‘universal resource’ that governs the player experience is money. While it doesn’t necessarily explain why one store bundle performs better than another, it does at least partially explain why more players buy Battle Passes than store bundles. Battle Passes typically contain the equivalent of multiple store bundles in terms of content for a fraction of the price. This is where things get fun. By manipulating the way our various progression curves interact with one another, we can change the nature of feedback loops in our game. We can speed up the income rate of one or more resources or slow them down. This allows us to manage the frequency and intensity of challenge, reward and relief within our game over time. Feedback Loops are most easily identified in Player Data when we can observe cause and effect in a (hopefully) large sample size. However, the job of identifying them in Player Data is made substantially easier when we’ve first set about attempting to identify them in simulations and before that, in models. By dictating our expectations about the nature of the interconnections between our systems in models, and attempting to observe them in our simulations, we build the muscle memory necessary to observe them in player data. TL;DR: Spreadsheets containing system inputs, models that represent the behavior of those systems over time, and simulations that inform the behavior of the system. Diagrams are important not only for refining our own understanding of a system, but also for communicating that understanding to others. The most common uses for diagrams in Game Economy Design are economic flow diagrams, where we map out system flow and points of interaction. Here’s what that might look like in a simple merchant system: But you could describe a more complex system as well: Models are our way of representing how we intend for our gameplay experience to change over time. These are foundational to Game Economy Design. Not only are they used to concretely balance progression curves within systems, but they are also used to balance larger abstract design intents within the player experience. For instance, we may use a model to define specifically how many experience points are required at each player level but we may also use a model to define our design intent for the transference of time-to-levels, or how much time our player should spend accruing those experience points in order to reach some level. The latter example is abstract because every player will play our game differently, but we can temper our game balance using simulations that dictate the conditions under which we achieve our design intent. Simulations are where we make assumptions about how our players will behave within our game and then use those assumptions along with our defined system parameters to determine whether or not the balance of our systems, when experienced by our assumed player behaviors, achieve the intent of our systems. We may have a model that indicates a time-to-level based on enemy health data and player damage estimates. However, for the sake of testing our system, we might assume that we have a ‘more skilled player’ which achieves player damage 20% higher than our estimates and a ‘less skilled player’ which achieves player damage 20% lower than our estimates. We could then “simulate”* the difference in the time it takes for these two player types to complete our game or other relevant aspects of our design goals. Additionally, as more players play our game, we’re able to get a better understanding of how different players will experience our game and use that knowledge to refine our assumptions. We may discover that players can be significantly more skilled than simply achieving 20% higher damage, or significantly less skilled than simply 20% less. These observations will yield more accurate simulations, which in turn will result in a more informed game balance. This is where player data comes in. *Note: I’m using simulate in quotations here because this example is a fairly obscene over-simplification. If there’s enough interest, I’ll write up something more in-depth about this fairly under-utilized design practice. Player Data allows us to observe how our game is experienced in the wild, as opposed to how we believe the game will be experienced in our models and simulations or how we experience it as the developers. This is where we can finally see how close our design intent is to the real player experience. Using this information, we can rebalance our systems to better achieve their intent – both individual systems and the game as a whole. Our more abstract models, those that combine multiple systems, are especially likely to benefit from Player Data as the interconnections between the systems will become more apparent. For example, we may discover that our model for time-to-level presumed that a player would have acquired a weapon at level 2 only to realize that a poorly balanced gold economy prevented players from acquiring one until much later than we intended, significantly impacting early progression within our game. So there you have it, Game Economy Design in a nutshell. I genuinely hope that if you’re reading this, you’ve found it more than informative; I hope you’ve found it useful. If not, please reach out and voice your (hopefully well-worded) criticism. After all, much like Game Economy Design – really much like everything – this only gets better through critique and iteration. The diagrams, models, and simulations we make are always only our current best understanding of our designs, and we designers are typically in a constant struggle of improving our understanding of our designs as they change and evolve (roadmap and documentation be damned). These might represent the toolbox for game economy design, but the real “How” is communication and iteration. Do the work, show it to your team, be open to criticism, then do it again and again until it’s polished – that’s the real how. Until next time, Keelan Transference of Resources – The function of one or more units becoming another. Quantifying Damage per Second and other factors helps us understand Time-to-Kill which alongside XP-per-Kill and XP-per-Level tells us Time-to-Level. Utility – Involves attempting to find a universal measurement of value within our game that we can attribute to all resources. Perhaps, like me, you’re a fan of League of Legends (a fascinating game for studying feedback loops, an awful game for hair retention). If so, you may have come across the term “ gold efficiency ” when observing high level players comparing one item to another. In essence, these players are normalizing the stat-per-gold across each item in the game to determine which items give them the most stats for the gold invested; which items provide the best utility.  Relative Strength of Feedback Loops – Involves understanding how and why transference may change over time. For instance, different aspects of our design may decrease Time-to-Kill during our mid-game. Perhaps Enemy health and player stats increase linearly within our game, but we introduce combat synergies over time that increase the influence of player stats on damage output. How might this impact Time-to-Level? What about the transference of other resources within our game, such as the gold income per hour?   Conditional Constraints – requirements that gate access to systems or content until specific conditions are met such as player levels, crafting requirements, or story milestones. Variance (RNG) – ways in which we generate different outcomes from the same input– think randomly rolled loot tables in treasure chests, random encounters, or randomly assigned modifiers on a crafted item. Efficiency Modifiers – Things that impact the strength of the system flow, on which the system is dependent. The impact of player level, inventory, and skill tree allocation on damage output, for instance. Linear Progression – Perhaps the most trustworthy of all progression curves. The same input always yields the same output. This is useful for systems that you want to build your experience around– perhaps you want players to start your game struggling to defeat a single enemy and but eventually be mowing down hordes of enemies- assign a linear progression curve to enemy HP and then get wild with the progression curves on your various damage-generating systems.  Exponential and Logarithmic Progression – USE THESE WITH CAUTION. Exponential Progression Curves have a tendency to invalidate designs and wreck ecosystems over time. Exponential Curves do this by rapidly increasing the output for each unit of input and Logarithmic Curves do this by rapidly reducing the output for each unit of input. These become a lot easier to manage when we apply fractional modifiers to the curve or when our systems have definitive endpoints, such as a maximum Player Level. Sigmoid Curve – Also known as the “S-curve”. I’ve got to be honest, I haven’t found a great application for a Sigmoid Curve in a single system, but I think it’s a great curve for demonstrating a player journey. For instance, a player’s power progression journey in an ARPG might look like several Sigmoid Curves in a trench coat.

0 views
Playtank 3 months ago

Tabletop Roleplaying as a Game Design Tool

The goal is to allow the player and their avatar to occupy the same emotional space. At Graewolv , while exploring the concept of the demon-powered first-person shooter , one question that kept nagging at my brain was who I was actually playing and why it led me to shooting people and interacting with demons in the first place. It bothered me that this didn’t have a straightup answer, or at least an answer that could make it comfortable to “occupy the same emotional space” as the character I played. Shooting people can be fine in a military shooter. “You’re a soldier following orders” usually works, even if it carries significant historical baggage . But when put in another pair of boots it feels weird. Shooting people becomes murder. Joel in The Last of Us murders some of the few remaining medical experts in the world in cold blood. He is written well enough — and we get enough time to sympathise with him — that we can still see Joel as the good guy. In any attempt at an objective analysis, he’s a selfish psychopath, but we can understand his motivation and pick his side over that of the nameless doctors in the game. In fact, I’m somewhat bothered by how easily some players can say “I would’ve done the same.” But in the end, we feel like we know Joel, which makes us side with Joel. I wanted this to be resolved for VEIL too. You commit despicable acts of violence and this needs to be motivated so that the player doesn’t get uncomfortable occupying this emotional space and so that the violence doesn’t become too gratuituous. These lines of thought made me look at role-playing as a design tool for exploring game concepts further. In this post, I’ll cover how I worked with it. Hopefully it can be interesting to other game designers out there. It’s a tool I still use whenever there’s a chance to do so. If you’ve done similar experiments, I’d love to hear about it. Write a comment or e-mail me at [email protected] . Note that some of the stuff I’m about to share in this post is the property of Graewolv and is shared with their kind permission . Special shoutout to the incredible David Brochard , who drew all the concept art . Wishlist VEIL on Steam: https://store.steampowered.com/app/2436490/VEIL/ Join the VEIL Discord server here: https://discord.com/invite/7JxqcDZ9Pq I started playing roleplaying games around the age of 10. It’s been my favorite hobby ever since, with a few breaks at times when life got in the way. My approach has always been somewhat experimental, trying to find new ways of playing or just variations on existing ways, and rarely playing the same thing through more than one campaign. Experiments like building a scenario where all of the information is within the group, putting all conflicts between players , playing with multiple game masters, no game master at all, or playing court intrigues based on the assassination of Gustav III . This has led me to focus on a number of things that I think make role-playing games unique and that makes them excellent as game design tools beyond being games in their own right. Roleplay can be empathetic , where you try to imagine how another person thinks or feels and you act it out. You can roleplay an asshole, like playing Cyberpunk 2077 as a Corpo, because there’s a detachment between you personally and the avatar you are playing. It’s engaging to make decisions based not on your own morality, but on your interpretation of this other person’s morality. Real or imagined. This is equally true whether you are a player or a games master. Every participant can engage in empathetic role-play. It also stays true with one character on several players, one character per player, or multiple characters per player — we can still engage in empathetic role-play. It can be exploratory , where you act out different things and find out what happens. Basically the FAFO (F*ck Around and Find Out) of role-play. Insult your friends. Kill the princess and rescue the dragon. Sail off on a ship instead of going down into the dungeon. Since the only limitation you have in role-playing is your own imagination, this element is one of the most unique that the hobby has to offer. It can also be used for more than just entertainment, such as exploring what may happen in a second Trump presidency . Exploration is related to empathy, but doesn’t have to be. It can also be purely for fun or as a method for pseudoformalised conjecture. It can be mechanical , where you play through situations using a platform of rules to see where the rules lead. Maybe you want to have rules for detailed mech customization, for realistic firefights or fencing, for exploring the unknown, or for leveling up and unlocking new tools to play with. This is very similar to hex-and-counter wargaming, which incidentally is also where the roots of role-playing games are firmly planted. It’s an effective way to see where the game may need more or fewer choices, or if you may have forgotten something that needs to be designed in more detail. It can also be narrative , testing or fleshing out the story or world-building. Role-playing games are extremely dynamic and pretty much all of the previously mentioned reasons to role-play clash fundamentally with the idea of a prewritten plot , but as a tool, narrative role-play is great. You can try out different villains to see how they work and see what kinds of interactions players expect, and you can work with language in interesting ways. In one test session a few years ago, the first question that came up in play was, “how do people in this world communicate?” Something the world-builder at the time (me…) had completely overlooked that became obvious through play when the characters needed to talk to each other. Note that these four forms of role-play are not an attempt to classify or define anything, and they definitely don’t cover the full breadth of the role-playing game hobby. They are often mixed together in different ways and sometimes hard to separate from each other. These four ways of approaching role-playing are consciously structured to answer relevant questions , and you should hopefully see the interesting space that starts to emerge between them. What the four forms help you do is push the game experience around the table towards empty spaces in your design. It helps you ask interesting questions and provide compelling answers. All of those answers won’t be what you actually use, but as a design process, role-play can be one of the fastest ways to explore your designs. All you really need is imagination. You will be playing the characters and having the experiences you want your game to offer, without having to finish your game. We can use empathetic role-play to sample our characters, factions, and conflicts. To figure out ways to make the world we are building or the villains we are introducing more compelling. It can also show us where our world-building may be missing something. If the hero may need a foil, for example, or if the conflicts sound a bit undercooked when put in motion, or become repetitive faster than we had anticipated. Exploratory role-play allows us to push the boundaries and see what happens. It’s a great opportunity to let developers improvise solutions to the problems or missing designs that may come up, and essentially design the game through participation. When someone decides to kill the main quest giver, for example, that may be something the game needs to solve for. Or when a certain spell or weapon is used in an unconventional way. What’s important here is that you never say no . See where the exploration leads and make decisions after you have talked it through. Take notes, but avoid turning the play session into a meeting. The beauty of the process is that you can just throw stuff out that doesn’t work. Mechanical role-play is a bit more tricky to make use of as a design tool, since it easily becomes a deep rabbit hole of mechanics design that are then only written for the tool and will never translate into its digital incarnation. Some of this can be worth a lot, since it can explain your intentions at a high level. But avoiding time waste is often a careful balancing act. If you focus on outcomes more than specifics, for example how many options you may choose from in customization, how much gold you make, or how much damage is dealt and taken, it’s still a valuable tool since it can hide large complex systems behind the improvised decisions of your players. You want the mechanics to be similar enough to your intended game to feel like it hits the same structural beats as your digital game would without only becoming a clunky version of it. Finally, narrative role-play is quite useful as a tool, since it allows you to take a trip through your broad story beats and see how they connect. If something needs a higher pace, clearer clues, or other changes. In some ways, it’s like a script reading session with some additional improv. It can also make use of random generators like tables and cards to help you create a fitting story for your game or even to decide where you want the narrative to connect to procedural elements. It’s particularly useful for filling in gaps between the story beats you already have in mind. Together with empathetic role-play, you may even get to see how the factions and characters in the game interact over time, and you can surmise empathetically how the story should play out in ways that are hard to do with just a word processor. Let’s look at how to do this, in practice, by first looking at the roles involved. The avatars whose emotional space we are about to share. The role part. If you’ve ever studied journalism, interrogation, questioning, or something along those lines, you should be familiar with the 5Ws (or 5W+H). They’re intended as a shorthand for getting to the meat of a story: Who, What, Where, Why, When, and How? These one-word questions are extremely useful for any form of characterization, regardless of context, since they help you tell a whole story. You don’t need to answer all five at the character level. Some can be answered by the setting or through collaborative improvisation. You can also consciously leave some of the answers blank in order to figure them out through play. Who , of course, asks who was involved. Who did the thing, who was affected by it, and what a third party thinks about it. In journalism, three sources is a kind of golden rule: two people representing the opposite sides, and a third neutral party. Even better if you can have more than just one neutral party. This is a great way to think of scenarios for games too, since the player is often a third party engaging with an external conflict. This was the trickiest one for VEIL, but the decision was to look at you as an occultist for hire . Someone who solves other people’s demonic woes in exchange for money and power. These “someone” were set as four specific factions in the game world, representing tradition, law, crime, and change. With those pieces in place, there was enough friction to create interesting missions. What tells you about the thing that happened. Murder? Injury? Theft? Job opportunity? There’s another journalistic axiom that says, “does it bleed?” Because suffering and bleeding traditionally sells stories, so the more violence or trauma — or risk of violence or trauma — you can push into this, the better. Games rarely shy away from violence in the first place so simply making someone bleed won’t catch anyone’s attention. Instead, this goes into the high level activities that you’re going to engage in. Not the verbs of the moment, but the motivations behind them. You exorcize demons and you take missions connected to that, but you also work for the power players of The City, running their (usually violent) errands. To explore this, a system for generating objectives was created. More on this later . Where lays out the geography of the matter, so you know if you need to care or not. Closer to home tends to mean higher relevance, which is why local news papers fill a role in journalism: you care because you live there. But fantastic cities and other pure escapism works too, just not on the same instinctual level. Even with fantastical environments, it’s usually good to anchor the where in something recognisable. The game takes place in The City. It has districts, it has class struggles, it has all the things you’d expect from a modern city but with a slightly gothic overtone. It’s Gotham City, in a way, but if Gotham City had demons from Hell instead of tragic villains with mental issues. Why is trickier, since motives are not always clear and because opinions may differ. This kid did the crime because they play Dungeons & Dragons says one side, while the other says they were bullied in school. A consulted psychologist chimes in with something about sexual frustration. (Three sources, remember?) What we like the least is when there’s no explanation whatsoever, even if it can also make us run wild with speculation. Cliffhangers exist, after all. But we tend to more easily reach for the obvious explanation. Figuring out why is trickier in real life than for game design, because in game design we already tend to obsess over motivation. The trick is to connect this motivation to the motivation of the characters in the game world. You’re a selfish sort of person that happens to do good by coincidence. An antihero. The reasoning behind this is that a player in an action video game of the VEIL kind, is inherently selfish. They want to get the next reward, collect the loot, finish the level, etc., and going back to Harrison Pink’s point on the avatar and player occupying the same emotional space this fits well with the goal. You pick your employers. You solve your problems. You get your rewards. The rest are a means to an end . When isn’t fifth in relevance, it’s just how I’ve taught myself to remember these words (Who, What, Where, Why, When). It’s the time and the place, in history or the present. When can be very broad, such as “19th century Paris” or “Middle-earth in the Second Age.” It can be extremely specific; “At 03:45 last night.” If a major plot beat in your game is the assassination of a king, then when can also inform you whether something is happening before, during, or after this assassination. You can also leave when blank and figure it out through play, in case it’s one of the issues you want to resolve. It’s not a flashback. It’s not the future. It’s the fictional world’s present, in a noirish gloomy perpetual fall season where it seems to never stop raining. (Because modern game engines obsess over real-time ray tracing, which makes reflections a thing. ) How will be the verbs. Your players’ inputs and intentions as supplied to the systems of the game, and what kinds of outputs they generate. What’s important if you want to make something interesting is to examine this at multiple levels. Your video game will more effectively demonstrate the second-to-second or micro loop of your game; shooting, jumping, taking cover, etc. But what the role-play tool can do is explore the minute-to-minute or macro loop , and potentially even the hour-to-hour or meta loop . Shooting, summoning demons, completing objectives, failing objectives, working for the factions, introducing factions, revealing secrets, collecting ritual materials, getting tricked, etc . Now that we know the roles we will take on, we need to know how to play the actual game intended to explore them. At their core, role-playing games are formalized conversations . You talk, respond to what others are saying, and you may use some rules to generate outcomes that steer the conversation in unexpected directions. The key differences between role-playing systems isn’t which polyhedral dice you roll or whether they take place in Narnia or Night City. It’s how truth is established and which parts of the conversation that we influence with mechanics . Some variants of role-play use a referee, often called a game or dungeon master, that acts as a rules moderator and comes up with parts of or even the entire plot or story of the game you are playing. Others eschew this in favor of collaborative storytelling. The key difference this makes is how truth is established. As mentioned previously, mechanical role-play is always at risk of wasting time if you write complex throwaway rules. Writing a deep combat system for a game that’ll ultimately be a first-person shooter is probably a waste, for example, because you are not actually solving any problems by doing so that you are not already tackling in your game engine. For most role-playing games as tools, you need to touch on some or all of the following elements in your mechanics: There are some practical ways you can approach making your test rules faster: The following example of a role-playing game as a design tool is from work I did for Graewolv on the upcoming first-person shooter VEIL . I served as Design Director for the project for about a year, in 2020-’21, and during that time it fell on me to explore the design in whatever ways I could while working on the early prototypes for the game. It was an incredibly useful tool for me, that helped flesh out the different factions and missions in the game, and it was the key inspiration for this post even if it’s a tool I’ve used several times since. Oathbreaker was written specifically to figure a few things out. As a foray into systemic design (of course), many of its more interactive elements worked better in digital form and were never included. But the playful ideas around changing reality and affecting things through the use of demonic powers were definitely included. My design goals were: Some things were also actively avoided, since they didn’t really help the game’s design: Most of Oathbreaker is a conversation engine. We can set up some scenes and talk through how they play out. Because of this, it doesn’t use any authoritative truth but relies instead on procedural truth via random tables combined with situational truth and table consensus. The digital game itself is cooperative, so it made sense to make Oathbreaker mostly cooperative too. We randomise things together, we create and discuss our characters together, and we generate and complete missions together. Each player does play a single selfish character, so sometimes they may not have enough reasons to cooperate, but then we can explain it using the goals and objectives. Discover more reasons for them to cooperate. With an objectives-based game, it can help to think of a map as the sketch for a movie set. We don’t care so much about how it’s related to other sets, as long as it’s believable enough to work and has some measure of internal consistency. We should also have a good concept of how it looks like, as descriptive adjectives. Role-playing games may refer to the areas on maps like this as “zones,” and the trick to making it interesting is to have enough of them. In the below example, there’s just Mansion, Parking Lot, and Guard House. The mansion itself could just as easily have been subdivided into Kitchen, Atrium, Gym, Entrance Hall, and so on. How detailed we make it is up to us. The beating heart of Oathbreaker is a set of random tables that creates missions. It generates this in a number of steps. First, a Goal is set, which gives you the reward you will be given if you complete the mission. You also figure out which Faction you are working for, and which faction you are working against. Second, a very broad Location is determined. A Faction Claim, since it has to have ties to one of the power groups of the setting. It’s one of six districts of The City and provides some ideas on what you could find there. Third, and illustrated in the screen grab below, you find out what the Mission Structure is, and then generate the objectives this requires. Once all three steps have been completed, you have a mission to play. For Oathbreaker , the focused mechanics approach fit quite well. It has mechanics for creating characters, playing objectives, changing reality, and making demonic pacts. No other mechanics are necessary. Each character is a selfish individual that managed to gain access to the Veiled Path but chose to break their oath and leave as an oathbreaker. When characters are created, each player rolls to find out first who recruited them, what they did for the Veiled Path, who made them leave, and who they tried to find after leaving. Each of these tables only has six entries, so that it’s fairly likely that some characters will share one or more of these. The idea is then that they also know each other and that these connections can be good or bad. This is good grounding for empathetic role-play. Maybe the recruiter was my brother, but also your lover. Or we had the same employer inside the Veiled Path, but left for different reasons. This creates situations where we may not trust each other and where we will automatically start to dig deeper into the game’s world. It’s also great grounds for quickly generating a number of faces that can represent characters we’d encounter in our world. If we missed something at this stage, it will usually be obvious. Soul is measured in dice placed on your character sheet or on the notes representing specific threats at a location. There was never a hard rule for how many of these dice you would start with, or if you should start with any at all. If someone opposed you when you tried to use magick, you’d roll dice from your Soul. Sometimes, only creatures or characters with ties to demons have Soul. At other times, everyone has Soul. It’s a simple dial to turn.. There are two paths in magical tradition. The right- and left-hand paths. Simplified, the saying is that “the right hand giveth, and the left hand taketh away.” What you would see as black magic follows the left-hand path. For this system, which was just a paragraph or two long, the taketh and giveth was used literally. With the right-hand path, you could give someone dice from your Soul; with the left-hand path you could take dice from someone else’s Soul. This way, dice can also be rolled to oppose such an attempt, or to transform into resources, damage, or something else, either for yourself or someone else. It’s an extremely high level abstraction since it made it possible to not commit to anything in particular. Pacts are measured in debts that must be paid off with Soul. If you look at the character sheet above, each of Annie’s two pacts (the one with Tchort and the one with Naamah) has three diamond boxes where none are checked. Each time the demon’s quite considerable power is activated, the player needs to either spend one Soul by discarding a die or check a single box that must then be paid off with Soul later. (The observant reader will also see that you can use the left-hand path to take Soul from someone else to pay this cost.) There was never a hard rule for when a demon’s drawback would trigger, since that was part of what was being explored. As a final note, let’s go over how you can use this tool yourself. This is by no means a checklist of things you must do. In fact, you should only do exactly what’s needed for your specific project and nothing more. If your game has empathetic , mechanical , situational , or narrative components, you may benefit from playing a role-playing game that explores it. But before you do, consider what you want to get out of it. Set up some concrete goals, like what was done for Oathbreaker . Use the 5W+H questions, as many of them as needed, and look at them through the lens of the following. You can skip this step entirely, or you can put extra effort into it at any level of detail that you want. One of my current spare time projects uses a fairly in-depth board game element to test full-scale combat, even though it won’t translate into its digital form. This has been written because I enjoyed it , an element that is certainly more important for hobby projects. With just a page or two, maybe some dice, bring your team together and get to it. There’s no point to any of this if you don’t make use of it. Building a role-playing tool like this can definitely be an interesting intellectual exercise in itself, but the real magic won’t happen until you gather some other people around a table, friends or coworkers, and start exploring your game. Authoritative truth . The game’s referee has the final say on what is true. Usually combined with one or more of the other forms of truth. In some games, the authoritative role can rotate between players or players can have authority over specific parts of the truth. Truth is established by the person(s) with authority. Pre-established truth . Lore. Whole geographies, histories, anthropologies, astrologies, and otheries. Can be your favorite IP, something you’ve written yourself, or what your favorite author came up with and published. Truth is established by what is written before play. Procedural truth . Often in the form of tables, charts, or dice rolls used to generate random outcomes, but it can also be the direct consequence of other forms of mechanics. Any entry or combination of entries could become true by rolling them at the point of generation, but you can’t know what the truth is until it’s put into motion. Truth is established by combining components in a given moment. Relational truth . Using relationships between people, places, or events, to establish what’s true. A hates B loves C trades with D; there’s the basis for our truth. The mechanics will typically push things, challenge things, and cause or handle conflicts of interest, but the relationships are still what are most important. If the king has an agenda, this agenda will affect what the king decides to do, for example. The agenda is true, but what the agenda makes the king do can only be decided in the moment. This is the primary vehicle for empathetic role-play. Truth is established in the moment, based on how things are related to each other. Situational truth . Where we don’t know what’s true in a certain situation until the situation plays out. A combat system won’t tell you who was injured until the dust (and dice) settle, just like we won’t know how casting a certain spell plays out until we’ve cast it and described its effects. We go through the motions, then we know what actually happened. Truth is established after the fact. Unreliable truth . Any variant of truth where the outcome can change after the fact. Maybe you roll to change it, or you collaborate, or you spend some kind of currency, or you rewind time because nah, that’s not what happened. Truth is established only after all unreliable steps have played out. Situations means rules for the kinds of scenarios you expect (or want) to happen in play. This can be very broad and may include genre expectations for your game, such as survival, firefights, construction projects, and so on. What’s important is to leave the potential outcomes open. A situation is the cause , it’s not the effect. It can represent the food shortage, but it won’t present for where to find food. Abilities describe characters. What they can or can’t do, but also as description. This doesn’t have to be detailed, but it can be. One project may need detailed lists or decks of cards that describe different capabilities, while others can use abstractions. This is the toolbox you are providing your characters with. Conflict doesn’t have to be armed and dangerous. It can be anything where there is a clear stake involved. Conversation, bartering, seeking aid, etc. One side wants to gain something and the other side stands in their way or needs convincing, cajoling, seducing, or other methods for changing their outlook. Role-playing games benefit from clear statements or triggers to tell you when a conflict has occured. When the first shot is fired, when the intent is stated; something to tell everyone playing that this is in fact a conflict. The clearer you can make this trigger, the better. But you can also skip this entirely, the way some screenwrights will just say “fight happens,” and then it’s up to the choreographers on the film to make it compelling. Scene is the moment of play, and may change key dynamics. This is where you can apply permissions, restrictions, and conditions in systemic terms. If the situation is a firefight, this is where you can add pouring rain, a particularly tough enemy, or other changes. If the situation presents the shortage, this is where you can collect the resources to solve it and where some other party may stand in your way. The scene is where it all comes together. Generic Mechanics . You can always start from a set of generic rules, such as Chaosium’s percentage-based Basic Role-Playing , Steve Jackson Games’ Generic Universal Role-Playing System (GURPS), Evil Hat’s Fate Core system, or Fantasy Flight Games’ Genesys . The simpler and more accessible the choice of rule system is, the better. Just like you don’t want to waste time building complex systems, you don’t want to waste time teaching them either. Proxy Mechanics . A lightweight version of using a generic system is to use proxy mechanics. This is when you take something like the combat system from Risk to represent battles, and perhaps use the cards from the board game Root to add some flavor. Using a proxy mechanic works best if it’s one that all participants already know. Focused Mechanics . You can also make extremely specific rules intended to model things that are unique about your game. Perhaps character customization is important to your game, and you decide to represent all the different parts with cards that let players have fun with the main ideas of this concept. Or you want to have a suppression system that allows you to force enemy AI to keep their heads down, so you model a simple rule system for only that rather than combat as a full simulation. Picking one or two things to turn into mechanics can be very effective, and lets you zoom in on exactly the things you want to explore while skipping everything else. Generators . Whether using decks of cards, random tables, or online generators, making use of random generators is a very powerful tool since you can construct them in such a way that they leave interesting blanks for you to fill during play. Figuring out who the player’s avatar is , what motivates them, and how they are connected to the world they live in. Empathetic role-play, considering what motivations the world provides based on the key “demon-powered” elements of the setting and making it plausible enough not to cause dissonance. What kinds of factions and different interests could exist in this world based on the player and how to generate conflict from the player’s goals. More narrative than empathetic, but one of the most effective parts of the tests when I look back at it today. Experimenting with missions, objectives, success, and failure . Mechanical role-play , as a way to figure out which kinds of missions felt more compelling than others, but also narrative role-play since it implied what kinds of story beats we’d be interested in pursuing if we took a more narrative direction with the game. Combat was largely ignored, because it would be designed in the first-person shooter in some detail and Oathbreaker couldn’t really solve any issues. Enemy design was also ignored, except as exploratory role-play to find inspiration on what kinds of opposition could be encountered in The City based on the factions involved. Theme . Start with a central theme stated as cleanly as possible. There are demons beyond the veil that are powerful enough to control reality. Agendas . Move on to the different agendas that the theme provides. Wanting to control the demons. Wanting to serve the demons. Wanting to hide the demons. Groups . Connect groups to the agendas, whether they are for, against, or neutral towards them . Law enforcement; those who want to hide the demons and maintain the status quo. Individuals . Populate the groups with individual characters. Emmet the Corrupt Cop, working for those who want to keep everyone in the dark. Authority . Decide what kind of authority you want. The default tends to be a referee, but it’s not necessary, and for a more collaborative team of designers you shouldn’t have authority that is too centralised or bottlenecked to a single person. Mechanics . Use proxies, think about situations and abilities, and dig into what characters can and can’t do, as well as the role of luck in the mechanics. Randomisation can be important to a game in order to generate tension through uncertainty, but in role-play as a tool, it can actually distract you from the conversation. Only add randomisation, success, failure, and so on, if it’s important as a representation of what your game is about. Modularity . Since systemic design is my jam, and in many cases this benefits from a modular approach. If you can take any system and decide whether it’s active or not in a playthrough, this can help you zoom in or out as you need to. Oathbreaker does this in several ways, not least of all by making some of the concept’s core elements entirely narrative, such as the magick.

0 views
Playtank 4 months ago

Challenges to Systemic Design

Systemic design comes down to making objects and rules and inviting the player to interact with them. This sometimes clashes with game design at large or the expectations of external stakeholders. This post is dedicated to some challenges that are facing systemic game design right now . It won’t go into broader problems like financing or marketing — not in this post. This one is focused on design. I would also love to hear about the challenges you are facing, as a comment or to [email protected] . Indie game developer Mike Bithell once tweeted that game design tends to favor the past five years’ most prominent hits. I’ve tried to put this in context in the past, writing about different broad “eras” of game design , but this is a considerable challenge for game design overall. Maybe the biggest one. Recency bias is one of the root causes for many of the other challenges described in this post. The only way to overcome recency bias and broaden your personal references for games is to play games from different eras. To push yourself out of the five-year recency bias. Playing games from genres you don’t normally play and engaging with games and gaming positively rather than through hearsay or preferences. Play lots of games and you will find both gems and turds along the way. Over time, this will make you a better game designer. Allegedly, Quentin Tarantino used to watch around 200 movies per year. Maybe as a designer you should take 30 minutes every morning to just try a game you wouldn’t normally play. Like a concept artist doing warmup sketches. Eventually, you’ll at least try as many games as Tarantino watched movies, and this will broaden your frame of reference. Call of Duty , which is a first-person shooter, has a sprint button that boosts your movement speed; therefore a game cannot be a first-person shooter without a sprint button. This line of reasoning is design reductionism. Portraying a thing as represented by a specific part, thereby reducing the thing to this part. You can extend the same kind of argument to almost any genre or game, and sadly this is very common. Many discussions on definitions in game design become reductionism. Not always intentionally, but whenever we say “X is not a Y because it doesn’t Z,” we’re falling into this particular trap. Two ways where reductionism become game design obstacles are as denial and as obligation . X doesn’t have the feature, so we shouldn’t have it either ; or, X has the feature, so we must have it too. One way to avoid reductionism is to remember the Mechanics, Dynamics, Aesthetics (MDA) framework and its conceptual division and to categorize what you may be reducing accordingly. If you look at sprint in Call of Duty (CoD) as a mechanic , for example, the running for cover to regenerate your health is the dynamic it leads to in combination with other mechanics. This means that a game that doesn’t have the regenerating health or even any cover to run for doesn’t benefit as much from a CoD-style sprint mechanic. If you borrowed only the mechanic, expecting the dynamic, you’d be disappointed. Since we don’t really have an established language around game design, and genre definitions lack unanimity, references to other games easily becomes the only common ground we have. But this easily leads to “reference tennis,” where you are bouncing different game references back and forth until someone mentions a game the other party isn’t familiar with, thereby dropping the ball and either ending the conversation or conceding it in some direction. This is not conducive of constructive design work. It’s often the worst possible kind of reductionism, or it’s simply a game developer form of might makes right. Avoiding reference tennis and designing by reference requires that you move the conversation to your own game. This is where game design pillars , established facts , and a playable game with clear problems that require solving come in. Actively avoiding references to other games during a game’s earliest design stages is the best way to try to build confidence in your design. Describe the experience, the emotions, the themes and mechanics; just don’t use other games to describe them. There’s little use in trying to boil something as complex as a video game down into a single hook or elevator pitch line, because this often forces you to say something like “the mechanics of X plus the art style of Y,” and that will have as many interpretations as it will have listeners. Designing by committee is where no one dares to have a vision and everyone defers to everyone else. It either leads to no decision-making at all or to decisions that are as vanilla as they can be so that no one in the committee risks feeling sidelined. As a colleague liked saying, it’s the heat and the pressure that makes the diamonds. Creative discussions, constructive disagreements, making things someone feels strongly about, and scrapping things that didn’t work out even when someone did feel strongly about it. Game development can’t afford fragile egos and also requires a diversity of skills that makes it a poor fit for auteur directors. Put a bunch of experts in a room and let them be experts. In reality, the only way to disband the design committee is to find people you can talk to and work with in an open and constructive manner. People you trust and who trust you. It also helps to have a clear vision, with the already mentioned pillars, facts, etc. Making a game that is in one way or another extremely close to something already on the market can be an efficient way to make a buck or two. Not always, of course, but the number of games that carry a World of Warcraft painted aesthetic, make use of extraction shooter mechanics, or strives to be another roguelike, Minecraft , or deckbuilder speaks for itself. Like reductionism, this often comes from risk aversion. If you see someone else demonstrating the success of a thing, you imagine that you can skip directly to the profits by making a similar thing. This is sometimes called the packaged goods model , where marketing is functionally more important than the product being marketed. Coca Cola vs Pepsi marketing often tries to sell an identity more than a beverage, for example. But games are not packaged goods. Games are creative products where gamers can express themselves through play or experience something outside of themselves. Gamers are also highly likely to vote with their wallets if you only give them something that is a repackaged version of something else. Some trends die faster than they appear, and it’s hard to know this before you get started. Considering how much business in game development that is handled by people from packaged goods industries, this issue is probably not going anywhere anytime soon. But please, as a designer, try not to chase trends. You don’t have to make the next extraction shooter survival game. When Kane returned in a coma with that thing clinging to his face, you had no clue what it was. It frightened you nonetheless. Its strangeness, its aliennes s, frightened you. But that terror can’t be replicated anymore. We’ve labeled the creature a “facehugger” and made it available as plushies, on mugs, and adorning the jewel cases of the special collector’s edition DVDs we hold on to but haven’t watched for fifteen years. Yet, more Alien-branded games are made. More scenes with facehuggers are featured, often predictably. It’s no longer a creative choice, it’s a must-have. Something to check off a list when we’re on Alien safari. Android, check. Distress call, check. Facehugger, check. It’s the same when characters in The Mandalorian keep joking about how bad Storm Troopers are at shooting. That was never a joke : it’s something the fans made fun of. To the Storm Troopers, what they are doing is real and most definitely not a joke. All of this is IP tourism. It adds nothing new, it doesn’t contribute anything. It only repeats the key selling points of a franchise either as fan service or as a lazy attempt to retain an existing audience by using self-referential in-jokes that only the “real fans” will get. In my opinion, the best games in the Halo franchise were Halo: Reach and Halo 3: O.D.S.T , simply because they did things that weren’t just IP tourism but took the IP to new places and painted the war against the Covenant in a different light. We didn’t need more Master Chief, even if the original games set the stage, and we got the Fall of Reach story and a noirish detective story with Halo framing instead. If you ever have a chance to work on a cool IP, don’t be an IP tourist. Build a real experience that explores that IP in some way. The key to Sid Meier’s classic statement on decisions is the word interesting . A game is a series of interesting decisions. If you remove the emphasised word and the player is making decisions that were all created equal or from only partial information, then the player no longer has any meaningful decisions to make, they are just along for a ride . I always felt that the style of choices you made in series like Mass Effect were this type of choice. You could choose to be altruistic or evil and you’d get an immediate often spectacular response, but the longterm effects were usually not that relevant. From your own intentions, you could end up making a right or wrong choice, but it would often be either completely obvious or entirely opaque and you’d be picking mostly as a gut reaction. Someone dying in a cutscene at the end of the game isn’t the consequence of an interesting decision, it’s just a shallow reminder that a decision was made. If you are interested in a deeper take on choices and consequences, you can watch Bob Case’s excellent video on the subject . To me, this is where systemic design truly shines, as interacting systems will be restricted more by which inputs and outputs you allow than by content. Remakes have always been a thing in video gaming, ever since the early days. But a trend that may have started with the Halo: Combat Evolved Anniversary Edition remake and that deeply affects game design is to take a game and increase its visual fidelity to a modern standard without considering the core art direction of the original game. To contextualize this a bit, production pipelines for video game graphics were revolutionized in the early 2000s with the gradual but widespread introduction of Physically-Based Rendering (PBR). The techniques were described in the 1980s, but what set this off for games was partly a book by Matt Pharr, Wenzel Jakob, and Greg Humphreys (link is to the table of contents for the 2023 edition). Before PBR, much work with textures had to be manually tweaked until it looked right. With PBR, artists could start relying on real world measurements and assign material properties that always provide realistic results. What many 3D remakes then do is that they take a pre-PBR 3D video game and they remake the visuals for PBR. A realistic look from a purely practical perspective, but also one that doesn’t respect the original often carefully crafted art direction. In a pre-PBR game, the environment and interactive objects could be designed to read more easily. In remakes with full PBR and high resolution textures, everything looks the same. More often than not, you need to compensate for the loss of art direction, for example by using dabs of contrasting paint to highlight what the player can interact with. Two things to note is that this in no way means PBR is bad or that it shouldn’t be used, or that this is limited to remakes. All it does is that it shows you how tricky it is to match game design and art direction when all you are doing is making something look “more realistic” by increasing fidelity. Movies, which are filmed in the actual real world, very rarely focus on looking realistic, but will instead use lighting, composition, and other techniques to make sure that the right information comes across. Allow art direction and game design to inform each other, and please stop letting whoever paints all the yellow paint have all the fun before the hero even gets there. We can look at old school gaming — as far back as hex and counter wargames — as fantasy systems . Our imagination takes the output of dice rolls and table results and conjures up fantastic chains of events. Like how you can imagine the anti-tank crew in a game of Advanced Squad Leader sit there and whisper hoooold to each other in Mel Gibson fashion while you, the player, are hoping that the tank will move one more hex so your chances of hitting are increased before you tell your opponent “I shoot!” All of that tension is a natural and emergent effect of the game’s systems. The actual physical experience of playing the game is just a bunch of cardboard counters and dice. Player imagination is the most powerful tool in a game designer’s toolbox. Yet, in many types of games, the design doesn’t really allow it. Instead, we sell you the permission to imagine things and actively restrict you to only imagine things we can charge money for. The official experience. You won’t find freeform customization as often as for-purchase skins of popular characters. The workings of our fantasy systems are paywalled, and there will always be a next purchase for you to make if you want to satisfy that fantasy you had in mind. Be it the all-black gothic armor set or the bladed boomerang or something else that you didn’t actually want or need. Players are creative anyway, of course. They will always draw penises if you give them half a chance, and some can spend hours in your character creator to imitate their favorite celebrity. But the reason this is a challenge for systemic design is that the official allowed content that we sell is never going to be half as cool as what players can discover on their own if you let them. Facilitate player imagination, don’t commodify it. Generative AI has been saved for last, because I’m not personally that worried. If people can find inspiration from a ChatGPT chatbot or get past programming obstacles that are hindering them in their work in some way thanks to some flavor of Copilot, then that’s great. Use the tools that make you more effective. But one thing is problematic: people’s faith in Large Language Models (LLMs) and other black box technologies. How people from outside the industry can come in and tell us that hey, you can use AI to make your enemies smarter or to write dialogue for you . Because yes we can, and we’ve been able to for decades, but we shouldn’t and we won’t. The amount of text that we put into our games has never been the problem, and having to expensively teach our enemies how to do actions we could much more easily build systems for is a bottleneck more than a solution. To make more dynamic and responsive games, we don’t need a new black box, we need to develop the paradigms around how we think and design. We need to design games in more systemic ways. Complex systems start from simple systems that work — they are not made out of black boxes. LLM technology, Machine Learning, Reinforcement Learning, and much more, are useful algorithms that we should put to good use when they solve problems for us. But only then. The best stuff we can get out of the LLMs probably hasn’t appeared yet, and it won’t do so until we get past the stage of overhyped excitement that seems to dominate the tech space today. Solve problems, don’t buy into hype.

0 views
Playtank 5 months ago

Making Money Making Games

There’s a popular joke about money and game development. It goes something like this: To make a small fortune from gamedev, start from a big one. A key element of gamedev finances is risk. Games are entertainment products, and even when someone has a great time testing your game at a conference or all the reviews come in at 11/10, that still doesn’t mean people will want to give you money. You can have vocal fans demanding a balancing change, or people with 1,000 hours logged that never say a word. Neither ultimately help you pay the bills in the longer term. You’re always building your game with someone — maybe yourself — gambling on its potential. Taking a financial risk. To provide material for discussion, this post will go over the often unintuitive ways game developers make money. Enjoy. Or disagree in comments (or to [email protected] ). Budgeting and cost analysis sounds about as exciting as it is. But if you want to make money making games you need to invest money or at least know how much you will be asking someone else to invest. By far the biggest cost for digital game development is staffing. Estimates run as high as 90-95% of gamedev budgets (not counting marketing), but it really depends on how you structure your company. When you calculate your budget, the easiest way to start is to list all the roles you want to fill and then multiply that headcount by the number of months they must do their job. You then take this number and multiply it again by a set price per month that covers both expenses and salary. This last number is usually somewhere in the range €5,000 to €15,000 per developer per month, where 5k is an idealistic basement-based indie studio (at least in the west), and 15k just about covers a San Fransisco receptionist working half-time (I jest, but SF is incredibly expensive). If you are a solo developer, don’t forget to set a rate for your own hours and tally them as a cost, even if that money is taken from some other fulltime job in practice. It’s still a budget; still an investment. After summing up all staffing costs, add any other costs for software licenses, conferences, marketing, computer hardware, office rent, office cleaning, accounting, etc. Add everything, no matter if it’s €10 or €10,000. Let’s say you have one artist/designer and one programmer. That’s two “roles.” Let’s say they will work 6 months. That’s 12 months total. Then slap a monthly cost on this, say €8,000 . Maybe you’re also accumulating total additional costs that amount to €4,000 for some travel tickets and licenses. All those things added together come out to €100,000 . Once all is summed up like this, you add another 30% on top. Don’t ask why — just thank me later. Adding 30%, our budget amounts to €130,000 . This would be the budget for this team of two to make a game in six months. If you want to read more about game business, I recommend the books The Gamedev Business Handbook and The Gamedev Budgeting Handbook , both by Michael Futter. A handy formula for calculating how to achieve the following goals is: Breakeven Sales = Budget / (Unit Price * X) Example 1: Total budget of €130,000 , Unit Price at €19.99 , and X of 0.5 . Breakeven sales come out at 13,006 units (130,000 / (19.99 * 0.5)). Example 2: Same budget, but with a €0.99 ARPU instead of unit price, you’d need 262,626 players to reach breakeven (130,000 / (0.99 * 0.5)). Contrary to popular belief, the goal of making money as a business isn’t to be able to buy a Ferrari. Rather, there are four quite specific goals you can set out to achieve and anything beyond those goals is a bonus (literally). Your goal may simply be to break even. If you sell those 13,006 units, you’ve made back what you invested and lost nothing. You have a game out in the wild! This is fine as a goal. To see the time and money you put in returned in some form is more than most indies can say about their gamedev adventures. A word of caution is that you should remember to count all the hours that you put into your project before you consider it breaking even. If you worked two hours every evening for a year, but you only calculated the budget based on money you paid for a sound commission, then “breaking even” won’t actually tell you anything. It’ll be undervalued to the point of meaninglessness. However, don’t put the Ferrari into your budget either. Focus on the cost of doing business. One factor of breaking even you should also consider is the timeframe. Different strains are put on your finances depending on if you break even in a month, six months, or eight years. Consider a range of scenarios and their consequences before you commit to your project. On the other hand, you may want to be able to sustainably make your next game. That requires your sales to hit breakeven quickly enough that you are paying for the next game in the meantime. If you can achieve sustainability, you can keep making your small games as long as you keep making them. It’s the dream goal of many small indies I know, to have Game A pay for Game B pay for Game C, and keep you salaried, stress-free, and happy, along the way. No Ferrari, but the lights are kept on. With a bit of luck, each project can provide you with passive income for a longer duration and the credibility and following you build over time may provide more stability than only relying on new releases for your income. You may also want to get enough money back from your first investment to be able to scale up and build more ambitious projects after. Hire more developers, maybe get a nice office, make a multiplayer version, or deploy your game to more platforms. It helps to look at money in a business less as money and more as investment capital. By all means, put some money in your own pocket as a reward for a job well done, but then you must account for it as well. Getting a Ferrari may sound amazing, but company capital that turns into private money gets taxed and won’t benefit the company’s long-term growth or short-term needs since it doesn’t exist anymore. If you aim for growth, you need to put the costs for both Game A and your hoped-for future Game B into the Budget field of the breakeven formula. At that point, the numbers will grow considerably, and you’ll start understanding the complex nature of game finances. Not to mention the reason you will often want someone else to take the financial risk in your stead. For most game studios that don’t have longterm first-party backing, growth will not be planned for but will happen organically due to Game A doing well enough to support it. You can’t count on it, but should at least be mentally prepared for it if it happens. Maybe you don’t actually care about breaking even, getting your money back, or any of it, because you either consider game development something you do for fun or you look at the things you make as a way to express yourself. You’ve probably read the past few sections feeling like you need to spit out the sour taste of capitalism. If making art is the goal you have, then power to you, and may you find the expression and reach the audience that you seek. The rest of this post will probably not apply to you, but may still be interesting to read (I hope). What is generally the most surprising to people when I discuss my job with anyone else, from gamers to people who have no personal experience with games, is that game developers actually rarely make their money from selling games. It sounds deeply unintuitive, even as I type it, but it’s true. To explain why this is, let’s talk about sales. Probably what most gamers think of as how game developers make money is by selling games to players of games. Putting your game in a store and asking for some money. A first party (the “producer”) sells their product to a second party (the “consumer”). Economy 101. Unless you put a page up with your own Paypal connected, release your own launcher as the only place to buy your game, or travel to cons to sell physical copies, you are not actually making direct sales. There will almost always be a go-between that’s not just a banking or payment service. One benefit of direct sales is that you won’t have to pay anyone a percentage. The downside, and why it’s quite uncommon, is that you must make everything yourself, including the server architecture to host your game, support forums, storefront, and so on. Things that will take time away from making the game. Direct sales will affect your X considerably: it can go from 0,5 to 0,7 or higher since you are only paying taxes, backend costs, transaction fees, etc. and don’t need to pay a cut to any platform holder. Steam, App Store, Google Play, Good Old Games, PlayStation Store; there are many platforms where players can purchase games. You’ve heard of them, probably used more than one of them yourself as a consumer, and may have worked with them for your own projects. Here’s the thing with these platforms: they have their own best interests in mind and not yours . When Apple was celebrating the 15th anniversary of the App Store in 2022, they said that “today, the App Store has more than 123 times as many apps — nearly 1.8 million — to choose from, compared to the thousands available on the App Store at the end of 2008.” This isn’t good for you , the individual developer. It’s only good for the platform owner, who can attract people with the implied software diversity of their platform. In the case of this example, it’s Apple, but the same is true for Google Play, Steam, and all other online stores. In fact, in the 2010s, some developers were talking about the “race to free,” which is an unfortunate side effect of the growth in competition. With more direct competitors for market attention, you are forced to rely on platform discount campaigns to shift more units. This means that your Unit Price from before is shrunk down by anything from 5-95%. You choose your own discount, of course, but if everyone else has a 95% discount and you provide 5%, this affects what people are likely to buy. Some can make more money by offering a discount because they find the sweet spot between discount and volume, but the dark side of that moon is that your unit price may shrink so low that it has effects on your sustainability as a business. Let’s say you used to get €19.99 for one unit before fees, but you discount it down to €4.99 in a Steam sale. Even such a thing as writing an answer to a support e-mail may start costing you more than your take from the sale of that customer’s unit. Meanwhile, the platform keeps getting its 30%. This “race to free” has been accelerating for some time, and while Steam and Apple revenues soar, there is a shrinking number of developers who can actually sell enough to make a living. Something that gets further exacerbated by a growing number of competitors with a decreasing development time cycle. Looking at VGInsights.com and its Revenue Distribution, you can see that only about 12% of all purchasable games on Steam made enough money to break even with our budget example from before. A percentage inclusive of all $50k+ brackets, even though the $50k-200k bracket is heavily skewed towards the bottom. So that 12% is likely to be lower in reality. If you sell your game on Steam, your game must do better than 88% of games on the platform if you want to have a chance to make enough money to break even with a €130k budget. This doesn’t mean you shouldn’t use Steam or the App Store. You just need to be aware of its caveats and prepare to make less per unit than may actually be sustainable. Also, don’t kid yourself in this regard. AAA and AAAA may be able to set prices at €70 and beyond per unit, but that’s because of a long-standing direct relationship with their customers. If you, as the theoretical small indie, push prices too high, people simply won’t buy your product. For you, the race to free is real. Platform sales is more or less the assumption. Your X will be around 0,5 depending on your taxes. But at least some other fees, including transaction fees, are baked into the platform’s cut . You should add unit price discounts into your breakeven sales calculations, because you are very likely to have to do them at some point and you need to know what that means for your numbers. A game can’t make any money until it’s actually ready and done. Before then, someone still needs to foot the bills. This is why it’s common that your studio doesn’t make money from selling games but from delivering milestones to someone else who is fronting that money and taking the financial risk. This can either be third-party contract work delivering a whole game, or it can be what’s referred to as co-development or just codev. A Request for Proposal (RFP) is a document that asks you to pitch your version of something. Classic examples are spinoff sequels and movie tie-ins, but a RFP can ask for almost anything. If you run a studio known for a certain thing, you may get RFPs asking you to pitch that thing within certain creative boundaries. I can’t use real world examples for obvious reasons, but RFPs can be anything from a single page asking you to hop onto a call and discuss specifics with the owner of an intellectual property (IP), to giant design bibles asking you to add the flavor on top that your studio is known for. Picture HBO contacting you to make a Game of Thrones-based strategy game, for example. They’d be doing so with a RFP. Probably what most people think of as “pitching” isn’t based off a RFP but is the style of pitch that you write yourself and bring to a publisher at a conference or some other gathering. Today, you must usually bring a prototype as well if you want to be seriously considered. This is particularly common among indie developers, who often strive to sell their creativity more than their credentials, but is actually not as important as you may think. Not in the grander scheme of things. Be mindful that no one will ever say “no” to you while pitching. They may ask for more details, a bigger prototype, a functional build, or something else, but they will rarely say no. Whatever you do, don’t take a lack of nos to mean yes. Pursue multiple leads, and if things don’t move forward, move on. Once your pitch is successful, you agree on a timeline and a budget, and schedule some milestone deliveries. The cadence of milestones varies immensely. Maybe you can have weekly check-ins with your publisher sometimes, while at other times it’s half a year between deliveries. Generally, the longer time you have, the tougher the requirements will be. Usually, a plan outlines what needs to be achieved at each milestone and once a milestone gets accepted an agreed amount of money shows up in your bank account. There can also be termination clauses built into a contract, where a certain number of failed milestones voids the entire contract. There can be cancellation fees to be paid, or penalties, and so on. How contracts look like is almost as varied as the stars in the night sky. Milestone payments will cover your running costs, and if you added those 30% I told you to add, they may give you a little bit of margin on top. But they also tie your company’s survival to the consistency of your financer’s payments. With milestone payments, you don’t need to do the breakeven calculation, because that whole thing is up to your financer. But you will also have to be more specific with your budgeting, and may have to cut some costs that the financer doesn’t think is worth it. Some costs may also be cut because it’s something that the financer can help you with; for example if you are working with a first-party publisher who also owns a platform, like Microsoft or Sony. Then they will be able to help you get your game onto their platforms, among other things. Maybe you are asking yourself how you can possibly reach your goals of growth or sustainability if you are only getting paid for milestone delivery. The answer is generally quite simple: you can’t . But it’s not all doom and gloom either. Many contracts will have various forms of bonuses that can be paid out if a game does particularly well. A bonus on delivery can be applied. Usually tied to delivering faster or to a higher standard (for example, a better Metacritic score). There can also be penalties to this or reductions to other bonuses if a project gets delayed or fails to achieve agreed-upon goals. There can also be straight-up royalties. Maybe you get 20% on all revenue that the game accumulates in stores. This is where the concept of “advance on royalties” will often come in and bite you. If you have such a contract, which was probably more common 10+ years ago, your 20% royalty will have to pay back all of those juicy milestone payments you got before you can bank any money towards your sustainability or growth. In other words, with a 20% advance on royalty, the financer will have to make its costs back five times over before you start seeing any royalties. Chris Taylor, then of Gas Powered Games, once called this a “500% loan.” The reality of the model described here is that most games either don’t break even at all or barely break even, for the developer , but the financer can still break even. In the meantime, the developer is forced to look for a new project with new milestone payments coming in or they are forced to cut staff or may even go bankrupt. This is one of the reasons you sometimes see studios do massive layoffs right after project delivery: no more milestone money coming in, and uncertainty around royalty profits for anything that isn’t an immediate hit. Many studios today don’t make their money making their game but solving the problems of bigger or more financially successful studios. This can be to handle porting, localisation, rendering optimisation, bug fixing, testing, or really any other thing that you can specialise in and that another studio may want to pay for. A codev studio may have the ambition to make its own games on the side, but codev can also be good business in itself. Particularly if you have a solid network of contacts that can provide you with a steady stream of work. It’s not unusual for experienced developers to found smaller codev studios that then sell their work to previous employers. It allows a bit more independence and flexibility. Codevs will usually function like any other contractor would, with an agreed-upon fee paid per developer per hour, week, month, or other time unit. As an example, a codev that charges $50/h (plus tax) would be paid around $8,000 per fulltime developer per month (i.e., 50 * 160). In 2012, Tim Schafer’s iconic studio Double Fine made games industry history. They launched their “Double Fine Adventure” crowdfunding campaign on Kickstarter, promising to make the kinds of point-and-click adventure games that Schafer used to work on back in his Lucas Arts days. The campaign went on to pull in $3,336,371 from 87,142 backers, while originally asking for $400,000, and demonstrated quite clearly that there was real money to find in crowd funding. However, before you jump off to work on your crowdfunding page, you must first realise two things. First, that Tim Schafer’s credentials as a developer was already proven and his quirky adventures from the past were games that many remembered fondly. Second, that even three million dollars is actually not all that much money for a mid-sized game project. Remember that just two people working for six months amounted to a €130k budget. Try doing the numbers for 15-20 people working for two years or more, and deduct all the costs to produce and ship the physical rewards you promised to some backers. Crowd funding can be incredibly successful. Let’s not forget to mention Star Citizen in this context, having made over $800,000,000 selling what Wired once called “doubly virtual” space ships. But the fact is that building a successful crowd funding campaign today is extremely hard and also unlikely to give you enough money to finish your game. Crowd funding can be used to gauge interest and to get you enough cash to build a prototype to bring to a publisher, but beyond that it’s a massive amount of risk to rely on crowd funding to pay your bills. The draw, of course, is that you’d only pay Kickstarter’s fees and taxes; you get to keep the rest. But if you think milestone penalties sounds like a tough consequence of delays, wait until you see the reactions of your future crowd funders when you tell them that they’ll have to wait another six months. With the explosion of Roblox and Fortnite , an entirely new revenue stream came to games: advertising revenue. Not just in the form of popup ads, like we’ve seen for years, but pure advertising. Big brands and franchises like Nike or Burger King, with giant treasure chests of advertising money normally transformed into TV commercials and roadside billboards, now want to grab the attention of the hundreds of millions of kids who are playing these insanely popular games. Of course, games have had instances of this before. It’s not entirely new. The Flash era, Second Life , and the various multimedia enterprises that cropped up to make low (and big) budget FMV games had similar goals and probably similar financing as well. So in a way, the current wave of ad revenue is just a much bigger version of what has come before. But what it means is that you can certainly make a living from building Roblox experiences or Fortnite levels for big brands. Though gamers may talk about Games as a Service (GaaS) kind of how the characters in Harry Potter talk about Voldemort, service games are some of the most lucrative games on the market. One reason is that they typically have no spend ceiling. Where the types of sales we based the budget example on earlier have a unit price, a service game’s price range is between €0 and infinity. Nicholas Lovell, in his book The Curve , refers to customers who pay nothing as freeloaders , but also point out that they are a crucial part of how you get superfans . Customers who can pay you so much money that they can finance your whole studio. Data varies between games, but some GaaS projects will see just 5-10% of players represent 90% of the continuous income. One key transformation that happens when you start working on a service game is that you have to make business and monetisation part of the whole experience. It’s not unusual for service games to apply various dark patterns in their user experience and to incorporate behavioral sciences in ways that are absent from other types of games. Just think about how many of World of Warcraft ‘s features are built around wasting your time. Be it fighting the same monsters over and over, playing the same raid multiple times, or having to find your way back to your dead remains after getting killed. This ties quite nicely into the fact that you are paying a monthly subscription. For as long as the game can have you waste your time (willingly and lovingly, mind you), the developers keep making money. On one side of the table you have yourself, a hopeful developer that may or may not run out of money a month from now and that are seated at this particular table maybe once every few years. On the other side, you have a professional negotiator who holds practically all the cards. Your future is in their hands. If you are going to a publisher or investor hoping that they will pay your budget, you are asking them to take the financial risk and you will have to make some kind of tradeoff for this to be worth it for them. If you attempt to go the publisher or investor route, you can forget about anything beyond sustainability. No publisher or investor out there will pay you ten times what your current game will cost to make in order to finance your future growth. They will pay you the least amount of money that they can get away with, and the pressure is then on you. The reasons publishers have for parting with their money in one instance but not in another are sometimes indecipherable to us mere mortals. Some deals can be signed based on timing and how your game fits a financer’s portfolio. This type of deal can have decent terms, but can also come with the strangest of caveats. If you are a publisher, and maybe for some investors too, what matters sometimes isn’t so much the game you are financing as its place in the larger scheme of things. Maybe you don’t have enough releases to coincide with Christmas, or you haven’t released a contemporary game or fantasy game in a long time and your competitors are about to do so. If you can find this type of slot with your game, as a developer, it can be a golden opportunity. But it won’t give you the biggest budgets or most generous timelines. Probably the most common exchange is to sell parts of your future revenue to a publisher. This is that “advance on royalties” scenario that was mentioned earlier. You get paid up front, usually in milestone arrears, and you then pay everything back once the game launches. It’s actually not that common for publishers to ask for the big 80% chunk anymore. Today it’s more common with something like 50%. The more risk you take yourself, the better. So a game that has a solid playable prototype that demonstrates both that the game is worth making and that you are the ones who should make it will put you in a better negotiation spot and may allow you to keep a bigger percentage of potential future revenue. Just remember that the publisher is taking the biggest risk. If your game doesn’t make any money, they will still have lost theirs, while you can just walk away. Some investors, and more rarely publishers, will want a percentage of your game company and a proportional role in your business decisions. There are some tricky things with trading money for equity. For example, if you start at a rate of €1,000 per percent in your company, that caps how much money you can get in and may force you to sell more of your company than you want if you run into delays. It’s also all but impossible to get someone who comes in later to pay more than the previous rate per share, unless something drastic happens to your evaluation. Another tricky thing is to make sure to rely on what’s called “smart money” in finance. You don’t want partners whose only contribution is money. You want them to know the business, have good contacts, or provide extra value of some other kind. If they don’t, it may not matter how much money they offer, because they are not improving your chances. During a PocketGamer meetup a few years ago, there was a panel on investment in games and how to build sustainable businesses. One topic that came up was exits. An exit is when someone who owns equity in something sells that something at a higher valuation than it was bought and then leaves (“exits”) the company. When a big-name game company is sold, it’s likely that it’s because some of its investors made an exit on their investment. Sold off all their shares, took the money, moved on. For years, this was what investors in gaming were after. If you played your money right, you could get returns on investment that were 10-100 times the money you invested. This was one of the reasons that there was so much “free” money to be had. It was simply quite lucrative to invest in games, with the kinds of payoffs that made the risk of losing it all quite worth it. In that PocketGamer panel, a developer in the crowd asked a question. “What if we really believe in what we do, and we don’t want an exit, can we still find investors?” Few things illustrate the mentality of some investors better than one panelist’s answer. They laughed, waved their hand dismissively, and said something like, “Why wouldn’t you want an exit? You can take the money and start a new company.” All of that is to say, if you work with investors who are looking to make a buck on your credibility in this way, you need to be aware of it and in on it. They are not investing in you because they believe in you or your game, but because they believe in the potential to grow the value of their investment. In some cases, this means talking about the game being made to make the market react, and not to actually deliver the game. It’s an investment strategy and not a creative enterprise. Know if that is what you want before you sign at the dotted line. One model you may run into is a setup where an external party buys your company outright. Usually paid for with shares in something else, such as the parent company. This can provide a safety net if the organisation is a mature one but also means that you are going from a founder or co-owner role to become what amounts to a glorified employee. If you can retain some authority over what you are selling, or if all you want is the relative safety of a larger organisation, this can still be worth it. Just be very careful to read the contract terms. Many developers I know have a romanticised image of the scrappy indie developer bursting onto the scene and taking home enough money to never have to work again. For several decades, the aspirational image was that of id Software’s DOOM -delivering founders posing with their Ferraris. But here’s something you need to remember. id Software was an independent company. They didn’t “just” make a good game and then get rich, they owned their intellectual properties, the technology they worked on, and they also experimented with how to sell and distribute games in the early 90s. There was no 30% Steam fee, no publisher taking a 50% cut of revenues (actually, for DOOM retail sales, GT Interactive took 80%…), no advance on royalties; it was all (mostly) theirs. Every time you give something away, whether it’s stock in your company, future revenues, or IP rights, you’re making a tradeoff that may buy you some security in the short term but will also cost you parts of your independence. If there’s any single takeaway you can make from this long-winded post on unintuitive ways to make money, it’s that. Consider carefully what you are willing to sacrifice, because you will have to sacrifice something. If at all possible under your particular circumstances, experiment and prototype with business the same way you would with gameplay. Don’t assume that you must have a publisher, or that you must use Steam to sell your game. Don’t assume anything. Budget should be the total money that the game costs you to make (plus 30%). Unit Price is what you will be charging your players. In tabletop gaming, the Manufacturer’s Suggested Retail Price (MSRP) is often around five times the cost of production per unit. This would be a tough sell in video games. In digital games, what you charge for your game is much more hotly debated. Also note that “Unit Price” can be replaced by an Average Revenue Per User (ARPU) metric if you have more of a games as a service setup. X is a fraction of 1 that takes sales tax, platform cut, etc., into account and modifies the unit price accordingly. Do some digging into VAT rules for your country, so you can be sure that your revenue per unit is reflected. Breakeven Sales will be the number of units you must sell to make back your budget, in case of unit price, or the number of players you will need in case of ARPU.

0 views
Playtank 6 months ago

My Game Engine Journey

There, but certainly not back again. It’s sometime around the late 1980s/early 1990s that some developers start talking about a “game engine” as a thing. Maybe not even using the term “engine” yet, but in the form of C/C++ libraries that can be linked or compiled into your project to provide you with ready-made solutions for problems. Color rendering for a particular screen, perhaps, or handling the input from a third-party joystick you want to support. The two Worlds of Ultima games are built on the Ultima VI: The False Prophet engine, as a decently early example. When you put a bundle of these ready-made solutions together, it becomes an engine . In those days, the beating heart would usually be a bespoke renderer. Software that transforms data into moving pictures and handles the instruction set of whichever hardware it’s expected to run on. What id Software perhaps revolutionised, if you are to believe John Romero in his autobiography Doom Guy: Life in First Person (an amazing book), was to make developer tools part of this process. To push for a more data-driven approach where the engine was simply the black box that you’d feed your levels and weapons and graphics into. This is how we usually look at engines today: as an editor that you put data into and that makes a game happen. To give some context for this, I thought I’d summarise my personal software journey. One stumbling step at a time, and not all of it strictly engines . When I grew up in the 80s/90s, I was often told that programming was simply too hard for Average Joe poor kids like myself. You had to be a maths genius and you had to have an IQ bordering on Einstein’s. At a minimum, you needed academic parents. If you had none of those, programming wasn’t for you. Sorry. This is the mindset I adopted and it affected my early days of dabbling profoundly. Where I lived, in rural Sweden, there were no programmer role models to look up to, and there was no Internet brimming with tutorials and motivation either. Not yet. We didn’t have a local store with game-stocked shelves or even ready access to computers at school. Again, not yet. But eventually, maybe around the age of 10 or so, I ran into QBASIC on the first home PC that was left over from my dad when he upgraded. Changing some values in the game Gorillas to see what happened was my introduction to programming in its most primitive form. Ultimately, I made some very simple goto-based text adventures and even an attempt at an action game or two, but I didn’t have enough context and no learning resources to speak of, so in many ways this first attempt at dabbling was a deadend. It’s clear to me today, looking back, that I always wanted to make games, and that I would probably have discovered programming earlier if I had been introduced to it properly. Even if I felt programming was too complicated, I did pull some games apart and attempt to change things under the hood. One way you could do this was by using a hex editor (hex for hexadecimal ) to manipulate local files. This is something you can still use for many fun things, but back then hexadecimal was part of how games were packaged on disk. (Maybe it still is and I’m letting my ignorance show.) The image below is from Ultima VII: The Black Gate seen through a modern (free) hex editor called HxD . As you can see, it shows how content is mapped in the game’s files. Back then, my friends and I would do things like replace “ghoul” in Ultima VIII with “zombi” (because it has to be the same number of letters), or even attempt to translate some things to Swedish for some reason. (To be fair, the Swedish translation of Dungeon Keeper 2 is in every way superior to the English simply because of how hilariously cheesy it is.) To grab this screenshot I could still find the file from memory, demonstrating just how spongy and powerful a kid’s brain really is… With Duke Nukem 3D , and to a lesser extent DOOM , I discovered level editors. The Build Engine, powering the former, was a place where I spent countless hours. Some of the levels I made, I played with friends. I particularly remember a church level I built that had sneaky pig cops around corners, and how satisfying it was to see my friends get killed when they turned those corners. How this engine mapped script messages to an unsigned byte, and memorising those tiny message codes and what they meant, were things I studied quite deeply at the time. I fondly remember a big level I downloaded at some point (via 28.8 modem I think) that was some kind of tribute level built to resemble Pompeii at the eruption of Vesuvius. It’s a powerful memory, and I’m quite actively not looking to find that level to get to keep the memory of it instead. The fact that walls couldn’t overlap because it wasn’t actually a 3D engine were some of the first stumbling steps I took towards seeing how the sausage gets made. Several years after playing around with the Build Editor, I discovered WorldCraft. I built a church here too for some reason, despite being a filthy secular Swede, and tried to work it into a level for the brilliant Wasteland Half-Life mod. This was much harder to do, since it was fully 3D, and you ran into the limitations of the day. The engine could only render about 30,000 polygons at a time, meaning that sightline optimisations and various types of load portals were necessary. Things I learned, but struggled with anyway. Mostly because Internet was still not that great as a resource. Had I been smarter, I would’ve started hanging around in level design forums. But level design never stuck with me the way programming eventually would. During this time, I also learned a little about tools like 3D Studio Max, but as with programming in the past I thought you had to be much better than I was to actually work on anything. My tip to anyone who is starting out in game development: don’t bring yourself down before you even get started. It can deal lasting damage to your confidence. During the late 90s and early 2000s, something came along that finally “allowed me” to make games, at least in my head. At first it was DarkBASIC , which is a BASIC version with added 3D rendering capabilities produced at the time by the British company The Game Creators. This discovery was amazing. Suddenly I was building little games and learning how to do things I had only dreamed of in the past. None of it was ever finished, and I always felt like I wasn’t as good as people from the online communities. It’s pretty cool, however, that Rami Ismail hung out in these forums and that I may even have competed against him in a text adventure competition once. Along the way, I did learn to finish projects however. I made two or three text adventures using the DarkBASIC sequel, DarkBASIC Professional, and even won a text adventure competition all the way back in 2006 with a little game I called The Melody Machine . In 2005 I enrolled in a game development education in the town of Falun, Sweden, called Playground Squad. It was the first year that they held their expanded two-year vocational education for aspiring game designers, programmers, and artists. My choice was game design, since I didn’t feel comfortable with art or code. This was a great learning experience, particularly meeting likeminded individuals, some who are still good friends today. It’s also when I started learning properly how the sausage gets made, and got to use things like RenderWare Studio. An early variant of an editor-focused game engine, where designers, programmers, and artists could cooperate more directly to build out and test games. It was never a hit the way Unity or the UDK would become, but I remember it as being quite intuitive and fun to play around with. We made one project in it, that was a horde shooter thing. I made the 3D models for it in Maya, which isn’t something I’ve done much since. I don’t remember what SimBin called their engine, but I got to work in two different iterations of it in my first real work at a game studio, as an intern starting in 2006. One engine was made for the older games, like RACE: The WTCC Game that became my first published credit . The other was deployed on consoles and was intended to be the next-generation version of SimBin technology. There I got to work on particle effects and other things, that were all scripted through Lua or XML if I recall correctly. Writing bugs in bug tools while performing light QA duties. To be honest, I’m not sure SimBin knew what they needed any designers for. But I was happy to get my foot in the door. My best lesson from SimBin was how focused it was on the types of experiences they wanted. They could track the heat on individual brakes, the effects of the slipstream behind a car in front of you, and much more. They also focused their polygon budget on the rear of cars, since that’s the part that you see the most. You typically only see the front of a game model car in the mirror, rendered much smaller than you see the rear of the car in front of you. This is an example I still use when talking about where to put your focus: consider what the player actually sees the most. I did work with the visual scripting tool Kismet (precursor to Blueprint) and Unreal’s then-intermediary scripting language UnrealScript in my spare time in 2006, for a year or so. It had so many strange quirks to it that I just never got into it properly. First of all, Unreal at the time used a subtractive approach to level editing unlike the additive approach that everyone else was using, which meant that level design took some getting used to. With BSP-based rendering engines, the additive norm meant that you had an infinite void where you added brushes (like cubes, stairs, cones, etc.) and that was your level. In the UDK, the subtractive approach meant that you instead had a filled space (like being underground) where you subtracted brushes to make your level. The results could be the same, and maybe hardcore level designers can tell me why one is better than the other, but for me it just felt inconvenient. Never got into UDK properly, because I always felt like you had to jump through hoops to get Unreal to do what you wanted it to. With Kismet strictly tied to levels (like a Level Blueprint today), making anything interesting was also quite messy, and you had to strictly adhere to Unreal’s structure. My longest stint at a single company, still to this day, was with Starbreeze. This is the pre- Payday 2 Starbreeze that made The Chronicles of Riddick: Escape from Butcher Bay and The Darkness . The reason I wanted to go there was the first game, the best movie tie-in I had ever played. A game that really blew my mind when I played it with its clever hybridisation of action, adventure, and story. Starbreeze was very good at making a particular kind of game. Highly cinematic elements mixed with first-person shooter. If this makes you think of the more recent Indiana Jones and The Great Circle , that’s because Machinegames was founded by some of the same people. Starbreeze Engine was interesting to work with, with one foot firmly in the brushy BSP shenanigans of the 90s (additive, thankfully), and the other trying to push forward into the future. Its philosophies, including how to render a fully animated character for the player in a first-person game, and how scripting was primarily “target-based” in the words of the original Ogier programmer, Jens Andersson, are things I still carry with me. But as far as the work goes, I’m happy that we don’t have to recompile our games for 20 minutes after moving a spawnpoint in a level anymore. (Or for 10-24 hours to bake production lighting…) During my time at Starbreeze, I finally discovered programming and C++ and learned how to start debugging the Starbreeze Engine. Something that made my job (gameplay scripting) a lot easier and finally introduced me to programming in a more concrete way at the ripe age of 26. At first, I tried to use the DarkBASIC-derived DarkGDK to build games in my spare time, since I understood the terminology and conventions, but soon enough I found another engine to use that felt more full-featured. It was called Nuclear Fusion. It was made by the American one-man company Nuclear Glory Entertainment Arts, and I spent some money supporting them during that time. Now they seem to be gone off the face of the Earth unfortunately, but I did recently discover some of the older versions of the software on a private laptop from those years. As far as projects go, I never finished anything in this engine, but I ended up writing the official XInput plugin for some reason. Probably the only thing I ever wrote in plain C++ to be published in any form. Having built many throwaway prototypes by this time, but never quite finished anything, I was still looking for that piece of technology that could bridge the gap between my lower understanding of programming and that coveted finished game project I wanted to make. At this point, I’m almost six years into my career as a game developer and my title is Gameplay Designer. It’s in 2011-2012 that I discover Unity. On my lunch break and on weekends, I played around with it, and it’s probably the fastest results I’ve ever had in any game engine. The GameObject/Component relationship was the most intuitive thing I had ever seen, and my limited programming experience was an almost perfect match for what Unity required me to know. Unity became my first introduction to teaching, as well, with some opportunities at game schools in Stockholm that came about because a school founder happened to be at the Starbreeze office on the lunch break one day and saw Unity over my shoulder. “Hey, could you teach that to students?” All of two weeks into using it, my gut response was “yes,” before my rational brain could catch up. But it turned out I just needed to know more than the students, and I had a few more weekends to prepare before course start. Teaching is something I’ve done off and on ever since—not just Unity—and something I love doing. Some of my students have gone on to have brilliant careers all across the globe, despite having the misfortune of getting me as their teacher at some point. Since 2011, I’ve worked at four different companies using Unity professionally, and I have been both designer and programmer at different points in time, sometimes simultaneously. It’s probably the engine I’m most comfortable using, still to this day, after having been part of everything from gameplay through cross-platform deployment to hardware integration and tools development in it. You can refer to Unity as a “frontier engine,” meaning that it’s early to adopt new technologies and its structure lends itself very well to adaptation. You set it up to build a “player” for the new target platform, and you’re set. Today it’s more fragmented than it used to be, with multiple different solutions to the same problems, some of which are mutually exclusive. If you ask me if I think it’s the best engine, my answer would be no, but I’ll be revisiting its strengths and weaknesses in a different post. The same person who pulled me in to teach Unity also introduced me to Unreal Engine 4 in the runup to its launch. I was offered an opportunity to help out on some projects, and though I accepted, I didn’t end up doing much work. It coincided with the birth of my first child (in 2013) and therefore didn’t work out as intended. I’ve still used Unreal Engine 4 quite a bit, including working on prototypes at a startup and teaching it to students. It’s a huge leap forward compared to the UDK, maybe primarily in the form of Blueprint. Blueprint is the UE4 generation of Kismet and introduced the object form of Blueprints that you’d be used to today. Rather than locking the visual scripting to a level, Blueprints can be objects with inheritance. They are C++ behind the scenes and the engine can handle them easily and efficiently using all the performance tricks Unreal is known for. Funnily enough, if you came from UDK, you can still find many of the Kismet helper classes and various UnrealScript template shenanigans are still there in Blueprint and Unreal C++ but wrapped into helper libraries. It’s clearly an engine with a lot of legacy, and the more of it you know before starting the better. Autodesk Stingray is an engine that was developed from the Swedish BitSquid engine after Autodesk purchased it and repurposed it for their own grand game engine schemes. BitSquid was a company founded by some of the developers that once made the Diesel engine, that was used at the long-since defunct Grin and later Starbreeze-merged Overkill game studios. When I worked with it, Autodesk had discontinued the engine, but three studios were still using it and supporting it with internal engine teams. Those three were Arrowhead, Fatshark, and Toadman. I worked at Toadman, as Design Director. As far as engines go, Stingray has some really interesting ideas. Two things struck me, specifically. The first is that everything in the engine is treated essentially as a plugin, making it incredibly modular. Animation tool? Plugin. Scripting VM? Plugin. The idea of a lightweight engine with high extensibility is solid. Not sure it was ever used that much in practice, but the intention is good. Another thing I bring with me from those days isn’t strictly about Stingray, but about a fantastic data management tool called Hercules that Toadman used. It allowed you to make bulk changes to data, say doubling the damage of all weapons with a single command, and was an amazing tool for a system designer. It decoupled the data from the game client in ways that are still inspiring me to this day. Sadly, since earlier this year (2025), Toadman is no longer around. The jump between Unreal Engine 4 and Unreal Engine 5 is not huge in terms of what the engine is capable of, even if Epic certainly wants you to think so (Lumen and Nanite come to mind). But there is one big difference and that’s the editor itself. The UE5 editor is much more extensible and powerful than its older sibling, and is both visually and functionally a complete overhaul. There’s also a distribution of Unreal Engine 5 called Unreal Editor for Fortnite that uses its own custom scripting language called Verse, that is said to eventually be merged into the bigger engine. But I simply have no experience with that side of things. My amateur level designing days are long-since over. Probably the biggest change between UDK and UE5 is that the latter wants to be a more generic engine. Something that can power any game you want to make. But in reality, the engine’s high end nature means that it’s tricky to use it for more lightweight projects on weaker hardware, and the legacy of Unreal Tournament still lives on in the engine’s core architecture and workflows. As with Unity, I don’t think it’s the best engine. But I’ll get into what I consider its strengths and weaknesses in a future post. I’ve spent years working with UDK, UE4, and UE5, in large teams and small, but haven’t released any games with them thus far. Projects have been defunded, cancelled, or otherwise simply didn’t release for whatever reason. Imagine that you release a new update for your game every week , and you’ve been doing so consistently since 2013. This is Star Stable Online—a technical marvel simply for the absolutely insane amounts of data it handles. Not to mention the constant strain on pipelines when they’re always in motion. My biggest takeaway from working alongside this engine last year (2024) is its brilliant snapshot feature that allows you to to save the game’s state at any moment and replay from that moment whenever you like. Even shared with other developers. This approach saves a ton of time and provides good grounds for testing the tens of thousands of quests that the game has in store for you after its 14 years (and counting) life span. You may look at its graphics and think, “why don’t they build this in Unreal?”, but let’s just say that Unreal isn’t an engine built to handle such amounts of data. The visuals may improve, but porting it over would be a much larger undertaking than merely switching out the rendering. Can’t really talk about it. It’s Stingray, but at Arrowhead, and it powers Helldivers 2 . Like the engine’s Fatshark and Toadman variants, it has some features and pipelines that are unique to Arrowhead. I hope I get to play around with even more engines than I already have. They all teach you something and expand your mind around how game development can be done. At the end of the day, it doesn’t matter which engine you use, and it’s not often that you can make that decision yourself anyway if you’re not footing the bill. Like an old colleague phrased it, “there’s no engine worse than the one you’re using right now.” Fortunately, there’s also no better engine for getting the work done. QBASIC (around ’89 or ’90?) Hex Editing (early 90s) Build Engine (early-mid 90s) WorldCraft/Hammer (late 90s, early 00s) DarkBASIC/DarkBASIC Pro (late 90s, early 00s) RenderWare Studio (’05 or ’06) SimBin Engine (’06) First professional work. UDK (’05-’07) Starbreeze Engine (’07-’12) DarkGDK/Nuclear Fusion (’09-’12) Unity (’12-today) Toadman Stingray (’17-’20) UE4 (’14-’21, sporadically) UE5 (’21-today) Star Stable Engine (2024) Arrowhead Stingray (2025-?)

0 views
Playtank 7 months ago

A State-Rich Simulation

The object-rich world is crucial for making systemic games. Similarly, the state-space of your game can be used to describe the entirety of your design and to facilitate more holistic game development . But it’s about time that we talked about data , since it keeps coming up. How to describe the smallest pieces of your simulation and the effects of this choice on your game. This nicely rounds out the design space for systemic games. One of the key things I have long wanted to solve is how to handle data as an external element to a project to facilitate both modularity and extensibility. The engine will have to interface with the data, but you shouldn’t have to chase down specific objects in a level to modify them. To better understand why this matters, let’s establish some terminology. We’ve defined data as almost everything a computer is operating on, and something we tend to bundle up and package as content using various tools. At this level, all data is more or less the same. A person’s state of being or state of mind define data in the moment: how you are right now and what you are thinking about or feeling. In computer science, state is remembered data; things that are stored and can be referenced. Context, in computing, is the minimum amount of state that needs to be saved to be able to restore the same state at a later point (where “context-switching” comes from). But for this post’s purposes, it’s more literal. The local context is an object’s local state at a given moment in the simulation. Once we start introducing more objects to the simulation, their relationships will result in relative context: object-relative state in a given moment. Comparisons expressed as state. For example, whether one object is moving faster or slower than another. When you plan out your state, it’s also relevant to consider how and by who it will be used. If you change a value that only exists for a single-player game it’s probably fine to treat it more carelessly. If players decide to go in and change it, this will not amount to cheating since it’ll only change their local gameplay experience. It’ll functionally be modding. But if you are building a multiplayer game with server-side authority and a network backend, you need to make different considerations and plan your data much more carefully. All games represent state in some way, even if we may not think of it or plan it as such. There will be health numbers, speeds, and all manner of things to represent, and sometimes this grows organically from implementing the features we want. “Eh,” the designer says to the programmer, “we need to add a Headshot Damage Multiplier to each enemy now that we have the helmeted one.” Additional state gets added, and often to every single object in the game , and not just to the ones that need it. How we represent this state in our logic is what this section is about. It can be just a flat number in a spreadsheet somewhere; what Michael Sellers would call the “spreadsheet specific” layer of your data. But it can also use one of many existing ways for easy or efficient data representation. When you work with numbers in games the only thing that is certain is uncertainty. You will change the numbers down the line. But the great risk of any numeric system that changes it that you get cascading effects if you don’t plan for which levers you need beforehand. To do this, you can separate the numbers up front into Baseline, Attributes, Modifiers, and Functions. You can read more about this in a previous post on gamification . King Arthur may have his Excalibur; as system designers we wield Excel! For many game designers it’s natural to gravitate towards spreadsheet tools for data management. To separate things into rows and columns and make any relevant changes as needed. Because of this, you will find variations on spreadsheet support for most game engines. It’s quite common to use the comma-separated values (CSV) format to export them from spreadsheets and pull them directly into your game engine. I use spreadsheets for a lot of things but very rarely for direct authoring of data. This is a preference, of course, but also comes from how spreadsheets represent data. Since it’s natural to simply add another column to represent a new feature for an object, even if it means that there’ll be an additional “0” in that column for every object that doesn’t use it. The risk for bloat is very high. Some of the procedural implementations of features described in the post on building a systemic gun come from a spreadsheet specific line of thinking and is far more common than you’d expect. The Extensible Markup Language (XML) is sometimes used for registry files that can be compiled into game data, and sometimes in portable formats where the XML remains accessible for developers or players to change the values if they want. Variants of XML were extremely common in the past but is something I haven’t personally seen as much in recent years except in its XAML format for UI construction. XML has a very readable and extensible format, with tags and closing tags that tell the parser what to expect. It can also be generated easily using custom tools. Probably more common today than XML, the JavaScript Object Notation (JSON) has pretty much the same benefits but is maybe slightly more readable. Which one you prefer, if any, is mostly down to preferences. JSON is used extensively in web development and database formats, which is probably one of the reasons it’s become more and more common. A lookup table is an array that contains all potential instances of some piece of data and allows it to be referenced by index. In any situation where you end up copying the same data over and over, potentially into hundreds or even thousands of instances of identical values, this can be a big way to save yourself from headaches (and memory waste). Imagine a flow field, for example. A space that represents the vector force you’d apply to any unit walking a grid based on which grid cell it’s currently occupying. This could have each cell use its own Vector3D, with three separate floating point numbers per cell, or it could store a single byte with a lookup table index. The Vector3Ds would only be stored in a single place. This shrinks the amount of data you need to use by a lot and makes it easier to plan the data from a design perspective. Since many types of state will repeat, lookup tables are a good way to represent them and can also provide a single location for developers to tweak values. For example, the damage modifier added from difficulty could live in a difficulty lookup table. If you want more than just object representation in a serialised format, a good way to achieve it is by using an external scripting language. Where spreadsheets and object notation allow you to populate your game with data, a scripting language allows you to provide logic along with the data. The below example is taken from the excellent book Programming Game AI by Example , by Mat Buckland, and shows a small Lua script defining a state (State_GoHome) for a state machine. A good example of what you can turn into data-driven parts of your game with a scripting language. This is often within the realm of what a technical designer would be working with, since it allows behavior to be constructed outside the compiled game client and therefore makes iteration a lot faster. If you push it even further, you can even make the scripting language a player-facing element, but then you’re obviously going into a different realm than data handling. Context the way I refer to it in this post is inspired by Elan Ruskin’s approach to dialog on Left 4 Dead . In his own words (from the book Procedural Storytelling in Games ), “A context is a single key-value pair such as PlayerHealth:72 or CurrentMap:Village5. For performance reasons it’s best to use numeric values as much as possible, so for string values such as names, consider internally replacing then with unique symbols or hashes.” A key-value pair can be represented in many different ways in code and is often used in data structures like maps and dictionaries. You’ve probably already made use of them many times before. Inspired by Jeff Orkin’s world state representation , one way you can represent state is by using a union in C++ or explicit memory layout in C# . Each piece of state will always take up the same amount of memory, you can pool it easily, and you can use it across your game to describe the state of individual objects. In the case of Goal-Oriented Action Planning (GOAP), this state is used to represent the current setup of the world so that enemy AI can make up a plan to execute. The state is handled as nodes in a graph with the edges represent actions. A goal-first A* algorithm handles the planning. This way of representing runtime state has other benefits too. One of them is that it can be decoupled from the objects that the data represents and can then be used for other intermediary operations as well. How it looks in the paper: And here is how the paper demonstrates the use of a world property: “If the planner is trying to satisfy the KillEnemy goal,” writes Jeff Orkin, “it does not need to know the shooter’s health, current location, or anything else. The planner does not even need to know whom the shooter is trying to kill! It just needs to find a sequence of actions that will lead to this shooter’s target getting killed, whomever that target may be.” In other words, it’s enough to store exactly what you need right now as world properties, and not treat game state as a runtime database. Tags have a lot in common with keywords in card and board game design. It’s the use of a single word or few-word sentence as shorthand for a game rule or exception. Some creatures in Magic: The Gathering deal their damage before other creatures get to deal theirs, for example. A rule effect referred to consistently as “First strike.” This same principle can be applied to game state too. As a descriptor (“Elf”), for conditional reasons (“Immunity.Fire”), or as a modifier (“Burning”). Consider a concept such as damage types for example. Just a damage number is fine, but you may want to qualify certain types of damage. Maybe a Piercing weapon does less damage to skeletons, or is better protected against by a chainmail armor. Then Piercing can be a tag applied to all three: weapons, enemies, and armor. Most game engines use tags in one way or another. They may be developer-facing strings that get hashed at compile-time or they can be sent as a stream. Some engines do none of this automatically, however, and may expect you as the developer to not do unnecessary string comparisons or other expensive things at runtime. (As a general rule you should always avoid comparing strings to each other: compare their hash, length, or other cheaper thing instead.) With a tag specified, and the developer-facing strings present somewhere, you can then create a structure for comparing groups of tags against each other and to test if specific tags are present. Of course, you may want to make the strings player-facing too and expose it completely to the game, but that’s not a requirement. Maybe you want to do additive trait-matching , and check if an armor has Resistance.Piercing before you deal damage with a sword that has Damage.Piercing. Or you want to collect tags as context before you do fuzzy pattern-matching. Simply put: tags are extremely useful. Many struggle to remember the exact number 9.80665. But if we refer to it as Gravity we don’t have to use the number. We can also change it down the line in a single place if we suddenly want things to behave differently across our game. When we do this, we fuzzify the data. We use words to describe it, as with variables in code. This can be done in a template (or C# generic ), for example: With a template like this, you can easily add saving and loading, comparison checks, and other handy ways of reusing the concept of data across your game. It’ll all just be added to the DataAsset class and you can make all of them live in a single place in memory, on disk, or whatever you want. It’s straightforward to use, even if this variant would still rely on hard-coded numbers, and it’s generally a better idea to use external JSON or other scripting methods that can be changed without having to recompile your code. The real power of fuzzification is that you can start referring to numbers conceptually and not just as plain numbers. This doesn’t just simplify the conversation, it also means you don’t have to painstakingly change that price point for a gazillion individual items. This same principle can be applied to sets with more than just one point of data. We will then want to define fuzzy sets where your input will have a degree of membership with each value in the set. Let’s grab an example of something fuzzified from the Internet. In this case temperature: To represent this in the simple code from before, it’d look something like this: To finally make practical use of this data, we can wrap a number of sets together, like the example below, to find out how warm a certain temperature is. A predicate function is a function that returns a single boolean true or false from supplied parameters. It’s an excellent way to test the validity of different situations at runtime and graduates state into its relational equivalent, which we can call context . Many world property unions will effectively do the same thing, such as the kTargetIsDead property example illustrating a desire for the target to be dead. A predicate function is where we learn what is true at runtime. This can be simple and effectively reusable, for example if you have a resource object that can be reused for any number of resources: Since predicates can be used for almost anything it can make a lot of sense to keep a bunch of them around in a gameplay-scope helper library. For the following examples, I was a bit lazy, but you can see how quickly this becomes useful. For example, if InFront and FacingSame are both true at the same time, it would be the contextual requirements for a classic video game stealth takedown. Once you have these helper functions, you can use them in code to generate tags, populate bitmasks or lookup tables, or determine what happens when objects hit each other. You can use them to generate context queries for dialogue or to qualify gameplay interactions. A bitmask means using a variable’s individual memory bits as flags. With a byte, you can store 8 bits. With a 32-bit integer, you can surprisingly enough store 32 bits. Many tutorials you’ll find will become shock-full of boolean flags faster than you can blink. A “bool,” though it stores the equivalent of a bit, is still one byte of memory due to the smallest addressable thing in memory having that size. A bitmask is therefore a way to not fill your memory with unnecessary waste while only recording bits anyway. For the purposes of data, it’s also a convenient way to bundle related information together. A good example is spawn points and spawning in general. If you have, say, five different game modes and you want to be able to support all five using different spawn points, you can use a bitmask to store this information for each spawn point. Last, but certainly not least, there are many ingenious ways to use asset data to store information. I will mention just a few, to give you some pointers, but suffice it to say that one reason technical artists are in high demand is that clever solutions to pipeline problems can save considerable amounts of time and money even for small projects. The same principles can be used in many different ways to store systemic data and state. Animation keyframes are used to store the positions, rotations, and scales of bones that are weighted to skinned meshes. This doesn’t have to be an animated character but can just as easily be a piece of cloth or parchment, or even a whole level. The latter was a way for Legacy of Kain: Soul Reaver to represent the two different worlds that the player could shift between. One keyframe per world (out of two). Using vertex colors to paint objects is tried and true, but when you texture your objects you may no longer need it for this purpose. This opens up countless other opportunities to store data in your mesh objects. For example, Vagrant Story used vertex colors to store its baked lighting. A technique that worked quite well at the resolutions for that game. Most game engines have support for one full RGB vertex color per vertex. It’s possible to store more than one vertex color per vertex too, such as is the case in The Last of Us Part 1 , where the different vertex color channels are used as mask values for things like mould, dirt, and cracks. Furthermore, vertex colors can be accessed at runtime as well, and can then be used for updated live information. Say, the heat or magnetism generated by an object. I don’t know that this is how Splinter Cell does its heat vision, but it could be. Something that has been mentioned before is how Neon Giant used the “U-dimension” (UDim) workflow not as a means to map more textures to an object but as a way to create masks simply by the act of UV-mapping a mesh. This technique is quite clever and relies on mesh UVs (which are simply coordinates; “XY” was taken) using normalised values as a standard. I.e., values between 0 and 1. So by storing coordinates at higher values, like 1-2 or 2-3, you can map more than one set of UVs to the same object. You can use this for anything where you’d use a mask or map more than one texture to the same object. It could be the albedo and metallic of a PBR material, as for Neon Giant, or you could map it to other properties such as bounciness or Resistance.Piercing. When you pick which way to represent your data, you need to consider four factors: Hopefully those pointers can help you at least consider how to represent your data. There are many ways that these things are tied together ultimately. Objects, data, state-spaces, etc., and there are more ways than can ever be summarised in a post like this. I will come back to this post to extend it when new things crop up. So if you have any suggestions for clever data representations, please send them to [email protected] and I’ll consider adding them along with a thank you. Everything in a game is data. Data is often bundled up as content. State is data that is stored and can be referenced. Something’s ‘state’ is its value when checked in the moment. Local context is an object’s local state at a given moment. Relative context is an object’s state in comparison to other objects. Hard-coded . Data is “hard-coded” when it’s written directly into program code and compiled, making it impossible to iterate on the data while the game is running and complicating knowledge sharing and tweaking. Initial test data, like move speeds or jump heights, can sometimes be hard-coded to make sure something works. Constant . A named variable that is available throughout a given scope. Pi and the gravitational constant, or your game’s easy mode damage baseline (see later) can be constants. Variable . A variable is a name for data that changes at runtime, or at least can change at runtime. Move speeds, jump heights, and other classics are examples of variables that may be manipulated during play. Tweakable . A number that developers can access readily and that may need several rounds of tweaking. This type of number benefits from templating (see later) and from being externalized from the object(s) it is affecting. Individual values for long lists of items, like the Damage value for all of your 250 guns, or the gold costs for your 1,000 items. Metric . A metric is something that gets sent to a backend and can be used to analyze how players engage with your game. It’s rarely a variable or even a tweakable that gets sent this way. May be something as simple as telling the backend which level is started or the duration of a challenge the player played. Optional . This is data, typically a variable, that is accessed directly by the player. The font scale, color of the UI, music volume, etc.; but it can also go deeper, as with the many customization options you have in a game like Civilization. Persistent . Data is ‘persistent’ when it needs to live across multiple game sessions. You don’t need to make constants persistent, for example, or really anything that is represented by content, but anything that should stay the same between play sessions will have to be persistent. Current health, current level, location of character in the game world, optional settings (like volume), etc., will usually be expected to be persistent. Visible . Whether a number or other point of data is player-facing is a crucial consideration. Anything that is player-facing will usually require filtering (e.g., Imperial vs Metric, or other localization), and needs to be more carefully designed than data that only exists in the simulation. Damage and health numbers, character names, dialogue subtitles, etc. Content . Usually when a game is referred to as data-driven , it’s because files on disk are defining how things get set up. Tweaking this data is about changing it, sometimes through an external tool or suite of tools. A premade level, an enemy with all its key data assigned through a registry file, or a 3D asset. Global . Data that is accessible everywhere in the game is global. This is generally the only scope consideration you need to do when you are designing your state space, since individual scopes are not as relevant or even automatic to the context you are working in. Quest facts, like if you have met Character Y before can be global, and optional and player-facing data is often global. Input . Data that comes from hardware input is a bit different, since you rarely want your game to access it directly. Rather, it’s good practice to use some kind of abstraction between the input and the gameplay action triggered by it. Analogue X/Y stick movement axes, touch gesture events, button presses and releases, etc. Replicated . Data that gets sent to clients across a network to simulate the same game state is said to be replicated . Which data a game replicates is an extremely important design consideration for multiplayer games and is therefore an important property to consider. Input sent to a server, timed events sent across peers in peer-to-peer networking, etc. Fuzzified . Data sets that has variable degrees of membership are referred to as “fuzzified” data, and we get into that later in this post. It’s a technique that can be used to turn tricky numbers into human-readable form and to allow computers to communicate in a way that somewhat resembles human conversation. How ‘warm’ a temperature is, how ‘damaged’ a character is, etc. Partial . If merely to track connections between pieces of data, it can be relevant to flag something as only part of a larger whole. If you separate data into base, attribute, and modifier, for example, noting that the data is partial and how can be very relevant. Any data that needs other data to be functional; maybe Strength is added to Damage and then multiplied by HitLocation; these three are then all partial pieces of data from the damage function. Temporary . Data that has a start and end time during the simulation and that isn’t technically variables. They can still be parts of key functions, but are not something that the developer is actively tweaking. Match points that are tossed out after tallying, score multipliers that are accumulated for just a single second, etc. Which tools pipeline you are already familiar with . Using UDims and other mesh techniques only make sense if you feel at home in a 3D suite, working with meshes. Similarly, you should only use CSVs and spreadsheets if you’re already comfortable with them or want to learn. Which problems you are solving . If your game is tied to a backend, JSON makes a lot of practical sense since it’s already speaking the language of the web. But if you want players to customize your game, it may make more sense to use a scripting language. Which levers you will need for testing and balancing . This is the most important, and the one that requires most design and planning. If you need to go back to an external tool every time something must be changed, whether that’s Excel or Blender, some changes may become too cumbersome to test. How the data will be communicated . Both internally, between objects in your game, and towards the player. Some things will be developer-facing only, others will be player-facing. Making sure to have one source of truth is extremely important.

0 views
Playtank 8 months ago

Combat as Drama

This post is the last post in a series on combat design . There has been many attempts to classify storytelling. Georges Polti suggested The Thirty-Six Dramatic Situations in 1895. Vladimir Propp used a selection of 31 functions to illustrate similar things in the 1920s. There’s also the widely misused monomyth of Joseph Campbell, originally published in his book The Hero With a Thousand Faces in 1949. Stepping forward into our present day, Dan Harmon’s story circle and Christopher Booker’s Seven Basic Plots pop up. Much of this work tries to take the nebulous concept of story and make it make sense. Sometimes through lenses such as folklore or mythology; today as attempts to make tools for screenwriters. Screenwriting is the storytelling craft that seeps over into game development most often. But where gunplay and melee are technical challenges to solve, the design space for drama is something else. Without stakes, there is no drama. Without characters, goals, motivations, and risks , there is no drama. Some would say without conflict, there is no drama, and if we are not competing against other players , drama must come from somewhere else. Let’s dive straight into the killing! We know we need to do violence in this combat game of ours, but we don’t yet know the details. The violence is also not what’s important for the drama to work. Instead, there are five areas you can start with if you want to figure this out: Where I am and what I’m doing. When someone draws their gun or sword in a movie it’s often the culmination of a longer storyline. It doesn’t have to be an on-screen culmination, however. It can just as easily be Inigo Montoya telling someone to prepare to die and detailing why in the same breath. The crux is that this doesn’t work in video games, and the reason is simple: a game cannot control its audience’s intentions or how they feel. Cinematic storytelling works on empathy. This has been discussed before . To afford a player the same level of connection to their character, the only trick that exists is to try to make the player and their avatar occupy the same head space. The player needs to know who are involved, what the stakes are, and what can be done about it, and the avatar needs to be someone who shares the goals of the player. This is one reason why obeying is such a common activity : a soldier following orders is strongly connected to a player following instructions. The fantasy and the activity become one and the same. Go here, destroy this, kill those sentries. In a game, it’s not enough to have your character tell the opponent that they should prepare to die because they killed your father. You, the player, will have no idea what the character is talking about if they do. To mitigate this, many games use one of two effective shortcuts: stereotypes and/or explicit connection. Alien invaders. Bugs. Nazis. The living dead. Foreigners . It’s always easier to make someone kill those who look different or speak a different language. Though the symbolism can be quite problematic, games rarely engage with symbolism and instead use stereotypical enemies for the sake of having something to kill. The more ham-fisted way is to copy the form that film uses and simply tell the player what they should care about. Those polygons over there were your family , now proceed to gun down bad guys for 15 hours. Or, even more lazily, you need to find a person who is gone. Now go off and find them and kill everyone who stands in your way. There’s no way for you to know how they look like, where they are, or anything else: you need to trust that the game tells you when you did right or wrong. What makes the empathetic connection work in film is the cinematic authorship and the way film directs the audience through this empathy. With players of games, they may be skipping all cutscenes, taking a phone call during the exposition, or even just fiddle around with their inventory items while someone is talking. Those are the activities you need to capture . Who I am, who I am killing, who I care about, and why. Making believable characters is not always the goal. Some games, like puzzle games and sports games, may not have much story context at all that requires such things. But my personal passion is immersive and highly systemic games with a strong core fantasy. Such games benefit from characters. When you sketch out your cast and why they hate each other, you shouldn’t get too stuck thinking of individuals. A character will often be an individual, of course, but characters can also be horses, space ships, machines, weather phenomena, and many more. A faction like “The Guards” will provide a good umbrella for presentations. If you present guards as corrupt and somewhat dull, this provides good information for the player whenever they encounter a guard. It also means that an individual guard that breaks from the stereotype becomes more interesting. Think of the Fable warden that reads poetry, for example; a character that plays off a warden trope and then has some fun with it. Companions in games range from animals to disembodied voices talking through an earpiece. Something that becomes extra relevant since it’s harder to give the player’s character a voice when there’s no way to know what the player is thinking. Then it’s easier to express world information through companions. But movies do the same with sidekicks and other characters who can provide infodumps. If a game is primarily an action game where the player will shoot and stab things, it’s hard to make a pacifist main character. In the first Tomb Raider reboot, Lara Croft is seen lamenting her first kill in a cutscene. The player playing Lara then proceeds to kill many more, presumably without batting an eyelid. This dissonance can only really be avoided by putting the main character (the player’s avatar ) and the player as close to the same mental space as possible. Or in the words of then-Telltale game designer, Harrison Pink: “Spend the time to let your player build the same primary motivations as the character. Let them experience the events that kick the story off together.” Few games do this better than Thief: The Dark Project . Players are wont to steal and loot things in all games, and Garrett is the master thief. A role that not only promotes but reinforces the player’s emotional space. “The goal is to allow the player and their avatar to occupy the same emotional space,” said Pink. Making sure that the role you play and the activities you engage in carry the same motivation. Screenwriter Aaron Sorkin refers to intention and obstacle as the drivers for a good script. “Somebody wants something. Something standing in their way of getting it,” he said in his Master Class on screenwriting. “They really want it bad, and whatever’s standing in their way has got to be formidable.” If you were to make a roadtrip story that starts with a group of friends going to Las Vegas, and then continues when they get there, it wouldn’t be much of a roadtrip story. But going to Vegas is a clear intention . To become a story worth telling—or, for a game, worth playing —something has to obstruct the trip, stir up a conflict in the group of friends that splits them up, or otherwise generate an obstacle . The more you can tie this to the individual characters, the better. One way to look at character development is from the perspective of flaws. Many stereotypes exist here. Alcoholism, avarice, jealousy, laziness; there’s a slew of flaws that a character may display. What you can take character development to mean is a character’s struggle to try to overcome their flaws. If the character succumbs, it indulges in its flaw and sinks deeper. If it instead overcomes its flaw, it gets to show to the world how this improves everything, or how it leads to another flaw. Some characters have flaws as defining traits instead and the portrayal focuses on how they handle the problems it leads to. They will never succumb or overcome—there’s no redemption for them—but they will still struggle. What’s important with flaws and character development is that they are made to matter. In games, you will sometimes fight against literal demons made to manifest flaws through the game’s other systems. In Condemned 2: Bloodshot , the main character Ethan struggles with alcoholism. You take a deep swig of hard liquor to steady your aim for a while. Throughout, the Alcohol Demon harasses you, until eventually, once the Alcohol Demon is defeated, Ethan’s aim when using firearms will no longer need to be steadied by consuming alcohol. These kinds of explorations of how to make interactions matter in game development are still not fully mature. We have a lot left to explore in this space as game developers. How to allow players to bring their own mental models to games and experience personalised stories that don’t have to turn mental issues into bossfights. When I played Red Dead Redemption 2 , I wanted to shoot Micah in the back during the rescue mission or just leave him in his cell to rot. I spontaneously disliked the guy, without knowing how things would develop. It’s one of the worst cases of dissonance I’ve personally had between the character I’m playing’s reaction to another character and my personal reaction. This type of dissonance, between the intentions of the character you are playing and your intentions as a player are quite common in games and come from the idea that you are telling a story to players rather than letting them experience one. Micah’s betrayal seemed inevitable to me, to the point that I groaned when it eventually happened. I could’ve prevented it without anyone ever being the wiser, by simply shooting him in the back during the rescue and dumping his corpse outside a bear cave somewhere . Because of RDR2’s deep systems, I even know how I’d do it. But I’m not allowed to. Micah has plot armor—he’s arbitrarily immune to the game’s systems because he has a role to play in the narrative script. An authorial infringement on my mental model playing Arthur. My canonical Arthur certainly shot Micah in the back. W hat happens if I don’t kill who I need to kill . Games rarely deal with stakes. The only thing that tends to be at stake is the player’s time. If the player character gets killed, it fails the game and triggers a checkpoint reload. In some types of games, the lack of any real stakes has consequences on the game’s emotional space. In horror games, the suspense often comes from uncertainty and from the fear of dying. Once you do die, the illusion crumbles, because you can see that all you ever risked was to have to redo some arbitrary part of the game. Dying becomes a fail state and part of a retry cycle, same as in any other kind of game. To approach this, let’s look at stakes. “It used the backdrop of an epic, but didn’t try to tell an epic,” said ex-Looking Glass art director Nate Wells about the Thief series. “I think that’s still one of the greatest mistakes games make. They set down all the proper names then proceed to show you the conflict at a kingdom versus kingdom level. What you have to do is just set that in the back and tell the story of one character. Tell the low-level story.” The premise is where and when we find our cast. Whether this is revolutionary France or Epic Fantasyland, it will tell the player something about what is important. In a desert, they will probably find water precious, and a group of parched survivors fighting over a wellspring has a very clear stake: without the water, they die. This is also why this isnt’ just setting . It needs to tell the player why something is worth fighting for and in as clear a way as possible. In the tabletop role-playing game Trollbabe , by Ron Edwards, stakes are defined by a concept called Scale and “applies to the extent of actions and effects in the fiction. Low Scale means only a few or little things are changed; high Scale means whole communities, even continents, are changed.” Scale ranges from 1 to 7, where 1 represents “[a] person’s or a few persons’ immediate well-being” while 7 represents “a large area identifiable by similar cultural practices and physical resources, including many communities across diverse geography.” This starting point is helpful, since Trollbabe also doesn’t allow Scale to be reduced. So if you increase the stakes by saying that an army is threatening the village, you cannot then decrease the Scale to make it about a stall merchant’s stolen bread loaf. This type of rule is helpful when working within any game design context. Many stories, whether written or recorded, will present a sense that if things are not resolved now , then there will be dire consequences. But translated into game contexts, any sense of urgency often falls flat. Particularly in open world games where months can pass between you receiving the quest and actually completing it, while dialogue and other in-game copy will still imply said urgency. This doesn’t have to be the case however. In games as old as The Hobbit , urgency has played an important role. Not always stated out loud, but that game’s dynamics affected where some characters could be found. Just like Dead Rising puts everything on a schedule and if you miss an event because you’re not there, then it is still resolved as if it happened. If you want to get on the chopper, you need to actually be there! Frankly, if you don’t do urgency in a systemic way, it’s better to not do it. The player will understand that it’s not real. Opportunities to make interesting choices. The concept of choices and consequences (sometimes “C&C”) has often been a talking point among gamers and game developers. Particularly for role-playing games. When it comes to combat, your choices will be informed by your understanding of the characters and premise. If you decide to poison the desert wellspring that was mentioned earlier, everyone would die. But if the game has already established poison as a tool, this makes it an interesting choice to be able to make. In Bob Case’s (“MrBtongue”) excellent YouTube video on choices and consequences , four things are brought up as how you can make choices work. The first three are highly relevant. If you also want the fourth you will simply have to watch Bob’s video. “As your number of choices increases arithmetically, the number of possible game states increases exponentially, and if you are not careful you may inflict an impossible workload on yourself.” Since my obsession is systemic games, scale is less about the state-space complexity Bob Case is talking about and more about the development overhead of your systems. You will design the objects and rules and the states will be consequences of how everything interacts. The key to managing scale is to be careful with how many rules you establish and how many tools you provide the player with. “[I]f your goal is simulation, then an action that would logically lead to failure in the real world should also lead to failure in your game.” Games rarely have interesting consequences for failure and combat is usually the worst. Like we covered before, dying means you’re dead and you have to replay. A future post will go into scenario and mission design, but at this level it’s interesting to remember that failure is real and that it should be allowed to happen. At the very least, your game should provide feedback that acknowledges the failure and builds forward on top of it. It can be to add scars or to have characters comment on it, but it needs to be a concrete thing. “Keep us guessing. Keep us worrying about the possible consequences of everything we do, regardless of whether the game accounts for them or not. It will make for a more immersive experience.” Bob Case mentions how, in the original Fallout , if you speak about the vault where you came from there may be bandits who go there to raid it. He mentions how this has affected how he looks at choices in every game he’s played since. Such a powerful consequence for speaking carelessly. But remember that you don’t need content for everything. For many games, as long as you provide enough consequences, the player will read more things into it. Imagination does a great job filling in the blanks. Trusting that the game remains stable . Many players are not used to pushing the boundaries. It’s also quite comfortable to know that, whatever happens, the game will reset back to its default state so you can try again. For as long as gaming has had right and wrong choices, there’s also been save scumming. From the sharing of ready-made save files to “abuse” of the Quick Save/Quick Load keys. Much of this comes down to stability . If a game has many interconnected systems, it can easily get out of control, and players may get frustrated or miss expensively produced pieces of content. This is one reason that killing the player’s avatar and resetting the state is so powerful: you know (as a developer) that the game state is being reset and that everything is now safe. Many games with stealth have a mechanic where being spotted and unable to stop the spotters will put the whole game into an alarm state. Turning off the alarm or disappearing for a while will have the enemies return to their previous state. There’s no checkpoint reload, but it kind of behaves the same as one. Players will sometimes comment on this and talk about how unrealistic it is, but as a mechanic, it allows players to try and try again without having to save scum. This was a hard series of posts to write and mainly because they treaded a bit too far from practical implementation and into the realms of theory. Personally, I think this makes them lower quality than the posts I have on my blog that are more specifically tied to systemic design, and I intend to return to the practical because of this. It’s been a good exercise in thinking through what combat can mean, and to inform my own projects too (more on those some day), but there are more systemic subjects to cover and those will be coming back next. Until then, if you agree or disagree with anything, please do so in comments or via [email protected] . Where I am and what I’m doing . Who I am, who I will be killing, who I care about, and why . What happens if I don’t kill who I need to kill . Which interesting choices I can make. I need to know that I won’t break the game. Protagonists are the main characters: usually who the player is portraying. Antagonists are the enemies of the main characters. Support is everyone else.

0 views
Playtank 9 months ago

Combat as Sport

This post is a continuation on a previous combat design post . Sport can be used as a layer on top of your gunplay or melee. Perhaps as added fairness (a sense of “good balancing”) or as a focus on competition. It can also be the whole purpose of your project. A competitive game needs to have a space for players to git gud and to compare their results to that of other players. Or to be the first to figure out winning strategies that can give them an edge. If you want to tell me I’m wrong or contact me for other reasons, do so in comments or to [email protected] . Now let’s dive into competition and how you can approach designing a “sport.” When designing anything, I find it helpful to first set up the terminology. This doesn’t have to be the exactly right words that other people use, necessarily. They’re here to help with the game design, not to become some type of definition. Chess is an incredible game design. It’s symmetrical, it has no random elements, and each pawn has its own clearly defined rules. Rook moves this way, bishop moves that way, grid has 8×8 individual square spaces, etc. This is what makes its game design deterministic . Doing a specific move under certain circumstances will always yield the same resulting game state. Because of this, pitting two players against each other is a test of skill. Who can predict what the opponent will do, make the most compelling opening move, or think the farthest ahead. It becomes a contest of ability. “In order to improve your game,” said legendary Cuban chess master José Capablanca , “you must study the endgame before everything else. For whereas the endings can be studied and mastered by themselves, the middle game and opening must be studied in relation to the end game.” Chess is a great example of a game that must be studied and practiced. Because of its determinism (no random or otherwise unknown elements), yet deeply complex state-space, it’s often considered a hard game to be good at, and if you’re not good you will simply not win. Poker, another highly competitive game, adds elements of player uncertainty and randomisation and is therefore not deterministic. The card combinations that form your playable hands are all known and their relative values are also known, but because players hide their cards from each other in their respective hands, and because of the luck of the draw, you can’t be entirely certain what another player is up to. They may be bluffing with their all-in, or they may indeed have a royal straight flush to give them confidence. As the game continues, more of the 52 cards from the deck will be revealed and you will have more “state” to consider, but you can’t be completely certain unless you already personally have the highest possible hand. This uncertainty and randomisation adds an additional layer to the competition. It doesn’t make poker a better game than chess, but it alters the required skillset. It’s not enough to master each hand, you must also play the bluffing game and start considering the myriad options based on limited information and mathematical probabilities. Chess and poker are incredibly mature games compared to most video games. They’ve been played for hundreds of years and countless kinks have been ironed out. Alternative ways of playing have come up that deal with common speed bumps and other issues. Video games, on the other hand, are released in the 100s every day, and because of this, some of them will come with unintended exploits. I’m personally not a very competitive player. I often play competitive games anyway to study them, but I very rarely win and pretty much never come up with any winning strategies. In 30-some years as a gamer, there’s just been the one exception: Battlefleet Gothic Armada . While playing the beta before launch, I realized that the Imperial ships with their heavily reinforced prows were almost immune to damage coming from the front. So I equipped some ships with weapons that didn’t require them to turn (many other weapons fire broadsides in the game), instructed them at the game’s start to only face forwards and to stay far away and fire these weapons near max range. They would sometimes move slowly towards their targets and then use a ramming action to deal the killing blow, but only against enemies that were already accelerating towards me. At first, I didn’t lose a single match with this setup! My ships took little to no damage and were able to destroy enemy ships consistently. For various reasons, I never really kept playing the game after launch, but this still serves as a decent example of exploitation. In game theory, a dominant strategy is a strategy that will always win, and that most players will eventually gravitate towards. It’s not clear whether my prow-forward approach was ultimately such a strategy, but consider it an example. The opposite of a dominant strategy is a dominated strategy , which is any strategy that is always inferior and that players will quickly abandon for other strategies. No one in a competitive first-person shooter would stick to only the knife, for example, unless there’s such a massive skill disparity that it can be done for laughs. It can be fine to have these strategies in a game, as long as you include them consciously and provide ways to mitigate them. Going for a knockout can be considered a dominant strategy in boxing, since it ends the match before the last round, but though it gives an edge to fighters that can consistently hit very hard it’s never guaranteed that they will end every match on a knockout, and hitting hard all the time may be more exhausting than playing a longer boxing game. If you are terrible at chess, you are terrible at chess. There’s no way to sugar-coat it. Other players are simply better than you. It’s the same if you play StarCraft and can’t peak out at the actions per minute (APM) of the pro players, that may span 180-1,000 APM. When games reach this level of competition, many players will bounce off. Psychologically, the knowledge that you are inferior and that there’s nothing you can do about it isn’t all that motivating. Some players will find motivation in this space anyway and push on. But another way to get around it is to let players blame the game. In competitive Magic: The Gathering , a common setup is to determine a winner by playing a best of three. This way, fewer players will feel that they lost because of a bad hand or lucky/unlucky draw. If they do end up losing anyway, they can still blame a bad hand or unlucky draw, however. If they had only played one more match , they may think. This is similar to the “just one more time” mentality that can come up when you play a fast-paced fighting game, or other high-paced game. Your opponent was just lucky; you will get them next time. It wasn’t your fault, it was chance, luck, poor balancing, the sun in your eye, etc. This is a good thing to have in a game design if you don’t want to cater it exclusively to potential hardcore players. It prevents beginners from bouncing off the game if they get to have a good run now and then, even without the skills the game would normally require. In the words of game designer and former competitive Street Fighter player David Sirlin, “Any decent competitive game needs to allow you to counter the opponent if you know what he will do. What happens, though, when your enemy knows that you know what he will do? He needs a way to counter you. He’s said to be on another level than you, or another ‘yomi layer.'” Yomi (読み, and not 黄泉; the latter is the underworld) means ‘reading’ in the sense that you can read your opponent. In Sirlin’s book, Playing to Win , he describes Yomi layers as levels of knowledge. You know what your opponent will do (layer 1), but they also know that you know (layer 2), and you know that they know that you know (layer 3). Each layer requires the game design to provide a counter action so that players can act on the information they have (or think they have). “[T]here need only be support up to yomi layer 3,” continues Sirlin, “as yomi layer 4 loops back around to layer 0.” Thinking in terms of yomi layers can help more areas than competition, however. If you look at a game enemy design in terms of yomi layers, you can design encounters that challenge players in more ways than the straightforward features they use and you can allow the player to feel clever about it along the way. The blue shell in the Mario Kart series has always been a bit contentious. It’s a knockout feature that specifically targets the leading kart and has ruined countless one-sided runs. According to interviews, the reason it was added was to keep races interesting up until the end, since it would often become a foregone conclusion who would finish first before its introduction. Especially in groups with high skill disparity, such as adults playing agaoinst young kids. When we talk about it in game design, it’s usually as a balancing factor against runaway victory. If a player is so much better than everyone else, it’s just not as much fun anymore, and the blue shell puts a spin on that situation that can make it more interesting for everyone to finish a race. One part of competitive gaming, as in real-life sports, is that competitors are directly incentivised to search for some kind of edge. Such an edge can be completely against the rules and disqualify the competitor who does them if they are caught doing it. Then we don’t call it a strategy anymore. We call it cheating . For professional sports, cheating and various forms of doping are illegal and enforcement of rules is continuous. Whole organizations are dedicated to assuring fairness. The bicycle race Tour de France, for example, has had instances of cyclists using electrical motors to give them a slight boost when cycling uphill. Muscle stimulants, growth hormones, anabolic steroids: professional sports have a long history of cheating. In esports, the expression “edoping” refers to manipulations of hardware and/or software that provide an invisible edge to a competitor. Things like aim bots or code that reveals client-side information a player is not supposed to have. Similarly, many exploits may be either patched out of a game or become part of a rule set dictating professional competitions. Take this lesson with you, if you want to make something competitive: players will cheat . Some because they want to win over other players, and others because they simply want to beat the system to prove that they can. A scrub is someone who “adamantly believes that their ‘house rules’ should apply to everyone to promote their view of ‘fair play.'” They are players who are quick to call foul or to call the way other players play boring or against the grain of a game. David Sirlin writes in his book that, “[a] common call of the scrub is to cry that the kind of play in which one tries to win at all costs is ‘boring’ or ‘not fun.'” But if you really want to win, you can’t have this type of “scrub mentality.” You need to play to your strengths and use every avenue of success that the game may provide. As a game designer, you must similarly be aware what the rules you introduce will lead to. In some competitive martial arts, for example, obstructing an opponent’s breathing by covering their mouth (called “smothering”) is legal according to the rules set out for the competition. Some will argue that it’s unethical, unfair, or makes for a dirtier sport: they would be the “scrubs.” Others make use of it where it fits, regardless of the scrub’s convictions. The key element of any sport is how to win . But before we can know how to win we need to know what we are doing. This is where you can make use of the same verbs and systemic rules as you would when designing a systemic game . Many sports revolve around activities that are easy to do but require a lot of practice to master. Kicking a ball isn’t all that hard in itself, but kicking it with accuracy and the right amount of force requires a lot of practice. This indicates that we want an activity with an analogue possibility space : it’s not enough with “success” or “failure.” Sometimes, as with game design, sports designers have been lazy and added a stopwatch on top of an activity to create this space. Sure, you can finish the race, but can you also do it in the shortest time? At other times, the analogue space is created by points scoring. It can be directly related to an activity in the game, such as kicking a soccer ball into a goal, or it can be indirect, such as the Technical Panel set out by the ISU Judging System used for figure skating. The use of an impartial judge or panel of judges is a common way to measure competitors against each other in individual sports. Another solution is to include a sudden death alternative. An occasion within the rules of the sport that immediately ends the competition and awards victory to the person who triggered the sudden death or their opponent. Most sports use the term “sudden death” specifically for match tiebreakers, but death can be sudden under other circumstances as well. Say, a knockout, or a racer’s car getting wrecked. There are also various forms of “no contest” conditions where a competition may end. If someone in a boxing match cannot defend themselves properly, for example. Some sports may also allow a competitor to voluntarily yield to their competition. Ragequitting fits in with this as well, since gamers can always decide to simply turn their game off. Team sports require group coordination and communication in ways that individual sports don’t. Whether you want teams or individuals compete affects a lot of things about your sport design. The combat reference here is the duel, which is fought one against one; the skirmish, which is smaller groups against each other; the battle, which pits whole armies against each other; and finally a whole war. Online gaming has generated its own blend of team and solo sport: coopetition. It’s cooperative, because you are completing objectives together and won’t be successful if you don’t. But it’s also competitive, because each of you will want to get the points and rewards individually. This becomes very clear in games inspired by Left 4 Dead and other games designed around LAN dynamics. Because the dynamic changes drastically when players are playing “alone together” and cannot simply lean over and yell for their friend to help them out. Throughout history, particularly in combat sports of different kinds, symmetry hasn’t always been relevant. Gladiators pitted against wild animals, or one with a trident and net pitted against another with a sword and shield, has been a recurring phenomenon. Usually either because someone has wanted to prove their ability under special circumstances, or because the competitors had no say in the matter to begin with. Conceptually, it’s a lot easier to design something for symmetrical opponents that are all expected to do the same things during a competition. Symmetry means that all sides of a competition are following the same rules. This is what generates the many layers of matchmaking regulation that sports may have. Weight classes, for example. Some sports require costly equipment, creating a high barrier of entry. Though some can afford to field their own race cars in scrappy “ folkrace ” competitions, for example, motor sports like NASCAR and Formula 1 are prohibitively expensive. The rules in place for such sports mean that it’s reserved for competitors with large financial backing. You may wonder how this ties into game design at all, much less combat. But it’s enough to think about games with items and character builds to see some parallells. In one particular Destiny raid, if you couldn’t show everyone that you packed an Ice Breaker and/or Gjallarhorn , you could be kicked out . What equipment your sports design will require depends on many things, of course, but it can be well worth thinking about. From the quirky golden snitch of quidditch (probably set up to poke fun at real-world sports) to things like the lacrosse stick basket handle, the equipment used to perform a sport can both dictate how it’s played and serve as excellent icons representing the whole activity. Though many sports may claim to be individual, they still allow competitors a crew to help them with all manner of things. This is of course similar to any form of stable, camp, or club, where the sum of the parts will affect how good your training is. But some sports allow this during a competition as well. Someone to patch you up between boxing rounds, or to check your tire pressure during pit stop. Maybe you can even look at the remote operator in Robot Wars as crew , and the robot itself as the competitor . Since we can’t really trust competitors to judge each other fairly or even to concede victory in cases where it’s a bit unclear who won, we may need a third party. Someone to call no context, to say when a goal scored or not, and to make sure we end our match on time. In digital games, computers can usually carry this burden, but in sports we use referees. If you want someone to be the referee, you need to figure out what they know and what they do. Which powers they have. In the eras of game design post , the idea of an umpire was discussed. But an umpire or a Dungeon Master is usually present to make the game world fair and not to adjudicate competitive results. Before you launch your design, you should consider how you want people to talk about the activities involved. Many sports have their own vernacular that tie the activities to what is happening in the sport. Inning, yardline, takedown; in digital games, deathmatch, kill, headshot, loot, powerup, zerg rush. Some of these expressions you can’t really invent. They’ll come naturally from how players interact with and talk about your game while playing or strategising. But it’s a great exercise to try to simplify terms, mash them together, and consider all the different strategies that players may use and how they’ll describe them. Even to invent a silly expression and then use it to make sure that you remember the concept it represents. Related to this is also the narrative of the game. Even if soccer is simply people chasing a ball across a field (if you are cynical about it) the story is one of a fight team against team where the winner takes all. The teams represent cities or clubs, and they are serving their fans; fighting for their fans. Not to mention that each player on each team may have their own fans and life struggles hyping up the competition. The words you use and the story you tell should be easy say and unique to your game. It should also be relatable. Sports have the advantage here, since it’s much easier to identify with kicking a ball against a garage door just like your childhood hero did, than it is to imagine yourself shooting zerg on a distant planet. This post took me a long time to research and write. Part of that is that balancing is a form of authorship . Just as with a linear story, if you want a balanced competitive experience, you must use a heavy hand to make it so. Often against the grain of your community, who will be enjoying the exploits they find and quickly get used to the dominant strategies presented. They will therefore loudly voice their dissent when you change the things they have been exploiting. Ultimately, though games like The Finals are trying, competitive games and a high degree of dynamics is very tricky to combine. The tools we use to balance our games are not very conducive of the right side of the master scale . This doesn’t mean you shouldn’t try, however. Systems at a gameplay level, where they can be balanced against each other, can still be very useful. Just be prepared to iterate a lot before the play experience is tuned right. Add time . Pushing for the shortest time has the added benefit of providing better entertainment for spectators. Add score . Define an activity that scores, then award victory to the competitor with the highest score at the end of a game. Add points . Award points based on an impartial panel and the ability of competitors to match specified expectations. Add limits . A competitor can only use a limited number of attempts or resources (such as the number of arrows for a bow) and must perform as well as possible within those limits. Add ladders . An additional way to generate results is to have more than one competition to determine the full outcome. This can be an elimination-style tournament where only one out of a roster of competitors will claim the prize, for example. Sudden death. Rather than using time, or in addition to time, add a condition where the game ends in immediate victory for a competitor. Yielding . Allow a competitor to voluntarily call out their own defeat. Either so an only opponent wins or to drop out of a larger competition.

0 views