The Many Faces of Low Morale

And it's one, two, three,

What are we fighting for?

Don't ask me, I don't give a damn,

Next stop is Vietnam.

And it's five, six, seven,

Open up the pearly gates.

Well there ain't no time to wonder why.

Whoopee! We're all gonna die.

    -Country Joe and the Fish

I want to talk a bit about morale.

As game developers, we have good days and bad days. When it's good, it's pretty exhilarating. We're lucky in that our industry is one where many of us do what we love; what we believe in. Most of us approach each day energized, and ready to make something cool.

When that morale drops, however, even the passion we have for our work can be too weak to stir us. It becomes a chore to start or continue a task; to find inspiration; to be critical of our own work; even to approach others. In a way, much of what makes us good game developers comes and goes with our morale.

As someone who's worked continuously for the last 14 years, I've been through a few spells of low morale. And as I became more familiar with them, I started noticing certain signature behaviors in myself and others. During one particularly long bout, I decided to catalog my feelings and behaviors as I had them, with the intent of cleaning it up for presentation and review later.

That "later" has finally come, and I've put together the list below. My hope is that it does a few things:

1. Help managers recognize the tangible benefits of high morale by contrasting against what is lost to low morale.
2. Help employees to understand how low morale can cause a negative feedback loop, worsening the problem.
3. Help both managers and employees alike to recognize the symptoms when they suffer from them.

Low morale has a way of creeping in, so sometimes we're under its influence before we realize it. And in many cases, our natural tendencies are to bunker down and make it worse. Recognizing that it's a problem, and when it happens, are important first steps towards taking corrective actions. Because, as we will see, low morale can have some pretty devastating effects, to individuals, their teams, and projects alike.

Motivation to Work


Probably the most obvious (and expected) effect of low morale is the lack of motivation to actually do work. I would have difficulty starting new tasks, or getting out of idle slumps. The prospect of coming in to work in the morning, or back from lunch to a task, felt burdensome instead of inviting. 

The days quickly devolve into a series of attempts at avoiding work, whether it be checking email, "researching" something on the web, or even making a long, slow trip to get a cup of coffee. I found I'd actually relish the need to use the restroom at times, because it meant I could take a walk away from my desk, even for a few minutes.

Not surprisingly, this type of foot-dragging creates a downward spiral, as tasks get pushed back later and later, piling up and seeming even more insurmountable against the already low, and falling, motivation.

Reactive Posture

Another fairly obvious change in my work ethic involved my willingness to seek out work. When succumbed by low morale, it was tempting to just wait for tasks to come to me, rather than seek out what needed doing most. I just didn't have the energy nor motivation to make new work for myself. Instead, I would lay low and hope to be looked over when it came time to task someone with something.

Unfortunately, that tended to make things worse as well. Invariably, the tasks that did find their way to me were things that others didn't want to do, either. And since I was decidedly un-busy, I was ripe for nomination. Again, tasks would pile up almost as fast as my distaste.

Indecisiveness/Ambivalence

One change that was a bit more of a surprise to me was my lowered investment in decision-making. As someone normally pretty engaged in lively debates (and a confessed contrarian), I was surprised to realize I just didn't care one way or the other how things turned out.

For someone to be this far gone should be concerning. Possibly the only mechanism one has for making things better is to be involved in decisions as they are made. Furthermore, personal investment in a project or organization are only likely to get worse as one sits out important decisions.

Less Feedback

Related to indecisiveness, above, I found a significant drop in my willingness to volunteer feedback to decisions and announcements. Like above, this only serves to dissociate one from the work or environment to which those decisions and announcements pertain.

Defensive Scheduling

My time became a battleground when my morale was at its lowest. I found myself defending personal time against any intrusion. If meetings ran long into my lunchtime, or overtime was called for, I was way more likely to make a "thing" of it. 

Ironically, for all of the lack of motivation and decisiveness exhibited in all other aspects, this area seemed to be the exact opposite. I had fuel for endless battles when it came to defending my personal time, and it only grew stronger the more I was resisted.

Pigeonholing


As with defensive scheduling, above, I also felt a distinct lack of enthusiasm or energy to do things not directly related to my job description. "Not my job" sprung to mind whenever anyone approached me with something I could find an excuse not to do.

In practice, this rarely plays out as obvious as that. Most people would prefer not to be "that guy," who shirks duties and passes the buck. Whether out of politeness or self preservation, most will quietly, begrudgingly, accept the tasks. However, this attitude can be as damaging just by virtue of the stress and resentment it breeds.

Distraction

I also found it can be easy to become distracted by anxiety when one's future is uncertain. When one is worried about what comes next, their mind is not on the "now," and the work suffers. This is a slightly different facet of low morale, as it can infect even the most diligent employees. This sort of anxiety is often the result of leadership failing to communicate in ways that the employee responds to, failing to follow-through with promises, or not communicating at all.

To make matters worse, most game developers are able to call upon an extremely powerful imagination when trying to ascertain worst possible outcomes. And fear can be infectious between colleagues.

Introversion

Possibly one of the more self-destructive aspects of low morale is the tendency to withdraw into oneself. Some employees actually form stronger coworker bonds during times of low morale, finding unity in the shared suffering. 

However, many in the games industry, myself included, are introverts. And introverts often find it easy to abandon social ties when things get tough. Over a period of time, I found myself transitioning away from daily lunch and evenings out with coworkers towards lunches at my desk, and retreating home after work.

The key behavior to watch for isn't necessarily reclusiveness (which might be normal), but rather a sudden or gradual divestment in social ties.

Nothing to Lose

For all the negative side-effects of low morale, it turns out there was at least one benefit: courage. When things are bad, it can feel like there is little room left to fall. Sometimes this can manifest as a desire to champion change within the workplace. 

More often, however, this is the trigger point for employee turnover. Visions of greener grass are all it takes to start vetting other employers, or new careers altogether.

Psychological Impact of Low Morale

Many of the above symptoms are not unlike experiencing depression, and maybe that should be no surprise. For many in the game industry, passion is what defines their career, and having that relationship fail can be devastating.

What are some things we can do to improve morale? A satisfactory discussion of that topic is well beyond the scope of a concluding paragraph. I've heard it said that employee autonomy is a good place to start. Another area to examine is whether your workplace is fostering the right balance of intrinsic and extrinsic motivators, as having  purpose is an important motivator. Or maybe you just need to work on getting everyone on the same page.

Whatever the case, morale should be one of your organization's top concerns, right up there with finding top talent. Because if your current top talent is suffering any or all of the symptoms above, the aren't really top talent anymore. They're just unhappy warm bodies drawing top talent salaries until they can be inspired again.

A Note About Low Morale for Indies

Indies are by no means immune to the effects of low morale. It might sound as if many of the above are AAA organizational and leadership issues, but low morale can precipitate out of a one-man show as well. Faith in one's work, skill, or even platform of choice, can be shaken. Indecision can paralyze progress. Distractions become that much harder to combat with nobody nearby to keep you in check.

And the effects are just as damaging. Low motivation to work can halt progress. Energy for making decisions can come up short, causing a shift to busy work instead of meaningful analysis. And the tendency to withdraw socially can inhibit good customer relations and PR.

Indies have a fairly serious obligation to keep their personal health and morale in check. We may be blessed by a vast network of internet buddies pulling for us, but our remoteness from the network might mean we're "off the grid" for too long before someone notices.

Being sensitive to the symptoms of low morale can help alert us to things gone awry. We can recognize self-destructive behavior if we know what we're looking for. And armed with that knowledge, we can make incremental changes to help get ourselves back on track, or seek a friendly ear when it's too much to tackle alone.

If You Agree to Crunch, You're Part of the Problem

Recently, Ben Kuchera called to light a eulogy for LucasArts, drawing particular attention to the sacrifices made by employees in enduring crunch. In his words, crunch is a "monstrosity" not to be romanticized, and that's actually a pretty good way to put it. For not only is it a wholly destructive force unleashed on those who work in the industry, it also never seems to die, no matter how many times we try to kill it.

And as developers, it's our fault.

What is crunch?

Before I get into the hows and whys, though, let's quickly establish some definitions.

Overtime, which is a component of crunch, is defined as working more than 8 hours in a day, and more than 40 hours in a week. Some places vary in those numbers (e.g. Alberta, Canada uses 44 hours for their week), but it's roughly in that ballpark for most of the world.

Crunch is the "sustained" application of overtime. Definitions of what "sustained" means here vary, but I think all will agree "months" qualifies without hesitation. "Weeks" has a pretty good shot of qualifying as well. "Days" is probably arguable, and starts to depend on how often within a month it happens.

Crunch is, basically, leaning on overtime too heavily to solve problems. And as it turns out, there are some more concrete definitions of how much overtime is "too much."

Why do we crunch?

What is good about crunch? Why do we do it?

Ostensibly, crunch is meant to increase productivity of a given set of developers within a given time frame. Evan Robinson actually addresses this question in his Why Crunch Mode Doesn't Work: Six Lessons:

Management wants to achieve maximal output from employees — they want to produce a (good) product as cheaply as possible. They also want to avoid hiring extra resources that increase the cost of the finished goods unless absolutely necessary. On the surface of it, Crunch Mode looks like the most obvious and logical way to reconcile these two desires.

He also points out that this is often related to a looming project deadline. He then expresses that assumption as a simple, linear function:

O = R * t

Where O is the team's total output, R is the team's rate of output per hour, and t is the number of hours worked.

However, as Evan's extensive research illustrates, R is not constant over time. R actually varies over the course of a normal work day, peaking in the first 4-6 hours. In fact, R approaches and even drops below zero after enough hours, resulting in negative output for workers.

Effectively, an employee starts damaging the product they work on (bugs, quality issues) if left to work for too long continuously. (For reference, Evan cites 21 as the number of continuous hours of work one needs to reach a mental state equivalent to being legally drunk.)  Conversely, working 8-hour days was shown to produce a 16-20% productivity boost over working 9-hour days.

What's more, prolonged periods of long work days start to produce a cumulative fatigue, reducing the average daily rate R by more each subsequent day. In The Revay Report, experimenters found that 60-hour weeks boost productivity for a few days, but productivity noticeably dropped after a week, cancelling out the boost at 2 months, and continuing to worsen over time after that. (see figs. 2, 3a, 3b, page 2)

Evan goes on to point out that every single other industry has spent the past 100 years optimizing this formula, and has arrived at the 8-hour day, 40-hour week. In Evan's words:

Any way you look at it, Crunch Mode used as a long-term strategy is economically indefensible. Longer hours do not increase output except in the short term. Crunch does not make the product ship sooner — it makes the product ready later . Crunch does not make the product better — it makes the product worse.

I don't think I could put it any clearer than that, except to point out that this is only how crunch negatively impacts the product. For the other drawbacks, I certainly can't put it any better than those who already have. In short, crunch ruins lives, products, and sometimes companies, with no up-side.

How is this our fault?

So how is crunch our fault? I mean, developers are the victims, aren't they?

It's true that developers bear the brunt of the pain in crunch. And it might be comforting to imagine that someone "up the pay scale" is responsible for botching things enough to warrant crunch. It's that last phrase, though, that's the problem: "enough to warrant crunch."

How can a project ever warrant crunch? We've already shown that crunch has a purely negative impact except in the shortest of intervals. So how can we agree to do it? Whether for selfish reasons or love for our product, how can we say it's "ok" to begin working in such a way that damages the product, ourselves, and our coworkers?

Nothing warrants crunch. As we've just seen, industry has been wrestling with the pros and cons of crunch for a century now, and crunch has been shown to be ineffective. Crunch is not a rational option. And our guilt is enabling crunch to happen in the first place.

If you agree to crunch, you are incrementally making the whole industry worse for everyone, yourself included.

Take a moment to let that sink in. Everyone is worse off for your agreeing to crunch. You have to work more, and deal with mounting stress and diminishing rest. Your coworkers have to agree or appear unreasonable in the face of your compliance. The lives of those around you and your coworkers are affected. And your company is forced to absorb the drop in product quality, along with a workforce that's losing competence, morale, and loyalty by the day.

Crunch isn't helping anyone. And by agreeing to it, you're making it easier for crunch to exist.

What if your manager asks you to crunch?

In short, tell them "no." Be polite about it, of course, but don't let politeness give way to bad business.

Look at it this way. By asking you to crunch, your manager has simultaneously just done two things:

1. Indicated that they have failed to manage the project appropriately thus far.
2. Indicated that they have no clue how to continue going forward.

Now, if you like this manager, it might be a good time to pull them aside and direct them to this post, or Evan's piece, or any of the research sources Evan used. If they didn't know, fair enough. Now they do.

If they still insist on crunch after learning about its negative effects, you might want to say "I'll think about it" and speak to their manager. Again, arming yourself with polite concern, and some established research on the topic, hopefully you can impress your point on someone with more experience and reverence for historical data.

If you find yourself talking to more than 2-3 managers in this way without progress (or run out of managers), you might want to consider another option: finding a new employer. Because any company willing to impose crunch on their employees at that many levels of management has a deep-seated philosophical problem, and it may take more than common sense to fix it.

What if your manager doesn't ask you directly?

What if you're in a place where crunch is the elephant in the room? I.e. nobody explicitly asks you to crunch, but it's implied that overtime is expected? Perhaps that's just "the way it's always been," and sticking to normal working hours seems like an invitation to be fired.

Again, this is a topic to be broached with managers. Give them the benefit of the doubt. Bring it up, and see where things go. As above, if you can't make any progress after 2-3 rungs on the company ladder, that may be a sign you're in a place that's unhealthy.

What if they fire me?

What if they do?

Ask yourself that, seriously. If the company you work for sees your concern about unhealthy work-life balance as cause for termination, I think you can safely write them off as an employer you want a relationship with any longer.

You may have heard (or even been told at some creepier companies) that there are 100 others waiting to take your job if you leave, so it's no skin off the company's teeth if you go. That's not true, though.

Good companies recognize the true cost of finding and training good workers. It takes time and resources to find a good worker, and more to train them in your company's workflow. If your company doesn't recognize this, it's probably not a good company. They'd be doing you a favor by firing you.

What if I'm compensated for crunch?

In light of the aforementioned effects of crunch, this should be irrelevant. The focus should be on removing crunch entirely, not putting a band-aid on it.

If employees were compensated for crunch, we might see a change in crunch habits in the industry, but that's just conjecture. As it is, employees are rarely compensated fairly for their crunch, either in dollars or days off.

California may be the one place where this is addressed by law, promising anyone under $83k annual salary ($39.90/hr) time-and-a-half pay for any and all overtime (Labor Code Section 515.5(a)(3)). They also define several exceptions and exemptions, which mandate overtime for entry-level or in-training software fields, film and television artists, and writers. How this impacts software development in California remains to be seen, though.

However, whether you're compensated for extra work or not doesn't address the bigger issue of whether your management knows what they're doing or not.

The bottom line

The point to remember here is that a century of industrial research and work hours testing has resulted in the nominal working hours of 8 per day, and 40-44 per week. This combination produces the highest sustainable productivity possible.

In short bursts, overtime can produce a slight boost in productivity. But the boost wanes after only a few days, and actually cumulatively grows worse each day after that.

If your employer is suggesting (or fostering) an environment where overtime is sustained longer than a few days, start considering whether they're causing more harm than good. See if you can open a dialogue with managers or HR to address the problem in other ways. And be prepared to say "no."

If you like your employer, reward them accordingly. Give them diligence, timeliness, hard work, honesty, creativity, accountability, loyalty, and all the other things you're paid for. In exchange, expect them to provide a healthy working environment, tools and support, intelligent planning, and monetary compensation for your efforts.

NEO Scavenger's Humble Beginnings

I was cleaning up some old files on my laptop this weekend, and I came across some of NEO Scavenger's earliest prototypes and documentation. And let me tell you, they were pretty eye-opening. Even for me. NEO Scavenger has come a long way.

Since this blog is meant to help newcomers to the indie world, I thought maybe I'd share some of what I found. Not only is it interesting to see how an idea evolves over time, it also might encourage those who are daunted by the finished products they play.

Few games, if any, spring forth whole like Athena from Zeus. More often, they're ugly, slimy, helpless little buggers, just like you and I were when we were born :)

A Little History

In April, 2011, I left my job at BioWare to try my hand at making games of my own design. NEO Scavenger was a foggy idea I had kicking around my brain, and was actually quite a different beast back then.

In fact, NEO Scavenger even had a different name: Post Apocalyptic Oregon Trail (PAOT). Here's a look at it's original design doc (pre-dating the design doc published in June 2011):


Title
Post Apocalyptic Oregon Trail (PAOT)

Category
Survival/Strategy

What Is The One Sentence Story Line?
Exiled from MegaCity, the player must survive the wild wastes as he travels west in search of paradise.

What Is The Game About?

Salvage food, shelter, and tools from the wastes to meet daily survival needs, as you travel west to paradise beyond the mountains.

Game Overview

• Man against nature
• Plot your course west, one day at a time.
• Search for food in the wilds and wastes, to stave off hunger.
• Find shelter from the elements to stay healthy.
• Find and improvise tools to help in your journey.
• Balance the provisions you carry against the fatigue of carrying them.
• Manage inventory by arranging your belongings in pockets, compartments, and other containers like puzzle pieces.
• Find transportation to help you travel faster, at the cost of fuel and maintenance.

Differentiation Within The Category

• Focus more on survival through resourcefulness rather than gunplay
• Opposition is mainly environmental rather than soldiers, monsters, etc.
• Play style is more laid back and pensive than Resident Evil type survival games.

Franchise Strategy

• Free Flash game, licensed to game hubs
• Possible ad revenue through MochiAds
• Story establishes IP for POST (Note: POST was a working title for a post-apocalyptic setting)

Similar Titles

• Oregon Trail (I, II, Yukon, Amazon, etc.)
• Survival Kids (1, 2)
• Lost in Blue (1, 2, 3, Shipwrecked)

The game described is actually not too far off from NEO Scavenger, at least in terms of theme and gameplay. The focus on traveling west is different, as is the origin of the character (MegaCity exile). And the transportation bit is admittedly optimistic.

The "Franchise Strategy" is a completely different story, though. NEO Scavenger as a free, ad-supported game was based on the assumption that I would work on it for a few months, then launch. Little did I know that I'd be working on the same game for years (starkly against my own advice).

Also, revel in how little I knew about the survival genre. Granted, many survival titles have cropped up in the past two years. But I'm pretty sure I was missing several important titles in that market assessment.

NEO Scavenger's First Prototype

Perhaps a more telling example of my lack of understanding is NEO Scavenger's first prototype:

Press the "I" key to see the map in the prototype.

Impressive, huh? You can move colored blocks around a grid, and switch to a map view to watch our protagonist travel west from "Elis." There's some random weather variables, tracking of time, hunger, sleep, and distance, and the ability to choose between traveling or sleeping for the next 4 hours.

The next prototype added a fancy map to the background:




Not much more to do, though. I eventually added a more representative item to the inventory screen, and made each location contain two of those items. The player could take the "soup" at a given stop, and the character would automatically eat when hungry:




It even featured an end-game! Patient players would be rewarded with green text proclaiming "You Made It!"

It wasn't very fun, though.

There were some interesting systems under the hood: weather simulation; tracking hunger and sleep; and item management in a grid. But I found myself clicking the "travel" button thoughtlessly until I needed to recharge "sleep." There wasn't much to the gameplay loop. No strategy. No risk. No fun.

I started wondering whether it might be more fun to navigate a map rather than a line. What if the player had to choose where to go, and there was no guarantee food or encounters would await them in the direction they chose? What if moving around was more or less costly depending on the terrain? What if visibility was limited by terrain?

Also, I was hooked on Civ V at the time.

So I decided to try changing the game to utilize a hex map. And this is how that looked, initially:

Still not much to look at. In fact, almost all of the systems of the above prototypes were stripped away, here, and it was just turn-based movement on an hex map, with date tracking per-turn.

Visibility, though, was a big difference. Not being able to see the rest of the map, and having to choose which way to go, felt like an improvement over having a linear, prescribed path to follow.

And within a few days, I had this:

Now I was actually starting to enjoy the prototype. Exploring the map kept my interest, as I wanted to see how the world looked, and what landscapes I could reveal. Movement was more strategic, as I weighed visibility vs. movement costs.

There wasn't any tension nor risk yet, of course, but it was starting to feel like a "toy" rather than a "tech demo."

A week later, and there was day, night, and weather!

Day

Night

Rain

Still no risk vs. reward, but I was starting to get more inspired with each iteration.

It was at this point that friends were starting to ask more frequently what the point of the game was. And they were right to ask. I needed to take a step back, and come up with a plan.

I drafted a new design doc. I started prioritizing features and tasks against that design. And from that blog post onward, you can see the iterations NEO Scavenger passed through to get to where we are today.

Rainy nights with stuff to do, and things to fear!

Baby Steps

Getting back to the original point, it's important to remember that making a game is a series of baby steps. Your game might not start out very good-looking, or even fun. And as you can see from PAOT/NEO Scavenger's history above, it might even involve a false start or two.

However, determination is key. As an amateur (programmer/artist/designer), I had to keep pushing forward, despite my own shortcomings. I made a ton of mistakes, too. Some more than once.

Over time, though, the baby steps add up. The thing you're working on gets better each time you add something that's necessary, or take away something unnecessary. Your own progress becomes a thing that motivates you, rather than just hope and optimism.

And eventually, you enter the phase where you wonder when you should call your project finished. I'll let you know once I discover the secret to learning that lesson!

Sometimes, Running a Business Stinks

The past 72 hours been a pretty wild ride. And it's highlighted some of the less glamorous aspects of running an online business. I think things are starting to stabilize this afternoon, but I'm pretty exhausted from the experience.

Things Were Running Smoothly When...

Friday was a pretty normal day. Quiet, even. Most of the day was spent working on plot development for NEO Scavenger. The day didn't go without it's hitches, but as days go, it was nothing unusual. I was happy to finish the day with some plot knots to untie over the weekend, so I wrapped-up, had some dinner, and Rochelle and I went bowling with some friends.

The next morning, I was pretty excited to see a sudden spike in traffic in my logs. NEO Scavenger was mentioned in a post apocalyptic survival reddit post, and dozens of folks were popping by the site to check out the game. Cool!

Site Maintenance

Except, my ISP was doing scheduled maintenance early Saturday morning. It wasn't until I tried loading bluebottlegames.com that I realized it was down.

5-day Site Visitor Graph: Hourly

Well crap. That stinks. Just as a bunch of new folks are drawn to check out my game, the site goes dark. And worse, dark for close to 12 hours.

"Oh well, " I said. It's a bummer, but nobody's fault, really. I mean, I guess I could blame myself for not having a redundant server or something, but I'm not that high tech (or deep-pocketed). I decided to just live with it. Besides, friendly Reddit server take-downs were nothing new. Folks probably would just figure my little server was flooded temporarily.

Site Flakiness

Later that day, bluebottlegames.com was back up and running. I did my usual email and forum check, to verify nobody was reporting any issues. And all seemed clear.

Except for one thing: every other page load seemed to turn up blank. No error message, no content, nothing. Just a blank white screen. Refreshing the page seemed to fix it, so I figured it was a temporal thing. "It'll sort itself out."

No, it won't. The following day, I was replying to a customer having issues with NEO Scavenger on their Mac, and it was still happening. Happening everywhere. Sometimes it was a content page on the site. Other times it was a forum. Even some of the site admin pages were failing. And as before, usually a reload would fix it. But the reloading was becoming less and less reliable. Sometimes, I had to reload the page 4-5 times to see anything. And if my customers were seeing the same thing, then that was unacceptable.


The White Screen of Death

I decided to dig into the issue a bit more. I started searching for related issues on the web, and was initially happy to see others reporting the same issue. Blank screens in Drupal (the content management system I use, v6.28) were pretty common. Maybe finding a solution will be easy?

However, upon further investigation, I was less happy to discover I had the same problem. This problem, as it was known to the Drupal community, was the "White Screen of Death."

The WSOD is a common issue with Drupal, but it doesn't have a common solution. In fact, there are almost as many causes of the WSOD as there are Drupal installations, and finding the right one for you can be a real quest.

The link above is probably the biggest authority on the issue, and even there, there are no less than 28 different causes listed in the article, and some 80+ comments detailing other issues customers have had. Basically, Drupal's WSOD is a symptom of practically every Drupal disease. I'm having trouble thinking of a human analogue. Headache? Fever? Common cold?

I spent hours on Sunday trying to make rhyme or reason of it. None of the remedies I saw seemed to help. I couldn't even get error or log messages. And worse, it was an intermittent problem, so I couldn't even reliably cause it to happen.

The only things I could verify about it were:

1. I only get the WSOD on my live server. Migrating the db from live to my localhost didn't duplicate the WSOD issues.
2. I only started getting the WSOD since my ISP's scheduled maintenance, when the server was (apparently) upgraded/restarted.
3. I only get a WSOD in Chrome.
4. Additionally, Chrome seemed to exhibit stylesheet issues when the page did load. Textareas would be too narrow to fit their <div>, or the page would nudge upward when I clicked a link (seemingly to adjust alignment with the Admin Menu module's topnav bar). Something was stalling the css until I clicked a link, upon which it would fix itself, then load a new page with stalled css (or js, or WSOD).
5. Firefox never exhibits any issues.
6. IE seems to work too, except for one page partially loading (later determined to be a known issue with YouTube embedding)
7. No errors appeared on the page, in Drupal's logs, nor server logs, even with error reporting hard-coded to be on in index.php.
8. Using Chrome's "Inspect Element" context menu option revealed that the page was entirely missing the <body> tag and contents. It was just an <html> and <head>, and the <head> seemed to be missing some elements. Also, Chrome usually complained of "Failed to load resource" on the page itself, but all css/js/images were loaded ok.
9. Using "View Source" on Chrome apparently reloaded the page, and showed the correct, full content source.
10. The WSOD appeared more frequently when js and css optimization was turned on (but still occurred when all Drupal optimization/compression/caching was disabled).
11. Flushing all caches had no effect.
12. Running update.php had no effect.
13. Manually truncating Drupal db tables had no effect.
14. Using Backup & Restore on Drupal's db had no effect.
15. Disabling all modules outside of Core and Core Optional had no effect.
16. Switching from BBG's custom theme to the Garland theme had no effect.
17. Rebuilding permissions had no effect.

By the time Sunday evening rolled around, bluebottlegames.com was stripped down to core modules, no theme, no caching, and had a rebuilt database. And it was still flaking out.

Worse, the node access modules I disabled caused the permissions table to get out-of-date, which caused all site content to disappear for all users, all the time. Basically, when the WSOD wasn't happening, all of the site's pages were empty blue shells, and the forums all had 0 posts in them.

Even worse still, to rebuild the permissions and fix the empty content, I had to run a script via Drupal. And that script failed with a WSOD whenever I attempted it.

I had totally messed up my site. The "Site Crash" label in the above image refers to the time when I took the site offline to avoid any more users seeing the empty shell of a site.

Fortunately, Firefox was able to run the permission rebuild script without any WSOD. And I was able to at least get the site showing content again.

But as my efforts continued past 10pm, I decided it wasn't going to be solved anytime soon. I started making changes necessary to return the site to the formerly flaky intermittent WSOD. It wasn't ideal, but the occasional user reload was a far cry better than no site at all. If nothing else, I wanted the forums and contact page online for users to report issues, if needed.

I posted a news item to the homepage alerting customers to the WSOD issue, and apologized for the inconvenience of the downtime. Then, I went to bed.

Come Monday, It'll Be Alright

I was back at the computer at 6:15am. And unsurprisingly, the site hadn't fixed itself. I fired up the usual websites, checked messages, looked for forum posts. Some users reported seeing similar WSOD issues. And, bless them, they blamed their internet connection instead of me.

I decided to try a different approach this time. Instead of grasping at straws offered by forums on the net, I decided to debug Drupal. I added print statements to Drupal's index.php, to see if I could trace the value of the content. And when that failed to reveal anything, I started adding traces to Drupal's core code (*.inc files).

I don't like doing this sort of thing, as I'm nervous about screwing things up worse than they are. Plus, doing it in a way that doesn't affect the live site's users is tricky. But in retrospect, it's the only way to really know what's going on.

I found a function in bootstrap.inc which loads various Drupal bits in phases: drupal_bootstrap($phase). Every page on a Drupal site calls this function first, doing a full bootstrap (all phases). I added a trace inside the while loop that executes for each phase as it loads, and I printed the ID of the phase.Testing on my local site, I could see that my site loads phases 0-8.

When I uploaded the modified bootstrap.inc file to the live server, I saw traces for all phases. Reload. All phases again. Repeat this another dozen times, on different pages where I most often encountered the WSOD. Everything loads normally.

Was the WSOD gone?

Tentatively, I backed out the bootstrap.inc changes, so it was back to normal. Still, the site seemed to be loading ok. I reenabled caching to normal. Still ok. Turned on page compression. Still ok. I stopped short of turning on optimized js and css. Maybe I'll muster the courage for that tomorrow.

A Wizard Did It

So what happened? Uploading that file seemed to stop the WSOD, and leave it fixed even after that file is restored. What dark magic is this?

That's actually my first theory: dark magic. But if you pin me down for a more mundane answer, I'm going to guess it was some sort of behind-the-scenes cache. I'm not sure what else would explain a site's complete performance alteration when a single file is uploaded and then un-uploaded again.

That was at about 11am today. As of 5pm, I haven't seen a WSOD. Mercifully, no players have posted in the White Screen tech support thread on my forums, either. I'm hopeful this issue is resolved.

But What About That Mac User?

Oh yeah, remember me mentioning way up there that this whole investigation started when trying to help a Mac user with NEO Scavenger? Yeah, Mac compatibility is an issue in it's own right, concurrent with the site debacle.

I'm not going to detail that issue here, as it's a pretty lengthy topic of it's own. The forum thread linked above has all the details. And what's more, I've partially touched on it in the past.

The short version is this: Flash is rapidly becoming as much a burden as a boon. For someone trying to develop a stand-alone application, I'm at the point where I am highly reluctant to recommend Flash as a viable option. Issues include:

1. "Create projector" no longer supported on Linux, as of v11.2.
2. Flash CS6 no longer supported on OSX 10.8.
3. Any projectors one does create are going to trip security on modern OSes. And in Mac's case, Gatekeeper is a sticky issue for OSX 10.7.3 and 10.7.4.
4. Digitally signing Flash projectors appears to have spotty support, unless one uses 3rd party wrappers (which are, in themselves, reportedly unreliable).
5. Adobe's recommended solution, building AIR apps, is unsupported on Linux. Also, AIR's installation process is flawed, at best. Also, AIR has the periodic "Update AIR" nagging dialog.
6. Flash is no longer officially supported on Android nor iOS.

I was a long adherent to Flash. It served me well. NEO Scavenger wouldn't be if it weren't for Flash's ease of use, and then-universal deployment options.

So it's unfortunate that this era appears to be in it's winter.

All's Well That Ends Well

The good news? At least we're back to normal. The site seems to be running again. Upgrading OSX to 10.7.5 seems to fix Flash projector Gatekeeper woes until I can find another way to certify projectors. I think I may actually be able to return to plot development tomorrow.

Let's just hope that stretch of actual game dev continues for a while!

Cross-Play

Recently, I was contacted by a couple of digital games vendors (ShinyLoot and Amazon Digital Games) about the possibility of selling NEO Scavenger on their services.

First of all, that's great news! It's encouraging to have folks asking to host NEO Scavenger. And those services each represent good-but-different opportunities to serve a greater market. I look forward to exploring those, and other, options further as NEO Scavenger approaches completion.

The point of this post, however, is more about the big picture, and how to properly balance NEO Scavenger's sale across multiple vendors. Specifically, I want to muse on the topic of "cross play."

What Is Cross-Play?

When I say "cross-play," what I'm referring to is the ability to buy a game from one service, and to have that unlock access on other services. I realize there are a few definitions of "cross-play" out there, but for the purposes of this post, it's about buying the game once, and playing anywhere.

In the case of NEO Scavenger, buying beta access at bluebottlegames.com automatically grants access on Desura. Similarly, buying a copy of the game on Desura allows the user to unlock a copy at bluebottlegames.com, using the Desura Connect feature.

When NEO Scavenger was sold in the Be Mine 5 bundle, Desura keys were given out, so those customers were also eligible for cross-play. Though in retrospect, that was less than fully effective: many customers didn't realize they had Desura keys, and weren't aware how to update, or even that they could. I should probably see about doing keys-only, rather than binaries plus keys, in the future to reduce confusion.

Why Provide Cross-Play?

One of the biggest reasons to provide cross-play is simply because it makes the customer happy. Customers feel like they're part of something bigger, and dealing with a business that values them more than their dollar. It let's them know that no matter which store they bought your product in, they're your customer, and you appreciate them just the same. And customers who feel appreciated are more likely to return for future business.

It also helps keep the audience fragmentation to a minimum. If communities were to develop at each storefront, then those communities may diverge over time, making it difficult to satisfy all tastes as they become incompatible. Smoothing out inroads between communities helps everyone stay on the same page, and helps keep the audience united.

There are also marketing advantages to providing cross-play. Customers who are pleased with the arrangement are more likely to recommend it to friends. And the relative rarity of cross-play may mean the press finds it a newsworthy business practice.

It can also accelerate sales, in the case of a gradual product roll-out (as is the case with NEO Scavenger). Knowing that one's preferred service will be supported in the future sometimes causes hesitation in customers, as they'd prefer to wait until the game comes out there. However, if purchasing the game now entitles them to a free unlock on their service of choice later, then there's no reason to wait. This was particularly the case with Steam users, as noted by the comments in NEO Scavenger's Greenlight page.

Lastly, there's a neat technical benefit to having cross-play enabled for one's game: redundancy. If something fails on one service, there's a way to get affected customers up and running again on a different cross-play service.

A recent example of this was when a new build was launched on Friday to both bluebottlegames.com and Desura. The new version went live immediately on bluebottlegames.com, but the Desura version was awaiting authorization over the weekend. Customers who wanted access right away simply used the connect feature to get the latest version at bluebottlegames.com instead.

Why Not?

One of the first reasons most will think of against providing cross-play is that there's a potential hit to sales. This is probably true. Anecdotal evidence abounds for customers buying and re-buying the same game across different services as they become available. Some are accidental (e.g. losing a CD or key), others are intentional (e.g. wanting the game in their Steam library for convenience). In some cases, they're even points of pride for the customer ("I love this game so much I bought it five times!").

In the first two cases, the customer is repurchasing the game for their own benefit. In the third case, it's primarily benefiting the developer. With cross-play, the customer can still repurchase the game if they want to, so the third situation is unchanged.

The important thing to remember about the first two cases is that customers who don't want to repurchase the game no longer have to. It might cost the developer the price of a new (or discounted) copy, but it gains the developer some good will. And I'd rather have an existing customer's good will than their additional $10 or less.

There is the possibility of customers giving cross-play keys to friends, so I suppose that's a consideration. I'm not really one to police pirates, though. And I figure that if they're going to pirate the game, cross-play doesn't greatly change their ability over the DRM-free version I sell now.


Technical feasibility may be a bigger reason. So far, cross-play between Desura and bluebottlegames.com has been pretty easy to implement. Desura has a workflow already setup for this, and adding a custom one to my site was entirely up to me. I want to do the same with Steam, though I may only be able to provide one-way unlocks (e.g. bluebottlegames.com customers get Steam keys, but not the other way around) depending on whether Steam has any mechanisms in place for cross-play.

Furthermore, each new case creates an increasing amount of integration work, and it would likely grow out of hand pretty quickly. There are a lot of services out there. E.g. ShinyLoot, Amazon, Good Old Games, Impulse, Origin, Google, iTunes, Ubuntu Software Center, etc. They all likely have different capabilities.

As such, it may be the case that my cross-play plans are impossible across 100% of vendors, even if I had the manpower.

Selective Cross-Play

In all likelihood, 100% reciprocal cross-play will not be possible as I offer NEO Scavenger in more places. So I'll need to come up with an acceptable compromise. The alternative would be to ignore sales channels that didn't offer cross-play tools.

I already suspect Steam is a one-way street in this regard, and cutting out Steam from sales channels would be pretty dumb. In fact, I think most online storefronts lack Desura's "connect" feature, so I may be living in a fantasy land right now.

One thing I can still do, however, is enable cross-play from bluebottlegames.com some other services. I.e. if they purchase at my site, they can get free keys to Steam, Desura, and maybe another service to two. More than likely, Steam and Desura are all most players care about anyway.

Plus, offering the one-way cross-play radiating out from bluebottlegames.com makes it somewhat more attractive to buy it there. The customer could still get a version on the service they want, plus elsewhere in the network. And more of the purchase money goes into developing new games. That seems like a nice win-win.

I'll have to see how this plays out, though. So far, I've been pretty lucky in that my only other vendor, Desura, makes this cross-play easy to do. So I've been treating it as my preferred business practice. But as I start working with new vendors, I'm see that the cross-play option is going to be complex to support.

Hopefully, I can find a way that is both sustainable and appreciated by my customers!

Marketing: From Passive to Active

To-date, NEO Scavenger's had a pretty low-key marketing strategy. As a title that's still under development, there haven't been many points where I felt comfortable actually driving folks to the game. I always figured that I should wait until I can put on the best show possible before I pump a lot of resources into marketing. As such, NEO Scavenger's been in a "passive" marketing mode.

Passive Marketing

Passive marketing mode is "word of mouth" marketing. I.e. the "soft sell." Rather than going out and seizing eyeballs and ears, I'm building something worth experiencing, and letting satisfied customers do the talking for me.

I'll gladly talk about NEO Scavenger to anyone who asks. I give interviews, give review copies to journalists when requested, and actively participate in fan discussions when I can. But I've only initiated a few marketing initiatives of my own, outside of bluebottlegames.com.

I've read in more than a few places that this is a terrible strategy for indie developers. The "build it and they will come" strategy, while comfortable for introverts like me, is not known for being very effective. And I think there's validity to that argument. Unless it's the right set of circumstances, or something that has an element of virality, word of mouth is a pretty unreliable method of marketing.

However, the soft sell has its place in a marketing strategy. For one thing, it's a good time to test the waters, and see how your product is received on a small scale before going big. You'll have time to see how the product behaves in the wild, see how people perceive it, assess feedback, and improve the product. Maybe people are excited about different elements than you expected, or your big selling point is still broken?

Plus, some target audiences are more receptive to a softer sales pitch (or no pitch at all). As a member of the audience my game targets, I can say with some authority that I appreciate a product that doesn't excessively toot its own horn. I like finding a product that is honest in its advertising, and sets appropriate expectations, rather than resorting to fanfare and hyperbole.

The operative clause above, though, is "before going big." Word of mouth shouldn't be one's only marketing tool. Instead, use it where appropriate, and plan on mixing it with some active strategies when the time is right.

Active Marketing

Active marketing is pretty familiar to most of us, by definition. From ads to interviews, "Let's Plays" to AMAs, it's the messaging with which we get bombarded every waking hour. "You can't buy it if you don't know it exists," as they say, and active marketing is trying to remove that very obstacle.

I think NEO Scavenger is starting to near a point where active marketing makes more sense. One of the biggest obstacles to enjoying NEO Scavenger has been legibility of its substantial text, and ugly aliasing when trying to play above the native 800x600 resolution. With fixes for those issues imminent, I think it's time for me to start warming up the marketing engine.

Building a Strategy

Even though NEO Scavenger's been "on the QT" so far, I've actually been building a strategy behind the scenes since day one. Whenever an opportunity for active marketing popped up, I may have passed it up, but I still made a note to myself for later. For example, IGF 2011 would've been pretty premature for NEO Scavenger, since the game was not even playable at that time. However, I made a note to look it up later, when it made more sense. All of these notes are in a text file that I've creatively named "PR.txt."

Since I'm starting to review this process, I figured I'd share some of my notes with any other readers who may be formulating marketing strategies of their own. In no particular order, here are some ideas to consider:

• Press Kit - This is actually pretty useful even during passive marketing. Basically, it's a handy collection of anything a journalist would need to feature your game in their publication. Usually, it includes several screenshots, gameplay videos, company and game logos in some print-ready format (or high enough resolution for print), and any other relevant materials you can offer (such as company info, team member bios, etc.).
• Rami Ismail has actually put together a DIY press kit that many indies have used with success.
• Website - This should be done as soon as possible, way back in the passive marketing phase, if possible. Having a website is pretty much a requirement these days. You could get by without one, but if you're serious about building a brand and a community, you should consider how folks are going to find more of your work after they discover you. This is a whole topic unto itself, and I've already discussed website and business planning a bit.
• Game Journals - Contacting your preferred game magazine is probably the bread and butter of a game marketing strategy. Gamers each have their journal of choice, so it's a good idea to figure out which ones your audience reads, and see if any journalists there might be interested in doing a piece on you or your game.
• While a comprehensive listing of game journals and how to contact them is beyond this article's scope, there are some really great resources out there on this topic.
• Sales Channels - Whether you think of them as such or not, sales channels are a form of marketing. Players will discover games as they shop for games, so having your game in their store of choice increases the chance your game will be discovered. And while big names like Steam, Desura, and GoG may come to mind, don't overlook more niche locations. Often the smaller or newer channels mean the competition is lighter, giving your product a greater chance of being noticed.
• GamersGate
• Google
• iTunes
• Impulse
• Ubuntu Software Centre
• Amazon
• etc.
• Festivals - Indie games are fortunate in that they are often celebrated in festivals expressly designed to highlight their unique styles. While not every festival is a good fit for every game, many can be a great way to raise awareness for your title. Plus, many offer prizes to winners!
• Pixel Prospector has already compiled a handy list here.
• Kickstarter - Kickstarter is a fund-raising tool, first and foremost. However, that almost always has the side-effect of raising awareness of the product along with the funds (in fact, even if the funding fails). While I don't think Kickstarter is right for NEO Scavenger right now, it might be something you're considering. And if so, it makes sense to use it in synergy with your other marketing efforts.
• Greenlight - Rumors of Greenlight's demise may or may not be greatly exaggerated. However, for the time being, it still represents an opportunity to raise awareness for one's game. NEO Scavenger garnered some considerable publicity as a result of Greenlight participation. However, the hints at Greenlight going away, coupled with the $100 entry fee, may mean it's best saved for games which already have some marketing working for them, or are expected to go viral somehow. Based on stats I see for the top 100 games, it appears it's still possible to skyrocket into the top slots with good marketing, but the long, steady climb may not pan-out anytime soon.
• Bundles - As I discovered last October, bundles can have a pretty significant effect on publicity. Bundles combine the traditional deep discount motivator with cross-promotion between games to produce a strong synergy of sales. There are probably more owners of NEO Scavenger from that one 5-day bundle sale than there are from NEO Scavenger's entire year of sales.
  
  The down-side, however, is that these customers have usually paid a small fraction of the asking price for the game. In my case, some 16k customers bought the bundle, but my share of the revenue was only $5400 (before income taxes). So the average sale price for each of those copies was only about $0.30-0.40. That, and some fraction of the game owners weren't interested in NEO Scavenger, but rather bought the bundle for other games.
  
  Still, that's a significant number of people who have the game, whereas before they didn't. Getting the game in front of a player is often the hardest part!
• IndieKings.com has a comprehensive list of game bundles.
• Promotions - While bundles combine deep discounts with cross-selling, the discount can be a formidable source of publicity on its own. Steam's holiday sales are nothing short of a media event these days, as are the GoG sales. Putting your game on sale for a limited time can spur renewed interest, as can interesting pricing schemes.
• Piracy - I include piracy as a subheading here because it can be a form of discount promotion. Sean Hogan has creatively leveraged piracy to this end, offering his game freely in exchange for the increased publicity and Greenlight exposure.
• Demos - Having a demo is a powerful way to increase awareness of your game. Demos let players see if they really enjoy the game. And a good demo may be so engaging that the customer is enticed to buy the game, to access more of the same experience.
• Portals - There are several websites which specialize in hosting game-related files and demos. Like with digital storefronts, having a presence on such a site provides a boost to awareness. Often times, these same demos will be picked up by other sites as well, further increasing your game's spread. This is particularly the case in the Flash demo scene. Just make sure that your demo includes some way for the player to find you should they decide your game is worth their time and money.
• Let's Plays - Quite a few folks like to record playthroughs of games, and publish them with commentary on the web. Sometimes, these are simply fans who want to share, or show various strategies. Other times, these can be widely-known video producers with huge followings.
  
  Whether you plan for this or not, it's going to come up. So it's best to decide how you'd like to handle Let's Plays and other videos of your game early. It wasn't long before I was asked for permission, and in some cases, you may be asked to sign paperwork authorizing them to publish videos of your game, depending on the video service.
• Once again, I have to defer to Pixel Prospector here, as they maintain an excellent list of YouTubers.
• Videos - Let's Plays aren't the only video format that can be useful for promoting your game. Creating videos with gameplay footage, teasers, or backstory can provide yet another a way for customers to explore the world you're creating. Some folks prefer watching a video over playing a demo or reading, so this opens up the game to that demographic. Plus, if the video is hosted on a socially-enabled website, viewers can easily share your video with others, or post it in reviews and other articles. Some places to consider publishing your game videos:
• YouTube - Probably the easiest to do, by far. Offers monetization via ads, though I would tend to stay away from any advertising to avoid branding confusion.
• Vimeo - Another popular video service with emphasis on creativity and quality, though it's had some run-ins with indies in the past.
• Any place your game is sold online (e.g. your website, Desura, Steam)
• Ask Me Anything - AMAs are pretty much what they sound like. You'll find quite a few game devs conducting these on Reddit, or similar. In practice, I find I'm doing a little bit of this every day, in various locations around the net. However, setting one up personally can lend an air of authenticity to the discussion, and help centralize and focus it, which might help it grow to larger proportions.
• Forums - Discussions tend to pop up all over the net, and I'll often swing by to read comments as they develop. I have my own forums, of course, and they provide the greatest volume and detail of all. However, it doesn't hurt to keep an eye out for discussions elsewhere, as they can often provide useful feedback of their own.
• Social Tools - It's also worth considering which social channels you plan to use. Every person has their preferred suite of social tools, and every one you support caters to that type of person. A word of caution, though: don't bite off more than you can chew. A stale or abandoned social channel can cause as much harm as good.
• Twitter - Very popular with indie developers. Provides easy sharing, direct access to fans, and all in bite-sized chunks.
• Facebook - A lot of indies have setup Facebook pages or sites for their companies and games. Provides a means for fans and developers to communicate directly. Can also be a cheap alternative to a website for burgeoning indies. However, be careful about making Facebook (or any third party service) the official site for your game. If things ever turn sour with the service, they've got your community as a hostage.
• Subreddit - Reddit can be a powerful tool for promoting content, if that content proves popular. A number of developers have setup specific subreddits, and often post updates to their projects, or other promotions.
• Conventions - Having a presence at a game convention can mean a couple of things. One option is to rent a booth, and show your game on the expo floor along with other developers. Alternatively, you could try to get a speaking gig, and use it as an opportunity to garner more focused attention. Game conventions each have a different flavor and style, so there's no guarantee a convention will be the right fit for your game. However, if you can find a way to make your game work with the format of the con', it can be useful for meeting fans and other devs alike. And if your presentation or personality are memorable, it can really stick with visitors long after the show is over.

There are others, for sure. Just about anything can be used as a tool for raising awareness, with the application of an appropriate amount of creativity and elbow grease. In particular, see if there are certain strengths you can leverage which set you apart from the crowd. Uniqueness usually more than compensates for volume, and is cheaper!

A Note About Messaging

Before closing, it's worth pointing out the importance of messaging. Take some time to get a real handle on what it is about your game that makes you special. Why would customers care about your game? What types of customers would most like your game?

As Tadhg Kelly puts it, You Need a Marketing Story.

The better you can tailor your messaging to the intended audience, the more effective it will be. Similarly, the more you can narrow your focus, the higher the chance is of getting through. Trying to reach "everyone" puts you in direct competition with AAA marketing. In that arena, money wins more often than merit. And believe me, they can outspend you.

So stay light. Stay nimble. Use guerilla tactics. And most importantly, be interesting. We're game designers and developers, after all. If anyone is equipped to design an engaging experience, it's gotta be us.

Gameplay Verbs and Ratios

This past holiday season, I decided to pick up a few games on the cheap. Courtesy of the Steam and GOG holiday sales, I picked up a handful of excellent games, two of which are Morrowind and Planetside 2.

That last one wasn't strictly on sale, since it's free-to-play. However, it's the one that got me thinking a lot about gameplay verbs recently.

Gameplay Verbs

I think I was first introduced to the idea of gameplay verbs in Jesse Schell's "The Art of Game Design: A Series of Lenses." The idea's been around since long before that book, of course, but that book formalized it quite a bit for me.

In short, a gameplay verb is one of any available actions the player can take in a game. Schell uses checkers as an example, citing its three available verbs: move checker forward, jump an opponent's checker, and move checker backward (kings only).

Schell goes on to describe what he calls "resultant actions" (as opposed to the "operative actions" listed above). These resultant actions include such things as protecting another checker by moving a checker behind it, or sacrificing a checker to trick one's opponent. They are perhaps more akin to strategies, or verbs with intent.

Verbs themselves can be entertaining, such as driving a sports car in a racing game. However, most of the staying power for games comes from the strategies; the emergent gameplay. Emergent gameplay includes such activities as trying to beat other drivers to a destination, or trying to jump the furthest off of a cliff. In essence, using simple gameplay verbs in meaningful and creative ways.

Verbs and Planetside 2

As mentioned above, I recently started thinking about this topic while playing Planetside 2. For those unfamiliar to the game, Planetside 2 (Ps2) is a massively multiplayer online first person shooter. In a given match, players on each of three teams are trying to gain control of the whole map via armed combat and capturing control points. It shares some similarities with games like the Battlefield series and it's conquest mode.

Players in Ps2 have a wide range of verbs available to them right from the start. They have the usual walking/running movements, jumping, primary and secondary weapons. And all have a special tool associated with their role. A sniper has a cloaking device, an engineer has a repair tool, etc.

Furthermore, as one plays the game and accumulates points, they can spend those points on upgrades for their character. These upgrades can include new tools, enhancements like higher ammo capacity and faster running speed, and even metagame enhancements, like shorter waiting times for vehicle respawns.

It didn't take me long to discover that I favored playing the light assault trooper role. They start out fairly out-gunned, having only a short range carbine and pistol, and out-armored, having the least armor of any class. However, they're faster than any other class, and have one thing which, in my mind, is a game-changer: jet packs.

In a game where all other soldiers are earthbound, I cannot emphasize enough how exciting it is to be able to use the third dimension as a tool against one's opponents. It opens up avenues of approach, evasive maneuvers, hiding places, and generally lets one go where no one else can.

High Resultant Action Ratios

In Schell's terms, this is a verb with a high ratio of resultant actions to objective actions. It's one action (limited vertical movement) that opens up a raft of new strategies.

However, it wasn't jet packs that got me thinking about verbs (although it did prolong my interest in the game considerably). I started thinking about verbs when it came time to upgrade my character.

Faced with a seemingly endless array of upgrades, my first inclination was to simply reinforce the thing that attracted me to the class: upgrade the jet pack to fly further. I was encountering some obstacles that I still couldn't surmount with my pack, so I figured I could bump it up a notch or two.

As upgrades progressed, though, I quickly reached a point where the pack was "good enough." Additional upgrades just didn't seem very worthwhile, nor exciting. Beyond clearing major obstacles, the pack upgrades were a case of diminishing returns.

Instead, what I found was that I started gravitating to upgrades that let me do new things. One of my first upgrades was the C4 explosive charge. Suddenly, my plucky gnat of a soldier packed some punch, and made me a threat to armored opponents. To my arsenal of disruptive strategies, I could now add dropping onto vehicles from above, and planting charges. Or, I could set the charges in a choke point, and detonate them as a trap. I could even set them someplace far away from my objective, and use them as a diversion. C4 was a high ratio upgrade.

What I didn't opt for, however, were upgrades with low ratios.

Low Resultant Action Ratios

Quite a few of the upgrades in Ps2 are little more than incremental changes to existing verbs. These upgrades include more armor, faster shield recharging, or extended ammo supply. Compared with what I experienced after unlocking C4, these seemed downright boring. Sure, they allow one to last longer in a toe-to-toe fight, or generally out on the field, but that's not really offering me a new strategy. It's more like a higher chance at success with existing strategies.

As I write this, it occurs to me that this may be one of the reasons I lost interest in Dungeon Siege II so quickly. It had many of the elements I enjoy in an RPG: fantastic worlds to explore, character creation and customization, party-based combat, and room for strategy.

However, after playing for a while, it became apparent that I wasn't getting any new verbs to play with. Most of my progression was incremental in nature, offering me progressively better chances to hit, damage rolls, and resistances. Rarely was anything introduced which made new strategies and techniques available.

In fact, I reached a similar point when playing Ps2. After unlocking most of the high ratio upgrades for my soldier, my interest started to wane. The idea of grinding for hours to get more armor just didn't have any appeal.

High Verb Count, Low Ratio

Let's take a moment to consider another arrangement: games with a large number of verbs, but introducing chance to determine success. A good example of such a game is Morrowind.

When one starts a game of Morrowind, one quickly learns to accept failure at nearly every task. Swinging a sword at a mudcrab? Miss. Casting a heal spell? Spell failed. Picking a lock? Lockpick broke. Jumping? Not over that tree stump.

Usually, several hours of gameplay are required to achieve a level of basic competence in most verbs. Instead of unlocking new verbs over time, Morrowind gives you nearly all the verbs at the start, but lets you unlock incrementally larger chances of success, and larger effects, when performing said verbs.

However, I think what we start out with in Morrowind are actually false verbs. They purport to do something, but when enacted, have little or no effect. Unskilled jumping doesn't really give me any new strategies, for example, it just has a cosmetic effect until it's leveled-up sufficiently. And the starting fireball spell doesn't really belong under the destruction school as much as illusion. It serves to get a creature's attention, but little more.

In other words, even though Morrowind starts players with a large number of objective actions, the resultant action ratio is still pretty low, in practice.

That said, the potential for a high ratio is there. Indeed, the promise of real power is one of the reasons many are willing to endure the slow start in Morrowind. Having a high acrobatics skill can be as liberating as the jet pack was in Ps2. And the upper range of destructive power in magic is nothing short of god-like. In Morrowind, a fully-formed verb is a sight to behold. For kicks, try opening Morrowind's debug console, and typing player->setacrobatics 250. Have fun :)

Improving Verbs and Ratios in Games

So what can we glean from this discussion to make our games better?

Adding more verbs seems obvious. However, as we can see in the Morrowind case, verbs alone are not always satisfying.

Most of the games we enjoy tend to have a high ratio of resultant actions to objective actions. In Super Mario Bros., the player's jump not only clears obstacles, but is a means of defeating enemies, getting power-ups out of boxes, and reaching secret areas. In Thief, the moss arrow can place a blanket of growth on the ground to mask your steps, but it can also push a button silently from a distance, or even temporarily choke NPCs for a quick getaway.

So designing games where each tool has multiple use-cases is probably more effective than simply adding more single-case verbs.

Having the high ratio verbs isn't enough, though. The player will also need occasion to use them. I feel like NEO Scavenger's biggest shortcoming right now is that the story affords too few chances to use the character's skills and items, along with the player's creativity. Ideally, there would be more opportunities for players to meaningfully use whichever skills they chose and items they found.

Introducing high ratio verbs gradually is also a useful technique in game design. The Zelda series, for example, is renowned for its gradual bestowing of new tools. The controlled rate of discovery means that new players can focus on broadening their mastery and creativity of one tool at a time, and also gives players something to look forward to.

Note that gradual doesn't necessarily mean incremental. In the case of Zelda, we get a reliable boomerang, and not a boomerang that only has a chance of stunning enemies, or retrieving objects. In Thief, the water arrow puts out fire reliably, not 25% of the time.

Morrowind's "training skills via their use" is certainly a realistic approach, and the outcome may also be realistic (i.e. unskilled alchemists might botch the potion recipe). However, long, arduous training probably isn't the element of fantasy we most want to experience. On the contrary, good storytellers usually know when to skip the long, boring parts to arrive at the scene of interesting action or dialogue: the part where the character is creative when faced with an obstacle; bold in the face of danger; or rational in the presence of escalating tempers. We want to vault over the chasm heroically, stare down the bodyguard, or negotiate the ceasefire.

And in situations where we must have a chance at failure, content creators can try to make those failures more interesting. This is definitely possible in cases where a skill check is done in dialogue, or a similar branching encounter. To do so, the designer ensures that failure cases present new opportunities for creative problem solving, or at least tell interesting stories. It's hard work for the author, to be sure, but as they say, "nothing worth doing is easy."

Ultimately, game designers are creating systems, not just stories. Stories may be told within our games, but they are not the linear stories one finds in other media. In games, players have agency, which is to say that they have verbs they can apply to objects in the game. And by virtue of their agency, they may not do what the designer intended.

Rather than curtail players' actions to keep them on a prescribed path, we should endeavor to validate and reward any path they may choose.