Hi everyone,
i am trying to find out what problems game developers are facing today. This is why i am doing a survey to better understand what your pain points are.
So please check out this short 3min survey. (one page only)
http://goo.gl/forms/9jEKGFECht
If you are interested in the outcome and aggregated results, feel free to leave your email at the bottom of the survey.
Thanks for your help.
Sebastian
What problems are game developers facing today?
Author
IMHO
Competition from other programmers / techs is turning the US technical job market into a brutal cut-throat experience .
It doesn't help that the number of H-1B and related visas have been raised in this country to the point they outpace job growth.
I have had a moderate amount of success in the industry. One of the aspects which has eaten a lot of my time is work into projects that were nowhere near as fruitful as the leaders claimed. I believe that I would have gone further as 100% independent developer. Don't fall for the hype!
Code Fox is correct that there is saturation in technical fields. Contrary to what corporations claim in the USA of not having enough technical people, my experience is that they come from every direction and out the woodwork when word gets out of a job or project.
Studies have shown that immigration of technical people from other parts of the world is driving wages down adjusted to inflation. From 2012 onward, corporations are posting record profits, both in amount and rates, on average. (I don't know the profit condition of the gaming industry now.) It is only going to get far worse as the USA finds itself outnumbered 1,000 to 1 in the world in this century for technical workers. To hell with the corporate ladder.
I am convinced that Indy Developer is the way to go.
I put this in your report, but I am adding it here because it seriously pisses me off.
The main problem at my company is that people keep committing bad code. It either doesn’t compile or crashes during run-time.
Next year I am going to be a leader in the company, and the absolute first thing I am going to do is create something like a wall of shame, where your bad commits are public. I know that bad commits happen, even for me, but currently there is no incentive to double-check your code etc.
I know that even I will eventually end up on the wall of shame, but the point is to motivate people to stop committing shit code. It either doesn’t compile at all or it asserts at run-time.
These kinds of problems are probably the single biggest in the entire industry. They are major time-wasters. I’m a senior now and will be a lead next year. It’s literally the first thing I will do, because it is literally the biggest issue when it comes to productivity.
L. Spiro
The main problem at my company is that people keep committing bad code. It either doesn’t compile or crashes during run-time.
Next year I am going to be a leader in the company, and the absolute first thing I am going to do is create something like a wall of shame, where your bad commits are public. I know that bad commits happen, even for me, but currently there is no incentive to double-check your code etc.
I know that even I will eventually end up on the wall of shame, but the point is to motivate people to stop committing shit code. It either doesn’t compile at all or it asserts at run-time.
These kinds of problems are probably the single biggest in the entire industry. They are major time-wasters. I’m a senior now and will be a lead next year. It’s literally the first thing I will do, because it is literally the biggest issue when it comes to productivity.
L. Spiro
That is a big problem, but fortunately one that is easily remedied. I wrote about a bigger one in my survey (resource availability).
Here was our best solution to the bad commits that have corrected it about as far as we're able:
#1. Every bad commit that breaks the build stops all -- or nearly all -- development on the team. For something that breaks the automated build from running, everybody joins the search. For bad builds that just don't run properly for unknown reasons, about half the team joins the search. Once the bad build is found we (leads) verify it get the fix in immediately. While we wait for the automated build to run, EVERYONE on the team (the animators if it was an animation issue, the network programming group if it was theirs, etc) gets to meet in the conference room.
Within a day, and typically it is immediate while the build servers are running, the person who broke it and the person who buddy checked the submission (more on that later) puts it up on the screen and explains to everyone what was broken. If they're junior members or if they really need the help they are shown a diff of the changes, or a more senior team member will run that. They then explain what tests they did on the before submitting, and why those tests did not find the error.
For the junior level people on the team this is often embarrassing but over very quickly, with easily missed problems and failure to do basic tests on their code. Often things like "I forgot to test for null", or "I didn't check the return value", and other beginner mistakes. For the art team especially the response frequently is "I just didn't bother to test it in game before submitting, I assumed it would work. I'll follow the rules to run it in game before submitting in the future."
For the mid level people on the team they usually did run all the expected tests, and it serves as a reminder to test all the little corner cases.
And when a senior level person breaks the build, usually it is for some crazy reason that is subtle, and when they share why it broke everybody learns something or we discover serious underlying flaws in the system. Like learning that one of the build chains for a secondary tool that is rarely rebuilt is still using an old pre-C++11 library that happens to break under some odd conditions.
While it does have some 'public shaming' aspects, it also serves as a learning tool to everyone on the team. We can see what mistakes are being repeated. If multiple people start repeating mistakes we can establish policy to fix it. Most team members hopefully learn about something in the code. Critical learning happens.
I once heard and then adopted the mantra that junior developers are expected to break the build fairly frequently with naive mistakes, mid level developers should break it less often with avoidable but sometimes tricky mistakes, and senior developers should break it very rarely, but those breakages should be with amazing mistakes. Someone who never breaks the build is someone who isn't trying hard enough.
#2. Public shaming when the problems are bad, but it applies to everyone from the junior developer to the most senior. Years ago someone on a team made a lovely .. well, ... necklace, or maybe pendant or medal would be better descriptors. I wish I had a picture. It starts with a big pink feather boa, worn around the neck. Then there was a toy they found -- a "Hello Kitty" character about 8" or 20cm tall. It is decorated with a big "I Broke The Build" message. The whole thing was then hit with a Bedazzler or something to be garishly ugly with sparkles and glued beads and ribbons of uncoordinated colors. Over time it gained additional decorations to make it quite unappealing.
If you broke the build, you got to wear the "I Broke The Build Kitty" for the rest of your day, then hang it on your cubicle until the next unfortunate soul gets it.
Sadly it eventually fell apart and was not put back together, but by then the problems were mostly resolved and it was no longer necessary to publicly call it out more than the immediate post-fix meeting.
#3. Assorted policies that grew up as a result of item #1. All submissions must be built locally and run at least once, even artwork. Art images must be viewed in game at least once, and code must be run and stepped through in the debugger. This one seems like it should be obvious, but too many people originally didn't even bother with that. All submissions must be buddy checked before submission to the main branch, the person cannot merge their own changes but must have a buddy review them, verify them, and merge them. Somebody within the group of senior developers must review the list of submissions every day, even if that is just reading through them quickly and checking for obvious issues. All submissions need a descriptive title that additionally tags the bug number or story number or feature ID (like: fix for fss-2345, use case insensitive search on profanity filter) which is nice for reviewing changes and also for auto-linking the issues and features with code submissions. And so on.
The policies take a little time, and they do slow down development slightly since each team member spends about 30-60 minutes each day on buddy checks, but the number of broken builds is very low, often weeks between breakages, and code quality increased substantially since we first started building the policies.
Here was our best solution to the bad commits that have corrected it about as far as we're able:
#1. Every bad commit that breaks the build stops all -- or nearly all -- development on the team. For something that breaks the automated build from running, everybody joins the search. For bad builds that just don't run properly for unknown reasons, about half the team joins the search. Once the bad build is found we (leads) verify it get the fix in immediately. While we wait for the automated build to run, EVERYONE on the team (the animators if it was an animation issue, the network programming group if it was theirs, etc) gets to meet in the conference room.
Within a day, and typically it is immediate while the build servers are running, the person who broke it and the person who buddy checked the submission (more on that later) puts it up on the screen and explains to everyone what was broken. If they're junior members or if they really need the help they are shown a diff of the changes, or a more senior team member will run that. They then explain what tests they did on the before submitting, and why those tests did not find the error.
For the junior level people on the team this is often embarrassing but over very quickly, with easily missed problems and failure to do basic tests on their code. Often things like "I forgot to test for null", or "I didn't check the return value", and other beginner mistakes. For the art team especially the response frequently is "I just didn't bother to test it in game before submitting, I assumed it would work. I'll follow the rules to run it in game before submitting in the future."
For the mid level people on the team they usually did run all the expected tests, and it serves as a reminder to test all the little corner cases.
And when a senior level person breaks the build, usually it is for some crazy reason that is subtle, and when they share why it broke everybody learns something or we discover serious underlying flaws in the system. Like learning that one of the build chains for a secondary tool that is rarely rebuilt is still using an old pre-C++11 library that happens to break under some odd conditions.
While it does have some 'public shaming' aspects, it also serves as a learning tool to everyone on the team. We can see what mistakes are being repeated. If multiple people start repeating mistakes we can establish policy to fix it. Most team members hopefully learn about something in the code. Critical learning happens.
I once heard and then adopted the mantra that junior developers are expected to break the build fairly frequently with naive mistakes, mid level developers should break it less often with avoidable but sometimes tricky mistakes, and senior developers should break it very rarely, but those breakages should be with amazing mistakes. Someone who never breaks the build is someone who isn't trying hard enough.
#2. Public shaming when the problems are bad, but it applies to everyone from the junior developer to the most senior. Years ago someone on a team made a lovely .. well, ... necklace, or maybe pendant or medal would be better descriptors. I wish I had a picture. It starts with a big pink feather boa, worn around the neck. Then there was a toy they found -- a "Hello Kitty" character about 8" or 20cm tall. It is decorated with a big "I Broke The Build" message. The whole thing was then hit with a Bedazzler or something to be garishly ugly with sparkles and glued beads and ribbons of uncoordinated colors. Over time it gained additional decorations to make it quite unappealing.
If you broke the build, you got to wear the "I Broke The Build Kitty" for the rest of your day, then hang it on your cubicle until the next unfortunate soul gets it.
Sadly it eventually fell apart and was not put back together, but by then the problems were mostly resolved and it was no longer necessary to publicly call it out more than the immediate post-fix meeting.
#3. Assorted policies that grew up as a result of item #1. All submissions must be built locally and run at least once, even artwork. Art images must be viewed in game at least once, and code must be run and stepped through in the debugger. This one seems like it should be obvious, but too many people originally didn't even bother with that. All submissions must be buddy checked before submission to the main branch, the person cannot merge their own changes but must have a buddy review them, verify them, and merge them. Somebody within the group of senior developers must review the list of submissions every day, even if that is just reading through them quickly and checking for obvious issues. All submissions need a descriptive title that additionally tags the bug number or story number or feature ID (like: fix for fss-2345, use case insensitive search on profanity filter) which is nice for reviewing changes and also for auto-linking the issues and features with code submissions. And so on.
The policies take a little time, and they do slow down development slightly since each team member spends about 30-60 minutes each day on buddy checks, but the number of broken builds is very low, often weeks between breakages, and code quality increased substantially since we first started building the policies.
The main problem at my company is that people keep committing bad code. It either doesn’t compile or crashes during run-time.
Yeah, this is a real "I'm going to straight up stab someone" problem for me too - made worse by my running a platform people don't develop on or test on.
Far too often I'll get latest only to discover it won't compile, often for massive glaring reasons (such as functions not being implemented on the damned platform!), because someone has gone "herp derp it works on windows it'll be fine" and checked it in, I come along, catch up and find it has broken my platform (and probably 2 others) with the knowledge that because I'm 5h a head of the person who checked it in a fix ain't turning up any time soon.
This is made worse by us having a CI system and one where you can trigger pre-flight tests and have it compile on more than one platform!
This is very much a cultural problem, far too often I see people check something in and the next 2 or 3 checkins are 'fixing problem <x>' with it.
(In contrast I check in less frequently but my shit tends to work first time because of this.)
Last place I worked had a better system, one I appreciate all the more now, where no one could check into mainline, you submitted into your branch then used a separate app to tell a central build system what change lists you wanted to integrate into mainline, it would put you in a queue and when your turn came it would integrate across, build and run some smoke tests across the platforms we were working on to ensure it built and at least booted correctly.
The downside was it could take a few hours for your change to hit mainline (queue time + 20 to 40mins depending on tests), but the upside was mainline was VERY stable and the builder was running 24/7 so even if you put something in the queue last thing on a week day then, chances are, it would be in by the time you got in.
(The app also featured an auto-catch system where, at a set time, it would pull from mainline to your branch and perform trivial integrations, submitting back to P4 on your branch if all merges were done - this was used to get around the 'everyone hammer P4 at 9am!' problem we had on a previous project.)
If you broke the build, you got to wear the "I Broke The Build Kitty" for the rest of your day, then hang it on your cubicle until the next unfortunate soul gets it.
A place where i used to work had the "cowboy of the week" award. If you seriously messed the system up, or did something really daft, you'd be awarded cowboy of the week award, which was a rusty sheriff badge certificate printed out with what you did (i kid you not) that you had to hang on your monitor for a week. It was awarded with much ceremony and the theme from rawhide...
Last place I worked had a better system, one I appreciate all the more now, where no one could check into mainline, you submitted into your branch then used a separate app to tell a central build system what change lists you wanted to integrate into mainline, it would put you in a queue and when your turn came it would integrate across, build and run some smoke tests across the platforms we were working on to ensure it built and at least booted correctly.
Broken builds SHOULD be a thing of the past. We set up TFS as a buildable machine, and have it try to build/deploy every checkin to a dev staging server. If someone merges a bad build, it skips it and sends an email out to our developer group.
If you guys use TFS and want this horrible specter removed, check out https://msdn.microsoft.com/en-us/library/dd787631.aspx and propose it. There's very little impact to teams, and saves days of work a year.
The survey is a bit weird in some places.
So please check out this short 3min survey. (one page only)
http://goo.gl/forms/9jEKGFECht
The non-business jobs listed are "design", "development" and "art & design". Development typically covers everything, including 'game design', 'level design', '3d art', '2d art', 'UI', 'animation', 'game programming', etc...
The answers given by a sound designer will be completely different from a business owner. On that note, you probably also should've asked for the number of employees -- the pains of a 2 man studio will be very different from a 200 man studio.
"Dey tuk are jerbs!" Really?Competition from other programmers / techs is turning the US technical job market into a brutal cut-throat experience.
It doesn't help that the number of H-1B and related visas have been raised in this country to the point they outpace job growth.
FWIW, I'm at the point in my career where I get harassed by American recruiters all the time, to try and fill roles that they can't easily find local talent to fill. In order to fill these positions, they're willing to offer me almost double the average American gamedev salary, plus free flights and hotels for the interview(s), visas for me and my family, relocation costs to ship my possessions halfway around the world, 3 months rent on an company apartment, plus assistance in finding my own apartment, assistance in opening bank accounts, getting US licenses, getting my kids into school, etc, etc...
That's a damn expensive endeavour for them to undertake, just for them to... what? Save money by driving down your wages? I think I must've missed something...
Nevermind that it's illegal to pay a H-1B holder less than an equivalent local worker, or that it has to be a specialty role. The equivalent visa in my country (457) also has the requirement that businesses have to advertise the role locally first, and only search overseas once enough time has lapsed to show that there is no local talent available.
Now sure, there may be unscrupulous companies out there who are bending/breaking the rules here, and they deserve to be exposed and punished... but in my experience, getting a visa into the US for gamedev is pretty damn hard, and only really occurs at the senior level, where expensive stories like the one above come into play. Not stories about mass-importing cheap labor to undercut the local population.
Shaming people does not fix the problem, it just toxifies your culture... if you already have a toxic culture though, go for it
The main problem at my company is that people keep committing bad code. It either doesn’t compile or crashes during run-time.
Next year I am going to be a leader in the company, and the absolute first thing I am going to do is create something like a wall of shame, where your bad commits are public. I know that bad commits happen, even for me, but currently there is no incentive to double-check your code etc.
Put an automated build & test machine into the commit pipeline. When you try to commit code, it goes into a queue. The build machine pops changesets from the queue and builds them. If they produce any compile errors or warnings on any platforms, then the build machine throws the changeset out and sends an email back to the author with the list of errors. If it does build successfully, then the machine farms out test cases to devkits for every platform. If any of those crash, then the build machine throws out their changeset, and the assertion message / log files are emailed back to the author. Only once the code has been built and ran on every platform, does the build machine actually allow the commit into the central repository.
You do that, you never have to deal with the fact that the master branch doesn't compile ever again. Occasionally game-breaking (but compilable) bugs will slip through, in which case you expand the automated test suite to try and catch others like it in the future. Thousands of man-hours saved without anyone making complaints to HR about harassment.
FWIW, I'm at the point in my career where I get harassed by American recruiters all the time, to try and fill roles that they can't easily find local talent to fill. In order to fill these positions, they're willing to offer me almost double the average American gamedev salary, plus free flights and hotels for the interview(s), visas for me and my family, relocation costs to ship my possessions halfway around the world, 3 months rent on an company apartment, plus assistance in finding my own apartment, assistance in opening bank accounts, getting US licenses, getting my kids into school, etc, etc...
That's a damn expensive endeavour for them to undertake, just for them to... what? Save money by driving down your wages? I think I must've missed something...
Nevermind that it's illegal to pay a H-1B holder less than an equivalent local worker, or that it has to be a specialty role. The equivalent visa in my country (457) also has the requirement that businesses have to advertise the role locally first, and only search overseas once enough time has lapsed to show that there is no local talent available.
Now sure, there may be unscrupulous companies out there who are bending/breaking the rules here, and they deserve to be exposed and punished... but in my experience, getting a visa into the US for gamedev is pretty damn hard, and only really occurs at the senior level, where expensive stories like the one above come into play. Not stories about mass-importing cheap labor to undercut the local population.
.
There are no laws in the US about "equivalent pay" for foreign workers ( or everyone ignores it ), but that is besides the point.
Your personal experience is not representative of the conditions of the technical jobs market, as a whole, in the US - There have been many posts on *THIS* forum about folks being forced to train their replacements imported from India and China ( which is not a rare event over here ).
On the programming end of things, I have personally seen many companies refuse to hire American workers, but will hire the first Indian worker that comes by simple because he works for $10 an hour, and doesn't know what 'over time' laws are in the US.
On my end of the technical jobs market, there are thousands of us who are fighting to get onto different projects, and I see it over and over again. Foreigners will get hired *BEFORE* Americans 3 out of 4 times - the kick to the groin is I have a lot training and qualifications to do my job, the foreigners they bring in, most of the time, have never done this kind of tech work before and have no qualifications.
Guess what - this behavior is very common on FEDERALLY CONTROLLED PROJECTS .
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
