Why I Would Hire Game Developers for my Startup
paulbakaus.com
paulbakaus.com
- Game developers are high-energy and are there because they really, really want to be doing their job. They could make more money doing something less sexy, so they're self-selected enthusiasts.
- My game projects tended to be under one year, with high pressure, clear goals and a definite deadline. This, and the general culture of the industry, encouraged lots of crunch time, and made any code philosophy other than churning out code asap hard to adopt.
- Driven by both their motivation and the project conditions, good game programmers are awesome at creating a lot of decent code very fast.
So, judged purely on coding game programmers tend to be pretty strong. The trade-off is that there are a lot of skills they don't have to develop that you need in the web world. The whole mindset of everything (apart from the HTML rendering) running on a machine you control changes things fundamentally:
- It's far easier to deploy fast and deal with problems as they arise, rather than coding and testing defensively to avoid them in the first place
- Optimization is a completely different beast. You now control the hardware side of the equation too, so the old habits of improving performance can lead you astray
Anyway, this isn't as clear-cut as I'm painting it (I'm sure MMORPG guys have a lot more in common with web developers for example), but who's 'better' definitely depends on which dimensions you're looking at.
Moronic article that seems to think that comparing apples to battleships somehow makes sense.
(Speaking as a game developer for 14 years and a web developer for 8).
The only catch is that they tend to be obsessed with games. So if you want them to build something else make sure they are tired of the gaming world and want something new.
Anyone who can commit their software to a ROM disc has my respect.
Disclaimer: I only know a few game developers. They are really good -- and to man burned out on that industry.
I worked in the industry for approximately 6 years (2 companies) and got out due to the stressful crunch periods and associated drama of working in a game studio - if you are working on multiple titles, the stress increases by orders of magnitude. In addition to the bug fixing and testing there is the necessary hassle of submitting the games to SONY/MS/Nintendo, marketing coordination (with what seems like infinite number of mags and gaming sites), etc. and etc.
...now doing geospatial web applications.
Further: http://www.slideshare.net/dansaffer/gaming-the-web-using-the...
The idea is based on a few aspects that game developers almost universally share: they are trained to think of new, innovative ways to solve problems since each new game has to push the boundaries of what was possible before, they tend to be passionate about development and doing cool things with code, they are hardcore about optimization, and they are used to constantly learning new technologies and algorithms.
That said, not all aspects of game development are ideal for other projects, especially on the web. As others have mentioned, web development requires a very different mindset than game development. One major example is that game developers often build components from scratch, rather than re-using existing ones. One of the hardest skill for me to learn was to avoid "reinventing the wheel" and using pre-made off the shelf and open source components in projects.
I am definitely biased, but my own experiences have caused me to pay more attention to resumes I get that list game development experience, but not to the point of excluding others.
"For game devs, they know from the beginning on that the console they’re developing for cannot handle the raw 3D data, so they need to find optimization patterns right away!"
I understand trying to find the optimal pattern/process for completing a task, but this seems like it's trying to say pre-optimizing is a good idea. I couldn't disagree more.
If you ask them to work on the your enterprise webapp , you can bet they'll charge high rates. Programmers will take a pay cut for interesting work. And making games is interesting work. An accounting system, not so much.
Game developers put up with the hours and pay because they're (theoretically) doing what they love. They are no more likely to bring that love and dedication to a tech startup than they are to a giant corporate accounting system.
For example: - Test driven development - Deploy, measure, iterate practices - High level languages
Most of which are rare in the games industry but seem to be very successful in the web industry.
Test driven development or more simply unit testing code, is writing automated tests that ensure your code at the smallest unit you can access ( e.g. a single method ) is doing what you expect under all conditions.
See: http://en.wikipedia.org/wiki/Test-driven_development and: http://en.wikipedia.org/wiki/Unit_test
That having been said, TDD and automated testing can definitely make some headway into game development, but there are a whole host of challenges and questions to surmount there, especially for code-bases that are going to get stripped down to bare-bones every 1-3 years for a new game, if they get reused at all, so the tolerance for hacky code is quite a bit higher.
Of course, a "play test" is not an unit test, or an integration test (and is only mildly similar to an acceptance test.) Playtest-driven development would be an entirely new affair, likely involving gameplay freeze-states and kept in version control, and a constant numerical analysis for the player's emotional state (perhaps using some sort of face-recognition) given alternate code paths.
Most of which are rare in the games industry but seem to be very successful in the web industry.
HTTP is also successful in the web industry. Perhaps game programmers should use it to pass around all their information.
Less snarkily, there is a reason why those things are popular in web development: they're good at it. There is a reason why C++ is used in game development: it's good at it. High-level languages are commonly used in scripting and game logic, but, if used in the engine, would slow it to a crawl.
With respect to "deploy, measure, iterate": I have a suspicion that such a methodology isn't entirely feasible in an industry that ships product in the literal sense of shipping product. It's easy enough to do A/B testing on a website. It would be a touch more difficult to do it for Half-Life, given that the install base is approximately everywhere and you have control of roughly none of it.
Unit testing is an excellent technique for any development environment but is sadly rare in the games industry.
Iterating on disc products is not simple :) Though a lot of metrics could be gathered for use on a sequel. During development though iterative development should be ( and often isn't ) absolutely fundamental. Trying to "create fun" is an incredibly difficult task and can only be done with plenty of feedback.
However I've never heard of TDD being used. Also C++ tends to be used as the proverbial hammer (e.g. for scanning debug output, build scripts). C# is quickly taking over for tools but it's also taking over as the new improved hammer.