Motivation, Milestones and Gamification

One of the things I love most about being an indie game developer is that I have no boss, and complete creative freedom. However, at the same time, being my own boss means that there's no one to push me or motivate me. There's no one to force me to crunch, and no one to stop me from taking a day off. While there's a lot of flexibility in that, it is also very dangerous, as sometimes the crunching, focus and motivation that traditional work environments offer are necessary to push through and finish a game. This post will be about how indie developers can motivate themselves, and finish games without having a boss keeping an eye on them.

Most indie developers I know think that all they need to motivate themselves is the desire to create the games, and the potential money they may earn from the game. However, both of these motivators are fairly weak. The desire to create will certainly motivate you to start a new game project, but it often fizzles during extended game development periods, and can even distract from your current project by enticing you with a new game idea while in the middle of your current one. The desire to create alone isn't enough to actually finish a game unless it is a short-term project. Potential money, as well, can be a very weak motivator - there is no guarantee you will get that money, and it sometimes seems so far off, so distant, that it doesn't really motivate you at all. This is true for anything that only motivates you once the game is released (enjoying others playing your game, fame, whatever).

As game developers, we know a lot about motivation, and how it impacts people. We design games which motivate players to progress step by step until they reach the conclusion of the game. However, we don't often seem to take that same knowledge and apply it to ourselves. Have you ever seen a game where the only goal is to defeat a single boss, and the entire game the player must grind with no direction until they are strong enough to eventually defeat that boss? That's essentially what we are doing to ourselves. We start the game really excited, saying "we're going to beat that boss, and it's going to be awesome!" But then, we have to grind a long time without any further rewards until we are strong enough to actually beat that boss. At times, the grinding may seem endless, futile, like the goal is barely getting closer at all. We might get tired and bored of doing the same old thing, and perhaps have a strong desire to switch to another project. If those other games are similar, we may never complete any games, and never beat any "bosses." This is a cycle that I've seen many game developers (myself included) get trapped in, and it's tough, especially if you are doing game development as a hobby and you are constantly distracted by your regular job as well.

One solution, of course, is to make SMALL games. Whether it be a game jam, or One Game A Month, if the game's development cycle is short enough that the initial desire to create keeps you motivated until the end, then you have your motivation. However, a lot of game developers, myself included, have big ideas that we want to make that just can't be completed in a short time frame. So, how can we, as our own bosses, motivate ourselves (and our teams) over long development cycles?

The solution is to break up the game development into smaller milestones. Each milestone is close enough that you feel motivated to push towards it, and completing each milestone must have a reward large enough to keep you going. We do this all the time in our game designs - instead of just grinding until you are powerful enough to defeat the boss, we add in quests and subquests, each giving you experience and moving you closer to defeating the one big boss, but also giving you rewards and incentives to continue along the way. Gamification is one of those buzzing words you hear a lot nowadays, and that's because by applying these principles of game development to real world situations, we can incentives and motivate ourselves and others. If you're the boss, there's nothing stopping you from gamifying your workplace.

So, what should these milestones be, and what rewards could they have? This depends on yourself, and your game, but typically, you want your milestones to be meaningful and tangible. Obviously, there are big milestones with prototypes, alpha builds, etc, but you can design tangible milestones for "hidden" code as well. Take AI for example, you could code a simple simulation showing it controlling dots instead of actual characters. This requires a little time to code, but doesn't require all of the game assets to be complete, and gives you a meaningful, tangible (and debuggable) milestone. As a very visual person, being able to see on the screen the AI algorithm or even the networking algorithm in action (simulating latency and multiple connections) makes me feel like I really accomplished something, and comes with the added bonus of revealing that "hidden" code and allowing you to tweak and debug it if necessary. By having meaningful milestones, you'll get a feeling of accomplishment, and by having tangible milestones, you'll get a feeling of progress, both of which are important to motivation.

I'm a strong believer in positive reinforcement, so to strengthen the effect of the milestones, you should add a reward (beyond the feeling of accomplishment). The reward depends on what you like to do, and what is reasonable. One reward I like is just a break, or doing something I've been wanting to do but have been too busy to do. This turns breaks from laziness that can strike at any time into a reward that you have to EARN. Money, of course is a good reward as well, if you have money you can dole out to yourself and your team. Work itself can be a reward as well - remember, we ENJOY making games, so perhaps make a reward for finishing something you don't enjoy to make (for me, the UI), with something you do enjoy to make (for me, rendering and procedural content). This spaces out the parts you don't like working on, and gives you a reward that is also productive.

My point here is that when you design the game, also design the game plan. What are your milestones and rewards, how will you keep track of progress and keep motivation high while working on the game? And, you can be fun and creative with this process as well, it's a lot like making a game. Making games should be fun, we just need to stay focused, motivated and passionate about the game throughout the entire development process, and breaking it up into manageable chunks makes it a lot easier to do that.

Where's My March 1GAM?

So, it is April 1st, past the deadline to have released my March One Game A Month, and yet I have only released this website: http://fancyfishgames.com/TripThroughTime/ , and there is no playable version of the game available anywhere. It's about a robot from a post-apocalyptic era who is sent back in time to observe the nature of humans and decide whether or not they are worth bringing back to life.

The trailer of the game, the only footage that I have released.

I'm sure you're all very patient, and are eagerly awaiting while I "look into one release option," but I regret to inform you that this has all been an April Fool's joke in bad taste. I'm not actually looking into release options at all, and have decided, aside from my friends and family, that no one should be able to play "Trip Through Time."

The world is not ready for this game.

This decision didn't come easily, as I really do want to get my games out there. However, I just feel that the world is not ready for this game. You see, in the development of this game, I wanted to have the robot travel all the way back to his "present," the year 397 A.H. (after humans). But, I am also a strong believer that games have to be realistic, and I just didn't know what the future era should look like, let alone the post-apocalyptic era. So there was only one reasonable way for me to add those eras: I invented a time machine, and both myself and my wife (Natalie Maletz, who created the art for the game) traveled into the future to gather reference material.

That's like spoiling the ending of a good book.

Now, the game and it's art was meant to only be loosely based off of the future, however, as people play-tested the game, we realized that the game was actually revealing too much of what we had seen, and I just can't in clear conscience do that to the world. That's like spoiling the ending of a good book.

So, I apologize to all followers and everyone who was excited about playing the game, but I wont be releasing it to the public. Thank you for all your interest, and please look forward to my April 1GAM. I have learned a lot from this game, and it is clear to me now that some things are best left unknown.