Going Too Many Extra Miles

And this is exactly the problem.

Hi everyone, sorry for the lack of posts, been two years, etc. Let's just assume I won't be updating this blog regularly so all of us will just be pleasantly surprised when I do. Today's topic involves "going the extra mile", which is code for someone going above and beyond what they're asked to do. Normally, it's a good thing, but I'd like to argue today that too much of it can be detrimental to both the person doing it and the game team as a whole, using two examples from my own experience.

I was bored one Sunday while I was working on City of Heroes. I came up with a challenge for myself - could I create a piece of content for the game from start to potentially shippable in one day? I went in and worked a full 8 hour day and got the content in. I tested it myself and was proud, I had made something completely from scratch that, with maybe a little more QA testing, could easily be shipped in the next release!

A few years later, I had been at Cryptic for a while and we were crunching. I didn't have too much to do during crunch, so I decided to work on a personal project. I created a template for setting up a puzzle that we hadn't done before. It took a while to do and test, but in the end I was able to get it working. I sent an e-mail out to the other designers saying I had taken care of this, and felt comfortable thinking I had added a new dimension for puzzles to do in the game.

What were the results of these two examples?

Complete with gravely voice.

In the City of Heroes example, I created surprise work for QA and the other designers with my work. Whoever was working on rewards now had to figure out how my content fit into the release plan. What I did was never scheduled and never asked for, but now it was nearly done. There were other parts of the release that could've used a hand, other parts of the game that could've been improved, but instead I went off on my own and did a thing that I thought was cool. We still released it, but it cost several people on the team, including myself, more hours than they thought they would need to get this next release out the door.

On top of that, I started to set a dangerous precedent for the rest of design. I went in and worked on brand new content for the game on a Sunday (a Sunday! A day of rest, for shame on me as a Catholic). Was this the new bar for everyone else? Did we need to do this from now on to maintain a level of content released in each patch? Or was it going to be a thing where the studio just relied on Sean to Go The Extra Mile and have me just always work extra hours? Lucky for me, the producers at Paragon did not take advantage of this and instead encouraged me to not do this sort of thing again.

In the Cryptic example, nobody really needed or wanted my puzzle. There was a reason why the team was crunching: work needed to get done with time the normal week didn't have. Instead of going to a producer or my lead and saying, "what can I do to help? I'm pretty light on work right now," I decided to do my own thing because I wanted to show off how much I knew the engine. In that time, I could've been peer reviewing other people's content, helping someone bash their bugs, or anything else that a lead or producer could think of to help the team with the next release.

"Going the Extra Mile" in the Cryptic example would've been asking people where my help could've been used. It's always a relief when someone can take care of your bugs so you can focus on other things. It's part of being a team working towards one goal instead of a team of solo designers doing their own thing.

With our powers combined, we create new patches.

However, going the extra mile too much can also lead to bad things. What I did on City of Heroes was me showing off, not working with the rest of the team. But it could just as easily turned into something even worse. Someone willing to always go the extra mile, whether its come in on weekends, do "surprise" work at the last minute, etc., can create a dangerous precedent. Does the content scheduled to be released begin to count on said person going the extra mile? They're always doing it anyway, so why not assume they'll keep doing it and load them up on things? At this point, there's no more extra mile, you're just doing your job and working your hours, which is more than the amount of hours everyone else is working.

Consistently going the extra mile works fine in the short-term, but can be devastating in the long-term. What happens when that one person leaves the team? How do people who can't work more than 40 hours compare to someone who is always coming on on weekends or staying late at night? The goal should be how we can get better and more efficient with our 40 hour work week, not adding more hours to it.

We should celebrate when someone goes the extra mile to lend a hand. But when that same person is always working more hours to help out the team, then something needs fixing and we shouldn't be celebrating. It's a sign that something is wrong with the process if it keeps happening.  The hardest part of this is standing up and saying, "no, I don't have time for that.". Short-term, you're the bad guy for not putting in content for the game. Long-term, you're helping set a healthy precedent for the team. Or learning the meaning of the phrase, "unemployment benefits". At which point, I'm sorry and I never wrote this blog in the first place. Stop e-mailing me saying it's my fault why your children are hungry.

This is all just, like, my opinion, man.

Six Years Later - Lessons Learned

I started my first job as a game designer on August 17th, 2009. I traded living in my parents' house in New York to living alone in a hotel room in California with everything I owned in four boxes. Six years later, I'm writing this post in the living room of the house that I rent (of course I rent, California is insane) with my wife and child. There was a lot I learned about myself, both as a person and as a game designer, but you aren't here to read about me, you're here to read about the gaming industry.

This is the start of (hopefully) a series on what I've learned in the game industry over the past six years. The first topic is...

Assume but Verify Competence 

Don't assume everyone is like this.

Don't be the guy that assumes that somebody is bad at their job.  This can lead you to distrust the people around you,  and cause those same people to distrust you, because it's always obvious when someone else has the attitude of, "I don't think you know what you're doing." Assume everyone is competent, but then verify that this is true. Here's an example:

A designer is making a mission and you're reviewing it. You see a portion of the mission takes place on a seemingly unreachable part of the map. 

Nothing you can think of will get a player to that area. 

You have a few ways to approach this: 

A) Tell the designer, "Change that part, players can't get up there." 

B) Assume the designer knows what he's doing, say it looks good, and walk away.

C) Ask the designer, "How do you plan on getting players up to that part of the map?" 

Option D, remain silent and walk away.

Option A assumes that the designer doesn't know what they're doing. It's you asserting authority and telling the person they're wrong, and also subtly suggesting that you know everything there is to know about the engine. 

Option B assumes competence but doesn't go through with "verify." You just assume that the designer knows what they're doing, and move on. This can lead to you getting burned if the designer did in fact make a mistake, and eventually you will assume that no one can be trusted.

Option C puts the power in the designer's hands.  You assume they have a plan and perhaps they know something you don't know. You're curious about how they're doing to deal with this seemingly impossible problem.  

This opens up many possibilities for dialogue. The designer could inform you about a new trick they learned, or a new piece of tech that was put in that you didn't know about. You could walk away from the conversation having learned something. 

On the other hand, if the designer did make a mistake, they could tell you that they didn't realize players couldn't get to that map. At this point, you can work together to solve the problem, and the designer walks away from the talk having learned something. 

Someone will learn something.

All of this boils down to you assuming that you might not have all the information needed to make a decision about something. I initially dismissed this lesson as just office politics that I didn't want to deal with. However, if you assume someone doesn't know what they're doing and they actually do, then it creates a really negative stigma against you. People begin to mistrust you because it's obvious you mistrust them.

Everyone starts lying to each other and it becomes an episode of Arrow.

This simple lesson can make or break an entire team. If a lead designer doesn't assume competence, it can create a terrible environment where the lead assumes they are always right and then enforces their own design decisions on the people beneath them without any discussion. The higher up they are, the more damaging it can be.

I was initially going to write all the things I learned, but it turns out I like talking more than I thought, and this blog post is long enough, so I'm going to save the second bit for next week's post. 

Stay tuned next Monday for the second part of this series, "Lessons Learned - Skill Isn't Enough." 

PS: Assume Competence does not extend to driving. Assume no one knows what they're doing behind the wheel.

Assume everyone else driving is like this. You'll live longer.

Why Do I Make Video Games?

Last night, I watched Video Games: The Movie on Netflix. If you haven't seen it, check it out, because it's a great film that every video game player and developer should see. Watching it made me realize that I needed to ask myself the question again - why do I make video games? It sounds dumb to ask, like, "why do I go into work every morning", but I think it's an important one to continually ask yourself to avoid just doing things automatically. 

I wanted to challenge a point that was brought up by a developer in the movie, which was that video games are a form of escapism. You play them to get away from your "boring" life to do something amazing. This is not why I make video games. I've used games as an escape before, and it never ends well. Plus, if your life is going well, and you were playing games as a way to escape from things, then why would you continue to play games?

Zynga's founder, Mark Pincus,  at one point used the phrase, "surprise and delight", to describe their games and their shopping. While I'm not a fan of anything that Zynga does, I think the idea that you want to surprise and delight your players is one of the reasons why I make video games. I love watching Let's Play videos of people playing through my content and their surprised gasps, laughter at easter eggs I've put in, or reactions to serious story moments that I've put in. One of my hopes with the content that I make is that it'll help make someone's day, give them a story to tell other people, or at least give them something to remember and smile about during the day.

One of the other reasons why I make games is the idea of trying to have a discussion about the every day things that we all go through, and maybe even try to glorify what others might consider "boring", or subjects that people would just want to escape from, like depression. One of my all time favorite story arcs that I had almost full freedom to work on start to finish was for Dark Astoria in City of Heroes. I know I bring it up a lot, but that's because I love it so much. It was a story arc about a god of Death trying to destroy the world, and he did that by tainting a person's memories and making all of their good memories seem empty, while the bad ones were given more weight. The story, for how over the top it sounds, at its heart was about depression - what it is, what it does to a person, and overcoming it.

I wanted to end this post with a long quote from what a player wrote in response to Dark Astoria. I smile every time I read it, because this is why I make games - for the players. If I can make a game that gives someone a good memory, something to help improve their lives, bring them together with their friends, help them deal with whatever circumstances they're in, or even see something from a different point of view, then I consider that a win. I want everything I do with games to deal with things in life, to help someone embrace more of life, not seek to escape it.

Anyway, here is a portion of this player's feedback on Dark Astoria, written before City of Heroes was shut down.

Throughout all of this, I read nothing about the new Dark Astoria and refused to be spoiled on anything. Until the announcement, my goal was to lead her through the story arcs all the way to level 50 for an eventual return to her hometown to fight Mot. After the announcement, I couldn't log into the game at all, and let several weeks go by without touching any of the characters. A few people, especially Golden Girl, had said there was still time get her to Dark Astoria as an incarnate, and I finally decided to try it, to forego the story arcs I'd hoped to run and instead grind her from 32 to 50 with just a few hours a day over a few weeks. With some help from the forums, she finally got to level 50, ran the Ramiel arc and then took the call from Captain Nolan to investigate an epidemic of murders and suicides in Peregrine Island. Well, over this past weekend she defeated Mot. And never has a video game left me in tears before.

DARK ASTORIA SPOILERS!

For one thing, it's even more amazing a story than I'd allowed myself to hear people say (i.e. "the new Dark Astoria is amazing, especially..." "lalala can't hear you!"), and it's a more perfect an ending to the game as any game I've ever played. The message about hope overcoming despair has never been more relevant, and as someone who's struggled all my life with depression, the metaphor of Mot as depression, especially how it drains the joy out of your memories and leaves you feeling like your whole life has never been any different, rang painfully true. For a story about a cursed town and a Lovecraftean horror ushering in the apocalypse, it turned into one of the uplifting, triumphant stories I've ever played, ever seen, or even read. The scene with the huge army of practically every NPC in the game gathered to fight against the Pantheon left me frantically hitting the screenshot key and just elated at the sight of it all, every arc in the game coming together at the last to fight for hope. Jim and Fusionette, Shadowstar and Sunstorm, Keith Nance and Jenni Adair, even Katie Hannon (one of my other big alts is a Cabal sorceress gone MAGI heroine, so I practically cheered aloud to see the Cabal represented in the fight against Mot)... it's like everyone in the game came out for one last, epic sendoff. If anyone hasn't played the DA arcs yet and has a level 50 character, please do so. If CoH has to end, that image alone is as beautiful an ending as could be asked for.

But with Astorian Shade, the story took on a life and power I'd never expected. I had no idea what the new DA was going to involve, I just drew on the old badge lore for her story - and yet the two stories intertwined in ways that left me just gaping at the screen, trembling with the emotion she'd naturally feel before finally catching my breath and daring to hit the keys again.

When Heather Townshend's story ended with the revelation of her role at the warehouse, I just sat there for half an hour, reeling with what it'd mean to Shade, how such a conversation would go. The game leaves it ambiguous whether Heather actually tells your character anything, but it all flashed in my mind with hardly a conscious thought. Heather had found hope in Shade saving both Kadabra and Sigil, only to have it snatched away again when she admitted to the heroine why she'd come back to Astoria. Shade's look of shocked betrayal, shaking her head wildly when asked what's wrong, and Heather's guilt-stricken realization that all this time she's been working with the ghost of someone who died there, that the screams haunting her dreams were probably Shade's own screams, her stammering attempt to apologize only to be answered with Shade furiously shouting to leave her alone (not even really out of anger, but from being so vividly reminded of something she'd tried so hard to forget)... all of it came together to make Heather's almost suicidal trip through the warehouse in a vain search for redemption, and then finding it in Ajax's reassurance that her life has meaning, that Shade's going to need her help to defeat Mot, incredibly moving.

Of course, everyone who's played the DA story knows what's coming, and that Heather's just the tip of the iceberg. The big moment, and another one I had no idea was coming at all, was the revelation in Cimerora of how the seal ended up beneath Astoria. Her whole afterlife had been driven by vengeance against the Pantheon and Mot for what happened in Astoria, only to find that she was the reason for it all. Now, to give the future a fighting chance against Mot, she'd have to condemn her town, her family, everyone she knew, and her past self to die. Heather's guilt became nothing against the enormity of that decision: Heather never would have been in that situation at all had Shade herself not sealed Astoria's fate centuries before. The question finally arose of what's really driving her, because vengeance no longer even made sense. She couldn't destroy her own life to make Mot pay for destroying her life. The only reason to make such a choice was to give up revenge in favor of saving the world, and accepting Astoria's fall as the price.

I'd never, ever imagined that plot twist coming, and it changed my original character into something far more than I'd planned, into a tragic, messianic figure. She'd learned at the end of her AE arc that blind vengeance only serves Mot's purpose. She'd learned from Aaron Thiery that vengeance and justice are two different things. But only now had she really learned that a third possibility exists, understanding and forgiveness, and when Hua Tov later asked her whether she thought he could be forgiven, she honestly said yes and comforted him before he died. And within a few more missions, the game had sent her back to Heather, this time understanding the terrible choices people sometimes have to make and so more compassionate and willing to listen to her.

And then there's the finale. Learning about David Hazen's life and struggle against Mot (and I really admire the sheer bravery of the journal addressing the question of how God fits into a setting where ancient deities threaten the world and can be killed with magic swords, as David himself asks that very question), saving Detective Hopp and Bellerose (and kudos to Hopp's story for subtly bringing Roy Cooling's arc back and showing that things have started to change because of it), and eventually having the whole world placing its faith in her, cheering her on as all the world's heroes and many of its villains rally to fight together in a massive war against the Banished Pantheon... I knew she was always going to defeat Mot, and then ascend to the afterlife, but I never dreamed of such a sight as this...

And all I can say is thank you. Thank you to Doctor Aeon for writing a story that did so much more for my character than I had ever imagined for her, that gave her a shining moment unlike anything I'd dared to hope she might have. I have two other characters who also worked hard to reach their proper endings, Sparkly Soldier Yuki in the Moonfire TF to arrest Arakhn, and New World Daughter in the Katie Hannon TF to reconcile with the Cabal and defeat the Red Caps, but Shade's story is the one that's going to haunt and inspire me for the rest of my life. Thank you.

The Art of Scoping

Scoping can be an ugly word in the game industry. When someone says, "scope it back" to a creative person, it can be taken as, "I know you want to make the Mona Lisa of game design, but you need to tone it down and make it more like the five dollar Target knock-off, thanks." However, knowing how to scope well can turn your piece of content from a mediocre work to a work of brilliance, and it is not a task you should rely on your producer or lead to do. Here are some things that I've learned about how to scope properly.

The first part of scoping is to prepare for it early. In a pitch meeting a few years ago on City of Heroes, I was asked by Matt Miller what part of my content could be cut due to time constrains. The question baffled me, as I had written an air-tight story in which everything absolutely had to happen, and if time didn't permit, well then I would make it permit. I'd put in the hours to make sure this work for brilliance happened. It's important to note that at this time I was single, and hadn't learned the lesson that another designer, Joe Morrissey, taught me, which was, "Learn how to get everything done during work hours"

"Yes, we can do it in 5 days. Of course, that's working for 24 hours a day for 5 days."

The guys over at Extra Credits have a phrase for scope, which they called the "minimal viable product", but I think that word sends shivers down the spine of designers who think that means you've done "just enough" to ship. Nobody ever wants to just do enough to get by. I prefer to think of it as, how much time do you want the player to spend playing your content? Also, let's include the idea they're having fun during this and that I'm not just wasting their time.

Pictured above, player's time that bad games have wasted. Sorry for the graphic image.

I'll give an example from a design I've made. I wanted the content to be about thirty to forty minutes long. The content was split into 5 sections: prologue, Act 1, Act 2, Act 3, epilogue. Act 2 was where the meat of the content was going to take place, where I would do the most complicated scripting/design work and where environment art would have to make the most new assets. Act 2 was going to be about 15 minutes out of the 40 minute game play. Everything aside from Act 2 would be about 5 minutes of game play.

As an side, some people may disagree with me, but I think it's important to aim for a set time you want players to be playing your content. It's really easy to just do what you think is cool in five different places, and then end up with things being wildly different flow-wise. Your first act is 30 minutes, your main act is 5, and your epilogue is 25 minutes. Knowing how much time each section is supposed to take helps you adjust your design early when those times aren't correct.

These remaining acts were meant to be visually appealing by re-using assets in a new manner and by doing scripting/design tricks to make it feel great. All of these methods were safe, proven, and easy to implement. The bulk of my risks were going to be put into Act 2. The risks were that environment art wouldn't have the time to support everything design wanted to do, and that the new design attempt would end up failing and not being fun or being too hard to support 15 minutes of it.

My plan was that anything cut in Act 2 would have its time dispersed into the previous acts. If something failed in Act 2 and it turned out we could only do 10 minutes of content, I could easily add a fun encounter or contact dialog in Act 1 or Act 3 to make up for the content. I had also written the outline of the story so that this could be done without the story suffering for it. It's important to note this added content was planned to not be just "filler", but to actually be interesting.

In the end, the design I mentioned above worked pretty well. I had actually put too much into Act 2 and its initial game play was something around 20-25 minutes. I cut a few things very early on, which at the time, I felt we probably could support. However, when everything was said and done, the entire piece of content flowed way better with those cuts and allowed us to really focus. The important thing about the project was that neither myself nor the environment artist working with me had to crunch at all, and we never felt pressured because we both knew that we had plenty of options if something had to be cut.

They call me The Cutter. ... this was the first thing that appeared on google when I searched "the cutter". Sorry.

This is the importance of scope. Scoping is not about avoiding taking risks or doing ambitious things, it's about doing all those things in a smart way. You just need to view it in a more strategic sense, because players aren't going to see what you wanted to do, they're going to see what you actually did.

I scoffed at the ideas that Matt Miller and Joe Morrissey told me about scope and work. Now, as a married man with a kid, I can see the importance of it. Planning scope in your projects gives you and your team confidence in your plans. If producers and leads know that you are a person who gets things done in the 8:30 - 5:30 work day, then they'll have that much more confidence when you give them time estimates for things. If you say, "it'll take me 5 days", they know you mean it's without crunch and with back up plans made to ensure that will happen.

Knowing that people can take you at your word for planning is a much better feeling than the pat on the back you get for "sticking it out" to crunch through something, trust me.

And not crunching means I get to see this little guy every day. Not pictured: him pooping.

A Day In the Life of a McDesigner (April 2014)

Hi everyone! As usual, it has been a while since I've posted. Many things have kept me away from blogging. The biggest thing has been the birth of my adorable baby boy, James Gerard McCann! He's nearly six months old and is completely adorable... which I can safely say now that he's sleeping and not crying.

A while back on twitter, I asked people what they wanted to hear from me as a game designer. One of the things that came up is, what exactly do you do  during the day? This has come up a lot in interviews that either I've done or that other people have done, so I figured it would be interesting to  post a blog about a random day in my life at work for people to read. There will be a lot of these, as days tend to be varied.

So, without further ado, here is an outline of a day in the life of a McDesigner. This one comes from a long time ago, before my son was born, around April 2014. Keep in mind that since I'm pulling this from a while back, this may be less "a day of" and more of, "Sean mashed together several memories and is calling it a day."

The main goal of the day was to pitch the episode, Capture the Flag, for Star Trek Online's Delta Rising expansion. In the morning before the meeting, I was going over the pitch idea with the environment artist, Adam Flores, who would be working with me on it.

A few days before this, I was given the times that I would get for support from environment (Adam) and also how long I would be given to work on the episode.  I was given the general outline of what story points had to happen in the quest and asked to fill in the blanks.  As a little, "bonus quest", our producers asked if I could shave the environment time down to give Adam extra time to support an episode that was already going to be big.As another side quest, the mission involved a "Super" version of a bad guy, and I was asked to replicate and improve upon a cool fight cutscene I did in the previous release.

This was an episode that was going to be tricky, as my wife was ready to give birth at any moment, so there was no guarantee that I would finish it. So, that morning, I finished making a very clear documentation which included drawn maps, of what the mission would look like. I had to make sure that someone who wasn't me could theoretically come in and pick up wherever I left off.

During the process, I had worked together with Adam to figure out how to use his time. Together, we came up with a proposal for the environment that would take significantly less time, but would still give us a great result and allow him more time to work on the other task. The work he would do would be to do big, sweeping material swaps on areas to make things feel different, along with lighting and propping the areas with pre-existing assets. Anyone familiar with the episode knows that we took a pre-existing interior kit and put different materials on it to look new.

Before the meeting, Adam and I double checked the document written to make sure we were on the same page. The meeting itself had the leads from the various disicplines that would be involved, along with the producer in charge of the episodes as a whole. I had the doc up on a projector describing what I wanted to do with the episode and outlined what each part of the mission would be. For the most part, the meeting went well. The leads and producers had some feedback regarding what could be potentially risky for the mission, such as the big fight scene and a boss fight I wanted to do, and I agreed to get the risky things done first in the event that I had to take Paternity leave. We set a deadline of three days until our first whitebox playable, where the leads and I sit down and run through a very basic version of the mission to see how it feels from a very high level.

Once the meeting was over, the rest of my day was spent whiteboxing the mission. This means that I went through and took existing assets to piece together the mission map and set up the flow of the ground portion of the mission from room to room; what encounters would be in this room, how the player would go from level to level, etc. Since I had written up a clear doc with a map, all I had to do was follow what I already planned out.

I also set up a mission design outline in the game, things like titles for mission objectives, how they would flow into one another. During this time, Adam was finishing up his previous tasks, this way I would be a day or two ahead of him to get everything orderly before he came in to art it up.

By the end of the day, the whitebox of the mission was complete. The task itself was pretty easy since everything was concrete and agreed upon by the higher ups. Adam had a good idea of what the art should be, and had looked over everything I set up and gave it the thumb's up that everything could be accomplished by him in 5 days time.

With that finished, I left the studio and figured out what I would do the next day - set up the scripting for the cool fight scene people wanted, and then actually set up the framing and shots for the cutscene, then finally put it all together and tweak everything to work. Long story short, my next day was going to be totally different from my previous day, which tends to be the norm in this line of work.

And that was a day in the life of a McDesigner. I hope this was only slightly boring, mostly interesting, and maybe a little exciting. Please feel free to leave feedback about what you all thought of this post, and I'll do my best to keep posting these more often!

Achievement Earned: Non-Achievement

I award you no points, and may God have mercy on your soul.

Good achievements can be hard to come by. Bad achievements can pile up by the dozens. The nature of achievements is extremely important in a game, especially in an MMO. Achievements can help define player behavior; bad ones will create aberrant behavior, good ones encourage good behavior. If you take this theory and put it into an MMO, you see how wildly dangerous or beneficial an achievement system can be. What is the difference between a good achievement and a bad achievement in an MMO? 

Before you make an achievement, you have to ask yourself, "What sort of behavior am I encouraging?". This is something that Matt "Positron" Miller taught me through his experience, and it has been an invaluable lesson. You want your achievements to reward some skill, good behavior, and fun. No one ever creates an achievement thinking, "this will be absolutely no fun at all". Plenty of people create achievements that they think are funny or interesting without thinking about what sort of behavior they're encouraging. If you have enough of these bad achievements in your MMO, players will begin to expect to be rewarded for bad behavior and will actively try to do bad things to get rewarded for it. I'm going to go over my laundry list of bad achievements, and then give some examples of where I've seen really good ones. 

MMO's are littered with the, "kill a whole lot of this guy" achievements. Achievements for killing 500 enemies over the course of gameplay might sounds good, especially if your combat system is enjoyable, but it does not create fun. People who hunt achievements will figure out the fastest and easiest way to achieve them, even if that way is incredibly dull. An achievement meant to be done in the natural gameplay of the game now has players trying to run one mission over and over again to get those kills. That isn't fun, and in a multiplayer setting, that is encouraging bad behavior. The end result of achievements for doing a single action a repetitive amount of times is grind, and it will be grind in the worst way possible.

Then there are the achievements that designers find funny. Sometimes these fall in line with good behavior... and sometimes they don't. Many people see giving a player an achievement for dying in a dumb/funny way to be the punchline to a joke - you stood in the fire and died, have a laugh, here's the, "Burning Man 2009" achievement. The goal there is to make the player laugh, maybe not take their death so seriously. However, the outcome is that now all players who want achievements are going to get themselves killed in this way. This is bad if you're in a solo mission and outright poisonous if it's in any sort of group context. If you start doing this in an MMO, people will actively seek dumb ways to die in your content to see if they're rewarded for it. These sorts of achievements, while made with good intentions, have one consequence: the destruction of good gameplay.

Throw the achievement into the fire and be done with it!

Finally, there is the combination of the two above. I've recently seen this in Guild Wars 2, and it bothers me to no end. The game gives you random daily achievements to strive for, which I think is a fantastic system that more games should do. However, one random daily achievement is to kill 35 ambient creatures, like rabbits, squirrels, etc. This isn't fun and it isn't challenging. It could be funny, seeing super powered warriors stomping on wildlife, but in my experience, it was just aggravating to hunt down enemies who possess no threat or challenge. This ends up just being a mindless and tedious grind that I was all too happy to be done with to get my reward.

Good achievements encourage players to play to the best of their abilities, and that method of gameplay should be fun. Team Fortress 2 can be hit or miss with their achievements, but one I particularly liked was for the spy, called, "The Man with the Broken Guns". It is rewarded for a spy backstabbing an engineer, then disabling three of the engineer's buildings within ten seconds. In the game, this is the best way to be a spy, both for your own gameplay and for helping out your team. This achievement encourages fun gameplay and good behavior, because people going for this achievement will be helping everyone on their team. 

I may or may not regularly play a spy.

Another good example of achievements are ones that record you doing something particularly difficult. Diablo 3 (another hit or miss with achievements) has the achievement, "Don't Stand in the Fire!", where you have to defeat a boss without being hit by any of its area of effect attacks. I personally love these types of achievements, as long as they are realistic. This is the designer saying, "try to beat this in the best way possible". 

This type of achievement can go south really fast, and I have personally done this in my career with the achievement, "The Midnight Dodger Which Dodges at Midnight". It was an achievement rewarded for avoiding being hit by land mines in a boss fight. However, these land mines were all over the place and somewhat random. In the end, it encouraged weird behavior because it was so hard to get the badge through normal gameplay that players had to come up with ways to cheese the fight. That isn't the fault of the players, that is the fault of the designer.

That is something I want to end this post on. As a designer, you are the one  (for the most part) who is creating the behavior that players will adapt to. Note that some players will always try to exploit or break your system, and for those, you can just do your best to guard against them. However, if you find yourself creating bad achievements that I've mentioned above, then you're the one setting up bad behaviors for players to follow and continue to follow. It is not the fault of the player for playing the game in a bad/boring way, it is the fault of the designer for setting up the system where that is the best or most rewarding way for playing the game. What you always have to keep in mind is the question, "What sort of behavior am I encouraging, and what sort of behavior am I rewarding?"

Designer Lessons: Hacking

When I first started in the game industry, I learned the phrase, "dirty hack". It was used for a lot of work that I did in my first few years, and at the time, I thought I was being clever. People would talk about how they had no idea how my designs got from A to B and ended up getting the results that I did, and I took pride in that. However, looking back, I can see the damage that dirty hacks can cause, both to the designer and to the player, what to do to avoid them in the future, and why it's important to design with both players and other designers in mind.

A "dirty hack" is taking a feature and using it in a way that was never intended. Now, there's a fine line between, "oh wow, I never thought of using it that way!" and, "OH MY JEEBERS WHAT ARE YOU DOING WITH THAT?!" Here's an example of the latter.

This was the face of QA, programming, and other designers when they saw what I am about to say.

Vincent Ross. He was a contact for a story arc that I worked on back on "City of Heroes" (pour one out). To this day, I still apologize to the other designers and QA who had to put up with me making him. I consider his story arc to be the height of my dirty hacks (although Matt Miller may have other suggestions for that).

We created a system called "Optional Dialog" where a player could talk to an unrelated NPC while they were on a mission. We used this in "Going Rogue" to let players call up an NPC to act like they were working undercover during a mission. The system itself was fantastic for what it was designed for - calling NPC's to add purely to ambiance for a solo player's experience. If you were a member of the resistance who turned loyalist, you could call up your resistance contact before a mission to get extra story details about what you were doing. For the most part, these contacts did not affect gameplay at all - they were simply dressing.

What a dressing it was! Please, pass the bread.

Enter Vincent Ross. We had just finished Going Rogue, and I was tasked with writing villain content. I helped implement the above system with one of our programmers and desperately wanted to use it more. I came up with an idea for an arc where several factions were all trying to get this one item. When you started the mission, you had the option to talk to one of five factions to do their story along with the actual storyline. The five factions were: Cage Consortium, the Family, Diviner Maros (if you played his story arc), Doc Buzzsaw (if you played her story arc), and Operative Kurkland (if you were an Arachnos Soldier). The idea was you'd have ultimate replay ability and understand more of the story was you went along. It would be 5 story arcs wrapped into one arc's worth of environment development, and I would use the above system to get it done. Everything was going to be fine!

Just fine.

The way the system worked was that when you accepted the first mission, you had the chance to talk to all five faction members, depending on which one you could unlock. Since the system was ancillary, there were no way points pointing you to talk to them, just a quick yellow text suggesting you could do this, but that you didn't have to. Because of this, you had to know where the contacts were in the world. When you officially chose one contact to work with, they gave you a clue, saying that you would work for them. Having that clue would lock you out of talking to any other contacts. On the level of hacks, this is fine, not even a hack, just using the optional dialog system as it is.

Next, when you entered the mission, there was... a radio on the ground. It was always there, whether or not you talked to someone or not (because remember, this entire system was optional). This was the only way, at the time, to get the optional dialog to talk with the mission system. That radio had a dialog tree on it, and that dialog tree was checking if you had any of the clues from the above interaction. If you did, you unlocked that person's optional dialog within the mission. That dialog triggered an objective to be complete in the mission, which triggered an enemy or a click to be spawned and UI to appear on the mission to explain what to do. When you completed the objective, you received a clue that basically acted as a, "you completed the person's mission objective". Once you completed mission 1 and moved on to mission 2, you could only talk to your optional contact if you had their original clue and the clue that said you completed their optional objective. The end result of all of this was that in the penultimate mission, you would get one of your contacts as an ally and a special badge. Repeat this for roughly 5 missions, it meant that each optional contact had more than 11 clues tied to their logic, putting us up to more than 50 clues for something that was not mandatory to do.

Nobody has time for that.

This whole logic falls apart as soon as the multi part of the massively multi-player online game comes in. If two people teamed up and went through the mission, they could have multiple side objective missions appear, which clogged up the UI and the mission map. Simple solution - make it so only the owner of the mission could do it. Bam! Problem solved, let's deter people from teaming up in a multiplayer game by making only the mission owner get the cool stuff.

Next problem. Let's say I did mission one and worked with Arachnos. My friend did mission one and also worked with Arachnos. We team up for mission two, he does the optional objective and gets a clue. Great! I helped with that, I should get it too, right? Nope, not how our system worked. Now my friend leaves for the night. I go on to mission 3 and try to talk to my contact, only to find I don't have the clue, so I can't progress forward with my optional mission. This broke while I was on vacation in Tahoe. Because I did everything in such a strange way with so many hoops, no one else could even begin to fix what I made, which meant we had to keep a showstopper open internally for about 3-4 days, with production not knowing if we could even come up with a fix.

How I pictured production when they saw the monstrosity I created.

Anyway, the solution was if the requirements are messing people up we'll just... not require you to do the optional objectives in each mission. We'll just ask that you have talked to one contact at the start to begin your optional missions. The final badge will be gated if you did one optional objective at all. This was the better solution overall, but still not great, because it still meant teaming was borked, just not as much, and the design became very flimsy.

Now, if you're a die hard fan of City of Heroes, you might be saying at this point, "Sean, you keep mentioning 5 optional contacts, but paragon wiki's entry for Vincent Ross only show 3!" Ha ha ha. Remember the "clever" use of clues? Turns out we had a limit on the amount of clues you could have. At a certain point, you just stopped getting clues. This broke everything in my frail system. We did the math and had to chop off two contacts, which meant Doc Buzzsaw and the Arachnos contact got the axe.

They would have followed me to the end.

Through all of this heartache, we finally launched the content. I was really excited! People would be running through the forums loving the optional contacts. However... in the end, not a lot of people even knew they existed. All of that QA work, all of that design work, all for a feature that nobody knew existed.

Why? Well, since we were using systems in a way that they were never meant to be used, the messaging on where to go, what to do, and how to do it, were all poor or non-existent, which meant only players who were playing very close attention and already knew where to go would find it. This sort of feature is fine for something small, but for something as massive as this... it was not good.

I thought at the start of this madness that I was just making another clever hack that would be awesome content for the players, but my days of hacking finally caught up to me. The whole system technically worked, just like a house of cards is technically standing. But the minute any pressure, any aberrant behavior was pushed against the system, it would collapse into a huge pile.

Not seen: my tears of frustration.

This is one of the defining characteristics of a dirty hack. Your system works in one way, but it collapses entirely if a player deviates at all from the expected behavior. It's also a hack when you are the only person on your team who understands what you've done. Everyone on your content team knows the tools and should be able to look at what you've done and put the pieces together. Your content needs to be readable by everyone on your team, not just you.

What does it mean then to make a clever design? Both a clever design and a dirty hack share the same description: using features and technology in ways that people may not have thought of. The difference being is that if you're clever, you play to the technology's strengths and create a castle of a design, one that won't collapse no matter how hard or crazy people play with it, a design that is understandable to both players in the game and designers working on the project.

Not that sort of Castle.

A clever design also understands where it should stop when using new technology. Vincent Ross would have been absolutely fine with one optional contact in one mission that changed a mission objective. We had never done something like that before. Instead of all of this crazy work, we instead could have just forced the player to talk to a contact before the mission, and then you chose to help that contact out and it changed the mission, all players would have seen it and people would have then let us know how they felt.

An example of a safe and clever design was the Personal Story missions that were put out in Dark Astoria. This was a non-combat mission where you played as the contact from your mission. At first, we wanted to shoot for the moon - make it a full combat mission, give your contact new powers, go crazy. However, the technology for doing this would have come in at the last minute, so we abandoned it and used technology that we knew worked. All we did was disable all player powers (easy to do, reliable), give them a costume (easy to do, reliable), and make the mission single-player (easy to do, reliable). We then had the contact give out the mission as their final mission (easy to do, reliable, easy for all players to see). The missions were kept short, simple, with no combat (easy to do, reliable, easy for QA to test, easy for other designers to reproduce).

The feedback from player was very positive. We had never let you play as other characters, and the entire thing was an experiment to see if people would want more. It was, more importantly, an experiment that was easy to make and, going forward, costed us very little to add on.

Personal Stories are an example of clever design. They weren't perfect, but they were good. We used existing resources in a reliable and smart way, while also pulling our punches by not going insane on something that was brand new. The majority of the players saw it, understood it, and played it. Vincent Ross is an example of a dirty hack. I used existing resources in a dangerous and unreliable way. A ton of time was put into it and not a lot of players even noticed it to ask for more.

That's it for today's random blog post. I would love to talk about more things related to design and MMO's, so please feel free to throw out ideas of what you would like to hear (or not hear ever again) in the comments section!

PS: Some of you might be asking, "Hey! Why no Star Trek Online stories?". Well, I feel pretty free saying all the stories from City of Heroes without asking for permission, given that the studio has shut down, but since I'm actively working on Star Trek Online, I would need to talk to people first to make sure I do not say anything that shouldn't be said. If people want to hear anything specific from STO, let me know and I will talk with People about it.