So I should probably brush the dust off of this as it's certainly been a while.
A curious thing happened at the office the other day and it got me thinking. I looked around the room and everyone was motivated. After slowly chipping away for months, the team had hit a period of reinvigoration. I took a glance at the latest build and realised that it wasn't any major feature implementation or bug fix that had resulted in this; it was a menu.
In game development there are typically two ways to demonstrate a project to someone; you load into a specific level or you load into the game from the beginning. While loading into a level directly is fast, convenient and the easiest way to check a specific feature it can actually have a really negative effect after a while because you stop thinking of the project as a whole but rather, a series of features. When your daily grind involves you looking at the same issue in isolation it's easy to forget how much other people are achieving around you and what it is you're actually working towards.
<TODO IMAGE>
This isn't the first time something like this has struck me as having a profound effect on the in-house team. Before this it was another small touch: camera shakes. Camera shakes can be brought in, often with incredible subtlety, to really enhance a scene. They make everything carry just a little more weight and add a nice level of polish to a product in even the earliest of stages. In our case it was the kick of a machine gun or the screen shaking when a T-Rex roars at you. These polishing effects help people catch brief glimpses of what it is you're ultimately working towards which is encouraging.
Cohesion in the actual design aside, at its core the benefit of these design decisions can be abstracted into basic principles that can help in project planning. Let me preface this with the obvious; no matter what you will have major hurdles in place. The hurdles are going to be grinding and are often the core features of the game you intend to develop. Unfortunately, large hurdle tasks often take relatively long period of time. B.F. Skinner once developed a simple mechanism to study operant and classical conditioning called a Skinner Box. I'm sure psych students would cringe at my over simplification, but a Skinner Box essentially uses reinforcement (such as giving treats) and punishment (such as electrocution*) to encourage behaviour. What I've always found most interesting about the Skinner Box is how the extinction process works. If you have a lever for a rat to pull and every time it pulls the lever it's given a pellet of food then eventually when it pulls the lever and is not given a treat it will only pull a few more times before giving up. If you have a lever that rarely gives out food then the rat will often not even realise that pulling the lever gives rewards. If, however, the rat has a high likelihood of being given a pellet of food for pulling the lever, but isn't always given a reward, it will pull the lever for much longer.
<TODO Image>
Many have discussed the importance of operant conditioning in solid game design, whether deliberate or not, however every now and then it becomes painfully obvious just how important it is. If your team is focussed exclusively on delivering the major features over an extended period of time without the incorporation of smaller, intermittent rewards they will almost certainly lose motivation. I'm not saying they won't come into work every day. I'm talking about losing the spirit that game development depends on. If people are getting paid and they don't completely hate their jobs they'll keep turning up, but a brainstorming session won't be the same. I can't phrase this any way that doesn't come across like buzz words, but what I'm getting at is the need for invigoration over motivation so that you have a team that aren't looking to just release a product, but a team looking to release the best possible product.
Much like the rat that will keep going because he’s waiting for a pellet of food, dispersing smaller jobs throughout your project development can help team members get that win. On previous projects I’ve watched our guys break and it’s horrible to see. A studio enforcing crunch times disgusts me to my core, and I’m not trying to use any Jedi mind tricks to get my staff to pull these, but I’ve seen what a motivated and invigorated team member can do. A motivated and invigorated team member will attack the hard tasks for a little longer if they have had a few wins where as their counterpart is more likely to break. If you have those smaller tasks, with tangible outcomes, interspersed throughout your development then you’re giving your team those wins and you’re slowing that process of extinction that can lead to people breaking later.
There is a saying that “he is able who thinks he is able” and there is a lot of truth in that. Amidst the large hurdles set aside tasks with smaller goals but noticeable impacts. If you can, try and spread them between team members. Aside from a team that’s in a better state of mind you also end up with a product with polish earlier on. It won’t necessarily be feature complete as quickly but the features that are in there will be more presentable and you’re less likely to witness your people lose the spark that makes independent game development great.
*Please note: I do not intend to electrocute my team. Often. Except Troy.
