Why I Would Hire Game Developers for my Startup(paulbakaus.com)
paulbakaus.com
Why I Would Hire Game Developers for my Startup
http://paulbakaus.com/2009/10/06/why-i-would-hire-game-developers-for-my-startup/
24 comments
Well, I for one can't wait for someone to come and show us whiny and despairing web developers how it's done.
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).
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).
I've been working at a major gaming studio in between startups and I have to agree with this - game programmers rock!
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.
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.
There's also a lot to be said for developing an (ordinary) application like a game. The best games teach players how to play slowly, building up knowledge and confidence as the game progresses. The best apps do this too, giving you rewards and tips when necessary, streamlining the sign-up and introductory processes to gain the confidence of new users.
Further: http://www.slideshare.net/dansaffer/gaming-the-web-using-the...
Further: http://www.slideshare.net/dansaffer/gaming-the-web-using-the...
My impression is that game developers mostly leave the gaming world after burning out too many times. Some cynical advice might be to only hire them a year after they stopped working on games?
Disclaimer: I only know a few game developers. They are really good -- and to man burned out on that industry.
Disclaimer: I only know a few game developers. They are really good -- and to man burned out on that industry.
I am one of the burned out ones ;)
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.
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.
While I share a lot of respect for game devs I'm curious about this quote from the article....
What do you mean by "While web developers have been whining for years and have been stuck in their despair"
The offer for one of my first programming jobs I landed was due to my having listed game development on my resume. The job had nothing to do with game development (though I later went on to build a 3D data visualization in DirectX that was a cornerstone of the software), but the people who hired me had the same mindset as this article.
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.
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.
I agree with this guy's thinking... but it's going to be hard to find a good game developer who wants to switch to web stuff. Try and recruit people who've just had kids. That's why I switched from games to something less crunchy (not web, but still)...
I don't know any game developers, so I can't really speak to their production quality/speed, but this quote just jumps out at me as a really bad thing:
"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.
"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.
This is like comparing apples to oranges. Game development is a more specialized industry. This is like comparing OS developers to VB developers. More people do web development, its easier to get into and therefore a lot more people just plain suck. Anyone who is in game development is probably already an above average developer, while an average web developer is, well average.
It doesn't hurt that game developers are willing to work their assess off for not a lot of money.
"It doesn't hurt that game developers are willing to work their assess off" on games "for not a lot of money".
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.
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.
to make games
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.
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.
I'm not sure I agree with the whining part, there is also an awful lot game developers could learn from web developers.
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.
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.
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.
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.
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.
I agree, there is no way a to-the-metal game engine will be written in any apart from C/C++ for a while. However, there is no reason why the higher level logic of the game ( the bit that is done by the designers/gameplay programmers ) shouldn't be done in a higher level language.
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.
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.
Others have pointed out that C++ is a necessity for at least the high-end games that push the hardware. High-level languages are used for scripting and logic (especially Lua). Deploy-measure-iterate is often used in the after-market for those games where it is appropriate, and in-house before release.
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.
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.
Game Development is test driven...When they play the part they just coded, isn't that testing?
I don't think you understand the significance of the word "driven." Coding something and then testing it is not TDD. In TDD, you don't write any application code that a failed test doesn't demand in order to pass—and even then, only just enough to make that test pass, even if it just means alwars returning 4 from a rand function.
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.
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.
Not quite the same thing, you are talking about QAing the product.
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
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's barely even testing, and it's certainly not TDD. If I play through the feature I just coded or the bug I just fixed, I can verify that it's doing what I think it's doing, but I need outside verification that it's correct. In effect, I can verify my code's precision (it's doing precisely what I told it to do), but not it's accuracy (if my idea of a feature is inaccurate, my own testing won't catch that).
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.
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.
game developers (who I respect immensely) aren't generally know for doing bug fixing for realtime services (unless they work on a WoW or its ilk).
Just curious, how much maintenance or code reuse do game developers have?
- 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.