Showering is an important part of everyone’s daily routine, even if it is one that programmers avoid too often. At Urbansquall, the daily showering ritual has taken on a whole different meaning. It is during this time that many of our most difficult problems are solved, or our most creative ideas born. Let’s delve a little deeper into “Shower Moments” and the critical role they play in effective game development.

Shower Moments Defined

A Shower Moment is an epiphany, a moment of focused clarity that changes your perspective on a particular design choice or implementation challenge. A Shower Moment doesn’t have to necessarily occur in a shower. It can happen while you’re on the toilet. Or while you’re eating a cheeseburger. Or while you are out walking your dog.

The Importance of Shower Moments

At the start of this year we had an impossibly short deadline to deliver a fairly complex game for one of our favorite clients. I was not sure if we would deliver the game on time, but I did my best to remove any production obstacles by trying to design the entire game up front before a single line of code was written. This worked as hoped for the most part, at least until a few days before the game was supposed to be ready to ship.

The controls were designed in a vacuum, and, in practice, they were far too complex. Everyone was too busy hammering to get the game done in time to notice, until I had one of these “Shower Moments” when my subconscious basically slapped me in the face and said “The game sucks and it is because of the controls!” Fortunately, we had just enough time left in the schedule to redo the control scheme. This didn’t instantly make the game great, but it saved it from being a total catastrophe. I became peripherally aware that shorter game development schedules were risky not only because there was less time to polish, but also because of something else. I just couldn’t put my finger on it.

The Shower Moment of Shower Moments

I only became acutely aware of the concept of the “Shower Moment” this year while attending a panel at the GDC. A developer from Capcom was complaining how difficult it was dropping from a traditional 2+ year development cycle to a 6+ month development cycle for console downloadable titles. The thing he lamented the most was not that it required smaller teams, or smaller scopes, but simply that there is a lot less idle time during a 6 month project than there is in a 2 year project. And no, the implication was not that 2 year development cycles have more downtime during production (they might), but rather that there was just less time with the project in general.

This is something I alluded to in my article about Maximizing Efficiency By Taking Breaks, so I was peripherally aware of the importance of this idle “production” time but I just didn’t fully grasp it until that panel.

Why Shower Moments Are Important

It’s possible to do a lot of proactive design and problem solving before production, but it is so rare that a game ends up being made exactly as it was penciled on paper. Throughout the course of a game’s development there are hundreds, if not thousands of little unplanned decisions that ultimately combine to create the final package. It’s fairly tempting to brute force all these decisions as they come up and often we have to do this. Many times these gut shot decisions are correct and life carries on, but frequently we’ll make a mistake, or base a decision on a false belief.

Shower Moments are vital to a game’s development because they help fix the problems that can’t simply be fixed with a hammer and a nail. Shower Moments are there to give you that solution that is out of the box, to fix the problem that is so pervasive you may not even notice it.

Why Shower Moments Work

I’m sure there are a lot of reasons why Shower Moments work. I believe it has a lot to do with our subconscious’s propensity to solve problems differently from our conscious. It could just be that sensory deprivation (specifically in the case of a shower where everything is white and the sound of water drowns everything out), activates a different problem solving part of our brain. I believe we have all experienced these moments, even if we didn’t recognize what they were, so I believe it is just self evident.

Employing Shower Moments for Success

The biggest problem with Shower Moments is they can’t really be forced, and they are often the most important when you are least likely to have the ability to rely on them. My goal now is to give each important project enough time to have all the Shower Moments it needs in order to achieve its full potential.

It is a luxury, one that is not always afforded, but with the knowledge that this critical element of game development exists, I can at least start each project hoping to give it enough breathing room to let these important insights bubble to the surface.

This week’s article, Little Games in Unlikely Places, appears as a guest post on the excellent MochiLand blog.

I’m excited about next week’s article. It’s a Q&A with Greg, the Community and Developer Relations Manager for Kongregate. He’s the guy you talk to when you want to get your game sponsored by Kongregate and he’s got a lot of interesting things to share with us.

Super Stacker is a fun little game. It’s nothing revolutionary but it has a lot of fun little touches that make it an enjoyable coffee break game. One thing in particular, however, blew my mind today, and that is the developer’s solution for creating an ever-present mute button, but without needing to dedicate UI to the cause.

In Make The Smart Choices So That Your User Doesn’t Have To, I discussed a trumping rule to preferences in the Flash domain. As the comments on that article later showed, I’m not alone in hating the need for those ever present mute/sound buttons. As it turns out, there is an elegant solution that, with wide-adoption, could easily become the preferred paradigm for giving our players the ability to toggle music and sound effects.

The solution is simple. Use the right-click menu to give the player constant, quick access to muting. Here is what you see when you right click in Super Stacker:

Simple, elegant and always available, this offers a lot of advantages over the traditional ever-present mute buttons. It does have one significant disadvantage, though, and that is the burden of education. Because it is hidden, you have to educate the user that the right-click menu provides access to the muting functionality. This is not a difficult task, but it is worth noting. If all Flash games suddenly started doing this, we might actually create a new paradigm and get rid of those pesky, ever-present mute-button eyesores. That would be awesome.

The article has some great suggestions (like stealing poses from existing sprite sheets), but I can’t help but feel the author is discounting his natural artistic talent. Either way, it’s worth tackling the full article.

1UP has a preview of That Game Company (creators of Flow)’s next PSN game, Flower. Obviously heavily inspired by the gamepoetry banner.

User Interface Design

Praise be Web 2.0! The term “Web 2.0″ is pretty loaded and that’s because it incorporates a lot of ideas. One of the core tenets of Web 2.0 is a revolution in user interfaces. The visual aesthetic of Web 2.0 is simple intelligent user interfaces that focus on ease of use over power of expression. The impact has been felt everywhere, both on and off the web. It’s not difficult to see how much of an impact “Web 2.0″ has had on modern operating system and software design either. Every new application release looks suspiciously more and more like the Web we’ve all gotten used to.

In our games this user interface design shift means that a lot of the times our game is going to resonate more with the player if the user interface stays out of his way. A loud clumsy user interface is going to constantly remind our player that they are simply playing a game. A simpler, intelligent user interface is going to go along way towards making a more enjoyable gaming experience.

Case 1: Battalion

One of the first games I released was a turn-based multiplayer Flash game. It was just meant to be a prototype, so I made dozens of mistakes along the way and never really had the experience or time to fix them while I was still actively developing the game. Among the plethora of tragic mistakes I made, one players constantly whined about was the chat box that would always get in their way. I thought I was helping players by having more real estate dedicated to the game, and then just overlaying the chat box on the game and letting the users move it around. I delegated the placement to the user, and the result is not pretty:

In most Battalion games, there are areas of the map that are not really used much by the player. I didn’t even need to dedicate space to the chat box, if I was just smart about making sure the chat stayed out of the way of the player. Eventually I got it usable enough that players stopped complaining. The reality is that I didn’t spend the time to make the right choice and the game was more frustrating than it should have been as a result.

Case 2: Matchmaking

I don’t know if you’ve had the pleasure of trying to coordinate an internet game of Counter-Strike with a friend. It starts with a huge list of possible pubic servers, each with their own custom rules, maps, pings, team sizes and all sorts of other options. If you find one you like, then hopefully you and your buddy can join before the empty slots fill up. I know that after awhile, I stopped trying to organize games of Counter-Strike over the internet, because it was easier just to lug all our computers over to a buddy’s house and set it up over a lan.

Contrast that to the party matchmaking that’s available in Bungie’s Halo 3. You fire up the game and within a few button presses, you have formed a party with your buddy and you are automatically matchmaking with other players looking for similar games. When the matchmaking service has found a suitable game for you to join, it gives you the option to veto the game map and mode. If the other players in the game agree, then a new one is picked. The matchmaking system doesn’t try to let you filter by map type or anything like that. It just asks you what type of game you’d like to play and gets you playing one with other people as soon as possible.

User Interface Trumps

I’m not sure there are any situations where a more complicated user interface is going to be better than a simpler one. Even in the most complex in-depth simulator we can think of, we still want to make sure that the user interface is as simple as possible for the player and make the smart choices so that the user isn’t forced to.

Follow Ups

Last up in the series is how we can apply this principle to API design to make libraries that are easier to use (and reuse).

Credit

I have to credit this wonderful insight to the chapter Avoid Preferences in 37 Signal’s awesome book Getting Real. The whole book is worth (several) readings, and I can’t recommend it enough.

Preferences

Some developers pride themselves on all the customization options they offer their players. They let them adjust everything from graphical quality to which key combination fires a particular action. Who is better qualified to make these decisions? You or the player? Generally speaking, you have the skills and ability to make better decisions about player preferences than they can make themselves, so instead of delegating the choice to the player, make the right decision so that they don’t have to. I’m not against exposing the ability to let the player override this default choice, but your goal as a developer is to create the game your players want to play, not the game they need to customize to enjoy.

Case 1: Controls

Look inversion in First Person Shooters is a topic as divisive as some of today’s hottest political issues. Up until very recently, a game would make a decision, either inverted or not inverted, and (hopefully), players would be forced to dig through a bunch of settings to if their personal preference did not match that of the developer.

Recently though, several FPSes, like Bungie’s Halo for example, have started using gameplay to determine your inversion preferences. During the first few seconds of play, the game asks you to look at an object in the world. Based on how you interact with the controls to achieve this objective, the game makes assumptions about your control preferences. It even gives you the opportunity to correct it if it guesses wrong. Is that better than forcing your player to spend the important first few seconds of your game digging through menus to find a look inversion setting? Immersion wins when your players aren’t reminded that they are simply playing a game.

Case 2: Playback Quality

I am as guilty of this than any other veteran Flash developer out there. In a graphically intensive Flash game it is very tempting to give the player the opportunity to play the game in low quality rendering mode in order to squeeze maximum performance out of the Flash Player. If you think about it, that is completely unforgivable. Using a timer and some basic computations, we can make some quick estimates about the hardware capabilities of player’s machine and make the right decision far more accurately than the player. How are they supposed to know if they want 3 levels of parallax instead of just 1? The reality is we’re hard pressed for time so we opt for the easy choice rather than the right choice. In a future article I will tackle a utility class that will handle this computation on our behalf so that we don’t have any excuse to do this again.

Preference Trumps

Sound Muting

Every good rule has its exceptions. An important trump to the preferences aspect of this rule, in regards to Flash games, relates specifically to sound. There are certain standards that have been established in Flash game design, and typically these are around for good reason. When it comes to muting sound and music in Flash games, we have to understand the context, which why this rule is more of a “Best Practice” than it is a real trumping exception. Flash games weren’t popularized by people who traditionally play PC and console games. Flash games were popularized by people who were supposed to be working or otherwise being productive on their computer. People want to play your Flash game without being fired. If they can’t turn off the music and sound in your game with the click of a button at any instant, chances are they’re not going to be able to enjoy your game that much, if they even play it at all.

As I discovered in a recent game release, it is not sufficient to bury this capability in an options menu. On any screen where there is music or sound playing, you must give the player the ability to quickly and effortlessly turn off any and all sounds with a single action.

Follow Ups

Next up we will be discussing how this rule applies to user interface design, and then we will wrap it up with how this rule can make your API easier to use.

I have a deep fascination with cooperative games. I’ll forgive a game for a lot of defects if it has a fun cooperative mode available. I love to play cooperative games, so naturally I spend quite a bit of time thinking about cooperative game designs and the sort of cooperative games I would like to build. This article explores one facet of cooperative game design, and that’s dealing with player death.

A Brief and Informal History of Games with Cooperative Modes

Arcade machines offered some of the first cooperative games. Many of these found their ways to the early console systems and home PCs. Double Dragon is probably the first truly cooperative PC game that I can remember playing. During the golden age of the arcades, there were a plethora of games where players cooperated to defeat the never ending stream of bad guys. Some of my favorites of this time come from games like Contra, Teenage Mutant Ninja Turtles and X-Men.

One of the most innovative games of all time also had extensive support for cooperative multiplayer. The seminal Doom let up to four people play through all the singleplayer campaigns. As multiplayer PC gaming became popular, the shift seemed to move to deathmatch and less emphasis was placed on cooperative gameplay. Many FPSes followed, but generally speaking cooperative modes only came about as a result of the efforts of unfulfilled mod communities.

Around this time, different genres started adding cooperative modes. Diablo pitted up to four players against endless swarms of dungeon beasts. Myth let two players battle through the campaign mode (I have no idea how anyone finished this game without a cooperative general dedicated to managing those suicidal dwarves). The multiplayer emphasis in FPS games seemed to refocus from deathmatch to team versus team gameplay, which has both cooperative and competitive elements, after Counter-Strike took over online gaming. Halo arrived for the X-Box with a tightly integrated 2-player cooperative experience.

Gears of War for the X-Box 360 took it to the next level by designing the cooperative elements directly into the game. Halo 3 added four player cooperative play. More recently, we have Schizoid, a game that only added singleplayer/competitive modes as an afterthought (it’s too bad they had to, because it dilutes the awesome cooperative experience), Army of Two which isn’t quite as a fun as Gears of War but brings some new cooperative juice to the table, and, as I’m sure every Flash developer is aware, Castle Crashers with its 4-player beat ‘em up cooperative gameplay.

Death in Cooperative Games

The way we treat player death in cooperative games has evolved with the games themselves. Arcade machines were designed to pull yet another coin from your pocket, so it handles player death very differently compared to a game like Crackdown, which has a massive world that spans several islands that two players can explore independently.

Here’s a list of some of the most common ways for dealing with death in cooperative games.

Individual Elimination

You start with a fixed number of lives. When you die, you lose a life. When you are out of lives, you stop playing. Anyone else who still has lives keeps going. This is the most common treatment of cooperative player death in arcade games. If you needed your buddy to help you finish a level, you had to encourage him to toss some quarters into the machine to keep going. Generally speaking, I feel like this is the weakest approach and generally applies only in the arcade environment when it makes sense as a business constraint but not a design one. If you put this into your cooperative game that’s not arcade based, realize how cruel you are being to the player who gets eliminated early and then has to sit there and watch his buddy keep playing, or, even worse, force the guy who is doing well to quit because his teammate didn’t have the stones to make it.

Shared Elimination

This is seen in some early console games, but also as recently as Schizoid and Urbansquall’s own Discarded: Online. The benefit of this approach over the fixed independent method is that it ties the fate of the team together. The strongest player is compelled to help the weakest player, because if the weakest player dies, it hurts the whole team. The flipside is that it makes it harder for players of different skills to play together because a weak player can take down the whole team, despite their best efforts. Its application is most appropriate when the game’s design makes it harder to use the other methods available. This strategy is most effectively employed when levels are shorter in nature and particularly in the style of game in which there is no inter-session saving and the team is tasked with getting as far as possible before dieing.

Automatic Respawn

This strategy usually has the player respawning after a certain amount of time passes. In team versus team gameplay, like Counter-Strike, this can be at the end of a round, or after a fixed respawn timer in Halo team multiplayer. Games that don’t necessarily require the players to stick together tend to favor this method and the reasons for doing so are good. If player Bob dies the equivalent of 1 game mile away from player Sue, and the respawn is conditional on an action by Bob, then both Bob and Sue are going to be pissed every time either of them dies. Diablo’s approach to this method is worth noting. If you died, you could respawn in town without most of your best equipment, and then return to the site of your death and try to reclaim your goodies before you got wiped out by whatever killed you in the first place. Players could also find Resurrection Scrolls to bring back teammates without them needing to trek all the way from town. It wasn’t perfect, but at least it gave you an interesting choice.

Conditional Respawn

Of the different strategies, Conditional Respawn is my favorite. Because it requires the intervention of a teammate, it encourages players to take only the necessary risks, particularly when there is a timer that will permanently kill a player if a teammate can’t save him in time. Dieing takes on a tangible cost, but it doesn’t cripple the well organized team. It introduces new interesting gameplay choices. You’ll be forced to consider if its worth reviving your teammate to get them back in the fight, or tackle your immediate objective at the risk of total failure.

In Halo cooperative, the teammate who fell in combat cannot respawn until his human allies clear the area of enemies. There is no inherent cost of abandoning your teammate, except the added risk of failure if you cannot clear the enemies before you die. In Gears of War, the conditional respawn requires an active intervention in order to save the life of a fallen teammate. The consequences of the action are heightened by making it possible for the enemy to kill a fallen team mate. The interesting choices now have very distinct consequences. Not only do you have to get to your team mate without dieing, you have to get there before he bleeds out or is killed with a finishing move by the enemy. Army of Two expands on the idea by letting the fallen comrade defend himself, so he is still actively engaged with the game. The fallen teammate still has some ability to fire, but the enemy can also shoot him while he is down thus quickening his death. Castle Crashers adds a fun mini-game element to the revival procedure. You can choose to mash the keys and revive your teammate quickly, but you restore more health if you take the time to do the mini-game correctly. The risk you assume then is that an enemy attack might interrupt you and force you to restart.

You should be striving to add interesting gameplay decisions to your games, and the Conditional Respawn attitude towards player death is a good way to encourage cooperative play while at the same time creating additional interesting choices for your players. Conditional Respawn doesn’t work especially well in games where players aren’t forced to stick together, and that is its greatest weakness. Conditional Respawn can be applied to games that have traditionally used other methods, however, and I believe we’ll quickly see it become the defacto design choice for modern cooperative games. Ideally, a smart developer will come up with a way to apply the principles of Conditional Respawn even in an environment where players can get separated by large distances.

Multiplayer games are Multiplayer!

The biggest mistake most indie developers make when they are building multiplayer games, is that they force the game to be multiplayer.

The developer thinks to himself “I can rely on the dynamic nature of PvP to keep players entertained.” The developer doesn’t bother building an AI. Tutorials aren’t necessary as everyone’s starting off on the same footing. There doesn’t need to be a lot of content as players will keep coming back to fight it out in PvP.

The reality is, if there is nothing but PvP available, your game will not be sticky. The first player who arrives at your game will see no one to play with and he will leave. If this cycle takes 10 seconds, you could get 6 new players per minute but no one will ever play your game. You have to give people a reason to stick around and play, whether that be a meta-game, bots, singleplayer missions, or whatever clever solution you come up with.

The reality is that the most important part of a multiplayer PvP is the community that plays it. If you don’t have that community before you release the game, you need to design a game that will encourage that community to form.

If the core of your game is PvP, make sure you address the reality that until your game is popular, people need something to do. Make bots. Make survival arenas. Do whatever it takes to give people a reason to stick around and play, even if there is no one to play against at this moment. With a little bit of luck, they’ll stick around long enough to actually get a PvP game going, and after a few weeks you might actually have the critical mass to start building an active community of players. Think about the first thing a new player sees when they first enter your game. An empty server is going to signal to them that the game is dead (even if it is not) and that they’re better of spending their time elsewhere because there is nothing to do here.