Gamasutra: The Art & Business of Making Gamesspacer
Making videogames without killing yourself
Printer-Friendly VersionPrinter-Friendly Version
arrowPress Releases
April 23, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
Making videogames without killing yourself
by Robert Fearon on 08/04/13 10:39:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

As any regular readers of my blog or followers of my amazingly sweary twitter feed will already be aware, the past couple of years have been marred by illnesses, both my own and the onward march of Mrs B’s collection of them.

Now, aside from the obvious “man, it take its toll” things and the occasional comedic “Rob turns up to give a talk off his face on painkillers, sorry about that but at least he can still draw a mean knob on demand” things, nearly snuffing it two years in a row really makes you sit down and think long and hard about things. And when you make videogames, long and hard about how you make videogames.

Which is why, for THE NEXT VIDEOGAME when working through the documents to fire over to partner in crime of mine Andy, there’s a series of golden rules in place. Because you know the biggest thing I’ve learned over the years? I’ve never met a videogame that’s worth my health. Not a single one. Not even if I get to fulfil my life’s ambition of getting to make or collate an all new Don’t Buy This for the upcoming console gen. Although admittedly, that would make the decision tougher.

They’re fairly simple too. Nothing too grand, right? 

---

Our Golden Rules

Keeping the project at a reasonable level of work is incredibly important.

  • It’s OK us having all the bright ideas in the world but if they impact on getting the game done in a relatively timely fashion, they’re not useful ideas.
  • Anything that can be made an art problem absolutely should be made an art problem. Do we need to rewrite this bit or can we cut, paste and swap a texture around?
  • No videogame is worth killing yourself over. When deciding whether to implement something always ask the simple questions “will trying this push me one step closer to the grave?”, “will it consume my existence?” And “will attempting this make me want to chew my own face off?”, if the answer is yes to any of these, it is not worth it.
  • Keep the scope small but think big within that space. How much can we milk out of not a lot of work? The answer is usually “quite a bit”
  • That said, if you can add a shiny at low personal cost, always add a shiny.
  • Cheat often. As long as something can be maintained within the project, no-one will ever care how hacky or quick and dirty it is. Perfectionism is never the goal, making a good game is. 

---

Now, I’m not even going to pretend that these are good or useful to anyone else, they’re certainly ill fitting for anyone wanting to carry work forward for a long time to come, engine building or perhaps anyone that isn’t me or Andy working together but they’re important for us. I'm sure you can find something that fits your life, your team, your project, y'know?

But without wishing to sound insulting, neither myself or Andy are spring chickens, we both have families and challenging lives at times and living those lives is exhausting enough. Making videogames can’t be crunch, can’t be nose to the grindstone, making videogames has to be around and within our lives not our lives.

That’s how it always should have been anyway. Now I’m just making sure.

That’s why I put these rules in place. They, along with the ethical guidelines of what THE NEXT VIDEOGAME can be, are the most important part of the documents, the most important part of making this game. Because for all the thousands of words on how THE NEXT VIDEOGAME works, what enemies do, how they work and whatever else, we can always make that stuff up as we go along if push comes to shove.

We can’t buy the time in our lives back we hurl down the drain if we don’t make games nicely and comfortably and I don’t want to be sitting here in 20 years time, just before the last vestiges of our western collapse play out, sitting staring out to the sea that wouldn’t have been quite so inland if we’d only paid attention, I don’t want to be sitting here going “shame we threw it all up the wall on making a videogame when we could have been holding the ones we love dear”.

That’d be terrible.

So we make games the best we can but we don’t kill ourselves.

Them’s the rules. They’re non-negotiable.


Related Jobs

Turbine Inc.
Turbine Inc. — Needham, Massachusetts, United States
[04.23.14]

Director, Analytics Platform Development
Linden Lab
Linden Lab — San Francisco, California, United States
[04.23.14]

Sr. Front-end Web Developer
Linden Lab
Linden Lab — San Francisco, California, United States
[04.23.14]

Sr. Software Engineer, Back-end
Linden Lab
Linden Lab — San Francisco, California, United States
[04.23.14]

Lead Engineer






Comments


David Klingler
profile image
"Making video games has to be around and within our lives not our lives."

Good quote. I wish I saw it that way during the development of my first game. Development was pretty much everything, and it took a huge toll on my health which then took a huge toll on the game itself. The game would have been better if I hadn't worked like that, so I always appreciate articles like this one.

Jim Buck
profile image
Another thing is that, if you somehow decide to kill yourself for a project, try to put in perspective as to whether it will really matter 5 years from now. 10 years from now. 15 years from now. Etc, etc. I killed myself on two versions of a well-known (at the time) franchise in the late 90s while working at a well-known company. I am now starting to meet relatively newcomers in the industry that haven't even heard of the franchise, nevermind the particular versions I worked on.

The point being that, right now, it might *feel* like "OMGWTFBBQ, gotta kill ourselves and DO THIS NOW!", but unless it's the supremely rare IP that everyone will know about (and, arguably, I'm not sure such an IP exists.. I've no doubt there are people now in the industry that never heard of Doom, for example; the industry is so big right now with mini-industries [eg. mobile] that no single IP is all-encompassing in being known for more than a handful of years), noone will really care in a few years. The only true exception is if that project you killed yourself on somehow set you up for some longer-term future, such as starting your own company. But that's for a super small percentage of developers, almost like trying to win the lottery.

Jeff Lydell
profile image
"Anything that can be made an art problem absolutely should be made an art problem. Do we need to rewrite this bit or can we cut, paste and swap a texture around?"

This is ultimately saying that art time is worth less than programming time, and not something I would use with the word "absolutely." While it's worth minimizing the number of technical changes inside a working system, I've seen the dark side of this mentality result in frustration & wasted time on a large scale. This can include bugs in tools that go unfixed, hacky work-arounds from content creators who are trying to avoid asking for programming help, and in the worst cases divisions between departments in a team. Ultimately this rule shifts the risk of overtime from one department to another, and doesn't address the problem.

The real key to avoiding crunch times is accurately estimating scope, and making decisions about how to manage that in a way that is respectful to all of the departments on a team. The problem is both of those steps are difficult to do well.

Robert Fearon
profile image
"This is ultimately saying that art time is worth less than programming time"

Right yeah. That's not reallly what I'm saying but I figured when I wrote that it was a fairly reasonable conclusion that someone would come to from it. Understandable too and yup, your points are sound and I agree. I did think about adding a disclaimer before I hit publish but I also figured that someone else would pull me on it and for that alone, it'd be worth keeping as is.

In our case, rather - in our very specific case given the way we work as a team and with the games we're currently making -, it's something that works best for our dynamic. Given that the majority of the work will be on Andy's side any steps that can help ease off his workload are super important. I'm going to be having a lot more downtime where I'm not doing things than he is. Hence anything he can foist off onto me, it's worthwhile doing.

For us, it's more about equalising things than prioritising one over the other and keeping a healthy balance for the two of us. I understand entirely that this isn't scaleable and would indeed be pillar to post'ing for most.


none
 
Comment: