Stardock's Art Director, Paul Boyer, will be working as a Game Designer on one of our projects.  Paul has been around forever and has a ton of experience.  At Stardock we believe that "everyone is on the design team" so just because Paul was the Art director before didn't mean that he didn't contribute to the design of every game he has worked on.  He has been a great asset to me and is second only to Brad in people I ask for feedback on FE design ideas.

Evaluating ideas

But it has left me thinking a lot about the role of a designer, and particularly how I can help Paul make that leap from "here is a cool idea we should think about adding" to how that idea affects the rest of the game.  What is the effect the scope (as an Art Director Paul is already very familiar with this process)?  Is it fun?  And how does it affect the rest of the game?

That last question is the hardest one.  In strategy games every piece affects every other piece.  There are the direct results, we raise spell damage and monsters seem to be too weak.  We make monsters tougher and spells seem underpowered.  But the indirect is more difficult.  If we have monsters lairs give good loot and xp, why bother researching the techs to unlock quests which offer similar rewards?*  By itself having lairs give xp and treasure is fun, but a game designer has to see the whole picture.

So I tend to review all ideas with the following criteria in mind:

1. Does it match the games focus?  The core experience of Fallen Enchantress is building, leveling your units, leveling your cities, designing units, building things.  Features and ideas that follow this progression are ideal to building a complete theme and feeling for the game.  Much like how lighting, music, set design, etc, all work together in a movie to reach a common goal all of the game mechanics should have a common feel that cause the games theme to resonate with the player.  (this is why cities having enchantment slots and city types worked so well for Fallen Enchantress)

2. Does it solve a problem?  The tendency of designers, including myself, is to create too much.  So once I'm beyond the base core of the game mechanics I have to force myself to ask if new ideas and mechanics solve any existing problems.  If not, why add it?

3. Does it solve multiple problems?  It's usually easy to solve a specific problem.  But as I mentioned above, in strategy games every piece affects every other piece.  If all an idea does is fix one problem, then it's probably not worth the effort and I usually hold out waiting for a solution that fixes multiple issues at once.

4. Does it have drool factor? (ie: if I tell a player about it will they be excited to try it).  I'm less eager to spend development time on things that players won't be excited to try (or as a business guy would say, "doesn't sell copies").  Sometimes we need to spend time on the unexciting parts of the game design, cleaning up screens, polishing graphics, improving performance, fixing bugs, or adding fundamental tools which support gameplay but aren't sexy (I don't think anyone checed out FE and thought "A game with a tax slider?!?  I love tax sliders!  I'm buying this!").

5. How difficult is it to implement?  Now the producer part takes over.  Even given all the above the implementation cost could be too high.  I love the random maps in Fallen Enchantress, but I don't know if it was worth the considerable implementation time it took to create them.  The game is definitely better for them, but we could have created 100 hand crafted maps in a fraction of the time and had all that extra time for other features.

6. How will we provide feedback?  A lot of gameplay is feedback.  How will the players interact with this mechanic?  Will they enjoy it?  A lot of mechanics die because there isn't a good way to show the player they are doing it right or wrong.

Let's go through an example.  A few weeks ago Brad suggested having cities that weren't connected to your capital suffer a penalty.  In his mind he wanted a reason to connect your empire with outposts.  He enjoyed doing it, as many player do, but there wasn't any mechanical reason to reward the behavior.  So the idea was evaluated.

1. Does it match the game focus?  Yes.  It allows the player to build his empire much as he builds his units, armies and cities.  This is empire level customization.

2. Does it solve a problem?  Yes.  It rewards players for building contiguous empires.  Perhaps more importantly it give a player a reason to chop his enemies empire apart by taking key cities (or a reason to be angry when an enemy does it to him).

3. Does it solve multiple problems? Yes. One of my lingering problems was that unrest was too low.  You build a few buildings and it doesn't matter anymore at even moderate tax rates.  I didn't want to simply raise the base unrest rate and force the player to build more improvements, I wanted the player to have more ways to deal with it.  So in came this mechanic to increase the amount of unrest and a new ways to deal with it (building the outposts to connect the empire).

4. Does it have drool factor? No.

5. Is it easy to implement?  Yes, it was nothing to implement.

6. Does it provide good feedback? No.  You see it in tooltips, but it’s a micro-mechanic.  It isn't important enough to take up main UI, so it lurks in the details for players that love those details, and ignored by players that don't care.  That isn't ideal.

Overall it’s a good mechanic so we added it.  Few (if any) mechanics answer yes to all the above questions (especially that "is it is to implement" question).  But 4 out of 6 is pretty good.

Types of Game Designers

I tend to think that there are two types of game designers.  System designers and content designers.  System designers love making systems, calculating the way all the widgets and gears fir together and turn.  I haven't asked him, but I think Jon Shafer is a system designer.  System designers love board games (especially if they get to change the rules to them) and are more impressed with Monopoly's option to remain in jail or pay your way out, then they are the "You have won $10 in a beauty contest" community chest card.

The other type of game designer is a content designer.  Content designers are interested in building narrative into game mechanics.  This comes across as a focus on detailed design, each aspect beyond the game function of the asset is considered.  Where a system designer would look at a champion and make sure it fit the mechanical criteria (we need a champion with water aptitude because that’s unrepresented, we want someone who would make a good defender so let's make him Krax and give him a shield), a content designer is interested in more.  His backstory may include a story about being beaten and left for dead by an Ogre.  His shield is battered, nearly destroyed.  He once had a powerful sword but the ogre took it from him.  Then as a rare monster lair sometimes there would be that ogre with that sword.

I'm a content designer, I suspect Paul will be one too.  His art background is all about creating narrative and those small details (Paul is the guy who fights hardest to fill our cities with pedestrians so you can zoom in and see them working).  I believe that the "You have won $10 in a beauty contest" is a more inspired mechanic that if you can stay in jail or not.  It creates fun each time it is drawn.

Of course the world needs both types, and both types do the others job.  I do plenty of system design, Jon does a lot of content creation.  But we usually start in our strong areas.  When Jon and I talk about game design he is usually excited about large scale mechanics and the potential of ideas.  I almost immedialty go to the details of it, "That's a great idea, with it we could have a unit that does A, a spell that does B, etc".  It doesn't really matter what side you start at, you just have to get to the other side.  You have to link the overall mechanics to the detailed implementation.

3 tips for Content Designers

So I think my best advice for Paul is probably to watch out for the same sort of stuff I have to watch out for.  I offer the following for content designers like us:

Games that are fun to design, aren't fun to play.  The first production system planned for FE was going to use population and citizen types.  There were workers, craftsmen and farmers, different things could affect how many of each you got in this intricate spinning top type of system that I loved for the flavor of it.  The only tiny disadvantage to it was that it didn't work at all.  It required perfect balance to function and any little wobble in the mechanics and the whole thing can tumbling down.  I'm embarrassed by how long I thought it was acceptable to have production times be estimates because the amount of production a city produced changed turn after turn.

But it looked so good on paper.  Brad played with it and played with it and must have passed me a dozen different design ideas that we went back and forth on trying to find a way to make it work before he suggested linking the rates to the city levels instead of directly to population.  The saddest part is we had all the tech to do that already (and implementing the citizen system was a pain, sorry Sarah).  In the end we ended up with a system I love, but I always have to remind myself that games that are fun to design, aren't fun to play.

Watch out for stairwell design.  This is the primary reason I'm distrustful of any idea that only fixes one problem.  In my experience every change leads to another issue.  If you then fix that issue, you get another one, and on and on until you are left making changes that you never would have considered at the start of the process (note: I'm talking about design changes here, not bug fixes).  Always remember what the purpose of a system is, because designs tend to grow and once they are in areas they shouldn't be it becomes hard to recognize them.  Cities are the resource inputs for your system.  They provide the money, research and production for you to do the things you want.  Having maintenance on improvements was contrary to the purpose of cities in the first place and we killed it as soon as we were able.  Addressing the problem by adding improvements that reduce maintenance costs was stairwell design.

The game should be fun without any flavor at all.  This is what those system designer types say all the time.  But they are right (as much as I hate to admit it).  Content designers have to force ourselves out of the mindset of the narrative.

"It would be so cool to start a game and have a massive black dragon perched in a hill within sight of your starting location.  You spend the whole game in fear of him, slowly building up until you can finally gather an army, rush up the hill and defeat the dragon that has been looming over you this whole time."

No.  It sounds kind of cool played out in a very specific way.  In truth it doesn't work out that well.  What about pacing?  At what rate would a system designer feed out challenges to a player as he opens up and explores the world?  What is the impact to a player exploring a world if the first thing he sees is a really cool dragon, then a troll, and a spider, and a wolf.  Take out the story, view it as gears and numbers, you will make a better game.

I hope this is interesting to those of you who enjoy thinking about game design or the job of a game designer.  let me know what you think or if you have any specific questions about the process.

* Origonally the only way to get good champion equipment and experience was through quests, so players that didn't research the techs to unlock them would never have good champions.  But getting equipment and leveling your champions through other things was fun, so we changed the design and removed the tech requirement from quests (which were also fun, but didn't offer any rewards unique or consistent enough to be worth spending valuable research time).