#completion urgency

[b0tster]

As a "not contract bound" dev who works on a project that you are (I assume) completely in control of, how do you choose the release date and why'd you choose one before finishing the project? Asked not in a "why'd you do that to yourself" way but in a "I wanna understand what's the logical process behind it, maybe it is smart to do it and I wanna know why".

I thought that it'd be logical to first have a finished thing and then say that it'll be released at "date_name_wgenever", instead of setting a certain date and then crunching yourself to fit it. But maybe it helps you somehow to not overwork yourself on the project thinking that if you have all the time in the world, why not add a thing or two, which results in project taking forever to be marked complete, or maybe you just have a pet birthday at that date and wanna make it symbolical lol, idk.

let me be clear here

i am not crunching on bbkart, or any of my projects for that matter

---

now, with that out of the way, time to talk about time frames and productivity. our labor doesnt operate on a linear scale. spending a decade on a game compared to a year will not mean that that game will be 10 times bigger. humans just dont work like that.

something ive picked up over the years is that productivity is like a gas: it will expand to fit the box its put in.

if u give urself infinite time, the gas will just dissipate. but of course if u squeeze it into a release thats too tight, u get an explosion (crunch).

now, im more of a 'find the fun' kinda developer. i make my tools and mechanics based on a loose concept and then decide what the game will be after once i have everything in front of me. in that initial period i do not set a release date, its impossible to predict how a games dev cycle will play out, so i dont bother and just focus on finding whats fun.

once the final game actually starts to take shape, i am capable of making an informed decision on how much labor is needed to finish, and i set an internal date that i do not make public. once im a few months out from that date, i will make an adjustment if neccesary (both bbpsx and kart had their internal date pushed back by a month) and then announce it. that sets it in stone and I have a runway to release.

mark darrah (bioware) talks about something he calls the 'hockey stick', which is the idea that once u get to a certain point, completion urgency kicks in and u get the drive to make the decisions neccesary to finish the game. cut this, reroute focus to that, crunch on this (dont do that last one, ever, but its important to bring up where crunch manifests. some advice: you either cut or you crunch. choose cut).

darrah talks about how to trigger completion urgency (one example is making a demo, be it publically released or exclusive to an event) and the fact of the matter is that a deadline will do it. of course, if completion urgency kicks in too close to the deadline, you get crunch, but if it kicks in earlier u will get things done in a way that doesnt leave permanent damage on your body and mind.

i know this is a very long winded answer, but i hope i was thorough enough to explain the benefits of setting a deadline and how that doesnt always have to end in crunch, like the question implied.

[askagamedev]

Do you think you personally put out better games, better art, under pressure? Some people put out masterpieces that only took the shape they did because they were under harsh constraints, cheifly low dev time. How about you? And is there a dichotomy between comfort and pressure to product quality that you find interesting?

That's an excellent question. You may remember the term [Decision Paralysis] used before on this blog. It's when a decisionmaker is presented with so many choices that they refuse to make (or put off making) a choice out of fear of making a mistake. Decision Paralysis affects everyone, including game developers like me. We can get so wrapped up in finding the perfect solution that we never commit to any one, for fear of that's solution's drawbacks... even though any solution that we commit to will have drawbacks regardless. This lack of commitment has side effects down the line - because we can't commit to something, we're afraid of our work being wasted or thrown out so we won't commit our best effort to it.

As such, pressure like a deadline naturally pushes us towards what I've taken to calling decision commitment - when we are willing to lock down a choice and accept all the benefits and tradeoffs that choice entails, rather than continuing to circle the options and never commit. It is closely related to what Mark Darrah likes to call completion urgency - the pressure to finish what we're working on. Decision commitment is necessary to make actual progress. Without any pressure to commit to a decision, dev teams can (and do) burn indefinite amounts of dev time and resources going in circles and end up with very little to show for it. When we've got a hard deadline, we know we have to buckle down and commit. That pushes us to give our best because we know it won't be wasted.

Lack of (or late) decision commitment really hurts craftsmanship and quality because we aren't actually committing to what we're building. If we are always keeping the back door open to drop whatever it is we're working on and changing our minds on the direction we're going, it always feels like a potential waste to do our best work. The quickest way to burnout is to feel like your work doesn't matter and your effort was wasted. Why polish, optimize, and improve if we're going to go a different way next week and throw this work out? No one likes to feel that way, so we naturally hedge our efforts with the minimum viable effort if we aren't sure whether it will be used.

This is all a long-winded way of saying "Yes, I absolutely do better quality work when I'm under pressure. Since I am confident we're doing this thing, I can give it my all." Without the pressure to deliver, the back door is always open and it's extremely hard to commit to the decision and give my best. If I know that we're absolutely committing to what I'm working on, I will build the best feature and content that I can. I believe that many other devs share this feeling for similar reasons.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

Triggered by a recent announcement at a studio where a friend works: in how many projects have you been asked to work mandatory 10 hour days? How about 6 day weeks? How long did those periods last?

Over the course of my career, I've worked crunch hours (10+ hours a day) on at least ten separate games, two of which never shipped. I worked weekends on nine of them. Some crunch periods were intermittent (crunching near the end of milestones to make the deadline) and others were ongoing due to overly ambitious schedules and constantly-moving goalposts. Crunch period length was determined primarily by the project - some were short (shortest: two week crunch periods and not more than four weeks total over the entire year) and some were long (longest: eight months of sequential crunch leading up to launch).

I like Mark Darrah's perspective on this - crunch often brings completion urgency, which is the feeling that the team must make final decisions and commit to them, rather than second-guessing and redoing work or just not deciding. Significant amounts of work are gated by committing to large decisions - and crunch is one of those things that tends to force commitment. The longer major decisions go without commitment, the more work piles up on the other side of the decision commitment, thus often necessitating crunch to finish. Looking back on all of the games I've worked on, the projects that committed to the big decisions early were the ones that had the least issues with crunch.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ

[askagamedev]

As a solo dev I sometimes find myself "tinkering" on polish or quality of life changes instead of the next big feature, almost like a form of semi-productive procrastination. What can I do to avoid this?

What you’re missing here is the drive to finish what you’ve started. Former Bioware studio head Mark Darrah calls this “completion urgency” in his [recent video about crunch as a video game institution] (I recommend his youtube channel in general, he creates game dev videos from the leadership perspective). Lack of completion urgency is a problem that affects everyone, including many professional devs in our work. There are an awful lot of developers who will happily spend all the time tinkering, tuning, and redesigning forever because the feature or content just isn’t perfect yet (and likely never will be).

I can't tell you what will work for you, but in order to keep myself moving forward and productive I need to set a schedule and stick to it. I estimate a reasonable amount of time for myself to complete the task (which I write down to track progress) and I re-evaluate when I arrive at the scheduled finish time. If the feature needs more time, then I give myself a small extension to get it to that point. However, once I reach that deadline and the feature or content is “good enough” to meet the criteria I set for myself, I force myself to put it down and move on to the next highest priority task. Then, if I want to go back and tinker with it again, I can put a new task at a new priority in the queue. That way I know that I will get back to it when I have already finished the other tasks I’ve identified that are higher priority. It may feel difficult to start with but (like most habits) it becomes easier with repetition and practice. I wish you good luck.

[Join us on Discord] and/or [Support us on Patreon]

The FANTa Project is being rebooted. [What is the FANTa project?]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Frequent Questions: The FAQ