We’ve released a lot of games on several different portals so we’re quite experienced with the Greater Internet Bastard Theory and how it is prevalent amongst what seems like a significant portion of the Flash game playing community. Last month we launched a single-level teaser of the upcoming Battalion games, and I must say, even though I usually can brush off this type of thing, many of the responses to the teaser level really left a bad taste in my mouth.

We wanted to put out Battalion: Skirmish for a few different reasons:

1. We wanted to raise awareness of the fact that there were additional Battalion games in the works, that they were coming soon, and that there would be a level editor and competitive multiplayer.
2. We wanted to recruit additional beta testers for Arena, the multiplayer version of the game.
3. We wanted to pimp the iPhone release of our puzzle game, Robo Riot.
4. We wanted to get feedback about all the changes we made since the first Battalion, Nemesis, including all the new graphics.
5. We recoded significant portions of the game (including a total rewrite of the AI, the UI and many of the rendering systems), so we wanted to get this code battle tested.

We released the game early on a Friday evening. By the time I went to bed, the game was hovering around almost a thousand plays and had a very respectable rating of almost 4.2 on Kongregate.

When I woke up on Saturday morning, the number of plays had jumped to almost 20,000, and the score had dropped to almost 3.6. Although that is only a 12% drop, it represents, for me, the difference between a Great Game and a Decent Game. I was really surprised. Battalion is a GOOD game, how could it be at 3.6?

After my initial panic, I realized that my biggest mistake was in failing to manage expectations. In the description on Kongregate I clearly stated that this was just a teaser level, and what our goals with this release were. When I read over all the comments, it was clear that the length of the game was failing to meet the player’s expectations and so they felt compelled to punish me for it. They hadn’t read the game description. My first reaction was to ignore people who were going to be that stupid. Then after I settled down a little, I understood that I couldn’t expect people to read the game description when even I didn’t read them most of the time.

So, I put out a new build that made it very obvious that the game was just a teaser level and that it was a sneak peek (actually, I said sneak peak which I left up on purpose), and updated the description:

Some people missed in the description that the purpose of this game is to get some community feedback on the new features, and also to give people a sneak peak at the game itself. I updated the title screen to show this more clearly. I don’t know if its too late to change anything, but such is life. I apologize to anyone who was expecting anything more than just a mission showing off a couple new units and the new graphics.

I think it is pretty obvious from this little excerpt that I was not at all happy how this little teaser level experience had turned out. In fact, I remember thinking how unfortunate it was because I would NEVER attempt another teaser level again because the feedback from the community was almost entirely useless, and, if I took it literally, would give me very bad feedback about future games even if they were awesome.

Time has passed and wounds have healed. I knew then that I had failed to manage people’s expectations and I know this is even more true now. After I made the changes to the title screen, the score started creeping up and it has settled at 3.74. I really wish I could see statistics about how many 1/5s there are because I think it would be very telling.

The game has hit almost 1.2M plays after three weeks, which for a teaser level is sort of amazing for me. Despite the bad rating on Kongregate, I feel like it has achieved all of its primary goals. We got tons of valuable feedback and bug reports for very obscure edge case bugs. The iPhone port of Robo Riot got as much exposure as I could have hoped for. I don’t think I’m ready to give up on the idea of small teaser games or previews, but I do know that I’m going to approach them a lot more carefully in the future.

This puts me in a fairly unique position to comment upon the production cycle at what I dare-say is a fairly typical development house. I have a degree of experience with generalized project management and have been a life-long gamer and for the past few years a game-writer, so I understand the basic structure of gaming. Getting in up to my elbows in the swamp that is production, though, has been an illuminating process, and something I’ll likely be writing about with some degree of regularity here.

Now: the topic at hand. Urbansquall released recently Battalion: Skirmish, a one-level preview for its upcoming releases in the Battalion franchise (multiplayer, single-player and cooperative games are due to be released in frighteningly rapid succession over the course of the summer). I had joined on as a producer at the final stages of Skirmish’s lifespan, and was asked to assist in its general release to some of the major Flash game portals that Urbansquall releases at (Kongregate, Newgrounds, etc.). And here’s what I learned.

1) Verify the .swf you will be Uploading

I would sincerely hope that this comes across as a massive no-brainer for everyone out there, but it bears mentioning. This is especially true if you are releasing with any degree of exclusivity to any particular portal. If that’s the case, it’s likely that you are releasing an .swf that has full-functionality with your main portal, and limited functionality with all others. It’s pretty crucial that you verify that the .swf will behave properly in each location. So, pretty please, take the extra time, check your file.

2) Pay Attention to the Small Things – Short vs. Long Description, Instructions

Do not underestimate the power of these small items. If you’re releasing a game on a major portal, you’re talking about hitting into the hundreds of thousands of gamers—a pretty hefty demographic spread. This horde of gamers is also choosing between a mob of games to play. How do they choose which to play and which to avoid? Presentation. And this is presentation before they have even loaded your game, so pay attention to the little things.

Most portals have two sets of description you can post, a short and a long. The short will display on their main page, the long once the game-page has been loaded. Some tips for creating these descriptions.

Your short description needs to be carefully crafted. Chances are you have no more than two fairly short or one complex sentence to get across the sense of what your game is. Don’t waste your time spouting how great and revolutionary your game is. Do give the gamer a sense of what they have to look forward to. What action can the gamer expect from your title? What experience will they be having? Distill that concept down to a single sentence. That’s your short description. If your game is part of a series, find a way to work that in, especially if the earlier games were popular. People will zero in on that keyword immediately.

The long description is where you want to get into the various features that will give your game legs. Think of anything that might be unique selling points, anything that will allow the player to customize or extend their gameplay past a single run-through.

Instructions: just because you have them in-game doesn’t mean you should half-ass writing them out by hand. Maybe in-game you were limited by screen-space or functionality. Take the time to write out some solid instructions for posting alongside your game description. It’s a useful exercise, too, because perhaps it will highlight something to you that you had overlooked previously. And when it comes to Instructions, step 4 below is crucial.

3) Choose the right Thumb

Thumbnail selection is probably the single most important step here. We’re very visual these days, and Flash portal main pages are rife with images. If your screenshot does not stand out in some way, you are lost in a sea of colors. Just as your short description should encapsulate the feel of the game experience, so should your thumbnail. I’m a fan of including notable in-game art. The player character, a cool enemy, a critical power-up. Something that will give the player a sense of what the game will actually look like. Thumbs of the splash screen are doable, but less exciting. That art likely doesn’t reference what the game will actually look like. It’s either boring or disingenuous, and those are both bad. Bottom of the rung in my opinion is a thumbnail showing the game’s title. I know what the title is. It’s right next to the thumb. Now I just see the title twice.

4) Have Someone Else Review All of your Release Materials

I cannot stress this enough. Even if you are a one-man development team, you need to have someone else review your materials. In fact, it’s better if someone who is not part of production review these materials. You’re too close to it. The concept is to have all of these items grab someone unfamiliar with the game and pull them in. Who best to review than someone who is actually unfamiliar with the game.

Do your thumbs look clear? Or are they too jumbled? Does the description give them a good sense of anything? Is the longer description readable? Do the instructions make sense?

Never underestimate your ability to gloss over mistakes. The brain is adept at this. It autocorrects, so be sure you have a failsafe.

Robo Riot on the iPhone

Robots are tired of doing the bidding of their human masters and they’ve figured it’s finally time to overthrow them. Robo Riot is an iPhone port of our recent Flash game of the same name. As it turns out, the game is very naturally suited to the iPhone platform and, dare I say, is even more fun in a mobile setting. Give it a whirl and let us know what you think!

Battalion: Skirmish

Take command of the mighty Warmachine and lead your troops to victory in the latest chapter of the Battalion saga! We wanted to celebrate the release of Robo Riot on the iPhone, and show off some of the tasty new graphics and features in the upcoming Battalion game. This is just a single-level teaser, but it should be enough to give you a pretty cool idea of some of the fun stuff you’ll be seeing in the rest of the series.

In the past, I’ve discussed the importance of using version control and also ways for structuring your subversion repository. Today, I’d like to cover an important best practices with version control whether you are a lone wolf developer or you frequently travel in a pack.

After you’ve wrapped your head around version control (and I’ll be honest, it baffled me the first time I was forced to use it), there’s only a couple more best practices you need to be aware of to get the most out it.

Don’t Commit Conflict Bait

Conflict Bait is basically something that’s going to generate conflicts pretty much any time a team member updates from the repository. A good example of Conflict Bait is the swf file that your project generates when you build, or intermediate build files that your IDE might generate. Don’t put these in the repository, because you will publicly mocked by your more senior team members when they are forced to remove them.

Exceptions: This one isn’t such a big deal if you’re the only person working on a particular project. When you are rocking it solo, it can sometimes be useful (read: lazy) to let version control track your builds so can look up old versions without checking out a fresh copy of the whole repository.

Write Comments In Your Commit Message

This one is a bit of a “Duh, really?” When you’re going back over a log of 1,000 commits, you’re going to be sorry you didn’t leave the breadcrumbs to help you track down that bug in that feature you haven’t tested in over 3 months.

Only Commit Verified Builds

Don’t commit code that breaks trunk. If you do, you will be shot and beaten. Resist the urge to commit that untested feature right before you sign off for the day. This is the absolutely WRONG thing to do. Perhaps your fellow coders were planning a code binge that night and your last minute tweak sends them on a 4 hour bug hunt instead. Don’t do this to your teammates.

Exceptions: This again is more applicable in a team environment.

Close Your Open Files Before Updating

Sure, Flash Develop or Flex Builder will usually warn you when a file has been externally updated and ask you if you want to reload. Usually. In my life, I’ve wasted at least 2 day’s work undoing the damage caused by accidental overwrites after the IDE failed to recognize an update changed a file. Close your open files, then update. Don’t be that guy, really.

Make Your Commit As Small As Possible

You might think you’re awesome by making monolithic commits, but you’re really just overcompensating. The best commits are ones that are as granular as possible. This is a good practice for numerous reasons, and one that helps support many of the other best practices already mentioned.

1. It keeps your project manager informed of your progress. If you’re making commits every 5 days, it doesn’t matter how big they are, you still look like you are not pulling your weight when your project manager gets his daily commit log and your name isn’t on it.
2. Your commit becomes easy to refer to because of its unique revision ID. It becomes an entity that can be referred to, entered into bug databases, etc.
3. When you’re digging through logs that have one succinct change applied to a single file, it is far more useful than a commit log that is 9 pages long and involved 30 files, which may or may not be related to your current search.
4. Your commit becomes easy to undo. Let’s say you really screwed things up and totally broke a feature (and then went to bed for the night). Your team members can see quickly from your commit log that revision 324 was a granular commit related to that feature and is likely the source of the issue. They can roll back the change and move forward while just cursing you briefly.

I’ve been using version control in a team environment for about a decade now. Hopefully this helps you benefit from some of that experience.

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.

1. Sirlin’s talk on competitive multiplayer was one of my top three favorite talks at this year’s GDC. You can get all the juicy details from his very helpful handout
2. The post mortem for Tale of Tale’s Graveyard.
3. Fairly sobering reflection on 2008 from Introversion (Uplink, Defcon, Darwinia, etc.).
4. Destructoid’s “Everything You Wanted To Know About Going Indie”.
5. The Four Hour Game Design from this year’s IGS. Genius.

That’s it for this week.

One case where you might be tempted to copy/paste code is when you’re performing some logic on a group of related objects. In the following example, we test the neighbors of our tile to see if we are surrounded by sea. This technique can be applied effectively to many other scenarios, however, like initializing a set of buttons, or aligning a bunch of logos.

var isSurroundedBySea : Boolean = false;

var leftTile : Tile = map.getTile( m_currentX - 1, m_currentY );
if( leftTile != null && !leftTile.isSea() )
{
    isSurroundedBySea = false;
}

var rightTile : Tile = map.getTile( m_currentX + 1, m_currentY );
if( rightTile != null && !rightTile.isSea() )
{
    isSurroundedBySea = false;
}

var upTile : Tile = map.getTile( m_currentX, m_currentY - 1 );
if( upTile != null && !upTile.isSea() )
{
    isSurroundedBySea = false;
}

var downTile : Tile = map.getTile( m_currentX, m_currentY + 1 );
if( downTile != null && !downTile.isSea() )
{
    isSurroundedBySea = false;
}

Copy/pasting has bloated the size of the code and made it incredibly brittle. If we need to modify the basic logic of the query (like perhaps testing for a modifier called “Sea” instead), we have to hope we remember to do it in all 4 places, and to do it correctly.

Never fear, though, Mr. For-Loop is here to save us. What I like to do in this particular case is plug all the objects into an array and then use a for-loop to make sure the code is written only once:

var isSurroundedBySea : Boolean = false;

var neighbors : Array = [
    map.getTile( m_currentX - 1, m_currentY ),
    map.getTile( m_currentX + 1, m_currentY ),
    map.getTile( m_currentX, m_currentY + 1),
    map.getTile( m_currentX, m_currentY - 1 ) ];

for( var n : int = 0; n < neighbors.length; n++ )
{
    var neighbor : Tile = neighbors[ n ];
    if( neighbor != null && !neighbor.isSea() )
    {
        isSurroundedBySea = false;
        break;
    }
 }

Not only is it faster to write this code than it is to copy/paste all that junk up there, the code is significantly more robust because we’ve converted 4 potential sources of failure into (basically) one.

You have to be able to write bug free for-loops to use this trick effectively. But I’m pretty sure you can handle that.

I took copious notes at the Flash Gaming Summit that was held the Sunday before the GDC began. I thought that I might transcribe my favorite parts of the sessions and post them up on gamepoetry so that everyone could benefit from all the great information that was being shared. Turns out the furious note taking was pretty much completely unnecessary because Mochi Media ended up pretty much posting the whole thing for the world to view.

I had the opportunity to go through my notes this week and reflect on some of the things that were said and discussed. As I reviewed my notes, I noticed four nuggets of wisdom that were worth highlighting, even though the sessions were all available anyway. These are paraphrased based on my very short-handed notes:

1. Stephen Harris (Ninja Kiwi) – You need fresh eyes on your game constantly. Familiarity tends to amplify the perceived success or failure of a design.
2. Daniel James (Three Rings) – With all their knowledge and experience, Three Rings still make design mistakes. They’ve learned to use playtesting to guide their instincts.
3. Paul Preece (Casual Collective) – In competitive multiplayer, microtransaction models make you hate your rich friends. In cooperative multiplayer, microtransaction models make you love your rich friends.
4. Chris Hughes (Flash Game License) – It is okay to let the portals handle the monetization of your flash game, but make sure you’re participating in the benefits if your game is a runaway success.