Talk delivered to a full room of producery types, and I feel really good 
It went down surprisingly well.
Producers! You are my people! (That’s why I married the best one I could find 
)
Hi there, #AltDevBlogADay denizens! I’m Simon Cooke, and this post is all about how to budget your game in preparation for pitching to a studio. How do I know anything about this? Well… Back in 2008 I was incredibly lucky to join X-Ray Kid Studios (a group of very talented people involved in the creation of Google Lively, and with a history in comic books, animation and video games going back decades) as their Director of Engineering. As time went on, I also shifted sideways into the role of Business Development Manager, where I helped take us from concept to pitching a number of game titles to several publishers. Unfortunately we ran out of steam before we could sign a deal, but I learned a lot along the way. (X-Ray Kid is still around though – it just morphed). (more...)
This one’s a quickie.
There are stupid questions – you know, things that with a tiny bit of work, you could get the answer to yourself. (The origin, no doubt, of the site Let Me Google That For You). Or questions such as… if I stick a fork in this light socket, will I get electrocuted? (Answer: yes).
No-one wants to look stupid. In fact, people will take great pains to avoid looking stupid. This is a really bad idea though – because it can get in the way of real progress. There are plenty of questions which could be answered twice as fast if you just let your ego go, and spoke up instead. This is the basis of putting together an egoless team – something practiced at Surreal, and at X-Ray Kid; the idea is to reduce that barrier, by encouraging people to talk and ask questions. If you get stuck? Go talk to someone! People get stuck all the time – there’s no excuse for sitting there and being stuck when you could fix the problem in five minutes instead of three days by going and talking to a peer – no matter how silly or stupid it makes you feel.
In fact, you’ll feel less stupid when you realize that you could have spent hours on it, and instead you found out the answer much quicker.
Now, there’s another kind of question which is very similar to the “stupid” question, but subtly different.
That’s the naive question.
Naive questions are great. You should ask them all the time. A lot of people get stuck thinking about the nitty-gritty details of a problem. While a naive question looks silly at first (and a good percentage of the time they are silly in reality), about 1 in 5 times, that question will make people stop, and suddenly reassess their assumptions.
It’s like a laser-guided can-opener that lets you jump straight into the middle of a problem. Worst case? Your assumptions get overturned. Best case? All of a sudden you’ve laid bare a fundamental issue.
It’s hard to figure out which is which – a stupid question or a naive question – so err on the side of asking anyway. It’s worth it, and allows you to perform miracles.
(In short, naive questions challenge assumptions and allow you to build models of systems. Do it often, do it early).
(more...)
The Surreal Gameplay Programming Team's Friday Meeting, July 2006. From Left to Right; John Cuyle, Lance Dyson, Matt Lauritzen, Joe "The Robot" Sola. Sola's Mom could not be reached for comment.
So just how do you get a team together, keep them working together, keep tensions low during high-crunch periods of time, and just generally make sure they rock the house?
I've got a secret little trick that I figured out while I was managing the Gameplay Programming team at Surreal. (Actually, I discovered some of this while managing the Tools Team, but I refined and codified it when I moved to Gameplay).
We moved to an Agile project management method (kind of based on Scrum) at Surreal in October 2005. Now, people have varying thoughts as to whether or not it was successful or not - but that's for another post - but the upshot of it was that we ended up having two Gameplay team stand-up meetings a week.
One of the things I did early on after moving to the Gameplay team - given that we had two meetings a week - was to look at exactly what those meetings were doing for the team. It ends up that really, the meetings had several purposes:
Now, 1) we were already doing via email, and 2) was good, but kind of out of scope for a 15 minute stand-up meeting (it'd expand the meeting for one). 3) seemed like a great thing to me, but needed more flexibility.
By this point I was already doing 1 on 1's with each team member, once a week; these were working well, and mainly I was using them to allow for private conversation about things that were bugging each team member, and to resolve inter-personnel issues, find out what was blocking them and so on.
And of course, Summer hit. And we were in crunch. Again. (We crunched all the way through the previous summer on Suffering: Ties That Bind... I was working 14 hours days on weekdays, and 8 hour days - sometimes longer - on weekends for three months).
Now, Summer in Seattle is a gorgeous time. After spending all winter under oppressive gray skies, everything flips and Seattle becomes one of the most gorgeous places on the planet.
I'd be damned if I was going to miss it again. So I decided to start a new practice.
Summer at Golden Gardens in Seattle - Seriously, it's what makes the rain worthwhile.
The Friday Gameplay Team Meeting was something I instituted at Surreal, and it works great for keeping your team together, focused and happy. It's now an institution at Surreal - even though I've not managed that team for over a year, which shows some of its staying power.
Instead of two Scrum meetings a week, I cut it down to one formal meeting, and one informal meeting (where I'd take notes if necessary; later we modified this so that notes weren't necessary at these meetings - I'll cover that later). The informal meeting was at 2pm on Friday afternoon, downstairs on the grass field outside the building. (The grass field no longer exists; which is ok, because we're no longer at that building). People were encouraged to bring beer (Friday at Surreal is Beer & Pizza friday). The meeting itself? 30 to 60 minutes long.
Over time, the meetings evolved to include a short soccer kickaround during the summer and early fall. These stopped at the new building because there's no field nearby, so we just meet out on the deck which overlooks the Puget Sound. The beer's still there though.
People swap notes and kick around ideas (and, I guess, soccer balls). They talk about the movies they're going to see, what's cool on TV, cool games they're playing (including ours), maybe a bit of what they're working on, and life in general. There's lots of joking around, a little bit of teasing, and usually very animated conversation. Some people (with nasty bad habits... er... like me) smoke.
It all seems very much like just an organized excuse to goof off. That's because it is. But if you dig a little deeper and look under the hood, there's some very specific reasons why I do it this way.
This isn't actually a Gameplay team meeting - but it's what one looks like in the new building (it's held right here on the deck, and usually there's that many people there. And the two people on the left (Darci Morales, Surreal Producer, back to the camera, Matt Lauritzen, Gameplay Programmer Extraordinaire, in shades) are usually there too. This photo is actually from the Surreal 2007 4th of July BBQ on the deck at work, where we got fantastic views of the fireworks show.
There are several key reasons for holding a meeting this way.
Games development is a pretty high stress environment, and I wanted to make sure that my team had a place that was safely away from potentially prying ears and eyes of their coworkers, so that they could feel comfortable discussing anything they wanted to - including the things that other people in the company are doing that are bugging them.
This is normally a 1 on 1 subject, but this also allows the whole team to voice what's derailing them - without fear of retribution. (And if you institute something like this, it's important that there will not be retribution. Handle the problem there and then by explaining the other side of the issue - as their manager you should understand the other side of the issue; if you don't, you're not doing your job - or by promising them that you'll look into it. Don't bear grudges. Don't throw blame. Don't be quick to judge. If people are bitching about something, there's something to it).
Related to #1... unlike regular meetings, this meeting - and I told my team this going into it, and repeated it regularly - is meant to be a "stitch and bitch". And yes, they should. It's healthy. But keep it in check, and address misconceptions where you can.
For example, one issue that comes up regularly near the ends of projects is the fact that programmers don't like getting bugs filed against them for content issues. They hate having to help Designers fix content that (they feel) should have been set up correctly in the first place. The job of the lead in this situation is to remind them that hey - guess what - designers aren't programmers. Part of your job as a programmer on a game team is to help the designers get their job done - and occasionally, that means holding their hands. Because god knows, they get to deal with our bugs all the time ;-)
There's a mental gear shift that happens when you get a team out of the office. This is why Marketing & Sales guys get to have expensive off-site retreats in ski lodges all the time. Well, no one pays for the geeks to ever do that (or if they do it's rare, or reserved for upper management), so this is the closest thing you can do without having to explain it to the Finance guys.
When you're out of the office, you can let your guard down, and let politics go by the wayside a little. You can be more objective about your work, and you can be more creative because you're removed from the issue. The creativity part is a big one - it gets your team's juices flowing.
The moment the conversation turns to the game you're working on - and it will, because most of the team spends nearly every waking moment working on it or thinking about it; you just can't turn that kind of passion off - you're going to get a torrent of ideas that will blow you away.
Take a notepad with you - there's gold in there.
Yep, you knew it was coming. Part of the idea of goofing off is to goof off. Just a little bit. It's Friday, people are already thinking about the weekend anyway. This just codifies it as something that's okay to do.
Why would you want people to goof off during work hours?
This is a team that's going to go through hell and back for you. They're going to put off doing their taxes, their laundry, and their utility bills because they're at work at 9pm on a Saturday night trying to get the game out for its next milestone. They need to work together as a cohesive unit. Everyone needs to know what everyone else is working one. You need to know who's stressed out the most, and who's got a low workload - and this is a way of letting that work auto-balance itself. People will and do offer to help each other out during these meetings. But they'll only do that if they trust, respect and are friends with each other. (You can of course force it yourself and shuffle the workload for them, and you should do that as well, but this way they all feel like they're all in it together).
Think of it like being in the military. You're the Sergeant of your platoon. They're your men. What does a platoon do during downtime? They hang out. They build camaraderie. They become friends, and turn into a close-knit, well oiled fighting machine. And that's all you can ask from a team - have that, and you've got the best team in the world.
But you're not in the military, so they're going to go home after work. So do it at work instead. And give them a place to relax while at work - seeing each other day in day out, it's something your team needs. It's therapeutic.
What do you need for a successful Friday Meeting like this?
The Friday Meeting (or Goof Off Meeting) is an excellent tool for building team morale and cohesion. It's also great for getting information on the team's status in a way that isn't formalized, allowing you to fix problems before they become real issues.
It's now a part of Surreal tradition (at least for the Gameplay team), and has been successful enough that when programmers move to other teams, it's one of the things they miss the most about the team. That's ok - we let them come along to the meeting as well if they have time. In my ideal world all of the teams would have one meeting a week that was like this - it really does help.
Next time I'll talk about team morale, and I'll explain how I try to show the team that I appreciate their efforts.
(more...)I've just gotten to a good place at work today. Finally, a long project is approaching its conclusion. So I've been thinking about what I know about project management, and working from my experience on tasks like this (and watching others tackle them) I came to some conclusions about how this kind of process works.
What is a broad task? Or a narrow one?
A broad task is one that cannot be easily broken down into pieces to attack. That's not to say you can't try; it's just that there are large numbers of unknowns at the start of the process.
A narrow task is one that is easily defined, narrow in scope (ie. tackles a very specific, small problem), and that is reasonably accurate to estimate.
Examples of broad tasks include any kind of integration work, any kind of porting work from one platform to another, and any time you need to build a new framework.
Examples of narrow tasks are those that could be described as "small features". For example, adding the ability to drop down a color-picker and select a color in an editor would be a narrow task. Adding the ability to specify that a mesh uses 16-bit floating point values for vertex positions instead of 32-bit floating point values would also be a narrow task.
The Graph of Progress over Time
Here is a graph of what a broad task looks like to the engineer doing it, and to the outside world, in terms of progress made. It's slightly scary, but that's ok, we're going to go through it in detail.
We're focusing here on the experience of the engineer themselves (because it's important to understand what they're going through as they do the work in question), and the experience of their managers/investors... the management layer which has a strong interest in getting the task done, but might not care quite so in-depth about how it's achieved. Basically, the people with financial responsibility for the work. The ones who have to explain to investors what's going on - or indeed, the ones who have to go to investors and ask for more money for the project to continue on a regular basis.
Visible Progress
In the above diagram, the yellow body of the graph is the amount of visible progress. This is what everyone else sees - managers, executives, people on other teams - unless you're providing detailed status updates. And by detailed, I mean, showing what you did every single day. It's unfortunate, but perception really is king - you will hang or fly based on what other people can see you doing.
With broad tasks, it's crucial therefore to make sure people know what's going on - they won't understand if you're not making visible progress - all they have to measure you by is the visible progress alone.
Expected Activity
The red dashed line (the straight one, for those of you who are color-blind, and I apologise for my poor color scheme if you are) is the expected amount of progress. It's when this line doesn't match the visible progress that people get ... well... kind of nervous.
In a perfect world, this line is what your output would be. But people aren't machines. Even taking unforseen circumstances (life intruding on work, discovering that the task is a bottomless pit that no one understood until now) into account, no-one ever works like this. Let's ignore the ebb and flow of up and down days, and assume that this line is an average. Even so, the shiny happy engineer will not match this line (unless they're an engineer in the category I like to call Bulldozer). They're human, and there's a stimulus-response thing you have to take into account here.
Either way, for planning purposes (both because you can't really plan any other way, except by padding... and also because they're not the ones doing the work, so they're removed from the immediate situation), this is what management normally expect of their warm bodies.
Actual Activity
This is the green, curvy dashed line. And it's curvy. Boy it's curvy. And it's a little badly drawn (view it more of an emotional line; if I'd done it completely right, it would always slope at least imperceptibly upwards; at worst, it'd be horizontal).
This line is the actual productivity and progress of an engineer on a given broadly scoped task. Why is it shaped like that, you ask? Well, let's break it down.
The Lifecycle of a Broad Task from an Engineer's Perspective
Ramp Up
Any broad task can be pretty reasonably expected to be at least somewhat new to the engineer performing it. A certain amount of book-keeping and surveying has to be done before the engineer can even begin, because you need to figure out where to start, and where you're going.
This part of the curve is a gentle, shallow ramp (far left of the graph). It soon peaks, however, as the work gets going.
Fatigue
Next up is our first dip. Literally, at this point, fatigue sets in on the developer. They've been bashing their head against their desk trying to break the task down into bits and pieces they can manage. They've been working a while, and churning on the problem, but at this point their work provides little gratification. Their own perceived progress level is excessively low compared to the amount of work left on the task - and that worsens the problem, because now they're feeling like they're useless and they still have a huge task ahead of them.
Disheartened, they step off the gas pedal, until either someone steps in and prods them, or they get their own internal second wind. They're in the middle of a death march at this point, and they know it.
First Flush of Success
Hey, what do you know? That curve does turn back up (unless the engineer in question quits - which, if it's a huge task with no end in sight, does happen). Why?
Broad tasks are basically - as far as perceived progress goes - exponential. You're tackling problems all over the place at first, and nothing works. Then, as you keep ploughing on through the problems, you start to gather steam as you get enough of the foundation problems fixed to start tackling specific problems.
The problem with foundation issues is that ultimately, you have to fix them. You can't put them off. If you don't fix them, nothing works. But fix enough of them, and that picture changes. You can start tackling specific problems. And specific problems have a number of great qualities:
Do the problems actually change at all? No, you're actually fixing specific problems the whole time. It's just that they were buried in a sea of other problems, and so they were masked, and you were also thinking about all the other problems as well.
Think of it as a huge party, where hundreds of people are shouting as loudly as they can, and everyone's standing shoulder to shoulder... and not only that, but you're the host, so your responsibility is to go and talk to every single person - even if you can't even squeeze through the crowd. Once you get a little breathing room and throw a bunch of people out, you can start having a normal conversation, and spend some quality time with your guests.
Power Curve
Here's the fun part. OK, so you're starting to thin out the problem "herd" and you've finally hit the point where not only do you know most of the systems you're working on pretty well at this point (ie. you know the mental geography of the problem you're fixing), but the herd is really thinning out. You've reduced the sea of problems down to a few rivers.
And all of a sudden, your activity level goes up, because you're making real progress. At least, you can see that you're making it.
Back to the cocktail party analogy - you're looking for people who need a fresh drink. Much easier to spot when there's only about 10 people in the room, instead of 100. Not only that, but you start noticing similarities between them - maybe three people want martinis, so you can do all of those in one go and save yourself some time.
All of a sudden, you're fixing problems, and systems start to come online. Maybe they don't work yet, but you know what you have to do to get them to work. And you know what? That's a great feeling.
In the Zone
This is the great part. All of a sudden, you've reached the point where you're making regular fast past progress. The brunt of the task has been done, and now you're at a point where you can get a good handle on your work. Here's the cool bit.
This is where the externally visible progress part of the graph takes off like a rocket. You've already slipped out of your funk, and have been grooving on the system for a while now. And with your happiness at the progress you've made, and all the positive feedback that gives, you're on a bit of a high. So your output increases.
But not only that... shortly after this point not only have you nailed enough of the problems to the wall that you're happy about what you're going, and can make targetted attacks, but at this point enough of the foundation work has been laid that the problems that remain aren't completely deadlocking your work from... well... working. All of a sudden whole systems are coming online with a few annoying hangnails here and there where things crash or don't work right. The important thing though is that until this point those systems didn't appear to work at all.
It's like an exponential curve. You've got to get past all of the long flat part until you hit the knee, and then it shoots off like a rocket.
Suddenly, to the outside observer, you're making continued, amazing, daily (or even hourly!) progress. Has anything changed?
Not really. You hit that point personally about a week before, but no one could see what the fuss was about. But the slope of your expected activity curve is now looking mighty shallow compared to the visible progress. Vindication! All those hours where people were wondering if you should be considering an alternative career path are now worth the pain.
And what does that do?
It bumps your activity up even further. Now you're jazzed, because not only can other people see what you knew you'd been doing all along, but the task is now starting to look easy to you. The visible progress curve lags the actual progress curve; at this point, you're down to a cocktail party with about 3 people, and you're serving the coffee and brandy.
Back-Patting
It's inevitable that an engineer after a long, arduous task, is going to indulge in a little back-patting. After all, if this was a race, then they've just been sprinting non-stop - which was a wonderful change of pace after trying to run through the middle of a swamp.
The only issues left to fix are pretty much in two categories - minor ones, which aren't preventing immediate progress, or huge ones which were discovered as the work went along, and have been worked around for now, and need some serious TLC in the near future.
But not right now. Because right now, they need a bit of a rest.
This phase is pretty short. It comes as the amount of issues remaining drops to only one or two. The top of the visible progress power curve is reached right at this point, and begins to slope down again - but now it's pretty much consistent progress going forward.
Refractory Period
Back patting is over, the engineer is a little mentally exhausted still (the low after the high of getting as far as they did). Now starts the ramp back up to regular productivity levels (the expected line now does have true meaning, because presumably we're back to narrow scoped tasks).
If you're going to give them some time off for good behavior, now is the time. They've milked their praise, and that little extra bit of buzz is wearing off. So now that they've done their work, and given their bows to their peers in the audience, let them go off stage gracefully and recoup their physical and mental energy.
And lo and behold... the task is done. It was a rocky road. And some rock stars were discovered.
The Secret
Some people can get past the initial curve by discipline and stiff upper lips alone (the aforementioned Bulldozers).
If you don't want to get fired, fight that visible progress curve by providing regular progress updates - never go "dark".
And the biggest secret of all?
All tasks work like this. Even the little narrow focused ones. It's just that it's over such a short period of time that you might not even notice the ups and downs, and the relative durations of each of the phases will change. About the only time it differs is if you've done something very similar many times before, in which case you might be able to avoid most of the doldrums at the start.
Even big, multiperson tasks work like this too (eg. Entire Projects). Different people in different disciplines might be at different points in the curve, but large projects do work like this.
Project Managers, Lead engineers (call them what you will) try to fight the visibile progress curve with a number of tools - milestones being one of them - for a number of reasons. Executives and financiers don't like it when a project isn't making visible progress at a consistent rate. Potentially more importantly, people can feel the ebb and flow of a project, and this can affect their productivity. Best to keep a good shiny face on things, and continuous displays of concrete progress will do that for the team - and that's good for the health of the team.
The only trick is, don't ever, ever, ever jeopardize the foundation of your project (you know, that long shallow part) solely to satisfy the need for visible progress. Because that will come back and bite you in the ass, big time, as that foundation you skimped on crumbles around you later. If you must muck around with that part, make sure you have a plan, everyone agrees on that plan, and you have a written document which specifies how and when you're going to go back and fix things up. It'll be more painful than doing it right up front, but that's the trade off you make.
More on that in a later post.
(more...)