How to Set Up Balance

So as you all know, the Undeadables is in development as a Warcraft 3 map.

Hewie sleeps over once a week, and we just make progress, watch movies, stuff our faces, and then as I wake up earlier than him in the morning I sneak out making him feel like a cheap whore.

Err... for the last reference I'd recommend seeing Up In The Air.

Also, a classmate at the AIE kind of pointed out an issue with game design blogs (or more, a personal reason for why he doesn't blog) - and that's because of people possibly stealing ideas.

I made my blog for educational reasons - both for myself and others. I like to clarify my thought by writing it all down, and I hope people read it so they can maybe refine the way they think about games - or, in some cases, they can flat out disagree and perhaps change mine.

That said, projects such as The Undeadables, and any other full game concepts I post here are my intellectual property (and any others who I am working with), and pretty much don't steal them.

Not saying they're good enough to be stolen, but in a world where they're selling L4D expansions as totally new games - I'm just being careful.

Introduction

This blog post is about starting your game, and setting it up to be balanced.

This is something you need to get right from the start. Prepare for it before you start making the first prototype. If you don't set it up properly at the start, you're going to regret it - especially if you don't apply any other methods of balance, or test it extensively.

Test your changes throughly with reference to balance. For every change you make to a player's stats and such, don't just boot up the game and see if it updated properly... makes tests to see how many enemies you can take on at once (for example), in comparison to what you'd like the player to be able to do.

Not testing as you go creates not only potential for massive code errors, but potential for terrible balance problems.

I follow this process when creating a game idea, when thinking of balance.

7 Steps to Ensuring Balance

1. Create expectations for all basic variables that will affect play, and evaluate how they will affect balance.
2. Apply any simple balance strategies that will be used.
3. Develop expectations for a battle between two or three basic units.
4. Test the match ups.
5. Alter until expected results are reached.
6. Repeat step 3-5 for all other units, with reference to step 1-2.
7. Test over and over and over whenever changes are made.

Now I'll go over each step.

Step 1 - Create expectations for all basic variables that will affect play, and evaluate how they will affect balance.

#1 is extremely important, but very few people even think of it. Most people jump right into "Okay how many backstabs should it take to kill a Mage?" without thinking of variables that will make these numbers vary a lot.

You should consider such variables as:

1. Game Time - The average time total in an instance of the game (such as a 'round' or a 'game'), as well as the rate at which players progress through the game is extremely important when it comes to balance.

For example, A character who slowly amasses massive amounts of power throughout a game will love a full 80 minute game as it suits his play style, while a character who totally dominates early in the game would love a game style that can be beaten within 10-20 minutes.

The game time in a single instance of play greatly affects balance depending on PCU's rate of power gain throughout the curve, so Game Time should be clearly defined.

That said, game time should be clearly defined anyway - as let's face it, most players can't play a 3 hour game, and others won't get much satisfaction from a 1 minute skirmish.

For the most part, most team based player vs. player games are focused around 40 minute times, often split into halves and quarters. For individual versus individual games, the time may be anywhere from 5-10 minutes.

That said, it depends on the game, and its gameplay. An RTS will always be slower than a fighting game, and an RPG will hopefully be even slower than that.

Pick a game similar to yours, and shoot for that game time.

Also, as a little pointer, if you're having trouble finding find the best game time for your game, shorter is better than longer for the majority of players.

2. Number of Players - the number of players in an instance of a game is important. Thankfully, most people will immediately define this, unlike average game time. Like game time, number of players definitely affects game balance.

If the game is based around teams of 2, and one character has the ability to disable another for a long period of time, that player will have a lot of power as he can reduce the power of a team by half, and potentially make combinations of that team's abilities impossible to pull of. Rather, if he was in a game where teams were of hundreds of units, being able to disable one is fairly pointless.

Similarly, Area of Effect abilities become more useful than single target abilities when teams get larger. Common sense.

Pretty much, make sure you know how many players will be playing, and how it will affect your game.

3. Player Skills - How much skill can a player apply to your game? And what skills in particular? Will your players have to out-aim each other, or will other skills be called into play?

If you haven't read my article about Skill Ceilings and Floors, I recommend you do so.

Remember how your effectiveness at your skill ceiling is equal to your absolute potential?

If a unit can reach their absolute potential, and it is far more effective than other units at this potential or skill level - you have an imbalance.

This one can be difficult to test, as you don't know how players will play until you have them playing and developing skills. Still, applying logical reason will at least lower the chances of massive imbalance if players formulate unexpected play styles.

First off, know your genre and how it's played - if you're making an FPS, know that there are Quake players out there who will hit players in the air with rockets from half the map away, and there'll be Counter Strike Snipers who can hit a head with less then half a second exposure.

Research other games and skill levels of players who at the top of these games.

Another concept to understand is... simple inbuilt restrictions. Cooldowns on abilities means they can't be spammed as fast as a user clicks a button. Move speed limits means a player can't zip around the map as fast as they can hammer the WASD buttons.

I feel like I'm babying you all, but - well, if you introduce simple time limitations on each action that require it, you're not going to have strange bugs and combinations of actions that can result in imbalanced movements and attack strategies.

The last point relates largely to the first two - know your engine. If you're creating your own engine, your software designers are going to have to understand the game and what is and is not allowed. You need to communicate properly.
Make sure they are knowledgeable of similar games and bugs/exploits/etc. that were in those. You may want to make a list of possible problems, and you will need good communication to ensure no bugs pop up.

If you're using another engine, play the games that have been made on it- and test bugs yourself. If one has a large following, especially a competitive scene - ask them about any bugs that are due to technicalities in the game (they may call them 'Advanced Techniques').

4. Game Area
The playable area in game also affects balance. This is quite obvious - someone who can maneuver faster will be able to run rings around slower opponents in enclosed areas, while Area of Effect attacks are extremely effective in enclosed spaces.
To limit the effects of game area on your game, you can try to make neutral areas that don't particularly favour any character - this is best for games where a stage advantage will imbalance match ups and can't be compensated for with intelligent play or team strategy (such as fighting games, in which stage balance is required as it's 1v1 and games are often very close and skill based).

There are many other variables that you must consider - and they will definitely change for individual games.
Find these variables then define them and their impact on your game's balance.

Step 2 - Apply any simple balance strategies that will be used.
Balance strategies are theoretical approaches to game balance that don't necessarily rely on number crunching to balance.

1. Role-based Balance
Role-based balance is a widely used balancing strategy - or, at least, it should be.
The approach involves looking at your PCUs, and giving them very specific and different roles within a team - while ensuring that the more rounded PCUs do not encroach too heavily on these roles.
If done correctly, you have a range of units who are not only exceptionally different and appeal to different players, but you ensure that no PCU is considered useless the entire role is considered redundant (in which case you have quite an issue and you may need to refocus your unit).

2. Strength/Weakness-based Balance.
Strength/Weakness-based Balance is where you give every PCU a main area of strength, and an easily exploitable weakness. The weakness is the key balancing point here. With the weakness, the PCU can be outplayed and exploited by hopefully any other PCU, whose own weaknesses can be played on. Similarly, with the different weaknesses come different strengths - and so players strive to battle in their element. The winner is ultimately the player who exploits the other's weaknesses and plays on their own strengths best - or, if both players evaluate the situation properly (and so don't enter situations where they will be weaker), it is defined by other skills.

The only issue is that often encounters will thus be based on luck, and running into someone who's in the wrong place at the wrong time. To counter this, map/game awareness should be highlighted as an important skill to players - and all PCUs should have the opportunity to act on awareness and turn ambushes around.

3. Counter-based Balance
Counter-based balance basically says "If every PCU has a reliable way of countering a strategy, unit or move, less attention needs to be focussed on balancing individual moves, units and strategies."

This is true to a point - but, well, you obviously can't smack an easy-to-use OHKO on a single PCU and tell everyone to "just dodge it" (much to the contrary of what many gamers think). Similarly, this strategy has the limitation of not being usable for all games

The idea is that if counters are readily available, and every player and PCU has access to them - there are no situations in which a player will be totally overpowered by another equally skilled player unless there are ridiculous mistakes (a character starts with 10% of the HP of other characters) or bugs in the game.

A good example is in Guilty Gear XX - where characters have the ability to do such things as

• Make their upper hitboxes invulnerable
• Emit a force that pushes enemies away.
• Do an immediate counter attack from block.

But that's not all, they can also use "Burst" which lets them totally break out of a combo if they are locked - counterattacking their opponent to break the combo.

Now here's the kicker - all characters have access to these moves. This means they have an array of defensive moves that effectively break them out of any situation, so, they always have a way of countering their opponent's actions.

Though, just so you don't read the above features of Guilty Gear and think people are unkillable turtles because they have too many defensive options, rest assured - every action above takes up 'Super' - meaning that you can't use them too many times unless you regenerate super by playing effectively.
The Burst actually uses up the Player's burst power, which regenerates slowly such that you will likely only get one burst per round. Also, if you fail to hit with a burst (which are fairly easy to block and punish), you lose all of your burst power, meaning you no longer have such a strong counter measure.
Pretty much, the game isn't too defensive - but every player has a lot of defence options to counter all imbalanced situations. This means you can have a larger variety of characters with a large variety of moves - with the potential for imbalance being far less than other games with a similarly varied roster.

Enough about Guilty Gear, anyway, I might make an entire separate post for it if I really feel like I need to give some praise for excellent balance strategy.

Step 3 - Develop expectations for a battle between two or three basic units.
Okay, so by now you're expected to know what variables will affect your game's balance, and you know what kinds of balancing techniques you can apply to your game (I also recommend you use one or create your own - think of what your game requires and what has been used in the genre.) - now you must highlight some basic combat situations and the outcomes of these situations.
Consider a couple of the units you wish to make, and say "X should be able to beat Y at close range, but should lose at close range" - or "X should be effective when pursuing this objective, but should be less effective when carrying out this task".
Do this with the most basic units - ones who are generally effective in most combat situations (for example a Sniper is not a good unit to start with because he sucks at close and moderate range combat, he is too much of a specialist).

A good idea is to use hit-counting and timing to describe exactly what you want to happen. This is not necessary, but useful of course.
If you want Unit X to kill Unit

Then you create these units in your prototype.

Step 4 - Test the match ups.
So you have your prototype and your units - you have your expectations for these units... let's get testing!
make
Play out several scenarios with the units and expectations in mind, and repeat them with slightly different positions etc. and make sure you're happy with the results - especially with regards to timing and hits.

If you're not, simply look at the values turning up, and see what can be tuned to make the match ups meet expectations.

As many scenarios as possible should be tested - but certain scenarios are well favoured over others.

You want to focus on common occurrences in the game - such as:

'Unit A counters Unit B. Unit B however has a slight level advantage over Unit A, and has ambushed the unit in favourable terrain at mid range - Unit B should win, but should sustain moderate damage (60% or so)'

This situation will arise.

However, there are obviously situations that are so unlikely that they aren't worth testing.

'Unit A counters Unit B, but has been afk for the whole game and so is still Level 1. Unit B is level 10 but ambushes Unit A in very unfavorable terrain at extremely long range. Unit B should still win without much problem.'

I think what I'm trying to say is, be thorough - but don't waste your time.

Really this is all just about controlled repetitions under different pretenses and tweaking the balance until it works well.

Repetition, repetition, repetition.

Step 5 - Alter until expected results are reached.

Ah I think I went over this in Step 4 with tweaking.

But, make sure you tweak intelligently. Make small changes, and make sure you clearly identify Variable Scope.

If you do this while tweaking, you should be fine. Save regularly, document and analyse any possible issues, test rigorously.

You know, all the good stuff.

Step 6 - Repeat step 3-5 for all other units, with reference to step 1-2.

Pretty much what we've covered so far - but more testing.

When you create a new unit - you need to know how the variables of the game will affect it (step 1), and if you have a balancing strategy in mind, you want to know how it will fit into that strategy (step 2), you want to know how it will interact with every other unit under different situations (step 3), you need to create and test these match-ups (step 4), then you need to make any alterations (step 5).

As said, we've covered it so far.

One little additional point I will make however is that as you create more units, the number of things you have to test increases and increases.

Think of it this way in a shooting game with 2 units you need to test perhaps 3 main situations - long range, medium range, close range.

Then you might want to test these in 3 areas, open area, moderately spaced area, enclosed area. That's 9 tests.

Let's add Unit 3 - you need to test him with 1 and 2 in each of these, so that's 18.

Perhaps units can be on teams, how will 2 unit 3s match up with a unit 1 and a unit 2.

What if unit 3 can choose between 2 weapons? What now?

As you add more and more, and there are more and more variables - the number of situations you need to test is astounding.

This is where balancing strategies come in.

The reason I recommend using balancing strategies is because they reduce necessary testing a bit - or, at the very least, aid it greatly.

This sounds awesome. But... well, let me be very clear.

You still need to test.

You still need to balance.

You still need to analyse.

I know some game designers that have taken a very devil may care attitude towards balance and testing because they think a balancing strategy will do all the heavy lifting for them.

"Hey, it's okay, we can do X because character Y still has a weakness to Z!"

No.

You're not allowed to arrive at that conclusion, unless you've done a lot of testing and analysis to come to it.

Don't get lazy.

Even with balancing strategies, I still test everything rigorously. Why? So I don't overlook an obvious problem and have to eat my words later.

Step 7 - Test over and over and over whenever changes are made.

This point has likely been sufficiently covered as well.

If I want you to go away with any knowledge after reading this blog post, it's constant testing is key to balance.

Conclusion:

This blog post was actually written over 2 weeks and had many paragraphs added and deleted over the period of writing, so frankly I'm just hoping it ties together nicely - but here's what I want you to go away with.

• Follow the 7 step process. If you follow it properly, and can follow the steps in reference to your game design - you won't miss a thing. Just know your game type, what variables will affect your balance, and possible balance strategies than can be applied and you'll be fine.
• Testing is key to balance.
• While balance strategies ease up on testing thousands of situations, don't even think of being lazy with it. You still need a lot of testing.
• If you're designing, do a lot of testing. If you're a programmer, get your designer to test. Designers often know what should and shouldn't happen, and how long it should take - or at least have a good idea of this.
• Setting up balance takes a lot of time, and must happen from the first prototype and units made, right through to the end. If you start too late, you'll likely need to totally remake some systems that would have been visibly problematic from the start. If you consider balance until the end, you'll likely have to backtrack changes.
• A monkey who understands balance scope and tweaking, testing a game for an infinite amount of time will eventually create a perfectly balanced game. Basically - don't give up. Keep testing, and thinking, and you'll get there with some hard work and ingenuity.

Anyway, thanks guys. I'd like to go in-depth for some balancing strategies.

Here's my to-do list for the moment:

• Pacing
• Single Player vs. Multiplayer Balance Concerns
• Balancing Strategies in Depth
• Canon vs. Gameplay
• Untitled Puzzle-Horror game idea.
• Untitled Puzzle-Adventure game idea.

I'll keep you all posted.

The Scope of Game Design (Refining the Problem)

Well, first off, I know you guys were all expecting a post on how awesome Knarf is - but to express that would take me too long to possibly contain in just a single blog. I would have to make volumes of blogs to cover her awesomeness.
(For those who don't know Knarf, she's an artist at the AIE :D)

Clarification

This blog post is what was originally going to be named 'Conservative Game Balance' - but I realised that I don't believe in conservative balance at all.

I believe in making the right changes.

This implies, of course, not making stupidly over the top alterations to systems that only need basic alterations. That is the meaning of conservative right there, but conservative also implies a resistance to change - and that goes against everything I believe in.

If there is a problem, I won't water down the solution to be "more conservative".

Introduction to Scope

So the title has been changed. I want to talk about Scope today.

Scope in game balance are the different environments and features of game play, and units in a game. They are areas related to their effects on gameplay, in order of importance. This makes it essential for refining balance problems - so you can fix them in the most effective way possible.

A High Scope Context relates to a feature that, if changed, will affect a large amount of gameplay - for example, if 90% of characters in a game use swords, and you change the strengths of swords, you are dealing with High Scope as it affects a lot of the gameplay.

A Low Scope Context relates to a feature that will affect a small part of the game, for example, changing a character's stats will only directly affect that character.

I borrow the term from the scope of a variable in programming - as they are very similar. The scope of a variable in program determines how much of the program can access it, while the scope of a balance issue or change relates to how much of the game will be directly affected. Just as you want to use the lowest scope possible when dealing with variables, you want to deal with the lowest scope possible for a game change.

The easiest way to figure out the scope hierarchy is to see how units are categorised in the game. If units are defined by their weapon (e.g. Rapier, Pirate and Warrior are all 'Swordsmen'), then the weapon is likely of a higher scope than the class's traits. If you change the weapon, it greatly effects all of them.

On the other hand, if if all weapons are character specific (that is, changing a weapon doesn't affect any other classes), the weapon is of a lower scope than the character.

Why Determine Scope?

The Scope of a balance problem is essentially its location in the system, and how much of the game the problem affects. A problem of a single's characters stats being too low is low scope, while a major weapon type being too powerful is high scope.

Effectively finding the scope of a problem involves narrowing down the overall problem to its absolute core. You want to find the lowest Scope of the problem, and fix it there.

e.g.

"X is overpowered" --> "X's weapon is overpowered." --> "X's weapon's fire rate is too high".

The weapon's statistics are considered the scope of the problem (not the character), and so that's where you apply the solution (reducing the fire rate).

The basic idea of finding Scope, and refining the problem is to prevent issues where someone says "X is overpowered", and you nerf the wrong features, affecting large amounts of content in the game.

When balancing, you want to change as little as possible.

To get the perfect solution, you need to seek the core of the problem.

Real Project Application

This post came from my work on Pokemon Universe - in which we are trying to balance Pokemon to be viable in higher levels of play.

To balance each Pokemon, there are a huge number of variables we could change:

• The traits of the Pokemon's types.
• The Pokemon's types.
• The Pokemon's stat spread shape.
• The Pokemon's individual stats (HP, Defense, Attack, Special Attack, Special Defence, Speed)
• The Pokemon's ability.
• The Pokemon's move pool.
• The Pokemon's optimal move sets.
  

And there are an amazing amount of changes that can be applied to each variable - and so, we need to decide on what needs to be fixed.
We must also determine the scope of each variable, as we want to change as little as possible.

The highest scope variable in this situation are the traits of a Pokemon's types.
if you were to change the Water type to have fewer resistances, you would affect all Pokemon of the water type.
After that you have the Pokemon itself, as an individual entity. As we are trying to fix individual Pokemon, this is the ideal scope to work in, but there are lower scopes for a Pokemon's individual problems. We need to delve deeper.

Now, Internal Scopes (those that will only affect the particular unit) are prioritised according to how much they will affect that unit - in terms of identity.
It is strongly believed that when you create individual units in a game, they should be more than just rehashes and clones of other units. They should have their own strategies and moves - so players feel like they are experiencing a new character, and so this character may fill a niche in the player's playing style.
For the most part in game balancing, you want to preserve identity. If you were to aim to change the identity of a unit, the change would be called a remake.

The greatest variables that determine a Pokemon's identity are its type combination (evaluates the Pokemon's type matchups, and the over all themes of the Pokemon), its over all stat spread (define the unique traits of the class and its role), and its optimal move sets (which determine what the Pokemon can do, and its role).

I would consider all of these equal in priority - and you generally want to preserve them all as much as possible.

That said, if you go through the lower scope variables, and you find that the problem is not in the Pokemon's stats or move pool - you do need to look at (and possibly change) its higher scope traits.

An example of such a problem is in Pokemon is where certain 'Walls' (for RPG players, tanks) hav exceptionally bad type match-ups, such as being weak to water and ground, being some of the most used and effective types in the game (hey there Rock Pokemon). A pokemon with this type combination has no viability as a Wall as it will fall very easily to any well rounded team.
For some types, stats can make up for these problems - but for others (such as the above example), the type combination must be changed (or the Pokemon needs to be reallocated to another role).

Identity vs. Viability?
The example above is a situation in which you have a choice to make a Pokemon useful, or keep its identity completely intact.
Personally, I prefer to increase the standard of gameplay - I will cover this argument in full when I do my Gameplay vs. Canon article later.

There will be times in which you need to make a big change to fix a big problem, and so you need to ensure you find the best scope to fix the issue. Don't immediately dismiss a fix because it alters the higher scopes, unless you already know those scopes are best left unchanged as they affect too much of the game (such as the relationship of types in Pokemon.)
That said however, sometimes big problems have big solutions, it's your job to have a balancing strategy that catches these issues earlier rather than later.

Thanks, I hope I explained the concept of Scope well enough.
Zanda.

Quick Update

Well, life has exploded.

I am at college 3 days a week, and I work a day a week, leaving me 3 me-days.

On my me-days, I work on balancing Pokemon for Pokemon Universe when my Balance Team is on IRC, I work on The Undeadables (more about that in the next paragraph!), and I write for this blog.

I have also started playtesting for a local company called Convict Interactive, but I can't give out information due to the NDA. Exciting stuff from them, anyway. Visit their site: http://cg.stephenbarnes.net/

Sooo I'm busy with all the design and game-related stuff, but I love it. I've always liked designing games more than playing them - and well, I'm not missing gaming too much.

But yes - The Undeadables is in production as a Warcraft 3 map. It just myself and my friend Alex Hewitt (who made 3D images for the Undeadables video), but we're going okay. We started development on Friday - and we've already hit a couple of snags to do with subterfuge vs. in-game communication, but Alex's knowledge of the Warcraft 3 engine is driving the project. We will likely be working on the game once a week. So, there will be some updates on how we're setting up the balance and sorting out issues in that project.

Anyway, I have 4-5 blog posts planned:

• Pacing (a theoretical post)
• Balance Concerns Across Different Genres (I promised this one a while back)
• Canon vs. Gameplay (the problems with games and their pre-existing universe)
• Setting Up Balance (in depth strategies to starting a balanced game)
• Conservative Game Balancing (how to ensure minimal effects on the entire game when balancing a particular unit)

Pacing is just one I find fun, and Setting Up Balance has a lot to do with The Undeadables - as myself and Alex are trying to find magic balance numbers from scratch.

Conservative Game Balancing and Canon vs. Gameplay are both very much to do with Pokemon Universe. In that project, myself and the other Balance Team member (Gammal) have to isolate problems in Pokemon, so only that Pokemon is affected. We are trying to be as conservative as possible, to ensure we don't cause larger problems in the game.

Canon vs. Gameplay is an issue I've found in the project, as, many members do not want the Pokemon to change at all, as it will interfere with existing canon. As a firm believer of Gameplay > Canon, I will be listing reasons pertaining to why you should try to preserve Canon, but when change is needed for the sake of balance, or in the name of fun, you shouldn't hesitate.

Balancing Pokémon

Now it's time for the second post of the night. In the morning. Sorry - I started this post but couldn't finish it due to the length. This one, like the other, is pretty tough.

I have undertaken a project in which I want to balance the Pokémon metagame as well as I can.

Note that I haven't even really started on this problem yet - I'm currently developing a tool that will greatly aid me in what I'm trying to do - but, without further crapping on...

Analyze the problem. (remember the brilliant 2 step problem solving method)

Pokemon faces 80% content redundancy.

No joke. Don't ask me how Nintendo let it get that way - but anyway, that is ridiculous. Most companies would freak over just 10% redundancy - but okay.

Now, remember to refine the problem - we can't magically make a solution that fixes "80% redundancy" without more information.

Refining The Problem

There are a multitude of balance problems in Pokemon:

• A vast majority of Pokemon do not have the stat totals to be competitive.
• Most Pokemon don't have a favourable stat spread that allows them to be competitive.
• A lot of Pokemon don't have the movepool to have viable movesets in competitive play.
• Some types are unfavourable in comparison to others.

As most of these issues are Pokemon based, it is probably best to leave types out of it for the most part - unless particularly problematic moves are found (hello, Stealth Rock).

Now, there are 2 main categories of change I can make -

1. Buff the weak Pokemon
2. Nerf the strong Pokemon

#2 is a bad idea, because the strong Pokemon have a really dynamic and fun game going on right now, ripe with strategy and counter strategy. Nerfing them and removing the viability of these strategies used would be a hit to the game.

Similarly, there is no stable metagame below the standard metagame we have now. There is the UU tier metagame, but it has been unstable with Pokemon entering and leaving it since Gen IV was released.

Similarly, there are a large amount of Pokemon in the NU tier than must be buffed to even be useful in UU. Merely weakening the stronger Pokemon will not change the majority of their viability.

So, we should buff the weaker Pokemon.

Choose a Balancing Strategy

Due to the scale of the problem (rather than looking at one unit, we're looking at around 230!), it could be a smart idea to consider options such as algorithms that will immediately scale all Pokemon stats to a certain total, while maintaining their stat spread.

This does not take into account Pokemon with amazing movepools, who are already competitively viable with their stat sets, and other Pokemon like them who may become too powerful if their movepool is too compatible with a large stat gain.

So - this will often attempt to solve problems, that aren't apparent for some pokemon.

Similarly, it will be necessary to scan over all affected Pokemon, to try and look for potential imbalances with movepools, or, problems that have simply not been solved, like Pokemon with bad movepools and pokemon with poor stat spreads (having all of your stats piled into Defence and Special Defence, with no HP for example is an awful stat spread).

Either way you'll be scanning over all Pokemon, still trying to fix imbalances on the majority of them - and a lot of them must be implemented into a game engine to find (with such large changes, testing is even more needed).

Basically, while trying to save time with a blind algorithm, you're ignoring 3/4 problems, and fixing the 1st problem, even when it isn't a problem - causing you to need to iterate over every Pokemon anyway.

So if we're going to be going over all of the Pokemon anyway, we should analyse the problems with each Pokemon and treat them accordingly.

1. A vast majority of Pokemon do not have the base stat totals to be competitive.

This problem is fairly self-explanatory, and it can be rectified by scaling up base stats to less terrible levels.

Chances are, you'd buff the lower stats to a more acceptable level to start (approx 65), and then see if the Pokemon needs to have more specialised stats (taking them to perhaps 110 or so) - leaving the rest in the 70s-80s.

A general guide to go by:

• Less than 50: Crippling. The Pokemon likely is useless because of this stat. Ridiculous other stats (255hp Blissey for example) are the only things that can make up for this.
• 50: Bad. Your Pokemon has to make up for it with other stats.
• 60-70: Passable, this is 'Okay', it will be a weakness of your Pokemon, but it won't cripple it.
• 75-85: Positively average. Most good pokemon have the majority of their less used stats around this level.
• 100: An important stat to the Pokemon. Well in the good range.
• 120: Considered a great stat.
• 130: The Pokemon is likely heavily based in this stat.
• Greater than 130: The Pokemon probably heavily gives up other stats for this stat.
• Greater than 160: The Pokemon is probably so one track stat wise, it suffers in the majority of other areas, if the Pokemon is weak, its stat spread likely needs to be looked at.

2. Most Pokemon don't have a favourable stat spread that allows them to be competitive.

Some Pokemon may have the right stat totals, but their stats may be spread out in a way that is very unfavourable. Some may be when the Pokemon has all of their stat points rather evenly distributed - 85 in every stat is great, the stat total is 510 - nothing to laugh at, but, the Pokemon can be considered plainly bad, relying on the features of their movesets to be useful.

A lot of these Pokemon would be better if they had some of their stats standing out more than others.

Another issue to do with averaging, is when a Pokemon has equal Attack and Special Attack, but only really has Physical (or Special) moves to work with. A lot of Pokemon are better of specialising in just one.

Another problem with stat spreads is... just really bad stat spreads. Let's take a look at the Pokemon Shuckle.

Hello Shuckle!

His stats of note are:

Defence: 230

Special Defence: 230

Wow! What a tan... wait... hold on...

HP: 20

What?!

This Pokemon suffers from possibly one of the most redundant, useless stat sets. So much defence, but no HP to back it up.

In fact, mathematically, if you were to change Shuckle's Defence to 165, his Special Defence to 165, and his HP to 60 (-70 stat points in total), he would have far better survival - despite the apparent stat nerf.

Let's not forget that Shuckle's Speed is 5, and his Attack/Special Attack are both 10 - and you're looking at an awful stat spread.

Your stats should properly reflect your role. A tank isn't a tank without good HP, and such.

To fix this, derived stats such as 'defence indexes' are useful, for finding more optimal arrangements of stats.

3. A lot of Pokemon don't have the movepool to have viable movesets in competitive play.

Some Pokemon have great stats - but moves that don't compliment them, or, bad moves in general.

A Pokemon should always have moves that support its role, and then a few that can be used to surprise the enemy, or create a slightly different play style. Simple.

If you're a tank, you should have moves that weaken the enemy team as they fumble to kill you, if you're a sweeper, you should have moves that allow you to hit the enemy hard. If you're a supporter, you should have moves that help your team.

If you are a tank, with low offenses (like Shuckle) and all you have are offensive moves, you are useless as you cannot perform your role.

The best way to balance movesets it to analyse other movesets of Pokemon with similar roles.

Let's say I got Shuckle's stats right, but, found he did not have a proper moveset to make him a viable tank. If I copied the features of a more effective tank's moveset into his, he would now be effective.

Solution: Single Target Analysis with Archetyping

I have picked my solution.

The best way to create balance in Pokemon, is to iterate through every single bad Pokemon, and analyse it heavily. I need to find its weaknesses, and fix them according to the balancing procedures outlined above (primarily stat analysis, and copying archetypal movesets).

While I plan to compare bad Pokemon to good Pokemon in order to find weaknesses in roles and movesets primarily - why stop there?

Archetyping is the practise of finding strong units, and latching onto them to base weaker units. You basically, make the weaker unit look statistically like the stronger 'Archetype', but also try and have it keep in tough with its own identity and nuances. The result, is, more often than not, a strong unit who performs their role properly, but still very much has their own identity.

If I make archetypes of each role (Physical/Special Sweeper, Physical/Special Wall, Staller, Support, etc.) - and compare these to the weaker Pokemon, and then again after the Pokemon has been buffed - we can get a good idea of the balance of the Pokemon.

Coupled with proper analysis, the Pokemon will be viable in no time.

Hopefully I can make a big difference to the Pokemon metagame, and increase the viability so that players can still fight with their favourite Pokes.

Wish me luck.

Skill Ceilings and Floors

Well, I have a night to update, and, people have been asking me when I plan to post - so I am posting now.

I have been at college, and occupied with other projects and commitments (hello, shuffling work shifts to not be when I am 2 hours away learning) - and so, well... hey.... I don't have to make excuses to you guys. >:[

Anyway, long story short, 2 articles tonight, this one, which is mainly definition, the other a more practical problem.

Player Controlled Units

Also, it has come to my attention that a very helpful term being used to describe a 'player controlled character or class' is a 'Player Controlled Unit' - a PCU for short. I plan to use this as I am sick of having to make the distinction. The term is also of great use because it can be used for any game I can think of, even ones where class and character don't work (such as in Space Invaders - where you don't identify with the unit (not a character), and it is not in a series of classes) - it can even be used to describe weapons. So, now you know what a Player Controlled Unit is.

On to the post.

Skill Ceilings and Floors

Skill ceilings and floors are terms given to the skill levels at which a player controlled unit is capped by the game mechanics. They are often mistakenly used to describe the effectiveness of a unit at various skill levels.

These terms are extremely... murky (in a word). They are poorly defined, and, are often used incorrectly - leading to somewhat of a double meaning.

I will try to clearly rectify this, but, I may fumble with my words a little and edit the post several times to make the point clearer.

On to the definitions!

Skill Ceilings

Skill Ceiling - This is the term for the maximum amount of skill that can be applied to a player controlled unit with regards to its technical limitations.

Similarly, you can say that it is the point at which an additional application of skill will yield no additional effectiveness due to the limitations imposed on the unit through the game mechanics.

If you play at the skill ceiling of a unit (you apply the maximum effective skill to it), the effectiveness reached is considered the absolute potential of the unit.

This is where I draw the distinction between the two 'definitions' of a Skill Ceiling.

If you play at the Skill Ceiling (skill cap) you reach the unit's absolute potential.

This does not saying anything about the effectiveness of the unit, aside from that its absolute potential has been reached. Even if the unit has a high skill ceiling, and you reach its absolute potential, it may still be ineffective - this is a problem, as the player is not being rewarded for his skill.

I repeat, reaching the unit's absolute potential does not actually definitely say anything about how effective it is in practice. This is where the definition problems arise.

An example of a high Skill Ceiling is in shooting games, where an accurate weapon compliments player skill greatly - and players are expected to become more accurate when aiming, and aim faster to reach the high skill ceiling. This is an impossible skill ceiling to reach however, as the rate at which a player can react to an enemy threat is limited to the slow human reaction time, when compared to a computer's reaction time - seen when a player uses an aimbot. In this situation, a skill ceiling is actually limited more by the human than the game mechanics put in place.

If you were to lower the accuracy of a weapon or give it a large damage falloff over range, you would lower the skill ceiling of a weapon, as now regardless of player skill, they cannot properly attack at longer ranges (which in the majority of games takes skill), and aim is less significant due to the lower accuracy (aim takes skill).

So how does this relate to game balance?

The main message here is that it doesn't define the unit's power. It affects balance of the unit on the skill vs. power issue (I will talk about this issue at another time), but saying that a unit has a high skill ceiling does not make it a powerful unit. You could have a weapon that takes massive amounts of skill to aim, but it can still shoot bullets that deal 1 damage.

It should be noted however, that when you discuss the overall balance of a unit, you will usually be discussing its absolute potential, rather than its potential at lower skill levels (you want to eliminate skill from the equation, which applying a skill ceiling does) - and so, Skill Ceilings also apply in this scenario.

Also, It is often ideal to try and balance all unit's potential at each skill level.

Skill Floors

Skill Floor - The skill floor is actually the opposite of the skill ceiling, it does not concern the application of a large amount of skill, but rather, a lower amount of skill. Due to the floorlessness of a realistic low skill setting (the lowest skill level is not inputting commands, but that's useless), Skill Floors are often directly tied to effectiveness when being discussed (they are useless to us otherwise).

Again, I will make the distinction between effectiveness and the meaning of a skill floor.

A Skill Floor is the application of the amount of skill yielded from the lowest amount of experience with the unit, game, or genre of game in question.

The reason why I mentioned experience was to eliminate the issues surrounding the floorlessness of low skill settings. Basically, we're talking about new players to the unit, game and genre.

Now, I will just get this out. There is no such thing as a high or low skill floor.

While the Skill Ceiling quantifies "How much skill can be applied", a Skill Floor is the opposite. "How much skill can't be applied" doesn't make any sense, nor does any other opposite trying to measure a valuable. You can graph a skill ceiling, you can't graph a skill floor (it's effectively 0 with our current definition).

So why would we bother talking about skill floors? We talk about a unit's effectiveness at its skill floor.

If a unit is highly effective at its skill floor, it is considered to be imbalanced with reference to skill (this is that thing that's coming later).

A unit that is considered ineffective at the skill floor is... well... normal. Nothing more needs to be said.

So remember:

There is no such thing as a high or low skill floor.

When discussing a unit's skill floor, you must mention its effectiveness at this skill floor.

Skill Curves

Using these measurements, we can make a Skill Curve (not to be confused with a Learning Curve or a Skill Aquisition Curve (used in RPGs to map when units get spells and such))

A Skill Curve is as such:

The vertical axis is Effectiveness (what we are measuring).

The horizontal axis is Skill Applied (what we are given).

The 'Skill Ceiling' is a constant value of applied skill, found at the maximum of the horizontal axis.

The 'Skill Floor' is a constant value of applied skill found at the minimum (0) of the horizontal axis.

In most situations, 0,0 is not a point on this curve, as even unskilled players are often at least a *little* effective with a difficult unit. If they weren't, there would likely be very little development in skill before a player gives up.

So we have:

Adding a typical Skill curve, we have

Note the X, that is what's known as:

Peak Skill - Peak skill is a common point found on Skill Curves that denotes a point at which the player will reach a point where any increase in skill results in a negligible gain in effectiveness. It's not a peak really, as the effectiveness doesn't turn downwards after this point (that would be dumb) - but that's just the term for it.

The Peak Skill doesn't really mean much when it comes to design and balance - though, as with all points on the Effectiveness vs. Skill Applied graph, it's ideal to have them all in similar places for all units in the game.

Conclusion

Anyway, that was possibly one of the toughest posts to write - due to the confusing nature of the terms, just remember:

Skill Floors and Ceilings are values in skill, not measures of effectiveness at their respective skill levels.

Thanks.

Maintenance

Hey guys, haven't posted in a while - but I started at the AIE yesterday and I've been working.

Turns out, the costs of getting to the AIE each week really cuts down on the money I'm making. Dang.

But I'll update soon, probably Thursday night.