Work life balance at game companies is always a hugely heated topic. Recently I’ve been getting a lot of questions – ‘what it’s really like’ and ‘is it really that bad?’ In this video I’ll go over my own experience along with what I’ve seen from friends and colleagues in the industry. Is crunching really that bad? Is it that common? Watch and find out 🙂
Ready to learn one of the most important skills for working with a game design team? Being able to predict what your design team will need in advance will make your job as a developer dramatically easier by reducing the amount of re-work and refactoring needed. And as an extra benefit, your design team will be pleasantly surprised when they ask for something and you tell them they can already do it!
Last week, I shared a bit of advice for web and business developers who are looking to make the change to video game development. It’s a big subject though, so today I’m going to follow up with a few more important things I’ve learned that you may want to know before taking the dive.
First, I want to address a couple objections I came across.. There are plenty of game developers who’ve had less than great experiences. I’ll start off with the worst stereotypes since they seem to be most prevalent.
If you haven’t read Part 1, I recommend you check it out as well, though the order doesn’t really matter – How to make games; Making the transition from business apps and web development into gaming – Part 1
There are horror stories all over the internet about the work conditions of your typical game developer. I’ll never forget when I heard about the EA spouses website.. a site dedicated to the spouses of overworked and underpaid EA employees who were exploited, working 60-80hrs a week with no overtime pay.
It’s true that there are places like this. I know a few developers who work at one big unnamed AAA game company that I’m told still acts like this. But I also know a few web developers who work in similar conditions.. on call all night, taking midnight meetings with teams across the world, working from 9am to 9pm..
Most places however are not like this.. It may have been the case that “everyone did it” decades ago, but today most game shops realize this is a terrible idea. And even more importantly, most game developers won’t put up with it.
Now it is the case that some game developers are kinda ‘workaholics’.. One of my best friends is like this. I’ve seen him work 12hrs/day building games for weeks at a time. But this isn’t something that’s usually pushed on them, they’re people who love what they do, love their project, and want to make it the best it can be. You’ll find people like this all across the professional spectrum, and they’re the exception, not the rule.
Crunch mode is what they call working way too many hours to finish a project that’s poorly managed and not on schedule. I’ve heard horror stories from friends in the past who lost their weekends, canceled vacations, and spent the night at the office on regular occasions. But most game developers I know have never experienced anything so crazy. There will always be times when you need to stay a bit late, maybe even work a really long day… If you’re launching the game you’ve been building for months or years, it’s probably a good idea to hang out and keep an eye on things. For the first few days, there may be bugs, crashes, etc that need to be fixed right away.
But in general, if you’re interviewing somewhere that says “crunching” is a normal thing, it’s probably not a great place to work. Any place that needs you to work long stints of overtime has a serious management failure. They’re failing to properly estimate and scope their projects. They could be overshooting, under-staffing to save money, or more often than not, just bad at time management and management in general. A well run project has attainable goals that are tracked throughout the process, without requiring the employees to sacrifice their entire life to get it done.
This is another theme that comes up quite a bit. “I want to build games, but I also don’t want to be poor”.
There is a grain of truth to this concern. If you’re starting out in game development, as a Jr. Programmer, there are plenty of places happy to take advantage of you. There are countless people who ‘want to make games’, and are willing to work for peanuts. When I started game development, I was just happy to get into the industry. Getting paid 50k/yr to do something I loved seemed great. And I saw plenty of other developers come in at numbers as low as 30k.
If you compare that to web development, it is a bit lower.. but it’s not that much lower. And it depends a whole lot on where you’re working. While some game shops pay their entry level developers near minimum wage, there are plenty of others that start people out at or above web developer salaries. In my experience it seems to be a typical representation of the supply & demand system. For popular games, there are 100’s of people applying, and many of them are willing to work for the bare minimum.. so those jobs are more likely to pay less because they can. But that willingness to work for low wages is much less prevalent for games that aren’t so well known.
It’s also important to note that on the high end, you can make just as much or more than in typical business development. Experienced Sr level game developers are a highly sought after commodity and can demand pay rates over 200k/yr. I’ve known a few experts making over 300k/yr.
Another thing I’ve only seen in game development are launch bonuses & commissions for the entire team. Not every place does this, but plenty do, and they can on occasion be huge. My first launch bonus was a check for 10% of my salary, and at one company, I was getting these about every 9 months. Sometimes these bonuses are based on sales. If you get in on a game early and it turns out to be a huge hit, these checks can be more than your salary. Now not everyone gets these, if you get an offer somewhere, you may want to ask if they have a commission or launch bonus program.
This is a tough subject. In web & line of business development, you can get a good idea of the code quality by checking out Unit test coverage. In most places I’ve worked, we had unit tests for anything important. Builds are run through continuous integration services, unit and integration tests are automatically run, and we know early if there’s a problem.
When you make the jump to games, be ready to see 0 automated tests. Of course a few select places have unit tests and automation, but they’re the exception to the rule.
This is something you’ll have to learn to accept, at least for the time being. I’ve seen a few friends really struggle with this. The feeling of comfort and correctness they get from unit tests in their day job is something they don’t want to lose on their ‘fun projects’. Most of the time though, after a lot of discussion, and burning 100’s of hours trying, they eventually give up on the tests.
As much as I love unit tests, there’s a good reason they’re not popular for game developers. Setting up tests for games is HARD. Much harder than it is for a website or your typical C.R.U.D. app with a few fancy screens. On a website, you have pretty tight control over what the user can do. They can fill out a couple fields, maybe leave some blank, click a button or two, and run through a few code paths to complete some operation. In most video games, your player can do all kinds of things, sometimes it’s stuff you’d expect but more often than not, they’re doing things you’d never think of.
Combine that with the countless interactions going on in your game, objects being destroyed, picked up, thrown in seemingly random directions.. The physics systems, rendering pipeline, the art pipeline which is out of your control.. design data put in by non-engineers, input systems, and everything else… It can quickly become a mess, impossible to test even a tiny % of possible scenarios.
On top of that, you don’t have the luxury of dependency injection. You can’t easily mock out substitutes for your player, or your enemies, or that remote player in Antarctica with a 5000 ping.
But there’s even more… for many games, you have to deal with devices nobody else does. Your game may need to run on xbox, playstation, pc, & ios. If you do get tests running, they’re probably not running on these actual devices. There’s no Selenium like solution to automate your gameplay across devices. And there’s no way to peek into the game and see how it’s responding to interactions like you can with a webpage.
Most game development shops have abnormally large QA / Test teams. In line of business development, I’ve experienced many setups where we had 1 tester per 10 developers. In games, I’ve never seen that ratio go above 1/3. In many situations I’ve seen it reversed, where there are more people testing the game than building it. This may seem counterproductive or expensive, but it’s done because it’s usually cheaper and more accurate. To get a game fully under automated tests would cost a whole lot more in expensive developer time than it does to hire a good QA team. It wouldn’t catch as many issues, and given how drastically games change in short periods of time, it’s not nearly as flexible.
For the time being, big test teams are something you’ll want to get used to. And it’s important to communicate well with them. If you release a new feature and don’t explain what it’s supposed to do, you’re going to get bad bug reports or missed issues.
Of course you’ll want to manually test your own changes first… don’t forget that step. And when you do, make sure to think.. “is this needlessly tedious?”.. “is there a way I can make this easier for QA?”. For example, if you know your QA team is going to need to summon 2000 items one by one, consider making a command that will let them pass in a text file of the items to load instead of wasting days of their time doing it item by item.
So far, I’ve focused on some of the less technical issues. This subject is a bit of a mix. It’s part engineering and part mindset.
One of the biggest mistakes I see people make as they transition is a tendency to over engineer things like crazy. People often start pulling in their web development patterns, attempting to re-create systems from their favorite framework, so they can ‘do game dev like they do web dev’.
This is a classic example of fighting against the engine. Instead of using what’s available or right, we attempt to use what’s comfortable. Many of us jump in and start trying to implement MVC everywhere.. our player’s visuals are the view right? The model has the characters data or something? The controller.. um maybe it’s the NPC? Or is it the NPC controller? “let me just build up a bunch of base classes and framework, THEN I’ll make my game”.
Now there’s nothing wrong with good design patterns.. where it makes sense. For your first few games, it almost never makes sense. Until you have a good level of experience in game development, with the engine you’re using, and have built a few games, you’re really just guessing what’s good.
When you start out in game development, especially if you start out on your own. Don’t start by building big systems. Build a game, learn, and only implement existing patterns when they really make sense and aren’t fighting against your engine.
And if you’re interested in learning some game specific patterns, this book comes highly recommended by a few developers: Game Development Patterns
Some programmers love to optimize. They love tricky algorithms designed to shave a few cpu cycles. They want to use arrays instead of lists because “they’re faster!”.
Optimization is a great thing. If you never optimize your game, you’ll probably run into serious performance problems.
But early / pre optimization is the bane of development. It’s often misguided.. attempting to make things better while accomplishing nothing (or even making things worse).
If you haven’t been developing games for a while, and profiling them, you’re not going to know what’s actually slow. If you think you need a “really fast lookup” for some objects, or you “don’t want to use Coroutines because you heard they’re slower”.. take a step back.
Remember that most of the optimization you know how to do from high scale web apps probably don’t apply to a game running on someone’s iPhone. In-fact, your optimizations probably won’t help at all, but knowing to check the GPU Instancing checkbox on the right things may make a huge difference.
And before you optimize anything, make sure you profile. For Unity developers, the profiler is built right in, and can usually show you exactly what’s slow. Often, you’ll be surprised by what it shows. For example, your Debug.Log statements are a huge performance hit. Those statements get a stack trace to display and will quickly kill your FPS if they’re called at a high rate.
Also make sure to test your release builds on occasion. The framerate difference from the editor to a release build can be big. That’s not to say you shouldn’t have a good level of performance in the editor too, but it’s something important to remember.
The last thing I want to touch on today is source control. Most of the non-game world is overcome with GIT now. It’s a great source control system, and it’s the one I use for everything.
There are some downsides to GIT with games though. Specifically the fact that art is LARGE, and it keeps all revisions locally. Having a bunch of art revisions in your main project can become problematic. Especially if your artists are using it for their art source files.
Many game development studios use alternative systems like Perforce, PlasticSCM, etc for this reason (and because Perforce has a strong hold in AAA game development).
Personally, I prefer GIT and use it for everything. But I always keep artist source work in another repository and only have them put the working or final product into the main repository.
I also recommend using GIT LFS for projects that are going to be art heavy. If you haven’t heard of LFS, it’s worth looking into here: https://git-lfs.github.com/
Merging your code in a game project isn’t really any different from merging anything else. But merging other assets can be a pain. In-fact it’s often an impossible task.
What other assets am I talking about? Things like your scenes (aka levels) & your prefabs. These are stored in big serialized files, ether in binary or text format. For minor changes, if you’re using text serialization, merging can be managable.
But most of the time, merging these types of things is more trouble than it’s worth.
You have a couple options. The first and most common is to break up your level into smaller chunks. You can create multiple scenes and have people work on them independently (designer 1 is working on the north east corner of this level in the LVL1_NE scene and designer 2 is working on the scene for the south east corner).
Or a more common thing is to make everything in your scene into a prefab. That way people can work on individual prefabs that are placed in the scene, and as long as they’re not working on the same one, everything is fine. If they’re granular enough and you have some decent management and communication, this won’t be too much of a problem.
But if you keep everything in the scene and don’t use prefabs, be prepared for a struggle.
There’s also an alternative in the Unity world called SceneFusion. I’ve only lightly played with it myself, but it does seem like an interesting fix for this kind of problem.
This is a question you’ll have to answer for yourself.. but before you do, think about what you’re doing now.
Do you love your job, find it challenging and fun? Or do hate your job and sit around thinking about how cool it’d be to make your own game?
Are you ready to accept that you won’t start off being the best game developer ever and will need to practice and build up your skills?
Do you only want to work on games if you can be on the team building Call of Duty, or only want to do it so you can be on stage at E3?
Or are you just into video games and like the idea of making something that puts a smile on other peoples faces.. something you can share with almost anyone and have them really enjoy what you’ve made? (I’ve never once shown my friends or kids a webpage I built that they cared about even a bit, but they’re always begging to help ‘test my new games’)
The final decision is up to you.. but I definitely recommend at least giving it a try.
Of course there are dozens of ways to start learning game development. My favorite way to learn this is by just doing them. Pick a game you want to build, find a tutorial and build the game. Try a few different ones, then start expand on them with your own changes. Once you feel comfortable, start building a game of your own from scratch.
I always like to recommend my basic 2D tutorial that takes you through the steps to build a Flappy Bird clone in an hour or two. If you don’t like reading though, I also love Brackey’s youtube videos. And if you’re really interested in VR, of course I’d point you at my VR Course.
Whatever you choose to learn with, if you get stuck, have some questions, or just wanna chat about game development, feel free to toss me an email (jason @ this website).. and make sure you have fun 🙂
