Design Blog

Saturday, February 25, 2012

What makes something "skillful"?

This has been a topic on my mind for a while, but in a lot of games, especially PvP games there is a much touted idea of "skill" that gets thrown around as a measure of worth. Certainly I think that there is meaning behind this phrase, as balance changes to PvP games revolve around this idea nearly all the time.

Twitch Functionality - This is the most obvious one, but depending on the game it's not always available. This is a gameplay element that only provides a very small window to execute the correct command, usually as a reaction to something else happening on screen. While fighting games and shooting games use this type of gameplay to great effect it's not always available depending on the genre and your audience. Guild Wars 2 dropped the notion of twitch interrupts for the most part because it's not practical in an MMO with so many players at the same time (interrupts still exist but they rely much less on twitch reaction). Twitch functionality as far as I can tell is almost always a high-level skill that while available early won't be something that beginning players will use much. It's just generally not practical to require fast reflexes for beginning players.

Best Use Cases - A skill or ability that is more effective when used in a certain "optimal situation". You have to be a little careful with designing these skills though since it's easy to add optimal situations that don't add to gameplay. These types of abilities usually manifest themselves as conditionals "if you meet X condition you get Y as a bonus". The best designed skills of this type typically reward the player for using them at all, but provide a much larger reward for using them correctly. Occasionally there are abilities in games that give no benefit when used improperly, though I feel that these types of abilities tend to be much more niche and harder to apply in normal gameplay. General use should come first before playing with conditionals if you can.

Clutch Use - A skill with a relatively large disadvantage (like a very long recharge or large weakness at the start or end of activation) that is intended to be used at a certain time for a large effect. This type of skill is about reading the opponent usually and responding properly. In BlazBlue and other fighting games the super attack usually fulfills this role. It's very skillful to turn a match around with a super, and on the other hand, it's very skillful to read your opponent's super and avoid it. These are actually great tools when designed properly as they make the player feel very powerful and generally have eye candy associated with them to get observers into the game.

Team Coordination - A game element that requires coordination between more than one player is a less common form of "skill" in games. Because most games want to appeal broadly, it's hard to add these elements without restricting your gameplay to all but organized teams. Most of the time when I see elements like this in games, the functionality is ignored by most players except those at the highest level. It's okay to build a game with these types of elements though and still have it appeal to a broad audience though. Left 4 Dead requires coordination to heal allies and avoid team damage, but for the most part it's okay to have the occasional friendly fire as long as you aren't playing on the hardest difficulty. Because the rewards for good team coordination scale up with difficulty, these elements can exist without alienating beginning players.

Of all of these functionalities I think that "best use case" is probably the one I think is the most important. To some extent it's already a generalization of the other three. Twitch use is just finding the "best case" when the window is very small, and clutch use is "best case" when the window only appears infrequently. Similarly, team coordination is a function of syncronizing "best case" with the "best case" of an ally. In order to make a game element skillful, I think this is probably the first step to look for.

Now I didn't really get into other elements like hard and soft counters or tactics versus strategy, which I think are also important elements to designing something "skillful" but I think this post is long enough as is. I'll save these topics for another day.

Labels: blazblue, design philosophy, game mechanics, guild wars, left 4 dead

posted by Saikyo at 6:48 PM

Thursday, January 26, 2012

The Cool Button

I've been thinking about a recent idea of games I like to call the "cool button". I first noticed this when I talked about the "Drive" system from the BlazBlue series. The idea is for the designer to provide for the player an easy instant way to do something impactful and visually interesting. In BlazBlue this manifests as a character specific mechanic being associated with the D button. As I talked about before, this mechanic can vary in complexity and depth per character, but because it's universal it means that new players can immediately jump into any character and see something exciting.

I've noticed that other games do this to varying degrees, and it usually manifests as a unique mechanic to the game. For example, the special ability button in Borderlands or the Adrenaline Skill in Guild Wars 2 to provide a few non-fighting game examples. In both of these examples, the "cool button" provides a fun way to provide a powerful, but simple to use tool for the player. Press button, receive awesome.

When I look back on some of the arcade games I played when I was younger, I notice that even some of these old games used this mechanic as well. Bomb attacks in Aero Fighters or the Mutant Power in the X-Men Arcade game are good examples of this. These examples are slightly more limited however owning to the pay per play nature of arcade games. However, when used in arcade games I feel that the cool button is actually more effective than usual, as it allows passerbys to see the cool effect and get interested in the game. In fact it may simply be that this mechanic was developed for this reason (though I don't have any proof to back this up).

As an added note, these examples also show that the cool effect does not have to be homogenous. In fact the variation in each of these examples is part of what makes it possible for these games to have additional replay value as the players experiment with different characters.

I think that in order for this type of pattern to be the most effective it must follow some guidelines:

1. The execution must have minimal complexity. (Ideally one button!)

2. The mechanic should be introduced early

3. There should be a high visual impact

4. Variation can exist in what the cool button does.

Now, none of these rules say that the cool button needs to lack complexity. In fact in the examples cited earlier all of the cool mechanics have a lot of depth to them that can eventually be discovered. However its important as an introduction for new players to make them simple to understand. Additionally, these rules don't include placing limitations on the number of times the cool button can be used. I feel that this mechanic is more effective when it's unlimited as in the case of BlazBlue (since it allows for more early experimentation) but in other systems that use resources (such as the limited number of bombs in Aero Fighters) I feel it can still be effective.

The context of this pattern however limits the situations where it can be applied, and to what degrees it can be applied. There are some games which simply don't benefit from putting this kind of mechanic in. A game like Portal for example gets its appeal through the puzzle solving and innovation or the mechanic rather than simply having some big flashy thing that happens when you press a single button. Having a single button which shot a nuke at the turrets would simply kill a lot of the fun of the game.

-----------

Pattern: The Cool Button

Problem: Game needs quick appeal and pop for demonstration purposes.

Context: A game with a defining, compelling, and interesting mechanic that can be expressed as a single button press. This mechanic should have gameplay depth but doesn't have to.

Solution: Bind the game mechanic to a single button.

Example: Blazblue Drive System

Anti-Pattern: Binding many different mechanics to different buttons. Or binding core functionality to multiple button presses.

Labels: blazblue, game mechanics, guild wars

posted by Saikyo at 6:03 PM

Wednesday, April 28, 2010

This blog has moved

This blog is now located at http://purpleanchor.blogspot.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://purpleanchor.blogspot.com/feeds/posts/default.

posted by Saikyo at 12:57 AM

Thursday, February 25, 2010

Game Design and Cooking

I started thinking today about how I could describe game design to people in a simple way. It seems to me sometimes that the intricacies of this industry are difficult to comprehend and that results in a lot of misconceptions about how this job works and the effort and knowledge that is required to get things to go well. When I was growing up and wanted to get into the game industry I had a lot of these misconceptions about what goes into a good game. I don't think that I'm fully there yet, but I think that I have found a decent way of explaining how it works to others.

Video game design is like cooking.

It sounds a little weird at first but I think it's something that most people can relate to. First of all both of these professions involve a lot of creativity on the part of the designer/cook. Both professions can seem deceptively simple on the outside, but have deep intricacies that take time to learn. They also both rely a lot on the subjective opinions of their customers to be successful, and as a result, both of them need to have a good degree of understanding when it comes to the "tastes" of their patrons. Finally, and I want to emphasize this part, being able to consume and enjoy the product does not inherently make one an expert on it.

Knowing what tastes good is not the same as being able to cook something that tastes good. Similarly, knowing what in a game is fun, is not the same as knowing what makes a fun game.

I'm a little worried that last sentence came off as a bit arrogant, so I'll clarify that I'm not saying that game players or their opinions are unimportant. Far from it, as I think it's imperative for a game designer to take feedback from the players of his game as well as his peers in order to improve his skills. However, I think that often times the feedback that a game designer receives from players and beta testers is highly skewed and cannot be taken at face value. What I am trying to get at here, is that the feedback from players is something that needs to be tempered by the game designer's own opinions and thoughts.

To get back to the cooking analogy, let's compare a game to a full course meal. The designer does his best and tries to prepare a meal/game which is balanced in flavor, nutrition and texture. He then asks the customer what he thinks could be improved.

The customer tells him, "I really liked the chocolate cake that I had for desert! Chocolate is really delicious, I think you should make the other dishes more like the cake and put in more chocolate. That would make them taste better."

This is difficult advice for the cook to follow. In his mind he realizes that putting chocolate in the salad or the mashed potatoes is a bad idea and wouldn't really help the dishes very much. Beyond that he also knows that if he were to feed someone a full course of chocolate dishes that they would very quickly tire of the flavor and the impact of his later dishes would be lessened. The customer may have eaten the food of a lot of famous cooks from around the world and knows what he likes and what he doesn't like. He might even think that he can make something that delicious by combining a lot of the dishes that he's seen before. But this isn't what makes a good meal and the cook knows it! So how can he use this seemingly useless comment?

The first step is to examine the origins of it. Why did the customer focus on the chocolate? Is it because the other dishes had too much salt and not enough sugar? Perhaps the other dishes were too bland and the sharp taste of the chocolate cake stood out more than the others. Was the dish that the customer had before the cake particularly good for complementing the flavor of the chocolate? All of this can come from simply analyzing the question in a little more detail, and there's a lot of lines of thought that can come from it. The cook also needs to be able to ask better questions as well. Perhaps the chocolate answer wasn't useful at all, maybe he should have specified that he wanted to know what the customer thought of the texture of the food, or if he felt bloated after eating it. Being able to realize what questions to ask next time is important as well.

From there it's a matter of exercising his expertise to craft a better dish for next time.

This is where the designer/cook has to put his own thoughts into the matter. As the creator, he's in the best position to know which of these threads to follow in order to improve. Perhaps when he was tasting the soup earlier he also thought it was a little bland. Or maybe he realizes that if he cooks the chicken a little less that the retained water will cause it to be less salty. He could even discover that cooking with a different type of oil produces the flavor that was lacking. There's room for improvement even from such a narrow response, the trick is being able to find it. This mentality and capacity for analysis is something that I think a game designer absolutely has to have in order to be able to improve.

And the end result will be something that both creator and customer can enjoy.

-----

Extra Note #1: Also like cooking, sometimes ingredients that don't seem like they would go well together end up forming an unexpectedly good combination. Perhaps combining the chocolate with the chicken will get the cook the mole poblano flavor that he has been looking for. Combining disparate elements from game genres that don't necessarily go together will sometimes get you something unexpectedly delicious. (Though sometimes it gets you an inedible mess.)

Extra Note #2: There's a saying that bacon goes with any dish. I imagine there may be a game design convention that fulfills a similar role, but I haven't discovered it yet.

Labels: design philosophy, game industry

posted by Saikyo at 12:32 AM

Thursday, November 26, 2009

The Intention of Design

Happy Thanksgiving everyone. It's been a while since my last post, my new job is pretty busy, and pretty awesome. Here's something I've been writing up in the meantime:

-----

This is a topic that came up when a friend told me the story of a City of Heroes character named "Twixt" and another story about an Everquest character known as "Fansy the Famous Bard". This eventually led me to another article about how David and Goliath works in real life.

The gist of these two stories was that the player's of these characters became the most hated people on their servers... and they did it all by playing by the rules that the designers developed. It brings up some interesting questions about the goals of designers versus the goals of the players, and how even when the two goals sometimes match up, things still don't go quite right.

For reference, here are the articles

Twixt (City of Heroes)

Fansy the Famous Bard (Everquest)

How David Beats Goliath

...

...

...

Now that you've read them (you did read them right?) let's break each part down.

Twixt, the Outcast
The Twixt case involves a player (specifically a university professor) who noticed that players in a certain server of City of Heroes/Villains did not tend to PvP in the designated PvP zones. Instead the players preferred to chat with the people the game designers intended to be their enemies while fighting NPCs that happened to be in the zone as well. The professor in this case decided to go against social convention and play by the designer's rules.

He PvPed villains. And he did it really well. So well in fact that for breaking this particular social agreement between the players, that he ended up being ostracized by both camps. The whole time, by following the game rules.

Now it should be obvious that this would happen. If someone breaks a social convention that is established and followed by many people he will likely draw a lot of their ire. What makes the case of Twixt so interesting was that what he was doing was EXACTLY what the designers wanted him to do. As a result, despite many other players complaining about him, the developers never acted against him. In fact, the player behind Twixt reported several people for threatening him, and as far as he knows, they have stopped since then.

The professor in this case was studying human behavior, and certainly deviation from social convention gave him a lot to work with, however, I'm more interested in how the game design factored into all this.

While my experiences in City of Heroes are somewhat limited parts of the article and the professor's paper seem to imply that the PvP zone was simply more lucrative for players to engage in NPC combat rather than combat with other players. This is a design issue, and this is the truly important takeaway from the article in my opinion. When players do not play the game as the designer intended, and more so, actively ostracize those who do find the best way to play with your rules as in the case of Twixt, then there is a problem with the design and it needs to change. There are many ways that this could have been accomplished, but there are two overall goals that a designer can follow in this kind of situation.

They can either change rules to force the players into the correct behavior, or they can change the rules to make the players' behavior the correct one.

Now, I'm not going to say one or the other is more correct, since I think this depends on the situation. And really, in any game, players will ultimately discover more than a designer or a tester will find during the games production. What matters though is how the game and the designer react to them. Now in the case of City of Heroes, I would say that changing the rules to encourage the correct behavior would have been the best choice. The game already has many zones where players can kill NPCs and if players were continuing to do so in PvP zones, then the first thing to look at is how the rewards are assigned. The players in this case could clearly tell that it was better to attack the NPCs, so it's up to the designer to make it better for them to attack other players to preserve the intent of the zone.

Fansy, the Rebel
The case of Fansy is a similar case of following the rules of design, however this case ended differently from that of Twixt. Like Twixt, Fansy existed on a server where certain social conventions had occurred. The server that Fansy was on had a specific rule set which seems to have precluded the players to choosing the "evil" faction in this game. (The website refers to it as "no play nice rules" and that it would probably have "many unfair battles".) With only 11% of the server being on the "good" side, much of the server was taken up by these "evil" characters. Fansy was one of the exceptions, and made it his quest to defeat the bad guys.

However, because he was excessively outnumbered in this case, he took advantage of certain server rules which made him invulnerable to certain enemy skills while he low level (presumably to prevent newer players from being killed off too early). With this invulnerability to direct attacks from the other faction, and not having enough power to defeat them in a direct confrontation, he used a "monster training" strategy, to lure high level monsters into his enemies where they (and occasionally he) were killed.

What's interesting is that, while this type of behavior is not very sporting, and probably not necessarily how the designers intended the game, this was still a valid tactic, and apparently there was even a GM who told him that this tactic was perfectly legal. Even one person who was personally against him, still had to admit that the server he was on had "no rules". Another person compared Fansy's actions to other legal game techniques that are frustrating to other players, such as going into the enemy zones at low levels and preemptively defeating monsters that they use to level in order to deny them that resource.

Fansy's adventure terminated differently from that of Twixt however, as the designers changed the rule that kept Fansy invulnerable to higher level players. They removed this ability across the board for zones deemed "mid-level" and above. This was a case of the designers changing the rules of the game to fix the problem. While this does seems like a somewhat heavy-handed solution, I won't say that it was the wrong one, especially given my low familiarity with Everquest.

What's important about this story is that unlike the Twixt story, Fansy was doing something that was NOT intended by the designers (but still playing by the designer's rules). This seems to be the important distinction on why no action was ever taken against Twixt. For the designer, it's very important to remember that your intent with the game rules is not something that the player necessarily has to follow, even if he plays by your rules.

Bringing it Together, David and Goliath
The final article talks a lot about how underdogs can overcome those in power. One of the big points it makes is that David should not follow the established conventions if he hopes to beat Goliath. Goliath in these situations is much more powerful when operating under these conventions and David will most certainly lose if he follows them. This article brings up two actual games, basketball and a naval game, and shows how David can win by going against Goliath's preconceived ideas about how the game should be played. In the case of the basketball game the coach instructed his less skilled players to play full-court press the entire game, which the other teams were not used to, but is perfectly legal to do. For the naval game the winning player used strategies that no real fleet commander would ever use in a real war but within the scope of the game they were the most efficient.

Both of these players met with similar fates to Twixt and Fansy as well. The basketball team was forced to change their playstyle when a referee who didn't like their playstyle started calling four times as many fouls against them. The naval game player was asked by the organizers of the tournament not to enter again because his strategies were "not really in the spirit of the tournament". For these situations, those in power worked to coerce the players into playing their way or not playing at all. This is a somewhat more extreme example of enforcing the intent of design than the previous two examples since it involves going after the players themselves instead of the designer changing the rules. However because these examples were not video games, its possible that this approach was less feasible in the context of the problems (though I'm not entirely convinced of this).

-----

So that was three different articles, all tied together by the same thing. INTENT of design versus design RULES. These examples all show that developing robust game rules can go a long way to preventing behavior which deviates from the intent of the designer. It also puts a great burden of responsibility on the designer as it should be clear from these examples that players will always try and seek out the best way to use the designer's rules to their advantage, regardless of if this type of gameplay goes against the designer's original intent.

There's a second facet of this too, and that is for situations where you discover that your rules do not accurately convey your intent and have the chance to change them. I think that when these situations come up, it's better for the designer to try and develop better rules that accurately convey his intent rather than simply trying to develop rules to stop the player. And that even developing hard rules to stopping players is better than making players who go against your intent feel unwelcome in the game as in the case of the player in the naval game.

A game is nothing without its players, even if they don't want to follow your rules, the fact that they are playing in the first place is an indication that they find the design fun. Design needs to work with players in order to convey the intent of the designer, but it should do that through the rules, rather than through mandates to the players.

-----

That was a long one this time. There are a lot of games I need to play this holiday season and a lot more I want to talk about. Although I may be busy with my awesome job as well, I hope to find more time to talk about these issues.

Labels: design intent, design philosophy, game mechanics, PvP

posted by Saikyo at 11:05 PM

Sunday, August 16, 2009

The Problem With PvP

I've been a fan of fighting games (especially Guilty Gear) for a while and now that I'm working on Guild Wars I find that there are a lot of parallels in terms of how the players approach the games and how new players get into them. After a bit more analysis I found that the reason for this seems to be a core of understanding the nature of competitive play.

To put this idea simply, it's that "PvP, by its nature, is designed to reject potential new players."

An adendum to this is: "The rejection rate of new players will increase with the game's lifetime."

Now, by PvP in this case I'm refering to any game which has direct competition between players based on skill. Fighting games are the purest example of this, but MMOs that have battlegrounds and balanced tournaments as well as sports games. However this also extends to just about every other method of playful competition including real world sports. I think in general the idea that competative activities can be hard to get into is obvious, but games have an additional layer to them.

Here is the process as I see it:

Stage 1: The Level Playing Field

In any PvP game that is first introduced, all new players start at the same skill level. Any new player has just about any chance to win as any other player. Obviously some players will grasp the rules of the game better than others and perform better, but in general at this point there exist no high level strategy of techniques and players work with simply their normal understanding of the rule set.

In fighting games, this is the absolute beginner stage where players mash buttons in an attempt to win.

Stage 2: Complexities Emerge

After a certain amount of time in the game a portion of players start to break off as "skilled" and have mastered all of the low level ideas of the game (punching, jumping, dashing, etc), and move onto developing more complex strategies and techniques. For fighting games this takes the form of things like wakeup games, high/low mixups, and intentionally wiffed moves.

At this point players who have not grasped these aspects of the game begin to lose more often. This is the stage at which you start to see complex behaviors develop, as designers, I think this is something we need to design into our base mechanics so that the game can reach this next level.

Stage 3: The Metagame

The metagame refers to the game that exists outside of the game. Generally this refers to elements of competative play which become determined by players rather than the designers. If a certain strategy or combo is seen as effective then it will start to be duplicated. The differece between competative players and non-competative players is that competative players will actively seek out the most efficient method for winning, even if it is less fun to play and especially if it is easier to execute for its effectiveness.

This is when specialized player terms begin to develop in a game. Game specific elements such as Wave Dashing, Roll Canceling and Burst Baiting start to show up at this time as a result of player experimentation and drive for efficiency. Generally at this level the true level of balance that the designer has achieved will become apparent.

This stage is also the one at which a barrier to entry becomes apparent. While competative players who have been playing since the beginning have gotten to the point where the previous low level elements have become simple, new players now have an even higher skill and knowledge bar to attain to become competative. This is the level at which new players start to be detered, due to the difficulty of learning everything as well as the low chance of winning against players that understand the metagame well.

Stage 4: The Slippery Slope

The final stage of PvP games comes when the influx of new players trickles to a halt or at least a slow drip. At this point new players are generally turned off from attempting this game due to the high time commitment required to compete on an even level with veteran players. The conundrum is that you have designed your game to be balanced, then this is exactly what should happen. But the problem is that if new players lose 90% of their matches or more because the game is filled with veteran players then the game has sealed its own fate by locking out any new players.

Even well designed PvP style games begin to decline at this point, and to some extent that's okay. No game is meant to last forever, but for many companies who produce these games it's valuable to be able to keep selling copies as long as possible between releases.

-----

So what can be done to prevent this kind of thing? Looking at some real world examples we can see a few solutions. Real life sports such as basketball and baseball separated players into leagues of relative skill levels. Even though NBA players would easily crush junior high basketball teams there are systems set up so that they only play people at their own skill level. Similar to this games sometimes use a ranking system to make sure that new players are not matched up with players of a higher skill level. This is a great solution and works in a lot of situations for many games since it allows new players to start out the game in an environment where their chances to win are approximately 50/50, and the large barrier of time to develop skills can proceed at its own pace. Players in these kinds of systems can choose to quit whenever they feel like it if the competition becomes too difficult.

But skill discrepancies can still cause problems even in these kinds of systems. Skilled players can often have a difficult time getting their friends to join them due to the skill barrier. If you prevent skilled players from dropping down levels to play with their friends then the system itself becomes a barrier to players. Similarly the ability to measure a player's skill level becomes difficult in video games as well, since players can simply buy another account or throw matches in order to get a low rank again. If too many players engage in this behavior then the ranking system becomes irrelavent since it does not reflect the skill level of the players anymore.

At the moment, there really isn't an obvious catch-all solution for the problems, and to some extent the solutions need to be developed to the case at hand. This somewhat extends into my ideas about game design patterns, but that can wait for another day.

Labels: design philosophy, game mechanics, guild wars, guilty gear, PvP

posted by Saikyo at 6:06 PM

Saturday, August 15, 2009

My New Job

I've been pretty busy lately with my new job, but I have updated my LinkedIn profile to reflect my new job at ArenaNet. My official title is "Live Team Designer" which basically means I get to work on all the issues affecting the current state of Guild Wars. This includes everything from skill balance to bug fixing to developing new ways for players to play and refining existing ones.

I've been really excited about it since I talk about and play Guild Wars a lot. I think it's going to be a really great job for me since I basically get to do what I do normally with regard to Guild Wars, except now I can actually affect changes. (And somehow I also get paid for it.)

I was a little worried when I started about the potential burnout, since I've been playing Guild Wars for so long and now I'm exposed to it even more as part of my job. So far though it's been pretty much the opposite, I've actually been trying to play the game more often since I started to see what kinds of other changes I can make and what other parts of the game could use work.

I've got a few other posts in the works that have been stewing for a while, as well as the next part of my thoughts on healing classes. I've been super busy the last few weeks trying to get up to speed on all the internal stuff as well as moving cross-country to Washington, but I think I should be able to get another one up this week.

Labels: arenanet, guild wars, job

posted by Saikyo at 5:11 PM