Weekly WaveShine #1: Design Balancing, Cameras in Unreal, and What’s a WaveShine? – Jack Park

JACK PARK -
GAME DESIGN
PORTFOLIO

Weekly WaveShine #1

Design Balancing, Cameras in Unreal, and What's a WaveShine?

Hello, and thanks for stopping by for the first entry in my Weekly WaveShine series! In this week’s entry you can look forward to:

What’s a WaveShine and the purpose of this blog series [Go To]
A writeup of a game balancing exercise I performed this week [Go To]
The technical work I’ve been doing with cameras for my side project in Unreal [Go To]
My reading and a summary of my notes on analytics from Game Balance [Go To]

What’s a WaveShine?

A WaveShine is a sequence of moves that Fox and Falco can perform in Super Smash Brothers Melee where they use their Reflector followed by a WaveDash to move quickly in a desired direction. The more well-traveled among you may already know WaveDashing as an exploit that competitive Melee players have used to “break” the game, and WaveShining is a natural extension of this technique.

A WaveShine can be simply described as reflection followed by forward movement. I’ve realized that I spend almost all of my free time working to build my game design skills, and don’t spend enough time adding that work to my portfolio. So, in the spirit of the WaveShine technique, this blog series is intended to create the space for me to reflect on what I’ve accomplished this week and (hopefully) move forward in my journey to working as a AAA game designer.

WaveShine Example

An in-game example of a fox WaveShine can be seen from 0:00 to 0:01. It’s quite quick!

[Back to Top]

Game Balancing Exercise #12.2

I recently finished reading and taking Chapter 12: Progression in PvP Games of Game Balance by Ian Schreiber and Brenda Romero. At the end of each of these chapters are a few design challenges that I like to use in order to apply what I’ve learned each week. I picked my response to Exercise 12.2 to transcribe from my notes here. First, a brief summary of the problem:

The Rules of the Game

Players: Any Number
Setup: Each Player begins with 2 forces.
Play: On each Player’s turn, they can either gain 1 force or attack another Player with any number of forces. Both the attacking and defending Players lose this number of forces. If an attacking Player attacks with greater forces than the defending Player, the defending player is eliminated from the game.
End: The game ends when only one player remains.

The Problem(s)

Add, remove, and/or alter the rules of the game to make the game more playable and compelling while addressing the following issues while making the smallest number of changes possible:

Players have no incentive to attack.
Under optimal play, the game never ends.
With greater than 2 Players, multiple players could band together and target a single Player, eliminating them from the game with no opportunity for counterplay.

Defining the Problem Space

Typically, when approaching any design problem, I first start by defining the problem space. While there is definitely merit to “just getting started”, I personally have found that rapid iteration and implementation gain a lot of value when there is a clear intention behind these actions. To me, the problem space typically includes the context the solution will be used/played in, the target audience of the solution, and any constraints, whether assumed or explicit, on the final solution. I adjust the level of detail of the definition of the problem space based on the importance of the design solution in question. In a team setting, I’ve found that a clear shared understanding of the problem space can help define the criteria against which competing solutions can be measured against. In this scenario, the assumptions I made as I defined the problem space are as follows:

Context: The overall simplicity of the rules and the openness of the number of players implies to me that this game is intended to be played in a wide variety of settings as a means to casually pass the time. 20 Questions seems to me like a game that would be played in similar contexts and time spans. The mental image of the context in which this game could be played is between the passengers of a road trip.
Target Audience: Based on the limited complexity of the rules as well as the assumptions made above about the context in which the game is to be played, I believe the intended target audience of this game is broad, including both adults and children.
Constraints: Changes to the rules should remain simple and few in number. The design problems explicitly pointed out above should be directly addressed by these changes.

Using these assumptions, I can determine the following qualities to be desirable in the final solution in no particular order of priority:

The overall length of the game should be short. This is because it is intended to be a casual means to pass time before moving on to some other, more important activity. A shorter game length helps reduce the Players’ investment in the outcome of a single instance of the game, making it easier to quickly drop the game and move on to whatever they were waiting for. This also ensures that eliminated Players don’t have to spend a lot of time waiting for the next game to begin. Approximately 5 minutes?
Individual turn length should be short. This is because the target audience includes children who tend to have a low attention span and overall patience. Additionally, if individual turn length is too long, then as more Players join, the more time an individual needs to spend resolving their turn.
Complexity and numerical scale should remain low. If the number of forces are too large or if resolving a turn becomes too complex, then scorekeeping can become a challenge and the game will no longer fit the casual context we assumed above. It would also become less accessible to part of its target audience.
Losing players should not be punished excessively. Considering again the mixed nature of the target audience, it would be particularly frustrating for a younger player to feel they have no chance of winning against an older sibling who knows more optimal strategies.
Players’ choices to attack/gain forces should be more meaningful. This is based on the design problems outlined by constraints, in particular the directions to make the game more compelling and to address the fact that players have no incentive to attack.
The overall average result of the game’s economy of forces should be negative sum. This will address the constraint to resolve the issue that the game does not end under optimal play, and will help with keeping the length of the game short and numerical scale low.
“Teaming up” on players should not be incentivized and potentially disadvantageous. This helps to address the constraint to resolve the issue of multiple players banding together to eliminate an individual player.

Simultaneous Turns

The first thing I considered when deciding on a solution was #5 from the above list. Simply put, this game is not very fun and there is very little sensation of interaction between players and meaningfulness behind choices. In my opinion, the driving factors behind this is that there players have perfect knowledge of the state of the game when their turns arrive, they have very few choices to choose between, and there is little incentive to make predictions on the future state of the game. Unfortunately, increasing the meaningfulness and richness of decision-making for players on an individual turn will actually work against several of the desired qualities mentioned above.

As a result, the first change that I made to the rules was: Players privately decide on their intended move for the turn before simultaneously revealing their intent to each other and resolving the outcomes of the turn. This change helps to keep the length of each player’s turn low (#2 above). The only time where a player is uninvolved in what is “going on” within the game is in the scenario where another player is taking a long time to decide on their move. This change can also increase the meaningfulness of Player’s choices (#5 above). Since they do not know the decisions of other Players, an individual player is more invested in what their opponents are doing and accurate predictions can be made more rewarding with additional changes.

Unfortunately, this change alone does not address the issue that the optimal strategy is still to continuously gain forces (part of #5 and #6 above). If on the first turn, a Player chooses to gain forces and is attacked by an enemy, then depending on the details of how turn resolution is accomplished, in the worst case, the gaining Player will tie since both of their armies will have 2 total forces, and in the best case they will win, since their army will have 3 forces, and the attacking army will only have 2 forces. Additionally, if a Player does decide to attack, there is very little reason to attack with anything less than their full forces. This is because regardless of the outcome of the attack, the attacking Player will lose their forces, and withholding any forces will increase the chances that their attack will fail. As a result, Players have effectively two choices: attack or gain forces. Regardless of what adjustments we make to the rules, if the Players are only left with two choices, then whichever is most likely to yield the ideal result will become the optimal strategy and limit the meaningfulness of the choice to attack or gain.

In order to address this issue, I decided it was necessary to make it meaningful to attack with a limited set of forces. Considering the starting set of

Defending Forces

In order to address this issue, I decided it was necessary to make it meaningful to attack with a limited set of forces. This led me to the idea of the remaining forces “defending” if they are not committed to a full attack. This leads to the following options:

Attack with 2 forces, defend with 0 forces.
Attack with 1 force, defend with 1 force.
Attack with 0 forces, defend with 2 forces.
Attack with 0, gain a force.

I then thought about what the emotional “feel” was behind each of these choices. Attacking with 2 forces feels aggressive while splitting into 1 attack and 1 defense feels balanced and conservative. It’s somewhat unclear what should happen to defending forces when a player decides to gain a force, and in the case where players decide to gain a force or to attack with 0 and defend with 2 forces. Both of these options feel more passive and defensive. Thus, I felt the option to defend with 2 forces overlapped enough in overall emotional intention with gaining a force that it was not necessary.

This effectively leaves 3 choices:

Attack with 2 forces, defend with 0 forces.
Attack with 1 force, and defend with 1 force.
Attack with 0 force, gain a force.

This makes the idea of a rock-paper-scissors relationship between these three choices appealing. Effectively, the first turn between two players becomes a game of rock-paper-scissors and all that remains is to determine specifically which choices beat which and what the reward/penalty should be for winning, losing, and ties in this exchange should be.

I decided that:

Attack 2 + Defend 0 should beat Gaining a Force
Gaining a Force should beat Attack 1 + Defend 1
Attack 1 + Defend 1 should beat Attack 2 + Defend 0

Qualitatively speaking I felt that , attacking with 2 is decisive enough to punish the greedy choice of gaining forces, but attacking with 1 is too noncommittal to do so. A balanced approach of attacking with only 1 force beats out the excessive aggression of attacking with 2 forces.

With the desired relationship between the three options established, I moved on to deciding what the outcome of winning/losing this RPS should be. Considering the above qualities, I felt that the winning army should have 2 forces, and the losing army should have 1 force remaining. This way, a losing player isn’t excessively punished, leading them to lose the game outright, and the average outcome reduces the overall number of forces within the game, meeting a number of our desired solution qualities.

With these outcomes in mind, all that remains is to establish a set of rules for resolving turns between players that ensures these outcomes occur.

These rules are as follows:

When you gain a force, you use 1 force to train the new one, and you can only use your remaining forces to defend.
When you attack, you must choose the number of forces to commit to the attack. The remaining forces become your defending army.
Only attacking and defending armies battle.
When armies battle, if the attacker has greater forces, the defending army is destroyed.
When armies battle, if the defending army has equal or greater forces, then both armies lose forces equal to the number of attacking forces.
If your army attacks and the defending player has 0 defending forces, then the attacker steals one force from the defenders army after all attacks and gains have been resolved.

Without working out every example here, the results of the first turn between two players is that if one player wins the RPS versus the other player, then they will end the turn with 2 forces, and the losing player will have 1. If both players attack with 2 forces, then there is no change in forces. If both players attack with 1 and defend with 1, then both Players’ forces are depleted to 0. If both players gain forces, then they both will have 3 forces at the end of the turn.

Assuming that each outcome is equally likely to occur between 2 players, 6 of the outcomes result in -1 net forces, one of the outcomes results in -4 net forces, one results in 0 net forces, and one results in +2 net forces. Overall, on average, a first turn interaction between two players should result in -8/9ths forces, an overall net negative outcome.

These changes effectively provide 3 different choices in a RPS relationship for the first turn between two players. Since turns are taken simultaneously, this creates a more meaningful interaction of attempting to read and counter the opponent’s choice. The overall outcome of the interaction is net negative, but losing the first interaction does not cause the player to lose the entire game. Overall, these changes meet a number of our design objectives. The only concerning case is when both players split forces, the game ends on the first turn in a draw. Further iteration would be desirable to address this.

Dealing with Being Behind

I then considered what should happen in the common case where 1 Player has 1 remaining force, and the other Player has 2. When again considering the target audience as well as #4 above, I think that the Player with less forces shouldn’t be automatically guaranteed to lose and should actually have a chance to come back. However, the Player with greater forces should still receive an advantage. Thus, I added a Last Man Standing rule: When a player has 1 remaining force, instead of their usual action, they guess how many forces will attack them. If their guess is correct, they gain 1 force and no forces are lost for either them or their attacker. If their guess is incorrect, they are eliminated from the game if they are attacked by any force equal to 1 or more.

Thus, a losing player always has a chance to come back, but a winning player gains a statistical advantage for having more forces. Without this rule, it becomes almost impossible for the losing player to regain a force and get back into the game. In order to prevent the winning player from indefinitely gaining forces, I also added the following rules: Players may only gain forces if they did not choose to gain forces last turn. and Eliminating a Player awards the attacking Player with 1 force.

This makes any of the choices for a player about to win a calculated risk, gives a losing player a chance to come back, and adds an incentive for players to attack, while still making it statistically likely that players will end the game.

Dealing with Ganging Up

With simultaneous turns, the case where multiple Players attack a single Player is unclear. This is actually good, since it introduces an opportunity to introduce a clarifying rule that will prevent Players from intentionally ganging up on a single victim (#7 above). Since it’s impossible to guess whether or not other Players will attack the same Player as you, I feel it would be unfair to punish players for attacking the same target. Thus, the rule I decided on to handle this case is: If multiple Players attack the same Player, the Player with the greatest attacking force actually performs the attack. The other Players are not affected by the changes as a result of this attack, but their attacking forces cannot be used to defend. If there is a tie, then the first player in the tie sitting clockwise from the defender attacks.

As a result, it’s no longer possible to explicitly eliminate a single other Player in a single turn and Players aren’t unduly punished for getting unlucky and attacking the same target.

Cleaning Up Simultaneous Turns

There are a few other things that are unclear under the current rules. Specifically, it’s not clear the ordering of resolving actions in a given turn. Just to clean up the logistics, I introduced a few rules: The first turn, designate someone as the “leader”. They figure out who is attacking them, and resolves that attack. The person sitting clockwise from them resolves their attacks next until all attacks for the round have been resolved. The “leader” then resolves any forces gained before again proceeding clockwise until all gains have been resolved. The “leader” resolves any forces they’ve stolen from other Players again proceeding clockwise. Finally, the “leader” passes to the next player clockwise and the turn ends.

These rules are mostly just to prevent open chaos in figuring out the results of everyone’s actions. Some testing to make sure this doesn’t afford any undue advantages would be ideal.

To Summarize (Finally...)

So finally to wrap up all of the added rules are as follows:

Players privately decide on their intended move for the turn before simultaneously revealing their intent to each other and resolving the outcomes of the turn.
The first turn, designate someone as the “leader”. They figure out who is attacking them, and resolves that attack.
The person sitting clockwise from them resolves their attacks next until all attacks for the round have been resolved.
The “leader” then resolves any forces gained before again proceeding clockwise until all gains have been resolved.
The “leader” resolves any forces they’ve stolen from other Players again proceeding clockwise.
Finally, the “leader” passes to the next player clockwise and the turn ends.
If any Player has no forces at the end of the turn, they are eliminated.
If all Players are simultaneously eliminated at the end of a turn, they tie for first place.
To resolve an attack, when you gain a force, you use 1 force to train the new one, and you can only use your remaining forces to defend.
When you attack, you must choose the number of forces (minimum 1) to commit to the attack. The remaining forces become your defending army.
Only attacking and defending armies battle.
When armies battle, if the attacker has greater forces, the defending army is destroyed.
When armies battle, if the defending army has equal or greater forces, then both armies lose forces equal to the number of attacking forces.
If your army attacks and the defending player has 0 defending forces, then the attacker steals one force from the defenders army after all attacks and gains have been resolved.
If multiple Players attack the same Player, the Player with the greatest attacking force actually performs the attack. The other Players are not affected by the changes as a result of this attack, but their attacking forces cannot be used to defend. If there is a tie, then the first player in the tie sitting clockwise from the defender attacks.
When a player has 1 remaining force, instead of their usual action, they guess how many forces will attack them. If their guess is correct, they gain 1 force and no forces are lost for either them or their attacker. If their guess is incorrect, they are eliminated from the game if they are attacked by any force equal to 1 or more.
Players may only gain forces if they did not choose to gain forces last turn.
Eliminating a Player awards the attacking Player with 1 force.

Next Steps

As a result of these rule changes, I believe the game is now more interactive and player choices are both more numerous and more meaningful. A few mechanics have been added in that help to ensure that winning players will gain a statistical advantage over time which should help keep the overall game time short. On the other hand, losing players still have a chance to stage exciting comebacks, helping to improve accessibility between players of varying skill levels. The simultaneous turns mechanics help to minimize individual player down time and prevent malicious ganging up. Finally, a few mechanics make it less likely for players to indefinitely extend the length of the game.

Some of the drawbacks of the design that I see are:

This re-design required a more significant number of rule changes that I originally intended. These additional rules may exceed what can be easily memorized by all players.
The changes have also increased the complexity of the game, potentially constraining the target audience and reducing effectiveness of addressing the original design intent.
The mechanics of resolving turns require players to have some means of writing down and revealing their intended moves. I assume all players would have a smartphone or some digital device, though pencil and paper would suffice as well. This does somewhat limit the portability and original intended use case of the design as well.

In my opinion, the best way to determine the extent of these drawbacks is to perform playtesting with a representative user audience. Additional points of improvement include cases where there are 3 or more players, and if there are any noticeable balance concerns in such a case, as well as cases where players have a larger number of forces and whether there are any undesirable interactions in these scenarios.

I figured at this point, I’d generally addressed the point of the exercise, and moved on to working on other things. I’m a little dissatisfied overall, because while I do feel like the game is more interesting and has greater strategic depth, it also feels a little clunky and inelegant, requiring a lot of rule changes to get there. It almost makes me wonder if I’ve just completely altered the original game and made up something completely different.

[Back to Top]

What I’m Working On: Cameras in Unreal

Right now, I’m working on a side project game in Unreal that I’ve codenamed Metal Wings. Its byline is:

Metal Wings is a single player 3rd person MOBA/RTS-style rogue-like where players incrementally level up, acquiring skills, gear, and passives as they fight increasingly difficult waves of enemies to survive their journey to reach the boss/bosses.

You can see a Game Design Doc that I’ve written mostly to help organize my thoughts here. You can also see a Vertical Slice Spec here. Finally, you can see the project on GitHub here. Overall, my objective is to complete a reasonable vertical slice that will show well in my portfolio and also serve as a means for me to learn and demonstrate my proficiency with C++, Blueprint scripting, and Unreal Engine concepts.

This week I’ve mostly been focused on getting a handle on the general architecture in place in Unreal and setting up controls for the Free Player Camera. While I’ve been able to get a simple implementation down, I’m also using this as a chance to figure out how to divide up the different parts of this functionality appropriately. I plan on spending the coming week cleaning up the implementation and giving a more in-depth tour of the implementation and architecture I’ve got in place for this game in the next Weekly WaveShine.

[Back to Top]

What I’m Reading: Analytics and Game Balance

I currently spend a few hours each day reading and taking notes from Game Balance by Ian Schreiber and Brenda Romero. The book itself mostly covers systems design and various techniques for mathematically modeling and statistically analyzing progression and balance between various systems within a game. This week’s reading was Chapter 13, Analytics. This chapter focused on:

Determining which scenarios and purposes are well-suited to analytics-driven design
How to define the problem space when applying analytics-driven design techniques
A brief rundown of the process most companies tend to follow for gathering metrics for analytics
Some techniques for performing statistical analysis on said metrics to deliver helpful design insights
A few case studies of how these techniques can be applied to fighting games as well as MOBAs

[Back to Top]

JACK PARK - GAME DESIGN PORTFOLIO