Reading 

● GDW Chapter 10: Functionality, Completeness and Balance (pages 305—338)

Prototype Testing, Four basic steps of design:

• Foundation: the core mechanic,  a system, what makes the game fun? (playtesting on your own, your intuition will decide whether or not this will be a fun game or not)
• Structure: making the initial prototype playable/functional for others to test (basic, clunky level that doesn't have to be perfect)
• Formal Details: building a fully functional game, that is [functional], internally complete, and balanced; experience will help judge what choices to make to make a clean, balanced system but at the same time this experience may not work in a different game
• Refinement: after your game's core mechanic is complete and fun and then balanced in a way that enhances the system , revisit what your original vision for the game was and focus on making that vision true at this step of the stage while making the game accessible to others

Functional game: "...the system is established to the point where someone who knows nothing about the game can sit down and play it (308)."

In which a player can play the game without being aided by the tester or developer, they can use what is given to them (in paper and software prototype) and progress in some way to reach some sort of conclusion, which may be a finish line or an ending of a story

Our job as the designer to prototype the core mechanics in addition to the game's overall functionality, which means loopholes that need to be identified and resolved in order to make the game work and complete.

Looking back at my team's "Love is War" card game, a lot of the elements we added to the game's system actually made the experience less fun. In our game specifically it's because we made our game more "structured" and restricted and ruined the core experience of the game which was to allow players to argue and debate, often times turning into a chaotic mess. That was something we wanted but how could we control it better without restricting it too much?

As Tracy Fullerton says, it's hard, the more you test these complex systems you create, the more you discover how malleable your game is. The possibilities for changes in the system are endless, but so are the potential of loopholes and deadends that come with this. To identify what might be missing, you should look over what your rules are to then see what is causing these flaws in your system. From there you will be able to conjecture what should be removed or revised and then forward these ideas towards testings to reach a high standard of what you feel and what is objectively “complete”.

There are many possible solutions to an issue in your system, what ends up being the final solutions relies on the core idea and what you envision your game to be. This and along with playtesting sessions and observations from your player base will help guide you to these decisions.

A loophole is a flaw in your system that a player can exploit to their advantage, ruining the experience for other players. As long as these loopholes exist, your game cannot be considered complete. However, while closing off these loopholes are important, it is also as important to avoid closing off potential emergent play. This can be seen throughout the history of MMOs regarding their solutions to player killing versus law-abiding players, keeping the excitement and thrill while making the game fair for players who do not wish to be unfairly slaughtered. To find out the loopholes in your design, test individual aspects of your system and challenge playtesters to think of creative ways to get to the objective (think of hardcore players and playtesters who enjoy thinking outside the box).

Dead ends are another type of flaw that disrupts the flow of gameplay by usually ending it, enabling the player to progress to their objective and, ultimately, the resolution of the game.

Balancing a game may be about balancing two players in an asymmetrical game so that their starting points are fair or may even be about balancing the difficulty of a level in accordance with the skill level of the player in a singleplayer game. Four areas of balancing mentioned by Fullerton include; variables, dynamics, starting conditions and skill.

Variables of your system are a set of numbers that define the properties of your game objects (ex: number of players, size of play, number of resources). According to how lower or higher these variables are will affect the play experience in different ways. An example of this is raising the number of lives the player might have, decreasing difficulty, or decreasing the value of lives, increasing difficulty. In digital games, these values may be difficult to analyze upfront, but can be conceptualized with our experience. In the end, the way you draw these values should be done in a way that properly showcases your vision and player experience goal of your game.

Dynamics are the relationships of things like rules and even objects in your system. In cases where a combination of these set of things may bring unexpected results, results that might even cause loopholes, is called an imbalance in dynamics. These imbalances will need to be identified and, according to what the problem might be, rules, variables or even the introduction of new rules may be issued to mitigate them. 

Reinforcing relationships help to iron out these imbalances in dynamics. As mentioned earlier, this may be the introduction of new procedures of play that take away unfairness which is mostly a situation where one player is snowballing in power while other players are left behind. The goal is to prevent this from happening while disallowing the stagnation of the gameplay. This could be allowing the weaker players to band together against the powerful player, allowing chances for other players to step up, or even adding an element of randomness. Note: you never want to drag out the ending, (unless it’s part of your play experience).

In balancing values of a set of/your game objects or other sets of variables, it is a good rule of thumb to keep them in proportional to strength while providing a large variety/range of choices to induce strategizing against strengths and weaknesses. A method of placing out these advantages and setbacks on the graph is to illustrate them on a payoff matrix, other times known as “rotational symmetry”. This can be seen in MMOs where players can choose their race in the character selection screen, with a variety of selections comes with the balancing of starting conditions from what these races might grant the player as a “passive”, an innate power specialized from a particular race. However, inside the MMO each of these races will have different sets of skills chosen from their class, so how might the developers balance this? Often times, from my observations, there is a graph in which one class may one-up the other while being disadvantageous to another. In balancing a game, make sure the player’s choices are not limited, otherwise their experience will be negatively affected if they are with a disadvantage towards other players.

This relates to the concept of having equal starting positions and, thus, equal chances at the opportunity for victory. This does not mean giving players the same amount of resources and setup but conceptualizing how a set of different game objects or resources and variables may be equal in power to that of a whole different set.

Symmetrical games: the sets mentioned above are all equal between players, the issue that these games deal with the most is turn order - the possibility of the starting player beginning on an advantage by having the first turn.

Asymmetrical games: players will each have a different set, the job as the designer is to tweak these sets so that they are balanced although different. These games have the potential to model conflicts in the real world.

Asymmetrical objectives [different win conditions between opponents]: 

• Ticking Clock: holding out for a certain amount of time to succeed your objective or mission
• Protection: in which one side protects something while the other tries to capture that or destroy it
• Combination: A combination of the “Ticking Clock” and “Protection” objective (ex: CS:GO)
• Individual Objectives: in which players have their own objective in accordance to their role or character in the game (that may or may not be known to the other players, ex: Mafia)
• Complete Asymmetry: Scotland Yard

Balancing of skill involves matching the player’s current skill level to the level of challenge provided by the game system, how difficult this might be is not only suggested by the chart between challenge and skill (anxiety and boredom) but also by how you want your player experience to be in that level and overall. Progression of level and difficulty [challenge].

The chart below portrays finding the average skill level of a player and the threshold of that average level, a novice,  in comparison to the skill level of hardcore players. Once you realize these boundaries from playtesting, you can balance out the variables in your game to suit these skill levels while progressing in difficulty at the “median” rate. 

Not all cases allow for this balancing through median skill level, in which cases the designer should balance dynamically. This might mean, for example, programming the system to adjust to the player’s skill level. An example of this are the difficulty settings when you first start a game, but in the first place, how does the designer judge these difficulties? I wonder if it’s actually tested or an analyzed increase of values that the designer may think raises difficulty and which it may, but not dynamically. Tetris also balances dynamically in accordance to speed, a variable that gradually increases throughout play.

In the balancing of computer-controlled characters, in other words, NPCs and AI, they must seem human and be able to make mistakes or otherwise a sniper enemy AI that lands every shot will definitely not be fun for the player.

Being a good designer does not only mean having the skills and experience but also being able to work with your team.

Techniques for balancing your game:

• Keep calm and think modular: most games are not comprised of a  single system, but a set of interrelated systems - break up your game in discrete functional units to see how the mechanics of each unit may work with each other, when thinking modular you will be able to see what unit has an impact on another when changes are made
• Purity of Purpose: every objective and mission is clearly defined - break down your game mechanics into building blocks using a  flowchart to define precisely what the purpose is of each block is
• One change at a time: - testing becomes easier, one change can already  impact many aspects of your game’s system, increasing the amount of changes increases the haziness of clarity in what has changed or affected the system
• Spreadsheets: keep track of data while mirror the game’s structure, take the chance to use this spreadsheet to communicate with the team’s programmers