Unite 2010GDC ChinaAsia Game Show 2010GDC 2011
|
Achieving BalanceabilityPlay balance is often considered an "alpha or beta thing", but the truth is that like any engineering task, good preparation is key to success in implementing good play balance. A good game design has strong balanceability, which can be defined as the relative ease with which a game system can be brought to a state of balance. If the system has no balanceability, all the tweaks in the world will not bring it to a state of balance. A game is a system, and good systems engineering practices, when applied in the early design phase, lead to strong balanceability. The three core ideas that translate well from systems engineering to game balance are: game element modularity, consistency of design motivation and complexity control. When used in combination early on, they can save designers enormous amounts of time in the alpha and beta testing stages. Game Element ModularityGame element modularity boils down to an idea that each game mechanic should exist for a specific purpose, and if possible, a singular purpose. When this principle is adhered to, tweaking a mechanic only changes one aspect of the gameplay, rather than several aspects. A good example of where this caused a developer unnecessary pain was during the beta testing of Starcraft. Blizzard (the developer of Starcraft) had a fairly straightforward damage system in which each unit did one of three types of damage, explosive, normal or concussive. Each of these damage types had a different damage multiplier against various unit sizes --explosive was good against large targets, concussive was good against small targets, and normal was good against everything. One unit, the Mutalisk, ended up being a constant hassle to balance in part because there were a lot more than three different types of units (i.e. large/med/small didn't really cut it) in terms of desired functionality. Setting the Mutalisk to the "medium" unit type classification made it far too resistant to explosive weapon-type units, while making it large made it too vulnerable to the same units (which were sometimes, but not always, its theoretical counters). Blizzard couldn't just change the coefficients of explosive vs. large or explosive vs. medium though, because that could've upset a bunch of other unit matchups that were not comparable to the Mutalisk vs. explosive damage-type unit matchup. They couldn't really change the attack values of the units using explosive weapons either, since that threw off other things as well! This was further confounded by the fact that the Mutalisk had two strong roles - anti-air and anti-infantry (ground units without air attack), all with the same base damage, while other units similar to it (scout, wraith) had separate weapon systems, which could be balanced for their specific roles. Due to this a lack of modularity in the damage system and the Mutalisk, Blizzard didn't manage to balance the Mutalisk until five months after the commercial release of the game. It wasn't that a fix was impossible, but rather that the fix was difficult to ascertain because of a lack of system modularity. The Mutalisk had a somewhat unique purpose in Starcraft, and if Blizzard had isolated its balance parameters from other unrelated units, they would've had a much easier time balancing it. The easiest solution would've been to simply add a unit type to hold the Mutalisk (Along with any similar units) with its own resistance to various types of damage. Had the designers made the Mutalisks air and ground attacks different, they would've also had an easier time. Of course, for the most part, Starcraft did have a reasonable amount of modularity. One example of this, is the Spellcaster units, which tended to have a crisp definition of purpose, and relatively specialized roles. The fact that many spells, including Broodling and EMP Blast, had super-specialized roles, made balance much easier to achieve with these units. Good system modularity isn't just preventative medicine for play balance, its actually a proactive step towards a solution. A system with strong modularity will have all the knobs and levers necessary to tweak very specific problems with exactly what is needed without side effects. Consistency of Design MotivationConsistency of design motivation is perhaps the most important principle to adhere to during the initial design phase, but it is easily ignored either for political reasons, carelessness, or a lack of good communication. The assumption behind consistency of design motivation is that if a game mechanic wasn't designed in sync with the greater whole of the game, the best case is that it will merely distract users from the "core gameplay" and the worst case is that it will actually damage the core gameplay in some manner. The best examples of this situation exist in games that either have no centralized control, or which have been developed over a very long period of time. The somewhat known MUD Duris: Land of Bloodlust (which is the sister MUD to Sojourn, which Everquest was based off of) suffered from this several times. In one case, a programmer took it upon himself to implement a new character class that he wanted to play. Although the character class was fun in and of itself, it made several other classes far less useful, and was greatly overpowered. By merely existing with the ability set it had, this character class essentially broke a monopoly that several other classes possessed, and which in turn had made them useful and fun to play. This was of course, in addition to the more "mundane" play balancing problems that he introduced. His objective was at its core, to make a class he wanted to play. This conflicted with the greater MUD developer desire to create interesting, original classes that meshed well with the MUD as a whole. His class was neither unique (it had a little of this and a little of that from other classes), nor coherent with the rest of the MUD. Complexity ControlComplexity control can best be summarized as "keep it simple, stupid". Excessively complex game systems are harder to understand, and thus, harder to balance. An overcomplicated system usually is developed either because an initial design that was poor was endlessly "patched" with design fixes (leaving an incoherent mess that in theory works) or because of the all-too-ancient "too many cooks in the kitchen" phenomena, which often also corresponds to a lack of consistent design motivation. An added advantage to complexity control is that it avoids a number of potential gameplay issues. In particular, just as complex game systems are hard to understand and in turn to balance, they are also harder for players to understand, and after a certain point, to enjoy. An all too common design mistake is to favor complexity over depth, which leads to extreme play balance difficulties, and confusing and difficult to understand gameplay.
|
Balance?