[This is a guest post by James Bowling, from Last Level Games]

For the last 3 or 4 months I’ve been working on a start-up gaming company, Last Level Games. I’ve been tackling server side development, while a friend manages the client side. We both do this outside of our day jobs. We’ll have our first game looking for release in about a month, and another project we’re keen to get back on very soon.

What I’d like to share with you are my experiences I’ve had maintaining self-motivation to keep on working on an unpaid project at the expense of free time and much needed sleep, while also maintaining healthy social ties around me. Finding that work-work-life balance required to make a transition to a full-time indie studio. I don’t pretend this will be relevant to everyone, these are just my experiences so far – and we’re most certainly not there yet, but I can see we are on the way. For a little background of the kind of worth ethic I have, I’m one of these don’t-normally-apply-myself kinda guys. I’m the B student that probably could have done better if I did a little more work, but I was always content with the above average grades. So, how have I managed to maintain motivation the last few months? How have I managed to keep being productive when all I wanted to do was curl up in bed with a DS? These are some of the strategies I’ve been using.

Accept that with the good, comes plenty of bad.

I’m a developer because I like developing software. I like designing games because I think I have a knack for game design. But along with all that stimulating sitting around thinking about crafting a fun user experience comes a truckload of boring, tedious and difficult work, especially if you’re branching into new and unfamiliar fields like we are. You will be bashing your head against third party libraries, user interfaces and uninteresting glue. But I don’t really approach this as something I just need to just “suck up”. I think of it as part of the whole game developer package. Embrace the difficulties – this is what it is to be a game developer. It’s not all sunshine and rainbows, so when I’m having to force myself to sit down to do something dull, I’m doing it right. I also make sure to alternate where I can. Swap between the interesting and mundane tasks as I complete them.

Which brings me on to…

Know when to not work.

I also need to keep in mind when I just shouldn’t bother working. Energy is indeed a finite resource and taking breaks is important, especially with this project not being my day job. Avoid burn out. It’s also worth using this time to make sure I keep up with friends and family. While I definitely don’t spend as much time with my social circle as I’d like to, I still take the time to see them. Quite often I set a night to code, and if a friend tries to organise something on that night I tell them I’m busy. Same goes with the reverse. If I commit to something socially, I don’t cancel it for work. I know if I don’t take the time to unwind, I’ll burn out and lose motivation on the project.

If they can do it, so can I.

This isn’t being arrogant, this is merely a reality. The successful game developers out there mostly likely aren’t leaps and bounds better at their craft than me, they just had the motivation to see it through. I use their success to visualise my own. With that in mind I find it easier to get myself in front of Visual Studio and getting in the few nights here and there required to get these things done. Part of what motivates me is seeing the success of people around me, and knowing I have the skill set to achieve what they have. It’s not a case of thinking I’m better than someone, it’s a case of respecting my own abilities.

Don’t lose sight of the light at the end of the tunnel.

I find it very difficult to maintain motivation for a project I don’t believe will go anywhere. It’s important that I can see an end to what I’m doing. This is one of the reasons I want to get into indie development. I want to feel like I’m working towards a tangible and realisable goal. I stay focused on what’s good in our project, and have trust in our ability to work out the kinks as we find them. I accept there will be plenty of design bumps on the way, but as I mentioned in my first point – that’s part of the whole game development package. I try not to beat myself up too much when we hit a stumbling block.

That’s just a few strategies I use to maintain focus and motivation.

What are some of the methods you use to stay productive?

The problem

I remember a few short years ago when many designers hated Popcap games and their simple gameplay.  With the proliferation of Facebook games, many of these designers would give anything to be back in the days when Popcap was their biggest concern.  I’ve listened to many designers complaints about Facebook games and there is a common thread through most of the discussions:

There is not enough depth or emergence in Facebook games

Another way of putting this is that there are very few operative and resultant actions the player can perform.  What do I mean by operative and resultant actions?  Jesse Schell used these terms in his book of lenses.  Operative actions are the base actions the player can take.  For example in Bejewelled this would be “swapping the place of a gem”.  Resultant actions on the other hand are higher-level actions that are only meaningful in the larger picture of the game.  They are how the player uses the operational actions to achieve their goal.  In bejewelled this would be equivalent to “match 4 or more gems to receive a special gem”.

A case study: “Plants vs Zombies” and “Treasure Isle”

Let’s look at two casual games to see a correlation between the actions and the depth of gameplay.  Plants vs Zombies (PvZ) has very few operational actions, simply selecting a plant and placing it on the game field.  However it has a myriad of resultant actions that build upon this simple foundation.  Plants interact in special ways that add emergence and depth (e.g. Torchwood doubles the damage of any peas that go through it).  Rewards are given to the player (the death of more zombies) for discovering these resultant actions.

Treasure Isle on the other hand has few operational actions and few resultant actions.  Players walk around the island digging up treasure.  There is very little emergence or interaction that grows out of these operational actions.  Rewards are given to the player for the operational actions.  Players are not encouraged to dig deeper into the game but instead to simply open their wallets so they can continue to get the next reward for finding the next piece of treasure.

The Hypothesis

Both Popcap and Zynga games are popular.  It is becoming apparent that much of Zynga, and other Facebook games, success is from the viral nature of Facebook rather than the quality of the game.  My hypothesis is that bringing the depth and emergence of a game like PvZ to Facebook would see more success than the current round of shallow games we’re seeing.  A game like PvZ would obviously need to be changed to fit with the social nature of Facebook, but the key is that giving a deeper player experience, as well as the means for virality is going to see greater success.

The Solution

I’ve looked at a number of casual games and the consistent thread between the successful games that have some depth is to:

Keep the operational actions low while maximizing resultant actions

The fewer operational actions a game has, the larger the market it can reach.  While the more resultant actions a game has, the deeper the game experience.  This fits in with the age old adage of “easy to play, difficult to master”.  Players want to pick up a game quickly and not have to learn controls.  This is perfect for Facebook games as they are primarily played with a mouse and one button.  Resultant actions need to be layered on top of this simple set of operations actions in the best ratio possible.

Why the need to change?

With the huge success Facebook games have been seeing over the past years, why am I talking about changing the formula?  The problem is that all the big Facebook games are seeing a drop in numbers.  The biggest games are losing millions of players per month!  To put that into perspective, many PC and console games are lucky to reach these kinds of numbers.

Why are they dropping off? The main reason is that Facebook has limited the ability for these games to send spam to the player’s friends.  A big part of their success is the viral nature of Facebook.  The game is more about convincing you to spam your friends than about convincing you that you’re having fun.  These games need to get more depth quickly, or they will disappear as quickly as they grew.

An analogy for this is that terrible restaurant in the food court of the local mall.  The food is terrible and however so many people go through the mall that even if people only go once or twice the restaurant will still always be full.  What happens if suddenly they get moved to the back part of the mall where few people visit?  They either make better food, or go out of business.

Conclusion

What are your thoughts on the current wave of casual games?  Do you think it’s possible to add more depth to these games without comprising the casual nature of them?  Is the Facebook game market already dying or is it just in need of some deeper games to bring it back?

Interesting Choices

If all games have choices, what makes Choice Driven Design so different?  The main difference is that the developers should forget about all parts of the game that don’t involve or affect a player choice.  Rather than focussing on the features being added to the game, developers should focus on the choices they are adding.

The reasoning behind this is that if the player isn’t making a choice about a part of the game, it’s only a secondary concern for the designer.  That isn’t to say that these other parts are unimportant, they simply have a lower importance than (and serve as a distraction from) the core game play that should be focussed on first.

To give a concrete example of this, let’s look at Spore, specifically the Civilization stage.  The decisions that are made in this stage include:

1. Which of 3 types of units to build
2. Which buildings to build and where to place them
3. Where to move units
4. What to do if you attack an enemy base

That’s it.  Anything outside of this should be ignored when working on the core design of the game and implementing a prototype.  There are two main advantages to this technique:

1. Less design time is wasted on the extraneous parts of the design focussing the designers time to the most important parts of the game
2. Prototype’s can rapidly be created that ignore any part of the game that doesn’t have a direct impact on the player’s choices in the game.  Leading to far smaller and more rapidly created prototypes to determine how fun the game is.

What is a Fun Choice

Ultimately, we want the player to be making “fun” choices.  Fun is quite a nebulous concept and there are many different ways for a choice to be fun.  Below is a list of points that help to make a choice more fun.

• One that isn’t obvious
• Something that requires some thought by the player
• Something the player must commit to
• Where there are many options to choose from
• Or there are no “good” options and so it’s choosing the best of a bad set of options
• Where different players will often choose different options
• Where the same options are presented in different situations, leading to a different choice
• Where there is no perfect choice
• Where one choice effects later choices

Choice Automation

One key concept in Choice Driven Design is the automation of obvious or repetitive choices.  If you find that the same choice is always being made for a given situation, or the same choice is occurring repeatedly then don’t bother the player with it.  These choices should be automated by the game as there’s no reason for the player to make the choice.  You can inform the user that the choice has been made so in the rare case that they want to make a different choice they can.

A simple example of this in every day life is the “Don’t Ask Me Again” message in Windows.  It is extremely annoying to be asked the same thing over and over if you are always answering the same way.  You can always go into the options and turn this automated answer off, but 99% of the time you will want it to perform the action for you.

During this critical analysis of the choices in a game you need to be bold and be prepared to remove or automate obvious and repetitive choices.  By removing or automating the choice, you will quickly see a gap forming and then have the option to replace it with a more interesting choice.

How to do it!

Below is the recommended way of developing a game using Choice Driven Design.

Break the game down into its various sections and complete the following:

1. Write down all the choices the player must make.
2. Sit and play through the game in your head.  Step through the list of choices and think about how interesting and fun they are.
3. Sit around the table and “play out” the game based solely on the choices.
   1. Ask the player questions based on the choices they must make and act as if they are playing the game, continuing to ask questions based on their previous ones.
   2. This will give you an idea of how “fun” the choices they make are, how repetitive they are and whether there are enough.
4. Once you have solidified the design, build a prototype which again only includes the choices the player makes.  Ignore everything that doesn’t involve a player choice.  This prototype should basically be a computerized version of the game in steps 3.
5. Make small iterations of step 4 until you are happy with how fun the prototype feels.  If you are not successful look at moving back to step 1 and redesigning the set of choices from the ground up.
6. Complete the rest of the game to bring it up to an acceptable standard for release.

Once all sections are complete you can look at the game as a whole and determine if there is any part of the game that is weaker than the others.  By focussing on choices only, it is far easier to get a picture of the whole game at an earlier stage in development.

Depending on the game type, these steps may become quite complex.  It may seem like a waste of time to perform these actions, however finding any problems before step 6 will greatly reduce the time required to make changes.  During typical development it can be month’s before a playable prototype is ready with only a small section of the game experience completed.  Using Choice Driven Design, the entire core gameplay can be developed in a far shorter time leading to more agility and freedom in making changes.

Conclusion

This sums up a basic overview of Choice Driven Design for games.  It’s still a work in progress so I encourage people’s comments and thoughts.  By focussing on the key choices made by a player we should begin to see deeper and more enjoyable games while minimizing risk in the development.

[1] Rollings & Morris 2000, p. 38