Designing Fun Games

Designing a co-operative card game takes a significantly greater effort than I'd originally anticipated.

I'm surprised because I'd already anticipated it taking quite a bit. What's challenging about the Square Root of Steam (name subject to change) is that its not only a co-operative card game, but its style is different than any game that either Mik or I have played, and possibly any game that exists. We've had literally hundreds of ideas that we've discussed, scrapped, improved on, crossed out, and so forth. For anybody interested in developing a game that's both new and actually fun to play, heed my warning:

It is not easy.

I'm excited because I'm learning so much about the game design process. While I've learned around a dozen really important things, I can narrow it down to the four most important lessons so far:

1. Fun is the most important aspect of the game. This might seem obvious, but its easy to get distracted over balanced mechanics or making the game the right level of difficulty for the player. If a game is too easy but still fun? Great! You've made a successful game. That mechanic is not totally balanced with other mechanics but everyone loves it? You win. Don't be afraid to design something that you think "doesn't work" if the result is something that ends up being fun for the player.
2. Story and context of the game are incredibly important. I tend to focus on mechanics and balance over story and flavor, but sometimes even clunkier mechanics can be more fun because of the context you're playing in. For instance, the game Ladies and Gentlemen is clunky on purpose--but its very fun because its silly and ties in with the game theme. Mechanically excellent games with little story canend up being less fun simply because there's less context for the player to relate to.
3. Games are very rarely too hard. Games need choice, and choice requires making mistakes. Players should be able to make several sub-optimal choices and still succeed. If you're designing a game, nobody on earth knows the game better than you, and if you can't beat it without thinking, its probably too hard. See #1.
4. Playtest all the time, especially in the beginning. If there were a formula for "fun", we'd have found it and have made the perfect game already. Fun is about how the player feels, and no amount of well-thought-out design can make up for a quick playtest session to see how your game feels to someone playing it. You'll end up wasting way more development time than you need to by developing something that a simple playtest would have revealed isn't fun at all.

Again, there are other lessons, but these stand out most clearly AND relate to the things that I've been told over and over again in the EAE program. Hearing good advice and understanding good advice are two very different things, and I'm excited to be able to incorporate that advice into how I design games.

Producing a Small Children's Summer Camp

Yesterday was the last day of the Mobile Game Dev camp, and I'm really glad I did it. Not only was it great to work with Chris Rawson and Sherly Yunita, but it was a really great experience over all. About halfway through the week we talked to Roger Altizer about some of our problems, and he gave us some great advice that I pondered over the remainder of the week.

While some of the students in the class were getting everything I dreamed of out of the course, many of the students were spending the majority of their time playing Minecraft and browser games. I figured that it wasn't really my responsibility to babysit the kids to get them to learn awesome things with their time--if they wanted to waste their parent's money, so be it. Roger set me straight, however--it is absolutely my responsibility to get them to learn awesome things. Some kids will inevitably goof off--he noted--but every kid comes home with a birdhouse, whether it be crappy or awesome.

After thinking about it, this really represents a lot of what I do as a producer, as well. I don't have to care what team members do with their time, but I should because it determines the success of the product. My success as a producer isn't about how well I organize the people who are already working fantastically, but about how well I motivate the rest of the team. Nobody praises a coach for the star player on the team, they praise the star player. The coach is praised when the entire team performs well, and getting the team to perform well is exactly what I should be doing as both a producer and a teacher.

I learned quite a few other things during the course of the camp, including a teacher's worth of knowledge about Game Maker and a lot about productivity and setting ground rules. I didn't think that I would learn as much as I did, but in reality, children are just very honest versions of adults. If they're bored, they're not going to listen. If they're interested in something, they'll pay attention to it. Managing children's productivity takes the same kind of skills that I enjoy working on that it takes to manage a large team, and I'm really happy I got the experience.

Using Project Management Software Correctly

Yesterday I talked with Amy Adkins--former producer at EA Salt Lake--about her thoughts on project management software and how I can use it to be more effective in general, because I was having trouble seeing the use. After talking, its use became very apparent if any of the three conditions are met:

1. You want to organize the vision of the entire team by ranking the importance of different tasks in the development cycle.
2. Your team is on a specific deadline you have to meet.
3. You're working on a large/long-distance team, and need to coordinate the efforts of multiple people.

Project management software is first and foremost a tool to prioritize and coordinate the efforts of a team. With this ideology, project management software can be used for absolutely every project that has more than one person, because each person on the team has a different idea about what kinds of things are most important.

Producers have the job of ranking this priority not only in what should be done, but what can be done. If a team is on a specific schedule, project management software comes in handy to give an overview of the total time a project will take. Often, the choice to cut a feature has to be made after the schedule for a project has been developed and not enough time exists to develop every feature. When a specific amount of hours to complete a project are established, the price of adding new content and/or features becomes much more apparent.

While both reasons above have certainly applied to me in years past, it wasn't until working on a large team that the purpose of project management software finally hit me in the face. Working on a team with 10 or more people is significantly harder in all respects--there are that many more visions of the project you're working on, there are that many more priorities, and more specifically, there just isn't enough time for a single person to coordinate all the efforts of people by keeping up with them individually.

However, using project management software--like Hansoft--still seemed to take more energy than it was worth because nobody on the team bothered using it. Amy explained that Producers and project managers have a responsibility to create a team culture of checking Hansoft on a regular basis, because it can do an infinitely better job of coordinating team efforts than people can. When looked at from that way, I can get more team product per effort I put in if I spend energy creating that culture and updating software than I would putting it directly into managing people. It's not completely intuitive, but it makes sense.

I asked Amy to critique my use of Kanbanpad--project management software I'm using for 3colors development, and her biggest critique was that I hadn't organized things in terms of priority, but rather by type of task. That really resonated with me, and I quickly began to see what I was missing. Project management software is supposed to be a place where any team member can go and quickly assess the most effective thing for them to do for the project at any given time, and I changed the structure to reflect that.

Game Design Camp Using the Activate! Curriculum

Next week I'm going to teach a summer camp about game development to middle-and-high-school age students. It's going to last for the whole week, and they'll hopefully be able to walk away with a game that they've designed, made art for, and coded all on their own.

It's been a bumpy ride, and there have been two waves of teachers who have had to bail on the project, but this last week Chris Rawson and I met together to put together a curriculum using Colleen Macklin's curriculum from Parsons The New School for Design in New York City.

The course that we're teaching focuses more on creating mobile games than it does making games that impact our environment and surroundings. While I firmly believe that games can have a significant positive impact on the way people behave and act, we didn't end up using many of the green-oriented teaching points of Colleen's curriculum. This was partly due to the course content, but mostly due to learning about this ready-made curriculum too late in our class design process. For those who are interested, the Activate curriculum can be found here.

Our course focuses on three specific things: design, teamwork, and coding. The coding aspect of the course will be done in Gamemaker: Studio, and while this is far from even the most liberal definition of coding, it will likely be the first exposure to any sort of code for the majority of the students attending. Most important, Gamemaker is a product that the students can install at home for free after the course.

For the design aspect, we plan on borrowing heavily from the Design I course here at the University of Utah's EAE masters program. Not only was the class the most fun I've had in a classroom, but it also taught many of the principles that I now use on a daily basis. Things like brainstorming methods, paper prototyping, or refinement and playtesting methods are some of the things that we're going to use during the camp.

About halfway through the week, we'll break the 21 kids attending into 7 groups of three, and have them each design a forced side scroller in gamemaker. We're really excited to see what unique things the kids come up with, and for the chance to teach some of the principles that have helped us out while making our own games.

Increasing Team Productivity

I met with AJ today to figure out how we can increase productivity within the Co-Signers team over the summer. Co-Signers has--as expected--taken quite the drop since people are off doing internships and visiting their home countries. I know that we can get progress on the game despite difficult communication circumstances, and I definitely know that we have the production manpower to do it. Even with just AJ and I (Zac is interning at EA and Andrew at Ubisoft), two producers is more than enough to get a firm hold on team organization.

The main problem that we've encountered is not one that is unique to this summer. Certain members of the team are fantastic self-starters who will take a problem from the scrum backlog we've developed and work on it--as decided on in the team meetings we've tried to regularly hold. Other team members will volunteer for a category of tasks, but won't ever check anything out or do anything.

While I initially thought that this second half of engineers were just lazy and didn't care about the project, I've come to believe that they are just the kind of people that will be more productive if things are spelled out for them and more strict deadlines are given. Even though I'd like to believe that everyone is so motivated that they'd put working on Co-Signers before anything else, this is realistically not the case. Some people want to help, but just want to be told what to do, as well.

With this new theory, I sent out individual emails to each team member asking them how many hours that they could contribute to the project, and then followed up within 2 days. Everyone responded, and I consulted with AJ about the kinds of things that we can assign to different members of the team by breaking the tasks into much more granular-ized tasks that we can directly assign to members of the team.

I suspect that the days of team-wide "answer the call" emails are over, and we've entered the age of individual, task-and-deadline oriented emails to some of the team members. I don't necessarily like to act like a boss to team members, but after giving it some thought, I think that a boss might be what some members of the team need to meet their potential. In the end, a producer makes sure that the game is made, and might just be what has to happen to get the game done.

Gears and Steam First Playthrough

On Friday Mik came up to Salt Lake and we had our much-anticipated first playthrough of our card game--for now called Gears and Steam--even though the prototype was decidedly un-finished. I'm thoroughly glad we decided to playtest earlier rather than later, however, because not 5 minutes into the game, we stopped to talk about some of the things we were noticing, and we continued talking for a good 2 hours.

Immediately, things became apparent about how fun or not fun they were, and I was disappointed with how many things just weren't fun. The most notable thing was the "speed" mechanic. Initially this was a resource that would allow you to either play a card or use a power. Every player started out with one speed, which was the core of the problem. While "do one thing on your turn" was supposed to be what made the game simple and streamlined, it was frustrating because it became "develop your character or do something to fight", which was a decidedly un-fun choice. Furthermore, while neither of us started our hands with the extra action cards in the deck, it was very clear that having that card in your starting hand would be tremendously advantageous--so much so that we could both picture players thumbing through their decks to "coincidentally" put the action-getter cards close to the top of their decks. Not good.

Furthermore, the original idea of speed was far away from making the game simpler. Since you could use this resource in any time during your turn and it was an inherently flexible resource (we'd talked about using a speed to draw a card, as well), it made things more complicated, not less. The original idea was inspired by Ticket to Ride, where each player only chose one thing to do during their turn and moved on. While this concept worked beautifully for Ticket to Ride, our game was going to scale by adding more of these actions during your turn down the road. In this case, having 2 speed was not twice as complicated as having 1 speed, it was several times as complicated. Specifically, it was however many things a player could do with a speed brought to the power of how many speed that player had. If the player could play a card, draw a card, or use a power with one speed, thats a choice of three things. Now if they have that choice twice, they have an initial choice of three, followed by an additional choice of one of three things for each option of their initial choice. Having 5 speed would result in 243 combinations, which is more daunting than we wanted, especially for the vanilla characters.

Speed was our primary problem, but there were others, too. Since we had begun by porting character decks from other games to give us a starting point, the characters were not designed to work with the mechanics we'd developed. Specifically, we both found ourselves without sufficient outlets for the steam cards we were attempting to acquire. Furthermore, we found our hand size rapidly dwindling to nothing as we faithfully discarded our worst card at the beginning of every turn to gain steam to potentially use later.

Discarding the worst card of your hand to get something is not necessarily a bad thing, but we found that this just wasn't as fun as we'd hoped. Nobody wants to look at a hand of great cards and decide which one they want to axe for an activity they can only do once per turn (so you'd better not miss it). Furthermore, if there's a card in there that you'd prefer to discard because its not as great, why not just make that card better?

When World of Warcraft was in beta, the game slowed down hardcore players with plenty of time to dedicate to the game by lowering their experience rate after a certain amount of time. They called this "unrested experience", with the idea that your character wouldn't level up or learn as fast without some time to rest. It was received poorly, but the mechanic was sound, so Blizzard changed the mechanic to "rested experience", which instead gave casual players a bonus to the experience they got until the bonus was gone. This was applauded by players alike as a great mechanic, but in reality, the only thing that changed was the wording. Now, people feel like they're being rewarded instead of punished, and subtle changes in mechanics like these are what separates mediocre games from games that truly shine. I frequently refer to the unrested experience story in terms of player perception, and it was appropriate in how our game gave players the steam resource.

Instead of discarding a card at the end of your turn to get a steam, we decided on changing it to a choice of gaining a steam or drawing a card. Now, the player feels like its the end of their turn and they get to choose a reward. Ironically, this mechanic is actually worse for the player, because they don't get a chance to search for a better card and discard their worst, but we both agreed that it felt much better and rewarding.

Still, speed was quite problematic, and steam felt like an all-or-nothing resource depending on what kinds of cards you drew. To make the early game fun and not punishing for not having sufficient speed, we changed speed to a resource that would do more limited things: play a card, and rarely be required for abilities. Most activated abilities would now cost steam, but speed would still be the kind of thing that would only be used on your turn. Abilities that required speed would carry the unspoken question: "is using this ability worth sacrificing a card drop?" This question will be the question that we consider while designing new decks.

Steam mounted really quickly when dealt the right cards, which was a problem because you had 8-12 permanent steam cards that would untap at the beginning of every turn. There were a couple things we did to address this. First, we moved the untap stage to the end of your turn instead of the beginning. While neither of us had seen a game that does that, the location of the untap phase primarily affects when you want the players to save their resources. Players tend to use all their resources right before they're refreshed, would we want players to save steam on their turn so they can use it later, or save steam on other player's turns so that they can have an awesome turn? Additionally, having resources vulnerable from the end of your turn, through the beginning of other players turn, and toward the beginning of your turn gives each player vulnerabilities that the villains can target without saying things like "target resource does not untap normally during your untap step". Now we can just say "tap a resource" and you're not able to use it until the round after your next round.

Finally, we ended up changing what we called the resources. Steam was feeling more like something you got paid in, and we switched to calling that particular resource money instead. Everyone understands how some villains would target their money, but it was always hard to picture somebody targeting steam and making sense. We still wanted steam, however, so now the "play card" resource is steam instead of speed. Speed is gone, which is fine with me--I called it "actions" probably 80% of the time, anyway. Since we're calling it money now, we changed the way that it operates slightly: when you spend money, you don't get it back, and you now have cards that are "contracts"-- permanents that give you additional money per turn. Players can choose to draw a card or get a one-time pay at the end of their turn.

There were a few things that ended up working very well, like the doom-track method of attacks and villain draws. We were both stoked that that turned out just as well as we anticipated, and we're looking forward to really making some interesting things happen with it.

Developing Game Wrappers

I cleaned out and organized all my miscellaneous files from my computer and external drive this past week, which required an additional hard drive. As it turns out, the hard drive I used had a working copy of Sins of a Solar Empire on it--a deceptively time-consuming and surprisingly addicting RTS game from 2008. Anywhere from 90 to 130% of my freetime this week has gone towards playing that, so I'll probably make a couple posts in a row, here.

 I'm really excited about the progress of several of the games I'm working on, and I'll start with 3colors. I consider myself to be a pretty talented game designer in most things, and an absolutely abysmal designer when it comes to creating game wrappers. 3colors was no exception, as I was honestly considering having the game play out with just the colored circles that I made from the Youtube video.

Even though I know that I would have been happy with that game, base mechanics with no story are not what make excellent games. They make excellent prototypes, and that's what I had. In my mind, the prototype involved matching things in your bank to things on the board, so I tried for quite some time to think of a wrapper involving that. What kinds of things could be in the bank that would make sense to match on the board? Food? Monsters? Animals? AngryBirds? At the time, I had quite the list of things of things that one could match up, but none of them seemed to work because they would all be randomized in the bank. If your foods were peanut butter, jelly, and bread, then what happens when you have bacon, lettuce, and tomato? Would you end up with peanut butter and bacon (potentially delicious)?

Instead of having sets of things that match, I moved on to random things, like monsters or animals. If these groups of items are random, however, why are you matching them? Why are you matching 2 dogs and a cat? Thus, my problem: going towards sets of things wouldn't work because they would mis-match in the randomizer, and going towards random things wouldn't work because it would never make sense why you were matching totally random things.

I was stuck, so I talked with Corrinne Lewis--one of the EAE advisors--about what kinds of wrappers I could develop for the game. Her approach was excellent, and the core concept of this blog post: Instead of trying to think of a wrapper for the mechanic that I couldn't get to work, try to find a different core aspect of the game to base a wrapper on. Good games tell a story, she said, and you need to find a wrapper that explains the mechanics so that people will understand your game faster than handing them the prototype.

What is the core mechanic of your game that you want to use a wrapper to convey? Clearly, matching isn't working, so she suggested exploring the "capture" aspect of the game. What kinds of things are people used to capturing? Territories, like in Risk? Companies, like in Acquire? What about capturing ships? Now you're playing as a pirate, trying to capture all the ships on the "ocean", and each ship has a different sail that changes when you double capture it. Excellent.

I shared this with the team, and Derek Higgs--one of our engineers--suggested using Tiki masks that flipped upside down when you captured or un-captured them. This led to what our game is now by showing a new core mechanic: toggling a grid of points. I'd never seen this because I went too narrow in my initial design by calling this action a "capture", which limited the design space of what we can tell a story about. Now that we were thinking about flipping things back and forth, it was a short walk to come to flipping different colored turtles from off their backs. Its satisfying, its something that everyone can relate to, and most importantly, its a wrapper that enables people to understand the mechanics of our game far faster than anything else could.

I'm excited because its the best wrapper-creation process I've been a part of, but also excited from the lessons that I learned from it:

1. Explore several different core mechanics of your game to develop a wrapper for, don't get stuck on one that isn't working, and
2. While making a prototype, always describe things in the most generic way possible. Un-necessarily defining things limits the creative ideas of how to describe the game later on.